Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Guillem Jover]

Hi!

JFYI, I released dupload 2.11.0 with support for the mentioned
transitions check hook. Have not received any complaints (yet? :).

On Sun, 2024-01-14 at 22:06:46 +0100, Guillem Jover wrote:
> On Sun, 2024-01-14 at 19:35:40 +0100, Guillem Jover wrote:
> > Perfect, thanks. I've force pushed the new changes to the previous
> > branch. How about then the following output?
> > 
> > ,---
> > Warning: Source package barnowl is part of ongoing transitions:
> > 
> >   auto-perl perl-5.38
> > 
> 
> Was wondering now whether it would be better to linkify the list of
> transitions, such as:
> 
> ,---
> Warning: Source package barnowl is part of ongoing transitions:
> 
>   <https://release.debian.org/transitions/html/auto-perl>
>   <https://release.debian.org/transitions/html/perl-5.38>
> 
> […]
> `---
> 
> Although that seems a bit more noisy, but provides more context. I'm
> not sure though how stable those URLs should be considered to be.

In the end went with full URLs, like above.

> > If the upload does not solve issues caused by these transitions, then it
> > might disrupt them by adding delays or entangling them. For more 
> > information,
> > please read:
> > 
> >   <https://wiki.debian.org/Teams/ReleaseTeam/TransitionUploadHook>
> > 
> > Note: If you are aware of this and do not want to be warned, you can disable
> > this hook from the config file, set the one-off environment variable
> > DUPLOAD_SKIP_TRANSITION_CHECK=1, or alternatively you can reply to the
> > following prompt.
> 
> (I think I'll be adding some generic way to skip specific hooks,
> because this is a common pattern among them, something like
> --skip-hooks=a,b and DUPLOAD_SKIP_HOOKS=a,b.)

I implemented this too.

Thanks,
Guillem

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Guillem Jover]

Hi!

On Sun, 2024-01-14 at 19:35:40 +0100, Guillem Jover wrote:
> Perfect, thanks. I've force pushed the new changes to the previous
> branch. How about then the following output?
> 
> ,---
> Warning: Source package barnowl is part of ongoing transitions:
> 
>   auto-perl perl-5.38
> 

Was wondering now whether it would be better to linkify the list of
transitions, such as:

,---
Warning: Source package barnowl is part of ongoing transitions:

  <https://release.debian.org/transitions/html/auto-perl>
  <https://release.debian.org/transitions/html/perl-5.38>

[…]
`---

Although that seems a bit more noisy, but provides more context. I'm
not sure though how stable those URLs should be considered to be.

> If the upload does not solve issues caused by these transitions, then it
> might disrupt them by adding delays or entangling them. For more information,
> please read:
> 
>   <https://wiki.debian.org/Teams/ReleaseTeam/TransitionUploadHook>
> 
> Note: If you are aware of this and do not want to be warned, you can disable
> this hook from the config file, set the one-off environment variable
> DUPLOAD_SKIP_TRANSITION_CHECK=1, or alternatively you can reply to the
> following prompt.
> 

(I think I'll be adding some generic way to skip specific hooks,
because this is a common pattern among them, something like
--skip-hooks=a,b and DUPLOAD_SKIP_HOOKS=a,b.)

> Continue anyway? (yes/NO) 
> Ok, aborting the upload.
> 
> `---

Thanks,
Guillem

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Guillem Jover]

Hi!

On Sun, 2024-01-14 at 19:12:03 +0100, Paul Gevers wrote:
> On 14-01-2024 18:46, Guillem Jover wrote:
> > I think that would be great, I guess the message from the hook could
> > give some very basic and generic guidance, and point to this page for
> > more in-depth explanation of what to do, what else to check etc. But in
> > any case an initial version sounds good, as that can always be tuned,
> > or extended/improved later on. :)
> 
> Initial version. Please consider the name too, moving now is easier than
> later:
> https://wiki.debian.org/Teams/ReleaseTeam/TransitionUploadHook

Perfect, thanks. I've force pushed the new changes to the previous
branch. How about then the following output?

,---
Warning: Source package barnowl is part of ongoing transitions:

  auto-perl perl-5.38

If the upload does not solve issues caused by these transitions, then it
might disrupt them by adding delays or entangling them. For more information,
please read:

  <https://wiki.debian.org/Teams/ReleaseTeam/TransitionUploadHook>

Note: If you are aware of this and do not want to be warned, you can disable
this hook from the config file, set the one-off environment variable
DUPLOAD_SKIP_TRANSITION_CHECK=1, or alternatively you can reply to the
following prompt.

Continue anyway? (yes/NO) 
Ok, aborting the upload.

`---

Thanks,
Guillem

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Guillem Jover]

Hi!

On Sun, 2024-01-14 at 18:22:16 +0100, Paul Gevers wrote:
> On 14-01-2024 17:43, Guillem Jover wrote:
> >https://wiki.debian.org/Teams/ReleaseTeam/Transitions
> > 
> > but it looks like that one is targeted more to maintainers that start
> > or drive the transitions instead of someone that might upload a
> > package which is part or affected by that transition?
> 
> Indeed. I had the same idea when I replied earlier, but I think we'd need a
> new (wiki) page for this. If we happen to agree here, I'm fine with creating
> an initial version.

I think that would be great, I guess the message from the hook could
give some very basic and generic guidance, and point to this page for
more in-depth explanation of what to do, what else to check etc. But in
any case an initial version sounds good, as that can always be tuned,
or extended/improved later on. :)

Thanks,
Guillem

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Guillem Jover]

Hi!

On Sun, 2024-01-14 at 10:22:21 +0100, Paul Gevers wrote:
> On 10-01-2024 02:23, Guillem Jover wrote:
> > I've had for a while a new hook for dupload that adds a transitions
> > check for Debian hosts, for sourceful uploads targeting unstable (to
> > avoid disrupting buildd or porter uploads, or uninteresting suites).
> > I've just finished polishing it, and the main lingering question I've
> > had all along has been whether you think this would actually be useful
> > and/or desired at all, see below.
> > 
> > The hook is currently using
> > https://release.debian.org/transitions/export/packages.yaml, and
> > prompting in case that source package is part of any ongoing
> > transition.
> 
> Cool.
> 
> > I wondered also whether checking
> > https://ftp-master.debian.org/transitions.yaml would be useful,
> > but I'm not sure whether that is or has ever been used?
> 
> It still works, but it's hardly used. I do have some vague ideas to use it
> again in the future, but that's not going to happen soon I guess.

Ok, then, I might leave this as a comment reference as a potential
future source in case this ever gets used.

> > So I guess my questions would be whether you think this is helpful or
> > useful at all?
> 
> Yes, I do.

Ok, great! :)

> > If so, whether the criteria is adequate or it needs to
> > be changed? Whether this should be a prompt, or maybe only an info or
> > warning? And any other comment or suggestion you might have!
> 
> I'm mostly wondering if the information shown is enough to help people. I'm
> actually surprised how many people don't know how transitions work. What is
> your opinion on the length of the text you could provide? Maybe a link to a
> wiki page with more info particularly for this case?

Ah, right, having a longer description and an external reference would
actually be in line with other similar notices such as:

  https://git.dpkg.org/cgit/dpkg/dupload.git/tree/hooks/debian-source-only#n73
  https://git.dpkg.org/cgit/dpkg/dupload.git/tree/hooks/debian-security-auth#n23

If you have some proposed wording, I'll gladly incorporate that,
otherwise I'll try to come up with something and post it here for
review, with a reference to at least:

  https://release.debian.org/transitions/

and perhaps to:

  https://wiki.debian.org/Teams/ReleaseTeam/Transitions

but it looks like that one is targeted more to maintainers that start
or drive the transitions instead of someone that might upload a
package which is part or affected by that transition?

> Maybe Sebastian can comment on how often he sees interfering uploads to
> judge if it should be a warning or a prompt. If you make this only a
> warning, what are the options of the uploader, canceling?

Hmm, right, just a warning would probably not be very helpful, and if
it gets a pause (with no prompt) then in effect that's kind of a prompt
anyway as you can always Ctrl-C or similar. So probably a prompt might
be the best option, but it's not clear whether that will end up being
very annoying. Probably it would need some easy way to disarm it, say
an env var or similar, instead of requiring to change the config.

> PS: if you're happy with this, should we file wish list bugs against dput
> and dput-ng too?

I think that would be nice, once the above details are more clear. :)

Thanks,
Guillem

Bug#1060367: release.debian.org: RFC: Transitions check for dupload?

[Guillem Jover]

Package: release.debian.org
Severity: wishlist

Hi!

I've had for a while a new hook for dupload that adds a transitions
check for Debian hosts, for sourceful uploads targeting unstable (to
avoid disrupting buildd or porter uploads, or uninteresting suites).
I've just finished polishing it, and the main lingering question I've
had all along has been whether you think this would actually be useful
and/or desired at all, see below.

The hook is currently using
https://release.debian.org/transitions/export/packages.yaml, and
prompting in case that source package is part of any ongoing
transition. I wondered also whether checking
https://ftp-master.debian.org/transitions.yaml would be useful,
but I'm not sure whether that is or has ever been used?

You can see the commit at
.

For a package currently under transitions such as dart, the hook
output and interaction could be right now:

,---
Source dart is part of ongoing transitions:
  auto-tinyxml2 boost1.83
Continue anyway? (yes/NO)
Ok, aborting upload.
`---

So I guess my questions would be whether you think this is helpful or
useful at all? If so, whether the criteria is adequate or it needs to
be changed? Whether this should be a prompt, or maybe only an info or
warning? And any other comment or suggestion you might have!

Thanks,
Guillem

Re: Bug#1059395: libacl1, debhelper: changelog handling with --no-trim seems to be not binNMU-safe

[Guillem Jover]

Control: reassign -1 debhelper
Control: found -1 debhelper/13.11.4

On Sun, 2023-12-24 at 14:27:22 +, Simon McVittie wrote:
> Package: libacl1,debhelper
> Control: found -1 libacl1/2.3.1-3
> Control: found -1 debhelper/13.11.9
> Severity: important
> X-Debbugs-Cc: debian-release@lists.debian.org

> I notice that libacl1 uses dh_installchangelogs --no-trim in its
> debian/rules to suppress the default exclusion of older changelog
> entries. It appears that using that option also suppresses the separation
> of binNMU changelog entries into a separate file? I think it probably
> should not, because the trimming of old changelog entries is merely
> a nice-to-have to save some disk space, but the separation of binNMU
> changelog entries is functionally necessary if we want packages to remain
> multiarch co-installable across binNMUs.

Yes, I don't see why the old behavior, when requested explicitly,
would no longer behave as previously. This would seem like a regression
in debhelper due to the trimming handling.

> A sourceful upload of libacl1 would temporarily address this (until the
> next binNMU) by not being a binNMU, but would not be a long-term solution,
> unless we stop using binNMUs entirely and replace them with "no-changes"
> machine-assisted sourceful uploads like Ubuntu has done.

I've uploaded acl now with some minor pending changes I had queued as
a temporary workaround. But the obvious and correct way forward to me
is to fix debhelper (instead of having to change all affected packages,
or having to stop using binNMUs due to this…).

And I've just tested this and it also affects the current debhelper
version in Debian (stable) bookworm. :/

Thanks,
Guillem

Bug#1051902: bullseye-pu: package dpkg/1.20.13

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: d...@packages.debian.org
Control: affects -1 + src:dpkg

Hi!

[ Reason ]

This update backports the loong64 arch support as requested in #1051763
because some of the Debian infra is still using bullseye. There's also
a fix for a segfault on virtual field formatting which is rather easy
to trigger for packages that are known to dpkg, but are not installed,
such as virtual packages or references from Recommends or Suggests,
which was also included in the 1.21.22 pre-approval request included
in bookworm. And finally a fix for a memory leak, included in 1.22.0
in unstable.

[ Impact ]

- If the loong64 arch is not supported in oldstable, packages and
  infra will not be able to add support for it.
- Easy to trigger segfault.
- Memory leak.

[ Tests ]

The arch addition and the segfault fix have tests. The memory leak
was detected by gcc ASAN, but it is trivial to verify. These pass
all dpkg unit test and functional tests, which are part of its release
process.

[ Risks ]

As part of the segfault backport, I also cherry-picked a minor
refactoring change that was required by another commit adding unit
tests for the module involved (which is required by the first
cherry-pick), but that should give better test coverage.

The two other changes seem rather low risk.

[ Checklist ]

  [√] *all* changes are documented in the d/changelog
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in (old)stable
  [√] the issue is verified as fixed in unstable

[ Changes ]

The git log is included in the debdiff, which I'm attaching in its full
compressed form with no filtering applied, but you might want to
filterdiff with:

  xzcat dpkg-1.20.12-1.20.13.debdiff.xz |
filterdiff --exclude '*.po' --exclude '*.pot' \
   --exclude '*/man/*/*.pod' \
   --exclude '*/testsuite' --exclude '*/t-func/*.m4' \
   --exclude '*/Makefile.in' \
   --exclude '*/configure'

Thanks,
Guillem


dpkg-1.20.12-1.20.13.debdiff.xz
Description: application/xz

Bug#1050332: bullseye-pu: package inetutils/2:2.0-1+deb11u2

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: inetut...@packages.debian.org, t...@security.debian.org
Control: affects -1 + src:inetutils

Hi!

[ Reason ]

This update fixes a minor security issue, that the security team did
not feel worth a DSA. It is now fixed already in unstable and testing.

[ Impact ]

It could lead to security issues.

[ Tests ]

The only relevant part of the patch is the one involving ftpd, which
still works as expected after the patch.

[ Risks ]

The risks seem minimal, as it is only adding checks for the return
codes of the set*id() functions.

[ Checklist ]

  [√] *all* changes are documented in the d/changelog
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in (old)stable
  [√] the issue is verified as fixed in unstable

[ Changes ]

  * Add patch from upstream to check return values for set*id() functions.
Fixes CVE-2023-40303. (Closes: #1049365)

Thanks,
Guillem
diff -Nru inetutils-2.0/debian/changelog inetutils-2.0/debian/changelog
--- inetutils-2.0/debian/changelog  2022-08-30 13:34:41.0 +0200
+++ inetutils-2.0/debian/changelog  2023-08-23 12:05:48.0 +0200
@@ -1,3 +1,10 @@
+inetutils (2:2.0-1+deb11u2) bullseye; urgency=medium
+
+  * Add patch from upstream to check return values for set*id() functions.
+Fixes CVE-2023-40303. (Closes: #1049365)
+
+ -- Guillem Jover   Wed, 23 Aug 2023 12:05:48 +0200
+
 inetutils (2:2.0-1+deb11u1) bullseye; urgency=medium
 
   * telnet: Add checks for option reply parsing limits causing buffer
diff -Nru 
inetutils-2.0/debian/patches/0002-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-check-set-id-retu.patch
 
inetutils-2.0/debian/patches/0002-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-check-set-id-retu.patch
--- 
inetutils-2.0/debian/patches/0002-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-check-set-id-retu.patch
1970-01-01 01:00:00.0 +0100
+++ 
inetutils-2.0/debian/patches/0002-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-check-set-id-retu.patch
2023-08-23 12:05:48.0 +0200
@@ -0,0 +1,283 @@
+From 8dd3c8bae7f95fc096bd36efdf62cc33250074dc Mon Sep 17 00:00:00 2001
+From: Jeffrey Bencteux 
+Date: Fri, 30 Jun 2023 19:02:45 +0200
+Subject: [PATCH 2/2] ftpd,rcp,rlogin,rsh,rshd,uucpd: fix: check set*id()
+ return values
+
+Several setuid(), setgid(), seteuid() and setguid() return values
+were not checked in ftpd/rcp/rlogin/rsh/rshd/uucpd code potentially
+leading to potential security issues.
+
+Signed-off-by: Jeffrey Bencteux 
+Signed-off-by: Simon Josefsson 
+Fixes: CVE-2023-40303
+Closes: #1049365
+Forwarded: not-needed
+Origin: upstream, commit:e4e65c03f4c11292a3e40ef72ca3f194c8bffdd6
+---
+ ftpd/ftpd.c  | 10 +++---
+ src/rcp.c| 39 +--
+ src/rlogin.c | 11 +--
+ src/rsh.c| 25 +
+ src/rshd.c   | 20 +---
+ src/uucpd.c  | 15 +--
+ 6 files changed, 100 insertions(+), 20 deletions(-)
+
+diff --git a/ftpd/ftpd.c b/ftpd/ftpd.c
+index 92b2cca5..28dd523f 100644
+--- a/ftpd/ftpd.c
 b/ftpd/ftpd.c
+@@ -862,7 +862,9 @@ end_login (struct credentials *pcred)
+   char *remotehost = pcred->remotehost;
+   int atype = pcred->auth_type;
+ 
+-  seteuid ((uid_t) 0);
++  if (seteuid ((uid_t) 0) == -1)
++_exit (EXIT_FAILURE);
++
+   if (pcred->logged_in)
+ {
+   logwtmp_keep_open (ttyline, "", "");
+@@ -1151,7 +1153,8 @@ getdatasock (const char *mode)
+ 
+   if (data >= 0)
+ return fdopen (data, mode);
+-  seteuid ((uid_t) 0);
++  if (seteuid ((uid_t) 0) == -1)
++_exit (EXIT_FAILURE);
+   s = socket (ctrl_addr.ss_family, SOCK_STREAM, 0);
+   if (s < 0)
+ goto bad;
+@@ -1978,7 +1981,8 @@ passive (int epsv, int af)
+   else/* !AF_INET6 */
+ ((struct sockaddr_in *) _addr)->sin_port = 0;
+ 
+-  seteuid ((uid_t) 0);
++  if (seteuid ((uid_t) 0) == -1)
++_exit (EXIT_FAILURE);
+   if (bind (pdata, (struct sockaddr *) _addr, pasv_addrlen) < 0)
+ {
+   if (seteuid ((uid_t) cred.uid))
+diff --git a/src/rcp.c b/src/rcp.c
+index 75adb253..cdcf8500 100644
+--- a/src/rcp.c
 b/src/rcp.c
+@@ -345,14 +345,23 @@ main (int argc, char *argv[])
+   if (from_option)
+ { /* Follow "protocol", send data. */
+   response ();
+-  setuid (userid);
++
++  if (setuid (userid) == -1)
++  {
++error (EXIT_FAILURE, 0, "Could not drop privileges (setuid() 
failed)");
++  }
++
+   source (argc, argv);
+   exit (errs);
+ }
+ 
+   if (to_option)
+ { /* Receive data. */
+-  setuid (userid);
++  if (setuid (userid) == -1)
++  {
++error (EXIT_FAILURE, 0, "Could not drop privileges (setuid() 
failed)");
++  }
++
+   sink (argc, argv);
+   exit (errs);
+ }
+@@ -537,7 +546,11 @@ toremote

Bug#1050331: bookworm-pu: package inetutils/2:2.4-2+deb12u1

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: inetut...@packages.debian.org, t...@security.debian.org
Control: affects -1 + src:inetutils

Hi!

[ Reason ]

This update fixes a minor security issue, that the security team did
not feel worth a DSA. It is now fixed already in unstable and testing.

[ Impact ]

It could lead to security issues.

[ Tests ]

The only relevant part of the patch is the one involving ftpd, which
still works as expected after the patch.

[ Risks ]

The risks seem minimal, as it is only adding checks for the return
codes of the set*id() functions.

[ Checklist ]

  [√] *all* changes are documented in the d/changelog
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in (old)stable
  [√] the issue is verified as fixed in unstable

[ Changes ]

  * Add patch from upstream to check return values for set*id() functions.
Fixes CVE-2023-40303. (Closes: #1049365)

Thanks,
Guillem
diff -Nru inetutils-2.4/debian/changelog inetutils-2.4/debian/changelog
--- inetutils-2.4/debian/changelog  2023-01-18 00:23:52.0 +0100
+++ inetutils-2.4/debian/changelog  2023-08-23 12:01:39.0 +0200
@@ -1,3 +1,10 @@
+inetutils (2:2.4-2+deb12u1) bookworm; urgency=medium
+
+  * Add patch from upstream to check return values for set*id() functions.
+Fixes CVE-2023-40303. (Closes: #1049365)
+
+ -- Guillem Jover   Wed, 23 Aug 2023 12:01:39 +0200
+
 inetutils (2:2.4-2) unstable; urgency=medium
 
   * Add support for new RFC4443 ICMPv6 destination unreachable codes.
diff -Nru 
inetutils-2.4/debian/patches/0002-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-check-set-id-retu.patch
 
inetutils-2.4/debian/patches/0002-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-check-set-id-retu.patch
--- 
inetutils-2.4/debian/patches/0002-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-check-set-id-retu.patch
1970-01-01 01:00:00.0 +0100
+++ 
inetutils-2.4/debian/patches/0002-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-check-set-id-retu.patch
2023-08-23 12:01:39.0 +0200
@@ -0,0 +1,283 @@
+From 8dd3c8bae7f95fc096bd36efdf62cc33250074dc Mon Sep 17 00:00:00 2001
+From: Jeffrey Bencteux 
+Date: Fri, 30 Jun 2023 19:02:45 +0200
+Subject: [PATCH 2/2] ftpd,rcp,rlogin,rsh,rshd,uucpd: fix: check set*id()
+ return values
+
+Several setuid(), setgid(), seteuid() and setguid() return values
+were not checked in ftpd/rcp/rlogin/rsh/rshd/uucpd code potentially
+leading to potential security issues.
+
+Signed-off-by: Jeffrey Bencteux 
+Signed-off-by: Simon Josefsson 
+Fixes: CVE-2023-40303
+Closes: #1049365
+Forwarded: not-needed
+Origin: upstream, commit:e4e65c03f4c11292a3e40ef72ca3f194c8bffdd6
+---
+ ftpd/ftpd.c  | 10 +++---
+ src/rcp.c| 39 +--
+ src/rlogin.c | 11 +--
+ src/rsh.c| 25 +
+ src/rshd.c   | 20 +---
+ src/uucpd.c  | 15 +--
+ 6 files changed, 100 insertions(+), 20 deletions(-)
+
+diff --git a/ftpd/ftpd.c b/ftpd/ftpd.c
+index 92b2cca5..28dd523f 100644
+--- a/ftpd/ftpd.c
 b/ftpd/ftpd.c
+@@ -862,7 +862,9 @@ end_login (struct credentials *pcred)
+   char *remotehost = pcred->remotehost;
+   int atype = pcred->auth_type;
+ 
+-  seteuid ((uid_t) 0);
++  if (seteuid ((uid_t) 0) == -1)
++_exit (EXIT_FAILURE);
++
+   if (pcred->logged_in)
+ {
+   logwtmp_keep_open (ttyline, "", "");
+@@ -1151,7 +1153,8 @@ getdatasock (const char *mode)
+ 
+   if (data >= 0)
+ return fdopen (data, mode);
+-  seteuid ((uid_t) 0);
++  if (seteuid ((uid_t) 0) == -1)
++_exit (EXIT_FAILURE);
+   s = socket (ctrl_addr.ss_family, SOCK_STREAM, 0);
+   if (s < 0)
+ goto bad;
+@@ -1978,7 +1981,8 @@ passive (int epsv, int af)
+   else/* !AF_INET6 */
+ ((struct sockaddr_in *) _addr)->sin_port = 0;
+ 
+-  seteuid ((uid_t) 0);
++  if (seteuid ((uid_t) 0) == -1)
++_exit (EXIT_FAILURE);
+   if (bind (pdata, (struct sockaddr *) _addr, pasv_addrlen) < 0)
+ {
+   if (seteuid ((uid_t) cred.uid))
+diff --git a/src/rcp.c b/src/rcp.c
+index 75adb253..cdcf8500 100644
+--- a/src/rcp.c
 b/src/rcp.c
+@@ -345,14 +345,23 @@ main (int argc, char *argv[])
+   if (from_option)
+ { /* Follow "protocol", send data. */
+   response ();
+-  setuid (userid);
++
++  if (setuid (userid) == -1)
++  {
++error (EXIT_FAILURE, 0, "Could not drop privileges (setuid() 
failed)");
++  }
++
+   source (argc, argv);
+   exit (errs);
+ }
+ 
+   if (to_option)
+ { /* Receive data. */
+-  setuid (userid);
++  if (setuid (userid) == -1)
++  {
++error (EXIT_FAILURE, 0, "Could not drop privileges (setuid() 
failed)");
++  }
++
+   sink (argc, argv);
+   exit (errs);
+ }
+@@ -537,7 +546,11 @@ toremote (char *targ, int argc

Bug#1035911: [pre-approval] unblock: dpkg/1.21.22

[Guillem Jover]

Control: tags -1 - moreinfo

Hi!

On Wed, 2023-05-17 at 04:24:06 +0200, Guillem Jover wrote:
> Control: tags -1 moreinfo

Oops, missed the «-», but then that seems fine :), as earlier today I
noticed that a triggered autopkgtest for another package had failed,
so retriggered it as it looked like a transient issue, and it then
passed, so it should be actually good now.

Thanks,
Guillem

Bug#1035911: [pre-approval] unblock: dpkg/1.21.22

[Guillem Jover]

Control: tags -1 moreinfo

Hi!

On Tue, 2023-05-16 at 23:44:29 +0200, Sebastian Ramacher wrote:
> Control: tags -1 moreinfo confirmed
> 
> On 2023-05-11 04:45:47 +0200, Guillem Jover wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: d...@packages.debian.org
> > Control: affects -1 + src:dpkg

> > Please pre-approve the dpkg 1.21.22 upload.
> 
> Please go ahead and remove the moreinfo tag once the upload is available
> in unstable.

Thanks! It's been uploaded and built on all release architectures, if
it's not yet in unstable it should be in the next dinstall run.

Thanks,
Guillem

Bug#1035911: [pre-approval] unblock: dpkg/1.21.22

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: d...@packages.debian.org
Control: affects -1 + src:dpkg

Hi!

Please pre-approve the dpkg 1.21.22 upload.

[ Reason ]

I got a report for a segfault privately (as the reporter was unsure
whether this constituted a security issue, which IMO it does not),
which is rather easy to trigger for packages that are known to dpkg,
but are not installed, such as virtual packages or references from
Recommends or Suggests.

I've also cherry picked a translation addition that was already in git
HEAD (targeting 1.22.x).

[ Impact ]

An easy to trigger segfault, which also affects dpkg 1.20.x (for which
I'll be preparing a stable release request).

[ Tests ]

The test suite has been updated to cover this case. And it's also easy
to reproduce with dpkg-query, for example on a minimal chroot, with:

  $ dpkg-query -f '${source:Upstream-Version}\n' -W firefox-esr
  Segmentation fault (core dumped)

[ Risks ]

The fix is trivial, so the risk seems low to me.

[ Checklist ]

  [√] all changes are documented in the d/changelog
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in testing

[ Other info ]

(I had in mind also including an addition for the riscv32 port, but
given that there's no consensus among the porters about its ABI or
even its mere existence, and time is running out, I'll postpone that,
and might include it instead in a future stable release if necessary.)

Attached the unfiltered debdiff, you might want to filterdiff with:

  xzcat dpkg-1.21.21-1.21.22.debdiff.xz |
filterdiff --exclude '*.po' --exclude '*.pot' \
   --exclude '*/man/*/*.pod' \
   --exclude '*/testsuite' --exclude '*/at/*.m4' \
   --exclude '*/configure'

unblock dpkg/1.21.22

Thanks,
Guillem


dpkg-1.21.21-1.21.22.debdiff.xz
Description: application/xz

Bug#1035709: unblock: pci.ids/0.0~2023.04.11-1

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pci@packages.debian.org
Control: affects -1 + src:pci.ids

Please unblock package pci.ids

[ Reason ]

This is a data-only package that provides known PCI IDs and their
descriptions, which helps with hardware enablement.

[ Impact ]

Hardware that was previously unknown would now be known to the system
and packages using this database.

[ Tests ]

The package provides an autopkgtest that verifies the format of the
database. I've skimmed over the ID changes.

[ Risks ]

I'd say very minimal.

[ Checklist ]

  [√] all changes are documented in the d/changelog
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in testing

[ Other info ]

None

unblock pci.ids/0.0~2023.04.11-1

Thanks,
Guillem
diff -Nru pci.ids-0.0~2023.03.17/debian/changelog 
pci.ids-0.0~2023.04.11/debian/changelog
--- pci.ids-0.0~2023.03.17/debian/changelog 2023-03-22 23:56:31.0 
+0100
+++ pci.ids-0.0~2023.04.11/debian/changelog 2023-05-07 02:10:00.0 
+0200
@@ -1,3 +1,10 @@
+pci.ids (0.0~2023.04.11-1) unstable; urgency=medium
+
+  * New upstream release.
+- Remove patch, fixed upstream.
+
+ -- Guillem Jover   Sun, 07 May 2023 02:10:00 +0200
+
 pci.ids (0.0~2023.03.17-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru pci.ids-0.0~2023.03.17/debian/patches/0001-Fix-encoding-issues.patch 
pci.ids-0.0~2023.04.11/debian/patches/0001-Fix-encoding-issues.patch
--- pci.ids-0.0~2023.03.17/debian/patches/0001-Fix-encoding-issues.patch
2023-03-22 23:51:29.0 +0100
+++ pci.ids-0.0~2023.04.11/debian/patches/0001-Fix-encoding-issues.patch
1970-01-01 01:00:00.0 +0100
@@ -1,138 +0,0 @@
-From ccfee565280cabd66b63dafea8b0aff2b896630d Mon Sep 17 00:00:00 2001
-From: Guillem Jover 
-Date: Tue, 4 Oct 2022 04:40:23 +0200
-Origin: vendor
-Forwarded: pci-adm...@ucw.cz
-Subject: [PATCH] Fix encoding issues
-
-These characters got reencoded as iso8859-1 into utf-8.

- pci.ids |   40 
- 1 file changed, 20 insertions(+), 20 deletions(-)
-
 a/pci.ids
-+++ b/pci.ids
-@@ -2752,7 +2752,7 @@
- # FX-797A-TNBC
-   1682 3213  HD 7970 Black Edition
-   1682 3214  Double D HD 7970
--  1787 201c  HD 7970 IceQ X²
-+  1787 201c  HD 7970 IceQ X²
- # Radeon HD 7970 X2
-   1787 2317  Radeon HD 7990
-   1787 3000  Tahiti XT2 [Radeon HD 7970 GHz Edition]
-@@ -2815,7 +2815,7 @@
-   174b e282  Vapor-X R9 290X Tri-X OC
-   174b e285  R9 290X Tri-X OC
-   174b e324  Grenada XT2 [Radeon R9 390X]
--  1787 2020  R9 290X IceQ X² Turbo
-+  1787 2020  R9 290X IceQ X² Turbo
-   1787 2357  Grenada XT [Radeon R9 390X]
-   67b1  Hawaii PRO [Radeon R9 290/390]
-   1043 04dd  STRIX R9 390
-@@ -3707,7 +3707,7 @@
-   1002 0322  All-in-Wonder X1800XL
-   1002 0d02  Radeon X1800 CrossFire Edition
-   710a  R520 [Radeon X1800 GTO]
--  1002 0b12  Radeon X1800 GTO²
-+  1002 0b12  Radeon X1800 GTO²
-   710b  R520 [Radeon X1800 GTO]
-   710e  R520 GL [FireGL V7300]
-   13cc 3d0c  MXRT-5150
-@@ -7499,7 +7499,7 @@
-   1077 02f2  QLogic 1x32Gb QLE2770 FC HBA
-   1077 02f3  QLogic 2x32Gb QLE2772 FC HBA
-   1590 02d3  SN1610Q - 1P Enhanced 32GFC Single Port Fibre 
Channel Host Bus Adapter
--  1590 02d4  SN1610Q – 2P Enhanced 32GFC Dual Port Fibre 
Channel Host Bus Adapter
-+  1590 02d4  SN1610Q - 2P Enhanced 32GFC Dual Port Fibre Channel 
Host Bus Adapter
-   2289  ISP2852-based 64/32G Fibre Channel to PCIe Controller with 
StorCryption
-   1077 02e9  QLE2882 Dual Port 64GFC PCIe Gen4 x8 Adapter with 
StorCryption
-   1077 02eb  QLE2782 Dual Port 32GFC PCIe Gen4 x8 Adapter with 
StorCryption
-@@ -13233,7 +13233,7 @@
-   10ec 8739  Dell Wireless 1801
-   17aa b736  Z50-75
-   b822  RTL8822BE 802.11a/b/g/n/ac WiFi adapter
--  103c 831b  Realtek RTL8822BE 802.11ac 2 × 2 Wi-Fi + Bluetooth 
4.2 Combo Adapter (MU-MIMO supported)
-+  103c 831b  Realtek RTL8822BE 802.11ac 2x2 Wi-Fi + Bluetooth 4.2 
Combo Adapter (MU-MIMO supported)
-   17aa 5124  ThinkPad E595
-   17aa b023  ThinkPad E595
-   c821  RTL8821CE 802.11ac PCIe Wireless Network Adapter
-@@ -21338,10 +21338,10 @@
-   193d 1084  NIC-ETH540F-3S-2P
-   1016  MT27710 Family [ConnectX-4 Lx Virtual Function]
-   1017  MT27800 Family [ConnectX-5]
--  15b3 0006  ConnectX®-5 EN network interface card, 100GbE 
single-port QSFP28, PCIe3.0 x16, tall bracket; MCX515A-CCAT
--  15b3 0007  Mellanox ConnectX®-5 MCX516A-CCAT
--  15b3 0020

Bug#1035683: bullseye-pu: package libbsd/0.11.3-1+deb11u1

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: lib...@packages.debian.org
Control: affects -1 + src:libbsd

Hi!

[ Reason ]

The libbsd library used to provide MD5 implementations, but those got
split into their own libmd library, and the code removed and switched
to be wrappers to use the libmd implementations to preserve the ABI.
The wrapping for one of those functions was not implemented properly
and that caused the symbol to call itself instead of redirecting to
the libmd symbol, which results in an infinite loop. This got later
inadvertently fixed when the wrapping method was changed, so it never
got noticed as a stable candidate, until now. (So this does not affect
neither earlier versions, nor later ones in other Debian releases.)

[ Impact ]

Any program that might have been linked against old libbsd versions
and uses this symbol from libbsd (instead of using the libmd ones
directly) can end up in this infinite loop, spinning CPU.

[ Tests ]

This is currently not part of the test suite, as these functions are
wrappers over the ones in libmd, and deprecated in favor of direct use
of the symbols in libmd. And while the fix seems obviously correct,
I've done the following to make sure, just in case:

  ,---
  $ cat test.c
  #include 
  #include 
  int main() {
char digest[MD5_DIGEST_STRING_LENGTH + 1];
MD5File("test.c", digest);
printf("md5sum %s\n", digest);
return 0;
  }
  $ gcc test.c -lbsd -o test
  $ timeout 2 ./test
  $ echo $?
  124
  $ sudo dpkg -i libbsd0_0.11.3-1+deb11u1_amd64.deb
  $ timeout 2 ./test
  md5sum e75d8ce892d0ed5fb1aa2d39242f156c
  $ md5sum test.c
  e75d8ce892d0ed5fb1aa2d39242f156c  test.c
  `---

