Bug#1082532: php-xmlrpc_1.0.0~rc3-8_i386-buildd.changes REJECTED
Source: php-xmlrpc Version: 1.0.0~rc3-8 Severity: serious On 2024-09-21 14:01, Debian FTP Masters wrote: > > > Version check failed: > Your upload included the binary package php-xmlrpc, version 3:1.0.0~rc3-8, > for i386, > however experimental already has version 3:1.0.0~rc3-8. > 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. > At a first glance, it appears that the php-xmlrpc binary package is built for both binary:all and binary:any. signature.asc Description: PGP signature
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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#1070872: marked as pending in glibc
Control: tag -1 pending Hello, Bug #1070872 in glibc reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/glibc-team/glibc/-/commit/cddca4c12be51d67d8f383b2ccf21b6335b61898 debian/patches/any/submitted-static-*.diff: add proposed patches to fix various missing math function in libm.a. Closes: #1070872. (this message was generated automatically) -- Greetings https://bugs.debian.org/1070872
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#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#1069191: marked as pending in glibc
Control: tag -1 pending Hello, Bug #1069191 in glibc reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/glibc-team/glibc/-/commit/994a994014c13b43ffc4768a8969cc44045d7a67 debian/patches/git-updates.diff: update from upstream stable branch: * debian/patches/git-updates.diff: update from upstream stable branch: - Fix fix out-of-bound writes when writing escape sequence in iconv ISO-2022-CN-EXT module (CVE-2024-2961). Closes: #1069191. (this message was generated automatically) -- Greetings https://bugs.debian.org/1069191
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#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#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#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#1068737: marked as pending in glibc
Control: tag -1 pending Hello, Bug #1068737 in glibc reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/glibc-team/glibc/-/commit/e4d86ee27cbefa6fa55f965c15b629170d60f302 debian/debhelper.in/locales.config: revert to the version that has been working for 20+ years. Closes: #1068737. (this message was generated automatically) -- Greetings https://bugs.debian.org/1068737
Bug#1068251: marked as pending in glibc
Control: tag -1 pending Hello, Bug #1068251 in glibc reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/glibc-team/glibc/-/commit/2aeb43031cb6bbcd1978c5329ffee010155c044f debian/rules.d/build.mk: present glibc with a compiler that does not default to -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64, as upstream doesn't support this configuration. This has the consequence of hiding real issues found by the testsuite, but there is a consensus that this is the way to go for now. Thanks to Helmut Grohne for the hint and starting the discussion. Closes: #1068251. (this message was generated automatically) -- Greetings https://bugs.debian.org/1068251
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
Bug#1068251: glibc: FTBFS on 32-bit architectures due to GCC defaulting to 64-bit time_t
Hi Helmut,
On 2024-04-08 22:19, Helmut Grohne wrote:
> Control: tags -1 + patch
>
> Hi Aurelien and Canonical folks,
>
> On Tue, Apr 02, 2024 at 08:53:31PM +0200, Aurelien Jarno wrote:
> > Starting with gcc-12 version 12.3.0-15, -D_TIME_BITS=64 together with
> > -D_FILE_OFFSET_BITS=64 are passed by default on 32-bit architectures
> > except i386.
> >
> > This has been partially fixed in the 2.37-15.1 NMU by adding
> > -U_TIME_BITS to CFLAGS, however it causes failures in the testsuite:
>
> There are two subtleties about -U_TIME_BITS in a moment.
>
> > | +-+
> > | | Encountered regressions that don't match expected failures. |
> > | +-+
> > | FAIL: conform/ISO/stdio.h/linknamespace
>
> The detail for this failure is:
>
> | [initial] fgetpos64
> | [initial] fopen64
> | [initial] freopen64
> | [initial] fsetpos64
>| [initial] tmpfine64
>
> What linknamespace.py wants to tell us here is that it expected
> fgetpos64, but no fgetpos64 was declared. It was not declared, because
> there is no difference between fgetpos and fgetpos64 after defining
> -D_FILE_OFFSET_BITS=64 (which is also in the default compiler flags).
>
> The other failures are of very similar kind, but there also is another
> kind.
>
> > | FAIL: conform/POSIX/sys/stat.h/conform
>
> The detail for this failure contains:
>
> | /tmp/tmpnzda_r9j/test.c:90:35: error: conflicting types for 'b2_8'; have
> '__time64_t' {aka 'long long int'}
> |90 | extern __typeof__ (a2_8.st_atime) b2_8;
> | | ^~~~
> | /tmp/tmpnzda_r9j/test.c:89:17: note: previous declaration of 'b2_8' with
> type '__time_t' {aka 'long int'}
> |89 | extern __time_t b2_8;
> | | ^~~~
>
> Here, it tells us that it expected the st_atime field of struct stat to
> have type __time_t (the 32 bit one), but it really has __time64_t.
>
> Looking at the invocation of linknamespace.py you can see:
>
> | python3 -B linknamespace.py --cc='arm-linux-gnueabihf-gcc-12'
> --flags='-I../include
> -I/build/reproducible-path/glibc-2.37/build-tree/armhf-libc
> -I../sysdeps/unix/sysv/linux/arm/le -I../sysdeps/unix/sysv/linux/arm
> -I../sysdeps/arm/nptl -I../sysdeps/unix/sysv/linux/include
> -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread
> -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv
> -I../sysdeps/unix/arm -I../sysdeps/unix -I../sysdeps/posix
> -I../sysdeps/arm/le/armv7/multiarch -I../sysdeps/arm/armv7/multiarch
> -I../sysdeps/arm/le/armv7 -I../sysdeps/arm/armv7 -I../sysdeps/arm/armv6t2
> -I../sysdeps/arm/armv6 -I../sysdeps/arm/le -I../sysdeps/arm/include
> -I../sysdeps/arm -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32
> -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic
> -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabihf/12/include -isystem
> /build/reproducible-path/glibc-2.37/debian/include -I..' ...
>
> In particular, what you do not see is -U_TIME_BITS inside --flags.
>
> > Ubuntu has just ignored those failures for now, but I am just afraid
> > that if we do the same, nobody will fix them.
>
> Armed with this knowledge, I think we need two changes. For one thing
> debian/sysdeps/linux.mk needs to add -U_FILE_OFFSET_BITS to extra_cflags
> to revert any possible ABI changing effects. For another, the
> conformance tests use independent compiler flags defined in
> conform/Makefile. There, a naive patch seems to be:
>
> -conformtest-cc-flags = -I../include $(+sysdep-includes) $(sysincludes) -I..
> +conformtest-cc-flags = -U_FILE_OFFSET_BITS -U_TIME_BITS -I../include
> $(+sysdep-includes) $(sysincludes) -I..
>
> With these two changes, I am able to successfully build glibc on armhf
> with the conformance test suite passing.
>
> > In addition it means that upstream glibc does not build anymore by
> > default on a 32-bit Debian. Not really a Debian issue, but that is not
> > nice either and should probably be fixed.
>
> I think that latter change may be applicable upstream. Running the
> conformance test suite with either _FILE_OFFSET_BITS or _TIME_BITS set
> is not expected nor supported. This is partially evident from
> conform/linknamespace.py in a comment:
>
> | # * Header inclusions should be compiled several times with
> | # different options such as -O2, -D_FORTIFY_SOURCE and
> | # -D_FILE_OFFSET_BITS=64 to find out what symbols are
Bug#1068473: icinga2: crashes on startup on ppc64el
Hi, On 2024-04-06 14:17, Sebastiaan Couwenberg wrote: > On 4/6/24 1:29 PM, Aurelien Jarno wrote: > > On 2024-04-06 08:01, Sebastiaan Couwenberg wrote: > > > On 4/5/24 9:51 PM, Aurelien Jarno wrote: > > > > For Bookworm given we can not fix the compiler easily, I propose to just > > > > build icinga2 with -O1 on ppc64el. If you are fine with that option, I > > > > can take care of proposing a patch and submitting it to the stable > > > > release team. > > > > > > A patch for this is very welcome. How do you propose to implement that? > > > Something like this maybe? > > > > > > --- a/debian/rules > > > +++ b/debian/rules > > > @@ -9,6 +9,11 @@ include /usr/share/dpkg/architecture.mk > > > > > >export CTEST_OUTPUT_ON_FAILURE=1 > > > > > > +ifneq (,$(filter $(DEB_HOST_ARCH), ppc64el)) > > > + export DEB_CXXFLAGS_STRIP = -O2 > > > + export DEB_CXXFLAGS_MAINT_APPEND = -O1 > > > +endif > > > + > > >ifneq (,$(filter $(DEB_HOST_ARCH), armel mips mipsel powerpc)) > > > export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic > > > -Wl,--as-needed > > >endif > > > > Yes, something like that works. I even tested without the > > DEB_CXXFLAGS_STRIP, gcc is smart enough to just take the last flag, so > > -O1. > > > > Also it seems that your diff applies to the Trixie/Sid version, while it > > should be applied to Bookworm instead. > > Correct, I did not actually prepare a bookworm branch as you offered to take > care of that. > > Since it's not that much work, I did that now: > > > https://salsa.debian.org/nagios-team/icinga2/-/commits/bookworm?ref_type=heads > > If you can confirm that those changes fix the issue, I can also fix the > bookworm-pu bugreport, or you can do that if you want. Thanks a lot for preparing that. I have just tested it and I confirm it fixes the problem, icinga2 is working nicely with this change. As the maintainer, I would be happy if you send the bookworm-pu bugreport, but in case you lack time or for other reasons, do not hesitate to ask it, and I will do it. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1068473: icinga2: crashes on startup on ppc64el
On 2024-04-06 08:01, Sebastiaan Couwenberg wrote: > On 4/5/24 9:51 PM, Aurelien Jarno wrote: > > For Bookworm given we can not fix the compiler easily, I propose to just > > build icinga2 with -O1 on ppc64el. If you are fine with that option, I > > can take care of proposing a patch and submitting it to the stable > > release team. > > A patch for this is very welcome. How do you propose to implement that? > Something like this maybe? > > --- a/debian/rules > +++ b/debian/rules > @@ -9,6 +9,11 @@ include /usr/share/dpkg/architecture.mk > > export CTEST_OUTPUT_ON_FAILURE=1 > > +ifneq (,$(filter $(DEB_HOST_ARCH), ppc64el)) > + export DEB_CXXFLAGS_STRIP = -O2 > + export DEB_CXXFLAGS_MAINT_APPEND = -O1 > +endif > + > ifneq (,$(filter $(DEB_HOST_ARCH), armel mips mipsel powerpc)) > export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic > -Wl,--as-needed > endif Yes, something like that works. I even tested without the DEB_CXXFLAGS_STRIP, gcc is smart enough to just take the last flag, so -O1. Also it seems that your diff applies to the Trixie/Sid version, while it should be applied to Bookworm instead. > Note that we ignore test failures on ppc64el which might have caught this > issue. I don't think so. Tests are not ignored for Bookworm and haven't caught the issue. OTOH they are ignored for Trixie/Sid, while this version works fine. > Upstream doesn't care about those architectures, so we're on our own > to resolve issues on architectures other than amd64/i386/arm64. Pretty much > all packages I maintain don't have actual users on non-amd64 architectures, > so I don't consider it worth the effort to ask the porters for help, they > should spend their time on packages that are actually used. With DSA's use > of icinga2 on porterboxes it's the exception to the norm. Yes, I agree that the upstream situation is not nice. I personally try to get things fixed [1], but it went nowhere. And the issue was not really architecture specific, just that icinga2 testsuite doesn't support page sizes bigger than 4K... Regards Aurelien [1] https://github.com/Icinga/icinga2/issues/9954#issuecomment-1875209616 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1068473: icinga2: crashes on startup on ppc64el
Source: icinga2
Version: 2.13.6-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: d...@debian.org
Control: fixed -1 icinga2/2.14.2-1
Dear maintainer,
DSA has issues running icinga2 on ppc64el on Bookworm, it fails with a
segmentation fault just after startup:
| × icinga2.service - Icinga host/service/network monitoring system
| Loaded: loaded (/lib/systemd/system/icinga2.service; enabled; preset:
enabled)
| Active: failed (Result: exit-code) since Thu 2024-04-04 20:55:13 UTC;
3min 57s ago
|Duration: 1.209s
|Docs: https://icinga.com/docs/icinga2/latest/
| Process: 356368 ExecStartPre=/usr/lib/icinga2/prepare-dirs
/usr/lib/icinga2/icinga2 (code=exited, status=0/SUCCESS)
| Process: 356373 ExecStart=/usr/sbin/icinga2 daemon --close-stdio -e
${ICINGA2_ERROR_LOG} (code=exited, status=139)
|Main PID: 356373 (code=exited, status=139)
| Status: "Startup finished."
| CPU: 473ms
|
| Apr 04 20:55:12 platti icinga2[356415]: [2024-04-04 20:55:12 +]
information/ConfigItem: Instantiated 1 IcingaApplication.
| Apr 04 20:55:12 platti icinga2[356415]: [2024-04-04 20:55:12 +]
information/ConfigItem: Instantiated 2 Endpoints.
| Apr 04 20:55:12 platti icinga2[356415]: [2024-04-04 20:55:12 +]
information/ConfigItem: Instantiated 1 FileLogger.
| Apr 04 20:55:12 platti icinga2[356415]: [2024-04-04 20:55:12 +]
information/ConfigItem: Instantiated 249 CheckCommands.
| Apr 04 20:55:12 platti icinga2[356415]: [2024-04-04 20:55:12 +]
information/ConfigItem: Instantiated 1 ApiListener.
| Apr 04 20:55:12 platti icinga2[356415]: [2024-04-04 20:55:12 +]
information/ScriptGlobal: Dumping variables to file
'/var/cache/icinga2/icinga2.vars'
| Apr 04 20:55:12 platti systemd[1]: Started icinga2.service - Icinga
host/service/network monitoring system.
| Apr 04 20:55:12 platti icinga2[356373]: [2024-04-04 20:55:12 +]
information/cli: Closing console log.
| Apr 04 20:55:13 platti systemd[1]: icinga2.service: Main process exited,
code=exited, status=139/n/a
| Apr 04 20:55:13 platti systemd[1]: icinga2.service: Failed with result
'exit-code'.
I have been able to obtain a backtrace:
| (gdb) bt full
| #0 0x000127d44850 in icinga::JsonRpcConnection::CheckLiveness
(this=this@entry=0x0, yc=...) at ./lib/remote/jsonrpcconnection.cpp:344
| ec = {val_ = 0, failed_ = false, cat_ = 0x0}
| #1 0x000127d44f04 in operator() (__closure=0x7fff7c002620, yc=...) at
./lib/remote/jsonrpcconnection.cpp:58
| keepAlive = {px = 0x0}
| this = 0x0
| keepAlive =
| this =
| #2 operator() (__closure=__closure@entry=0x7fff7c002620, yc=...) at
./lib/base/io-engine.hpp:106
| f = {__this = 0x0, __keepAlive = {px = 0x0}}
| #3 0x000127d521bc in
boost::asio::detail::coro_entry_point,
icinga::IoEngine::SpawnCoroutine
>(boost::asio::io_context::strand&,
icinga::JsonRpcConnection::Start()::)::
>::operator() (
| ca=..., this=) at
/usr/include/boost/asio/impl/spawn.hpp:355
| data =
| yield = {coro_ =
std::weak_ptr> (use count 1, weak count
5) = {get() = 0x7fff7c0c3640}, ca_ = @0x7fff7c103488,
| handler_ = {> = {},
> = {}, > = {}, > = {executor_ = {service_ =
@0x7fff94003150,
| impl_ = 0x7fff7c002040}, target_ = 0x127d70760
}, }, ec_ = 0x0}
| data =
| yield =
| #4
boost::coroutines::detail::push_coroutine_object,
void, boost::asio::detail::coro_entry_point,
icinga::IoEngine::SpawnCoroutine
>(boost::asio::io_context::strand&,
icinga::JsonRpcConnection::Start()::)::
>&,
boost::coroutines::basic_standard_stack_allocator
>::run (this=0x7fff7c1035c0)
| at /usr/include/boost/coroutine/detail/push_coroutine_object.hpp:302
| b = {> =
{ = { = {}, },
| _vptr.pull_coroutine_impl = 0x12884b938 +16>, flags_ = 0,
except_ = {ptr_ = {px = 0x0, pn = {pi_ = 0x0}}}, caller_ = 0x7fff7c103618,
| callee_ = 0x7fff7c1035f0}, }
| push_coro = {impl_ = 0x7fff7c103490}
| to = {do_unwind = 64, coro = 0x7fff7c103670}
| __PRETTY_FUNCTION__ =
| b =
| push_coro =
| to =
| #5
boost::coroutines::detail::trampoline_push_void,
void, boost::asio::detail::coro_entry_point,
icinga::IoEngine::SpawnCoroutine
>(boost::asio::io_context::strand&,
icinga::JsonRpcConnection::Start()::)::
>&,
boost::coroutines::basic_standard_stack_allocator
> >(boost::context::detail::transfer_t) (t=...) at
/usr/include/boost/coroutine/detail/trampoline_push.hpp:70
| __PRETTY_FUNCTION__ = "void
boost::coroutines::detail::trampoline_push_void(boost::context::detail::transfer_t)
[with Coro = push_coroutine_object,
void, boost::asio::detail::coro_ent"...
| data =
| param =
| coro = 0x7fff7c1035c0
| #6 0x7fffa9670f0c in make_fcontext () from
/lib/powerpc64le-linux-gnu/libboost_context.so.1.74.0
| No symbol table info available.
It is not exactly cle
Bug#1068188: pthread_cond_init.3.gz: conflict with manpages-dev 6.7-1
control: found -1 glibc/2.37-15.1 Hi, On 2024-04-01 16:23, Alejandro Colomar wrote: > Package: glibc-doc > Version: 2.38-6 > Severity: serious > Justification: Policy 7.4 > X-Debbugs-Cc: a...@kernel.org, mar...@debian.org > > Dear Maintainer, > > The Linux man-pages project has recently added the pthread_*(3) manual > pages that were provided by glibc-doc. The first upstream version of > the Linux man-pages that includes these pages is man-pages-6.06. Here's > what was added: Thanks, that sounds great that we can finally get rid out of those in the debian package. > $ git diff --stat b06cd070f..128a3ae35 >man3/pthread_cond_init.3| 264 >man3/pthread_condattr_init.3| 48 >man3/pthread_key_create.3 | 178 + >man3/pthread_mutex_init.3 | 241 ++ >man3/pthread_mutexattr_setkind_np.3 | 52 >man3/pthread_once.3 | 44 >6 files changed, 827 insertions(+) > > Debian's manpages-dev_6.7-1_all.deb has been the first package since > that happened, and I've noticed that dpkg(1) (via apt-get(8)) refuses to > upgrade manpages-dev due to a conflict with glibc-doc. > > $ sudo apt-get upgrade -V; > [...] > Do you want to continue? [Y/n] y > Reading changelogs... Done > (Reading database ... 404853 files and directories currently installed.) > Preparing to unpack .../manpages-dev_6.7-1_all.deb ... > Unpacking manpages-dev (6.7-1) over (6.05.01-1) ... > dpkg: error processing archive > /var/cache/apt/archives/manpages-dev_6.7-1_all.deb (--unpack): >trying to overwrite '/usr/share/man/man3/pthread_cond_init.3.gz', > which is also in package glibc-doc 2.38-6 > Errors were encountered while processing: >/var/cache/apt/archives/manpages-dev_6.7-1_all.deb > needrestart is being skipped since dpkg has failed > E: Sub-process /usr/bin/dpkg returned an error code (1) I think this is actually not specific to the experimental version, those manpages are also in the unstable version. > Please, remove from glibc-doc those manual pages that conflict with > manpages-dev. Noted. However following the time_t transition, the glibc package does not build anymore on 32-bit architectures (i have just opened #1059937 to make people aware of that), so uploading a new glibc now is probably not the best idea. 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
Source: glibc Version: 2.37-15.1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: debian-...@lists.debian.org Starting with gcc-12 version 12.3.0-15, -D_TIME_BITS=64 together with -D_FILE_OFFSET_BITS=64 are passed by default on 32-bit architectures except i386. This has been partially fixed in the 2.37-15.1 NMU by adding -U_TIME_BITS to CFLAGS, however it causes failures in the testsuite: | +-+ | | Encountered regressions that don't match expected failures. | | +-+ | FAIL: conform/ISO/stdio.h/linknamespace | FAIL: conform/ISO11/stdio.h/linknamespace | FAIL: conform/ISO99/stdio.h/linknamespace | FAIL: conform/POSIX/aio.h/linknamespace | FAIL: conform/POSIX/dirent.h/linknamespace | FAIL: conform/POSIX/fcntl.h/conform | FAIL: conform/POSIX/fcntl.h/linknamespace | FAIL: conform/POSIX/glob.h/conform | FAIL: conform/POSIX/mqueue.h/conform | FAIL: conform/POSIX/mqueue.h/linknamespace | FAIL: conform/POSIX/stdio.h/linknamespace | FAIL: conform/POSIX/sys/mman.h/linknamespace | FAIL: conform/POSIX/sys/stat.h/conform | FAIL: conform/POSIX/unistd.h/conform | FAIL: conform/POSIX/unistd.h/linknamespace | FAIL: conform/POSIX/utime.h/conform | FAIL: conform/POSIX2008/aio.h/linknamespace | FAIL: conform/POSIX2008/dirent.h/linknamespace | FAIL: conform/POSIX2008/fcntl.h/conform | FAIL: conform/POSIX2008/fcntl.h/linknamespace | FAIL: conform/POSIX2008/glob.h/conform | FAIL: conform/POSIX2008/mqueue.h/conform | FAIL: conform/POSIX2008/mqueue.h/linknamespace | FAIL: conform/POSIX2008/signal.h/conform | FAIL: conform/POSIX2008/stdio.h/linknamespace | FAIL: conform/POSIX2008/stdlib.h/linknamespace | FAIL: conform/POSIX2008/sys/mman.h/linknamespace | FAIL: conform/POSIX2008/sys/select.h/conform | FAIL: conform/POSIX2008/sys/stat.h/conform | FAIL: conform/POSIX2008/sys/statvfs.h/linknamespace | FAIL: conform/POSIX2008/unistd.h/linknamespace | FAIL: conform/UNIX98/aio.h/linknamespace | FAIL: conform/UNIX98/dirent.h/linknamespace | FAIL: conform/UNIX98/fcntl.h/conform | FAIL: conform/UNIX98/fcntl.h/linknamespace | FAIL: conform/UNIX98/glob.h/conform | FAIL: conform/UNIX98/mqueue.h/conform | FAIL: conform/UNIX98/mqueue.h/linknamespace | FAIL: conform/UNIX98/stdio.h/linknamespace | FAIL: conform/UNIX98/stdlib.h/linknamespace | FAIL: conform/UNIX98/sys/mman.h/linknamespace | FAIL: conform/UNIX98/sys/resource.h/linknamespace | FAIL: conform/UNIX98/sys/statvfs.h/linknamespace | FAIL: conform/UNIX98/sys/time.h/conform | FAIL: conform/UNIX98/unistd.h/linknamespace | FAIL: conform/UNIX98/utmpx.h/conform | FAIL: conform/XOPEN2K/aio.h/linknamespace | FAIL: conform/XOPEN2K/dirent.h/linknamespace | FAIL: conform/XOPEN2K/fcntl.h/conform | FAIL: conform/XOPEN2K/fcntl.h/linknamespace | FAIL: conform/XOPEN2K/glob.h/conform | FAIL: conform/XOPEN2K/mqueue.h/conform | FAIL: conform/XOPEN2K/mqueue.h/linknamespace | FAIL: conform/XOPEN2K/stdio.h/linknamespace | FAIL: conform/XOPEN2K/stdlib.h/linknamespace | FAIL: conform/XOPEN2K/sys/mman.h/linknamespace | FAIL: conform/XOPEN2K/sys/resource.h/linknamespace | FAIL: conform/XOPEN2K/sys/select.h/conform | FAIL: conform/XOPEN2K/sys/statvfs.h/linknamespace | FAIL: conform/XOPEN2K/sys/time.h/conform | FAIL: conform/XOPEN2K/unistd.h/linknamespace | FAIL: conform/XOPEN2K/utmpx.h/conform | FAIL: conform/XOPEN2K8/aio.h/linknamespace | FAIL: conform/XOPEN2K8/dirent.h/linknamespace | FAIL: conform/XOPEN2K8/fcntl.h/conform | FAIL: conform/XOPEN2K8/fcntl.h/linknamespace | FAIL: conform/XOPEN2K8/ftw.h/conform | FAIL: conform/XOPEN2K8/glob.h/conform | FAIL: conform/XOPEN2K8/mqueue.h/conform | FAIL: conform/XOPEN2K8/mqueue.h/linknamespace | FAIL: conform/XOPEN2K8/signal.h/conform | FAIL: conform/XOPEN2K8/stdio.h/linknamespace | FAIL: conform/XOPEN2K8/stdlib.h/linknamespace | FAIL: conform/XOPEN2K8/sys/mman.h/linknamespace | FAIL: conform/XOPEN2K8/sys/resource.h/linknamespace | FAIL: conform/XOPEN2K8/sys/select.h/conform | FAIL: conform/XOPEN2K8/sys/stat.h/conform | FAIL: conform/XOPEN2K8/sys/statvfs.h/linknamespace | FAIL: conform/XOPEN2K8/sys/time.h/conform | FAIL: conform/XOPEN2K8/unistd.h/linknamespace | FAIL: conform/XOPEN2K8/utmpx.h/conform | FAIL: conform/XPG4/dirent.h/linknamespace | FAIL: conform/XPG4/fcntl.h/conform | FAIL: conform/XPG4/fcntl.h/linknamespace | FAIL: conform/XPG4/glob.h/conform | FAIL: conform/XPG4/stdio.h/linknamespace | FAIL: conform/XPG4/unistd.h/linknamespace | FAIL: conform/XPG42/dirent.h/linknamespace | FAIL: conform/XPG42/fcntl.h/conform | FAIL: conform/XPG42/fcntl.h/linknamespace | FAIL: conform/XPG42/glob.h/conform | FAIL: conform/XPG42/stdio.h/linknamespace | FAIL: conform/XPG42/stdlib.h/linknamespace | FAIL: conform/XPG42/sys/mman.h/linknamespace | FAIL: conform/XPG42/sys/resource.h/linknamespace | FAIL: conform/XPG42/sys/statvfs.h/linknamespace | FAIL: conform/XPG42/s
Bug#1068198: debian-installer-netboot-images: accesses the internet during build
Source: debian-installer-netboot-images Severity: serious Justification: Policy 4.9 X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org Control: affects -1 buildd.debian.org Hi, debian-installer-netboot-images attemps network access during build, although only to the mirrors listed in /etc/apt/sources.list and in a secure way. This is forbidden by Policy 4.9: For packages in the main archive, required targets must not attempt network access, except, via the loopback interface, to services on the build host that have been started by the build. In addition this brings constraints to the build daemons infrastructure. Regards, Aurelien
Bug#1068197: debian-installer: accesses the internet during build
Source: debian-installer Severity: serious Justification: Policy 4.9 X-Debbugs-Cc: d...@debian.org, wb-t...@buildd.debian.org Control: affects -1 buildd.debian.org Hi, debian-installer attemps network access during build, although only to the mirrors listed in /etc/apt/sources.list and in a secure way. This is forbidden by Policy 4.9: For packages in the main archive, required targets must not attempt network access, except, via the loopback interface, to services on the build host that have been started by the build. In addition this brings constraints to the build daemons infrastructure. Regards, Aurelien
Bug#1067711: mrpt: dpkg-gencontrol: warning: can't parse dependency fonts-roboto-fontface (= )
Source: mrpt
Version: 1:2.12.0+ds-1.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Dear maintainer,
mrpt fails to build from source with an error in dpkg-gencontrol. From
my build log on amd64:
| make[1]: Leaving directory '/<>'
|dh_gencontrol -O--buildsystem=pybuild
| dpkg-gencontrol: warning: Depends field of package libmrpt-topography2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-topography2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-topography2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-kinematics2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-kinematics2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-kinematics2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-poses2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-poses2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-poses2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-topography2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-nav2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-nav2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-nav2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-detectors2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-detectors2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-detectors2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-ros1bridge2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-ros1bridge2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-ros1bridge2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-system2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-system2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-system2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-config2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-config2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-config2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-hwdrivers2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-hwdrivers2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-hwdrivers2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-apps2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-apps2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrpt-apps2.12:
substitution variable ${t64:Provides} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-graphslam2.12:
substitution variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package libmrpt-graphslam2.12:
substitution variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package libmrp
Bug#1066444: nacl: FTBFS: ld: cannot find -lnsl: No such file or directory
control: retitle -1 nacl: FTBFS due to -Werror=implicit-function-declaration Hi, On 2024-03-13 13:03, Lucas Nussbaum wrote: > Source: nacl > Version: 20110221-13 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240313 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): [ snip] > > === Tue Mar 12 20:30:43 UTC 2024 === checking -lnsl > > /usr/bin/ld: cannot find -lnsl: No such file or directory > > collect2: error: ld returned 1 exit status The build system of nacl is totally nonstandard and difficult to understand, but it appears that this error is harmless. The real issue behind this FTBFS is the -Werror=implicit-function-declaration introduced by dpkg 1.22.6. Retitling the bug accordingly. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1066403: R packages failing to build with missing -ltirpc are actually an issue in r-base
control: reassign 1066403 r-base-dev control: reassign 1066452 r-base-dev control: reassign 1066455 r-base-dev control: reassign 1066456 r-base-dev control: forcemerge 1066403 1066452 1066455 1066456 control: affects 1066403 rjava control: affects 1066403 rapache control: affects 1066403 littler control: affects 1066403 rpy2 control: retitle 1066403 r-base-dev: missing dependency on libtirpc-dev Hi Dirk, There are 4 r-base packages failing to build in the latest archive rebuild: #1066403 rjava: FTBFS: ld: cannot find -ltirpc: No such file or directory #1066452 rapache: FTBFS: ld: cannot find -ltirpc: No such file or directory #1066455 littler: FTBFS: ld: cannot find -ltirpc: No such file or directory #1066456 rpy2: FTBFS: ld: cannot find -ltirpc: No such file or directory Investigating, it appears that the issue is actually at the r-base level. They try to link with -ltirpc because R tell them to do so: $ R CMD config --ldflags -Wl,--export-dynamic -fopenmp -Wl,-z,relro -L/usr/lib/R/lib -lR -lpcre2-8 -llzma -lbz2 -lz -ltirpc -lrt -ldl -lm -licuuc -licui18n Therefore it seems that r-base-dev is missing a dependency on libtirpc-dev. Sorry for not having noticed that when filling #1065216. Regards Aurelien
Bug#1066422: packages using dcmtk failing to build with missing -lnsl are actually an issue in dcmtk
control: reassign 1066422 libdcmtk-dev control: reassign 1066423 libdcmtk-dev control: forcemerge 1066422 1066423 control: retitle 1066422 libdcmtk-dev: missing dependency on libnsl-dev control: affects 1066422 plastimatch control: affects 1066423 sight Hi, There are 2 packages using dcmtk failing to build in the latest archive rebuild: #1066422 plastimatch: FTBFS: ld: cannot find -lnsl: No such file or directory #1066423 sight: FTBFS: ld.gold: error: cannot find -lnsl Investigating, it appears that the issue is actually at the dcmtk package level. They try to link with -lnsl because dcmtk says so: $ grep nsl /usr/lib/x86_64-linux-gnu/cmake/dcmtk/DCMTKTargets.cmake INTERFACE_LINK_LIBRARIES "DCMTK::config;nsl;pthread;rt" dcmtk actually does not depends on libnsl-dev, but gets this dependency through the libwrap0-dev package. Therefore it seems that libdcmtk-dev is missing a dependency on libnsl-dev. In addition it might be good to add it as a build-dependency of the dcmtk package, to ensure it continues building even if libwrap0-dev drops it at some point. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1066117: FTBFS: missing build-dep on libnsl-dev
Hi, On 2024-03-12 23:22, Preuße, Hilmar wrote: > On 12.03.2024 21:59, Aurelien Jarno wrote: > > Hi Aurelien, > > > 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 proftpd-dfsg to FTBFS in > > sid with: > > > I've seen the issue, but I wasn't sure if I have to do something or if I > have just have to wait until the dep change has been reverted. Let me > know if I should upload a fixed package w/ the BD added. Yes, please upload a package with the extra BD. The time_t transition takes longer than expected, and proftpd-dfsg is part of the transition. Thanks Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1066117: FTBFS: missing build-dep on libnsl-dev
Source: proftpd-dfsg Version: 1.3.8.b+dfsg-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 proftpd-dfsg to FTBFS in sid with: | /bin/bash ../libtool --mode=compile --tag=CC gcc -Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_CONFIG_H -DLINUX -I.. -I../include -I../include -I/usr/include/mariadb/mysql -I/usr/include/mariadb -I/usr/include/postgresql -I/usr/include/mariadb -I/usr/include/mariadb/mysql -I/usr/include/postgresql -Wdate-time -D_FORTIFY_SOURCE=2 -g2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -fno-omit-frame-pointer -fno-strict-aliasing -Werror=implicit-function-declaration -g -O2 -ffile-prefix-map=/<>/modules=. -fstack-protector-strong -Wformat -Werror=format-security -DPR_SHARED_MODULE -c ../modules/mod_wrap2_file.c | libtool: compile: gcc -Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_CONFIG_H -DLINUX -I.. -I../include -I../include -I/usr/include/mariadb/mysql -I/usr/include/mariadb -I/usr/include/postgresql -I/usr/include/mariadb -I/usr/include/mariadb/mysql -I/usr/include/postgresql -Wdate-time -D_FORTIFY_SOURCE=2 -g2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -fno-omit-frame-pointer -fno-strict-aliasing -Werror=implicit-function-declaration -g -O2 -ffile-prefix-map=/<>/modules=. -fstack-protector-strong -Wformat -Werror=format-security -DPR_SHARED_MODULE -c ../modules/mod_wrap2_file.c -fPIC -DPIC -o .libs/mod_wrap2_file.o | gcc -Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_CONFIG_H -DLINUX -I.. -I../include -I../include -I/usr/include/mariadb/mysql -I/usr/include/mariadb -I/usr/include/postgresql -I/usr/include/mariadb -I/usr/include/mariadb/mysql -I/usr/include/postgresql -Wdate-time -D_FORTIFY_SOURCE=2 -g2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -fno-omit-frame-pointer -fno-strict-aliasing -Werror=implicit-function-declaration -g -O2 -ffile-prefix-map=/<>/src=. -fstack-protector-strong -Wformat -Werror=format-security -c trace.c | /bin/bash ../libtool --mode=link --tag=CC gcc -o mod_wrap.la -rpath /usr/lib/proftpd -Wl,-L../lib,-L../lib -Wl,-z,relro -Wl,-z,now -rdynamic -L/usr/lib/i386-linux-gnu/ -L/usr/lib/i386-linux-gnu -Wl,-z,relro -Wl,-z,now -avoid-version -export-dynamic -module -lidn2 -lsodium mod_wrap.lo `cat ../modules/mod_wrap.c | grep '$Libraries:' | sed -e 's/^.*\$Libraries: \(.*\)\\$/\1/'` | libtool: link: gcc -shared .libs/mod_wrap.o -L/usr/lib/i386-linux-gnu/ -L/usr/lib/i386-linux-gnu -lidn2 -lsodium -lwrap -lnsl -Wl,-L../lib -Wl,-L../lib -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-soname -Wl,mod_wrap.so -o .libs/mod_wrap.so | /usr/bin/ld: cannot find -lnsl: No such file or directory | collect2: error: ld returned 1 exit status | make[3]: *** [Makefile:34: mod_wrap.la] Error 1 | make[3]: *** Waiting for unfinished jobs The full build log can be found here: https://buildd.debian.org/status/fetch.php?pkg=proftpd-dfsg&arch=i386&ver=1.3.8.b%2Bdfsg-1%2Bb2&stamp=1710157209&raw=0 This can be fixed by adding an explicit Build-Depends on libnsl-dev. Regards Aurelien
Bug#1065210: fricas: missing build-dep on libtirpc-dev or libtirpc-dev dependency in gcl
Hi, On 2024-03-10 11:20, Camm Maguire wrote: > Greetings! For now I am adding a libnsl-dev dependency to the gcl > package to restore the old behavior. A small fix to the fricas package > will eventually make this obsolete. You probably want to add a libtirpc-dev dependency instead, libnsl-dev is what was only ensuring that libtirpc-dev is installed. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1065816: weston: Dependency neatvnc found: NO found 0.8.0 but need: '< 0.8.0' ; matched: '>= 0.7.0'
Source: weston Version: 13.0.0-4 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear maintainer, weston fails to build in unstable since the upload of neatvnc in version 8.0. From my build log on amd64: | Determining dependency 'neatvnc' with pkg-config executable '/usr/bin/pkg-config' | env[PKG_CONFIG_PATH]: | env[PKG_CONFIG]: /usr/bin/pkg-config | --- | Called: `/usr/bin/pkg-config --modversion neatvnc` -> 0 | stdout: | 0.8.0 | --- | env[PKG_CONFIG_PATH]: | env[PKG_CONFIG]: /usr/bin/pkg-config | --- | Called: `/usr/bin/pkg-config --cflags neatvnc` -> 0 | stdout: | -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/p11-kit-1 -I/usr/include/x86_64-linux-gnu | --- | env[PKG_CONFIG_ALLOW_SYSTEM_LIBS]: 1 | env[PKG_CONFIG_PATH]: | env[PKG_CONFIG]: /usr/bin/pkg-config | --- | Called: `/usr/bin/pkg-config --libs neatvnc` -> 0 | stdout: | -L/usr/lib/x86_64-linux-gnu -lneatvnc | --- | env[PKG_CONFIG_PATH]: | env[PKG_CONFIG]: /usr/bin/pkg-config | --- | Called: `/usr/bin/pkg-config --libs neatvnc` -> 0 | stdout: | -lneatvnc | --- | Dependency neatvnc found: NO found 0.8.0 but need: '< 0.8.0' ; matched: '>= 0.7.0' | CMake binary for host machine is cached as not found | CMake binary for machine host machine not found. Giving up. | Run-time dependency neatvnc found: NO (tried pkgconfig and cmake) | Looking for a fallback subproject for the dependency neatvnc | Automatic wrap-based subproject downloading is disabled | Subproject neatvnc is buildable: NO (disabling) | Dependency neatvnc from subproject neatvnc found: NO (subproject failed to configure) | | ../libweston/backend-vnc/meson.build:8:1: ERROR: Problem encountered: VNC backend requires neatvnc which was not found. Or, you can use '-Dbackend-vnc=false'. | dh_auto_configure: error: cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 meson setup .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=lib/x86_64-linux-gnu -Dpython.bytecompile=-1 -Dbackend-rdp=true -Dbackend-vnc=true -Dscreenshare=true -Dsystemd=true returned exit code 1 | make[1]: *** [debian/rules:18: override_dh_auto_configure] Error 25 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:44: binary] Error 2 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 A full build log is also available here: https://buildd.debian.org/status/fetch.php?pkg=weston&arch=riscv64&ver=13.0.0-4%2Bb2&stamp=1710049432&raw=0 Regards Aurelien
Bug#1065366: python3-stdlib-extensions: uninstallable, depends on unavailable python3:any (>= 3.11.8-1~)
Source: python3-stdlib-extensions Version: 3.12.2-1 Severity: serious Dear maintainer, python3-distutils and python3-lib2to3 version 3.12.2-1 depend on python3:any (>= 3.11.8-1~). However python3 (provided by python3-defaults) is only at version 3.11.6-1, making python3-distutils and python3-lib2to3 uninstallable: | apt install python3-lib2to3 python3-distutils | Reading package lists... Done | Building dependency tree... Done | Reading state information... Done | Some packages could not be installed. This may mean that you have | requested an impossible situation or if you are using the unstable | distribution that some required packages have not yet been created | or been moved out of Incoming. | The following information may help to resolve the situation: | | The following packages have unmet dependencies: | python3-distutils : Depends: python3:any (>= 3.11.8-1~) | python3-lib2to3 : Depends: python3:any (>= 3.11.8-1~) | E: Unable to correct problems, you have held broken packages. Regards Aurelien
Bug#1065330: numpy_1.26.3-2_ppc64el-buildd.changes REJECTED
Source: numpy Version: 1.26.3-2 Severity: serious On 2024-03-02 22:06, Debian FTP Masters wrote: > > > python3-numpy_1.26.3-2_ppc64el.deb: has 876 file(s) with a timestamp too far > in the past: > usr/lib/python3/dist-packages/numpy/LICENSE.txt (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/__init__.cython-30.pxd (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/__init__.pxd (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/__init__.py (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/__init__.pyi (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_core/__init__.py (Thu > Jan 1 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_core/_dtype.py > (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_core/_dtype_ctypes.py (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_core/_internal.py (Thu > Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_core/_multiarray_umath.py (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_core/multiarray.py (Thu > Jan 1 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_core/umath.py > (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_distributor_init.py (Thu Jan 1 00:00:00 > 1970) usr/lib/python3/dist-packages/numpy/_globals.py (Thu Jan 1 00:00:00 > 1970) usr/lib/python3/dist-packages/numpy/_pyinstaller/__init__.py (Thu Jan > 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_pyinstaller/hook-numpy.py (Thu Jan 1 > 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_pyinstaller/pyinstaller-smoke.py (Thu > Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_pyinstaller/test_pyinstaller.py (Thu Jan > 1 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_pytesttester.py (Thu > Jan 1 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_pytesttester.pyi > (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_typing/__init__.py (Thu Jan 1 00:00:00 > 1970) usr/lib/python3/dist-packages/numpy/_typing/_add_docstring.py (Thu Jan > 1 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_typing/_array_like.py > (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_typing/_callable.pyi (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_typing/_char_codes.py > (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_typing/_dtype_like.py (Thu Jan 1 > 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_typing/_extended_precision.py (Thu Jan > 1 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_typing/_nbit.py (Thu > Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_typing/_nested_sequence.py (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_typing/_scalars.py (Thu > Jan 1 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_typing/_shape.py > (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_typing/_ufunc.pyi (Thu Jan 1 00:00:00 > 1970) usr/lib/python3/dist-packages/numpy/_typing/setup.py (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_utils/__init__.py (Thu > Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/_utils/_convertions.py (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_utils/_inspect.py (Thu > Jan 1 00:00:00 1970) usr/lib/python3/dist-packages/numpy/_utils/_pep440.py > (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/__init__.py (Thu Jan 1 > 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_array_object.py (Thu Jan 1 > 00:00:00 1970) usr/lib/python3/dist-packages/numpy/array_api/_constants.py > (Thu Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_creation_functions.py (Thu Jan > 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_data_type_functions.py (Thu > Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_dtypes.py (Thu Jan 1 00:00:00 > 1970) > usr/lib/python3/dist-packages/numpy/array_api/_elementwise_functions.py (Thu > Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_indexing_functions.py (Thu Jan > 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_manipulation_functions.py (Thu > Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_searching_functions.py (Thu > Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_set_functions.py (Thu Jan 1 > 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_sorting_functions.py (Thu Jan > 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_statistical_functions.py (Thu > Jan 1 00:00:00 1970) > usr/lib/python3/dist-packages/numpy/array_api/_typing.py (Thu Jan 1 00:00:00 > 1970) usr/lib/python3/dist-packages/numpy/array_api/_utility_functions.py > (Thu Jan 1 00:00:00 1970) > usr/lib/python3/d
Bug#1065290: libhdf4: missing build-dep on libtirpc-dev
Source: libhdf4
Version: 4.2.16-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-gl...@lists.debian.org
Usertags: libtirpc-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, 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 libhdf4 to
FTBFS in sid with:
| dh_auto_configure --sourcedirectory=HDF4 \
| --builddirectory=debian/build-hdf4 \
| -- --prefix=/usr \
| --includedir=/usr/include/hdf \
| --libdir=/usr/lib \
| --enable-shared \
| --enable-fortran \
| --with-szlib=yes \
| F77="gfortran" CC="gcc" CXX="g++" \
| CFLAGS="-g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2
-I/usr/include/tirpc/" LDFLAGS="-Wl,-z,relro -Wl,-z,now -ltirpc"
| cd debian/build-hdf4 && ../../HDF4.2.16/configure
--build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include
--mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc
--localstatedir=/var --disable-option-checking --disable-silent-rules
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run
--disable-maintainer-mode --disable-dependency-tracking --prefix=/usr
--includedir=/usr/include/hdf --libdir=/usr/lib --enable-shared
--enable-fortran --with-szlib=yes F77=gfortran CC=gcc CXX=g\+\+ "CFLAGS=-g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
-Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include/tirpc/" "LDFLAGS=-Wl,-z,relro
-Wl,-z,now -ltirpc"
| checking for a BSD-compatible install... /usr/bin/install -c
| checking whether build environment is sane... yes
| checking for a race-free mkdir -p... /usr/bin/mkdir -p
| checking for gawk... no
| checking for mawk... mawk
| checking whether make sets $(MAKE)... yes
| checking whether make supports nested variables... yes
| checking whether make supports nested variables... (cached) yes
| checking whether to enable maintainer-specific portions of Makefiles... no
| checking shell variables initial values... done
| checking build system type... x86_64-pc-linux-gnu
| checking host system type... x86_64-pc-linux-gnu
| checking if basename works... yes
| checking if xargs works... yes
| checking for config x86_64-pc-linux-gnu... no
| checking for config x86_64-pc-linux-gnu... no
| checking for config pc-linux-gnu... no
| checking for config pc-linux-gnu... no
| checking for config x86_64-linux-gnu... no
| checking for config x86_64-linux-gnu... no
| checking for config x86_64-pc... no
| checking for config linux-gnu... found
| compiler 'gcc' is GNU gcc-13.2.0
| gfortran: error: unrecognized command-line option '-V'
| gfortran: fatal error: no input files
| compilation terminated.
| ../../HDF4.2.16/config/gnu-fflags: line 66: test: -ge: unary operator expected
| checking whether make sets $(MAKE)... (cached) yes
| checking for gcc... gcc
| checking whether the C compiler works... no
| configure: error: in `/<>/debian/build-hdf4':
| configure: error: C compiler cannot create executables
| See `config.log' for more details
| cd debian/build-hdf4 && tail -v -n \+0 config.log
| ==> config.log <==
| This file contains any messages produced by compilers while
| running configure, to aid debugging if configure makes a mistake.
...
| configure:4337: checking whether the C compiler works
| configure:4359: gcc -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2
-I/usr/include/tirpc/ -std=c99 -Wall -Wcast-qual -Wconversion -Wextra
-Wfloat-equal -Wformat=2 -Winit-self -Winvalid-pch -Wmissing-include-dirs
-Wshadow -Wundef -Wwrite-strings -pedantic -Wno-c++-compat
-Wno-error=implicit-function-declaration -Wdate-time -D_FORTIFY_SOURCE=2
-I/usr/include/tirpc/ -Wl,-z,relro -Wl,-z,now -ltirpc conftest.c >&5
| cc1: warning: /usr/include/tirpc/: No such file or directory
[-Wmissing-include-dirs]
| cc1: warning: /usr/include/tirpc/: No such file or directory
[-Wmissing-include-dirs]
| /usr/bin/ld: cannot find -ltirpc: No such file or directory
| collect2: error: ld returned 1 exit status
| configure:4363: $? = 1
| configure:4403: result: no
| configure: failed program was:
| | /* confdefs.h */
| | #define PACKAGE_NAME "HDF"
| | #define PACKAGE_TARNAME "hdf"
| | #define PACKAGE_VERSION "4.2.16"
| | #define PACKAGE_STRING "HDF 4.2.16"
| | #define PACKAGE_BUGRE
Bug#1065289: mysql-8.0: missing build-dep on libtirpc-dev
Source: mysql-8.0 Version: 8.0.36-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-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, 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 mysql-8.0 to FTBFS in sid with: | -- MECAB_INCLUDE_DIR = /usr/include | -- MECAB_LIBRARY = /usr/lib/x86_64-linux-gnu/libmecab.so | -- Found PkgConfig: /bin/pkg-config (found version "1.8.1") | -- Checking for module 'libtirpc' | -- Package 'libtirpc', required by 'virtual:world', not found | CMake Warning at cmake/rpc.cmake:40 (MESSAGE): | Cannot find RPC development libraries. You need to install the required | packages: | | Debian/Ubuntu: apt install libtirpc-dev | RedHat/Fedora/Oracle Linux: yum install libtirpc-devel | SuSE: zypper install glibc-devel | | Call Stack (most recent call first): | cmake/rpc.cmake:96 (WARN_MISSING_SYSTEM_TIRPC) | plugin/group_replication/libmysqlgcs/cmake/configure.cmake:34 (MYSQL_CHECK_RPC) | plugin/group_replication/libmysqlgcs/CMakeLists.txt:31 (INCLUDE) | | | CMake Error at cmake/rpc.cmake:97 (MESSAGE): | Could not find rpc/rpc.h in /usr/include or /usr/include/tirpc | Call Stack (most recent call first): | plugin/group_replication/libmysqlgcs/cmake/configure.cmake:34 (MYSQL_CHECK_RPC) | plugin/group_replication/libmysqlgcs/CMakeLists.txt:31 (INCLUDE) | | | -- Configuring incomplete, errors occurred! | make[1]: *** [debian/rules:80: configure-stamp] Error 1 | make[1]: Leaving directory '/home/aurel32/work/glibc/libnsl/packages/mysql-8.0-8.0.36' | make: *** [debian/rules:230: build-arch] Error 2 | dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 This can 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. Regards Aurelien
Bug#1065283: lsof: recent libc6-dev change causes the RPC support to be dropped
Package: lsof Version: 4.95.0-1 Severity: serious User: debian-gl...@lists.debian.org Usertags: libtirpc-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, 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 the RPC support in lsof to be dropped, I am not sure it is something to care about. Therefore please either: - Add libtirpc-dev as build dependency - Disable the RPC support explicitly so that this feature does not depend on the packages installed on the system. 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. Regards Aurelien
Bug#1065282: dsniff: missing build-dep on libtirpc-dev
Source: dsniff
Version: 2.4b1+debian-31
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-gl...@lists.debian.org
Usertags: libtirpc-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, 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 dsniff to
FTBFS in sid with:
|dh_auto_configure
| ./configure --build=x86_64-linux-gnu --prefix=/usr
--includedir=\${prefix}/include --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-option-checking --disable-silent-rules
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run
--disable-maintainer-mode --disable-dependency-tracking
| checking for gcc... gcc
| checking whether the C compiler works... no
| configure: error: in `/<>':
| configure: error: C compiler cannot create executables
| See `config.log' for more details
| tail -v -n \+0 config.log
| ==> config.log <==
| This file contains any messages produced by compilers while
| running configure, to aid debugging if configure makes a mistake.
...
| configure:3051: checking whether the C compiler works
| configure:3073: gcc -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -fcf-protection -I/usr/include/tirpc/ -Wdate-time
-D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -ltirpc conftest.c >&5
| /usr/bin/ld: cannot find -ltirpc: No such file or directory
| collect2: error: ld returned 1 exit status
| configure:3077: $? = 1
| configure:3117: result: no
| configure: failed program was:
| | /* confdefs.h */
| | #define PACKAGE_NAME ""
| | #define PACKAGE_TARNAME ""
| | #define PACKAGE_VERSION ""
| | #define PACKAGE_STRING ""
| | #define PACKAGE_BUGREPORT ""
| | #define PACKAGE_URL ""
| | /* end confdefs.h. */
| |
| | int
| | main (void)
| | {
| |
| | ;
| | return 0;
| | }
| configure:3122: error: in `/<>':
| configure:3124: error: C compiler cannot create executables
| See `config.log' for more details
This can 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.
Regards
Aurelien
Bug#1065212: asymptote: recent libc6-dev change causes XDR and V3D support to be dropped
Hi Hilmar, On 2024-03-02 00:19, Preuße, Hilmar wrote: > On 01.03.2024 23:33, Aurelien Jarno wrote: > > Hi Aurelien, > > > This can 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 do not fully understand, what needs to be done from my side: add a BD on > libtirpc-dev and (maybe) remove it later on? If you say the change will be > reverted later, I'd guess one can rather wait for that point in time and > then request an binNMU (or wait until anybody triggers a mass binNMU). What > do I miss? Sorry if i was not very clear, all of those bug filling was done in emergency and was not really planned. Asymptote needs libtirpc-dev to build with the proper features, so you need to add it as a build-depends, to avoid side effects of dependency changes in other packages. You do not need to remove it at any point. In the long term, we will definitely drop the libtirpc-dev dependency in libc6-dev. The plan is to do it for Trixie if possible, but we don't know when this is going to happen, this release cycle is really chaotic. We might also not even revert the temporary change if all packages are fixed before the time_t transition is finished. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1065216: r-base: recent libc6-dev change causes the xdr feature to be dropped
Source: r-base Version: 4.3.3-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-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, 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 the xdr feature of r-base to be dropped, I am not sure it is something to care about. Therefore please either: - Add libtirpc-dev as build dependency - Disable the xdr feature support explicitly so that it does not depend on the packages installed on the system. Regards Aurelien
Bug#1065215: xinetd: recent libc6-dev change causes the RPC support to be dropped
Source: xinetd Version: 1:2.3.15.4-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-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, 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.1i NMU, as part of the 64-bit time_t transition. This causes the RPC support of xinetd to be dropped, I am not sure it is something to care about. Therefore please either: - Add libtirpc-dev as build dependency - Disable the RPC support explicitly using --with-rpc=no, so that this feature does not depend on the packages installed on the system. Regards Aurelien
Bug#1065214: iproute2: recent libc6-dev change causes the RPC support to be dropped
Package: iproute2 Version: 6.7.0-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-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, 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 the RPC support in iproute2 (from misc/ss.c) to be dropped, I am not sure it is something to care about. Therefore please either: - Add libtirpc-dev as build dependency - Disable the RPC support explicitly using --without-rpc so that this feature does not depend on the packages installed on the system. Regards Aurelien
Bug#1065213: dovecot: recent libc6-dev change causes the rquota feature to be dropped
Source: dovecot Version: 1:2.3.21+dfsg1-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-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, 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 the rquota feature of dovecot to be dropped, I am not sure it is something to care about. Therefore please either: - Add libtirpc-dev as build dependency - Disable the rquota feature explicitly so that it does not depend on the packages installed on the system. Regards Aurelien
Bug#1065212: asymptote: recent libc6-dev change causes XDR and V3D support to be dropped
Source: asymptote Version: 2.86+ds1-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-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, 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 XDR and V3D support in asymptote to be dropped, something which is not recommended by upstream. This can 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. Regards Aurelien
Bug#1065208: gcl: recent libc6-dev change causes XDR support to be dropped
On 2024-03-01 22:10, Aurelien Jarno wrote: > Source: gcl > Version: 2.6.14-6 > Severity: serious > User: debian-gl...@lists.debian.org > Usertags: libtirpc-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, 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 gcl to disable > the XDR support. Not fully sure what are the consequences, but it seems > at least axiom requires XDR support. > > Therefore please either: > - Add libnsl-dev as build dependency Sorry that was a thinko. I meant libtirpc-dev. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1065207: gcl27: recent libc6-dev change causes XDR support to be dropped
On 2024-03-01 22:10, Aurelien Jarno wrote: > Source: gcl27 > Version: 2.7.0-20 > Severity: serious > User: debian-gl...@lists.debian.org > Usertags: libtirpc-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, 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 gcl27 to > disable the XDR support. Not fully sure what are the consequences. > > Therefore please either: > - Add libnsl-dev as build dependency Sorry that was a thinko. I meant libtirpc-dev. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1065210: fricas: missing build-dep on libtirpc-dev or libtirpc-dev dependency in gcl
Source: fricas Version: 1.3.10-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-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, 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 fricas to FTBFS in sid with: | End of Pass 1. | End of Pass 2. | OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3 | Finished compiling /<>/src/lisp/primitives.o. | #p"/<>/src/lisp/primitives.o" | NIL | NIL | | >echo '(compiler::link nil "prelisp" ' \ | ' (format nil "(progn (let ((SI::*load-path*' \ | ' (cons ~S SI::*load-path*))' \ | ' (si::*load-types* ~S))' \ |' (compiler::emit-fn t))' \ | ' (when (fboundp (quote si::sgc-on))' \ | ' (si::sgc-on nil))' \ | ' (setq compiler::*default-system-p* nil))' \ | ' (setq compiler::*default-large-memory-model-p* t))"' \ | ' si::*system-directory* (quote (list ".lsp")))' \ |' "/<>/src/lib/bsdsignal.o /<>/src/lib/cfuns-c.o /<>/src/lib/sockio-c.o ")' \ | | gcl | GCL (GNU Common Lisp) 2.6.14 Fri Jan 13 10:47:56 AM EST 2023 ANSIgit: Version_2_6_15pre5 | Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl) | Binary License: GPL due to GPL'ed components: (XGCL UNEXEC) | Modifications of this banner must retain notice of a compatible license | Dedicated to the memory of W. Schelter | | Use (help) to get some basic information on how to use GCL. | Temporary directory for compiler files: | /tmp/ | | >/usr/bin/ld: cannot find -ltirpc: No such file or directory | collect2: error: ld returned 1 exit status | | Correctable error: | Fast links are on: do (si::use-fast-links nil) for debugging | Signalled by COMPILER::LINK. | If continued: Continues anyway. | SIMPLE-ERROR: (SYSTEM "/usr/bin/gcc -Wl,-z,relro -no-pie -Wl,-T,../unixport/gcl.script -o /<>/src/lisp/raw_prelisp user-init.o -L/usr/lib/gcl-2.6.14/unixport/ -Wl,-Map /<>/src/lisp/raw_prelisp_map /<>/src/lib/bsdsignal.o /<>/src/lib/cfuns-c.o /<>/src/lib/sockio-c.o -lansi_gcl -lX11 -lm -ldl -lgmp -ltirpc -lreadline -lc -lgclp") returned a non-zero value 1 0. | | Broken at COMPILER::LINK. Type :H for Help. | 1 (continue) Continues anyway. | 2 Return to top level. | >>make[3]: *** [Makefile:250: do_it.gcl] Error 255 | make[3]: Leaving directory '/<>/src/lisp' | make[2]: *** [Makefile:231: all-lisp] Error 2 | make[2]: Leaving directory '/<>/src' | make[1]: *** [Makefile:251: all-src] Error 2 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:43: build-stamp] Error 2 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 One way to fix that would be to add an explicit Build-Depends on libtirpc-dev. That said I could not find any reference to tirpc in the fricas package, so I wonder if the right change is actually to add a libtirpc-dev dependency to the gcl binary package. You probably know that better than me, so please use the best option and feel free to reassign the bug to the right package. Regards Aurelien
Bug#1065207: gcl27: recent libc6-dev change causes XDR support to be dropped
Source: gcl27 Version: 2.7.0-20 Severity: serious User: debian-gl...@lists.debian.org Usertags: libtirpc-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, 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 gcl27 to disable the XDR support. Not fully sure what are the consequences. Therefore please either: - Add libnsl-dev as build dependency - Disable XDR support explicitly with --disable-xdr so that this feature does not depend on the packages installed on the system. 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. Regards Aurelien
Bug#1065208: gcl: recent libc6-dev change causes XDR support to be dropped
Source: gcl Version: 2.6.14-6 Severity: serious User: debian-gl...@lists.debian.org Usertags: libtirpc-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, 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 gcl to disable the XDR support. Not fully sure what are the consequences, but it seems at least axiom requires XDR support. Therefore please either: - Add libnsl-dev as build dependency - Disable XDR support explicitly with --disable-xdr so that this feature does not depend on the packages installed on the system. 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. Regards Aurelien
Bug#1065188: [Pkg-samba-maint] Bug#1065188: samba: missing build-dep on libtirpc-dev (and also rpcsvc-proto)
control: notfound -1 samba/2:12.3.5-4 control: found -1 samba/2:4.19.5+dfsg-2 On 2024-03-01 20:26, Michael Tokarev wrote: > 01.03.2024 19:05, Aurelien Jarno : > > Source: samba > > Version: 2:12.3.5-4 > > Is it really 12.3.5-4? :) Oops, sorry about that. I probably mixed packages when reporting the bug :( -ETOOMANYBUGS. Fixing that with this mail. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1065190: ogdi-dfsg: missing build-dep on libtirpc-dev
Source: ogdi-dfsg Version: 4.1.1+ds-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 ogdi-dfsg to FTBFS in sid with: | checking for string.h... yes | checking for inttypes.h... yes | checking for stdint.h... yes | checking for strings.h... yes | checking for sys/stat.h... yes | checking for sys/types.h... yes | checking for unistd.h... yes | checking for rpc/rpc.h... no | checking for libtirpc... no | configure: error: Package requirements (libtirpc) were not met: | | Package 'libtirpc', required by 'virtual:world', not found | | Consider adjusting the PKG_CONFIG_PATH environment variable if you | installed software in a non-standard prefix. | | Alternatively, you may set the environment variables RPC_CFLAGS | and RPC_LIBS to avoid the need to call pkg-config. | See the pkg-config man page for more details. | tail -v -n \+0 config.log This can 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. Regards Aurelien
Bug#1065189: libguestfs: missing build-dep on libtirpc-dev (and also rpcsvc-proto)
Source: libguestfs Version: 1:1.52.0-2.1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-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, 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 libguestfs to FTBFS in sid with: | checking for CFLocaleCopyPreferredLanguages... no | checking for GNU gettext in libc... yes | checking whether to use NLS... yes | checking where the gettext function comes from... libc | checking if the user specified a default backend... direct | checking for dlopen in -ldl... yes | checking for dlfcn.h... (cached) yes | checking for libtirpc... no | checking for rpc/xdr.h... no | configure: error: XDR header files are required | cd debian/build-1 && 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 libguestfs, 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. Regards Aurelien
Bug#1065188: samba: missing build-dep on libtirpc-dev (and also rpcsvc-proto)
Source: samba Version: 2:12.3.5-4 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-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, 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 samba to FTBFS in sid with: | [4938/6301] Compiling ctdb/utils/smnotify/smnotify.c | 13:58:50 runner ['x86_64-linux-gnu-gcc', '-D_SAMBA_BUILD_=4', '-DHAVE_CONFIG_H=1', '-g', '-O2', '-ffile-prefix-map=/<>=.', '-fstack-protector-strong', '-fstack-clash-protection', '-Wformat', '-Werror=format-security', '-fcf-protection', '-ffile-prefix-map=../../=', '-MMD', '-D_GNU_SOURCE=1', '-D_XOPEN_SOURCE_EXTENDED=1', '-DHAVE_CONFIG_H=1', '-fPIE', '-fPIC', '-D__STDC_WANT_LIB_EXT1__=1', '-D_REENTRANT', '-DCTDB_HELPER_BINDIR="/usr/libexec/ctdb"', '-DLOGDIR="/var/log/ctdb"', '-DCTDB_DATADIR="/usr/share/ctdb"', '-DCTDB_ETCDIR="/etc/ctdb"', '-DCTDB_VARDIR="/var/lib/ctdb"', '-DCTDB_RUNDIR="/run/ctdb"', '-fstack-protector-strong', '-fstack-clash-protection', '-DSTATIC_smnotify_MODULES=NULL', '-DSTATIC_smnotify_MODULES_PROTO=extern void __smnotify_dummy_module_proto(void)', '-Ictdb', '-I../../ctdb', '-Ictdb/utils', '-I../../ctdb/utils', '-Ictdb/utils/smnotify', '-I../../ctdb/utils/smnotify', '-Iinclude/public', '-I../../include/public', '-Isource4', '-I../../source4', '-Ilib', '-I../../lib', '-Isource4/lib', '-I../../source4/lib', '-Isource4/include', '-I../../source4/include', '-Iinclude', '-I../../include', '-Ilib/replace', '-I../../lib/replace', '-Ictdb/include', '-I../../ctdb/include', '-I.', '-I../..', '../../ctdb/utils/smnotify/smnotify.c', '-c', '-o/<>/bin/default/ctdb/utils/smnotify/smnotify.c.54.o', '-Wdate-time', '-D_FORTIFY_SOURCE=2'] | [4939/6301] Linking bin/default/ctdb/ctdb_takeover_helper.inst | 13:58:50 runner ['x86_64-linux-gnu-gcc', '-Wl,--as-needed', 'ctdb/protocol/protocol_header.c.7.o', 'ctdb/protocol/protocol_packet.c.7.o', 'ctdb/protocol/protocol_types.c.7.o', 'ctdb/protocol/protocol_call.c.7.o', 'ctdb/protocol/protocol_message.c.7.o', 'ctdb/protocol/protocol_control.c.7.o', 'ctdb/protocol/protocol_keepalive.c.7.o', 'ctdb/protocol/protocol_tunnel.c.7.o', 'ctdb/protocol/protocol_client.c.7.o', 'ctdb/protocol/protocol_debug.c.7.o', 'ctdb/protocol/protocol_sock.c.7.o', 'ctdb/server/ipalloc_deterministic.c.11.o', 'ctdb/server/ipalloc_nondeterministic.c.11.o', 'ctdb/server/ipalloc_lcp2.c.11.o', 'ctdb/server/ipalloc_common.c.11.o', 'ctdb/server/ipalloc.c.11.o', 'ctdb/protocol/protocol_basic.c.6.o', 'ctdb/server/ctdb_takeover_helper.c.47.o', 'ctdb/common/cmdline.c.4.o', 'ctdb/common/comm.c.4.o', 'ctdb/common/conf.c.4.o', 'ctdb/common/db_hash.c.4.o', 'ctdb/common/event_script.c.4.o', 'ctdb/common/hash_count.c.4.o', 'ctdb/common/line.c.4.o', 'ctdb/common/logging.c.4.o', 'ctdb/common/path.c.4.o', 'ctdb/common/pidfile.c.4.o', 'ctdb/common/pkt_read.c.4.o', 'ctdb/common/pkt_write.c.4.o', 'ctdb/common/rb_tree.c.4.o', 'ctdb/common/reqid.c.4.o', 'ctdb/common/run_event.c.4.o', 'ctdb/common/run_proc.c.4.o', 'ctdb/common/sock_client.c.4.o', 'ctdb/common/srvid.c.4.o', 'ctdb/common/tmon.c.4.o', 'ctdb/common/tunable.c.4.o', 'lib/async_req/async_sock.c.1.o', 'ctdb/protocol/protocol_util.c.8.o', 'ctdb/client/client_connect.c.9.o', 'ctdb/client/client_call.c.9.o', 'ctdb/client/client_message.c.9.o', 'ctdb/client/client_control.c.9.o', 'ctdb/client/client_message_sync.c.9.o', 'ctdb/client/client_control_sync.c.9.o', 'ctdb/client/client_db.c.9.o', 'ctdb/client/client_util.c.9.o', 'ctdb/client/client_tunnel.c.9.o', '-o/<>/bin/default/ctdb/ctdb_takeover_helper.inst', '-Wl,-rpath,/usr/lib/x86_64-linux-gnu/samba', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-L/<>/bin/default/libcli/util', '-L/<>/bin/default/lib/tdb_wrap', '-L/<>/bin/default/lib/util', '-L/<>/bin/default/lib/replace', '-L/usr/local/lib', '-L/usr/local/lib', '-lreplace-samba4', '-lsocket-blocking-samba4', '-lsys-rw-samba4', '-lsamba-util', '-liov-buf-samba4', '-ltdb-wrap-samba4', '-ltevent-util', '-lutil-setid-samba4', '-ltime-basic-samba4', '-lgenrand-samba4', '-lsamba-debug-samba4', '-lsamba-errors', '-licuuc', '-licui18n', '-licudata', '-lsystemd', '-lgnutls', '-lpopt', '-lbsd', '-ltevent', '-ltalloc', '-ltdb', '-ltalloc', '-Wl,-z,relro', '-Wl,-z,now', '-pie', '-Wl,-z,relro,-z,now', '-Wl,-no-undefined', '-Wl,--export-dynamic'] | In file included from ../../ctdb/utils/smnotify/smnotify.c:27: | ctdb/utils/smnotify/smnotify.h:9:10: fatal error: rpc/rpc.h: No such file or directory | 9 | #include | | ^~~ | compilation terminated. This could be fixed by adding an explicit Build-Depends on libtirpc-dev. The glibc change wi
Bug#1065186: caml-crush: missing build-dep on libtirpc-dev (and also rpcsvc-proto)
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. Regards Aurelien
Bug#1065187: open-vm-tools: missing build-dep on libtirpc-dev (and also rpcsvc-proto)
Source: open-vm-tools Version: 2:12.3.5-4 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 open-vm-tools to FTBFS in sid with: | checking for gtkmm-3.0 >= 3.0.0 (via pkg-config)... yes | checking for sigc++-2.0 >= 2.5.1 (via pkg-config)... yes | checking for crypt in -lcrypt... yes | checking for dlopen... yes | checking for ecvt... yes | checking for fcvt... yes | checking for mkdtemp... yes | checking for pthread_mutex_init in -lpthread... yes | checking for g++... yes | checking for libtirpc (via pkg-config)... no | configure: tirpc is needed: yes | configure: error: cannot find libtirpc but it is required. | cd open-vm-tools && 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 open-vm-tools, uses rpcgen, provided by the rpcsvc-proto during the build process. It is currently a depends 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. Regards Aurelien
Bug#1065183: python-fsquota: missing build-dep on libtirpc-dev
Source: python-fsquota
Version: 0.1.0+dfsg1-4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-gl...@lists.debian.org
Usertags: libtirpc-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, 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 python-fsquota
to FTBFS in sid with:
|dh_auto_configure -O--buildsystem=pybuild
| pybuild --configure -i python{version} -p 3.11
| I: pybuild base:305: python3.11 setup.py config
| Using hints/linux.h for myconfig.h
| WARNING: Header file /usr/include/rpc/rpc.h not present on this system.
| Likely compilation will fail. Recommend to either install package
| "libtirpc-dev", or disable RPC (network file system) support by
| adding the following switch to myconfig.h:
| #define NO_RPC
|
| running config
|dh_auto_build -O--buildsystem=pybuild
| pybuild --build -i python{version} -p 3.11
| I: pybuild base:305: /usr/bin/python3 setup.py build
| Using hints/linux.h for myconfig.h
| WARNING: Header file /usr/include/rpc/rpc.h not present on this system.
| Likely compilation will fail. Recommend to either install package
| "libtirpc-dev", or disable RPC (network file system) support by
| adding the following switch to myconfig.h:
| #define NO_RPC
|
| running build
| running build_ext
| building 'FsQuota' extension
| creating build
| creating build/temp.linux-x86_64-cpython-311
| creating build/temp.linux-x86_64-cpython-311/src
| x86_64-linux-gnu-gcc -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g
-fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -fcf-protection -g -fwrapv -O2 -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I. -I/usr/include/python3.11 -c
src/FsQuota.c -o build/temp.linux-x86_64-cpython-311/src/FsQuota.o
| In file included from src/FsQuota.c:18:
| ./myconfig.h:18:10: fatal error: rpc/rpc.h: No such file or directory
|18 | #include
| | ^~~
| compilation terminated.
| error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1
| E: pybuild pybuild:391: build: plugin distutils failed with: exit code=1:
/usr/bin/python3 setup.py build
| dh_auto_build: error: pybuild --build -i python{version} -p 3.11 returned
exit code 13
| make: *** [debian/rules:9: binary] Error 25
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status
2
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.
Regards
Aurelien
Bug#1065185: zfs-fuse: missing build-dep on libtirpc-dev
Source: zfs-fuse Version: 0.7.0-26 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-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, 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 zfs-fuse to FTBFS in sid with: | gcc -o lib/libnvpair/build-user/nvpair.o -c -pipe -Wall -std=c99 -Wno-switch -Wno-unused -Wno-missing-braces -Wno-parentheses -Wno-uninitialized -fno-strict-aliasing -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_REENTRANT -DTEXT_DOMAIN=\"zfs-fuse\" -ggdb -DNDEBUG -O2 -DLINUX_AIO -Ilib/libnvpair/include -Ilib/libsolcompat/include -I/usr/include/tirpc lib/libnvpair/nvpair.c | lib/libnvpair/nvpair.c:33:10: fatal error: rpc/types.h: No such file or directory |33 | #include | | ^ | compilation terminated. | scons: *** [lib/libnvpair/build-user/nvpair.o] Error 1 | scons: building terminated because of errors. | make[1]: *** [debian/rules:15: override_dh_auto_build] Error 2 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:38: build] Error 2 | dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 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. Regards Aurelien
Bug#1065180: argus-clients: missing build-dep on libtirpc-dev
Source: argus-clients Version: 1:3.0.8.2-6.2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-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, 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 argus-clients to FTBFS in sid with: | checking for strtof... (cached) yes | checking for srandomdev... no | checking for tzset... yes | checking for .threads... yes | checking for sched_get_priority_min... yes | checking for local tcp_wrappers library... not found | checking for system tcp_wrappers library... yes | checking for rpc_call in -ltirpc... no | configure: error: no tirpc library, exiting...! | 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. Regards Aurelien
Bug#1065184: xwayland: missing build-dep on libtirpc-dev
Package: xwayland Version: 2:23.2.4-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-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, 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 xwayland to FTBFS in sid with: | Configuring version-config.h using configuration | Configuring xkb-config.h using configuration | Configuring xwayland-config.h using configuration | Run-time dependency glproto found: YES 1.4.17 | Run-time dependency gl found: YES 1.2 | Dependency glproto found: YES 1.4.17 (cached) | Dependency gl found: YES 1.2 (cached) | Run-time dependency libtirpc found: NO (tried pkgconfig and cmake) | Has header "rpc/rpc.h" : NO | | ../os/meson.build:63:8: ERROR: Problem encountered: secure-rpc requested, but neither libtirpc or libc RPC support were found | | A full log can be found at /<>/obj-x86_64-linux-gnu/meson-logs/meson-log.txt | cd obj-x86_64-linux-gnu && tail -v -n \+0 meson-logs/meson-log.txt 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. Regards Aurelien
Bug#1065181: liblxi: missing build-dep on libtirpc-dev
Source: liblxi Version: 1.20-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-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, 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 liblxi to FTBFS in sid with: | Found pkg-config: /usr/bin/pkg-config (1.8.1) | Run-time dependency avahi-client found: YES 0.8 | Run-time dependency libxml-2.0 found: YES 2.9.14 | Run-time dependency threads found: YES | Has header "avahi-client/client.h" : YES | Did not find CMake 'cmake' | Found CMake: NO | Run-time dependency libtirpc found: NO (tried pkgconfig) | | ../src/meson.build:30:14: ERROR: Dependency "libtirpc" not found, tried pkgconfig | | A full log can be found at /<>/obj-x86_64-linux-gnu/meson-logs/meson-log.txt | cd obj-x86_64-linux-gnu && tail -v -n \+0 meson-logs/meson-log.txt 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. Regards Aurelien
Bug#1065182: libquota-perl: missing build-dep on libtirpc-dev
Source: libquota-perl Version: 1.8.2+dfsg-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-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, 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 libquota-perl to FTBFS in sid with: | x86_64-linux-gnu-gcc -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -DVERSION=\"1.8.2\" -DXS_VERSION=\"1.8.2\" -fPIC "-I/usr/lib/x86_64-linux-gnu/perl/5.38/CORE" linuxapi.c | In file included from linuxapi.c:13: | myconfig.h:18:10: fatal error: rpc/rpc.h: No such file or directory |18 | #include | | ^~~ | compilation terminated. | make[1]: *** [Makefile:345: linuxapi.o] Error 1 | make[1]: *** Waiting for unfinished jobs | mv Quota.xsc Quota.c | make[1]: Leaving directory '/<>' | dh_auto_build: error: make -j3 returned exit code 2 | make: *** [debian/rules:9: binary] Error 25 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 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. Regards Aurelien
Bug#1065179: argus: missing build-dep on libtirpc-dev
Source: argus Version: 2:3.0.8.2-2.2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) User: debian-gl...@lists.debian.org Usertags: libtirpc-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, 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 argus to FTBFS in sid with: | checking for inet_aton... yes | checking for setlinebuf... yes | checking for strerror... yes | checking for strtof... yes | checking for floorf... no | checking for remainderf... no | checking for timegm... yes | checking for rpc_call in -ltirpc... no | configure: error: no tirpc library, exiting...! | tail -v -n \+0 config.log | ==> 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. Regards Aurelien
Bug#1065165: autofs: recent libc6-dev change causes NIS support to be dropped
Source: autofs Version: 5.1.9-1 Severity: serious 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 autofs to be built without NIS support, which in practice means that the following modules are missing from the autofs package: /usr/lib/x86_64-linux-gnu/autofs/lookup_nisplus.so /usr/lib/x86_64-linux-gnu/autofs/lookup_yp.so /usr/lib/x86_64-linux-gnu/autofs/lookup_nis.so -> lookup_yp.so Please either: - Add libnsl-dev as build dependency - Disable NIS support explicitly so that this feature does not depend on the packages installed on the system. 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. Regards Aurelien
Bug#1065162: yp-tools: FTBFS: missing build-dep on libnsl-dev
Source: yp-tools Version: 4.2.3-3 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 yp-tools to FTBFS in sid with: | gcc -DHAVE_CONFIG_H -I. -I.. -I. -I/usr/include/tirpc -DLOCALEDIR=\"/usr/share/locale\" -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -D_REENTRANT=1 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -c -o host2ypbind3_binding.o host2ypbind3_binding.c | yp_all_host.c:30:10: fatal error: rpcsvc/ypclnt.h: No such file or directory |30 | #include | | ^ | compilation terminated. | make[3]: *** [Makefile:443: yp_all_host.o] Error 1 | make[3]: *** Waiting for unfinished jobs | make[3]: Leaving directory '/<>/lib' | make[2]: *** [Makefile:447: all-recursive] Error 1 | make[2]: Leaving directory '/<>' | make[1]: *** [Makefile:379: all] Error 2 | make[1]: Leaving directory '/<>' | dh_auto_build: error: make -j3 returned exit code 2 | make: *** [debian/rules:19: 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. Regards Aurelien
Bug#1065163: ypserv: FTBFS: missing build-dep on libnsl-dev
Source: ypserv Version: 4.2-1.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 ypserv to FTBFS in sid with: | gcc -DHAVE_CONFIG_H -D_REENTRANT=1 -DCONFDIR=\"/etc\" -DYPMAPDIR=\"/var/yp\" -DUSE_SD_NOTIFY=1 -I. -I.. -I.. -I.. -I. -Wdate-time -D_FORTIFY_SOURCE=2 -fpie -I/usr/include/tirpc -Werror -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wno-error=format-truncation= -Wno-error=format-overflow= -W -Wall -Wbad-function-cast -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -c -o securenets.o securenets.c | In file included from ypproc_match_2.c:22: | yp.h:10:10: fatal error: rpcsvc/yp_prot.h: No such file or directory |10 | #include | | ^~ | compilation terminated. | gmake[3]: *** [Makefile:615: ypproc_match_2.o] Error 1 | gmake[3]: *** Waiting for unfinished jobs | gmake[3]: Leaving directory '/<>/lib' | gmake[2]: *** [Makefile:395: all-recursive] Error 1 | gmake[2]: Leaving directory '/<>' | make[1]: *** [Makefile:336: all] Error 2 | make[1]: Leaving directory '/<>' | dh_auto_build: error: make -j3 returned exit code 2 | make: *** [debian/rules:28: 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. Regards Aurelien
Bug#1065161: udptunnel: FTBFS: missing build-dep on libnsl-dev
Source: udptunnel
Version: 1.1-10
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 udptunnel to FTBFS in
sid with:
| gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\"
-DPACKAGE=\"udptunnel\" -DVERSION=\"1.1\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1
-DHAVE_FCNTL_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DSIZEOF_SHORT=2
-DHAVE_SELECT=1 -DHAVE_SOCKET=1 -DHAVE_STRTOL=1 -I. -Wdate-time
-D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -fstack-clash-protection -Wformat
-Werror=format-security -fcf-protection -Wall -c -o host2ip.o host2ip.c
| host2ip.c:7:10: fatal error: rpcsvc/ypclnt.h: No such file or directory
| 7 | #include/* YP */
| | ^
| compilation terminated.
| make[1]: *** [Makefile:379: host2ip.o] Error 1
| make[1]: *** Waiting for unfinished jobs
| udptunnel.c: In function ‘await_incoming_connections’:
| udptunnel.c:430:55: warning: pointer targets in passing argument 3 of
‘accept’ differ in signedness [-Wpointer-sign]
| 430 | (struct sockaddr *) &client_addr, &addrlen)) < 0)
{
| | ^~~~
| | |
| | int *
| In file included from udptunnel.c:14:
| /usr/include/x86_64-linux-gnu/sys/socket.h:307:42: note: expected ‘socklen_t
* restrict’ {aka ‘unsigned int * restrict’} but argument is of type ‘int *’
| 307 |socklen_t *__restrict __addr_len);
| |~~^~
| udptunnel.c: In function ‘udp_to_tcp’:
| udptunnel.c:485:26: warning: pointer targets in passing argument 6 of
‘recvfrom’ differ in signedness [-Wpointer-sign]
| 485 | &addrlen)) <= 0) {
| | ^~~~
| | |
| | int *
| In file included from /usr/include/x86_64-linux-gnu/sys/socket.h:343:
| /usr/include/x86_64-linux-gnu/bits/socket2.h:62:56: note: expected ‘socklen_t
* restrict’ {aka ‘unsigned int * restrict’} but argument is of type ‘int *’
|62 | __SOCKADDR_ARG __addr, socklen_t *__restrict __addr_len)
| | ~~^~
| udptunnel.c: In function ‘tcp_to_udp’:
| udptunnel.c:564:36: warning: pointer targets in passing argument 5 of
‘getsockopt’ differ in signedness [-Wpointer-sign]
| 564 | (void *)&err, &len) < 0) {
| |^~~~
| ||
| |int *
| /usr/include/x86_64-linux-gnu/sys/socket.h:257:46: note: expected ‘socklen_t
* restrict’ {aka ‘unsigned int * restrict’} but argument is of type ‘int *’
| 257 |socklen_t *__restrict __optlen) __THROW;
| |~~^~~~
| make[1]: Leaving directory '/<>'
| dh_auto_build: error: make -j3 returned exit code 2
| make: *** [debian/rules:6: binary] Error 25
| dpkg-buildpackage: error: debian/rules binary 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.
Regards
Aurelien
Bug#1065160: slapi-nis: FTBFS: missing build-dep on libnsl-dev
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. Regards Aurelien
Bug#1065159: aplus-fsf: FTBFS: missing build-dep on libnsl-dev
Source: aplus-fsf Version: 4.22.1-12 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 aplus-fsf to FTBFS in sid with: | libtool: compile: gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"aplus-fsf\" -DVERSION=\"4.22\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DRETSIGTYPE=void -DHAVE_STRFTIME=1 -DHAVE_FORK=1 -DHAVE_VFORK=1 -DHAVE_WORKING_VFORK=1 -DHAVE_WORKING_FORK=1 -DHAVE_VPRINTF=1 -DHAVE_GETCWD=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_GETWD=1 -DHAVE_MKTIME=1 -DHAVE_PUTENV=1 -DHAVE_REGCOMP=1 -DHAVE_SELECT=1 -DHAVE_SIGACTION=1 -DHAVE_SOCKET=1 -DHAVE_STRCSPN=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOD=1 -DHAVE_STRTOL=1 -DHAVE_STRTOUL=1 -DHAVE_DIRENT_H=1 -DSTDC_HEADERS=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_FCNTL_H=1 -DHAVE_LIMITS_H=1 -DHAVE_MALLOC_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_FILE_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYSLOG_H=1 -DHAVE_UNISTD_H=1 -DHAVE_MATH_H=1 -DHAVE_FLOAT_H=1 -DHAVE_NEW=1 -DHAVE_IOSTREAM=1 -DHAVE_IOMANIP=1 -DHAVE_FSTREAM=1 -DHAVE_SSTREAM=1 -DHAVE_IOSFWD=1 -DHAVE_FPCLASSIFY=1 -DHAVE_FINITE=1 -DHAVE_ISINF=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_STRUCT_STAT_ST_BLOCKS=1 -DHAVE_ST_BLOCKS=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DHAVE_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DHAVE_SOCKLEN_T=1 -I. -I.. -g -pipe -std=gnu++98 -O2 -MT getmuser.lo -MD -MP -MF .deps/getmuser.Tpo -c getmuser.c -fPIC -DPIC -o .libs/getmuser.o | cc1: warning: command-line option â<80><98>-std=gnu++98â<80><99> is valid for C++/ObjC++ but not for C | getmuser.c:10:10: fatal error: rpcsvc/ypclnt.h: No such file or directory |10 | #include | | ^ | compilation terminated. | make[3]: *** [Makefile:872: getmuser.lo] Error 1 | make[3]: *** Waiting for unfinished jobs 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. Regards Aurelien
Bug#1065158: postfix: FTBFS: missing build-dep on libnsl-dev
Source: postfix Version: 3.8.5-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 postfix to FTBFS in sid with: | gcc -fPIC -I. -I../../include -DDEBIAN -DHAS_PCRE=2 -DHAS_LDAP -DUSE_LDAP_SASL -DHAS_SQLITE -DMYORIGIN_FROM_FILE -DHAS_CDB -DHAS_LMDB -DHAS_MYSQL -I/usr/include/mysql -DHAS_PGSQL -I/usr/include/postgresql -DHAS_SQLITE -DHAS_SSL -I/usr/include/openssl -DUSE_SASL_AUTH -I/usr/include/sasl -DUSE_CYRUS_SASL -DUSE_TLS -DHAS_DEV_URANDOM -DDEF_DAEMON_DIR=\"/usr/lib/postfix/sbin\" -DDEF_HTML_DIR=\"/usr/share/doc/postfix/html\" -DDEF_MANPAGE_DIR=\"/usr/share/man\" -DDEF_README_DIR=\"/usr/share/doc/postfix\" -DUSE_DYNAMIC_LIBS -DUSE_DYNAMIC_MAPS -Wmissing-prototypes -Wformat -Wno-comment -fno-common -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -g -O2 -ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -flto=auto -ffat-lto-objects -Wl,-z,relro -Wl,-z,now -I. -DLINUX6 -c dict_nis.c | dict_nis.c:42:10: fatal error: rpcsvc/ypclnt.h: No such file or directory |42 | #include | | ^ | compilation terminated. | make: *** [Makefile:220: dict_nis.o] Error 1 | make: *** Waiting for unfinished jobs | make: Leaving directory '/<>/src/util' | make[2]: *** [Makefile:114: update] Error 1 | make[2]: Leaving directory '/<>' | dh_auto_build: error: make -j3 "INSTALL=install --strip-program=true" returned exit code 2 | make[1]: *** [debian/rules:90: override_dh_auto_build] Error 25 | make[1]: Leaving directory '/<>' | make: *** [debian/rules:63: binary] Error 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. Regards Aurelien
Bug#1065129: python3.11: recent libc6-dev change causes NIS support to be dropped
Source: python3.11 Version: 3.11.13-1 Severity: serious 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 python3.11 to be built without NIS support, which in practice means that this python module is missing from libpython3.11-stdlib: /usr/lib/python3.11/lib-dynload/nis.cpython-311-x86_64-linux-gnu.so Please either: - Add libnsl-dev as build dependency - Disable NIS support explicitly so that this feature does not depend on the packages installed on the system. 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. Regards Aurelien
Bug#1065130: python3.10: recent libc6-dev change causes NIS support to be dropped
Source: python3.10 Version: 3.10.13-1 Severity: serious 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 python3.10 to be built without NIS support, which in practice means that this python module is missing from libpython3.10-stdlib: /usr/lib/python3.10/lib-dynload/nis.cpython-310-x86_64-linux-gnu.so Please either: - Add libnsl-dev as build dependency - Disable NIS support explicitly so that this feature does not depend on the packages installed on the system. 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. Regards Aurelien
Bug#1065128: python3.12: recent libc6-dev change causes NIS support to be dropped
Source: python3.12 Version: 3.12.13-1 Severity: serious 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 python3.12 to be built without NIS support, which in practice means that this python module is missing from libpython3.12-stdlib: /usr/lib/python3.12/lib-dynload/nis.cpython-312-x86_64-linux-gnu.so Please either: - Add libnsl-dev as build dependency - Disable NIS support explicitly so that this feature does not depend on the packages installed on the system. 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. Regards Aurelien
