- openSUSE Support

[opensuse-support] Sorting BCM20702 Bluetooth dongles
by Robert T Hardy 04 May '19

04 May '19

In /lib/firmware/brcm/ I currently have: -rw-r--r-- 1 root root 34700 Oct 24 2018 BCM20702A0-0a5c-21e8.hcd~ -rw-r--r-- 1 root root 34997 Dec 23 23:07 BCM20702A1-05ac-21e1.hcd -rw-r--r-- 1 root root 35042 Dec 23 23:07 BCM20702A1-0a5c-21e6.hcd -rw-r--r-- 1 root root 35934 Oct 24 2018 BCM20702A1-0a5c-21e8.hcd~ -rw-r--r-- 1 root root 35000 Dec 23 23:07 BCM20702A1-0b05-17cb.hcd -rw-r--r-- 1 root root 35127 Dec 23 23:07 BCM20702A1-0b05-17cf.hcd where the ones without the tilde are from package bcm20702a1-firmware . I use one of them, BCM20702A1-0b05-17cb.hcd, with an ASUSTek Computer, Inc. Broadcom BCM20702A0 Bluetooth dongle, and it works fine, excepting occasional weird interactions with an Android phone. I may want to get into that later. The other two are an attempt to provide firmware to a Broadcom Corp. BCM20702A0 Bluetooth 4.0 dongle. The A0 version is old; I don't remember where I got it; it may have come out of the box, but no matter, because there is no attempt made to load it, even when untilded. The A1 version comes from https://github.com/winterheart/broadcom-bt-firmware/ blob/master/brcm/BCM20702A1-0a5c-21e8.hcd . That one loads just fine, and disables the Bluetooth dongle as shown by: sgt:/lib/firmware/brcm # hciconfig -a hci0: Type: Primary Bus: USB BD Address: 00:02:72:DA:29:9C ACL MTU: 1021:8 SCO MTU: 64:1 DOWN RX bytes:3380 acl:0 sco:0 events:410 errors:0 TX bytes:36343 acl:0 sco:0 commands:409 errors:0 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT hci1: Type: Primary Bus: USB BD Address: 5C:F3:70:80:A0:29 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING PSCAN RX bytes:263513266 acl:907311 sco:1675 events:233331 errors:0 TX bytes:50912616 acl:465265 sco:1671 commands:254 errors:0 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'sgt.decathlon.org' Class: 0x1c010c Service Classes: Rendering, Capturing, Object Transfer Device Class: Computer, Laptop HCI Version: 4.0 (0x6) Revision: 0x15bb LMP Version: 4.0 (0x6) Subversion: 0x220e Manufacturer: Broadcom Corporation (15) and sgt:/lib/firmware/brcm # hciconfig hci0 up Can't init device hci0: Invalid request code (56) However, if I disable the firmware (with the tilde), then the dongle appears to work: sgt:/lib/firmware/brcm # hciconfig -a hci1: Type: Primary Bus: USB BD Address: 00:02:72:DA:29:9C ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING PSCAN ISCAN RX bytes:4018971 acl:17398 sco:0 events:6779 errors:0 TX bytes:1500425 acl:13379 sco:1 commands:55 errors:0 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'sgt.decathlon.org' Class: 0x1c010c Service Classes: Rendering, Capturing, Object Transfer Device Class: Computer, Laptop HCI Version: 4.0 (0x6) Revision: 0x1000 LMP Version: 4.0 (0x6) Subversion: 0x220e Manufacturer: Broadcom Corporation (15) hci0: Type: Primary Bus: USB BD Address: 5C:F3:70:80:A0:29 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING PSCAN ISCAN RX bytes:4750 acl:54 sco:0 events:305 errors:0 TX bytes:37328 acl:60 sco:0 commands:238 errors:0 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'sgt.decathlon.org #1' Class: 0x1c010c Service Classes: Rendering, Capturing, Object Transfer Device Class: Computer, Laptop HCI Version: 4.0 (0x6) Revision: 0x15bb LMP Version: 4.0 (0x6) Subversion: 0x220e Manufacturer: Broadcom Corporation (15) This is despite the message from the log: May 04 17:36:54 sgt.decathlon.org kernel: bluetooth hci1: Direct firmware load for brcm/BCM20702A1-0a5c-21e8.hcd failed with error -2 So I guess my first burning question is, is firmware loading necessary to the operation of my bluetooth dongle, or is it only necessary if you want up-to- date firmware. :-) Some other questions revolve around whether the bluetooth stack (and KDE, which I typically use) are up to handling two dongles, since the unplugging of the Broadcom dongle seems to disrupt the operation of the ASUSTek dongle. But that's enough for now. -- To unsubscribe, e-mail: opensuse-support+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-support+owner(a)opensuse.org