[ Risks ]

Seems like low risk to me

[ Checklist ]

  [√] *all* changes are documented in the d/changelog
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in (old)stable
  [√] the issue is verified as fixed in unstable

[ Changes ]

Adds a patch making the MD5File() function call the libmd MD5File()
one instead of calling itself.

Attached the debdiff for the update I've prepared.

Thanks,
Guillem
diff -Nru libbsd-0.11.3/debian/changelog libbsd-0.11.3/debian/changelog
--- libbsd-0.11.3/debian/changelog  2021-02-09 06:36:23.0 +0100
+++ libbsd-0.11.3/debian/changelog  2023-05-07 19:13:23.0 +0200
@@ -1,3 +1,11 @@
+libbsd (0.11.3-1+deb11u1) bullseye; urgency=medium
+
+  * Fix infinite loop when using MD5File() symbol due to missing symbol
+redirection. Thanks to Guillaume Morin .
+Closes: #1033671
+
+ -- Guillem Jover   Sun, 07 May 2023 19:13:23 +0200
+
 libbsd (0.11.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
libbsd-0.11.3/debian/patches/Fix-infinite-loop-on-MD5File-symbol-use.patch 
libbsd-0.11.3/debian/patches/Fix-infinite-loop-on-MD5File-symbol-use.patch
--- libbsd-0.11.3/debian/patches/Fix-infinite-loop-on-MD5File-symbol-use.patch  
1970-01-01 01:00:00.0 +0100
+++ libbsd-0.11.3/debian/patches/Fix-infinite-loop-on-MD5File-symbol-use.patch  
2023-05-07 19:13:23.0 +0200
@@ -0,0 +1,22 @@
+Author: Guillem Jover 
+Description: The MD5File() symbol is calling itself causing an infinite loop.
+ This was caused by an omission when switching to use the symbol redirects,
+ which was not applied for this symbol, but was subsequently fixed w/o notice
+ when the redirection method was changed, so this was not spotted as a stable
+ candidate fix.
+Origin: upstream, commit:e7cf8c5785b14fc8fbd37bb665a5f9a4f28c7888
+Bug-Debian: https://bugs.debian.org/1033671
+Forwarded: not-needed
+Last-Update: 2023-05-07
+
+--- a/src/md5.c
 b/src/md5.c
+@@ -105,7 +105,7 @@
+ MD5File(const char *filename, char *buf)
+ {
+   libmd_wrapper(MD5File);
+-  return MD5File(filename, buf);
++  return libmd_MD5File(filename, buf);
+ }
+ 
+ char *
diff -Nru libbsd-0.11.3/debian/patches/series 
libbsd-0.11.3/debian/patches/series
--- libbsd-0.11.3/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ libbsd-0.11.3/debian/patches/series 2023-05-07 19:13:23.0 +0200
@@ -0,0 +1 @@
+Fix-infinite-loop-on-MD5File-symbol-use.patch

Bug#1034157: unblock: pci.ids/0.0~2023.03.17-1

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pci@packages.debian.org
Control: affects -1 + src:pci.ids

Please unblock package pci.ids

[ Reason ]

This is a data-only package that provides know PCI IDs and their
descriptions, which helps with hardware enablement. (I've been meaning
to send similar requests for stable, but as I've not don that before I
was a bit hesitant, but depending on the outcome of this one, I might
start proposing those too.)

[ Impact ]

Hardware that was previously unknown would now be known to the system
and packages using this database.

[ Tests ]

The package provides an autopkgtest that verifies the format of the
database.

[ Risks ]

I'd say very minimal.

[ Checklist ]

  [√] all changes are documented in the d/changelog
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in testing

[ Other info ]

None.

unblock pci.ids/0.0~2023.03.17-1

Thanks,
Guillem
diff -Nru pci.ids-0.0~2023.02.23/debian/changelog 
pci.ids-0.0~2023.03.17/debian/changelog
--- pci.ids-0.0~2023.02.23/debian/changelog 2023-02-26 23:31:06.0 
+0100
+++ pci.ids-0.0~2023.03.17/debian/changelog 2023-03-22 23:56:31.0 
+0100
@@ -1,3 +1,10 @@
+pci.ids (0.0~2023.03.17-1) unstable; urgency=medium
+
+  * New upstream release.
+- Refresh patch.
+
+ -- Guillem Jover   Wed, 22 Mar 2023 23:56:31 +0100
+
 pci.ids (0.0~2023.02.23-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru pci.ids-0.0~2023.02.23/debian/patches/0001-Fix-encoding-issues.patch 
pci.ids-0.0~2023.03.17/debian/patches/0001-Fix-encoding-issues.patch
--- pci.ids-0.0~2023.02.23/debian/patches/0001-Fix-encoding-issues.patch
2023-02-26 23:30:31.0 +0100
+++ pci.ids-0.0~2023.03.17/debian/patches/0001-Fix-encoding-issues.patch
2023-03-22 23:51:29.0 +0100
@@ -12,7 +12,7 @@
 
 --- a/pci.ids
 +++ b/pci.ids
-@@ -2749,7 +2749,7 @@
+@@ -2752,7 +2752,7 @@
  # FX-797A-TNBC
1682 3213  HD 7970 Black Edition
1682 3214  Double D HD 7970
@@ -21,7 +21,7 @@
  # Radeon HD 7970 X2
1787 2317  Radeon HD 7990
1787 3000  Tahiti XT2 [Radeon HD 7970 GHz Edition]
-@@ -2812,7 +2812,7 @@
+@@ -2815,7 +2815,7 @@
174b e282  Vapor-X R9 290X Tri-X OC
174b e285  R9 290X Tri-X OC
174b e324  Grenada XT2 [Radeon R9 390X]
@@ -30,7 +30,7 @@
1787 2357  Grenada XT [Radeon R9 390X]
67b1  Hawaii PRO [Radeon R9 290/390]
1043 04dd  STRIX R9 390
-@@ -3703,7 +3703,7 @@
+@@ -3707,7 +3707,7 @@
1002 0322  All-in-Wonder X1800XL
1002 0d02  Radeon X1800 CrossFire Edition
710a  R520 [Radeon X1800 GTO]
@@ -39,7 +39,7 @@
710b  R520 [Radeon X1800 GTO]
710e  R520 GL [FireGL V7300]
13cc 3d0c  MXRT-5150
-@@ -7495,7 +7495,7 @@
+@@ -7499,7 +7499,7 @@
1077 02f2  QLogic 1x32Gb QLE2770 FC HBA
1077 02f3  QLogic 2x32Gb QLE2772 FC HBA
1590 02d3  SN1610Q - 1P Enhanced 32GFC Single Port Fibre 
Channel Host Bus Adapter
@@ -48,7 +48,7 @@
2289  ISP2852-based 64/32G Fibre Channel to PCIe Controller with 
StorCryption
1077 02e9  QLE2882 Dual Port 64GFC PCIe Gen4 x8 Adapter with 
StorCryption
1077 02eb  QLE2782 Dual Port 32GFC PCIe Gen4 x8 Adapter with 
StorCryption
-@@ -13227,7 +13227,7 @@
+@@ -13233,7 +13233,7 @@
10ec 8739  Dell Wireless 1801
17aa b736  Z50-75
b822  RTL8822BE 802.11a/b/g/n/ac WiFi adapter
@@ -57,7 +57,7 @@
17aa 5124  ThinkPad E595
17aa b023  ThinkPad E595
c821  RTL8821CE 802.11ac PCIe Wireless Network Adapter
-@@ -21323,10 +21323,10 @@
+@@ -21338,10 +21338,10 @@
193d 1084  NIC-ETH540F-3S-2P
1016  MT27710 Family [ConnectX-4 Lx Virtual Function]
1017  MT27800 Family [ConnectX-5]
@@ -72,7 +72,7 @@
193d 1051  NIC-IB1040i-Mb-2P
1018  MT27800 Family [ConnectX-5 Virtual Function]
1019  MT28800 Family [ConnectX-5 Ex]
-@@ -21522,7 +21522,7 @@
+@@ -21540,7 +21540,7 @@
  15cd  Dreamtech Co Ltd
  15ce  Genrad Inc
  # https://www.hilscher.com/imprint/
@@ -81,7 +81,7 @@
  CIFX PCI/PCIe
  15d1  Infineon Technologies AG
  15d2  FIC (First International Computer Inc)
-@@ -21993,14 +21993,14 @@
+@@ -22013,14 +22013,14 @@
002e  AR9287 Wireless Network Adapter (PCI-Express)
105b e034  T77H167.00
0030  AR93xx Wireless Network Adapter
@@ -98,7 +98,7 @@
105b e044  Unex DHXA-225
144d 410e  AR9485WB-EG 802.11b/g/n mini-PCIe card on a series 3 
laptop
1a3b 1186  AW-NE186H
-@@ -25410,13 +25410,13 @@
+@@ -25434,13 +25434,13 @@
1203  NVMe SSD Controller UHXXXa series
1e81 a121  NVMe SSD UHXXXa

Bug#1033067: unblock: glide/2002.04.10ds1-21

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: gl...@packages.debian.org
Control: affects -1 + src:glide

Please unblock package glide

[ Reason ]

This non-key package does not currently contain autopkgtests.

These two releases include a couple of changes to make the package
finally reproducible, as the generated shared libraries would change
the optimized objects being linked to depending on the build system
(for host=i386 build=amd64).

[ Impact ]

Same generated objects regardless of the build system being used.

[ Tests ]

The tests were performed locally in an amd64 host and an i386 chroot,
before and after the fixes, and the reproducible builds are now green
for i386 for this package.

[ Risks ]

The risks seem minimal, as this is just making sure the build always
behaves in the same way.

[ Checklist ]

  [√] all changes are documented in the d/changelog
(There is the grammar fix in the changelog itself, which I do not
 tend to mention explicitly as it seems unnecessary verbiage.)
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in testing

[ Other info ]

(nothing)


unblock glide/2002.04.10ds1-21

Thanks,
Guillem
diff -Nru glide-2002.04.10ds1/debian/changelog 
glide-2002.04.10ds1/debian/changelog
--- glide-2002.04.10ds1/debian/changelog2023-02-26 23:15:35.0 
+0100
+++ glide-2002.04.10ds1/debian/changelog2023-03-10 02:37:51.0 
+0100
@@ -1,6 +1,20 @@
+glide (2002.04.10ds1-21) unstable; urgency=medium
+
+  * Pass --build and --host to configure via chores.3dfx.
+
+ -- Guillem Jover   Fri, 10 Mar 2023 02:37:51 +0100
+
+glide (2002.04.10ds1-20) unstable; urgency=medium
+
+  * Use autoconf $host_cpu instead of «uname -m» to decide how to optimize
+and what to compile into the resulting objects, which was making the
+build unreproducible on i386 when built on an amd64 build system.
+
+ -- Guillem Jover   Sat, 04 Mar 2023 13:24:56 +0100
+
 glide (2002.04.10ds1-19) unstable; urgency=medium
 
-  * Enable LFS build options. This should ABI safe as the shared library
+  * Enable LFS build options. This should be ABI safe as the shared library
 does not expose any problematic type.
   * Actually show the debconf error when the target is not a symlink.
 
diff -Nru glide-2002.04.10ds1/debian/patches/no-uname.patch 
glide-2002.04.10ds1/debian/patches/no-uname.patch
--- glide-2002.04.10ds1/debian/patches/no-uname.patch   1970-01-01 
01:00:00.0 +0100
+++ glide-2002.04.10ds1/debian/patches/no-uname.patch   2023-03-04 
13:38:57.0 +0100
@@ -0,0 +1,30 @@
+Description: Use autoconf $host_cpu instead of «uname -m»
+ This was making the build unreproducible as the uname will return the build
+ system CPU and not the host one.
+Author: Guillem Jover 
+Origin: vendor
+Forwarded: no
+
+---
+ glide3x/configure.in |3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/glide3x/configure.in
 b/glide3x/configure.in
+@@ -142,6 +142,7 @@ AM_CONDITIONAL(FX_GLIDE_CVG, test x$FX_G
+ #
+ # Architecture
+ #
++AC_CANONICAL_HOST
+ AC_ARG_ENABLE([build-architecture],
+   [dnl
+   --enable-build-architecture Enable AMD 3DNow instructions 
[default=current]],
+@@ -152,7 +153,7 @@ AC_ARG_ENABLE([build-architecture],
+*)
+AC_MSG_ERROR([Illegal value (${enableval}) for 
--enable-build-architecture])
+;;
+-   esac],[FX_GLIDE_BUILD_ARCHITECTURE=`uname -m`])
++   esac],[FX_GLIDE_BUILD_ARCHITECTURE=$host_cpu])
+ AC_SUBST(FX_GLIDE_BUILD_ARCHITECTURE)
+ #
+ # Various tests needed at points in the build
diff -Nru glide-2002.04.10ds1/debian/patches/series 
glide-2002.04.10ds1/debian/patches/series
--- glide-2002.04.10ds1/debian/patches/series   2022-07-17 18:28:36.0 
+0200
+++ glide-2002.04.10ds1/debian/patches/series   2023-03-04 13:16:21.0 
+0100
@@ -36,3 +36,4 @@
 z12-local-libtool
 z13-install-perms
 no-x11.patch
+no-uname.patch
diff -Nru glide-2002.04.10ds1/debian/rules glide-2002.04.10ds1/debian/rules
--- glide-2002.04.10ds1/debian/rules2023-02-25 15:42:22.0 +0100
+++ glide-2002.04.10ds1/debian/rules2023-03-10 01:34:56.0 +0100
@@ -10,6 +10,12 @@
 
 include /usr/share/dpkg/default.mk
 
+ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE))
+  confflags += --build=$(DEB_HOST_GNU_TYPE)
+else
+  confflags += --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
+endif
+
 ifeq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
 ifeq ($(DEB_HOST_ARCH),alpha)
   CFLAGS += -mcpu=ev5 -fomit-frame-pointer \
@@ -32,6 +38,7 @@
   cd $(CURDIR)/glide3x; \
   mkdir $(CURDIR)/debian/tmp.$(1); \
   ./chores.3dfx --generate "--configure=--enable-fx-glide-hw=$(1) \
+$(confflags) \
 --prefix=/usr" --build-dir=build.$(1); \
   cd build.$(1); \
   ./build.3dfx --no-x DESTDIR="$(CURDIR)/debian/tmp.$(1)/" \

Bug#1026199: release.debian.org: Is the toolchain list updated for bookworm

[Guillem Jover]

Hi!

On Wed, 2023-01-25 at 09:47:59 +0100, Guillem Jover wrote:
> Ah, was wondering the same few days before the toolchain freeze, as I
> was unsure whether to update some of the packages I maintain (in
> particular libmd, for which I was thinking of doing a new upstream
> release), and was also checking hints for explicit blocks. See below…

Could we get an answer to the below question? I'm currently uncertain
how to proceed with libmd as I have pending to do an upstream release
with targeted fixes, and have several packaging fixes too. And
depending on the answer below I'd either discard one or both, and
request or not a pre-approval unblock, or forget about it. I've also
just pondered simply requesting a pre-approval unblock, given that to
me libmd seems clearly to be in the essential-set now, but… :)

(I don't greatly mind the answer, say "yes, they should be but because
they were not included we will include them on the next freeze", or "yes,
they should be considered", or "no, they are not", or anything else, I'm
more interested on knowing how to proceed to get this off the back of
my head. :)

> > I just refreshed the list, it's still there. I used a script on udd,
> > essentially this:
> > 
> > essentials = {'build-essential'}
> > 
> > def add_sql_packages(con, essentials, query):
> > cur = con.cursor()
> > 
> > cur.execute(query)
> > items = cur.fetchall()
> > cur.close()
> > 
> > for item in items:
> > if item[0] is not None:
> > no_alt = re.sub(alternatives, "", item[0])
> > no_ver = re.sub(version, "", no_alt)
> > 
> > for x in no_ver.split(','):
> > essentials.add(re.sub(multiarch, "", x.strip()))
> > 
> > query = "SELECT DISTINCT package FROM packages WHERE release = 'bookworm'
> > and essential = 'yes'"
> > 
> > add_sql_packages(con, essentials, query)
> > 
> > done = False
> > while not done:
> > ess_org = copy.copy(essentials)
> > query = """SELECT DISTINCT depends FROM packages WHERE release =
> > 'bookworm' and
> > package in ('%s')""" % "','".join(essentials)
> > add_sql_packages(con, essentials, query)
> > if essentials == ess_org:
> > done = True
> 
> …but hmm, is this perhaps not taking into account Pre-Depends?

Thanks,
Guillem

Bug#1031910: [pre-approval] unblock: dpkg/1.21.21

[Guillem Jover]

Hi!

On Sat, 2023-02-25 at 13:32:55 +0100, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> 
> On 2023-02-25 04:57:58 +0100, Guillem Jover wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: d...@packages.debian.org
> > Control: affects -1 + src:dpkg

> > Please pre-approve the dpkg 1.21.21 upload.
> > 
> > [ Reason ]
> > 
> > The loong64 arch support got reverted as there was a bug filed
> > requesting to change its GNU triplet and multiarch tuple after this
> > had been agreed on previously. Clarification was requested and as that
> > was blocking the previous pre-approval, it was decided that the best
> > would be to temporarily revert it until and if things had been cleared
> > out. Upstream now has decided to go back to the previous triplets and
> > tuples (what was already in dpkg), so this reverts that revert.
> > 
> > There are also a couple of translation updates included. One was a
> > fix for an issue that made the CI checks fail that slipped in due
> > to a release script deficiency, the other is a translation update
> > received after the last upload.
> > 
> > [ Impact ]
> > 
> > Not including this means the port cannot easily be added into the
> > infra as it requires for the stable dpkg to support it. And its
> > addition would end up being requested as part of a stable update
> > (as has happened with other ports in the past).
> 
> Please go ahead.

Great, thanks, just uploaded it.

Regards,
Guillem

Bug#1031910: [pre-approval] unblock: dpkg/1.21.21

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: d...@packages.debian.org
Control: affects -1 + src:dpkg

Hi!

Please pre-approve the dpkg 1.21.21 upload.

[ Reason ]

The loong64 arch support got reverted as there was a bug filed
requesting to change its GNU triplet and multiarch tuple after this
had been agreed on previously. Clarification was requested and as that
was blocking the previous pre-approval, it was decided that the best
would be to temporarily revert it until and if things had been cleared
out. Upstream now has decided to go back to the previous triplets and
tuples (what was already in dpkg), so this reverts that revert.

There are also a couple of translation updates included. One was a
fix for an issue that made the CI checks fail that slipped in due
to a release script deficiency, the other is a translation update
received after the last upload.

[ Impact ]

Not including this means the port cannot easily be added into the
infra as it requires for the stable dpkg to support it. And its
addition would end up being requested as part of a stable update
(as has happened with other ports in the past).

[ Tests ]

The arch change already had tests, and it's in any case a data file
change.

[ Risks ]

Very minimal, and the change has already been part of several dpkg
releases before it got reverted.

[ Checklist ]

  [√] all changes are documented in the d/changelog
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in testing

[ Other info ]

Attached the unfiltered debdiff, you might want to filterdiff with:

  xzcat dpkg-1.21.20-1.21.21.debdiff.xz |
filterdiff --exclude '*.po' --exclude '*.pot' \
   --exclude '*/man/*/*.pod' \
   --exclude '*/testsuite' --exclude '*/at/*.m4' \
   --exclude '*/configure'

unblock dpkg/1.21.21

Thanks,
Guillem


dpkg-1.21.20-1.21.21.debdiff.xz
Description: application/xz

Bug#1030672: [pre-approval] unblock: dpkg/1.21.20

[Guillem Jover]

Hi!

On Tue, 2023-02-07 at 09:01:44 +0100, Emilio Pozuelo Monfort wrote:
> On 06/02/2023 12:43, Guillem Jover wrote:
> > Please pre-approve the dpkg 1.21.20 upload.

> Please go ahead. Late translations are also OK to include.

Thanks! Uploaded it yesterday.

Regards,
Guillem

Bug#1030672: [pre-approval] unblock: dpkg/1.21.20

[Guillem Jover]

On Mon, 2023-02-06 at 19:18:41 +0100, Guillem Jover wrote:
> On Mon, 2023-02-06 at 12:43:37 +0100, Guillem Jover wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: d...@packages.debian.org
> > Control: affects -1 + src:dpkg
> 
> > Please pre-approve the dpkg 1.21.20 upload.
> > 
> > [ Reason ]
> > 
> > This dpkg release includes the translation updates for the recent Call
> > for Translations, a few test suite fixes to make them pass again due
> > to these translations and a recent cppcheck upload in unstable. A typo
> > fix in the man pages. Updates to the lintian overrides. And fixes a
> > typo in the Build-Depends that made the version too low.
> > 
> > [ Impact ]
> > 
> > These would give better translation coverage, the rest are not
> > relevant to the final user, but can affect CI systems and downstream
> > users, as they are build/test system fixes.
> > 
> > [ Tests ]
> > 
> > The various test suite fixes are due to the test suite failing now.
> > The Build-Depends fix should be self-evident and would otherwise make
> > the build fail. The new translations pass the tests too.
> > 
> > [ Risks ]
> > 
> > These all seem like very low risk changes to me.
> > 
> > [ Checklist ]
> > 
> >   [√] all changes are documented in the d/changelog
> >   [√] I reviewed all changes and I approve them
> >   [√] attach debdiff against the package in testing
> > 
> > [ Other info ]
> > 
> > Actually, I've only attached the filtered debdiff, and not the unfiltered
> > one here, as due to the translations it seems a bit big, and I'm afraid
> > it might make the mail not get through. It can be found at:
> > 
> >   https://people.debian.org/~guillem/dpkg-1.21.19-1.21.20.debdiff.xz
> > 
> > That debdiff is unfiltered, you might want to filterdiff with, which
> > should give the same result as the attached one:
> > 
> >   xzcat dpkg-1.21.19-1.21.20.debdiff.xz |
> > filterdiff --exclude '*.po' --exclude '*.pot' \
> >--exclude '*/man/*/*.pod' \
> >--exclude '*/testsuite' --exclude '*/at/*.m4' \
> >--exclude '*/configure'
> > 
> > Alternatively I've pushed all except for the usual update-po and
> > actual release commit and tag to:
> > 
> >   https://git.dpkg.org/cgit/dpkg/dpkg.git/log/
> > 
> > unblock dpkg/1.21.20
> 
> Hmm, just received three bug reports with updates to the Dutch
> translations (#1030710, #1030711, #1030712), and although these came
> after the CfT deadline, I'm inclined to include them and redo the
> release process machinery (which ends up affecting the two topmost
> commits in git, the signed git tag and the built artifacts). If you'd
> like to see the debdiff for that, I'm happy to update and provide it.

Hmm, and just directly received now a Portuguese translation update
too.

> But otherwise let me know, and I can just queue them up "for later",
> whenever that might be.

Thanks,
Guillem

Bug#1030672: [pre-approval] unblock: dpkg/1.21.20

[Guillem Jover]

Hi!

On Mon, 2023-02-06 at 12:43:37 +0100, Guillem Jover wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: d...@packages.debian.org
> Control: affects -1 + src:dpkg

> Please pre-approve the dpkg 1.21.20 upload.
> 
> [ Reason ]
> 
> This dpkg release includes the translation updates for the recent Call
> for Translations, a few test suite fixes to make them pass again due
> to these translations and a recent cppcheck upload in unstable. A typo
> fix in the man pages. Updates to the lintian overrides. And fixes a
> typo in the Build-Depends that made the version too low.
> 
> [ Impact ]
> 
> These would give better translation coverage, the rest are not
> relevant to the final user, but can affect CI systems and downstream
> users, as they are build/test system fixes.
> 
> [ Tests ]
> 
> The various test suite fixes are due to the test suite failing now.
> The Build-Depends fix should be self-evident and would otherwise make
> the build fail. The new translations pass the tests too.
> 
> [ Risks ]
> 
> These all seem like very low risk changes to me.
> 
> [ Checklist ]
> 
>   [√] all changes are documented in the d/changelog
>   [√] I reviewed all changes and I approve them
>   [√] attach debdiff against the package in testing
> 
> [ Other info ]
> 
> Actually, I've only attached the filtered debdiff, and not the unfiltered
> one here, as due to the translations it seems a bit big, and I'm afraid
> it might make the mail not get through. It can be found at:
> 
>   https://people.debian.org/~guillem/dpkg-1.21.19-1.21.20.debdiff.xz
> 
> That debdiff is unfiltered, you might want to filterdiff with, which
> should give the same result as the attached one:
> 
>   xzcat dpkg-1.21.19-1.21.20.debdiff.xz |
> filterdiff --exclude '*.po' --exclude '*.pot' \
>--exclude '*/man/*/*.pod' \
>--exclude '*/testsuite' --exclude '*/at/*.m4' \
>--exclude '*/configure'
> 
> Alternatively I've pushed all except for the usual update-po and
> actual release commit and tag to:
> 
>   https://git.dpkg.org/cgit/dpkg/dpkg.git/log/
> 
> unblock dpkg/1.21.20

Hmm, just received three bug reports with updates to the Dutch
translations (#1030710, #1030711, #1030712), and although these came
after the CfT deadline, I'm inclined to include them and redo the
release process machinery (which ends up affecting the two topmost
commits in git, the signed git tag and the built artifacts). If you'd
like to see the debdiff for that, I'm happy to update and provide it.

But otherwise let me know, and I can just queue them up "for later",
whenever that might be.

Thanks,
Guillem

Bug#1030672: [pre-approval] unblock: dpkg/1.21.20

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: d...@packages.debian.org
Control: affects -1 + src:dpkg

Hi!

Please pre-approve the dpkg 1.21.20 upload.

[ Reason ]

This dpkg release includes the translation updates for the recent Call
for Translations, a few test suite fixes to make them pass again due
to these translations and a recent cppcheck upload in unstable. A typo
fix in the man pages. Updates to the lintian overrides. And fixes a
typo in the Build-Depends that made the version too low.

[ Impact ]

These would give better translation coverage, the rest are not
relevant to the final user, but can affect CI systems and downstream
users, as they are build/test system fixes.

[ Tests ]

The various test suite fixes are due to the test suite failing now.
The Build-Depends fix should be self-evident and would otherwise make
the build fail. The new translations pass the tests too.

[ Risks ]

These all seem like very low risk changes to me.

[ Checklist ]

  [√] all changes are documented in the d/changelog
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in testing

[ Other info ]

Actually, I've only attached the filtered debdiff, and not the unfiltered
one here, as due to the translations it seems a bit big, and I'm afraid
it might make the mail not get through. It can be found at:

  https://people.debian.org/~guillem/dpkg-1.21.19-1.21.20.debdiff.xz

That debdiff is unfiltered, you might want to filterdiff with, which
should give the same result as the attached one:

  xzcat dpkg-1.21.19-1.21.20.debdiff.xz |
filterdiff --exclude '*.po' --exclude '*.pot' \
   --exclude '*/man/*/*.pod' \
   --exclude '*/testsuite' --exclude '*/at/*.m4' \
   --exclude '*/configure'

Alternatively I've pushed all except for the usual update-po and
actual release commit and tag to:

  https://git.dpkg.org/cgit/dpkg/dpkg.git/log/

unblock dpkg/1.21.20

Thanks,
Guillem


dpkg-1.21.19-1.21.20.debdiff-filtered.xz
Description: application/xz

Bug#1026199: release.debian.org: Is the toolchain list updated for bookworm

[Guillem Jover]

Hi!

On Sat, 2022-12-17 at 08:42:18 +0100, Paul Gevers wrote:
> On 16-12-2022 02:40, Sam Hartman wrote:
> > I was looking at 
> > https://release.debian.org/testing/essential-and-build-essential.txt
> > 
> > trying to figure out which packages I'm involved in are covered by the
> > toolchain freeze.  I am wondering what's still pulling
> > libgssapi-krb5-2 and friends into build-essential.  It used to be
> > pulled in via pam via libtirpc, but that should have gone away with
> > the pam upload of 1.4.0-13.
> > 
> > 
> > I'm wondering if that list hasn't been recently updated or if there's some 
> > other dependency cycle pulling in krb5?

Ah, was wondering the same few days before the toolchain freeze, as I
was unsure whether to update some of the packages I maintain (in
particular libmd, for which I was thinking of doing a new upstream
release), and was also checking hints for explicit blocks. See below…

> I just refreshed the list, it's still there. I used a script on udd,
> essentially this:
> 
> essentials = {'build-essential'}
> 
> def add_sql_packages(con, essentials, query):
> cur = con.cursor()
> 
> cur.execute(query)
> items = cur.fetchall()
> cur.close()
> 
> for item in items:
> if item[0] is not None:
> no_alt = re.sub(alternatives, "", item[0])
> no_ver = re.sub(version, "", no_alt)
> 
> for x in no_ver.split(','):
> essentials.add(re.sub(multiarch, "", x.strip()))
> 
> query = "SELECT DISTINCT package FROM packages WHERE release = 'bookworm'
> and essential = 'yes'"
> 
> add_sql_packages(con, essentials, query)
> 
> done = False
> while not done:
> ess_org = copy.copy(essentials)
> query = """SELECT DISTINCT depends FROM packages WHERE release =
> 'bookworm' and
> package in ('%s')""" % "','".join(essentials)
> add_sql_packages(con, essentials, query)
> if essentials == ess_org:
> done = True

…but hmm, is this perhaps not taking into account Pre-Depends?

Thanks,
Guillem

Bug#1029585: [pre-approval] unblock: dpkg/1.21.19

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: d...@packages.debian.org
Control: affects -1 + src:dpkg

Hi!

(Even though I've noticed no blocking hints, given that the package
is supposed to be frozen, I'm requesting this pre-approval explicitly
anyway through the normal procedures as usual and expected.)

[ Reason ]

This dpkg release fixes several regressions. Reverts the loong64 arch
support given the uncertain status with its changing ABI. And updates
few translations.

[ Tests ]

The lto regression fix includes unit tests. The rest were tested
manually, the reproducible one by messing with the file perms of the
source, the GnuPG ones by creating fresh keys in a clean user home.

[ Risks ]

The changes seem targeted and small to me.

[ Checklist ]
  [√] all changes are documented in the d/changelog
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in testing

[ Other info ]

The attached debdiff is unfiltered, you might want to filterdiff with:

  xzcat dpkg-1.21.18-1.21.19.debdiff.xz |
filterdiff --exclude '*.po' --exclude '*.pot' \
   --exclude '*/man/*/*.pod' \
   --exclude '*/testsuite' --exclude '*/at/*.m4' \
   --exclude '*/configure'

Once (and iff) I get an approval, I'll upload to sid. I don't think
there's a need for an actual unblock hint though? :) But in any case:

unblock dpkg/1.21.19

Thanks,
Guillem


dpkg-1.21.18-1.21.19.debdiff.xz
Description: application/xz

Re: Bug#1019724: warning: stray \ before - causes autopkgtest failure

[Guillem Jover]

On Wed, 2022-09-14 at 17:31:16 +0200, Santiago Ruano Rincón wrote:
> Yeah, sorry. I lately realised not all the packages would autoreconf
> during building time.
> 
> So silencing these warnings would make sense.

Please consider implementing a way to be able to conditionally re-enable
locally these warnings so that we can try to hunt down and fix those,
otherwise we might end up hitting these once we revert the silencing,
for example for code paths that are not commonly exercised.

I've mentioned this on the upstream bug report, but it would be nicer
if you could coordinate a way upstream might be happy with, say using
a specific environment variable or similar.

Thanks,
Guillem

Bug#1018857: bullseye-pu: package dpkg/1.20.12

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]

This update backports multiple fixes from unstable for RC bugs and fixes
broken behavior. It makes the dpkg-fsys-usrunmess script more robust,
fixes mishandling of versioned symbols due to output changes in objdump,
fixes the removal-on-upgrade conffile support, and adds support for the
ARC arch. There's also a tiny fix for the Dutch translated man pages.

[ Impact ]

* The dpkg-shlibdeps problem would cause wrong dependency information
  which could lead to programs unable to run-time link due to missing
  symbols.

* The removal-on-upgrade conffile support could end up removing
  pathnames owned by other packages.

* The dpkg-fsys-usrunmess changes make the script more robust, to
  reduce the potential for breakage and avoid known problematic
  scenarios that can leave the system messed up, requiring arduous
  recovery.

* The arc arch porters cannot introduce it properly as the infr runs
  on stable which currently does not know about it.

[ Tests ]

* The fix for dpkg-shlibdeps can be verified by running that version
  on unstable/testing and building cppcheck. (I have pending adding
  a minimal test case into the test suite in git main though.)

* The removal-on-upgrade conffile fix contains functional tests.

* The dpkg-fsys-usrunmess has been run on a merged-/usr system with
  the various conditions and it works as expected.

* The arc arch addition is trivial, but still contains some test suite
  coverage.

[ Risks ]

All these fixes have been in unstable/testing for months now, w/ no
reported regressions. The biggest changes are for the
removal-on-upgrade conffile support, but that ends up being more of
moving code around, and the changes to dpkg-fsys-usrunmess. But none
are that big anyway.

[ Checklist ]

  [√] *all* changes are documented in the d/changelog
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in (old)stable
  [√] the issue is verified as fixed in unstable

[ Changes ]

The git log is included in the debdiff, which I'm attaching in its full
compressed form with no filtering applied.

[ Other info ]

None.

Thanks,
Guillem


dpkg-1.20.11-1.20.12.debdiff.xz
Description: application/xz

Bug#1018854: buster-pu: package dpkg/1.19.9

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]

