July 2019 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] Reclaiming /srv and some other servery type of stuff
by Stasiek Michalski 15 Jul '19

15 Jul '19

Hi, I was playing around with my server today, having some fun with setting up some services on it, and I noticed that nextcloud requires apache2 for no particular reason. So I went to mess with some specs. For quite some time I wanted to switch packaging around, as /srv should stay reserved for user needs and not packaging. It's easy to set up random sub pages and stuff manually with default apache/nginx configs when /srv is empty, however when it is also used for packaging, it makes unnecessary amount of mess in there, when default configuration could be solved with apache/nginx configs shipped with packages themselves. Don't get me wrong, I like when I install software and it instantly works, but this doesn't really require server software to be installed in /srv, it could work as well in /usr directories. I really don't like defaults to be forced upon me, I like when there are sub packages for different options I can use with certain software. Requiring apache2 with any server software is a crime if nothing else. I understand that with databases, certain stuff will plain not work when you switch mysql for pgsql, I accept that as a sad fact of reality, but there is (almost) no reason why any server software wouldn't work with nginx when apache is recommended. Even if I have to write the configs myself *and then push them upstream for anybody to use*. There are a few examples of software that requires requires apache, but it's rare. Taking nextcloud as an example, it recommends sqlite installation and requires mysql, when both can work independently with nextcloud (I believe it also kinda supports pgsql, but don't quote me on that). This could easily be split into 3 packages, with the same provides, similar supplements and a requirement in the main package to install one of three sub packages for the database based on the provides set up earlier. In similar fashion, that could be done with web server. This is not really a rant, I'm ready to do the work on all of this, but a heads up, I really want to do this now. If anybody is willing to join in on the fun of getting 60 packages sorted, come and join me. This is the list of src packages that install to /srv (gathered using dnf, because zypper can't get remote file list *grumble grumble*): adminer apache2 apache2-mod_perl apcupsd atftp bugzilla cacti cgit cobbler collectd dnsmasq exim firebird froxlor ganglia-web git gitolite gnump3d hiawatha htdig info2html kohana2 libinfinity mailgraph mathgl matomo moinmoin-wiki munin ndpmon nextcloud nginx nut otrs pagure php7 phpMyAdmin phpPgAdmin python-kiwi roundcubemail salt salt-shaptools sarg sca-appliance-broker sca-appliance-common sca-appliance-patdev sleuth source-highlight squidGuard subversion system-users tftp thttpd tomcat velum viewvc vnstat w3c-markup-validator webalizer webdot wt xsp If that goes through, and every package stops using /srv, I expect that the rpmlint checks will advise against using the directory for packaging in the future, just so I don't need to complain again ;) LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

14 30

[opensuse-factory] I need help with RPM macros
by Larry Finger 12 Jul '19

12 Jul '19

In the spec file for VirtualBox is the following code: %patch128 -p1 %if 0%{?suse_version} > 1500 || (0%{?sle_version} >= 150100 && 0%{?is_opensuse}) # Tumbleweed, Leap 15.1 and above drm adjustments %patch129 -p1 %else %if (0%{?sle_version} == 150100) # Patch only for SLE15.1 %patch133 -p1 %endif %endif # Qt5.13 adjustments %if %{qt5ver} >= 51300 %patch131 -p1 %endif %patch132 -p1 Patch #129 is needed for Leap 15.1, and patch #133 is needed for SLE15 and for SLE15_SP1. The log shows that Patch #128 is applied, followed by #132. My problem is that Patch #133 is not used. Anyone know why? Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 5

[opensuse-factory] Am I the only one with massive pulseaudio-bluetooth problems since ~ last week?
by Markus Feilner 12 Jul '19

12 Jul '19

Hi dear former colleagues and great opensuse community! I am back, with a different e-mail address, but still running Tumbleweed on ~5 desktops. and I am taking the following problem as a "hello again, I am back!"... Since about a week all of them fail to connect to my Bluetooth headphones and other audio devices. They connect, then disconnect. I didn't find anything about that in the forests of Google and on opensuse mailing lists - I find it hard to believe I am the only one that suffers from that... (on Dell, Acer, and Lenovo hardware). Android phones connect instantly. Who can help? Where should I ask this question? mfeilner@fibonacci:~> bluetoothctl Agent registered [bluetooth]# paired-devices Device 0C:A6:94:D1:77:5D PhilipsBT [bluetooth]# devices Device 0C:A6:94:D1:77:5D PhilipsBT [bluetooth]# connect 0C:A6:94:D1:77:5D Attempting to connect to 0C:A6:94:D1:77:5D [CHG] Device 0C:A6:94:D1:77:5D Connected: yes Failed to connect: org.bluez.Error.Failed [CHG] Device 0C:A6:94:D1:77:5D Connected: no [bluetooth]# trust 0C:A6:94:D1:77:5D [CHG] Device 0C:A6:94:D1:77:5D Trusted: yes Changing 0C:A6:94:D1:77:5D trust succeeded [bluetooth]# connect 0C:A6:94:D1:77:5D Attempting to connect to 0C:A6:94:D1:77:5D [CHG] Device 0C:A6:94:D1:77:5D Connected: yes Failed to connect: org.bluez.Error.Failed [CHG] Device 0C:A6:94:D1:77:5D Connected: no [CHG] Device 0C:A6:94:D1:77:5D Connected: yes [CHG] Device 0C:A6:94:D1:77:5D Connected: no [CHG] Device 0C:A6:94:D1:77:5D Connected: yes [CHG] Device 0C:A6:94:D1:77:5D Connected: no [bluetooth]# [bluetooth]# exit from journalctl -xe: Jul 12 11:17:43 fibonacci bluetoothd[1734]: connect error: Connection refused (111) Jul 12 11:17:43 fibonacci plasmashell[7493]: org.kde.bluez: PendingCall Error: "Resource temporarily unavailable" Jul 12 11:17:53 fibonacci bluetoothd[1734]: connect error: Connection refused (111) Jul 12 11:17:53 fibonacci kcmshell5[20253]: org.kde.bluez: PendingCall Error: "Resource temporarily unavailable" and here's a hcidump of the connect I tried from the desktop: # hcidump HCI sniffer - Bluetooth packet analyzer ver 5.50 device: hci0 snap_len: 1500 filter: 0xffffffffffffffff < HCI Command: Create Connection (0x01|0x0005) plen 13 bdaddr 0C:A6:94:D1:77:5D ptype 0xcc18 rswitch 0x01 clkoffset 0x0000 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 > HCI Event: Command Status (0x0f) plen 4 Create Connection (0x01|0x0005) status 0x00 ncmd 1 > HCI Event: Vendor (0xff) plen 4 > HCI Event: Connect Complete (0x03) plen 11 status 0x00 handle 256 bdaddr 0C:A6:94:D1:77:5D type ACL encrypt 0x00 < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2 handle 256 > HCI Event: Command Status (0x0f) plen 4 Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7 bdaddr 0C:A6:94:D1:77:5D mode 1 > HCI Event: Max Slots Change (0x1b) plen 3 handle 256 slots 5 > HCI Event: Read Remote Supported Features (0x0b) plen 11 status 0x00 handle 256 Features: 0xff 0xfe 0x0f 0xc6 0x8b 0xef 0x59 0x83 < HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3 handle 256 page 1 > HCI Event: Command Status (0x0f) plen 4 Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1 > HCI Event: Read Remote Extended Features (0x23) plen 13 status 0x00 handle 256 page 1 max 0 Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 < HCI Command: Remote Name Request (0x01|0x0019) plen 10 bdaddr 0C:A6:94:D1:77:5D mode 2 clkoffset 0x0000 > HCI Event: Command Status (0x0f) plen 4 Remote Name Request (0x01|0x0019) status 0x00 ncmd 1 > HCI Event: Remote Name Req Complete (0x07) plen 255 status 0x00 bdaddr 0C:A6:94:D1:77:5D name 'PhilipsBT' < HCI Command: Authentication Requested (0x01|0x0011) plen 2 handle 256 > HCI Event: Command Status (0x0f) plen 4 Authentication Requested (0x01|0x0011) status 0x00 ncmd 1 > HCI Event: Link Key Request (0x17) plen 6 bdaddr 0C:A6:94:D1:77:5D < HCI Command: Link Key Request Reply (0x01|0x000b) plen 22 bdaddr 0C:A6:94:D1:77:5D key 763E2EC130E5B25CF27DD036A4C34D46 > HCI Event: Command Complete (0x0e) plen 10 Link Key Request Reply (0x01|0x000b) ncmd 1 status 0x00 bdaddr 0C:A6:94:D1:77:5D > HCI Event: Auth Complete (0x06) plen 3 status 0x00 handle 256 < HCI Command: Set Connection Encryption (0x01|0x0013) plen 3 handle 256 encrypt 0x01 > HCI Event: Command Status (0x0f) plen 4 Set Connection Encryption (0x01|0x0013) status 0x00 ncmd 1 > HCI Event: Encrypt Change (0x08) plen 4 status 0x00 handle 256 encrypt 0x01 < HCI Command: Read Encryption Key Size (0x05|0x0008) plen 2 > HCI Event: Command Complete (0x0e) plen 7 Read Encryption Key Size (0x05|0x0008) ncmd 1 < ACL data: handle 256 flags 0x00 dlen 10 L2CAP(s): Info req: type 2 > HCI Event: Number of Completed Packets (0x13) plen 5 handle 256 packets 1 > ACL data: handle 256 flags 0x02 dlen 16 L2CAP(s): Info rsp: type 2 result 0 Extended feature mask 0x0000 < HCI Command: Disconnect (0x01|0x0006) plen 3 handle 256 reason 0x13 Reason: Remote User Terminated Connection > HCI Event: Command Status (0x0f) plen 4 Disconnect (0x01|0x0006) status 0x00 ncmd 1 > HCI Event: Disconn Complete (0x05) plen 4 status 0x00 handle 256 reason 0x16 Reason: Connection Terminated by Local Host -- Best Regards - Mit freundlichen Grüßen, Markus Feilner ------------------------- _"Zu sagen was ist, bleibt die revolutionärste Tat."_ ------------------------- Leitender Redakteur IX - www.heise.de Karl-Wiechert-Alle 10, 30625 Hannover fon: +49 511 53 52 388 mail: mfe(a)ix.de PGP: 40A3C306F96133067C11CFD9A958A906268C9F0A http://www.feilner-it.net/files/MFpub.asc Xing: http://www.xing.com/profile/Markus_Feilner LinkedIn: https://www.linkedin.com/in/markusfeilner ------------------------- Mindestinformationen nach §37a HGB: Heise Medien GmbH & Co. KG Registergericht: Amtsgericht Hannover HRA 26709 Persoenlich haftende Gesellschafterin: Heise Medien Geschaeftsfuehrung GmbH Registergericht: Amtsgericht Hannover, HRB 60405 Geschaeftsfuehrer: Ansgar Heise, Dr. Alfons Schraeder -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

7 16

[opensuse-factory] Re: [opensuse] how do I disable snapper?
by Hans-Peter Jansen 12 Jul '19

12 Jul '19

[Sorry for cross post, but I think, this discussion belongs to factory] Am Freitag, 12. Juli 2019, 13:13:58 CEST schrieb Mathias Homann: > Am Freitag, 12. Juli 2019, 11:24:59 CEST schrieb Carlos E. R.: > > You simply need a much bigger root partition. 100 gigs at least. > > please read this out loud, slowly, and let it sink in. > > And anyone who still believes in btrfs: do the same, twice. What I find ridiculous is, that it's the installation default. Of course, none of the about 100 openSUSE installations, that I care about (and did the installation), have btrfs roots. I use xfs¹. The only systems, that cross my site and use btrfs roots were installed by others, *less* informed users. What's interesting here: those, who are typically not capable of dealing with related issues use it, because they accepted the defaults. In that way, openSUSE becomes a (failed) technology presentation for them, before they go somewhere else. What does openSUSE want to prove with this policy? "We (about to) master a technology, that most probably *will* fall on your feet, or at least provide regular work at moments, where you can afford it fewest at all? Puzzled, Pete ¹) with 2 calculated deficits only: it cannot be shrunken, and dropbox will fail on it (for silly reasons, they insist running on ext4 file systems only. Obviously, they still have too many Linux customers..). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 1

[opensuse-factory] Accepting requests by non-maintainers
by Arjen de Korte 12 Jul '19

12 Jul '19

I just found out that a package I maintain (php-cs-fixer) got a request, which was accepted within three hours (and not by me). Why? Shouldn't maintainers be allowed a few days before someone stepping in? I'm f*cking pissed that someone just accepted this change without having a clue of what he is doing. Note: the 'new' version was released on the same date as the previous one and I deliberately choose not to use that one. Regards, Arjen -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 10

[opensuse-factory] Are OBS _constraints a broken concept?
by Stefan Brüns 12 Jul '19

12 Jul '19

Hi everyone, anyone else waiting for a package to go through Staging to land in Tumbleweed? Better see yourself to a large stack of book/DVDs/BluRays/whatever, as that will probably not happen in the near future. Just have a look at the Dashboard [1], and notice almost every Staging is stuck at 99%. And if you dig any deeper, all Stagings are waiting for Firefox to be built. Now, Firefox apparently is a monster and needs 16GByte of memory to build, but that's not the relevant part. The OBS has 4 workers able to build Firefox, and as FF needs about 2 hours to complete it should be able to complete a Staging about twice an hour. Unfortunately, that's only half (or more likely 5%) of the truth ... --- As we all know, FF runs much better if you rebuild it in your home project, just _link or copypac the one from the Mozilla OBS project. Make sure you build it for Leap 15.0, 15.1 and Tumbleweed, just in case. If you need some more customization, add a llvm and gcc copy, and ideally modify their _constraints to <physicalmem>16GB</> - you want it to build fast, after all ... Of course you can add _constraints to any other package as well. --- end of rant --- Several of the copies are the personal development projects of the respective package maintainers, and there also a few copies which are just personal experiments. These are IMHO using the OBS for what it is meant for. The majority, however are just plain links to the development projects, revision count 1, sitting there forever, creating bit-identical copies of other projects. Currently, it is possible for a single user to stage a DoS on the OBS, deliberately, by lack of knowledge or by just not caring. I think this is far from ideal. So, any good ideas how to remove these annoying delays from the Stagings? Kind regards, Stefan [1] https://build.opensuse.org/project/staging_projects/openSUSE:Factory -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019

2 1

[opensuse-factory] LyX and ImageMagick
by Cor Blom 11 Jul '19

11 Jul '19

Hi all, A week ago I asked on this list about ImageMagick's security settings, because it is an issue when using LyX. A follow-up question: would it be acceptable if LyX requires/recommends ImageMagick-config-7-upstream instead of going with the default? This question comes from one of the main developers of LyX, in whose opinion LyX with a crippled ImageMagick is not really usable and when we leave it to the (informed) user to make the change, we make it more difficult for average users. It is about a balance between security and usability. I am not a security expert, so I will accept the verdict given, but for the sake of the ease of the use of LyX I wanted to ask. To give context: we hardly get bug reports for LyX on openSUSE, but for a non-working eps preview we got a bug report. Thanks, Cor -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 4

[opensuse-factory] Missing announcement for TW Snapsh 0708
by Dominique Leuenberger / DimStar 10 Jul '19

10 Jul '19

Dear Users, A new snapshot, 20190708, has been published to the mirrors and is available for installation. Unofrtunately, the release mail will not come. In the last days, the openqa infrastructure was upgraded to Leap 15.1 (yay!) - and the web app producing the changelogs for the announcement is also running on this server. Unofrtunately, the upgrade caused a minor issue on this app - which is not installed from a package, but comes directly from git checkouts. As a consequence, it remained unnoticed that a package was no longer present on said machine. This issue has now been fixed, the missing package installed and the webapp is back operational. This means that the next snapshot to be published (hopefully 0709) should have the release announcement mail again and will contain the changelog of 0708 in plus (as the bot always does the diff to the last published changelog file it has) Additionally, there is a minor glitch which I can warn you about regarding this snapshot: The package python-Sphin1 has been renamed to python2-Sphinx (which is more in line with the package naming standards). This naturally resulted in rebuilt packages. The old as well as the new source package produce a python2-Sphinx-1.8.5-1.1.rpm - with different content. The repo metadata now contains the info about the NEW variant of those two RPMs, but most mirrors will stick with what they already have, as they check the file names to identify what needs to be mirrored. I retriggered this package for a rebuild, which will also be part of 0709 - resulting in python2-sphinx-1.8.5-1.2.rpm. This will allow mirrors to see this as a new file to be mirrored.

1 0

[opensuse-factory] New package for factory: solo
by Matthias Bach 09 Jul '19

09 Jul '19

Hi all, I'd like to add a new package to Factory: solo. The solo package provides support for the Solo and Solo Tap security key [1]. These are USB (and NFC) keys for use with Webauthn / FIDO2. The package is based on the upstream main solo source repository [2] and maintained in the Hardware project. Currently the only binary package provided ensures proper udev rules are in place so that local non-root users can use the devices. I plan on also packaging the Python client [3] that can be used to configure and flash the devices. However, there are currently some dependency issues for that one. As basic support already solves the most important use case (webauthn) I did not want to delay submission until those are resolved. Kind Regards, Matthias [1]: https://solokeys.com/ [2]: https://github.com/solokeys/solo [3]: https://github.com/solokeys/solo-python -- Dr. Matthias Bach www.marix.org „Der einzige Weg, die Grenzen des Möglichen zu finden, ist ein klein wenig über diese hinaus in das Unmögliche vorzustoßen.“ - Arthur C. Clarke

3 3

[opensuse-factory] [PLEASE SPEAK UP] Disabling legacy file systems by default?
by Martin Wilck 09 Jul '19

09 Jul '19

SUSE will blacklist a number of legacy and/or less frequently used file systems by default on SLES for security reasons. The proposed list can be seen here: https://github.com/openSUSE/suse-module-tools/pull/5/commits/8cb42fb6658f21… The question is now whether we should do the same for openSUSE. I figure that while the above list is probably not controversial for enterprise customers, openSUSE users may have objections to some items on the list. Please speak up if you do. In any case, note that even if we do this, you can re-enable the filesystems you need by simply commenting out lines in the blacklist file. Regards, Martin -- Dr. Martin Wilck <mwilck(a)suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

45 209