September 2021 - openSUSE Factory - openSUSE Mailing Lists

Tumbleweed with /bin /sbin /lib /lib64 move why is /opt not moved?
by Larry Len Rainey 18 Oct '21

18 Oct '21

12 12

Packaging issue for libz1/libz-ng-compat1
by Guillaume Gardet 13 Oct '21

13 Oct '21

Hi, In Tumbleweed, we have libz-ng-compat1 which can be a drop-in replacement of libz1. The problem is zypper drop the previous package, before installing the new one, but the lib is required to extract the new RPM. Any idea how to solve this problem in the spec file? Log: ******************************************************************************** sudo zypper in libz-ng-compat1 Loading repository data... Reading installed packages... Resolving package dependencies... Problem: the to be installed libz-ng-compat1-2.0.5-1.1.aarch64 conflicts with 'libz1' provided by the installed libz1-1.2.11-18.10.aarch64 Solution 1: deinstallation of libz1-1.2.11-18.10.aarch64 Solution 2: do not install libz-ng-compat1-2.0.5-1.1.aarch64 Choose from above solutions by number or cancel [1/2/c/d/?] (c): 1 Resolving dependencies... Resolving package dependencies... The following NEW package is going to be installed: libz-ng-compat1 The following package is going to be REMOVED: libz1 1 new package to install, 1 to remove. Overall download size: 67.9 KiB. Already cached: 0 B. After the operation, 5.7 KiB will be freed. Continue? [y/n/v/...? shows all options] (y): Retrieving package libz-ng-compat1-2.0.5-1.1.aarch64 (1/1), 67.9 KiB (142.4 KiB unpacked) Retrieving: libz-ng-compat1-2.0.5-1.1.aarch64.rpm ......................................................................................................................................................................................................................[done] Checking for file conflicts: ...........................................................................................................................................................................................................................................[done] (1/2) Removing libz1-1.2.11-18.10.aarch64 ..............................................................................................................................................................................................................................[done] (2/2) Installing: libz-ng-compat1-2.0.5-1.1.aarch64 ...................................................................................................................................................................................................................[error] Installation of libz-ng-compat1-2.0.5-1.1.aarch64 failed: Error: Subprocess failed. Error: RPM failed: rpm: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory Abort, retry, ignore? [a/r/i] (a): Problem occurred during or after installation or removal of packages: Installation has been aborted as directed. Please see the above error message for a hint. ******************************************************************************** Cheers, Guillaume

2 2

openSUSE:Factory - Build fail notification
by DimStar / Dominique Leuenberger 12 Oct '21

12 Oct '21

Dear Package maintainers and hackers. Below package(s) in openSUSE:Factory have been failing to build for at least 4 weeks. We tried to send out notifications to the configured bugowner/maintainers of the package(s), but so far no fix has been submitted. This probably means that the maintainer/bugowner did not yet find the time to look into the matter and he/she would certainly appreciate help to get this sorted. - libraqm - plasma-mycroft - rabbitmq-server Unless somebody is stepping up and submitting fixes, the listed package(s) are going to be removed from openSUSE:Factory. Kind regards, DimStar / Dominique Leuenberger <dimstar(a)opensuse.org>

3 2

openSUSE:Factory - Build fail notification
by DimStar / Dominique Leuenberger 12 Oct '21

12 Oct '21

Dear Package maintainers and hackers. Below package(s) in openSUSE:Factory have been failing to build for at least 4 weeks. We tried to send out notifications to the configured bugowner/maintainers of the package(s), but so far no fix has been submitted. This probably means that the maintainer/bugowner did not yet find the time to look into the matter and he/she would certainly appreciate help to get this sorted. - soapy-remote - soapy-uhd Unless somebody is stepping up and submitting fixes, the listed package(s) are going to be removed from openSUSE:Factory. Kind regards, DimStar / Dominique Leuenberger <dimstar(a)opensuse.org>

2 1

openSUSE:Factory - Build fail notification
by DimStar / Dominique Leuenberger 11 Oct '21

11 Oct '21

Dear Package maintainers and hackers. Below package(s) in openSUSE:Factory have been failing to build for at least 4 weeks. We tried to send out notifications to the configured bugowner/maintainers of the package(s), but so far no fix has been submitted. This probably means that the maintainer/bugowner did not yet find the time to look into the matter and he/she would certainly appreciate help to get this sorted. - pink-pony - python-hyper - python-pyftpdlib - python-thriftpy2 Unless somebody is stepping up and submitting fixes, the listed package(s) are going to be removed from openSUSE:Factory. Kind regards, DimStar / Dominique Leuenberger <dimstar(a)opensuse.org>

3 2

RFH: How to cross-compile rustc on openSUSE
by John Paul Adrian Glaubitz 07 Oct '21

07 Oct '21