This update fixes the same regression (introduced in the security fix
in dpkg 1.19.8) that was fixed in bullseye for dpkg 1.20.11 (#1014206).

[ Impact ]

This introduced a regression when unpacking source packages.

[ Tests ]

As lintian does not appear to have had the failing test there, I did
the following quick verification:

  - Download a source package.
  - Unpack the orig tarball.
  - Remove all write permissions from all files.
  - Repack and amend the .dsc
  - Unpacking with dpkg-source -x does not work in buster, works with
the fixed package.

(And I'll be adding a functional test in dpkg 1.21.x to cover this…)

[ Risks ]

The code has been in unstable, bookworm and bullseye for a while. The
patch applied cleanly, and it's minimal.

[ Checklist ]

  [√] *all* changes are documented in the d/changelog
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in (old)stable
  [√] the issue is verified as fixed in unstable

[ Changes ]

The git log is included in the debdiff, which I'm attaching in its full
compressed form with no filtering applied.

[ Other info ]

None.

Thanks,
Guillem
diff -Nru dpkg-1.19.8/.dist-version dpkg-1.19.9/.dist-version
--- dpkg-1.19.8/.dist-version   2022-05-24 13:40:09.0 +0200
+++ dpkg-1.19.9/.dist-version   2022-09-01 03:40:03.0 +0200
@@ -1 +1 @@
-1.19.8
+1.19.9
diff -Nru dpkg-1.19.8/ChangeLog dpkg-1.19.9/ChangeLog
--- dpkg-1.19.8/ChangeLog   2022-05-24 13:40:09.0 +0200
+++ dpkg-1.19.9/ChangeLog   2022-09-01 03:40:03.0 +0200
@@ -1,3 +1,137 @@
+commit e2254431dca4eccb5125c21cb7299090e6725b3a
+Author: Guillem Jover 
+Date:   Thu Sep 1 03:43:20 2022 +0200
+
+Release 1.19.9
+
+ debian/changelog | 8 +---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+commit e1e6c85841778630facbefa1b8ed928668283d79
+Author: Guillem Jover 
+Date:   Thu Sep 1 03:40:03 2022 +0200
+
+po: Regenerate .pot files and merge .po files with them
+
+ dselect/po/bs.po| 2 +-
+ dselect/po/ca.po| 2 +-
+ dselect/po/cs.po| 2 +-
+ dselect/po/da.po| 2 +-
+ dselect/po/de.po| 2 +-
+ dselect/po/dselect.pot  | 4 ++--
+ dselect/po/el.po| 2 +-
+ dselect/po/es.po| 2 +-
+ dselect/po/et.po| 2 +-
+ dselect/po/eu.po| 2 +-
+ dselect/po/fr.po| 2 +-
+ dselect/po/gl.po| 2 +-
+ dselect/po/hu.po| 2 +-
+ dselect/po/id.po| 2 +-
+ dselect/po/it.po| 2 +-
+ dselect/po/ja.po| 2 +-
+ dselect/po/ko.po| 2 +-
+ dselect/po/nb.po| 2 +-
+ dselect/po/nl.po| 2 +-
+ dselect/po/nn.po| 2 +-
+ dselect/po/pl.po| 2 +-
+ dselect/po/pt.po| 2 +-
+ dselect/po/pt_BR.po | 2 +-
+ dselect/po/ro.po| 2 +-
+ dselect/po/ru.po| 2 +-
+ dselect/po/sk.po| 2 +-
+ dselect/po/sv.po| 2 +-
+ dselect/po/tl.po| 2 +-
+ dselect/po/vi.po| 2 +-
+ dselect/po/zh_CN.po | 2 +-
+ dselect/po/zh_TW.po | 2 +-
+ man/po/dpkg-man.pot | 4 ++--
+ po/ast.po   | 2 +-
+ po/bs.po| 2 +-
+ po/ca.po| 2 +-
+ po/cs.po| 2 +-
+ po/da.po| 2 +-
+ po/de.po| 2 +-
+ po/dpkg.pot | 4 ++--
+ po/dz.po| 2 +-
+ po/el.po| 2 +-
+ po/eo.po| 2 +-
+ po/es.po| 2 +-
+ po/et.po| 2 +-
+ po/eu.po| 2 +-
+ po/fr.po| 2 +-
+ po/gl.po| 2 +-
+ po/hu.po| 2 +-
+ po/id.po| 2 +-
+ po/it.po| 2 +-
+ po/ja.po| 2 +-
+ po/km.po| 2 +-
+ po/ko.po| 2 +-
+ po/ku.po| 2 +-
+ po/lt.po| 2 +-
+ po/mr.po| 2 +-
+ po/nb.po| 2 +-
+ po/ne.po| 2 +-
+ po/nl.po| 2 +-
+ po/nn.po| 2 +-
+ po/pa.po| 2 +-
+ po/pl.po| 2 +-
+ po/pt.po| 2 +-
+ po/pt_BR.po | 2 +-
+ po/ro.po| 2 +-
+ po/ru.po| 2 +-
+ po/sk.po| 2 +-
+ po/sv.po| 2 +-
+ po/th.po| 2 +-
+ po/tl.po| 2 +-
+ po/tr.po| 2 +-
+ po/vi.po| 2 +-
+ po/zh_CN.po | 2 +-
+ po/zh_TW.po | 2 +-
+ scripts/po/ca.po| 2 +-
+ scripts/po/de.po| 2 +-
+ scripts/po/dpkg-dev.pot | 4 ++--
+ scripts/po/es.po| 2 +-
+ scripts/po/fr.po| 2 +-
+ scripts/po/pl.po| 2 +-
+ scripts/po/ru.po| 2 +-
+ scripts/po/sv.po| 2 +-
+ 82 files changed, 86 insertions(+), 86 deletions(-)
+
+commit d0f3775a0334261b793acc87c56146df7bb3fc66
+Author: Guillem Jover 
+Date:   Sat Jun 4 05:48:21 2022 +0200

Bug#1018800: buster-pu: package inetutils/2:1.9.4-7+deb10u2

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@security.debian.org

Hi!

This is the counterpart to #1018744 but for buster.

[ Reason ]

This fixes three pending security issue, that the security team (CCed)
would prefer to see handled as normal oldstable updates.

(This is the same set of changes as the bullseye version, plus a couple
of patches from upstream for CVE-2019-0053, that are missing in that
version.)

[ Impact ]

All changes are security related, mostly buffer overflows, that can at
least cause crashes and DoS.

[ Tests ]

The same tests as the ones for bullseye in #1018744 were used here and
the issues could be reproduced before, and not any more after the
patched version.

[ Risks ]

Same risks as the version for bullseye.

[ Checklist ]

  [√] *all* changes are documented in the d/changelog
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in (old)stable
  [√] the issue is verified as fixed in unstable

[ Changes ]

  * Security fixes for telnet client:
- Validate supplied environment variables.
- Check for buffer overflows when processing telnet protocol messages.
- Add checks for option reply parsing limits causing buffer
  overflow induced crashes due to long option values.
- Fix infinite loop causing a stack exhaustion induced crash due to
  malicious server commands.
Fixes CVE-2019-0053. Closes: #945861
  * Fix inetutils-ftp security bug trusting FTP PASV responses.
Fixes CVE-2021-40491. Closes: #993476
  * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
adapted by Erik Auerswald .
Fixes CVE-2022-39028.

[ Other info ]

None.

Thanks,
Guillem
diff -Nru inetutils-1.9.4/debian/changelog inetutils-1.9.4/debian/changelog
--- inetutils-1.9.4/debian/changelog2020-09-18 20:06:42.0 +0200
+++ inetutils-1.9.4/debian/changelog2022-08-31 00:58:35.0 +0200
@@ -1,3 +1,23 @@
+inetutils (2:1.9.4-7+deb10u2) buster; urgency=medium
+
+  * Security fixes for telnet client:
+- Validate supplied environment variables.
+- Check for buffer overflows when processing telnet protocol messages.
+- Add checks for option reply parsing limits causing buffer
+  overflow induced crashes due to long option values.
+- Fix infinite loop causing a stack exhaustion induced crash due to
+  malicious server commands.
+Fixes CVE-2019-0053. Closes: #945861
+  * Fix inetutils-ftp security bug trusting FTP PASV responses.
+Fixes CVE-2021-40491. Closes: #993476
+  * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
+a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
+or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
+adapted by Erik Auerswald .
+Fixes CVE-2022-39028.
+
+ -- Guillem Jover   Wed, 31 Aug 2022 00:58:35 +0200
+
 inetutils (2:1.9.4-7+deb10u1) buster; urgency=medium
 
   * CVE-2020-10188 (Closes: #956084)
diff -Nru 
inetutils-1.9.4/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
 
inetutils-1.9.4/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
--- 
inetutils-1.9.4/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
  1970-01-01 01:00:00.0 +0100
+++ 
inetutils-1.9.4/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
  2022-08-31 00:58:35.0 +0200
@@ -0,0 +1,54 @@
+From 58cb043b190fd04effdaea7c9403416b436e50dd Mon Sep 17 00:00:00 2001
+From: Simon Josefsson 
+Date: Wed, 1 Sep 2021 09:09:50 +0200
+Subject: [PATCH] ftp: check that PASV/LSPV addresses match.
+
+* ftp/ftp.c (initconn): Validate returned addresses.
+---
+ ftp/ftp.c |   21 +
+ 1 file changed, 21 insertions(+)
+
+--- a/ftp/ftp.c
 b/ftp/ftp.c
+@@ -1357,6 +1357,13 @@ initconn (void)
+ uint32_t *pu32 = (uint32_t *) _addr_sa4->sin_addr.s_addr;
+ pu32[0] = htonl ( (h[0] << 24) | (h[1] << 16) | (h[2] << 8) | 
h[3]);
+   }
++  if (data_addr_sa4->sin_addr.s_addr
++  != ((struct sockaddr_in *) )->sin_addr.s_addr)
++{
++  printf ("Passive mode address mismatch.\n");
++  (void) command ("ABOR");/* Cancel any open connection.  
*/
++  goto bad;
++}
+   } /* LPSV IPv4 */
+ else /* IPv6 */
+   {
+@@ -1387,6 +1394,13 @@ initconn (void)
+ pu32[2] = htonl ( (h[8] << 24) | (h[9] << 16) | (h[10] << 8) 
| h[11]);
+ pu32[3] = htonl ( (h[12] << 24) | (h[13] << 16) | (h[14] << 
8) | h[15]);
+   }
++

Bug#1018744: bullseye-pu: package inetutils/2:2.0-1+deb11u1

[Guillem Jover]

Hi!

Sorry, I'm updating the request as I found missing stuff while
preparing the companion update for buster!

On Tue, 2022-08-30 at 00:37:03 +0200, Guillem Jover wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: t...@security.debian.org

> [ Reason ]
> 
> A recent vulnerability (DoS) was reported upstream, for which I
> uploaded a fixed package to sid (will migrate tomorrow). There was a
> (minor) pending security update missing from bullseye. The security
> team (CCed) would prefer to see these handled as normal stable updates.

I'm adding a couple of patches to solve lingering buffer overflow issues
from #945861 and CVE-2019-0053.

> [ Impact ]
> 
> These are both security issues. One against malicious ftp servers
> which can end up controlling the client to connect to other hosts,
> the other a DoS on the telnetd server which makes it crash with
> specific two-byte payloads.

The additional patches are buffer overflows.

> [ Tests ]
> 
> For the ftp client, there's a test recipe at
> <https://lists.gnu.org/archive/html/bug-inetutils/2021-06/msg2.html>.
> 
> For the telnetd server there's a test recipe at
> <https://lists.gnu.org/archive/html/bug-inetutils/2022-08/msg3.html>
> which amounts to «printf "\xff\xf7" | nc -n -v localhost 23».

The two new patches fix the following reproducers:

  $ DISPLAY=`perl -e 'print Ax"5"'` telnet -l`perl -e 'print "A"x5000'` 
localhost

and

  
https://raw.githubusercontent.com/hackerhouse-opensource/exploits/master/telnet_term_0day.py

> Both test recipes could be reproduced before, and do not work after
> the patched version.

> [ Risks ]
> 
> The fix for the ftp client has been in sid since 2021-09 with no
> reported regressions.
> 
> The fix for telnetd has not yet migrated to testing, but is few lines
> long fixing a couple of NULL pointer dereferences.

Both new fixes have been part of sid/testing for a while now.

> [ Checklist ]
> 
>   [√] *all* changes are documented in the d/changelog
>   [√] I reviewed all changes and I approve them
>   [√] attach debdiff against the package in (old)stable
>   [√] the issue is verified as fixed in unstable
> 
> [ Changes ]

  * telnet: Add checks for option reply parsing limits causing buffer
overflow induced crashes due to long option values.
Fixes CVE-2019-0053. Closes: #945861
  * Add patch from upstream to fix infinite loop causing a stack exhaustion
induced crash in telnet client due to malicious server commands.
Closes: #945861
>   * Fix inetutils-ftp security bug trusting FTP PASV responses.
> Fixes CVE-2021-40491. Closes: #993476
>   * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
> a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
> or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
> adapted by Erik Auerswald .

> [ Other info ]
> 
> None.

I'm attaching the refreshed debdiff.

Thanks,
Guillem
diff -Nru inetutils-2.0/debian/changelog inetutils-2.0/debian/changelog
--- inetutils-2.0/debian/changelog  2021-02-05 23:14:20.0 +0100
+++ inetutils-2.0/debian/changelog  2022-08-30 13:34:41.0 +0200
@@ -1,3 +1,21 @@
+inetutils (2:2.0-1+deb11u1) bullseye; urgency=medium
+
+  * telnet: Add checks for option reply parsing limits causing buffer
+overflow induced crashes due to long option values.
+Fixes CVE-2019-0053. Closes: #945861
+  * Add patch from upstream to fix infinite loop causing a stack exhaustion
+induced crash in telnet client due to malicious server commands.
+Closes: #945861
+  * Fix inetutils-ftp security bug trusting FTP PASV responses.
+Fixes CVE-2021-40491. Closes: #993476
+  * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
+a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
+or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
+adapted by Erik Auerswald .
+Fixes CVE-2022-39028.
+
+ -- Guillem Jover   Tue, 30 Aug 2022 13:34:41 +0200
+
 inetutils (2:2.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
--- 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
1970-01-01 01:00:00.0 +0100
+++ 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
2022-08-30 13:33:33.0 +0200
@@ -0,0 +1,59 @@
+From 58cb043b190fd04effdaea7c9403416b436e50dd Mon Sep 17 00:00:00 2001
+From: Simon Josefsson 
+Date: Wed, 1 Sep 2021 09:09:50 +0200
+Subject: [PATCH] 

Bug#1018744: bullseye-pu: package inetutils/2:2.0-1+deb11u1

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@security.debian.org

Hi!

[ Reason ]

A recent vulnerability (DoS) was reported upstream, for which I
uploaded a fixed package to sid (will migrate tomorrow). There was a
(minor) pending security update missing from bullseye. The security
team (CCed) would prefer to see these handled as normal stable updates.

[ Impact ]

These are both security issues. One against malicious ftp servers
which can end up controlling the client to connect to other hosts,
the other a DoS on the telnetd server which makes it crash with
specific two-byte payloads.

[ Tests ]

For the ftp client, there's a test recipe at
<https://lists.gnu.org/archive/html/bug-inetutils/2021-06/msg2.html>.

For the telnetd server there's a test recipe at
<https://lists.gnu.org/archive/html/bug-inetutils/2022-08/msg3.html>
which amounts to «printf "\xff\xf7" | nc -n -v localhost 23».

Both test recipes could be reproduced before, and do not work after
the patched version.

[ Risks ]

The fix for the ftp client has been in sid since 2021-09 with no
reported regressions.

The fix for telnetd has not yet migrated to testing, but is few lines
long fixing a couple of NULL pointer dereferences.

[ Checklist ]

  [√] *all* changes are documented in the d/changelog
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in (old)stable
  [√] the issue is verified as fixed in unstable

[ Changes ]

  * Fix inetutils-ftp security bug trusting FTP PASV responses.
Fixes CVE-2021-40491. Closes: #993476
  * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
adapted by Erik Auerswald .

[ Other info ]

None.

Thanks.
Guillem
diff -Nru inetutils-2.0/debian/changelog inetutils-2.0/debian/changelog
--- inetutils-2.0/debian/changelog  2021-02-05 23:14:20.0 +0100
+++ inetutils-2.0/debian/changelog  2022-08-28 16:01:41.0 +0200
@@ -1,3 +1,14 @@
+inetutils (2:2.0-1+deb11u1) bullseye; urgency=medium
+
+  * Fix inetutils-ftp security bug trusting FTP PASV responses.
+Fixes CVE-2021-40491. Closes: #993476
+  * Fix remote DoS vulnerability in inetutils-telnetd, caused by a crash by
+a NULL pointer dereference when sending the byte sequences «0xff 0xf7»
+or «0xff 0xf8». Found by Pierre Kim and Alexandre Torres. Patch
+adapted by Erik Auerswald .
+
+ -- Guillem Jover   Sun, 28 Aug 2022 16:01:41 +0200
+
 inetutils (2:2.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
--- 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
1970-01-01 01:00:00.0 +0100
+++ 
inetutils-2.0/debian/patches/0001-ftp-check-that-PASV-LSPV-addresses-match.patch
2022-08-28 16:01:41.0 +0200
@@ -0,0 +1,59 @@
+From 58cb043b190fd04effdaea7c9403416b436e50dd Mon Sep 17 00:00:00 2001
+From: Simon Josefsson 
+Date: Wed, 1 Sep 2021 09:09:50 +0200
+Subject: [PATCH] ftp: check that PASV/LSPV addresses match.
+
+* ftp/ftp.c (initconn): Validate returned addresses.
+---
+ ftp/ftp.c | 21 +
+ 2 files changed, 30 insertions(+)
+
+diff --git a/ftp/ftp.c b/ftp/ftp.c
+index d21dbdd8..7513539d 100644
+--- a/ftp/ftp.c
 b/ftp/ftp.c
+@@ -1365,6 +1365,13 @@ initconn (void)
+ uint32_t *pu32 = (uint32_t *) _addr_sa4->sin_addr.s_addr;
+ pu32[0] = htonl ( (h[0] << 24) | (h[1] << 16) | (h[2] << 8) | 
h[3]);
+   }
++  if (data_addr_sa4->sin_addr.s_addr
++  != ((struct sockaddr_in *) )->sin_addr.s_addr)
++{
++  printf ("Passive mode address mismatch.\n");
++  (void) command ("ABOR");/* Cancel any open connection.  
*/
++  goto bad;
++}
+   } /* LPSV IPv4 */
+ else /* IPv6 */
+   {
+@@ -1395,6 +1402,13 @@ initconn (void)
+ pu32[2] = htonl ( (h[8] << 24) | (h[9] << 16) | (h[10] << 8) 
| h[11]);
+ pu32[3] = htonl ( (h[12] << 24) | (h[13] << 16) | (h[14] << 
8) | h[15]);
+   }
++  if (data_addr_sa6->sin6_addr.s6_addr
++  != ((struct sockaddr_in6 *) )->sin6_addr.s6_addr)
++{
++  printf ("Passive mode address mismatch.\n");
++  (void) command ("ABOR");/* Cancel any open connection.  
*/
++  goto bad;
++}
+   } /* LPSV IPv6 */
+   

Bug#1014206: bullseye-pu: package dpkg/1.20.11

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

Hi!

[ Reason ]

This request includes several targeted minimal fixes for issues found
in dpkg 1.20.10, including one regression introduced in the security
update.

I mentioned to Adam that I'd prepare two sets of debdiffs, one with just
the regression fix and another one with fixes for the other pending RC
and other fixes. But after checking them, the latter seemed too big for
the amount of time available, and while these have all been in sid for
a while they have not been tested on their own, so I think it's probably
better to postpone those for a next release, that I'll be preparing once
this one is handled. Instead I went with a small set of small targeted
fixes.

[ Impact ]

a) A CI fix, that was causing the branch to fail on salsa.
b) The dpkg-deb change fixes handling for truncated .debs.
c) The virtual fields one fixes a regression in dpkg --showformat.
d) The Dpkg::Source::Package::V2 fixes the regression from the security
   fix. This affects systems with "unusual" umasks.

[ Tests ]

a) The CI for that branch is green again. :)
b) The commit includes functional tests.
c) Running dpkg-deb --showformat with a virtual field now works again.
d) The lintian test suite was executed successfully.

[ Risks ]

The set of changes cherry-picked is focused and easily verifiable.
Any bigger/riskier change has been left out.

[ Checklist ]

  [√] *all* changes are documented in the d/changelog
  [√] I reviewed all changes and I approve them
  [√] attach debdiff against the package in (old)stable
  [√] the issue is verified as fixed in unstable

[ Changes ]

The git log is included in the debdiff, which I'm attaching in its full
compressed form with no filtering applied.

[ Other info ]

None.

Thanks,
Guillem


dpkg-1.20.10-1.20.11.debdiff.xz
Description: application/xz

Bug#1008184: nmu: unknown packages affected by dpkg-dev bug #1000421

[Guillem Jover]

Package: release.debian.org
Severity: important
User: release.debian@packages.debian.org
Usertags: binnmu

Hi!