1 0

Fwd: Re: [opensuse-support] maven
by Christian Boltz 04 May '19

04 May '19

Hello, Fridrich answered to me and the mailinglist, but it looks like his mail didn't make it to the mailinglist. Therefore I'm forwarding it. My understanding of his mail is that the best solution is zypper rm apache-commons-parent because the package is now only needed at build time. ---------- Forwarded message ---------- Betreff: Re: [opensuse-support] maven Datum: Freitag, 3. Mai 2019, 22:49:33 CEST Von: Fridrich Strba <fridrich.strba AT suse DOT com> An: Christian Boltz <...>, opensuse-support(a)opensuse.org, Fridrich Strba <fstrba AT suse DOT com> Hello, TLDR; version: It was needed only for satisfying formal dependencies, and now it is not needed any more for any java package as runtime dependency. This changes that just landed last week are meant to make that package useful for maven build. On 03/05/2019 19:01, Christian Boltz wrote: > I also noticed this - maven etc. (a total of 123 additional packages [1]) > get dragged in by the latest apache-commons-parent package. > > Therefore a temporary workaround is > zypper al apache-commons-parent > to keep the old package version with less dependencies or > zypper rm apache-commons-parent > to uninstall it. Now, the parent pom files are only useful for maven builds. They provide information about needed plug-ins and build variables for their children projects. They are completely useless on runtime. Nevertheless, when we package a maven artifact using the dependency free %add_maven_depmap macro, the resulting metadata is not standalone and when using such a package, maven must resolve its pom file with all its dependencies and parent pom structure. When integrating maven into openSUSE, I came with better way of handling such packages. I simply remove from the pom file the parent information and leave the runtime dependencies only. There is even a macro for that in javapackages-local (%pom_remove_parent) This allows us to have a proper dependency information in the parent poms since they will not be used for anything else then for building using maven. Before, I had to patch out their dependency information, since they normally require maven plug-ins that were not packaged. > https://build.opensuse.org/package/revisions/openSUSE:Factory/apache-common… > looks like https://build.opensuse.org/request/show/691849 introduced the > additional dependencies. > > Fridrich, are these additional dependencies intentional? Yes, they are intentional because they allow us to use this particular parent package in maven builds. Nonetheless, the parent package should not be needed at runtime by anything. If it is not so, I should be punched and kicked to fixing that ASAP. > I also wonder why I have apache-commons-parent installed. > /var/log/zypp/history says it was installed as part of a zypper dup on > 2019-03-11, but rpm -q --whatrequires and --whatrecommends don't show > anything. At a certain moment of time, this package was needed by a majority of apache-commons-* packages. All the maven plugin dependencies were patched out of it and it was only used to satisfy formal dependency. Now, it is not needed by those packages. So, I stop patching out the dependencies and this package is useful for maven builds of apache-commons-* packages that we build with maven. Cheers Fridrich ------------------------------------------------------------- Regards, Christian Boltz -- <jjohansen> this change is inconsistent with what we do now <jjohansen> however what we do now is broken [from #apparmor] -- To unsubscribe, e-mail: opensuse-support+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-support+owner(a)opensuse.org

1 0

[opensuse-support] maven
by mike 04 May '19

04 May '19

