Bug#1081678: gtk4: riscv64: please do not force softpipe to run the testsuite
Source: gtk4 Version: 4.16.0+ds-1 Severity: wishlist Tags: patch X-Debbugs-Cc: debian-ri...@lists.debian.org User: debian-ri...@lists.debian.org Usertags: riscv64 Dear maintainer, Since version 4.16.0+ds-1, softpipe is forced to run the gtk4 testsuite due to bug#1080475). As this bug is now fixed, could you please stop forcing softpipe? I have verified that after applying the patch below the gtk4 testsuite works fine with the fixed libllvm18 version (after downgrading weston due to #1081515). Other packages affected by the libllbm18 bug also work fine. Thanks Aurelien --- gtk4-4.16.0+ds/debian/rules +++ gtk4-4.16.0+ds/debian/rules @@ -260,8 +260,8 @@ # The doc-check tests aren't passing yet skipped_suites += docs -ifneq ($(filter mips% powerpc riscv% sparc%,$(DEB_HOST_ARCH_CPU)),) -$(info Disabling use of llvmpipe on this CPU, see https://bugs.debian.org/993550 and https://bugs.debian.org/1080435) +ifneq ($(filter mips% powerpc sparc%,$(DEB_HOST_ARCH_CPU)),) +$(info Disabling use of llvmpipe on this CPU, see https://bugs.debian.org/993550) export GALLIUM_DRIVER=softpipe # https://bugs.debian.org/1077178 ignore_reftests += label-shadows
Bug#1069959: libcbor FTBFS on hppa and mips to due different NaN encoding
Hi On 2024-09-11 23:01, Bo YU wrote: > Hi, > > Sorry for jumping into this topic. > > Is there anything I can do to push for updates to this package? > > Becasue the package blocked debci team to create riscv64/testing chroot > on our riscv64 workers due to this FTBFS on mips64el lead to fail to > migrate. > > On Mon, Aug 12, 2024 at 10:33:28AM +0200, Aurelien Jarno wrote: > > Hi, > ... > > > > But for upstream, it just hides the real bug. On those architectures, > > the NaN encoding is indeed different, but the resulted encoded data > > should be the identical, as defined in the RFC. Therefore I believe the > > real fix is to convert NaNs (and probably also infinities) during the > > encoding process. > > My initial thoughts is to report this to upstream and then we can Sounds good. > disable/skip NaNs related test on Debian side. But I am not sure if this > is appropriate so let me make sure first here. Yep, either that or ignoring the testsuite result on mips64el and hppa. Thanks Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1081515: gtk4: FTBFS with weston 14: many tests fail with --setup=wayland: Failed to open display
On 2024-09-12 20:59, Simon McVittie wrote:
> Control: retitle -1 gtk4: FTBFS with weston 14: many tests fail with
> --setup=wayland: Failed to open display
> Control: severity -1 serious
>
> (Please remove -ports from cc in replies, this is no longer believed to
> be -ports specific)
>
> On Thu, 12 Sep 2024 at 11:48:21 +0100, Simon McVittie wrote:
> > gtk4's test suite is failing on all -ports architectures that have buildds
> >
> > (/<>/debian/build/deb/testsuite/gtk/spinbutton:12693):
> > Gtk-WARNING **: 17:54:18.469: Failed to open display
>
> It seems that it's now also failing on release architectures, and the
> failure seems well-correlated with weston being upgraded to version 14.
> The reason this particularly affected -ports is that -ports didn't have
> an installable version of weston 13, so by definition all of their recent
> gtk4 builds had to be with weston 14.
>
> My current working theory is either a behaviour change in Weston 14,
> or Weston 14 is crashing part way through testing and all subsequent
> tests fail.
Weston 14 is crashing with SIGSEGV a following a few tests like flowbox
or textiter, despite the test being successful. The following tests
fails with no display.
Here is a backtrace for the flowbox test:
[New LWP 1618393]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `weston --backend=headless-backend.so
--socket=wayland-113 --idle-time=0'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x7f42fd8f8be5 in wl_shm_buffer_get_data () from
/lib/x86_64-linux-gnu/libwayland-server.so.0
(gdb) bt full
#0 0x7f42fd8f8be5 in wl_shm_buffer_get_data () at
/lib/x86_64-linux-gnu/libwayland-server.so.0
#1 0x7f42fd957327 in noop_renderer_attach (pnode=) at
../libweston/noop-renderer.c:97
es =
buffer = 0x558f9273d1b0
renderer =
shm_buffer = 0x0
data =
size =
i =
height =
stride =
unused = 0 '\000'
#2 0x7f42fd946c1a in paint_node_update_late (pnode=0x558f9273c330) at
../libweston/compositor.c:332
surf = 0x558f9273bf60
vis_dirty =
plane_dirty =
content_dirty =
buffer_dirty = true
surf =
vis_dirty =
plane_dirty =
content_dirty =
buffer_dirty =
__PRETTY_FUNCTION__ = "paint_node_update_late"
#3 weston_output_repaint (output=, now=0x7fff0a5a9790) at
../libweston/compositor.c:3785
pnode = 0x558f9273c330
animation =
cnext =
r =
frame_time_msec =
highest_requested =
ec =
next =
cb =
frame_callback_list = {prev = 0x0, next = 0x2800400}
ec =
pnode =
animation =
next =
cb =
cnext =
frame_callback_list = {prev = , next = }
r =
frame_time_msec =
highest_requested =
__PRETTY_FUNCTION__ = "weston_output_repaint"
tmp___ =
tmp___ =
#4 output_repaint_timer_handler (data=0x558f927129a0) at
../libweston/compositor.c:3988
compositor = 0x558f927129a0
backend =
output =
now = {tv_sec = 1651551, tv_nsec = 89727725}
ret =
#5 0x7f42fd8f9c4f in wl_event_loop_dispatch () at
/lib/x86_64-linux-gnu/libwayland-server.so.0
#6 0x7f42fd8f74c5 in wl_display_run () at
/lib/x86_64-linux-gnu/libwayland-server.so.0
#7 0x7f42fdb96eb2 in wet_main () at
/usr/lib/x86_64-linux-gnu/weston/libexec_weston.so.0
#8 0x7f42fd9b8dba in __libc_start_call_main
(main=main@entry=0x558f7141e050, argc=argc@entry=5,
argv=argv@entry=0x7fff0a5aa448) at ../sysdeps/nptl/libc_start_call_main.h:58
self =
result =
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140733367100488,
-8995727586356845932, 0, 140733367100536, 139925701668864, 94074568838560,
8995612458023297684, 9055958596649132692}, mask_was_saved = 0}}, priv = {pad =
{0x0, 0x0, 0x7fff0a5aa448, 0x5}, data = {prev = 0x0, cleanup = 0x0, canceltype
= 173712456}}}
not_first_call =
#9 0x7f42fd9b8e75 in __libc_start_main_impl (main=0x558f7141e050, argc=5,
argv=0x7fff0a5aa448, init=, fini=,
rtld_fini=, stack_end=0x7fff0a5aa438) at ../csu/libc-start.c:360
#10 0x558f7141e081 in ??? ()
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
Bug#1079548: gtk4: upload of 4.16 to unstable blocked by riscv64 build
On 2024-09-12 11:53, Simon McVittie wrote: > Control: unblock -1 by 1081275 > > On Sat, 24 Aug 2024 at 09:37:57 -0400, Jeremy Bícha wrote: > > This is a tracker bug with known blockers for uploading the new gtk4 > > series 4.15.x/4.16.x to Unstable. > > > > The new gtk4 series is required for libadwaita 1.6 which is required > > by many GNOME 47 apps. > > I believe we are now only waiting for GTK 4.16.0+ds-2 to be successfully > built on a riscv64 buildd. (It works on a porterbox, but it would be safer > to have a successful build on a buildd before going to unstable.) > > Would it be possible for a riscv64 porter or a buildd operator to bump up > the priority of gtk4/experimental (gtk4_4.16.0+ds-2) on riscv64, to get that > built a bit sooner? It seems it has been done. Unfortunately it failed to build from source, but it is not riscv64 specific and can be reproduced easily on amd64. As a first guess by looking at the packages difference, it seems to be due to weston 14, and seems to be corroborated by the corresponding autopkgtest: https://ci.debian.net/packages/g/gtk4/testing/amd64/51575899/ Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1081259: libreoffice:FTBFS:build failure (test failed on riscv64)
On 2024-09-10 12:15, Yue Gui wrote: > Source: libreoffice > Version: 4:24.2.6-1 > Severity: serious > Tags: FTBFS, patch > User: debian-ri...@lists.debian.org > Usertags: riscv64 > X-Debbugs-Cc: debian-ri...@lists.debian.org Libreoffice has never been built in trixie/sid, so this is technically not a regression. Therefore downgrading the severity as important. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1080435: mesa: 24.2.x regression on riscv64: JIT session error, Failed to materialize symbols
control: reassign -1 src:llvm-toolchain-18
control: forcemerge 1080493 1080435
control: affects -1 src:gtk4
control: affects -1 src: lomiri-online-accounts
Hi,
On 2024-09-04 10:10, Eric Long wrote:
> Hi Simon,
>
> On Wed, 4 Sep 2024 00:36:05 +0100 Simon McVittie wrote:
> > Source: mesa
> > Version: 24.2.1-3
> > Severity: important
> > Justification: FTBFS in previously working package
> > User: debian-ri...@lists.debian.org
> > Usertags: riscv64
> > X-Debbugs-Cc: debian-ri...@lists.debian.org, g...@packages.debian.org,
> > llvm-toolchain...@packages.debian.org
> > Control: affects -1 + src:gtk4
> >
> > gtk4 previously passed most of its build-time tests on riscv64, but it's
> > now failing on the riscv64 porterbox ricci. I initially thought this was a
> > regression in 4.15.x (in experimental) but in fact I can reproduce the
> > failure in the previously-working version in unstable. I think this might
> > be related to the addition of ORC JIT support in the new Mesa.
> >
> > Steps to reproduce:
> > * set up a chroot with gtk4 build-dependencies
> > * build gtk4 (it will fail build-time tests)
> > * To run one of the affected tests:
> > schroot -c $chroot -r -- \
> > env GDK_DEBUG=opengl,vulkan,gl-debug GDK_BACKEND=x11 \
> > xvfb-run -a \
> > debian/build/deb/testsuite/gdk/memorytexture --tap -k
> >
> > Expected result: test passes
> >
> > Actual result:
> > > JIT session error: No HI20 PCREL relocation type be found for LO12 PCREL
> > > relocation type
> > > Failed to materialize symbols: { (fs681_variant0_14, {
> > > fs_variant_linear2, fs_variant_partial }) }
> > and the program exits with status 1.
>
> AFAIK we need to backport a commit [1] to LLVM to fix the issue. Moreover, a
> small memory leak related to ORCJIT can be fixed by another one [2].
>
> [1]:
> https://github.com/llvm/llvm-project/commit/78f39dc70c1feaea5130b90ea3fb7b3ddd62446b
> [2]:
> https://github.com/llvm/llvm-project/commit/3d67cf681a728e4cf0ab9947c0dd07539dda8b74
Thanks for the pointer. Bo Yu has submitted bug #1080493 with this patch
and provided me a build of llvm-toolchain-18 with these patches. I can
confirm that it fixes both gtk4 and lomiri-online-accounts.
In addition the switch to orcjit means that we do not have to ignore the
test label-shadows in gtk4 anymore.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
Bug#1076612: libquadmath0: wrongly assumes that the storage for __float128 arguments is aligned
control: notfixed -1 libquadmath0/14-20240429-1 control: fixed -1 gcc-14/14-20240429-1 Hi Paul, On 2024-08-31 07:46, Paul Gevers wrote: > Hi Aurelien, > > On Fri, 19 Jul 2024 18:35:04 +0200 Aurelien Jarno > wrote: > > Package: libquadmath0 > > Version: 14-20240330-1 > > Severity: serious > > Tags: upstream fixed-upstream > > Control: affects -1 evolver libc6 > > Control: fixed -1 libquadmath0/14-20240429-1 Control: block 1075938 by > > -1 > > ... > > > Closing the bug as it is fixed in unstable. The version tracking > > should do the rest for testing. > > The fixed version is earlier than the found version, which confused the BTS > version tracking. Did you mean it the other way around? No I don't mean the other way around, for me found in version 14-20240330-1 and solved in version 14-20240429-1 looks correct. The problem might be that I used the libquadmath0 package for the fixed version while the BTS seems to expect the source version. Sorry about that, trying to fix that with this mail. > In any case, the BTS > tells me now that this bug affects unstable and trixie which is clearly not > what you intended. Definitely not. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1079615: transition: glibc 2.40
On 2024-08-25 16:53, Sebastian Ramacher wrote: > Control: tags -1 confirmed > Control: forwarded -1 > https://release.debian.org/transitions/html/glibc-2.40.html > > On 2024-08-25 14:28:36 +0200, Aurelien Jarno wrote: > > Package: release.debian.org > > Severity: normal > > X-Debbugs-Cc: gl...@packages.debian.org > > Control: affects -1 + src:glibc > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Dear release team, > > > > I would like to get a transition slot for glibc 2.40. It has been > > available in experimental for one month already. It has been built > > successfully on all release architectures and most ports architectures. > > The experimental pseudo-excuses look good overall, and there is no known > > issue. > > Please go ahead. Thanks, I have just uploaded it. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1079615: transition: glibc 2.40
Package: release.debian.org Severity: normal X-Debbugs-Cc: gl...@packages.debian.org Control: affects -1 + src:glibc User: release.debian@packages.debian.org Usertags: transition Dear release team, I would like to get a transition slot for glibc 2.40. It has been available in experimental for one month already. It has been built successfully on all release architectures and most ports architectures. The experimental pseudo-excuses look good overall, and there is no known issue. As glibc is using symbol versioning, there is no soname change. That said a few packages are using libc internal symbols and have to be rebuilt for this transition. Here is the corresponding ben file: title = "glibc"; is_affected = .depends ~ /libc[0-9.]* \(<
Bug#1079501: linux-image-6.11-rc4-riscv64: Linux kernel config INPUT_AXP20X_PEK=m missing INPUT_MISC=y dependency
Hi, On 2024-08-24 09:05, Salvatore Bonaccorso wrote: > Hi, > > On Fri, Aug 23, 2024 at 06:43:50PM -0700, E Shattow wrote: > > Package: src:linux > > Version: 6.11~rc4-1~exp1 > > Severity: normal > > X-Debbugs-Cc: luc...@gmail.com > > > > Dear Maintainer, > > > > Dependency INPUT_MISC=y is missing from Kconfig options needed by > > CONFIG_INPUT_AXP20X_PEK=m in debian/config/config > > > > This makes built Linux kernels fail to have > > CONFIG_INPUT_AXP20X_PEK=m (and probably other options are washed out > > too). > > INPUT_MISC=y has been enabled through architecture specific configs, > but it is missing in riscv64 AFAICS. If that make sense there then > that's where it is missing. > > Aurelien, want to have a look at this? Setting INPUT_MISC=y enables the following options: CONFIG_INPUT_ATI_REMOTE2=m CONFIG_INPUT_KEYSPAN_REMOTE=m CONFIG_INPUT_POWERMATE=m CONFIG_INPUT_YEALINK=m CONFIG_INPUT_CM109=m CONFIG_INPUT_AXP20X_PEK=m CONFIG_INPUT_DA9063_ONKEY=m That looks reasonable overall. I'll submit a PR to enable it, but there are other options into discussion, and prefer to just group all of that in a single PR. Regards AUrelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1079443: Processed: Re: dracut-install ... -m =drivers/XXX is ignored
control: unmerge 1079443 control: retitle 1079443 fts_* calling non-LFS __readdir On 2024-08-24 21:40, Stepan Golosunov wrote: > On Sat, Aug 24, 2024 at 05:20:44PM +0200, Aurelien Jarno wrote: > > control: forcemerge 916276 1079443 > > > > Hi > > > > On 2024-08-24 10:27, Debian Bug Tracking System wrote: > > > Processing control commands: > > > > > > > reassign -1 glibc > > > Bug #1079443 [dracut-install] dracut-install ... -m =drivers/XXX is > > > ignored > > > Bug reassigned from package 'dracut-install' to 'glibc'. > > > No longer marked as found in versions dracut/103-1.1. > > > Ignoring request to alter fixed versions of bug #1079443 to the same > > > values previously set > > > > This bug keeps coming, but porters do not work on getting it fixed > > upstream. > > > > My position explained in the two other merged bugs still stands. Given > > it only affects the qemu-user case, I do not want to take any risk > > applying a patch that has not been reviewed and merged upstream. If we > > end up "missing" files in the non qemu-user case, it might have some > > security implications. > > I think #1079443 is different from the other two bugs: LFS versions of > the fts_* functions are calling non-LFS __readdir. This will also fail on > large inode numbers, even without qemu. Ok, then I got misled by the earlier messages in that bug that pointed the same upstream bugs. Unmerging them, and retitling because the existing title is also misleading. As you seems to have investigated seems more than me could you please take care of reporting the bug in the upstream bugzilla? A simple reproducer would be ideal. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1079443: Processed: Re: dracut-install ... -m =drivers/XXX is ignored
control: forcemerge 916276 1079443 Hi On 2024-08-24 10:27, Debian Bug Tracking System wrote: > Processing control commands: > > > reassign -1 glibc > Bug #1079443 [dracut-install] dracut-install ... -m =drivers/XXX is ignored > Bug reassigned from package 'dracut-install' to 'glibc'. > No longer marked as found in versions dracut/103-1.1. > Ignoring request to alter fixed versions of bug #1079443 to the same values > previously set This bug keeps coming, but porters do not work on getting it fixed upstream. My position explained in the two other merged bugs still stands. Given it only affects the qemu-user case, I do not want to take any risk applying a patch that has not been reviewed and merged upstream. If we end up "missing" files in the non qemu-user case, it might have some security implications. Therefore, 32-bit porters, please work on providing a patch to upstream and get it merged. I'll then backport it to the debian package. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1074338: Bug#1073508: Bug#1074338: src:libxml2: fails to migrate to testing for too long: unresolved RC issue
Hi, Sorry to be late to the party. On 2024-08-19 09:51, Emilio Pozuelo Monfort wrote: > On 17/08/2024 11:13, Paul Gevers wrote: > > Hi, > > > > [Disclaimer: I'm not the most experienced person on transitions in the > > team, so I'd like for Graham, Emilio and/or Sebastian to check if they > > agree with me.] > > > > Thanks for working on this. > > > > On 17-08-2024 05:58, Aron Xu wrote: > > > After some research, I prefer making a t64-like transition for libxml2 > > > for the following reasons: > > > > I'm a bit curious in how far you think this looks like a t64-like > > transition as apposed to a regular c-library transition. Is it because > > the libraries will not be co-installable, you don't bump SONAME and just > > rename the binary package name? Even with all the work that went into > > the t64 transition, we're starting to see hidden bugs [0] (although I > > think this can happen with any transition). > > > > > - Upstream is not prepared to bump the SONAME to something like > > > libxml3. Given the long history of this function library, determining > > > which APIs should be public and which should be private is > > > challenging. > > > > That's why earlier I proposed a Debian specific SONAME, "in between" 2 > > and 3. Upstream (I think) even suggested that [1]. > > > > > - The potential for breaking locally built software is minimal. > > > Although abi-compliance-checker raises many issues, most of them are > > > not used in the real world. > > > > Isn't the fact that we *caught* an issue in Debian the proof that it's > > not just academic? > > > > > - This approach is significantly easier and safer. > > > > I'm hesitant because we have well established procedures to handle ABI > > breakage with SONAME bumps and how to handle them in Debian. Can you > > elaborate on the easier and safer parts? Because I mostly see risks to > > deviate from established paths as the corner cases on them are less > > known. > > I feel like the proposed change by Aron is the best course of action. The > benefits are that we get everything rebuilt against the new package, > effectively avoiding any issues with the ABI breaks inside Debian. And by > maintaining the same SONAME as upstream, if a user installs a binary > provided by a 3rd-party, then it will just work (assuming it was built for > the newer releases or is not affected by the ABI breaks). The drawbacks are > that the old and new packages won't be co-installable due to the file > conflicts, and so the transition will have to happen in lockstep. It will It also means that at least gettext will need to get reboostrapped on all architectures. Indeed the new libxml2-dev won't be co-installable with debhelper, which is a build-dependency of gettext: - libxml2-dev will depend on libxml2n - debhelper will still depend (through debhelper) on libxml2 What are the plans with regard to that? Note that I haven't check further in the (build)-dependency tree. Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1050872: release.debian.org: mips64el apparently relies on buster (oldoldstable) LTS?
Hi,
On 2024-08-20 11:08, Simon McVittie wrote:
> On Wed, 30 Aug 2023 at 16:54:01 +0100, Simon McVittie wrote:
> > from the point of view of continued development of testing/unstable,
> > I would have hoped that packages in testing/unstable could safely
> > assume that they will run on at least the kernel from stable (or maybe
> > oldstable for a short time after a new stable release), following our
> > usual "skipping a release is unsupported" rule. Obviously if the buildds
> > are running on an oldoldstable kernel, any mips64el package that might
> > be used at compile-time or for build-time tests will be unable to make
> > that assumption.
>
> It's been about a year, so it seems like it's time to catch up on this.
>
> According to db.debian.org, we have these mips(64)el machines:
>
> - eberlin (porterbox, LS3A-RS780-1w (Quad Core Loongson 3A), Linux 4.19.249-2)
> - mipsel-manda-{04,05} (buildd, Quad Core Loongson 3A3000)
> - mipsel-osuosl-{01,02} (buildd, Rhino Labs UTM8)
> - mipsel-osuosl-{03,04,05} (buildd, Quad Core Loongson 3A3000)
>
> running these kernels and OSs (directly queried on the porterbox, taken
> from a semi-recent buildd log for the others):
>
> - eberlin:
> - 4.19.0-21-loongson-3 4.19.249-2 (Debian 10)
> - Debian 10 user-space
Correct.
> - mipsel-osuosl-{01,02}:
> - 4.19.0-21-octeon 4.19.249-2 (Debian 10)
> - Debian 11 user-space (guessed from sbuild version)
Correct.
> - mipsel-osuosl-{03,04}:
> - 6.1.0-23-loongson-3 6.1.99-1 (Debian 12)
> - presumably Debian 12 user-space (guessed from sbuild version)
Correct.
> - mipsel-osuosl-05:
> - 6.1.0-21-loongson-3 6.1.90-1 (Debian 12)
> - presumably Debian 12 user-space
The kernel version is wrong, it runs an up to date bookworm kernel.
> - mipsel-manda-{04,05}:
> - probably >= 5.10.0-22-loongson-3 (Debian 11)
> - probably >= Debian 11 user-space
>
> I was unable to find a recent build on mipsel-manda-{04,05} on
> buildd.debian.org: are they perhaps reserved for -security or something?
> During the most recent builds with public logs that I could find there
> (1-2 years ago), they appear to have been running 5.10.0-22-loongson-3
> (Debian 11 kernel) with what appears to be Debian 11 user-space, which
> presumably means that these two buildds do not suffer from the kernel
> issue that prevented mipsel-osuosl-{01,02} from being upgraded beyond a
> buster kernel, so hopefully they are running Debian 12 by now.
mipsel-manda-{04,05} are powered down for many months due to fan issues.
Unfortunately we have not been able to get someone looking at them. In
any case they should be upgradable to a Bookworm system without problem.
> However, this means that, 1 year into Debian 12's lifetime as stable, two
> of our official buildds for a release architecture are still running a
> Debian 10 kernel, with no security fixes beyond 2 years ago. Meanwhile,
> the porterbox that is an ordinary Debian developer's only opportunity to
> debug problems on this architecture is running the same outdated kernel,
> and also Debian 10 user-space. mips64el is not supported by Debian LTS or
> ELTS, so there is no channel that I'm aware of from which these machines
> could receive security fixes, even outside Debian itself.
>
> This worries me, and I think it should be a factor in decisions made by
> the release, security and DSA teams about whether mips64el is a candidate
> to be a release architecture in trixie.
>
> If the mips64el porting team and their hardware sponsors would like it
> to be treated as a potential release architecture, then I think it would
> be a good idea to prioritize either providing a newer kernel that can
> run successfully on the hardware that is used for Debian's official
> buildds, or replacing mipsel-osuosl-{01,02} with hardware that can run
> newer kernels successfully.
I don't think hardware sponsors are to blame here. They delivered 2
machines to replace the ones that can't upgraded. That was end of
October 2023, unfortunately we have not been able to get them racked.
All that said I am not sure how to make things progress.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
signature.asc
Description: PGP signature
Bug#1078762: bullseye-pu: package usb.ids/2024.07.04-0+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye X-Debbugs-Cc: usb@packages.debian.org Control: affects -1 + src:usb.ids User: release.debian@packages.debian.org Usertags: pu [ Reason ] This new upstream version of the USB ID database adds a few USB devices. [ Impact ] New USB devices will not be displayed with a human readable name for package using this database. [ Tests ] There is no test associated with this database. This package only contains data, no code. [ Risks ] Risks are very low, such update are routinely done in stable. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] I would like to do an update of the usb.ids package to add/update around 100+ USB devices to the usb.ids database. Those changes are already in testing/sid. [ Other info ] Given the changes are minimal, I have already uploaded the package to the archive. Thanks for considering. diff -Nru usb.ids-2024.01.20/debian/changelog usb.ids-2024.07.04/debian/changelog --- usb.ids-2024.01.20/debian/changelog 2024-01-30 07:07:08.0 +0100 +++ usb.ids-2024.07.04/debian/changelog 2024-08-15 17:40:44.0 +0200 @@ -1,3 +1,9 @@ +usb.ids (2024.07.04-0+deb11u1) bullseye; urgency=medium + + * New upstream version. + + -- Aurelien Jarno Thu, 15 Aug 2024 17:40:44 +0200 + usb.ids (2024.01.20-0+deb11u1) bullseye; urgency=medium * New upstream version. diff -Nru usb.ids-2024.01.20/usb.ids usb.ids-2024.07.04/usb.ids --- usb.ids-2024.01.20/usb.ids 2024-01-20 21:34:02.0 +0100 +++ usb.ids-2024.07.04/usb.ids 2024-07-04 22:34:02.0 +0200 @@ -9,8 +9,8 @@ # The latest version can be obtained from # http://www.linux-usb.org/usb.ids # -# Version: 2024.01.20 -# Date:2024-01-20 20:34:02 +# Version: 2024.07.04 +# Date:2024-07-04 20:34:02 # # Vendors, devices and interfaces. Please keep sorted. @@ -29,6 +29,8 @@ 0004 Nebraska Furniture Mart 0011 Unknown 7788 counterfeit flash drive +001f Walmart + 0b21 AB13X Headset Adapter 0040 Anyware Corporation 073d Mini Multimedia 2.4GHz Wireless Keyboard with Touch Pad 0042 DMT @@ -207,6 +209,7 @@ 0012 DeskJet 1125C Printer Port 0024 KU-0316 Keyboard 002a LaserJet P1102 + 0036 CCID Smartcard Keyboard KUS0133 0053 DeskJet 2620 All-in-One Printer 0101 ScanJet 4100c 0102 PhotoSmart S20 @@ -2397,8 +2400,10 @@ 02e3 Xbox One Elite Controller 02e6 Xbox Wireless Adapter for Windows 02ea Xbox One Controller + 02f3 Xbox One Chatpad 02fd Xbox One S Controller [Bluetooth] 02fe Xbox Wireless Adapter for Windows + 0306 Surface Pro 7 SD Card Reader 0400 Windows Powered Pocket PC 2002 0401 Windows Powered Pocket PC 2002 0402 Windows Powered Pocket PC 2002 @@ -4988,7 +4993,7 @@ 0a28 INDI AV-IN Device 1301 Network Controller 1302 i3 Gateway - 1303 3 Micro Module + 1303 i3 Micro Module 1304 i3 Module 1305 i3 Multi Sensing Module 04c1 U.S. Robotics (3Com) @@ -5047,6 +5052,7 @@ 072d Revio KD410Z 04ca Lite-On Technology Corp. 0020 USB Keyboard + 003a Multimedia Keyboard 004b Keyboard 004f SK-9020 keyboard 008a Acer Wired Mouse Model SM-9023 @@ -5269,6 +5275,7 @@ 1400 PS/2 keyboard + mouse controller 1503 Keyboard 1603 Keyboard + 1605 Keyboard 1702 Keyboard LKS02 1818 Keyboard [Diatec Filco Majestouch 2] 2011 Keyboard [Diatec Filco Majestouch 1] @@ -5862,6 +5869,7 @@ b681 ThinkPad T490 Webcam b71a Integrated IR Camera b76b SunplusIT Inc [HP HD Camera] + b7b4 Integrated Camera (1920x1080) 04f3 Elan Microelectronics Corp. 000a Touchscreen 0103 ActiveJet K-2024 Multimedia Keyboard @@ -6426,6 +6434,7 @@ 2060 PT-E550W P-touch Label Printer 2061 PT-P700 P-touch Label Printer 2064 PT-P700 P-touch Label Printer RemovableDisk + 2065 PT-P750W P-Touch Label Writer 2074 PT-D600 P-touch Label Printer 209b QL-800 Label Printer 209c QL-810W Label Printer @@ -6485,6 +6494,8 @@ 0003 Smart Card Reader II 04fe PFU, Ltd 0006 Happy Hacking Keyboard Lite2 + 0020 HHKB-Classic + 0021 Happy Hacking Keyboard Professional HYBRID Type-S 04ff E-CMOS Corp. 0500 Siam United Hi-Tech 0001 DART Keyboard Mouse @@ -6552,6 +6563,7 @@ 0081 F8T001v2 Bluetooth 0083 Bluetooth Device 0084 F8T003v2 Bluetooth + 008a 6-in-1 Multiport Adapter 0102 Flip KVM 0103 F5U103 Serial Adapter [etek] 0106 VideoBus II Adapter, Video @@ -7029,6 +7041,7
Bug#1078761: bookworm-pu: package usb.ids/2024.07.04-0+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm X-Debbugs-Cc: usb@packages.debian.org Control: affects -1 + src:usb.ids User: release.debian@packages.debian.org Usertags: pu [ Reason ] This new upstream version of the USB ID database adds a few USB devices. [ Impact ] New USB devices will not be displayed with a human readable name for package using this database. [ Tests ] There is no test associated with this database. This package only contains data, no code. [ Risks ] Risks are very low, such update are routinely done in stable. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] I would like to do an update of the usb.ids package to add/update around 100+ USB devices to the usb.ids database. Those changes are already in testing/sid. [ Other info ] Given the changes are minimal, I have already uploaded the package to the archive. Thanks for considering. diff -Nru usb.ids-2024.01.20/debian/changelog usb.ids-2024.07.04/debian/changelog --- usb.ids-2024.01.20/debian/changelog 2024-01-30 07:07:50.0 +0100 +++ usb.ids-2024.07.04/debian/changelog 2024-08-15 16:39:01.0 +0200 @@ -1,3 +1,9 @@ +usb.ids (2024.07.04-0+deb12u1) bookworm; urgency=medium + + * New upstream version. + + -- Aurelien Jarno Thu, 15 Aug 2024 16:39:01 +0200 + usb.ids (2024.01.20-0+deb12u1) bookworm; urgency=medium * New upstream version. diff -Nru usb.ids-2024.01.20/usb.ids usb.ids-2024.07.04/usb.ids --- usb.ids-2024.01.20/usb.ids 2024-01-20 21:34:02.0 +0100 +++ usb.ids-2024.07.04/usb.ids 2024-07-04 22:34:02.0 +0200 @@ -9,8 +9,8 @@ # The latest version can be obtained from # http://www.linux-usb.org/usb.ids # -# Version: 2024.01.20 -# Date:2024-01-20 20:34:02 +# Version: 2024.07.04 +# Date:2024-07-04 20:34:02 # # Vendors, devices and interfaces. Please keep sorted. @@ -29,6 +29,8 @@ 0004 Nebraska Furniture Mart 0011 Unknown 7788 counterfeit flash drive +001f Walmart + 0b21 AB13X Headset Adapter 0040 Anyware Corporation 073d Mini Multimedia 2.4GHz Wireless Keyboard with Touch Pad 0042 DMT @@ -207,6 +209,7 @@ 0012 DeskJet 1125C Printer Port 0024 KU-0316 Keyboard 002a LaserJet P1102 + 0036 CCID Smartcard Keyboard KUS0133 0053 DeskJet 2620 All-in-One Printer 0101 ScanJet 4100c 0102 PhotoSmart S20 @@ -2397,8 +2400,10 @@ 02e3 Xbox One Elite Controller 02e6 Xbox Wireless Adapter for Windows 02ea Xbox One Controller + 02f3 Xbox One Chatpad 02fd Xbox One S Controller [Bluetooth] 02fe Xbox Wireless Adapter for Windows + 0306 Surface Pro 7 SD Card Reader 0400 Windows Powered Pocket PC 2002 0401 Windows Powered Pocket PC 2002 0402 Windows Powered Pocket PC 2002 @@ -4988,7 +4993,7 @@ 0a28 INDI AV-IN Device 1301 Network Controller 1302 i3 Gateway - 1303 3 Micro Module + 1303 i3 Micro Module 1304 i3 Module 1305 i3 Multi Sensing Module 04c1 U.S. Robotics (3Com) @@ -5047,6 +5052,7 @@ 072d Revio KD410Z 04ca Lite-On Technology Corp. 0020 USB Keyboard + 003a Multimedia Keyboard 004b Keyboard 004f SK-9020 keyboard 008a Acer Wired Mouse Model SM-9023 @@ -5269,6 +5275,7 @@ 1400 PS/2 keyboard + mouse controller 1503 Keyboard 1603 Keyboard + 1605 Keyboard 1702 Keyboard LKS02 1818 Keyboard [Diatec Filco Majestouch 2] 2011 Keyboard [Diatec Filco Majestouch 1] @@ -5862,6 +5869,7 @@ b681 ThinkPad T490 Webcam b71a Integrated IR Camera b76b SunplusIT Inc [HP HD Camera] + b7b4 Integrated Camera (1920x1080) 04f3 Elan Microelectronics Corp. 000a Touchscreen 0103 ActiveJet K-2024 Multimedia Keyboard @@ -6426,6 +6434,7 @@ 2060 PT-E550W P-touch Label Printer 2061 PT-P700 P-touch Label Printer 2064 PT-P700 P-touch Label Printer RemovableDisk + 2065 PT-P750W P-Touch Label Writer 2074 PT-D600 P-touch Label Printer 209b QL-800 Label Printer 209c QL-810W Label Printer @@ -6485,6 +6494,8 @@ 0003 Smart Card Reader II 04fe PFU, Ltd 0006 Happy Hacking Keyboard Lite2 + 0020 HHKB-Classic + 0021 Happy Hacking Keyboard Professional HYBRID Type-S 04ff E-CMOS Corp. 0500 Siam United Hi-Tech 0001 DART Keyboard Mouse @@ -6552,6 +6563,7 @@ 0081 F8T001v2 Bluetooth 0083 Bluetooth Device 0084 F8T003v2 Bluetooth + 008a 6-in-1 Multiport Adapter 0102 Flip KVM 0103 F5U103 Serial Adapter [etek] 0106 VideoBus II Adapter, Video @@ -7029,6 +7041,7
Bug#1076832: bullseye-pu: package glibc/2.31-13+deb11u11
On 2024-08-14 20:42, Adam D. Barratt wrote: > Control; tags -1 + confirmed > > On Tue, 2024-07-23 at 23:23 +0200, Aurelien Jarno wrote: > > The upstream glibc stable 2.31 branch got a fixes since the last > > oldstable updates. That said as this branch is getting old, the > > number > > of fixes is decreasing. > > Please go ahead. > Thanks, I have just uploaded it. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1076831: bookworm-pu: package glibc/2.36-9+deb12u8
On 2024-08-14 21:35, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Tue, 2024-07-23 at 22:50 +0200, Aurelien Jarno wrote: > > [ Reason ] > > The upstream glibc stable branch got a fixes since the last stable > > updates. This hasn't been missed in the last point release, so the > > number of fixes is slightly higher than usual. > > Please go ahead. > Thanks, I have just uploaded it. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1069959: libcbor FTBFS on hppa and mips to due different NaN encoding
Hi, On 2024-05-03 22:26, Vincent Bernat wrote: > Hello Helge, > > Couldn't the patch be pushed upstream? And maybe there should be an else > branch with the encoding of the other NaN? > I am not sure the patch is upstreamable. It basically disables the test on mips and hppa, which is fine for Debian given it is not a regression compared to the previous version where the testsuite was fully disabled. But for upstream, it just hides the real bug. On those architectures, the NaN encoding is indeed different, but the resulted encoded data should be the identical, as defined in the RFC. Therefore I believe the real fix is to convert NaNs (and probably also infinities) during the encoding process. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1078245: cfengine3: FTBFS: 1 of 61 tests failed
Hi, On 2024-08-08 23:43, Chris Hofstaedtler wrote: > Source: cfengine3 > Severity: serious > Tags: ftbfs sid trixie > > Hi, > > cfengine3 currently fails to build from source on armel, armhf, > riscv64 but has successfully built there before. > > https://buildd.debian.org/status/fetch.php?pkg=cfengine3&arch=armhf&ver=3.24.0-1&stamp=1722892279&raw=0 > https://buildd.debian.org/status/fetch.php?pkg=cfengine3&arch=armel&ver=3.24.0-1&stamp=1722892342&raw=0 > https://buildd.debian.org/status/fetch.php?pkg=cfengine3&arch=riscv64&ver=3.24.0-1&stamp=1722894244&raw=0 The riscv64 FTBFS is actually a different issue, reported in #1070850. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1070850: fixed in cfengine3 3.21.4-1.2
control: reopen -1 control: found -1 cfengine3/3.24.0-1 control: severity -1 serious Hi, On 2024-05-21 00:34, Debian FTP Masters wrote: > Format: 1.8 > Date: Tue, 21 May 2024 02:16:43 +0200 > Source: cfengine3 > Architecture: source > Version: 3.21.4-1.2 > Distribution: unstable > Urgency: medium > Maintainer: CFEngine Team > Changed-By: Andreas Beckmann > Closes: 1060533 1070850 > Changes: > cfengine3 (3.21.4-1.2) unstable; urgency=medium > . >* Non-maintainer upload. >* Switch B-D to systemd-dev. (Closes: #1060533) >* Switch B-D to pkgconf. >* Add B-D: passwd. (Closes: #1070850) Thanks for fixing that. However the dependency got dropped in version 3.24.0-1, reintroducing the FTBFS. I am therefore reopening the bug. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1078254: ksh93u+m_1.0.8-1.1_all-buildd.changes REJECTED
Source: ksh93u+m Version: 1.0.8-1.1 Severity: serious X-Debbugs-Cc: Chris Hofstaedtler On 2024-08-08 22:50, Debian FTP Masters wrote: > > > Version check failed: > Your upload included the binary package ksh, version 20240113, for all, > however testing already has version 20240113. > Uploads to unstable must have a higher version than present in testing. > > Mapping sid to unstable. > > === > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. > -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1078065: r-bioc-dirichletmultinomial_1.46.0-1~0exp1_ppc64el-buildd.changes REJECTED
Source: r-bioc-dirichletmultinomial Version: 1.46.0-1~0exp1 Severity: serious A binNMU got scheduled on version 1.46.0-1~0exp, leading to version 1.46.0-1~0exp+b1 for the binary packages. This version is higher than 1.46.0-1~0exp1, hence the dak rejection. On 2024-08-06 12:36, Debian FTP Masters wrote: > > > Version check failed: > Your upload included the binary package r-bioc-dirichletmultinomial, version > 1.46.0-1~0exp1, for ppc64el, > however experimental already has version 1.46.0-1~0exp+b1. > Uploads to experimental must have a higher version than present in > experimental. > > > > === > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. > -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1077185: msc-generator: uses too much buildd resources on !amd64 !all
Hi, On 2024-07-29 10:40, Philipp Kern wrote: > Hi, > > On 26.07.24 15:05, Aurelien Jarno wrote: > > Starting with version 8.6.1-1, msc-generator takes a lot of time to > > build, except for arch:all and amd64 architectures. > > If I read the log correctly, it runs a ton of tests with 30m timeouts of > which a lot fail. And then there's a summary in the build log and the build > succeeds regardless. > > Looking at the s390x build it just sits there idle for 30m - the commands > all have no CPU time. > > "LOFFICE=:" according to /environ and then it turns out the test script is > just calling : in a loop, thus it makes sense that it just keeps sitting in > the shell: Good catch. It appears that libreoffice is only a build-dependency on amd64, so that matches the behaviour seen on the buildds in terms of build time. Unfortunately libreoffice is not available on all architectures, so it is not just about adding the build-dependency everywhere. Regads Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1077336: jpeg-xl: FTBFS on riscv64: ninja: build stopped: interrupted by user.
Source: jpeg-xl Version: 0.10.3-4 Severity: serious Tags: patch ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: debian-ri...@lists.debian.org User: debian-ri...@lists.debian.org Usertags: riscv64 Dear maintainer, jpeg-xl fails to build on riscv64 due to a timeout issue in the testsuite: |debian/rules override_dh_auto_test-arch | make[1]: Entering directory '/<>' | # armel requires 7h to run complete testsuite: | timeout 7h dh_auto_test -- | cd obj-riscv64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 ninja test | [0/1] Running tests... | Test project /<>/obj-riscv64-linux-gnu ... | 5955/7667 Test #5955: DecodeAllEncodingsVariantsTestInstantiation/DecodeAllEncodingsVariantsTest.SetPreferredColorProfileTest/From_RGB_DCI_DCI_Per_PeQ_without_icc_dst_without_cms # GetParam() = (ColorEncoding/RGB_DCI_DCI_Per_PeQ, false, false) . Passed1.93 sec | Start 5956: DecodeAllEncodingsVariantsTestInstantiation/DecodeAllEncodingsVariantsTest.SetPreferredColorProfileTest/From_RGB_DCI_DCI_Per_PeQ_without_icc_dst_with_cms # GetParam() = (ColorEncoding/RGB_DCI_DCI_Per_PeQ, false, true) | SCALAR(0x2af9d0e210)ninja: build stopped: interrupted by user. | make[1]: *** [debian/rules:104: override_dh_auto_test-arch] Error 124 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:61: binary-arch] Error 2 | dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 It appears that this new version added more tests, which overall takes longer to execute. Increasing the timeout from 7h to 10h is enough to fix the FTBFS: --- jpeg-xl-0.10.3/debian/rules +++ jpeg-xl-0.10.3/debian/rules @@ -100,8 +100,8 @@ override_dh_auto_test-indep: override_dh_auto_test-arch: - # armel requires 7h to run complete testsuite: - timeout 7h dh_auto_test -- + # riscv64 requires 10h to run complete testsuite: + timeout 10h dh_auto_test -- override_dh_installman-arch: tools_manpages devtools_manpages jpegli_tools_manpages dh_installman Regards Aurelien
Bug#1074368: marked as pending in glibc
Hi Helmut, On 2024-07-27 10:46, Helmut Grohne wrote: > Hi Aurelien, > > On Tue, Jul 02, 2024 at 09:36:36PM +, Aurelien Jarno wrote: > > > > debian/control.in/libc: add breaks against base-files version not providing > > /usr-merge aliasing symlinks. Closes: #1074368. > > > > I see you resolved the guestfs issue by adding Breaks. I don't quite > like this outcome and would like to discuss alternative solutions. When > I created these patches, I carefully ensured that the order of upgrades > (base-files vs libc6) would work in both orderings. In adding Breaks you > restrict the ordering and I am already seeing how this makes upgrades > from bookworm to trixie more difficult (due to the imposed ordering). > > My change makes libc6 require something else to provide the aliasing > symbolic links and the added Breaks is one way to ensure their presence. > I argue that the links are already ensured by having essential > init-system-helpers depend on usr-is-merged. I am fine reverting that change on the glibc side if you believe it's better. But the submitter encountered a real issue... > The failure in libguestfs-tools is a bug there in my opinion. It uses > the host system to construct a VM environment and fails to account for > the aliasing links created by usrmerge or debootstrap not recorded in a > packaging database. This is unfortunate, but not a bug in libc6 as it > correctly explains its requirements (via an implicit dependency on > essential packages). Do you mean we could reassign the bug to libguestfs-tools? And get solve it there instead? > I argue that the risk of running a partially upgraded system and running > libguestfs tests is fairly low at this time as both packages have > migrated and trixie-based images typically have been updated (even in a > monthly cadence) to include all relevant changes. Hence, I argue that at > this time the cost of including this Breaks outweighs its benefits. > > Do you agree with this reasoning? I am also fine to just ignore the bug, but I don't want it to come back at a later stage. Should we maybe get an agreement with the release team that it is not considered as a bug? Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1077186: FTBFS: Could not find a package configuration file provided by "lxqt-build-tools"
Source: lxqt-session Version: 1.4.0-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear maintainer, lxqt-session fails to build from source. From my build log on amd64: | -- The C compiler identification is GNU 14.1.0 | -- The CXX compiler identification is GNU 14.1.0 | -- Detecting C compiler ABI info | -- Detecting C compiler ABI info - done | -- Check for working C compiler: /usr/bin/cc - skipped | -- Detecting C compile features | -- Detecting C compile features - done | -- Detecting CXX compiler ABI info | -- Detecting CXX compiler ABI info - done | -- Check for working CXX compiler: /usr/bin/c++ - skipped | -- Detecting CXX compile features | -- Detecting CXX compile features - done | -- Found X11: /usr/include | -- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so | -- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so - found | -- Looking for gethostbyname | -- Looking for gethostbyname - found | -- Looking for connect | -- Looking for connect - found | -- Looking for remove | -- Looking for remove - found | -- Looking for shmat | -- Looking for shmat - found | CMake Error at /usr/share/cmake-3.30/Modules/CMakeFindDependencyMacro.cmake:76 (find_package): | By not providing "Findlxqt-build-tools.cmake" in CMAKE_MODULE_PATH this | project has asked CMake to find a package configuration file provided by | "lxqt-build-tools", but CMake did not find one. | | Could not find a package configuration file provided by "lxqt-build-tools" | (requested version 0.13.0) with any of the following names: | | lxqt-build-toolsConfig.cmake | lxqt-build-tools-config.cmake | | Add the installation prefix of "lxqt-build-tools" to CMAKE_PREFIX_PATH or | set "lxqt-build-tools_DIR" to a directory containing one of the above | files. If "lxqt-build-tools" provides a separate development package or | SDK, be sure it has been installed. | Call Stack (most recent call first): | /usr/share/cmake/lxqt/lxqt-config.cmake:40 (find_dependency) | CMakeLists.txt:32 (find_package) | | | -- Configuring incomplete, errors occurred! Full build logs are also available on riscv64 or s390x: https://buildd.debian.org/status/fetch.php?pkg=lxqt-session&arch=riscv64&ver=1.4.0-1&stamp=1721813443&raw=0 https://buildd.debian.org/status/fetch.php?pkg=lxqt-session&arch=s390x&ver=1.4.0-1&stamp=1721952593&raw=0 Or on reproducible builds: https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/lxqt-session_1.4.0-1.rbuild.log.gz Regards Aurelien
Bug#1077185: msc-generator: uses too much buildd resources on !amd64 !all
Source: msc-generator Version: 8.6.1-1 Severity: important X-Debbugs-Cc: debian-wb-t...@lists.debian.org Dear maintainer, Starting with version 8.6.1-1, msc-generator takes a lot of time to build, except for arch:all and amd64 architectures. This happens even on fast hardware, for instance it took 51h to build on i386 (6 cores of an AMD EPYC 7702P processor), or 39h on ppc64el (8 cores of a POWER9 CPU). In both cases it is the longest build time for all packages in the archive for these architecture. And it is still building on some other architectures after almost 3 days... By comparison the package only took 23 minutes to build on a somewhat old Xeon E5-2699 v3 processor. Therefore something looks very fishy. Could you please investigate? Regards Aurelien
Bug#684134: Package 'locales' resets pre-set debconf variable 'default_environment_locale' on install
Hi, On 2024-07-25 00:34, Lee Garrett wrote: > So when /etc/locale.gen exists, this file is read, and then the settings in > the debconf database overwritten by those value. So once debconf is > installed, there's no programmatic way via debconf to change the locale. A > workaround is template the files /etc/locale.gen and /etc/locale.conf and > then run dpkg-reconfigure locales. Yes, this works exactly as expected. debconf can be used to preconfigure the package before it gets installed. But *debconf is not a registry*. The way to change the configuration is by editing the files. This is very clear in the debconf manual: "You can also use debconf in other, standalone programs. The issue to watch out for here is that debconf is not intended to be, and must not be used as a registry. This is unix after all, and programs are configured by files in /etc, not by some nebulous debconf database (that is only a cache anyway and might get blown away). So think long and hard before using debconf in a standalone program." https://manpages.debian.org/unstable/debconf-doc/debconf-devel.7.en.html > This however seems counterintuitive to me, as practically all other packages > using debconf have the debconf database as authoritative data from which the > config is written (e.g. apt-cacher-ng, ca-certificates, console-setup, > iproute2, grub-efi-amd64, grub-pc, postfix, tzdata, wireshark-common, to > name a few). Then those packages are buggy, please report bugs. And I really doubt about the behaviour you describe, for at least tzdata. > Neither /etc/locale.gen, nor /etc/locale.conf are marked as conffiles, so > they shouldn't edited by users, and neither be preserved, nor authoritative > on the matter. As such, I'm raising the bug severity. They are not conffiles, because there are not mandatory and thus not shipped by the package. But it's something we can change. In any case, as you raised the bug to serious, could you please tell me which section of the Debian policy is violated? > I propose to remove the shown code lines from locales.config. This would > make any debconf selections authoritative again. As said above this is wrong. > A compromise would be to add another debconf option that decides on which > side is authoritative (either config file, or debconf), but IMHO that adds > complexity without much benefit. I agree with you it should not be done. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1076974: samba_4.20.2+dfsg-8_riscv64-buildd.changes REJECTED
Source: samba Version: 4.20.2+dfsg-8 Severity: serious On 2024-07-24 18:50, Debian FTP Masters wrote: > > > Version check failed: > Your upload included the binary package ldb-tools, version 2:2.9.1+samba, for > riscv64, > however testing already has version 2:2.9.1+samba4.20.2+dfsg-7. > Uploads to unstable must have a higher version than present in testing. > > Mapping sid to unstable. > > === > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. > signature.asc Description: PGP signature
Bug#1076832: bullseye-pu: package glibc/2.31-13+deb11u11
Package: release.debian.org Severity: normal Tags: bullseye X-Debbugs-Cc: gl...@packages.debian.org Control: affects -1 + src:glibc User: release.debian@packages.debian.org Usertags: pu [ Reason ] The upstream glibc stable 2.31 branch got a fixes since the last oldstable updates. That said as this branch is getting old, the number of fixes is decreasing. [ Impact ] In case the update isn't approved, systems will be left with a few issues, and the differences with upstream will increase. [ Tests ] The upstream fixes come with additional tests, which represent a significant part of the diff. [ Risks ] The changes to do not affect critical part of the library, and come with additional tests. The changes are already in testing/sid and in other distributions. [ Changes ] All the changes come from the upstream 2.31 stable branch, and are summarized in the Debian changelog: * debian/patches/git-updates.diff: update from upstream stable branch: - debian/patches/any/local-CVE-2024-2961-iso-2022-cn-ext.patch: upstreamed. - debian/patches/any/local-CVE-2024-33599-nscd.patch: upstreamed. - debian/patches/any/local-CVE-2024-33600-nscd.patch: upstreamed. - debian/patches/any/local-CVE-2024-33601-33602-nscd.diff: upstreamed. - Fixes ffsll() performance issue depending on code alignment. - Performance improvements for memcpy() on arm64. - Fixes y2038 regression in nscd following CVE-2024-33601 and CVE-2024-33602 fix. - Fix compatibility with make 4.4. - Fixes build with --enable-hardcoded-path-in-tests with newer linkers. A few changes are not relevant for Debian Bullseye as they fix issues with different toolchain version or with different configure options. That said it is easier to pull the whole changes from upstream. Among the important changes, there is a y2038 regression fix in nscd following the latest security update, and performance issues on arm64 and amd64. [ Other info ] None commit 4227474b675fa9e610d11da7ae0c4cb654d104d2 Author: Aurelien Jarno Date: Tue Jul 23 22:59:08 2024 +0200 debian/patches/git-updates.diff: update from upstream stable branch: * debian/patches/git-updates.diff: update from upstream stable branch: - debian/patches/any/local-CVE-2024-2961-iso-2022-cn-ext.patch: upstreamed. - debian/patches/any/local-CVE-2024-33599-nscd.patch: upstreamed. - debian/patches/any/local-CVE-2024-33600-nscd.patch: upstreamed. - debian/patches/any/local-CVE-2024-33601-33602-nscd.diff: upstreamed. - Fixes ffsll() performance issue depending on code alignment. - Performance improvements for memcpy() on arm64. - Fixes y2038 regression in nscd following CVE-2024-33601 and CVE-2024-33602 fix. - Fix compatibility with make 4.4. - Fixes build with --enable-hardcoded-path-in-tests with newer linkers. diff --git a/debian/changelog b/debian/changelog index 45150729..e973aeb2 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,19 @@ +glibc (2.31-13+deb11u11) UNRELEASED; urgency=medium + + * debian/patches/git-updates.diff: update from upstream stable branch: +- debian/patches/any/local-CVE-2024-2961-iso-2022-cn-ext.patch: upstreamed. +- debian/patches/any/local-CVE-2024-33599-nscd.patch: upstreamed. +- debian/patches/any/local-CVE-2024-33600-nscd.patch: upstreamed. +- debian/patches/any/local-CVE-2024-33601-33602-nscd.diff: upstreamed. +- Fixes ffsll() performance issue depending on code alignment. +- Performance improvements for memcpy() on arm64. +- Fixes y2038 regression in nscd following CVE-2024-33601 and + CVE-2024-33602 fix. +- Fix compatibility with make 4.4. +- Fixes build with --enable-hardcoded-path-in-tests with newer linkers. + + -- Aurelien Jarno Tue, 23 Jul 2024 22:58:29 +0200 + glibc (2.31-13+deb11u10) bullseye-security; urgency=medium * debian/patches/local-CVE-2024-33599-nscd.patch: Fix a stack-based buffer diff --git a/debian/patches/any/local-CVE-2024-2961-iso-2022-cn-ext.patch b/debian/patches/any/local-CVE-2024-2961-iso-2022-cn-ext.patch deleted file mode 100644 index 88c45cc8.. --- a/debian/patches/any/local-CVE-2024-2961-iso-2022-cn-ext.patch +++ /dev/null @@ -1,207 +0,0 @@ -commit 3703c32a8d304c1ee12126134ce69be965f38000 -Author: Charles Fol -Date: Thu Mar 28 12:25:38 2024 -0300 - -iconv: ISO-2022-CN-EXT: fix out-of-bound writes when writing escape sequence (CVE-2024-2961) - -ISO-2022-CN-EXT uses escape sequences to indicate character set changes -(as specified by RFC 1922). While the SOdesignation has the expected -bounds checks, neither SS2designation nor SS3designation have its; -allowing a write overflow of 1, 2, or 3 bytes with fixed values: -'$+I', '$+J', '$+K', '$+L', '$+M', or '$*H'. - -Checked on aarch64-linux-gnu. - -Co-authored-by: Adhemerval Zanella -
Bug#1076820: onboard: FTBFS on riscv64: FAILED Onboard/test/test_migration.py::TestMigration::test_migrate_user_model
Source: onboard Version: 1.4.1-8 Severity: serious Tags: patch ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: debian-ri...@lists.debian.org User: debian-ri...@lists.debian.org Usertags: riscv64 Dear maintainer, onboard fails to build with a testsuite error on riscv64 since it has been enabled in version 1.4.1-6: | I: pybuild base:311: cd /<>/.pybuild/cpython3_3.12_onboard/build; python3.12 -m pytest | task-0: = test session starts == | task-0: platform linux -- Python 3.12.4, pytest-8.2.2, pluggy-1.5.0 | task-0: rootdir: /<> | task-0: collected 7 items | task-0: | task-0: Onboard/test/test_LayoutLoaderSVG.py [ 57%] | task-0: Onboard/test/test_migration.py F. [ 85%] | task-0: Onboard/test/test_translations.py . [100%] | task-0: | task-0: === FAILURES === | task-0: TestMigration.test_migrate_user_model _ | task-0: | task-0: self = | task-0: | task-0: def test_migrate_user_model(self): | task-0: tests = [ | task-0: [ | task-0: # old user.lm becomes new model of system language | task-0: [ | task-0: ['user.lm', 1], | task-0: ], | task-0: [ | task-0: ['en_US.lm', 1], | task-0: ] | task-0: ], | task-0: [ | task-0: # a backup model is renamed too | task-0: [ | task-0: ['user.lm', 1], | task-0: ['user.lm.bak', 2], | task-0: ], | task-0: [ | task-0: ['en_US.lm', 1], | task-0: ['en_US.lm.bak', 2], | task-0: ] | task-0: ], | task-0: [ | task-0: # a backup alone is ignored | task-0: [ | task-0: ['user.lm.bak', 2], | task-0: ], | task-0: [ | task-0: ['user.lm.bak', 2], | task-0: ] | task-0: ], | task-0: [ | task-0: # must not overwrite existing files | task-0: [ | task-0: ['user.lm', 1], | task-0: ['user.lm.bak', 2], | task-0: ['en_US.lm', 3], | task-0: ['en_US.lm.bak', 4], | task-0: ], | task-0: [ | task-0: ['en_US.lm', 3], | task-0: ['en_US.lm.bak', 4], | task-0: ['user.lm', 1], | task-0: ['user.lm.bak', 2], | task-0: ] | task-0: ], | task-0: [ | task-0: # must not overwrite existing backup model | task-0: [ | task-0: ['user.lm', 1], | task-0: ['user.lm.bak', 2], | task-0: ['en_US.lm.bak', 4], | task-0: ], | task-0: [ | task-0: ['en_US.lm', 1], | task-0: ['en_US.lm.bak', 4], | task-0: ['user.lm.bak', 2], | task-0: ] | task-0: ], | task-0: [ | task-0: # must not overwrite existing model | task-0: [ | task-0: ['user.lm', 1], | task-0: ['user.lm.bak', 2], | task-0: ['en_US.lm', 3], | task-0: ], | task-0: [ | task-0: ['en_US.lm', 3], | task-0: ['user.lm', 1], | task-0: ['user.lm.bak', 2], | task-0: ] | task-0: ], | task-0: ] | task-0: | task-0: os.mkdir(self._user_dir)# foil user dir migration | task-0: os.mkdir(self._model_dir) | task-0: | task-0: for i, (_input, _output) in enumerate(tests): | task-0: for fn, size in _input: | task-0: self._touch(os.path.join(self._model_dir, fn), size) | task-0: | task-0: with self._run_onboard() as p: | task-0: > self.assertEqual(_output, | task-0: self._get_model_files(), "test " + str(i)) | task-0: E AssertionError: Lists differ: [['en_US.lm', 1]] != [['user.lm', 1]] | task-0: E | task-0: E First differing element 0: | task-0: E ['en_US.lm', 1] | task-0: E ['user.lm', 1] | task-0: E | task-0: E - [['en_US.lm', 1]] | task-0: E ? | task-0: E | task-0: E + [['user.lm', 1]] | task-0: E
Bug#1076818: mayavi2: FTBFS: NameError: name 'build_src' is not defined
Source: mayavi2
Version: 4.8.1-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Dear maintainer,
mayavi2 fails to build from source. From my build log:
| dpkg-buildpackage: info: source package mayavi2
| dpkg-buildpackage: info: source version 4.8.1-5
| dpkg-buildpackage: info: source distribution unstable
| dpkg-source --before-build .
| dpkg-buildpackage: info: host architecture amd64
| debian/rules clean
| dh clean --buildsystem=pybuild
|dh_auto_clean -O--buildsystem=pybuild
| I: pybuild base:311: python3.12 setup.py clean
| /<>/setup.py:127: SyntaxWarning: invalid escape sequence '\.'
| sources = '(\.py)|(\.rst)$'
| /<>/setup.py:128: SyntaxWarning: invalid escape sequence '\.'
| excluded_dirs = '^\.'
| /<>/setup.py:152: SyntaxWarning: invalid escape sequence '\.'
| sources = '(\.py)|(\.rst)$'
| /<>/setup.py:153: SyntaxWarning: invalid escape sequence '\.'
| excluded_dirs = '^\.'
| Traceback (most recent call last):
| File "/<>/setup.py", line 291, in
| class MyBuildSrc(build_src.build_src):
| ^
| NameError: name 'build_src' is not defined
| E: pybuild pybuild:389: clean: plugin distutils failed with: exit code=1:
python3.12 setup.py clean
| dh_auto_clean: error: pybuild --clean -i python{version} -p 3.12 returned
exit code 13
| make: *** [debian/rules:12: clean] Error 25
| dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2
A full build log is available here:
https://buildd.debian.org/status/fetch.php?pkg=mayavi2&arch=riscv64&ver=4.8.1-5&stamp=1721739198&raw=0
https://buildd.debian.org/status/fetch.php?pkg=mayavi2&arch=ppc64el&ver=4.8.1-5&stamp=1721738978&raw=0
The issue seems to be related to the removal of python3-distutils
starting with python3-stdlib-extensions version 3.12.4-1.
Regards
Aurelien
Bug#1076650: [d...@fifthhorseman.net: Bug#1076650: rust-sequoia-sop 0.35.0-3 FTBFS on mips64el ("relocation truncated to fit: R_MIPS_TLS_GD ...")]
/usr/src/rustc-1.79.0/library/std/src/sys/thread_local/fast_local.rs:93:(.text._ZN3std4hash6random11RandomState3new4KEYS7__getit17hf1d4ca09b6309bdaE+0x38): relocation truncated to fit: R_MIPS_TLS_GD against `std::hash::random::RandomState::new::KEYS::__getit::__KEY' collect2: error: ld returned 1 exit status error: could not compile `sequoia-sop` (lib test) due to 1 previous error Caused by: process didn't exit successfully: `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=sequoia_sop CARGO_MANIFEST_DIR=/<> CARGO_PKG_AUTHORS='Justus Winter ' CARGO_PKG_DESCRIPTION='An implementation of the Stateless OpenPGP Interface using Sequoia' CARGO_PKG_HOMEPAGE='https://sequoia-pgp.org/' CARGO_PKG_LICENSE=GPL-2.0-or-later CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=sequoia-sop CARGO_PKG_README=README.md CARGO_PKG_REPOSITORY='https://gitlab.com/sequoia-pgp/sequoia-sop' CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=0.35.0 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=35 CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' CARGO_PRIMARY_PACKAGE=1 CARGO_RUSTC_CURRENT_DIR=/<> LD_LIBRARY_PATH=/<>/target/debug/deps OUT_DIR=/<>/target/mips64el-unknown-linux-gnuabi64/debug/build/sequoia-sop-f5bc5e9e498cf4f4/out rustc --crate-name sequoia_sop --edition=2021 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --test --cfg 'feature="default"' -C metadata=07411ef21101d0bf -C extra-filename=-07411ef21101d0bf --out-dir /<>/target/mips64el-unknown-linux-gnuabi64/debug/deps --target mips64el-unknown-linux-gnuabi64 -C incremental=/<>/target/mips64el-unknown-linux-gnuabi64/debug/incremental -L dependency=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps -L dependency=/<>/target/debug/deps --extern anyhow=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/libanyhow-6b4ca0a2ff29fed5.rlib --extern sequoia_openpgp=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/libsequoia_openpgp-c8df2195a74c1140.rlib --extern sop=/<>/target/mips64el-unknown-linux-gnuabi64/debug/deps/libsop-4d091cf357cb81c2.rlib -C debuginfo=2 -C strip=none --cap-lints warn -C linker=mips64el-linux-gnuabi64-gcc -C link-arg=-Wl,-z,relro --remap-path-prefix /<>=/usr/share/cargo/registry/sequoia-sop-0.35.0 --remap-path-prefix /<>/debian/cargo_registry=/usr/share/cargo/registry -C codegen-units=1 -L native=/usr/lib/mips64el-linux-gnuabi64 -L native=/usr/lib/mips64el-linux-gnuabi64 -L native=/usr/lib/mips64el-linux-gnuabi64` (exit status: 1) dh_auto_test: error: /usr/share/cargo/bin/cargo test --all returned exit code 101 make[1]: *** [debian/rules:29: override_dh_auto_test] Error 25 ``` - Fin du message transféré - -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1073859: gopacket: FTBFS with glibc 2.39 due to internal type __time64_t
Hi,
On 2024-07-18 01:15, Reinhard Tartler wrote:
> Aurelien Jarno writes:
>
> > I have just uploaded a NMU to delayed/2 using the above strategy. Please
> > feel free to ask me to delay or cancel it. You will find the
> > corresponding debdiff attached.
>
> I've looked over the patch, it LGTM. Thank you for providing the patch!
>
> I understand it is going to land later today, that's awesome! If for
> some reason it should fall throught he cracks, please upload it directly
> to sid.
It appears that the fix was not fully correct and trigger an autopkgtest
regression on armhf and armel. I took the freedom to upload a fix,
please find the debdiff attached.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
diff -Nru gopacket-1.1.19/debian/changelog gopacket-1.1.19/debian/changelog
--- gopacket-1.1.19/debian/changelog2024-07-16 22:14:26.0 +0200
+++ gopacket-1.1.19/debian/changelog2024-07-19 23:22:16.0 +0200
@@ -1,3 +1,10 @@
+gopacket (1.1.19-6.2) unstable; urgency=medium
+
+ * Non maintainer upload.
+ * Better fix for compatibility with glibc 2.39.
+
+ -- Aurelien Jarno Fri, 19 Jul 2024 21:22:16 +
+
gopacket (1.1.19-6.1) unstable; urgency=medium
* Non maintainer upload.
diff -Nru
gopacket-1.1.19/debian/patches/0002-fix-time-type-with-__USE_TIME_BITS64.patch
gopacket-1.1.19/debian/patches/0002-fix-time-type-with-__USE_TIME_BITS64.patch
---
gopacket-1.1.19/debian/patches/0002-fix-time-type-with-__USE_TIME_BITS64.patch
2024-07-16 22:14:26.0 +0200
+++
gopacket-1.1.19/debian/patches/0002-fix-time-type-with-__USE_TIME_BITS64.patch
2024-07-19 23:21:35.00000 +0200
@@ -1,20 +1,27 @@
From: Aurelien Jarno
-Date: Tue, 16 Jul 2024 19:28:53 +0200
+Date: Fri, 19 Jul 2024 23:21:31 +0200
Subject: fix time type with __USE_TIME_BITS64
---
- pcap/pcap_unix.go.orig |3 ---
- 1 file changed, 3 deletions(-)
+ pcap/pcap_unix.go | 10 --
+ 1 file changed, 8 insertions(+), 2 deletions(-)
--- a/pcap/pcap_unix.go
-+++ b/pcap/pcap_unix.go.orig
-@@ -111,9 +111,6 @@ int pcap_tstamp_type_name_to_val(const char* t) {
- #elif __ANDROID__
b/pcap/pcap_unix.go
+@@ -112,8 +112,14 @@ int pcap_tstamp_type_name_to_val(const c
#define gopacket_time_secs_t __kernel_time_t
#define gopacket_time_usecs_t __kernel_suseconds_t
--#elif __GLIBC__
+ #elif __GLIBC__
-#define gopacket_time_secs_t __time_t
-#define gopacket_time_usecs_t __suseconds_t
++#define gopacket_time_secs_t time_t
++// Due to https://sourceware.org/bugzilla/show_bug.cgi?id=31510 we need a
special case of gopacket_time_usecs_t
++// Once fixed on the GNU libc side, the whole special __GLIBC__ case can be
removed.
++#if defined(__USE_TIME64_REDIRECTS) || (__TIMESIZE == 32 && __USE_TIME_BITS64)
++#define gopacket_time_usecs_t __suseconds64_t
++#else
++#define gopacket_time_usecs_t suseconds_t
++#endif
#else // Some form of linux/bsd/etc...
#include
#ifdef __OpenBSD__
Bug#1076612: libquadmath0: wrongly assumes that the storage for __float128 arguments is aligned
Package: libquadmath0
Version: 14-20240330-1
Severity: serious
Tags: upstream fixed-upstream
Control: affects -1 evolver libc6
Control: fixed -1 libquadmath0/14-20240429-1
Control: block 1075938 by -1
Hi,
evolver autopkgtest fails with glibc 2.39:
https://ci.debian.net/packages/e/evolver/testing/amd64/49199929/
I have track the issue to a segmentation fault inside libquadmath0:
| Surface Evolver Version 2.70a (Debian 2.70+ds-8+b2), August 27, 2013, 64-bit.
| Compiled for float128, 33 digits precision.
| Built with Geomview support.
|
| Enter command:
| Enter command: // Typical evolution to sphere
| Enter command: gogo := { g 5; r; g 5; hessian; r; g 5; hessian; }
| Enter command:
| Enter command: // Evolution to very high accuracy, using higher-order
Lagrange elements.
| Enter command: // To be run on original datafile.
| Enter command: gogo2 := { g 5; r; g 5; hessian; r; g 5; hessian;
| more>lagrange 2; g 5; hessian;
| more>lagrange 4; g 5; hessian;
| more>lagrange 6; g 5; hessian;
| more>ideal_rad := (3*body[1].volume/4/pi)^(1/3);
| more>printf "Area error: %g\n",total_area - 4*pi*ideal_rad^2;
| more>printf "Vertex radius spread: %g\n",
| more> max(vertex,sqrt((x-.5)^2+(y-.5)^2+(z-.5)^2))
| more>- min(vertex,sqrt((x-.5)^2+(y-.5)^2+(z-.5)^2));
| more> }
| Enter command: g 5; v; r ; g 10; v;
|
| Program received signal SIGSEGV, Segmentation fault.
| 0x77f93ed9 in __quadmath_printf_fp (fp=fp@entry=0x7fffb1b0,
info=0x7fffb498, args=0x7fffb200) at
../../../src/libquadmath/printf/printf_fp.c:366
| 366 ../../../src/libquadmath/printf/printf_fp.c: No such file or
directory.
| (gdb) bt
| #0 0x77f93ed9 in __quadmath_printf_fp (fp=fp@entry=0x7fffb1b0,
info=0x7fffb498, args=0x7fffb200) at
../../../src/libquadmath/printf/printf_fp.c:366
| #1 0x77f96b3a in flt128_printf_fp (fp=,
info=, args=) at
../../../src/libquadmath/printf/quadmath-printf.c:371
| #2 0x77ca96cf in __printf_function_invoke
(buf=buf@entry=0x7fffc210, callback=0x77f96b00 ,
args_value=0x7fffb890, ndata_args=,
info=info@entry=0x7fffb498) at ./printf_buffer_as_file.h:52
| #3 0x77cac337 in printf_positional (buf=buf@entry=0x7fffc210,
format=format@entry=0x558aefd0 "%3d. energy: %#*.*Qg scale: %#Qg\n",
readonly_format=readonly_format@entry=0, ap=ap@entry=0x7fffc250,
| ap_savep=ap_savep@entry=0x7fffbdb8, nspecs_done=1,
nspecs_done@entry=0, lead_str_end=, work_buffer=,
save_errno=, grouping=, thousands_sep=, mode_flags=)
| at ./stdio-common/vfprintf-internal.c:1345
| #4 0x77cadbfa in __printf_buffer (buf=buf@entry=0x7fffc210,
format=0x558aefd0 "%3d. energy: %#*.*Qg scale: %#Qg\n", ap=0x7fffc250,
mode_flags=6) at ./stdio-common/vfprintf-internal.c:1041
| #5 0x77cc99f1 in __vsprintf_internal (string=,
maxlen=maxlen@entry=18446744073709551615, format=,
args=args@entry=0x7fffc250, mode_flags=mode_flags@entry=6) at
./libio/iovsprintf.c:62
| #6 0x77d62afd in ___sprintf_chk (s=,
flag=flag@entry=1, slen=slen@entry=18446744073709551615,
format=format@entry=0x558aefd0 "%3d. energy: %#*.*Qg scale: %#Qg\n") at
./debug/sprintf_chk.c:40
| #7 0x556d919b in sprintf (__fmt=0x558aefd0 "%3d. energy: %#*.*Qg
scale: %#Qg\n", __s=) at
/usr/include/x86_64-linux-gnu/bits/stdio2.h:30
| #8 iterate () at ../../../src/iterate.c:277
| #9 0x556f170c in letter_command (c=) at
../../../src/command.c:465
| #10 0x556564a7 in eval (ex_original=ex_original@entry=0x7fffdeb0,
params=params@entry=0x0, self_id=self_id@entry=0, parent_frame=,
parent_frame@entry=0x0) at ../../../src/evaltree.c:396
| #11 0x555a3f43 in command (text=text@entry=0x7fffdf70 "g 5; v; r
; g 10; v;", mode=mode@entry=1) at ../../../src/query.c:247
| #12 0x556eeb17 in old_menu (text=text@entry=0x7fffdf70 "g 5; v; r
; g 10; v;") at ../../../src/command.c:125
| #13 0x556944a0 in exec_commands (basefd=basefd@entry=0x0,
promptstring=promptstring@entry=0x558b6aa1 "Enter command: ") at
../../../src/tmain.c:839
| #14 0x5556816e in main (argc=1, argv=0x7fffe210) at
../../../src/tmain.c:678
This issue has been fixed upstream by the following commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8455d6f6cd43b7b143ab9ee19437452fceba9cc9
This fixes went into libquadmath0/14-20240429-1, but hasn't reached
testing yet due to the new dependency on amdgcn-tools-18 added in that
version and the llvm-toolchain-18 mess.
Regards
Aurelien
Bug#1070446: rocm-hipamd: arm64 FTBFS with glibc 2.38
Hi, On 2024-05-06 23:14, Aurelien Jarno wrote: > Dear maintainers, > > glibc 2.38 introduced changes to the bits/math-vector.h file on arm64 in > order to support math vector functions. This unfortunately caused the > FTBFS of your packages. > > The change has been temporarily reverted in version 2.38-8 until a fix > is found, and I have opened #1070668 on the glibc side to track the > issue, with a Cc: to the arm64 porters. > > I am therefore downgrading the bugs to severity important. However this > should not prevent working on a solution to the problem with the arm64 > porters, and depending on the case either at the package level, or at > the upstream glibc/gcc/llvm level. With glibc 2.39, the revert is not possible anymore, therefore I rocm-hipamd FTBFS again. I have therefore upgraded the severity to serious. Emanuele Rocca is working on a solution on the upstream LLVM side. In the meantime we might have to remove the rocm-hipamd arm64 binaries to let glibc and future rocm-hipamd migrate to testing. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1075938: transition: glibc 2.39
On 2024-07-17 11:27, Graham Inggs wrote: > Hi Aurelien > > On Mon, 15 Jul 2024 at 20:54, Aurelien Jarno wrote: > > Ok, I have upgraded them to serious. Note that at least for gopacket and > > rocm-hipamd, these bugs translate into autopkgtest regressions. > > If I recall correctly, in Ubuntu the issue was first seen in the > autopkgtest failure of mumax3, which is in contrib and not built for > arm64 in Debian. > > The remaining failures; in rocm-hipamd, aspectc++, cbmc, et al, > manifested as FTBFS. rocm-hipamd manifests as FTBFS, but also as an autopkgtest regression for the current version: https://ci.debian.net/packages/r/rocm-hipamd/testing/arm64/ gopacket causes bettercap autopkgtest to fail: https://ci.debian.net/packages/b/bettercap/testing/amd64 I have done a NMU currently in delayed, so that should get fixed soon, at least in sid. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1073859: gopacket: FTBFS with glibc 2.39 due to internal type __time64_t
control: tag -1 + pending
Dear maintainer,
On 2024-06-19 23:07, Aurelien Jarno wrote:
> Source: gopacket
> Version: 1.1.19-6
> Severity: important
> Tags: patch ftbfs
> User: debian-gl...@lists.debian.org
> Usertags: glibc2.39
> Control: affects -1 bettercap
>
> Dear maintainer,
>
> gopacket fail to build from source when built against glibc 2.39:
>
> | src/github.com/google/gopacket/pcap/pcap_unix.go:349:18: could not
> determine kind of name for C.gopacket_time_secs_t
>
> Packages depending on golang-github-google-gopacket-dev are also
> affected.
>
> It appears that the issue has been introduced in version 1.1.19-5 by
> 0002-fix-time-type-with-__USE_TIME_BITS64.patch. It uses __time64_t when
> __USE_TIME_BITS64 is defined, but __time64_t is an internal type which
> must never used by user code. Among other things it is not defined in
> when it equals __time_t. glibc 2.39 changed the cases where
> __USE_TIME_BITS64 is defined.
>
> The easiest way to fix that is to just drop the glibc specific part and
> use the generic definition, which relies on correct definition of time_t
> and suseconds_t, and avoid logic duplication between gopacket and glibc.
> The following patch does that and could be used as a replacement for
> 0002-fix-time-type-with-__USE_TIME_BITS64.patch:
>
I have just uploaded a NMU to delayed/2 using the above strategy. Please
feel free to ask me to delay or cancel it. You will find the
corresponding debdiff attached.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
diff -Nru gopacket-1.1.19/debian/changelog gopacket-1.1.19/debian/changelog
--- gopacket-1.1.19/debian/changelog2024-03-28 09:51:11.0 +0100
+++ gopacket-1.1.19/debian/changelog2024-07-16 22:14:26.0 +0200
@@ -1,3 +1,11 @@
+gopacket (1.1.19-6.1) unstable; urgency=medium
+
+ * Non maintainer upload.
+ * Fix time type with __USE_TIME_BITS64 in a way that is compatible with
+glibc 2.39.
+
+ -- Aurelien Jarno Tue, 16 Jul 2024 20:14:26 +
+
gopacket (1.1.19-6) unstable; urgency=medium
* Fix missing endif
diff -Nru
gopacket-1.1.19/debian/patches/0002-fix-time-type-with-__USE_TIME_BITS64.patch
gopacket-1.1.19/debian/patches/0002-fix-time-type-with-__USE_TIME_BITS64.patch
---
gopacket-1.1.19/debian/patches/0002-fix-time-type-with-__USE_TIME_BITS64.patch
2024-03-28 09:51:11.0 +0100
+++
gopacket-1.1.19/debian/patches/0002-fix-time-type-with-__USE_TIME_BITS64.patch
2024-07-16 22:14:26.0 +0200
@@ -1,26 +1,20 @@
-From: Shengjing Zhu
-Date: Thu, 28 Mar 2024 16:28:53 +0800
+From: Aurelien Jarno
+Date: Tue, 16 Jul 2024 19:28:53 +0200
Subject: fix time type with __USE_TIME_BITS64
---
- pcap/pcap_unix.go | 5 +
- 1 file changed, 5 insertions(+)
+ pcap/pcap_unix.go.orig |3 ---
+ 1 file changed, 3 deletions(-)
-diff --git a/pcap/pcap_unix.go b/pcap/pcap_unix.go
-index d1a9cdc..4f0c92b 100644
--- a/pcap/pcap_unix.go
-+++ b/pcap/pcap_unix.go
-@@ -112,8 +112,13 @@ int pcap_tstamp_type_name_to_val(const char* t) {
b/pcap/pcap_unix.go.orig
+@@ -111,9 +111,6 @@ int pcap_tstamp_type_name_to_val(const char* t) {
+ #elif __ANDROID__
#define gopacket_time_secs_t __kernel_time_t
#define gopacket_time_usecs_t __kernel_suseconds_t
- #elif __GLIBC__
-+#ifndef __USE_TIME_BITS64
- #define gopacket_time_secs_t __time_t
- #define gopacket_time_usecs_t __suseconds_t
-+#else
-+#define gopacket_time_secs_t __time64_t
-+#define gopacket_time_usecs_t __suseconds64_t
-+#endif
+-#elif __GLIBC__
+-#define gopacket_time_secs_t __time_t
+-#define gopacket_time_usecs_t __suseconds_t
#else // Some form of linux/bsd/etc...
#include
#ifdef __OpenBSD__
Bug#1075938: transition: glibc 2.39
Hi, On 2024-07-14 19:57, Sebastian Ramacher wrote: > Control: tags -1 confirmed > Control: forwarded -1 > https://release.debian.org/transitions/html/glibc-2.39.html > > On 2024-07-08 07:26:43 +0200, Aurelien Jarno wrote: > > Package: release.debian.org > > Severity: normal > > X-Debbugs-Cc: gl...@packages.debian.org > > Control: affects -1 + src:glibc > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Dear release team, > > > > I would like to get a transition slot for glibc 2.39. It has been > > available in experimental for two months already. It has been built > > successfully on all release architectures and most ports architectures. > > The experimental pseudo-excuses look good overall. > > Please go ahead. Thanks, I have just uploaded it. > > The current known issues are available in the BTS using the glibc2.39 > > usertag: > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=glibc2.39;users=debian-gl...@lists.debian.org > > > > gopacket has a patch available and I can take care of NMUing if it is > > not fixed before the transition starts. > > > > For aspectc++, cbmc and rocm-hipamd, the situation is a bit more > > complex. Those packages have issues with the types introduced on the > > arm64 version of bits/math-vector.h. Those are guarded by clang or gcc > > version checks, but the guards are ignored by the packages for various > > reasons. A workaround is present in glibc 2.38, but it can't be ported > > easily in glibc 2.39. I therefore propose to remove the corresponding > > arm64 packages from the archive. aspectc++ and cbmc are leaf packages. > > For rocm-hipamd, this also means removing 15 reverse dependencies. > > We can wait a bit for the maintainers to react and otherwise let's go > ahead with the removals. Ok, I have upgraded them to serious. Note that at least for gopacket and rocm-hipamd, these bugs translate into autopkgtest regressions. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1075849: websockify: FTBFS on riscv64 (test timeout)
control: retitle -1 websockify: FTBFS with systemd (>= 256~rc3-3) due to fileno limit bump Hi, On 2024-07-06 11:54, Graham Inggs wrote: > Source: websockify > Version: 0.10.0+dfsg1-6 > Severity: serious > Tags: ftbfs > X-Debbugs-Cc: debian-ri...@lists.debian.org > > Hi Maintainer > > Since the recent binNMU for Python 3.12 as default, websockify FTBFS > on riscv64 [1], where it built previously. I've copied what I hope > is the relevant part of the log below. > > Currently builds time out after 10 hours, where previous builds would > complete successfully in 10 - 20 minutes. > > This is blocking the transition to Python 3.12 as default. The problem is not limited to riscv64, but can be reproduced on an up to date amd64 testing/sid installation. Depending on the amount of swap available, the result could be an OOM or a FTBFS. In my test it OOmed after allocating around 60 GB. I tracked down the issue to the increase of open file limit in systemd 256~rc3-3 [1] from 1048576 to 1073741816. In particular this code from websockify/websockifyserver.py is the culprit: |# Close open files |maxfd = resource.getrlimit(resource.RLIMIT_NOFILE)[1] |if maxfd == resource.RLIM_INFINITY: maxfd = 256 |for fd in reversed(range(maxfd)): Just allocating an array of 1000+ millions entries with range() requires a lot of resources, but it is also reversed and looped over. Regards Aurelien [1] https://tracker.debian.org/news/1533060/accepted-systemd-256rc3-3-source-into-unstable/ -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1076217: locales,gosa-dev: install program with same name (update-locale)
control: reassign -1 gosa-dev On 2024-07-12 20:22, Chris Hofstaedtler wrote: > Package: locales,gosa-dev > Control: block 1075856 by -1 > > Hi, > > your packages locales and gosa-dev both install a program > named "update-locale", although in different components of the PATH. > > As this is confusing and a possible source of bugs, policy bug > #1075856 wants to outlaw this. > > Please find a solution for your packages. Ideas: > 1) if one of the programs is an internal implementation detail of > the package, install it into a private path in /usr/lib instead. > 2) rename one of the programs I would go for the option to rename the one in the gosa-dev package. Rationale: - The version in locales predates the one in gosa-dev by a few years - The version in locales acts at the system level - The locale package has a much higher popcon than gosa-dev [1][2] I am therefore reassigning the bug there, but feel free to answer if you disagree. Regards Aurelien [1] https://qa.debian.org/popcon-graph.php?packages=locales&show_installed=on&want_percent=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 [2] https://qa.debian.org/popcon-graph.php?packages=gosa-dev&show_installed=on&want_percent=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1063515: glibc: Please build with -mbranch-protection=standard on arm64 to enable PAC/BTI support
Hi, On 2024-07-10 10:15, Emanuele Rocca wrote: > Hi, > > On 2024-02-09 11:36, Emanuele Rocca wrote: > > In order to properly support PAC/BTI in Debian we need first GCC to > > enable support for the feature, and that has not happened yet. > > PAC/BTI support is now turned on in GCC starting with 13.3.0-2. I have tried a > glibc rebuild in sid with the following patch, which was proposed some time > ago > by Aurelien. The rebuild went fine and I double-checked that crti.o, Scrt1.o, > and crtn.o have BTI enabled. > > Logs here: https://people.debian.org/~ema/glibc_2.38-15_arm64.build > > Please consider applying the patch at the next glibc upload. Thanks! There is already a transition to glibc 2.39 planned (see bug#1075938). To avoid mixing possible issues, this will have to wait for it to finish first. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1075851: mayavi2: FTBFS on ppc64el and riscv64
On 2024-07-06 12:09, Graham Inggs wrote: > Source: mayavi2 > Version: 4.8.1-5 > Severity: serious > Tags: ftbfs > X-Debbugs-Cc: debian-ri...@lists.debian.org, debian-powe...@lists.debian.org > > Hi Maintainer > > mayavi2 FTBFS on ppc64el [1] and riscv64 [2], where it built > previously. I've copied what I hope > is the relevant part of the log below. From a quick look, the problems appears when testing for the support of -march=native. ppc64el and riscv64 have in common that they don't support this GCC option. Normally this fails the following way: | $ gcc -march=native | gcc: error: '-march=native': ISA string must begin with rv32 or rv64 | gcc: fatal error: no input files | compilation terminated. However something sets LC_CTYPE to C.UTF-8, and pybuild also sets LC_ALL to C.UTF-8. This causes GCC to output a slightly different error message: | $ LC_CTYPE=C.UTF-8 gcc -march=native | gcc: error: ‘-march=native’: ISA string must begin with rv32 or rv64 | gcc: fatal error: no input files | compilation terminated. Note how the quotes are different and use non-ASCII characters. This is what chokes numpy distutils code. Now I am not sure why the problem suddenly happens. It might be related or not to a Python 3.12 change. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1075938: transition: glibc 2.39
Package: release.debian.org Severity: normal X-Debbugs-Cc: gl...@packages.debian.org Control: affects -1 + src:glibc User: release.debian@packages.debian.org Usertags: transition Dear release team, I would like to get a transition slot for glibc 2.39. It has been available in experimental for two months already. It has been built successfully on all release architectures and most ports architectures. The experimental pseudo-excuses look good overall. The current known issues are available in the BTS using the glibc2.39 usertag: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=glibc2.39;users=debian-gl...@lists.debian.org gopacket has a patch available and I can take care of NMUing if it is not fixed before the transition starts. For aspectc++, cbmc and rocm-hipamd, the situation is a bit more complex. Those packages have issues with the types introduced on the arm64 version of bits/math-vector.h. Those are guarded by clang or gcc version checks, but the guards are ignored by the packages for various reasons. A workaround is present in glibc 2.38, but it can't be ported easily in glibc 2.39. I therefore propose to remove the corresponding arm64 packages from the archive. aspectc++ and cbmc are leaf packages. For rocm-hipamd, this also means removing 15 reverse dependencies. As glibc is using symbol versioning, there is no soname change. That said a few packages are using libc internal symbols and have to be rebuilt for this transition. Here is the corresponding ben file: title = "glibc"; is_affected = .depends ~ /libc[0-9.]* \(< from ISO C2X They are unlikely to be widely used at this point, but at least systemd uses some of them. This might block their migration to testing during the transition. Thanks for considering. Regards, Aurelien
Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test
Hi, On 2024-07-05 09:43, Sam Hartman wrote: > >>>>> "Chris" == Chris Hofstaedtler writes: > Chris> Adam (adsb) points out that the test code in > Chris> lib/rpc/unit-test/client.c [1] uses code that does not > Chris> support IPv6(-only). I.e. gethostbyname for a name that has > Chris> no IPv4 address will fail. > > So, are the builds going to unshare or not? Yes, that's the plan, but there is still packages to fix before we can do that, so that will still take a few weeks or months. > given that the code is apparently quite happy to work with a hostname > that points to ipv4 loopback and given that I already spent a good > chunk of time dealing with buildd churn this month, I don't have a lot > of love for dealing with more gratuitous environment changes entirely > outside my control. Your package is not able to cope with host names pointing to an IPv6 due the use of gethostbyname in the testsuite to do the name resolution. Switching to unshare buildds will only hide the problem. It has nothing to do with gratuitous environment change. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1074368: libc6: libguestfs-test-tool fails on 2.38.13 libc6
Hi, On 2024-06-28 11:45, vishal bhoj wrote: > On Fri, Jun 28, 2024 at 12:07 AM Aurelien Jarno wrote: > > > Hi, > > > > On 2024-06-27 10:44, Vishal Bhoj wrote: > > > Package: libc6 > > > Version: 2.38-13 > > > Severity: important > > > X-Debbugs-Cc: vishalb...@gmail.com > > > > > > Dear Maintainer, > > > > > > *** Reporter, please consider answering these questions, where > > appropriate *** > > > > > >* What led up to the situation? > > > Upgrading libc6 on testing has caused libguestfs usage. > > > > Thanks for your bug report. I am unable to reproduce your issue, here > > the libguestfs-test-tool program returns: > > > > = TEST FINISHED OK = > > > > Therefore, could you please share the full output of that program so > > that we can understand the problem? > > > > I use debian testing in container. I have ran the below test case using > docker and podman as well: > $ docker run -it debian:testing > root@9d14b1ceee4f:/# apt update > root@9d14b1ceee4f:/# apt install -y libguestfs-tools > root@9d14b1ceee4f:/# libguestfs-test-tool // Passes with libc 2.38.12 > root@9d14b1ceee4f:/# apt install libc6 // updates libc to 2.38.13 > root@9d14b1ceee4f:/# libguestfs-test-tools // fails > . > . > . > [2.498808] Kernel panic - not syncing: Attempted to kill init! > exitcode=0x0100 > [2.499156] CPU: 0 PID: 1 Comm: init Not tainted 6.8.12-amd64 #1 Debian > 6.8.12-1 > [2.499277] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS > 1.16.3-debian-1.16.3-2 04/01/2014 > [2.500309] Call Trace: > [2.500781] > [2.500894] panic+0x33b/0x360 > [2.501120] do_exit+0x987/0xaf0 > [2.501166] ? do_iter_readv_writev+0x151/0x1c0 > [2.501219] do_group_exit+0x31/0x80 > [2.501266] __x64_sys_exit_group+0x18/0x20 > [2.501324] do_syscall_64+0x83/0x190 > [2.501569] ? syscall_exit_to_user_mode+0x88/0x220 > [2.501623] ? do_writev+0x7e/0x160 > [2.501660] ? do_writev+0x7e/0x160 > [2.501697] ? syscall_exit_to_user_mode+0x88/0x220 > [2.501746] ? do_syscall_64+0x8f/0x190 > [2.501786] ? do_writev+0x7e/0x160 > [2.502782] ? do_writev+0x7e/0x160 > [2.502821] ? syscall_exit_to_user_mode+0x88/0x220 > [2.502870] ? do_syscall_64+0x8f/0x190 > [2.502908] ? do_syscall_64+0x8f/0x190 > [2.502947] ? __irq_exit_rcu+0x3b/0xc0 > [2.502988] entry_SYSCALL_64_after_hwframe+0x78/0x80 > [2.504127] RIP: 0033:0x4094ee > [2.504359] Code: 00 00 48 8b 05 73 59 00 00 e9 81 fe ff ff 66 2e 0f 1f > 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 48 63 ff b8 e7 00 00 00 0f 05 > 3c 00 00 00 0f 1f 44 00 00 48 89 d0 0f 05 eb f9 90 f3 0f 1e fa > [2.504557] RSP: 002b:7ffc901cd868 EFLAGS: 0246 ORIG_RAX: > 00e7 > [2.505435] RAX: ffda RBX: 0001 RCX: > 004094ee > [2.505530] RDX: RSI: RDI: > 0001 > [2.505599] RBP: 7ffc901cd8c0 R08: fefefefefefefeff R09: > 002a > [2.506576] R10: 0006 R11: 0246 R12: > 0040b20c > [2.506650] R13: 7f6e61228173 R14: 7ffc901cd8b0 R15: > 0ff0 > [2.506750] > [2.507099] Kernel Offset: 0x1b60 from 0x8100 > (relocation range: 0x8000-0xbfff) > [2.507984] Rebooting in 1 seconds.. > libguestfs: error: appliance closed the connection unexpectedly, see > earlier error messages > libguestfs: child_cleanup: 0x62967dcdbd80: child process died > libguestfs: sending SIGTERM to process 21005 > libguestfs: qemu maxrss 256472K > libguestfs: error: guestfs_launch failed, see earlier error messages > libguestfs: closing guestfs handle 0x62967dcdbd80 (state 0) > libguestfs: command: run: rm > libguestfs: command: run: \ -rf /tmp/libguestfsyfGib0 > libguestfs: command: run: rm > libguestfs: command: run: \ -rf /tmp/libguestfsWw8pYe > root@9d14b1ceee4f:/# Thanks for the details, The problem is due to the fact your only partially upgraded your testing system, which is not something supported. In that particular case you also need to upgrade base-files along with libc6, as there are tight together by the usr-merge transition.. I'll see if this can be forced by adding for instance a break against base-files, but this might just increase the chance that apt fails to find a solution to the ugprade from bookworm to trixie. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1074368: libc6: libguestfs-test-tool fails on 2.38.13 libc6
Hi, On 2024-06-27 10:44, Vishal Bhoj wrote: > Package: libc6 > Version: 2.38-13 > Severity: important > X-Debbugs-Cc: vishalb...@gmail.com > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > Upgrading libc6 on testing has caused libguestfs usage. Thanks for your bug report. I am unable to reproduce your issue, here the libguestfs-test-tool program returns: = TEST FINISHED OK = Therefore, could you please share the full output of that program so that we can understand the problem? Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1065186: caml-crush: missing build-dep on libtirpc-dev (and also rpcsvc-proto)
Dear maintainer, On 2024-03-01 16:55, Aurelien Jarno wrote: > Source: caml-crush > Version: 1.0.12-1.1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > > Dear maintainer, > > Starting with glibc 2.31, support for NIS (libnsl library) has been > moved to a separate libnsl2 package. In order to allow a smooth > transition, a libnsl-dev, which depends on libtirpc-dev, has been added > to the libc6-dev package. > > The libnsl-dev dependency has been temporarily dropped in the 2.37-15.1 > NMU, as part of the 64-bit time_t transition. This causes caml-crush to > FTBFS in sid with: > > | checking for gawk... no > | checking for mawk... mawk > | checking for camlidl... yes > | checking for spatch... yes > | Detected coccinelle version 1.1.1 > | configure: Using default C based client and RPC > | checking for getnetname in -ltirpc... no > | configure: Using the glibc RPC implementation > | checking for rpc/rpc.h... no > | configure: error: Could not find C RPC headers. > | cd build-SERVER && tail -v -n \+0 config.log > > This could be fixed by adding an explicit Build-Depends on libtirpc-dev. > The glibc change will likely be reverted in the short term, but given > its a change we want to do for Trixie, this will only lower the severity > of the bug. > > I also noticed that caml-crush, uses rpcgen, provided by the > rpcsvc-proto during the build process. It is currently a dependency of > the libc6-dev package for the same reason as libnsl-dev, and will be > removed at some point. Therefore please also add an explicit > Build-Depends on rpcsvc-proto. I have just done a NMU to fix this issue. Please find the debdiff attached. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net diff -Nru caml-crush-1.0.12/debian/changelog caml-crush-1.0.12/debian/changelog --- caml-crush-1.0.12/debian/changelog 2023-01-27 09:11:33.0 +0100 +++ caml-crush-1.0.12/debian/changelog 2024-06-26 17:42:56.0 +0200 @@ -1,3 +1,10 @@ +caml-crush (1.0.12-1.2) unstable; urgency=medium + + * Non-maintainer upload. + * Add build-dependency on libtirpc-dev and rpcsvc-proto (Closes: #1065186). + + -- Aurelien Jarno Wed, 26 Jun 2024 17:42:56 +0200 + caml-crush (1.0.12-1.1) unstable; urgency=medium * Non-maintainer upload diff -Nru caml-crush-1.0.12/debian/control caml-crush-1.0.12/debian/control --- caml-crush-1.0.12/debian/control2021-11-25 16:23:09.0 +0100 +++ caml-crush-1.0.12/debian/control2024-06-26 17:42:56.0 +0200 @@ -2,7 +2,7 @@ Section: net Priority: optional Maintainer: Thomas Calderon -Build-Depends: debhelper (>= 12), debhelper-compat (= 13), ocaml-native-compilers, camlidl, coccinelle, libocamlnet-ocaml-dev (>= 3.5.1), libocamlnet-ssl-ocaml-dev (>= 3.5.1), libocamlnet-ocaml-bin (>= 3.5.1), libssl-dev, libgnutls28-dev, libconfig-file-ocaml-dev, camlp4, dh-exec +Build-Depends: debhelper (>= 12), debhelper-compat (= 13), ocaml-native-compilers, camlidl, coccinelle, libocamlnet-ocaml-dev (>= 3.5.1), libocamlnet-ssl-ocaml-dev (>= 3.5.1), libocamlnet-ocaml-bin (>= 3.5.1), libssl-dev, libgnutls28-dev, libconfig-file-ocaml-dev, camlp4, dh-exec, libtirpc-dev, rpcsvc-proto Standards-Version: 4.6.0.1 Homepage: https://github.com/caml-pkcs11/caml-crush Vcs-Git: https://github.com/caml-pkcs11/caml-crush.git
Bug#1065160: slapi-nis: FTBFS: missing build-dep on libnsl-dev
Dear maintainer, On 2024-03-01 11:33, Aurelien Jarno wrote: > Source: slapi-nis > Version: 0.60.0-1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > User: debian-gl...@lists.debian.org > Usertags: libnsl-dev > > Dear maintainer, > > Starting with glibc 2.31, support for NIS (libnsl library) has been > moved to a separate libnsl2 package. In order to allow a smooth > transition, a libnsl-dev has been added to the libc6-dev package. > > This dependency has been temporarily dropped in the 2.37-15.1 NMU, as > part of the 64-bit time_t transition. This causes slapi-nis to FTBFS in > sid with: > > | /bin/bash ../libtool --tag=CC --mode=link gcc -I/usr/include/nss > -I/usr/include/nspr -I/usr/include/tirpc -DDEFS_NIS_MAIN -g -O2 > -ffile-prefix-map=/<>=. -fstack-protector-strong > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection > -module -avoid-version -export-symbols-regex '.*_plugin_init' -Wl,-z,relro -o > nisserver-plugin-defs nisserver_plugin_defs-defs-nis.o -lsss_nss_idmap > | libtool: link: gcc -I/usr/include/nss -I/usr/include/nspr > -I/usr/include/tirpc -DPORTMAP_MAIN -g -O2 > -ffile-prefix-map=/<>=. -fstack-protector-strong > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection > -Wl,-z -Wl,relro -o portmap portmap-portmap.o -lnss3 -lnssutil3 -lsmime3 > -lssl3 -lplds4 -lplc4 -lnspr4 -ltirpc -lwrap -lnsl -lsss_nss_idmap > | /usr/bin/ld: cannot find -lnsl: No such file or directory > | collect2: error: ld returned 1 exit status > | make[3]: *** [Makefile:717: portmap] Error 1 > | make[3]: *** Waiting for unfinished jobs > | libtool: link: gcc -I/usr/include/nss -I/usr/include/nspr > -I/usr/include/tirpc -DDEFS_NIS_MAIN -g -O2 > -ffile-prefix-map=/<>=. -fstack-protector-strong > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection > -Wl,-z -Wl,relro -o nisserver-plugin-defs nisserver_plugin_defs-defs-nis.o > -lsss_nss_idmap > | make[3]: Leaving directory '/<>/src' > | make[2]: *** [Makefile:547: all] Error 2 > | make[2]: Leaving directory '/<>/src' > | make[1]: *** [Makefile:481: all-recursive] Error 1 > | make[1]: Leaving directory '/<>' > | dh_auto_build: error: make -j3 returned exit code 2 > | make: *** [debian/rules:8: build] Error 25 > | dpkg-buildpackage: error: debian/rules build subprocess returned exit > status 2 > > This could be fixed by adding an explicit Build-Depends on libnsl-dev. > The glibc change will likely be reverted in the short term, but given > its a change we want to do for Trixie, this will only lower the severity > of the bug. I have just done a NMU to fix this issue. Please find the debdiff attached. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net diff -Nru slapi-nis-0.60.0/debian/changelog slapi-nis-0.60.0/debian/changelog --- slapi-nis-0.60.0/debian/changelog 2022-11-21 10:38:23.0 +0100 +++ slapi-nis-0.60.0/debian/changelog 2024-06-26 17:18:36.0 +0200 @@ -1,3 +1,10 @@ +slapi-nis (0.60.0-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Add libnsl-dev as build-dependency. Closes: #1065160. + + -- Aurelien Jarno Wed, 26 Jun 2024 17:18:36 +0200 + slapi-nis (0.60.0-1) unstable; urgency=medium * New upstream release. diff -Nru slapi-nis-0.60.0/debian/control slapi-nis-0.60.0/debian/control --- slapi-nis-0.60.0/debian/control 2022-11-21 10:16:32.0 +0100 +++ slapi-nis-0.60.0/debian/control 2024-06-26 17:18:36.0 +0200 @@ -13,6 +13,7 @@ libsss-nss-idmap-dev, libtirpc-dev, libwrap0-dev, + libnsl-dev, pkg-config Standards-Version: 4.5.0 Homepage: https://pagure.io/slapi-nis
Bug#1074141: razercfg_0.43-1_mips64el-buildd.changes REJECTED
Source: razercfg Version: 0.43-1 Severity: serious On 2024-06-23 16:05, Debian FTP Masters wrote: > > > razercfg_0.43-1_mips64el.deb: has 7 file(s) with a timestamp too far in the > past: > etc/init.d/razerd (Thu Jan 1 00:00:00 1970) etc/razer.conf (Thu Jan 1 > 00:00:00 1970) usr/bin/razer-gamewrapper (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/pyrazer/__init__.py (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/pyrazer/main.py (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/pyrazer/ui.py (Thu Jan 1 00:00:00 1970) > usr/lib/tmpfiles.d/razerd.conf (Thu Jan 1 00:00:00 1970) > > > > === > > Please feel free to respond to this email if you don't understand why > your files were rejected, or if you upload new files which address our > concerns. >
Bug#1073861: chrony: autopkgtest/upstream-simulation-test-suite fails with glibc 2.39
Source: chrony Version: 4.5-2 Severity: important Tags: patch User: debian-gl...@lists.debian.org Usertags: glibc2.39 Dear maintainer, The upstream-simulation-test-suite test of chrony autopkgtest fails to run when running against glibc 2.39 (currently in experimental): | 129s 001-defaults Testing default test settings: | 129s network with 1*1 servers and 1 clients: | 129s non-default settings: | 129s starting node 1: OK | 129s starting node 2: OK | 139s running simulation:clknetsim failed | 139s ERROR | 139s FAIL | 139s | 139s 002-largenetwork Testing large network: | 139s network with 4*3 servers and 5 clients: | 139s non-default settings: | 139s client_start=2000 | 139s clients=5 | 139s max_sync_time=2300 | 139s min_sync_time=2100 | 139s server_strata=3 | 139s servers=4 | 139s time_rms_limit=5e-4 | 140s starting node 1: OK | 140s starting node 2: OK | 140s starting node 3: OK | 140s starting node 4: OK | 140s starting node 5: OK | 140s starting node 6: OK | 140s starting node 7: OK | 140s starting node 8: OK | 140s starting node 9: OK | 140s starting node 10:OK | 140s starting node 11:OK | 140s starting node 12:OK | 140s starting node 13:OK | 140s starting node 14:OK | 140s starting node 15:OK | 140s starting node 16:OK | 140s starting node 17:OK | 150s running simulation:clknetsim failed | 150s ERROR | 150s FAIL https://ci.debian.net/packages/c/chrony/unstable/arm64/47859880/ The issue is already fixed in upstream clknetsim [1]. Could you please update the commit in the autopktest? Regards Aurelien [1] https://github.com/mlichvar/clknetsim/commit/633a0be069bac00e5aa562c0e5e15a3bf30b6af2
Bug#1073859: gopacket: FTBFS with glibc 2.39 due to internal type __time64_t
Source: gopacket Version: 1.1.19-6 Severity: important Tags: patch ftbfs User: debian-gl...@lists.debian.org Usertags: glibc2.39 Control: affects -1 bettercap Dear maintainer, gopacket fail to build from source when built against glibc 2.39: | src/github.com/google/gopacket/pcap/pcap_unix.go:349:18: could not determine kind of name for C.gopacket_time_secs_t Packages depending on golang-github-google-gopacket-dev are also affected. It appears that the issue has been introduced in version 1.1.19-5 by 0002-fix-time-type-with-__USE_TIME_BITS64.patch. It uses __time64_t when __USE_TIME_BITS64 is defined, but __time64_t is an internal type which must never used by user code. Among other things it is not defined in when it equals __time_t. glibc 2.39 changed the cases where __USE_TIME_BITS64 is defined. The easiest way to fix that is to just drop the glibc specific part and use the generic definition, which relies on correct definition of time_t and suseconds_t, and avoid logic duplication between gopacket and glibc. The following patch does that and could be used as a replacement for 0002-fix-time-type-with-__USE_TIME_BITS64.patch: --- a/pcap/pcap_unix.go +++ b/pcap/pcap_unix.go @@ -111,9 +111,6 @@ #elif __ANDROID__ #define gopacket_time_secs_t __kernel_time_t #define gopacket_time_usecs_t __kernel_suseconds_t -#elif __GLIBC__ -#define gopacket_time_secs_t __time_t -#define gopacket_time_usecs_t __suseconds_t #else // Some form of linux/bsd/etc... #include #ifdef __OpenBSD__ Regards Aurelien
Bug#1073806: atftp: autopkgtest fail with glibc 2.39
Source: atftp Version: 0.8.0-4 Severity: important Tags: patch User: debian-gl...@lists.debian.org Usertags: glibc2.39 Dear maintainer, atftp autopkgtest fails to run when running against glibc 2.39 (currently in experimental): https://ci.debian.net/packages/a/atftp/unstable/amd64/47816426/ After investigation, it appears to be due to the "to" variable in tftpd_receive_request() to contain uninitialized values, as a consequence of removing the initialization in #613582. When using glibc 2.39, the values on the stack from which the "to" variable is allocated seems to have different values. The issue also seems to have been triggered by #1070683, and not reproducible with version 0.8.0-3. The following patch fixes the issue, but it might just be a workaround, and the real problem might be deeper: --- atftp-0.8.0.orig/tftpd.c +++ atftp-0.8.0/tftpd.c @@ -643,6 +643,9 @@ void *tftpd_receive_request(void *arg) socklen_t len = sizeof(to); char addr_str[SOCKADDR_PRINT_ADDR_LEN]; + + /* Do not rely on uninitialized data following the https://bugs.debian.org/613582 fix */ + memset(&to, 0, sizeof(to)); /* Detach ourself. That way the main thread does not have to * wait for us with pthread_join. */ Regards Aurelien
Bug#1073046: FTBFS with huge file limit due to testsuite timeouts
control: reopen -1 control: retitle -1 FTBFS with huge file number limit due to testsuite timeouts control: found -1 2.4.7-3 control: severity -1 important Hi, On 2024-06-16 00:19, Debian FTP Masters wrote: > cups (2.4.7-3) unstable; urgency=medium > . >[ Helge Kreutzmann ] >* Update German man page (2220t) > . >[ Thorsten Alteholz ] >* reintroduce time_t changes that were accidentally deleted > with last upload > (thanks to Michael Hudson-Doyle for this work) >* debian/rules: no test on riscv64 (Closes: #1073046) Thanks for fixing this bug promptly. However it only papers over the real issue, which is not riscv64 specific. riscv64 build daemons run a mix of testing and sid, and are thus affected by some recent changes in systemd. More precisely, systemd 256~rc3-3 bumped the maximum number of open files hard limit from 1048576 to 1073741816 [1]. This value seems to be used for the maxevents argument of an epoll_pwait syscall, which now fails: | epoll_pwait(3, NULL, 1073741816, 1000, NULL, 8) = -1 EINVAL (Invalid argument) Note that the second argument is NULL, as the call to calloc() to allocate the events buffer for 1073741816 events failed and returned NULL. This leads to the corresponding error message in the log file: | X [17/Jun/2024:18:35:01.401971 +] cupsdDoSelect() failed - Bad address! The issue is reproducible on an up to date testing system, which has been rebooted since the upgrade to systemd 256. Reducing that limit with ulimit workarounds the issue. Regards Aurelien [1] https://salsa.debian.org/systemd-team/systemd/-/commit/99066f931bb49b43e7282fc1fe8488373bfb81e5 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1072375: sysvinit: please implement restarting init using triggers
Hi Mark, On 2024-06-13 10:26, Mark Hindley wrote: > Aurelien, > > On Sun, Jun 09, 2024 at 08:51:34PM +0100, Mark Hindley wrote: > > Until that happens, does that mean that sysvinit will be restarted twice, > > once by > > libc6 postinst and once by the libc-upgrade trigger? > > For the record, this appears to be the case: > > $ dpkg-reconfigure libc6 > > logs in /var/log/syslog: > > Jun 13 10:11:21 DebianUnstable init: Trying to re-exec init > Jun 13 10:11:23 DebianUnstable init: Trying to re-exec init > > I suppose it isn't a show-stopper, but it is ugly. Do you see a way to avoid > it? Yes, this is indeed a side effect, that we will have to leave with for some time. The goal is to reduce it as much as possible, and in anycase to get that done before the trixie release. My idea is to remove the old restart mechanism once all init systems have added the trigger support. For that we probably wants to add a Breaks against the init system version older than the one implementing the change. So far this has been implemented in systemd, and sysvinit (but not yet uploaded). TTBOMK, the only other one that need to get support is finit. I will see if I can come with a patch to move things forward. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
Hi Helmut On 2024-06-05 14:21, Helmut Grohne wrote: > Hi Aurelien, > > On Tue, Jun 04, 2024 at 06:58:00PM +0200, Aurelien Jarno wrote: > > It would be really great if glibc can migrate before as it fixes an RC > > bug. That said there are suspicions that it introduced bug #1072521, so > > it might be worth investigating before it gets pushed into testing. > > Unfortunately, on my side, I am unable to reproduce the issue. > > I looked and couldn't spot the RC bug you are referring to. The highest > severity one I could spot is the systemd/debianutils/sbuild where > telinit kills the build, but that isn't RC. Am I missing something? Oops, I was convinced that #1071462 was filled with severity serious. Nevermind. > I also looked at #1072521 and am fairly certain that it is not a glibc i> regression. For sure, #1072521 is not trivially reproducible. In fact, I > am not aware of anyone other than the submitter reproducing it. Beyond > that, it is very likely that the submitter uses a non-default file > descriptor soft limit (even though raising it does not reproduce the > problem). > > In general, I agree with glibc migrating before doing the synced upload > and that's also what Paul asked for. From my side the urgency here is > risk management. Doing it later makes it harder for me to provide > resources to fix fallout and I'm trying to find a good balance. > Given that both util-linux and glibc need to migrate, deferring to > Thursday (still leaves time until the Sunday cron) or even Monday looks > most reasonable to me. Ok, thanks. > > Please go ahead with a NMU. I wonder about experimental, do we want to > > do the changes at the same time, or a bit after? Said otherwise is > > moving files from /usr to /lib supported? > > I don't want to support such moves in any way. Hence, I think the best > option would be to simultaneously NMU experimental. dash is affected in > the same way. Ok, a simultaneous experimental NMU sounds good. Note however that people often downgrade glibc when they have suspicions (like in the fakeroot case above), or even the hard way with dpkg once their system is broken. Therefore we should at least test that case to see how much breakage to expect, and also to easily spot patterns where a system went through a glibc downgrade possibly followed by an upgrade. But that's not a reason to block the upload. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
Hi, On 2024-06-03 23:10, Helmut Grohne wrote: > On Wed, May 29, 2024 at 03:14:59PM +0200, Helmut Grohne wrote: > > Since noble includes these changes and I'd get this done sooner rather > > than later, how about moving forward with June 5th after 22:30 UTC (such > > that all buildds have regenerated their chroots before the upload)? > > I got vaguely positive feedback from Paul Gevers on this date. Hence, I > plan to upload after the June 5th mirror push and allocate time for > handling unexpected fallout. > > dash, base-files and bash are fully migrated at the time of this > writing. glibc migrated -11 and -12 still has 5 autopkgtest regressions. > util-linux migrated -6, -7 has a piuparts regression and -8 hopefully > gets tested soon. I hope that both migrate before the planned upload and > will consult with the release team on whether to bump back or go ahead. It would be really great if glibc can migrate before as it fixes an RC bug. That said there are suspicions that it introduced bug #1072521, so it might be worth investigating before it gets pushed into testing. Unfortunately, on my side, I am unable to reproduce the issue. > I have rebased and retested the patches in > https://salsa.debian.org/helmutg/bootstrap-usrmerge-demo. > > Andrew, Aurelien, Chris, Matthias, Santiago: Any objections? For glibc no objection. > You may send me signed uploads (.dsc + source chanages) and I will > otherwise move ahead with regular NMUs. If you send signed changes, I > recommend encrypting them using my gpg key. Please go ahead with a NMU. I wonder about experimental, do we want to do the changes at the same time, or a bit after? Said otherwise is moving files from /usr to /lib supported? Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1072392: RM: ctfutils -- RoQA; RoQA; port abandoned
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: ctfut...@packages.debian.org, debian-...@lists.debian.org Control: affects -1 + src:ctfutils User: ftp.debian@packages.debian.org Usertags: remove The kfreebsd-* ports have been removed. Please remove ctfutils which has no reverse dependencies.
Bug#1072375: sysvinit: please implement restarting init using triggers
Source: sysvinit Version: 3.09-1 Severity: important Dear maintainer, To avoid issues like #1071462, please implement restarting init by declaring an interest on the "libc-upgrade" trigger, introduced in glibc 2.38-12. At some point this will allow us to drop the corresponding part of the libc6 postinst. Thanks Aurelien
Bug#1072374: finit: please implement restarting init using triggers
Source: finit Version: 4.7-1 Severity: important Dear maintainer, To avoid issues like #1071462, please implement restarting init by declaring an interest on the "libc-upgrade" trigger, introduced in glibc 2.38-12. At some point this will allow us to drop the corresponding part of the libc6 postinst. Thanks Aurelien
Bug#1072373: systemd: please implement restarting systemd using triggers
Package: systemd Version: 256~rc3-7 Severity: important Dear maintainer, To avoid issues like #1071462, please implement restarting systemd by declaring an interest on the "libc-upgrade" trigger, introduced in glibc 2.38-12. At some point this will allow us to drop the corresponding part of the libc6 postinst. Thanks Aurelien
Bug#1071172: libc6-dev omits the bits directory
Hi, On 2024-05-15 19:10, Aurelien Jarno wrote: > Hi, > > On 2024-05-15 22:10, Joris van der Geer wrote: > > package:libc6-dev > > version: 2.36 > > Please provide a more accurate version than this. In the rest of this > email i will therefore consider the latest glibc version, in sid, ie > 2.38-11: > > > Libc6 omits thr ‘bits’ directory, rendering glibc inoperable > > The bits directory is not omitted, it is provided in > /usr/include/aarch64-linux-gnu following the multiarch path convention. > > > after sucessfull apt-get install libc6 libc6-dev : > > > > When compiling gcc, the process halts at : > > > > In file included from ../.././libgcc/../gcc/tsystem.h:95, > > from ../.././libgcc/libgcc2.c:27: > > /usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No such > > file or directory > >27 | #include > > | ^~ > > compilation terminated. > > make[2]: *** [Makefile:508: _muldi3.o] Error 1 > > make[2]: Leaving directory > > '/home/joris/src/gcc-14.1.0/aarch64-unknown-linux-gnu/libgcc' > > make[1]: *** [Makefile:14517: all-target-libgcc] Error 2 > > make[1]: Leaving directory '/home/joris/src/gcc-14.1.0' > > make: *** [Makefile:1050: all] Error 2 > > I guess you are building gcc from source. For using the multiarch path > convention, you should configure it with --enable-multiarch. Any news on that, can we close the bug? Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1071554: lintian-brush: removal of autotools-dev debhelper causes FTBFS
Package: lintian-brush Version: 0.152 Severity: important Tags: ftbfs Dear maintainer, autotools-dev debhelper has been deprecated, so lintian-brush just removes it [1], which causes packages to FTBFS [2]. It should be replaced by dh_update_autotools_config instead of simply being dropped. Regards Aurelien [1] https://salsa.debian.org/debian/tla/-/commit/6cea8b94c34768268a7a03538d11e1ecc508eb46 [2] https://bugs.debian.org/1071544
Bug#1071544: tla: FTBFS on arm64/ppc64el/riscv64: config.guess: unable to guess system type
Source: tla Version: 1.3.5+dfsg1-4 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear maintainer, The tla packages fails to build on a few "recent" architectures due to outdated config.guess/sub: | cd debian/build && \ | CFLAGS='-g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -mbranch-protection=standard -Wall' CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=2' LDFLAGS='-Wl,-z,relro' \ | AUTOCONF_CROSS='--build aarch64-linux-gnu' AUTOCONF_CFLAGS='-g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -mbranch-protection=standard -Wall' \ | AUTOCONF_CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=2' AUTOCONF_LDFLAGS='-Wl,-z,relro' \ | ../../src/configure --prefix=/usr --with cc gcc | /<>/src/build-tools/gnu/config.guess: unable to guess system type | | This script, last modified 2006-06-06, has failed to recognize | the operating system you are using. It is advised that you | download the most up to date version of the config scripts from | | http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.guess | and | http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/config/config/config.sub | | If the version you run (/<>/src/build-tools/gnu/config.guess) is already up to date, please | send the following data and any information you think might be | pertinent to in order to provide the needed | information to handle your system. | | config.guess timestamp = 2006-06-06 | | uname -m = aarch64 | uname -r = 6.1.0-21-arm64 | uname -s = Linux | uname -v = #1 SMP Debian 6.1.90-1 (2024-05-03) | | /usr/bin/uname -p = unknown | /bin/uname -X = | | hostinfo = | /bin/universe = | /usr/bin/arch -k = | /bin/arch = aarch64 | /usr/bin/oslevel = | /usr/convex/getsysinfo = | | UNAME_MACHINE = aarch64 | UNAME_RELEASE = 6.1.0-21-arm64 | UNAME_SYSTEM = Linux | UNAME_VERSION = #1 SMP Debian 6.1.90-1 (2024-05-03) | make: *** [debian/rules:26: configure-stamp] Error 1 | dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2 The full build logs are available here: https://buildd.debian.org/status/fetch.php?pkg=tla&arch=arm64&ver=1.3.5%2Bdfsg1-4&stamp=1715943782&raw=0 https://buildd.debian.org/status/fetch.php?pkg=tla&arch=ppc64el&ver=1.3.5%2Bdfsg1-4&stamp=1715943032&raw=0 https://buildd.debian.org/status/fetch.php?pkg=tla&arch=riscv64&ver=1.3.5%2Bdfsg1-4&stamp=1715953860&raw=0 It appears that code for updating config.guess/sub from autotools-dev has been dropped, while it is still necessary. Regards Aurelien [1] https://salsa.debian.org/debian/tla/-/commit/6cea8b94c34768268a7a03538d11e1ecc508eb46
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
On 2024-05-20 10:40, Luca Boccassi wrote: > On Mon, 20 May 2024 at 10:37, Aurelien Jarno wrote: > > > > On 2024-05-20 10:22, Luca Boccassi wrote: > > > On Mon, 20 May 2024 at 10:20, Johannes Schauer Marin Rodrigues > > > wrote: > > > > > > > > Hi, > > > > > > > > Quoting Chris Hofstaedtler (2024-05-20 10:38:04) > > > > > * Johannes Schauer Marin Rodrigues [240520 07:35]: > > > > > > [..] But maybe it [glibc's postinst] should be doing some > > > > > > more involved checks about what PID 1 is? It could then make sure > > > > > > to only call > > > > > > systemd telinit if systemd is pid 1. [..] > > > > > > > > > > Well, that would probably suck. Putting the knowledge when to call > > > > > telinit, and a specific telinit, into a ton of different things > > > > > makes all those things hard to get right, hard to update, the usual. > > > > > > > > > > I've checked the sysvinit and the systemd implementations now, and > > > > > they are not that different. Both try to talk to their respective > > > > > pid1 daemons first using their respective communication socket. > > > > > > > > > > But then, if that doesn't work, they diverge: > > > > > - sysvinit's telinit just gives up > > > > > - systemd's telinit, *as an explicit fallback*, sends signals. > > > > > > > > > > systemd's telinit (aka systemctl) helpfully exits if it detects > > > > > being in a chroot, before doing any of that. > > > > > > > > > > IWSTM systemd's telinit could, if called as telinit, not do the > > > > > fallback to stick with sysvinit's behaviour? > > > > > > > > > > As a bonus, sysvinit's telinit could also gain the chroot check, and > > > > > glibc's > > > > > postinst (and other places) can become simpler again. > > > > > > > > via irc, jochen also pointed out: telinit could be the component which > > > > checks > > > > what PID 1 actually is and only do its thing after it confirmed that it > > > > is > > > > indeed an init system like systemd that is providing PID 1? > > > > > > That's all legacy stuff and I really don't want to touch it anymore. > > > Going from the other side, maybe libc6.postinst could use something > > > more reliable than ischroot()? Is systemd-detect-virt able to figure > > > out the situation a bit better? > > > > Nope. > > What's the output? With SYSTEMD_LOG_LEVEL=debug exported In sbuild using unshare chroot running in a VM: | SYSTEMD_LOG_LEVEL=debug /usr/bin/systemd-detect-virt | Failed to read $container of PID 1, ignoring: Permission denied | Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy | Found container virtualization none. | Virtualization QEMU found in DMI (/sys/class/dmi/id/sys_vendor) | UML virtualization not found in /proc/cpuinfo. | Virtualization XEN not found, /proc/xen does not exist | Virtualization found, CPUID=KVMKVMKVM | Found VM virtualization kvm | kvm -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
On 2024-05-20 10:38, Chris Hofstaedtler wrote: > * Johannes Schauer Marin Rodrigues [240520 07:35]: > > [..] But maybe it [glibc's postinst] should be doing some > > more involved checks about what PID 1 is? It could then make sure to only > > call > > systemd telinit if systemd is pid 1. [..] > > Well, that would probably suck. Putting the knowledge when to call > telinit, and a specific telinit, into a ton of different things > makes all those things hard to get right, hard to update, the usual. On the glibc side, this part has always been a pain to handle (a bit less since upstart got removed). And the systemd decision to increase the use of dlopen() will make this step even more necessary. Therefore I wonder if it could be solved using the trigger mechanism, basically glibc saying "I got upgraded" and the packages, being systemd, sysv or any other system can then decide what to do instead of hardcoding that on the glibc side. That would also simplify the chrootless case a bit. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines
On 2024-05-20 10:22, Luca Boccassi wrote: > On Mon, 20 May 2024 at 10:20, Johannes Schauer Marin Rodrigues > wrote: > > > > Hi, > > > > Quoting Chris Hofstaedtler (2024-05-20 10:38:04) > > > * Johannes Schauer Marin Rodrigues [240520 07:35]: > > > > [..] But maybe it [glibc's postinst] should be doing some > > > > more involved checks about what PID 1 is? It could then make sure to > > > > only call > > > > systemd telinit if systemd is pid 1. [..] > > > > > > Well, that would probably suck. Putting the knowledge when to call > > > telinit, and a specific telinit, into a ton of different things > > > makes all those things hard to get right, hard to update, the usual. > > > > > > I've checked the sysvinit and the systemd implementations now, and > > > they are not that different. Both try to talk to their respective > > > pid1 daemons first using their respective communication socket. > > > > > > But then, if that doesn't work, they diverge: > > > - sysvinit's telinit just gives up > > > - systemd's telinit, *as an explicit fallback*, sends signals. > > > > > > systemd's telinit (aka systemctl) helpfully exits if it detects > > > being in a chroot, before doing any of that. > > > > > > IWSTM systemd's telinit could, if called as telinit, not do the > > > fallback to stick with sysvinit's behaviour? > > > > > > As a bonus, sysvinit's telinit could also gain the chroot check, and > > > glibc's > > > postinst (and other places) can become simpler again. > > > > via irc, jochen also pointed out: telinit could be the component which > > checks > > what PID 1 actually is and only do its thing after it confirmed that it is > > indeed an init system like systemd that is providing PID 1? > > That's all legacy stuff and I really don't want to touch it anymore. > Going from the other side, maybe libc6.postinst could use something > more reliable than ischroot()? Is systemd-detect-virt able to figure > out the situation a bit better? Nope. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1071192: maildir-utils: FTBFS on riscv64: testsuite failure
Source: maildir-utils
Version: 1.12.4-1
Severity: important
Tags: ftbfs patch upstream
X-Debbugs-Cc: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64
Dear maintainer,
maildir-utils fails to build from source on riscv64 due to a testsuite
failure:
| Summary of Failures:
|
| 38/46 test-storeFAIL4.41s killed by signal 6 SIGABRT
|
| Ok: 45
| Expected Fail: 0
| Fail: 1
| Unexpected Pass:0
| Skipped:0
| Timeout:0
| rm -fr -- /tmp/dh-xdg-rundir-yjVOiMWA
| dh_auto_test: error: cd obj-riscv64-linux-gnu &&
DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test
returned exit code 1
| make: *** [debian/rules:26: binary-arch] Error 25
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit
status 2
The full build log is available there:
https://buildd.debian.org/status/fetch.php?pkg=maildir-utils&arch=riscv64&ver=1.12.4-1&stamp=1714778367&raw=0
After investigation, it appears the test fails due to a too small
timeout in the check for the buildd hardware. Doubling the timeout with
the following patch fixes the issue:
--- maildir-utils-1.12.4.orig/lib/tests/test-mu-store.cc
+++ maildir-utils-1.12.4/lib/tests/test-mu-store.cc
@@ -494,7 +494,7 @@ test_store_circular_symlink(void)
size_t n{};
while (store.indexer().is_running()) {
std::this_thread::sleep_for(100ms);
- g_assert_cmpuint(n++,<=,25);
+ g_assert_cmpuint(n++,<=,50);
}
// there will be a lot of dups
g_assert_false(store.empty());
Note that it might also fix the FTBFS on alpha, hppa and sparc64 as the
symptoms look similar.
Regards
Aurelien
Bug#1071172: libc6-dev omits the bits directory
Hi, On 2024-05-15 22:10, Joris van der Geer wrote: > package:libc6-dev > version: 2.36 Please provide a more accurate version than this. In the rest of this email i will therefore consider the latest glibc version, in sid, ie 2.38-11: > Libc6 omits thr ‘bits’ directory, rendering glibc inoperable The bits directory is not omitted, it is provided in /usr/include/aarch64-linux-gnu following the multiarch path convention. > after sucessfull apt-get install libc6 libc6-dev : > > When compiling gcc, the process halts at : > > In file included from ../.././libgcc/../gcc/tsystem.h:95, > from ../.././libgcc/libgcc2.c:27: > /usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No such > file or directory >27 | #include > | ^~ > compilation terminated. > make[2]: *** [Makefile:508: _muldi3.o] Error 1 > make[2]: Leaving directory > '/home/joris/src/gcc-14.1.0/aarch64-unknown-linux-gnu/libgcc' > make[1]: *** [Makefile:14517: all-target-libgcc] Error 2 > make[1]: Leaving directory '/home/joris/src/gcc-14.1.0' > make: *** [Makefile:1050: all] Error 2 I guess you are building gcc from source. For using the multiarch path convention, you should configure it with --enable-multiarch. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1071093: libc6: [adequate] undefined-symbol
control: reassign -1 adequate control: retitle -1 false positive detected in in libthread_db.so.1 Hi, On 2024-05-14 10:14, Martin-Éric Racine wrote: > Package: libc6 > Version: 2.38-11 > Severity: important > > $ adequate --all --tags -py-file-not-bytecompiled > libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => > ps_pdwrite > libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => > ps_pglobal_lookup > libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => > ps_lsetregs > libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => > ps_getpid > libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => > ps_lgetfpregs > libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => > ps_lsetfpregs > libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => > ps_lgetregs > libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => > ps_pdread This is perfectly normal. libthread_db.so is a special system library for thread debugging. Those symbols are provided by the debuggers using it, for instance gdb or lldb. I am therefore reassigning this to adequate as a false positive. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1070666: util-linux: last(1) is broken on i386 since 2.40-8
Hi, On 2024-05-14 21:51, Chris Hofstaedtler wrote: > Hi Eugene, > > could you please try again with: > util-linux 2.40.1-1 > glibc 2.38-7 or newer > > and report back, if the problem is fixed for you? > > The newer util-linux is rebuilt against the fixed glibc, so it > hopefully is now fine. It might be necessary to delete your old > utmp/lastlog files tho. Looking at it more in details, this is definitely bug#1042562 applied to util-linux. It appears that starting with version 2.40., util-linux automatically enables -D_TIME_BITS=64, so even if i386 is not an architecture that was part of the time_t transition, the problem has been triggered there. It appears that util-linux 2.40.1-1 has been rebuilt against a fixed glibc, so the problem is probably fixed. At the end it should be limited to util-linux versions 2.40-1 to 2.40-8. I don't think it is necessary to upgrade glibc to get the issue fixed. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1071085: chr: FTBFS on riscv64 due to test timeout
Source: chr Version: 0.1.78-1 Severity: important Tags: ftbfs X-Debbugs-Cc: debian-ri...@lists.debian.org User: debian-ri...@lists.debian.org Usertags: riscv64 Dear maintainer, chr fails to build from source on riscv64 (and a few other slow architectures) with a timeout in a test: | tests time out (After 30 seconds) | ―― | 1/1 tests TIMEOUT30.07s killed by signal 15 SIGTERM | | | Ok: 0 | Expected Fail: 0 | Fail: 0 | Unexpected Pass:0 | Skipped:0 | Timeout:1 The full build log is available there: https://buildd.debian.org/status/fetch.php?pkg=chr&arch=riscv64&ver=0.1.78-1&stamp=1715582047&raw=0 After investigation, it appears the test actually passes, but needs 68 seconds instead of the default 30 seconds it got allocated. The following patch uses the --timeout-multiplier feature of meson to increase the timeout. I didn't try to use a different multiplier depending on the architecture as it has no impact on working tests. diff -Nru chr-0.1.78/debian/rules chr-0.1.78/debian/rules --- chr-0.1.78/debian/rules +++ chr-0.1.78/debian/rules @@ -22,8 +22,8 @@ dh_auto_build --builddirectory=$(build_tiny) override_dh_auto_test: - dh_auto_test --builddirectory=$(build_edit) - dh_auto_test --builddirectory=$(build_tiny) + dh_auto_test --builddirectory=$(build_edit) -- --timeout-multiplier=4 + dh_auto_test --builddirectory=$(build_tiny) -- --timeout-multiplier=4 override_dh_auto_install: dh_auto_install --builddirectory=$(build_edit) --destdir=debian/chr Note that it might also fix the same issue on hppa and sparc64. Regards Aurelien
Bug#1071076: inotify-info: baseline ABI violation, builds with -march=native
Source: inotify-info Version: 0.0.1-1 Severity: serious Dear maintainer, inotify-info builds with -march=native, which means the instruction set it uses depends on the buildd that is used. For instance the i386 package uses AVX instructions. In addition -march=native is not supported on all architectures. This is unfortunately not visible in the build log, you might want to make the build system as verbose as reasonably possible as recommended by the debian policy. Regards Aurelien
Bug#1070668: Processed: glibc: packages FTBFS caused by vector math library header on arm64
On 2024-05-07 00:29, Simon Chopin wrote: > As the one who reported the issue in the glibc upstream tracker, I'm now > of the opinion it's not a glibc bug, but rather issues with the > individual packages that are now FTBFS. As far as I know, this is either > a parser pretending to be GCC without implementing all the GCC features > (e.g. aspectc++), and/or a compiler targetting another platform while > still using the system headers (e.g. rocm-hipamd). The goal of the removal was able to progress with the migration of glibc 2.38 to testing to not block other packages for a long time. Anyway this strategy does not work for glibc 2.39 (it causes a FTBFS of glibc), so we have to solve the issues before being able to get glibc 2.39 to unstable. Among the 4 failures, cxref already got fixed. For aspectc++ and cbmc, I agree with you that the issues have to be fixed at the package level. For rocm-hipamd, the maintainer claims this is a toolchain issue... -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1070981: RM: h5z-zfp/experimental -- RoQA; outdated version wrt unstable
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: h5z-...@packages.debian.org Control: affects -1 + src:h5z-zfp User: ftp.debian@packages.debian.org Usertags: remove h5z-zfp in experimental has a lower version than in unstable, which means binNMUs are not possible as they get rejected by dak. I do not see the point of keeping this lower version in experimental, I think the only reason it has not been decrufted is the s390x binary which is only in experimental. It is not buildable in sid anymore due to the new architecture-is-little-endian build dependency.
Bug#1070980: libamplsolver: FTBFS on architectures calling fedisableexcept (ppc64el, s390x, riscv64, ...)
Source: libamplsolver
Version: 0~20190702-2
Severity: serious
Tags: patch upstream ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-ri...@lists.debian.org
Usertags: riscv64
Dear maintainer,
libamplsolver fails to build from source on a few architectures that call
fedisableexcept(), which from a quick look seems to be !x86 !arm !alpha:
| make[1]: Entering directory '/<>'
| cd ${OBJDIR=sys.`uname -m`.`uname -s`}; make
| make[2]: Entering directory '/<>/sys.riscv64.Linux'
| make[2]: warning: jobserver unavailable: using -j1. Add '+' to parent make
rule.
| cc -c -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -pipe -DASL_BUILD -fPIC -DPIC -DASL_NO_FPINITMT fpinit.c
| fpinit.c: In function ‘fpinit_ASL’:
| fpinit.c:143:9: error: implicit declaration of function ‘fedisableexcept’;
did you mean ‘feraiseexcept’? [-Werror=implicit-function-declaration]
| 143 | fedisableexcept(FE_ALL_EXCEPT);
| | ^~~
| | feraiseexcept
| cc1: some warnings being treated as errors
| make[2]: *** [makefile:240: arith.h] Error 1
| make[2]: Leaving directory '/<>/sys.riscv64.Linux'
| make[1]: *** [makefile:2: amplsolver] Error 2
| make[1]: Leaving directory '/<>'
| dh_auto_build: error: make -j4 returned exit code 2
| make: *** [debian/rules:15: binary-arch] Error 25
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit
status 2
A full build log is available there:
https://buildd.debian.org/status/fetch.php?pkg=libamplsolver&arch=riscv64&ver=0%7E20190702-2%2Bb2&stamp=1715411707&raw=0
The problem has been introduced with dpkg 1.22.5, which changed the
build flags to include -Werror=implicit-function-declaration as part of
the time_t transition. fedisableexcept() is a GNU extension, so it has
to be enabled by building with -D_GNU_SOURCE. The patch belows implement
that.
Regards
Aurelien
--- libamplsolver-0~20190702.orig/fpinit.c
+++ libamplsolver-0~20190702/fpinit.c
@@ -49,6 +49,7 @@ int isatty_ASL; /* for use with "sw" und
#undef WIN32
#define WIN32
#else
+#define _GNU_SOURCE /* needed for fedisableexcept */
#include "fenv.h"
#endif
--- libamplsolver-0~20190702.orig/solvers/fpinit.c
+++ libamplsolver-0~20190702/solvers/fpinit.c
@@ -49,6 +49,7 @@ int isatty_ASL; /* for use with "sw" und
#undef WIN32
#define WIN32
#else
+#define _GNU_SOURCE /* needed for fedisableexcept */
#include "fenv.h"
#endif
Bug#1070909: llvm-toolchain-18: FTBFS on riscv64: dh_install: warning: llvm-18-linker-tools missing files: usr/lib/llvm-18/lib/LLVMgold.so
control: tag -1 + patch On 2024-05-11 19:50, Aurelien Jarno wrote: > On 2024-05-11 15:46, Sebastian Ramacher wrote: > > Source: llvm-toolchain-18 > > Version: 1:18.1.5-2 > > Severity: serious > > Tags: ftbfs > > Justification: fails to build from source (but built successfully in the > > past) > > X-Debbugs-Cc: sramac...@debian.org > > > > riscv64 is now a release architecture and llvm-toolchain-18 built > > previously. > > > > https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-18&arch=riscv64&ver=1%3A18.1.5-2&stamp=1715249422&raw=0 > > > >debian/rules override_dh_install > > make[1]: Entering directory '/<>' > > dh_install -p libpolly-18-dev usr/lib/llvm-18/lib/cmake/polly/*.cmake > > usr/lib/llvm-18/lib/cmake/polly > > rm -rf debian/tmp/usr/lib/llvm-18/lib/cmake/polly/*.cmake > > dh_install --fail-missing > > dh_install: warning: Please use dh_missing --list-missing/--fail-missing > > instead > > dh_install: warning: This feature will be removed in compat 12. > > dh_install: warning: Cannot find (any matches for) > > "usr/lib/llvm-18/lib/LLVMgold.so" (tried in ., debian/tmp) > > > > dh_install: warning: llvm-18-linker-tools missing files: > > usr/lib/llvm-18/lib/LLVMgold.so > > dh_install: error: missing files, aborting > > make[1]: *** [debian/rules:1432: override_dh_install] Error 255 > > I believe this should be fixed by the following patch. I have launched a > local build and I will confirm that when it is done. The build finished, I confirm that the patch fixes the issue. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1064003: patch for c-t-b build
Hi,
On 2024-05-05 20:57, Helmut Grohne wrote:
> Control: tags -1 + patch
>
> Hi Matthias,
>
> I'm attaching a patch for the c-t-b FTBFS. Note that due to the
> glibc/2.38 upload c-t-b has become completely uninstallable. Hence, a
> timely upload is appreciated. Due to linux-libc-dev currently providing
> the -$arch-cross packages, we have to remove the Build-Conflicts or make
> rename the Provides on linux-libc-dev. I'm ok with both approaches and
> offer dropping the conflict here.
Thanks for working on that. Note that glibc 2.38-9 switched the compiler
to gcc 13, so your patch needs a small update. Please find it attached.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
diff -Nru cross-toolchain-base-68/debian/changelog
cross-toolchain-base-68+nmu1/debian/changelog
--- cross-toolchain-base-68/debian/changelog2023-10-31 08:50:26.0
+
+++ cross-toolchain-base-68+nmu1/debian/changelog 2024-05-04
07:23:39.0 +
@@ -1,3 +1,16 @@
+cross-toolchain-base (68+nmu1) UNRELEASED; urgency=medium
+
+ [ Helmut Grohne ]
+ * Non-maintainer upload.
+ * Build using linux 6.7. Closes: #1064003, #1067370.
+ * Build using glibc 2.38.
+ * Remove linux-libc-dev-ARCH-cross from GLIBC_BUILD_CONFLICTS.
+
+ [ Aurelien Jarno ]
+ * Build using gcc 13.
+
+ -- Helmut Grohne Sat, 04 May 2024 09:23:39 +0200
+
cross-toolchain-base (68) unstable; urgency=medium
* Build using linux 6.5.8. Closes: #1042118.
diff -Nru cross-toolchain-base-68/debian/control
cross-toolchain-base-68+nmu1/debian/control
--- cross-toolchain-base-68/debian/control 2023-10-31 08:50:26.0
+
+++ cross-toolchain-base-68+nmu1/debian/control 2024-05-04 07:23:39.0
+
@@ -9,9 +9,9 @@
Build-Depends: binutils-multiarch,
dpkg (>= 1.21.17), rdfind, symlinks, lsb-release,
binutils-source (>= 2.41-6~),
- glibc-source (>= 2.37-3~),
- gcc-12-source (>= 12.3.0-11~), g++-12 (>= 12.3.0-11~),
- linux-source-6.5 (>= 6.5.8), linux-libc-dev (>= 6.5.8),
+ glibc-source (>= 2.38),
+ gcc-13-source (>= 13), g++-13 (>= 13),
+ linux-source-6.7 (>= 6.7.0), linux-libc-dev (>= 6.7.0),
autoconf (>= 2.69), autoconf2.69, autogen,
automake, bison (>= 1:2.3), chrpath, debhelper-compat (= 13),
dpkg-dev (>= 1.15.3.1), fakeroot, file, flex,
@@ -27,7 +27,7 @@
libjansson-dev, pkg-config,
Build-Conflicts: dpkg-cross, libdebian-dpkgcross-perl,
binutils-x86-64-linux-gnu [!amd64], binutils-i686-linux-gnu [!i386],
binutils-s390x-linux-gnu [!s390x], binutils-powerpc64le-linux-gnu [!ppc64el],
binutils-aarch64-linux-gnu [!arm64], binutils-arm-linux-gnueabihf [!armhf],
binutils-arm-linux-gnueabi [!armel], binutils-riscv64-linux-gnu [!riscv64],
- libc6-amd64-cross, linux-libc-dev-amd64-cross, libc6-i386-cross,
linux-libc-dev-i386-cross, libc6-s390x-cross, linux-libc-dev-s390x-cross,
libc6-ppc64el-cross, linux-libc-dev-ppc64el-cross, libc6-arm64-cross,
linux-libc-dev-arm64-cross, libc6-armhf-cross, linux-libc-dev-armhf-cross,
libc6-armel-cross, linux-libc-dev-armel-cross, libc6-riscv64-cross,
linux-libc-dev-riscv64-cross,
+ libc6-amd64-cross, libc6-i386-cross, libc6-s390x-cross, libc6-ppc64el-cross,
libc6-arm64-cross, libc6-armhf-cross, libc6-armel-cross, libc6-riscv64-cross,
libc6-amd64 [i386 x32], libc6-i386 [amd64 x32], libc6-x32 [amd64 i386]
Package: linux-libc-dev-amd64-cross
diff -Nru cross-toolchain-base-68/debian/rules
cross-toolchain-base-68+nmu1/debian/rules
--- cross-toolchain-base-68/debian/rules2023-10-31 08:50:26.0
+
+++ cross-toolchain-base-68+nmu1/debian/rules 2024-05-04 07:23:39.0
+
@@ -61,11 +61,11 @@
CROSS_GNU_TYPE = $(call _gnu_type,${CROSS_ARCH})
CROSS_PKG_GNU_TYPE = $(subst _,-,$(call _gnu_type,${CROSS_ARCH}))
-MIN_VER_GLIBC := 2.37-3~
-MIN_VER_LINUX := 6.5.8
-MIN_VER_GCC:= 12.3.0-11~
+MIN_VER_GLIBC := 2.38
+MIN_VER_LINUX := 6.7.0
+MIN_VER_GCC:= 13
MIN_VER_BINUTILS := 2.41-6~
-VER_GCC_BASE := 12
+VER_GCC_BASE := 13
libgcc_base:= gcc-s
DEB_VER_LINUX := $(shell apt-cache policy linux-libc-dev | awk '/^ \*\*\*/
{print $$2}')
@@ -110,7 +110,7 @@
# FIXME: No conflict for the host == cross case ...
BINUTILS_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),binutils-$(subst
_,-,$(call _gnu_type,$(a))) [!$(a)]$(,))
-GLIBC_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),libc6-$(a)-cross$(,)
linux-libc-dev-$(a)-cross$(,))
+GLIBC_BUILD_CONFLICTS = $(foreach a,$(CROSS_ARCHS),libc6-$(a)-cross$(,))
# taken from gcc packaging
define unpack_tarball
Bug#1070909: llvm-toolchain-18: FTBFS on riscv64: dh_install: warning: llvm-18-linker-tools missing files: usr/lib/llvm-18/lib/LLVMgold.so
On 2024-05-11 15:46, Sebastian Ramacher wrote: > Source: llvm-toolchain-18 > Version: 1:18.1.5-2 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > X-Debbugs-Cc: sramac...@debian.org > > riscv64 is now a release architecture and llvm-toolchain-18 built > previously. > > https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-18&arch=riscv64&ver=1%3A18.1.5-2&stamp=1715249422&raw=0 > >debian/rules override_dh_install > make[1]: Entering directory '/<>' > dh_install -p libpolly-18-dev usr/lib/llvm-18/lib/cmake/polly/*.cmake > usr/lib/llvm-18/lib/cmake/polly > rm -rf debian/tmp/usr/lib/llvm-18/lib/cmake/polly/*.cmake > dh_install --fail-missing > dh_install: warning: Please use dh_missing --list-missing/--fail-missing > instead > dh_install: warning: This feature will be removed in compat 12. > dh_install: warning: Cannot find (any matches for) > "usr/lib/llvm-18/lib/LLVMgold.so" (tried in ., debian/tmp) > > dh_install: warning: llvm-18-linker-tools missing files: > usr/lib/llvm-18/lib/LLVMgold.so > dh_install: error: missing files, aborting > make[1]: *** [debian/rules:1432: override_dh_install] Error 255 I believe this should be fixed by the following patch. I have launched a local build and I will confirm that when it is done. diff -Nru llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.install.in llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.install.in --- llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.install.in 2024-04-29 11:11:01.0 +0200 +++ llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.install.in 2024-05-11 19:31:14.0 +0200 @@ -2,4 +2,4 @@ usr/lib/llvm-@LLVM_VERSION@/lib/libLTO.so.@LLVM_VERSION@.1 [!powerpc !powerpcspe] usr/lib/llvm-@LLVM_VERSION@/lib/LLVMPolly.so -[!powerpc !powerpcspe] usr/lib/llvm-@LLVM_VERSION@/lib/LLVMgold.so +[!powerpc !powerpcspe !riscv64] usr/lib/llvm-@LLVM_VERSION@/lib/LLVMgold.so diff -Nru llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.links.in llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.links.in --- llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.links.in 2024-03-06 09:19:46.0 +0100 +++ llvm-toolchain-18-18.1.5/debian/llvm-X.Y-linker-tools.links.in 2024-05-11 19:33:50.0 +0200 @@ -1,3 +1,3 @@ #!/usr/bin/dh-exec -[!powerpc !powerpcspe] usr/lib/llvm-@LLVM_VERSION@/lib/LLVMgold.so usr/lib/bfd-plugins/LLVMgold-@LLVM_VERSION@.so +[!powerpc !powerpcspe !riscv64] usr/lib/llvm-@LLVM_VERSION@/lib/LLVMgold.so usr/lib/bfd-plugins/LLVMgold-@LLVM_VERSION@.so Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1070850: cfengine3: missing build-depends on passwd, needed for usermod
Source: cfengine3 Version: 3.21.4-1.1 Severity: important Tags: ftbfs X-Debbugs-Cc: debian-ri...@lists.debian.org User: debian-ri...@lists.debian.org Usertags: riscv64 Dear maintainer, cfengine3 fails to build from source on riscv64, here is the relevant part of the log: | checking for useradd... no | checking for usermod... no | checking for userdel... no ... | /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I./../libpromises -I./../libntech/libutils -I./../libcfnet -I./../cf-check -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu99 -I/usr/include/libxml2 -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu99 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -g -Wall -Wno-pointer-sign -Werror=implicit-function-declaration -Wunused-parameter -O2 -DNDEBUG -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -I/usr/include/libxml2 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -g -Wall -Wno-pointer-sign -Werror=implicit-function-declaration -Wunused-parameter -O2 -DNDEBUG -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -c -o verify_users_pam.lo verify_users_pam.c | libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I./../libpromises -I./../libntech/libutils -I./../libcfnet -I./../cf-check -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu99 -I/usr/include/libxml2 -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu99 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -g -Wall -Wno-pointer-sign -Werror=implicit-function-declaration -Wunused-parameter -O2 -DNDEBUG -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -I/usr/include/libxml2 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -g -Wall -Wno-pointer-sign -Werror=implicit-function-declaration -Wunused-parameter -O2 -DNDEBUG -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -c verify_users_pam.c -fPIC -DPIC -o .libs/verify_users_pam.o | verify_users_pam.c: In function ‘SetAccountLockExpiration’: | verify_users_pam.c:850:50: warning: unused parameter ‘puser’ [-Wunused-parameter] | 850 | static bool SetAccountLockExpiration(const char *puser, bool lock) | | ^ | verify_users_pam.c:850:62: warning: unused parameter ‘lock’ [-Wunused-parameter] | 850 | static bool SetAccountLockExpiration(const char *puser, bool lock) | | ^ | verify_users_pam.c: In function ‘DoCreateUser’: | verify_users_pam.c:1565:38: warning: unused parameter ‘puser’ [-Wunused-parameter] | 1565 | static bool DoCreateUser(const char *puser, const User *u, enum cfopaction action, | | ^ | verify_users_pam.c:1565:57: warning: unused parameter ‘u’ [-Wunused-parameter] | 1565 | static bool DoCreateUser(const char *puser, const User *u, enum cfopaction action, | | ^ | verify_users_pam.c:1565:76: warning: unused parameter ‘action’ [-Wunused-parameter] | 1565 | static bool DoCreateUser(const char *puser, const User *u, enum cfopaction action, | | ^~ | verify_users_pam.c:1566:39: warning: unused parameter ‘ctx’ [-Wunused-parameter] | 1566 | EvalContext *ctx, const Attributes *a, const Promise *pp) | | ~^~~ | verify_users_pam.c:1566:62: warning: unused parameter ‘a’ [-Wunused-parameter] | 1566 | EvalContext *ctx, const Attributes *a, const Promise *pp) | |~~^ | verify_users_pam.c:1566:80: warning: unused parameter ‘pp’ [-Wunused-parameter] | 1566 | EvalContext *ctx, const Attributes *a, const Promise *pp) | | ~~~^~ | verify_users_pam.c: In function ‘DoRemoveUser’: | verify_users_pam.c:1619:62: warning: unused parameter ‘action’ [-Wunused-parameter] | 1619 | static bool DoRemoveUser (const char *puser, enum cfopaction action) | | ^~ | verify_users_pam.c: In function ‘DoModifyUser’: | verify_users_pam.c:1642:18: error: ‘USERMOD’ undeclared (first use in this function) | 1642 | strcpy (cm
Bug#1070441: FTBFS due to /usr/include/aarch64-linux-gnu/bits/math-vector.h
control: severity 1070441 important control: block 1070668 by 1070441 control: severity 1070443 important control: block 1070668 by 1070443 control: severity 1070444 important control: block 1070668 by 1070444 control: severity 1070446 important control: block 1070668 by 1070446 Dear maintainers, glibc 2.38 introduced changes to the bits/math-vector.h file on arm64 in order to support math vector functions. This unfortunately caused the FTBFS of your packages. The change has been temporarily reverted in version 2.38-8 until a fix is found, and I have opened #1070668 on the glibc side to track the issue, with a Cc: to the arm64 porters. I am therefore downgrading the bugs to severity important. However this should not prevent working on a solution to the problem with the arm64 porters, and depending on the case either at the package level, or at the upstream glibc/gcc/llvm level. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1070668: glibc: packages FTBFS caused by vector math library header on arm64
Source: glibc Version: 2.38-1 Severity: important Tags: upstream X-Debbugs-Cc: debian-...@lists.debian.org Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=30909 glibc 2.38 added vector math library (libmvec) support for arm64, with ASIMD and SVE version. This includes an architecture specific header, /usr/include/aarch64-linux-gnu/bits/math-vector.h, to declare the vectorized functions. For that the ASIMD types __Float32x4_t and __Float64x2_t are also defined for GCC >= 9 or CLANG >= 8, and SVE types __SVFloat32_t, __SVFloat64_t and __SVBool_t for GCC >= 10 and CLANG >= 11. Unfortunately this causes issues to the following packages: - #1070441 cmbc: arm64 FTBFS with glibc 2.38 - #1070443 aspectc++: arm64 FTBFS with glibc 2.38 - #1070444 cxref: arm64 FTBFS with glibc 2.38 - #1070446 rocm-hipamd: arm64 FTBFS with glibc 2.38 The issue has already been reported upstream [1]. For now this file has been restored to the generic version in glibc 2.38-8, removing support for the corresponding vector functions [2]. Porters, could you please have a look at the issue, and work on fixes at the package level and at the upstream glibc/gcc/llvm level? Thanks Aurelien [1] https://sourceware.org/bugzilla/show_bug.cgi?id=30909 [2] https://salsa.debian.org/glibc-team/glibc/-/commit/9e2889537336bdad878eef88bcfb13e457e8ea77
Bug#1055297: ruby3.1: fails to build against glibc 2.38
control: severity -1 serious Hi, On 2023-11-03 19:45, Samuel Thibault wrote: > Package: ruby3.1 > Version: 3.1.2-7 > Severity: important > Tags: patch > > Hello, > > ruby3.1 fails to build against glibc 2.38: > > dpkg-gensymbols -plibruby3.1 -Idebian/libruby3.1.symbols -Pdebian/libruby3.1 > -edebian/libruby3.1/usr/lib/x86_64-gnu/libruby-3.1.so.3.1.2 > dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols > file: see diff output below > dpkg-gensymbols: warning: debian/libruby3.1/DEBIAN/symbols doesn't match > completely debian/libruby3.1.symbols > --- debian/libruby3.1.symbols (libruby3.1_3.1.2-7_hurd-amd64) > +++ dpkg-gensymbols5L9SYx 2023-11-03 17:57:31.0 + > [...] > @@ -1818,5 +1818,5 @@ > ruby_xrealloc2@Base 3.1.0~preview1 > ruby_xrealloc@Base 3.1.0~preview1 > setproctitle@Base 3.1.0~preview1 > - strlcat@Base 3.1.0~preview1 > - strlcpy@Base 3.1.0~preview1 > +#MISSING: 3.1.2-7# strlcat@Base 3.1.0~preview1 > +#MISSING: 3.1.2-7# strlcpy@Base 3.1.0~preview1 > > strlcat and strlcpy were indeed added to glibc in version 2.38, so it's > not surprising that ruby3.1 doesn't define its internal versions any > more, and the attached patch can probably be applied? glibc 2.38 is now in unstable, so upgrading the severity to serious. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1059852: transition: glibc 2.38
Hi, On 2024-01-02 13:23, Aurelien Jarno wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: gl...@packages.debian.org > Control: affects -1 + src:glibc > > Dear release team, > > I would like to get a transition slot for glibc 2.38. It has been > available in experimental for a few months and does not have any known > issue anymore. It has been built successfully on all release > architectures and most ports architectures, and the experimental > pseudo-excuses look good overall. > > As glibc is using symbol versioning, there is no soname change. That > said a few packages are using libc internal symbols and have to be > rebuilt for this transition. Here is the corresponding ben file: > > title = "glibc"; > is_affected = .depends ~ /libc[0-9.]* \(< is_good = .depends ~ /libc[0-9.]* \(<< 2.39\)/; > is_bad = .depends ~ /libc[0-9.]* \(<< 2.38\)/; > > The main symbol related changes in this version are the addition of > strlcat and strlcpy and related functions, coming from the BSD world. A > few packages have their own implementation exported in their symbols > file. With glibc 2.38 starting to provide those functions, the packages > stops providing compatibility functions and the associated symbols, > causing them to FTBFS. Many of them have been identified thanks to the > hurd-amd64 bootstrap and have been fixed. The known remaining ones are: > - #1055297 ruby3.1: fails to build against glibc 2.38 > - #1055316 heimdal: fails to build against glibc 2.38 > > Other than that a few symbols have been added to support the C2X binary > constant handling in scanf family of functions. There are unlikely to be > widely used at this point and thus that new packages start to use them, > blocking their migration to testing during the transition. > > Thanks for considering. As discussed on IRC, I just uploaded it. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1070012: keyutils: testsuite wrongly assumes that user 0 always exists
Source: keyutils Version: 1.6.3-3 Severity: important Tags: patch upstream ftbfs X-Debbugs-Cc: debian-wb-t...@lists.debian.org Usertags: unshare Dear maintainer, keyutils fails to build from source when built inside a container: | === /<>/tests/keyctl/newring/bad-args/test.out === | ./runtest.sh: line 13: [: 4096: unary operator expected | +++ CHECK MAXLEN DESC FAILS WITH EDQUOT | FAILED | FAILED | +++ CHECK OVERLONG DESC | +++ CHECK EMPTY KEYRING NAME | +++ CHECK BAD KEY ID | make[3]: *** [Makefile:41: run] Error 1 | make[3]: Leaving directory '/<>/tests' | make[2]: *** [Makefile:253: test] Error 2 | make[2]: Leaving directory '/<>' | dh_auto_test: error: make -j4 test PATH=/<>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games LD_LIBRARY_PATH=/<> SKIPROOTREQ=yes SKIPINSTALLREQ=yes returned exit code 2 | make[1]: *** [debian/rules:25: override_dh_auto_test] Error 25 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:10: binary] Error 2 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 The "unary operator expected" issue is because maxsquota is undefined. Indeed it is defined by looking at /proc/key-users for user 0 (root), however this user does necessary not exists in a container. In addition as the testsuite is run as non-root (contrary to what upstream recommends), I believe the returned values are incorrect. At least on my system they are quite different between root and normal users. This simple one-liner fixes the issue, and should still work fine with the testsuite run as root: --- keyutils-1.6.3.orig/tests/toolbox.inc.sh +++ keyutils-1.6.3/tests/toolbox.inc.sh @@ -45,7 +45,7 @@ fi maxcall=$fullpage -maxsquota=`grep '^ *0': /proc/key-users | sed s@.*/@@` +maxsquota=`grep "^ *$UID": /proc/key-users | sed s@.*/@@` key_gc_delay_file="/proc/sys/kernel/keys/gc_delay" if [ -f $key_gc_delay_file ]; then Regards Aurelien
Bug#1070007: sbuild/unshare: writing to /dev/stdout denied
Package: sbuild Version: 0.85.8 Severity: normal When running sbuild in unshare chroot mode, it is not possible to write to /dev/stdout: | echo test > /dev/stdout | sh: 1: cannot create /dev/stdout: Permission denied This is the reason of the FTBFS of at least clisp and supervisor when using the unshare chroot mode of sbuild.
Bug#1070003: sbuild/unshare: bind mounting individual /dev entries causes inconsistent readdir results
Package: sbuild
Version: 0.85.7
Severity: normal
When running sbuild in unshare chroot mode, /dev is provided by creating
all the entries as regular files, and then the entries from the host
/dev are bind-mounted to the container. This causes readdir(), which
maps to the getdents64 syscall, to return the underlying files in the
/dev directory instead of the bind-mounted files. Although the names are
correct, the d_ino, d_off and d_type values are incorrect. For instance
/dev/null is reported as regular file instead of a character device.
This can be demonstrated by this simple C code:
| #include
| #include
| #include
|
| int main()
| {
| struct dirent *entry;
| DIR *dp;
|
| dp = opendir("/dev");
| if (dp == NULL) {
| perror("opendir");
| return -1;
| }
|
| while((entry = readdir(dp))) {
| printf("%s: type %d\n", entry->d_name, entry->d_type);
| }
|
| closedir(dp);
|
| return 0;
| }
This is the reason of the FTBFS of at least glibc and libwibble when
using the unshare chroot mode of sbuild.
That said, this seems to be the standard way to provide /dev entries on
a non-privileged user namespace, for instance podman has the same issue.
Docker does not have the issue, but on the other hand requires root.
There might be no way to fix the issue, in that case we should consider
this a limitation of the unshare chroot mode, document it, and add
debian specific workarounds to the affected packages.
Bug#1060772: python3-jupyterlab: Using node-corepack downloads yarnpkg from Internet
control: severity -1 serious On 2024-01-14 08:20, Yadd wrote: > Package: python3-jupyterlab > Version: 4.0.9+ds1-1 > Severity: important > X-Debbugs-Cc: y...@debian.org > > Hi, > > the patch 0003-Use-system-provided-yarn.js.patch replaces missing > yarn.js by node-corepack. Please keep in mind that > node-corepack/../yarn.js is a wrapper that downloads yarnpkg from > Internet instead of using Debian's one. As network access is forbidden by Debian Policy section 4.9, this is actually a serious bug. Changing the severity accordingly. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1036369: ruby-rest-client: network-dependent tests fail
control: severity -1 serious On 2023-05-20 10:46, Vignesh Raman wrote: > Package: ruby-rest-client > Version: 2.1.0-3 > Severity: normal > Tags: patch > X-Debbugs-Cc: vignesh.ra...@collabora.com > > Dear Maintainer, > > ruby-rest-client is failing to build because its test suite > depends on access to the internet, As network access is forbidden by Debian Policy section 4.9, this is actually a serious bug. Changing the severity accordingly. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1069892: qemu: FTBFS on riscv64: error: macro "KVM_RISCV_GET_TIMER" requires 4 arguments, but only 3 given
Source: qemu
Version: 1:8.2.3+ds-1
Severity: important
Tags: upstream patch ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-ri...@lists.debian.org
Dear maintainer,
qemu version 1:8.2.3+ds-1 fails to build from source on riscv64:
| FAILED: libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o
| cc -Ilibqemu-riscv64-softmmu.fa.p -I. -I../.. -Itarget/riscv
-I../../target/riscv -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1
-I/usr/include/capstone -I/usr/include/glib-2.0
-I/usr/lib/riscv64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall
-Winvalid-pch -std=gnu11 -O2 -g -fstack-protector-strong -Wundef
-Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls
-Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs
-Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2
-Wmissing-format-attribute -Wno-missing-include-dirs -Wno-shift-negative-value
-Wno-psabi -Wshadow=local -isystem /<>/linux-headers -isystem
linux-headers -iquote . -iquote /<> -iquote
/<>/include -iquote /<>/host/include/generic -iquote
/<>/tcg/riscv -pthread -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -g -O2
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security
-ffile-prefix-map=../../= -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE
-isystem../../linux-headers -isystemlinux-headers -DNEED_CPU_H
'-DCONFIG_TARGET="riscv64-softmmu-config-target.h"'
'-DCONFIG_DEVICES="riscv64-softmmu-config-devices.h"' -MD -MQ
libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o -MF
libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o.d -o
libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o -c
../../target/riscv/kvm/kvm-cpu.c
| ../../target/riscv/kvm/kvm-cpu.c: In function
‘kvm_riscv_get_timebase_frequency’:
| ../../target/riscv/kvm/kvm-cpu.c:691:43: error: macro "KVM_RISCV_GET_TIMER"
requires 4 arguments, but only 3 given
| 691 | KVM_RISCV_GET_TIMER(cs, frequency, reg);
| | ^
| ../../target/riscv/kvm/kvm-cpu.c:104: note: macro "KVM_RISCV_GET_TIMER"
defined here
| 104 | #define KVM_RISCV_GET_TIMER(cs, env, name, reg) \
| |
| ../../target/riscv/kvm/kvm-cpu.c:691:5: error: ‘KVM_RISCV_GET_TIMER’
undeclared (first use in this function); did you mean ‘KVM_RISCV_SBI_EXT_TIME’?
| 691 | KVM_RISCV_GET_TIMER(cs, frequency, reg);
| | ^~~
| | KVM_RISCV_SBI_EXT_TIME
| ../../target/riscv/kvm/kvm-cpu.c:691:5: note: each undeclared identifier is
reported only once for each function it appears in
| ninja: build stopped: subcommand failed.
| make: *** [debian/rules:229: b/qemu/built] Error 1
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit
status 2
A full build log is available here:
https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=riscv64&ver=1%3A8.2.3%2Bds-1&stamp=1714044943&raw=0
After investigation it appears to be an upstream issue, caused by a
patch backported to the 8.2 stable branch, which does not work as this
branch misses some refactoring commits:
| commit 1e4ec0958ec734ed6a194475e699c917ba950cb2
| Author: Yong-Xuan Wang
| Date: Thu Mar 14 14:15:09 2024 +0800
|
| target/riscv/kvm: fix timebase-frequency when using KVM acceleration
|
| The timebase-frequency of guest OS should be the same with host
| machine. The timebase-frequency value in DTS should be got from
| hypervisor when using KVM acceleration.
|
| Signed-off-by: Yong-Xuan Wang
| Message-ID: <20240314061510.9800-1-yongxuan.w...@sifive.com>
| Reviewed-by: Andrew Jones
| Reviewed-by: Philippe Mathieu-Daudé
| Reviewed-by: Alistair Francis
| Signed-off-by: Alistair Francis
| (cherry picked from commit 385e575cd5ab2436c123e4b7f8c9b383a64c0dbe)
| Signed-off-by: Michael Tokarev
| (Mjt: context fix due to missing other changes in this area in 8.2.x)
One way to fix that is to identify and backport the missing commits. I
know that 10f86d1b845087d14b58d65dd2a6e3411d1b6529 is one of them, but
is not enough. However the risk to break more things by backporting more
commits is important.
An alternative is to just fix the build issue with the following patch:
diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
index c1675158fe..f15a540f61 100644
--- a/target/riscv/kvm/kvm-cpu.c
+++ b/target/riscv/kvm/kvm-cpu.c
@@ -687,8 +687,9 @@ static void kvm_riscv_put_regs_timer(CPUState *cs)
uint64_t kvm_riscv_get_timebase_frequency(CPUState *cs)
{
uint64_t reg;
+CPURISCVState *env = &RISCV_CPU(cs)->env;
-KVM_RISCV_GET_TIMER(cs, frequency, reg);
+KVM_RISCV_GET_TIMER(cs, env, frequency, reg);
return reg;
}
I will let you,
Bug#1041415: details
control: tag -1 + fixed-upstream On 2024-04-23 16:22, David Edmondson wrote: > tag 1041415 - upstream > thanks > > Ultimately this fails because /proc is not available in the chroot. > > The version of libc in use *emulates* fchmodat() using /proc/self/fd > rather than using the fchmodat system call. It is emulated, because support for flags != 0 is something new, and requires the fchmodat2 syscall that has been added in Linux kernel version 6.6. On the glibc side, support has been added in glibc 2.39, which is available in git [1], but unfortunately not yet in sid due to binutils/valgrind bug [2] and time_t transition [3] blocking things. Regards Aurelien [1] https://salsa.debian.org/glibc-team/glibc/-/tree/glibc-2.39 [2] https://bugs.debian.org/1057693 [3] https://bugs.debian.org/1059852 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1069730: unblock: glibc/2.37-18
Package: release.debian.org Severity: normal Tags: security X-Debbugs-Cc: gl...@packages.debian.org Control: affects -1 + src:glibc User: release.debian@packages.debian.org Usertags: unblock Hi, glibc 2.37-18 fixes an import security issue (CVE-2024-2961), and it would be nice to have it in testing asap. It is currently blocked by the proftpd-dfsg autopkgtest, which fails due to the lack of libnsl-dev in the chroot, as this dependency got removed in glibc version 2.37-15.1 as part of the time_t transition. proftpd-dfsg has already been fixed by making it an explicity build-dependency, however this fixed version can't enter testing as it is entangled in the time_t transition. The glibc doesn't break proftpd-dfsg in testing, but basically breaks its buildability and thus its autopkgtest. Do you think it would be possible to allow this glibc version to enter testing by ignoring the result of the proftpd-dfsg autopkgtest? Regards Aurelien
Bug#1068963: python-falcon: FTBFS: testsuite failure: 3084 passed, 313 skipped, 170 warnings, 35 errors
Source: python-falcon Version: 3.1.1-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear maintainer, python-falcon fails to build from source due to errors in the testsuite. >From my build log on amd64: | === short test summary info | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_get[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_put[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_head_405[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_post_multipart_form[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_post_multiple[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_post_invalid_content_length[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_post_read_bounded_stream[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_post_read_bounded_stream_large[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_post_read_bounded_stream_no_body[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_sse[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_sse_client_disconnects_early[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestASGIServer::test_stream_chunked_request[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_hello[_uvicorn_factory-None-True] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_hello[_uvicorn_factory-None-False] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_hello[_uvicorn_factory-4321-True] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_hello[_uvicorn_factory-4321-False] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_rejected[_uvicorn_factory-None-True] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_rejected[_uvicorn_factory-None-False] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_rejected[_uvicorn_factory-4040-True] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_rejected[_uvicorn_factory-4040-False] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_missing_responder[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_select_subprotocol_known[_uvicorn_factory-*-amqp] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_select_subprotocol_known[_uvicorn_factory-wamp-wamp] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_select_subprotocol_unknown[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_disconnecting_client_early[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_send_before_accept[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_recv_before_accept[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_invalid_close_code[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_close_code_on_unhandled_error[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_close_code_on_unhandled_http_error[_uvicorn_factory] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_type_mismatch[_uvicorn_factory-text-send] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_type_mismatch[_uvicorn_factory-text-recv] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_type_mismatch[_uvicorn_factory-data-send] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_type_mismatch[_uvicorn_factory-data-recv] | ERROR tests/asgi/test_asgi_servers.py::TestWebSocket::test_passing_path_params[_uvicorn_factory] | = 3084 passed, 313 skipped, 170 warnings, 35 errors in 36.58s == A full build log on riscv64 is available here: https://buildd.debian.org/status/fetch.php?pkg=python-falcon&arch=riscv64&ver=3.1.1-2%2Bb2&stamp=1713048383&raw=0 Full build logs on amd64 and arm64 are also available on reproducible builds: https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/python-falcon_3.1.1-2.rbuild.log.gz https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/python-falcon_3.1.1-2.rbuild.log.gz Regards Aurelien
Bug#1068959: py-ubjson: FTBFS: testsuite failure: FAILED (failures=2)
Source: py-ubjson Version: 0.16.1-3 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear maintainer, py-ubjson fails to build from source due to errors in the testsuite. >From my build log on amd64: | == | FAIL: test_recursion (test.TestEncodeDecodeFpExt.test_recursion) | -- | Traceback (most recent call last): | File "/<>/.pybuild/cpython3_3.12_ubjson/build/test/test.py", line 476, in test_recursion | with self.assert_raises_regex(RuntimeError, 'recursion'): | AssertionError: RuntimeError not raised | | == | FAIL: test_recursion (test.TestEncodeDecodePlainExt.test_recursion) | -- | Traceback (most recent call last): | File "/<>/.pybuild/cpython3_3.12_ubjson/build/test/test.py", line 476, in test_recursion | with self.assert_raises_regex(RuntimeError, 'recursion'): | AssertionError: RuntimeError not raised | | -- | Ran 116 tests in 2.212s | | FAILED (failures=2) | E: pybuild pybuild:389: test: plugin distutils failed with: exit code=1: cd /<>/.pybuild/cpython3_3.12_ubjson/build; python3.12 -m unittest discover -v test/ A full build log on riscv64 is available here: https://buildd.debian.org/status/fetch.php?pkg=py-ubjson&arch=riscv64&ver=0.16.1-3%2Bb1&stamp=1713019530&raw=0 Full build logs on amd64 and arm64 are also available on reproducible builds: https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/py-ubjson_0.16.1-3.rbuild.log.gz https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/py-ubjson_0.16.1-3.rbuild.log.gz Regards Aurelien
Bug#1068960: python-pybedtools: FTBFS: testsuite error: 14 failed, 491 passed, 2 deselected, 3 xfailed
Source: python-pybedtools
Version: 0.9.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Dear maintainer,
python-pybedtools fails to build from source due to errors in the
testsuite. From my build log on amd64:
| === short test summary info
| FAILED pybedtools/test/test_gzip_support.py::test_gzipped_file_types_are_bed
| FAILED
pybedtools/test/test_gzip_support.py::test_gzipped_files_can_be_intersected
| FAILED
pybedtools/test/test_gzip_support.py::test_gzipped_files_are_iterable_as_normal
| FAILED
pybedtools/test/test_gzip_support.py::test_str_representation_of_gzipped_files_is_the_same_as_normal
| FAILED
pybedtools/test/test_gzip_support.py::test_head_of_gzipped_files_is_the_same_as_normal
| FAILED pybedtools/test/test_gzip_support.py::test_gzipped_output -
FileNotFou...
| FAILED
pybedtools/test/test_gzip_support.py::test_gzipping_is_default_when_extension_is_dot_gz
| FAILED
pybedtools/test/test_gzip_support.py::test_gzipping_can_be_turned_off_even_for_dot_gz
| FAILED pybedtools/test/test_issues.py::test_issue_169 - UnicodeDecodeError:
'...
| FAILED pybedtools/test/test_issues.py::test_issue_196 - OSError: Could not
op...
| FAILED pybedtools/test/test_issues.py::test_issue_180 - OSError: Could not
op...
| FAILED pybedtools/test/test_issues.py::test_issue_181 - OSError: Could not
op...
| FAILED pybedtools/test/test_issues.py::test_issue_258 - gzip.BadGzipFile:
Not...
| FAILED pybedtools/test/test_issues.py::test_issue_343 - UnicodeDecodeError:
'...
| === 14 failed, 491 passed, 2 deselected, 3 xfailed in 9.27s
| E: pybuild pybuild:389: test: plugin distutils failed with: exit code=1: cd
/<>/.pybuild/cpython3_3.11_pybedtools/build; python3.11 -m pytest
-k "not test_chromsizes"
| dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12
3.11" returned exit code 13
| make: *** [debian/rules:30: binary] Error 25
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status
2
A full build log on riscv64 is available here:
https://buildd.debian.org/status/fetch.php?pkg=python-pybedtools&arch=riscv64&ver=0.9.1-1%2Bb2&stamp=1713040255&raw=0
Full build logs on amd64 and arm64 are also available on reproducible
builds:
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/python-pybedtools_0.9.1-1.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/python-pybedtools_0.9.1-1.rbuild.log.gz
Regards
Aurelien
Bug#1068473: closed by Debian FTP Masters (reply to Bas Couwenberg ) (Bug#1068473: fixed in icinga2 2.13.6-2+deb12u1)
Hi Sebastiaan, On 2024-04-09 16:51, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the src:icinga2 package: > > #1068473: icinga2: crashes on startup on ppc64el > > It has been closed by Debian FTP Masters > (reply to Bas Couwenberg ). > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Debian FTP Masters > (reply to Bas Couwenberg > ) by > replying to this email. Thanks a lot for promptly fixing this bug. The ppc64el hosts in the debian infrastructure are now using the icinga2 packages from bookworm-proposed-updates and all works fine. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1066887: ENhance Patch for local-gen
Hi,
On 2024-03-15 16:13, M. Buecher wrote:
> Adding / back to end of the path, so that a locale file is immediately
> found.
> diff --git a/debian/local/usr_sbin/locale-gen
> b/debian/local/usr_sbin/locale-gen
> index 7fa3d772..1711a4f0 100755
> --- a/debian/local/usr_sbin/locale-gen
> +++ b/debian/local/usr_sbin/locale-gen
> @@ -23,6 +23,12 @@ is_entry_ok() {
> fi
> }
>
> +if [ -z "${I18NPATH:-}" ]; then
> + if [ -d "${USER_LOCALES}" ]; then
> +I18NPATH="${USER_LOCALES%%/locales*}/"
> + fi
> +fi
> +
> echo "Generating locales (this might take a while)..."
> while read -r locale charset; do
> if [ -z "$locale" ] || [ "${locale#\#}" != "$locale" ]; then continue;
> fi
> @@ -46,7 +52,7 @@ while read -r locale charset; do
> input="$USER_LOCALES/$input"
> fi
> fi
> - localedef -i "$input" -c -f "$charset" -A
> /usr/share/locale/locale.alias "$locale" || :
> + I18NPATH="${I18NPATH}" localedef -i "$input" -c -f "$charset" -A
> /usr/share/locale/locale.alias "$locale" || :
> echo " done"
> done < "$LOCALEGEN"
> echo "Generation complete."
Thanks for your bug report and for even proposing a patch which looks
good to me.
That said as I18NPATH could actually contains a list of directory, I
wonder if the behaviour would be more consistent if the user locales
directory is always prepended to I18NPATH if it exists. What do you
think?
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
Bug#1067505: libc-bin: iconv: misleading error "illegal input sequence"
Hi, On 2024-03-22 16:42, Frank Heckenbach wrote: > - I tried to report it upstream, but that's also broken. According to > https://www.gnu.org/software/libc/manual/html_node/Reporting-Bugs.html, bugs > should be reported at https://www.gnu.org/software/libc/bugs.html, but this > page redirects to https://www.gnu.org/savannah-checkouts/gnu/libc/index.html > which does not mention reporting bugs. Please see this page for reporting bug upstream: https://sourceware.org/glibc/bugs.html Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t
Hi,
On 2024-04-09 07:56, Helmut Grohne wrote:
> Hi Aurelien,
>
> On Mon, Apr 08, 2024 at 11:24:40PM +0200, Aurelien Jarno wrote:
> > Thanks for you analysis and your patch. In short your proposal is to
> > extend the initial patch from Steve to fully hide the fact that the
> > compiler default to -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64.
> >
> > This indeed works and fixes the FTBFS. However it seems that, at least
> > for some of the issues, it just hides them. For instance the wrong type
> > for timeval.tv_usec, reported by Simon upstream [1], was detected by the
> > conformance tests. Quoting utmpx.h/conform.out:
>
> I think this needs a more nuanced look. From the comments in the
> conformance test suite, it is evident that it expects to be run without
> _FILE_OFFSET_BITS and _TIME_BITS. Many of the symbols it requires to
> exist only exist when these macros are unset. The conformance test suite
> has a comment saying that it should be testing the case where
> _FILE_OFFSET_BITS is defined, but it currently does not provide
> expectations for that case.
>
> Before we can reasonably run the conformance test suite with these
> macros set (and really, the test suite should be in control of these
> macros), we cannot reasonably use it with them set. Let us now imagine a
> future where the conformance test suite has been extended to provide
> expectations (which in lots of cases means that *64 symbols disappear
> when -D_FILE_OFFSET_BITS=64). Then what still remains is Simon's issue:
>
> > | /tmp/tmp98wzaavx/test.c:4:35: error: conflicting types for ‘b2_10’; have
> > ‘__suseconds64_t’ {aka ‘long long int’}
> > | 4 | extern __typeof__ (a2_10.tv_usec) b2_10;
> > | | ^
> > | /tmp/tmp98wzaavx/test.c:3:20: note: previous declaration of ‘b2_10’ with
> > type ‘suseconds_t’ {aka ‘long int’}
> > | 3 | extern suseconds_t b2_10;
> > | |^
> > | FAIL: Type of member tv_usec
>
> Indeed, this is not something that can easily be fixed and where
> upstream is still debating on what the correct solution should be. It
> also is an issue that existed for a long time. If you head over to a
> bookworm glibc and enable -D_TIME_BITS=64 there, you'll also notice that
> tv_usec and suseconds_t have different sizes. So yes, this is a bug, but
> it is not one that is directly related to Debian changing the default.
> We merely increased the visibility of this problem that existed earlier
> already.
I agree that this is an existing issue. My point there was mostly that
your solution is just hiding a real issue that is found by the
testsuite, and basically the testsuite runs in a different configuration
than the one used on the system. We might just miss new issues for new
upstream versions, which is not something very comfortable for a base
library.
> Given that
> * the issue is already present in bookworm,
> * there are two mutually exclusive solutions and
> * upstream is still discussing the best solution
> I recommend deferring this aspect.
While the issue is already present in bookworm, it is not visible
because the toolchain has different defaults.
> > And we know it is the reason for the FTBFS of libflorist [2], so should
> > we just ignore that issue anyway?
>
> The libflorist issue likely is a consequence. It arises from
> gnat_to_gnu_field where GNAT verifies that the value (of type
> suseconds_t) to be assigned to a field (tv_usec) has the matching size.
> This is directly based on the POSIX expectation and will be fixed with
> the glibc issue.
>
> How about filing a separate bug with glibc that tracks this POSIX
> divergence and mark the libflorist bug as being blocked by this other
> glibc bug? It can be RC or not, but since it affects bookworm, it won't
> block testing migration.
Yes we can do that. That said I am not sure we can claim the issue
affects bookworm, as again the toolchain does not have the same defaults
and therefore libflorist does not FTBFS in bookworm.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
signature.asc
Description: PGP signature