The objdump tool changed its output for copy relocations for versioned
symbols (from @@ to @) in binutils 2.26 (uploaded on 2016-01). This has
caused dpkg-shlibdeps to ignore some of those symbols and potentially end
up generating version restrictions that are less than required. (This was
dpkg bug #1000421.)

So this involves shared libraries using versioned symbols, for symbols
that are objects (variables instead of functions or methods), on
architectures that emit copy relocations for these. On my checks these
were at least any-amd64, hppa and m68k.

A small example on linux-amd64:

  ,--- copyrel.c ---
  #include 
  int main() { return optind; }
  `---

  ,--- (stretch) ---
  $ make copyrel
  $ objdump -R copyrel | grep R_[^ ]*_COPY
  00201028 R_X86_64_COPY optind@@GLIBC_2.2.5
  `---

  ,--- (sid) ---
  $ make copyrel
  $ objdump -R copyrel | grep R_[^ ]*_COPY
  4028 R_X86_64_COPY optind@GLIBC_2.2.5
  `---

What unearthed this was a recentish glibc upload that AFAIR has started
merging its libpthread library into libc proper, and added a new symbol
for a variable (__libc_single_threaded@GLIBC_2.32).

I guess the archive should be checked for other instances of at least
that glibc issue, because that can affect partial upgrades in a pretty
nasty way (with programs being unable to be run-time linked). So that
would imply any program that has been:

  * built against glibc >= 2.32-0experimental0
  * built using binutils >= 2.26
  * built using dpkg-dev < 1.21.0
  * containing a copy reloc for __libc_single_threaded:
objdump -R $prog | grep 'R_[^ ]*_COPY .* __libc_single_threaded'

Most of this information should be available at least from the .buildinfo
files.


This could have affected other programs using other versioned variables
from other shared libraries, for quite some time, but not that many shared
libraries use versioned symbols, but checking that would imply more effort
to detect. :/

Thanks,
Guillem

Bug#999504: transition: liburing

[Guillem Jover]

Hi!

On Fri, 2021-11-12 at 18:50:36 +0100, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-liburing.html
> 
> On 2021-11-12 04:18:57 +0100, Guillem Jover wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition

> > The liburing source bumped its SONAME from liburing1 to liburing2, but
> > it should be API compatible. The new upstream has been uploaded to
> > experimental, and I did a rebuild of all reverse build-depends with the
> > 2.0 release, no FTBFS were found due to the new release. So binNMUs
> > should be enough for this.
> 
> Please go ahead.

Thanks! I've just uploaded it to unstable.

Regards,
Guillem

Bug#999504: transition: liburing

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi!

The liburing source bumped its SONAME from liburing1 to liburing2, but
it should be API compatible. The new upstream has been uploaded to
experimental, and I did a rebuild of all reverse build-depends with the
2.0 release, no FTBFS were found due to the new release. So binNMUs
should be enough for this.

Ben file:

title = "liburing";
is_affected = .depends ~ "liburing1" | .depends ~ "liburing2";
is_good = .depends ~ "liburing2";
is_bad = .depends ~ "liburing1";

Thanks,
Guillem

Bug#986835: [pre-approval] unblock: dpkg/1.20.8

[Guillem Jover]

Control: retitle -1 [pre-approval] unblock: dpkg/1.20.9
Control: tag -1 - moreinfo

Hi!

On Tue, 2021-04-13 at 20:22:46 +0200, Ivo De Decker wrote:
> On Tue, Apr 13, 2021 at 08:13:10PM +0200, Guillem Jover wrote:
> > On Tue, 2021-04-13 at 17:58:08 +0200, Guillem Jover wrote:
> > > On Tue, 2021-04-13 at 15:36:08 +0200, Ivo De Decker wrote:
> > > > Please go ahead with the upload and remove the moreinfo tag from this 
> > > > bug when
> > > > the new version is in unstable.
> > > 
> > > Thanks! I'm targeting an upload for later today, but I was thinking I
> > > might try to quickly produce a tiny functional test for the
> > > auto-deconfigure bug. I'll update the report once I get that, and I
> > > could hold the upload until you approve that, but I'm not sure that's
> > > worth the round-trip, given that it's a test? :)
> > 
> > Ok, this was actually trivial, as it was pretty much like the existing
> > t-breaks test case but with Protected/Essential:yes added to the broken
> > packages.
> > 
> > Attached updated patch, including test case and ref.
> 
> I don't know if you're expecting an explicit ack on the extra test as well,
> but if you do: please go ahead and include the test :)

And arf, sorry, one of the changes to make the test suite more portable
ended up triggering a mass FTBFS. :/ I guess it was a problem waiting to
happen anyway, but… The attached patch fixes this, and I've uploaded now
dpkg 1.20.9.

For the future I'll probably update my release script to build in a
non-amd64 system too, or choose a fake arch different from the current
one to always spot this kind of problem in 1.21.x.

Thanks,
Guillem
From 7719a3aab135d904d3c43f7958415604f41e7d47 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Wed, 14 Apr 2021 00:34:18 +0200
Subject: [PATCH] test: Pass --ignore-builtin-builddeps to dpkg-buildpackage

We should ignore any builtin build dependencies (in particular
build-essential, which is an arch:any package), as we are forcing the
build and host architectures, which will make them not match whatever
is on the system status file if present at all, and cause dependency
unsatisfiability.

Fixes: commit 0e2ae4e706e816a9ce200bb506674d19af25a55f
---
 scripts/t/dpkg_buildpackage.t | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/t/dpkg_buildpackage.t b/scripts/t/dpkg_buildpackage.t
index d529eb69c..47c6e184b 100644
--- a/scripts/t/dpkg_buildpackage.t
+++ b/scripts/t/dpkg_buildpackage.t
@@ -187,6 +187,7 @@ sub test_build
 chdir $dirname;
 spawn(exec => [ $ENV{PERL}, "$srcdir/dpkg-buildpackage.pl",
 '--host-arch=amd64',
+'--ignore-builtin-builddeps',
 '--unsigned-source', '--unsigned-changes',
 '--unsigned-buildinfo',
 "--build=$typename", '--check-command=' ],
-- 
2.31.0

Bug#986835: [pre-approval] unblock: dpkg/1.20.8

[Guillem Jover]

On Tue, 2021-04-13 at 17:58:08 +0200, Guillem Jover wrote:
> On Tue, 2021-04-13 at 15:36:08 +0200, Ivo De Decker wrote:
> > Please go ahead with the upload and remove the moreinfo tag from this bug 
> > when
> > the new version is in unstable.
> 
> Thanks! I'm targeting an upload for later today, but I was thinking I
> might try to quickly produce a tiny functional test for the
> auto-deconfigure bug. I'll update the report once I get that, and I
> could hold the upload until you approve that, but I'm not sure that's
> worth the round-trip, given that it's a test? :)

Ok, this was actually trivial, as it was pretty much like the existing
t-breaks test case but with Protected/Essential:yes added to the broken
packages.

Attached updated patch, including test case and ref.

Thanks,
Guillem
From a57b563c247f7c8025bc1e33713325452dabd2d7 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Mon, 22 Feb 2021 18:12:18 +0100
Subject: [PATCH] dpkg: Fix --auto-deconfigure for essential and protected
 during installation

Only apply the --force-remove-essential and --force-remove-protected
during package removals, which can only happen due to Conflicts,
otherwise we cannot solve auto-deconfigurations due to Breaks on essential
or protected packages during installations or upgrades.

This is a regression when the Breaks field got introduced, as the same
function that had been used for Conflicts was refactored to be used for
Breaks, but without taking into account the removal case.

Fixes: commit b301c0e71a5314bb4560111c6cf1602269f6f672
Reported-by: Julian Andres Klode 
Ref: #983014
---
 src/archives.c  |  4 ++--
 tests/Makefile  |  2 ++
 tests/t-breaks-essential/Makefile   | 13 +
 tests/t-breaks-essential/lib-a-0/DEBIAN/control |  8 
 tests/t-breaks-essential/lib-a-1/DEBIAN/control |  8 
 tests/t-breaks-essential/pkg-b/DEBIAN/control   |  8 
 tests/t-breaks-protected/Makefile   | 13 +
 tests/t-breaks-protected/lib-a-0/DEBIAN/control |  8 
 tests/t-breaks-protected/lib-a-1/DEBIAN/control |  8 
 tests/t-breaks-protected/pkg-b/DEBIAN/control   |  8 
 10 files changed, 78 insertions(+), 2 deletions(-)
 create mode 100644 tests/t-breaks-essential/Makefile
 create mode 100644 tests/t-breaks-essential/lib-a-0/DEBIAN/control
 create mode 100644 tests/t-breaks-essential/lib-a-1/DEBIAN/control
 create mode 100644 tests/t-breaks-essential/pkg-b/DEBIAN/control
 create mode 100644 tests/t-breaks-protected/Makefile
 create mode 100644 tests/t-breaks-protected/lib-a-0/DEBIAN/control
 create mode 100644 tests/t-breaks-protected/lib-a-1/DEBIAN/control
 create mode 100644 tests/t-breaks-protected/pkg-b/DEBIAN/control

diff --git a/src/archives.c b/src/archives.c
index 96079ab1f..aa56e9e9c 100644
--- a/src/archives.c
+++ b/src/archives.c
@@ -1239,7 +1239,7 @@ try_deconfigure_can(bool (*force_p)(struct deppossi *), struct pkginfo *pkg,
 warning(_("ignoring dependency problem with %s:\n%s"), action, why);
 return 2;
   } else if (f_autodeconf) {
-if (pkg->installed.essential) {
+if (removal && pkg->installed.essential) {
   if (in_force(FORCE_REMOVE_ESSENTIAL)) {
 warning(_("considering deconfiguration of essential\n"
   " package %s, to enable %s"),
@@ -1251,7 +1251,7 @@ try_deconfigure_can(bool (*force_p)(struct deppossi *), struct pkginfo *pkg,
 return 0;
   }
 }
-if (pkg->installed.is_protected) {
+if (removal && pkg->installed.is_protected) {
   if (in_force(FORCE_REMOVE_PROTECTED)) {
 warning(_("considering deconfiguration of protected\n"
   " package %s, to enable %s"),
diff --git a/tests/Makefile b/tests/Makefile
index 6a52e50e2..3b885f04e 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -53,6 +53,8 @@ TESTS_PASS += t-provides-self
 TESTS_PASS += t-provides-arch-implicit
 TESTS_PASS += t-provides-arch-qualified
 TESTS_PASS += t-breaks
+TESTS_PASS += t-breaks-protected
+TESTS_PASS += t-breaks-essential
 TESTS_PASS += t-conflicts
 TESTS_PASS += t-conflict-provide-replace-real
 TESTS_PASS += t-conflict-provide-replace-virtual
diff --git a/tests/t-breaks-essential/Makefile b/tests/t-breaks-essential/Makefile
new file mode 100644
index 0..ace63f0ef
--- /dev/null
+++ b/tests/t-breaks-essential/Makefile
@@ -0,0 +1,13 @@
+TESTS_DEB := lib-a-0 lib-a-1 pkg-b
+
+include ../Test.mk
+
+DPKG_OPTIONS += --auto-deconfigure
+
+test-case:
+	$(DPKG_INSTALL) lib-a-0.deb
+	$(DPKG_INSTALL) pkg-b.deb lib-a-1.deb
+
+test-clean:
+	$(DPKG_PURGE) pkg-b
+	$(DPKG_PURGE) --force-remove-essential lib-a
diff --git a/tests/t-breaks-essential/lib-a-0/DEBIAN/control b/tests/t-breaks-essential/lib-a-0/DEBIAN/control
new file mode 100644
index 0..7643fd86b
--- /dev/null
+++ b/tests/

Bug#986835: [pre-approval] unblock: dpkg/1.20.8

[Guillem Jover]

Hi!

On Tue, 2021-04-13 at 15:36:08 +0200, Ivo De Decker wrote:
> On Mon, Apr 12, 2021 at 06:20:10PM +0200, Guillem Jover wrote:
> > This is a pre-approval unblock request for dpkg.
> > 
> > [ Reason ]
> > 
> > This includes an RC bug fix, and an old regression affecting apt
> > with auto-deconfiguring during upgrades for Protected/Essential
> > packages,
> 
> Can you give an example of how this issue can happen (if there is a bug
> report, feel free to point at that one).

Right sorry, should have included a reference here. That'd be #983014,
I've amended the commit to include that now.

> > a regression in the perl code ignoring exceptions, and a
> > couple of recent regressions in start-stop-daemon and dpkg-realpath.
> > Then a few fixes to the test suite, affecting mostly CPAN.
> > 
> > [ Impact ]
> > 
> > The ones affecting the code would not be good to let as is. The test
> > suite ones even though not affecting Debian directly should be safe,
> > otherwise they'd not pass. :)
> > 
> > [ Tests ]
> > 
> > The unit tests and the recently merged functional test suite all pass.
> > Not all the above are covered by these, but they have been tested
> > manually otherwise. I have tests for the exception trapping, but it
> > was too invasive so I've queued it for 1.21.x instead.
> > 
> > [ Risks ]
> > 
> > The changes either affect new features (s-s-d), new features breaking
> > other parts of the code (dpkg-realpath), or behavior that would
> > currently fail anyway (auto-deconfigure for Protected/Essential),
> > and that apt will need to workaround for now via --force options.
> > 
> > There should be no behavior changes during source package building,
> > except for restoring some error failures that were currently being
> > partially ignored (for dpkg-source, but then trapped by dpkg-buildpackage
> > f.ex.).

(BTW this was not very clear here, but just in case, dpkg-buildpackage
currently fails to notice dpkg-source truly failing (because it
exits 0), but then fails due to missing files such as the .dsc f.ex.,
but if you run dpkg-source directly then you'd not get the correct
exit code.)

> > All changes are fairly minimal.
> 
> Please go ahead with the upload and remove the moreinfo tag from this bug when
> the new version is in unstable.

Thanks! I'm targeting an upload for later today, but I was thinking I
might try to quickly produce a tiny functional test for the
auto-deconfigure bug. I'll update the report once I get that, and I
could hold the upload until you approve that, but I'm not sure that's
worth the round-trip, given that it's a test? :)

> [...]
> 
> > The debdiff includes lots of noise due to the po and generated translated
> > man pages, that's why I've included the relevant split patches  excluding
> > translation updates.
> 
> Thanks for that! That made the review a lot easier.
> 
> > And the git branch is at:
> > 
> >   https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=next/1.20.8
> > 
> > unblock dpkg/1.20.8

Thanks,
Guillem

Bug#986835: [pre-approval] unblock: dpkg/1.20.8

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

This is a pre-approval unblock request for dpkg.

[ Reason ]

This includes an RC bug fix, and an old regression affecting apt
with auto-deconfiguring during upgrades for Protected/Essential
packages, a regression in the perl code ignoring exceptions, and a
couple of recent regressions in start-stop-daemon and dpkg-realpath.
Then a few fixes to the test suite, affecting mostly CPAN.

[ Impact ]

The ones affecting the code would not be good to let as is. The test
suite ones even though not affecting Debian directly should be safe,
otherwise they'd not pass. :)

[ Tests ]

The unit tests and the recently merged functional test suite all pass.
Not all the above are covered by these, but they have been tested
manually otherwise. I have tests for the exception trapping, but it
was too invasive so I've queued it for 1.21.x instead.

[ Risks ]

The changes either affect new features (s-s-d), new features breaking
other parts of the code (dpkg-realpath), or behavior that would
currently fail anyway (auto-deconfigure for Protected/Essential),
and that apt will need to workaround for now via --force options.

There should be no behavior changes during source package building,
except for restoring some error failures that were currently being
partially ignored (for dpkg-source, but then trapped by dpkg-buildpackage
f.ex.).

All changes are fairly minimal.

[ Checklist ]

  [~] all changes are documented in the d/changelog
  (except a silent indentation fix in one of the man pages,
  covered in the ChangeLog file)
  [√] I reviewed all changes and I approve them
  [~] attach debdiff against the package in testing
  (debdiff against 1.20.7 which is what's in git's master, instead
   of 1.20.7.1 which was a source rebuild due to a botched tarball
   and lived in the sid branch)

[ Other info ]

The other remaining RC I need to downgrade, as it looks like a wishlist
now, if I've understood the reopen reason correctly.

The debdiff includes lots of noise due to the po and generated translated
man pages, that's why I've included the relevant split patches  excluding
translation updates. And the git branch is at:

  https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=next/1.20.8

unblock dpkg/1.20.8

Thanks,
Guillem


dpkg-1.20.7--1.20.8.debdiff.xz
Description: application/xz
From 09b0b3ab99ba197a4fc5abf9363de32b472d9b61 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 16 Jan 2021 13:34:34 +0100
Subject: [PATCH 01/15] Test::Dpkg: Fix test data path fetching on CPAN
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

There is no guarantee that the perl used will have «.» in INC, so we
need to add an explicit «./» prefix, which we were already doing for
the autotools case. Unify the handling for autotools and CPAN, which
should fix the latter.
---
 scripts/Test/Dpkg.pm | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/scripts/Test/Dpkg.pm b/scripts/Test/Dpkg.pm
index 937f333ba..a30168975 100644
--- a/scripts/Test/Dpkg.pm
+++ b/scripts/Test/Dpkg.pm
@@ -79,12 +79,10 @@ sub test_get_data_path
 my $path = shift;
 
 if (defined $path) {
-if ($test_mode eq 'cpan') {
-return $path;
-} else {
-my $srcdir = $ENV{srcdir} || '.';
-return "$srcdir/$path";
-}
+my $srcdir;
+$srcdir = $ENV{srcdir} if $test_mode ne 'cpan';
+$srcdir ||= '.';
+return "$srcdir/$path";
 } else {
 return _test_get_caller_dir();
 }
-- 
2.31.0

From 1974f18a184a7425ffa75b70f0d24852ef61ecd1 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 16 Jan 2021 13:25:14 +0100
Subject: [PATCH 02/15] test: Set PERL in the perl test suite

There is no guarantee that the PERL environment variable will contain
the perl executable path or name. When running the test suite from the
autotools build system we always set the PERL environment variable,
but on CPAN we were not doing that, and some CPAN testers have PERL
set to its version.
---
 scripts/Build.PL.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/Build.PL.in b/scripts/Build.PL.in
index 9846ffc91..c6be8c36a 100644
--- a/scripts/Build.PL.in
+++ b/scripts/Build.PL.in
@@ -17,6 +17,7 @@ if (-e 'Build.PL.in') {
 my $class = Module::Build->subclass(
 class => 'Module::Build::Dpkg',
 code => q{
+require Config;
 require IPC::Cmd;
 
 sub find_command {
@@ -70,6 +71,7 @@ my $class = Module::Build->subclass(
 
 local $ENV{LANG} = 'C';
 local $ENV{LC_ALL} = 'C';
+local $ENV{PERL} = $Config{perlpath};
 local $ENV{DPKG_TEST_MODE} = 'cpan';
 local $ENV{DPKG_DATADIR} = 'data';
 local $ENV{DPKG_ORIGINS_DIR} = 't/origins';
-- 
2.31.0

From 3844c38302396772f78a670bb

Bug#920993: nmu: influxdb_1.6.4-1

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu influxdb_1.6.4-1 . ANY . unstable . -m "Rebuild against fixed 
golang-github-influxdata-influxql-dev (see #917041)."

Thanks,
Guillem

Bug#890791: stretch-pu: package dpkg/1.18.25

[Guillem Jover]

Hi!

On Sun, 2018-06-24 at 16:34:53 +0100, Adam D. Barratt wrote:
> Control: tags -1 = stretch confirmed
> 
> On Sun, 2018-02-18 at 22:26 +0100, Guillem Jover wrote:
> > I'd like to update dpkg in stretch. This includes several fixes for
> > documentation, regressions, misbheavior, minor security issues, and
> > a new arch definition so that DAK can accept packages using it. The
> > fixes have been in sid/buster for a while now.
> 
> With apologies for the delay in getting back to this again, please feel
> free to go ahead with the upload, so we can make sure to get this in
> for 9.5.

Thanks, I've started rechecking the branch, and preparing the release
process. To minimize string translation fuzz, I'm taking the strings
from master. I'll run this again over the functional test suite and
upload in a few hours during the morning.

Regards,
Guillem

Bug#890791: stretch-pu: package dpkg/1.18.25

[Guillem Jover]

Hi!

On Wed, 2018-02-28 at 18:45:49 +, Adam D. Barratt wrote:
> On Wed, 2018-02-28 at 16:05 +0100, Manuel A. Fernandez Montecelo wrote:
> > 2018-02-18 22:26 Guillem Jover:
> > > I'd like to update dpkg in stretch. This includes several fixes for
> > > documentation, regressions, misbheavior, minor security issues, and
> > > a new arch definition so that DAK can accept packages using it. The
> > > fixes have been in sid/buster for a while now.
> > 
> > We depend on this version being accepted and installed in the systems
> > where DAK lives to learn about the new architecture.  After that,
> > several other packages can add support for the architecture, without
> > receiving an automatic reject when uploaded.
> > 
> > It would be great if this update could enter in the next stable
> > update, so we can make progress on that front.

> We've been discussing this amongst the SRMs and are quite wary of a
> dpkg update this close to the p-u freeze. We appreciate that the
> changes individually seem self-contained but would like to have an
> update of such a key package able to be tested more than is feasible in
> the time available.
> 
> (On a related note, in practical terms it's very unlikely that there
> would be sufficient time to get the new strings that are introduced 
> translated.)

Is there perhaps anything you are waiting for me to do here?

For the strings I realized afterwards I can take the ones from sid.
I've not yet checked how many, or if I'd really need a call for
translation, but I'd rather do that only after I know which parts you
are going to accept. :) But TBH, this being gettext I'm not sure it
matters that much, as only those strings might end up not being
translated and dpkg does not have 100% coverage for all languages
anyway. :)

Thanks,
Guillem

Bug#890791: stretch-pu: package dpkg/1.18.25

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi!

I'd like to update dpkg in stretch. This includes several fixes for
documentation, regressions, misbheavior, minor security issues, and
a new arch definition so that DAK can accept packages using it. The
fixes have been in sid/buster for a while now.

Attached the git diff 1.18.24..next/1.18.x (excluding translation
updates). Also given that unfortunately this time around there are
several string changes, I might need to do a translation round before
the upload, if the changes get approved.

Also available as a branch at
<https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=next/1.18.x>.

Thanks,
Guillem
diff --git a/data/cputable b/data/cputable
index a2bd7d687..9f2a8e0e4 100644
--- a/data/cputable
+++ b/data/cputable
@@ -41,6 +41,7 @@ powerpc		powerpc		(powerpc|ppc)		32	big
 powerpcel	powerpcle	powerpcle		32	little
 ppc64		powerpc64	(powerpc|ppc)64		64	big
 ppc64el		powerpc64le	powerpc64le		64	little
+riscv64		riscv64		riscv64			64	little
 s390		s390		s390			32	big
 s390x		s390x		s390x			64	big
 sh3		sh3		sh3			32	little
diff --git a/debian/changelog b/debian/changelog
index 26a8b14cd..64d09cb40 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,44 @@
+dpkg (1.18.25) stretch; urgency=medium
+
+  [ Guillem Jover ]
+  * Parse start-stop-daemon usernames and groupnames starting with digits in
+-u and -c correctly. Reported by Bodo Eggert <7egg...@online.de>.
+  * Always use the binary version for the .buildinfo filename in
+dpkg-genbuildinfo. Reported by Raphaël Hertzog <hert...@debian.org>.
+Closes: #869236
+  * Fix integer overflow in deb(5) format version parser.
+Closes: #868356
+  * Fix directory traversal with dpkg-deb --raw-extract, by guaranteeing
+that the DEBIAN pathname does not exist. Closes: #879982
+Reported by Jakub Wilk <jw...@jwilk.net>.
+  * Do not try to recompute hashes for the .dsc file when signing binary-only
+builds in dpkg-buildpackage. Reported by Ximin Luo <infini...@debian.org>.
+  * Architecture support:
+- Add support for riscv64 CPU. Closes: #822914
+  Thanks to Manuel A. Fernandez Montecelo <m...@debian.org>
+  * Perl modules:
+- Do not normalize args past a passthrough stop word in Dpkg::Getopt.
+  Some commands pass some arguments through to another command, and
+  those must not be normalized as that might break their invocation.
+  Reported by Helmut Grohne <hel...@subdivi.de>.
+  * Documentation:
+- Update buildinfo information in dpkg-buildpackage man page to match
+  the current implementation.
+- Use correct name for archname validator value in dpkg(1) man page.
+  Reported by Niels Thykier <ni...@thykier.net.
+  * Packaging:
+- Add versioned Build-Depends on tar, due to the --clamp-mtime option
+  being used in Dpkg::Source::Archive which is used by dpkg-source,
+  used by the test suite. Closes: #877330
+
+  [ Updated programs translations ]
+  * German (Sven Joachim).
+
+  [ Updated man pages translations ]
+  * German (Helge Kreutzmann).
+
+ -- Guillem Jover <guil...@debian.org>  Sun, 18 Feb 2018 22:15:36 +0100
+
 dpkg (1.18.24) unstable; urgency=medium
 
   [ Guillem Jover ]
diff --git a/debian/control b/debian/control
index f2cd11766..1b20f8f04 100644
--- a/debian/control
+++ b/debian/control
@@ -14,6 +14,8 @@ Build-Depends:
  dpkg-dev (>= 1.17.14),
  debhelper (>= 9.20141010),
  pkg-config,
+# Needed for --clamp-mtime in dpkg-source -b.
+ tar (>= 1.28-1) ,
 # Needed for --add-location.
  gettext (>= 0.19),
 # Needed for --porefs.
diff --git a/dpkg-deb/dpkg-deb.h b/dpkg-deb/dpkg-deb.h
index bc90c271e..54a5d71fd 100644
--- a/dpkg-deb/dpkg-deb.h
+++ b/dpkg-deb/dpkg-deb.h
@@ -53,6 +53,8 @@ enum dpkg_tar_options {
 	DPKG_TAR_PERMS = DPKG_BIT(2),
 	/** Do not set tar mtime on extract. */
 	DPKG_TAR_NOMTIME = DPKG_BIT(3),
+	/** Guarantee extraction into a new directory, abort if it exists. */
+	DPKG_TAR_CREATE_DIR = DPKG_BIT(4),
 };
 
 void extracthalf(const char *debar, const char *dir,
diff --git a/dpkg-deb/extract.c b/dpkg-deb/extract.c
index b1d66ee15..f91d18ad8 100644
--- a/dpkg-deb/extract.c
+++ b/dpkg-deb/extract.c
@@ -336,15 +336,15 @@ extracthalf(const char *debar, const char *dir,
   unsetenv("TAR_OPTIONS");
 
   if (dir) {
-if (chdir(dir)) {
-  if (errno != ENOENT)
-ohshite(_("failed to chdir to directory"));
-
-  if (mkdir(dir, 0777))
+if (mkdir(dir, 0777) != 0) {
+  if (errno != EEXIST)
 ohshite(_("failed to create directory"));
-  if (chdir(dir))
-ohshite(_("failed to chdir to directory after creating it"));
+
+  if (taroption & DPKG_TAR_CREATE_DIR)
+ohshite(_("unexpected pre-existing 

Re: Accepted dpkg 1.18.19 (source) into unstable

[Guillem Jover]

Hi!

On Fri, 2017-01-27 at 16:07:32 +, Ian Jackson wrote:
> Hi, Guillem.  I'm afraid I find myself writing a critical email.

Fair enough.

> Guillem Jover writes ("Accepted dpkg 1.18.19 (source) into unstable"):
> > Date: Fri, 27 Jan 2017 05:43:36 +0100
> > Source: dpkg
> > Binary: dpkg libdpkg-dev dpkg-dev libdpkg-perl dselect
> 
> AIUI this has missed the deadline for migration into stretch.

Nope, it went in, in time. As confirmed by Niels on IRC.

> Did you intend this for stretch ?  If not then I don't think
> it was appropriate to upload it to sid.

Yes, that was the intention.

> I have just filed three bugs, at least the first two of which I think
> are troubling for stretch:
> 
>  #852822  signing buildinfo by default breaks compatibility
>  #852821  Dropping Built-For-Profiles is risky
>  #852820  Testsuite-Restrictions field is hard to use

Of those only the first one is an issue, which I had already noticed,
and was planning on fixing in .20 after the migration. But see below.

> If you did intend it for stretch, then I question the wisdom of making
> such large changes so close to the deadline.  If (as I calculate) you
> have missed the formal deadline, you will need a freeze exception.

I'm not really happy about the timing either, but I've been pretty
swamped and didn't have the time up to now. I even had to take
yesterday's off $job (which I'll have to recover during the weekend)
to finish this up. :/ And while this might seem like a bad excuse,
sometimes life does get in the way…

I will miss the deadline due to the SH and MIPS issues, which required
an upload just now, to not break the buildd network. :(

> I think at the very least changes like these:
[…]
> ought not to get a freeze exception and are unwise at this point in
> the release cycle.

Several of those commits are supporting changes as part of the other
commits. The major changes involve reproducible, regression and bug
fixes. The few cleanup commits (that are not supporting changes) are
actually very minor and/or safe IMO.

Was it unwise to do an upload so close to the deadline? Sure. But the
other option was to not do any upload, which would have been worse. And
I even pulled out required changes that were possibly more disruptive!

In any case, I'll file a bug to the release team, and see how to deal
with this now, either an age reduction to 9, or a full review or
whatever, with the understanding that things might possibly need
reverting if they deem it necessary.

Thanks,
Guillem

Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

[Guillem Jover]

On Wed, 2016-12-14 at 14:05:44 +0100, Bálint Réczey wrote:
> 2016-12-13 9:29 GMT+01:00 Bálint Réczey <bal...@balintreczey.hu>:
> > 2016-11-27 23:11 GMT+01:00 Bálint Réczey <bal...@balintreczey.hu>:
> >> 2016-11-23 2:30 GMT+01:00 Guillem Jover <guil...@debian.org>:
> >>> My mine concern is and has always been that bindnow changes the
> >>> run-time behavior (instead of the build-time one) and could break
> >>> things such as dlopen() on shared libraries or plugins and similar.
> >>> And detecting problems becomes harder, and reverting this change
> >>> iff we notice that it breaks too much might imply rebuilding an
> >>> unspecified number of packages. So in a way it feels kind of like
> >>> a transition?
> >>>
> >>> OTOH Ubuntu seems to have been enabling not only PIE and bindnow by
> >>> default in gcc for a long time, but also relro, stack-protector and
> >>> fortify. Which would seem to imply this might not break that much?
> >>> (I'm not sure why we are not enabling all those in gcc in Debian
> >>> too, but that's probably a different conversation to have if at all.)
> >>
> >> Lucas already performed the archive-wide rebuild with bindnow
> >> enabled by dpkg and we have not observed breakages specific to
> >> bindnow. IMO this is mostly due to packages already disabling
> >> bindnow through dpkg-buildflags.

But you didn't do the requested archive-wide autopkgtest run (because
"it was hard"), and even though the coverage is not great it would
be better than nothing. Requested in this case because bindnow changes
the *run-time* behavior, which is not visible or noticable in normal
circumstances by just *building* packages.

> >> Considering that we are already in the transition freeze I suggest
> >> going with enabling bindnow for all architectures in dpkg and
> >> for Stretch+1 the responsibility of setting some hardening flags
> >> could be transferred to gcc.
> >> IMO this is not a transition because the change does not affect
> >> package interdependencies.
> >
> > Is there any update on this?

I've not seen any reply from the release team, no. And as explicitly
mentioned before multiple times now, this has the potential to impact
the release by introducing subtle and possibly hard to spot errors at
*run-time*, which might be triggered by simple a upload or a binNMU w/o
the maintainer being in the loop and knowing they have enabled bindnow.
So I want the release team to be involved in ACKing this potentially
release breaking change.

I guess this is "The current PIE situation is already an unholy mess"
(which I'll cover in another mail), so let's make the mess bigger
approach to releasing the distribution…

> > We are running out of time...
> 
> I have uploaded a dpkg NMU with bindnow enabled to DELAYED/10
> according to current NMU rules. If the Release Team increases the
> severity of #835146 it can reach unstable earlier.

… seriously I'm not sure why I bothered with this thread really? And
this makes no sense whatsover. The currently uploaded dpkg 1.18.16 does
*not* contain the change, and neither will subsequent uploads, as long
as the conditions stated in my initial mail on this thread are not met,
I'm not going to merge this change for Stretch.

> >>> So at this point, I guess I still have concerns, but only very mild
> >>> ones, and would not mind one way or another, but would like input
> >>> from at least the release team, because I don't feel like possibly
> >>> deciding on this on my own, even more at this stage of the release.

Whatever,
Guillem

Bug#845304: transition: libxtables12

[Guillem Jover]

Hi!

On Tue, 2016-11-22 at 10:49:11 +0100, Arturo Borrero Gonzalez wrote:
> On 22 November 2016 at 10:39, Emilio Pozuelo Monfort  wrote:
> > To the maintainer: Why bump to a snapshot at this point in the cycle? Have 
> > the
> > rdeps been build-tested against the new libxtables? Are you aware we are in 
> > the
> > transition freeze and this is a transition?

> I bumped to a snapshot release because several people asked me to do so.

I was one of those. The changes in the snapshot are requiered for the
various translation tools, to convert from the legacy iptables to
nftables command-line syntax, or to be able to inject rules into
the nftables using iptables commands and syntax, otherwise the tools
do not see each others rulesets. I'm sorry this has caused grief for
Arturo and the Release Team. :(

We had an in-person chat several days ago with the principal
iptables/nftables developer and we mentioned that having an actual
release would be helpful, and he said that he might be doing that
soonish?

I can understand why you'd prefer a revert at this point in time, although
I think it's worth considering that given that this transition has already
been started (even though, unfortunately, via an accident), that it
involves very few packages, that it will have a positive effect on people
wanting to migrate to use nftables in Stretch, that the upload was done
in good faith, and reverting might be messy as well, perhaps it actually
it's worth letting it in?

OTOH, the conversion is usually a one-off thing, so I guess this could be
handled via backports or on another system with more up-to-date userland.

On Tue, 2016-11-22 at 12:05:35 +, Simon McVittie wrote:
> On Tue, 22 Nov 2016 at 10:49:11 +0100, Arturo Borrero Gonzalez wrote:
> > I missed the point that libxtables (which is in src:iptables) added a
> > few new symbols that triggers transitions.
> 
> Wait, *added* a few new symbols?

It also changes the «struct xtables_match», which is passed and returned
as part of the public API. So the SOVERSION bump seems warranted to me
(upstream commit 7a0992da44cfb6cab0ccd1beadcf326df8773552).

Thanks,
Guillem

[RFC] Enabling bindnow by default in dpkg-buildflags?

[Guillem Jover]

Hi!

This was discussed relatively recently, but it was not entirely clear
to me what was the conclusion, if there was any(?), about enabling
bindnow by default.

And although this got enabled by default in gcc-6 6.2.0-7 when PIE
also got enabled, it seems it got disabled in 6.2.0-10 when I pointed
out that enabling bindnow in gcc w/o enabling relro too didn't seem to
make much sense, but then I didn't notice any rationale for the
reversion, instead of say enabling relro too.


My mine concern is and has always been that bindnow changes the
run-time behavior (instead of the build-time one) and could break
things such as dlopen() on shared libraries or plugins and similar.
And detecting problems becomes harder, and reverting this change
iff we notice that it breaks too much might imply rebuilding an
unspecified number of packages. So in a way it feels kind of like
a transition?

OTOH Ubuntu seems to have been enabling not only PIE and bindnow by
default in gcc for a long time, but also relro, stack-protector and
fortify. Which would seem to imply this might not break that much?
(I'm not sure why we are not enabling all those in gcc in Debian
too, but that's probably a different conversation to have if at all.)


So at this point, I guess I still have concerns, but only very mild
ones, and would not mind one way or another, but would like input
from at least the release team, because I don't feel like possibly
deciding on this on my own, even more at this stage of the release.

Thanks,
Guillem

Re: Porter roll call for Debian Stretch

[Guillem Jover]

Hi!

On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote:
> I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for all
> arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu.
>
> My assumption was that this set of architectures need the least amount of
> additional work since they are tested already in Ubuntu, but I would be happy
> if more ports would opt in for PIE.
> 
> I plan filing wishlist bugs against dpkg and gcc with the patches
> after I rebuilt a
> few packages with the defaults.

TBH I think PIE should in fact be safer to enable globally than
bindnow, because the latter changes the run-time behavior and things
might break (perhaps even silently) when failing to load plugins
or similar.

From dpkg PoV enabling both, would at least require a full-archive
rebuild, for bindnow ideally also a full autopkgtest run (as the
updated dpkg FAQ states now, after Lucas Nussbaum approached me some
weeks ago mentioning he was willing to do such archive-wide rebuild).

Thanks,
Guillem

Re: Porter roll call for Debian Stretch

[Guillem Jover]

Hi!

On Sun, 2016-08-21 at 08:22:09 +0200, Niels Thykier wrote:
> Kurt Roeckx:
> > On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
> >>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
> >>also apply to this port? [0]
> > 
> > If -fPIE is the default will -fPIC override it?
> > 
> > It will also default to tell the linker to use -pie, but then
> > don't do it when you want to create a shared library?
> 
> I believe so.  At least, Ubuntu made PIE default in their compiler
> without having to change all SO packages to still build.

As I mentioned on IRC, the Gentoo people seems to have done so as well
in their Gentoo Hardened Toolchain project
.

> Admittedly, it could also be that GCC uses some built "compiler spec"
> files for this case (a la an implicit "-specs=$FILE"), which are similar
> to those Redhat uses for this purposes (see [1] for an example of such
> files).

I think there are some bugs tracked in Fedora about this
, And this
is what I based the dpkg patch on as a potential alternative instead
of modifying our toolchain, which I think would be preferable. But see
below.

> >>From what I understand, depending on what the .o file is going to
> > be used for you want different things:
> > - shared library: -fPIC
> > - executable: -fPIC or -fPIE both work, but prefer -fPIE
> > - static library: Same as executables
> > 
> > For static libraries we now have a policy to not use -fPIC,
> > should that then get replaced by using -fPIE?

> Honestly, I had not thought about that.  From the looks of it, de facto
> we will end up with -fPIE being the default for static libraries as well.
>   I would be supporting that change on the assumption that it requires
> less work from individual maintainers (and presumably has no notable
> downsides in the final result).

I think that's what we are getting right now for any package enabling
the "pie" build flags feature anyway.

> [1] Example spec files for this case seems to be something like:
> 
> pie-compile.specs
> """
> *cc1_options:
> + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
> """
> 
> pie-link.specs:
> """
> *self_spec:
> + %{!shared:%{!r:-pie}}
> """
> 
> NB: I manually carved them out of a diff without testing them.

That would be
,
which neither I tested. Testing should first be done for gcc, g++, gcj,
gobjc, gobjc++, gccgo (although I've not managed to use shared libraries
with latest releases, but used to be able to) and gfortran. If someone
wants to test these first to see if it works and then later on do an
archive rebuild, that would also be appreciated.

At that point I could then at least switch the current implementation
so that we can just enable the "pie" feature per package regardless of
it building prorgrams or shared libraries. Enabling it by default
globally would require the usual process described in the dpkg FAQ.

Thanks,
Guillem

Bug#826568: Bug#826161: Bug#826568: jessie-pu: package sendmail/8.14.4-8+deb8u1

[Guillem Jover]

Hi!

On Tue, 2016-07-05 at 14:41:26 +0200, Andreas Beckmann wrote:
> On 2016-07-05 11:51, Adam D. Barratt wrote:
> > On a related note, which has been mentioned before (on dda at least) -
> > please don't name your .changes file _amd64.changes if the package
> > builds amd64 binaries and they're not included in the upload. dak keeps
> 
> That's dpkg-buildpackage -g in stable. It is fixed in sid. (#826161)
> 
> Guillem, could #826161 be fixed in stable, too?

Ah certainly! I didn't mark it as a stable candidate because I was
afraid it could cause unintended problems, but if it is already
causing problems now I don't see why not. I've added a git-notes to
that commit to queue it for the next stable update.

Thanks,
Guillem

Bug#818908: jessie-pu: package dpkg/1.17.27

[Guillem Jover]

Hi!

On Tue, 2016-04-19 at 20:34:19 +0100, Adam D. Barratt wrote:
> Apologies for the delays in getting back to you. Please go ahead.

No problem! Uploaded now too.

Thanks,
Guillem

Bug#818906: wheezy-pu: package dpkg/1.16.18

[Guillem Jover]

Hi!

On Tue, 2016-04-19 at 20:36:32 +0100, Adam D. Barratt wrote:
> Control: tags -1 -moreinfo +confirmed
> 
> On Sun, 2016-03-27 at 12:07 +0200, Guillem Jover wrote:
> > On Wed, 2016-03-23 at 18:07:46 +0100, Guillem Jover wrote:
> > > On Mon, 2016-03-21 at 16:36:16 +0100, Guillem Jover wrote:
> [...]
> > > > Here's a proposed dpkg 1.16.18, with cherry picked fixes from master
> > > > (already in unstable). These include fixes for regressions, memory 
> > > > leaks,
> > > > segmentation faults, portability and interaction with tools such as
> > > > GNU tar or the system shell.
> [...]
> > > The same reply as the one for jessie applies here. I've also taken out
> > > the git log fix here, and I'm attaching the compressed full diff. Let
> > > me know if anything else needs clarification, etc.
> > 
> > Same as for the 1.17.x release, I've removed the string changes in the
> > man page and rerolled the release. Attached the new patch.
> 
> Apologies for the delay in getting back to you. Please go ahead.

No problem! Uploaded now.

Thanks,
Guillem

Bug#818906: wheezy-pu: package dpkg/1.16.18

[Guillem Jover]

Hi!

On Wed, 2016-03-23 at 18:07:46 +0100, Guillem Jover wrote:
> On Mon, 2016-03-21 at 16:36:16 +0100, Guillem Jover wrote:
> > Package: release.debian.org
> > Severity: normal
> > Tags: wheezy
> > User: release.debian@packages.debian.org
> > Usertags: pu
> 
> > Here's a proposed dpkg 1.16.18, with cherry picked fixes from master
> > (already in unstable). These include fixes for regressions, memory leaks,
> > segmentation faults, portability and interaction with tools such as
> > GNU tar or the system shell.
> > 
> > The change for Config-Version should be safe, as at worst it will have
> > no effect, otherwise packages relying on the correct behavior will
> > start to work now.
> > 
> > The «git log» fix is not yet in master though, but it should also be safe,
> > otherwise the build would simply fail. And I've just realized it's not
> > documented in debian/changelog, it will be in the ChangeLog, but I could
> > add it to debian/changelog too.
> > 
> > The changes have passed all unit tests which are part of the build,
> > and all functional test in the dpkg-tests git repo. Attached a diff
> > with translation updates filtered.
> 
> The same reply as the one for jessie applies here. I've also taken out
> the git log fix here, and I'm attaching the compressed full diff. Let
> me know if anything else needs clarification, etc.

Same as for the 1.17.x release, I've removed the string changes in the
man page and rerolled the release. Attached the new patch.

Thanks,
Guillem


dpkg-1.16.17-1.16.18.debdiff.xz
Description: application/xz

Bug#818908: jessie-pu: package dpkg/1.17.27

[Guillem Jover]

Hi!

On Wed, 2016-03-23 at 20:52:04 +0100, Julien Cristau wrote:
> On Mon, Mar 21, 2016 at 16:49:35 +0100, Guillem Jover wrote:
> > diff --git a/man/dpkg.1 b/man/dpkg.1
> > index 4e9f7a3..fb6c43e 100644
> > --- a/man/dpkg.1
> > +++ b/man/dpkg.1
> > @@ -694,8 +694,9 @@ Sent just before a processing stage starts. \fIstage\fR 
> > is one of
> >  .TP
> >  \fB\-\-status\-logger\fR=\fIcommand\fR
> >  Send machine-readable package status and progress information to the
> > -shell \fIcommand\fR's standard input. This option can be specified
> > -multiple times. The output format used is the same as in \fB\-\-status\-fd.
> > +shell \fIcommand\fR's standard input, to be run via \*(lqsh \-c\*(rq.
> > +This option can be specified multiple times.
> > +The output format used is the same as in \fB\-\-status\-fd.
> >  .RE
> >  .TP
> >  \fB\-\-log=\fP\fIfilename\fP
> > @@ -739,7 +740,7 @@ temporary files and directories.
> >  The program \fBdpkg\fP will execute when displaying the conffiles.
> >  .TP
> >  .B SHELL
> > -The program \fBdpkg\fP will execute when starting a new shell.
> > +The program \fBdpkg\fP will execute when starting a new interactive shell.
> >  .TP
> >  .B COLUMNS
> >  Sets the number of columns \fBdpkg\fP should use when displaying formatted
> 
> This change regresses translations.  As it's essentially a clarification
> rather than a fix to the previous text, wouldn't it be better to leave
> the text as-is so as not to invalidate existing translations?

I always hesitate with string changes, as PO files are designed to
cope with this gracefully, but in this case I guess it's indeed
probably not worth it. So I've removed them and rerolled the release.
Attached the new patch.

Thanks,
Guillem


dpkg-1.17.26-1.17.27.debdiff.xz
Description: application/xz

Bug#818906: wheezy-pu: package dpkg/1.16.18

[Guillem Jover]

Hi!

On Mon, 2016-03-21 at 16:36:16 +0100, Guillem Jover wrote:
> Package: release.debian.org
> Severity: normal
> Tags: wheezy
> User: release.debian@packages.debian.org
> Usertags: pu

> Here's a proposed dpkg 1.16.18, with cherry picked fixes from master
> (already in unstable). These include fixes for regressions, memory leaks,
> segmentation faults, portability and interaction with tools such as
> GNU tar or the system shell.
> 
> The change for Config-Version should be safe, as at worst it will have
> no effect, otherwise packages relying on the correct behavior will
> start to work now.
> 
> The «git log» fix is not yet in master though, but it should also be safe,
> otherwise the build would simply fail. And I've just realized it's not
> documented in debian/changelog, it will be in the ChangeLog, but I could
> add it to debian/changelog too.
> 
> The changes have passed all unit tests which are part of the build,
> and all functional test in the dpkg-tests git repo. Attached a diff
> with translation updates filtered.

The same reply as the one for jessie applies here. I've also taken out
the git log fix here, and I'm attaching the compressed full diff. Let
me know if anything else needs clarification, etc.

Thanks,
Guillem


dpkg-1.16.17-1.16.18.debdiff.xz
Description: application/xz

Bug#818908: jessie-pu: package dpkg/1.17.27

[Guillem Jover]

Hi!

On Tue, 2016-03-22 at 22:04:00 +0100, Julien Cristau wrote:
> Control: tag -1 moreinfo
> 
> On Mon, Mar 21, 2016 at 16:49:35 +0100, Guillem Jover wrote:
> 
> > Here's a proposed dpkg 1.17.27, with cherry picked fixes from master
> > (already in unstable). These include fixes for regressions, memory
> > leaks, portability, interaction with tools such as GNU tar or the
> > system shell, install-info transition, and a sync of the architectures
> > supported (in case some of these end up accepted in the archive).

> Why do the portability and architecture tables changes need to be in
> stable?

I've always included portability fixes in previous stable updates, because
they tend to not affect the code executed in Debian (so they tend to be
very low risk), and they tend to be FTBFS fixes but for systems other
than the ones we support in Debian, and because dpkg does not have other
distribution channels other than via Debian.

The arch table updates are required in case we want to add those
arches into the archive, as dak makes use of the dpkg tables in stable
AFAIK. It's also required to be able to bootstrap such ports using
only infrastrcuture from stable. I've always synced them up to now.

> > The change for Config-Version should be safe, as at worst it will have
> > no effect, otherwise packages relying on the correct behavior will
> > start to work now, it will also make upgrades easier, for example for
> > systemd, which I'm aware suffered from this problem.
> > 
> > The «git log» fix is not yet in master though, but it should also be
> > safe, otherwise the build would simply fail. And I've just realized it's
> > not documented in debian/changelog, it will be in the ChangeLog, but I
> > could add it to debian/changelog too.

> Yes, please do ship it in sid first, and please document it in
> debian/changelog.  (Or you could have explained it here, but you
> didn't, so debian/changelog will do.)

Then I think I'll just take it out, as I'm not sure yet when I'll do an
unstable upload. And instead I'll temporarily amend my local .gitconfig
(which I often forget to do). (The fix is required to avoid leaking
local repo information and divering output such as the one coming from
log.decorate=true, core.quotepath=off, diff.renames=copies and similar
into the generated ChangeLog.)

> > The changes have passed all unit tests which are part of the build,
> > and all functional test in the dpkg-tests git repo. Attached a diff
> > with translation updates filtered.

> Thanks.  Please also provide a full diff.

Ok, attached the new full diff. I've compressed it with xz because it's
huge, and I don't think I ususually provide an unfiltered one.

Thanks,
Guillem


dpkg-1.17.26-1.17.27.debdiff.xz
Description: application/xz

Bug#818908: jessie-pu: package dpkg/1.17.27

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Hi!

Here's a proposed dpkg 1.17.27, with cherry picked fixes from master
(already in unstable). These include fixes for regressions, memory
leaks, portability, interaction with tools such as GNU tar or the
system shell, install-info transition, and a sync of the architectures
supported (in case some of these end up accepted in the archive).

The change for Config-Version should be safe, as at worst it will have
no effect, otherwise packages relying on the correct behavior will
start to work now, it will also make upgrades easier, for example for
systemd, which I'm aware suffered from this problem.

The «git log» fix is not yet in master though, but it should also be
safe, otherwise the build would simply fail. And I've just realized it's
not documented in debian/changelog, it will be in the ChangeLog, but I
could add it to debian/changelog too.

The changes have passed all unit tests which are part of the build,
and all functional test in the dpkg-tests git repo. Attached a diff
with translation updates filtered.

Thanks,
Guillem
diff --git a/Makefile.am b/Makefile.am
index aa13270..c9f63d3 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -172,6 +172,7 @@ dist-hook:
 exit 1 ; \
 			fi ; \
 		done ; \
+		XDG_CONFIG_HOME= HOME= \
 		git log -C --stat 1.15.0.. >$(distdir)/ChangeLog; \
 	fi
 
diff --git a/check.am b/check.am
index 458214d..5e0d3cf 100644
--- a/check.am
+++ b/check.am
@@ -30,6 +30,7 @@ check-local: $(test_data) $(test_programs) $(test_scripts)
 	  $(TEST_ENV_VARS) \
 	  srcdir=$(srcdir) builddir=$(builddir) \
 	  PERL_DL_NONLAZY=1 \
+	  PERL5LIB=$(abs_top_srcdir)/scripts:$(abs_top_srcdir)/dselect/methods \
 	  PERL5OPT=$(TEST_COVERAGE) \
 	  $(PERL) -MTAP::Harness -e $(TEST_RUNNER) \
 	$(addprefix $(builddir)/,$(test_programs)) \
diff --git a/cputable b/cputable
index b8b2da2..b376aa0 100644
--- a/cputable
+++ b/cputable
@@ -29,6 +29,7 @@ mips		mips		mips(eb)?		32	big
 mipsel		mipsel		mipsel			32	little
 mips64		mips64		mips64			64	big
 mips64el	mips64el	mips64el		64	little
+nios2		nios2		nios2			32	little
 or1k		or1k		or1k			32	big
 powerpc		powerpc		(powerpc|ppc)		32	big
 powerpcel	powerpcle	powerpcle		32	little
diff --git a/debian/changelog b/debian/changelog
index 8b2a4d0..eca2d78 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,45 @@
+dpkg (1.17.27) jessie; urgency=medium
+
+  [ Guillem Jover ]
+  * Add more Conflicts for removed packages expecting dpkg to ship
+install-info. Namely ada-mode and octave2.1-info. Closes: #783657
+Thanks to Andreas Beckmann <a...@debian.org>.
+  * Remove trailing space before handling blank line dot-separator in
+Dpkg::Control::HashCore. Regression introduced in dpkg 1.17.25.
+Reported by Jakub Wilk <jw...@debian.org>. Closes: #789580
+  * Only use the SHELL environment variable for interactive shells.
+Closes: #788819
+  * Move tar option --no-recursion before -T in dpkg-deb. With tar > 1.28 the
+--no-recursion option is now positional, and needs to be passed before
+the -T option, otherwise the tarball will end up with duplicated entries.
+Thanks to Richard Purdie <richard.pur...@linuxfoundation.org>.
+Closes: #807940
+  * Initialize Config-Version also for packages previously in triggers-pending
+state, otherwise we end up not passing the previously configured version
+to «postinst configure», which might consider this a first install instead
+of an upgrade. Closes: #801156
+  * Fix memory leak in dpkg infodb format upgrade logic.
+  * Fix physical file offset comparison in dpkg. Closes: #808912
+Thanks to Yuri Gribov <tetra2...@gmail.com>.
+  * Add kfreebsd-armhf support to ostable and triplettable. Closes: #796283
+Thanks to Steven Chamberlain <ste...@pyro.eu.org>.
+  * Add NIOS2 support to cputable. Thanks to Marek Vasut <ma...@denx.de>.
+  * Build system:
+- Set PERL5LIB globally for the test suite to the local modules directory,
+  to avoid using the system modules. Regression introduced in dpkg 1.17.8.
+  Reported by Jérémy Bobbio <lu...@debian.org>. Closes: #801329
+- When sys_siglist is defined in the system, try to use NSIG as we cannot
+  compute the array size with sizeof(). If NSIG is missing fallback to 32
+  items. Prompted by Igor Pashev <pashev.i...@gmail.com>.
+
+  [ Updated scripts translations ]
+  * German (Helge Kreutzmann). (Various fixes)
+
+  [ Updated manpages translations ]
+  * German (Helge Kreutzmann). (Various fixes)
+
+ -- Guillem Jover <guil...@debian.org>  Sun, 20 Mar 2016 11:40:28 +0100
+
 dpkg (1.17.26) jessie-security; urgency=high
 
   [ Guillem Jover ]
diff --git a/debian/control b/debian/control
index ade9839..97f06d2 100644
--- a/debian/control
+++ b/debian/control
@@ -80,11 +80,13 @@ Conflicts:
  gcc-4.2-doc (<< 4.2.4.nf1-4~), gcj-4.2

Bug#818906: wheezy-pu: package dpkg/1.16.18

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian@packages.debian.org
Usertags: pu

Hi!

Here's a proposed dpkg 1.16.18, with cherry picked fixes from master
(already in unstable). These include fixes for regressions, memory leaks,
segmentation faults, portability and interaction with tools such as
GNU tar or the system shell.

The change for Config-Version should be safe, as at worst it will have
no effect, otherwise packages relying on the correct behavior will
start to work now.

The «git log» fix is not yet in master though, but it should also be safe,
otherwise the build would simply fail. And I've just realized it's not
documented in debian/changelog, it will be in the ChangeLog, but I could
add it to debian/changelog too.

The changes have passed all unit tests which are part of the build,
and all functional test in the dpkg-tests git repo. Attached a diff
with translation updates filtered.

Thanks,
Guillem
diff --git a/Makefile.am b/Makefile.am
index 406d3dd..cb12880 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -140,7 +140,7 @@ update-po:
 DISTCLEANFILES = ChangeLog
 
 ChangeLog:
-	git log -C --stat 1.15.0.. >$@
+	XDG_CONFIG_HOME= HOME= git log -C --stat 1.15.0.. >$@
 
 # If we create the dist tarball from the git repository, make sure
 # that we're not forgetting some files...
diff --git a/debian/changelog b/debian/changelog
index 1c5a662..19b76f3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,29 @@
+dpkg (1.16.18) wheezy; urgency=medium
+
+  * Remove trailing space before handling blank line dot-separator in
+Dpkg::Control::Hash. Regression introduced in dpkg 1.16.16.
+Reported by Jakub Wilk <jw...@debian.org>. Closes: #789580
+  * Only use the SHELL environment variable for interactive shells.
+Closes: #788819
+  * Move tar option --no-recursion before -T in dpkg-deb. With tar > 1.28 the
+--no-recursion option is now positional, and needs to be passed before
+the -T option, otherwise the tarball will end up with duplicated entries.
+Thanks to Richard Purdie <richard.pur...@linuxfoundation.org>.
+Closes: #807940
+  * Initialize Config-Version also for packages previously in triggers-pending
+state, otherwise we end up not passing the previously configured version
+to «postinst configure», which might consider this a first install instead
+of an upgrade. Closes: #801156
+  * Fix memory leaks in dpkg infodb format upgrade logic.
+  * Fix physical file offset comparison in dpkg. Closes: #808912
+Thanks to Yuri Gribov <tetra2...@gmail.com>.
+  * Do not accept empty field names in dpkg. Closes: #769111
+  * When sys_siglist is defined in the system, try to use NSIG as we cannot
+compute the array size with sizeof(). If NSIG is missing fallback to 32
+items. Prompted by Igor Pashev <pashev.i...@gmail.com>.
+
+ -- Guillem Jover <guil...@debian.org>  Sun, 20 Mar 2016 10:23:24 +0100
+
 dpkg (1.16.17) wheezy-security; urgency=high
 
   [ Guillem Jover ]
diff --git a/dpkg-deb/build.c b/dpkg-deb/build.c
index b798b1f..e83ed51 100644
--- a/dpkg-deb/build.c
+++ b/dpkg-deb/build.c
@@ -545,7 +545,8 @@ do_build(const char *const *argv)
 m_dup2(p2[1],1); close(p2[0]); close(p2[1]);
 if (chdir(dir))
   ohshite(_("failed to chdir to `%.255s'"), dir);
-execlp(TAR, "tar", "-cf", "-", "--format=gnu", "--null", "-T", "-", "--no-recursion", NULL);
+execlp(TAR, "tar", "-cf", "-", "--format=gnu", "--null", "--no-recursion",
+   "-T", "-", NULL);
 ohshite(_("unable to execute %s (%s)"), "tar -cf", TAR);
   }
   close(p1[0]);
