- openSUSE Packaging

Apache:Modules openSUSE_Leap_15.5 repo has bad checksums
by Daugherity, Andrew W 22 Dec '23

22 Dec '23

For the past few days, any zypper refresh operation on a machine with this repo enabled will fail like so: ==== Retrieving repository 'Third-party modules for the Apache HTTP server. (openSUSE_Leap_15.5)' metadata -----------------------[\] Warning: Digest verification failed for file '1ec74d96a0429bd0dfee7acf227ab71bdcad2244ecf56de7d28c5daefd209bf7-primary.xml.gz' [/var/tmp/AP_0xnELCHG/repodata/1ec74d96a0429bd0dfee7acf227ab71bdcad2244ecf56de7d28c5daefd209bf7-primary.xml.gz] expected 1ec74d96a0429bd0dfee7acf227ab71bdcad2244ecf56de7d28c5daefd209bf7 but got 17511d69d98c32ae8193661bd4c8d02eb4a125d4ccc51a76fdd56e8ddd535b7a Accepting packages with wrong checksums can lead to a corrupted system and in extreme cases even to a system compromise. However if you made certain that the file with checksum '1751..' is secure, correct and should be used within this operation, enter the first 4 characters of the checksum to unblock using this file on your own risk. Empty input will discard the file. Unblock or discard? [1751/...? shows all options] (discard): Repository 'Third-party modules for the Apache HTTP server. (openSUSE_Leap_15.5)' is invalid. [Apache_Modules|https://download.opensuse.org/repositories/Apache:/Modules/o…] Valid metadata not found at specified URL History: - 1ec74d96a0429bd0dfee7acf227ab71bdcad2244ecf56de7d28c5daefd209bf7-primary.xml.gz has wrong checksum - Can't provide ./repodata/1ec74d96a0429bd0dfee7acf227ab71bdcad2244ecf56de7d28c5daefd209bf7-primary.xml.gz Please check if the URIs defined for this repository are pointing to a valid repository. Warning: Skipping repository 'Third-party modules for the Apache HTTP server. (openSUSE_Leap_15.5)' because of the above error. Some of the repositories have not been refreshed because of an error. ==== Strangely, the SLE_15_SP5 repo appears to be working fine. However I’ve noticed what look like typos in https://build.opensuse.org/projects/Apache:Modules/meta, where certain repos are using older versions of the update repos: <repository name="openSUSE_Leap_15.5"> <path project="openSUSE:Leap:15.4:Update" repository="standard"/> <arch>x86_64</arch> </repository> <repository name="SLE_15_SP5"> <path project="SUSE:SLE-15-SP3:Update" repository="standard"/> <arch>x86_64</arch> </repository> <repository name="SLE_15_SP4"> <path project="SUSE:SLE-15-SP3:Update" repository="standard"/> <arch>x86_64</arch> </repository> Shouldn’t those repos use openSUSE:Leap:15.5:Update, SUSE:SLE-15-SP5:Update, and SUSE:SLE-15-SP4:Update, respectively? Or is there any reason to have separate SLE and Leap repos any more since Leap now uses (mostly) SLE packages? Thanks, -Andrew

1 0

Source file not patched
by Axel Braun 22 Dec '23

22 Dec '23

Good morning, the new version of boost (1.84) breaks the build of orthanc in TW. This can be fixed with a little patch https://build.opensuse.org/package/view_file/home:DocB:Orthanc/orthanc/ libboost.diff?expand=1 I noticed that this patch is not included in the source-rpm (which is needed to build all plugins for Orthanc). Is there a trick to include this, or does every plugin needs to be patched? Thanks Axel

1 1

Buildservice Scheduler Dead?
by David C. Rankin 21 Dec '23

21 Dec '23

All, I was working an issue with /dev/ttyACM0 with Andrei on the user's list, see: "How can openSUSE udev rule for /dev/ttyACM0 impact communication with the device?", and he suggested and update to the kernel on 15.4 to the 6.6.7 in Backport - done. However, this laptop had built-in Nvidia (390.xxx driver), so I branched and patched the driver for the 6.6 kernel. See: https://build.opensuse.org/package/show/home:drankinatty:branches:X11:Drive… The build has been "finished" for hours and has not been picked up by the scheduler to give the "succeeded" or "failed". Is there something peculiar about the nvidia-gfxG04 package that prevents the scheduler from picking the packages up? When it "failed" it will come back with a "failed", but for reasons I can't explain, the build is stuck at "finished" - for hours... Any thoughts? -- David C. Rankin, J.D.,P.E.

1 3

-devel-static for LDC (D compiler) runtime and phobos
by Jake Drahos 19 Dec '23

19 Dec '23

The OBS build of LDC does not currently package libdruntime.a or libphobos2.a in any (sub)package. This means that there isn't a way of building a statically-linked D program with LDC short of building a new runtime and phobos to link against. Since static libs can be a delicate topic and static lib bloat best avoided for obvious reasons, I decided it'd be best to ask on the mailing list first instead of just putting together a pull request. Has there been any discussion on it as it applies to LDC (or other applicable compilers)? My position would be that the core runtime and stdlib for a compiler clearly count as an "exceptional case" to offer a -devel-static.

2 3

How to branch from user's build service home to mine?
by David C. Rankin 15 Dec '23

15 Dec '23

All, I can't figure out how to branch a package (the gcc-arm-none-eabi packages) from https://build.opensuse.org/project/show/home:wkazubski to my build service account with the new interface? I can't osc -a (Permission Denied) and I just need to get the packages to my build service to rebuild with the correct options so the executables will work on a Pi Pico (without hardlocking on every strcmp() call, etc..) What is the best way to go? The packages I need are: cross-arm-none-eabi-binutils cross-arm-none-eabi-gcc cross-arm-none-eabi-newlib (I've already rebuilt newlib locally, but it puts a hell of a demand on my laptop...) -- David C. Rankin, J.D.,P.E.

2 3

Increase the open file limit on OBS?
by Bruno Pitrus 14 Dec '23

14 Dec '23

I maintain the vscode package. In the latest version, all systems and architectures on OBS started failing with `EMFILE: too many open files, open '/home/abuild/rpmbuild/BUILD/[blah]'` (i assume this is being thrown by a nodejs process). The package builds fine in a chroot on my Tumbleweed computer where `ulimit -aH` shows the limit for open files as 524288. Is it possible to reconfigure the OBS kernel to allow this many too?

3 4

submitting CFLAG
by Axel Braun 13 Dec '23

13 Dec '23

Good morning, I try to submit a compiler option like export CFLAGS = -DUSE_X_DOM_SOCKET inside a spec file. From the wiki it seemed that RPM_OPT_FLAGS=\-DUSE_X_DOM_SOCKET\ would do the job, but that seems not the case. Whats the correct command? Thanks Axel

3 3

Conflicting requests for new JPM package
by Jochen Breuer 12 Dec '23

12 Dec '23

Hi folks, hi Soc, I've just noticed that we've got conflicting requests to create a new JPM package in devel:languages:misc. JPM is the Janet Project Manager tool and Janet is already in devel:languages:misc. So JPM is kind of missing there. There is a request from uncomfyhalomacro [0] and one from me [1]. Both are very similar. The main difference is that I'm using the bootstrapping script from upstream and uncomfyhalomacro is installing files manually. Not sure if the linux_config.janet is really needed past installation, but this is something we can discuss afterwards. While I like the approach with the bootstrapping script more, I'd be happy if any of them would be accepted. We could then start improving on top of the accepted package. Cheers, Jochen [0] https://build.opensuse.org/request/show/1123454 [1] https://build.opensuse.org/request/show/1125447

1 1

Global fix for "have choice for pkgconfig(icu-uc) needed by harfbuzz-devel: icu.691-devel libicu-devel"
by Stefan Brüns 09 Dec '23

09 Dec '23

Hi, currently, many packages in repositories based on openSUSE:Leap:15.{4,5} fail with the above error message. See e.g. [1] for quite some occurences. Another affected base repository is openSUSE:Backports:SLE-15-SP5. Repositories based on openSUSE:Leap:15.{4,5}:Update are fine. Some projects have worked around this by adding "Prefer: icu-devel" to their project config, while SUSE:SLE-15-SP4:Update [2] has: --- #request by dcermak 2023-01-25 #modified request by fvogdt 2023-01-27 #modified request by dmueller 2023-09-15 Prefer: -libicu60_2 -libicu69 -libicu-suse65_1 --- The current state is IMHO quite messy, and leaving this up to the individual projects is wrong. The packages inherited from openSUSE:Leap:15.5 should be in a consistent state, without need for any local fixups. So, can someone please add the actually correct lines to the relevant base projects? Kind regards, Stefan [1] https://www.google.com/search?q=opensuse+have+choice+harfbuzz+icu.691-devel [2] https://build.opensuse.org/projects/SUSE:SLE-15-SP4:Update/prjconf -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019

4 11

Leap 15.5 compiler error
by Axel Braun 07 Dec '23

07 Dec '23

Hi, I'm trying to compile the new OHIF-plugin for Orthanc and run into the following problem (Leap only, TW is fine): [ 26s] make[2]: Entering directory '/home/abuild/rpmbuild/BUILD/OrthancOHIF-1.1/build' [ 26s] [ 3%] Generating AUTOGENERATED/StaticAssets.cpp [ 26s] /usr/bin/python3.6 /home/abuild/rpmbuild/BUILD/OrthancOHIF-1.1/Resources/EmbedStaticAssets.py /home/abuild/rpmbuild/BUILD/OrthancOHIF-1.1/OHIF/dist /home/abuild/rpmbuild/BUILD/OrthancOHIF-1.1/build/AUTOGENERATED/StaticAssets.cpp [ 26s] Traceback (most recent call last): [ 26s] File "/home/abuild/rpmbuild/BUILD/OrthancOHIF-1.1/Resources/EmbedStaticAssets.py", line 116, in <module> [ 26s] compressed = gzip.compress(content, mtime=0) Is this an issue of make, or of the ancient python version? Thanks Axel https://build.opensuse.org/package/show/home:DocB:Orthanc/orthanc-ohif[1] -------- [1] https://build.opensuse.org/package/show/home:DocB:Orthanc/orthanc-ohif

3 4