Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency
Quoting Paul Gevers (2024-01-06 13:20:11) > Thanks for being elaborate in your reply, it matches what I was thinking. (I > wasn't aware of the other examples though). there are certainly more examples. For example I maintain the package box64 which allows running amd64 binaries on arm64 but requires amd64 libc to operate. Because pkg:amd64 doesn't work for britney, I used this: Depends: libgcc-s1:amd64 | libgcc-s1-amd64-cross, libstdc++6:amd64 | libstdc++6-amd64-cross I had to patch the software to also look into the paths that libgcc-s1-amd64-cross and libstdc++6-amd64-cross use to make this work. Those two packages are Architecture:all but they do contain amd64 shared libraries. Helmut probably has a much better idea whether, in an ideal world, Arch:all packages like libgcc-s1-amd64-cross should go away and be replaced by corresponding architecture-qualified dependencies on the architecture-specific libraries. Thanks! cheers, josch signature.asc Description: signature
Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency
Quoting Paul Gevers (2024-01-05 20:15:22) > Thanks for reaching out. Thank Helmut for poking me in #debian-apt :) > For britney2, the Sources stanza would also be needed; then we could use this > to generate britney2 testcases. I created 10 of those yesterday by hand [1]. > > The simplest for of tests is a tree with > var/data/unstable/Sources > # i386 is the default archive of the testsuite, which can be overruled > # if that makes sense > var/data/unstable/Packages_i386 > var/data/testing/Sources (may be empty) > var/data/testing/Packages_i386 > expected > > expected is in Heidi format (if I understand correctly) of what britney2 > will allow to be in testing after the run, it will only migrate packages > that are installable. > > Would it make sense to you to generate a branch in that archive with a bunch > of tests that you know the answer too? I think it's a bit more complicated than that. Currently, the tool creates 8624 package relationships. If I remember correctly, britney is unable to analyze cross-architecture relationships? In that case that number goes down to 2352. One could reduce that number even further and only check those cases where apt, dpkg and dose3 agree on a solution but that would then rather be a documentation of the status quo than a list of the intended ground truth. Maybe it would make sense to analyze the archive and only add those cases that currently exist as real package relationships? What the tool never received since its inception was somebody to look over these cases and write down what the ground-truth actually is supposed to look like. For the britney tests you likely want some kind of ground-truth and I fear that tool can give you the status quo but not necessarily the truth as intended by the spec. If that is fine for you, do you still want to add thousands of test-cases? Or do you want to hand-pick them? Thanks! cheers, josch signature.asc Description: signature
Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency
Hi, On Thu, 4 Jan 2024 21:04:57 +0100 Paul Gevers wrote: > [20:21:54] agreed, but britney2 doesn't handle :any on virtual > packages in any way (neither binary dep nor build dep) > [20:22:10] (and I'm not sure whether that's legal in any way) > [20:23:08] agreed > [20:23:28] which I'm fixing right now > [20:23:39] apparently there's builds with :native > [20:23:43] so I'll support that > [20:24:04] but I wanted to know what happens with :any (and > virtual B-D) > [20:25:07] well, this is not something that existed in the > archive before gobject-introspection, so we're about to extend what is > defined > [20:25:15] according to smcv this is legal to dpkg and apt > [20:25:35] but we know that resolvers > (dpkg/apt/dose/britney2/...) disagree on corner cases > [20:25:50] and I'm guilty of having written yet another > resolver in dumat > [20:26:26] britney2 just has to follow what dpkg and apt happen > to agree on > [20:26:45] or maybe even, what apt says > [20:27:01] if that works back in 2015 I wrote a small tool which is able to create artificial dependency situations involving two real packages and (optionally) a third virtual packages to make sure that the multi-arch implementations of apt, dpkg and dose3 agree with each other in all cases (spoiler: they do not). https://gitlab.mister-muffin.de/josch/deb-m-a-dep-check/ The tool is meant to make mass comparisons (it generates 8624 test cases) and thus its interface is a bit clunky but if what you want to do is to see whether apt, dose3 and dpkg agree on a situation where one package depends on a virtual package with :any which is provided by a real m-a: allowed package, then you would write this: ./check.sh binary pkgc amd64 amd64 no allowed depends pkgc:any It would generate the following two stubs (shortened here for brevity): Package: pkga Version: 1 Architecture: amd64 Depends: pkgc:any Multi-Arch: no Package: pkgb Version: 1 Architecture: amd64 Provides: pkgc Multi-Arch: allowed And yes, all three tools agree on this situation: it is satisfiable. If you make pkgb m-a:no, then all tools agree that the situation is unsatisfiable. We can do the same checks for pkga being a source package: ./check.sh source pkgc none amd64 none allowed depends pkgc:any Again, all three tools agree that this situation is satisfiable. Thanks! cheers, josch signature.asc Description: signature
Re: severity of bugs that FTBFS because of missing B-D
Hi, Quoting Sebastian Ramacher (2023-10-22 16:03:46) > Unless there is a plan to pu this change to stable's debootstrap, we are a > full release cycle away from this change having an effect. The time to change > this in deboostrap is now. debootstrap 1.0.133 now creates chroots with only essential, build-essential and apt with --variant=buildd. It was uploaded yesterday by Luca and seems to be ready to transition to testing tomorrow. Personally, I think this change is too disruptive for a stable update of debootstrap. So yes, effectively, buildds will probably only start using this change after the trixie release. But it now became much easier for maintainers of the remaining bugs to reproduce the problem by creating their buildd chroots with debootstrap from unstable and soon testing. Thanks! cheers, josch signature.asc Description: signature
Re: severity of bugs that FTBFS because of missing B-D
Hi, Quoting Sam Hartman (2023-10-12 20:28:15) > >>>>> "Johannes" == Johannes Schauer Marin Rodrigues > >>>>> writes: > >> also because technically it's the right decision from the release > >> team. these bugs are *currently*, in real life, merely cosmetic. > > Johannes> I disagree they are cosmetic or otherwise I would not've > Johannes> encountered them in my own work in Debian. But lets assume > Johannes> that you mean that they are only cosmetic as far as what > Johannes> the buildds do are concerned. In that case, would you > Johannes> rather be in favour of first changing debootstrap to not > Johannes> include Priority:required anymore in the buildd variant > Johannes> and only *then* raise their severity because only then an > Johannes> upload would really fail on the buildds? My idea was to do > Johannes> it the other way round but as said above this is of course > Johannes> up to the release team. > > We normally do it the other way around. For example in a transition, often > bugs start as important when they will ftbfs in the future. Then when the > transitioning software hits unstable, we mark them serious. > > I understand it's more complex here because on some non-buildd environments > these packages already ftbfs. But I do think it would be better to merge > into debootstrap and then upgrade the severity of the bugs. I agree with > Holger here. I note that none of us are on the release team. thank you for your input! I do not have a strong opinion or preference on either approach. I'm happy with anything that works so I'm glad that I've got all your replies here on how to best proceed in this situation. Thank you! Santiago also already replied in #837060 agreeing that it would make sense to first upload debootstrap with the change and not wait with that until all the bugs are fixed. Thanks! cheers, josch signature.asc Description: signature
Re: severity of bugs that FTBFS because of missing B-D
Hi Holger, let me re-order your mail so that I can reply in an order that puts more concrete points at the top and lets my mail end with a more meta discussion. Quoting Holger Levsen (2023-10-10 16:54:30) > policy is not a stick to hit with. I agree. I have not argued with policy in favour of this change anywhere unless I'm mistaken. I see RC bugs not as a policy tool but as a way of the release team to classify bugs as being okay for the next release or not. There exist RC bugs that the release team deems RC even though they do not directly violate policy and vice-versa. This is why I contacted the release team before raising their severity. In my mind it is up to them whether the bugs should be RC severity or not but please correct me if I'm wrong. > also because technically it's the right decision from the release team. > these bugs are *currently*, in real life, merely cosmetic. I disagree they are cosmetic or otherwise I would not've encountered them in my own work in Debian. But lets assume that you mean that they are only cosmetic as far as what the buildds do are concerned. In that case, would you rather be in favour of first changing debootstrap to not include Priority:required anymore in the buildd variant and only *then* raise their severity because only then an upload would really fail on the buildds? My idea was to do it the other way round but as said above this is of course up to the release team. > what do you gain by making people more annoyed? nothing. the bugs will not be > fixed faster and the people will not learn to be less or not annoyed. > > so there's no point. I'm going this route because *if* those bugs get classified as RC by the release team, then there are different mechanisms available to fix them, like NMUs in case the maintainer is unresponsive. The patch for each of these bugs is very minimal, so fixing them is usually as simple as adding the missing B-D. > but why? IME people will be more annoyed about RC bugs they disagree with > (even if they only disagree about the severity) than they will be annoyed > about the same bug with severity important. I am aware that this annoys people. I do not like to annoy people. But this is a problem that annoys me (and others). So right now we are in a situation where there are two ways forward: doing nothing and changing things. For each of these two ways there are people in favour of it and people against it. So independent of what the outcome is, *somebody* will be annoyed. Who is there to choose who should be the one annoyed in the end? Quite evidently there is no way out of this that annoys nobody. What would you do? Thanks! cheers, josch signature.asc Description: signature
Re: severity of bugs that FTBFS because of missing B-D
Hi, Quoting Sebastian Ramacher (2023-10-10 16:27:02) > Is there any progress on the buildd side to remove tzdata from the chroots? do you mean changing debootstrap such that the buildd variant is no longer including Priority:required packages? The MR for that is here: https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/106 Luca Boccassi seems to approve that change and in [1] expresses that it would be good for the list of affected bugs to go to zero before merging it. Before I go through these bugs again and contact their respective maintainers, I wanted to clarify their severity with you. Thanks! cheers, josch [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837060#84 signature.asc Description: signature
severity of bugs that FTBFS because of missing B-D
Dear release team, I'd like to get your confirmation that source packages that fail to build from source because they miss to declare a build dependency on packages outside the essential and build-essential set are actually of RC severity. The remaining packages that fail this (mostly because they are missing a B-D on tzdata or mount) can be found under this usertag: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org;tag=missing-build-depends-on-not-build-essential The fix is trivial (just adding the B—D) and all bugs have a patch attached. Those bugs were set from 'serious' to 'important' by Sebastian Ramacher a few months ago and I'd like to revisit this decision now that we are at the beginning of a new release cycle. Thanks! cheers, josch signature.asc Description: signature
Bug#1035975: [pre-approval] unblock: mmdebstrap/1.3.5-X
Hi, Quoting Luca Boccassi (2023-05-24 10:52:08) > Regarding dash, would it be possible for the autopkgtest to support both the > versions in unstable and experimental, so that it works and you can get it > unblocked? yes. The current version in unstable does exactly that. But as the dash unblock request got denied I guess I should revert that change now and do another upload. Thanks! cheers, josch signature.asc Description: signature
Bug#1035975: [pre-approval] unblock: mmdebstrap/1.3.5-X
Hi, Quoting Sebastian Ramacher (2023-05-24 09:48:31) > mmdebstrap's autopkgtest seem to depend quite extensively on the state of > other packages in the archive. Maybe it would be better to make them as > flaky. I don't think that would be wise. We do these tests for packages to find out when something breaks and we run those as autopkgtests so that things do not transition to testing when they break other things. Because the mmdebstrap autopkgtest tests so many things it found bugs earlier than many other mechanisms we use for QA. There are packages with autopkgtests depending on many more things than what the mmdebstrap autopkgtest depends on. Marking it as flaky would also be wrong because its output is not random but depends precisely on the state of the archive and produces the same result for the same state every time. Marking it as flaky would just hide problems. I think it's expected that a tool creating Debian chroots has tests that are affected by things happening in the Essential:yes set. > In any case, if you want to have this change in bookworm, be aware that the > window is closing quickly. I do not need this change in bookworm as the change only covers the autopkgtest. The contents of the mmdebstrap binary package are not affected by any of this, so even if this change gets approved it would not change what is shipped in bookworm (except of course the source package itself). I filed this pre-approval because maybe it is important for the release team that autopkgtests pass and thus I prepared for the changes that recently happened in doc-debian as well as in dash and adduser. Thanks! cheers, josch signature.asc Description: signature
Bug#1035975: [pre-approval] unblock: mmdebstrap/1.3.5-X
Hi, Quoting Sebastian Ramacher (2023-05-24 08:31:36) > Please check the autopkgtests. They are failing with errors that seem > unrelated to doc-debian. yes. As I said in my original email. mmdebstrap in unstable prepares not only for doc-debian but also for dash. But maybe you are not going to approve #1035745? Thanks! cheers, josch signature.asc Description: signature
Bug#1035975: [pre-approval] unblock: mmdebstrap/1.3.5-X
Hi,
Quoting Sebastian Ramacher (2023-05-20 13:38:20)
> > some of the packages uploaded to unstable or experimental are breaking the
> > mmdebstrap autopkgtest:
> >
> > - doc-debian rebuilt with debhelper (>= 13.4) changes the doc-base paths.
> > This
> >is recorded as #1035913 and the change is intentional. Thus the
> > mmdebstrap
> >autopkgtest has to be adjusted. The unblock bug for doc-debian was
> > #1035710.
> > - dash has an upload in experimental which removes its diversions. See bug
> >#989632 for details. The unblock bug is #1035745. I also adjusted the
> >autopkgtest to cope with those changes.
> > - if it is decided for adduser to become Essential:yes or pseudo-essential
> >(instead of using Protected:yes) more changes are required. I didn't
> >implement those yet, because I'm still hoping that it will be decided to
> > use
> >Protected:yes (in which case no changes are needed). Please consider
> >replying to my idea in #1035654
> >
> > All of the needed changes only affect the autopkgtest. Nothing touches the
> > functionality shipped by the mmdebstrap binary package and thus, this
> > unblock
> > cannot break anything (other than autopkgtest results).
>
> Could you please provide a debdiff of the proposed changes?
this is the debdiff between mmdebstrap in testing and unstable:
diff -Nru mmdebstrap-1.3.5/debian/changelog mmdebstrap-1.3.5/debian/changelog
--- mmdebstrap-1.3.5/debian/changelog 2023-03-20 08:05:19.0 +0100
+++ mmdebstrap-1.3.5/debian/changelog 2023-05-11 14:53:04.00000 +0200
@@ -1,3 +1,29 @@
+mmdebstrap (1.3.5-5) unstable; urgency=medium
+
+ * tests/jessie-or-older: dash 0.5.12-3 dropped diversions
+
+ -- Johannes Schauer Marin Rodrigues Thu, 11 May 2023
14:53:04 +0200
+
+mmdebstrap (1.3.5-4) unstable; urgency=medium
+
+ * tests/eatmydata-via-hook-dir: dash 0.5.12-3 dropped diversions
+
+ -- Johannes Schauer Marin Rodrigues Thu, 11 May 2023
06:57:42 +0200
+
+mmdebstrap (1.3.5-3) unstable; urgency=medium
+
+ * fix regex in debian/tests/copy_host_apt_config to first remove
+non-free-firmware and then non-free or otherwise components like
+"main-firmware" will be the result
+
+ -- Johannes Schauer Marin Rodrigues Wed, 10 May 2023
22:41:17 +0200
+
+mmdebstrap (1.3.5-2) unstable; urgency=medium
+
+ * fix for doc-debian 11.0 changing the doc-base paths
+
+ -- Johannes Schauer Marin Rodrigues Sat, 06 May 2023
19:15:48 +0200
+
mmdebstrap (1.3.5-1) unstable; urgency=medium
* New upstream version 1.3.5
diff -Nru
mmdebstrap-1.3.5/debian/patches/0001-tests-doc-debian-11.0-changed-the-doc-base-paths.patch
mmdebstrap-1.3.5/debian/patches/0001-tests-doc-debian-11.0-changed-the-doc-base-paths.patch
---
mmdebstrap-1.3.5/debian/patches/0001-tests-doc-debian-11.0-changed-the-doc-base-paths.patch
1970-01-01 01:00:00.0 +0100
+++
mmdebstrap-1.3.5/debian/patches/0001-tests-doc-debian-11.0-changed-the-doc-base-paths.patch
2023-05-11 14:53:04.0 +0200
@@ -0,0 +1,81 @@
+From e27a8d34724673f4df07b5827c921a9b63903095 Mon Sep 17 00:00:00 2001
+From: Johannes Schauer Marin Rodrigues
+Date: Sat, 6 May 2023 08:33:15 +0200
+Subject: [PATCH] tests: doc-debian 11.0 changed the doc-base paths
+
+---
+ tests/include | 2 +-
+ tests/install-doc-debian| 2 +-
+ tests/install-doc-debian-and-test-hooks | 2 +-
+ tests/multiple-include | 2 +-
+ tests/unpack-doc-debian | 2 +-
+ 5 files changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/tests/include b/tests/include
+index 95c9c69..e284b7d 100644
+--- a/tests/include
b/tests/include
+@@ -3,7 +3,7 @@ set -eu
+ export LC_ALL=C.UTF-8
+ trap "rm -rf /tmp/debian-chroot" EXIT INT TERM
+ {{ CMD }} --mode=root --variant=apt --include=doc-debian {{ DIST }}
/tmp/debian-chroot {{ MIRROR }}
+-rm /tmp/debian-chroot/usr/share/doc-base/debian-*
++rm /tmp/debian-chroot/usr/share/doc-base/doc-debian.debian-*
+ rm -r /tmp/debian-chroot/usr/share/doc/debian
+ rm -r /tmp/debian-chroot/usr/share/doc/doc-debian
+ rm /tmp/debian-chroot/var/lib/apt/extended_states
+diff --git a/tests/install-doc-debian b/tests/install-doc-debian
+index 81cb513..27d7f3e 100644
+--- a/tests/install-doc-debian
b/tests/install-doc-debian
+@@ -24,7 +24,7 @@ tar -C /tmp/debian-chroot --owner=0 --group=0
--numeric-owner --sort=name --clam
+ tar tvf /tmp/debian-chroot.tar > doc-debian.tar.list
+ rm /tmp/debian-chroot.tar
+ # delete contents of doc-debian
+-rm /tmp/debian-chroot/usr/share/doc-base/debian-*
++rm /tmp/debian-chroot/usr/share/doc-base/doc-debian.debian-*
+ rm -r /tmp/debian-chroot/usr/share/doc/debian
+ rm -r /tmp/debian-chroot/usr/share/doc/doc-debian
+ # delete real files
+diff --git a/tests/install-doc-debian-and-test-hooks
b/tests/inst
Bug#1036396: unblock: x2gothinclient/1.5.0.1-10
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: x2gothincli...@packages.debian.org, sunwea...@debian.org
Control: affects -1 + src:x2gothinclient
Please unblock package x2gothinclient
[ Reason ]
In the context of #1035654, five source packages (including this one)
still fail to purge remove without adduser installed.
[ Impact ]
We want to avoid the situation where a user removes the package, then
upgrades to apt that doesn't depend on adduser, then removes adduser and
then attempts to purge this package.
[ Tests ]
See the script I posted in #1035654.
[ Risks ]
Low risk due to trivial changes (see end of this mail) and because of
low popcon number (36 votes).
In addition to the adduser changes, the diff to testing also includes removal
of lsb-base and policykit-1 (in favour of polkitd). I'll leave it up to the
release team whether those additional changes on top of the adduser changes are
permitted or whether they should be reverted before granting the unblock
request.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock x2gothinclient/1.5.0.1-10
diff -Nru x2gothinclient-1.5.0.1/debian/changelog
x2gothinclient-1.5.0.1/debian/changelog
--- x2gothinclient-1.5.0.1/debian/changelog 2022-10-15 12:58:17.0
+0200
+++ x2gothinclient-1.5.0.1/debian/changelog 2023-05-19 10:59:29.0
+0200
@@ -1,9 +1,19 @@
-x2gothinclient (1.5.0.1-8.1) unstable; urgency=medium
+x2gothinclient (1.5.0.1-10) unstable; urgency=medium
- * Non-maintainer upload.
- * No source change upload to rebuild with debhelper 13.10.
+ * debian/changelog:
++ Fix wrong bug closure in upload of 1.5.0.1-9.
- -- Michael Biebl Sat, 15 Oct 2022 12:58:17 +0200
+ -- Mike Gabriel Fri, 19 May 2023 10:59:29 +0200
+
+x2gothinclient (1.5.0.1-9) unstable; urgency=medium
+
+ * debian/x2gothinclient-common.postrm:
++ Ignore failures during execution of deluser/delgroup. (Closes: #1034755).
+ * debian/control:
++ Drop from D: lsb-base (obsoleted package). Thanks, lintian.
++ Drop from D: policykit-1, replace by polkitd. Thanks, lintian.
+
+ -- Mike Gabriel Tue, 16 May 2023 22:09:06 +0200
x2gothinclient (1.5.0.1-8) unstable; urgency=medium
diff -Nru x2gothinclient-1.5.0.1/debian/control
x2gothinclient-1.5.0.1/debian/control
--- x2gothinclient-1.5.0.1/debian/control 2022-10-03 11:54:53.0
+0200
+++ x2gothinclient-1.5.0.1/debian/control 2023-05-16 22:14:12.0
+0200
@@ -56,7 +56,6 @@
${misc:Pre-Depends},
Depends:
${misc:Depends},
- lsb-base,
nfs-common,
patch,
plymouth,
@@ -66,7 +65,7 @@
dbus-user-session,
x2gothinclient-displaymanager | x2gothinclient-minidesktop,
locales,
- policykit-1,
+ polkitd,
Recommends:
acpid,
gnupg-agent,
@@ -187,14 +186,13 @@
${misc:Pre-Depends},
Depends:
${misc:Depends},
- lsb-base,
psmisc,
pinentry-x2go,
xauth,
xinit,
locales,
dbus-x11,
- policykit-1,
+ polkitd,
libfile-path-expand-perl,
x2gothinclient-common (>= ${source:Version}), x2gothinclient-common (<<
${source:Version}.1),
Provides:
@@ -265,7 +263,6 @@
Depends:
${shlibs:Depends},
${misc:Depends},
- lsb-base,
lsscsi,
eject,
libfile-path-expand-perl,
diff -Nru x2gothinclient-1.5.0.1/debian/x2gothinclient-common.postrm
x2gothinclient-1.5.0.1/debian/x2gothinclient-common.postrm
--- x2gothinclient-1.5.0.1/debian/x2gothinclient-common.postrm 2019-12-13
12:28:29.0 +0100
+++ x2gothinclient-1.5.0.1/debian/x2gothinclient-common.postrm 2023-05-16
22:07:53.0 +0200
@@ -17,8 +17,8 @@
case "$1" in
purge)
- getent passwd x2gothinclient >/dev/null && deluser
x2gothinclient
- getent group x2gothinclient >/dev/null && delgroup
x2gothinclient
+ getent passwd x2gothinclient >/dev/null && deluser
x2gothinclient || true
+ getent group x2gothinclient >/dev/null && delgroup
x2gothinclient || true
rm -Rf /var/lib/x2gothinclient
Bug#1036394: unblock: desktop-autoloader/0.0.4-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: desktop-autoloa...@packages.debian.org, sunwea...@debian.org Control: affects -1 + src:desktop-autoloader Please unblock package desktop-autoloader [ Reason ] In the context of #1035654, five source packages (including this one) still fail to purge remove without adduser installed. [ Impact ] We want to avoid the situation where a user removes the package, then upgrades to apt that doesn't depend on adduser, then removes adduser and then attempts to purge this package. [ Tests ] See the script I posted in #1035654. [ Risks ] Low risk due to trivial change (see end of this mail) and because of low popcon number (2 votes). [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock desktop-autoloader/0.0.4-2 diff -Nru desktop-autoloader-0.0.4/debian/changelog desktop-autoloader-0.0.4/debian/changelog --- desktop-autoloader-0.0.4/debian/changelog 2018-05-16 13:31:31.0 +0200 +++ desktop-autoloader-0.0.4/debian/changelog 2023-05-16 22:37:00.0 +0200 @@ -1,3 +1,10 @@ +desktop-autoloader (0.0.4-2) unstable; urgency=medium + + * debian/desktop-autoloader.postrm: ++ Ignore failures during execution of deluser/delgroup: (Closes: #1035291). + + -- Mike Gabriel Tue, 16 May 2023 22:37:00 +0200 + desktop-autoloader (0.0.4-1) unstable; urgency=medium * New upstream release. diff -Nru desktop-autoloader-0.0.4/debian/desktop-autoloader.postrm desktop-autoloader-0.0.4/debian/desktop-autoloader.postrm --- desktop-autoloader-0.0.4/debian/desktop-autoloader.postrm 2018-04-03 20:40:40.0 +0200 +++ desktop-autoloader-0.0.4/debian/desktop-autoloader.postrm 2023-05-16 22:35:46.0 +0200 @@ -22,8 +22,8 @@ rm -Rf ~desktop-autoloader fi - getent passwd desktop-autoloader >/dev/null && deluser desktop-autoloader - getent group desktop-autoloader >/dev/null && delgroup desktop-autoloader + getent passwd desktop-autoloader >/dev/null && deluser desktop-autoloader || true + getent group desktop-autoloader >/dev/null && delgroup desktop-autoloader || true # there might be extra .desktop symlinks in /etc/desktop-autoloader/autostart, # wiping them all...
Bug#1036383: unblock: webdis/0.1.9+dfsg-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: web...@packages.debian.org, and...@senkovych.com Control: affects -1 + src:webdis Please unblock package webdis [ Reason ] In the context of #1035654, five source packages (including this one) still fail to purge remove without adduser installed. [ Impact ] We want to avoid the situation where a user removes the package, then upgrades to apt that doesn't depend on adduser, then removes adduser and then attempts to purge this package. [ Tests ] See the script I posted in #1035654. [ Risks ] Low risk due to trivial change (see end of this mail) and because of low popcon number (5 votes). [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock webdis/0.1.9+dfsg-1.1 diff -Nru webdis-0.1.9+dfsg/debian/changelog webdis-0.1.9+dfsg/debian/changelog --- webdis-0.1.9+dfsg/debian/changelog 2020-04-23 01:04:04.0 +0200 +++ webdis-0.1.9+dfsg/debian/changelog 2023-05-18 00:10:16.0 +0200 @@ -1,3 +1,10 @@ +webdis (0.1.9+dfsg-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * ignore deluser not being available in postrm purge (closes: #1035435) + + -- Johannes Schauer Marin Rodrigues Thu, 18 May 2023 00:10:16 +0200 + webdis (0.1.9+dfsg-1) unstable; urgency=medium * d/copyright: acknowledge upstream files relocation diff -Nru webdis-0.1.9+dfsg/debian/webdis.postrm webdis-0.1.9+dfsg/debian/webdis.postrm --- webdis-0.1.9+dfsg/debian/webdis.postrm 2018-08-25 09:53:40.0 +0200 +++ webdis-0.1.9+dfsg/debian/webdis.postrm 2023-05-17 23:56:44.0 +0200 @@ -15,7 +15,7 @@ fi rm -rf $WEBDIS_LOG -deluser --system webdis +deluser --system webdis || true ;; *)
Bug#1036355: unblock: adduser/3.133
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: addu...@packages.debian.org, mh+debian-packa...@zugschlus.de
Control: affects -1 + src:adduser
Please unblock package adduser
[ Reason ]
After apt dropped its dependency on adduser, we want to make sure that
all packages requiring adduser in their purge removal maintainer scripts
can still be purged. Instead of adding adduser to the Essential:yes set,
we add the Protected:yes field to make harder to remove it once it is
installed. In the past, apt's dependency on adduser made it hard to
remove. Only five packages in testing still rely on adduser to purge.
More context can be found in #1035654
[ Impact ]
Then it could happen that a user upgrading to bookworm first upgrades
apt, then removes adduser and then is unable to purge packages they had
removed earlier.
[ Tests ]
piuparts correctly concluded that adduser cannot be removed anymore
(without supplying the --allow-remove-essential flag).
[ Risks ]
adduser is a central package but the change is small (see debdiff
below). The mmdebstrap autopkgtest heavily tests the pseudo-essential
set and none of its test cases broke by the addition of the
Protected:yes field.
What did break is the adduser piuparts result. So it is not sufficient
to just reduce the required age for adduser but to also force its
transition despite its piuparts failure. The piuparts failure is an
intended result from this change. The failure shows that the change has
the desired effect. To solve this, changes have to happen on the
piuparts side. See #1035654 for more discussion around this.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
Do not forget to add an additional hint that makes adduser migrate despite its
piuparts failure.
unblock adduser/3.133
diff -Nru adduser-3.132/debian/changelog adduser-3.133/debian/changelog
--- adduser-3.132/debian/changelog 2023-03-08 21:45:42.0 +0100
+++ adduser-3.133/debian/changelog 2023-05-16 23:27:12.0 +0200
@@ -1,3 +1,10 @@
+adduser (3.133) unstable; urgency=medium
+
+ [ Johannes Schauer Marin Rodrigues ]
+ * mark adduser as Protected:yes. This is a temporary fix for #1035694
+
+ -- Marc Haber Tue, 16 May 2023 23:27:12
+0200
+
adduser (3.132) unstable; urgency=medium
* This is a translation/documentation only release
diff -Nru adduser-3.132/debian/control adduser-3.133/debian/control
--- adduser-3.132/debian/control2023-03-08 21:45:42.0 +0100
+++ adduser-3.133/debian/control2023-05-16 23:27:12.0 +0200
@@ -15,6 +15,7 @@
Multi-Arch: foreign
Pre-Depends: ${misc:Pre-Depends}
Depends: passwd, ${misc:Depends}
+Protected: yes
Suggests: liblocale-gettext-perl, perl, cron, quota
Description: add and remove users and groups
This package includes the 'adduser' and 'deluser' commands for creating
diff -Nru adduser-3.132/doc/po4a/po/adduser.pot
adduser-3.133/doc/po4a/po/adduser.pot
--- adduser-3.132/doc/po4a/po/adduser.pot 2023-03-08 21:45:42.0
+0100
+++ adduser-3.133/doc/po4a/po/adduser.pot 2023-05-16 23:27:12.0
+0200
@@ -7,7 +7,7 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
-"POT-Creation-Date: 2023-03-17 12:15+0100\n"
+"POT-Creation-Date: 2023-05-17 12:17+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME \n"
"Language-Team: LANGUAGE \n"
diff -Nru adduser-3.132/doc/po4a/po/fr.po adduser-3.133/doc/po4a/po/fr.po
--- adduser-3.132/doc/po4a/po/fr.po 2023-03-08 21:45:42.0 +0100
+++ adduser-3.133/doc/po4a/po/fr.po 2023-05-16 23:27:12.0 +0200
@@ -8,7 +8,7 @@
msgid ""
msgstr ""
"Project-Id-Version: adduser 3.115\n"
-"POT-Creation-Date: 2023-03-17 12:15+0100\n"
+"POT-Creation-Date: 2023-05-17 12:17+0200\n"
"PO-Revision-Date: 2023-01-18 08:09+0100\n"
"Last-Translator: Jean-Paul Guillonneau \n"
"Language-Team: French \n"
diff -Nru adduser-3.132/doc/po4a/po/pt.po adduser-3.133/doc/po4a/po/pt.po
--- adduser-3.132/doc/po4a/po/pt.po 2023-03-08 21:45:42.0 +0100
+++ adduser-3.133/doc/po4a/po/pt.po 2023-05-16 23:27:12.0 +0200
@@ -5,7 +5,7 @@
msgid ""
msgstr ""
"Project-Id-Version: adduser 3.130\n"
-"POT-Creation-Date: 2023-03-17 12:15+0100\n"
+"POT-Creation-Date: 2023-05-17 12:17+0200\n"
"PO-Revision-Date: 2023-01-06 23:30+\n"
"Last-Translator: Américo Monteiro \n"
"Language-Team: Portuguese <>\n"
Re: non-essential adduser poses problems to purging packages
Hi, Quoting Nicolas Dandrimont (2023-05-18 20:51:04) > On Thu, May 18, 2023, at 10:03, Marc Haber wrote: > > adduser probably needs an additional hint because the new upload makes > > piuparts fail now, as discussed yesterday. > To work around this issue on the piuparts side, it sounds like we should make > piuparts treat adduser as fake-essential for tests ending at bookworm or sid, > so that we don't try to uninstall it; Andreas, what do you think? a more general solution would be to skip uninstallation on all packages marked with Protected:yes or to only uninstall with --allow-remove-essential. Such a solution would not only benefit adduser but also any future packages marked with Protected:yes. Thanks! cheers, josch signature.asc Description: signature
Re: non-essential adduser poses problems to purging packages
Hi, here is a status update on the adduser situation. Quoting Johannes Schauer Marin Rodrigues (2023-05-10 08:10:26) > The remaining 14 failures belong to the following 9 source packages: > > amavisd-new #1035841 > debian-edu-fai #1035292 > desktop-autoloader #1035291 > kismet #1035290 > matrix-sydent #1035844 > tcpcryptd #1035845 > webdis #1035435 > x2gobroker #1035847 > x2gothinclient #1034755 > > Out of these 9 remaining source packages, 5 had bugs already filed by Andreas > Beckmann. I filed bugs with patches for the remaining 4 packages and offered > to NMU if necessary. amavisd-new #1035841 fixed in unstable, unblock approved, will transition tomorrow debian-edu-fai #1035292, desktop-autoloader #1035291, x2gobroker-* #1035847, x2gothinclient #1034755 done by Mike Gabriel kismet #1035290, matrix-sydent #1035844, tcpcryptd #1035845 not in testing (nor stable) so no action required right now webdis #1035435 NMU-ed to DELAYED/2 Mike, you said on IRC that you want to file the unblock bugs for debian-edu-fai, desktop-autoloader, x2gobroker and x2gothinclient (which didn't happen yet). If you like, I can file these for you. Just say the word. :) Marc, the same offer to you for your recent adduser upload to unstable. Thanks! cheers, josch signature.asc Description: signature
Bug#1036016: unblock: amavisd-new/1:2.13.0-3
Control: tags -1 - moreinfo Quoting Sebastian Ramacher (2023-05-16 23:24:42) > Okay, then please go ahead and remove the moreinfo tag once the package is > available in unstable. version 1:2.13.0-3 has been uploaded to unstable four days ago and implements exactly (and only) this change: https://tracker.debian.org/news/1431032/accepted-amavisd-new-12130-3-source-into-unstable/ Thanks! cheers, josch signature.asc Description: signature
Re: non-essential adduser poses problems to purging packages
Hi, Quoting Sebastian Ramacher (2023-05-16 22:15:33) > If you agree that making it Essential: yes or Protected: yes, then please go > ahead with implementing this change. The window to fix this is closing > quickly. I've submitted a merge request for adduser adding the Protected:yes field: https://salsa.debian.org/debian/adduser/-/merge_requests/86 I'll NMU the remaining four packages that haven't been fixed yet on Thursday with a delay of 2-days unless the release team recommends a different delay. Thanks! cheers, josch signature.asc Description: signature
Bug#1036016: unblock: amavisd-new/1:2.13.0-3
Hi, Quoting Sebastian Ramacher (2023-05-16 22:11:58) > > [ Risks ] > > > > Low risk as the diff simply is: > > > > diff -Nru amavisd-new-2.13.0/debian/amavisd-new.postrm > > amavisd-new-2.13.0/debian/amavisd-new.postrm > > --- amavisd-new-2.13.0/debian/amavisd-new.postrm 2023-02-23 > > 05:59:36.0 +0100 > > +++ amavisd-new-2.13.0/debian/amavisd-new.postrm 2023-05-12 > > 00:41:50.0 +0200 > > @@ -33,7 +33,7 @@ > > dpkg-statoverride --remove $i || true > > done > > > > -userdel amavis > > +userdel amavis || true > > userdel is from passwd and not from adduser. Am I missing something? Correct. But passwd is not Essential:yes and only gets pulled in by adduser. The passwd package missing was part of my analysis in #1035654 because in that test I only had Essential:yes packages installed (or otherwise I would not've found this bug). Thanks! cheers, josch signature.asc Description: signature
Bug#1036016: unblock: amavisd-new/1:2.13.0-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: amavisd-...@packages.debian.org, b...@debian.org Control: affects -1 + src:amavisd-new Please unblock package amavisd-new [ Reason ] In the context of #1035654 me and Andreas Beckmann discovered nine source packages that fail to purge without the adduser package installed. Accepting this change would reduce that number to eight and close #1035841 in testing. [ Impact ] That depends on the resolution of #1035654. We want to avoid the situation where a user removes the package, then upgrades to apt that doesn't depend on adduser, then removes adduser and then attempts to purge this package. [ Tests ] See the script I posted in #1035654. [ Risks ] Low risk as the diff simply is: diff -Nru amavisd-new-2.13.0/debian/amavisd-new.postrm amavisd-new-2.13.0/debian/amavisd-new.postrm --- amavisd-new-2.13.0/debian/amavisd-new.postrm2023-02-23 05:59:36.0 +0100 +++ amavisd-new-2.13.0/debian/amavisd-new.postrm2023-05-12 00:41:50.0 +0200 @@ -33,7 +33,7 @@ dpkg-statoverride --remove $i || true done -userdel amavis +userdel amavis || true echo "Removing amavis files and directories..." [ -d /var/lib/amavis ] && rm -fr /var/lib/amavis [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] I'd like to get some feedback on my proposal in #1035654 and I'd like to know whether you'd think whether I should NMU the remaining eight packages that fail to purge without adduser with the same patch as this package? unblock amavisd-new/1:2.13.0-3
Bug#1035975: [pre-approval] unblock: mmdebstrap/1.3.5-X
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: mmdebst...@packages.debian.org Control: affects -1 + src:mmdebstrap Control: block -1 by #1035654 #1035745 #1035710 Hi, some of the packages uploaded to unstable or experimental are breaking the mmdebstrap autopkgtest: - doc-debian rebuilt with debhelper (>= 13.4) changes the doc-base paths. This is recorded as #1035913 and the change is intentional. Thus the mmdebstrap autopkgtest has to be adjusted. The unblock bug for doc-debian was #1035710. - dash has an upload in experimental which removes its diversions. See bug #989632 for details. The unblock bug is #1035745. I also adjusted the autopkgtest to cope with those changes. - if it is decided for adduser to become Essential:yes or pseudo-essential (instead of using Protected:yes) more changes are required. I didn't implement those yet, because I'm still hoping that it will be decided to use Protected:yes (in which case no changes are needed). Please consider replying to my idea in #1035654 All of the needed changes only affect the autopkgtest. Nothing touches the functionality shipped by the mmdebstrap binary package and thus, this unblock cannot break anything (other than autopkgtest results). Thanks! cheers, josch
Bug#1035745: unblock: dash/0.5.12-4 (preapproval)
Hi, On Mon, 08 May 2023 16:54:32 +0100 Luca Boccassi wrote: > This cleanup has been uploaded last week to experimental with dash/0.5.12-3. > We have tested it and cannot see any issues with it. dash in experimental breaks the autopkgtest of mmdebstrap. I've fixed these problems already and uploaded the fixed version of mmdebstrap to unstable. I can also confirm that dash in experimental does not break my work on chrootless bootstrap. I will file the unblock request for mmdebstrap as soon as the breakages with the recent doc-debian upload are resolved. Thanks! cheers, josch signature.asc Description: signature
Bug#1035710: doc-debian 11.0 changed /usr/share/doc-base/ paths
Package: doc-debian
Version: 11.0
Severity: normal
Hi,
On Mon, 8 May 2023 07:46:09 +0200 Joost van =?utf-8?Q?Baal-Ili=C4=87?=
wrote:
> [ Risks ] None. The doc-debian package is a key package due to Priority:
> standard. It acts as a leaf package: Its only true reverse depends is the
> live-task-standard package.[reverse-depends]
you are forgetting packages using doc-debian in their autopkgtests.
> [ Other info ] I made a mistake uploading doc-debian 11.0 to unstable; that
> got accepted. The version 11.1 is now available from
> http://mdcc.cx/tmp/doc-debian/ . I've incorporated some small cosmetic
> changes next to the much needed document updates. Attached is a 161 kB
> doc-debian_6.5-11.1.dsc-debdiff , as well as a summarizing 13kB
> doc-debian_6.5-11.1.dsc-debdiff-tldr .
Before your upload of 11.0, doc-debian contained:
/usr/share/doc-base/debian-constitution-text
/usr/share/doc-base/debian-mailing-lists
/usr/share/doc-base/debian-manifesto
/usr/share/doc-base/debian-reporting-bugs
/usr/share/doc-base/debian-social-contract
Then with 11.0 this became:
/usr/share/doc-base/doc-debian.debian-constitution-text
/usr/share/doc-base/doc-debian.debian-mailing-lists
/usr/share/doc-base/doc-debian.debian-manifesto
/usr/share/doc-base/doc-debian.debian-reporting-bugs
/usr/share/doc-base/doc-debian.debian-social-contract
This broke the autopkgtest of mmdebstrap which you can also see on the excuses
page for doc-debian: https://qa.debian.org/excuses.php?package=doc-debian
Since I noticed this breakage, I uploaded a new version of mmdebstrap that
works around this problem, assuming that this change was intentional. In
hindsight, I probably should've contacted you instead because when
investigating http://mdcc.cx/tmp/doc-debian/doc-debian_11.1_all.deb and
comparing it to the version from unstable I see:
diff -u <(curl --silent
http://ftp.de.debian.org/debian/pool/main/d/doc-debian/doc-debian_11.0_all.deb
| dpkg-deb -c - | awk '{print $6}' | sort) <(curl --silent
http://mdcc.cx/tmp/doc-debian/doc-debian_11.1_all.deb | dpkg-deb -c - | awk
'{print $6}' | sort)
--- /dev/fd/63 2023-05-11 08:18:34.782823397 +0200
+++ /dev/fd/62 2023-05-11 08:18:34.782823397 +0200
@@ -3,11 +3,11 @@
./usr/share/
./usr/share/doc/
./usr/share/doc-base/
-./usr/share/doc-base/doc-debian.debian-constitution-text
-./usr/share/doc-base/doc-debian.debian-mailing-lists
-./usr/share/doc-base/doc-debian.debian-manifesto
-./usr/share/doc-base/doc-debian.debian-reporting-bugs
-./usr/share/doc-base/doc-debian.debian-social-contract
+./usr/share/doc-base/debian-constitution-text
+./usr/share/doc-base/debian-mailing-lists
+./usr/share/doc-base/debian-manifesto
+./usr/share/doc-base/debian-reporting-bugs
+./usr/share/doc-base/debian-social-contract
./usr/share/doc/debian/
./usr/share/doc/debian/bug-log-access.txt
./usr/share/doc/debian/bug-log-mailserver.txt.gz
What are the intended paths. Should I revert my changes to mmdebstrap or not?
Also, these changes of paths in /usr/share/doc-base/ forth and back are not
recorded in debian/changelog. If the change was intended, please document it.
Thanks!
cheers, josch
signature.asc
Description: signature
Re: non-essential adduser poses problems to purging packages
Hi, Quoting Helmut Grohne (2023-05-07 13:52:50) > > I contend that: > > 1. This change is in unstable since 2022-10-31, i.e. more than half a > year. > 2. While having adduser drop from the essential+apt set is caused by > apt dropping it, this was an implementation detail and any package > using adduser without a dependency was (invisibly) buggy before. > > So I don't quite buy the reasoning of "too late" or it being apt's > fault. > > On the flip side, I think it would technically have been the > responsibility of the proponents of dropping adduser to do the testing. > The proponents have been Josch and my self and we ultimately failed to do so. > Thanks to Andreas for doing it for us. this is true. I must admit that I haven't thought of maintainer scripts using adduser during purge and failing because they expect adduser to always be installed. Even though it is too late, I ran this script on all 11864 binary packages in unstable amd64 that have either a postrm or prerm script: #!/bin/sh set -eu ret=0 PKG_TO_TEST="$1" mmdebstrap --logfile="$1.log" --variant=essential \ --customize-hook='APT_CONFIG=$MMDEBSTRAP_APT_CONFIG apt-get -oDPkg::Chroot-Directory="$1" --yes install --no-install-recommends "$PKG_TO_TEST"' \ --customize-hook='APT_CONFIG=$MMDEBSTRAP_APT_CONFIG apt-get -oDPkg::Chroot-Directory="$1" --yes remove adduser' \ --customize-hook='printf "#!/bin/sh\nset -eu\necho \"I: adduser-dummy: attempting to run \$0\" >&2\nexit 1\n" > "$1/usr/sbin/adduser-dummy"' \ --customize-hook='chmod +x "$1/usr/sbin/adduser-dummy"' \ --customize-hook='ln -s adduser-dummy "$1/usr/sbin/adduser"' \ --customize-hook='ln -s adduser-dummy "$1/usr/sbin/deluser"' \ --customize-hook='ln -s adduser-dummy "$1/usr/sbin/addgroup"' \ --customize-hook='ln -s adduser-dummy "$1/usr/sbin/delgroup"' \ --customize-hook='APT_CONFIG=$MMDEBSTRAP_APT_CONFIG apt-get -oDPkg::Chroot-Directory="$1" --yes remove --purge "$PKG_TO_TEST"' \ unstable /dev/null http://127.0.0.1:3142/debian || ret=$? if [ "$ret" -eq 0 ] && ! grep --silent "^I: adduser-dummy: attempting to run " "$1.log"; then rm "$1.log" fi I did not limit the investigation to the packages with strings like deluser and delgroup in their maintainer scripts to make sure to also catch packages that indirectly call adduser tools through another script. Out of the tested 11864 packages, 133 called adduser tools at one point or the other but purging still succeeds (for example because of a || true). 210 of the tested 11864 packages fail this script. Out of the 210 failures, 17 are Essential:yes packages and thus failed. Out of the 193 remaining failures, 113 fail to install in the first place. Out of the 80 remaining failures, 32 fail because they try calling adduser tools which are not installed and thus fail. I skimmed through the 48 other purging failures and they seem to be nearly all related to gtk and gsettings. Of the remaining 32 adduser related purging problems, 18 packages check if deluser/delgroup exist before calling it and then fail because I installed the dummy. The remaining 14 failures belong to the following 9 source packages: amavisd-new #1035841 debian-edu-fai #1035292 desktop-autoloader #1035291 kismet #1035290 matrix-sydent #1035844 tcpcryptd #1035845 webdis #1035435 x2gobroker #1035847 x2gothinclient #1034755 Out of these 9 remaining source packages, 5 had bugs already filed by Andreas Beckmann. I filed bugs with patches for the remaining 4 packages and offered to NMU if necessary. > > With such a change I would have expected upgrade/piuparts tests from > > bullseye to bookworm that tried to remove adduser a various stages and > > check for the fallout. Given that Andreas is only doing them now, that's > > too late for changes to the pseudo-essential set. Given that only 9 source packages in unstable fail to purge because they expect adduser to be present, I have another proposal. I think making adduser Essential:yes (even if temporary) or making it a dependency of an Essential:yes has the downside, that now package maintainers have official reason to rely on its functionality and include that into their maintainer scripts. Finding these new bugs becomes a bit more tricky because to test for this, an Essential:yes package has to be removed. Same goes for making it pseudo-essential via apt because removing adduser to test regressions would remove apt. According to [popcon], adduser is installed on 100% of the systems providing popcon data. This makes sense because probably near 100% of the systems submitting popcon data either has apt installed (which used to pull in adduser) or was installed via d-i (which pulls in adduser because it is Priority:important). I would thus argue that what we have to guard against
Bug#1033347: nmu: gridsite, mutt, slashem, util-linux
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: grids...@packages.debian.org, m...@packages.debian.org,
slas...@packages.debian.org, util-li...@packages.debian.org
Control: affects -1 + src:gridsite src:mutt src:slashem src:util-linux
Hi,
fakeroot bug #1023286 [1] is fixed now in unstable. Using the attached
script, I found four source packages that have non-root owned files for
amd64 and no files owned by a non-root user for i386. Rebuilding those
four source packages with fakeroot in unstable will fix this issue. I
didn't try the other three 32 bit architectures but assume that the
issue will be fixed there in the same way.
To prevent multi-arch:same version skews, gridsite and util-linux maybe have to
be rebuilt on ANY architecture?
Thanks!
cheers, josch
nmu gridsite_3.0.0~20180202git2fdbc6f-3+b4 . armel armhf i386 mipsel . unstable
. -m "rebuild with fakeroot #1030638 fixed"
nmu mutt_2.2.9-1 . armel armhf i386 mipsel . unstable . -m "rebuild with
fakeroot #1030638 fixed"
nmu slashem_0.0.7E7F3-10 . armel armhf i386 mipsel . unstable . -m "rebuild
with fakeroot #1030638 fixed"
nmu util-linux_2.38.1-5 . armel armhf i386 mipsel . unstable . -m "rebuild with
fakeroot #1030638 fixed"
[1] https://lists.debian.org/167595344742.2689605.6866779165899252490@localhost
#!/bin/sh
set -eu
if [ ! -e rootneeded.txt ]; then
curl --silent
https://trends.debian.net/rulesreqroot_unstable-packages.csv \
| grep --invert-match ',adopted, fakeroot not needed' \
| sed -ne 's/,.*//p' \
| sort > rootneeded.txt
fi
if [ ! -e archany.txt ]; then
apt-get indextargets --format '$(FILENAME)' 'Identifier: Sources'
'Component: main' 'Origin: Debian' 'Suite: unstable' \
| xargs /usr/lib/apt/apt-helper cat-file \
| grep-dctrl --invert-match --exact-match --field Architecture
all --no-field-names --show-field=Package \
| sort > archany.txt
fi
comm -12 rootneeded.txt archany.txt > archanyrootneeded.txt
dlarchany() {
arch="$1"
while read -r src; do
echo "$src" >&2
mkdir tmp
apt-cache showsrc --only-source "$src" \
| grep-dctrl --show-field Binary
--no-field-names '' \
| tr , '\n' \
| sort -u \
| while read -r bin; do
[ -z "$bin" ] && continue
# this fails if $bin is arch:all but we
are not
# interested in those anyways because
those are built
# on amd64
env --chdir tmp apt-get download
"$bin:$arch" >/dev/null || continue
if dpkg-deb --fsys-tarfile tmp/*.deb \
| tar tv \
| grep --silent --invert-match
' root/root '; then
echo "$src"
rm tmp/*.deb
break
fi
rm tmp/*.deb
done
rmdir tmp
done
}
dlarchany amd64 < archanyrootneeded.txt > nonrootownership_amd64.txt
dlarchany i386 < nonrootownership_amd64.txt > nonrootownership_i386.txt
comm -23 nonrootownership_amd64.txt nonrootownership_i386.txt
Bug#1027127: transition: zxing-cpp
Hi, Quoting Sebastian Ramacher (2022-12-29 10:30:42) > > > Is it too late before the freeze to do this? > > > > It's not too late, but we need to finish the qtbase-opensource-src > > transition first. > > Please go ahead. zxing-cpp 1.4.0-1 is now in unstable and the transition underway: https://release.debian.org/transitions/html/auto-zxing-cpp.html In case anything FTBFS I'll file bugs and patches as required. Boyuan, I tried to merge the unstable and experimental branches as best I could. I hope I didn't forget anything. If I messed something up, please tell and I'll take care to repair it. Dennis, in #1021686 you expressed that you wanted 1.4.0 for mediastreamer2 5.2. I wanted to notify you, that the version is now available for you in unstable. Thanks! cheers, josch
Bug#1027127: transition: zxing-cpp
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: zxing-...@packages.debian.org Control: affects -1 + src:zxing-cpp Hi, the gstreamer 1.22 release as well as mediastreamer2 5.2 need zxing-cpp version 1.4. Currently there is 1.2 in unstable and 1.4 in experimental. Boyuan Yang, the maintainer of zxing-cpp told me to take care of this transition as they lack the time right now to to so themselves. I have rebuilt the reverse dependencies of libzxing-dev as listed here: https://release.debian.org/transitions/html/auto-zxing-cpp.html The one that FTBFS is libreoffice for which I submitted a bug here that is already fixed in unstable: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027048 Is it too late before the freeze to do this? Thanks! cheers, josch Ben file: title = "zxing-cpp"; is_affected = .depends ~ "libzxingcore1" | .depends ~ "libzxing2"; is_good = .depends ~ "libzxing2"; is_bad = .depends ~ "libzxingcore1";
Bug#1020799: Transition: pkg-config to pkgconf: next steps
Quoting Andrej Shadura (2022-10-20 12:25:13) > I’ve been rebuilding packages with pkgconf for the past couple of weeks, and > it looks very good so far: > > http://pkgconf-migration.debian.net/ Thank you! Attached is a dd-list of those packages listed in the "Failures only" page in case somebody wants to have a quick glance whether their package is affected. Thanks! cheers, joschA Mennucc1 gpr xmorph (U) A. Maitland Bottoms gr-fcdproplus (U) gr-iio gr-radar uhd Abou Al Montacir view3dscene (U) Adrian Bunk gconf-editor Adrian Knoth ardour (U) liblrdf (U) Adrien Cunin libdjconsole Aggelos Avgerinos xmobar (U) Alberto Garcia webkit2gtk (U) wpewebkit (U) Alessandro Ghedini kcov Alessio Treglia gigedit (U) lives (U) Alexander GQ Gerasiov clickhouse xneur Alexander Wirt icinga2 (U) Ana Custura chkservice Andreas Beckmann beignet (U) Andreas Metzler enblend-enfuse (U) Andreas Tille anfo (U) biobambam2 (U) camitk (U) iqtree (U) jellyfish (U) libmaus2 (U) wise (U) Andrej Shadura golang-github-containers-toolbox (U) Andrew Lee (李健秋) kwin-effect-xrdesktop xrdesktop Andrew Shadura guessnet Anton Gladky ceres-solver (U) eigen3 (U) vtk6 (U) vtk9 (U) yade (U) Apollon Oikonomopoulos xmobar (U) Arnout Engelen jack-tools (U) Aurelien Jarno freebsd-libs (U) kfreebsd-10 (U) Barry deFreese xnee (U) Barry deFreese xboard (U) Bastian Blank linux (U) Ben Hutchings linux (U) Bernd Zeimetz ceph (U) Birger Schacht foot usbguard Brandon Barnes dolphin-emu (U) Bruno "Fuddl" Kleinert faumachine (U) Camm Maguire xmpi Carles Fernandez gnss-sdr (U) Carsten Schoenert kopano-webapp (U) kopanocore (U) Ceph Packaging Team ceph Changwoo Ryu gnome-hwp-support (U) ChangZhuo Chen (陳昌倬) lunar-date (U) Charles Plessy wise (U) Chiara Marmo freeture (U) Chow Loong Jin zeitgeist-sharp (U) Chris Halls libreoffice (U) Chris Hofstaedtler dnsdist (U) Chris Lamb zoneminder (U) Chris Leishman libcypher-parser libneo4j-client Christian Dreihsig boinc-app-eah-brp (U) Christian T. Steigies gle-graphics (U) luola Christoph Berg wsjtx (U) Christoph Egger clisp (U) fife (U) freebsd-libs (U) kfreebsd-10 (U) Christoph Ender fizmo Christoph Haas zabbix (U) Christoph Martin vdr-plugin-infosatepg (U) Christoph Martin xapp (U) Chrysostomos Nanakos accelio Clint Adams ghc (U) haskell-gi-gio (U) haskell-gi-gtk (U) haskell-hledger-web (U) haskell-hopenpgp-tools (U) haskell-pandoc-citeproc (U) haskell-yesod-bin (U) CrossWire Packaging Team xiphos Cyril Brulebois xfonts-scalable (U) Damien Caliste v-sim (U) Daniel Echeverri guake Daniel Glassey xiphos (U) Daniel Hughes widemargin (U) Daniel Leidert drawxtl (U) Daniel Schaal bino Dave Hibberd wsjtx (U) xnec2c (U) David Nusinow xfonts-scalable (U) David Paleino bist Debian Astro Maintainers gravit Debian Astro Team healpy Debian Astronomy Team freeture Debian Bitcoin Packaging Team cgminer Debian BOINC Maintainers boinc-app-eah-brp Debian Chinese Team lunar-calendar lunar-date Debian Cinnamon Team xapp Debian CLI Applications Team cowbell graphmonkey widemargin xsddiagram yahtzeesharp Debian CLI Libraries Team gtk-sharp2 log4net zeitgeist-sharp Debian Common Lisp Team clisp cmucl Debian D Language Group vibe.d Debian Electronics Team drawtiming irsim klayout Debian FreeIPA Team jss Debian Games Team 0ad dolphin-emu fife freeorion lugaru wesnoth-1.14 wesnoth-1.16 widelands xboard Debian Games Team lix Debian GCC Maintainers gcc-10 gcc-11 gcc-11-cross-mipsen gcc-12 gcc-12-cross-mipsen gcc-9 gcc-9-cross-mipsen Debian GNOME Maintainers endeavour gnome-books gnome-recipes xdg-user-dirs-gtk Debian Go Packaging Team acmetool golang-github-twstrike-gotk3adapter Debian Go Packaging Team cadvisor gitlab-ci-multi-runner (U) golang-github-containers-toolbox Debian Hamradio Maintainers gnss-sdr gr-fcdproplus wsjtx xnec2c Debian Haskell Group darcs ghc haskell-blogliterately haskell-gi-gio haskell-gi-gtk haskell-gi-harfbuzz haskell-hledger-web haskell-hopenpgp-tools haskell-pandoc-citeproc haskell-stack haskell-yesod-bin haskell-yi-frontend-pango xmobar xmonad-contrib xmonad-extras Debian HPC Team libvma Debian Java Maintainers zookeeper Debian KDE Extras Team kmplayer Debian Kernel Team linux Debian Korean L10N gnome-hwp-support Debian LibreOffice Maintainers libreoffice Debian Math Team fplll Debian Med Packaging Team anfo
Bug#1018259: nmu: libidn2_2.3.3-1
Quoting Simon Josefsson (2022-08-29 08:09:59) > I could upload a real version too, maybe that is faster? Can do today unless > someone objects. libidn2 has already been binNMUed by Sebastian Ramacher -- see the other mail to this bug. Thanks! cheers, josch signature.asc Description: signature
Bug#1018259: nmu: libidn2_2.3.3-1
Quoting Cyril Brulebois (2022-08-28 14:20:48) > Johannes Schauer Marin Rodrigues (2022-08-28): > > The current version of libidn2-0 in unstable still wrongly depends on > > sgml-base. A rebuild of src:libidn2 against the version of debhelper > > that is currently in the archive will fix this problem. > > Sure, that's the part I agree with. > > > I added you to CC because you commented on #1015263 saying "This breaks > > d-i builds". The thing that doesn't have a udeb is sgml-base (which you > > pointed out in the same message). > > Let's backpedal a bit, my message had: > > > Judging by the current list of `apt-cache rdepends sgml-base`, this > > problem has already spread quite a bit. > > This breaks d-i builds, (at least) via libnl udebs picking up a > dependency on sgml-base, which doesn't exist in a udeb context. > > There, “this” = buggy sgml-base dependency spreading, which broke d-i > builds *via libnbl udebs* (which was worked around); that wasn't meant > to mean that libidn2 itself was breaking d-i builds. It can't, as it > doesn't build udebs, so it's no factor. > > Hope that clarifies. Ah cool, thanks! Yes, then d-i is not a reason at all to binNMU src:libidn2. The wrong dependency on sgml-base remains as a reason to do it. Thank you! cheers, josch signature.asc Description: signature
Bug#1018259: nmu: libidn2_2.3.3-1
Quoting Cyril Brulebois (2022-08-28 13:18:05) > Johannes Schauer Marin Rodrigues (2022-08-28): > > due to a bug in debhelper (see #1015263) the libidn2-0 package gained a > > wrong dependency on sgml-base. Since there was no upload of libidn2 > > since the bug got fixed in debhelper, the current version on unstable > > still wrongly depends on sgml-base. This breaks di-builds because > > sgml-base doesn't exist in udeb context. This added dependency also > > hurts bootstrapping and breaks our DPKG_ROOT CI. Please rebuilds libidn2 > > with the current debhelper version. > > > > nmu libidn2_2.3.3-1 . ANY . unstable . -m "rebuild with debhelper after > > #1015263 was fixed" > > I'm a little confused. > > d-i builds are all green: > https://d-i.debian.org/daily-images/daily-build-overview.html > > and more importantly, src:libidn2 doesn't build any udeb. > > > Note that I'm not objecting to the rebuild, I'm just not sure the context > is right… libnl3 was building a broken udeb though, for which I uploaded > a workaround: > > https://tracker.debian.org/news/1353402/accepted-libnl3-370-02-source-into-unstable/ The current version of libidn2-0 in unstable still wrongly depends on sgml-base. A rebuild of src:libidn2 against the version of debhelper that is currently in the archive will fix this problem. I added you to CC because you commented on #1015263 saying "This breaks d-i builds". The thing that doesn't have a udeb is sgml-base (which you pointed out in the same message). Thanks! cheers, josch signature.asc Description: signature
Bug#1018259: nmu: libidn2_2.3.3-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: jo...@debian.org, ond...@debian.org, si...@josefsson.org, k...@debian.org Hi, due to a bug in debhelper (see #1015263) the libidn2-0 package gained a wrong dependency on sgml-base. Since there was no upload of libidn2 since the bug got fixed in debhelper, the current version on unstable still wrongly depends on sgml-base. This breaks di-builds because sgml-base doesn't exist in udeb context. This added dependency also hurts bootstrapping and breaks our DPKG_ROOT CI. Please rebuilds libidn2 with the current debhelper version. nmu libidn2_2.3.3-1 . ANY . unstable . -m "rebuild with debhelper after #1015263 was fixed" Thanks! cheers, josch
Bug#994540: transition: imagemagick
Hi Sebastian, Quoting Sebastian Ramacher (2022-07-13 22:52:52) > On 2021-09-29 10:38:07 +0200, jo...@mister-muffin.de wrote: > > > Do all reverse dependencies build fine with the new Imagemagick version? > > > If not, have bugs been filed? > > > > I have rebuilt all 399 source packages that have at least one binary > > produced > > by src:imagemagick in their build dependency installation closure. Of > > those, 16 > > packages FTBFS with the imagemagick version form experimental but succeed > > with > > the version from unstable. Of those, only one package (src:wand) is in the > > list > > from https://release.debian.org/transitions/html/auto-imagemagick.html I > > filed > > this failure as #995290 and will investigate the other 15 instances as well. > > But since those source packages are not part of the transition, they should > > probably not block this bug. > > This transition completly dropped off my radar, sorry! > > What's the current status of the preparations? Have the bugs been filed? we had one build failure in src:wand which I fixed in imagemagick upload of 8:6.9.12.20+dfsg1-1.2 to experimental. See also #995290 Thanks! cheers, josch signature.asc Description: signature
Bug#1003188: bullseye-pu: package mmdebstrap/0.7.5-2.2
Quoting Adam D. Barratt (2022-02-19 19:07:46) > On Wed, 2022-01-05 at 20:28 +0100, Johannes Schauer Marin Rodrigues wrote: > > Currently, when a user happens to have an ASCII armored key in > > /etc/apt/trusted.gpg.d, running mmdebstrap without any special > > options > > will not work. See #1003175 for details. > > > > The problem is fixed in unstable and testing, starting with 0.8.0-1. > 0001-Do-not-use-gpg-trust-model-always isn't mentioned in the > changelog. Is it part of the fix for the issue mentioned above, or a > separate change? I picked both patches directly from upstream git. The patch you mention fixes a bug in the other so they are only useful together. I can merge both patches into one if that's more helpful. Thanks! cheers, josch signature.asc Description: signature
Bug#1003188: bullseye-pu: package mmdebstrap/0.7.5-2.2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: jo...@debian.org
[ Reason ]
Currently, when a user happens to have an ASCII armored key in
/etc/apt/trusted.gpg.d, running mmdebstrap without any special options
will not work. See #1003175 for details.
The problem is fixed in unstable and testing, starting with 0.8.0-1.
[ Impact ]
Users will either have to remove an ASCII armored key from their
/etc/apt/trusted.gpg.d or supply keys to mmdebstrap manually. But either
is unlikely to happen because the error message does not give a clue
about the actual cause of the problem.
[ Tests ]
Me and two users checked that the attached debdiff fixed the
problem. If desired, I can also add a test from the upstream project
to the debdiff but that would double its size. Essentially, the change
is already well tested upstream.
[ Risks ]
In the worst case, GPG key autodetection breaks and one has to pass the
keyring material to mmdebstrap manually. This is what users with ASCII
armored keys in /etc/apt/trusted.gpg.d already have to do today without
this patch.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
GPG is called with --show-keys instead of with --list-keys. The latter
requires "public keyring v4" key material while the former also allows
ASCII armored keys.
[ Other info ]
This is my first upload to a stable release, so stupid mistakes can be
hiding anywhere.
Thanks!
cheers, josch
diff -Nru mmdebstrap-0.7.5/debian/changelog mmdebstrap-0.7.5/debian/changelog
--- mmdebstrap-0.7.5/debian/changelog 2021-05-07 17:30:39.0 +0200
+++ mmdebstrap-0.7.5/debian/changelog 2022-01-05 16:05:13.0 +0100
@@ -1,3 +1,10 @@
+mmdebstrap (0.7.5-2.2+deb11u1) bullseye; urgency=medium
+
+ * Do not error out with ASCII armored keyrings in /etc/apt/trusted.gpg.d
+(closes: #1003175)
+
+ -- Johannes Schauer Marin Rodrigues Wed, 05 Jan 2022
16:05:13 +0100
+
mmdebstrap (0.7.5-2.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru
mmdebstrap-0.7.5/debian/patches/0001-Do-not-use-gpg-trust-model-always.patch
mmdebstrap-0.7.5/debian/patches/0001-Do-not-use-gpg-trust-model-always.patch
---
mmdebstrap-0.7.5/debian/patches/0001-Do-not-use-gpg-trust-model-always.patch
1970-01-01 01:00:00.0 +0100
+++
mmdebstrap-0.7.5/debian/patches/0001-Do-not-use-gpg-trust-model-always.patch
2022-01-05 16:04:09.0 +0100
@@ -0,0 +1,23 @@
+From 91d8be5f9c204f0ee8d524eb1382934e608a9d43 Mon Sep 17 00:00:00 2001
+From: Johannes Schauer Marin Rodrigues
+Date: Thu, 26 Aug 2021 07:58:27 +0200
+Subject: [PATCH] Do not use gpg --trust-model=always
+
+ - gpg will not create a trustdb when running with --update-trustdb with
+ --trust-model=always:
+ gpg: no need for a trustdb update with 'always' trust model
+ - subsequent gpg calls will fail because there is no trustdb in GPGHOME
+---
+ mmdebstrap | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/mmdebstrap
b/mmdebstrap
+@@ -4861,7 +4861,6 @@ sub main() {
+ '--ignore-time-conflict', '--no-options',
+ '--no-default-keyring', '--homedir',
+ $gpghome, '--no-auto-check-trustdb',
+-'--trust-model', 'always'
+ );
+ my ($ret, $message);
+ {
diff -Nru
mmdebstrap-0.7.5/debian/patches/0001-gpg-handle-ASCII-armored-keyrings-as-well.patch
mmdebstrap-0.7.5/debian/patches/0001-gpg-handle-ASCII-armored-keyrings-as-well.patch
---
mmdebstrap-0.7.5/debian/patches/0001-gpg-handle-ASCII-armored-keyrings-as-well.patch
1970-01-01 01:00:00.0 +0100
+++
mmdebstrap-0.7.5/debian/patches/0001-gpg-handle-ASCII-armored-keyrings-as-well.patch
2022-01-05 16:05:13.0 +0100
@@ -0,0 +1,75 @@
+From ccd4b5c163d322045c92f734f43bb5e1945fa774 Mon Sep 17 00:00:00 2001
+From: Konstantin Demin
+Date: Thu, 15 Apr 2021 03:00:39 +0300
+Subject: [PATCH] gpg: handle ASCII-armored keyrings as well
+
+gpg command "--list-keys" requires input files to be passed with
+option "--keyring" and each file must match type "public keyring v4"
+while gpg command "--show-keys" doesn't require extra options and
+handles also ASCII-armored public keyrings as well.
+
+Signed-off-by: Konstantin Demin
+---
+ mmdebstrap | 28 +---
+ 1 file changed, 17 insertions(+), 11 deletions(-)
+
+--- a/mmdebstrap
b/mmdebstrap
+@@ -4880,30 +4880,37 @@ sub main() {
+ . " signed-by value";
+ last;
+ }
++# initialize gpg trustdb with empty one
++{
++
Re: Release status of i386 for Bullseye and long term support for 3 years?
Hi, Quoting Russ Allbery (2020-12-14 23:54:37) > > The point I'm making is that i386 processors are still incredibly common, > > and we shouldn't abandon their users. > > Not abandoning users is a powerful motivating force, but it still has to > succeed in motivating people. Debian can't make a decision on the basis > of not abandoning users. We have to make a decision on the basis that > someone is volunteering to do the work. Perhaps they're volunteering to > do that work so that we're not abandoning users, and that's great, but > that additional step is important. > > I think it's therefore useful in this sort of thread to be very clear > whether your conclusion is "and therefore I am volunteering to do the work > to keep i386 alive" or whether your conclusion is "and therefore I am > asking other people to volunteer to keep i386 alive," and be aware that > the latter may not be successful because volunteer time is a limited > resource and there are many worthy things that we could all be working on > to make the lives of users better. > > If we can confirm that the volunteer resources are there, we can ask what > they need from the rest of the project to be successful. I cannot donate my time (I'm also lacking the skill) but I'm willing to put my money somewhere if it means to keep i386 alive for longer. I privately own perfectly working old hardware that I would hate to send to the landfill just because software support is ending. Should i386 be discontinued I should probably only keep using the hardware in a separate network disconnected from the internet but that would make the hardware much less useful. If somebody could direct me to organizations or people who just need financial support to keep i386 alive, that would be great. In the light of a planet with limited resources, I think it's worth my money to help keeping old hardware around and avoid the waste of resources and energy that manufacturing new equipment incurs. Thanks! cheers, josch signature.asc Description: signature
Re: Optional Build-Depends
Quoting Adrian Bunk (2020-07-18 10:36:11) > On Thu, Jul 16, 2020 at 07:27:52PM +0200, Julian Andres Klode wrote: > >... > > We have came up with a syntax, one goal being to break parsers and not > > silently ignore optional deps: > > > > Build-Depends: foo? (>= 1) | baz > > Any suggestion has to equally cover runtime dependencies, > the same situation is common there. > > [...] > > 1. You can start optionally build-depending on stuff available only on some > >architectures, without having to use arch restriction lists. > > > > Arch restriction lists are tediuous, especially also because in > > the case of libraries, they need to be recursively applied: > > > > libfoo is only available on bar > > libbaz depends on libfoo > > > > results in build-depends: libbaz [bar] > > > > With optional build-depends, you can just write libbaz? and > > not have to update the dep each time libfoo appears on a new > > arch. (apply argument to longer recursive chains) > >... > > It was never necessary to use arch restriction lists for that. > > When several reverse dependencies are affected, the correct solution > for this problem is one package (or Provides) foobaz that selects the package > for an architecture. plus, that solution would also cover runtime dependencies. I do not yet see sufficient evidence that we really need a new syntax element and adjust all the tools involved with parsing Build-Depends. Last time I did that for introducing the build-profile syntax and it wasn't fun at all. See the list of software that needed to be changed here: https://wiki.debian.org/BuildProfileSpec I think you should have a really strong reason before making changes to the syntax. Is there something that cannot be covered by existing mechanisms? Thanks! cheers, josch signature.asc Description: signature
Re: Optional Build-Depends
Hi, Quoting Julian Andres Klode (2020-07-16 19:27:52) > Rationales: > > > 1. You can start optionally build-depending on stuff available >only on some architectures, without having to use arch restriction >lists. > >Arch restriction lists are tediuous, especially also because in >the case of libraries, they need to be recursively applied: > > libfoo is only available on bar > libbaz depends on libfoo > >results in build-depends: libbaz [bar] > >With optional build-depends, you can just write libbaz? and >not have to update the dep each time libfoo appears on a new >arch. (apply argument to longer recursive chains) > > 2. Now I'm not sure if that's a pro or a con, but downstream >distributions could also add optional dependencies on stuff >only they ship. > >It's a question of policy whether optional build-dependencies >on out-of-archive stuff should be allowed or not (e.g. you >could add an optional b-d while sth is in NEW, and do binNMUs >after too) > >I only heard this after talking about the proposal though, >it was not on my mind while creating it ... If (1.) is the main reason for this syntax change, then why not improve the architecture restriction list syntax instead and make it more expressive? And why change the syntax at all? The scenario "package X only exists on a sometimes-changing list of architectures" can also be solved by an arch:any package existing on all architectures that is maintained by the maintainers of X and adjusts its runtime dependencies accordingly when the list of available architectures changes, no? Thanks! cheers, josch signature.asc Description: signature
re: git-buildpackage to be autoremoved due to python2 transition
Quoting peter green (2020-02-27 22:54:19) > > Relevant packages and bugs: > > 943107 git-buildpackage: Python2 removal in sid/bullseye > This bug is not marked as rc. > > Nevertheless I believe that this bug report is in-fact a false positive. From > what I can tell git-buildpackage, even in buster, does not (build-)depend on > python 2 or any python 2 modules. correct, but it does build-depend on packages that require python2: rpm I was recently in a similar situation where I thought I had a false positive for one of my package so I filed this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952523 You can always check whether you got a false positive or not by investing the dependency relationship yourself. In this case: dose-ceve -T grml --deb-builds-from --deb-native-arch=amd64 debsrc://Sources deb://Packages > /tmp/graph.xml botch-graph-shortest-path /tmp/graph.xml /tmp/out.xml --source realpackage:src:git-buildpackage --target realpackage:src:python2.7 Thanks! cheers, josch signature.asc Description: signature
Bug#863335: unblock: vcmi/0.99+dfsg-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package vcmi
The upload fixes a critical (causes dataloss) RC bug #863301 using a
minimal patch supplied by upstream.
Patch between the version of unstable and testing is attached.
unblock vcmi/0.99+dfsg-2
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf
Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru vcmi-0.99+dfsg/debian/changelog vcmi-0.99+dfsg/debian/changelog
--- vcmi-0.99+dfsg/debian/changelog 2016-11-08 13:35:01.0 +0100
+++ vcmi-0.99+dfsg/debian/changelog 2017-05-25 08:12:26.0 +0200
@@ -1,3 +1,10 @@
+vcmi (0.99+dfsg-2) unstable; urgency=medium
+
+ * Add patch from upstream which makes sure that removing a mod cannot
+accidentally recursively delete $HOME (closes: #863301)
+
+ -- Johannes Schauer <jo...@debian.org> Thu, 25 May 2017 08:12:26 +0200
+
vcmi (0.99+dfsg-1) unstable; urgency=medium
* new upstream release
diff -Nru
vcmi-0.99+dfsg/debian/patches/0001-Launcher-add-sanity-checks-for-QDir-removeRecursivel.patch
vcmi-0.99+dfsg/debian/patches/0001-Launcher-add-sanity-checks-for-QDir-removeRecursivel.patch
---
vcmi-0.99+dfsg/debian/patches/0001-Launcher-add-sanity-checks-for-QDir-removeRecursivel.patch
1970-01-01 01:00:00.0 +0100
+++
vcmi-0.99+dfsg/debian/patches/0001-Launcher-add-sanity-checks-for-QDir-removeRecursivel.patch
2017-05-25 08:12:26.0 +0200
@@ -0,0 +1,72 @@
+From 5d8e943787666543df6b858c001ab4e59b09fe2d Mon Sep 17 00:00:00 2001
+From: Arseniy Shestakov <m...@arseniyshestakov.com>
+Date: Thu, 25 May 2017 03:03:02 +0300
+Subject: [PATCH] Launcher: add sanity checks for QDir::removeRecursively.
+ Issue 2673
+
+I'm not always fail to uninstall mod, but when I do I remove $HOME
+Bumblebee developers should be proud of us...
+---
+ launcher/modManager/cmodmanager.cpp | 22 --
+ launcher/modManager/cmodmanager.h | 1 +
+ 2 files changed, 21 insertions(+), 2 deletions(-)
+
+diff --git a/launcher/modManager/cmodmanager.cpp
b/launcher/modManager/cmodmanager.cpp
+index 59fd7faf..99a3df32 100644
+--- a/launcher/modManager/cmodmanager.cpp
b/launcher/modManager/cmodmanager.cpp
+@@ -245,7 +245,7 @@ bool CModManager::doInstallMod(QString modname, QString
archivePath)
+
+ if (!ZipArchive::extract(qstringToPath(archivePath),
qstringToPath(destDir)))
+ {
+- QDir(destDir + modDirName).removeRecursively();
++ removeModDir(destDir + modDirName);
+ return addError(modname, "Failed to extract mod data");
+ }
+
+@@ -270,7 +270,7 @@ bool CModManager::doUninstallMod(QString modname)
+ if (!localMods.contains(modname))
+ return addError(modname, "Data with this mod was not found");
+
+- if (!QDir(modDir).removeRecursively())
++ if (!removeModDir(modDir))
+ return addError(modname, "Failed to delete mod data");
+
+ localMods.remove(modname);
+@@ -279,3 +279,21 @@ bool CModManager::doUninstallMod(QString modname)
+
+ return true;
+ }
++
++bool CModManager::removeModDir(QString path)
++{
++ // issues 2673 and 2680 its why you do not recursively remove without
sanity check
++ QDir checkDir(path);
++ if(!checkDir.cdUp() || QString::compare("Mods", checkDir.dirName(),
Qt::CaseInsensitive))
++ return false;
++ if(!checkDir.cdUp() || QString::compare("vcmi", checkDir.dirName(),
Qt::CaseInsensitive))
++ return false;
++
++ QDir dir(path);
++ if(!dir.absolutePath().contains("vcmi", Qt::CaseInsensitive))
++ return false;
++ if(!dir.absolutePath().contains("Mods", Qt::CaseInsensitive))
++ return false;
++
++ return dir.removeRecursively();
++}
+diff --git a/launcher/modManager/cmodmanager.h
b/launcher/modManager/cmodmanager.h
+index 800db6b5..b759ef06 100644
+--- a/launcher/modManager/cmodmanager.h
b/launcher/modManager/cmodmanager.h
+@@ -18,6 +18,7 @@ class CModManager
+
+ QStringList recentErrors;
+ bool addError(QString modname, QString message);
++ bool removeModDir(QString mod);
+ public:
+ CModManager(CModList * modList);
+
+--
+2.11.0
+
diff -Nru vcmi-0.99+dfsg/debian/patches/series
vcmi-0.99+dfsg/debian/patches/series
--- vcmi-0.99+dfsg/debian/patches/series2016-11-08 13:33:57.0
+0100
+++ vcmi-0.99+dfsg/debian/patches/series2017-05-25 08:12:26.0
+0200
@@ -1,3 +1,4 @@
disable-privacy-breach
minizip_maxu32
fix-spelling
+0001-Launcher-add-sanity-checks-for-QDir-removeRecursivel.patch
Bug#853050: unblock: botch/0.21-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package botch Yesterday, an FTBFS bug against botch was reported: #852917 I fixed the problem and uploaded to unstable. Since it's too late for the 10 day package transition to testing until February 5, I hereby request its unblock. Attached is the patch that fixes the FTBFS bug. It makes botch compatible with changes introduced by a dose3 upload 10 days ago. This is why the problem with botch wasn't spotted earlier. The patch seems long but it only touches the relevant parts. Despite its size I think it's safe because: - buildcheck-more-problems.ml: that file is a copy of a file from dose3 with custom changes which just needed rebasing - bin2src.ml, src2bin.ml: just blacklisted an otherwise auto-generated command line option - doc/man/botch-*.pod: just updates to man pages which are necessary because the test suite checks that the --help output of the respective programs agrees with the man page. The --help output is autogenerated and was influenced by said dose3 upload. - tools/debarch.py: update to support dpkg debtuples. This file is a copy from a test suite I maintain that checks dpkg architecture wildcard matching between dpkg, dose3 and apt on the basis of 17591105 testcases. I thus have reason to believe that its behaviour is correct. Furthermore, the following datapoints: - the package built successfully on all architectures https://buildd.debian.org/status/package.php?p=botch - the package succeeds its autopkgtests https://ci.debian.net/packages/b/botch/unstable/amd64/ - the compile time checks and runtime tests are very extensive (take 40 minutes each on my machine). That the former succeed on all architectures and that the latter succeed on the Debian ci infrastructure give me reason to believe that the patch doesn't break anything important in the package itself. - the package has no reverse dependencies so it cannot break anything anywhere else Lastly, botch is currently blocking the transition of the new dose3 version. Because botch and dose3 are written in OCaml botch depends on the exact version of dose3. Thus, since botch in testing would become uninstallable if dose3 from unstable transitioned, dose3 is currently blocked from transitioning even though its 10 day delay is over. Making a binNMU of botch against the new dose3 version was impossible due to this FTBFS bug. If this patch making botch 0.21-3 become part of testing cannot be accepted, then it makes sense to remove botch from testing so that dose3 can be part of it. unblock botch/0.21-3 diff -Nru botch-0.21/debian/changelog botch-0.21/debian/changelog --- botch-0.21/debian/changelog 2017-01-09 13:16:33.0 +0100 +++ botch-0.21/debian/changelog 2017-01-28 23:32:39.0 +0100 @@ -1,3 +1,10 @@ +botch (0.21-3) unstable; urgency=medium + + * Add patch to fix FTBFS due to API breakage introduced by src:dose3 5.0.1-8 +(closes: #852917) + + -- Johannes Schauer <jo...@debian.org> Sat, 28 Jan 2017 23:32:39 +0100 + botch (0.21-2) unstable; urgency=medium * python3-pygraphviz dropped the file attribute. Thus adapting the code diff -Nru botch-0.21/debian/patches/add-patch-to-fix-ftbfs-due-to-api-breaka botch-0.21/debian/patches/add-patch-to-fix-ftbfs-due-to-api-breaka --- botch-0.21/debian/patches/add-patch-to-fix-ftbfs-due-to-api-breaka 1970-01-01 01:00:00.0 +0100 +++ botch-0.21/debian/patches/add-patch-to-fix-ftbfs-due-to-api-breaka 2017-01-28 22:47:50.0 +0100 @@ -0,0 +1,336 @@ +From: Johannes Schauer <jo...@debian.org> +Date: Sat, 28 Jan 2017 10:26:13 +0100 +X-Dgit-Generated: 0.21-3 e3fbc643e6af55da3b9b547e41d6189a7fed4c7e +Subject: Add patch to fix FTBFS due to API breakage introduced by src:dose3 5.0.1-8 (closes: #852917) + + +--- + +--- botch-0.21.orig/bin2src.ml botch-0.21/bin2src.ml +@@ -49,7 +49,7 @@ module Options = struct + StdOptions.OutputOptions.add_options ~default options;; + + include StdOptions.DistribOptions;; +- let default = List.filter (fun e -> not (List.mem e ["deb-drop-b-d-indep"; "deb-profiles"; "deb-ignore-essential"; "deb-builds-from"])) StdOptions.DistribOptions.default_options in ++ let default = List.filter (fun e -> not (List.mem e ["deb-drop-b-d-indep"; "deb-drop-b-d-arch"; "deb-profiles"; "deb-ignore-essential"; "deb-builds-from"])) StdOptions.DistribOptions.default_options in + StdOptions.DistribOptions.add_debian_options ~default options ;; + end + +--- botch-0.21.orig/buildcheck-more-problems.ml botch-0.21/buildcheck-more-problems.ml +@@ -32,7 +32,7 @@ module Options = struct + let dump = StdOpt.str_option () + let maforeign = StdOpt.store_true () + let includextra = StdOpt.store_true () +- let triplettable = StdOpt.str_option (
Bug#852938: nmu: botch_0.21-2
Hi, Quoting Ralf Treinen (2017-01-28 12:48:08) > nmu botch_0.21-2 . mips mips64el mipsel ppc64el s390x . unstable . -m > "rebuild against dose3 (5.0.1-8)" it might be best to close this bug without taking action. botch was reported as FTBFS today (#852917), so triggering a binNMU right now would only lead to build failures across all arches. Thanks! cheers, josch signature.asc Description: signature
Bug#837469: nmu: dose3_5.0.1-1
Hi, Quoting Emilio Pozuelo Monfort (2016-09-14 00:47:01) > On 11/09/16 22:04, Johannes Schauer wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: binnmu > > > > nmu dose3_5.0.1-1 . ANY . unstable . -m "rebuild for camlzip 1.06-1" > > Can you explain why this is needed? We don't like to blindly binNMU stuff, so > a little explanation is always helpful. When src:dose3 (= 5.0.1-1) was originally built, it was built with src:camlzip (= 1.05-3) in the archive. This means that src:dose3 built libdose3-ocaml with a dependency on the virtual package libzip-ocaml-8wtm6 on amd64 which was provided by libzip-ocaml (= 1.05-3). Building the new src:camlzip release 1.06-1, replaced that libzip-ocaml package by a new version which now provides libzip-ocaml-4m8e9 on amd64. As a result, no package provides libzip-ocaml-8wtm6 anymore and libdose3-ocaml ocaml become uninstallable. You can verify this situation here: https://packages.debian.org/sid/libdose3-ocaml (it says Package not available next to libzip-ocaml-8wtm6) and here: https://qa.debian.org/dose/debcheck/unstable_main/1473742805/packages/libdose3-ocaml.html The situation is analogous on all other architectures than amd64. The situation arises because OCaml packages are statically linked and rebuilding a library requires a rebuild of all its reverse dependencies. I was told in #debian-ocaml that usually Stéphane Glondu would schedule OCaml binNMUs but he hasn't been on IRC for 3 days, so Mehdi Dogguy advised me to ask the release team to schedule the required binNMU of src:dose3. One practical consequence of libdose3-ocaml not being installable right now is, that src:botch is currently bd-uninstallable: https://buildd.debian.org/status/package.php?p=botch Thank you! cheers, josch signature.asc Description: signature
Bug#837469: nmu: dose3_5.0.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu dose3_5.0.1-1 . ANY . unstable . -m "rebuild for camlzip 1.06-1"
Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
Hi, Quoting Anton Gladky (2016-07-09 16:01:21) > is there any progress on this issue? How can we help with it? I have 3 > pending packages, waiting to be built. I created a minimum test case from the data that Aurélien provided and reported it in the upstream bug tracker: https://gforge.inria.fr/tracker/index.php?func=detail=20539_id=4395=13808 I didn't work on a solution yet. Maybe Pietro did? Thanks! cheers, josch signature.asc Description: signature
Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
Hi all, Quoting Ralf Treinen (2016-07-05 15:51:58) > One change I also spotted only very recently is that the --latest option now > takes an integer argument. If you used -latest before you should replace it > by "--latest 1" now. from IRC, the error supposedly was: STDERR: Fatal error in module deb/debcudf.ml: Unable to get real version for libusb-1.0-0-dev:kfreebsd-i386 (20826) All Known versions for this package are (libusb-1.0-0-dev,2:1.0.19) Aurélien told me that they will try to get some data for us to reproduce and analyze the issue. > Cheers from debconf in Cape Town -Ralf. cheers to cape town! josch signature.asc Description: signature
Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
Hi Anton, Quoting Anton Gladky (2016-06-29 07:30:36) > are you planning to upload dose3 to jessie-backports? I would like to ask Ralf to do that because I never did a backport upload and would first have to familiarize myself with all the policies and technicalities for which I currently do not have time right now. Thanks! cheers, josch signature.asc Description: signature
Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
Hi all, Quoting Pietro Abate (2016-06-22 11:44:59) > Hei josh, can you check this branch ? > > dose3.5.0-debian-jessie > > I don't have a vm with debian jessie ready, but I've used an opam > switch that should be close enough to what we ave in jessie. thanks to Pietro we now have a patch that lets dose3 from experimental work in stable. I pushed it to the branch jessie-backports/master of the dose3 packaging git. https://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/dose3.git/commit/?h=jessie-backports/master=e6b2a9b7321cf5639826ef73ff6f668dfc3fdf0d It builds fine inside a Jessie chroot with backports enabled (needed for newer librpm). Thanks! cheers, josch signature.asc Description: signature
Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
Hi all, Quoting Emilio Pozuelo Monfort (2016-06-20 20:52:32) > On 20/06/16 20:17, Anton Gladky wrote: > > Dear release team, > > > > I am not sure, whether I ask the question, using > > the correct address. If I am not right, please redirect > > me. > > > > Two of my packages (liggghts and yade) are waiting to > > be build on build servers due to unsatisfied dependency > > with the following note: > > > > = > > liggghts build-depends on: > > - amd64:libvtk6-dev > > amd64:libvtk6-dev depends on: > > - amd64:python-vtk6 (= 6.3.0+dfsg1-1) > > amd64:python-vtk6 depends on: > > - amd64:python-twisted > > amd64:python-twisted depends on: > > - amd64:python-twisted-core (>= 16.2.0-1) > > amd64:python-twisted-core depends on: > > - amd64:python-openssl > > amd64:python-openssl depends on: > > - amd64:python-cryptography (>= 1.3) > > amd64:python-cryptography depends on missing: > > - amd64:python-cffi-backend-api-min (<= 9729) > > > > = > > > > Can it happen due to some ongoing transitions and I should > > just wait? > > That's not caused by any transition. That's due to missing support for > versioned > provides on dose/stable (the one we run on wanna-build). > > Josch, you told me backporting dose wasn't easy because of ocaml. Can you be a > bit more specific? Does the new dose version depend on a new ocaml compiler? > If > so, would it be easier to cherry-pick this feature? > > If we can't backport this, then maybe we should tell people to not use > versioned > provides until Stretch is released. I just had a look at backporting it. It's not only OCaml, it's also the versions of libextlib-ocaml-dev, libocamlgraph-ocaml-dev and librpm-dev which either have to be backported or dose3 has to be patched. Cherry-picking the feature is quite difficult as well. At least I got now stuck and would need some time to investigate why things fail. Unfortunately, that is time that I don't currently have. Maybe Pietro (in CC) can give some insight? Thanks! cheers, josch signature.asc Description: signature
Re: More trigger cycles
Hi, Quoting Niels Thykier (2015-02-22 09:43:00) I admit I would (also?) have preferred that we did not depend on a missing error check in dpkg. If the automatic check on jenkins.d.n is extended early in the stretch cycle, I suspect we have a pretty good chance at getting most of them done. My major concern right now is that we are still blind to the actual number of remaining issues. We only learn of them by getting occasional upgrade is broken reports - this way, we are never really sure when we have fixed the last one. even with an extension of the automatic check you could not be sure to have caught all issues because any extension on top of the existing checks would only be a heuristic and will thus miss some cases. The fix for this would be to have a declarative way to express those trigger activations which are currently done in maintainer scripts so that it is not needed to try to parse maintainer scripts with a regex. cheers, josch signature.asc Description: signature
Bug#777216: (pre-approval) unblock: sbuild/0.65.0-2
Control: tag -1 patch
Forgot the patch. Now attached.
Description: handle-native-arch-qualifiers-in-build-deps
sbuild turns build dependencies into the dependencies of a dummy binary
package. Since binary package dependencies do not support the :native
architecture qualifier, these have to either be removed during native
compilation or replaced by the build (native) architecture during cross
building
Author: Johannes Schauer j.scha...@email.de
--- sbuild-0.65.0.orig/lib/Sbuild/ResolverBase.pm
+++ sbuild-0.65.0/lib/Sbuild/ResolverBase.pm
@@ -842,6 +842,25 @@ EOF
reduce_profiles = 1,
build_profiles = [ split / /, $self-get('Build Profiles') ]);
+# sbuild turns build dependencies into the dependencies of a dummy binary
+# package. Since binary package dependencies do not support :native the
+# architecture qualifier, these have to either be removed during native
+# compilation or replaced by the build (native) architecture during cross
+# building
+my $handle_native_archqual = sub {
+my ($dep) = @_;
+if ($dep-{archqual} $dep-{archqual} eq native) {
+if ($self-get('Host Arch') eq $self-get('Build Arch')) {
+$dep-{archqual} = undef;
+} else {
+$dep-{archqual} = $self-get('Build Arch');
+}
+}
+return 1;
+};
+deps_iterate($positive, $handle_native_archqual);
+deps_iterate($negative, $handle_native_archqual);
+
$self-log(Merged Build-Depends: $positive\n) if $positive;
$self-log(Merged Build-Conflicts: $negative\n) if $negative;
signature.asc
Description: signature
Bug#777216: (pre-approval) unblock: sbuild/0.65.0-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, we recently found that sbuild is not able to handle source packages using the :native architecture qualifier [1]. Fixing this issue can be done by the minimal attached patch (also found in bug #777204). Since build daemons run stable, not having this functionality in stable would delay the possibility to upload packages with the :native architecture qualifier for another release cycle. Given how small the patch is and the impact for the coming release cycle, would it be possible to grant a unblock for sbuild once the version fixing this issue is in unstable? For evidence that dpkg, apt and dose3 understand this syntax and that the proposed patch works as advertised, please have a look at bug #777204. By doing a test upload of a source package using the :native qualifier we also show how sbuild is the remaining blocker in being able to upload packages with this syntax to unstable. This problem was discussed with wookey in his position as an sbuild maintainer and I'm writing you instead because he's currently busy. Thanks! cheers, josch [1] https://wiki.ubuntu.com/MultiarchCross -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150206121912.3790.30709.reportbug@hoothoot
Re: backport of dpkg (= 1.17.2) and apt (= 0.9.16.1) for build profiles
Hi, Quoting Cyril Brulebois (2014-07-28 16:40:49) diff -Nru apt-0.9.7.9+deb7u2/debian/libapt-pkg4.12.symbols apt-0.9.7.9+deb7u3/debian/libapt-pkg4.12.symbols --- apt-0.9.7.9+deb7u2/debian/libapt-pkg4.12.symbols 2013-03-01 10:51:21.0 + +++ apt-0.9.7.9+deb7u3/debian/libapt-pkg4.12.symbols 2014-07-28 11:32:23.0 + @@ -369,6 +369,7 @@ (c++)debListParser::VersionHash()@Base 0.8.0 (c++)debListParser::Architecture()@Base 0.8.0 (c++)debListParser::ParseDepends(char const*, char const*, std::basic_stringchar, std::char_traitschar, std::allocatorchar , std::basic_stringchar, std::char_traitschar, std::allocatorchar , unsigned int, bool const, bool const)@Base 0.8.0 + (c++)debListParser::ParseDepends(char const*, char const*, std::basic_stringchar, std::char_traitschar, std::allocatorchar , std::basic_stringchar, std::char_traitschar, std::allocatorchar , unsigned int, bool const, bool const, bool const)@Base 0.9.7.9+deb7u2 This is wrong. Why? And how would it be done right? diff -Nru python-apt-0.8.8.2/debian/control python-apt-0.8.8.2+deb7u1/debian/control --- python-apt-0.8.8.2/debian/control 2013-03-13 22:25:59.0 + +++ python-apt-0.8.8.2+deb7u1/debian/control 2014-07-28 11:46:59.0 + @@ -10,7 +10,7 @@ apt-utils, debhelper (= 7.3.5), fakeroot, - libapt-pkg-dev (= 0.8.11), + libapt-pkg-dev (= 0.9.7.9+deb7u3), I'm pretty sure this a bad idea. This happened not so long ago: [12 Jun 2014] DSA-2958 apt - security update Next apt update would mean python-apt is no longer buildable in stable. This is correct. I am not aware of a correct way to express this dependency. I know nothing about python bindings but anyway, it looks like you're not updating doc strings. I can easily update all the necessary doc strings. But it seems that more fundamental questions should be solved first. More importantly, what's the impact in packages using those functions? Were packages identified, their code reviewed, and their features tested? I might lack the necessary understanding but given the changes expressed in the patches I cannot imagine in what way packages depending on apt or python-apt would start failing or having any different functionality besides not failing when faced with the new syntax. For python-apt, none of the exposed python functions gained new arguments and thus no code should break. The only difference now is, that it will be able to understand the new syntax. For libapt-pkg4.12, existing code will be calling ParseDepends in a way which sets ParseRestrictionsList to false and thus should not experience any functionality change at all. To be able to understand the new syntax as well, they'd have to explicitly call ParseDepends with ParseRestrictionsList=true. But this is no change in functionality from the status quo. If you want us to do any additional tests, I'll be glad to carry them out. cheers, josch -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140728161353.4150.65436@hoothoot
Re: backport of dpkg (= 1.17.2) and apt (= 0.9.16.1) for build profiles
Hi, Quoting Cyril Brulebois (2014-07-28 18:38:38) Johannes Schauer j.scha...@email.de (2014-07-28): Quoting Cyril Brulebois (2014-07-28 16:40:49) diff -Nru apt-0.9.7.9+deb7u2/debian/libapt-pkg4.12.symbols apt-0.9.7.9+deb7u3/debian/libapt-pkg4.12.symbols --- apt-0.9.7.9+deb7u2/debian/libapt-pkg4.12.symbols 2013-03-01 10:51:21.0 + +++ apt-0.9.7.9+deb7u3/debian/libapt-pkg4.12.symbols 2014-07-28 11:32:23.0 + @@ -369,6 +369,7 @@ (c++)debListParser::VersionHash()@Base 0.8.0 (c++)debListParser::Architecture()@Base 0.8.0 (c++)debListParser::ParseDepends(char const*, char const*, std::basic_stringchar, std::char_traitschar, std::allocatorchar , std::basic_stringchar, std::char_traitschar, std::allocatorchar , unsigned int, bool const, bool const)@Base 0.8.0 + (c++)debListParser::ParseDepends(char const*, char const*, std::basic_stringchar, std::char_traitschar, std::allocatorchar , std::basic_stringchar, std::char_traitschar, std::allocatorchar , unsigned int, bool const, bool const, bool const)@Base 0.9.7.9+deb7u2 This is wrong. Why? And how would it be done right? Pretty sure 0.9.7.9+deb7u2 doesn't ship the symbol you pretend it does… you are right, I wrongly updated the version when I rebased the patch from the one prepared for backports to the current stable version of apt. But that is trivially fixed. Is there anything else wrong with that line? (Ansgar told you where to look, by the way.) Which message of Ansgar are you referring to? diff -Nru python-apt-0.8.8.2/debian/control python-apt-0.8.8.2+deb7u1/debian/control --- python-apt-0.8.8.2/debian/control 2013-03-13 22:25:59.0 + +++ python-apt-0.8.8.2+deb7u1/debian/control 2014-07-28 11:46:59.0 + @@ -10,7 +10,7 @@ apt-utils, debhelper (= 7.3.5), fakeroot, - libapt-pkg-dev (= 0.8.11), + libapt-pkg-dev (= 0.9.7.9+deb7u3), I'm pretty sure this a bad idea. This happened not so long ago: [12 Jun 2014] DSA-2958 apt - security update Next apt update would mean python-apt is no longer buildable in stable. This is correct. I am not aware of a correct way to express this dependency. Well, as usual, = foo together with bar? My problem with that solution is: than what version? Also, apt starts shipping the proper symbol with version 0.9.16.1 and the only way to retrieve a version before 0.9.16.1 is from snapshot.debian.org. So is a even necessary? If it is, then less than what version? I read this as “no tests have been performed”. Not quite what I'd expect for things as critical as a new apt in stable… We are quite confident that apt, python-apt and dpkg itself work as expected as those were thoroughly tested. As for their reverse dependencies: Of the reverse dependencies of libapt-pkg4.12 only qapt uses the ParseDepends function. But it doesnt do so for parsing source control data so there will be no behaviour change. Of the reverse dependencies of python-apt, ParseSrcDepends is used by none. The rest use ParseDepends which only acts on binary packages and thus does not have a change in functionality. Of the reverse dependencies of libdpkg-perl only libsbuild-perl and xapt make use of the changed deps_parse function. Because they do not pass the reduce_profiles argument they will not be able to parse the new syntax. We did test sbuild but we did not test xapt. What other tests would you like me to run? cheers, josch -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140728181959.4150.26090@hoothoot
Re: backport of dpkg (= 1.17.2) and apt (= 0.9.16.1) for build profiles
Hi, Quoting Philipp Kern (2014-07-24 00:25:41) so I think this would rather be a question for stable, than for backports? Maybe. We'd be equally (if not more) happy if SRM would reconsider their decision (expressed on #debian-release toward Helmut Grohne) that these patches are too intrusive for a stable update. As I understand it, if this backport is in, and packages in the archive can hence be modified to incorporate the new syntax, stable tooling will no longer work with them? That is correct. cheers, josch -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140725121938.4150.24302@hoothoot
Re: A new metric for source package importance in ports
Hi,
Quoting Steven Chamberlain (2013-11-28 01:04:56)
On 27/11/13 17:58, Johannes Schauer wrote:
http://mister-muffin.de/p/Gid8.txt
One can see that now the amount of source packages which is needed to build
the
rest of the archive is only 383.
So, there are 383 packages that share the same, maximum value (in this
case 11657) in the second column?
Correct.
$ curl -s http://mister-muffin.de/p/Gid8.txt | awk '{ if ($2==11657) print $0
}' | wc -l
383
In this particular graph the maximum value of the second column (11657) is less
than the total amount of source packages (in contrast to the first graph)
because this latter graph assumes that arch:all, essential:yes and
build-essential do not have to be rebuild. Therefore, lots of source packages
do not have to be compiled at all.
Does anybody see enough value in these numbers for source package
importance in the light of bootstrapping Debian (either for a new port or
for rebuilding the archive from scratch)?
I find the list of 383 packages interesting, at least. I think this
closure is what I had in mind[0] for regular testing of ports' toolchains and
reproducibility of builds.
In that email you wrote:
Some people have been trying to identify small sets of essential packages
already, in the context of bootstrapping an architecture[1]. I wonder if
that's likely to overlap with this? It encompasses toolchain and essential
arch-specific packages.
I imagine a healthy port should be able to bootstrap itself with only current
package versions. If this was being tested regularly it could let porters
know if circular dependencies are introduced
Yes, if you omit the necessity to rebuild arch:all packages, then these 383
source packages are about what you were talking about: the set of source
packages which makes a port able to bootstrap itself. Though notice that this
number (383) is only the very lower bound because it was deducted using strong
dependencies only. You can see the upper bound in the column that was
calculated using the closure graph which would be 457 source packages.
If you also want to rebuild arch:all packages, then you have to look at the
first graph and then the number quickly climbs to 1194 source packages minimum
and 1424 source packages maximum.
Does the list vary by architecture? I see many odd things in here such as
'systemd' and 'redhat-cluster' which would be unavailable if trying to
bootstrap a non-Linux port, for example.
Yes it does vary by architecture because dependencies can have architecture
qualifiers. Here, I used amd64 as an example.
I also find it interesting to see openjdk-7 listed but not gcj; or even
gcc-4.8. Was this computed for jessie or sid?
Using Debian Sid as of yesterday.
cheers, josch
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131128080012.2752.32993@hoothoot
Re: A new metric for source package importance in ports
Hi, Quoting Dmitrijs Ledkovs (2013-11-28 01:15:06) On 28 November 2013 00:04, Steven Chamberlain ste...@pyro.eu.org wrote: I also find it interesting to see openjdk-7 listed but not gcj; or even gcc-4.8. Was this computed for jessie or sid? I guess implicit relationships are not considered: build-essential build-dependencies, and essential dependencies. I would expect for packages in those to sets have the highest rank, since, hypothetically, all packages in debian build-depend depend on those. Steven was looking at the second graph which (in contrast to the first graph) makes the assumption that essential:yes and build-essential are already available somehow (for example by having cross compiled them) and thus do not need to be recompiled to bootstrap the port. gcj and gcc-4.8 is part of the packages which are drawn in by creating a co-installation set of essential:yes and build-essential packages. Therefore they do not appear in the second graph. Since this co-installation set is an input to the algorithm of creating the second graph, they implicitly receive the highest rank. For the same reason you will also see them being assigned the highest rank in the first graph which does not assume that essential:yes and build-essential do not have to be recompiled. Implicit dependency relationships are considered by both algorithms to calculate the strong dependencies and the dependency closure of source and binary packages. My code uses dose3 to do the required calculations. cheers, josch -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131128080700.2752.98455@hoothoot
A new metric for source package importance in ports
Hi, the following is a report of a successful implementation of what I have been talking about with Niels Thykier during debconf13. The question was how important it is for a source package to be compilable or exist in the first place given an incomplete port which is in the process of being bootstrapped. This work is solving a different purpose than the identification of key packages by Lucas Nussbaum [1]. Instead of attaching a binary value to each source package, this method is associating integer values to them. Once bootstrapping of the whole archive becomes more important or even possible in real life through an implementation of build profiles, this heuristic could be used to further extend the meaning of key packages as well. This heuristic attaches to each source package A the number of source packages which need A to be compilable so that they become compilable themselves. The dependency graph which is needed to extract this information is conveniently created by the service I run as http://bootstrap.debian.net - I'm using a simple Python script to walk this graph to extract the information. In fact that Python script uses two different graphs. Since dependencies contain disjunctions, there exists different choices for packages which have to be available for something to be compilable or installable. To not make this choice arbitrary, I calculate the minimum number of dependencies that have to be available (strong dependencies) and the maximum number that has to be available (dependency closure). Therefore each source package A is associated with two numbers: the minimum amount of source packages which depend on A being compilable and the maximum number of source packages which depend on A being compilable. To create more than syntactic meaning I also added popcon information to the output. I associate to each source package A the sum of all popcon values of the source packages which depend on A being compilable. Again this is done for the minimum as well as the maximum. So here is the (tab delimetered) data in no particular order: http://mister-muffin.de/p/pVxb.txt 1st column: the name of the source package 2nd column: minimum number of source packages which need this source pacage to be compilable 3rd column: maximum number of source packages which need this source pacage to be compilable 4th column: minimum sum of popcon values 5th column: maximum sum of popcon values Do you see any obvious error? When sorting the data by the second column, you will see that there are 1194 source packages with the same value: 19554. This value corresponds to the total amount of source packages. It means: everything else depends on these 1194 source packages being compilable. If those 1194 source package are not compilable then the rest will be neither. Remember that this only true during a bootstrappping scenario. These 1194 source package are also all part of the same strongly connected component of the strong srcgraph and roughly correlate to the smallest set of packages which are needed for a self-hosting Debian system. We call a set of binary and source packages self-hosting if all binary packages can be created from the source packages and all source packages can be compiled with just the available binary packages. In my opinion it would make sense to make all packages which are at minimum required to make Debian self-hosted to the set of key packages by extending the definition by Lucas Nussbaum at [1]. The amount of source packages which are needed to bootstrap themselves and all the rest of Debian is that high because it includes source packages which are only included because of the arch:all binary packages they build, because of the essential:yes packages they build or because of the build-essential packages they build. While it is important to include these for rebuilds of the whole archive, they are not important in a real bootstrap situation. Arch:all binary packages already exist and do not need to be bootstrapped and to start to compile packages natively, a minimal build system (essential:yes + build-essential) is required in the first place. Therefore I created a different graph which takes into account that arch:all packages as well as the packages of the minimal build system do not need to be rebuild: http://mister-muffin.de/p/Gid8.txt One can see that now the amount of source packages which is needed to build the rest of the archive is only 383. It is important that these source packages remain compilable (in addition to essential:yes + build-essential being cross-able) because otherwise a bootstrap of any new architecture cannot be done. The service at http://bootstrap.debian.net will indicate that an architecture is not bootstrappable at all if this is the case. Does anybody see enough value in these numbers for source package importance in the light of bootstrapping Debian (either for a new port or for rebuilding the archive from scratch)? If so, then I can generate these
Re: A new metric for source package importance in ports
Hi, Quoting peter green (2013-11-28 01:12:57) One problem with these metrics is that you get source packages whose importance is artifically inflated because of the way our source packages work. If anything in a source package needs x then the whole source package has to build-depend on x. Even if x is only needed for some perhipheral functionlity that could easilly be removed in the event that x was unavailable (either on a particular port or in general). In the case of libraries there may be a binary dependency too for rarely used fuctionality. For example some of the mesa libraries drag in libwayland0 which means wayland ends up with a very high importance even though afaict hardly anyone uses it right now. Another big example is languages. Lots of packages build language bindings for lots of languages dragging those languages into the important set. So these metrics are a good guide to what packages are unimportant but to determine whether a package is really important or just psuedo-important still requires human judgement. Correct. The situation can be greatly improved once build profiles allow to mark build dependencies as less important or non essential. cheers, josch -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131128074506.2752.10616@hoothoot
Re: Candidates for removal from testing (2013-06-30)
Hi, Quoting Lucas Nussbaum (2013-07-01 08:21:30) Currently, the following criterias are used: | Key packages are: | - packages whose popcon is higher than 5% of the max popcon (that's | 7570 insts currently) | OR | - packages of priority = standard | OR | - packages of section debian-installer | OR | - debian-installer, debian-cd, piuparts | OR | - build-dependencies of key packages [binary dependencies are covered | by the popcon criteria] How are dependency disjunctions in direct or indirect build dependencies handled? Which package is selected if a key package Build-Depends: A | B? And are you only talking about direct build dependencies or also indirect build dependencies? In the latter case, the amount of possible choices (installation sets) becomes even higher. cheers, josch -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130701130056.14706.49386@hoothoot