diff --git a/lib/compat/strsignal.c b/lib/compat/strsignal.c
index 92fad03..7ff23e2 100644
--- a/lib/compat/strsignal.c
+++ b/lib/compat/strsignal.c
@@ -52,7 +52,12 @@ const char *const sys_siglist[] = {
 	"SIGTTIN",	/* 21 */
 	"SIGTTOU",	/* 22 */
 };
+# define COMPAT_NSIGLIST (int)(sizeof(sys_siglist) / sizeof(sys_siglist[0]))
 #else
+# ifndef NSIG
+#  define NSIG 32
+# endif
+# define COMPAT_NSIGLIST NSIG
 extern const char *const sys_siglist[];
 #endif
 
@@ -61,7 +66,7 @@ strsignal(int s)
 {
 	static char buf[100];
 
-	if (s > 0 && s < sizeof(sys_siglist) / sizeof(sys_siglist[0]))
+	if (s > 0 && s < COMPAT_NSIGLIST)
 		return sys_siglist[s];
 
 	sprintf(buf, _("Unknown signal %d"), s);
diff --git a/lib/dpkg/command.c b/lib/dpkg/command.c
index 859f8a1..f9b3302 100644
--- a/lib/dpkg/command.c
+++ b/lib/dpkg/command.c
@@ -216,14 +216,16 @@ command_shell(const char *cmd, const char *name)
 	const char *shell;
 	const char *mode;
 
-	shell = getenv("SHELL");
-	if (str_is_unset(shell))
-		shell = DEFAULTSHELL;
-
-	if (cmd == NULL)
+	if (cmd == NULL) {
 		mode = "

Re: [Reproducible-builds] [Reproducible] On making Stretch self-contained IRT to reproducibility

[Guillem Jover]

Hi!

On Wed, 2016-03-09 at 10:32:08 +0100, Holger Levsen wrote:
> On Mittwoch, 24. Februar 2016, Emilio Pozuelo Monfort wrote:
> > On 24/02/16 22:16, Niels Thykier wrote:
> > >- Possible lack of buildd resources to do the rebuild.  Notably, due
> > >  to Multi-Arch:same we would generally need to do the rebuild on all
> > >  architectures.
> > FWIW, that would be solved with #758616.
> 
> this bug doesnt look like it will be fixed anytime soon. (Also I'm not 
> convinced the bug this one is blocked by (#681289: "changelog and copyright 
> should be metadata") will really be implemented as suggested.)

Actually I've got code implementing the change in principle, I just
need to write the functional test cases. But recently I realized that
it might potentially get in the way of fixing a bug I found in the
current refcounting. :/ So I'll need to check that first. I can take
some time to publish more details if there's interest.

Thanks,
Guillem

Bug#799681: release.debian.org: testing.pl does not understand build-profiles

[Guillem Jover]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: tools

Hi!

The migration/testing.pl script does not understand build-profiles,
such as the ones used in the dpkg source package. The page has this
output :

,---
Dependency analysis (including build-depends; i386 only):

 dpkg depends on libio-string-perl , which is not available in testing
libio-string-perl is not available in Debian
`---

With libio-string-perl being a link to

and «is not available in Debian» being a link to
.

Thanks,
Guillem

Bug#781829: wheezy-pu: package dpkg/1.16.16

[Guillem Jover]

Hi!

On Wed, 2015-04-08 at 20:58:02 +0100, Adam D. Barratt wrote:
 Those look okay too, assuming that the structs aren't used outside of
 dpkg itself.

They are part of libdpkg, which is only ever shipped as a static
library, so this should be safe.

It seems I forgot another commit, attached. :( Sorry. This should be
the last one.

Thanks,
Guillem
From 742072b318a062702dd499f8dbc841d0095992a4 Mon Sep 17 00:00:00 2001
From: Jae Junh jaej...@embian.com
Date: Mon, 21 Jul 2014 00:55:40 +0200
Subject: [PATCH] Add powerpcel support to cputable

Cherry picked from commit fd8934117860821c3a5ddb11c51eb86b25ad97c0.

Signed-off-by: Guillem Jover guil...@debian.org
---
 cputable | 1 +
 debian/changelog | 1 +
 2 files changed, 2 insertions(+)

diff --git a/cputable b/cputable
index 506083e..1f299f9 100644
--- a/cputable
+++ b/cputable
@@ -33,6 +33,7 @@ mips64		mips64		mips64			64	big
 mips64el	mips64el	mips64el		64	little
 or1k		or1k		or1k			32	big
 powerpc		powerpc		(powerpc|ppc)		32	big
+powerpcel	powerpcle	powerpcle		32	little
 ppc64		powerpc64	(powerpc|ppc)64		64	big
 ppc64el		powerpc64le	powerpc64le		64	little
 s390		s390		s390			32	big
diff --git a/debian/changelog b/debian/changelog
index 0c94fdd..59c9250 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -34,6 +34,7 @@ dpkg (1.16.15+nmu1) UNRELEASED; urgency=low
   * Fix out-of-bounds buffer read accesses when parsing field and trigger
 names or checking package ownership of conffiles and directories.
 Reported by Joshua Rogers megaman...@gmail.com.
+  * Add powerpcel support to cputable. Thanks to Jae Junh jaej...@embian.com.
 
   [ Updated scripts translations ]
   * Fix typos in German (Helge Kreutzmann)
-- 
2.2.1.209.g41e5f3a

Bug#781829: wheezy-pu: package dpkg/1.16.16

[Guillem Jover]

Hi!

On Sat, 2015-04-04 at 08:58:01 +0100, Adam D. Barratt wrote:
 Control: tags -1 -moreinfo +confirmed

 As far as I can see, the fixes all look okay to me (and assuming they've
 been tested on a wheezy system).

Thanks. Although, sorry, I've realized I had forgotten about two other
fixes. Are the attached patches fine to include too? They have been in
unstable/jessie for a while (and approved for jessie while frozen).

Note that the second patch fixes the first one too. Trying to fix the
first problem requires pulling in most of the second patch, and I didn't
want to merge them into a single commit, to keep them as independent
fixes.

Thanks,
Guillem
From 07434a794527d37f1bec62aee3b69bd4cb671d6f Mon Sep 17 00:00:00 2001
From: Guillem Jover guil...@debian.org
Date: Tue, 11 Nov 2014 17:37:04 +0100
Subject: [PATCH 1/2] libdpkg: Do not match partial field names in control
 files

Cherry picked from commit 611305ef0e85092cc24887e040c19e9e808dd633.

There is currently no instance of any misspelled field names known to
dpkg in Debian. Only known field names are possibly affected.

Regression introduced in commit 864e230e90de1cef94c81f10582e6d99717d593b.

Closes: #769119
---
 debian/changelog | 2 ++
 lib/dpkg/parse.c | 6 --
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 9c29d6f..d7751ab 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -29,6 +29,8 @@ dpkg (1.16.15+nmu1) UNRELEASED; urgency=low
 and they come from the package fields, which are under user control.
 Regression introduced in dpkg 1.16.0. Fixes CVE-2014-8625. Closes: #768485
 Reported by Joshua Rogers megaman...@gmail.com.
+  * Do not match partial field names in control files. Closes: #769119
+Regression introduced in dpkg 1.10.
 
   [ Updated scripts translations ]
   * Fix typos in German (Helge Kreutzmann)
diff --git a/lib/dpkg/parse.c b/lib/dpkg/parse.c
index b51ca1b..446805b 100644
--- a/lib/dpkg/parse.c
+++ b/lib/dpkg/parse.c
@@ -130,7 +130,8 @@ pkg_parse_field(struct parsedb_state *ps, struct field_state *fs,
   }
 
   for (fip = fieldinfos, ip = fs-fieldencountered; fip-name; fip++, ip++)
-if (strncasecmp(fip-name, fs-fieldstart, fs-fieldlen) == 0)
+if (strncasecmp(fip-name, fs-fieldstart, fs-fieldlen) == 0 
+fip-name[fs-fieldlen] == '\0')
   break;
   if (fip-name) {
 if ((*ip)++)
@@ -151,7 +152,8 @@ pkg_parse_field(struct parsedb_state *ps, struct field_state *fs,
   fs-fieldlen, fs-fieldstart);
 larpp = pkg_obj-pkgbin-arbs;
 while ((arp = *larpp) != NULL) {
-  if (strncasecmp(arp-name, fs-fieldstart, fs-fieldlen) == 0)
+  if (strncasecmp(arp-name, fs-fieldstart, fs-fieldlen) == 0 
+  arp-name[fs-fieldlen] == '\0')
 parse_error(ps,
_(duplicate value for user-defined field `%.*s'),
fs-fieldlen, fs-fieldstart);
-- 
2.2.1.209.g41e5f3a

From ece3ccdf17da15989c2c9f031c09cce114bce666 Mon Sep 17 00:00:00 2001
From: Guillem Jover guil...@debian.org
Date: Sat, 29 Nov 2014 15:56:15 +0100
Subject: [PATCH 2/2] libdpkg, dpkg: Fix out-of-bounds read accesses

Cherry picked from commit fa1cfce24dc7c0659cb16b4a6ff09f660e318731.

Limit the buffer accesses to the size of the buffer being accessed. This
affects reads done when parsing field and trigger names, or checking the
package ownership of conffiles and directories.

Use a new length member for struct fieldinfo and nickname to avoid
recomputing the same known length over and over again, but use strlen()
instead for arbitrary fields, conffiles and directories to avoid
increaseing the memory footprint too much.

Reported-by: Joshua Rogers megaman...@gmail.com
---
 debian/changelog  |  3 ++
 lib/dpkg/parse.c  | 84 +--
 lib/dpkg/parsedump.h  |  6 
 lib/dpkg/pkg-format.c | 10 +++---
 lib/dpkg/triglib.c|  4 +--
 src/help.c|  3 +-
 6 files changed, 60 insertions(+), 50 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index d7751ab..0c94fdd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -31,6 +31,9 @@ dpkg (1.16.15+nmu1) UNRELEASED; urgency=low
 Reported by Joshua Rogers megaman...@gmail.com.
   * Do not match partial field names in control files. Closes: #769119
 Regression introduced in dpkg 1.10.
+  * Fix out-of-bounds buffer read accesses when parsing field and trigger
+names or checking package ownership of conffiles and directories.
+Reported by Joshua Rogers megaman...@gmail.com.
 
   [ Updated scripts translations ]
   * Fix typos in German (Helge Kreutzmann)
diff --git a/lib/dpkg/parse.c b/lib/dpkg/parse.c
index 446805b..e790ec5 100644
--- a/lib/dpkg/parse.c
+++ b/lib/dpkg/parse.c
@@ -51,49 +51,49 @@
  */
 const struct fieldinfo fieldinfos[]= {
   /* Note: Capitalization of field name strings is important. */
-  { Package,  f_name,w_name

Bug#781829: wheezy-pu: package dpkg/1.16.16

[Guillem Jover]

Hi!

On Fri, 2015-04-03 at 17:26:01 +0100, Adam D. Barratt wrote:
 Control: tags -1 + moreinfo
 
 On Fri, 2015-04-03 at 16:18 +0200, Guillem Jover wrote:
  There's some pending changes for dpkg targetting wheezy I'd like to
  include as part of a security upload (as agreed with the security
  team). The proposed changes have been part of unstable/jessie for a
  while. I requested additional testing from my last d-d-a mail but
  didn't get any positive or negative results back (yet?).
 
 If this is for a security update, which changes from the list that you
 provided are you asking us to approve?

In principle just the non-security related changes. The security fix
was included out of completeness. And more review is never bad!

  The prospective changelog would be something like this:
 
 Does prospective here refer just to the wording of the changelog, or
 to the list of fixes that you're proposing to include?

Sorry, that's my usual wording. Just in case something else comes up,
there are new translations, I do some rewording or typo fixing, or I
find some last minute problem for which I'd update the request, etc.

Thanks,
Guillem


-- 
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/20150404022046.gb1...@gaara.hadrons.org

Bug#781829: wheezy-pu: package dpkg/1.16.16

[Guillem Jover]

Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian@packages.debian.org
Usertags: pu

Hi!

There's some pending changes for dpkg targetting wheezy I'd like to
include as part of a security upload (as agreed with the security
team). The proposed changes have been part of unstable/jessie for a
while. I requested additional testing from my last d-d-a mail but
didn't get any positive or negative results back (yet?).

The prospective changelog would be something like this:

,---
dpkg (1.16.16) wheezy-security; urgency=low

  [ Guillem Jover ]
  * Do not leak long tar names on bogus or truncated archives.
  * Do not leak the filepackages iterator when a directory is used by other
packages.
  * Do not leak color string on «dselect --color».
  * Fix memory leaks when parsing alternatives.
  * Fix memory leaks in buffer_copy() on error conditions.
  * Fix possible out of bounds buffer read access in the error output on
bogus ar member sizes.
  * Fix file triggers/Unincorp descriptor leak on subprocesses. Regression
introduced with the initial triggers implementation in dpkg 1.14.17.
Closes: #751021
  * Fix a descriptor leak on dselect subprocesses when --debug is used.
  * Do not run qsort() over the scandir() list in libcompat if it is NULL.
  * Fix off-by-one stack buffer overrun in start-stop-daemon on GNU/Linux and
GNU/kFreeBSD if the executable pathname is longer than _POSIX_PATH_MAX.
Although this should not have security implications as the buffer is
surrounded by two arrays (so those catch accesses even if the stack
grows up or down), and we are compiling with -fstack-protector anyway.
  * Add a workaround to start-stop-daemon for bogus OpenVZ Linux kernels that
prepend, instead of appending, the  (deleted) marker in /proc/PID/exe.
Closes: #731530
  * Fix off-by-one error in libdpkg command argv size calculation.
Based on a patch by Bálint Réczey bal...@balintreczey.hu. Closes: #760690
  * Escape package and architecture names on control file parsing warning,
as those get injected into a variable that is used as a format string,
and they come from the package fields, which are under user control.
Regression introduced in dpkg 1.16.0. Fixes CVE-2014-8625. Closes: #768485
Reported by Joshua Rogers megaman...@gmail.com.

  [ Raphaël Hertzog ]
  * Drop myself from Uploaders.

  [ Updated scripts translations ]
  * Fix typos in German (Helge Kreutzmann)
  * Swedish (Peter Krefting).

  [ Updated man page translations ]
  * Fix typos in German (Helge Kreutzmann)
  * Swedish (Peter Krefting).

 -- Guillem Jover guil...@debian.org  Fri, 03 Apr 2015 15:44:39 +0200
`---

Attached the git patch series excluding translation updates.

Thanks,
Guillem
From 44a7fca84cb32bb98999546685a5492b02fa6a60 Mon Sep 17 00:00:00 2001
From: Guillem Jover guil...@debian.org
Date: Mon, 28 Apr 2014 20:48:14 +0200
Subject: [PATCH 01/15] libdpkg: Do not leak long tar names on bogus tar
 archives

Cherry picked from commit 055717db09c9b6de7bf3cd9e12fd579d8002e565.

Make sure we free the long names, in case of a bogus or truncated
tar archive with long entries not followed by a normal entry.

Warned-by: coverity
---
 debian/changelog | 3 +++
 lib/dpkg/tarfn.c | 4 
 2 files changed, 7 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 6313a1d..08e2fa6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,8 @@
 dpkg (1.16.15+nmu1) UNRELEASED; urgency=low
 
+  [ Guillem Jover ]
+  * Do not leak long tar names on bogus or truncated archives.
+
   [ Updated scripts translations ]
   * Fix typos in German (Helge Kreutzmann)
   * Swedish (Peter Krefting).
diff --git a/lib/dpkg/tarfn.c b/lib/dpkg/tarfn.c
index 90d5071..5b3b39b 100644
--- a/lib/dpkg/tarfn.c
+++ b/lib/dpkg/tarfn.c
@@ -377,6 +377,10 @@ tar_extractor(void *ctx, const struct tar_operations *ops)
 		free(symlink_head);
 		symlink_head = symlink_node;
 	}
+	/* Make sure we free the long names, in case of a bogus or truncated
+	 * tar archive with long entries not followed by a normal entry. */
+	free(next_long_name);
+	free(next_long_link);
 
 	if (status  0) {
 		/* Indicates broken tarfile: “Read partial header record”. */
-- 
2.2.1.209.g41e5f3a

From 7c4c359473481f15aa0e8b6d2a0113cc723964b2 Mon Sep 17 00:00:00 2001
From: Guillem Jover guil...@debian.org
Date: Mon, 28 Apr 2014 21:54:52 +0200
Subject: [PATCH 02/15] dpkg: Do not leak the filepackages_iterator in
 dir_is_used_by_others()

Cherry picked from commit b6788715227adb30ba41b5a049d1cbfb9e3ff1d7.

Warned-by: coverity
---
 debian/changelog | 2 ++
 src/help.c   | 1 +
 2 files changed, 3 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 08e2fa6..7e85c2d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,8 @@ dpkg (1.16.15+nmu1) UNRELEASED; urgency=low
 
   [ Guillem Jover ]
   * Do not leak long tar names on bogus or truncated archives.
+  * Do not leak the filepackages

Bug#777646: pre-approval: unblock: dpkg/1.17.24

[Guillem Jover]

Control: tags -1 - moreinfo

Hi!

On Sun, 2015-02-22 at 09:29:33 +0100, Niels Thykier wrote:
 Control: tags -1 confirmed moreinfo
 
 On 2015-02-21 08:35, Guillem Jover wrote:
  I'm attaching the two other patches targetted for 1.17.x. The revert
  passes the functional test suite (although I've disabled three tests
  that require dependency checks on trigger processing).
 
 Thanks - please go ahead and upload this to unstable.

Uploaded now. I've ended up removing the dependency checks instead of
disabling them via the preprocessor, as I had missed an unused variable
warning, and leaving the code there didn't seem to make much sense
anyway.

Thanks,
Guillem


-- 
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/20150223003551.ga27...@gaara.hadrons.org

Re: More trigger cycles

[Guillem Jover]

Hi!

On Wed, 2015-02-18 at 19:00:23 +0100, Niels Thykier wrote:
 Based on #778695, it seems like we still have trigger cycles.  At this
 point in the freeze, I am afraid it is too late to fix the remaining cycles.
 
 I have asked Johannes if this kind of trigger cycles can be found via
 his script.  If so, hopefully we can have them eliminated for Stretch,
 but as said - we are over 3 months into the freeze and these trigger
 cycles are still biting us.

Ok. I'll take a look at those anyway to see what's going on.

 @dpkg maintainers: Please make the necessary changes to revert the
 trigger cycle error or have dpkg recover from it automatically
 immediately without aborting the upgrade.

Sure, I've now disabled the dependency checks and will proceed with a
full test suite run, will update the pre-approval request later today.

From my part, sorry for the trouble, I guess I didn't anticipate the
archive would be in such a bad state regarding the trigger cycles. :/

Thanks,
Guillem


--
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/20150220164238.ga17...@gaara.hadrons.org

Bug#777646: pre-approval: unblock: dpkg/1.17.24

[Guillem Jover]

Hi!

On Wed, 2015-02-11 at 11:40:39 +0100, Andreas Beckmann wrote:
 +  * Switch versioned Breaks for trigger cycles from  to = relations (with
 +the necessary version adjustments).
 
 Your changelog and commit message describe the change in the wrong direction,
 the patch shows it the other way:

Nice catch! Fixed locally.

I'm attaching the two other patches targetted for 1.17.x. The revert
passes the functional test suite (although I've disabled three tests
that require dependency checks on trigger processing).

Thanks,
Guillem
From 567be0ef2128dc6add2261d376559ec0ea8de0e5 Mon Sep 17 00:00:00 2001
From: Guillem Jover guil...@debian.org
Date: Fri, 20 Feb 2015 17:20:04 +0100
Subject: [PATCH] dpkg: Disable dependency checks on trigger processing

There are still trigger showing up this close to the Debian release,
which are hard to detect automatically as they are caused by maintainer
script actions.

The checks are only removed in the 1.17.x series, and will be kept in
force for the 1.18.x series.

Requested-by: Niels Thykier ni...@thykier.net (Debian Release Manager)
---
 debian/changelog |  4 
 src/trigproc.c   | 12 
 2 files changed, 16 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 53f512f..da2bfcc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -13,6 +13,10 @@ dpkg (1.17.24) UNRELEASED; urgency=low
   * Check that HAVE_DECL_SYS_SIGLIST is 0 instead of undefined, to fix a
 build failure on uclibc based systems. Closes: #777044
 Based on a patch by Alex Potapenko opotape...@gmail.com.
+  * Disable dependency checks on trigger processing. There are still trigger
+cycles showing up this close to the Debian release, which are hard to
+detect automatically as they are caused by maintainer script actions.
+Requested by Niels Thykier ni...@thykier.net (Debian Release Manager).
 
  -- Guillem Jover guil...@debian.org  Mon, 02 Feb 2015 19:46:07 +0100
 
diff --git a/src/trigproc.c b/src/trigproc.c
index bb17346..77b4877 100644
--- a/src/trigproc.c
+++ b/src/trigproc.c
@@ -365,11 +365,18 @@ trigproc(struct pkginfo *pkg, enum trigproc_type type)
 	pkg-clientdata-trigprocdeferred = NULL;
 
 	if (pkg-trigpend_head) {
+/*
+ * Disable dependency checks on trigger processing only for the 1.17.x cycle
+ * as it is causing too much problems too close to the Debian jessie release.
+ */
+#if 0
 		enum dep_check ok;
+#endif
 
 		assert(pkg-status == PKG_STAT_TRIGGERSPENDING ||
 		   pkg-status == PKG_STAT_TRIGGERSAWAITED);
 
+#if 0
 		if (dependtry  1) {
 			gaveup = check_trigger_cycle(pkg);
 			if (gaveup == pkg)
@@ -421,6 +428,11 @@ trigproc(struct pkginfo *pkg, enum trigproc_type type)
 			if (gaveup == pkg)
 return;
 		}
+#else
+		gaveup = check_trigger_cycle(pkg);
+		if (gaveup == pkg)
+			return;
+#endif
 
 		printf(_(Processing triggers for %s (%s) ...\n),
 		   pkg_name(pkg, pnaw_nonambig),
-- 
2.2.1.209.g41e5f3a

From ee90d408f0f549aa1e686270fddaf2edaa4ed45f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= hert...@debian.org
Date: Wed, 11 Feb 2015 08:33:21 +0100
Subject: [PATCH] debian: drop myself from Uploaders

Cherry picked from commit 10ff6c4fc598dbc9697c825a8c8e1bf25caa2fcb.

Signed-off-by: Guillem Jover guil...@debian.org
---
 debian/changelog | 3 +++
 debian/control   | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index da2bfcc..9ef67a9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -18,6 +18,9 @@ dpkg (1.17.24) UNRELEASED; urgency=low
 detect automatically as they are caused by maintainer script actions.
 Requested by Niels Thykier ni...@thykier.net (Debian Release Manager).
 
+  [ Raphaël Hertzog ]
+  * Drop myself from Uploaders.
+
  -- Guillem Jover guil...@debian.org  Mon, 02 Feb 2015 19:46:07 +0100
 
 dpkg (1.17.23) unstable; urgency=low
diff --git a/debian/control b/debian/control
index 18fe580..12fb93f 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: dpkg
 Section: admin
 Priority: required
 Maintainer: Dpkg Developers debian-d...@lists.debian.org
-Uploaders: Guillem Jover guil...@debian.org, Raphaël Hertzog hert...@debian.org
+Uploaders: Guillem Jover guil...@debian.org
 Origin: debian
 Bugs: debbugs://bugs.debian.org
 Homepage: https://wiki.debian.org/Teams/Dpkg
-- 
2.2.1.209.g41e5f3a

Bug#777646: pre-approval: unblock: dpkg/1.17.24

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi!

I'd like to upload dpkg 1.17.24 with the following changes. I'm including
the patch series w/ translation commits omitted.

All trigger cycle generating packages should now be fixed (and unblocked)
I think. The only remaining problem I know of is the gconf2 issue Andreas
reported, which at first sight looks like the dbus issue, but I'm going
to be looking at in more detail.

The dpkg-statoverride change required translation updates, but I
managed to infer them out from the shadow package, except Vietnamese
and Thai for which I had doubts or no translation at all, but the
translators were very swift.

Here's the full changelog:

,---
dpkg (1.17.24) unstable; urgency=low

  [ Guillem Jover ]
  * Add missing versioned Breaks on packages creating trigger cycles.
Namely debian-security-support, doc-base, gitweb, grace, install-info,
libapache2-mod-php5, libapache2-mod-php5filter, php5-fpm and xine-ui.
Closes: #774794
  * Switch versioned Breaks for trigger cycles from  to = relations (with
the necessary version adjustments).
  * Add Conflicts for removed packages expecting dpkg to ship install-info.
Namely octave3.2-info, octave3.0-info and polgen-doc. Closes: #776984
  * Do not accept unknown user or group names on «dpkg-statoverride --add».
Regression introduced in dpkg 1.17.11. Closes: #775124
  * Check that HAVE_DECL_SYS_SIGLIST is 0 instead of undefined, to fix a
build failure on uclibc based systems. Closes: #777044
Based on a patch by Alex Potapenko opotape...@gmail.com.

  [ Updated programs translations ]
  * All complete languages (shadow package).
  * Thai (Theppitak Karoonboonyanan).

 -- Guillem Jover guil...@debian.org  Tue, 10 Feb 2015 19:48:59 +0100
`---

Thanks,
Guillem
From 4ac8a7e2c1dd72492ee9f23aebbbdf8e299af089 Mon Sep 17 00:00:00 2001
From: Guillem Jover guil...@debian.org
Date: Mon, 2 Feb 2015 20:14:50 +0100
Subject: [PATCH 1/5] debian: Add missing versioned Breaks on packages creating
 trigger cycles

Closes: #774794
---
 debian/changelog | 5 -
 debian/control   | 9 +
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index b2d83f9..6237a95 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,9 @@
 dpkg (1.17.24) UNRELEASED; urgency=low
 
-  *
+  * Add missing versioned Breaks on packages creating trigger cycles.
+Namely debian-security-support, doc-base, gitweb, grace, install-info,
+libapache2-mod-php5, libapache2-mod-php5filter, php5-fpm and xine-ui.
+Closes: #774794
 
  -- Guillem Jover guil...@debian.org  Mon, 02 Feb 2015 19:46:07 +0100
 
diff --git a/debian/control b/debian/control
index a1e3409..93ee039 100644
--- a/debian/control
+++ b/debian/control
@@ -41,19 +41,28 @@ Breaks: dpkg-dev ( 1.15.8), libdpkg-perl ( 1.15.8),
  auctex (= 11.87-3),
  ccache ( 3.1.10-1),
  cups ( 1.7.5-10),
+ debian-security-support ( 2014.10.26),
  distcc ( 3.1-6.1),
+ doc-base ( 0.10.5),
  fusionforge-plugin-mediawiki ( 5.3.2+20141104-3),
  gap-core ( 4r7p5-2),
+ gitweb ( 1:2.1.4-2.1),
+ grace ( 1:5.1.24-3),
  gxine (= 0.5.908-3),
  hoogle ( 4.2.33-4),
  icecc (= 1.0.1-1),
+ install-info ( 5.1.dfsg.1-3),
+ libapache2-mod-php5 ( 5.6.4+dfsg-3),
+ libapache2-mod-php5filter ( 5.6.4+dfsg-3),
  libjs-protoaculous ( 5),
  man-db ( 2.6.3-6), fontconfig ( 2.11.0-6.2),
  mcollective ( 2.6.0+dfsg-2.1),
+ php5-fpm ( 5.6.4+dfsg-3),
  pypy ( 2.4.0+dfsg-3),
  readahead-fedora ( 2:1.5.6-5.2),
  wordpress ( 4.1+dfsg-1),
  xfonts-traditional ( 1.7),
+ xine-ui ( 0.99.9-1.2),
 # These do not support triggers.
  apt ( 0.7.7), aptitude ( 0.4.7-1)
 Conflicts:
-- 
2.2.1.209.g41e5f3a

From cde74ec0f0f4aec1d7e6bb7d12e08032ea4538bb Mon Sep 17 00:00:00 2001
From: Guillem Jover guil...@debian.org
Date: Mon, 2 Feb 2015 20:27:11 +0100
Subject: [PATCH 2/5] debian: Switch versioned Breaks for trigger cycles from
  to = relations

Adjust to the versions actually fixing the trigger cycles.
---
 debian/changelog | 2 ++
 debian/control   | 6 +++---
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 6237a95..2588b82 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,6 +4,8 @@ dpkg (1.17.24) UNRELEASED; urgency=low
 Namely debian-security-support, doc-base, gitweb, grace, install-info,
 libapache2-mod-php5, libapache2-mod-php5filter, php5-fpm and xine-ui.
 Closes: #774794
+  * Switch versioned Breaks for trigger cycles from  to = relations (with
+the necessary version adjustments).
 
  -- Guillem Jover guil...@debian.org  Mon, 02 Feb 2015 19:46:07 +0100
 
diff --git a/debian/control b/debian/control
index 93ee039..49717fc 100644
--- a/debian/control
+++ b/debian/control
@@ -38,7 +38,7 @@ Depends: ${misc:Depends}
 Breaks: dpkg-dev ( 1.15.8), libdpkg-perl ( 1.15.8),
 # These cause trigger cycles due to using awaiting trigger directives

Re: new pre-dependency: perl{,-base,-modules} - dpkg (= 1.17.17)

[Guillem Jover]

[ CCing debian-release. ]

Hi!

On Sun, 2015-01-18 at 20:12:55 +0200, Niko Tyni wrote:
 In order to fix trigger related wheezy-jessie upgrade failures in
 xfonts-traditional (#774844, cc'd), I intend to make the main perl
 binary packages (perl, perl-base, and perl-modules) Pre-Depend on dpkg
 (= 1.17.17), which has this change:
 
   * Defer trigger processing if the package does not fulfill dependencies.
 Closes: #671711
 
 Together with making the jessie perl-modules and perl-base Break the
 wheezy perl, this should ensure that the xfonts-traditional trigger will
 not run when perl is in a broken state during upgrades.
 
 Please see the #774844 bug log for details, and let me know if you have
 objections or other suggestions.

I've not looked into the details yet, but just to comment that there's
been talk about possibly reverting that fix, because in some error
situations it can get apt into an unrecoverable state (#774124). :(

Of course reverting that fix brings back all upgrade issues related
to trigger processing w/o the required dependencies. Which are
probably more, and easier to get into.

(I guess this just calls for both a fixed apt, and a dpkg that
workarounds any such situation.)

Thanks,
Guillem


-- 
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/20150119101504.gc20...@gaara.hadrons.org

Bug#773256: dbus + triggers + apt issue (was: Bug#773256: pre-approval: unblock: dpkg/1.17.23)

[Guillem Jover]

Hi!

On Tue, 2015-01-13 at 15:08:01 +0100, Michael Vogt wrote:
 On Thu, Jan 08, 2015 at 02:47:05AM +0100, Guillem Jover wrote:
  [ Re dbus issue ]
   Noted.  Do we (still?) have a (reliable) way of reproducing the dbus
   trigger issue?
  
  We didn't up to now (AFAIK), but there's now very valuable data from
  Karl Ljungkvist at #774124. I've been able to reproduce the issue with
  that status file and apt (over a clean debootstrap of jessie, and
  adding i386 as a foreign arch). 
 
 Thanks for pointing us towards this bugreport, this contains some good
 information. I followed up there with some more questions, it would be
 really nice to be able to reproduce what error happend that caused
 this broken state.

The bug probably deserves to be reassigned to apt, I'll do that later.

Unfortunately it seems many if not all of these instances where also
affected by the apt bug eating dpkg's output. :(

I've some code locally that will log dpkg errors to the log file, but
didn't even try to get this into jessie due to the deep freeze. Will
be included with 1.18.x in any case.

  And have been trying out several things:
  
* It seems to affect both apt from jessie/sid and wheezy. :(
  apt gets into a state it cannot recover from by itself.
 
 Indeed, apt sees the triggers-pending and triggers-awaited state
 and tries to run dpkg --configure on all those packages. This
 fails.

Because I'm assuming apt is simply not taking into account the
unsatisfied dependencies for those package states?

* «dpkg --configure --pending» solves the issue.
* Using dpkg --force-configure-any only fixes the issue partially, :(
  because apt does not notice that the package has been implicitly
  configured, and tries to configure the package again and dpkg exits
  with an error for that run, which apt does not like much either (as
  I feared). So I'd need to also change dpkg to not fail configuring
  an already configure package, or try to detect that specific case.
 
 When you say implicitly configured what does that mean exactly? Is
 the issue here that apt should ignore the triggers-awaited state
 because those will be dealt with by dpkg entirely?

In normal conditions, when dpkg is called with an explicit list of
packages to configure, it will only configure those.

When using dpkg with --force-configure-any, if there's an unsatisfied
dependency that could be fixed by configuring another package, then
dpkg will also enqueue that package for configuration. Which means that
even though apt didn't request its configuration, it got configured
(implicitly) anyway.

Ideally apt would notice this through the status-fd updates, and not
try to configure that package explicitly afterwards, but it seems this
is not currently the case? And dpkg fails when apt requests to
configure the already configured package.

Otherwise enabling --force-configure-any by default in dpkg, would be
a sufficient workaround for this issue.

 I also wonder if there are further implications for apt by the trigger
 changes. The ordering code in apt builds on the premise that there is
 no implict configuration, it builds the unpack/configure ordering
 early and its static. Is this still a valid assumption?

As long as --force-configure-any is not used (which is the case
currently), then yes, there's no implicit configuration going on. I
was just checking if that would be a viable workaround for the dbus
issue. But due to the current apt behavior, that is not a viable
workaround by itself, it might require more changes in dpkg.

The only implication that I assume was not being taken into account
previously is that for dpkg to be able to process pending triggers,
the dependencies for that package need to be satisfied.

 [..] 
  Before considering either reverting, or trying to find a workaround
  for this in dpkg, I'd like to know if this is easily fixable in apt
  and the implications of this problem (i.e. can it affect similar
  situations regardless of the recent dpkg trigger changes?) and the
  implications of such a fix.
 
 We have code in pkgApplyStatus that detects and fixes not-ok
 packages. So far it considered packages with
 triggers-{pending,awaited} as something to just dpkg --configure. We
 could change the code to ignore those states and simply let dpkg
 handle them (via Davids code that ensures 'dpkg --configure -a' gets
 called). Does that sound sensible?

That should indeed in theory fix the issue (depending where apt runs
that command). The other option is to micromanage dpkg even more, by
checking for unsatisfied dependencies, and configuring those first. I'd
rather go with the first, as a way to start micromanaging dpkg less.

 I'm still a bit nervous about the issue that lead to #774124. It would
 be good to get more data here.

Indeed, that's why I wanted to get you guys to take a look at it
before proceeding with a decision or fixes/workarounds in dpkg. If it
ends up being a very localized problem of apt

Bug#773256: dbus + triggers + apt issue (was: Bug#773256: pre-approval: unblock: dpkg/1.17.23)

[Guillem Jover]

[ @deity: please check out the dbus issue below. ]

Hi!

On Sat, 2014-12-27 at 18:45:38 +0100, Niels Thykier wrote:
 I hope you are feeling better now. :)

Yes, much better, thanks. :)

 TL;DR: Please upload dpkg/1.17.23 with the proposed fix for #771730 at
 your earliest convenience - by the looks of it, might fix one or two of
 our upgrade tests on jenkins.d.n.

Thanks for the unblock.

[ Re dbus issue ]
 Noted.  Do we (still?) have a (reliable) way of reproducing the dbus
 trigger issue?

We didn't up to now (AFAIK), but there's now very valuable data from
Karl Ljungkvist at #774124. I've been able to reproduce the issue with
that status file and apt (over a clean debootstrap of jessie, and
adding i386 as a foreign arch). And have been trying out several things:

  * It seems to affect both apt from jessie/sid and wheezy. :(
apt gets into a state it cannot recover from by itself.
  * «dpkg --configure --pending» solves the issue.
  * Using dpkg --force-configure-any only fixes the issue partially, :(
because apt does not notice that the package has been implicitly
configured, and tries to configure the package again and dpkg exits
with an error for that run, which apt does not like much either (as
I feared). So I'd need to also change dpkg to not fail configuring
an already configure package, or try to detect that specific case.

This is the (trimmed) «dpkg -C» output for the broken status file:

,---
The following packages have been unpacked but not yet configured.
They must be configured using dpkg --configure or the configure
menu option in dselect for them to work:
 bluezBluetooth tools and daemons
 bzip2high-quality block-sorting file compressor - utilities
 libdbus-1-3:amd64simple interprocess messaging system (library)
 libdbus-1-3:i386 simple interprocess messaging system (library)
 libdbus-1-dev:amd64  simple interprocess messaging system (development headers
 libperl5.20  shared Perl library
 perl Larry Wall's Practical Extraction and Report Language
 perl-modules Core Perl modules
 systemd-sysv system and service manager - SysV links
 tzdata-java  time zone and daylight-saving time data for use by java r

The following packages are awaiting processing of triggers that they
have activated in other packages.  This processing can be requested using
dselect or dpkg --configure --pending (or dpkg --triggers-only):
 systemd  system and service manager

The following packages have been triggered, but the trigger processing
has not yet been done.  Trigger processing can be requested using
dselect or dpkg --configure --pending (or dpkg --triggers-only):
 dbus simple interprocess messaging system (daemon and utilitie
`---

And here's the «apt-get install -f -s» output:

,---
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following extra packages will be installed:
  libpam-systemd
The following packages will be upgraded:
  libpam-systemd
1 upgraded, 0 newly installed, 0 to remove and 238 not upgraded.
10 not fully installed or removed.
Conf systemd-sysv (215-8 Debian:testing [amd64]) [libpam-systemd:amd64 ]
Inst libpam-systemd [215-7] (215-8 Debian:testing [amd64])
Conf libdbus-1-3 (1.8.12-3 Debian:testing [amd64])
Conf libdbus-1-3:i386 (1.8.12-3  [i386])
Conf bzip2 (1.0.6-7+b2 Debian:testing [amd64])
Conf perl-modules (5.20.1-4 Debian:testing [all])
Conf perl (5.20.1-4 Debian:testing [amd64])
Conf bluez (5.23-2 Debian:testing [amd64])
Conf libdbus-1-dev (1.8.12-3 Debian:testing [amd64])
Conf libperl5.20 (5.20.1-4 Debian:testing [amd64])
Conf tzdata-java (2014j-1 Debian:testing [all])
Conf libpam-systemd (215-8 Debian:testing [amd64])
`---

Trying to run the first action gives the undesired unsatisfied trigger
dependency problem:

,---
$ dpkg --configure systemd-sysv
dpkg: dependency problems prevent processing triggers for dbus:
 dbus depends on libdbus-1-3 (= 1.7.6); however:
  Package libdbus-1-3:amd64 is not configured yet.

dpkg: error processing package dbus (--configure):
 dependency problems - leaving triggers unprocessed
[…]
dpkg: too many errors, stopping
Errors were encountered while processing:
 dbus
[…]
Processing was halted because there were too many errors.
`---

Before considering either reverting, or trying to find a workaround
for this in dpkg, I'd like to know if this is easily fixable in apt
and the implications of this problem (i.e. can it affect similar
situations regardless of the recent dpkg trigger changes?) and the
implications of such a fix.

Thanks,
Guillem


-- 
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/20150108014705.gc30...@gaara.hadrons.org

Bug#773256: pre-approval: unblock: dpkg/1.17.23

[Guillem Jover]

Hi!

On Tue, 2014-12-23 at 02:52:01 +0100, Guillem Jover wrote:
 On Sun, 2014-12-21 at 21:38:31 +0100, Niels Thykier wrote:
  I do not recall (all of?) these trigger cycles being known.  @Guiliem,
  can you have a look at them and file bugs as necessary for these?
 
 These smell like instances of #771730 (more so when libc-bin is
 noawait), but I fired up a test upgrade with 1.17.23 to make sure.

Ok, after several GiBs of downloads and unpacks, the upgrade went fine
with dpkg 1.17.23 for education-thin-client-server. I'll leave one of
the other ones testing during the night, but I don't expect any
problems either.

On Tue, 2014-12-23 at 04:36:07 +0100, Guillem Jover wrote:
 On Sun, 2014-12-21 at 09:57:51 +0100, Niels Thykier wrote:
It possibly still is since the version that introduced the trigger
  checks.  I hope we can have it resolved shortly.
 
 Yeah, I'm planning to upload tomorrow, sorry about the delay, was not
 feeling quite well the past couple of days.

Actually, I just noticed the bug was not tagged confirmed, so given
this, the wordpress situation, and the questions you posed in the
previous email, I'll hold off the upload, which is tested and ready
for when I get a go.

Thanks,
Guillem


-- 
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/20141224012624.ga24...@gaara.hadrons.org

Bug#773256: pre-approval: unblock: dpkg/1.17.23

[Guillem Jover]

On Wed, 2014-12-24 at 02:26:24 +0100, Guillem Jover wrote:
 On Tue, 2014-12-23 at 02:52:01 +0100, Guillem Jover wrote:
  On Sun, 2014-12-21 at 21:38:31 +0100, Niels Thykier wrote:
   I do not recall (all of?) these trigger cycles being known.  @Guiliem,
   can you have a look at them and file bugs as necessary for these?
  
  These smell like instances of #771730 (more so when libc-bin is
  noawait), but I fired up a test upgrade with 1.17.23 to make sure.
 
 Ok, after several GiBs of downloads and unpacks, the upgrade went fine
 with dpkg 1.17.23 for education-thin-client-server. I'll leave one of
 the other ones testing during the night, but I don't expect any
 problems either.

… And the haskell one went well too.

Thanks,
Guillem


-- 
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/20141224064301.ga24...@gaara.hadrons.org

Bug#773256: pre-approval: unblock: dpkg/1.17.23

[Guillem Jover]

Hi!

On Sun, 2014-12-21 at 21:38:31 +0100, Niels Thykier wrote:
 Thanks.  We noticed the following results with the dpkg/1.17.22:
 
 
  19:49  h01ger 
  https://jenkins.debian.net/view/chroot-installation/view/upgrade%20wheezy2jessie/job/chroot-installation_wheezy_install_haskell_upgrade_to_jessie/lastBuild/console
   not sure if i have seen this already:
  19:50  h01ger dpkg: cycle found while processing triggers:
  19:50  h01ger  chain of packages whose triggers are or may be responsible:
  19:50  h01ger   doc-base - libc-bin
  19:50  h01ger 
  https://jenkins.debian.net/view/chroot-installation/view/upgrade%20wheezy2jessie/job/chroot-installation_wheezy_install_education-desktop-other_upgrade_to_jessie/lastBuild/console
   has
  19:50  h01ger   desktop-file-utils - libc-bin
  19:50  h01ger 
  https://jenkins.debian.net/view/chroot-installation/view/upgrade%20wheezy2jessie/job/chroot-installation_wheezy_install_education-standalone_upgrade_to_jessie/lastBuild/console
   OTOH has
  19:50  h01ger   gnome-icon-theme - libc-bin
  19:51  h01ger education-workstation_upgrade_to_jessie is boringly 
  repeating education-desktop-other_upgrade_to_jessie ;)
  19:55  h01ger 
  https://jenkins.debian.net/view/chroot-installation/view/upgrade%20wheezy2jessie/job/chroot-installation_wheezy_install_education-thin-client-server_upgrade_to_jessie/lastBuild/console
   has  something new:
  19:55  h01ger   gconf2 - desktop-file-utils
  19:55  h01ger nthykier: 
  https://jenkins.debian.net/view/chroot-installation/view/upgrade%20wheezy2jessie/
   updated + done
 
 
 The last one with a bit more details:
 
  Setting up libdevmapper1.02.1:amd64 (2:1.02.90-2) ...
  dpkg: cycle found while processing triggers:
   chain of packages whose triggers are or may be responsible:
gconf2 - desktop-file-utils
   packages' pending triggers which are or may be unresolvable:
libc-bin: ldconfig
desktop-file-utils: /usr/share/applications
gconf2: /usr/share/gconf/schemas
  dpkg: error processing package libc-bin (--configure):
   triggers looping, abandoned
  Errors were encountered while processing:
   libc-bin
 

 I do not recall (all of?) these trigger cycles being known.  @Guiliem,
 can you have a look at them and file bugs as necessary for these?

These smell like instances of #771730 (more so when libc-bin is
noawait), but I fired up a test upgrade with 1.17.23 to make sure.

Thanks,
Guillem


-- 
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/20141223015201.gb14...@gaara.hadrons.org

Bug#773256: pre-approval: unblock: dpkg/1.17.23

[Guillem Jover]

Hi!

On Sun, 2014-12-21 at 09:57:51 +0100, Niels Thykier wrote:
   It possibly still is since the version that introduced the trigger
 checks.  I hope we can have it resolved shortly.

Yeah, I'm planning to upload tomorrow, sorry about the delay, was not
feeling quite well the past couple of days.

  It seems that only gxine and icecc are missing now.  If so, please go
  ahead with the .23 with versioned breaks for them as well.  Worst case,
  I will have them removed from testing - best case, they will be fixed.
I will take the political fall-out of this and notify the maintainers
  of the affected packages.  Let me know if I missed any packages.
  
  Unfortunately there's still auctex, gxine, icecc, mcollective, pypy
  and wordpress. And I'm not sure if the fix for all of them might be
  a strightforward switch to a -noawait directive.
 
 Indeed I missed those.  For reference, pypy got fixed and gxine, icecc
 and mcollective will get auto-removed eventually.  My previous remark
 for gxine plus icecc applies equally to mcollective (and pypy, in case
 migration is stalled) as well.
   This leaves auctex as the only remaining blocker auctex.

In the meantime mcollective also got fixed, which leaves auctex, gxine,
icecc and wordpress. The latter has a fixed package sitting in NEW
(but I'm not sure it will be accepted and allowed to migrate?).

I've added  versioned Breaks for the packages with fixed versions,
and = for the ones with unfixed ones against the version in testing
(as for auctex it differs against unstable).

  I've also not added the --force-configure-any default switch, because we
  don't really know what happened with apt and dbus there, and if apt from
  stable is affected or not. Given the recent dpkg, apt, and dbus changes
  I think I'd rather let this as is, and wait in case it shows up again,
  which should give us more information (due to the new apt not eating
  dpkg's output).
 
  Noted, though I sincerely hope it is fixed.  I /might/ be convinced to
  accept a .24 for this particular issue.
  
  Just to clarify, if there's still an issue, it's exclusively in apt.
  The problems with dbus were due to apt trying to configure stuff when
  libdbus was not yet properly configured (AFAIR). And there was similar
  issues in apt between 0.9.9 and 1.0.7 (see #767734), but maybe this is
  something else, although related, but only showing up when trigger
  states are involved, this might also be a problem in apt in stable or
  just with newer versions, that might have only emerged due to the
  recent changes in dpkg. It might be that this only happens when
  packages break on upgrade as it happened with some of the dbus
  versions that failed on postinst, etc. Dunno, really.

 @deity/@dpkg: Right now, I am less concerned with whose fault it is
 and vastly more concerned with getting a functional upgrade path.
   If the correct fix is in APT and it can be provided in a reviewable
 diff in a reasonable time frame, I will happily take that.  Otherwise,
 the fix needs to be in dpkg (despite being wrong or a revert).  At
 this point in the freeze, we do not have the luxury of finding perfection.

Sorry, my point was that I don't think we know exactly what lead
to the dbus issue, which apt versions are affected, or if this is
actually something that showed up due to the trigger changes, dbus
maintscripts errors and if it was a latent issue that could as well
show up with a system crash leaving dpkg in a broken state, etc.

As I've mentioend before I don't mind at all adding a workaround in
dpkg if that provides a smooth upgrade path, but I'd like to do that
understanding what it's working around, and that it actually fixes
the issue, and not just blindly.

 The main issue for me is that besides this trigger issue, we also got
 the entire init system replacement on upgrades.  I fear this is
 uncharted territories right now because everybody is (mostly) stuck
 behind these trigger issues.

While I think trigger cycles (be them real or bogusly detected as
the ones in 1.17.22) should be RC, they are actually recoverable
upgrade errors, as package involved in trigger cycles get reset into
half-configured, and their pending triggers reset. Which means that
a subsequent apt invocation should be able to continue from where it
was left off. So I don't think this has gotten people stuck on upgrade
problems (at least with dpkg = 1.17.22).

The dbus problem seemed to be actually more severe, because although
«dpkg --configure --pending» seemed to be able to recover from the
situation, apt did not and got stuck there w/o being able to continue,
at least from the logs and comments in the bug reports, but not many
people have reported such issue so…

  I also don't
  know what's the stance on requiring specific packaging tools to be
  upgraded first? Which might mean that if the issue is still there it
  could be fixed in apt proper.
 
 (@deity: You may want to have a look at this as well)
 
 As I recall, it 

Bug#773256: pre-approval: unblock: dpkg/1.17.23

[Guillem Jover]

Hi!

On Wed, 2014-12-17 at 22:18:12 +0100, Niels Thykier wrote:
 On 2014-12-16 06:22, Guillem Jover wrote:
  Package: release.debian.org
  Severity: normal
  User: release.debian@packages.debian.org
  Usertags: unblock
  Control: block -1 by 770627

  I'd prefer if 1.17.22 could be unblocked before uploading this, because
  that version is way better than the one currently in testing, and it is
  causing fewer upgrade issues. Otherwise I'll just merge both unblock
  requests.
 
 Apologies, but I am not entirely convinced here.  I would strongly
 prefer /not/ having trigger regressions right now.

Sorry, it seems there was a communication breakdown somewhere, my
fault.

As I just mentioned on #771730, once tracked down I always thought
this affected all dpkg versions doing trigger dependency checks
(although other issues might have shadowed that specific problem),
but it seems I thought I mentioned it somewhere but cannot find any
reference now :(, and did not actually try to reproduce with older
versions because it seemed a bit like a waste of time when the
unblock didn't seem to be dependenent on that issue.

So, yes, 1.17.22 is really better in any possible way to 1.17.21.
But, obviously your call.

 In fact, I am honestly considering to request having the trigger change
 reverted if 1.17.23 does not solve the issues without introduce another
 regression.

Ok. I'll do another pass over the code, and then try to improve the
functional test suite to see if I catch something else before the
upload.

   We are one and a half month into the freeze and we still do not have a
 clean upgrade path on a package level.  I am deeply concerned that we
 have been missing out on (e.g.) the systemd upgrade reports because of this.

Sorry, I guess I should have tried to push a fix for the RC bug earlier
w/o waiting for the translations deadline, but was not entirely clear
on whether the disabled unblock was permanent or temporary until
clarification on the dbus issue and enabling it back had not happened
for unrelated reasons.

Also given that #771730 was not a regression, it seemed prudent to let
.22 migrate first.

  I've delayed a bit the request because there are still some packages
  with trigger cycles that have not been uploaded yet, I can start taking
  a look on delayed NMUs and wait for those or upload .23 right away and
  possibly prepare a .24 with those additional versioned Breaks, whichever
  you prefer.
 
 It seems that only gxine and icecc are missing now.  If so, please go
 ahead with the .23 with versioned breaks for them as well.  Worst case,
 I will have them removed from testing - best case, they will be fixed.
   I will take the political fall-out of this and notify the maintainers
 of the affected packages.  Let me know if I missed any packages.

Unfortunately there's still auctex, gxine, icecc, mcollective, pypy
and wordpress. And I'm not sure if the fix for all of them might be
a strightforward switch to a -noawait directive.

  I've also not added the --force-configure-any default switch, because we
  don't really know what happened with apt and dbus there, and if apt from
  stable is affected or not. Given the recent dpkg, apt, and dbus changes
  I think I'd rather let this as is, and wait in case it shows up again,
  which should give us more information (due to the new apt not eating
  dpkg's output).
 
 Noted, though I sincerely hope it is fixed.  I /might/ be convinced to
 accept a .24 for this particular issue.

Just to clarify, if there's still an issue, it's exclusively in apt.
The problems with dbus were due to apt trying to configure stuff when
libdbus was not yet properly configured (AFAIR). And there was similar
issues in apt between 0.9.9 and 1.0.7 (see #767734), but maybe this is
something else, although related, but only showing up when trigger
states are involved, this might also be a problem in apt in stable or
just with newer versions, that might have only emerged due to the
recent changes in dpkg. It might be that this only happens when
packages break on upgrade as it happened with some of the dbus
versions that failed on postinst, etc. Dunno, really.

But in any case the --force-configure-any default change would be a
workaround in dpkg to cover for the dist-upgrade problem of apt not
upgrading itself as the first thing, and reexecuting. I also don't
know what's the stance on requiring specific packaging tools to be
upgraded first? Which might mean that if the issue is still there it
could be fixed in apt proper.

 Apologies for the less optimistic view on my end and thanks for your work.

Sure, fully understood, no problem.

Thanks,
Guillem


-- 
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/20141219193527.ga27...@gaara.hadrons.org

Bug#773256: pre-approval: unblock: dpkg/1.17.23

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: block -1 by 770627

Hi!

I'd like to upload dpkg 1.17.23 with the following changes. I've
excluded and filtered translation changes. I'm including a patch series
instead of a debdiff, because it should be clearer and easier to spot
specific changes you might not want to approve?

I'd prefer if 1.17.22 could be unblocked before uploading this, because
that version is way better than the one currently in testing, and it is
causing fewer upgrade issues. Otherwise I'll just merge both unblock
requests.

I've delayed a bit the request because there are still some packages
with trigger cycles that have not been uploaded yet, I can start taking
a look on delayed NMUs and wait for those or upload .23 right away and
possibly prepare a .24 with those additional versioned Breaks, whichever
you prefer.

I've also not added the --force-configure-any default switch, because we
don't really know what happened with apt and dbus there, and if apt from
stable is affected or not. Given the recent dpkg, apt, and dbus changes
I think I'd rather let this as is, and wait in case it shows up again,
which should give us more information (due to the new apt not eating
dpkg's output).

Here's the full tentative changelog (with the translation changes
already in master):

,---
dpkg (1.17.23) UNRELEASED; urgency=low

  [ Guillem Jover ]
  * Use a matching group instead of ${^MATCH} in s/// in dselect build script.
  * Skip tar extractor tests if tar is not GNU tar = 1.27.
  * Reset the trigger cycle tracking on unsatisfied dependencies.
Closes: #771730
  * Fix out-of-bounds buffer read accesses when parsing field and trigger
names or checking package ownership of conffiles and directories.
Reported by Joshua Rogers megaman...@gmail.com.
  * Add versioned Breaks on packages creating trigger cycles. Namely
apt-cudf, ccache, cups, distcc, fusionforge-plugin-mediawiki, gap-core,
hoogle, libjs-protoaculous and xfonts-traditional.

  [ Updated programs translations ]
  * Basque (Iñaki Larrañaga Murgoitio). Closes: #771893
  * Catalan (Guillem Jover).
  * Czech (Miroslav Kure).
  * Esperanto (Felipe Castro).
  * French (Sébastien Poher).
  * Italian (Milo Casagrande).
  * Swedish (Peter Krefting).
  * Portuguese (Miguel Figueiredo).
  * Russian (Yuri Kozlov). Closes: #771691
  * Simplified Chinese (Zhou Mo). Closes: #771264
  * Spanish (Javier Fernández-Sanguino)
  * Thai (Theppitak Karoonboonyanan). Closes: #772965

  [ Updated scripts translations ]
  * Catalan (Guillem Jover).
  * Polish (Łukasz Dulny).
  * Russian (Yuri Kozlov). Closes: #772841

  [ Updated manpages translations ]
  * French (Sébastien Poher).
  * Italian (Beatrice Torracca). Closes: #771673

  [ Updated dselect translations ]
  * Catalan (Guillem Jover).
  * Czech (Miroslav Kure).
  * Norwegian Bokmål (Hans Fredrik Nordhaug).
  * Polish (Łukasz Dulny).
  * Portuguese (Miguel Figueiredo).
  * Russian (Yuri Kozlov). Closes: #771682
  * Spanish (Javier Fernández-Sanguino)
  * Vietnamese (Trần Ngọc Quân).

 -- Guillem Jover guil...@debian.org  Fri, 28 Nov 2014 02:41:17 +0100
`---

Thanks,
Guillem
From a5d6590b7a2a9f649f5aab01e3410bac62e12a76 Mon Sep 17 00:00:00 2001
From: Guillem Jover guil...@debian.org
Date: Fri, 5 Dec 2014 23:29:03 +0100
Subject: [PATCH 1/5] dselect: Use a matching group instead of ${^MATCH} in
 s///

It seems that this is not supported or does not work in perl 5.14.0,
although it should be since 5.10.0. Switch to a group matching to
allow using older perl version from stable.
---
 debian/changelog | 3 +++
 dselect/mkcurkeys.pl | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 432d705..0ff1d9b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,8 @@
 dpkg (1.17.23) UNRELEASED; urgency=low
 
+  [ Guillem Jover ]
+  * Use a matching group instead of ${^MATCH} in s/// in dselect build script.
+
   [ Updated programs translations ]
   * Basque (Iñaki Larrañaga Murgoitio). Closes: #771893
   * Catalan (Guillem Jover).
diff --git a/dselect/mkcurkeys.pl b/dselect/mkcurkeys.pl
index d859376..342d491 100755
--- a/dselect/mkcurkeys.pl
+++ b/dselect/mkcurkeys.pl
@@ -140,6 +140,6 @@ sub capit {
 sub p {
 my ($k, $v) = @_;
 
-$v =~ s/[\\]/\\${^MATCH}/pg;
+$v =~ s/([\\])/\\$1/g;
 printf(  { %-15s \%-20s },\n, $k . ',', $v . '') or die $!;
 }
-- 
2.2.0.rc0.207.ga3a616c

From 88999a73fc4d77b3ab1072f3102cfbeaff94ab31 Mon Sep 17 00:00:00 2001
From: Guillem Jover guil...@debian.org
Date: Sat, 6 Dec 2014 00:11:14 +0100
Subject: [PATCH 2/5] libdpkg: Skip tar extractor tests if tar is not GNU tar
 = 1.27

This allows building on older systems.
---
 debian/changelog  |  1 +
 lib/dpkg/test/t-tar.t | 13 -
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 0ff1d9b..da54d81 100644

Re: understanding dpkg trigger cycles

[Guillem Jover]

[ CCed d-release. TL;DR: josch has created a list of packages that can
  generate trigger cycles (13), I'm filing bug reports. ]

Hi!

On Thu, 2014-12-11 at 13:51:16 +0100, Johannes Schauer wrote:
 thanks a lot for your further explanations and clarifications!

Well, thanks a lot for doing the analysis!

 Based on this understanding I wrote a script which does the following:
 
  1. calculate the set of packages A which declare an interest or
 interest-await file trigger (no explicit triggers) in their
 DEBIAN/triggers control file (Helmut supplied me with an initial list of
 binary packages to check from the data on lilburn)
 
  2. calculate the dependency closure of all packages in the set A
 
  3. for each package in A, check if it gets triggered by any of the paths
 provided by any of the packages in its dependency closure
 
 In summary, this finds some of the instances where a trigger cycle is created
 by an interested package directly or indirectly depending on a package which 
 is
 put into triggers-awaited state for that particular package.
 
 Helmut helped me to limit the binary packages to search for DEBIAN/trigger
 files to 136 packages. After downloading and inspecting their content of
 DEBIAN/trigger, 48 packages remained which express an interest (without
 noawait) on a path.

(Sorry, I should have mentioned that I also had this information
available in lilburn. :/ )

 Out of those, it seems that 27 binary packages could potentially form a 
 trigger
 cycle.

 The data is attached. The first column is the package containing the trigger.
 The second column is the path for which the trigger gets activated. The third
 column is a binary package that the binary package in the first column 
 directly
 or indirectly depends on and which contains one or more files that trigger the
 package in the first column.
 
 Does this data look correct?

Yes, it does! I've excluded self-triggers though, as those are not
possible when path activated, because a package in an unpacked state
cannot accumulate pending triggers (sorry, should have mentioned that
before). Which gives a list of only 13 packages:

 ,---
 apt-cudf
 auctex
 cups
 fusionforge-plugin-mediawiki
 gap-core
 gxine
 hoogle
 icecc
 libjs-protoaculous
 mcollective
 pypy
 wordpress
 xfonts-traditional
 `---

I'll start filing bug reports.

BTW, would it be possible to have this generated, say once a week? I
assume the major roadblock here is the need to get an up-to-date list
of trigger control files? We could export a list from lilburn for
example?

Thanks,
Guillem


-- 
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/20141211185944.gb4...@gaara.hadrons.org

Bug#770627: dbus: Please (consider) switch(ing) to no-await triggers

[Guillem Jover]

Hi!

On Sun, 2014-12-07 at 14:01:51 +0100, Niels Thykier wrote:
 On 2014-12-05 05:20, Guillem Jover wrote:
  Given this, the only options seem to be to possibly change the
  --force-configure-any default to enabled (I'll try to test if this
  helps in the dbus situation) which I'd rather not do (but oh well),
  or disable the triggers dependency checks for jessie (and possibly
  later releases, if apt does not get fixed for jessie) and go back
  to the previous (broken, but known) behavior. :(

 As I mentioned to David/the APT maintainers, I could be interested in
 having the patch for #769609 in APT.  @Guillem, do you think that will
 deal with the issue?

That would fix the issue with dangling trigger-pending packages, but
I don't think it would fix the dbus issue. I've not tried to check a
dpkg workaround for that yet, sorry. I've got a fix for the nvidia
kernel module one, and asked for access to the ppc system with the pam
module 100% cpu usage bug, to try to confirm that's been fixed in .22,
which I think it does, but would like to make sure.

In any case I think .22 would be an improvement over what's currently
in testing.

Thanks,
Guillem


-- 
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/20141209055900.ga32...@gaara.hadrons.org

Bug#772053: unblock: startupmanager/1.9.13-8

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi!

Please unblock the package startupmanager so that it can migrate
to testing.

It fixes an instance of update-alternatives usage through the compat
symlink, so that it can be removed in dpkg 1.18.x w/o needing a Breaks.
Attached the debdiff.

unblock startupmanager/1.9.13-8

Thanks,
Guillem
diff -u startupmanager-1.9.13/debian/changelog 
startupmanager-1.9.13/debian/changelog
--- startupmanager-1.9.13/debian/changelog
+++ startupmanager-1.9.13/debian/changelog
@@ -1,3 +1,10 @@
+startupmanager (1.9.13-8) unstable; urgency=low
+
+  * QA upload.
+  * Do not use an absolute path when calling update-alternatives.
+
+ -- Guillem Jover guil...@debian.org  Mon, 17 Nov 2014 20:52:00 +0100
+
 startupmanager (1.9.13-7) unstable; urgency=low
 
   * QA upload.
only in patch2:
unchanged:
--- startupmanager-1.9.13.orig/bootconfig/usplash.py
+++ startupmanager-1.9.13/bootconfig/usplash.py
@@ -99,7 +99,7 @@
 if filename == usplash_file:
 os.system('ln -sf ' + self.alternatives_file + ' ' + 
   self.themes_directory + 'usplash-artwork.so')
-command = '/usr/sbin/update-alternatives --set ' + \
+command = 'update-alternatives --set ' + \
   'usplash-artwork.so /usr/lib/usplash/' + filename
 os.system(command)
 self.update_initramfs = True
@@ -122,7 +122,7 @@
 new_path = self.themes_directory + filename
 if not path == new_path:
 shutil.copy(path, self.themes_directory)
-command = '/usr/sbin/update-alternatives '+ \
+command = 'update-alternatives '+ \
   '--install /usr/lib/usplash/usplash-artwork.so ' + \
   'usplash-artwork.so ' + \
   new_path + ' 10'

Bug#770627: dbus: Please (consider) switch(ing) to no-await triggers

[Guillem Jover]

Hi!

On Thu, 2014-12-04 at 20:23:28 +, Simon McVittie wrote:
 Control: tags 771989 + moreinfo
 
 On Thu, 04 Dec 2014 at 16:39:31 +0100, Niels Thykier wrote:
  On 2014-12-04 09:11, Simon McVittie wrote:
 [see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770627#70 for full
 analysis]

   If I am correct in my interpretation, then it seems to me that normal
   interest triggers are right here. However, if there is consensus that
   using the wrong trigger is a less severe bug than #771417, I can switch
   to interest-noawait and open a bug for should go back to ordinary
   triggers post-jessie... as long as that new bug is not *also* going to
   be considered RC.

  If your interpretation is correct, then I am certainly not convinced
  that changing the triggers to the interest variant is the correct
  thing to do for dbus.
Sadly, I am no expert on these matters, so I will have to defer it to
  the APT or dpkg maintainers for whether your interpretation is correct.
 
 Thanks. apt/dpkg people: please send any feedback on the correct thing to do
 to 771...@bugs.debian.org. Sorry, I mixed up the various bugs and
 didn't reply to that one initially; I have now bounced the missing
 messages to that bug (hopefully).

It seems the bounced mails didn't make it. In any case, from your
other mail:

 My question is, crucial for who? If dbus-daemon has not yet reloaded,
 then dbus-daemon will continue to work fine (it's in a consistent state
 either way), but the package that shipped the system service or security
 policy (in #771417 it's systemd) won't necessarily work properly until
 dbus-daemon has had a chance to reload.

Crucial for the awaiting package (I'll be updating the docs for 1.18.x).
So, from your explanation, then in this case they are crucial for the
activating packages yes, and the bug report against dbus can be closed.

Given this, the only options seem to be to possibly change the
--force-configure-any default to enabled (I'll try to test if this
helps in the dbus situation) which I'd rather not do (but oh well),
or disable the triggers dependency checks for jessie (and possibly
later releases, if apt does not get fixed for jessie) and go back
to the previous (broken, but known) behavior. :(

Thanks,
Guillem


-- 
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/20141205042000.ga14...@gaara.hadrons.org

Bug#770627: pre-approval: unblock: dpkg/1.17.22

[Guillem Jover]

Hi!

On Sat, 2014-11-29 at 12:20:45 +0100, Niels Thykier wrote:
 Control: reopen -1
 
 On 2014-11-28 04:23, Guillem Jover wrote:
  On Tue, 2014-11-25 at 08:05:00 +0100, Niels Thykier wrote:
  Other than that, please go ahead and upload to unstable and notify us
  once it has been accepted.
  
  dpkg 1.17.22 has now been accepted in the archive.

 I just saw #771417, which claims dpkg to have made a regression.  I have
 pulling my unblock until you have had a look at it.

Sure. As I mentioned on the bug, this is two issues in apt (#765687
and #771428) and a minor one in dpkg (#771417), which I knew already
but forgot to mention on the unblock request. As I said on the bug,
this is just a cosmetic issue, and because it should only happen due
to problems elsewhere, I didn't consider it worth fixing for 1.17.x.

If this cannot be fixed in apt proper (due to requiring it to
self-upgrade), then it should be fixable by switching dbus to
noawaiting trigger directives (which I think would be correct
regardless).

Thanks,
Guillem


-- 
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/20141130015216.ga19...@gaara.hadrons.org

Bug#770627: pre-approval: unblock: dpkg/1.17.22

[Guillem Jover]

Hi!

On Sat, 2014-11-29 at 12:20:45 +0100, Niels Thykier wrote:
 Control: reopen -1
 
 On 2014-11-28 04:23, Guillem Jover wrote:
  On Tue, 2014-11-25 at 08:05:00 +0100, Niels Thykier wrote:
  Other than that, please go ahead and upload to unstable and notify us
  once it has been accepted.
  
  dpkg 1.17.22 has now been accepted in the archive.

 I just saw #771417, which claims dpkg to have made a regression.  I have
 pulling my unblock until you have had a look at it.

Oh, almost forgot, there's been also
https://lists.debian.org/debian-dpkg/2014/11/msg00053.html, which
got introduced in 1.17.22, but that's just part of the problem,
there's several other instances in the codebase, affecting compat
field names, triggers and conffile handling on versions going as far
as the one in stable.

So I can finish up a fix for a quickish .23, or just queue it for
when the translations deadline is over. Personally I don't think this
is urgent.

Thanks,
Guillem


-- 
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/20141130021004.ga23...@gaara.hadrons.org

Re: Bug#758616: dpkg: support installing M-A:same packages with different binNMU version

[Guillem Jover]

Hi!

On Fri, 2014-11-28 at 15:17:29 +, Wookey wrote:
 What is the current thinking on this for Jessie? I presume that at
 this stage it is not going to be implemented so running lots of
 binNMUs, or no-change sourceful upload to syncronise all arches is the
 only fix available in that timeframe?

I asked this on d-r last time it got brought up on d-d, but given the
lukewarm response, I didn't try anything further.

  https://lists.debian.org/debian-release/2014/11/msg00019.html

 Does anyone know of problems that comparison of the source version
 would actually cause? This seems to me to be the right way to deal
 with this problem, but I don't claim any particular insight. Is the
 worry just 'unforseen side-effects in complex code'? Syncronisation
 with apt?

I started implementing this, but posponed finishing it up for 1.18.x,
given the above response. If there is still interest I could propose
a patch. But it might end up being a non-minimal change.

As discussed some time ago on #debian-bootstrap, this just defers any
breakage to the reference counting code, so it just makes that
possible breakage be detectable later on. (The whole thing still seems
to me to be broken by design, but that ship sailed long ago.)

Thanks,
Guillem


-- 
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/20141128154413.gb5...@gaara.hadrons.org

Bug#770627: pre-approval: unblock: dpkg/1.17.22

[Guillem Jover]

Hi!

On Thu, 2014-11-27 at 08:15:02 +0100, Niels Thykier wrote:
 On 2014-11-27 04:07, Guillem Jover wrote:
  I'd rather upload 1.17.22 right away to get those fixes into the
  archive, and prepare a translations-only 1.17.23, but I'll be glad to
  act on any upload plans that you are comfortable with.

 Agreed, please do that.  I also strongly prefer more testing of dpkg
 plus a translation-only update afterwards to shorter testing time and
 rushed translations.
 
 With a CfT today/tomorrow with 14 days, we are looking the 12th of
 December.  With a couple of days latency, we will be looking the 16th of
 December for the (hopefully) finally dpkg upload for Jessie.  How do
 that sound?
   I am curious since I want to keep track of the (potential) blockers
 for the release.

Sounds perfect! Will be proceeding with that plan then.

Thanks,
Guillem


-- 
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/20141127145554.gb27...@gaara.hadrons.org

Bug#770627: pre-approval: unblock: dpkg/1.17.22

[Guillem Jover]

Hi!

On Tue, 2014-11-25 at 08:05:00 +0100, Niels Thykier wrote:
 Other than that, please go ahead and upload to unstable and notify us
 once it has been accepted.

dpkg 1.17.22 has now been accepted in the archive.

Thanks,
Guillem


-- 
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/20141128032337.ga3...@gaara.hadrons.org

Bug#770627: pre-approval: unblock: dpkg/1.17.22

[Guillem Jover]

Control: tags -1 - moreinfo

On Tue, 2014-11-25 at 08:05:00 +0100, Niels Thykier wrote:
 Control: tags -1 confirmed moreinfo
 
 On Sat, 22 Nov 2014 19:26:44 +0100 Guillem Jover guil...@debian.org wrote:
  Package: release.debian.org
  Severity: normal
  User: release.debian@packages.debian.org
  Usertags: unblock

 I can see some of the patches modify an existing changelog; I assume
 that only contains the before mentioned translation updates.

Yes, some where already in git master, few others where pending in my
push. They are all in master now.

   IRT the string changes done in this version of dpkg, have they already
 been fixed in git, or you called for a translation update?

Right, I was waiting for the approval, to avoid having to possibly
revert. I'll probably upload tomorrow, waiting for some of the fast
translators that might commit directly.

Given the current freeze policy, I'm not sure though what to set the
deadline for the CfT (which to be fair I should have sent long ago :/),
and if a subsequent translations-only upload (1.17.23) would be allowed
after the 5th of Dec, if that should be the CfT deadline, or if I should
defer 1.17.22 until translation updates come in? (I thought there was
some confusion regarding the freeze policy and translation and doc only
uploads? Not sure if it got clarified though.)

I'd rather upload 1.17.22 right away to get those fixes into the
archive, and prepare a translations-only 1.17.23, but I'll be glad to
act on any upload plans that you are comfortable with.

 Other than that, please go ahead and upload to unstable and notify us
 once it has been accepted.

Thanks! Will notify when the package hits the archive.

Regards,
Guillem


-- 
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/20141127030730.ga6...@gaara.hadrons.org

Bug#770627: pre-approval: unblock: dpkg/1.17.22

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi!

I'd like to upload dpkg 1.17.22 with the following changes. I've
excluded and filtered translation changes. I'm including a patch series
instead of a debdiff, because it should be clearer and easier to spot
specific changes you might not want to approve?

This passes all unit tests, and the functional tests (which I've fixed
to comply) from https://anonscm.debian.org/cgit/dpkg/dpkg-tests.git.
In addition, I've got some status files that trigger some of the bugs,
that I've not yet synthetized, which work fine with the new dpkg. I've
also been running this on my main system with daily upgrades for over
a week now.

Thanks,
Guillem
From 2d3adc759c37bf73c12730c79b73dc26ca171c7d Mon Sep 17 00:00:00 2001
From: Guillem Jover guil...@debian.org
Date: Thu, 6 Nov 2014 18:13:27 +0100
Subject: [PATCH 01/12] man: Add when dpkg-deb --ctrl-tarfile got introduced

Missed in commit 03c0873bd720a4f93db0cc4764fa98d3dbcadede.
---
 debian/changelog|  3 +++
 man/dpkg-deb.1  |  2 +-
 man/po/de.po| 12 +++-
 man/po/dpkg-man.pot |  8 
 man/po/es.po|  8 
 man/po/fr.po| 12 ++--
 man/po/hu.po|  8 
 man/po/it.po|  8 
 man/po/ja.po|  8 
 man/po/pl.po|  8 
 man/po/pt_BR.po |  8 
 man/po/ru.po|  8 
 man/po/sv.po| 14 +++---
 13 files changed, 56 insertions(+), 51 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index a02a208..7e34751 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,8 @@
 dpkg (1.17.22) UNRELEASED; urgency=low
 
+  [ Guillem Jover ]
+  * Add version introducing --ctrl-tarfile in dpkg-deb(1) man page.
+
   [ Updated programs translations ]
   * German (Sven Joachim).
   * French (Sébastien Poher).
diff --git a/man/dpkg-deb.1 b/man/dpkg-deb.1
index 09c066c..c5038ec 100644
--- a/man/dpkg-deb.1
+++ b/man/dpkg-deb.1
@@ -174,7 +174,7 @@ The target directory (but not its parents) will be created if necessary.
 Extracts the control data from a binary package and sends it to standard
 output in
 .B tar
-format. Together with
+format (since dpkg 1.17.14). Together with
 .BR tar (1)
 this can be used to extract a particular control file from a package archive.
 The input archive will always be processed sequentially.
-- 
2.1.3

From e04dd68c0a36e465a656a9e78830dcf28e455242 Mon Sep 17 00:00:00 2001
From: Guillem Jover guil...@debian.org
Date: Mon, 17 Nov 2014 00:55:20 +0100
Subject: [PATCH 02/12] man: Bump minimal version for dir_to_symlink and
 symlink_to_dir commands

The minimal version for dir_to_symlink with all current features is
1.17.13, and for symlink_to_dir is 1.17.14. But to make it simpler,
let's just say the latter. This also avoids unnecessary translator
work.

Missed in commits 7fe9dcdd57c083180a7994957d1e5217d28e970a and
a92a3ac5056363e9c21c48187f6ff965481742f4.

Closes: #769843
---
 debian/changelog  |  2 ++
 man/dpkg-maintscript-helper.1 |  4 ++--
 man/po/de.po  | 10 +-
 man/po/fr.po  | 10 +-
 man/po/sv.po  | 10 +-
 5 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 7e34751..ec5b9cd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,8 @@ dpkg (1.17.22) UNRELEASED; urgency=low
 
   [ Guillem Jover ]
   * Add version introducing --ctrl-tarfile in dpkg-deb(1) man page.
+  * Bump minimal version for dir_to_symlink and symlink_to_dir commands
+to 1.17.14 in dpkg-maintscript-helper(1) man page. Closes: #769843
 
   [ Updated programs translations ]
   * German (Sven Joachim).
diff --git a/man/dpkg-maintscript-helper.1 b/man/dpkg-maintscript-helper.1
index 908083d..85185ac 100644
--- a/man/dpkg-maintscript-helper.1
+++ b/man/dpkg-maintscript-helper.1
@@ -230,9 +230,9 @@ using it unconditionally requires a pre-dependency to ensure that the
 required version of \fBdpkg\fP has been unpacked before. The required version
 depends on the command used, for \fBrm_conffile\fP and \fBmv_conffile\fP
 it is 1.15.7.2, for \fBsymlink_to_dir\fP and \fBdir_to_symlink\fP
-it is 1.17.5:
+it is 1.17.14:
 .P
-\fBPre\-Depends:\fP dpkg (= 1.17.5)
+\fBPre\-Depends:\fP dpkg (= 1.17.14)
 .P
 But in many cases the operation done by the program is not critical for
 the package, and instead of using a pre-dependency we can call the
-- 
2.1.3

From a213746672a3e12a8ef6b86ccf04594bf30e8fba Mon Sep 17 00:00:00 2001
From: Guillem Jover guil...@debian.org
Date: Sun, 9 Nov 2014 00:51:42 +0100
Subject: [PATCH 03/12] debian: Reintroduce u-a, dpkg-divert and
 dpkg-statoverride compat symlinks

There are still packages using those paths, but the relevant lintian
check did not list any, so these got removed prematurely.
---
 Makefile.am   | 1 +
 TODO  | 2 ++
 debian

Bug#767706: unblock: debsig-verify/0.13

[Guillem Jover]

Hi!

On Thu, 2014-11-20 at 22:30:41 +, Jonathan Wiltshire wrote:
 Control: tag -1 moreinfo
 
 On Sun, Nov 02, 2014 at 01:23:13AM +0100, Guillem Jover wrote:
  Please unblock or reduce age-days for package debsig-verify so that it
  can migrate before the freeze.
  
  It fixes the code so that it now checks for errors returned by relevant
  library and system calls, either directly or by switching to the more
  tested code from libdpkg. This is particularly important given that
  debsig-verify is one of the pieces in the packaging toolchain that
  might be exposed to untrusted binary .deb packages. In addition this
  version adds a new functional testsuite, which is run during the build.
 
 Sorry you didn't get an answer to this sooner. To be honest, the size of
 the debdiff is rather off-putting.

Hmm, right, that's partly due to many files having moved around. The
debdiff should be equivalent to «git diff --shortstat 0.10..0.13»:

  52 files changed, 2260 insertions(+), 1701 deletions(-)

but with «git diff -C --shortstat 0.10..0.13» it becomes:

  37 files changed, 924 insertions(+), 389 deletions(-)

which is not *that* bad, but it's it's not small either.

 How bad would it be if this *wasn't* in Jessie?

I was actually expecting either a reduction of age-days or an unblock
before the freeze, or for it to not be accepted afterwards. The changed
code has been like the one in Jessie (more or less) for ages, so I don't
think it would be the end of the world if it continued that way for some
more years, although I think it would be better to have the new version.
But I can pretty much understand you being very much uncomfortable
accepting this amount of changes at this stage of the freeze.

I'm attaching the condensed git diff, in case you'd feel like taking a
look, otherwise just ignore it and go ahead closing this request.

Thanks,
Guillem
 .gitignore |  19 ++
 ChangeLog  |  84 ---
 Makefile   |  61 -
 Makefile.am|  65 ++
 README |  70 ++
 autogen|   5 +
 configure.ac   |  64 +
 debian/.cvsignore  |   6 -
 debian/changelog   |  66 ++
 debian/control |   7 +-
 debian/copyright   |   1 +
 debian/rules   |  62 -
 {docs = doc}/TODO |   0
 {docs = doc}/debsig-verify.1.in   |  19 +-
 {docs = doc}/policy-syntax.txt|   0
 {docs = doc}/policy.dtd   |   0
 get-version|  41 
 ar-parse.c = src/ar-parse.c   |  61 +++--
 debsig-verify.c = src/debsig-verify.c | 258 +
 debsig.h = src/debsig.h   |  38 +--
 gpg-parse.c = src/gpg-parse.c | 140 +++
 misc.c = src/misc.c   |   9 +-
 xml-parse.c = src/xml-parse.c |  58 +++--
 test/.gitignore|   4 +
 test/Makefile.am   |  41 
 test/atlocal.in|  68 ++
 {testing = test}/debs/sigtest1_1.0-1_all.deb  | Bin
 {testing = test}/debs/sigtest2_2.0-1_all.deb  | Bin
 test/debsig-cmd.at |  11 +
 test/debsig-sig.at |  36 +++
 .../keyrings/7CD73F641E04EC2D/debian-debsig.gpg| Bin
 test/keyrings/FAD46790DE88C7E2/pubring.gpg | Bin 0 - 1245 bytes
 test/keyrings/FAD46790DE88C7E2/secring.gpg | Bin 0 - 2547 bytes
 .../policies/7CD73F641E04EC2D/generic.pol  |   0
 .../policies/7CD73F641E04EC2D/potato-release.pol   |   0
 .../policies/FAD46790DE88C7E2}/generic.pol |   8 +-
 test/testsuite.at  |  11 +
 37 files changed, 924 insertions(+), 389 deletions(-)

diff --git a/.gitignore b/.gitignore
index fa38d3d..6688d50 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,22 @@
+# Inherited ignores
 *.o
+*.log
+*.trs
+*~
+.deps/
+.dirstamp
+Makefile
+Makefile.in
+
+# Top dir ignores
+autom4te.cache/
+build-aux/
+build-tree/
+INSTALL
+configure
+config.*
+aclocal.m4
+stamp-h1
+
 debsig-verify
 debsig-verify.1
diff --git a/ChangeLog b/ChangeLog
deleted file mode 100644
index 8f347fe..000
--- a/ChangeLog
+++ /dev/null
@@ -1,84 +0,0 @@
-Fri Apr 27 13:53:32 EDT 2001  Ben Collins bcoll...@debian.org
-
-  * debsig.h: Redefine ds_fail_printf with exit values, and macros. Also, add
-__attributes__ to ds_printf so gcc will warn us on misuse
-  * ar-parse.c: Convert to new ds_fail_printf
-  * debsig

Re: Status on dpkg for Jessie

[Guillem Jover]

Hi!

On Fri, 2014-11-21 at 18:36:45 +0100, Niels Thykier wrote:
 Do you have an ETA on the next upload of dpkg (and if there is anything
 blocking it)?

Yes, it's waiting on readahead-fedora, waiting in the DEFERRED queue, to
be able to add the correct Breaks, in case the maintainer override with
a normal upload.

I'll be filing a tentative pre-approval request later today, after
that, once it is approved I'll proceed with the upload.

 Besides the filed 3 RC bugs, the compat symlinks also need to be
 recreated.  The latter does not have a bug (at least, not an RC one); if
 you prefer I can file one for it

Not really needed, I've had it already reverted locally. :)

Thanks,
Guillem


-- 
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/20141121183458.gb21...@gaara.hadrons.org

Re: Packages using old dpkg tools paths

[Guillem Jover]

Hi!

On Mon, 2014-11-03 at 11:23:37 +0100, Guillem Jover wrote:
 I'm planning on starting to file bug reports for the source packages
 below (BCCed).

Here's the current status. I've filed bugs now with patches, or just
uploaded for orphaned ones.

 Sources list (via codesearch.d.o)
 
 
 ,--- u-a ---
 startupmanager_1.9.13-7/bootconfig/usplash.py

QA upload startupmanager_1.9.13-8.

 wmanager_0.2.1-11/debian/wmanagerrc-update

Bug #769966.

 `---

 ,--- dpkg-divert ---
 amule_2.3.1+git1a369e47-2/debian/amule-utils.preinst
 amule_2.3.1+git1a369e47-2/debian/amule.preinst

Bug #769847.

 `---

 ,--- dpkg-statoverride ---
 acidbase_1.4.5-4/debian/postinst

Bug #769899, wontfixed as the package will be left to die instead.

 beep_1.3-3/debian/postinst

Bug #769898.

 geki2_2.0.3-8/debian/postinst

Bug #770055.

 geki3_1.0.3-7/debian/postinst

Bug #770056.

 gravitywars_1.102-32/debian/postinst

Bug #770062.

 im_1:151-3/debian/postrm

Bug #770042.

 monsterz_0.7.1-7/debian/postinst

Bug #770057.

 netdiag_1.1-1/debian/diagperm

Bug #770044 (minor, it's just an example script now).

 netselect_0.3.ds1-26/debian/netselect.postinst

Bug #770045.

 man-db_2.7.0.2-2/debian/postinst
 openssh_1:6.7p1-2/debian/openssh-client.postinst
 openssh_1:6.7p1-2/debian/openssh-server.postinst

Coling uploaded these, thanks!

 pconsole_1.0-11/debian/postinst

Bug #770046, pending, was already fixed in VCS.

 phpgacl_3.3.7-7.3/debian/phpgacl.postinst

Bug #770048.

 pure-ftpd_1.0.36-3/debian/pure-ftpd-common.postinst

Bug #770049.

 systemtap_2.6-0.1/debian/systemtap-runtime.postinst

Bug #770050.

 tecnoballz_0.93.1-1/debian/tecnoballz.postinst

Bug #770059.

 terminatorx_3.90-2/debian/postinst

Bug #770051.

 tvtime_1.0.2-12.1/debian/postinst

QA upload tvtime_1.0.2-13.

 xvt_2.1-20.1/debian/postinst

Bug #770052.

 `---

Thanks,
Guillem


-- 
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/20141118162923.ga28...@gaara.hadrons.org

Re: Bug#767999: base-files: fails to install with pre-jessie debootstrap

[Guillem Jover]

Hi!

On Fri, 2014-11-07 at 08:30:39 +, Michael Tautschnig wrote:
 On Fri, Nov 07, 2014 at  8:34:49 +0100, Guillem Jover wrote:
  Control: severity -1 serious
  Control: retitle -1 dpkg: Correct fix breaks bogus assumptions in old 
  debootstrap
 
 I'd say the bug title ought to be Correct fix makes bug in base-passwd
 surface.

No, see below.

 [...]
 
 I do agree with all the dpkg reasoning and in a way I'm grateful that dpkg 
 made
 this bug surface. But really there shouldn't be any such dependency on the 
 order
 of configuration of base-files and base-passwd.

There needs to be one, and that's part of the problem of bootstrapping
a system. I agree with Santiago that adding an implicit Depends
completely defeats the point of Essential, and that's a wrong fix.

   Reassigning it
   to dpkg for now; and cc-ing the release team because of things like the
   #768346 unblock request.
  
  I'm going to revert the commit above (only in 1.17.x, it will be kept
  in 1.18.x), because it is very minimal, just reintroduces again an
  unnecessary package queue stage, and such regression is acceptable if
  it makes buggy bootstrappers work again. But a fixed debootstrap (and
  maybe cdebootstrap if that fails too) should really be pushed to stable.
 
 I think you might want to hold off on this revert. See
 
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767999#73
 
 and Adam's kind testing of that patch.

The reasoning there is not correct, Santiago is right except for the
part where he might be trying to justify this through policy, because
bootstrapping a system is currently outside the realms of policy. Many
of the packaging system invariants do not hold there.

What debootstrap does is more or less this (with other setup
sprinkled in between):

  Extract .debs
  - dpkg-deb --extract
  Install core .debs
  - dpkg --install --force-depends
  Unpack required .debs
  - dpkg --unpack --force-depends
  Configure required .debs
  - dpkg --configure --pending --force-configure-any --force-depends
  Install dependencies of pre-depencies for base system .debs
  - dpkg --force-overwrite --force-confold --skip-same-version --install
  Install base system .debs
  - dpkg --force-overwrite --force-confold --skip-same-version --install
  Configure base system .debs
  - dpkg --force-confold --skip-same-version --configure -a

There are several stages where for example preinst scripts have never
been run for any Essential packages, --force options are used all
over the place; this should be a very clear indication debootstrap has
to operate in a completely different environment and conditions. For
example, dpkg will fail flat out if there is no status file, and that
cannot be shipped in the .deb; dpkg will create it if not present in
its postinst (but that's really too late when bootstrapping a system),
so debootstrap needs to create these instead, and this is a very similar
situation to the one with the passwd file, but in that case a better
solution is to hardcode an install order and offload the work to
base-passwd. Someone needs to know that that file has to be created
somewhen or by something.

ISTR there was in the past discussions (AFAIR either in d-d or a dpkg
bug) about trying to move the bootstrapping information into packages
in a bootstrap maintscript or similar. Those would need to be run from
outside the chroot, so that we are not back to the problem of implicit
assumptions and ordering though. And the expectations on the external
environment would need to be specified, for example assuming just POSIX
utilities.

*That* would be a proper fix to the problem of the implicit ordering,
would also be a generic solution independent of the distribution or
derivative, or current set of packages, and we might be able to have
(possibly) a more generic debootstrap. I can try to draft something
up if people are interested in this for jessie+1.

Thanks,
Guillem


-- 
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/20141107163806.ga28...@gaara.hadrons.org

Re: Bug#767999: base-files: fails to install with pre-jessie debootstrap

[Guillem Jover]

Control: severity -1 serious
Control: retitle -1 dpkg: Correct fix breaks bogus assumptions in old 
debootstrap

On Fri, 2014-11-07 at 02:33:48 +0100, Cyril Brulebois wrote:
 Cyril Brulebois k...@debian.org (2014-11-05):
  But, from where I stand, several developers were actually checking facts
  after I cherry-picked the patch in to the stable branch, and I decided
  to wait and see where the situation was going. Apparently there are
  several views on the matter, and without commenting on their respective
  relevance, I'd like to emphasize several things:
   - Developers have limited free time.
   - Developers might be getting ready for the imminent freeze.
   - Uploading to stable means making sure the fix is right, rather than
 uploading hastily.
   - Uploads to stable don't appear magically on users' systems a few
 hours later; it takes a point release or users' having configured
 s-p-u in their sources.list; so I don't think any haste (see previous
 point) would help anyway.
   - Uploads to stable have to be reviewed by release team members, who
 might also be busy dealing with a flood of freeze-related requests at
 the moment.
 
 Tests performed on an amd64 host running wheezy, debootstrapping amd64.
 
 Well I bisected the archive and the last debootstrapable jessie release
 was at 20141102T221202Z; looking at the set of updated packages between
 that one and the next one, it looks like… dpkg got updated from 1.17.13
 to 1.17.21. And unsurprisingly reverting current jessie to dpkg 1.17.13
 makes debootstrap work again.

What's making the breakage in debootstrap surface is dpkg 1.17.20, commit
9ee62ecfc8937f24a82805a424564997042dd984. At least with my testing
using a patched debootstrap, and using --foreign + --second-stage to
inject a dpkg with the reverted commit.

 A few weeks or even days before the freeze doesn't quite seem to be the
 right time to introduce (not so) subtle changes in dpkg.

(So we need to actually freeze months in advance of the freeze… right.)

The above commit is a *correct* fix for a very old regression, to remove
a bogus package queue dependency stage in dpkg. The breakage in
debootstrap in older versions is due to incorrect assumptions, which
where fixed correctly (not worked around, contrary to what is mentioned
on its changelog) in 1.0.56. The change was:

-   x_core_install base-files base-passwd
+   x_core_install base-passwd
+   x_core_install base-files

where debootstrap was expecting that dpkg run to process base-passwd
first, even though it was passed last. This, on a call to dpkg using
--force-depends, for essential packages that do not have any kind of
dependency relationship between them, which makes any such assumption
be based on something far beyond undefined behavior.

 Reassigning it
 to dpkg for now; and cc-ing the release team because of things like the
 #768346 unblock request.

I'm going to revert the commit above (only in 1.17.x, it will be kept
in 1.18.x), because it is very minimal, just reintroduces again an
unnecessary package queue stage, and such regression is acceptable if
it makes buggy bootstrappers work again. But a fixed debootstrap (and
maybe cdebootstrap if that fails too) should really be pushed to stable.

Guillem


-- 
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/20141107073449.ga11...@gaara.hadrons.org

Re: Packages using old dpkg tools paths

[Guillem Jover]

Hi!

On Mon, 2014-11-03 at 22:20:48 +0100, Niels Thykier wrote:
 On 2014-11-03 11:23, Guillem Jover wrote:
  I'm planning on starting to file bug reports for the source packages
  below (BCCed). I've not checked (yet) how severe the dpkg-statoverride
  ones are, but if most of them do not get fixed, I might consider
  reintroducing the compat symlink for that one alone if the release-team
  (CCed) sees fit to that. :/
 
 Could you please re-instate all the compat symlinks for Jessie?  Besides
 the package listed, we are also concerned about the upgrade path from
 Wheezy.

I just did a bit more digging, and the compat symlinks have been
present since dpkg 1.15.0 (squeeze). I removed them in 1.17.0 because
the lintian check (which I've found now :), reported no more callers:

https://lintian.debian.org/tags/command-with-path-in-maintainer-script.html

but it seems that is not exhaustive. So we cannot really know how many
packages where affected in wheezy, w/o a full archive scan. :( At least
now we have an exhaustive list, which I could make dpkg Breaks/Conflicts
with in 1.18.x.

So, yes, given the above, I'll reinstate the compat symlinks for dpkg
1.17.22. It would be nice though, if as many of the fixes for the
remaining callers could be accepted for jessie, if possible?

Thanks,
Guillem


-- 
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/20141105202105.ga31...@gaara.hadrons.org

Packages using old dpkg tools paths

[Guillem Jover]

Hi!

I was notified by Emmanuel Bourg that there are still packages making
use of the old compat paths for u-a, dpkg-divert and dpkg-statoverride
in /usr/sbin. Those compat symlinks got removed in dpkg 1.17.0:

  ,---
  * Remove update-alternatives, dpkg-divert and dpkg-statoverride
compatibility symlinks under /usr/sbin/.
  `---

I'm planning on starting to file bug reports for the source packages
below (BCCed). I've not checked (yet) how severe the dpkg-statoverride
ones are, but if most of them do not get fixed, I might consider
reintroducing the compat symlink for that one alone if the release-team
(CCed) sees fit to that. :/

I'm not entirely sure why most of those packages are using a construct
like this though:

  ,---
  if [ ! -x /usr/sbin/dpkg-statoverride ] || \
 ! dpkg-statoverride --list $CONF  /dev/null
  then
  […]
  fi
  `---

instead of just using the command directly? Maybe cargo-culted from
somewhere? I also thought there was a lintian warning on absolute path
usage, but either I cannot find it after a quick glance over the
website, the code, git log and BTS, or I misremembered.


Sources list (via codesearch.d.o)


,--- u-a ---
startupmanager_1.9.13-7/bootconfig/usplash.py
wmanager_0.2.1-11/debian/wmanagerrc-update
`---

,--- dpkg-divert ---
amule_2.3.1+git1a369e47-2/debian/amule-utils.preinst
amule_2.3.1+git1a369e47-2/debian/amule.preinst
`---

,--- dpkg-statoverride ---
acidbase_1.4.5-4/debian/postinst
beep_1.3-3/debian/postinst
geki2_2.0.3-8/debian/postinst
geki3_1.0.3-7/debian/postinst
gravitywars_1.102-32/debian/postinst
im_1:151-3/debian/postrm
man-db_2.7.0.2-2/debian/postinst
monsterz_0.7.1-7/debian/postinst
netdiag_1.1-1/debian/diagperm
netselect_0.3.ds1-26/debian/netselect.postinst
openssh_1:6.7p1-2/debian/openssh-client.postinst
openssh_1:6.7p1-2/debian/openssh-server.postinst
pconsole_1.0-11/debian/postinst
phpgacl_3.3.7-7.3/debian/phpgacl.postinst
pure-ftpd_1.0.36-3/debian/pure-ftpd-common.postinst
systemtap_2.6-0.1/debian/systemtap-runtime.postinst
tecnoballz_0.93.1-1/debian/tecnoballz.postinst
terminatorx_3.90-2/debian/postinst
tvtime_1.0.2-12.1/debian/postinst
xvt_2.1-20.1/debian/postinst
`---


dd-list
===

,---
Adrian Yanes de...@ayanes.com
   amule (U)

Alessio Treglia ales...@debian.org
   terminatorx (U)

Axel Beckert a...@debian.org
   pconsole

Barry deFreese bdefre...@debian.org
   gravitywars (U)
   monsterz (U)
   tecnoballz (U)

Colin Watson cjwat...@debian.org
   man-db
   openssh (U)

David Gil d...@telefonica.net
   phpgacl

Debian aMule Team pkg-amule-de...@lists.alioth.debian.org
   amule

Debian Games Team pkg-games-de...@lists.alioth.debian.org
   geki2
   geki3
   gravitywars
   monsterz
   tecnoballz

Debian Multimedia Maintainers 
pkg-multimedia-maintain...@lists.alioth.debian.org
   terminatorx

Debian OpenSSH Maintainers debian-...@lists.debian.org
   openssh

Debian QA Group packa...@qa.debian.org
   startupmanager
   tvtime

Gerfried Fuchs rho...@debian.org
   beep

Giuseppe Iuculano iucul...@debian.org
   amule (U)

Gonéri Le Bouder gon...@rulezlan.org
   geki2 (U)
   monsterz (U)

Javier Fernandez-Sanguino Pen~a j...@computer.org
   acidbase (U)
   phpgacl (U)

Javier Fernández-Sanguino Peña j...@debian.org
   netselect

Jeremy T. Bouse jbo...@debian.org
   acidbase

Markus Koschany a...@gambaru.de
   tecnoballz (U)

Matthew Vernon matt...@debian.org
   openssh (U)

Michael Meskes mes...@debian.org
   netdiag

Peter Pentchev r...@ringlet.net
   wmanager

Ritesh Raj Sarraf r...@debian.org
   systemtap

Sam Hocevar (Debian packages) sam+...@zoy.org
   geki2 (U)
   geki3 (U)
   gravitywars (U)
   monsterz (U)
   xvt

Sandro Tosi mo...@debian.org
   amule (U)

Stefan Hornburg (Racke) ra...@linuxia.de
   pure-ftpd

Tatsuya Kinoshita t...@debian.org
   im

Timo Juhani Lindfors timo.lindf...@iki.fi
   systemtap (U)
`---

Thanks,
Guillem


-- 
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/20141103102337.ga16...@gaara.hadrons.org

Re: inconsistent versions of M-A: same packages

[Guillem Jover]

[ Fixed CC and M-F-T addresses, and bounced to debian-release. ]

Hi!

On Sat, 2014-11-01 at 11:45:56 +0100, Marc Glisse wrote:
 sorry for the naive question, but is there a plan for massively rebuilding
 all Multi-Arch: same packages that have inconsistent version numbers
 across architectures before releasing Jessie?

That's something for the release-team and build admins.

 I understand that in testing or unstable, rebuilding for all platforms every
 time a single one needs a rebuild is costly. And there may be solutions in
 future versions of dpkg/apt to accept multiarch co-installations that differ
 only by a rebuild. But in the mean time, for a stable release like Jessie,
 it would be nice to be able to take advantage of the good work some
 maintainers have put into adapting their packages to M-A.

I was planning to propose a minimal fix in dpkg to the release-team,
after the current version has migrated. Of course if it is not accepted,
then targetted rebuilds might be needed instead, or a decision to ignore
it.

Thanks,
Guillem


-- 
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/20141101121711.ga14...@gaara.hadrons.org

Bug#767705: unblock: inetutils/2:1.9.2.39.3a460-3

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi!

Please unblock or reduce age-days for package inetutils so that it can
migrate before the freeze, it fixes a security issue, an instance of
CVE-2014-3634.

unblock inetutils/2:1.9.2.39.3a460-3

Thanks,
Guillem


-- 
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/20141102001615.ga10...@gaara.hadrons.org

Bug#767706: unblock: debsig-verify/0.13

[Guillem Jover]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock or reduce age-days for package debsig-verify so that it
can migrate before the freeze.

It fixes the code so that it now checks for errors returned by relevant
library and system calls, either directly or by switching to the more
tested code from libdpkg. This is particularly important given that
debsig-verify is one of the pieces in the packaging toolchain that
might be exposed to untrusted binary .deb packages. In addition this
version adds a new functional testsuite, which is run during the build.

unblock debsig-verify/0.13

Thanks,
Guillem


-- 
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/20141102002313.ga30...@gaara.hadrons.org

Bug#755850: Bug#753184: Bug#755850: wheezy-pu: package foremost/1.5.7-5

[Guillem Jover]

Hi!

On Wed, 2014-08-27 at 15:00:27 -0300, Raúl Benencia wrote:
 Hello Guillem. Let's try this once more. :-)

 On Wed, Aug 13, 2014 at 01:21:42PM +0200, Guillem Jover wrote:
  Thanks, although could you tweak a bit the changelog entry to mention
  what did the dpkg update break, or in other words what did you had to
  fix? Otherwise it's not very clear what is going on. Once that's done
  I'll be uploading the package.
 
 Fine. Attached you'll find a debdiff with a more verbose changelog
 entry. Here[0] is the link to the DSC, in case you need it.

I uploaded it yesterday, just letting you know in case you didn't
receive a mail from the upload.

 Thanks for your help. 

You're welcome!

Regards,
Guillem


-- 
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/20140908092859.ga28...@gaara.hadrons.org