Bug#1069362: libcleri: FTBFS on arm64: make: *** [debian/rules:7: binary] Error 25
Control: reassign -1 debputy Control: affects -1 libcleri On Sat, 20 Apr 2024 14:06:18 +0200 Lucas Nussbaum wrote: Source: libcleri Version: 1.0.2-1 Severity: serious Justification: FTBFS Tags: trixie sid ftbfs User: lu...@debian.org Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-arm64 Hi, During a rebuild of all packages in sid, your package failed to build on arm64. [...] Inverted boolean assertion in `debputy`, reassigning. Best regards, Niels
Bug#1068189: debhelper: --link-doc checking for known packages makes linux-signed build FTBFS
Salvatore Bonaccorso:
Source: debhelper
Version: 13.15
Severity: serious
Tags: ftbfs
Justification: Regression for other package builds, FTBFS
X-Debbugs-Cc: car...@debian.org,debian-ker...@lists.debian.org
Control: affects -1 + src:linux,src:linux-signed-amd64,src:linux-signed-arm64
Hi Niels,
Not fully investigated, but starting to fill a bugreport. I noticed
that the src:linux pipeline on salsa started to fail for the
jobs in th build-signed stage (in the build-signed job).
https://salsa.debian.org/carnil/linux/-/jobs/5527774
(and for saving the output):
[...]
(attached as well the raw log)
I'm not 100% sure yet, this might be a problem in our packaging in
which case we can re-eassign. But it only got triggered with the
change recently in debhelper:
https://salsa.debian.org/debian/debhelper/-/commit/dec5cfad00e2abd9ee3594f90c93f3fa42bb73ff
Regards,
Salvatore
Hi Salvatore
It was a suggestion raised (I think on IRC) to have debhelper explicitly
check these parameters, because a lot of t64 breakage was "unnoticed" by
debhelper. That is, when people forgot to update --link-doc parameters
(etc.).
The code for `--link-doc` uses `${binary:Version}` for the dependency,
so the package should really be from the same source[1]. In my view, it
was never a case that was expected to work between source packages.
I think `linux` with `linux-signed` is doing something really special
here (especially considering it has worked so far), and I think the
question is whether `linux`/`linux-signed` should get a special-case or
concluding that the `--link-doc` is not suitable for the
`linux`/`linux-signed` case.
I would like to hear your case for what makes `--link-doc` sensible for
the `linux-signed` case. I know of `linux-signed`, but I have no idea
what you are dealing with in practice, so it is hard for me to make a
judgement call on this (other than my biased gut feeling of wanting to
minimize special-cases).
Best regards,
Niels
[1]: Policy also documents the "same source" requirement.
https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information
Bug#1067711: marked as pending in debhelper
Control: tag -1 pending Hello, Bug #1067711 in debhelper 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/debian/debhelper/-/commit/3e289043fd79a9d474a3b6d6f4591408cef26e65 dh_gencontrol: Gracefully cope with custom substvars and -dbgsym packages Closes: #1067711 Signed-off-by: Niels Thykier (this message was generated automatically) -- Greetings https://bugs.debian.org/1067711
Bug#1067711: Bug related to "dpkg-gencontrol: warning: can't parse dependency pkg (= )" for -dbgsym packages
Control: reassign 1067711 debhelper Control: reassign 1067728 debhelper Control: forcemerge 1067711 1067728 Control: retitle 1067711 dh_gencontrol: substvars and -dbgsym packages Control: affects 1067711 mrpt genomethreader Hi, I think this kind of bugs are likely to be a bug in debhelper. Best regards, Niels
Bug#1067509: marked as pending in debhelper
Control: tag -1 pending Hello, Bug #1067509 in debhelper 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/debian/debhelper/-/commit/791f69537725c8183dc42bffbfbb0e09b77082cc Dh_Lib.pm: Fix field truncation in compat 14+ Closes: #1067508 Closes: #1067509 Signed-off-by: Niels Thykier (this message was generated automatically) -- Greetings https://bugs.debian.org/1067509
Bug#1067508: marked as pending in debhelper
Control: tag -1 pending Hello, Bug #1067508 in debhelper 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/debian/debhelper/-/commit/791f69537725c8183dc42bffbfbb0e09b77082cc Dh_Lib.pm: Fix field truncation in compat 14+ Closes: #1067508 Closes: #1067509 Signed-off-by: Niels Thykier (this message was generated automatically) -- Greetings https://bugs.debian.org/1067508
Bug#1059565: pkg-js-tools: Tests (autopkgtests) uses `fakeroot` without dependency
Package: pkg-js-tools Severity: serious X-Debbugs-Cc: ni...@thykier.net Control: affects -1 src:devscripts Justification: Autopkgtests failures are RC per RT decision Hi A new version of `devscripts` removed its dependency on `fakeroot`. After this, the pkg-js-tools's autopkgtests started failing with errors like: 759s Can't exec "fakeroot": No such file or directory at /usr/share/perl5/Dpkg/IPC.pm line 312. 759s dh_eslint.t: error: unable to execute fakeroot dh_auto_install --buildsystem=nodejs: No such file or directory 759s dh_eslint.t: error: fakeroot dh_auto_install --buildsystem=nodejs subprocess returned exit status 25 https://ci.debian.net/packages/p/pkg-js-tools/testing/amd64/41355085/#L12525 This implies that `pkg-js-tools` was missing a (test) dependency on `fakeroot`. Looking a bit deeper into the tests, I think the `fakeroot` usage is unnecessary. Example from dh_badfilesfield.t: spawn( exec => [ 'fakeroot', 'dh_auto_install', '...' ], wait_child => 1 ); Generally, `dh_auto_install` (nor any other `debhelper` tool) does not require `fakeroot` and should be runnable without it assuming the underlying build system is ready for it (which is generally should be these days). You *may* need to set `DEB_RULES_REQUIRES_ROOT=no` to avoid triggering a safety check inside debhelper. I would recommend that you remove all uses of `fakeroot` where possible instead of just blindly adding the depends. Best regards, Niels
Bug#1042124: Flex help needed for eegdev (Was: Re: eegdev: FTBFS: ../../lib/stdio.h:64:3: error: #error "Please include config.h first.")
Nilesh Patra: On 25 August 2023 1:47:26 pm IST, Nilesh Patra wrote: On Wed, 26 Jul 2023 21:52:17 +0200 Lucas Nussbaum wrote: Source: eegdev Version: 0.2-6 Severity: serious In file included from conffile.lex.c:242: ../../lib/stdio.h:64:3: error: #error "Please include config.h first." 64 | #error "Please include config.h first." | ^ The lexed file conffile.lex.c seems to include some stuff before config.h is included which is causing it to choke. I'm not acquainted with lexers and not sure what causes this. I'd appreciate any help. Adding mentors list as well. If someone can help with this, that'd be great. Best, Nilesh Hi, I do not think the lexer has anything to do with this. A quick look at the log suggests that the package is "rolling" its own "stdio.h" (note the "../../lib/stdio.h" in the error message). Indeed, the full log has "mv stdio.h-t3 stdio.h" as well. I believe that this is stdio.h is generated by the embedded gnulib copy and that is as far as I am willing to debug that rabbit hole. Based on the error, I assume gnulib's generated stdio.h requires the project specific "config.h" to be loaded first. As for solving it, I would have a look at the "conffile.lex.c" file, see where it has its "#include" for stdio.h and then add an `include "config.h"` before that to see if it works (via a patch). Hope that helps. Best regards, Niels
Bug#1042124: Flex help needed for eegdev (Was: Re: eegdev: FTBFS: ../../lib/stdio.h:64:3: error: #error "Please include config.h first.")
Niels Thykier: [...] Hi, [...] I believe that this is stdio.h is generated by the embedded gnulib copy and that is as far as I am willing to debug that rabbit hole. Based on the error, I assume gnulib's generated stdio.h requires the project specific "config.h" to be loaded first. [...] Best regards, Niels Correction; the gnulib was probably not an "embedded copy". The file still seems to be generated via gnulib, so the rest of my argument would remain the same.
Bug#1024261: debhelper: dbgsym packages contain directoryr writable by build user
Axel Beckert: Hi, Helmut Grohne wrote: 308 armel 313 armhf 316 i386 613 mipsel I think it is fairly safe to say that the problem affects 32bit architectures. Could this be https://bugs.debian.org/1023286 in fakeroot as well as Niels pointed out in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024520#37 ? Regards, Axel It is. Helmut and I discussed this on IRC and Helmut's findings is based on that IRC discussion between him and I in relation to #1023286. (Which people not IRC had no chance of knowing, so putting the context here for good measure) Thanks, ~Niels
Bug#1024520: debhelper: Use of uninitialized value $dest in -l at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 662.
Axel Beckert: Hi Niels, Niels Thykier wrote: [...] It was indeed an oversight. Yep, looked like that: Was the only occurence far away from the remaining calls. Also wondered if that call better should have been a simple install_file() instead. The $mode parameter gets in the way. However, no one is using that function outside of debhelper, so I can just simplify it so we can use install_file instead - done! Thanks for the suggestion. I will probably not change anything for now. Having slept on it and given additional evidence, I think the underlying issue was a bug in fakeroot (#1023286 is most my most likely candidate) and not a bug in debhelper I see. Given that comment and the fact that #1023286 only affects 32 bit architectures, I think that #1024261 (in debhelper) is related and might have the same cause as only 32-bit files seem to be affected. (Or was #1024261 the whole trigger for that 4-argument conversion? Saw no comment from you there so far.) I got #1024261 filed against debhelper, which made me assume this was a bug in debhelper. While I had seen #1023286, I originally thought debhelper was not doing the job properly as well. This prompted me to do the 4-argument conversion to resolve it. To be honest, it was a precursor for a change to `install_dir`, which I thought we would be the full fix - but `install_dir` had "complicated" usage outside debhelper, so I got rid of the easy parts first. However, post upload, I finally understood that the real problem is not related to debhelper creating the directory with the wrong ownership (if it did, *all* directories in the dbgsym would be wrong). Instead, it is most likely a "cp" or a "mv" call that copies a file into the directory that causes fakeroot to drop its ownership information. I.e., the 4-argument conversion changes will not change anything as the bug is 100% fakeroot. At least hindsight is still 20/20. (meaning the change to 4 parameters should probably be undone). Ack, sounds as if this is probably the way to go once it's clear that #1023286 was really the cause. I also wonder if some versioned Breaks or Conflicts would be helpful, too. Regards, Axel I am not sure version Breaks/Conflicts is necessary to be honest. My 13.11 upload included a fail-safe that works around this particular bug in fakeroot in dbgsyms - one could argue that I "fixed" #1024261 with that. At the time, I felt it was a work around, so I kept it open. However, I think once the dusts settles, I will probably close #1024261 as "not a bug in debhelper" and undo the 4-argument conversion. But for now - I will just let the dust settle; after all the fakeroot bug is still present in mipsel due to a FTBFS (#1024544)... Thanks, ~Niels
Bug#1024544: fakeroot: FTBFS on mipsel blocking fix for #1023286
Package: fakeroot Version: 1.29-1 Severity: serious X-Debbugs-Cc: ni...@thykier.net Hi, The fakeroot/1.30.1-1 FTBFS on mipsel (release arch) which blocks the fix for #1023286 from affecting mipsel binaries. The #1023286 also seems to be source of a lot of a dbgsym packages having the wrong ownership in them (see #1024261). With debhelper/13.11, the dbgsym packages will no longer be a problem but we risk that the bug leaks into regular debs as well (no one has tested for this). Thanks, ~Niels
Bug#1024520: debhelper: Use of uninitialized value $dest in -l at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 662.
Axel Beckert: Hi again, Will upload anyway as it clearly improves the situation and we need a fix quickly. Niels: Feel free to improve my fix in the next upload in case I understood some of the new code wrongly. Regards, Axel Hi, Thanks for finding and working around the bug. It was indeed an oversight. I will probably not change anything for now. Having slept on it and given additional evidence, I think the underlying issue was a bug in fakeroot (#1023286 is most my most likely candidate) and not a bug in debhelper (meaning the change to 4 parameters should probably be undone). Thanks, ~Niels
Bug#1015033: mscgen: FTBFS: configure: error: Package requirements (gdlib) were not met
Control: tags -1 moreinfo On Sat, 16 Jul 2022 15:37:05 +0200 Lucas Nussbaum wrote: > Source: mscgen > Version: 0.20-14 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20220716 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > checking pkg-config is at least version 0.9.0... yes > > checking for unistd.h... (cached) yes > > checking for limits.h... yes > > checking for gdlib-config... no > > checking for gdlib... no > > configure: error: Package requirements (gdlib) were not met > > > > Package 'libwebp', required by 'gdlib', 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 GDLIB_CFLAGS > > and GDLIB_LIBS to avoid the need to call pkg-config. > > See the pkg-config man page for more details. > > cd _build && tail -v -n \+0 config.log > > > [...] This looks suspiciously like #1014759, which was fixed the same day as you filed this bug. Could I have you please confirm this is still an issue with libgd2/2.3.3-6 or later? (I noted your test used 2.3.3-3, which current at the time) Thanks, ~Niels
Bug#1012252: debhelper: execute_after not executed for binary-indep build
Control: tags -1 moreinfo Drew Parsons: > Package: debhelper > Version: 13.7.1 > Severity: Serious > Justification: FTBFS > Control: block 1012022 by -1 > > fenics-basix 0.4.2-1exp1 is currently failing to build in a > binary-indep build, see > https://buildd.debian.org/status/logs.php?pkg=fenics-basix=all > > The problem occurs when building docs in an > execute_before_dh_install-indep rule. The doc build (via sphinx) > expects the basix python module to have been built. The rules file is > available at > https://tracker.debian.org/media/packages/f/fenics-basix/rules-0.4.2-1exp1 > > The python module build is supposed to have been performed already in > an execute_after_dh_auto_install rule (after dh_auto_install has put > the libbasix.so shared library in place). > > We can see in the binary-indep log at > https://buildd.debian.org/status/fetch.php?pkg=fenics-basix=all=0.4.2-1exp1=1654102080=0 > that libbasix.so did get built by the override_dh_auto_build rule, and > got installed by dh_auto_install -i. > > But after dh_auto_install -i, the next rule that gets run is > execute_before_dh_install-indep. execute_after_dh_auto_install never > gets run. > > This doesn't meet the intention of the rules file. > execute_after_dh_auto_install should be run after dh_auto_install, > with or without the -i flag, shouldn't it? > > In particular, dh --no-act indicates it should have been executed: > > $ dh binary-indep --no-act >dh_testroot -i >dh_prep -i >dh_installdirs -i >dh_auto_install -i >debian/rules execute_after_dh_auto_install >debian/rules execute_before_dh_install-indep >dh_install -i >dh_installdocs -i >... > > > So it looks like a bug in dh during actual execution, that the > execute_after_dh_auto_install rule is not getting executed. > > This bug is blocking #1012022, which is Severity: serious (FTBFS), > hence I'm marking this bug Severity: serious (FTBFS) to match. > > > [...] Hi, The bug report contains inconsistent information. The bug report says and includes a dh --no-act that implies there is a rule called "execute_after_dh_auto_install" in debian/rules. However, the rules files provided via "https://tracker.debian.org/media/packages/f/fenics-basix/rules-0.4.2-1exp1; does *not* have that rule. Instead it has the "execute_after_dh_auto_install-arch" rule, which would explain a lot of the issues you are reporting. If you have linked to the wrong debian/rules file, then please provide an updated link. Thanks, ~Niels
Bug#965887: Update debhelper compatibility and build rules
On Tue, 21 Dec 2021 21:23:42 +0100 =?iso-8859-1?q?Sl=E1vek_Banko?= wrote: > Hi Jorge, Niels, all, > > I prepare patch for Debian packaging files that increases debhelper > compatibility and makes clean of build rules. This should completely > address this bug. See attachment. > > Cheers > -- > Slávek Hi Slávek, FTR, I think this package might be a candidate for the [ITS process] in case you are interested in maintaining it. ~Niels [ITS process]: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
Bug#965829: sofia-sip: Removal of obsolete debhelper compat 5 and 6 in bookworm
On Wed, 22 Dec 2021 09:37:46 +0100 Evangelos Ribeiro Tzaras wrote: > Just as a follow up: > > I could imagine adopting the package (possibly within the VoIP team) > in case the maintainer is willing to part with it. I don't want to be > stepping on any toes, which is why I'm cautiously putting that option > on the table :) > > Cheers > -- > Evangelos > PGP: B938 6554 B7DD 266B CB8E 29A9 90F0 C9B1 8A6B 4A19 > > Hi, FTR, I think this package might be a candidate for the [ITS process] in case you are interested in maintaining it. ~Niels [ITS process]: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
Bug#996541: racon: FTBFS when rebuilt against libedlib1
Package: racon Version: 1.4.21-1 Severity: serious X-Debbugs-Cc: ni...@thykier.net Hi, A new version of libedlib (with a new ABI) has been uploaded to unstable and that causes racon to fail to build from source. Relevant parts of the amd64 log: ``` > /usr/bin/cmake -E cmake_link_script CMakeFiles/racon_test.dir/link.txt > --verbose=1 > /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > -D_FORTIFY_SOURCE=2 -Wall -Wextra -pedantic -Wl,-z,relro -Wl,-z,now -rdynamic > CMakeFiles/racon_test.dir/test/racon_test.cpp.o > CMakeFiles/racon_test.dir/src/logger.cpp.o > CMakeFiles/racon_test.dir/src/polisher.cpp.o > CMakeFiles/racon_test.dir/src/overlap.cpp.o > CMakeFiles/racon_test.dir/src/sequence.cpp.o > CMakeFiles/racon_test.dir/src/window.cpp.o -o bin/racon_test -lspoa -ledlib > -lz /usr/lib/x86_64-linux-gnu/libgtest_main.a > /usr/lib/x86_64-linux-gnu/libgtest.a -pthread > /usr/bin/ld: CMakeFiles/racon_test.dir/test/racon_test.cpp.o: in function > `calculateEditDistance(std::__cxx11::basic_string std::char_traits, std::allocator > const&, > std::__cxx11::basic_string, std::allocator > > const&)': > ./obj-x86_64-linux-gnu/./test/racon_test.cpp:18: undefined reference to > `edlibDefaultAlignConfig' > /usr/bin/ld: ./obj-x86_64-linux-gnu/./test/racon_test.cpp:18: undefined > reference to `edlibAlign' > /usr/bin/ld: ./obj-x86_64-linux-gnu/./test/racon_test.cpp:22: undefined > reference to `edlibFreeAlignResult' > /usr/bin/ld: CMakeFiles/racon_test.dir/src/overlap.cpp.o: in function > `racon::Overlap::align_overlaps(char const*, unsigned int, char const*, > unsigned int)': > ./obj-x86_64-linux-gnu/./src/overlap.cpp:208: undefined reference to > `edlibNewAlignConfig' > /usr/bin/ld: ./obj-x86_64-linux-gnu/./src/overlap.cpp:208: undefined > reference to `edlibAlign' > /usr/bin/ld: ./obj-x86_64-linux-gnu/./src/overlap.cpp:213: undefined > reference to `edlibAlignmentToCigar' > /usr/bin/ld: ./obj-x86_64-linux-gnu/./src/overlap.cpp:223: undefined > reference to `edlibFreeAlignResult' > collect2: error: ld returned 1 exit status > make[3]: *** [CMakeFiles/racon_test.dir/build.make:182: bin/racon_test] Error > 1 > make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu' > make[2]: *** [CMakeFiles/Makefile2:88: CMakeFiles/racon_test.dir/all] Error 2 > make[2]: *** Waiting for unfinished jobs > [100%] Linking CXX executable bin/racon > /usr/bin/cmake -E cmake_link_script CMakeFiles/racon.dir/link.txt --verbose=1 > /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > -D_FORTIFY_SOURCE=2 -Wall -Wextra -pedantic -Wl,-z,relro -Wl,-z,now -rdynamic > -pthread CMakeFiles/racon.dir/src/main.cpp.o > CMakeFiles/racon.dir/src/logger.cpp.o CMakeFiles/racon.dir/src/polisher.cpp.o > CMakeFiles/racon.dir/src/overlap.cpp.o > CMakeFiles/racon.dir/src/sequence.cpp.o CMakeFiles/racon.dir/src/window.cpp.o > -o bin/racon -lspoa -ledlib -lz > /usr/bin/ld: CMakeFiles/racon.dir/src/overlap.cpp.o: in function > `racon::Overlap::align_overlaps(char const*, unsigned int, char const*, > unsigned int)': > ./obj-x86_64-linux-gnu/./src/overlap.cpp:208: undefined reference to > `edlibNewAlignConfig' > /usr/bin/ld: ./obj-x86_64-linux-gnu/./src/overlap.cpp:208: undefined > reference to `edlibAlign' > /usr/bin/ld: ./obj-x86_64-linux-gnu/./src/overlap.cpp:213: undefined > reference to `edlibAlignmentToCigar' > /usr/bin/ld: ./obj-x86_64-linux-gnu/./src/overlap.cpp:223: undefined > reference to `edlibFreeAlignResult' > collect2: error: ld returned 1 exit status ``` Thanks, ~Niels
Bug#993316: systemd: missing /lib/systemd/system/rpcbind.service file
Control: reassign -1 debhelper Control: affects -1 systemd Michael Biebl: > Am 30.08.21 um 18:31 schrieb Vincent Lefevre: >> Package: systemd >> Version: 247.9-1 >> Severity: critical >> Justification: breaks unrelated software >> >> systemd provides a dangling symlink: >> >> $ ls -l /lib/systemd/system/portmap.service >> lrwxrwxrwx 1 root root 15 2021-08-17 17:31:36 >> /lib/systemd/system/portmap.service -> rpcbind.service >> $ ls -L /lib/systemd/system/portmap.service >> ls: cannot access '/lib/systemd/system/portmap.service': No such file >> or directory > > This symlink is created via > > dh_link lib/systemd/system/rpcbind.service > lib/systemd/system/portmap.service > > I wonder if debhelper can do something about this or if this is one of > the cases where the package is best updated manually. > > I suspect we have a few packages which create such aliasing symlinks via > *.links files or explicit calls to dh_link > > > Niels, what's your thought on this? > > >> This breaks checkrestart: > > [...] > > Regards, > Michael > Hi, I am moving this bug to debhelper. ~Niels
Bug#993759: uucp FTBFS: dh_installsystemd vs /usr-merge
Control: reassign -1 debhelper Control: affects -1 uucp Helmut Grohne: > Source: uucp > Version: 1.07-27 > Severity: serious > Tags: ftbfs > X-Debbugs-Cc: debhel...@packages.debian.org > > The /usr-merge broke the uucp build. dh_installsystemd now moves > .services files from /lib to /usr/lib. The consequence is as follows: > > |debian/rules override_dh_installsystemd > | make[1]: Entering directory '/<>' > | dh_installsystemd > | # we come from an inetd service, so we have to set accept=yes in > uucp.socket and such require the @ > | mv `pwd`/debian/uucp/lib/systemd/system/uucp.service > `pwd`/debian/uucp/lib/systemd/system/uucp@.service > | mv: cannot stat > '/<>/debian/uucp/lib/systemd/system/uucp.service': No such file > or directory > | make[1]: *** [debian/rules:119: override_dh_installsystemd] Error 1 > | make[1]: Leaving directory '/<>' > | make: *** [debian/rules:27: binary] Error 2 > | dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned > exit status 2 > > Please don't shoot the messenger. > > Helmut > Noted. @Thorsten: Please hold on changing anything in uucp if you can. I am awaiting feedback on whether this change should stay in debhelper or be rolled back. @Helmut: If you find other instances, please consider them to be in debhelper and affecting the other package until further notice. :) Thanks, ~Niels
Bug#993316: systemd: missing /lib/systemd/system/rpcbind.service file
Michael Biebl: > Hi Niels > > Am 31.08.21 um 18:07 schrieb Niels Thykier: > >> My thought is that this is not something I want in dh_link - dh_link has >> no business second guessing the link values it gets. Since dh_link runs >> after dh_installsystemd, then we cannot even rely on dh_installsystemd >> to perform a fix up either. > > Nod. > >> Which begins to smell like that either people have to update their >> dh_links calls/configuration OR we roll back the dh_installsystemd >> change to move to /usr. I am not particular fan of either. :-/ >> >> Nevertheless, I am inclined to do a rollback and then punt on the "/ -> >> /usr" migration track for now. > > I'll see if I can compile a list of possibly affected packages. > If the number is low enough, I think updating the symlink manually is > probably ok. > > Regards, > Michael > > I appreciate it, but I think we should be careful here with the manual update. If consensus on debian-devel is that debhelper should roll this back, then we will break these packages again. I do not think that would make us popular... :-/ ~Niels
Bug#993316: systemd: missing /lib/systemd/system/rpcbind.service file
Michael Biebl: > Am 30.08.21 um 18:31 schrieb Vincent Lefevre: >> Package: systemd >> Version: 247.9-1 >> Severity: critical >> Justification: breaks unrelated software >> >> systemd provides a dangling symlink: >> >> $ ls -l /lib/systemd/system/portmap.service >> lrwxrwxrwx 1 root root 15 2021-08-17 17:31:36 >> /lib/systemd/system/portmap.service -> rpcbind.service >> $ ls -L /lib/systemd/system/portmap.service >> ls: cannot access '/lib/systemd/system/portmap.service': No such file >> or directory > > This symlink is created via > > dh_link lib/systemd/system/rpcbind.service > lib/systemd/system/portmap.service > > I wonder if debhelper can do something about this or if this is one of > the cases where the package is best updated manually. > > I suspect we have a few packages which create such aliasing symlinks via > *.links files or explicit calls to dh_link > > > Niels, what's your thought on this? > > >> This breaks checkrestart: > > [...] > > Regards, > Michael > My thought is that this is not something I want in dh_link - dh_link has no business second guessing the link values it gets. Since dh_link runs after dh_installsystemd, then we cannot even rely on dh_installsystemd to perform a fix up either. Which begins to smell like that either people have to update their dh_links calls/configuration OR we roll back the dh_installsystemd change to move to /usr. I am not particular fan of either. :-/ Nevertheless, I am inclined to do a rollback and then punt on the "/ -> /usr" migration track for now. ~Niels
Bug#992508: units-filter FTBFS: dh_installdocs: error: Cannot find (any matches for) "README" (tried in ., debian/tmp)
Helmut Grohne: > Source: units-filter > Version: 4.0.1-1 > Severity: serious > Tags: ftbfs > X-Debbugs-Cc: debhel...@packages.debian.org > > units-filter fails to build from source. A build ends with: > > |dh_installdocs > | dh_installdocs: error: Cannot find (any matches for) "README" (tried in ., > debian/tmp) > | > | make: *** [debian/rules:15: binary] Error 25 > | dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned > exit status 2 > > This is reproduced on crossqa: http://crossqa.debian.net/src/units-filter > > Helmut > Hi, For reference, the underlying issue is that upstream renamed the README to README.rst while the docs file has not been updated to match. Thanks, ~Niels
Bug#980903: debhelper: doc-base doc-id deduplication does not work as documented with multiple "dh_installdocs -p" calls; causes /usr/share/doc-base/ to be installed multiple times
Axel Beckert: > Package: debhelper > Version: 13.3.1 > Severity: serious > Justification: Causes file conflicts within binary packages of the same > source package > Control: block 961757 by -1 > > > [...] Hi Axel, Thanks for filing the bug. I have not examined this fully and I do not expect to be diving into the details here any time soon. Personally, it seems a bit like a "last minute bug" and I am do not feel I have the necessary spoons to tackle it (or rather any fall out if it goes less than perfectly smooth). As it seems urgent to you and I suspect you have researched this (at least much better than I will have energy to do for now), I am fine with letting you manage it from here if you wish to do that. Assuming you wish to have this fixed for bullseye, then I propose the following: 1) Please base your work on debhelper's master branch. It is mostly typo fixes and translation work. Please do commit directly to the master branch. 2) I will expect you to handle the relevant release engineering (i.e. uploads, unblock requests as necessary, etc.) along with tackling regressions for this feature should any occurs. (Feel free to upload debhelper using "Team Upload" rather than "NMU" rules.) 3) Please do a call for updates to existing translations once you are done or certain you will not need any more updates to the manpages. - I am fine with doing a translation-only update after you are done, so you do not need to follow up on that (unless you change strings after the calls for translations). I assume you are aware that it affects *every* doc-base package in the archive and with the freeze approaching "work around sometimes required" is better than "FTBFS bugs in packages that used to work". Let me know if this arrangement sounds good to you or propose alternatives. Thanks for considering, ~Niels
Bug#957206: dh_testroot: error: Package needs targeted root but builder has not provided a gain-root command via ${DEB_GAIN_ROOT_CMD}
Andreas Tille:
> Control: tags -1 pending
>
> Hi,
>
> upstream of fis-gtm package[1] confirmed that the build needs some root
> permissions. Thus I've set
>
>Rules-Requires-Root: yes
>
> When trying to build with pbuilder I get:
>
>dh_testroot
> dh_testroot: error: Package needs targeted root but builder has not provided
> a gain-root command via ${DEB_GAIN_ROOT_CMD}
> make: *** [debian/rules:21: binary] Error 25
>
>
> How can this be fixed?
>
> Kind regards
>
> Andreas.
>
>
> [1] https://salsa.debian.org/med-team/fis-gtm
>
You want "Rules-Requires-Root: binary-targets".
~Niels
Bug#972813: xournal FTBFS: wrongly declared R³
Guillem Jover: > Hi! > > On Sat, 2020-10-24 at 11:54:54 +0200, Niels Thykier wrote: >> Rather, I suspect the issue is that Rules-Requires-Root is set to "No" >> rather than "no". AFAICT, only "no" has been defined and it is >> interpreted case sensitively. > > Right, and even though this is described in the deb822(5) man page, it > is not explicitly spelled out in the various specific file format man > pages, so I've clarified that there. Also added more clear references > to deb822(5) in the relevant man pages. Patches attached. > >> @Guillem/Dpkg Maintainers: Should we provide stricter validation for >> this to stop this at dpkg-source build time ? > > Yeah, I think that make sense, as dpkg-buildpackage is already > erroring out on unknown values for «dpkg/» namespaced keywords. So I > prepared the attached patch to do this too. > > Thanks, > Guillem > Thanks. My pedantic nit would be to have dpkg-buildpackage be explicit in what it expects if it already knows the right answer (which it does in this case). E.g. "R³ field keyword No is uppercase. Please use no instead" Saves people a round-trip through the manual if they are unsure about how to fix the error. We should probably also add a special-case check for "yes" which I have seen in the wild. ~Niels
Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade
Control: reassign -1 perl-base Control: affects -1 upgrade-reports Control: severity -1 grave Hi Perl team, I have reassigned this bug to perl because perl-base being essential must remain functional during an upgrade and AFAICT perl-base fails in this case here. If it is a direct linkage, then you might be needing a Pre-Depends. If it is an indirect linkage then I am not sure how to fix it. :-/ ~Niels Alois Wohlschlager: > Package: upgrade-reports > Severity: critical > Justification: breaks the whole system > X-Debbugs-Cc: alo...@gmx-topmail.de > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > >Do an upgrade from buster to bullseye. > > >* What exactly did you do (or not do) that was effective (or > ineffective)? > >1. adjust sources.list >2. apt upgrade >3. apt dist-upgrade > >* What was the outcome of this action? > >apt dist-upgrade goes horribly wrong. Excerpt from the log: > > --- > Entpacken von libc6:amd64 (2.31-4) über (2.28-10) ... > Vormals nicht ausgewähltes Paket libc6:i386 wird gewählt. > Vorbereitung zum Entpacken von .../4-libc6_2.31-4_i386.deb ... > Entpacken von libc6:i386 (2.31-4) ... > Vormals nicht ausgewähltes Paket libgcc-s1:i386 wird gewählt. > Vorbereitung zum Entpacken von .../5-libgcc-s1_10.2.0-16_i386.deb ... > Entpacken von libgcc-s1:i386 (10.2.0-16) ... > Vormals nicht ausgewähltes Paket gcc-10-base:i386 wird gewählt. > Vorbereitung zum Entpacken von .../6-gcc-10-base_10.2.0-16_i386.deb ... > Entpacken von gcc-10-base:i386 (10.2.0-16) ... > /usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot > open > shared object file: No such file or directory > dpkg: Fehler: Fehler beim Ausführen des Hooks »if [ -x /usr/share/debian- > security-support/check-support-status.hook ] ; then /usr/sh > are/debian-security-support/check-support-status.hook ; fi«, Exitkode 32512 > --- > >At this point, perl is still the version from buster, and libcrypt1 is not > yet installed. The missing libcrypt.so.1 also completely breaks PAM, so login > and sudo don't work any more. >To recover from this outcome, I had to boot with "init=/bin/sh", install > the > libcrypt1 package with dpkg and run "apt -f install" twice. This rendered the > system operational again and a further "apt dist-upgrade" ran through > smoothly. > >* What outcome did you expect instead? > >libcrypt1 is installed before libcrypt.so.1 is required again, so the dist- > upgrade can proceed normally. > > [...]
Bug#972813: xournal FTBFS: wrongly declared R³
On Sat, 24 Oct 2020 11:49:46 +0200 Helmut Grohne wrote: > Source: xournal > Version: 1:0.4.8.2016-6 > Severity: serious > Tags: ftbfs > > xournal fails to build from source on buildds, because it wrongly > declares that it doesn't need root while in fact it does issue > dh_testroot. Dropping the R³ line from control should fix that. > > Helmut > > > Rather, I suspect the issue is that Rules-Requires-Root is set to "No" rather than "no". AFAICT, only "no" has been defined and it is interpreted case sensitively. Presumably, this could also be fixed by using the correct case for "no". @Guillem/Dpkg Maintainers: Should we provide stricter validation for this to stop this at dpkg-source build time ? ~Niels
Bug#962253: debhelper: dh_installman error instead of warning on invalid section
Control: reassign -1 esys-particle Control: retitle -1 esys-particle: Broken section number in manpage Adrian Bunk: > On Fri, Jun 05, 2020 at 07:55:33AM +0200, Niels Thykier wrote: >> Adrian Bunk: >>> Source: debhelper >>> Version: 13.1 >>> Severity: serious >>> Control: affects -1 src:esys-particle >>> Control: block 961995 by -1 >>> >>> https://buildd.debian.org/status/package.php?p=esys-particle >>> >>> ... >>>dh_installman -a >>> dh_installman: warning: Section for ./debian/esysparticle.1 is computed as >>> "2012-12-30", which is not a valid section >>> dh_installman: error: Could not determine section for >>> ./debian/esysparticle.1 >>> dh_installman: error: Aborting due to earlier error >>> make: *** [debian/rules:15: binary-arch] Error 25 >>> >>> >>> debhelper (13.1) unstable; urgency=low >>> ... >>> * dh_installman: Improve error messages and handling of broken >>> section numbers. Notably ignore (with a warning) sections from >>> manpages that look suspiciously like a version number. Thanks >>> to Paul Gevers for reporting the bug. (Closes: #958343) >>> ... >>> >> >> Hi Adrian, > > [...]>> Prior to that error, dh_installman silently installed it in >> /usr/share/man/man2, which would clearly have been wrong: >> >> """ >> $ apt-file show esys-particle | grep share/man/ >> esys-particle: /usr/share/man/man2/esysparticle.2012-12-30.gz >> """ >> >> Based on this, can we agree that this and future instances you find of >> this case should in general be filed against packages containing the >> manpage rather then debhelper? > > My reading of the debhelper changelog was that "ignore (with a warning)" > means that this was not intended to cause an error. > > I might have misunderstood that. > > > cu > Adrian > I see how this could have caused the confusion. I will update the changelog to better reflect the reality. The "ignore" here refers to the auto-detected section number and not the manpage itself. Without a well-defined section number, dh_installman would then stop with an error (which it has always done - it is just more picky in its auto-detection mechanism). Related, I have reassigned this bug to esys-particle. ~Niels
Bug#962253: debhelper: dh_installman error instead of warning on invalid section
Adrian Bunk: > Source: debhelper > Version: 13.1 > Severity: serious > Control: affects -1 src:esys-particle > Control: block 961995 by -1 > > https://buildd.debian.org/status/package.php?p=esys-particle > > ... >dh_installman -a > dh_installman: warning: Section for ./debian/esysparticle.1 is computed as > "2012-12-30", which is not a valid section > dh_installman: error: Could not determine section for ./debian/esysparticle.1 > dh_installman: error: Aborting due to earlier error > make: *** [debian/rules:15: binary-arch] Error 25 > > > debhelper (13.1) unstable; urgency=low > ... > * dh_installman: Improve error messages and handling of broken > section numbers. Notably ignore (with a warning) sections from > manpages that look suspiciously like a version number. Thanks > to Paul Gevers for reporting the bug. (Closes: #958343) > ... > Hi Adrian, I do not understand how you came to the conclusion that because esys-particle has a completely broken manpage then debhelper should have an RC bug. Prior to that error, dh_installman silently installed it in /usr/share/man/man2, which would clearly have been wrong: """ $ apt-file show esys-particle | grep share/man/ esys-particle: /usr/share/man/man2/esysparticle.2012-12-30.gz """ Based on this, can we agree that this and future instances you find of this case should in general be filed against packages containing the manpage rather then debhelper? ~Niels
Bug#960907: dothost: CI test fails due to layout changes but is flagged as a debhelper regression
Package: dothost Severity: serious Control: affects -1 src:debhelper The dothost CI test has the following output: > """ > Removing autopkgtest-satdep (0) ... > autopkgtest [08:29:06]: test command1: dothost www.debian.org | graph-easy > --as boxart || exit 77 > autopkgtest [08:29:06]: test command1: [--- > Warning: Layouter could only place 10 nodes/14 edges out of 10/15 - giving up > at /usr/bin/graph-easy line 144. > >┌──┐ > ┌───┐ >∨ │ ∨ >│ > ┌┐ ┏┓ > ┌─┐ ┌─┐ > ┌─┐ > │ 149.20.4.15 │ <┐ ┃┃ ──> │ > 128.31.0.62 │ ──> │ mirror-csail.debian.org │ ──> │ > 2603:400a::bb8::801f:3e │ ─┐ > └┘ │ ┃┃ > └─┘ └─┘ > └─┘ │ >│ │ ┃┃ >∧ ∧ > │ >│ │ ┃ www.debian.org ┃ > ──┼───┘ >│ >∨ │ ┃┃ >│ > │ > ┌┐ │ ┃┃ >│ > │ > ┌> │ mirror-isc3.debian.org │ ─┘ ┃┃ > ─┐ > └──┘ > │ └┘ ▙▟ > │ > ││ │ > │ > ││ │ > │ > │∨ ∨ > │ > │ ┌┐ ┌┐ > ┌─┐ │ > └─ │2001:4f8:1:c::15│ │ 130.89.148.77 │ ──> │ > klecker-misc.debian.org │ │ > └┘ └┘ > └─┘ │ > ┌┐ > │ > │ 2001:67c:2564:a119::77 │ > <┘ > └┘ > autopkgtest [08:29:14]: test command1: ---] > autopkgtest [08:29:14]: test command1: - - - - - - - - - - results - - - - - > - - - - - > command1 FAIL stderr: Warning: Layouter could only place 10 > nodes/14 edges out of 10/15 - giving up at /usr/bin/graph-easy line 144. > autopkgtest [08:29:14]: test command1: - - - - - - - - - - stderr - - - - - > - - - - - > Warning: Layouter could only place 10 nodes/14 edges out of 10/15 - giving up > at /usr/bin/graph-easy line 144. > autopkgtest [08:29:14]: test command2: preparing testbed > """ https://ci.debian.net/data/autopkgtest/testing/arm64/d/dothost/5540910/log.gz I presume it is related to dothost resolving "www.debian.org" and it suddenly has more IPs and hostnames to render instead of having fixed test data. Sadly, this is considered a "regression caused by debhelper" by the CI/Britney framework as the problem occurred after the previous baseline test of dothost. ~Niels
Bug#960405: mscgen: FTBFS and debci failure
Control: reassign -1 mscgen,libgd3 Control: affects -1 mscgen control: retitle -1 mscgen crashes after libgd3 upload On Tue, 12 May 2020 13:16:59 +0300 Adrian Bunk wrote: > Source: mscgen > Version: 0.20-13 > Severity: serious > Tags: ftbfs > > https://ci.debian.net/packages/m/mscgen/unstable/amd64/ > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mscgen.html > > [...] This started after libgd3 was uploaded to unstable. Related #959591 ~Niels
Bug#959591: marked as done (mscgen: FTBFS: dh_auto_test: error: cd _build && make -j4 check VERBOSE=1 returned exit code 2)
Control: reassign -1 libgd2 Control: affects -1 mscgen (Re-assigning this to libgd3 because that is where the original bug was found and fixed). Ondřej Surý: > My very quick guess would be that in the last case `-1` is returned > and therefore mscgen fails on `realloc(ptr, -1)`. I guess this needs > to be fixed in the mscgen. > > libgd2 is such a mess :-(. (Actually, all the graphics libraries are such > a mess :-(…) > > Ondrej > -- > Ondřej Surý > ond...@sury.org > > [...] No, we literally crash on when calling realloc(ptr, 48), which is why I suspect a memory corruption. That is only for the case where the realloc is called by mscgen. In the other case, where libgd chokes on its own, I do not know what it passed to realloc. I strongly suspect there is another bug in libgd3. Thanks, ~Niels
Bug#959591: mscgen: FTBFS: dh_auto_test: error: cd _build && make -j4 check VERBOSE=1 returned exit code 2
Ondřej Surý:
> Hi Lucas,
>
> this: https://github.com/libgd/libgd/issues/615 ?
>
>[...]
>
Hi Ondřej,
Thanks for the link. It indeed looks related and if I special case
0-sized strings in mscgen, the error goes away (see attached patch).
Should I apply this patch to mscgen, or should this be fixed in libgd2?
~Niels
diff --git a/src/gd_out.c b/src/gd_out.c
index 64d82b2..34451f9 100644
--- a/src/gd_out.c
+++ b/src/gd_out.c
@@ -194,6 +194,12 @@ unsigned int gdoTextWidth(struct ADrawTag *ctx,
int rect[8] = { 0, 0, 0, 0, 0, 0, 0, 0 };
const char *r;
+/* Work around https://github.com/libgd/libgd/issues/615 */
+if (string[0] == '\0')
+{
+ return 0;
+}
+
r = gdImageStringFT(NULL,
rect,
context->pen,
@@ -297,6 +303,11 @@ void gdoTextR(struct ADrawTag *ctx,
int textWidth;
textWidth = gdoTextWidth(ctx, string);
+/* Work around https://github.com/libgd/libgd/issues/615 */
+if (textWidth == 0)
+{
+return;
+}
/* Range check since gdImageFilledRectangle() takes signed values */
if(x + textWidth <= INT_MAX && y <= INT_MAX)
Bug#959591: mscgen: FTBFS: dh_auto_test: error: cd _build && make -j4 check VERBOSE=1 returned exit code 2
Lucas Nussbaum: > Source: mscgen > Version: 0.20-13 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200501 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > Hi Ondřej, You broke my stuff! :) Seriously though, it seems the recent libgd2 upload broke mscgen (also visible in the autopkgtest blocking libgd2 from transitioning to testing). I checked the upstream changelog and cannot see an obvious change related to the function that fails. The test case in question is a rather lengthy string shoved into "gdImageStringFT" trying to determine how wide the string will be (so mscgen can figure out how to render it). Help figuring out what broke would be nice as the error "Problem doing text layout" is not very helpful in debugging the issue. ~Niels > Relevant part (hopefully): >> make[4]: Entering directory '/<>/_build/test' >> FAIL: renderercheck.sh >> == >>mscgen 0.20: test/test-suite.log >> == >> >> # TOTAL: 1 >> # PASS: 0 >> # SKIP: 0 >> # XFAIL: 0 >> # FAIL: 1 >> # XPASS: 0 >> # ERROR: 0 >> >> .. contents:: :depth: 2 >> >> FAIL: renderercheck.sh >> == >> >> testinput0.msc >> testinput1.msc >> testinput10.msc >> testinput11.msc >> testinput12.msc >> testinput13.msc >> testinput14.msc >> testinput15.msc >> testinput16.msc >> testinput17.msc >> Error: gdoTextWidth: Problem doing text layout (GDFONTPATH=) >> FAIL renderercheck.sh (exit status: 1) >> >> >> Testsuite summary for mscgen 0.20 >> >> # TOTAL: 1 >> # PASS: 0 >> # SKIP: 0 >> # XFAIL: 0 >> # FAIL: 1 >> # XPASS: 0 >> # ERROR: 0 >> >> See test/test-suite.log >> Please report to michael.mcternan.2...@cs.bris.ac.uk >> >> make[4]: *** [Makefile:495: test-suite.log] Error 1 >> make[4]: Leaving directory '/<>/_build/test' >> make[3]: *** [Makefile:603: check-TESTS] Error 2 >> make[3]: Leaving directory '/<>/_build/test' >> make[2]: *** [Makefile:676: check-am] Error 2 >> make[2]: Leaving directory '/<>/_build/test' >> make[1]: *** [Makefile:421: check-recursive] Error 1 >> make[1]: Leaving directory '/<>/_build' >> dh_auto_test: error: cd _build && make -j4 check VERBOSE=1 returned exit >> code 2 > > The full build log is available from: >http://qa-logs.debian.net/2020/05/01/mscgen_0.20-13_unstable.log > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > About the archive rebuild: The rebuild was done on EC2 VM instances from > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every > failed build was retried once to eliminate random failures. >
Bug#959421: debhelper 13 complains about source files missing in the binary of ebumeter
Control: severity -1 normal Control: tags -1 moreinfo Dennis Braun: > Package: debhelper > Version: 13 > Severity: serious > Tags: upstream ftbfs > Justification: fails to build from source > > Dear Maintainer, > > when upgrading to dh 13 with ebumeter, dh complains about source files from > ebumeter/source missing in the binary. > > https://salsa.debian.org/multimedia-team/ebumeter > > Best regards, > Dennis > > > [...] Hi Dennis, This bug report leaves me with very mixed feelings. The report has no details of what you did other than a vague "Upgrading to dh" which is ambiguous (did you upgrade to debhelper 13 or bump compat level to 13? There is a major difference between the two). There are no details of what you did to understand the problem nor any mention of unclear documentation from debhelper's documentation. This leaves me with the feeling that you bumped the compat level without reading the relevant documentation and when it broke you shoved the broken pieces to me with an implicit "Please fix this for me!". This is hopefully not what you intended to do. In the future, I would recommend you provide a bit more details on what you have tried to do or/and which part of the documentation that you do not feel match the reality you see. This would leave me with less guess work and also less likely to come to the above assumption that cannot be part of a fruitful discussion on how we fix the issue you experience. *Moving on* Pushing that aside, lets move on to ebumeter. I presume what you were experiencing was that dh_missing terminated when an error as it now defaults to --fail-missing instead of --list-missing. This is documented in "man 7 debhelper" under "Supported compatibility levels" (see the "v13" / "Changes from v12" entry). Related, dh_missing emits the same warnings already under compat 12, which is an early warning and would have enabled you to fix this problem ahead of time. I can recommend checking the build logs for warnings before bumping compat levels. At this point, we might be tempted to just neuter the dh_missing issue (instructions are in "man 7 debhelper") and move on. However, I recommend that you fix the root cause, which in this case involves the --sourcedir parameter to dh and some follow up fixes. *The root cause for ebumeter* The "--sourcedir" parameter is accepted by dh_install AND the dh_auto_* commands. But in ebumeter, it *seem* to be used to make sure dh_auto_* pick up the upstream source files directly. This can be done by using the longer form "--sourcedirectory", which only dh_auto_* responds to[1]. This will trigger some errors from the .install and .manpages files because the "../" hack does not work any longer. That said, it is unneeded and simply removing "../" will work because the relevant dh_install* helpers will fall back to the source root when they do not get the --sourcedir parameter. These changes should also work in compat 12, so you can try them out without bumping to compat 13 and see all the dh_missing warnings disappear. Note: I have made no attempts to check if the package work after these changes and include every thing as you would expect. I leave that to you. *In summary* I do not see a bug in debhelper, only a failed attempt to migrate to compat 13 (which I have provided suggestions on how to fix). Should you find that the documentation for bumping compat levels is unclear or have suggestions to improve it, please let me know and I will look at fixing it. ~Niels [1] Yes, it is confusing that --sourcedir is picked up by both dh_install + dh_auto_*.
Bug#948643: apt-file: fails to update
Control: reassign -1 command-not-found Control: affects -1 apt-file Anthony M.R. Alvis: > Package: apt-file > Version: 3.2.2 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > I have attached a text file containing what happens after i run sudo apt-file > update; > > [...] The error comes from command-not-found's hook into the apt update process - reassigning accordingly. @Julian: There is a log file in the original report. Note the report appears to come from a "Raspbian GNU/Linux 10 (buster)" in case that helps. Thanks, ~Niels
Bug#943705: dh_installman: man-recode integration gets confused if both foo.1 and foo.1.gz exist
Colin Watson: > Package: debhelper > Version: 12.7.1 > Severity: important > > rumur FTBFS with debhelper 12.7.1 and man-db 2.9.0-1. Running the > binary target manually with DH_VERBOSE=1, I see the following at the > end: > > [...] > Hi Colin, Thanks for filing this bug. I think you have spotted a case of (unintentional) undefined behaviour in debhelper. > [...] > > Of course, rumur could easily work around this by removing > debian/rumur.manpages, but I assume debhelper doesn't want to create > this kind of regression. Before man-recode existed, the net effect > would have been that only the last of a group of files that differ only > by compression extension is considered. For compatibility purposes, I > think the logic in reencode_manpages will need to be adjusted to > preserve this property. > > Thanks, > Rather, I would argue that the result is "it depends(tm)". Your statement is true only when @manpages_to_reencode is constructed deterministically AND when the conflicting definitions end up in the same "parallelization bucket". However: 1) If the two conflicting definitions of the manpages end in different buckets when calling "on_items_in_parallel", then all bets are off and you get a standard race-condition. In best case, you get "one" of the input files - worst case, corrupted manpages. 2) Even then, the construction of @manpages_to_reecode depends on the order returned by filesystem (File::Find does not sort the result readdir by default; this has to be done by the preprocess option) 3) Even if the order in 2) is stable (but not sorted), the build putting the files there may be unstable due to parallelism. (prior to adding parallelization in 10.2.X, we "only" suffered from 2+3) I think the proper solution here is to either pick a "winner" deterministically OR reject the situation as a conflict and have the packager sort out the issue. I am learning towards the latter as a long term solution (compat 13) and the former as a short term (current compat levels). Suggestions/feedback welcome. Thanks, ~Niels
Bug#941128: xorg-server FTBFS
Control: reassign -1 xorg-server Control: retitle -1 xorg-server: build target must depend on build-* Control: tags -1 ftbfs Timo Aaltonen: > Package: debhelper > Severity: important > > Hi, debhelper 12.4 was fine but the current one broke xorg-server build, > build-indep isn't run at all. With the old version it was run right in > the beginning: > > dh build --with quilt,autoreconf --parallel >debian/rules build-indep > make[1]: Entering directory '/<>' > mkdir -p build-source > tar \ > --owner=0 --group=0 \ > --transform 's,^,xorg-server/,' \ > --exclude=debian \ > --exclude=autom4te.cache \ > -cf - * | xz > build-source/xorg-server.tar.xz > tar: build-source/xorg-server.tar.xz: file changed as we read it >> build-source-stamp > dh build-indep --with quilt,autoreconf --parallel >dh_quilt_patch -i -O--parallel > Applying patch 001_fedora_extramodes.patch > patching file hw/xfree86/common/extramodes > ... > > but now it's skipped: > > dh build --with quilt,autoreconf --parallel >dh_quilt_patch -O--parallel > Applying patch 001_fedora_extramodes.patch > patching file hw/xfree86/common/extramodes > ... > > > Hi, This problem is fundamentally caused by xorg-server's "build" target not invoking build-arch and build-indep (eventually). The xorg-server package is assumed to invoke all relevant build steps as a part of the build target itself but it fails to do the build-arch and build-indep steps as a part of its build target. Previous debhelper behaviour just happened to work around that issue. Thanks, ~Niels
Bug#935290: moar digging
On Wed, 11 Sep 2019 07:21:24 +0200 Robert Lemmen wrote: > ...and it's fakeroot! it does ld_preload to map file user ids, and doing > that it fakes stat calls, but not statx! > > regards robert > > -- > Robert Lemmen http://www.semistable.com Does rakudo build with "Rules-Requires-Root: no"[1]? If it does, then you can work around the bug / issue in fakeroot for sid, testing and stable for now by using it. Thanks, ~Niels [1] Assumes you do not need static ownerships or any chown calls during package build/installation.
Bug#933715: jh_linkjars: dpkg -L "debhelper-compat" returned exit code 1
Control: severity -1 important On Fri, 02 Aug 2019 14:05:25 +0200 Markus Koschany wrote: > Package: javahelper > Version: 0.72.9 > Severity: serious > > > jh_linkjars apparently chokes on the new debhelper-compat package. > Since it is not a real package dpkg -L does not work. I presume the > workaround is to either add debhelper-compat to a blacklist or to find > a more general way to not use dpkg -L on virtual packages. > > This bug can be reproduced by switching to debhelper-compat = 12, e.g. > in lombok-patcher. > > > [...] While it is certainly an annoying bug, it is possible to use debhelper compat 12 without relying on the virtual package. Obviously, it would be best if it was fixed ... :) Thanks, ~Niels
Bug#935017: debhelper breaks strip-nondeterminism autopkgtest
Control: reassign -1 strip-nondeterminism On Sun, 18 Aug 2019 08:19:37 +0200 Paul Gevers wrote: > Source: debhelper, strip-nondeterminism > Control: found -1 debhelper/12.5.1 > Control: found -1 debhelper/12.5 > Control: found -1 strip-nondeterminism/1.5.0-1 > Severity: serious > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: breaks needs-update > > Dear maintainers, > > With a recent upload of debhelper the autopkgtest of > strip-nondeterminism fails in testing when that autopkgtest is run with > the binary packages of debhelper from unstable. It passes when run with > only packages from testing. In tabular form: >passfail > debhelper from testing12.5.1 > strip-nondeterminism from testing1.5.0-1 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration of debhelper to > testing [1]. Due to the nature of this issue, I filed this bug report > against both packages. Can you please investigate the situation and > reassign the bug to the right package? > > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [1] https://qa.debian.org/excuses.php?package=debhelper > > https://ci.debian.net/data/autopkgtest/testing/amd64/s/strip-nondeterminism/2758965/log.gz > > 1..2 > not ok 1 - bin/dh_strip_nondeterminism --help returns 255 > > # Failed test 'bin/dh_strip_nondeterminism --help returns 255' > # at t/binaries.t line 42. > ok 2 - bin/strip-nondeterminism --help returns 0 > # Looks like you failed 1 test of 2. > I cannot reproduce this locally in a sane way. For me, it returned 1 before and after upgrading to debhelper/12.5.1 (from 12.4). Digging in the tests, it looks like strip-nondeterminism is *not* testing the installed binaries[1]. So for now I am punting it to strip-nondeterminism (even if only on a technicality). If you can dig out the real problem, please reassign back/file a bug as appropriate. Thanks, ~Niels [1]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism/blob/master/t/binaries.t
Bug#935016: [Pkg-javascript-devel] Bug#935016: pkg-js-tools: An unannounced change in "debhelper" breaks pkg-js-tools
Control: reassign -1 debhelper Control: affects -1 pkg-js-tools Xavier: > Le 18/08/2019 à 08:15, Xavier a écrit : >> [...] >> >> Works fine until debhelper 12.5. Then dh returns: >> >> dh: unable to load addon nodejs: Debian/Debhelper/Sequence/nodejs.pm >> did not return a true value at (eval 13) line 1. >> BEGIN failed--compilation aborted at (eval 13) line 1. >> >> >> Next debug: >> # perl -le 'use Debian::Debhelper::Sequence::nodejs' >> Undefined subroutine ::add_command_options called at >> /usr/share/perl5/Debian/Debhelper/Sequence/nodejs.pm line 8. >> >> [...] Thanks for debugging this. This is a regression in debhelper that broke pkg-js-tools and nothing else. Thanks, ~Niels
Bug#935016: pkg-js-tools: An unannounced change in "debhelper" breaks pkg-js-tools
Control: tags -1 moreinfo On Sun, 18 Aug 2019 07:55:59 +0200 Xavier Guimard wrote: > Package: pkg-js-tools > Version: 0.9.5 > Severity: grave > Justification: renders package unusable > > pkg-js-tools was based on add_command_options which disappears in > Debhelper 12.5.1. This renders pkg-js-tools unusable. > > Hi, No, add_command_options has not been (intentionally?) removed in debhelper 12.5.1. Could you please clarify what made you file this bug? Did you get an error/did something break? Thanks, ~Niels
Bug#934821: fcm: usr/bin/fcm_test_battery uses invalid interpreter (/usr/bin/bash instead of /bin/bash)
Package: fcm Version: 2019.05.0-1 Severity: serious Hi, Found by lintian and confirmed manually; the fcm_test_battery script installed into the default PATH uses /usr/bin/bash as interpreter. This only works on /usr-merged systems. However, Debian systems cannot be assumed to have been /usr-merged. """ #!/usr/bin/bash #--- # Copyright (C) 2006-2019 British Crown (Met Office) & Contributors. # """ Thanks, ~Niels
Bug#934034: monkeysphere: FTBFS in stretch
Chris Lamb: > [Correctly adding t...@release.debian.org to CC...] > > Hi Santiago, > >> For completeness I would also make the build-dependency on gnupg to be >> versioned. > > Good idea; updated patch attached. > > Stable release managers, would you consider this for the next stretch > point release? > > > Regards, > Hi Chris, Thanks for considering to fix bugs in stretch. Please use the process described in [1] to ensure we will get to look at it: 1) The current bug metadata suggests it affects sid. Please ensure the bug is resolved in sid (by fixing it in sid or correcting bug metadata as appropriate). 2) File an opu (and a separate pu bug if it also affects buster) with the full debdiff (including changelog). This ensures that the stable release team will get have a look at the issue. We are quite insisting on 2) as it is very hard for us to keep track of non-bugs requests. This is a lesson learned time and again (both for us and Debian contributors). As for your concrete diff (IANASRM, but my personally take is that): It looks like something we would accept as stable update. Note that [1] describes some short cuts that may or may not be applicable to your situation. Thanks, ~Niels [1] https://lists.debian.org/debian-devel-announce/2019/08/msg0.html
Bug#932073: closed by Niels Thykier (Bug#932073: fixed in debhelper 12.2.1)
Helmut Grohne: > Control: reopen -1 > Control: affects -1 + src:dropbear > > On Tue, Jul 16, 2019 at 08:42:09PM +, Debian Bug Tracking System wrote: >>* dh_installinit: Fix regression where dh_installinit bailed >> out on --name if only one of the acted on packages had an >> init script file. Thanks to Helmut Grohne for reporting >> the issue. (Closes: #932073) > > The bug is partially fixed. A full build of openssh and dropbear now > works. At least the following situation (dropbar) is still broken: > > The init script lives in an arch-all package, you pass the relevant > --name and you perform an arch-only build. Here is a cross build log, > but it fully reproduces natively: > > http://crossqa.debian.net/build/dropbear_2019.78-1_mips_20190717050430.log > > I'm also confused by the following message: > > dh_link: No packages to build. Architecture mismatch: amd64, want: all any > > It happens both during native and during cross builds of dropbear. I > would have assumed that "amd64" and "mips" match the "any" part of "all > any". I'd appreciate if someone could enlighten me about this aspect. > > Helmut > Thanks reopening the bug. I have considered it for a while and I think the correct answer is to take a step back and consider whether this is truly the best approach (e.g. Guillem filed #932152 as an alternative that completely replaces --name and the related issues). Accordingly, I will revert the change and reopen #462389. For reference, I am aware of at least 3 suggested changes/patches related to this bug after Helmut reopened it. (Those are Dmitry's follow plus two independent merge requests on salsa). Thanks, ~Niels
Bug#932073: dh_installinit fails with "--name=foo option specified, but init script not found"
Helmut Grohne: > Package: debhelper > Version: 12.2 > Severity: serious > Tags: ftbfs > Control: affects -1 + src:openssh src:util-linux > User: helm...@debian.org > Usertags: rebootstrap > > debhelper 12.2 fixes #462389 and makes dh_installinit fail when the > --name'd init script does not exist. This behaviour change makes at > least openssh and util-linux FTBFS. These are two high popcon example > packages. I expect more. > > It is unclear to me whether it can be fixed in debhelper at all. Yet I > am filing the bug to have something recorded. If you determine that this > should be fixed in the individual packages, please clone and reassign. > > Helmut > Hi Dmitry, This report seems to be a regression related to your patch from #462389. Of the two issues spotted: * openssh: Could be fixed by having openssh pass -p openssh-server to dh_installinit AFAICT (not tested) * util-linux: It does something "funky" where I am not really sure what the best solution is[1] Could you please have a look at it? If you do not have time to look at it in a short timeframe, then please let me know. In that case, I will prefer to revert the patch for now to avoid having breakage for too long. Thanks, ~Niels [1]: from d/rules: """ # install /etc/init.d/hwclock.sh dh_installinit --name=hwclock.sh --no-start # install /etc/default/hwclock dh_installinit --name=hwclock """ It contains the following related packaging files AFAICT: debian/util-linux.hwclock.default debian/util-linux.hwclock.sh.init Source: * https://salsa.debian.org/debian/util-linux/blob/master/debian/rules * https://salsa.debian.org/debian/util-linux/tree/master/debian
Bug#931985: file: Experimental file breaks package creation at dh_shlibdeps stage due to file command
On Sat, 13 Jul 2019 14:33:00 +0200 Christoph Biedl wrote: > Control: tags 931985 pending > > So here's the story: The dh_shlibdepends program runs under fakeroot, > and libfakeroot will be loaded be the file binary as well. Nothing new. > > Enter seccomp: The version of file in experimental is the first one to > have seccomp support enabled. The syscalls used by libffakeroot are not > whitelisted, so msgsend or getpid case program abort. You should have > seen according messages in the kernel log as well. > > A sane solution will take time. For the moment the only sane choice will > do to re-disable seccomp support. > > Christoph Is it possible to patch the code to skip the seccomp support only under fakeroot? While we are slowly reducing the number of packages relying on fakeroot, it will probably take a decade or more to be completely free from it. But I think it would be unfortunate not to have the seccomp filtering until then. Thanks, ~Niels
Bug#928770: sqlite3: CVE-2019-5018: Window Function Remote Code Execution Vulnerability
On Thu, 16 May 2019 20:09:52 +0200 =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote: > Hi, > > On Thu, May 16, 2019 at 11:57 AM Pirate Praveen > wrote: > > On Fri, 10 May 2019 21:04:33 +0200 Salvatore Bonaccorso > > wrote: > > > Source: sqlite3 > > > The following vulnerability was published for sqlite3. > > > CVE-2019-5018[0]: > > > Window Function Remote Code Execution Vulnerability > > Could this be that commit? I have not checked thoroughly only looked at > > the commit message. > > > > "Prevent aliases of window functions expressions from being used as > > arguments to aggregate or other window functions." > > > > https://sqlite.org/src/info/1e16d3e8fc60d39c > Can be, but not sure. At least four sqlite 3.x issues reported > recently and as I know, usually upstream is not informed about these. > :-/ > > > > [1] > > > https://www.talosintelligence.com/vulnerability_reports/TALOS-2019-0777 > > Regards, > Laszlo/GCS > > According to the TALOS link from the initial mail, TALOS informed the vendor and the vendor provided on the same day as that commit. """ Timeline 2019-02-05 - Vendor Disclosure 2019-03-07 - 30 day follow up with vendor; awaiting moderator approval 2019-03-28 - Vendor patched 2019-05-09 - Public Release """ So this implies that there is a patch and it would be dated no later than 2019-03-28 (caveat emptor: Time zones). It *might* be fixed in 3.28 (TALOS does not mention it as vulnerable), but the changelog does not mention this explicit[1]. Alternatively, it could be related to: https://www.sqlite.org/src/info/4feb3159c6bc3f7e33959 This was released as a part of 3.27.2 and looks like it has the right text as well. What concerns me is that the ticket[0] is almost a week before TALOS's timeline for "Vendor patched" plus it mentioned "free that has not been malloc'ed" rather than "use after free". That said, the test case examples for both issue are similar. Thanks, ~Niels [0] Related and correct commit appears to be: https://www.sqlite.org/src/info/a21ffcd8176672e7 (Based on https://www.sqlite.org/src/info/579b66eaa0816561) [1] https://www.sqlite.org/draft/changes.html
Bug#923592: marble: diff for NMU version 4:17.08.3-3.2
Control: tags 923592 + patch Control: tags 923592 + pending Dear maintainer, I've prepared an NMU for marble (versioned as 4:17.08.3-3.2) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. diff -Nru marble-17.08.3/debian/changelog marble-17.08.3/debian/changelog --- marble-17.08.3/debian/changelog 2018-10-27 11:38:29.0 + +++ marble-17.08.3/debian/changelog 2019-05-18 07:16:42.0 + @@ -1,3 +1,13 @@ +marble (4:17.08.3-3.2) unstable; urgency=medium + + * Non-maintainer upload. + + [ Frédéric Bonnard ] + * Add Comment fields to the .desktop files as they are now +required by the Appstream generator. (Closes: #923592) + + -- Niels Thykier Sat, 18 May 2019 07:16:42 + + marble (4:17.08.3-3.1) unstable; urgency=low * Non-maintainer upload. diff -Nru marble-17.08.3/debian/patches/fix-923592.patch marble-17.08.3/debian/patches/fix-923592.patch --- marble-17.08.3/debian/patches/fix-923592.patch 1970-01-01 00:00:00.0 + +++ marble-17.08.3/debian/patches/fix-923592.patch 2019-05-18 07:14:54.0 + @@ -0,0 +1,34 @@ +Description: Fix FTBFS due to missing comment/description + After that commit https://phabricator.kde.org/D16867, a description is +needed in .desktop files. +The keyword actually looked for by desktoptojson converter utility is +"Comment=" . + +Author: Frédéric Bonnard +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +Index: marble-17.08.3/src/plasma/wallpapers/worldmap/metadata.desktop +=== +--- marble-17.08.3.orig/src/plasma/wallpapers/worldmap/metadata.desktop 2017-10-20 03:52:49.0 + marble-17.08.3/src/plasma/wallpapers/worldmap/metadata.desktop 2019-04-24 15:10:53.251732393 + +@@ -23,6 +23,7 @@ + Name[x-test]=xxWorld Mapxx + Name[zh_CN]=ä¸çå°å¾ + Name[zh_TW]=ä¸çå°å ++Comment=Shows a map of the world as wallpaper + Type=Service + Icon=marble + +Index: marble-17.08.3/src/plasma/applets/worldclock/package/metadata.desktop +=== +--- marble-17.08.3.orig/src/plasma/applets/worldclock/package/metadata.desktop 2017-10-20 03:52:49.0 + marble-17.08.3/src/plasma/applets/worldclock/package/metadata.desktop 2019-04-24 15:09:41.781959847 + +@@ -49,7 +49,7 @@ + Name[x-test]=xxWorld Clockxx + Name[zh_CN]=ä¸çæ¶é + Name[zh_TW]=ä¸çæé +-# not yet... Comment=Shows the time in different parts of the world ++Comment=Shows the time in different parts of the world + + Icon=marble + Type=Service diff -Nru marble-17.08.3/debian/patches/series marble-17.08.3/debian/patches/series --- marble-17.08.3/debian/patches/series2018-10-27 11:38:29.0 + +++ marble-17.08.3/debian/patches/series2019-05-18 07:15:08.0 + @@ -1,3 +1,4 @@ do_not_install_private_headers kubuntu_disable-MarbleRunnerManagerTest.diff qt5.11.patch +fix-923592.patch
Bug#928172: fixing debian-security-support upgrades from stretch (for good)
Sean Whitton: > Hello, > > On Mon 13 May 2019 at 11:52AM +00, Holger Levsen wrote: > >> [re-sent with debian-release list address corrected...] > > Also resending. Sorry. > >> so there is "#928172 debian-security-support: fails to upgrade from >> 'testing': >> dpkg: error: error executing hook" which happens when base-files is upgraded >> before debian-security-support (but doesnt happen if d-s-s is upgraded >> first...) >> >> So I think this can only be fixed properly (=without asking people to >> upgrade to the latest stretch pointrelease but instead allowing upgrades >> to buster from *any* stretch pointrelease) by adding a "pre-depends: >> debian-security-support (>= 2019.04.25)" to base-files in buster. > > I didn't think we supported upgrades from anything but the latest point > release of the previous stable release? > > My belief is based on the release notes saying that you should upgrade > to the latest point relesae first. > My understanding is that we prefer that upgrade paths works regardless of which minor version of the stable release you upgrade from (to the extend possible). Thanks, ~Niels
Bug#926698: cpio: messes with /usr/sbin/rmt in --merged-usr environment
Niels Thykier: > Hi Chris and Ruben, > > Could either of you please have a look at this bug in cpio (you are > listed as Uploaders)? Even if it is just in the form of "ENOTME, NMU > welcome". > > Note that Anibal is MIA (per #925021). > > Thanks, > ~Niels > Hi Chris, Thanks for the fast upload. Just to confirm, did you intend to use "test -L /sbin/rmt" instead of "! test -L /sbin/rmt" as Andreas suggested? I am concerned that we might have missing negation at play and wanted to be sure before I unblocked it. Thanks, ~Niels > On Tue, 9 Apr 2019 18:05:00 +0200 Andreas Beckmann wrote: >> Control: clone -1 -2 >> Control: reassign -2 tar 1.30+dfsg-5 >> Control: retitle -2: tar: prerm deletes /usr/sbin/rmt in --merged-usr >> environment >> Control: retitle -1: cpio: prerm deletes /usr/sbin/rmt in --merged-usr >> environment >> >> On 2019-04-09 11:44, Andreas Beckmann wrote: >>> 0m17.9s ERROR: WARN: Broken symlinks: >>> /etc/rmt -> /usr/sbin/rmt (tar) >>> >>> 0m22.0s ERROR: FAIL: After purging files have disappeared: >>> /usr/sbin/rmt -> /etc/alternatives/rmt not owned >> >> This is caused by the prerm script which contains this not merged-usr >> aware code: >> >> if [ "$1" = remove ]; then >> update-alternatives --remove mt /bin/mt-gnu >> if test -L /sbin/rmt && test /sbin/rmt -ef /usr/sbin/rmt; then >> rm -f /sbin/rmt >> fi >> fi >> >> Cloning the bug to tar, since its prerm contains a similar construct. >> (And I don't mean the update-alternatives call ...) >> >> remove|deconfigure) >> update-alternatives --remove rmt /usr/sbin/rmt-tar >> if test -L /sbin/rmt && test /sbin/rmt -ef /usr/sbin/rmt; then >> rm -f /sbin/rmt >> fi >> ;; >> >> Probable use >> >> if ! test -L /sbin && test -L /sbin/rmt && ... >> >> >> Andreas >> >>
Bug#927765: Bug #927765 in debian-archive-keyring marked as pending
Control: tag -1 pending Hello, Bug #927765 in debian-archive-keyring 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/release-team/debian-archive-keyring/commit/29c8051721317895a2258acb74c6fe5c023e56bc Add myself as uploader Closes: #927765 Signed-off-by: Niels Thykier (this message was generated automatically) -- Greetings https://bugs.debian.org/927765
Bug#926698: cpio: messes with /usr/sbin/rmt in --merged-usr environment
Niels Thykier: > Hi Chris and Ruben, > > Could either of you please have a look at this bug in cpio (you are > listed as Uploaders)? Even if it is just in the form of "ENOTME, NMU > welcome". > > Note that Anibal is MIA (per #925021). > > Thanks, > ~Niels > > [...] Hi Chris, FYI, Ruben's email bounces with "No such user" in the other end. Accordingly, you are currently the only (trivially reachable) maintainer/uploader left of cpio. Thanks, ~Niels
Bug#926698: cpio: messes with /usr/sbin/rmt in --merged-usr environment
Hi Chris and Ruben, Could either of you please have a look at this bug in cpio (you are listed as Uploaders)? Even if it is just in the form of "ENOTME, NMU welcome". Note that Anibal is MIA (per #925021). Thanks, ~Niels On Tue, 9 Apr 2019 18:05:00 +0200 Andreas Beckmann wrote: > Control: clone -1 -2 > Control: reassign -2 tar 1.30+dfsg-5 > Control: retitle -2: tar: prerm deletes /usr/sbin/rmt in --merged-usr > environment > Control: retitle -1: cpio: prerm deletes /usr/sbin/rmt in --merged-usr > environment > > On 2019-04-09 11:44, Andreas Beckmann wrote: > > 0m17.9s ERROR: WARN: Broken symlinks: > > /etc/rmt -> /usr/sbin/rmt (tar) > > > > 0m22.0s ERROR: FAIL: After purging files have disappeared: > > /usr/sbin/rmt -> /etc/alternatives/rmt not owned > > This is caused by the prerm script which contains this not merged-usr > aware code: > > if [ "$1" = remove ]; then > update-alternatives --remove mt /bin/mt-gnu > if test -L /sbin/rmt && test /sbin/rmt -ef /usr/sbin/rmt; then > rm -f /sbin/rmt > fi > fi > > Cloning the bug to tar, since its prerm contains a similar construct. > (And I don't mean the update-alternatives call ...) > > remove|deconfigure) > update-alternatives --remove rmt /usr/sbin/rmt-tar > if test -L /sbin/rmt && test /sbin/rmt -ef /usr/sbin/rmt; then > rm -f /sbin/rmt > fi > ;; > > Probable use > > if ! test -L /sbin && test -L /sbin/rmt && ... > > > Andreas > >
Bug#883872: Bug#927383: unblock: bitlbee/3.6-1.1
Andreas Tille: > Control: tags -1 - moreinfo > > Hi Niels, > > On Fri, Apr 19, 2019 at 06:05:00AM +, Niels Thykier wrote: > [...] > >> If the incomplete d/copyright also applies to testing, then it will need >> a fix via testing-proposed-updates. The bug metadata does not have any >> found version, so it is not clear to me if the issue existing before the >> new upstream version in sid or that version introduced the issue. > > I think the patch also applies to version in testing. I've now > uploaded to testing-proposed-updates - debdiff attached. > > [...] > > Kind regards > > Andreas. > Approved the tpu upload, thanks. ~Niels
Bug#921599: [debian-mysql] Bug#921599: mariadb-10.3: always connects to localhost ignoring host entry in option file
On Tue, 2 Apr 2019 09:41:25 +0300 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?= wrote: > OK, so current MariaDB 10.3.13 we have in Debian contains MariaDB > Connector C 3.0.9 > > mariadb-10.3$ grep -rF 'SET(CPACK_PACKAGE_VERSION_' libmariadb/CMakeLists.txt > SET(CPACK_PACKAGE_VERSION_MAJOR 3) > SET(CPACK_PACKAGE_VERSION_MINOR 0) > SET(CPACK_PACKAGE_VERSION_PATCH 9) > > This has been fixed upstream in MariaDB Connector C 3.0.10: > https://github.com/MariaDB/mariadb-connector-c/pull/101 > > MariaDB 10.3.14 release preparations are in progress, so this can be > fixed soon via the new upstream release: > https://mariadb.com/kb/en/library/mariadb-10314-release-notes/ > > Hi, Gentle ping on this. :) Thanks, ~Niels
Bug#926872: evolution: Spaces in mail view disappeared with recent updates
Control: tags -1 moreinfo unreproducible Hi Boyuan Yang, Dominique provided the following message to your bug. However, I am sure if you have seen it (you were not listed as an explicit CC and the BTS does not CC submitters by default). On Wed, 17 Apr 2019 10:06:22 +0200 Dominique Dumont wrote: > On Thu, 11 Apr 2019 11:22:46 -0400 Boyuan Yang wrote: > > A screenshot is provided with the email here. I'm not sure if it can be > > reproduced by you, but at least this issues appears on all my machines > > running Debian Sid. > > I'm using evolution 3.30.5-1 and cannot reproduce this bug. > > Could you check that the mail source does contain the missing white spaces ? > > Could you reproduce this bug with different font settings ? > > All the best > > Thanks, ~Niels
Bug#926392: licensecheck chokes on long lines
On Thu, 04 Apr 2019 18:13:43 +0200 Jonas Smedegaard wrote:
> control: tag -1 confirmed
>
> Quoting Sandro Mani (2019-04-04 13:36:28)
> > $ wget
> > https://files.pythonhosted.org/packages/source/x/xonsh/xonsh-0.8.12.tar.gz
> > $ tar xf xonsh-0.8.12.tar.gz
> > $ licensecheck xonsh-0.8.12/xonsh/parser_table.py
> >
> > => Licensecheck hangs eating cpu cycles (the file has lines with 33k and
> > 71k characters).
>
> Indeed. Thanks for reporting!
>
> - Jonas
>
> --
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136 Website: http://dr.jones.dk/
>
> [x] quote me freely [ ] ask before reusing [ ] keep private
Hi,
I have been digging in the code (admittedly using the master branch of
the libregexp-pattern-license-perl and licensecheck rather than the
packages) and basically, it is a DOS from suboptimal regex.
I traced it down to getting stuck on the python_2 "grant_license". This
regex expands to (manually reformatted with /x for readability):
"""
m!
(?^:
(?:
(?: (?:[Ll]icensed|[Rr]eleased) [ ] under|(?:according [ ] to|as
[ ] governed [ ] by|under) [ ] the [ ] (?:conditions|terms)
[ ] of)(?:(?:[Tt]he [ ] )?Python-2.0
| (?:[Tt]he [ ])?Python(?: [ ] [Ll]icense)? [ ] 2.0
| (?:[Tt]he [ ])?Python-2.0
| (?:[Tt]he [ ])?Python [ ] Software [ ]
Foundation(?: [ ] [Ll]icense)? [ ] version [ ] 2
| (?:[Tt]he [ ])?python2
| (?:[Tt]he [ ])?Python-2
| (?:[Tt]he [ ])?PSF-2
| (?:[Tt]he [ ])?Python(?: [ ] [Ll]icense)? [ ] Version [ ] 2
| (?:[Tt]he [ ])?PYTHON [ ] SOFTWARE [ ] FOUNDATION [ ] LICENSE [
] VERSION [ ] 2
| (?:[Tt]he [ ])?python-license-2.0)
| (?:\W*\S+\W*)PSF [ ] is [ ] making [ ] Python [ ] available [ ]
to [ ] Licensee
)
)
!x
"""
The problem is the *last* alternative, namely:
"""
(?:\W*\S+\W*)PSF [ ] is [ ] making [ ] [...]
"""
That \W*\S+\W* (known as ${BB} in the libregexp-pattern-license-perl
code) is stirring up hell. Basically, perl wants to find the *longest*
match and will spent stupid amount of time in this "trivial" regex
enumerating exponentially many "non-matches" ([1] strikes again).
Simply removing ${BB} will make the code continue past the python_2 test
relatively fast. For the python_2 case, I think that the phrase "PSF
is making Python available to Licensee" would be sufficient enough to
consider it a match (i.e. ${BB} is redundant) - though it will change
behaviour on an anchored match (I hope this is not a problem).
Though it then gets stuck in the next regex "cube" (from
@L_type_unversioned) and that is as far down the rabbit hole I ventured
in terms of regex getting stuck (note that "cube" indirectly uses the
$BB regex too).
Thanks,
~Niels
[1] https://swtch.com/~rsc/regexp/regexp1.html
Bug#905772: [Pkg-libvirt-maintainers] Bug#905772: libvirtd upgrade broken stretch->buster
On Mon, 15 Apr 2019 22:27:57 +0200 Guido =?iso-8859-1?Q?G=FCnther?= wrote: > Hi, > On Mon, Apr 15, 2019 at 10:18:18PM +0200, Michael Biebl wrote: > > Hi Sam > > > > Am 15.04.2019 um 20:38 schrieb Sam Hartman: > > > control: severity -1 serious > > > > > > justification: libvirtd upgrades from stretch to buster break causing > > > apt to fail and requiring the admin to get the systemd units into a > > > consistent state before things can continue > > > > > > > > > Unfortunately based on discussion so far this is a complex bug to fix. > > > Ubuntu's solution is to drop the sysv scripts and to drop Also= lines > > > in some of the units. > > > > > > The systemd maintainers proposed that dropping Also as well as some > > > changes to move toward dh_systemd_start being used even when sysvinit > > > scripts are present would help this situation. Unfortunately it at > > > least doesn't look like those changes are in debhelper for buster. > > > Systemd folks, do you have any suggestions on how to approach this for > > > buster? > > > > Using debhelper compat level 12, you are able to completely decouple > > dh_installinit and dh_installsystemd which would give you the ability to > > implement what you want afaics. > > So let's move libvirt from 8 to 12 for stretch? I'm all for it but it'll > be a couple of days until I can set time aside for this. > cheers, > -- Guido > > [...] Hi, I think we should keep libvirt at compat 8 in general for now and then leave a full bump to compat 12 for bullseye. The reason here being that the compat changes documented in debhelper(7) amounts to 3-4 screens worth of changes across all of debhelper's tools. Instead, we can do a mixed compat setup, where the package remains at compat 8 in general but we force selected tools to run in compat 12. I have made a PoC of that in https://salsa.debian.org/libvirt-team/libvirt/merge_requests/21/diffs Note that change set is only meant as inspiration; I have not tried to understand the problem nor the solution fully (nor have I tested that it actually still builds). Thanks, ~Niels
Bug#909750: applications tries to write to /usr/* directories via libfontconfig1
Vincas Dargis: > On 2019-04-13 12:50, Niels Thykier wrote: >> What is the status of this bug? AFAICT, we have *some* fixes from >> upstream but Chris's mail implies that the bug is not completely fixed. > > This bug disappeared from my logs long time ago, at least haven't seen > any application reproducing it so far. Interestingly, Chris (just Cc'ed) claims to have reproduced it about a week ago with libfontconfig1:amd64 using strace and to my knowledge libfontconfig1 hasn't changed for months in sid/buster. @Chris: Just to confirm: Do you still see the issue? Thanks, ~Niels
Bug#927007: libopenblas-base: Disable TLS (thread-local storage) to work around #903514
Source: openblas Severity: serious User: release.debian@packages.debian.org Usertags: buster-is-blocker Hi, Please disable the usage of TLS (thread-local storage) to work around #903514 (deadlocks in glibc with TLS) for now. Thanks, ~Niels
Bug#910964: libprotobuf17 might need Breaks: libprotobuf10
On Wed, 3 Apr 2019 00:04:43 +0200 Andreas Beckmann wrote: > [...] > > What's the point in having a cruft package (libprotobuf10) installable > in buster, if it has been shown that this allows partial upgrades (yes, > partial upgrades *are* supported) that reproducibly cause failures? > The cruft package itself does not cause harm. It's the combination with > other packages that's problematic. There is an easy solution to prevent > all these (see Subject), without imposing any limitation on buster. > > While it is possible to add the Breaks to libarcus3 instead, is this > sufficient to prevent *all* failure cases? Which package will be the > next to be touched to prevent mixture errors? > > There is no point in touching Build-Depends, as we can't build against > this cruft in sid. > > Andreas > > Hi, >From a release team PoV, we would very much like to see this be fixed with a Breaks as well. > Hi Pirate, > > On Sat, Oct 20, 2018 at 10:39 AM Pirate Praveen > wrote: >> On Mon, 15 Oct 2018 16:26:23 +0300 Adrian Bunk wrote: >> > When it has been observed that ending up with both libprotobuf10 and >> > libprotobuf17 in a binary will not work, then this should be expressed >> > through the package dependencies. > ... of the binaries that need to be compiled with the same ProtoBuf version. > >> Are you planning to upload this fix? Testing migration is currently >> blocked by this rc bug and there is a delay caused by autopkgtest failure. > Let's break it to parts. > 1) Can libprotobuf10 and libprotobuf17 installed together and > independent packages working correctly with these libraries? Yes, > these are possible. I don't see the need to break the old > libprotobuf10 package. > While libprotobuf10 and libprotobuf17 *can* be installed together, nothing in buster should rely on libprotobuf10 any longer. Indeed, libprotobuf10 is not even in buster any longer. > [...] >> > That would avoid a couple of potential problems in situations like >> > stretch->buster upgrades or for testing users. > Breaking libprotobuf10 would cause more problems. All ProtoBuf > related packages would need to migrate once and together. Cause > problem with any local compiled program for libprotobuf10. > This may have been an issue at that time, but it no longer is (as libprotobuf10 is not in testing anymore). On the flip side, having libprotobuf10 remain on some systems during upgrades will spell trouble for us later. Each release, we see a number of upgrade issues related to old, long obsolete packages that were removed releases ago. Lets ensure libprotobuf10 does not become one of them for bullseye or later. Thanks, ~Niels
Bug#909750: applications tries to write to /usr/* directories via libfontconfig1
On Sat, 6 Apr 2019 16:38:13 +0200 Chris Hofstaedtler wrote: > * Thierry fa...@linux.ibm.com [190406 14:35]: > > > >The only occurrence I'm seeing on my system is: > > > > > > > >openat(AT_FDCWD, "/usr/lib/firefox/fonts/.uuid.TMP-EWjEq0", > > > >O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0600) = -1 EACCES (Permission denied) > > > > > > Now it's the only occurrence for me, too. > > > > > > > With current packages I don't see any more issues of openat() > > EACESS(...) when tracing firefox-bin > > With libfontconfig1:amd64 2.13.1-2: > > $ strace -o '| grep -w EACCES' /usr/lib/firefox-esr/firefox-bin > openat(AT_FDCWD, "/usr/lib/firefox-esr/fonts/.uuid.TMP-pZnI7N", > O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0600) = -1 EACCES (Permission denied) > > C. > Hi, What is the status of this bug? AFAICT, we have *some* fixes from upstream but Chris's mail implies that the bug is not completely fixed. Related, upstream closed their side of the bug a few days ago with the note: """ uuid related code has been gone in git. this should be improved. closing. """ (Not sure if that means they committed some recent changes to fix this). Thanks, ~Niels
Bug#901148: Debian Bug#901148: timidity: upgrading to 2.14.0-2 broke sound in KDE plasma
Hi Bastien, Could you have a look at this bug (in particular) the mail below. The bug has been tagged buster-ignore, but we would still like a more user-friendly solution (even if just in the form of a NEWS entry, so upgrading people are not caught unaware). Thanks, ~Niels On Sun, 7 Apr 2019 09:33:34 +0200 Wolfgang Silbermayr wrote: > Having been hit by this on Buseter Testing before, I did some > investigation. Here are my findings: > > Conditions for this bug to appear are: > >* timidity-daemon is installed >* timidity service (from the timidity-daemon package) is enabled or > timidity gets started by hand >* No midi device is provided by the kernel > > Only if all of these these conditions are fulfilled at the same time, > this comes into effect. > > A quick test on Stretch with the timidity service enabled did not reveal > the bug. However, timidity was not running after boot, and I didn't find > the reason why. After starting it by hand, pulseaudio got unusable, just > like it does on Buster. So my guess is that the bug was actually present > in Stretch, it just did not show due to timidity not starting properly > at boot. > > A removal of timidity-daemon on affected systems is sufficient. It is > set to "Suggests" instead of "Recommends" with timidity as of 2.14.0-8, > so the majority of people who install games or music programs that pull > in timidity will no longer be affected. > > People who will be affected are those that got timidity-daemon installed > in Stretch by the "Recommends" dep, and then upgraded to Buster. Even an > apt autoremove will keep timidity-daemon installed. > > One way to escape this bug is to have a midi device available in the > system, which can also be snd_virmidi. But I don't consider this a clean > solution, because it will probably interfere for people who have real > midi hardware. > > What other options do we have? Simply keep it as-is and document it in > the the upgrade manual? Or do we have some mechanism available that > would remove timidity-daemon if it was installed automatically? Any > other ideas? > >
Bug#891434: Bug#923839: shim-signed: setup of shim-signed failed with 'Could not delete variable: No space left on device'
On Sun, 10 Mar 2019 21:57:02 + Colin Watson wrote: > Control: reassign 891434 src:grub2 > Control: forcemerge 891434 923839 > > On Tue, Mar 05, 2019 at 03:43:31PM -0800, Steve Langasek wrote: > > But I'm reassigning this bug to grub2, because I think the right answer for > > nearly all efibootmgr write failures on update of the bootloader packages is > > that grub should not be writing to nvram at all. Rather, in the common case > > of a bootloader upgrade, the contents being written to nvram will match what > > is already there. By detecting that there are no changes, we save ourselves > > a write, which in the exceptional cases sidesteps a write failure, and in > > the common case, reduces wear on the nvram which may have limited write > > cycles. > > This is the same as #891434, which I've been working on recently, and at > a high level you and I have reached the same conclusions about what's > needed. (I've also been discussing it with Steve McIntyre, again > reaching similar conclusions.) > > [...] > > I got this almost working at the Cambridge BSP today before I ran out of > time (very nearly bricking my own laptop in the process ...). I need to > add suitable --debug messages, finish getting it working, ensure that > it's only rewriting variables where needed, and generally tidy up the > fairly large pile of code involved, so there's still probably at least > four hours of work left to do on it, not to mention upstream review. > However, I'm reasonably hopeful that I'll have this done for buster. > > -- > Colin Watson [cjwat...@debian.org] > > Hi Colin, Thanks for working on this. :) I am glad to hear that we might have something almost ready thanks to your hard work. :) Thanks, ~Niels
Bug#910201: Processed: tagging 910201
Lars Wirzenius: > On Tue, Mar 05, 2019 at 07:24:03PM +, Debian Bug Tracking System wrote: >> Added tag(s) bullseye and sid. > > Does this mean buster is going to be released with vmdebootstrap? This > would make me sad. Why is this? I'm not going to spend any time to fix > vmdebootstrap. I'd really rather nobody else did, either, and instead > spent the effort on fixing anything that still uses vmdebootstrap to > use something else. > Hi Lars, I am sorry to hear that you are sad by this. To be honest, I had expected you were informed about this already. This was requested in #922826 with the argument that our live image builds no longer worked and that it was too risky to rewrite it at this time in the release cycle (I remember some of this discussion from IRC, so it might not be visible in the bug). I have CC'ed the people requesting/supporting this change as they are better suited for answering any questions you have in details but also figuring out where we go from here (even if that ends up being something as trivial as replacing you the maintainer field, so you are not listed at the direct contact point vmdebootstrap longer than you had anticipated). Thanks, ~Niels
Bug#923654: libowasp-java-html-sanitizer-java-doc: Depends on libjsr305-java-doc which is no longer built in sid/buster
Package: libowasp-java-html-sanitizer-java-doc Version: 0.1+r88-1 Severity: serious Hi, The libowasp-java-html-sanitizer-java-doc package is depending on libjsr305-java-doc in sid + buster, however libjsr305-java-doc is no longer buit. Please remove the dependency for buster. Thanks, ~Niels
Bug#923585: debian-installer-netboot-images: Built against openssl1.0 and ttf-freefontfrom stable (neither are in sid/testing atm.)
Source: debian-installer-netboot-images Version: 20190118 Severity: serious Hi, The "Built-Using" field of debian-installer-netboot-images references openssl1.0/1.0.2q-1~deb9u1 and ttf-freefont/20100919-1, neither of which are in unstable nor testing at the moment. The former was removed very recently and the other was removed in 2018-06. Thanks, ~Niels
Bug#891434: grub-efi: System fails to boot after "No space left on device" on EFI variable storage
On Fri, 14 Dec 2018 10:22:49 +0100 Ralf Jung wrote: > Hi, > > > Fixing this does seem like it would be a good idea for general > > robustness against dodgy firmware (this is not the first iteration of > > problems along these lines). It would take some development work, but > > hopefully not too much. > > > > Things that GRUB can't do, as far as I can tell: > > > > * I don't think there's a way for GRUB to check whether it will be > >possible to recreate a boot entry later; as I understand it, that > >depends on various low-level details, including firmware-specific > >quirks. > > > > * Even detecting that nothing changed would require cooperation from > >efibootmgr, since the encoding of the EFI variable is an > >implementation detail there (so we can't just read it out and > >compare), and efibootmgr doesn't expose a way for GRUB to say "set > >this configuration, but only if it's different from what's already > >there". > > > > However, I think GRUB can at least manage to delete all but one entry > > from the same distributor rather than all of them, and if it finds one > > remaining entry then it can modify that rather than writing a brand new > > variable. As I understand it, that would probably be enough to fix this > > bug? > > Assuming that modification works even when the variable storage is (close to) > full, then yes, that would at least keep the device bootable which would be a > big improvement. > > Kind regards, > Ralf > > Hi Colin, Thanks for proposing this solution. :) I also think it would be a good solution for now that will hopefully avoid most of these errors. :) Thanks, ~Niels
Bug#917501: meson: FTBFS (failing tests)
On Sat, 29 Dec 2018 00:56:55 +0200 Jussi Pakkanen wrote: > On Fri, Dec 28, 2018 at 1:57 AM Santiago Vila wrote: > > > The build was made in my autobuilder with "dpkg-buildpackage -A" > > but it also fails here: > > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/meson.html > > > > where you can get a full build log if you need it. > > The actual error message was not in your snippet, but from the log it is this: > > Traceback (most recent call last): > File "run_unittests.py", line 2044, in test_rpath_uses_ORIGIN > self.assertTrue(rpath) > AssertionError: None is not true > > The test is verifying that libraries and executables have the correct > rpath. However in this case, for some reason I don't understand, the > files built in the second step do not have rpaths at all. I made a PR > improving the message here: > > https://github.com/mesonbuild/meson/pull/4684 > > It's probably not particulary useful but still. Does anyone have any > suggestions on what the second build setup has would cause rpaths to > not be there? > > Hi, The first and second build uses different locales by default. I know meson's d/rules sets "export LC_ALL=C.UTF-8", so that "shouldn't" be the problem unless something in the test reintroduces the locale again (e.g. by unsetting LC_ALL). But if my theory is to hold, then Santiago's build must have been in a non-English locale. @Santiago: Which locale did you use for the build? Thanks, ~Niels
Bug#912685: debian/rules is not binNMU safe
On Sat, 1 Dec 2018 14:34:26 +0100 gregor herrmann wrote: > Control: tag -1 + pending > > On Fri, 02 Nov 2018 21:07:04 +0100, Laurent Bigonville wrote: > > > Why aren't you using "dh_makeshlibs -V" or the version macro that are > > present in /usr/share/dpkg/pkg-info.mk ? > > This seems to be fixed in git: > https://salsa.debian.org/debian/net-snmp/commit/231fe8fe9712040354cf19bd1909c3a3b974d496 > hence marking as pending. > > > Cheers, > gregor, from the Bern BTS > > -- > .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org > : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 > `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe >`- Hi Craig, Thanks for fixing this bug in git. Could I perhaps convince you to upload it to unstable in the form of a net-snmp/5.7.3+dfsg-5 release (or let me do an NMU for it)? We are approaching the freeze and I would like to see the RC bug count drop as much as possible before then. :) Thanks, ~Niels
Bug#917592: libterm-termkey-perl: FTBFS (failing tests)
Niels Thykier: > [...] > > Stacktrace follows: > > """ > (gdb) bt full > #0 termkey_get_flags (tk=0x0) at termkey.c:565 > No locals. > #1 0x7794cba6 in XS_Term__TermKey_get_flags (my_perl= out>, cv=) at lib/Term/TermKey.xs:457 > self = > RETVAL = > targ = 0x55ffd9c8 > sp = > ax = > mark = > items = > #2 0x5563fd11 in Perl_pp_entersub () > No symbol table info available. > #3 0x55636026 in Perl_runops_standard () > No symbol table info available. > #4 0x555b2097 in perl_run () > No symbol table info available. > #5 0x55588402 in main () > No symbol table info available. > > """ > > > [...] > > > Thanks, > ~Niels > How to reproduce with gdb: """ $ TERM=vt100 gdb -quiet /usr/bin/perl Reading symbols from /usr/bin/perl... [...] (gdb) run -I blib/arch -Ilib t/05flags.t 0https://sources.debian.org/src/libtermkey/0.20-3/termkey.c/
Bug#917592: libterm-termkey-perl: FTBFS (failing tests)
gregor herrmann: > On Sat, 29 Dec 2018 16:11:00 +0000, Niels Thykier wrote: > >>>> Does/did it work under nohup (without the >>>> debhelper work around to make nohup work)? >>> >>> Yes, in the same chroot (i.e. with the STDIN redirection commented >>> out) `TERM=vt100 nohup prove --blib --verbose t/*.t' in d/rules works. >>> >> Now I am even more puzzled. >> >> nohup does the eqv. of >> >> open(STDIN, '>', '/dev/null') >> >> and libterm-termkey-perl allegedly copes with that!? Unless the answer >> is that prove "fixes" this for us and "perl Build test --verbose" (as >> run by dh_auto_test) does not have the same magic as prove? > > Hm, I don't know what's going on there … > But maybe I did the test the other way around yesterday? > > So, some more testing: > > Chroot A: my normal sid cowbuilder chroot > Chroot B: a copy with debhelper installed and the redirect STDIN line > in _doit() commented out > > Results for the various option in override_dh_auto_test: > > [...] > > > Cheers, > gregor > Hi, Basically, the test (t/05flags.t) seg. faults if stdin is a *readable* non-tty (but succeeds in all other cases). My recommendation is to use a short term work around by replacing the dh_auto_test call with the upstream test runner. This will take the "edge" off this bug and enable us to debug this issue without the same pressure with the upcoming freeze. Anyhow, on to the details I have found: * Only test case 05flags.t fails and only if stdin is a *readable* non-tty (e.g. /dev/null, an empty file or a non-empty file) * It success the moment, stdin is either "left alone" or is a "writable" non-tty (0>/dev/null). * If the TERM is set to "dump", the test hangs. * If the TERM is set to a random / unknown TERM, the test succeeds. Presumably termkey does not know the terminal and skips the code that crashes. Stacktrace follows: """ (gdb) bt full #0 termkey_get_flags (tk=0x0) at termkey.c:565 No locals. #1 0x7794cba6 in XS_Term__TermKey_get_flags (my_perl=, cv=) at lib/Term/TermKey.xs:457 self = RETVAL = targ = 0x55ffd9c8 sp = ax = mark = items = #2 0x5563fd11 in Perl_pp_entersub () No symbol table info available. #3 0x55636026 in Perl_runops_standard () No symbol table info available. #4 0x555b2097 in perl_run () No symbol table info available. #5 0x55588402 in main () No symbol table info available. """ Compare the following runs: TERM=vt100 perl -I blib/arch -Ilib t/05flags.t 0/dev/null vs. TERM=dumb perl -I blib/arch -Ilib t/05flags.t 0
Bug#917592: libterm-termkey-perl: FTBFS (failing tests)
gregor herrmann: > On Sat, 29 Dec 2018 04:57:00 +0000, Niels Thykier wrote: > >>> From the debhelper changelog: >>> >>> debhelper (11.5.4) unstable; urgency=medium >>> >>> [ Niels Thykier ] >>> * Dh_Lib.pm: Reopen stdin to read from /dev/null in doit (and its sibling >>> functions) to prevent issues when stdin is open in write-only mode >>> (which is what nohup(1) does). Thanks to Julian Gilbey for reporting >>> the issue and providing a sample patch for it as well. >>> (Closes: #913663) >>> >>> >>> Can this be related? (The failing test operate on \*STDIN.) >>> Cc'ing the debhelper bug and debhelper maintainers … >> >> Hi gregor, >> >> Indeed, that could be related. >> >> [...] >> Does/did it work under nohup (without the >> debhelper work around to make nohup work)? > > Yes, in the same chroot (i.e. with the STDIN redirection commented > out) `TERM=vt100 nohup prove --blib --verbose t/*.t' in d/rules works. > > > Cheers, > gregor > Now I am even more puzzled. nohup does the eqv. of open(STDIN, '>', '/dev/null') and libterm-termkey-perl allegedly copes with that!? Unless the answer is that prove "fixes" this for us and "perl Build test --verbose" (as run by dh_auto_test) does not have the same magic as prove? Thanks, ~Niels signature.asc Description: OpenPGP digital signature
Bug#917605: rainloop: Depends on libphp-predis, which is scheduled for removal (per #915069)
Package: rainloop Version: 1.11.1-1 Severity: serious Hi, The rainloop package currently depends on libphp-predis, which is scheduled for removal (see #915069 for the details). AFAICT, the replacement for libphp-predis is php-nrk-predis (which is a newer version of the same code just using a different package name). Please consider migrating rainloop to php-nrk-predis soon. As it is, rainloop plus libphp-predis will be removed from testing before buster is released. Thanks, ~Niels
Bug#917592: libterm-termkey-perl: FTBFS (failing tests)
gregor herrmann:
> On Sat, 29 Dec 2018 00:25:25 +, Santiago Vila wrote:
>
>> Package: src:libterm-termkey-perl
>> Version: 0.16-3
>> Severity: serious
>> Tags: ftbfs
>
>> I tried to build this package in buster but it failed:
>
>> Test Summary Report
>> ---
>> t/05flags.t (Wstat: 11 Tests: 2 Failed: 0)
>> Non-zero wait status: 11
>> Parse errors: Bad plan. You planned 4 tests but ran 2.
>
> Same in #917497.
>
> Both tests fail during build and not during autopkgtests (locally and
> on r-b/ci.debian.net).
>
> After thinking a bit I tried:
>
> #v+
> --- a/debian/rules
> +++ b/debian/rules
> @@ -4,4 +4,4 @@
> dh $@
>
> override_dh_auto_test:
> - TERM=vt100 dh_auto_test
> + TERM=vt100 prove --blib --verbose t/*.t
> #v-
>
> [...]
>
> From the debhelper changelog:
>
> debhelper (11.5.4) unstable; urgency=medium
>
> [ Niels Thykier ]
> * Dh_Lib.pm: Reopen stdin to read from /dev/null in doit (and its sibling
> functions) to prevent issues when stdin is open in write-only mode
> (which is what nohup(1) does). Thanks to Julian Gilbey for reporting
> the issue and providing a sample patch for it as well.
> (Closes: #913663)
>
>
> Can this be related? (The failing test operate on \*STDIN.)
> Cc'ing the debhelper bug and debhelper maintainers …
>
>
> Cheers,
> gregor
>
>
Hi gregor,
Indeed, that could be related.
To confirm it, please consider editing/patching
lib/Debian/Debhelper/Dh_Lib.pm by finding the "_doit" function and
commenting out the following line[1]:
"""
open(STDIN, '<', '/dev/null') or error("redirect STDIN failed: $!");
"""
If your test starts working again after that has been removed, then we
confirmed that is the problem.
Can you elaborate a bit more on what libterm-termkey-perl expects from
STDIN here? A tty perhaps? Does/did it work under nohup (without the
debhelper work around to make nohup work)?
Thanks,
~Niels
[1] Introduced in fff0f01c4ceb910ec4d0455718a2f60e22463792 but the
entire commit is not directly revertable.
Bug#917536: debian-archive-keyring: release key for buster
Package: debian-archive-keyring Version: 2017.5 Severity: serious Hi, We need a new release signing key for buster so we can include it in a debian-archive-keyring upload before the buster release. Thanks, ~Niels (If we need a better template, please help us with an update to https://wiki.debian.org/Teams/ReleaseTeam/ReleaseCheckList/, which currently uses #860831 as a reference)
Bug#917535: debian-archive-keyring: ftp-master key for buster
Package: debian-archive-keyring Version: 2017.5 Severity: serious Hi, We need new archive signing keys for buster, so we can include them in a debian-archive-keyring upload before the buster release. Thanks, ~Niels (If we need a better template, please help us with an update to https://wiki.debian.org/Teams/ReleaseTeam/ReleaseCheckList/, which currently uses #860830 as a reference)
Bug#916712: libgnutls30: Dummy bug - prevent too fast migration to testing
On Mon, 17 Dec 2018 19:43:35 +0100 Andreas Metzler wrote:
> Package: libgnutls30
> Version: 3.6.5-2
> Severity: serious
> Justification: maintainer's opinion
>
> gnutls 3.6.5-2 would be a candidate for testing migration tomorrow ("Too
> young, only 1 of 2 days old"). This is too quick, the changes require
> more testing in sid.
>
> cu Andreas
>
> --
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'
Hi Andreas,
Could you comment on how long testing time you expect here? :)
Thanks,
~Niels
Bug#914419: debhelper mustn't set pass V to make
Adrian Bunk:
> Package: debhelper
> Version: 11.5.2
> Severity: serious
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/apcupsd.html
>
> ...
> dh clean --with autoreconf
>dh_auto_clean
> make V=1 -j16 clean
> make[1]: Entering directory '/build/1st/apcupsd-3.14.14'
> 1find . -depth \
> \( -name -o -name -o -name \*.a \) \
> -exec " CLEAN" \{\} \; -exec \{\} \;
> /bin/sh: 1: 1find: not found
> make[1]: *** [autoconf/targets.mak:98: clean] Error 127
>
>
> https://sources.debian.org/src/apcupsd/3.14.14-2/autoconf/targets.mak/#L98
>
>
> Using V=1 for getting verbose build output is a relatively
> recent convention followed by some software.
>
> It is not something that is safe to use everywhere.
>
Hi,
Adding Luca to this report as it affect a change by Luca.
@Luca: What is your take on this? Should we roll back on this, guard it
by a compat level or something else?
Thanks,
~Niels
Bug#912272: staden-io-lib FTBFS: dh_installdocs: Cannot find (any matches for) "README" (tried in .)
Helmut Grohne: > Source: staden-io-lib > Version: 1.14.9-4 > Severity: serious > Tags: ftbfs > > staden-io-lib fails to build from source in unstable. This smells a bit > like a debhelper regression, but I'm not sure actually. In any case, it > fails to build reliably. > > |dh_installdocs -O--no-parallel > | dh_installdocs: Cannot find (any matches for) "README" (tried in .) > | > | make: *** [debian/rules:11: binary] Error 2 > | dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned > exit status 2 > > Helmut > That is a real issue in staden-io-lib. The debian/staden-io-lib-utils.docs file lists "README" but there is no "README" in the source root. Note that there was a regression in debhelper's reporting of such issues which was fixed in debhelper/11.3.5 (#902355). This can explain why this issue was not noticed until now. Thanks, ~Niels
Bug#885563: vte: Do not release with Buster
On Thu, 28 Dec 2017 00:05:02 -0500 Jeremy Bicha wrote: > Source: vte > Severity: serious > Tags: sid buster > User: pkg-gnome-maintain...@lists.alioth.debian.org > Usertags: oldlibs vte > > The old vte 0.28 series has not had a release since GNOME3's release in 2011. > > Please port your app to the vte2.91 source. That also means porting > your app to gtk3. gtk3 was declared stable over a year ago with the > 3.22 series. (There also have not been any gtk2 maintenance releases > since that time.) > > We do not intend to release Debian 10 "Buster" with the old src: vte. > > On behalf of the Debian GNOME team, > Jeremy Bicha > > Hi, AFAICT, the cdebconf-gtk-terminal bug (#887649) has not been updated in the past 8 months. Is it still realistic to remove vte before the transition freeze (2019-01-12)? Thanks, ~Niels
Bug#885657: rarian: Don't release with Buster
On Thu, 28 Dec 2017 17:14:52 -0500 Jeremy Bicha wrote: > Source: rarian > Version: 0.8.1-6 > Severity: serious > User: pkg-gnome-maintain...@lists.alioth.debian.org > Usertags: oldlibs rarian > Tags: sid buster > > scrollkeeper has been deprecated and unmaintained for years. Its > replacement, rarian has been deprecated for years too. More > importantly, it doesn't seem to be needed at all. yelp can easily > display Docbook help files without any .omf files. > > We do not intend to ship rarian in Debian 10 "Buster". > > About half the affected packages in Testing already have patches > prepared or are trivial to fix. The remainder probably just need to > have scrollkeeper dropped from their build systems (which might involve > some work with autoreconf and removing old copies of autoconf macros. > Many of the affected packages have *old* build systems.). > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-gnome-maintaine > r...@lists.alioth.debian.org;tag=rarian > > On behalf of the Debian GNOME team, > Jeremy Bicha > > Hi, FYI: There are still ~15-16 open bugs on the bts tagged rarian (I have made them blockers via a separate update). If the plan is still to remove rarian for Buster, these bugs should be resolved before the transition freeze (2019-01-12). Is this still the plan? Thanks, ~Niels
Bug#863801: grub-coreboot: fails to upgrade from jessie to stretch if init-select was installed
On Sun, 2 Jul 2017 03:15:36 +0200 Guillem Jover wrote: > Hi! > > [...] > > Isn't the obviously correct and policy compliant approach to just > Conflicts/Replaces (or Breaks/Replaces depending on the force you want > to apply here) with the init-select package from one of the grub > packages, and on that grub package ship a stub init-select.cfg with > just a comment explaining what's going on. And in the next release cycle, > just make that package remove its (now) own conffile? > > Thanks, > Guillem > > Hi Colin, Based on Guillem's reply above, can we do with a Conflicts and close this bug in buster? Alternatively, if this bug is not relevant for buster, please tag it "stretch" and consider fixing it in a pu. Thanks, ~Niels
Bug#909906: jh_installlibs --version-strip="+.*": Quantifier follows nothing in regex
On Sat, 29 Sep 2018 20:47:00 + Niels Thykier wrote: > clone 909906 -1 > reassign -1 jython > reassign 909906 jsurf-alggeo > retitle -1 jython: Invalid regex passed to jh_installlibs > retitle 909906 jsurf-alggeo: Invalid regex passed to jh_installlibs > thanks, > > Adrian Bunk: > > Package: javatools > > Version: 0.66 > > Severity: serious > > Control: affects -1 src:jython > > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jython.html > > > > ... > >debian/rules override_jh_installlibs > > make[1]: Entering directory '/build/1st/jython-2.7.1+repack' > > jh_installlibs --version-strip="+.*" > > Quantifier follows nothing in regex; marked by <-- HERE in m/+ <-- HERE .*/ > > at /usr/bin/jh_installlibs line 111. > > make[1]: *** [debian/rules:89: override_jh_installlibs] Error 25 > > > > The shell version of jh_installlibs used sed which is apparently more > forgiving (or possibly does not handle "+" like perl does). Attempting > to emulate sed's behaviour will never be a perfect match. > > Maintainers of jython and jsurf-alggeo: You presumably wanted to match a > literal "+", in which case please escape it (by using e.g. [+] like the > htsjdk package). > > * The jython variant then becomes --version-strip="[+].*" > * The jsurf-alggeo variant becomes --version-strip="[+]ds" > > Thanks, > ~Niels > > Btw, the default regex for jh_installlibs is: [\.+~-]ds(?:fg)?[0-9]* It looks like it might be sufficient to replace the need for passing the --version-strip option. Thanks, ~Niels
Bug#909906: jh_installlibs --version-strip="+.*": Quantifier follows nothing in regex
clone 909906 -1 reassign -1 jython reassign 909906 jsurf-alggeo retitle -1 jython: Invalid regex passed to jh_installlibs retitle 909906 jsurf-alggeo: Invalid regex passed to jh_installlibs thanks, Adrian Bunk: > Package: javatools > Version: 0.66 > Severity: serious > Control: affects -1 src:jython > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jython.html > > ... >debian/rules override_jh_installlibs > make[1]: Entering directory '/build/1st/jython-2.7.1+repack' > jh_installlibs --version-strip="+.*" > Quantifier follows nothing in regex; marked by <-- HERE in m/+ <-- HERE .*/ > at /usr/bin/jh_installlibs line 111. > make[1]: *** [debian/rules:89: override_jh_installlibs] Error 25 > The shell version of jh_installlibs used sed which is apparently more forgiving (or possibly does not handle "+" like perl does). Attempting to emulate sed's behaviour will never be a perfect match. Maintainers of jython and jsurf-alggeo: You presumably wanted to match a literal "+", in which case please escape it (by using e.g. [+] like the htsjdk package). * The jython variant then becomes --version-strip="[+].*" * The jsurf-alggeo variant becomes --version-strip="[+]ds" Thanks, ~Niels
Bug#909762: debhelper 11.4 makes dublin-traceroute FTBFS
On Fri, 28 Sep 2018 05:14:00 + Niels Thykier wrote: > Control: tags -1 moreinfo > > [...] > > > Truly, it did until dublin-traceroute/0.4.2-2 was uploaded a short while > ago, which solved this issue on their side by updating the debian/*.install. > > Have you seen any other packages affected by this issue (I am not aware > of any)? If not, I am tempted to close this as resolved. > > Thanks, > ~Niels > > FTR, there is also chrome-gnome-shell, which the maintainer has updated in git. Thanks, ~Niels
Bug#909820: pd-mrpeach: d/rules have build steps that are "hidden" no ops
Source: pd-mrpeach
Version: 0.1~svn17647-2
Severity: serious
Hi,
Due to a recent change in debhelper, we learning that pd-mrpeach have a
build step that seems like it ought to do something but in fact does
nothing.
In d/rules we find this:
"""
override_dh_auto_install:
dh_auto_install -- prefix=/usr pkglibdir=$(pkglibdir)
# fix permissions
find $(CURDIR)/debian/pd-*/ -name "*.pd_linux" -exec \
chmod 0664 {} +
# replace license file with link to the Debian license file
rm -f --
$(CURDIR)/debian/$(PACKAGE)/$(pkglibdir)/$(LIBRARY_NAME)/LICENSE.txt
"""
The dh_auto_isntall call creates debian/*tmp* rather than
debian/*${pkg}* when d/control lists multiple binary packages.
Accordingly, both the "find" and the "rm -f" calls matches nothing.
This became apparent when I changed debhelper to avoid creating empty
directories for packages a head of time as that makes the find call
error out[1].
Please evaluate whether the code bits are still relevant and either:
* remove them if they are obsolete.
* change them to apply their changes to debian/tmp
* move them to a later step where they can be applied correctly.
On a related note: it is not clear to me that the chmod 0664 surives
past dh_fixperms at the moment.
I have filed this as serious against pd-mrpeach on the assumption that
the chmod change is important. If it is no longer revelevant, then
this bug can be downgraded to minor (please remember to CC me if you
do that as I will have to update debhelper to undo some code).
Thanks,
~Niels
[1]:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pd-mrpeach.html
Bug#909762: debhelper 11.4 makes dublin-traceroute FTBFS
Control: tags -1 moreinfo Sven Joachim: > On 2018-09-27 23:20 +0300, Adrian Bunk wrote: > >> Package: debhelper >> Version: 11.4 >> Severity: serious >> Control: affects -1 src:dublin-traceroute >> >> https://buildd.debian.org/status/package.php?p=dublin-traceroute=sid >> >> ... >>dh_install -a >> install -d debian/dublin-traceroute//usr/bin >> cp --reflink=auto -a debian/tmp/usr/bin/dublin-traceroute >> debian/dublin-traceroute//usr/bin/ >> dh_install: Cannot find (any matches for) >> "usr/lib/libdublintraceroute.so.0.*" (tried in ., debian/tmp) >> >> dh_install: libdublintraceroute0 missing files: >> usr/lib/libdublintraceroute.so.0.* >> dh_install: Cannot find (any matches for) "usr/lib/libdublintraceroute.so" >> (tried in ., debian/tmp) >> >> dh_install: libdublintraceroute-dev missing files: >> usr/lib/libdublintraceroute.so >> dh_install: missing files, aborting >> install -d debian/.debhelper/generated/dublin-traceroute >> install -d debian/.debhelper/generated/libdublintraceroute0 >> install -d debian/.debhelper/generated/libdublintraceroute-dev >> make: *** [debian/rules:8: binary-arch] Error 25 > > This is apparently a side effect of the fix for #903042 (commit bab43d46, > "cmake: Explicitly set CMAKE_INSTALL_LIBDIR"). The Debian changelog > entry says "This should not make any pratical difference" but for > dublin-traceroute it does. That's because its CMakeLists.txt has the > following three lines: > > if (NOT CMAKE_INSTALL_LIBDIR) > set(CMAKE_INSTALL_LIBDIR "lib") > endif() > > So it did not install the libraries into a multiarch directory before, > but now that CMAKE_INSTALL_LIBDIR is explicitly set it does, and the > debian/*.install files are of course not prepared for that. > > Cheers, >Sven > Truly, it did until dublin-traceroute/0.4.2-2 was uploaded a short while ago, which solved this issue on their side by updating the debian/*.install. Have you seen any other packages affected by this issue (I am not aware of any)? If not, I am tempted to close this as resolved. Thanks, ~Niels
Bug#675857: pulseaudio creates .config/pulse in a root directory
On Sun, 7 Jan 2018 14:33:51 + Simon McVittie wrote: > Control: retitle 675857 /etc/init.d/alsa-utils creates /.config/pulse under > sysvinit > > Forwarding the text of Daniel Reichelt's message reopening RC bug > #675857 (and its merged duplicates) to the bug, so that it's visible > to the alsa-utils maintainers and on the BTS without rummaging in "Show > full text". > > I'm also retitling it to clarify which systems it affects (those that > boot with sysvinit or similar, but not systemd). I've checked that the > systemd units don't invoke aumix, and pass -E HOME=/run/home to every > alsactl invocation. > > On Thu, 04 May 2017 at 22:16:32 +0200, Daniel Reichelt wrote: > > /.config/pulse still is getting created when /etc/init.d/alsa-utils runs > > on boot. > > > > I'm using sysvinit instead of systemd. > > > > Tracing the init script and the included utils.sh showed, that any call > > to aumix somehow triggers pulseaudio as well which - due to HOME not > > being set - leads to /.config/pulse being created. The top of the call > > chain of aumix is the init script's call to sanify_levels(). > > > > Why was this previously fixed by prepending HOME=$ALSACTLHOME to only > > some commands instead of just exporting HOME? > > [...] > > Thanks, > smcv > (with no particular interest in this bug or this package, just trying > to tidy the RC bugs list) > > Hi, I added a MR on salsa for this issue[1] fixing a missing call to alsactl. I could not see any (direct) calls to aumix, so these are not covered. There are some calls to amixer but it does not seem to create .config if missing despite looking for it. Admittedly, Daniel's solution of simply setting HOME is probably easier to maintain in the long run and less like to "miss" a call. Thanks, ~Niels [1] https://salsa.debian.org/alsa-team/alsa-utils/merge_requests/1
Bug#909203: libreswan: Hardcoded dependency on libunbound2 - stalls unbound transition
Package: libreswan
Version: 3.25-1
Severity: serious
Hi,
The libreswan package has a hardcoded dependency on libunbound2, which
prevents us from replacing libunbound2 with libunbound8. Please
remove that dependency and rely on ${shlib:Depends} (which pick ups
libunbound8 automatically).
Thanks,
~Niels
Bug#909089: debhelper: GNU configure $prefix expanded too early?
Sven Joachim:
> On 2018-09-18 14:09 +0300, Peter Pentchev wrote:
>
>> Package: debhelper
>> Version: 11.4
>> Severity: serious
>>
>> Hi,
>>
>> Thanks for maintaining and extending debhelper!
>>
>> I don't have much information right now, maybe I'll look into it in
>> the evening (Eastern European time), but trying to build gforth in
>> a chroot containing debhelper-11.4 results in a package where all
>> the paths passed to the GNU configure script as "\$prefix/something"
>> are actually defined as "/something", thus placing binaries in /bin,
>> include files in /include, etc. Installing debhelper-11.3.5 fixes
>> the problem.
>
> Bisection shows that commit a7ec05c10093f ("dh: Track which options have
> been passed") has triggered the problem. I had a look at the gforth
> build logs with debhelper 11.3.5 and 11.4, but could not spot an obvious
> cause. Maybe Niels has more luck.
>
> Cheers,
>Sven
>
Hi,
@Sven: Thanks for bisecting it. FTR, which version of gforth did you
test with?
@Both: I checked the configure lines and they are identical
(bit-for-bit) in the log, so we are probably looking for something
different.
I have compared the build logs from Peter with the amd64 build on the
buildds (with some messaging) and I do not see any obvious problems (I
assume the differences shown are due to -6 vs. -7).
"""
Generated the files with:
grep dh_ \
| grep -v 'The use of "debhelper-compat (= 11)" is experimental' \
| sed 's/-a //'
--- dh_broken.log 2018-09-19 08:00:04.640018651 +0200
+++ dh_ok.log 2018-09-19 08:00:20.952018495 +0200
@@ -1,6 +1,5 @@
debian/rules override_dh_auto_clean
dh_auto_clean
- dh_autoreconf_clean -O--no-parallel
dh_clean -O--no-parallel
dh_update_autotools_config -O--no-parallel
dh_autoreconf -O--no-parallel
@@ -15,8 +14,7 @@
debian/rules override_dh_install
dh_installdocs -O--no-parallel
debian/rules override_dh_installchangelogs
-dh_installchangelogs -X ChangeLog
-set -e; for p in $(dh_listpackages); do \
+dh_installchangelogs NEWS
dh_installman -O--no-parallel
dh_installemacsen -O--no-parallel
dh_lintian -O--no-parallel
"""
The dh_autoreconf_clean omission is expected (dh-autoreconf made it
optional so we could avoid calling it in the initial clean where it is
always a no-op) and the remaining diffs looks like a change to the rules.
I also checked the make install part and both logs installs the files
into /<>/debian/tmp/usr/...
@Peter: Could you try to add a "dh_installdirs" (or mkdir -p $(DG)/)
before the following line?
mv /<>/debian/tmp/* /<>/debian/gforth/
https://sources.debian.org/src/gforth/0.7.3+dfsg-6/debian/rules/#L81
Thanks,
~Niels
Bug#909089: debhelper: GNU configure $prefix expanded too early?
Control: tags -1 moreinfo On Tue, 18 Sep 2018 14:09:03 +0300 Peter Pentchev wrote: > Package: debhelper > Version: 11.4 > Severity: serious > > Hi, > > Thanks for maintaining and extending debhelper! > > I don't have much information right now, maybe I'll look into it in > the evening (Eastern European time), but trying to build gforth in > a chroot containing debhelper-11.4 results in a package where all > the paths passed to the GNU configure script as "\$prefix/something" > are actually defined as "/something", thus placing binaries in /bin, > include files in /include, etc. Installing debhelper-11.3.5 fixes > the problem. > > Thanks again for everything you're doing for debhelper and Debian, > and keep up the great work! > > G'luck, > Peter > > [...] Hi Peter, Could you please provide the logs of the build (preferably with "export DH_VERBOSE=1")? Thanks, ~Niels
Bug#909071: pbbam: FTBFS on every release architecture where it previously built
Source: pbbam
Version: 0.18.0+dfsg-1
Severity: serious
Hi,
The pbbam package FTBFS on every release architecture. The following
snippet is from the arm64 build:
"""
# Fix broken PATH
synthetic_movie_all_path=`find $PWD -name synthetic_movie_all.subreadset.xml` ;
\
sed -i -e
"s?.GENERATEDDATADIR/synthetic_movie_all.subreadset.xml?${synthetic_movie_all_path}?"
tests/src/cram/pbbamify*
BINDIR=`dirname $(find $PWD -name pbmerge -type f -executable)`; \
LIBDIR=`find $PWD -name lib -type d`; \
PATH="$BINDIR:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
LD_LIBRARY_PATH="$LIBDIR:" \
cram -v tests/src/cram/pbmerge_pacbio_ordering.deb.t
tests/src/cram/pbmerge_mixed_ordering.deb.t
tests/src/cram/pbmerge_aligned_ordering.deb.t
tests/src/cram/pbindexdump_json.deb.t tests/src/cram/pbindexdump_cpp.deb.t
tests/src/cram/pbmerge_fofn.deb.t tests/src/cram/pbbamify.deb.t
tests/src/cram/pbmerge_dataset.deb.t
tests/src/cram/pbmerge_pacbio_ordering.deb.t: failed
--- tests/src/cram/pbmerge_pacbio_ordering.deb.t
+++ tests/src/cram/pbmerge_pacbio_ordering.deb.t.err
@@ -14,444 +14,104 @@
Sanity Check:
$ samtools view -H $HQREGION_BAM
- @HD\tVN:1.1\tSO:unknown\tpb:3.0.1 (esc)
-
@RG\tID:ca75d884\tPL:PACBIO\tDS:READTYPE=HQREGION;DeletionQV=dq;DeletionTag=dt;InsertionQV=iq;MergeQV=mq;SubstitutionQV=sq;SubstitutionTag=st;Ipd:Frames=ip;PulseWidth:Frames=pw;PkMid=pm;PkMean=pa;LabelQV=pq;AltLabel=pt;AltLabelQV=pv;PulseMergeQV=pg;PulseCall=pc;PrePulseFrames=pd;PulseCallWidth=px;BINDINGKIT=100372700;SEQUENCINGKIT=100356200;BASECALLERVERSION=0.1;FRAMERATEHZ=100.00\tPU:ArminsFakeMovie
(esc)
- @PG\tID:baz2bam-0.15.0\tPN:baz2bam\tVN:0.15.0 (esc)
- @PG\tID:bazFormat-0.3.0\tPN:bazFormat\tVN:0.3.0 (esc)
- @PG\tID:bazwriter-0.15.0\tPN:bazwriter\tVN:0.15.0 (esc)
+ [E::hts_open_format] Failed to open file
/<>/pbbam-0.18.0/tests/data/polymerase/internal.hqregions.bam
+ samtools view: failed to open
"/<>/pbbam-0.18.0/tests/data/polymerase/internal.hqregions.bam" for
reading: No such file or directory
+ [1]
$ samtools view $HQREGION_BAM | cut -f 1
- ArminsFakeMovie/10/2659_7034
+ [E::hts_open_format] Failed to open file
/<>/pbbam-0.18.0/tests/data/polymerase/internal.hqregions.bam
+ samtools view: failed to open
"/<>/pbbam-0.18.0/tests/data/polymerase/internal.hqregions.bam" for
reading: No such file or directory
[...]
"""
Thanks,
~Niels
Bug#908987: litecoin: FTBFS on mips64el in binNMU against qrencode - test failure
Source: litecoin Version: 0.16.0-2 Severity: serious Control: block 908980 by -1 Hi, During the qrencode transition, we noticed that litecoin FTBFS on mips64el. It is not entirely clear that the FTBFS is related to qrencode (from my PoV the failures looks related to cryptography and I would assume qrencode was not used for that). Anyhow, the last bit of the log is: """ FAIL: tests === src/tests.c:200: test condition failed: secp256k1_ecdsa_verify(vrfy, , ctmp, ) == 1 FAIL tests (exit status: 134) Testsuite summary for libsecp256k1 0.1 # TOTAL: 2 # PASS: 1 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See ./test-suite.log make[8]: *** [Makefile:1229: test-suite.log] Error 1 make[8]: Leaving directory '/<>/src/secp256k1' make[7]: *** [Makefile:1337: check-TESTS] Error 2 make[7]: Leaving directory '/<>/src/secp256k1' make[6]: *** [Makefile:1550: check-am] Error 2 make[6]: Leaving directory '/<>/src/secp256k1' make[5]: *** [Makefile:10233: check-local] Error 2 make[5]: Leaving directory '/<>/src' make[4]: *** [Makefile:9333: check-am] Error 2 make[4]: Leaving directory '/<>/src' make[3]: *** [Makefile:9011: check-recursive] Error 1 make[3]: Leaving directory '/<>/src' make[2]: *** [Makefile:748: check-recursive] Error 1 make[2]: Leaving directory '/<>' dh_auto_test: make -j4 check VERBOSE=1 returned exit code 2 make[1]: *** [debian/rules:37: override_dh_auto_test] Error 2 make[1]: Leaving directory '/<>' make: *** [debian/rules:12: build-arch] Error 2 dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 Build finished at 2018-09-17T02:09:46Z """ Note it might be relevant to see the entire log as it appears to list more failures https://buildd.debian.org/status/fetch.php?pkg=litecoin=mips64el=0.16.0-2%2Bb1=1537150206=0 Thanks, ~Niels
Bug#907448: goxel: Ships files in /usr/local
Package: goxel Version: 0.8.0-1 Severity: serious Hi, The goxel binary (on at least amd64) ships files and directories in /usr/local, which is not permitted by the Debian policy. """ [...] drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/applications/ -rw-r--r-- root/root 149 2018-08-18 12:52 ./usr/local/share/applications/goxel.desktop drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/icons/ drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/icons/hicolor/ drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/icons/hicolor/128x128/ drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/icons/hicolor/128x128/apps/ -rw-r--r-- root/root 10628 2018-08-18 12:52 ./usr/local/share/icons/hicolor/128x128/apps/goxel.png drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/icons/hicolor/16x16/ drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/icons/hicolor/16x16/apps/ -rw-r--r-- root/root 686 2018-08-18 12:52 ./usr/local/share/icons/hicolor/16x16/apps/goxel.png drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/icons/hicolor/24x24/ drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/icons/hicolor/24x24/apps/ -rw-r--r-- root/root 1156 2018-08-18 12:52 ./usr/local/share/icons/hicolor/24x24/apps/goxel.png drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/icons/hicolor/256x256/ drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/icons/hicolor/256x256/apps/ -rw-r--r-- root/root 25043 2018-08-18 12:52 ./usr/local/share/icons/hicolor/256x256/apps/goxel.png drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/icons/hicolor/32x32/ drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/icons/hicolor/32x32/apps/ -rw-r--r-- root/root 1712 2018-08-18 12:52 ./usr/local/share/icons/hicolor/32x32/apps/goxel.png drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/icons/hicolor/48x48/ drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/icons/hicolor/48x48/apps/ -rw-r--r-- root/root 3004 2018-08-18 12:52 ./usr/local/share/icons/hicolor/48x48/apps/goxel.png drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/icons/hicolor/64x64/ drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/icons/hicolor/64x64/apps/ -rw-r--r-- root/root 4397 2018-08-18 12:52 ./usr/local/share/icons/hicolor/64x64/apps/goxel.png drwxr-xr-x root/root 0 2018-08-18 12:52 ./usr/local/share/metainfo/ -rw-r--r-- root/root 2879 2018-08-18 12:52 ./usr/local/share/metainfo/io.github.guillaumechereau.Goxel.appdata.xml [...] """ This files looks like they should have been in /usr/ instead of /usr/local/. Please note this is also a regression from 0.7.3-1 (which appears to ship files in the correct paths). Thanks, ~Niels
Bug#907239: ldc: FTBFS on ppc64el with .../disassembler.cpp.o uses 64-bit long double, .../libLLVMCore.a(LegacyPassManager.cpp.o) uses 128-bit long double
Source: ldc Version: 1:1.11.0-1 Severity: serious Hi, The ldc package FTBFS on ppc64el but built there in the past. """ /usr/bin/c++ -DLDC_DYNAMIC_COMPILE -DLDC_DYNAMIC_COMPILE_API_VERSION=1 -DLDC_ENABLE_PLUGINS -DLDC_LLVM_SUPPORTED_TARGET_AArch64=1 -DLDC_LLVM_SUPPORTED_TARGET_AMDGPU=1 -DLDC_LLVM_SUPPORTED_TARGET_ARM=1 -DLDC_LLVM_SUPPORTED_TARGET_AVR=1 -DLDC_LLVM_SUPPORTED_TARGET_BPF=1 -DLDC_LLVM_SUPPORTED_TARGET_Hexagon=1 -DLDC_LLVM_SUPPORTED_TARGET_Lanai=1 -DLDC_LLVM_SUPPORTED_TARGET_MSP430=1 -DLDC_LLVM_SUPPORTED_TARGET_Mips=1 -DLDC_LLVM_SUPPORTED_TARGET_NVPTX=1 -DLDC_LLVM_SUPPORTED_TARGET_PowerPC=1 -DLDC_LLVM_SUPPORTED_TARGET_Sparc=1 -DLDC_LLVM_SUPPORTED_TARGET_SystemZ=1 -DLDC_LLVM_SUPPORTED_TARGET_WebAssembly=1 -DLDC_LLVM_SUPPORTED_TARGET_X86=1 -DLDC_LLVM_SUPPORTED_TARGET_XCore=1 -I/<>/. -I/<>/dmd -I/<>/dmd/root -I/<>/build-static/dmd -I/<> -isystem /usr/lib/llvm-6.0/include -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -DDMDV2 -DHAVE_SC_ARG_MAX -I/usr/lib/llvm-6.0/include -std=c++0x -fuse-ld=gold -Wl,--no-keep-files-mapped -Wl,--no-map-whole-files -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -ffunction-sections -fdata-sections -O2 -DNDEBUG -fno-exceptions -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fno-rtti -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wno-non-virtual-dtor -Wno-pedantic -mlong-double-64 -DLDC_POSIX -DIN_LLVM -DOPAQUE_VTBLS "-DLDC_INSTALL_PREFIX=/usr" -DLDC_LLVM_VER=600 "-DLDC_LIBDIR_SUFFIX=\"\"" -DLDC_HOST_LDMD=1 -DLDC_HOST_FE_VER=2068 -o CMakeFiles/LDCShared.dir/gen/arrays.cpp.o -c /<>/gen/arrays.cpp /usr/bin/ld: CMakeFiles/ldc-jit-rt-so.dir/jit-rt/cpp-so/disassembler.cpp.o uses 64-bit long double, /usr/lib/llvm-6.0/lib/libLLVMCore.a(LegacyPassManager.cpp.o) uses 128-bit long double /usr/bin/ld: failed to merge target specific data of file /usr/lib/llvm-6.0/lib/libLLVMCore.a(LegacyPassManager.cpp.o) collect2: error: ld returned 1 exit status """ This issue prevents ldc from migrating to testing. Thanks, ~Niels
Bug#906460: facter: FTBFS in buster/sid (catching polymorphic type by value)
Control: tags -1 moreinfo On Fri, 17 Aug 2018 19:20:54 + Santiago Vila wrote: > Package: src:facter > Version: 3.11.0-1 > Severity: serious > Tags: ftbfs > > Dear maintainer: > > I tried to build this package in buster but it failed: > > > [...] > > > The build was made with "dpkg-buildpackage -B" in my autobuilder. > Most probably, it also fails here in reproducible builds: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/facter.html > > where you can get a full build log if you need it. > > If this is really a bug in one of the build-depends, please use reassign and > affects, > so that this is still visible in the BTS web page for this package. > > Thanks. Hi, This package was just rebuilt successfully in sid as a part of the libleatherman transition (which also matches the build logs of the reproducible builds project). Can you confirm the problem still exist? Thanks, ~Niels