Hi, Just curious, what are all these maven files showing for a tumbleweed zypper dup?? I am not a programmer and do not see any ANT on my system. Iam using a 500GB ssd and do not want to fill it with things I will not use. If I don't need them how would I prevent them from showing on my "zypper dup" ? Thanks........mike -- To unsubscribe, e-mail: opensuse-support+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-support+owner(a)opensuse.org

3 3

[opensuse-support] tw update leaves smb failing
by Patrick Shanahan 01 May '19

01 May '19

20190428 tumbleweed update and subsequent reboot leaves me w/o samba access to windows machines (primarily for backup purposes) and no cifs systemctl start smb Crash systemd[1]: Starting Samba SMB Daemon... May 01 08:22:10 Crash smbd[23147]: [2019/05/01 08:22:10.228654, 0] ../../source3/auth/auth_util.c:1386(make_new_session_info_guest) May 01 08:22:10 Crash smbd[23147]: create_local_token failed: NT_STATUS_NO_MEMORY May 01 08:22:10 Crash smbd[23147]: [2019/05/01 08:22:10.228791, 0] ../../source3/smbd/server.c:2041(main) May 01 08:22:10 Crash smbd[23147]: ERROR: failed to setup guest info. May 01 08:22:10 Crash systemd[1]: smb.service: Main process exited, code=exited, status=255/EXCEPTION May 01 08:22:10 Crash systemd[1]: smb.service: Failed with result 'exit-code'. May 01 08:22:10 Crash systemd[1]: Failed to start Samba SMB Daemon. # smb.conf is the main Samba configuration file. You find a full commented # version at /usr/share/doc/packages/samba/examples/smb.conf.SUSE if the # samba-doc package is installed. /etc/samba/smb.conf: [global] passdb backend = tdbsam printing = cups printcap name = cups printcap cache time = 750 cups options = raw map to guest = Bad User logon path = \\%L\profiles\.msprofile logon home = \\%L\%U\.9xprofile logon drive = P: usershare allow guests = No security = domain usershare max shares = 100 wins support = No wins server = [homes] comment = Home Directories valid users = %S, %D%w%S browseable = No read only = No inherit acls = Yes [profiles] comment = Network Profiles Service path = %H read only = No store dos attributes = Yes create mask = 0600 directory mask = 0700 [users] comment = All users path = /home read only = No inherit acls = Yes veto files = /aquota.user/groups/shares/ [groups] comment = All groups path = /home/groups read only = No inherit acls = Yes [printers] comment = All Printers path = /var/tmp printable = Yes create mask = 0600 browseable = No [print$] comment = Printer Drivers path = /var/lib/samba/drivers write list = @ntadmin root force group = ntadmin create mask = 0664 directory mask = 0775 I have found recent (~1 year) mention of NT_STATUS_NO_MEMORY, but none appear to apply to my status and until yesterdays update, my system worked fine. my local server on 42.2 appears to have developed the same or similar problem yesterday, no cifs access but samba is running, so may be something changed on windows 10. unadvertised as usual. the reverse is not true. the windows machine has directory access to my 42.2 server. tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-support+owner(a)opensuse.org

1 2

[opensuse-support] btrfs question
by Axel Braun 29 Apr '19

29 Apr '19

Hi, and another one regarding btrfs: fstrim is regulary running, and stopping the laptop going to suspend (which I usually only notice when the battery is empty...) fstrim is obviously triggered from systemd service btrfs-trim. For a for a 40GB btrfs partition it runs more than 2h on a Kingston-SSD! The second partition is a 850GB encrypted XFS partition - fstrim does not work on encrypted partitions w/o special settings in fstab. So the runtime must be related to the btrfs partition. That does not sound healthy to me. Any ideas? Cheers Axel -- To unsubscribe, e-mail: opensuse-support+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-support+owner(a)opensuse.org

2 2

[opensuse-support] snapper question
by Axel Braun 28 Apr '19

28 Apr '19

6 15

[opensuse-support] Fonts are not displayed right. XFCE, 15.1 Beta, Nvidia.
by Carlos E. R. 22 Apr '19

22 Apr '19

