Bug#1082898: dhcpcd - Runs as service
pe 27. syysk. 2024 klo 23.51 Bastian Blank (wa...@debian.org) kirjoitti: > Package: dhcpcd > Version: 1:10.0.10-2 > Severity: serious > X-Debbugs-Cc: wa...@debian.org > > dhcpcd runs itself as service, not controlled by the network management. > This makes it not a suitable replacement for isc-dhcp. bin:dhcpcd does run as a service, since it ships the init script and systemd unit, and launches the dhcpcd binary as a daemon. I purposely package these separate precisely to avoid the issue you mentioned. bin:dhcpcd-base doesn't run as a service. It merely provides the binary and exit scripts. Martin-Éric
Bug#1078756: lintian-brush is not updated for 3.12
la 17. elok. 2024 klo 0.56 Chris Hofstaedtler (z...@debian.org) kirjoitti: > > * Martin-Éric Racine [240816 18:49]: > > On Thu, 15 Aug 2024 15:17:53 +0200 Chris Hofstaedtler > > wrote: > > > lintian-brush is built against python3.11. Thus all fixers etc fail, > > > because the 3.11 modules are already gone. > > > > Could at least some of these 4 bugs be fixed by triggering a bin-NMU > > rebuild to at least get rid of python3.11 dependencies? > > https://buildd.debian.org/status/package.php?p=lintian-brush > > Doesn't look like a rebuild would help. Meanwhile: https://qa.debian.org/cgi-bin/vcswatch?package=lintian-brush It seems that at least some of it was already fixed, but is pending a release. Martin-Éric
Bug#1078756: lintian-brush is not updated for 3.12
On Thu, 15 Aug 2024 15:17:53 +0200 Chris Hofstaedtler wrote: > Package: lintian-brush > Version: 0.157 > Severity: serious > > lintian-brush is built against python3.11. Thus all fixers etc fail, > because the 3.11 modules are already gone. > > Gonna merge a few bugs into this one. Could at least some of these 4 bugs be fixed by triggering a bin-NMU rebuild to at least get rid of python3.11 dependencies? Martin-Éric
Bug#1058329: ipxe: FTBFS: arch/x86/core/patch_cf.S:26: Error: 64bit mode not supported on `i386'.
Package: ipxe Version: 1.0.0+git-20190125.36a4c85-5.1 Followup-For: Bug #1058329 Control: tags -1 ftbfs -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 That's because Debian presumes that EFI means x86-64 binary... $ file /boot/ipxe.efi /boot/ipxe.efi: PE32+ executable (DLL) (EFI application) x86-64, for MS Windows, 6 sections $ uname -a Linux u1400 6.10.3-686-pae #1 SMP PREEMPT_DYNAMIC Debian 6.10.3-1 (2024-08-04) i686 GNU/Linux Meanwhile, upstream has been able to generate separate 32-bit and 64-bit EFI images for some time: $ dir -1 Projects/ipxe/src/ arch bin bin-i386-efi bin-i386-linux bin-x86_64-efi config core crypto doc doxygen.cfg drivers hci image include interface libgcc Makefile Makefile.efi Makefile.housekeeping Makefile.linux net scripts tests usr util A new Debian upload that enables this, possibly built along similar methods as memtest86+, would probably fix this. Martin-Éric - -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 6.10.3-686-pae (SMP w/1 CPU thread; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAma5A6kACgkQrh+Cd8S0 17Zg3w//e1oMjh13FudUgsnEgHzzv4rQ3EDpXRxW90ywzdNWrfbCf+zSI/9g2715 ErPYaoFx+/TSPAVcmwsOWUV51bLJ4yFc5oueimQQnTCQx1wzGJpYDouw1Zel0J2O wVZ0EGY/153+oUwg0NELr8MrNx0A5GrTnYQfe//p7/DvrBJB+J+4q/rVTd7y2lSE 7pj3RLydoaL/vDguWQGlONmeudouBW3J76sZ5EDiQydHiqlefVtgDA9baIR/bVcO sshGizbPaTDDbuhCpE1X1zrsg+J6wVUfmfaF7m8amG5ZHfbynL/ZLXtuCbfZtiwm GYQGToAICXCBTImcFJ3fYQaRvMPEJTsYGKFMCNPSGW5xIBkWhIvIBE7NmhD/emco 9yFzCEv3XYQp9G5XAEdyEdVCtxliKHXGqposhOJn63roNCwll9XCn+S5X/dfy3Po 4Lrs9ndHfbnjkRls0mnDQ85oHjZtEnG6EPVfirDPNEBnvX13jX2qaOBfBQ5hwTI9 vUiswnbr2W0pfdbdUru9e7sdQzvOYHJsxOqOKKr7tTlGltIxH2AQGKlD+Fzu+HOA DYc28ABiao8sJzBcNPU8rfViTx4ssGM5qVS7bew6zZMnFlIxBuBwFNw8XgW1DvNM 2QnKN65EkD/RdZ56ipdJoaVwvr2567esYflrmM2l/v40WZS+bNM= =WAnb -END PGP SIGNATURE-
Bug#1078023: login: SIGHUP upon executing 'login'
ti 6. elok. 2024 klo 10.46 Martin-Éric Racine (martin-eric.rac...@iki.fi) kirjoitti: > > ti 6. elok. 2024 klo 10.19 Martin-Éric Racine > (martin-eric.rac...@iki.fi) kirjoitti: > > > > ti 6. elok. 2024 klo 10.13 Chris Hofstaedtler (z...@debian.org) kirjoitti: > > > > > > Control: tags -1 + unreproducible moreinfo > > > > > > On Tue, Aug 06, 2024 at 09:35:52AM +0300, Martin-Éric Racine wrote: > > > > The latest upload to unstable breaks login. Running the 'login' command > > > > consistently returns SIGHUP. This effectively prevents logging in. > > > > > > Works for me. Please provide additional info on when/how this > > > happens. > > > > When is systematically. > > > > I'm really not sure of what info would match 'how'. > > What I run: > > sudo --preserve-env chroot /srv/chroot/unstable-i386/ login "$USER" > > Since this morning's 'login' update, this returns SIGHUP. > > Meanwhile: > > sudo --preserve-env chroot /srv/chroot/stable-amd64/ login "$USER" > > This presents me with the password prompt as normal. PS: reverting to login_4.16.0-1_i386.deb from src:shadow restored functionality. I can login using the above receipe as before. Martin-Éric
Bug#1078023: login: SIGHUP upon executing 'login'
ti 6. elok. 2024 klo 10.19 Martin-Éric Racine (martin-eric.rac...@iki.fi) kirjoitti: > > ti 6. elok. 2024 klo 10.13 Chris Hofstaedtler (z...@debian.org) kirjoitti: > > > > Control: tags -1 + unreproducible moreinfo > > > > On Tue, Aug 06, 2024 at 09:35:52AM +0300, Martin-Éric Racine wrote: > > > The latest upload to unstable breaks login. Running the 'login' command > > > consistently returns SIGHUP. This effectively prevents logging in. > > > > Works for me. Please provide additional info on when/how this > > happens. > > When is systematically. > > I'm really not sure of what info would match 'how'. What I run: sudo --preserve-env chroot /srv/chroot/unstable-i386/ login "$USER" Since this morning's 'login' update, this returns SIGHUP. Meanwhile: sudo --preserve-env chroot /srv/chroot/stable-amd64/ login "$USER" This presents me with the password prompt as normal. Martin-Éric
Bug#1078023: login: SIGHUP upon executing 'login'
ti 6. elok. 2024 klo 10.13 Chris Hofstaedtler (z...@debian.org) kirjoitti: > > Control: tags -1 + unreproducible moreinfo > > On Tue, Aug 06, 2024 at 09:35:52AM +0300, Martin-Éric Racine wrote: > > The latest upload to unstable breaks login. Running the 'login' command > > consistently returns SIGHUP. This effectively prevents logging in. > > Works for me. Please provide additional info on when/how this > happens. When is systematically. I'm really not sure of what info would match 'how'. Martin-Éric
Bug#1078023: login: SIGHUP upon executing 'login'
Package: login Version: 1:4.16.0-2+really2.40.2-4 Severity: grave Justification: renders package unusable The latest upload to unstable breaks login. Running the 'login' command consistently returns SIGHUP. This effectively prevents logging in. I've thus had to do backflips with 'chroot' and 'su' just to be able to file this bug report. Martin-Éric -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 6.1.0-23-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages login depends on: ii libaudit1 1:3.1.2-4+b1 ii libc6 2.39-6 ii libcrypt1 1:4.4.36-4 ii libpam-modules 1.5.3-7 ii libpam-runtime 1.5.3-7 ii libpam0g1.5.3-7 ii login.defs 1:4.16.0-4 login recommends no packages. login suggests no packages. -- no debconf information
Bug#1050805: dhcpcd-base: DoS: zero-length packet cause eventual lease expiration
to 20. kesäk. 2024 klo 11.32 Nicolas Cavallari (nicolas.cavall...@green-communications.fr) kirjoitti: > > On 18/06/2024 16:39, Martin-Éric Racine wrote: > > ti 18. kesäk. 2024 klo 15.52 Nicolas Cavallari > > (nicolas.cavall...@green-communications.fr) kirjoitti: > >> > >> On 18/06/2024 13:14, Martin-Éric Racine wrote: > >>> su 16. kesäk. 2024 klo 9.05 Martin-Éric Racine > >>> (martin-eric.rac...@iki.fi) kirjoitti: > >>>> > >>>> la 15. kesäk. 2024 klo 16.55 Nicolas Cavallari > >>>> (nicolas.cavall...@green-communications.fr) kirjoitti: > >>>> > >>>>> I didn't check if there were any adverse effect or if leases are still > >>>>> renewed. I can't check on the production system before Monday. > >>>> > >>>> Please let me know. > >>> > >>> Any news on this? > >> > >> My dedicated server receives leases of 86400s, it takes a while to check > >> if leases are renewed correctly. > > > > Noted. > > After two days and multiples renews, I can confirm that it works. Excellent. I'll upload to bookworm-pu. Martin-Éric
Bug#1050805: dhcpcd-base: DoS: zero-length packet cause eventual lease expiration
ti 18. kesäk. 2024 klo 15.52 Nicolas Cavallari (nicolas.cavall...@green-communications.fr) kirjoitti: > > On 18/06/2024 13:14, Martin-Éric Racine wrote: > > su 16. kesäk. 2024 klo 9.05 Martin-Éric Racine > > (martin-eric.rac...@iki.fi) kirjoitti: > >> > >> la 15. kesäk. 2024 klo 16.55 Nicolas Cavallari > >> (nicolas.cavall...@green-communications.fr) kirjoitti: > >> > >>> I didn't check if there were any adverse effect or if leases are still > >>> renewed. I can't check on the production system before Monday. > >> > >> Please let me know. > > > > Any news on this? > > My dedicated server receives leases of 86400s, it takes a while to check > if leases are renewed correctly. Noted. > I installed it today. For some reason, dhcpcd was stopped when upgrading > the 'dhcpcd' package but was not restarted afterward. Looking at the > dhcpcd maintainer scripts, I see the deb-systemd-invoke stop in preinst > but i don't see any start in postinst or anywhere else. Which was fixed in Testing a while back. For Stable, this is what I would upload, once you've confirmed that the 3 cherry-picks work: dhcpcd5 (9.4.1-24~deb12u4) bookworm; urgency=medium * Add --no-stop-on-upgrade --no-restart-after-upgrade (Closes: #1057959). * Cherry-pick upstream backported fixes for RC bug (Closes: #1050805). * Update dhcpcd.preinst version check to match current one. On the plus side, no attempt will be made to restart it, to prevent connection loss. On the minus side, it means that the administrator must restart manually or reboot. Martin-Éric
Bug#1050805: dhcpcd-base: DoS: zero-length packet cause eventual lease expiration
su 16. kesäk. 2024 klo 9.05 Martin-Éric Racine (martin-eric.rac...@iki.fi) kirjoitti: > > la 15. kesäk. 2024 klo 16.55 Nicolas Cavallari > (nicolas.cavall...@green-communications.fr) kirjoitti: > > > > On 15/06/2024 11:33, Martin-Éric Racine wrote: > > > On Tue, 29 Aug 2023 13:17:51 +0200 Nicolas Cavallari > > >> This affects version 9.4.1-22 (stable) and 1:9.4.1-24~deb12u2 > > >> (stable proposed update) but not 1:10.0.2-4 (testing/unstable) as > > >> upstream fixed it in 10.0.2: > > >> > > >> Upstream Bug report: > > >> https://github.com/NetworkConfiguration/dhcpcd/issues/179 > > >> Upstream Fix: > > >> https://github.com/NetworkConfiguration/dhcpcd/commit/8b29c0ddf026c1c5647c3b8c6cfe21699c4056ae > > >> > > >> This patch does not apply cleanly to 9.4.1 because the privsep > > >> structure changed in 10.0.2. It's likely that only the src/privsep.c > > >> hunks about len == 0 and eloop_exit() needs to be backported, the other > > >> changes are just here to avoid compiler warnings about unused > > >> parameters. > > > > > > Upstream got around releasing a backport of this for branch 9 as > > > commits 53e2f6de4ba87d0534c89cae674e6c1a48724ef0 and > > > 6e127eac6903524d401b31893167e4529b8ab111 respectively. > > > > > > You are hereby invited to test and report whether this fixes it for > > > Stable. > > > > I did some quick tests on a VM: > > > > First, with 9.4.1-24~deb12u3 as present in debian stable: > > > Then I apt sourced dhcpcd, applied the two patches, rebuilt debian > > packages and tested them. The situation is now worse: > > > I then tested this patch from issue #283: > > > > https://github.com/NetworkConfiguration/dhcpcd/commit/727c78f503d456875e2a3cee7609288b537d9d25.patch > > > > And this time, it appears to fix the problem: > > > I didn't check if there were any adverse effect or if leases are still > > renewed. I can't check on the production system before Monday. > > Please let me know. Any news on this? Martin-Éric
Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out
to 13. kesäk. 2024 klo 11.52 Martin-Éric Racine (martin-eric.rac...@iki.fi) kirjoitti: > > Adding the dnsmasq maintainer in CC. > > to 13. kesäk. 2024 klo 11.39 Paul Gevers (elb...@debian.org) kirjoitti: > > On 13-06-2024 3:36 a.m., Martin-Éric Racine wrote: > > > Subsequent ones randomly timeout waiting for an IP from the DHCP > > > server. This could well be an issue with dnsmasq, which is what we use > > > for the test. Alternately, it could be caused by those constant fails > > > on glibc. Without more detailed logs, I am not in a position to > > > investigate this. Help is welcome. > > > > Well, I can't give you more logs than what your test writes. So that's > > in your hands, I suggest you try and make the test more verbose of > > what's going on, or maybe ensure some logs end up in the artifacts for > > inspection. Also, if dnsmasq is the problem, you might want to contact > > the maintainer and discuss the issue (e.g. in a bug report). From my > > standpoint, it's the autopkgtest of dhcpcd that's having issues and that > > *is* an issue for src:dhcpcd. You could reassign this bug and mark it > > "affects dhcpcd". > > I'm curious to hear whether any of what appears in the log rings any > bell for Simon. > > > I acknowledge that something fishy seems to be ongoing in the archive > > when new version of src:glibc binaries appear (not only with dhcpcd I > > mean). For now I'll not hold that against autopkgtest failures of > > packages too much. > > Which is where I suspect the real issue is. > > Personally, I already find it suspicious that the tracker tells me > about unrelated packages' transitions or issues. If the problem is in > someone else's code, while mine hasn't changed in ages, that's where > the bug report needs to go. In this case, dhcpcd's autopkgtest hasn't > changed in ages, and has been verified to work as-is at Ubuntu, where > isolation machines were implemented a long time before Debian. Sorry Paul but, at this point, I'm gonna call CI itself flaky. Right now, CI hasn't even registered any test attemps for recent uploads to Unstable and its results for Testing out of sync. Given this, if you're gonna start mass-filing bugs against any package whose test reults show discrepancy, first make sure that, in fact, your code is not the one causing others unnecesary work. Martin-Éric
Bug#1050805: dhcpcd-base: DoS: zero-length packet cause eventual lease expiration
la 15. kesäk. 2024 klo 16.55 Nicolas Cavallari (nicolas.cavall...@green-communications.fr) kirjoitti: > > On 15/06/2024 11:33, Martin-Éric Racine wrote: > > On Tue, 29 Aug 2023 13:17:51 +0200 Nicolas Cavallari > >> This affects version 9.4.1-22 (stable) and 1:9.4.1-24~deb12u2 > >> (stable proposed update) but not 1:10.0.2-4 (testing/unstable) as > >> upstream fixed it in 10.0.2: > >> > >> Upstream Bug report: > >> https://github.com/NetworkConfiguration/dhcpcd/issues/179 > >> Upstream Fix: > >> https://github.com/NetworkConfiguration/dhcpcd/commit/8b29c0ddf026c1c5647c3b8c6cfe21699c4056ae > >> > >> This patch does not apply cleanly to 9.4.1 because the privsep > >> structure changed in 10.0.2. It's likely that only the src/privsep.c > >> hunks about len == 0 and eloop_exit() needs to be backported, the other > >> changes are just here to avoid compiler warnings about unused > >> parameters. > > > > Upstream got around releasing a backport of this for branch 9 as > > commits 53e2f6de4ba87d0534c89cae674e6c1a48724ef0 and > > 6e127eac6903524d401b31893167e4529b8ab111 respectively. > > > > You are hereby invited to test and report whether this fixes it for Stable. > > I did some quick tests on a VM: > > First, with 9.4.1-24~deb12u3 as present in debian stable: > Then I apt sourced dhcpcd, applied the two patches, rebuilt debian > packages and tested them. The situation is now worse: > I then tested this patch from issue #283: > > https://github.com/NetworkConfiguration/dhcpcd/commit/727c78f503d456875e2a3cee7609288b537d9d25.patch > > And this time, it appears to fix the problem: So you had to apply 3 patches to fix 9.4.1 in Stable? The 2 aforementioned ones and the one from upstream issue 283? > I didn't check if there were any adverse effect or if leases are still > renewed. I can't check on the production system before Monday. Please let me know. Martin-Éric
Bug#1050805: dhcpcd-base: DoS: zero-length packet cause eventual lease expiration
On Tue, 29 Aug 2023 13:17:51 +0200 Nicolas Cavallari wrote: > Package: dhcpcd-base > Version: 9.4.1-22 > Severity: critical > Tags: security > Justification: breaks unrelated software > X-Debbugs-Cc: Debian Security Team > > When the dhcpcd DHCPv4 client receives a zero-length UDP packet on port > 68, the "network proxy" dhcpcd process exits with status 0. dhcpcd then > stops all network activity: It does not renew leases and eventually expires > the current lease (unless it has infinite duration) and removes the IP > address, leaving the system without networking. > > This bug can be triggered remotely over the internet from any UDP port > and is critical on an internet-facing system that needs DHCP to get > an IP address, such as a gateway, a dedicated server or a VM. > > This affects version 9.4.1-22 (stable) and 1:9.4.1-24~deb12u2 > (stable proposed update) but not 1:10.0.2-4 (testing/unstable) as > upstream fixed it in 10.0.2: > > Upstream Bug report: https://github.com/NetworkConfiguration/dhcpcd/issues/179 > Upstream Fix: > https://github.com/NetworkConfiguration/dhcpcd/commit/8b29c0ddf026c1c5647c3b8c6cfe21699c4056ae > > This patch does not apply cleanly to 9.4.1 because the privsep > structure changed in 10.0.2. It's likely that only the src/privsep.c > hunks about len == 0 and eloop_exit() needs to be backported, the other > changes are just here to avoid compiler warnings about unused > parameters. Upstream got around releasing a backport of this for branch 9 as commits 53e2f6de4ba87d0534c89cae674e6c1a48724ef0 and 6e127eac6903524d401b31893167e4529b8ab111 respectively. You are hereby invited to test and report whether this fixes it for Stable. Martin-Éric
Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out
Adding the dnsmasq maintainer in CC. to 13. kesäk. 2024 klo 11.39 Paul Gevers (elb...@debian.org) kirjoitti: > On 13-06-2024 3:36 a.m., Martin-Éric Racine wrote: > > Subsequent ones randomly timeout waiting for an IP from the DHCP > > server. This could well be an issue with dnsmasq, which is what we use > > for the test. Alternately, it could be caused by those constant fails > > on glibc. Without more detailed logs, I am not in a position to > > investigate this. Help is welcome. > > Well, I can't give you more logs than what your test writes. So that's > in your hands, I suggest you try and make the test more verbose of > what's going on, or maybe ensure some logs end up in the artifacts for > inspection. Also, if dnsmasq is the problem, you might want to contact > the maintainer and discuss the issue (e.g. in a bug report). From my > standpoint, it's the autopkgtest of dhcpcd that's having issues and that > *is* an issue for src:dhcpcd. You could reassign this bug and mark it > "affects dhcpcd". I'm curious to hear whether any of what appears in the log rings any bell for Simon. > I acknowledge that something fishy seems to be ongoing in the archive > when new version of src:glibc binaries appear (not only with dhcpcd I > mean). For now I'll not hold that against autopkgtest failures of > packages too much. Which is where I suspect the real issue is. Personally, I already find it suspicious that the tracker tells me about unrelated packages' transitions or issues. If the problem is in someone else's code, while mine hasn't changed in ages, that's where the bug report needs to go. In this case, dhcpcd's autopkgtest hasn't changed in ages, and has been verified to work as-is at Ubuntu, where isolation machines were implemented a long time before Debian. Martin-Éric
Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out
ke 12. kesäk. 2024 klo 7.20 Martin-Éric Racine (martin-eric.rac...@iki.fi) kirjoitti: > > ti 11. kesäk. 2024 klo 23.21 Paul Gevers (elb...@debian.org) kirjoitti: > > > > Source: dhcpcd > > Version: 1:10.0.8-1 > > Severity: serious > > User: debian...@lists.debian.org > > Usertags: flaky > > > > Dear maintainer(s), > > > > I looked at the results of the autopkgtest of your package because it > > was tested for glibc. I noticed that it regularly fails. > > > > Because the unstable-to-testing migration software now blocks on > > regressions in testing, flaky tests, i.e. tests that flip between > > passing and failing without changes to the list of installed packages, > > are causing people unrelated to your package to spend time on these > > tests. > > > > Don't hesitate to reach out if you need help and some more information > > from our infrastructure. > > This is a non-bug. This package has only one test and it requires an > isolation machine. amd64 is the only architecture that provides it. > Other architectures will always be marked flakey. Additionally, > looking at the tracker for this package, amd64 always passes. This being said, if you can spot what makes it randomly fails, please do send me a patch. Martin-Éric
Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out
ti 11. kesäk. 2024 klo 23.21 Paul Gevers (elb...@debian.org) kirjoitti: > > Source: dhcpcd > Version: 1:10.0.8-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: flaky > > Dear maintainer(s), > > I looked at the results of the autopkgtest of your package because it > was tested for glibc. I noticed that it regularly fails. > > Because the unstable-to-testing migration software now blocks on > regressions in testing, flaky tests, i.e. tests that flip between > passing and failing without changes to the list of installed packages, > are causing people unrelated to your package to spend time on these > tests. > > Don't hesitate to reach out if you need help and some more information > from our infrastructure. This is a non-bug. This package has only one test and it requires an isolation machine. amd64 is the only architecture that provides it. Other architectures will always be marked flakey. Additionally, looking at the tracker for this package, amd64 always passes. Martin-Éric
Bug#1072857: dput: Incorrect delayed argument: ValueError: delayed days value must be a decimal integer:
ma 10. kesäk. 2024 klo 2.18 Ben Finney (bign...@debian.org) kirjoitti: > > Howdy Martin-Éric, > > On 09-Jun-2024, Martin-Éric Racine wrote: > > > Incorrect delayed argument: ValueError: delayed days value must be a > > decimal integer: > > > > I did not specify any delayed queue, so I am perplexed as to what > > produced this. > > You did not specify a command-line option for the delayed queue; but your > configuration file does specify a value. > > […] > > So, that configuration section overrides default behaviour and specifies > empty-string values for many options that would otherwise have no value > defined. The script ANDs /etc/dput.cf and the user's own. My config actually is much shorter than that. Martin-Éric
Bug#1061519: shim: all CVEs fixed in upstream 15.8, please package
Package: shim Followup-For: Bug #1061519 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 shim 15.8 @vathpela vathpela released this 23 Jan 19:01 What's New * Various CVE fixes: CVE-2023-40546 mok: fix LogError() invocation CVE-2023-40547 - avoid incorrectly trusting HTTP headers CVE-2023-40548 Fix integer overflow on SBAT section size on 32-bit system CVE-2023-40549 Authenticode: verify that the signature header is in bounds. CVE-2023-40550 pe: Fix an out-of-bound read in verify_buffer_sbat() CVE-2023-40551: pe-relocate: Fix bounds check for MZ binaries -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmXIZ50ACgkQrh+Cd8S0 17ZHWhAAge996R8VG8WR1eoqM13HYsAvDh/ITPOHEAInuAvxnxW2f77RQuAdh/lL SK0++9aR6P2yQu1j+JjfRz7vBt4FQ1j08RkjYj3kpKq8nHdA6C0fg1OvqXKs5+lc 44noX5AfKGyYDu/EhNkmAdFmE98sRVRqLlu8Ilfg1r8/voYFLOeyplW1T5Pk9xqW Uv+wvLFNyj5mxMakPRyuZWD0bjkw33GYHKHMG5uB1ElwKws8cS/Lh9ZjaDk0GBy+ m4v0mhsIghPCcrNSfNcxvBT7fzR0dsD/wO21rBLcJc3ExdCeA39U4+jO86TS2/39 cfJhaY5FO72F8kX5qDKsNJzvl8Bhq4gH7YtEqyZC9aYdQgSpUdAuU6RQu9zDvpZm EKuJVmXlgc+4IhgYLzJDHH2rL9gI2IctMNPwlKPI89SVs5J+Ha11t8V6oC36Chgq nWrJeWnAhgHiDoTwHwqsj2j3YAVE7lHrAcxqgN1Sl5knmO26qxf8ZgrjB3iR/lVR ufjBnkN+MJaN5oSV4XUTOlOk8uDswtQ1b6ycJAHbA+XhyHcHLRFY4bLVuDviJFsd c3HGcsjzEwepvkg5mmKBm9renLxyUkqhiXQ7JSr5nKWlkaz5DR/4t74sfPjm1qK2 jsugjusiKZG4D895vQ3QcDafL4hdpqgpfi8k4O/Xbq5ncFIjs4Y= =bM7B -END PGP SIGNATURE-
Bug#1040714: dhcpcd: Missing epoch from souce package version
On Tue, Jul 11, 2023 at 10:05 PM Salvatore Bonaccorso wrote: > On Tue, Jul 11, 2023 at 06:30:38PM +0300, Martin-Éric Racine wrote: > > Reintroducing the epoch produces the following Lintian ERROR: > > > > E: dhcpcd source: > > epoch-changed-but-upstream-version-did-not-go-backwards 10.0.1-2 -> > > 1:10.0.1-3 [debian/changelog:1] > > The lintian tag in it's intention is clear. But I believe in this case > it reports in error. Because the history of the dhcpcd source package > is as follows, cutting of some irrelevant inbetween steps: > > 0.4-1 -> 1.3.8-0.1 -> 1:0.70-5 (epoch introduced here), then moved > upwards -> 1:3.2.3-11 / 1:3.2.3-11+deb7u1 which was the last version > available for a while. > > But then we dropped to 10.0.1-1 (which already missed the epoch). > > Now the lintian just only checks 10.0.1-2 -> 1:10.0.1-3 and thinks to > report that the epoch addition is an error, but it would not if all > the 10.0.1-1, 10.0.1-2 versions already had the epoch still. > > Does this make sense? Makes sense to me. Uploaded to Mentors. Please note that Mentors forces me to 'debuild -sa' because it cannot find the 'orig' on its repository even though it's already in unstable. Martin-Éric
Bug#1040714: dhcpcd: Missing epoch from souce package version
On Mon, Jul 10, 2023 at 7:30 PM Martin-Éric Racine wrote: > > On Mon, Jul 10, 2023 at 7:05 PM Salvatore Bonaccorso > wrote: > > On Sun, Jul 09, 2023 at 10:39:59PM +0300, Martin-Éric Racine wrote: > > > On Sun, Jul 9, 2023 at 10:33 PM Salvatore Bonaccorso > > > wrote: > > > > On Sun, Jul 09, 2023 at 09:25:33PM +0200, Salvatore Bonaccorso wrote: > > > > > Source: dhcpcd > > > > > Version: 10.0.1-1 > > > > > Severity: serious > > > > > Justification: Debian version goes backwards from previous released > > > > > versions > > > > > X-Debbugs-Cc: car...@debian.org > > > > > > > > > > Hi > > > > > > > > > > The new src:dhcpcd has a lower version of any previous released > > > > > src:dhcpd version, which had an epoch: > > > > > > > > Apologies for the typo, should be src:dhcpcd in both cases obviously > > > > :( > > > > > > Which is a slightly different issue than what Andtreas reported at > > > #1037190. Sorry. > > > > No problem, just reopenng while we discuss it. > > Agreed. > > > > Unless I'm mistaken, we're basically looking at 2 separate issues: > > > > > > 1) bin:dhcpcd from Wheezy has a higher epoch that the one in Bookworm. > > > This is easily fixed as explained in #1037190 for Bookworm. > > > > > > 2) Since transiting the source from src:dhcpcd5 to src:dhcpcd we're > > > missing an epoch for everything. This requires reverting the above fix > > > and simply introducing an epoch for the whole src and binaries. > > > > Yes correct, this is maninly as well what I was referring to. But that > > would solve as well at same time the former issue right, if we drop > > all special casing for epoch on the binary packages, is this correct? > > In Trixie, for the version, it would. Just insert the epoch for the > whole source (which would apply to the binaries generated too) and > we're done. > > However, we still need that preinst script to clean up possible Wheezy > leftovers. > > In Bookworm, we'll still need the version mingle just for one binary > target. debdiff for stable-proposed-updates are on #1037190 and the > upload is ready on Mentors. > > > So if we add the epoch to the whole src;dhcpcd version, and to the > > produced binaries I think all the issues should be resolved. > > > > My background is here: > > https://security-tracker.debian.org/tracker/source-package/dhcpcd > > e.g. https://security-tracker.debian.org/tracker/CVE-2002-1403 will be > > considered not yet fixed, because for dpkg: > > > > $ dpkg --compare-versions 1:1.3.22pl2-2 lt 10.0.1-1 > > $ echo $? > > 1 > > I was actually wondering how to close those old CVE against the old fork. > > > > Or have I misunderstood the issue? > > > > No, I think we are on the same page in my understnding! > > Excellent. Reintroducing the epoch produces the following Lintian ERROR: E: dhcpcd source: epoch-changed-but-upstream-version-did-not-go-backwards 10.0.1-2 -> 1:10.0.1-3 [debian/changelog:1] Martin-Éric
Bug#1040714: dhcpcd: Missing epoch from souce package version
On Mon, Jul 10, 2023 at 7:05 PM Salvatore Bonaccorso wrote: > On Sun, Jul 09, 2023 at 10:39:59PM +0300, Martin-Éric Racine wrote: > > On Sun, Jul 9, 2023 at 10:33 PM Salvatore Bonaccorso > > wrote: > > > On Sun, Jul 09, 2023 at 09:25:33PM +0200, Salvatore Bonaccorso wrote: > > > > Source: dhcpcd > > > > Version: 10.0.1-1 > > > > Severity: serious > > > > Justification: Debian version goes backwards from previous released > > > > versions > > > > X-Debbugs-Cc: car...@debian.org > > > > > > > > Hi > > > > > > > > The new src:dhcpcd has a lower version of any previous released > > > > src:dhcpd version, which had an epoch: > > > > > > Apologies for the typo, should be src:dhcpcd in both cases obviously > > > :( > > > > Which is a slightly different issue than what Andtreas reported at > > #1037190. Sorry. > > No problem, just reopenng while we discuss it. Agreed. > > Unless I'm mistaken, we're basically looking at 2 separate issues: > > > > 1) bin:dhcpcd from Wheezy has a higher epoch that the one in Bookworm. > > This is easily fixed as explained in #1037190 for Bookworm. > > > > 2) Since transiting the source from src:dhcpcd5 to src:dhcpcd we're > > missing an epoch for everything. This requires reverting the above fix > > and simply introducing an epoch for the whole src and binaries. > > Yes correct, this is maninly as well what I was referring to. But that > would solve as well at same time the former issue right, if we drop > all special casing for epoch on the binary packages, is this correct? In Trixie, for the version, it would. Just insert the epoch for the whole source (which would apply to the binaries generated too) and we're done. However, we still need that preinst script to clean up possible Wheezy leftovers. In Bookworm, we'll still need the version mingle just for one binary target. debdiff for stable-proposed-updates are on #1037190 and the upload is ready on Mentors. > So if we add the epoch to the whole src;dhcpcd version, and to the > produced binaries I think all the issues should be resolved. > > My background is here: > https://security-tracker.debian.org/tracker/source-package/dhcpcd > e.g. https://security-tracker.debian.org/tracker/CVE-2002-1403 will be > considered not yet fixed, because for dpkg: > > $ dpkg --compare-versions 1:1.3.22pl2-2 lt 10.0.1-1 > $ echo $? > 1 I was actually wondering how to close those old CVE against the old fork. > > Or have I misunderstood the issue? > > No, I think we are on the same page in my understnding! Excellent. Martin-Éric
Bug#1040714: dhcpcd: Missing epoch from souce package version
On Sun, Jul 9, 2023 at 10:33 PM Salvatore Bonaccorso wrote: > On Sun, Jul 09, 2023 at 09:25:33PM +0200, Salvatore Bonaccorso wrote: > > Source: dhcpcd > > Version: 10.0.1-1 > > Severity: serious > > Justification: Debian version goes backwards from previous released versions > > X-Debbugs-Cc: car...@debian.org > > > > Hi > > > > The new src:dhcpcd has a lower version of any previous released > > src:dhcpd version, which had an epoch: > > Apologies for the typo, should be src:dhcpcd in both cases obviously > :( Which is a slightly different issue than what Andtreas reported at #1037190. Sorry. Unless I'm mistaken, we're basically looking at 2 separate issues: 1) bin:dhcpcd from Wheezy has a higher epoch that the one in Bookworm. This is easily fixed as explained in #1037190 for Bookworm. 2) Since transiting the source from src:dhcpcd5 to src:dhcpcd we're missing an epoch for everything. This requires reverting the above fix and simply introducing an epoch for the whole src and binaries. Or have I misunderstood the issue? Martin-Éric
Bug#1040714: dhcpcd: Missing epoch from souce package version
On Sun, Jul 9, 2023 at 10:27 PM Salvatore Bonaccorso wrote: > > Source: dhcpcd > Version: 10.0.1-1 > Severity: serious > Justification: Debian version goes backwards from previous released versions > X-Debbugs-Cc: car...@debian.org > > Hi > > The new src:dhcpcd has a lower version of any previous released > src:dhcpd version, which had an epoch: > > 1:3.2.3-11+deb7u1 > 1:3.2.3-11 > 1:3.2.3-10 > 1:3.2.3-9 > 1:3.2.3-8 > 1:3.2.3-7 > 1:3.2.3-6 > 1:3.2.3-5+squeeze2 > 1:3.2.3-5+squeeze1 > 1:3.2.3-5 > 1:3.2.3-4 > 1:3.2.3-3 > 1:3.2.3-2 > 1:3.2.3-1.1 > 1:3.2.3-1 > 1:3.2.2-1 > 1:3.0.17-2 > 1:3.0.17-1 > 1:2.0.3-1 > 1:2.0.2-1 > 1:2.0.1-1 > 1:2.0.0-2 > 1:2.0.0-1 > 1:1.3.22pl4-22 > 1:1.3.22pl4-21sarge1 > 1:1.3.22pl4-21 > 1:1.3.22pl4-20 > 1:1.3.17pl2-8.1 > 1:1.3.17pl2-8 > 1:0.70-5 > 1.3.8-0.1 > 0.70-3 > 0.6-1 > 0.4-1 > > Regards, > Salvatore This was already reported at #1037190. Closing. Martin-Éric
Bug#1037190: dhcpcd: version is lower than in wheezy
On Wed, Jun 7, 2023 at 3:09 PM Andreas Beckmann wrote: > > Package: dhcpcd > Version: 9.4.1-22 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > wheezy had a dhcpcd binary package built from src:dhcpcd at version > 1:3.2.3-11+deb7u1 while bookworm has one built from src:dhcpcd5 at > version 9.4.1-22 which is lower, violating the archive property of > monotonically increasing version numbers. You are talking about a version that is even older than what's in oldstable. Sorry, but that really doesn't qualify as Severity:serious. This being said, this is something that is easily fixed by re-introducing the epoch. Whether this is really worth the trouble given how the discrepancy dates back to something even older than oldstable is an entirely different issue. Martin-Éric
Bug#1029174: Bug#1029176: please check dhcpcd 9.4.1-14 in unstable
On Thu, Jan 19, 2023 at 10:25 PM Beat Bolli wrote: > On 19.01.23 16:35, Martin-Éric Racine wrote: > > We've just pushed dhcpcd 9.4.1-14 into unstable. Can you please check > > whether that fixes it? > > Indeed, this new version works. Marking FIXED as of 9.4.1-14 . I'll wait until it has trickled down to Testing before closing. Martin-Éric
Bug#1029174: please check dhcpcd 9.4.1-14 in unstable
Greetings, Something tells me that both of you have encountered the same bug. We've just pushed dhcpcd 9.4.1-14 into unstable. Can you please check whether that fixes it? Martin-Éric
Bug#1017425: closed by Debian FTP Masters (reply to Salvatore Bonaccorso ) (Bug#1017425: fixed in linux 5.19.6-1)
] >* [hppa] Drop CONFIG_PATA_LEGACY for hppa architecture > . >[ Salvatore Bonaccorso ] >* [rt] Refresh "rcutorture: Also force sched priority to timersd on > boosting > test." >* Drop setting of CRYPTO_BLAKE2S > crypto: blake2s shash module was removed upstream. >* [arm] arch/arm/crypto: Enable CRYPTO_BLAKE2S_ARM >* certs: Rotate to use the "Debian Secure Boot Signer 2022 - linux" > certificate (Closes: #1018752) >* Set ABI to 1 >* [hppa/parisc64] Drop explicit setting of 64BIT > Checksums-Sha1: > 42a3c472d3128c9f851b9416e674497e8ddfd252 251841 linux_5.19.6-1.dsc > 1aac6f7bbdd6de2d32a8e8da75b163d79383d207 133767148 linux_5.19.6.orig.tar.xz > feabaae96187bad30f3967959c0c955fd050082c 1318072 linux_5.19.6-1.debian.tar.xz > 0db0b77cb3cdeee0a626e24fed1828d455bacb93 6975 linux_5.19.6-1_source.buildinfo > Checksums-Sha256: > 4cc09d519dbd22b1b2ca074b98c3caf101494982e170fafa858d6ee930b18b4f 251841 > linux_5.19.6-1.dsc > 57b61adbafbd97e41da2153a2733ba3d3d2963c96d391ce57b29c0bb58010de4 133767148 > linux_5.19.6.orig.tar.xz > e3f6a4e6191a0e67678dacba4beea0dcf61fc0d90a96ceb79d993f41f4da9275 1318072 > linux_5.19.6-1.debian.tar.xz > 6ed558d70babbcfcc1d648d319eac9e639b973693e68ee99d5121c38875edbdd 6975 > linux_5.19.6-1_source.buildinfo > Files: > 08b47f7b67275e2180c0aa6b4d9dfe9e 251841 kernel optional linux_5.19.6-1.dsc > f968bf5c2f82b1dc40754fde8bcbfddb 133767148 kernel optional > linux_5.19.6.orig.tar.xz > 086b762bf7e3734ab211ecfad57d8c58 1318072 kernel optional > linux_5.19.6-1.debian.tar.xz > 0db0c08b0dc5c25e6042db1c5feaffe3 6975 kernel optional > linux_5.19.6-1_source.buildinfo > > -BEGIN PGP SIGNATURE- > > iQKmBAEBCgCQFiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmMQWkRfFIAALgAo > aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2 > NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQSHGNhcm5pbEBk > ZWJpYW4ub3JnAAoJEAVMuPMTQ89E8vUP/iCUO04lUb4AauAGRemK+AlnyZnh++oM > tuqA/FWYUX+iuIE3CyutJgCFGxIGru7Hc3kHtJchbeZM90DbTo/kDlH+M0T6+24i > PMWLuHRWZScJVpOO3ZhJ4nni5/T1r+Q1BjUYYfB3Skvxwu6KNJCTWpBXUekgsMAx > IGviP7jg7T1wNlxfLFLHkPaHDUOGQ9N8jqVJRJgBC5XF3aquGw6GVeS2HKISFSg0 > 83RdmmBlN38V9xOiggzKKIxj9OCcdVc17bGNUQsXmxYmhgoqbzE43F+CBE7JAqzH > 9Z2GHTMJvha2hNKLaHoNEcXn6aJMEkszXaFFiILkO6diZbX971jp39KfnuVzQ7J5 > RypFZtVGXTQXvzPksalMDCVQgGzU5KBukb6Q0D9b2M49gMvWfCNrrwpTNu25+do4 > e/OMgIUgk7dsoUtBr9Iqa5saBP1NULFumWW2N8S1qAyvilOYryYCt2ZTsuvsi1cy > NfVzUfyhyK1sY1HIDIz/+ufcfwWTNAh5TpfZeceeaKZDSDCPH3c/E/8NJxCP3mr6 > JLT3NXzCDe26YHqDjLKWnbZy9aYbyEpcnmgPA7KuRx+YLGyJ3B7xPIGPvEQsbCsJ > UEQ126lBAtulJ1YiCHaGRcCJTS1W6cerPBYF34oTy5GyCky3xcHSnd0qEWXDlw6k > fESUPZGDwiGd > =agDJ > -END PGP SIGNATURE- > > > -- Forwarded message -- > From: "Martin-Éric Racine" > To: Debian Bug Tracking System > Cc: > Bcc: > Date: Tue, 16 Aug 2022 06:57:22 +0300 > Subject: 5.10.0-17-686-pae: repeatedly crashes during initrd loading [PIII] > Package: src:linux > Version: 5.10.136-1 > Severity: grave > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > 5.10.0-17-686-pae cannot boot on this Pentium III. The fan goes to full speed > during initrd loading and the host reboots at that point. There is no > screenshot to attach since there is no screen output after the "Loading > initrd..." message from GRUB2. > > Reverting to 5.10.0-16-686-pae, the fan runs at low speed and the host boots > normally. > > Martin-Éric > > - -- Package-specific info: > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 8 > model name : Pentium III (Coppermine) > stepping: 6 > microcode : 0x8 > cpu MHz : 865.440 > cache size : 256 KB > physical id : 0 > siblings: 1 > core id : 0 > cpu cores : 1 > apicid : 0 > initial apicid : 0 > fdiv_bug: no > f00f_bug: no > coma_bug: no > fpu : yes > fpu_exception : yes > cpuid level : 2 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pse36 mmx fxsr sse cpuid pti > bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf > mds swapgs itlb_multihit > bogomips: 1730.88 > clflush size: 32 > cache_alignment : 32 > address sizes : 36 bits physical, 32 bits virtual > power management: > > ** Kernel log: boot messages should be attached > > ** Model information > > ** PCI devices: > 00:00.0 Host bridge [0600]: Intel Corporation 82815 815 Chipset Host Bridge > and Memory Controller Hub [8086:1130] (rev 02) >
Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it
On Tue, Aug 30, 2022 at 3:00 PM Peter Zijlstra wrote: > On Tue, Aug 30, 2022 at 02:42:04PM +0300, Martin-Éric Racine wrote: > > On Fri, Aug 19, 2022 at 3:15 PM Peter Zijlstra wrote: > > > > > > On Fri, Aug 19, 2022 at 01:38:27PM +0200, Ben Hutchings wrote: > > > > > > > So that puts the whole __FILL_RETURN_BUFFER inside an alternative, and > > > > we can't have nested alternatives. That's unfortunate. > > > > > > Well, both alternatives end with the LFENCE instruction, so I could pull > > > it out and do two consequtive ALTs, but unrolling the loop for i386 is > > > a better solution in that the sequence, while larger, removes the need > > > for the LFENCE. > > > > Have we reached a definitive conclusion on to how to fix this? > > https://git.kernel.org/tip/332924973725e8cdcc783c175f68cf7e162cb9e5 Thanks. Ben: When can we expect an updated kernel to security-updates at Debian? Martin-Éric
Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it
Greetings, On Fri, Aug 19, 2022 at 3:15 PM Peter Zijlstra wrote: > > On Fri, Aug 19, 2022 at 01:38:27PM +0200, Ben Hutchings wrote: > > > So that puts the whole __FILL_RETURN_BUFFER inside an alternative, and > > we can't have nested alternatives. That's unfortunate. > > Well, both alternatives end with the LFENCE instruction, so I could pull > it out and do two consequtive ALTs, but unrolling the loop for i386 is > a better solution in that the sequence, while larger, removes the need > for the LFENCE. Have we reached a definitive conclusion on to how to fix this? Martin-Éric
Bug#1017425: [PATCH] x86/speculation: Avoid LFENCE in FILL_RETURN_BUFFER on CPUs that lack it
On Fri, Aug 19, 2022 at 2:01 PM Peter Zijlstra wrote: > I'm not entirly sure what to do here. On the one hand, it's 32bit, so > who gives a crap, otoh we shouldn't break these ancient chips either I > suppose. This is something that I've repeatedly had to bring up, whenever something breaks because someone meant well by enabling more security bells and whistles: x86-32 is by definition legacy hardware. Enabling more bells and whistles essentially kills support for all but the very latest variants of the x86-32 family. This is the wrong approach. The right approach is to accept that building for x86-32 inherently means building for older and thus less secure architectures. Martin-Éric
Bug#1017425: 5.10.0-17-686-pae: repeatedly crashes during initrd loading [PIII]
On Fri, Aug 19, 2022 at 12:32 PM Etienne Vogt wrote: > > On Thu, 18 Aug 2022, Ben Hutchings wrote: > > >> I suspect someone thought it would be a good idea to compile the kernel > >> for P4 only, as both PIII and Athlon XP processors lack the SSE2 > >> instruction set. > > > > That was a good guess, though we don't change the configuration like > > that in stable updates. > > Well, that happened for Firefox, it became SSE2 only when they switched > to a higher upstream version in a stable update. 78.15.0esr-1~deb11u1 > is the last version that works on non SSE2 CPUs. Firefox is an entirely different issue. It uses Rust and, despite Debian's Rust maintainters' best intentions, upstream insists on making its 686 target use all the bells and whistles. Debian tried to mitigate this by generating code for plain old Pentium on i386, but it hasn't worked in recent times, because upstream has started treating all x86-32 targets as "just a number" instead of an actual CPU sepc. This also affects, among other things SVG-lib, which also migrated to Rust a few years ago. Martin-Éric
Bug#1017425: 5.10.0-17-686-pae: repeatedly crashes during initrd loading [PIII]
On Thu, Aug 18, 2022 at 10:59 PM Ben Hutchings wrote: > > Control: retitle -1 [i386] Unconditional LFENCE instructions in > FILL_RETURN_BUFFER > Control: tag -1 confirmed upstream > Control: found -1 5.18.14-1 > > On Wed, 2022-08-17 at 11:42 +0200, Etienne Vogt wrote: > > I can confirm that this bug also occurs on Athlon XP systems (Generic VIA > > KT333 motherboard, CPU AMD Athlon(tm) XP 2600+) : kernel panic early on > > boot. > > > > I suspect someone thought it would be a good idea to compile the kernel > > for P4 only, as both PIII and Athlon XP processors lack the SSE2 > > instruction set. > > > > That was a good guess, though we don't change the configuration like > that in stable updates. > > The RETbleed mitigations, which are not needed on these CPUs or even > functional on 32-bit kernels, interact with the Spectre v2 mitigations, > which *are* used on these CPUs. And unfortunately the RETbleed > mitigations added some unconditional LFENCE instructions, which should > be conditional since they are part of SSE2. > > As a temporary workaround, disabling the Spectre v2 mitigation with the > kernel parameter "nospectre_v2" should allow this kernel version to run > on older CPUs without SSE2. We'll fix this properly in a later update. That breakage affects Stable. Expecting people to go and use workarounds on what was meant to be a stable update isn't acceptable. I really hope that the fix will be pushed within the next 24 hours with high urgency. Martin-Éric
Bug#1017425: 5.10.0-17-686-pae: repeatedly crashes during initrd loading [PIII]
Package: src:linux Version: 5.10.136-1 Severity: grave -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 5.10.0-17-686-pae cannot boot on this Pentium III. The fan goes to full speed during initrd loading and the host reboots at that point. There is no screenshot to attach since there is no screen output after the "Loading initrd..." message from GRUB2. Reverting to 5.10.0-16-686-pae, the fan runs at low speed and the host boots normally. Martin-Éric - -- Package-specific info: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 6 microcode : 0x8 cpu MHz : 865.440 cache size : 256 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug: no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 mmx fxsr sse cpuid pti bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips: 1730.88 clflush size: 32 cache_alignment : 32 address sizes : 36 bits physical, 32 bits virtual power management: ** Kernel log: boot messages should be attached ** Model information ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub [8086:1130] (rev 02) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: agpgart-intel 00:01.0 PCI bridge [0604]: Intel Corporation 82815 815 Chipset AGP Bridge [8086:1131] (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 01) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- 00:1f.0 ISA bridge [0601]: Intel Corporation 82801BA ISA Bridge (LPC) [8086:2440] (rev 01) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Kernel driver in use: nouveau Kernel modules: nouveau 02:04.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller [10ec:8169] (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RTL8169/8110 Family PCI Gigabit Ethernet NIC [10ec:8169] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: r8169 Kernel modules: r8169 02:08.0 Ethernet controller [0200]: Intel Corporation 82801BA/BAM/CA/CAM Ethernet Controller [8086:2449] (rev 01) Subsystem: Compaq Computer Corporation EtherExpress PRO/100 VM [0e11:0012] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: e100 Kernel modules: e100 02:09.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller [10ec:8169] (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RTL8169/8110 Family PCI Gigabit Ethernet NIC [10ec:8169] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: r8169 Kernel modules: r8169 02:0a.0 USB controller [0c03]: VIA Technologies, Inc. VT82xx/62xx UHCI USB 1.1 Controller [1106:3038] (rev 62) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. VT82xx/62xx UHCI USB 1.1 Controller [1106:3038] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: uhci_hcd Kernel modules: uhci_hcd 02:0a.1 USB controller [0c03]: VIA Technologies, Inc. VT82xx
Bug#1011146: cups-pdf is marked for autoremoval from testing
Dev list, Someone apparently made a commit to the autoremoval hinter that makes it mark packages unrelated to an RC-bug package getting marked for autoremoval. Could someone please look into this? Thanks! Martin-Éric On Thu, May 26, 2022 at 10:38 AM Debian testing autoremoval watch wrote: > > cups-pdf 3.0.1-14 is marked for autoremoval from testing on 2022-06-30 > > It (build-)depends on packages with these RC bugs: > 1011146: nvidia-graphics-drivers-tesla-470: CVE-2022-28181, CVE-2022-28183, > CVE-2022-28184, CVE-2022-28185, CVE-2022-28191, CVE-2022-28192 > https://bugs.debian.org/1011146 > > > > This mail is generated by: > https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl > > Autoremoval data is generated by: > https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
Bug#1011146: xserver-xorg-video-geode is marked for autoremoval from testing
I'd really like to know why a package that that nothing to do with NVIDIA drivers came to be marked for auto-removal. Martin-Éric On Thu, May 26, 2022 at 9:04 AM Debian testing autoremoval watch wrote: > > xserver-xorg-video-geode 2.11.20-9 is marked for autoremoval from testing on > 2022-06-30 > > It (build-)depends on packages with these RC bugs: > 1011146: nvidia-graphics-drivers-tesla-470: CVE-2022-28181, CVE-2022-28183, > CVE-2022-28184, CVE-2022-28185, CVE-2022-28191, CVE-2022-28192 > https://bugs.debian.org/1011146 > > > > This mail is generated by: > https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl > > Autoremoval data is generated by: > https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
Bug#1011146: upgrade-system is marked for autoremoval from testing
I'd really like to know how anyone could ever come to the conclusion that a package that has nothing to do with graphic drivers needs to be auto-removed. Martin-Éric On Thu, May 26, 2022 at 9:01 AM Debian testing autoremoval watch wrote: > > upgrade-system 1.9.1.0 is marked for autoremoval from testing on 2022-06-30 > > It (build-)depends on packages with these RC bugs: > 1011146: nvidia-graphics-drivers-tesla-470: CVE-2022-28181, CVE-2022-28183, > CVE-2022-28184, CVE-2022-28185, CVE-2022-28191, CVE-2022-28192 > https://bugs.debian.org/1011146 > > > > This mail is generated by: > https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl > > Autoremoval data is generated by: > https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
Bug#1001234: src:firefox-esr: fails to migrate to testing for too long: FTBFS on mipsel and unresolved RC bug
ke 8. jouluk. 2021 klo 9.41 Mike Hommey (m...@glandium.org) kirjoitti: > On Wed, Dec 08, 2021 at 09:07:24AM +0200, Martin-Éric Racine wrote: > > 91.4.0esr-1 was indeed uploaded. However, mipsel was not removed from the > > list of architectures in the control file, so it attempted building. This > > will likely prevent migration. > > I don't think removing the architecture from the control file would > change anything wrt migration. It would. AFAIK you explicitly need to declare: Architecture: [!mipsel] ... instead of any. You'll also need to contact mipsel admins to ask them to remove the package from their port. > > Better care in maintaining this package would be appreciated. CVE fixes > > have yet to trickle into Testing or be uploaded to Stable-Updates for over > > 60 days. That's not acceptable. > > For stable, it's not under my control. Fair enough. > AFAIK, the necessary rust compiler is still not available yet. Which is inexcusable. 78 end of life was announced well ahead of time. There was plenty of time to prepare for this. Martin-Éric
Bug#1001234: src:firefox-esr: fails to migrate to testing for too long: FTBFS on mipsel and unresolved RC bug
Package: firefox-esr Version: 78.15.0esr-1~deb11u1 Followup-For: Bug #1001234 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 91.4.0esr-1 was indeed uploaded. However, mipsel was not removed from the list of architectures in the control file, so it attempted building. This will likely prevent migration. Better care in maintaining this package would be appreciated. CVE fixes have yet to trickle into Testing or be uploaded to Stable-Updates for over 60 days. That's not acceptable. Martin-Éric -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmGwWasACgkQrh+Cd8S0 17bKIA//QwVaZSjj17lL/tzje02i5CD1K4VNKTjSutNsQoJqa8YbBjSpbSl+qEsI Wwo0lYYFWA6D7I6dyQsErsLEHlC4V0QI/LbHC1aY097OAQf1zj/yGPIYlDyFOpxW oxOnWgSIXUwhNZbVdLm96kgjmHYPqZksJe9ZNqMwST8krtoRVnMdHlR0dqfZEYlq sskO6WPS4q52HzC8mmgzUY8aLcUQB36G1SbR4laQJHVH7NJoimQWVf2IwG5YOyZn A+OD0Gy8mN1E0dx4ALwxao8A6HrXik0uqiaSY2hbnxGy4tI+8JHgx5O1zq9fWvaI t6Hdnq77izrp7f+s/vozYK+GJaliz0HAJ9dUlogns4aYnbVppKV0bUMe/cAVP6Y0 4kPWuanKc5fetoa9bAYv1mcdhfD/ff7wVKHYGGVIrE+yW45S1eWoZ3R+FWzAuHx0 vHV2tgy+K25p09M078FHWal1SZkyzkgRrWnPEtLA5xppE9iNoiycanX4jOskSG2i 58P/x3vUfk/QqeeEkPLbwZGKjxNqSkCqZGiAsBHJXA+674vaHzm5dddWQQd2buNz iG67aB88yzfn0kcbZWlfoZWRqhDfXshnYA5pJ7jj0HC26Zc0C0uSC3ser/5KICtL WZwAfouqAIJPREp8l5VTaoN4W/8A+TL2EwpDiS7ZT8VYCdvhTn4= =HoFh -END PGP SIGNATURE-
Bug#993162: libc6: i386 (Geode LX): latest push to Bookwork produces multiple sig ILL
la 28. elok. 2021 klo 13.43 Martin-Éric Racine (martin-eric.rac...@iki.fi) kirjoitti: > > la 28. elok. 2021 klo 13.40 Aurelien Jarno (aurel...@aurel32.net) kirjoitti: > > > > On 2021-08-28 13:36, Martin-Éric Racine wrote: > > > la 28. elok. 2021 klo 12.58 Aurelien Jarno (aurel...@aurel32.net) > > > kirjoitti: > > > > > $ sudo coredumpctl debug 1011 > > > > >PID: 1011 (apt-get) > > > > >UID: 0 (root) > > > > >GID: 0 (root) > > > > > Signal: 4 (ILL) > > > > > Timestamp: Sat 2021-08-28 11:00:34 EEST (3min 22s ago) > > > > > Command Line: apt-get --quiet --quiet update > > > > > Executable: /usr/bin/apt-get > > > > > Control Group: /user.slice/user-1000.slice/session-4.scope > > > > > Unit: session-4.scope > > > > > Slice: user-1000.slice > > > > >Session: 4 > > > > > Owner UID: 1000 (perkelix) > > > > >Boot ID: 77dfa6eb16584c02b84de4e2b8feb781 > > > > > Machine ID: 1063a9d1fb9df6e371ea9f94491345ed > > > > > Hostname: geode > > > > >Storage: > > > > > /var/lib/systemd/coredump/core.apt-get.0.77dfa6eb16584c02b84de4e2b8feb781.1011.163013763400.zst > > > > >Message: Process 1011 (apt-get) of user 0 dumped core. > > > > > > > > > > Stack trace of thread 1011: > > > > > #0 0xb7ad2ed0 __cpu_indicator_init > > > > > (libgcc_s.so.1 + 0x2ed0) > > > > > #1 0xb7faf02c call_init (ld-linux.so.2 + > > > > > 0x1102c) > > > > > #2 0xb7faf132 call_init (ld-linux.so.2 + > > > > > 0x11132) > > > > > #3 0xb7f9f0fa _dl_start_user (ld-linux.so.2 > > > > > + 0x10fa) > > > > > > > > The SIGILL happens in __cpu_indicator_init which is provided by > > > > libgcc-s1. Bookworm got a new upstream version of this package compared > > > > to bullseye, so if you also upgraded it, it's more likely to be the > > > > issue. In that case, have you tried to downgrade it? > > > > > > Just did. Here's the result: > > > > > > $ sudo coredumpctl debug 2083 > > >PID: 2083 (apt-get) > > >UID: 0 (root) > > >GID: 0 (root) > > > Signal: 4 (ILL) > > > Timestamp: Sat 2021-08-28 13:33:05 EEST (1min 36s ago) > > > Command Line: apt-get update > > > Executable: /usr/bin/apt-get > > > Control Group: /user.slice/user-1000.slice/session-2.scope > > > Unit: session-2.scope > > > Slice: user-1000.slice > > >Session: 2 > > > Owner UID: 1000 (perkelix) > > >Boot ID: a200afe0e5134b8a812b05c898c8b859 > > > Machine ID: 1063a9d1fb9df6e371ea9f94491345ed > > > Hostname: geode > > >Storage: > > > /var/lib/systemd/coredump/core.apt-get.0.a200afe0e5134b8a812b05c898c8b859.2083.163014678500.zst > > >Message: Process 2083 (apt-get) of user 0 dumped core. > > > > > > Stack trace of thread 2083: > > > #0 0xb7ae9170 frame_dummy (libstdc++.so.6 + > > > 0x87170) > > > > It seems that all libraries from gcc-11 are now compiled with Intel CET > > enabled, following an upstream commit [1]. I guess you will also have to > > downgrade libstdc++6. > > > > [1] > > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8d286dd118a5bd16f7ae0fb9dfcdcfd020bea803 > > Sure enough, downgrading libstdc++6 too fixed it. Preventing other binaries from crashing with sig ILL required downgrading libgomp1 and other packages build from GCC11 as well. Martin-Éric
Bug#993162: libc6: i386 (Geode LX): latest push to Bookwork produces multiple sig ILL
la 28. elok. 2021 klo 13.40 Aurelien Jarno (aurel...@aurel32.net) kirjoitti: > > On 2021-08-28 13:36, Martin-Éric Racine wrote: > > la 28. elok. 2021 klo 12.58 Aurelien Jarno (aurel...@aurel32.net) kirjoitti: > > > > $ sudo coredumpctl debug 1011 > > > >PID: 1011 (apt-get) > > > >UID: 0 (root) > > > >GID: 0 (root) > > > > Signal: 4 (ILL) > > > > Timestamp: Sat 2021-08-28 11:00:34 EEST (3min 22s ago) > > > > Command Line: apt-get --quiet --quiet update > > > > Executable: /usr/bin/apt-get > > > > Control Group: /user.slice/user-1000.slice/session-4.scope > > > > Unit: session-4.scope > > > > Slice: user-1000.slice > > > >Session: 4 > > > > Owner UID: 1000 (perkelix) > > > >Boot ID: 77dfa6eb16584c02b84de4e2b8feb781 > > > > Machine ID: 1063a9d1fb9df6e371ea9f94491345ed > > > > Hostname: geode > > > >Storage: > > > > /var/lib/systemd/coredump/core.apt-get.0.77dfa6eb16584c02b84de4e2b8feb781.1011.163013763400.zst > > > >Message: Process 1011 (apt-get) of user 0 dumped core. > > > > > > > > Stack trace of thread 1011: > > > > #0 0xb7ad2ed0 __cpu_indicator_init > > > > (libgcc_s.so.1 + 0x2ed0) > > > > #1 0xb7faf02c call_init (ld-linux.so.2 + > > > > 0x1102c) > > > > #2 0xb7faf132 call_init (ld-linux.so.2 + > > > > 0x11132) > > > > #3 0xb7f9f0fa _dl_start_user (ld-linux.so.2 + > > > > 0x10fa) > > > > > > The SIGILL happens in __cpu_indicator_init which is provided by > > > libgcc-s1. Bookworm got a new upstream version of this package compared > > > to bullseye, so if you also upgraded it, it's more likely to be the > > > issue. In that case, have you tried to downgrade it? > > > > Just did. Here's the result: > > > > $ sudo coredumpctl debug 2083 > >PID: 2083 (apt-get) > >UID: 0 (root) > >GID: 0 (root) > > Signal: 4 (ILL) > > Timestamp: Sat 2021-08-28 13:33:05 EEST (1min 36s ago) > > Command Line: apt-get update > > Executable: /usr/bin/apt-get > > Control Group: /user.slice/user-1000.slice/session-2.scope > > Unit: session-2.scope > > Slice: user-1000.slice > >Session: 2 > > Owner UID: 1000 (perkelix) > >Boot ID: a200afe0e5134b8a812b05c898c8b859 > > Machine ID: 1063a9d1fb9df6e371ea9f94491345ed > > Hostname: geode > >Storage: > > /var/lib/systemd/coredump/core.apt-get.0.a200afe0e5134b8a812b05c898c8b859.2083.163014678500.zst > >Message: Process 2083 (apt-get) of user 0 dumped core. > > > > Stack trace of thread 2083: > > #0 0xb7ae9170 frame_dummy (libstdc++.so.6 + > > 0x87170) > > It seems that all libraries from gcc-11 are now compiled with Intel CET > enabled, following an upstream commit [1]. I guess you will also have to > downgrade libstdc++6. > > [1] > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8d286dd118a5bd16f7ae0fb9dfcdcfd020bea803 Sure enough, downgrading libstdc++6 too fixed it. Martin-Éric
Bug#993162: libc6: i386 (Geode LX): latest push to Bookwork produces multiple sig ILL
la 28. elok. 2021 klo 12.58 Aurelien Jarno (aurel...@aurel32.net) kirjoitti: > > $ sudo coredumpctl debug 1011 > >PID: 1011 (apt-get) > >UID: 0 (root) > >GID: 0 (root) > > Signal: 4 (ILL) > > Timestamp: Sat 2021-08-28 11:00:34 EEST (3min 22s ago) > > Command Line: apt-get --quiet --quiet update > > Executable: /usr/bin/apt-get > > Control Group: /user.slice/user-1000.slice/session-4.scope > > Unit: session-4.scope > > Slice: user-1000.slice > >Session: 4 > > Owner UID: 1000 (perkelix) > >Boot ID: 77dfa6eb16584c02b84de4e2b8feb781 > > Machine ID: 1063a9d1fb9df6e371ea9f94491345ed > > Hostname: geode > >Storage: > > /var/lib/systemd/coredump/core.apt-get.0.77dfa6eb16584c02b84de4e2b8feb781.1011.163013763400.zst > >Message: Process 1011 (apt-get) of user 0 dumped core. > > > > Stack trace of thread 1011: > > #0 0xb7ad2ed0 __cpu_indicator_init (libgcc_s.so.1 > > + 0x2ed0) > > #1 0xb7faf02c call_init (ld-linux.so.2 + 0x1102c) > > #2 0xb7faf132 call_init (ld-linux.so.2 + 0x11132) > > #3 0xb7f9f0fa _dl_start_user (ld-linux.so.2 + > > 0x10fa) > > The SIGILL happens in __cpu_indicator_init which is provided by > libgcc-s1. Bookworm got a new upstream version of this package compared > to bullseye, so if you also upgraded it, it's more likely to be the > issue. In that case, have you tried to downgrade it? Just did. Here's the result: $ sudo coredumpctl debug 2083 PID: 2083 (apt-get) UID: 0 (root) GID: 0 (root) Signal: 4 (ILL) Timestamp: Sat 2021-08-28 13:33:05 EEST (1min 36s ago) Command Line: apt-get update Executable: /usr/bin/apt-get Control Group: /user.slice/user-1000.slice/session-2.scope Unit: session-2.scope Slice: user-1000.slice Session: 2 Owner UID: 1000 (perkelix) Boot ID: a200afe0e5134b8a812b05c898c8b859 Machine ID: 1063a9d1fb9df6e371ea9f94491345ed Hostname: geode Storage: /var/lib/systemd/coredump/core.apt-get.0.a200afe0e5134b8a812b05c898c8b859.2083.163014678500.zst Message: Process 2083 (apt-get) of user 0 dumped core. Stack trace of thread 2083: #0 0xb7ae9170 frame_dummy (libstdc++.so.6 + 0x87170) gdb terminated by signal ILL. Martin-Éric
Bug#993162: libc6: i386 (Geode LX): latest push to Bookwork produces multiple sig ILL
Package: libc6 Version: 2.31-17 Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Since 2.31-17 trickled into Bookworm, a number of executables (including APT and GDB) die with sig ILL. An example: $ sudo coredumpctl debug 1011 PID: 1011 (apt-get) UID: 0 (root) GID: 0 (root) Signal: 4 (ILL) Timestamp: Sat 2021-08-28 11:00:34 EEST (3min 22s ago) Command Line: apt-get --quiet --quiet update Executable: /usr/bin/apt-get Control Group: /user.slice/user-1000.slice/session-4.scope Unit: session-4.scope Slice: user-1000.slice Session: 4 Owner UID: 1000 (perkelix) Boot ID: 77dfa6eb16584c02b84de4e2b8feb781 Machine ID: 1063a9d1fb9df6e371ea9f94491345ed Hostname: geode Storage: /var/lib/systemd/coredump/core.apt-get.0.77dfa6eb16584c02b84de4e2b8feb781.1011.163013763400.zst Message: Process 1011 (apt-get) of user 0 dumped core. Stack trace of thread 1011: #0 0xb7ad2ed0 __cpu_indicator_init (libgcc_s.so.1 + 0x2ed0) #1 0xb7faf02c call_init (ld-linux.so.2 + 0x1102c) #2 0xb7faf132 call_init (ld-linux.so.2 + 0x11132) #3 0xb7f9f0fa _dl_start_user (ld-linux.so.2 + 0x10fa) Stack trace for other executables show the same cause as above. $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 10 model name : Geode(TM) Integrated Processor by AMD PCS stepping: 2 cpu MHz : 497.996 cache size : 128 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug: no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow cpuid 3dnowprefetch vmmcall bugs: sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass bogomips: 995.99 clflush size: 32 cache_alignment : 32 address sizes : 32 bits physical, 32 bits virtual power management: Feel free to reassign as appropriate. Cheers! Martin-Éric -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmEp8TIACgkQrh+Cd8S0 17YLcQ/9GU6jypIgCKXTN48qzbAbDZYiGnKmsRJ7vXmmKZOLH75SWsmT++NJi+lf SPe0JCKRhBuRVBx+0kIRZ89KaTn/L4fWXMb1UF9wLQQEkvQfj0Vbnwi5lgQuLTTw x99Zouh9s9OtRQ+SZhQnuTts2SeiYLN9xkmCVPlK4LUSYuNfXJ60dOmmCXvgzpoQ 7BAZ43XciA5jU2+SmK506oFCVjNQWstgncRKMVj2++apdXiSZXZ1cP2RLfIpurLU OH6Ke3iifeOgcNuhPbLfva5rrdwFIEo0mEKzNzgpzIsOzBjow2EAmLehr24iAcoy BkxGuTdGeUtF/rOQFEwhtPi2BwAqrgqSe0BFvy8D4rfY2wM0fprAV6/1xtMRAGCX HBo+VQPbBjcfW91sKXIBMAolJcirV1HoiKGZCjjQpPzZUSe7oTnFmVFvsSiCkfAb gNL4MTKnN6s5F4rGDmOcIxQ2B5h/AK/au8yB6gjPpyDWjQJ3812PpHlOoFUjrQzu Mhdr+er8oWZc8Thq9IN+tv76CeV9FLWPwNs8Fs5yVi11Tj5SCJJrNEe3IqnUBKj6 ioxg3WLAY3V+dYrFCTycZuaE+3wO9uNDmJZWFOOKeBptgiMqxgGOuoDO/IFSBLst kslWCmTguCn7EoHFGEK4Tlv8cSNZbZaIcsdDWNNgibFPqG12I8I= =uPzL -END PGP SIGNATURE-
Bug#991588: systemd: Buster to Bullseye: boot stalls at network loading on normal boot
ke 28. heinäk. 2021 klo 20.21 Martin-Éric Racine (martin-eric.rac...@iki.fi) kirjoitti: > > ke 28. heinäk. 2021 klo 19.18 Dennis Filder (d.fil...@web.de) kirjoitti: > > * You have tpm2-abrmd installed, and its systemd unit is the only one > > defining a Requires=systemd-udev-settle.service. 2.1.0-1 under > > Buster didn't do that yet, so this could be the breaking change. As > > its manpage states systemd-udev-settle.service as a unit is > > conceptually problematic because udev events are never really > > settled; the unit is also deprecated, so tpm2-abrmd should correct > > its systemd/udev definitions. > > It was probably pulled in as a Recommends. At least I don't recall > ever installing it. It appears that this bug is caused by tpm2-abrmd's systemd unit. Tagging the maintainer. Martin-Éric
Bug#991588: systemd: Buster to Bullseye: boot stalls at network loading on normal boot
ke 28. heinäk. 2021 klo 20.21 Martin-Éric Racine (martin-eric.rac...@iki.fi) kirjoitti: > > ke 28. heinäk. 2021 klo 19.18 Dennis Filder (d.fil...@web.de) kirjoitti: > > * You have tpm2-abrmd installed, and its systemd unit is the only one > > defining a Requires=systemd-udev-settle.service. 2.1.0-1 under > > Buster didn't do that yet, so this could be the breaking change. As > > its manpage states systemd-udev-settle.service as a unit is > > conceptually problematic because udev events are never really > > settled; the unit is also deprecated, so tpm2-abrmd should correct > > its systemd/udev definitions. > > It was probably pulled in as a Recommends. At least I don't recall > ever installing it. > > > * Another potential issue is this line: > > > > post-up systemctl restart micro-httpd.socket > > > > The call to systemctl might be blocking. > > Could be. That post-up is there because micro-https is launched by > systemd before all network interfaces are up, which fails because the > 172.16.1.2 to which I've configured it to bind does not exist that > early during bootup. micro-httpd would need to launch only after all > interfaces are up. I filed a bug against micro-https for that specific > issue. > > > I wonder if that micro-httpd.socket definition amounts to a circular > > dependency resulting in a deadlock. > > Could be. However, please note that bootup only stalls when launched > using the normal mode. If I boot via recovery mode and resume from the > rescue shell prrompt, it doesn't stall. > > > I recommend uncommenting the post-up line from /etc/network/interfaces > > just to see if this solves the problem. Alternatively try disabling > > tpm2-abrmd.service temporarily. > > I purged tpm2-abrmd and regular bootup no longer stalls. > > Thanks for the above. You zeroed-in on the most probable cause of the > problem. :) > > Martin-Éric $ LC_ALL=C apt-cache depends tpm2-abrmd tpm2-abrmd PreDepends: init-system-helpers Depends: libc6 Depends: libglib2.0-0 Depends: libtss2-mu0 Depends: libtss2-rc0 Depends: libtss2-sys1 Depends: libtss2-tctildr0 $ LC_ALL=C apt-cache rdepends tpm2-abrmd tpm2-abrmd Reverse Depends: tpm2-abrmd-dbgsym $ LC_ALL=C apt-cache rdepends tpm2-abrmd-dbgsym tpm2-abrmd-dbgsym Reverse Depends: Given the above, I'm begining to wonder whether 1) reassigining to src:tpm2-abrmd or even 2) removing src:tpm2-abrmd from the archive would make more sense? Martin-Éric
Bug#991588: systemd: Buster to Bullseye: boot stalls at network loading on normal boot
ke 28. heinäk. 2021 klo 19.18 Dennis Filder (d.fil...@web.de) kirjoitti: > * You have tpm2-abrmd installed, and its systemd unit is the only one > defining a Requires=systemd-udev-settle.service. 2.1.0-1 under > Buster didn't do that yet, so this could be the breaking change. As > its manpage states systemd-udev-settle.service as a unit is > conceptually problematic because udev events are never really > settled; the unit is also deprecated, so tpm2-abrmd should correct > its systemd/udev definitions. It was probably pulled in as a Recommends. At least I don't recall ever installing it. > * Another potential issue is this line: > > post-up systemctl restart micro-httpd.socket > > The call to systemctl might be blocking. Could be. That post-up is there because micro-https is launched by systemd before all network interfaces are up, which fails because the 172.16.1.2 to which I've configured it to bind does not exist that early during bootup. micro-httpd would need to launch only after all interfaces are up. I filed a bug against micro-https for that specific issue. > I wonder if that micro-httpd.socket definition amounts to a circular > dependency resulting in a deadlock. Could be. However, please note that bootup only stalls when launched using the normal mode. If I boot via recovery mode and resume from the rescue shell prrompt, it doesn't stall. > I recommend uncommenting the post-up line from /etc/network/interfaces > just to see if this solves the problem. Alternatively try disabling > tpm2-abrmd.service temporarily. I purged tpm2-abrmd and regular bootup no longer stalls. Thanks for the above. You zeroed-in on the most probable cause of the problem. :) Martin-Éric
Bug#991588: systemd: Buster to Bullseye: boot stalls at network loading on normal boot
ke 28. heinäk. 2021 klo 10.43 Michael Biebl (bi...@debian.org) kirjoitti: > > control: reassign -1 ifupdown > > Am 28.07.21 um 06:13 schrieb Martin-Éric Racine: > > Package: systemd > > Version: 247.3-6 > > Severity: serious > > > > Since upgrading to Bullseye, the boot process stalls at network loading [1] > > when booting in regular mode. When booting in recovery mode and resuming > > boot at the rescue shell prompt, the boot process completes as normal. > > > > Since /etc/network/interfaces [2] remains the same and worked fine under > > Buster, I suspect that this is a systemd issue. Feel free to reassign as > > appropriate. > > > > Since this prevents normal rebooting, I consider this a serious issue. > > > > [1] Alternates between these two lines: > > A start job is running for Helper to synchronize boot up for ifupdown > > A start job is running for Wait for udev to complete device initialization > > Since ifupdown installs a udev rule for allow-hotplug interfaces and > ifupdown-pre.service is shipped by ifupdown, I'm going to reassign this > to the ifupdown package. > Its maintainer is more likely to help you debug any ifupdown related issues. Fair enough. Adding ifupdown reportbug output: --- up and down scripts installed: /etc/network/if-down.d: total 4 lrwxrwxrwx 1 root root 29 Feb 24 13:34 bridge -> /lib/bridge-utils/ifupdown.sh -rwxr-xr-x 1 root root 1677 Mar 30 2019 clamav-freshclam-ifupdown lrwxrwxrwx 1 root root 32 Feb 25 23:19 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh /etc/network/if-post-down.d: total 4 lrwxrwxrwx 1 root root 29 Feb 24 13:34 bridge -> /lib/bridge-utils/ifupdown.sh lrwxrwxrwx 1 root root 25 Feb 25 23:19 hostapd -> ../../hostapd/ifupdown.sh -rwxr-xr-x 1 root root 1409 Mar 24 2016 wireless-tools lrwxrwxrwx 1 root root 32 Feb 25 23:19 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh /etc/network/if-pre-up.d: total 12 lrwxrwxrwx 1 root root 29 Feb 24 13:34 bridge -> /lib/bridge-utils/ifupdown.sh -rwxr-xr-x 1 root root 344 Jun 30 2016 ethtool lrwxrwxrwx 1 root root 25 Feb 25 23:19 hostapd -> ../../hostapd/ifupdown.sh -rwxr-xr-x 1 root root 4191 Sep 15 2018 wireless-tools lrwxrwxrwx 1 root root 32 Feb 25 23:19 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh /etc/network/if-up.d: total 16 -rwxr-xr-x 1 root root 1677 Mar 30 2019 clamav-freshclam-ifupdown -rwxr-xr-x 1 root root 1685 Jun 30 2016 ethtool -rwxr-xr-x 1 root root 4938 Jan 4 2021 mountnfs lrwxrwxrwx 1 root root 32 Feb 25 23:19 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh Versions of packages ifupdown depends on: ii adduser 3.118 ii iproute2 5.10.0-4 ii libc6 2.31-13 ii lsb-base 11.1.0 Versions of packages ifupdown recommends: ii isc-dhcp-client [dhcp-client] 4.4.1-2.3 Versions of packages ifupdown suggests: ii ppp 2.4.9-1+1 pn rdnssd -- no debconf information > > > [2] /etc/network/interfaces: > > allow-hotplug /en* /wl* > > auto br0 > > > > iface br0 inet static > > bridge_hw (MAC) > > bridge_ports regex (enp3|enp6|wl).* > > address 172.16.1.2 > > post-up systemctl restart micro-httpd.socket > > iface br0 inet6 manual > > bridge_hw (MAC) > > bridge_ports regex (enp3|enp6|wl).* > > # IPv6 from /etc/dhcp/dhclient-exit-hooks.d/prefix_delegation > > privext 2 > > > > iface enp3s0 inet manual > > > > iface enp4s0 inet dhcp > > iface enp4s0 inet6 auto > > post-up /etc/boot.d/iptables_IPv4-MASQ_IPv6-bridge_no-LTSP-outside > > request_prefix 1 > > privext 2 > > dhcp 1 > > > > #BGN,2x2:2 > > iface wlxMAC1 inet manual > > hostapd /etc/hostapd/hostapd-1-wlxMAC1.conf > > > > #ABGN,2x2:2 > > iface wlxMAC2 inet manual > > hostapd /etc/hostapd/hostapd-1-wlxMAC2.conf > > > > -- Package-specific info: > > > > -- System Information: > > Debian Release: 11.0 > >APT prefers testing-security > >APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, > > 'testing'), (500, 'stable') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) > > Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8), LANGUAGE=fi:en > > Shell: /bin/sh linked to /bin/dash > > Init: systemd (via /run/systemd/system) > > LSM: AppArmor: enabled > > > > Versions of packages systemd depends on: > > ii adduser 3.118 > > ii libacl1 2.2.53-10 > > i
Bug#991416: bridge-utils: broken IPv4 connection after upgrading to Debian Bullseye, setting old MAC with bridge_hw fixes the issue
Package: bridge-utils Followup-For: Bug #991416 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I've had similar problems in the past. IIRC this is caused by occasional changes in how the kernel does interface discovery. In my particular case, the bridge took on the nasty habit of adopting the MAC address of a removable interface. Removing the device made the bridge collapse. The fix indeed was to specificy the MAC address I want it to use using bridge_hw. Martin-Éric -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmD6g2AACgkQrh+Cd8S0 17a0qxAAuAAYpas+x9BIvJdgd6I6Mxh+iVFzlCwuUwE351eDfzDcSDAFepUQ/r8m +HGL0bn6pJDgfOF1xWHLWKB85YGjENu0M1AaI3ABxu/wA3KTHmhPP5932KbqM6Lz yfEpvBonsD6La7R1zBqp/n/n+/NHmkJt8JFVd4ltQ3na3gIShKdc71CiuHoe0ZRU v07JobiDnxJyz/RwdJUKKKiqLn1y6HeexEz42sT0u6nd16h/vqjF1THKhlfg9n6x 5iUK7djWMzijsz81wduHUIku+0ac8yrjGgCqjBkyFVeZV0AZypWD/jDXV1bPNnm7 MfUXauUgjdHa9aW7RIwHL3xuDUUWGIoaoH8AnVlgBu7I4yH9yf3Se6L4+uzaLsMh EJ4ABZaYKZLh598XNR8owCrJaYErUSJoAX91KwmmCZrHaNI6mAB+UDW5sjtvjHox acfskUi/WjE5EjKJMX7ZONuloctzVVqY5s1QtT2j7laBDVyTWBnPFV0iG0vopyqS Qkp2io7eKwjEp9BLd/e6pkCeW5zWm87CMDQClTOgQZ6PPkbMhiyLAwNrjWJddN+h yjAagiM5om4akJ3VwTmBVsNDFjz8FQPKAlBvgaVGyCH+Ql5IWfaK68gjc+exCcpt /3H+TTTLloQ0m2BYTrMhD2TVfU5yDTOHFCjndmlNxzRmEPfSo9o= =h3CF -END PGP SIGNATURE-
Bug#974608: gthumb uses internal libexiv2 functions to get the user comment
Package: gthumb Version: 3:3.8.3-0.1 Followup-For: Bug #974608 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Fixed upstream 1 hour ago: https://gitlab.gnome.org/GNOME/gthumb/-/commit/3bdb4f94ba37b410ac07c25b5c83e587b55482fd See also: https://gitlab.gnome.org/GNOME/gthumb/-/issues/137 https://gitlab.gnome.org/GNOME/gthumb/-/issues/30 I haven't checked whether this can be backported to the 3.8.3 branch. Upgrading the Debian package to 3.11.1 might make more sense. - -- System Information: Debian Release: 10.7 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-13-amd64 (SMP w/8 CPU cores) Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8), LANGUAGE=fi_FI.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gthumb depends on: ii gsettings-desktop-schemas 3.28.1-1 ii gthumb-data 3:3.8.3-0.1 ii libbrasero-media3-1 3.12.2-5 ii libc6 2.28-10 ii libcairo2 1.16.0-4 ii libclutter-1.0-01.26.2+dfsg-10 ii libclutter-gtk-1.0-01.8.4-4 ii libexiv2-14 0.25-4+deb10u1 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgl1-mesa-dri 18.3.6-2+deb10u1 ii libglib2.0-02.58.3-2+deb10u2 ii libgstreamer-plugins-base1.0-0 1.14.4-2 ii libgstreamer1.0-0 1.14.4-1 ii libgtk-3-0 3.24.5-1 ii libjpeg62-turbo 1:1.5.2-2+deb10u1 ii libjson-glib-1.0-0 1.4.4-2 ii liblcms2-2 2.9-3 ii libpango-1.0-0 1.42.4-8~deb10u1 ii libpangocairo-1.0-0 1.42.4-8~deb10u1 ii libpng16-16 1.6.36-6 ii libraw190.19.2-2 ii librsvg2-2 2.44.10-2.1 ii libsecret-1-0 0.18.7-1 ii libsoup2.4-12.64.2-2 ii libstdc++6 8.3.0-6 ii libtiff54.1.0+git191117-2~deb10u1 ii libwebkit2gtk-4.0-372.30.4-1~deb10u1 ii libwebp60.6.1-2 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages gthumb recommends: ii libgphoto2-6 2.5.22-3 ii libgphoto2-port12 2.5.22-3 gthumb suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAl/txdoACgkQrh+Cd8S0 17Z/Fg/+LtN/1HlY196Ud3lZKaZCbb4py9hYszATImYcOtY8/kzxWhMJXYPLEkEj WiiN2TxzWgXNTJWc8GLIUDC/bFI3ePculd5nn9c1kiVxP4+2lLXANxnwGUJS0mLb ssbNSO5asysFWYtV17b30qU6Nfc6FPmnbSbhpz24OfrKytRw/w+trtJCkv/6g18c PcVD8N050uXaJX7+cwyzZ1kjXyEcAzL7uCuNPlu8O9kZcTm7+7cMD4nufBLtNW4a cOC0/UigG/0L+hD//8sBq8FXdLrUvqStp1mffeGLy0k7yDFf9LMVO4kQmwLI6edQ s7SFagRj23pUn7Ibvp3EQUgFfDe7IPujsFVsNLCpir/IVRQBoTUbhHPopKsGaJkJ KddKqxT0DZ40yJVveDAN7EaIKSkSzoWJJ4F40vjYvMnW6XO+ZRIaOsbWgGaOVPdh HBxga3g/8X0xzlhkenStqnxliyTjvHzAa0H7e0Ka610/9Kc/6GmMc1QpEDmYuCbM jmmki3I3JWG5P6t+bo+8kMRhTr2wwohrL51kIctP6UqcN2YZphHLvjH+O736Q4IP WqFNJxb4ntiPbVi6ETLlRo/vjbNynIE70TEp6QVWPn4j9kpsR/jKlX9ElnILQfqd jBrTNMl15PDTahJZ01kmNAT5ZCygs9SKaOK0U02p50yjz6MO+qE= =fi0x -END PGP SIGNATURE-
Bug#903343: two causes
The causes are simple: First of all: $ find . -name '*README*' ./README.md This would suggest a raw README with markup, except that 1) there is no markup in that file and 2) no README gets generated. Additionaly, we try to install two fles that were not generated: $ cat debian/docs README README.fi As to how we got there is an entirely different story. Martin-Éric
Bug#900108: xserver-xorg-video-geode: FTBFS with xserver 1.20
It ought to be noted that: 1) This bug was fixed ages ago. 2) It only concerns building against Xserver 1.20, which has been stuck in unstable for ages. 3) Basically, the version in testing works as expected with the Xserver that is in testing. Despite this, xf86-video-geode has been slated for removal. I'd really like to know why. Martin-Éric 2018-05-26 12:28 GMT+03:00 Emilio Pozuelo Monfort : > Source: xserver-xorg-video-geode > Version: 2.11.19-3 > Severity: serious > Tags: patch > > geode fails to build with xserver 1.20. There is a patch available > upstream but no release at this time: > > https://cgit.freedesktop.org/xorg/driver/xf86-video-geode/commit/?id=8382e6bb0c76a8029493eae3f2d7a3dbfd0cfc12 > > Emilio
Bug#886224: printer-driver-cups-pdf: Virtual pdf printer error: no output and config problem
2018-01-03 11:51 GMT+02:00 Rudolf Polzer : > Package: printer-driver-cups-pdf > Version: 3.0.1-4 > Severity: grave > Justification: renders package unusable > > > > -- System Information: > Debian Release: buster/sid > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.14.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= > (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages printer-driver-cups-pdf depends on: > ii cups2.2.6-4 > ii cups-client 2.2.6-4 > ii ghostscript 9.22~dfsg-1 > ii libc6 2.25-6 > ii libcups22.2.6-4 > ii libpaper-utils 1.1.24+nmu5 > > printer-driver-cups-pdf recommends no packages. > > Versions of packages printer-driver-cups-pdf suggests: > pn system-config-printer > > -- no debconf information > > > Bug description: > > The cups pdf printer produces no pdf output file. > > After deleting the pdf printer, the add printer function does not work as > expected: > After selecting "Generic" as printer make, no pdf printer model is selectable. > I instead selected one of the existing ppd files in /usr/share/ppd/cups-pdf > but this did not make the pdf printer work. > > The bug started by my recent update from cups-pdf, where pdf printing did > work, > to printer-driver-cups-pdf. I notice that you're using AppArmor. Please check what the README says about this. Martin-Éric
Bug#823796: Phatch RC bug
It wasn't there this morning when I fetched the sources and attempted to produce the NMU. All is good then. Thanks! 2017-06-02 10:53 GMT+03:00 Emilio Pozuelo Monfort : > On 02/06/17 09:07, Martin-Éric Racine wrote: >> Greetings, >> >> I've tried merging this patch to submit an NMU. >> >> This fails miserably because the existing patches are not applied in a >> known order and dpkg complains loudly that patches are either fuzzy or >> cannot be applied as-is. >> >> To guarantee that patches are always applied in the same order, their >> filename would need to start with a number e.g. 001_fix_for_foo.patch, >> 002_fix_for_bar.patch and the patches would probably need to be >> refreshed anyhow. >> >> Basically, unless someone is willing to overhaul Phatch's packaging >> ASAP, it's quite likely to get removed from the Debian archive before >> the Release. > > This bug is already fixed, and the upload is already unblocked and due to > enter > testing in 5 days afaics. Am I missing something? > > Cheers, > Emilio
Bug#823796: Phatch RC bug
Greetings, I've tried merging this patch to submit an NMU. This fails miserably because the existing patches are not applied in a known order and dpkg complains loudly that patches are either fuzzy or cannot be applied as-is. To guarantee that patches are always applied in the same order, their filename would need to start with a number e.g. 001_fix_for_foo.patch, 002_fix_for_bar.patch and the patches would probably need to be refreshed anyhow. Basically, unless someone is willing to overhaul Phatch's packaging ASAP, it's quite likely to get removed from the Debian archive before the Release. Best Regards, Martin-Éric
Bug#848709: xserver-xorg-video-geode-dbg: depends on xserver-xorg-core-dbg, which is no longer built
2016-12-19 20:26 GMT+02:00 Emilio Pozuelo Monfort : > Package: xserver-xorg-video-geode-dbg > Version: 2.11.18-2 > Severity: serious > > Hi, > > x-x-v-geode-dbg depends on xserver-xorg-core-dbg, but we no longer build > that, and rely on debhelper creating dbgsym packages instead. Thus, please > drop that dependency. Bonus points if you switch to -dbgsym packages too. :) Thanks for the heads up. Now, what I'm wondering is how that constitues a sufficient reason for Severity:serious? Martin-Éric
Bug#769146: openntpd: fails to upgrade from 'sid' - trying to overwrite /etc/apparmor.d/usr.sbin.ntpd
Package: openntpd Version: 20080406p-10 Followup-For: Bug #769146 In response to the point about handling config files, I think that the simplest way is to upload to unstable new versions of apparmors-extras and openntpd, each using dpkg-maintscript-helper rm_conffile to remove old config. Once those two packages have migrated to Testing, a new ntp that Breaks older versions of openntpd and apparmor-extras can be uploaded.
Bug#769146: openntpd: fails to upgrade from 'sid' - trying to overwrite /etc/apparmor.d/usr.sbin.ntpd
Package: openntpd Followup-For: Bug #769146 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 It should be noted that this bug was filed in November 2014. Since then, openntpd has been removed from Testing due to this bug being marked as Serious and not having been acted upon within a reasonable time. Whichever solution the maintainers of openntpd, ntp and apparmor decide to go with, a timely response would be appreciated. In any case, letting the package get removed from the archive because nobody dares to make a decision in one direction or another should be avoided. - -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (1001, 'testing'), (1001, 'stable'), (1001, 'oldstable') Architecture: i386 (i586) Kernel: Linux 3.16.0-4-586 Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openntpd depends on: ii adduser 3.113+nmu3 ii init-system-helpers 1.24 ii libc62.19-22 ii libssl1.0.0 1.0.2d-1 ii netbase 5.3 openntpd recommends no packages. openntpd suggests no packages. - -- Configuration Files: /etc/default/openntpd changed [not included] - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWZd/MAAoJEK4fgnfEtNe2F3kP/j/B9sN2FwupCrBm1SqcTXNI 4+5XI9HYfUDeEw9C6IU+YCxNr5NkV1pFbzAOsd8QnRWIudrhpZvycAzkL9adBgX/ Tq/7Za6Zh93M8YIVrxN9ggGZttsf7T8hI1EOeF/NkLDPiZ+LIDQMdXnoTTvSi/wo 6SuI8Gtdpsvs2PRCnOxx3T6WGWF3Hz2Oe7P/rLd77UZXnevML+JZpwoDGc6L4STR lP83/pBIVt3SfJsFYQTWb+LfwZWnvM40Bzny2NZzqIt3ntZ+JYYhKJ+bgVmCwmTn +Y15Fnm/MkaorfX8yDf7yijq0J94qThJpCpMe4W07UcgsMWRJlk/KAgrqL3b6HhL AsMyZloFg26Hs/Ekp0snCBKz/wIWI4KP4x/y/Tat/HG8fx0q6tUOJrvr0vjmTDZ6 D+/iekAWdFswqLYqJvBsvIhwm1sWDKvM4dKd5vDyH0tUunsUMS+mm5y/buqqED+W 9wdby7gHx1UB9R6aFL3PMB8dqr5uGjuLbooIj2JvMw8pE5MGYpDOub6gup8r44TV NMSodJtrgtkY1opcxToUelKkxoZVJMpvLh46Y9TSWd0qvPpCOR3YZWXG5QobOcvS WXOwRq1ye2I2ulRR3WNCUtYzxDg+k++TxP86bhnxoCZSwiQO2MF606f+Mk0W5ijd 6huz5H6/rACTPy3sVmhr =zcM7 -END PGP SIGNATURE-
Bug#794977: dselect: no access methods are available
Package: dselect Version: 1.18.2 Followup-For: Bug #794977 Confirmed to be a path issue. Here, what fixed it was: sudo ln -s /usr/lib/dpkg /usr/lib/i386-linux-gnu/dpkg -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (1001, 'testing'), (1001, 'stable'), (1001, 'oldstable') Architecture: i386 (i586) Kernel: Linux 4.1.0-2-586 Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dselect depends on: ii dpkg 1.18.2 ii libc6 2.19-19 ii libgcc1 1:5.2.1-17 ii libncursesw5 6.0+20150810-1 ii libstdc++65.2.1-17 ii libtinfo5 6.0+20150810-1 dselect recommends no packages. Versions of packages dselect suggests: ii perl 5.20.2-6 -- no debconf information
Bug#779288: upgrade-system: cronjob still active after package was removed (but not purged)
2015-02-26 18:12 GMT+02:00 Andreas Beckmann : > Package: upgrade-system > Version: 1.7.2.1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package includes a cronjob > that is still active after removing (but not purging) the package. > > The cronjob needs to have a test that skips its execution after removal, > e.g. start with > > # skip cronjob if upgrade-system is no longer installed > test -x /usr/sbin/upgrade-system || exit 0 > > I noticed this because I have apt-get configured to produce more debug > output and suddenly the cronjob started emitting such even after package > removal. Thanks for the info and the solution. That's easily added. I'll fix this now and upload. Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774918: Fwd: Re: Bug#776072: dpkg-maintscript-helper dir_to_symlink explodes on subtree in cups-pdf package
2015-01-23 18:14 GMT+02:00 Andreas Beckmann : > > > > Forwarded Message > Subject: Re: Bug#776072: dpkg-maintscript-helper dir_to_symlink explodes > on subtree in cups-pdf package > Date: Fri, 23 Jan 2015 17:12:17 +0100 > From: Guillem Jover > To: Andreas Beckmann , 776072-d...@bugs.debian.org > > Hi! > > On Fri, 2015-01-23 at 16:44:53 +0100, Andreas Beckmann wrote: >> Package: dpkg >> Version: 1.17.23 >> Severity: serious >> Control: block 774918 by -1 > > I don't think this is a bug in dpkg, see below. > >> cups-pdf recently switched to dir_to_symlink which explodes for whatever >> reason (the cups-pdf bug is #774918): >> >> Selecting previously unselected package printer-driver-cups-pdf. >> Preparing to unpack .../printer-driver-cups-pdf_2.6.1-14.1_amd64.deb ... >> Unpacking printer-driver-cups-pdf (2.6.1-14.1) ... >> Replacing files in old package cups-pdf (2.6.1-6) ... >> Preparing to unpack .../cups-pdf_2.6.1-14.1_all.deb ... >> dpkg-query: no packages found matching cups-pdf:all >> dpkg-query: package 'cups-pdf' is not installed >> Use dpkg --info (= dpkg-deb --info) to examine archive files, >> and dpkg --contents (= dpkg-deb --contents) to list their contents. > […] >> dpkg-maintscript-helper: error: directory '/usr/share/doc/cups-pdf' >> contains files not owned by package cups-pdf:all, cannot switch to symlink >> dpkg: error processing archive >> /var/cache/apt/archives/cups-pdf_2.6.1-14.1_all.deb (--unpack): >>subprocess new pre-installation script returned error exit status 1 >> Preparing to unpack .../libreadline5_5.2+dfsg-2_amd64.deb ... >> Unpacking libreadline5:amd64 (5.2+dfsg-2) over (5.2+dfsg-2~deb7u1) ... >> Preparing to unpack .../libpam-runtime_1.1.8-3.1_all.deb ... >> Unpacking libpam-runtime (1.1.8-3.1) over (1.1.3-7.1) ... >> Errors were encountered while processing: >>/var/cache/apt/archives/cups-pdf_2.6.1-14.1_all.deb > > That's because the previous version (2.6.1-6) was an arch:any package, > so the dpkg-query on cups-pdf:all does not find it. This works as > expected, and a fix needs to be implemented in cups-pdf itsel to cope > with that. Right. I have changed that back to arch:any in 2.6.1-15, since dh_installdoc complains about it too. >> At this point we still have these files: >> >> # dpkg -S $(find /usr/share/doc/cups-pdf) > […] > > Yes, if dpkg-maintscript-helper cannot do its job it will abort. > >> and the preinst looks like this: >> >> #!/bin/sh >> set -e >> # Automatically added by dh_installdeb >> dpkg-maintscript-helper dir_to_symlink /usr/share/doc/cups-pdf >> /usr/share/doc/printer-driver-cups-pdf -- "$@" >> # End automatically added section > > This needs to be passed the correct arch-qualified package name (either > : or :all) for the previous package. Thus closing. But feel free > to reopen if I missed something else. There is exactly one release that has that arch:all. Preveious and later releases use arch:any to maintain continuity and please DPKG. Basicall,y this won't show when upgrading to Jessie. Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775471: xserver-xorg-video-geode-dbg: copyright file missing after upgrade (policy 12.5)
2015-01-17 7:19 GMT+02:00 Andreas Beckmann :
> On 2015-01-16 14:15, Martin-Éric Racine wrote:
>> ---
>> xserver-xorg-video-geode-2.11.16/debian/xserver-xorg-video-geode-dbg.maintscript
>> 1970-01-01 02:00:00.0 +0200
>> +++
>> xserver-xorg-video-geode-2.11.16/debian/xserver-xorg-video-geode-dbg.maintscript
>> 2015-01-16 15:02:13.0 +0200
>> @@ -0,0 +1 @@
>> +dir_to_symlink /usr/share/doc/xserver-xorg-video-geode-dbg
>> /usr/share/doc/xserver-xorg-video-geode 2.11.13-5
>
> I think you should use the relative target as it is in the current package:
>
> lrwxrwxrwx 1 root root 24 Nov 10 23:22
> /usr/share/doc/xserver-xorg-video-geode-dbg -> xserver-xorg-video-geode
I always have my doubts about putting relative links anywhere but, if
you think that this will work as intended, why not.
> Also the prior-version was wrong, so the .maintscript file should look like
>
> dir_to_symlink /usr/share/doc/xserver-xorg-video-geode-dbg
> xserver-xorg-video-geode 2.11.13-6~
Shouldn't the version be the same one as when the symlink was
introduced? (The relative version tilde is ok).
> For debian/control I'd recommend to use ${misc:Pre-Depends) instead of
> hardcoding it manually.
Sure, why not.
Martin-Éric
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775471: xserver-xorg-video-geode-dbg: copyright file missing after upgrade (policy 12.5)
Wait. Got it: DPKG won't squash a previous directory.
Fixed in maintainer script. Patch attached.
Release Team:
Is this something worth getting a freeze exception for? If yes, should
it be introduced via unstable, jessies-update, or something else?
Cheers!
Martin-Éric
2015-01-16 14:48 GMT+02:00 Martin-Éric Racine :
> Hey Andreas,
>
> debian/rules uses this:
>
> override_dh_installdocs:
> dh_installdocs --link-doc=xserver-xorg-video-geode NEWS README TODO
>
> Surely that would link the -dbg package's /usr/share/doc/foo-dbg to
> .../foo, wouldn't it?
>
> Martin-Éric
>
>
> 2015-01-16 5:21 GMT+02:00 Andreas Beckmann :
>> Package: xserver-xorg-video-geode-dbg
>> Version: 2.11.16-5
>> Severity: serious
>> User: debian...@lists.debian.org
>> Usertags: piuparts
>>
>> Hi,
>>
>> a test with piuparts revealed that your package misses the copyright
>> file after an upgrade, which is a violation of Policy 12.5:
>> https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
>>
>> After the upgrade /usr/share/doc/$PACKAGE/ is just an empty directory.
>>
>> This was observed on the following upgrade paths:
>>
>> wheezy -> jessie
>>
>> >From the attached log (scroll to the bottom...):
>>
>> 3m56.0s ERROR: WARN: Inadequate results from running adequate!
>> xserver-xorg-video-geode-dbg: missing-copyright-file
>> /usr/share/doc/xserver-xorg-video-geode-dbg/copyright
>>
>> 3m59.5s DUMP:
>> MISSING COPYRIGHT FILE:
>> /usr/share/doc/xserver-xorg-video-geode-dbg/copyright
>> # ls -lad /usr/share/doc/xserver-xorg-video-geode-dbg
>> drwxr-xr-x 2 root root 40 Jan 15 11:43
>> /usr/share/doc/xserver-xorg-video-geode-dbg
>> # ls -la /usr/share/doc/xserver-xorg-video-geode-dbg/
>> total 0
>> drwxr-xr-x 2 root root 40 Jan 15 11:43 .
>> drwxr-xr-x 185 root root 3840 Jan 15 11:43 ..
>>
>>
>> Additional info may be available here:
>> https://wiki.debian.org/MissingCopyrightFile
>>
>> Note that dpkg intentionally does not replace directories with symlinks
>> and vice versa, you need the maintainer scripts to do this.
>> See in particular the end of point 4 in
>> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase
>>
>> It is recommended to use the dpkg-maintscript-helper commands
>> 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
>> to perform the conversion, ideally using d/$PACKAGE.mainstscript.
>> Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
>> See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.
>>
>>
>> cheers,
>>
>> Andreas
diff -Nru xserver-xorg-video-geode-2.11.16/debian/changelog
xserver-xorg-video-geode-2.11.16/debian/changelog
--- xserver-xorg-video-geode-2.11.16/debian/changelog 2014-11-11
01:12:48.00000 +0200
+++ xserver-xorg-video-geode-2.11.16/debian/changelog 2015-01-16
15:11:33.0 +0200
@@ -1,3 +1,12 @@
+xserver-xorg-video-geode (2.11.16-6) unstable; urgency=medium
+
+ * debian/xserver-xorg-video-geode-dbg.maintscript:
++ New file. Handles dir_to_symlink for 2.11.13-5 (Closes: # 775471).
+ * debian/control:
++ xserver-xorg-video-geode-dbg: Pre-Depends: dpkg (>= 1.17.14)
+
+ -- Martin-Éric Racine Fri, 16 Jan 2015 15:10:36
+0200
+
xserver-xorg-video-geode (2.11.16-5) unstable; urgency=medium
* debian/control:
diff -Nru xserver-xorg-video-geode-2.11.16/debian/control
xserver-xorg-video-geode-2.11.16/debian/control
--- xserver-xorg-video-geode-2.11.16/debian/control 2014-11-11
00:33:21.0 +0200
+++ xserver-xorg-video-geode-2.11.16/debian/control 2015-01-16
15:10:27.0 +0200
@@ -40,6 +40,7 @@
Architecture: any-i386
Section: debug
Priority: extra
+Pre-Depends: dpkg (>= 1.17.14)
Depends: xserver-xorg-core-dbg,
xserver-xorg-video-geode (= ${binary:Version}),
${misc:Depends},
diff -Nru
xserver-xorg-video-geode-2.11.16/debian/xserver-xorg-video-geode-dbg.maintscript
xserver-xorg-video-geode-2.11.16/debian/xserver-xorg-video-geode-dbg.maintscript
---
xserver-xorg-video-geode-2.11.16/debian/xserver-xorg-video-geode-dbg.maintscript
1970-01-01 02:00:00.0 +0200
+++
xserver-xorg-video-geode-2.11.16/debian/xserver-xorg-video-geode-dbg.maintscript
2015-01-16 15:02:13.0 +0200
@@ -0,0 +1 @@
+dir_to_symlink /usr/share/doc/xserver-xorg-video-geode-dbg
/usr/share/doc/xserver-xorg-video-geode 2.11.13-5
Bug#775471: xserver-xorg-video-geode-dbg: copyright file missing after upgrade (policy 12.5)
Hey Andreas,
debian/rules uses this:
override_dh_installdocs:
dh_installdocs --link-doc=xserver-xorg-video-geode NEWS README TODO
Surely that would link the -dbg package's /usr/share/doc/foo-dbg to
.../foo, wouldn't it?
Martin-Éric
2015-01-16 5:21 GMT+02:00 Andreas Beckmann :
> Package: xserver-xorg-video-geode-dbg
> Version: 2.11.16-5
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> a test with piuparts revealed that your package misses the copyright
> file after an upgrade, which is a violation of Policy 12.5:
> https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
>
> After the upgrade /usr/share/doc/$PACKAGE/ is just an empty directory.
>
> This was observed on the following upgrade paths:
>
> wheezy -> jessie
>
> >From the attached log (scroll to the bottom...):
>
> 3m56.0s ERROR: WARN: Inadequate results from running adequate!
> xserver-xorg-video-geode-dbg: missing-copyright-file
> /usr/share/doc/xserver-xorg-video-geode-dbg/copyright
>
> 3m59.5s DUMP:
> MISSING COPYRIGHT FILE:
> /usr/share/doc/xserver-xorg-video-geode-dbg/copyright
> # ls -lad /usr/share/doc/xserver-xorg-video-geode-dbg
> drwxr-xr-x 2 root root 40 Jan 15 11:43
> /usr/share/doc/xserver-xorg-video-geode-dbg
> # ls -la /usr/share/doc/xserver-xorg-video-geode-dbg/
> total 0
> drwxr-xr-x 2 root root 40 Jan 15 11:43 .
> drwxr-xr-x 185 root root 3840 Jan 15 11:43 ..
>
>
> Additional info may be available here:
> https://wiki.debian.org/MissingCopyrightFile
>
> Note that dpkg intentionally does not replace directories with symlinks
> and vice versa, you need the maintainer scripts to do this.
> See in particular the end of point 4 in
> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase
>
> It is recommended to use the dpkg-maintscript-helper commands
> 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
> to perform the conversion, ideally using d/$PACKAGE.mainstscript.
> Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
> See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.
>
>
> cheers,
>
> Andreas
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728312: gnome-keyring RC bug – GNOME Bugzilla – Bug 711222
Hey Stef!, As reported at GNOME Bugzilla – Bug 711222 [1] there are some serious issues with gnome-keyring that have resulted in the package being marked as unfit for release. As you seem to be the main contributor to this package, could you please look into this? Thanks! Martin-Éric [1] https://bugzilla.gnome.org/show_bug.cgi?id=711222 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-bugs-rc
Bug#741785: seed: FTBFS: seed-readline.c:80:22: error: 'Function' undeclared (first use in this function)
On Sun, 16 Mar 2014 14:01:55 +0100 David =?iso-8859-1?Q?Su=E1rez?= wrote: > Source: seed > Version: 3.8.1-1 > Severity: serious > Tags: jessie sid > User: debian...@lists.debian.org > Usertags: qa-ftbfs-20140315 qa-ftbfs > Justification: FTBFS on amd64 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. FYI, this issue is now reported as FIXED upstream. -- Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-bugs-rc
Bug#739867: librest: FTBFS on kfreebsd-*
Package: librest Followup-For: Bug #739867 GNOME has become dependant upon Linux-specific features such as systemd anyhow, so the Arch field can probably be changed to linux-any as a fix. -- Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-bugs-rc
Bug#750883: gnome-keyring: ftbfs on kfreebsd
On Sat, 7 Jun 2014 23:26:44 -0400 Michael Gilbert wrote: > package: src:gnome-keyring > severity: grave > version: 3.12.0-2 > > The test suite failed on both kfreebsd architectures: > https://buildd.debian.org/status/package.php?p=gnome-keyring&suite=unstable GNOME has become dependant upon Linux-specific features such as systemd anyhow, so the Arch field can probably be changed to linux-any as a fix. Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-bugs-rc
Bug#747761: xulrunner-dev: ships mozilla-js.pc which is also in libmozjs-dev
2014-05-12 19:07 GMT+03:00 Rene Engelhard : > Hi, > > On Mon, May 12, 2014 at 04:41:35PM +0200, Rene Engelhard wrote: >> On Mon, May 12, 2014 at 02:01:28PM +0300, Martin-Éric Racine wrote: >> > xulrunner-dev probably needs to Conflicts/Provides/Replaces libmozjs-dev > > Yep. > > What I needed for upgrade was: > dpkg -P --force-depends libmozjs-dev > (installed xulrunner still wants it.) > apt-get -f install > (dist-upgrade complains about the now not fullfilled xulrunner-dev -> > libmozjs-dev > dependency) > > So yes, that Conflicts is definitely needed besides the obvious > Provides/Replaces Mike, do you need help on this one? -- Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-bugs-rc
Bug#747761: xulrunner-dev: ships mozilla-js.pc which is also in libmozjs-dev
2014-05-11 20:06 GMT+03:00 Rene Engelhard :
> Package: xulrunner-dev
> Version: 29.0.1-1
> Severity: serious
>
> Hi,
>
> In my dist-upgrade today:
>
> [...]
> dpkg: Fehler beim Bearbeiten des Archivs
> /var/cache/apt/archives/xulrunner-dev_29.0.1-1_amd64.deb (--unpack):
> Versuch, »/usr/lib/pkgconfig/mozilla-js.pc« zu überschreiben, welches auch
> in Paket libmozjs-dev 24.5.0esr-1 ist
> [...]
>
> Sorry, german, but you should get the idea ("xulrunner-dev contains
> /usr/lib/pkgconfig/mozilla-js.pc which is also
> in package libmozjs-dev 24.5.0esr-1")
>
> Interestingly there was no libmozjs-dev update.
That's probably because upstream decided to no longer ship a separate
Javascript parser; building the suite with their parser has become
compulsory.
xulrunner-dev probably needs to Conflicts/Provides/Replaces libmozjs-dev
-- Martin-Éric
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/debian-bugs-rc
Bug#720968: Enables javascript without asking
I suspect that this is a result of upstream's decision to no longer make it possible to build the browser without the Javascript component. http://news.slashdot.org/story/13/07/01/1547212/firefox-23-makes-javascript-obligatory -- Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714056: iceweasel: build-depends on obsolete ttf-* packages
Maintainer, This Iceweasel bug has been marked as serious for nearly a month, which has prevented transition of a recent enough Iceweasel package into Testing. Additionally, it has failed to build for a number of architectures (presumably because of the issue reported via this bug). Could an update be pushed into Unstable at your earliest convenience? Thanks! Martin-Éric 2013/6/25 Ansgar Burchardt > Source: iceweasel > Tags: jessie sid experimental > Version: 17.0.6esr-1 > Severity: serious > Control: found -1 21.0-1 > > iceweasel build-depends on two obsolete ttf-* packages. > ttf-dejima-mincho is already no longer build from source. > > Please depend on the fonts-* packages. > > ttf-dejima-mincho -> fonts-dejima-mincho > ttf-freefont -> fonts-freefont > > Ansgar > > >
Bug#672959: [Pkg-sysvinit-devel] Bug#672959: kfreebsd-*: panic: vm_fault_copy_wired
2012/8/20 Steven Chamberlain : > On 20/08/12 20:16, Axel Beckert wrote: >> [...] clearly something _after_ the fsck does that. > > Looking back at my 'dot' graph of initscript dependencies, it seems like > freebsdutils is the only thing that is free to run before, after, or at > the same time as checkroot.sh and thus could be affected by how long it > takes to run. Given how this issue only seems to affect kFreeBSD ports anyhow, I'm begining to suspect that it's due to freebsdutils having incorrect LSB header information in its init scripts and thus extremely tempted to reassign this bug to freebsdutils. Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672959: kfreebsd-*: panic: vm_fault_copy_wired
Something that popped into mind: Has the exact sysvinit version where this issue crept in been positively identified? While the bug report was filed against version 2.88dsf-22.1, I'm wondering if that was the exact sysvinit version where fsck.ufs started crashing the boot process in such a systematic way. Could someone from the debian-bsd list check this using earlier binaries from ( http://snapshot.debian.org/package/sysvinit/ ) and report whether any of them magically fixes the issue? If this is the case, it would allow us to backtrack the source of the bug. Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679409: lightdm: Fails to start on boot, invoke-rc.d lightdm start fails
2012/8/12 Roger Leigh : > On Sun, Aug 12, 2012 at 03:37:52PM +1000, James Tocknell wrote: >> I've tested the patch, and it doesn't fix the issue I'm having. I'm >> using Upstart >> as my init daemon, and lightdm still fails, with no useful output in >> /var/log/boot. However, lightdm does start when I use sysvinit as the init >> daemon, with the patch. Could this be a Upstart issue? I know lightdm has >> some association with Ubuntu, and Upstart is Ubuntu's default init daemon, >> could the issue be with the very different versions of Upstart in Ubuntu and >> Debian? The problem could lie in the fix for the bug #660824, which was a >> change between the version of sysvinit-utils that works for me and don't work >> for me, as it's Upstart related. > > I'll have to ask Steve Langasek, who was responsible for that change. > > Steve, it appears that lightdm won't start using upstart with the > recent sysvinit upstart bridge stuff. I'm not sure if this is an > issue in sysvinit, startpar-upstart-inject, or upstart. I've > patched startpar to special-case lightdm as for gdm/kdm, but this > doesn't appear to have any effect here (but is probably generally > a good thing to have). I'm wondering whether keeping the severity of this bug at RC level for what seems to be a corner case that only occurs whenever using 'upstart' as /sbin/init makes sense. It's currently blocking the transition into Testing of all packages generated from src:sysvinit, including recent fixes for a number of long-standing bugs. Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#609215: embedding PDF readers in chromium steals mouse pointer and lock X session
Package: mozplugger Followup-For: Bug #609215 As Wheezy is frozen and we have a better idea of which software versions will ship with it, I gotta ask: Does this issue still warrant the current severity level it has? Here, with Iceweasel 10 and Evince 3.4, I don't notice these symptoms, so I wonder if the severity should perhaps be lowered or the bug closed? -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (1001, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-3-686-pae (SMP w/2 CPU cores) Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mozplugger depends on: ii dpkg 1.16.4.3 ii iceweasel 10.0.6esr-1 ii libc6 2.13-33 ii libx11-6 2:1.5.0-1 ii m4 1.4.16-3 mozplugger recommends no packages. Versions of packages mozplugger suggests: pn abiword-common pn bplay ii evince 3.4.0-2+b1 pn gnumeric pn gqview ii imagemagick 8:6.7.7.10-2 ii libreoffice-common 1:3.5.4-5 pn mikmod pn mpg123 pn mpg321 pn mplayer | mplayer2 pn playmidi pn qiv pn rasmol pn sidplay-base pn sox pn splay pn texlive-base pn timidity pn vorbis-tools pn xcdroast pn xine-ui pn xmp pn xpdf pn xscreensaver-gl -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#650068: [Pkg-cups-devel] Bug#650068: cups-pdf: PDF created are all void without error notice
2011/11/26 Eric Lavarde : > Package: cups-pdf > Version: 2.6.1-3 > Severity: grave > Justification: renders package unusable > > Hello, > > after having migrated from squeeze to wheezy, cups-pdf does only produce > minimal PDF files without any content. I tried different apps > (Iceweasel, LibreOffice) without apparent difference in (bad) behavior. > The PDFs created do only differentiate in terms of IDs and dates/times > else they are completely the same; I'll attach an example. > I have also set the report level to debug and will also attach the > logfile but I don't see anything noticeable. > > I'm at loss what to do but currently cups-pdf is not usable at all for > me, hence the high severity. I'm pretty sure that we had resolved this issue when we introduced automatic updating of PPD files. However, Debian has taken the habit of heavily modifying CUPS, which often breaks CUPS-PDF. Let's see if other CUPS maintainers might know the cause. Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#648105: [Pkg-cups-devel] Bug#648105: closed by Martin Pitt (Bug#648105: fixed in cups 1.5.0-11)
2011/11/13 Michael Biebl : > On 13.11.2011 13:03, Martin-Éric Racine wrote: >> 2011/11/13 Michael Biebl : >>> It's about libcups2-dev having a Depends on libkrb5-dev | heimdal-dev, >>> not about the Build-Depends of the cups package. >> >> It would most likely affect both, actually. > > Fair enough. That said, do you have a eta for an upload which fixes both? I just pushed the fix in our Bazar repository, but I'not a DD, so I'd need someone to upload. Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#648105: [Pkg-cups-devel] Bug#648105: closed by Martin Pitt (Bug#648105: fixed in cups 1.5.0-11)
2011/11/13 Michael Biebl : > found 648105 1.5.0-11 > thanks > > On 11.11.2011 16:21, Debian Bug Tracking System wrote: >> This is an automatic notification regarding your Bug report >> which was filed against the libcups2-dev package: >> >> #648105: libheimdal-dev does not satisfy dependencies of cups-config --libs >> >> It has been closed by Martin Pitt . >> >> Their explanation is attached below along with your original report. >> If this explanation is unsatisfactory and you have not received a >> better one in a separate message then please contact Martin Pitt >> by >> replying to this email. >> >> > ... >> [ Martin-Éric Racine ] > ... >> * Removed |libheimdal-dev alternative from Build-Depends (Closes: #648105) > > > > This is not what the bug report was about. So re-opening. > > It's about libcups2-dev having a Depends on libkrb5-dev | heimdal-dev, > not about the Build-Depends of the cups package. It would most likely affect both, actually. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#583183: [Pkg-cups-devel] Bug#584003: cups-pdf: Security bugs in ghostscript
On Tue, Jun 1, 2010 at 4:06 AM, Paul Szabo wrote: > Package: cups-pdf > Severity: grave > Tags: security > Justification: user security hole > > > Please note remote execute-any-code security bugs in ghostscript: > > http://bugs.debian.org/583183 > > This package depends on ghostscript, and may be affected. Please > evaluate the security of this package, and fix if needed. In the future, please have the decency to consult with debian-devel before mass-filing bugs. Also check whether the issue actually applies to a package before filing a bug against it. We already call -dSAFER and drop privileges early, so we're already protected as it is. Closing. Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539705: can we proceed?
2009/9/12 Julien Cristau : > On Sat, Sep 12, 2009 at 13:18:16 +0300, Martin-Éric Racine wrote: > >> On Tue, Aug 18, 2009 at 12:35 PM, Julien Cristau wrote: >> > On Tue, Aug 18, 2009 at 10:50:57 +0300, Martin-Éric Racine wrote: >> > >> >> Unless I'm mistaken, all the required components for this new MESA and >> >> the new X.org to go into Testing are ready. Shall we remove this >> >> artificial RC bug then? >> >> >> > Not unless we want to ignore xserver-xorg-video-intel bugginess. >> > I'm not sure that we do, at this point. >> >> If -intel is the problem, then why don't we block that one, instead of >> blocking the whole X transition by blocking mesa? >> > Is this a joke? Intel has all the paid developers in the world to look after that particular issue with their driver. Meanwhile, the rest of X works fine as it is. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539705: can we proceed?
On Tue, Aug 18, 2009 at 12:35 PM, Julien Cristau wrote: > On Tue, Aug 18, 2009 at 10:50:57 +0300, Martin-Éric Racine wrote: > >> Unless I'm mistaken, all the required components for this new MESA and >> the new X.org to go into Testing are ready. Shall we remove this >> artificial RC bug then? >> > Not unless we want to ignore xserver-xorg-video-intel bugginess. > I'm not sure that we do, at this point. If -intel is the problem, then why don't we block that one, instead of blocking the whole X transition by blocking mesa? Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#545244: [Pkg-cups-devel] Bug#545244: Never mind
On Sun, Sep 6, 2009 at 2:03 AM, pete wrote: > This appears to have been a dependency problem. The package for version > 1.4.0-4 installed without installing the requisite library upgrades. Manually > installing the libcups* packages corrected the problem. I'm sorry, are you saying that 1.4.0-4 doesn't pull new dependencies with a matching version? Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543468: comment client.conf out if you're not using it
On Sat, Sep 5, 2009 at 9:55 PM, Matthew Sachs wrote: > On Sep 5, 2009, at 8:59, Martin-Éric Racine wrote: > >> That's an interesting case. Are you connecting only to remote printers or >> also to local printers? > > Only remote. OK, that would explain why you get asked for the password. Anyhow, we intentionally added a "-h localhost" option to every 'lpstat' and 'lpadmin" instance in the maintainer scripts of all CUPS-related packages that were uploaded over the past 24 hours. Please check whether that solves it for you and let us know if it doesn't. Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543468: comment client.conf out if you're not using it
On Sat, Sep 5, 2009 at 3:15 PM, Matthew Sachs wrote: > On 2009-09-05, at 07:19, Martin-Éric Racine wrote: > >> I notice that several people reporting this bug have an >> /etc/cups/client.conf pointing to some bogus remote host. Please >> comment this out and see if it fixes it. > > I can't speak for the others, but mine actually points to a non-bogus host. > I redacted the name to avoid exposing internal company network info. That's an interesting case. Are connecting only to remote printers or also to local printers? Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543468: comment client.conf out if you're not using it
I notice that several people reporting this bug have an /etc/cups/client.conf pointing to some bogus remote host. Please comment this out and see if it fixes it. Thanks! Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543973: [Pkg-cups-devel] Bug#543973: cups_1.4.0~svn8773-1(hppa/experimental): FTBFS: trying to link PIC and non-PIC code
On Thu, Aug 27, 2009 at 11:11 PM, Frank Lichtenheld wrote: > Package: cups > Version: 1.4.0~svn8773-1 > Severity: serious > > your package failed to build from source. > > | Automatic build of cups_1.4.0~svn8773-1 on meitner by sbuild/hppa 98-farm > | Build started at 20090827-1219 > [...] > | make[3]: Entering directory > `/build/buildd/cups-1.4.0~svn8773/filter/fontembed' > | cc -I/usr/include/poppler -I/usr/include/poppler -g -O2 -g -Wall -O2 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include > -DDBUS_API_SUBJECT_TO_CHANGE -D_REENTRANT -Wall -g -c -o sfnt.o sfnt.c > | sfnt.c: In function 'otf_subset': > | sfnt.c:1201: warning: unused variable 'iB' > | cc -I/usr/include/poppler -I/usr/include/poppler -g -O2 -g -Wall -O2 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include > -DDBUS_API_SUBJECT_TO_CHANGE -D_REENTRANT -Wall -g -c -o embed.o embed.c > | cc -I/usr/include/poppler -I/usr/include/poppler -g -O2 -g -Wall -O2 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include > -DDBUS_API_SUBJECT_TO_CHANGE -D_REENTRANT -Wall -g -c -o embed_sfnt.o > embed_sfnt.c > | cc -I/usr/include/poppler -I/usr/include/poppler -g -O2 -g -Wall -O2 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include > -DDBUS_API_SUBJECT_TO_CHANGE -D_REENTRANT -Wall -g -c -o dynstring.o > dynstring.c > | cc -I/usr/include/poppler -I/usr/include/poppler -g -O2 -g -Wall -O2 > -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include > -DDBUS_API_SUBJECT_TO_CHANGE -D_REENTRANT -Wall -g -c -o fontfile.o > fontfile.c > | ar rcu libfontembed.a sfnt.o embed.o embed_sfnt.o dynstring.o fontfile.o > | make[3]: Leaving directory > `/build/buildd/cups-1.4.0~svn8773/filter/fontembed' > | echo Linking texttopdf... > | Linking texttopdf... > | cc -L../cgi-bin -L../cups -L../filter -L../ppdc -L../scheduler > -Wl,--as-needed -pie -fPIE -Wall -Wno-format-y2k -fPIC -Os -g > -fstack-protector -D_GNU_SOURCE -o texttopdf texttopdf.o textcommon.o > common.o pdfutils.o -Lfontembed -lfontembed -lcups -lavahi-common > -lavahi-client -lgnutls -lpthread -lm -lcrypt > | /usr/bin/ld.real: fontembed/libfontembed.a(sfnt.o): relocation > R_PARISC_DPREL21L can not be used when making a shared object; recompile with > -fPIC > | fontembed/libfontembed.a: could not read symbols: Bad value > | collect2: ld returned 1 exit status > | make[2]: *** [texttopdf] Error 1 > | make[2]: Leaving directory `/build/buildd/cups-1.4.0~svn8773/filter' > | make[1]: *** [all] Error 1 > | make[1]: Leaving directory `/build/buildd/cups-1.4.0~svn8773' > | make: *** [debian/stamp-makefile-build] Error 2 > | dpkg-buildpackage: error: debian/rules build gave error exit status 2 > | > ** > | Build finished at 20090827-1228 > | FAILED [dpkg-buildpackage died] > > Full build log(s): > http://experimental.ftbfs.de/build.php?&ver=1.4.0~svn8773-1&pkg=cups&arch=hppa Thanks for bringing this to our attention. Does it still apply to 1.4.0-3 that is currently in experimental? Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529967: rezound: patch for CUPS transition attached
On Tue, Sep 1, 2009 at 2:12 PM, Martin Pitt wrote: > Martin-Éric Racine [2009-08-26 14:56 +0300]: >> +rezound (0.12.3beta-2.3) unstable; urgency=low >> + >> + * Non-maintainer upload. >> + * Removed old CUPSYS names in Build-Depends and Depends (Closes: #529967). > > I'd love to sponsor this, but the package is currently FTBFS. When > calling autoconf, m4 gets stuck in an eternal loop. > > I bump this to RC now, since rezound is the only (relevant) package > left in unstable which still needs the old transitional packages, and > I'm going to drop them in the next cups upload. (The other one is > libfox1.4, which is planned for removal anyway). As pointed out in my removal request against ftp.debian.org by an FTP Master, rezound actually is the last package left in the Debian archive that still depends upon libfox1.4 these days. I'm begining to wonder if it might be a good idea to request the removal of both packages. Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543661: patch for NMU attached
Package: gpr
Severity: normal
And sure enough, once I removed the higher APT priority given to Stable,
it built as expected. However, there were several Lintian warnings, some
of which the attach patch resolves.
diff -Nru gpr-0.14deb1/debian/changelog gpr-0.14deb1+nmu1/debian/changelog
--- gpr-0.14deb1/debian/changelog 2007-12-30 15:07:06.0 +0200
+++ gpr-0.14deb1+nmu1/debian/changelog 2009-08-30 15:30:34.0 +0300
@@ -1,3 +1,19 @@
+gpr (0.14deb1+nmu1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Removed old CUPSYS names in Build-Depends and Depends (Closes: #529964).
+ * Fixed the following Lintian warnings:
+W: gpr source: debhelper-but-no-misc-depends gpr
+ (fix: added ${misc:Depends} to debian/control)
+W: gpr source: package-uses-deprecated-debhelper-compat-version 4
+ (fix: 'echo 5 > debian/compat' and (>= 5.0) in debian/control)
+W: gpr source: debian-rules-sets-DH_COMPAT line 9
+ (fix: line commented out)
+W: gpr source: debian-rules-ignores-make-clean-error line 52
+ (fix: "-$(MAKE) distclean" to "[ ! -f Makefile ] || $(MAKE) distclean")
+
+ -- Martin-Éric Racine Sun, 30 Aug 2009 15:29:23 +0300
+
gpr (0.14deb1) unstable; urgency=low
* New README.Debian (with some explanations for CUPS)
diff -Nru gpr-0.14deb1/debian/compat gpr-0.14deb1+nmu1/debian/compat
--- gpr-0.14deb1/debian/compat 1970-01-01 02:00:00.0 +0200
+++ gpr-0.14deb1+nmu1/debian/compat 2009-08-30 15:11:07.0 +0300
@@ -0,0 +1 @@
+5
diff -Nru gpr-0.14deb1/debian/control gpr-0.14deb1+nmu1/debian/control
--- gpr-0.14deb1/debian/control 2007-12-30 13:10:20.0 +0200
+++ gpr-0.14deb1+nmu1/debian/control 2009-08-30 15:25:21.0 +0300
@@ -1,13 +1,13 @@
Source: gpr
Section: utils
Priority: optional
-Build-Depends: debhelper (>= 4.1.16), po-debconf, gettext, autotools-dev , libtool, libppd-dev (>= 0.10), libgtk2.0-dev (>= 2.6), libpopt-dev, zlib1g-dev
+Build-Depends: debhelper (>= 5.0), po-debconf, gettext, autotools-dev, libtool, libppd-dev (>= 0.10), libgtk2.0-dev (>= 2.6), libpopt-dev, zlib1g-dev
Maintainer: A Mennucc1
Standards-Version: 3.7.3.0
Package: gpr
Architecture: any
-Depends: ppdfilt, lprng | cupsys-bsd | lpr-ppd | lpr, debconf | debconf-2.0 , ${shlibs:Depends}
+Depends: ppdfilt, lprng | cups-bsd | lpr-ppd | lpr, debconf | debconf-2.0 , ${shlibs:Depends}, ${misc:Depends}
Recommends: a2ps
Description: GUI for lpr: print files and configure printer-specific options
gpr is a graphical interface to lpr that provides for easy configuration
diff -Nru gpr-0.14deb1/debian/rules gpr-0.14deb1+nmu1/debian/rules
--- gpr-0.14deb1/debian/rules 2006-07-06 19:18:03.0 +0300
+++ gpr-0.14deb1+nmu1/debian/rules 2009-08-30 15:25:49.0 +0300
@@ -6,7 +6,7 @@
#export DH_VERBOSE=1
# This is the debhelper compatability version to use.
-export DH_COMPAT=4
+#export DH_COMPAT=4
export DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
@@ -49,7 +49,7 @@
dh_testdir
dh_testroot
rm -f build-stamp
- -$(MAKE) distclean
+ [ ! -f Makefile ] || $(MAKE) distclean
dh_clean
#REALLY clean, since we call all the 'auto' stuff at build time
#find ltmain.sh config.guess config.sub COPYING INSTALL ABOUT-NLS missing mkinstalldirs intl po -type l | xargs -r rm
Bug#543661: FTBFS: build-depends cannot be met in Squeeze
On Sun, Aug 30, 2009 at 3:57 AM, peter green wrote: >>While producing a trivial patch for #529966, I noticed that >>"apt-get build-dep gpr" replied that build-depends >>cannot be met in Squeeze. > Seems to work fine for me in both squeeze and sid (and in both cases I > checked I had nothing listed in the obsolete and locally created packages > category) > > Can you still reproduce this issue? maybe it was something transiant. Yes, I can: $ LC_ALL=C apt-cache policy gpr gpr: Installed: (none) Candidate: 0.14deb1 Version table: 0.14deb1 0 500 http://ftp.fi.debian.org testing/main Packages 100 http://ftp.fi.debian.org unstable/main Packages $ date --utc su 30.8.2009 11.32.32 + $ LC_ALL=C sudo apt-get build-dep gpr Reading package lists... Done Building dependency tree Reading state information... Done E: Build-dependencies for gpr could not be satisfied. -- Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543661: FTBFS: build-depends cannot be met in Squeeze
Package: gpr Severity: serious Justification: no longer builds from source While producing a trivial patch for #529966, I noticed that "apt-get build-dep gpr" replied that build-depends cannot be met in Squeeze. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (990, 'stable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543647: FTBFS: build-deps cannot be met in Squeeze
Package: taxbird Severity: serious Justification: no longer builds from source While producing a trivial patch for bug #529946, "apt-get build-dep taxbird" reported that build-depends cannot be met by what's in Squeeze. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (990, 'stable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539705: can we proceed?
Unless I'm mistaken, all the required components for this new MESA and the new X.org to go into Testing are ready. Shall we remove this artificial RC bug then? Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539156: [Pkg-cups-devel] Bug#539156: Bug#539156: cups-pdf: requires user interaction on installation
On Thu, Jul 30, 2009 at 8:56 PM, Ronny Standtke wrote: > Am Donnerstag, den 30.07.2009, 15:20 +0200 schrieb Daniel Baumann: >> Martin-Éric Racine wrote: >> > How is the developer who builds a CD image expected to execute >> > lh_build? Using fakeroot, sudo or some other method? >> >> as root (as the documentation somewhere says). > > Here are the steps to reproduce the bug: > > 1) Do a fresh installation of Debian GNU/Linux 5.0.2 with all default > values. We have VirtualBox OSE in Debian so this should be no problem... It shouldn't but it was. The kernel inside VB keeps on getting a panic during bootup. Full stop. -- Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539156: [Pkg-cups-devel] Bug#539156: Bug#539156: cups-pdf: requires user interaction on installation
On Thu, Jul 30, 2009 at 3:42 PM, Daniel Baumann wrote: > Martin-Éric Racine wrote: >> I'll let them comment on this bug. > > nothing live specific, normal chroot with debconf priority criticial and > debconf frontend non-interactive. How is the developer who builds a CD image expected to execute lh_build? Using fakeroot, sudo or some other method? I'm just trying to determine what could possibly result in DPKG exceptionally running as a non-root user, which is the only way that lpadmin would ever get around prompting for a password. When executed by the root user, lpadmin does not ask for a password. -- Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539156: [Pkg-cups-devel] Bug#539156: Bug#539156: cups-pdf: requires user interaction on installation
On Thu, Jul 30, 2009 at 2:15 PM, Ronny Standtke wrote: >> -bash: lh_config: command not found >> -bash: lh_build: command not found > > $ sudo apt-get install live-helper > then try again lh_config (no output) lhconfig : Please note that the only way I could get lh_build to perform anything was by calling 'sudo lh_build' as 'fakeroot lh_build' would not work. Anyhow, the result was: Processing triggers for man-db ... Setting up console-data (2:1.07-11) ... dpkg: warning: obsolete option '--print-installation-architecture', please use '--print-architecture' instead. Looking for keymap to install: NONE Setting up cups-pdf (2.5.0-4) ... Setting up foomatic-db (20090616-1) ... Setting up foomatic-filters (4.0-20090509-1) ... Thus, I still fail to reproduce the bug that you reported. -- Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539156: [Pkg-cups-devel] Bug#539156: Bug#539156: cups-pdf: requires user interaction on installation
On Thu, Jul 30, 2009 at 2:55 PM, Ronny Standtke wrote: >> Checking with other members of the CUPS maintainer team, we noticed >> that the only case when lpadmin would ask for a password is when it's >> run by a non-root user. However, package installation (dpkg >> execution) always happens under user root. Thus, we fail to see how >> the issue you describe could ever happen. > > Could you please also check with the live-helper maintainers? Maybe they > can provide some more insight why installation of cups-pdf via > live-helper triggers this issue. I'll let them comment on this bug. -- Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538204: [Pkg-cups-devel] Bug#538204: cups: broken on squeeze by upgrade
On Fri, Jul 24, 2009 at 2:02 AM, Andres Salomon wrote: > On Thu, 23 Jul 2009 18:48:22 -0400 > Andres Salomon wrote: > >> Package: cups >> Version: 1.3.11-1 >> Severity: grave >> Justification: makes cupsd usuable >> >> Upon upgrading cups on a squeeze system, I see the following: > [...] >> >> I don't know if this is related, but in /var/log/cups/error_log, I >> see: E [23/Jul/2009:18:35:10 -0400] "/etc/cups/ssl/server.crt" is a >> bad symlink - No such file or directory >> >> >> lrwxrwxrwx 1 root root 36 2009-05-21 16:32 /etc/cups/ssl/server.crt >> -> /etc/ssl/certs/ssl-cert-snakeoil.pem ls: cannot >> access /etc/ssl/certs/ssl-cert-snakeoil.pem: No such file or directory >> > > Moving the server.crt aside allows the daemon to start. I'm pretty > sure that I didn't manually create that server.crt symlink.. Hello Andres, Martin Pitt and I just checked and found three points: 1) pkg:ca-certificates provides those PEM files. 2) CUPS only depends on the certificates. 3) Any missing certificate could only be the result of a) manual removal or b) broken maintainer scripts in pkg:ca-certificates. Please correct us if you disagree. Alternately, if you agree, please reassign this bug to ca-certificates. -- Cheers! Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539156: [Pkg-cups-devel] Bug#539156: Bug#539156: cups-pdf: requires user interaction on installation
Checking with other members of the CUPS maintainer team, we noticed hat the only case when lpadmin would ask for a password is when it's run by a non-root user. However, package installation (dpkg execution) always happens under user root. Thus, we fail to see how the issue you describe could ever happen. Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539156: [Pkg-cups-devel] Bug#539156: cups-pdf: requires user interaction on installation
On Wed, Jul 29, 2009 at 6:50 PM, Ronny Standtke wrote: >> Excuse me, but exactly how is a fully automated run of lpadmin >> supposed to qualify as user prompting? > > By printing the following line on the console > "Password for root on localhost?" > and waiting for the user to provide input. It doesn't ask for anything here. > What *exactly* happens when you execute the following both commands in a > new emtpy directory? > > $ lh_config \ > --distribution squeeze \ > --packages "cups-pdf" > > $ lh_build > -bash: lh_config: command not found -bash: lh_build: command not found Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539178: xserver-xorg-video-geode: complete freeze of a geode client (thincan DBE61)
2009/7/29 Xavier Brochard : > Package: xserver-xorg-video-geode > Version: 2.11.1-1~bpo50+1 > Severity: critical > Justification: breaks the whole system Please note that backports are not officially supported packages. :) > I use LTSP 5 on Debian Lenny. The Thincan DBE62 randomly freeze several time > a day. I would need to get a copy of the X.org log to see what happens. > The Thincan DBE-62 has a Geode LX700 microprocessor and 256 MB of ram. > We don't use flat-screen (I changed that in the Thincan's bios but it has no > effect). I am intimately familiar with those as I used to work for Artec. It could be a good idea to ask Artec for a BIOS update, since there were some stability issues with the BIOS that shipped with those preproduction DBE62D-700. Those were fixed during the development cycle of the similar upcoming DBE63 model. > The chroot is up to date (last lenny packages), geode driver is the last one > fom backports.org (2.11.1-1~bpo50+1), > but previous packages were freezing the system also. The geode-dbg package is > also installed. In that case, I'd like a full backtrace. Since the DBE62 can boot from USB, you should be able to use 'reportbug' after booting from a minimal OS running off a USB device. If you have all relevant debug packages installed and use 'reportbug' it will automatically attach useful debuging info which we could use to check what happens. Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