Hello! I'm currently trying to cross-compile the Rust compiler on openSUSE but I'm running into the problem that the build system wants to invoke the cross-gcc compiler with the naming scheme $ARCH-linux-gnu-gcc where ARCH is the target architecture. However, on openSUSE, the cross-compiler prefix is $ARCH-suse-linux- which is why the build system can't find the cross-compiler although it has been installed. Does anyone know how to tell Rust's build system to use the proper cross-compile prefix, similar to the CROSS_COMPILE environment variable that the Linux kernel uses? Configuring the Rust compiler with "--host=$ARCH-suse-linux" doesn't work either. Thanks, Adrian

4 4

[opensuse-factory] openSUSE:Factory git mirror update
by Bernhard M. Wiedemann 04 Oct '21

04 Oct '21

Hi, our experimental git mirror of openSUSE:Factory got a new feature: It now makes single commits from most individual updates with some useful info in the commit message. This makes the whole history much nicer to read: https://github.com/bmwiedemann/openSUSE/commits/master In the usual case of SRs it links back to the SR on OBS, because that is where most of the discussion might have happened: https://github.com/bmwiedemann/openSUSE/commit/d1afc9699 but sometimes direct commits happen and they are shown with the commit message and a link to the OBS change https://github.com/bmwiedemann/openSUSE/commit/b2786e5c8 Ideas for future work: In theory we could also track these packages' devel projects on a 'devel' branch In a similar fashion we could also track openSUSE:Leap:15.* on stable/leap15_N branches to allow offline diff We could try to enable osc build to work from such git dirs. Either this uses the OBS server-side logic to resolve dependencies to get the usual .osc/_buildinfo* and .osc/_buildconfig* files or we re-implement or re-use OBS server logic to allow builds when offline. And then (in the foggy far future) it would be possible to make a gateway back from github pull-requests or gitlab merge-requests to submitting SRs in OBS. Or we re-think how OBS handles its source files until then. See https://www.youtube.com/watch?v=iY_ADUQiiQI&t=787 Ciao Bernhard M.

4 8

[opensuse-factory] openSUSE reproducible builds status 2021-05
by Bernhard M. Wiedemann 30 Sep '21

30 Sep '21

Hi, last month's status: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/… Last months' reproducible builds project updates (including my work): https://reproducible-builds.org/reports/2021-04/ This time I spent most time on rebuilding and fixing issues in 15.3 https://rb.zq1.de/leap/15.3/ has some stats. It was a bit more difficult than 15.2, because older SLE binaries do not get rebuilt, and even Leap is split between Backports and Leap project. I also ran my scripts on https://build.opensuse.org/project/show/openSUSE:Step:FrontRunner to check what stops building there and found many issues. I uploaded https://rb.zq1.de/compare.factory-20210531/ today and rbstats are: total-packages: 14026 (+71) build-tried: 13989 (+44) build-failed: 58 (-5) build-n-a: 164 (-9) build-succeeded: 13767 (+58) build-official-failed+na: 398 (+136) build-compare-failed: 365 (-1) build-compare-succeeded: 13402 (+59) verify-failed: 468 (-27) verified-semi-reproducible: 12588 (-372) bit-by-bit-identical: 13126 (-65) not-bit-by-bit-identical: 641 (+106) https://rb.zq1.de/compare.factory-20210531/graph.png shows the change over time https://rb.zq1.de/compare.factory-20210531/unreproduciblerings.txt lists very unreproducible core packages (bootstrap+DVD) Of the badly unreproducible packages, 3 were in ring0 46 were in ring1 That makes it 49/3247 => 1.51 % which is below the overall average of which is below the overall average of 365/13767 => 2.65 % 641/13767 => 4.66 % of packages are not perfectly reproducible newly unreproducible core packages: kopete is again/still unreproducible from https://bugreports.qt.io/browse/QTBUG-83186 python-pandas suffers from the usual .pyc non-determinism javassist has filesys-order-related variations in javadoc index-all.html Ciao Bernhard M.

1 4

YaST: highlights of development sprints 131 & 132
by Ancor Gonzalez Sosa 30 Sep '21

30 Sep '21

Again, the YaST Team combines the information from the two latest sprints into a single blog post, including: - Rethinking some internals in several areas - Heavy work (still in progress) on yast2-users - Improvements in the way YaST handles libYUI plugins - A visual fix in the packages manager - More progress in the release tools Check the full report at https://yast.opensuse.org/blog/2021-09-28/sprints-131-132 Cheers -- Ancor González Sosa YaST Team at SUSE Linux GmbH

2 1

No wayland since 20210920
by Bernhard Held 30 Sep '21

30 Sep '21

Hi, wayland/plasma doesn't start any more after on my venerable HD5450 since 20210920. It freezes immediately after startup with a black screen and a static mouse pointer. VT switching doesn't work. Recovery via SysRq-e is possible. It's reproducible: Wayland works again after rolling back; re-installation of > 3000 packages results in wayland freezing. Both IceWM and plasma on X11 are working. Is anybody else experiencing such a problem with wayland? I can't find any error messages. Is there a possibility to enable extra logging at startup of wayland or plasmashell? Thanks Bernhard

4 5