For example, in the XFCE terminal (default settings, except font size=11; black background as default), the '[' has a greenish tinct, and the ']' has a violet tinct. Previously I was using noveau with another theme, the tinct colours were a bit different. Now proprietary nvidia with theme "Eazel-blue". I try different themes, same issue. YaST, letters do not look very nice. Seem wires, too thin. Same hardware, with Leap 15.0, I don't notice these things. -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse-support+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-support+owner(a)opensuse.org

3 6

[opensuse-support] Erlang packages for Pleroma instance
by Maximilian Trummer 21 Apr '19

21 Apr '19

Hello, I'm trying to set up a Pleroma instance on Leap 15.0. Unfortunately there is no guide for openSUSE yet, so I'm going by the ones for Debian and CentOS[1][2]. The requirements are as follows (Debian's and CentOS' combined in one list): postgresql postgresql-contrib elixir erlang *erlang-dev* *erlang-tools* *erlang-parsetools* *erlang-xmerl* git build-essential I've marked the packages which are not immediately obvious to find on openSUSE. Is "erlang-dev" in Debian the same as openSUSE's "erlang-src"? The three packages "erlang-tools", "erlang-parsetools" and "erlang-xmerl" can be found in a home repo here [3]. Is it safe to use that? Any reason they aren't in the devel:languages:erlang project? regards from Easterhegg 2019 in Vienna [1] https://docs-develop.pleroma.social/debian_based_en.html [2] https://docs-develop.pleroma.social/centos7_en.html [3] https://build.opensuse.org/project/subprojects/home:Ledest:erlang

1 0

[opensuse-support] Installation of FlightGear removes nvidia rpms. Leap 15.1 Beta
by Carlos E. R. 21 Apr '19

21 Apr '19

#### YaST2 conflicts list - generated 2019-04-21 12:35:14 #### FlightGear-2017.3.1-lp151.2.6.x86_64 requires libSimGearCore.so.2017.3.1()(64bit), but this requirement cannot be provided not installable providers: libSimGearCore-2017_3_1-2017.3.1-lp151.2.3.x86_64[download.opensuse.org-oss] [ ] do not install FlightGear-2017.3.1-lp151.2.6.x86_64 [ ] break FlightGear-2017.3.1-lp151.2.6.x86_64 by ignoring some of its dependencies [ ] Following actions will be done: deinstallation of nvidia-computeG03-340.107-lp151.12.2.x86_64 deinstallation of x11-video-nvidiaG03-340.107-lp151.12.2.x86_64 #### YaST2 conflicts list END ### This crashes the graphic system on next boot. -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse-support+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-support+owner(a)opensuse.org

1 1

[opensuse-support] How is chronyd using IPv6, when I don't have IPv6?
by Carlos E. R. 21 Apr '19

21 Apr '19

2019-04-21T00:19:00.637082+02:00 Elesar chronyd[2008]: Source 2001:720:1014:a202::2 replaced with 213.251.52.234 2019-04-21T00:48:52.674097+02:00 Elesar chronyd[2008]: Source 2001:720:1014:a201::2 replaced with 2001:720:1014:a202::2 2019-04-21T01:18:44.846401+02:00 Elesar chronyd[2008]: Source 2001:720:424:1::1:15 replaced with 2001:720:1014:a201::2 2019-04-21T01:48:37.325828+02:00 Elesar chronyd[2008]: Source 2001:720:1014:a205::2 replaced with 2001:720:424:1::1:15 2019-04-21T02:18:29.433522+02:00 Elesar chronyd[2008]: Source 2001:720:1014:a201::2 replaced with 2a00:1158:3::14b 2019-04-21T02:48:21.786491+02:00 Elesar chronyd[2008]: Source 2001:720:1014:a202::2 replaced with 2a02:40c0:1000:1000::ffff:ffff 2019-04-21T03:18:15.151481+02:00 Elesar chronyd[2008]: Source 2a02:40c0:1000:1000::ffff:ffff replaced with 2001:720:1014:a202::2 -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse-support+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-support+owner(a)opensuse.org

1 1