Bug#987299: unblock: gstreamer1.0/1.18.4-1

[Ivo De Decker]

tags -1 confirmed moreinfo

On Thu, Apr 22, 2021 at 02:09:20PM +0200, Moritz Mühlenhoff wrote:
> Am Wed, Apr 21, 2021 at 09:31:12AM +0300 schrieb Sebastian Dröge:
> > In addition to various more minor bugs, this release also fixes 
> > CVE-2021-3497
> > and CVE-2021-3498 as well as other potentially security-relevant issues that
> > didn't get their own CVE.
> 
> JFTR, there was an earlier discussion about CVE-2021-3497/CVE-2021-3498 with
> Sebastian and given the way gstreamer release branches are handled we
> suggested to ask for an unblock of 1.18.4 (it's fundamentally quite similar
> to ffmpeg or vlc where we're also following release branches).

OK, thanks for the clarification.

You can go ahead with the uploads of these packages, and remove the moreinfo
tag from this bug once they are ready to migrate.

Please note that it seems there was a fix for #984579 in the upload to
unstable that isn't included in the upload to experimental. I assume this will
be fixed in the next upload as well.

Cheers,

Ivo

Bug#987262: [pre-approval] unblock: node-lodash/4.17.21+dfsg+~cs8.31.189.20210220-2

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Tue, Apr 20, 2021 at 08:25:53PM +0530, Pirate Praveen wrote:
> Please unblock package node-lodash/4.17.21+dfsg+~cs8.31.189.20210220-2
> 
> I'd like to include this in bullseye if possible. Attaching the debdiff
> (uploaded to experimental already). Since I was not sure, I did not upload
> to unstable.
> 
> [ Reason ]
> This fixes #979531 but it uses a new upstream version of lodash-cli which is
> embedded in node-lodash. We were unaware of the new location of this fork
> and were not able to build a part of node-lodash. Thanks to Akshay, we
> figured out the new location of lodash-cli and fixed the build.

It seems the RC bug fix is unrelated to the new upstream. Please prepare an
upload based on the version currently in testing that only contains the fix
for the RC bug, not the new upsteam.

Thanks,

Ivo

Bug#987158: unblock: chezscheme/9.5.4+dfsg-4

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Sun, Apr 18, 2021 at 05:47:44PM +0200, Göran Weinholt wrote:
> [ Other info ]
> I've prepared a source upload for unstable and I'm holding off on
> uploading it until I receive instructions from you.
> 
> unblock chezscheme/9.5.4+dfsg-4

Please go ahead with the upload to unstable and remove the moreinfo tag from
this bug once the package is ready to migrate.

Thanks,

Ivo

Bug#987022: unblock: spamassassin/3.4.5~pre1-4

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi Noah,

On Thu, Apr 15, 2021 at 11:52:39AM -0700, Noah Meyerhans wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> (I sent a similar message to debian-release recently, but am opening a
> bug under the expectation that the post will get lost in the noise.)
> 
> There are a few issues in spamassassin that need to be addressed prior to
> the bullseye release, and I'd like to discuss the best path forward.
> 
> Bullseye currently contains version 3.4.5~pre1-3, which is based on a
> pre-release of the 3.4.5 upstream release.  Upstream released 3.4.5 during
> the bullseye freeze, and followed up immediately with a 3.4.6 to fix two
> regressions [1] [2] that were not caught in testing.  The regressions are
> already present in 3.4.5~pre-3, so we'll need some form of an update.
> 
> I'd also like to include the fix for [3], which breaks installation in some
> (uncommon) scenarios.  The fix is small and should be low-risk.
> 
> These are all pretty clearly issues that need to get fixed.  What I'm
> specifically interested in discussing, though, is the various upstream
> commits between the 3.4.5-pre1 release and 3.4.5-final.  There are 37
> commits in this set, involved in fixing 10 upstream bugs.  As most of these
> bugs involve miscategorization of processed email, leaving them unfixed can
> potentially lead to data loss.
> 
> I've compiled a list of the upstream bugs fixed in their 3.4 branch at [4].
> 
> Most of the rest of the changes have to do with release administrivia
> and housekeeping (svn branch management, updating the Apache logo,
> updating version strings, spelling corrections, etc).
> 
> If it was completely up to me, I'd want 3.4.6-1 released with bullseye.
> It will be better supported by upstream and contains all the relevant
> bug fixes.  IMO it's less likely to introduce any new regressions than a
> 3.4.5-pre1-4 with relevant changes pulled back from upstream's svn.
> However, it's late in the freeze and I fully understand the policy wrt
> to new upstream releases.
> 
> The alternative is that we update to a 3.4.5~pre1-4 that cherry-picks
> only the specific commits targeting the bugs I'd like to fix.  This
> will definitely result in a smaller debdiff, but would still carry a
> comparable level of risk due to the cherry-picked changes being most
> of the actual code changes introduced upstream.
> 
> The debdiff for 3.4.6-1 is at [5].  The debdiff for 3.4.5~pre1-4 is at
> [6].

I suggest you upload 3.4.5~pre1-4 to unstable and 3.4.6-1 to experimental. I
haven't looked at 3.4.5~pre1-4 in detail yet, but I suspect it will be fine.
Once it migrates, we can look at 3.4.6-1 again, and by then, the upload to
experimental will at least show us obvious issues in the builds or the ci.

Please remove the moreinfo tag from this bug when 3.4.5~pre1-4 (or something
similar) is ready to migrate.

Thanks,

Ivo

Bug#986758: unblock: systemd/247.3-5

[Ivo De Decker]

Control: tags -1 confirmed d-i

Hi,

On Mon, Apr 12, 2021 at 08:54:51PM +0200, Michael Biebl wrote:
> control: retitle -1 unblock: systemd/247.3-5

This look ok. Kibi was already in Cc for the unblock-udeb (the original mail
is quoted below).

Cheers,

Ivo

> 
> Am 11.04.21 um 18:48 schrieb Luca Boccassi:
> > Please unblock package systemd
> > 
> > As requested by Michael, opening unblock ticket. Debdiff attached. Two
> > high-impact patches are backported from upstream and should be included
> > in Bullseye.
> 
> Thanks Luca!
> 
> > * Backport patch to fix assert with invalid LoadCredentials=
> >Regression introduced in v247, fixed in v249, see:
> >https://github.com/systemd/systemd/issues/19178
> >(Closes: #986302)
> > 
> > * network: Delay addition of IPv6 Proxy NDP addresses.
> >Fixes "IPv6 Proxy NDP addresses are being lost from interfaces after
> >networkd adds them". (Closes: #985510)
> > 
> > The first patch fixes a crash when a malformed option is set in any
> > unit.
> > 
> > unblock systemd/247.3-4
> 
> I decided to make a 247.3-5 upload to fix #975018 as well:
> 
> > udev-udeb: setup /dev/fd, /dev/std{in,out,err} symlinks
> > As systemd-udevd no longer sets them up itself, we create them manually
> > after mounting devtmpfs. This avoids breaking applications which expect
> 
> 
> Somehow this issue did not show up on the systemd bug tracker, so I
> completely forgot about it. Apologies for that.
> 
> This fixes a regression which e.g. broke fetch-url and triggered a
> workaround in debian-installer-utils_1.134:
> 
> >[ Raphaël Hertzog ]
> >* Use /proc/self/fd/4 instead of /dev/fd/4 to unbreak fetch-url with
> recent
> >  udev versions that no longer setup the /dev/fd symlink. Closes: #967546
> 
> 
> I'd rather see this fixed for good. It's possible that other applications
> expect those symlinks as well.
> 
> This does affect udev-udeb, so kibi's ack would be appreciated.
> 
> Thanks for considering,
> Michael
> 
> 
> unblock systemd/247.3-5

> diff --git a/debian/changelog b/debian/changelog
> index 22a8ad2..0588fec 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,27 +1,3 @@
> -systemd (247.3-5) unstable; urgency=medium
> -
> -  * udev-udeb: setup /dev/fd, /dev/std{in,out,err} symlinks.
> -As systemd-udevd no longer sets them up itself, we create them manually
> -after mounting devtmpfs. This avoids breaking applications which expect
> -those symlinks. (Closes: #975018)
> -
> - -- Michael Biebl   Mon, 12 Apr 2021 20:21:24 +0200
> -
> -systemd (247.3-4) unstable; urgency=medium
> -
> -  [ Luca Boccassi ]
> -  * Backport patch to fix assert with invalid LoadCredentials=
> -Regression introduced in v247, fixed in v249, see:
> -https://github.com/systemd/systemd/issues/19178
> -(Closes: #986302)
> -
> -  [ Michael Biebl ]
> -  * network: Delay addition of IPv6 Proxy NDP addresses.
> -Fixes "IPv6 Proxy NDP addresses are being lost from interfaces after
> -networkd adds them". (Closes: #985510)
> -
> - -- Michael Biebl   Sun, 11 Apr 2021 16:06:46 +0200
> -
>  systemd (247.3-3) unstable; urgency=medium
>  
>* pkg-config: make prefix overridable again (Closes: #984763)
> diff --git a/debian/extra/start-udev b/debian/extra/start-udev
> index 0a8b284..6048925 100755
> --- a/debian/extra/start-udev
> +++ b/debian/extra/start-udev
> @@ -6,11 +6,6 @@ fi
>  
>  if ! grep -E -q "^[^[:space:]]+ /dev devtmpfs" /proc/mounts; then
>  mount -n -o mode=0755 -t devtmpfs devtmpfs /dev
> -# Setup a few /dev symlinks, see #975018
> -[ ! -h /dev/fd ] && ln -s /proc/self/fd /dev/fd
> -[ ! -h /dev/stdin ] && ln -s /proc/self/fd/0 /dev/stdin
> -[ ! -h /dev/stdout ] && ln -s /proc/self/fd/1 /dev/stdout
> -[ ! -h /dev/stderr ] && ln -s /proc/self/fd/2 /dev/stderr
>  fi
>  
>  SYSTEMD_LOG_LEVEL=notice /lib/systemd/systemd-udevd --daemon 
> --resolve-names=never
> diff --git 
> a/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch 
> b/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch
> deleted file mode 100644
> index c9e3500..000
> --- a/debian/patches/LoadCredentials-do-not-assert-on-invalid-syntax.patch
> +++ /dev/null
> @@ -1,34 +0,0 @@
> -From: Luca Boccassi 
> -Date: Thu, 1 Apr 2021 22:18:29 +0100
> -Subject: LoadCredentials: do not assert on invalid syntax
> -
> -LoadCredentials=foo causes an assertion to be triggered, as we
> -are not checking that the rvalue's right hand side part is non-empty
> -before using it in unit_full_printf.
> -
> -Fixes #19178
> -
> -# printf [Service]nLoadCredential=passwd.hashed-password.rootn > 
> hello.service
> -# systemd-analyze verify ./hello.service
> -...
> -Assertion 'format' failed at src/core/unit-printf.c:232, function 
> unit_full_printf(). Aborting.
> -Aborted (core dumped)
> -
> -(cherry picked from commit f7a6f1226e800f7695c2073675523062ea697aa4)
> 
> - src/core/load-fragment.c | 2 +-
> - 1 file changed, 1 

Bug#986899: [pre-approval] unblock: apt/2.2.3

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Tue, Apr 13, 2021 at 06:46:57PM +0200, Julian Andres Klode wrote:
> [ Reason ]
> 
> Fix downloading packages from repositories without a Size field; those
> fail if the unsized package is the largest one on the server that's in
> the pipeline.
> 
> Add warnings for such repositories, to actually surface such
> repositories.
> 
> We also fix a unit test to not trigger a test failure and hence FTBFS.
> This only got triggered on Ubuntu's LTO toolchain so far, but is an
> actual bug - it's unclear why we haven't seen it before.
> 
> [ Impact ]
> 
> Repositories without Size fields, such as those generated by pulp,
> will have failing downloads.
> 
> Without the warning, users will have no clear deprecation, and the error
> in 2.3.y that will land in bookworm will be hard on them.
> 
> The test case fix should not have any impact on bullseye; well it
> _should_ not have worked before. It's mostly there for other
> downstreams, but I can't rule out the possibility of it triggering at
> some point after a toolchain update or by luck or whatever :D
> 
> [ Tests ]
> 
> We have added automatic integration tests for the unsized package
> stuff; and the unit test is well a unit test itself.
> 
> [ Risks ]
> 
> CI that checks for APT warnings will fail on broken repositories, as
> they'll get the warning :)
> 
> The maximum pipeline size now being calculated correctly for unsized
> packages should not cause any issue, as that could have returned 0
> (unknown) before already; though in practice, most times, you don't end
> up with packages with unknown size.
> 
> If you don't have a repo without a Size field, there should be no risk,
> as none of the code paths should be triggered.
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> [ Other info ]
> 
> unblock apt/2.2.3

Please go ahead with the upload and remove the moreinfo tag from this bug once
the package is ready to migrate.

Thanks,

Ivo

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

[Ivo De Decker]

Hi Guillem,

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 :)

Thanks,

Ivo

Bug#985958: [pre-approval] unblock: spip/3.2.11-2

[Ivo De Decker]

Control: tags -1 moreinfo

Hi David,

On Mon, Apr 12, 2021 at 04:46:35PM -0400, David Prévot wrote:
> Le 02/04/2021 à 16:41, Paul Gevers a écrit :
> > On 26-03-2021 20:53, David Prévot wrote:
> > > Please unblock package spip
> > 
> > This package does have a bit of a track record for security issues.
> 
> Indeed. Since 3.3 will soon be released, the 3.2 branch (as currently in
> testing) should mostly only receive security updates starting from now (and
> as you already pointed out, it probably will rather sooner than later).
> Updating SPIP to 3.2.11 in Bullseye should make our lives less sad during
> the Bullseye lifetime, by allowing us to (hopefully) simply cherry-pick
> further security fixes (rather than backporting them due to changes between
> 3.2.10 and 3.2.11).
> 
> > > [ Reason ]
> > > Upstream just released a new minor version to improve PHP 7.4 compat
> > > (latest version already improved PHP 7.3 compat). Since Bullseye ship
> > > with PHP 7.4, including those fixes should avoid future issues (I had
> > > to backport a PHP 7.3 compatibility issue with a buster-security upload
> > > already to fix a serious issue with plugins handling).
> > 
> > If I read the upstream CHANGELOG correctly, it seems that this was all
> > put together in a short time (days).
> 
> Indeed, they finally realized that compatibility with current PHP version is
> useful (I’ve tried pushing for a while, but was not very successful).
> 
> > Are you aware of any tests in the
> > package (I didn't spot them)? Does upstream have any testing infra?
> 
> Nothing I’m aware of, unfortunately. On the other hand, this version has
> been released upstream more than two weeks ago and I’m not aware of any
> reported regression.
> 
> > I'm seriously doubting if we'd not introduce more issues than we solve here.
> 
> I understand your concern, but SPIP 3.2.10, currently in Bullseye, is known
> to not be fully compatible with PHP 7.4, also in Bullseye.
> 
> > > [ Impact ]
> > > On top of fixing possible problems, this update avoids filling the
> > > web server error.log due to multiple warnings and deprecation notices.
> > 
> > Ack. Are those fixes cherry-pickable?
> 
> That’s the main purpose of all the changes from 3.2.10 to 3.2.11 actually.
> 
> > > [ Tests ]
> > > I only tested the package manually, but I’m keeping an eye on upstream
> > > issues that may arise about this new release.
> > 
> > See above. This doesn't sound great.
> 
> I understand, the timing of this release sucks, and I’ll trust the judgment
> of the release team.

Yeah, neither option sounds very good.

I'm leaning towards accepting it. I suggest you upload it to unstable, and
we'll leave it there for a while. If issues show up (either in unstable or
upstream), we can reconsider it.

I'm tagging the bug moreinfo for now. Please remove that when the upload has
been in unstable for a while.


Thanks,

Ivo

Bug#986439: [pre-approval] unblock: node-xmldom/0.5.0-1

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Tue, Apr 06, 2021 at 12:48:59AM +0200, Yadd wrote:
> [ Reason ]
> node-xmldom ≤ 0.4 do not correctly preserve system identifiers, FPIs or
> namespaces when repeatedly parsing and serializing maliciously crafted
> documents. This may lead to unexpected syntactic changes during XML
> processing in some downstream applications (CVE-2021-21366).
> 
> [ Impact ]
> Medium vulnerability
> 
> [ Tests ]
> Upstream provides new test for this vulnerability. Tested during build
> and autopkgtest. I verified also that node-jsonld autopkgtest is OK with
> this new version.
> Upstream test are not trivial tests but real ones.
> 
> [ Risks ]
> Upstream changed lib/dom-parser.js lib/dom.js and lib/sax.js to have a
> better XML doc check. Other changes have no impact.
> Note that license is changed, reported in debian/copyright

The diff is rather bug. A filtered diff with only the relevant changes would
have made things easier to review.

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

Please go ahead with the upload and remove the moreinfo tag from this bug once
the package is ready to migrate to testing.

Thanks,

Ivo

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

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

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).

> 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.

Please go ahead with the upload and remove the moreinfo tag from this bug when
the new version is in unstable.

[...]

> 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

Cheers,

Ivo

Re: Finding a tentative bullseye release date

[Ivo De Decker]

Hi Holger,

On 4/10/21 5:58 PM, Holger Wansing wrote:


  1. https://d-i.debian.org/testing-summary.html



It's of course additional work to file the unblock bugreports, but I would
do that, if there are no objections.


I went trough the list and unblocked all the translation updates. Let us 
know if I missed anything.


Cheers,

Ivo

Bug#986051: unblock: krb5/1.18.3-5

[Ivo De Decker]

Control: tags 986051 confirmed moreinfo

Hi Sam,

On Sun, Mar 28, 2021 at 02:13:29PM -0400, Sam Hartman wrote:
> [ Reason ]
> In #985739 it was pointed out that internal symbols disappeared from 
> libk5crypto.
> My bad; I noticed this, confirmed they were not externally visible, approved 
> the symbols file change, but didn't think about the upgrade implications.
> 
> What happens is that if the new libk5crypto3 is unpacked before the
> new libkrb5-3, the old libkrb5-3 breaks.  In the bug, the user managed
> to get into a position where pam_krb5 was broken and logins didn't
> work.

I was able to reproduce this issue with the following steps:

I started from the debian-10-generic-amd64-20210208-542.qcow2 buster cloud
image, and made sure root was able to login on the console (by setting a
password). After this, installing libk5crypto3 and libpam-modules from
bullseye (and the dependencies pulled in by apt) triggers this issue. At that
point, root is no longer able to log in on the console (I was able to login
via ssh using a key). Installing libkrb5-3 from bullseye fixes the issue.

The issue can also be triggered by installing libpam-krb5 (from buster), and
only upgrading libk5crypto3 to bullseye.

> So, update the breaks, or add an equals binary:Version depends, no big, right?
> 
> While I wasn't looking, krb5 has apparently become part of
> pseudo-essential.
> login->libpam-modules->libnsl->libtirpc3->libgssapi-krb5-2->libk5crypto3|libkrb5-3
> The only reason I even know that is because I've been tracking pam.
> 
> Long term, we don't want that.
> 
> As a result, it's probably the case in #985739 that pam_unix is broken as 
> well as pam_krb5.
> 
> I'm not really an expert on all the ways that dependency resolution
> gets complex for essential packages.  I do know that dependencies for
> essential packages are supposed to be pre-depends.  That's not
> currently the case for anything in krb5, or for libkeyutils,
> libcomerr-2, etc.
> 
> So, we have a few options.
> 
> 1) Add the breaks.  Things are fairly stable in this part of the
> dependency graph; it was 2016 when libk5crypto last had an
> internally-incompatible break.  That will probably work in practice.
> 
> On #debian-devel, Adrian Bunk argues that it should be a versioned conflicts 
> not a break
> because it's essential.  I'm not sure--I think in most situations the
> fact that you cannot unpack the breaking package without deconfiguring
> the broken package means that apt will simply reorder things so that
> libk5crypto3 comes before libkrb5-3 and all happens to be well with
> the breaks.

I did some tests with modified binaries with either the breaks or the
conflicts. Both result in the same upgrade order.

Looking at policy 7.4, the argument for conflicts could be that this is a case
"that must prevent both packages from being unpacked at the same time, not
just configured".
https://www.debian.org/doc/debian-policy/ch-relationships.html#conflicting-binary-packages-conflicts

I don't know if there is any situation where apt/dpkg would unpack
libk5crypto3 before libkrb5-3 if the breaks is present, so I don't know if it
makes any difference in practice.

Note that it's possible to install only
libgssapi-krb5-2 libk5crypto3 libkrb5-3 libkrb5support0
from bullseye on a buster system, and have a working system (note that I
didn't test if kerberos is actually working in this case, as I don't have a
kerberos setup). This means that I'm fairly confident that apt will be able to
solve this issue without creating other breakage, by just upgrading these
packages first (which it does in my tests).


I would unblock an upload with either the breaks or the conflicts.


> 2) Do we also want to add the pre-depends to krb5.  I'm nervous adding
> additional pre-depends this late in the process.
> 
> 3) Do we want to add pre-depends to the entire dependency chain from
> libpam-modules to libkeyutils|libcom-err2?  I think this is
> technically correct, but I am uncomfortable with it.

I agree that adding pre-depends at this point doesn't sound like something
that we should try.

> 4) Do we want to do enough surgery to pam to avoid krb5 being
> essential.  With my pam hat on in January, I concluded it was too late
> in the process for me to feel comfortable adequately testing a (not
> yet developed) patch.  That was before I realized how big of a deal it
> might be that krb5 had become essential.
> The solution basically involves making pam_unix dlopen its dependencies for 
> nis rather than  link-time dependencies.  So, ugly games with c macros or 
> wrappers trying to get some internally typed NIS APIs right.
> I definitely do not have time to develop the patch, although I could 
> potentially make time to review and help test.
> I consider this risky for bullseye.

I agree here as well.

> I think my recommendation is go approve the breaks change, and hope that's 
> good enough in practice.

OK.

Please remove the moreinfo tag from the unblock bug when the 

Bug#985408: unblock: mutter/3.38.4-1

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Wed, Mar 17, 2021 at 03:44:33PM +, Simon McVittie wrote:
> I would like to update mutter from our current heavily-patched 3.38.3
> (effectively 3.38.4~git20210309) to the upstream 3.38.4 release.

Please go ahead with the upload to unstable and remove the moreinfo tag from
this bug once the builds for the new version are done.

Thanks,

Ivo

Bug#985407: unblock: gnome-shell/3.38.4-1

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Wed, Mar 17, 2021 at 03:44:31PM +, Simon McVittie wrote:
> I would like to update gnome-shell from our current heavily-patched 3.38.3
> (effectively 3.38.4~git20210306) to the upstream 3.38.4 release.

Please go ahead with the upload to unstable and remove the moreinfo tag from
this bug once the builds for the new version are done.

Cheers,

Ivo

Bug#985228: unblock: petsc/3.14.5+dfsg1-2

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Sun, Mar 14, 2021 at 09:01:26PM +0100, Drew Parsons wrote:
> upstream released petsc 3.14.5 with bug fixes only.
> This will help improve the stability of the package over the lifetime
> of the bullseye release.

I'm not convinced this complies with the freeze policy (but see below).

> This update also fixes Bug#983892, fixing orphaned alternatives after
> removal of libpetsc64-complex3.14-dev,
> 
> [ Impact ]
> 
> If this release is not permitted into stable then some users may
> encounter the issues addressed by the patch, especially when running
> under MPI parallelization.  A range of bugs have been addressed:
> - MatBAIJ: Fix specialization for size 9
> - Do not use MPI_Bcast() on a single rank.
> - PCHPDDM: fix for KSPLSQR
> - DMPlexVTKWriteAll_VTU: a couple of bugfixes
> - handling error conditions in PetscOptions
> - handling NULL objects in Fortran interface
> - bugfix for MatMatMultSymbolic_MPIAIJ_MPIDense() 
> - CPARDISO: stick to OpenMPI BLACS when needed
> - minor Documentation fixes

> If the release is not allowed into stable then
> libpetsc64-complex3.14-dev will leave dangling alternatives links when
> removed.

This specific issue could be fixed without switching to a new upstream version
(as was done initially in 3.14.4+dfsg1-2).


> [ Tests ]
> 
> debian/tests autopkgtest is enabled.
> petsc debci tests have passed in unstable.
> 
> debci tests in client packages are also passing successfully in unstable
> (petsc4py, slepc, slep4py, deal.ii, dolfin, mshr, dolfinx)
> 
> sundials continues to build successfully.
> 
> [ Risks ]
> 
> The patch fixes a range of bugs, it is not a simple one-line patch.

> [ Checklist ]
>   [-] all changes are documented in the d/changelog
>   - documented as "New upstream release (bugfixes)"
>   [x] I reviewed all changes and I approve them
>   [ ] attach debdiff against the package in testing

We ask these this for a reason. The current diff between the version in
testing and unstable is very large and unreviewable. It certainly isn't going
to get unblocked like this. If you can provide a filtered diff, with only the
'real' changes, and not the noise generated by the new upstream release,
there's at least a chance we could look at them. Note that this doesn't
guarantee it will be unblocked. There's still a decent chance that the changes
will be too big.

Thanks,

Ivo

Bug#985139: unblock: manpages-l10n/4.9.3-1

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Sat, Mar 13, 2021 at 04:02:43PM +0100, Helge Kreutzmann wrote:
> Please unblock package manpages-l10n

In General, I think this is ok, if the issues below can be fixed fairly soon.

[...]

> Furthermore, I finally managed to contact Javier Fernández-Sanguino
> Peña, and we agreed that the very outdated spanish man page
> translations are taken over by manpages-l10n, manpages-es-extra is
> asked for removal.

The current version has this in debian/control:

Replaces: manpages-es (<= 1.55-10), manpages-es-extraA

That's clearly a typo. Please fix this first. When that fix is in unstable,
please remove the moreinfo tag from this bug and retitle it as needed.

I assume you tested the upgrade scenario from manpages-es-extra to the
packages that currently contain the manpages?

> I can prepare the debdiff, but it will contain lots of changes, since
> many man pages had updated (even if only due to po4a reformatting
> them).

Could you prepare a filtered debdiff between the version currently in testing
and the new upload to unstable, that doesn't contain the translation changes.
Also, please mention the command you used to do the filtering.

> [ Other info ]
> If there is any open question regarding this unblock, I'm most happy
> to provide it.
> 
> In the changelog unfortunately there is a typo, the new upstream
> versio is indeed 4.9.3, *not* 4.9.1.

As a new upload is needed anyway, you can fix this too.

Thanks,

Ivo

Re: Please also unblock the other cpl-plugin-* packages

[Ivo De Decker]

Hi Ole,

On 3/13/21 11:11 AM, Ole Streicher wrote:

I just found that you unblocked the packages cpl-plugin-hawki and
cpl-plugin amber, due to their fixing of grave/serious bugs (#984058 and
#984546).

There are however also other packages that had in fact the same bug
#984508; the bug author mentioned it there but didn't really open then.
Therefore, I fixed them as well (referencing all to the same bug). So
factically, they all fall into the same category.


Having separate bugs for each package puts the on our radar. Version 
tracking doesn't really work correctly when multiple packages close the 
same bug (and in fact, it isn't really the same bug, because it's 
present in each of these packages separately). But there's probably no 
point in changing that now.



Could I therefore ask you to unblock them as well? These are


For future reference: it's better to file an unblock request, to make 
sure the request doesn't get lost.



cpl-plugin-fors
cpl-plugin-giraf
cpl-plugin-muse
cpl-plugin-naco
cpl-plugin-uves
cpl-plugin-vimos
cpl-plugin-visir
cpl-plugin-xshoo


All unblocked.


These all have a targeted update that specifically fixed the mentioned bug.



Cheers,

Ivo

Re: Update luajit to git master version

[Ivo De Decker]

Hi,

On 3/8/21 11:05 AM, YunQiang Su wrote:

John Paul Adrian Glaubitz  于2021年3月8日周一 下午5:57写道：


Hello YunQiang!

On 3/8/21 10:50 AM, YunQiang Su wrote:

I upload the cur exp version to unstable with 2 days delay.


That's probably not such a good idea at this point of the release.

You should better check back with the release team as we're in the middle
of a freeze.


OK, dcuted. and CC release team.


You Cc-ed the release list without a specific question, so that's not 
very clear. If you want to ask for an unblock, please file an unblock 
request as described in

https://release.debian.org/bullseye/FAQ.html

However, if you are asking if it's a good idea to do an upload of luajit 
to unstable based on the current version in experimental, the answer is no.


Also, please note that your upload is still in the deferred queue, so if 
you tried to remove it, that must have failed somehow.


Cheers,

Ivo

Bug#926455: mail_autoremovals: incorrect version number in email warning

[Ivo De Decker]

Hi,

On Mon, Aug 17, 2020 at 10:33:09AM +0200, Matthijs Kooijman wrote:
> Looking at the mailer script [1], it seems it tracks the most recent autorm
> email notification timestamp (to make sure to send out a notification only
> every 20 days) for each package version separately. So this makes me suspect
> that when a package migrates to testing that is subject to autorm:
> 
>  1 the new version is first inserted into the `testing_autoremovals` table
>  2 the mail_autoremovals.pl script runs, sees this new version for which no
>notification was sent before, so immediately sends out a mail notification
>  3 the autorm status is cleared for the package, because the fixing version 
> was
>migrated to testing
> 
> I'm not quite sure where all this is orchestrated, so I couldn't check this in
> any code (other than the mail_autoremovals.pl code). Also, I can't remember
> seeing this behaviour before for packages where autorm was cleared by an
> upload, so I suspect that there might be a race condition between two 
> processes
> here.
> 
> Regardless, it seems that the new, fixing, version should *never* end up in 
> the
> `testing_autoremovals` table, since that version is really never subject to
> autorm AFAICS. So if my analysis is correct, maybe that's something that can 
> be
> fixed?

The main issue is that the 'affects_testing' field in the udd bugs table
doesn't provide information about the version that was used to decide if the
bug affects testing or not. When a new version migrates to testing, it can
take some time for this information to be recalculated based on the new
version. Until that is done, this information is wrong. The autoremoval info
will be calculated based on that. The correct way to solve this would be to
somehow include version information in the importer for bug information.

To work around the mailing problem, I changes the autoremoval importer to
reset the 'first_seen' timestamp when the version changes, and I changed the
mail script to avoid sending mail on the first day. When a new version
migrates, this should prevent a mail from being sent in the first 24 hours.
By the time those are passed, the bug status and the autoremoval info should
be up-to-date.

Please let me know if this doesn't solve the mail issue.

Thanks,

Ivo

Bug#145257: #145257 Re: why did hypercorn migrate to testing?

[Ivo De Decker]

Control: retitle -1 [britney] migrations can break build-depends

Hi,

On 6/29/20 5:15 PM, peter green wrote:
> However hypercorn just migrated to testing again, despite the fact that
> python-asynctest is rc buggy and not in testing. This leaves hypercorn
> in violation of "packages must be buildable within the same release".
>
> Any idea why this happened?

Thanks for pointing this out.

On 6/29/20 8:59 PM, Rebecca N. Palmer wrote:

hypercorn is arch:all, and their build-dependencies aren't checked:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=145257


Thanks for the reference. However, the info in this bug is outdated.

Arch: all build-dependencies have been checked for a while now (since 
cd08deb943 in Jan 2019), but see below.


I didn't close #145257 (and I'm not closing it now), because there are 
still situations where build-dependencies can be broken:


Build-dependencies are (currently) only checked in the excuses step. If 
src a has a build-dependency on binary b, and the excuse for b is a 
valid candidate, a will not be blocked. This means a will be able to 
migrate in the migration stage, even if b isn't able to migrate at that 
point.


Also, if src c has a build-dependency on binary d, and an update of d 
makes the build-dependency of c unsatisfiable, this will not be detected 
by britney.


Note that neither of these cases are arch: all specific. However, a 
common case for arch: any build-dependencies involves libraries, which 
usually also result in dependencies on the binaries. These dependencies 
are checked in the migration stage, so they usually prevent the cases 
described above.


The issue with hypercorn was that there is a bug in build-dependency 
checking when there are multiple build-dependencies that are not 
satisfiable in testing, but are satisfiable by from unstable. Only the 
last one was kept (uvloop in this case). I submitted a fix for this issue:


https://salsa.debian.org/release-team/britney2/-/merge_requests/47

Ivo

Re: ftp.debian.org: [rfc] improving point release workflow

[Ivo De Decker]

Hi,

On Sat, Sep 17, 2016 at 01:52:30PM +0200, Julien Cristau wrote:
> during point releases ftpmaster and SRM spend quite a bit of time
> waiting on each other.  It would be nice if we could avoid that.  One
> idea would be to have a "stable-staging" suite (or some such), not
> mirrored except on coccia (I guess), under SRM's control (via
> control-suite / import_dataset), where we could dump the bits we want
> from proposed-updates, ideally also run cruft-report / dominate / gps2,
> and do our checks in advance, so that on release day ftpmaster could
> just either copy that to stable, or still do the same dance as today,
> except that SRM's double checking would be much easier since we would
> already know the expected final state of things.
> 
> Comments / ideas / opinions?

I think we should give it a try.

If ftp-master creates a 'buster-staging' suite after the upcoming point
release, that can be set using control-suite, we can try to see if this is
useful. I can set up a britney instance that fills this suite based on stable
and pu, and keep an eye to see if something needs to be added to the dak
config for this. As Julien noted, this should allow checking the contents of
the upcoming point release before it actually happens.

If it turns out this is useful during later point releases, it can be kept. If
not, it can just be deleted again. Having this suite doesn't prevent doing a
point release based on stable an pu, as it is done now.


If we try this, I don't think buster-staging should be on the standard mirrors
right now. As we haven't tried this before, it's unclear how this would work.
Publishing it to the mirrors requires documenting the role of this suite to
users, which we shouldn't do at this point. If the suite is available on
respighi (for britney), that should be enough. If we decide to keep long term,
we can work out how/where to publish the suite and how to document it.

An important consideration is that there is a (real) risk that some versions
would go backwards in this suite: when a new version is added to
buster-staging, but issues are discovered before the point release, that
prevent the new version from going into stable, this has to be reverted in
buster-staging. For a (semi-)private suite, this isn't really an issue. Even
if the suite is used for (automated) qa, that shouldn't be a big issue. But if
users start installing it on 'real' systems, this would need attention. If we
publish this suite later on, we should think about a way to deal with this. I
don't think we should try to solve this issue right now.


More comments still welcome. Any objections?

Thanks,

Ivo

Re: migration of coq

[Ivo De Decker]

Hi,

On 3/22/20 9:45 PM, Ralf Treinen wrote:

Hello,

On Wed, Mar 18, 2020 at 10:50:13PM +0100, Ivo De Decker wrote:

On Wed, Mar 18, 2020 at 08:38:56PM +0100, Ralf Treinen wrote:



aac-tactics build-depends on coq. Currently, coq does no longer build
on i386, hence the same is true for aac-tactics. This will block
migration of aac-tactics to testing.


libaac-tactics-coq is not allowed to become uninstallable on i386 because it
is arch: all and i386 is a 'nobreakall' architecture in britney. When the new
aac-tactics migrates, the i386 binaries would be removed, making
libaac-tactics-coq uninstallable on i386. A manual (allow-uninst) hint is
necessary to allow this. I just added such a hint, so aac-tactics should
migrate once the 5 days are over. If it doesn't (and it's unclear why), please
feel free to check again with us.


Could you please hint the following packages as allow-uninst as well.
These are Architecture=all packages which currently are no longer
installable on i386 as coq currently has build failures on this
architecture:

libfloat-coq
libssreflect-coq


I added those as well.


I hope that this unblocks the migration of coq.


If it doesn't, let us know and we'll have a look.


Thanks in advance -Ralf.


Cheers,

Ivo

Bug#939989: transition: gdal

[Ivo De Decker]

Hi,

On 1/21/20 5:51 AM, Sebastiaan Couwenberg wrote:

On 1/20/20 5:38 AM, Sebastiaan Couwenberg wrote:

Looks like britney needs some help to migrate everything to testing. The
update_output.txt shows most rdeps, I can't make sense of why it's not
migrating them.


Paul asked me to look at this. It seems the openscenegraph binNMU picked 
up a dependency on the newer coin3, which can't migrate (it needs the 
new libglvnd, which seems to break a number of packages, I didn't 
investigate why).



DDPO shows 3.0.3+dfsg-1 in testing-proposed-updates, is that intended?


Yes. I copied gdal to t-p-u to do a rebuild of openscenegraph there, in 
the hope that that one would be able to migrate.


Cheers,

Ivo

Bug#945471: britney crashes when trying removal multiple times

[Ivo De Decker]

On Mon, Nov 25, 2019 at 03:21:47PM +0100, Ivo De Decker wrote:
> The root cause is that items that migrate due to the easy hint, are tried
> again during the main run. This started with commit
> 6174d2c3f9590eba90f9c6dd613a553edd3a80e6
> 
> After this commit, the 'selected' items are no longer removed from
> self.upgrade_me, because the items are represented by different objects in
> both cases:
> 
> self.upgrade_me = [x for x in self.upgrade_me if x not in set(selected)]
> https://salsa.debian.org/release-team/britney2/blob/master/britney.py#L1113
> 
> Example (from test takeover-removal-easy): both contain 'linux/5.3-1' and
> '-linux-latest/10', but the objects are different:
> 
> selected: [, 
> ]
> upgrade_me: [, 
> ]
> 
> 
> The commit mentioned above might have caused similar issues elsewhere in the
> code.
> 
> Note that, for test takeover-removal-easy, not only '-linux-latest/10' is
> tried again, but also 'linux/5.3-1'. For the latter, all binaries are removed
> and added again when it 'migrates' for the second time. There are probably
> corner cases where this would also cause unwanted behaviour.

The root cause of the issue is that the MigrationItem object can be versioned
or unversioned. When comparing a versioned to an unversioned item from the
same source, they match, however, the hashing function will return a different
value. So whenever a set is used, this goes wrong. The way to fix this is to
make all (relevant) migrationitems versioned and don't allow unversioned
migration items to be hashed.

Ivo

Bug#945929: nmu: php7.3_7.3.11-1~deb10u1

[Ivo De Decker]

Hi Andreas,

Thanks for your work tracking broken/uninstallable packages.

On Sun, Dec 01, 2019 at 11:32:11AM +0100, Andreas Beckmann wrote:
> nmu php7.3_7.3.11-1~deb10u1 . ANY . unstable . -m "Rebuild in sid."
> 
> I don't know what happened to 7.3.11-1 ... but currently we have a
> version skew
> 
> php7.3 | 7.3.10-1 | testing| source, all
> php7.3 | 7.3.11-1~deb10u1 | stable | source, all
> php7.3 | 7.3.11-1~deb10u1 | unstable   | source, all
> 
> and the 7.3.11-1~deb10u1 security cannot migrate to testing because of
> * maintainer built binaries for the security upload
> * snmp transition that was done in sid some time ago
> A binNMU should get the package into testing.

In this case, I'm reluctant to do this. What is really needed here is an
upload of the newer version to unstable. If nobody is willing to work on that,
I don't know if we can keep php7.3 in bullseye.

If there is an indication that a new upload is coming (fairly soon), and that
this is a temporary workaround, that might be a different situation.

Thanks,

Ivo

Bug#945471: britney crashes when trying removal multiple times

[Ivo De Decker]

Package: release.debian.org
Severity: serious
User: release.debian@packages.debian.org
Usertags: britney

Hi,

When a removal is done during an easy hint, the removal is tried again
afterwards, causing a crash.

There is a testcase for this in the testsuite (test takeover-removal-easy).

A workaround would be to throw an exception in this case:

https://salsa.debian.org/release-team/britney2/merge_requests/31


The root cause is that items that migrate due to the easy hint, are tried
again during the main run. This started with commit
6174d2c3f9590eba90f9c6dd613a553edd3a80e6

After this commit, the 'selected' items are no longer removed from
self.upgrade_me, because the items are represented by different objects in
both cases:

self.upgrade_me = [x for x in self.upgrade_me if x not in set(selected)]
https://salsa.debian.org/release-team/britney2/blob/master/britney.py#L1113

Example (from test takeover-removal-easy): both contain 'linux/5.3-1' and
'-linux-latest/10', but the objects are different:

selected: [, 
]
upgrade_me: [, 
]


The commit mentioned above might have caused similar issues elsewhere in the
code.

Note that, for test takeover-removal-easy, not only '-linux-latest/10' is
tried again, but also 'linux/5.3-1'. For the latter, all binaries are removed
and added again when it 'migrates' for the second time. There are probably
corner cases where this would also cause unwanted behaviour.


In addition to a fix, it might be useful to extend the testsuite to discover
unexpected behaviour like this. One step could be to make the tests fail if a
MigrationConstraintException is triggered (except for tests where this is
explicitly allowed, because they are designed to trigger it). Also, the
consistency checks could be extended to check the validity of upgrade_me wrt
the current state of testing.

Comments welcome...

Ivo

Re: Please allow optimir to migrate to testing

[Ivo De Decker]

Hi,

On 9/20/19 11:10 AM, Dylan Aïssi wrote:

Hi release team,

I guess the summer break period (+ debconf2019) was not the best time
for my request. I try it again :-), could you allow optimir to migrate
to testing?


There is now a new britney hint 'allow-uninst', to avoid the need for a 
(dangerous) 'force-hint'. I added an allow-uninst for optimir on i386. 
It should migrate soon.


Thanks,

Ivo

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

[Ivo De Decker]

Hi,

On 8/9/19 4:41 PM, Karsten Merker wrote:

On Fri, Aug 09, 2019 at 02:31:47PM +0200, Ivo De Decker wrote:

Some random notes (these are just my preliminary thoughts, not a new release
team policy):

[...]

- We are talking about having both native 32-bit and 64-bit packages in
   the same environment. We are NOT talking about emulated builds. The
   resulting (32-bit) binaries still need to run natively in the build
   environment.


Hello,

this requirement poses a significant difficulty: while 64bit x86
CPUs can always execute 32bit x86 code, the same isn't
necessarily the case on other architectures. On arm, there is no
requirement that an arm64 system has to be able to execute 32bit
arm code and in particular in the arm server space, i.e. on the
kind of hardware that DSA wants to have for running buildds on,
64bit-only systems are becoming more and more common. On RISC-V
the 64bit and 32bit ISAs have been disjunct forever, i.e. there
is no riscv64 system that can natively execute riscv32 code. I
don't know what the situation looks like in mips and ppc/power
land but I wouldn't be surprised if developments would go into
the same direction there.


To be clear:

This requirement would only apply for 32-bit ports that are built with 
64-bit compilers. For ports that are built natively (as happens now) 
nothing would change.


So if (say) armhf would be built using 64-bit (arm64) compilers, the 
build environment for armhf would need to be able to run both the 64-bit 
and 32-bit binaries natively.


For 64-bit architectures that are built natively (like arm64), there is 
no requirement that these buildds should be able to run 32-bit binaries.


If (some of) the arm64 buildds would run on hardware that doesn't 
support 32-bit, that would obviously mean that builds for armel and 
armhf would have to be done on other hardware.


And for 32-bit architectures that are built natively, there is no 
requirement that the buildds should be able to run 64-bit binaries 
(assuming building on 32-bit still works).


I hope this clarifies what I meant.

Ivo

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

[Ivo De Decker]

Hi Aurelien,

On 8/8/19 10:38 PM, Aurelien Jarno wrote:


32-bit processes are able to address at maximum 4GB of memory (2^32),
and often less (2 or 3GB) due to architectural or kernel limitations.


[...]

Thanks for bringing this up.


1) Build a 64-bit compiler targeting the 32-bit corresponding
architecture and install it in the 32-bit chroot with the other
64-bit dependencies. This is still a kind of cross-compiler, but the
rest of the build is unchanged and the testsuite can be run. I guess
it *might* be something acceptable. release-team, could you please
confirm?


As you noted, our current policy doesn't allow that. However, we could 
certainly consider reevaluating this part of the policy if there is a 
workable solution.


Some random notes (these are just my preliminary thoughts, not a new 
release team policy):


- There would need to be a team of '32-bit porters' (probably
  overlapping with the porters for the remaining 32-bit architectures)
  who manage the changes to make and keep this working. Without a team
  committed to this, we can't really support this in a stable release.

- There would need to be a rough consensus that the solution is the way
  to go.

- The solution needs to work on the buildds. We still want all binaries
  to be built on the buildds.

- We are talking about having both native 32-bit and 64-bit packages in
  the same environment. We are NOT talking about emulated builds. The
  resulting (32-bit) binaries still need to run natively in the build
  environment.

- It's not our intention to lower the bar for architectures in testing.
  On the contrary. We intend to raise the bar at some point. As we
  already stated in the past, we would really prefer if more release
  architectures had some type of automated testing (piuparts,
  autopkgtests, archive rebuilds, etc). Eventually, this will probably
  become a requirement for release architectures.

- For architectures to be included in a future stable release, they
  still need to be in good enough shape. I won't go into everything
  involved in architecture qualification in this mail, but I do want to
  mention that the buildd capacity for mipsel/mips64el is quite limited.
  During the buster release cycle, they had trouble keeping up. If this
  continues, we might be forced to drop (one of) these architectures in
  the near future.


In the past it would have been enough to "just" do that for GCC, but
nowadays, it will also be needed for rustc, clang and many more. The
clang case is interesting as it is already a cross-compiler
supporting all the architectures, but it default to the native
target. I wonder if we should make mandatory the "-target" option,
just like we do not call "gcc" anymore but instead "$(triplet)-gcc".
Alternatively instead of creating new packages, we might just want
to use the corresponding multiarch 64-bit package and use a wrapper
to change the native target, ie passing -m32 to gcc or -target to
clang.


I think a solution based on multiarch packages would probably be nicer 
than the mess of having packages for the 32-bit arch that contain the 
64-bit compiler.


Thanks,

Ivo

Re: Bits from the Release Team: ride like the wind, Bullseye!

[Ivo De Decker]

On 8/3/19 8:31 PM, Ivo De Decker wrote:

Hi,

On 8/3/19 10:12 AM, Andreas Beckmann wrote:

Q: BinNMUs of packages uploaded before this new policy that have
    arch:all binaries can no longer migrate to testing. Is that
    intentional?


I read this as:
Q: I already did a binary upload, do I need to do a new (source-only)
upload?


I read this as

Q: The maintainer-uploaded arch:all packages are already in testing.
Will new buildd-built binNMUs migrate to testing or do I need to do a
new source-only upload to "fix" the arch:all packages?


This isn't really intentional.


This should be fixed now.

Ivo

Re: Bits from the Release Team: ride like the wind, Bullseye!

[Ivo De Decker]

Hi,

On 8/3/19 10:12 AM, Andreas Beckmann wrote:

Q: BinNMUs of packages uploaded before this new policy that have
arch:all binaries can no longer migrate to testing. Is that
intentional?


I read this as:
Q: I already did a binary upload, do I need to do a new (source-only)
upload?


I read this as

Q: The maintainer-uploaded arch:all packages are already in testing.
Will new buildd-built binNMUs migrate to testing or do I need to do a
new source-only upload to "fix" the arch:all packages?


This isn't really intentional. However, if you're worried about delays 
following uploads of new versions, keep in mind that a possible fix for 
this will almost certainly take more time than the delay caused by new 
uploads.


Also, given that we eventually want to get rid of the old binaries 
uploaded by maintainers, a fix for this is low priority (if it happens 
at all).


Cheers,

Ivo

Re: testing migration aging and reproducible builds

[Ivo De Decker]

Hi Vagrant,

On 7/21/19 4:55 PM, Vagrant Cascadian wrote:


I think it's:

   https://tests.reproducible-builds.org/reproducible-tracker.json

Which only shows results for "bullseye" (formerly only "buster).

We wanted to filter out the unstable and experimental suites from the
tracker which may have larger numbers of variations (e.g. build path),
some of which may be just be distracting to developers at this point
until we have a more complete fix for those issues.

I'm not sure relying on our test infrastructure at the moment is the
right approach long-term, maybe fine in the short-term.

We really need to start doing verification of buildd builds rather than
simply rebuilding packages twice with variations. Was hoping to put
together a BoF this week with DSA about that; maybe release team would
also be interested?


Sure, just let me know the details.

Ivo

Re: testing migration aging and reproducible builds

[Ivo De Decker]

Hi Chris,

On 7/21/19 4:09 PM, Chris Lamb wrote:

So, the devil is very much in the details here, alas. Whilst I am a
definite +1 on this idea the day-to-day experience may not be ideal
so your thoughts are very welcome.

Just to take one recent example: I noticed yesterday a regression
whereby one of our tools (strip-nondeterminism) is causing a fair
number of Java packages to be unreproducible — it would seem a little
antisocial to block them from migrating to testing when it was "our"
fault. It is not really within the power or remit of the maintainers
in-question to fix this particular issue, and we should not implicitly
encourage maintainers to manually (!) fix it in each of the affected
packages just to get it to migrate...

Similar mishaps or problems with the testing framework itself are
usually more typical than the above but would have the same effect of
directing a lot of distracting and demotivating blowback in our
direction.


Thanks for raising this concern. As with other policies, we should try 
to find a balance. I also expect this to be something that needs to be 
fine-tuned over time. The details haven't been worked out yet, and there 
have already been a number of interesting suggestions in this thread.


I guess a lot will depends on the impact of the delay. If the difference 
in migration delay is small enough, then there would still be an 
incentive to make packages reproducible, but it wouldn't create too much 
of an issue if there is a temporary problem that makes some packages 
unreproducible in a way the maintainer can't fix.


Adding a long delay or even blocking unreproducible packages doesn't 
seem to be appropriate at this point.


Note that (temporary) breakage, causing unexpected FTBFS, is 
(unfortunately) already fairly common in unstable. This is part of the 
way unstable works. If some change makes a number of packages 
unreproducible, people can always try to fix that themselves (worst case 
with an NMU). If these kinds of issues are rare enough, it should be OK. 
If not, the policy might need to be relaxed.


If infrastructure issues cause the reproducibility information to be 
unreliable, the impact on testing migration should be disabled.


As with autopkgtests, we can always (temporarily) add overrides for 
certain issues if development is being stalled by them.



Note that delaying migration here has quite a different consent
and social dynamic to autopkgtest failures as the maintainers have,
by uploading a package that contains autopkgtests, implicitly opted
into the committment to ensure they continue to pass.


Just FTR: this isn't correct: if package A, which depends on package B, 
adds an autopkgtest, this can block the migration of package B, even 
though package B didn't opt in.



Anyway, your thoughts on this important angle?


Once we have worked out what tests should actually be used for this and 
how the information about them is exchanged, we can create an 
implementation to see the impact, and improve it based on the results we 
see over time.


Cheers,

Ivo

Re: Bits from the Release Team: ride like the wind, Bullseye!

[Ivo De Decker]

Hi Ben,

Sorry for not getting back to you about this earlier.

On 7/7/19 3:43 PM, Ben Hutchings wrote:

On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote:
[...]

No binary maintainer uploads for bullseye
=

The release of buster also means the bullseye release cycle is about to begin.
 From now on, we will no longer allow binaries uploaded by maintainers to
migrate to testing. This means that you will need to do source-only uploads if
you want them to reach bullseye.


I support this move in principle, but:


   Q: I already did a binary upload, do I need to do a new (source-only) upload?
   A: Yes (preferably with other changes, not just a version bump).

   Q: I needed to do a binary upload because my upload went to the NEW queue,
  do I need to do a new (source-only) upload for it to reach bullseye?
   A: Yes. We also suggest going through NEW in experimental instead of unstable
  where possible, to avoid disruption in unstable.

[...]

This is not going to fly for src:linux.  We can't stage ABI bumps in
experimental as we typically have a different upstream versions in
unstable and experimental.  We even need to do ABI bumps in stable from
time to time.


We are aware that src:linux is a special case here. I added an exception 
for the arch:all binaries from src:linux. When the next ABI bump in 
unstable happens, feel free to let me know, so that I can check if it 
works as expected.


Thanks,

Ivo

testing migration aging and reproducible builds

[Ivo De Decker]

Hi reproducible builds team,

The release team is planning to revisit the testing migration aging 
policy in the near future. The details haven't been worked out yet, but 
we are considering to use reproducibility of packages as one of the new 
factors that could influence the aging.


For this to be possible, we would need to have an automated way to get 
data about the source packages for which the binaries from the buildds 
can be reproduced. Would this be something that could be arranged?


Thanks,

Ivo

Bug#931043: unblock: expat/2.2.6-2

[Ivo De Decker]

Control: tags -1 d-i

Hi,

On Tue, Jun 25, 2019 at 06:59:09AM +0200, Salvatore Bonaccorso wrote:
> Please unblock package expat, it fixes CVE-2018-20843 and got fixed by
> Laszlo cherry-picking the upstream fix. The issue is tracked as
> #931031 in the BTS:
> 
> > expat (2.2.6-2) unstable; urgency=high
> > 
> >   * Fix extraction of namespace prefix from XML name (CVE-2018-20843)
> > (closes: #931031).
> > 
> >  -- Laszlo Boszormenyi (GCS)   Mon, 24 Jun 2019 21:18:31 
> > +
> 
> unblock expat/2.2.6-2

I'm fine with this, but expat has a udeb, so this needs a d-i ack. Kibi Cc's
(and diff quoted below for easy review).

Thanks,

Ivo


> diff -Nru expat-2.2.6/debian/changelog expat-2.2.6/debian/changelog
> --- expat-2.2.6/debian/changelog  2018-08-15 17:18:15.0 +0200
> +++ expat-2.2.6/debian/changelog  2019-06-24 23:18:31.0 +0200
> @@ -1,3 +1,10 @@
> +expat (2.2.6-2) unstable; urgency=high
> +
> +  * Fix extraction of namespace prefix from XML name (CVE-2018-20843)
> +(closes: #931031).
> +
> + -- Laszlo Boszormenyi (GCS)   Mon, 24 Jun 2019 21:18:31 
> +
> +
>  expat (2.2.6-1) unstable; urgency=medium
>  
>* New upstream release.
> diff -Nru 
> expat-2.2.6/debian/patches/Fix_extraction_of_namespace_prefix_from_XML_name.patch
>  
> expat-2.2.6/debian/patches/Fix_extraction_of_namespace_prefix_from_XML_name.patch
> --- 
> expat-2.2.6/debian/patches/Fix_extraction_of_namespace_prefix_from_XML_name.patch
>  1970-01-01 01:00:00.0 +0100
> +++ 
> expat-2.2.6/debian/patches/Fix_extraction_of_namespace_prefix_from_XML_name.patch
>  2019-06-24 23:18:31.0 +0200
> @@ -0,0 +1,23 @@
> +From 11f8838bf99ea0a6f0b76f9760c43704d00c4ff6 Mon Sep 17 00:00:00 2001
> +From: Sebastian Pipping 
> +Date: Wed, 12 Jun 2019 15:42:22 +0200
> +Subject: [PATCH] xmlparse.c: Fix extraction of namespace prefix from XML name
> + (#186)
> +
> +---
> + expat/lib/xmlparse.c | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/expat/lib/xmlparse.c b/expat/lib/xmlparse.c
> +index 30d55c5c..737d7cd2 100644
> +--- a/expat/lib/xmlparse.c
>  b/expat/lib/xmlparse.c
> +@@ -6080,7 +6080,7 @@ setElementTypePrefix(XML_Parser parser, ELEMENT_TYPE 
> *elementType)
> +   else
> + poolDiscard(>pool);
> +   elementType->prefix = prefix;
> +-
> ++  break;
> + }
> +   }
> +   return 1;
> diff -Nru expat-2.2.6/debian/patches/series expat-2.2.6/debian/patches/series
> --- expat-2.2.6/debian/patches/series 1970-01-01 01:00:00.0 +0100
> +++ expat-2.2.6/debian/patches/series 2019-06-24 23:18:31.0 +0200
> @@ -0,0 +1 @@
> +Fix_extraction_of_namespace_prefix_from_XML_name.patch

Bug#931064: unblock: grub2/2.02+dfsg1-20

[Ivo De Decker]

Control: tags -1 confirmed d-i

Hi,

On Tue, Jun 25, 2019 at 01:33:50PM +0100, Steve McIntyre wrote:
> Subject: unblock: grub2/2.02+dfsg1-20

Unblocked. Still needs the unblock u-deb (kibi Cc'ed).

Thanks,

Ivo

Bug#930715: release.debian.org: gcc-mingw-w64 Buster upload

[Ivo De Decker]

user release.debian@packages.debian.org
usertag 930715 unblock
tags 930715 confirmed moreinfo
retitle 930715 unblock: gcc-mingw-w64/21.3~deb10u1
thanks


Hi,

Please note that you didn't use the correct usertag. Please do so in the
future to avoid the bug getting missed.

On Wed, Jun 19, 2019 at 09:27:46AM +0200, Stephen Kitt wrote:
> I uploaded an updated gcc-mingw-w64 package to unstable, 21.3, with a
> fix for #928214. I’ve since been informed (by Paul Gevers, re
> Mednafen) that gcc-8 8.3.0-7 won’t be migrating, which means
> gcc-mingw-w64 21.3 won’t either.
> 
> Could I upload the package as 21.3~deb10u1 to testing-pu? The diff
> between 21.2 and 21.3 is as follows:

OK. Please go ahead with the 21.3~deb10u1 upload and set the distribution to
'buster' (not 'testing' or 'testing-proposed-updates') and remove the moreinfo
tag from this bug once the upload has been accepted and built everywhere.

> The package is currently building in unstable, with a killed job on
> i386 for some reason; it also builds fine in testing.

I guess there was a buildd reboot. I gave back the build for unstable on i386.

Thanks,

Ivo

Bug#930597: unblock: pikepdf/1.0.5+dfsg-3 -- redux

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Sun, Jun 16, 2019 at 10:37:01AM +0100, Sean Whitton wrote:
> pikepdf 1.0.5+dfsg-3 was unblocked by nthykier but has not migrated:
> 
> Migration status: Blocked. Can't migrate due to a non-migratable
> dependency. Check status below.
> Blocked by: gcc-8
> 48 days old (2 needed)
> 
> People in #debian-release told me I should ask whether I can upload
> pikepdf to testing-proposed-updates to bypass this problem.

OK. Please remove the moreinfo tag from this bug once the upload is ready to
be unblocked.

> (I guess with version number 1.0.5+dfsg-2+deb10u1 ?)

No. For a rebuild of 1.0.5+dfsg-3, the preferred version is
1.0.5+dfsg-3~deb10u1 (with the changelog entry for 1.0.5+dfsg-3 also in the
changelog). For patches on top of 1.0.5+dfsg-2 (but not a rebuild of a newer
version), the version would have been 1.0.5+dfsg-2+deb10u1, as you suggested.
Please set the distribution in the changelog to 'buster' (not 'testing' or
'testing-proposed-updates').

Thanks,

Ivo

Bug#929214: release.debian.org - Add package constraint for cloud images

[Ivo De Decker]

Control: retitle -1 Add key package for cloud images

Hi,

On Sun, May 19, 2019 at 12:18:31PM +0200, Bastian Blank wrote:
> To make your and our work easier, we would like to ask you to add a
> package constraint for all the packages included into the official
> Debianm cloud images.
> 
> From what I read, the easiest way for you would be to specify a single
> package as constraint, a package that depends on all the other binary
> package we explicitely include in the images.
> 
> I intend to add one binary package per architecture we currently build
> images for: amd64, arm64 and ppc64el.  The dependencies will be arch
> dependent and auto-generated from our own list.
> 
> The package would look like this:
> 
> | Package: debian-cloud-images-packages
> | Architecture: amd64
> | Depends: apparmor, awscli, chrony, cloud-init, cloud-initramfs-growroot, 
> google-compute-engine, grub-cloud-amd64, grub-pc, libpam-systemd, 
> linux-image-amd64, linux-image-cloud-amd64, openssh-server, python, 
> python-boto, python3-boto, sudo, unattended-upgrades, waagent
> 
> Please acknowledge that such a package would be okay for using as
> constraint.  After that I'll upload that change.

Constraints are only used to check installability of packages that britney
wouldn't otherwise be able to check. This isn't necessary in this case. What
you want is a source package that is added to the key packages list, to
prevent auto-removal.

If you create such a package, having a binary per architecture as you
describe, should do what you want. It can be added to the list as soon as it
is in testing.

Please note that if some of the packages involved would cause serious issues
for the release, we might still notify you that we would be forced to
(manually) remove them if the issues aren't fixed.

Also, just as a suggestion: if it is feasible, you could add an autopkgtest to
that source to build (or even test) the cloud images. That would prevent
migration to testing of packages that break your images.

Cheers,

Ivo

Bug#930222: unblock: mailman-suite/0+20180916-9

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Sat, Jun 08, 2019 at 05:45:56PM +0200, Jonas Meurer wrote:
> Sorry to prod you again, but while working on mailman-suite I just
> realized that the build-time dependency on node-less is completely
> useless. So I now dropped it in a subsequent upload. I don't plan to do
> any further uploads of mailman3-web targeted for Buster.

If I understand you correctly, the useless dependency is harmless. In that
case, I'd rather not unblock it, as we are very close to the buster release.

If the dependency causes serious issues, please explain and remove the
moreinfo tag from this bug. Otherwise, please close this bug.

Thanks,

Ivo

Bug#930324: unblock: nageru/1.8.4-2

[Ivo De Decker]

Control: reopen -1

Hi,

On Mon, Jun 10, 2019 at 04:44:07PM +0200, Steinar H. Gunderson wrote:
> Please unblock package nageru

I unblocked it, but noticed it's stuck behind gcc-8. Can you prepare a
testing-proposed-updates upload?

Thanks,

Ivo

Re: That merged-usr is mandatory is RC

[Ivo De Decker]

Hi,

Given that there is still discussion about the impact of merged /usr at this
very late point of the freeze, I think having merged /usr by default for new
installations should be reconsidered.

On Sun, May 19, 2019 at 07:22:08AM -0400, Sam Hartman wrote:
> I've been debating doing this, but continue to believe that it's
> important after several days of pondering.  So, per constitution 5.1
> (2), I'd like to explicitly lend support to the idea that it would be
> really good if we provide our users a way to install buster without
> merged /usr.  I think that if we do not do so now, we need to be open to
> the possibility that if users are stymied in doing their work, we will
> need to do so in a buster point release even if we would not normally
> add something some might consider a feature in a point release.
> 
> I'm not speaking to whether I think it should be RC or even whether an
> expert only option is good enough.
> I am simply saying that with my DPL hat on, I think this issue is
> important enough it deserves real consideration.
> 
> 
> I think that the TC's ruling and ongoing experience suggests we have
> carefully considered how we want to approach merged /usr for our own
> internal work developing Debian and come to a position that at least for
> the moment seems to be working.
> 
> What I'm most concerned about is people who use Debian to develop
> software they plan to use on Debian but who are not part of Debian.
> Examples of this include people within organizations who build programs
> to distribute within their organization.  People who build upstream
> programs using configure from source.  That sort of thing.
> 
> These people may not use packages.  These people may not use chroots.

People who develop software often do this on different machines than the one
the software runs on. When the production server gets upgraded, and a new
development machine is installed, one will have merged /usr and the other
doesn't. This probably isn't very good. Having an option to change this during
the install probably won't help these users.

In general, I think that if merged /usr is the default for new installations
for a Debian release, it should be the default on upgrades to that release as
well. This is not the case for buster. Obviously changing the default on
upgrades needs carefull planning and should be started at the beginning of a
release cycle.

> They are our users; they are our priority.  Even if we believe using
> chroots or containers would be better for them, I don't think we should
> force people into changing their build processes.
> 
> 
> I don't think we have a good idea how big the impact will be for these
> users, and so, I think we should be conservative.
> 
> If we don't choose to be conservative, I think we should be extra
> willing to revisit our decision if we find we are wrong.

Please note that there were a number of bugs triggered by merged /usr that
were discovered during the freeze. Most of them were actual bugs in the
packages, but they were (only) triggered with merged /usr. The fact that they
were only discovered late in the release cycle isn't a good sign.

> Again, all I'm saying is that I think this issue is important enough to
> consider seriously.  I am not in a position to balance this issue
> against other things before us.
> I'm speaking as the DPL because I'm trying to consider something that is
> a project level concern.  However, this statement has no actual force as
> clearly spelled out in the constitution.
> I'm speaking in the hopes of getting people to take a moment, think
> about this issue and come to their own conclusions.

Having an option to allow experienced user to change the default doesn't
really solve this. So the way forward is to change the default back to not
having merged /usr on new installs.

Thanks,

Ivo

Bug#929108: unblock / tpu approval: gmsh/4.1.3+ds1-2

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi Ansgar,

On Fri, May 17, 2019 at 11:12:59AM +0200, Ansgar Burchardt wrote:
> gmsh has an old path to OpenCASCADE include files (#927808); this is
> easy to fix (see attached diff).
> 
> Rebuilding the package also changes a dependency on amd64 (libgmsh4.1
> depends on `libhdf5-openmpi-103 (>= 1.8.13)` instead of `libhdf5-103`
> after the rebuild); however this matches the dependency on i386.
> 
> However gmsh was updated to a new upstream release in unstable on
> 2019-03-02 with a small fix on 2019-03-04; this missed the freeze date
> slightly.
> 
> Do you prefer an upload via t-p-u or should I prepare a gmsh
> 4.1.5+really4.1.3+ds1-1 upload for unstable?

An upload to unstable would be preferred. So please go ahead with that and
remove the moreinfo tag from this bug once it is in unstable.

Thanks,

Ivo

Bug#928507: unblock: grub2/2.02+dfsg1-18

[Ivo De Decker]

Control: tags -1 confirmed d-i

Hi,

On Mon, May 06, 2019 at 01:07:50PM +0100, Colin Watson wrote:
> Please unblock grub2 2.02+dfsg1-18.  #927888 is RC; #927269 possibly
> should be RC since it entirely breaks one of GRUB's platforms; and
> #919915 causes upgrade trouble if you run into it.
> 
> (Apologies for the .gitignore/.bzrignore noise, which is the result of
> switching to using dgit as of this upload.  But it's easy enough to, er,
> ignore.)

I unblocked it, but it needs a d-i ack as well (Cc kibi, diff below).

> I don't remember if it needs to be done separately, but I've included
> the -signed versions in this unblock request just in case, since they
> should all go in together.
> 
> unblock grub2/2.02+dfsg1-18
> unblock grub-efi-amd64-signed/1+2.02+dfsg1+18
> unblock grub-efi-arm64-signed/1+2.02+dfsg1+18
> unblock grub-efi-ia32-signed/1+2.02+dfsg1+18

Thanks for mentioning this. A separate unblock is needed. I unblocked them as
well.

Ivo

> diff -Nru grub2-2.02+dfsg1/debian/.git-dpm grub2-2.02+dfsg1/debian/.git-dpm
> --- grub2-2.02+dfsg1/debian/.git-dpm  2019-03-23 13:48:41.0 +
> +++ grub2-2.02+dfsg1/debian/.git-dpm  2019-05-04 22:58:32.0 +0100
> @@ -1,6 +1,6 @@
>  # see git-dpm(1) from git-dpm package
> -3ddfe605a6a472100f529c3d7465bf4eb7fe954d
> -3ddfe605a6a472100f529c3d7465bf4eb7fe954d
> +9569221816a2a1a832be106440375a612e0121b7
> +9569221816a2a1a832be106440375a612e0121b7
>  59aeb1cfaa3d5bfd7bb0f0d37f6d9eed51fe
>  59aeb1cfaa3d5bfd7bb0f0d37f6d9eed51fe
>  grub2_2.02+dfsg1.orig.tar.xz
> diff -Nru grub2-2.02+dfsg1/debian/.gitignore 
> grub2-2.02+dfsg1/debian/.gitignore
> --- grub2-2.02+dfsg1/debian/.gitignore1970-01-01 01:00:00.0 
> +0100
> +++ grub2-2.02+dfsg1/debian/.gitignore2019-05-04 22:58:32.0 
> +0100
> @@ -0,0 +1,110 @@
> +*.bash-completion
> +*.config
> +*.debhelper*
> +*.postinst
> +*.postrm
> +*.preinst
> +*.templates
> +files
> +grub-common
> +grub-common.maintscript
> +grub-coreboot
> +grub-coreboot*.dirs
> +grub-coreboot*.install
> +grub-coreboot*.links
> +grub-coreboot*.maintscript
> +grub-coreboot-bin
> +grub-coreboot-dbg
> +grub-efi
> +grub-efi-amd64
> +grub-efi-amd64*.dirs
> +grub-efi-amd64*.install
> +grub-efi-amd64*.links
> +grub-efi-amd64*.maintscript
> +grub-efi-amd64-bin
> +grub-efi-amd64-dbg
> +grub-efi-amd64-signed-template
> +grub-efi-arm
> +grub-efi-arm*.dirs
> +grub-efi-arm*.install
> +grub-efi-arm*.links
> +grub-efi-arm*.maintscript
> +grub-efi-arm-bin
> +grub-efi-arm-dbg
> +grub-efi-arm64
> +grub-efi-arm64*.dirs
> +grub-efi-arm64*.install
> +grub-efi-arm64*.links
> +grub-efi-arm64*.maintscript
> +grub-efi-arm64-bin
> +grub-efi-arm64-dbg
> +grub-efi-arm64-signed-template
> +grub-efi-ia32
> +grub-efi-ia32*.dirs
> +grub-efi-ia32*.install
> +grub-efi-ia32*.links
> +grub-efi-ia32*.maintscript
> +grub-efi-ia32-bin
> +grub-efi-ia32-dbg
> +grub-efi-ia32-signed-template
> +grub-efi-ia64
> +grub-efi-ia64*.dirs
> +grub-efi-ia64*.install
> +grub-efi-ia64*.links
> +grub-efi-ia64*.maintscript
> +grub-efi-ia64-bin
> +grub-efi-ia64-dbg
> +grub-emu
> +grub-emu*.dirs
> +grub-emu*.install
> +grub-emu*.links
> +grub-emu*.maintscript
> +grub-emu-dbg
> +grub-extras-enabled
> +grub-extras/*/conf/*.mk
> +grub-firmware-qemu
> +grub-ieee1275
> +grub-ieee1275*.dirs
> +grub-ieee1275*.install
> +grub-ieee1275*.links
> +grub-ieee1275*.maintscript
> +grub-ieee1275-bin
> +grub-ieee1275-dbg
> +grub-linuxbios
> +grub-mount-udeb
> +grub-pc
> +grub-pc*.dirs
> +grub-pc*.install
> +grub-pc*.links
> +grub-pc*.maintscript
> +grub-pc-bin
> +grub-pc-dbg
> +grub-rescue-pc
> +grub-theme-starfield
> +grub-uboot
> +grub-uboot*.dirs
> +grub-uboot*.install
> +grub-uboot*.links
> +grub-uboot*.maintscript
> +grub-uboot-bin
> +grub-uboot-dbg
> +grub-xen
> +grub-xen*.dirs
> +grub-xen*.install
> +grub-xen*.links
> +grub-xen*.maintscript
> +grub-xen-bin
> +grub-xen-dbg
> +grub-xen-host
> +grub-yeeloong
> +grub-yeeloong*.dirs
> +grub-yeeloong*.install
> +grub-yeeloong*.links
> +grub-yeeloong*.maintscript
> +grub-yeeloong-bin
> +grub-yeeloong-dbg
> +grub2
> +grub2-common
> +prep-bootdev
> +stamps
> +tmp-*
> diff -Nru grub2-2.02+dfsg1/debian/changelog grub2-2.02+dfsg1/debian/changelog
> --- grub2-2.02+dfsg1/debian/changelog 2019-03-23 23:28:17.0 +
> +++ grub2-2.02+dfsg1/debian/changelog 2019-05-04 22:58:32.0 +0100
> @@ -1,3 +1,24 @@
> +grub2 (2.02+dfsg1-18) unstable; urgency=medium
> +
> +  * Apply patches from Alexander Graf to fix grub-efi-arm crash (closes:
> +#927269):
> +- arm: Move trampolines into code section
> +- arm: Align section alignment with manual relocation offset code
> +  * Make grub2-common Breaks+Replaces grub-cloud-amd64 (<< 0.0.4) to work
> +around that package shipping colliding configuration file names in
> +stretch-backports (closes: #919915).
> +  * Apply patch from Peter Jones to forbid the "devicetree" command when
> +Secure Boot is enabled (closes: #927888).
> +
> + -- Colin Watson   Sat, 

Bug#928306: unblock: liblivemedia/2018.11.26-1.1

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Wed, May 01, 2019 at 06:45:04PM +0200, Hugo Lefeuvre wrote:
> Please unblock package liblivemedia
> 
> Dear Release team,
> 
> liblivemedia 2018.11.26-1 from Buster is affected by CVE-2019-9215[1] and
> CVE-2019-7314[2], two security issues in the server part of the library.
> 
> The impact is at least DoS, which is trivial to manage using a publicly
> available script. In fact theses issues might allow any script kiddie to
> make any live555 server fully unusable.
> 
> These issues have been fixed in oldstable and stable. Not fixing them in
> Buster would be a security regression.
> 
> Sebastian Ramacher (Debian maintainer) did not want to take time for this
> NMU, but did not oppose either[3]. He meant that these CVEs are only
> affecting the server part of the library, which is not used by reverse
> dependencies.
> 
> debdiff with targeted fixes in attachment.

According to the security tracker, liblivemedia in buster/sid is also affected
by CVE-2019-7732 and CVE-2019-7733. Maybe you should consider fixing these as
well (if there is a fix available that's easy to apply to the version in sid).

Either way, the diff you attached to this bug look fine, so you can go ahead
with the upload to unstable and remove the moreinfo tag from this bug once the
package is in unstable. If you want to add targeted fixes for the two other
CVEs, you don't need to ask pre-approval for them, you can include them in the
upload to unstable and send an updated debdiff.

Thanks,

Ivo

Bug#928291: unblock: signing-party/2.10-1

[Ivo De Decker]

Control: tags -1 moreinfo confirmed

Hi,

On Wed, May 01, 2019 at 01:44:08PM +0200, Guilhem Moulin wrote:
> On Wed, 01 May 2019 at 12:46:12 +0200, Guilhem Moulin wrote:
> > gpg-key2ps(1) from signing-party 2.9-1 is vulnerable to CVE-2018-15599:
> > unsafe shell call enabling shell injection via a User ID.
> 
> Erm that should be CVE-2019-11627, and the changelog is wrong as well.
> Would you like me to upload a 2.10-1 with a fixed debian/changelog?

You can't upload 2.10-1 again, so that would need to be 2.10-2. In that case,
please don't include the 2.10-1 entry in the changelog, to make sure the wrong
CVE number isn't in there.

If you do so, please remove the moreinfo tag from this bug once the new
package is in unstable. Otherwise, you can remove the moreinfo tag and ask for
this version to be unblocked as well.

Thanks,

Ivo

Bug#928269: unblock: cryptsetup/2.1.0-3

[Ivo De Decker]

Control: tags -1 confirmed d-i

Hi,

On Tue, Apr 30, 2019 at 10:14:22PM +0200, Guilhem Moulin wrote:
> The cryptsetup package found in Buster, currently at version 2:2.1.0-2,
> contains regressions affecting unlocking using OpenSC (PKCS#15 compatible
> Smart Card):
> 
> [#926573] The `decrypt_opensc` keyscript poisons standard output,
> causing `cryptsetup open --key-file -` to fail.  (Since 2:2.0.3-7.)
> https://salsa.debian.org/cryptsetup-team/cryptsetup/merge_requests/8
> 
> [#928263] The initramfs hook fails to copy libpcsclite.so to the
> initramfs on non-usrmerge systems, causing the pcscd daemon to fail to
> start, hence failing unlocking at initramfs stage.  (Since 2:2.0.3-2.)
> 
> These regressions are RC for users relying on OpenSC integration, but
> the bugs have ‘Severity: important’ since src:cryptsetup is still usable
> to others.
> 
> Debdiff between 2:2.1.0-2 and 2:2.1.0-3 attached.

This looks ok, but needs a d-i ack. Cc'ed kibi.

Thanks,

Ivo

> diff -Nru cryptsetup-2.1.0/debian/changelog cryptsetup-2.1.0/debian/changelog
> --- cryptsetup-2.1.0/debian/changelog 2019-02-28 22:32:43.0 +0100
> +++ cryptsetup-2.1.0/debian/changelog 2019-04-30 21:20:47.0 +0200
> @@ -1,3 +1,12 @@
> +cryptsetup (2:2.1.0-3) unstable; urgency=medium
> +
> +  * d/scripts/decrypt_opensc: Fix standard output poisoning.  Thanks to Nils
> +Mueller for the report and patch.  (Closes: #926573.)
> +  * d/initramfs/hooks/cryptopensc: Ensure that libpcsclite.so is copied to 
> the
> +initramfs on non-usrmerge systems.  (Closes: #928263.)
> +
> + -- Guilhem Moulin   Tue, 30 Apr 2019 21:20:47 +0200
> +
>  cryptsetup (2:2.1.0-2) unstable; urgency=medium
>  
>* debian/copyright:
> diff -Nru cryptsetup-2.1.0/debian/initramfs/hooks/cryptopensc 
> cryptsetup-2.1.0/debian/initramfs/hooks/cryptopensc
> --- cryptsetup-2.1.0/debian/initramfs/hooks/cryptopensc   2019-02-28 
> 22:32:43.0 +0100
> +++ cryptsetup-2.1.0/debian/initramfs/hooks/cryptopensc   2019-04-30 
> 21:20:47.0 +0200
> @@ -47,7 +47,7 @@
>  # pcscd utilizes pthread_cancel
>  copy_exec /usr/sbin/pcscd
>  LIBC_DIR="$(ldd /usr/sbin/pcscd | sed -nr 's#.* => 
> (/lib.*)/libc\.so\.[0-9.-]+ \(0x[[:xdigit:]]+\)$#\1#p')"
> -find -L "$LIBC_DIR" -maxdepth 1 \( -name 'libgcc_s.*' -o -name 
> 'libusb-*.so*' -o -name 'libpcsclite.so*' \) -type f | while read so; do
> +find -L "$LIBC_DIR" "/usr$LIBC_DIR" -maxdepth 1 \( -name 'libgcc_s.*' -o 
> -name 'libusb-*.so*' -o -name 'libpcsclite.so*' \) -type f | while read so; do
>  copy_exec "$so"
>  done
>  
> diff -Nru cryptsetup-2.1.0/debian/scripts/decrypt_opensc 
> cryptsetup-2.1.0/debian/scripts/decrypt_opensc
> --- cryptsetup-2.1.0/debian/scripts/decrypt_opensc2019-02-28 
> 22:32:43.0 +0100
> +++ cryptsetup-2.1.0/debian/scripts/decrypt_opensc2019-04-30 
> 21:20:47.0 +0200
> @@ -12,7 +12,7 @@
>  check_card() {
>  cardfound=0
>  
> -if /usr/bin/opensc-tool -n 2>&1; then
> +if /usr/bin/opensc-tool -n >/dev/null 2>&1; then
>  cardfound=1
>  fi
>  }

Bug#928223: unblock / pre approval: otrs2/6.0.16-2

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Tue, Apr 30, 2019 at 09:55:58AM +0200, Patrick Matthäi wrote:
> I would like to upload the attached diff to fix several security issues in the
> buster otrs2 version.

Please go ahead and remove the moreinfo tag from this bug once the package is
in unstable.

Thanks,

Ivo

Bug#928111: [pre-approval] unblock: icu/63.2-1

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Sun, Apr 28, 2019 at 01:57:15PM +0200, László Böszörményi (GCS) wrote:
> Hi Release Team,
> 
> As Hideki Yamane noted on debian-release [1] Japanese new era is in
> effect. ICU upstream released the 63.2 version to address this. The
> packaging is ready to be uploaded. There are two things to consider.
> First that it contains other (not related to the new era), stable
> fixes as well. Including the two backported patches present in the
> 63.1-6 package.
> Second is that I've made local testing and only found a regression.
> Chromium (the browser) needs to be binNMUed as otherwise it will crash
> on startup.

First of all, we can't make a statement on something like this without seeing
the diff.

Secondly, the fact that chromium needs a rebuild suggest there is a change
that breaks something. This makes it very unlikely that this change is
appropriate at this point in the freeze. Maybe targeted fixes on top of 63.1
would be better.

Please do not upload 63.2 to unstable at this point.

I suggest you upload the new version to experimental. That way we can look at
the differences and people can test the new packages.

Thanks,

Ivo

Bug#928227: unblock: golang-golang-x-net-dev/1:0.0+git20181201.351d144+dfsg-3

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Tue, Apr 30, 2019 at 05:07:57PM +0800, Drew Parsons wrote:
> Please unblock package golang-golang-x-net-dev
> 
> Upstream has provided patches addressing security issues 
> CVE-2018-17846 / CVE-2018-17847 / CVE-2018-17848
> (Debian bug #911795).

How will unblocking this fix these issues? golang-golang-x-net-dev is embedded
in a number of packages in buster. If they are not updated, the unblock will
not fix anything. How will this be handled?

Thanks,

Ivo

Bug#924974: unblock (pre-approval) or RM: epiphany-browser/3.32.1.2-2

[Ivo De Decker]

Hi,

On Sat, Apr 20, 2019 at 09:49:25PM +0100, Simon McVittie wrote:
> Control: retitle -1 unblock (pre-approval) or RM: epiphany-browser/3.32.1.2-2
> 
> On Mon, 25 Mar 2019 at 09:42:58 +, Simon McVittie wrote:
> > According to upstream, 3.32.0 is not suitable and we should be using
> > 3.32.1.2. That version has various post-release fixes, and also restores
> > the bundled copy of libdazzle 3.32.x instead of using the system libdazzle
> > 3.30.x: upstream say 3.32.x has important fixes for epiphany-browser.
> > 
> > I've prepared a draft package at
> > 
> 
> Now that webkit2gtk 2.24.x is in buster, I've reverted the parts of that
> draft package that were only there to relax the dependency on webkit2gtk
> to 2.22.x, and uploaded it to experimental.
> 
> Here's a debdiff excluding the translations and the now-bundled copy
> of libdazzle:
> https://people.debian.org/~smcv/epiphany-browser_3.32.1.2-1_without-libdazzle.diff
> 
> and a separate debdiff between buster's libdazzle and the bundled copy,
> in the hope that this is less horrible to review than the whole of the
> bundled copy:
> https://people.debian.org/~smcv/epiphany-browser_3.32.1.2-1_libdazzle.diff
> 
> An upload to unstable would presumably differ only by a
> changelog entry.
> 
> > someone who knows the package better should probably take over at
> > this point, so I'm marking the unblock request as moreinfo
> 
> This still stands. I don't use epiphany-browser myself, so if the GNOME
> team is intending to release it in buster, I would strongly prefer for
> someone else to do the upload to unstable.
> 
> If nobody is willing to do that, then we should remove epiphany-browser
> from buster, and possibly reopen #916347 "epiphany-browser: Don't include
> in Buster".

Please upload to unstable. As the current version in unstable doesn't even
build, it will be better that what is there now. And if we end up removing it,
a new version in unstable won't hurt.

Note that I'm not tagging this request 'confirmed', becuase I haven't looked
at the details to see if an unblock would be appropriate. That can happen
later.

Thanks,

Ivo

Bug#927189: unblock: docker.io/18.09.1+dfsg1-5+b10

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Tue, Apr 16, 2019 at 05:42:00AM +, Niels Thykier wrote:
> > I'd like to fix #925224 [1] for buster. The fix is trivial, and allows
> > the docker's debootstrap script to work again when it queries
> > security.debian.org, by following redirections. Please see bug for
> > more details.
> > 
> > I attached a source debdiff as mentioned in buster freeze policy [2].
> > 
> > Sorry for the inconvenience,

Your upload incorporated a newer version of golang-golang-x-sys in ustable,
which has changes that are not appropriate during the freeze. If you want
docker.io to migrate, the changes in golang-golang-x-sys need to be reverted.

Thanks,

Ivo

Bug#927784: unblock: cups/2.2.10-6

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Tue, Apr 23, 2019 at 09:20:51AM +0200, Didier 'OdyX' Raboud wrote:
> I hereby request an upload authorization towards an unblock for package cups
> 2.2.10-6; which was not uploaded yet.
> 
>   cups (2.2.10-6) unstable; urgency=medium
> 
> * Backport patch from upstream's 2.2 "stable" branch:
>   - Fix an issue with `PreserveJobHistory` and time values (Issue #5538)
> (Closes: #921741)
> 
> The `PreserveJobHistory` configuration doesn't work correctly in 2.2.10, and
> this was fixed by upstream in 2.2.11; this upload has only a cherry-pick of
> upstream's ba9d68cc7467a7a47ef219071902b9e9eb6dbc44 and would fix src:cups bug
> #921741.
> 
> Both the concrete upstream diff and the full debdiff are attached.
> 
> Thanks for your consideration, cheers,
> OdyX
> 
> unblock cups/2.2.10-6

Please go ahead with the upload to unstable and remove the moreinfo tag from
this bug once the package is built.

Thanks,

Ivo

Bug#927199: unblock: gnome-shell/3.30.2-6

[Ivo De Decker]

Hi,

On Tue, Apr 16, 2019 at 08:08:00AM +, Niels Thykier wrote:
> > unblock gnome-shell/3.30.2-6
> > 
> 
> There is a bug in d/clean.  The "debian/home" line is a directory and
> therefore needs a trailing slash (otherwise, dh_clean will refuse to
> remove it - see "man dh_clean").
> 
> Otherwise, it looks fine.

Also, are you aware of these bugs:

https://bugs.debian.org/926212 gnome-shell crashed (segfault)
https://bugs.debian.org/927162 gnome-shell segfaults in libst-1.0.so

It would probably be good to have a fix for that.

Thanks,

Ivo

Bug#926651: unblock: nodejs/10.15.2~dfsg-2

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Mon, Apr 08, 2019 at 03:12:44PM +0200, Jérémy Lal wrote:
> Please unblock package nodejs
> 
> Two trivial changes:
> 
> - two tests are marked as flaky
> (one fails with eatmydata, one fails for no known reason
> though i suspect it is related to running tests in parallel).
> 
> - debian/gbp.conf set to debian/buster branch
> 
> unblock nodejs/10.15.2~dfsg-2

This version doesn't seem to be in unstable. If this was meant as a
pre-approval request, please go ahead and remove the moreinfo tag from this
bug once the upload is in unstable and the builds are done.

Thanks,

Ivo

Bug#926907: unblock: python-django-casclient/1.2.0-2.2

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Thu, Apr 11, 2019 at 09:37:03PM -0400, William Blough wrote:
> Please unblock package python-django-casclient
> 
> As explained in bug #926350 [1], python-django-casclient is broken when used
> with Django versions >= 1.10, due to Django middleware API changes. Since
> Buster will ship with Django 1.11, python-django-casclient is useless in its
> current state.
> 
> The patch to fix the issue was obtained from upstream [2].  The source
> debdiff between the version in testing/unstable and the fixed version I
> would like to upload (via unstable) is attached.

Please go ahead with the upload to unstable based on this patch and remove the
moreinfo tag from this bug once the builds are done.

Thanks,

Ivo

Bug#926817: unblock: publicsuffix/20190329.0756-1

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Wed, Apr 10, 2019 at 03:31:07PM -0400, Daniel Kahn Gillmor wrote:
> Please unblock package publicsuffix
> 
> The publicsuffix package contains up-to-date descriptions of the network
> environment.  In addition to capturing the most recent state of the
> DNS's public cutpoints, this update marks the correct level of debian
> policy compliance (4.3.0) and moves to debhelper compat level 12 (no
> changes to the generated tarball resulted from this shift in dh compat
> level).

We don't accept debhelper compat changes during the freeze. Please do an
upload reverting that change and update this request after that.

The other changes look ok.

Thanks,

Ivo

Bug#926994: unblock: gcc-mingw-w64/21.2 (pre-upload approval request)

[Ivo De Decker]

Control: tags -1 confirmed moreinfo


Hi Stephen,

On Sat, Apr 13, 2019 at 04:18:44PM +0200, Stephen Kitt wrote:
> On Sat, 13 Apr 2019 13:22:01 +0200, Ivo De Decker  wrote:
> > On Sat, Apr 13, 2019 at 10:26:04AM +0200, Stephen Kitt wrote:
> > > I have a couple of fixes pending upload for gcc-mingw-w64, and I’m
> > > wondering if they’d pass muster for Buster. The attached patches fix,
> > > in order:
> > > 
> > > * #923214 — an ICE hit with external static data members
> > > * #925172 — std::filesystem support is broken in the current Buster
> > >   package
> > > 
> > > I’m requesting approval for these fixes before uploading them to
> > > unstable. The candidate source package would contain only those fixes
> > > plus the result of running "dch -r". Note that because of the way
> > > gcc-mingw-w64 works, this would involve pulling gcc-8 8.3.0-6 (or
> > > whatever version is in unstable when the package is built) in too.  
> > 
> > I haven't looked at the details of these patches yet, but I notice that this
> > doesn't address #923698 (which you set to serious). What's your plan with
> > that one?
> 
> I’m still working on it, it’s taking longer than I hoped to figure out what’s
> broken. I thought it would be worth getting the fixes I do have into the
> archive sooner rather than later, especially since #923214 prevents
> meaningful testing in a number of cases!

OK. That sounds reasonable.

I had a look at the patches, and they seem like something that would be
acceptable for buster. Please go ahead with the upload to unstable and remove
the moreinfo tag from this bug once the builds are done.

Thanks,

Ivo

Bug#926994: unblock: gcc-mingw-w64/21.2 (pre-upload approval request)

[Ivo De Decker]

Hi,

On Sat, Apr 13, 2019 at 10:26:04AM +0200, Stephen Kitt wrote:
> I have a couple of fixes pending upload for gcc-mingw-w64, and I’m
> wondering if they’d pass muster for Buster. The attached patches fix,
> in order:
> 
> * #923214 — an ICE hit with external static data members
> * #925172 — std::filesystem support is broken in the current Buster
>   package
> 
> I’m requesting approval for these fixes before uploading them to
> unstable. The candidate source package would contain only those fixes
> plus the result of running "dch -r". Note that because of the way
> gcc-mingw-w64 works, this would involve pulling gcc-8 8.3.0-6 (or
> whatever version is in unstable when the package is built) in too.

I haven't looked at the details of these patches yet, but I notice that this
doesn't address #923698 (which you set to serious). What's your plan with that
one?

Thanks,

Ivo

Bug#926747: unblock: adacontrol/1.20r7-2

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Wed, Apr 10, 2019 at 08:17:36AM +0200, Matthias Klose wrote:
> On 10.04.19 02:55, Nicolas Boulenguez wrote:
> >  override_dh_auto_test-arch:
> >ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS) $(DEB_BUILD_PROFILES)))
> > -   cd test && sh run.sh
> > +# Disable build-time tests so that the severity of #924835 can be
> > +# lowered and the package accepted into buster.  An actual fix
> > +# requires a bit more time and probably a longer diff.
> > +#  cd test && sh run.sh
> 
> if the tests don't break the buildd, it would be better to run those and 
> ignore
> the test results.

Based on this suggestion, I'm tagging this unblock request moreinfo for now.
Please either do a new upload with this change, or if you believe this version
should be unblocked anyway, please explain this and remove the moreinfo tag.

Thanks,

Ivo

Bug#926708: unblock: otrs2/6.0.17-1

[Ivo De Decker]

Hi,

On 4/9/19 2:59 PM, Patrick Matthäi wrote:

Am 09.04.2019 um 14:46 schrieb Ivo De Decker:



Being in non-free doesn't give you an exception to the freeze.

Sorry you are right, I totaly forget it..
It was an exception for fglrx in the past-past, but because it was also
closed source, so no fixes could be adapted.

I will prepare a diff along with other security fixes (I think there
will be one in the next time) if they are out


OK. Do you have an idea about the timeframe of this future release?

Thanks,

Ivo

Re: Freeze-exception for pcsc-cyberjack 3.99.5final.sp09-2

[Ivo De Decker]

Hi,

On 4/9/19 12:14 AM, Reinhard Tartler wrote:

Hi Release Team,

Frank and I would like to see RC bug #926103 fixed in Debian 10. Please approve 
the attached debdiff, so that I can upload the fixed package to unstable.


We really prefer unblock request bugs instead of mails to the list, to 
make sure the request is tracked and doesn't get lost.


That said, please go ahead and do the upload of 3.99.5final.sp09-2 to 
unstable based on the diff you sent.



Thank you for your consideration.


Thanks,

Ivo

Bug#925525: unblock: glusterfs/5.5-1

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Mon, Apr 08, 2019 at 11:50:50AM +0200, Patrick Matthäi wrote:
> Am 06.04.2019 um 13:42 schrieb Ivo De Decker:
> > Control: tags -1 moreinfo
> >
> > Hi,
> >
> > On Tue, Mar 26, 2019 at 11:33:20AM +0100, Patrick Matthäi wrote:
> >> I would like to upload glusterfs 5.5-1 (currently in experimental) to sid 
> >> and
> >> target this release for buster. It is a bugfix only release, also for a
> >> regression, and has got small changes:
> > You didn't explain what changes are important enough to ask for an unblock.
> > Please elaborate.
> >
> > The diff is small, so it might be suitable.
> >
> > Cheers,
> >
> > Ivo
> 
> Hi,
> 
> there are several fixes:
> https://docs.gluster.org/en/latest/release-notes/5.5/
> 
> They also state, that 5.4 was never offical announced, because of the
> regressions in it, which prevents rolling upgrades:
> https://bugzilla.redhat.com/show_bug.cgi?id=1679968
> https://bugzilla.redhat.com/show_bug.cgi?id=1684569
> https://bugzilla.redhat.com/show_bug.cgi?id=1684385

OK, having some of the info included in those links in the changelog or in the
unblock request would have made things a bit easier. That said, it looks like
5.5-1 is acceptable for buster. So please go ahead and do an upload to
unstable, and remove the moreinfo tag from this bug once the package is in
unstable and built on all relevant architectures.

Thanks,

Ivo

Bug#925314: unblock: wordpress/5.0.3+dfsg1-1

[Ivo De Decker]

Control: tags -1 confirmed

Hi,

On Sun, Mar 24, 2019 at 09:31:11AM +1100, Craig Small wrote:
> Hi,
>   Attached is a debdiff between 5.0.3 to 5.04 which is essentially the
> changesets I previously reference from the upstream SVN repository.
> 
> Option 1 is my preference, the main difference between #1 and #2 was the
> changelog version.

Please go ahead with the upload of 5.0.4+dfsg1-1 ("option 1"), but set the
distribution to "buster" instead of "testing-proposed-updates".

Remove the moreinfo tag from this bug once the upload is in t-p-u.

Thanks,

Ivo

P.S. In the future, please try to avoid uploading new upstream versions to
unstable that might not be suitable for testing.

Bug#925265: unblock: ntp/1:4.2.8p12+dfsg-4 or ntp/1:4.2.8p13+dfsg-2 (pre-approval)

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Fri, Mar 22, 2019 at 12:11:29AM +0100, Bernhard Schmidt wrote:
> The other option would be to only backport the fix for CVE-2019-8936 and 
> upload
> -4.
> 
> While processing this I discovered three small commits sitting in the master
> branch that had not been uploaded yet. They could be backed out if you want 
> to.
> They fix important Bug#772790, normal Bug#764546 and remove a leftover from 
> the
> locking that used to be in place to prevent a race between ntpd and the 
> ntpdate
> ifupdown hooks. The ifupdown hooks have been removed since September, so the
> locking is not necessary anymore.
> 
> Please tell me what you want me to upload
> 
> a) 1:4.2.8p13+dfsg-1 currently in experimental (as -2)
> b) 1:4.2.8p13+dfsg-1 currently in experimental (as -2), but with some/all not
>previously uploaded changes to debian/ dropped
> c) 1:4.2.8p12+dfsg-4 containing only the CVE fix
> d) 1:4.2.8p12+dfsg-4 containing the CVE fix and some/all not previously 
> uploaded
>changes to debian/

Both option c or d sound ok. Options a and b really don't sound like something
we should do at this point.

So please go ahead with the 1:4.2.8p12+dfsg-4 upload and remove the moreinfo
tag from this bug once the package is in unstable.

Thanks,

Ivo

Bug#925525: unblock: glusterfs/5.5-1

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Tue, Mar 26, 2019 at 11:33:20AM +0100, Patrick Matthäi wrote:
> I would like to upload glusterfs 5.5-1 (currently in experimental) to sid and
> target this release for buster. It is a bugfix only release, also for a
> regression, and has got small changes:

You didn't explain what changes are important enough to ask for an unblock.
Please elaborate.

The diff is small, so it might be suitable.

Cheers,

Ivo

Bug#926337: unblock: notary/0.6.1~ds1-3

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Thu, Apr 04, 2019 at 01:00:00AM +0800, Shengjing Zhu wrote:
> Please unblock package notary
> 
> * Regenerate some test certs since they are expired (Closes: #924119)
> 
> unblock notary/0.6.1~ds1-3

The build failed on mips. This will block migration, even if the package is
unblocked.

https://buildd.debian.org/status/package.php?p=notary

Ivo

Bug#926302: unblock: ciftilib/1.5.3-2

[Ivo De Decker]

Control: tags -1 moreinfo

Hi Andreas,

On Wed, Apr 03, 2019 at 08:40:59AM +0200, Andreas Tille wrote:
> Please unblock package ciftilib

You included the diff between 1.5.3-1 and 1.5.3-2. However, testing currently
has 1.5.1-3. The diff beween 1.5.1-3 and 1.5.3-2 is much bigger, and doesn't
look like something that is acceptable during the freeze.

Version 1.5.3-1 didn't migrate due to the missing builds (which are fixed by
the patch in -2).

Ivo

Bug#925604: unblock: ruby-doorkeeper-openid-connect/1.5.5-1

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Wed, Mar 27, 2019 at 07:11:57PM +0530, Utkarsh Gupta wrote:
> Please unblock package ruby-doorkeeper-openid-connect.
> 
> There was a CVE bug (#924747) reported against the package with severity:
> grave.
> It was reported on 16th March and was resolved in the latest upload, which was
> on 24th March.
> Thus, requesting you to please unblock the same and let it be a part of 
> Buster,
> as was going to :)

This upload seems to include a number of changes other than the fix for the
security issue. This doesn't seem to comply with the freeze policy. Perhaps
you can clarify the changes. Otherwise, please revert the upload and upload a
targeted fix for this issue.

Thanks,

Ivo

Bug#919395: Heads up to release team about MariadB 10.3

[Ivo De Decker]

Hi,

On 3/23/19 2:26 AM, Andreas Beckmann wrote:

On 2019-03-20 12:28, Emilio Pozuelo Monfort wrote:

On 20/03/2019 00:49, Andreas Beckmann wrote:

please give-back qt4-x11. A build has succeeded today in my pbuilder sid



Scheduled.


That worked. What needs to be done to make the three late binNMUs
migrate to testing? Does not seem to happen on its own ...


BinNMUs and new binaries also need an unblock during the freeze (this 
was a fairy recent change in britney), so they didn't migrate on their 
own. I unblocked them and they migrated.


Ivo

Bug#925249: unblock: ldb/2:1.5.1+really1.4.6-3 and samba/2:4.9.5+dfsg-2

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Thu, Mar 21, 2019 at 07:03:08PM +0100, Mathieu Parent wrote:
> I'm waiting your ack to upload those to unstable:
> 
> unblock ldb/2:1.5.1+really1.4.6-3
> unblock samba/2:4.9.5+dfsg-2

Please go ahead with the upload to unstable and remove the moreinfo tag from
this bug once the builds in unstable are done.

Thanks,

Ivo

Bug#924683: binnmus for multiarch coinstallability

[Ivo De Decker]

Hi Helmut,

On Fri, Mar 15, 2019 at 09:04:34PM +0100, Helmut Grohne wrote:
> We don't epxect much churn in unstable anymore, so it is a good time to
> cover up for past mistakes in binNMUing Multi-Arch: same packages and
> make them coinstallable again. I know that you dislike excessive binNMUs
> just to get the versions right, but the last time I asked was before the
> release of stretch. It turns out than there are only 7 skewed packages
> left. Would you be so kind and binNMU them to make their versions match?
> 
> # 61 affected
> nmu libxt . amd64 arm64 armel armhf i386 mips64el ppc64el s390x . unstable . 
> -m "multiarch sync"
> # 32 affected
> nmu libxdamage . amd64 arm64 armel armhf i386 mips mipsel ppc64el s390x . 
> unstable . -m "multiarch sync"
> # 19 affected
> nmu rustc . amd64 arm64 armel armhf i386 mips64el ppc64el s390x . unstable . 
> -m "multiarch sync"
> # 8 affected
> nmu libxkbfile . amd64 arm64 armel armhf i386 mips64el ppc64el s390x . 
> unstable . -m "multiarch sync"
> # 5 affected
> nmu libxmu . amd64 arm64 armel armhf i386 mips64el ppc64el s390x . unstable . 
> -m "multiarch sync"
> # 3 affected
> nmu libidl . amd64 arm64 armel armhf i386 mips64el ppc64el s390x . unstable . 
> -m "multiarch sync"
> # 1 affected
> nmu libglu . amd64 arm64 armel armhf i386 mips64el ppc64el s390x . unstable . 
> -m "multiarch sync"

Just out of curiosity:

What query did you use to generate this list?

Thanks,

Ivo

Bug#924670: unblock: augustus/3.3.2+dfsg-2

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Fri, Mar 15, 2019 at 05:22:45PM +0100, Sascha Steinbiss wrote:
> please unblock package augustus.

First of all, the package isn't in unstable, so it can't be unblocked. I guess
it was rejected due to the issue below.

> The only change I have made in the current version in unstable is making
> sure that no hardcoded value for Built-Using is used any more,
> calculating it from the version used at build time instead. I have also
> corrected the name of the respective package referenced by this Built-Using.
> 
> Please find attached a debdiff with my changes.

The built-using field has to refer to the source package, not the binary
package, so the reference to libbam-dev in the Built-Using header is wrong.
A package with a non-existant reference in built-using will be rejected by the
archive.

Please remove the moreinfo tag from this bug once a new version is in unstable.

Thanks,

Ivo

Bug#924434: unblock pre-approval: movim/0.14.1-4

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Tue, Mar 12, 2019 at 11:14:16PM +0100, Dominik George wrote:
> Please unblock package movim
> 
> Upstream fixed a few semi-critical bugs, which we here would call important.
> I added the bugs to the BTS and backported the fixes form the new upstream
> release, they are listed in the attached
> debdiff/changelog.
> 
> If you are up to gifts today, you may as well pre-approve the upload of 
> 0.14.2,
> the new upstream release. It does not include much more, only some more
> minor bugfixes and some UI improvements in CSS ;).

Please go ahead with the upload to unstable and remove the moreinfo tag from
this bug once the package is in unstable and is built on all relevant
architectures, passed piuparts, autopkgtests (if present), etc.

Thanks

Ivo

Bug#924305: unblock: python-saharaclient/2.0.0-2.1

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Mon, Mar 11, 2019 at 12:18:42PM +0100, Andreas Beckmann wrote:
> Please unblock package python-saharaclient
> 
> This upload fixes removal of obsolete alternatives that would otherwise
> stay around after upgrades from stretch.
> The NMU was just uploaded to DELAYED/5

Please don't file unblock request for packages not (yet) in unstable. We can't
do anything about them, and it's just extra work to check.

Thanks,

Ivo

P.S. I've tagged this bug moreinfo for now instead of closing it, please
remove the tag once the package is in unstable.

Bug#922010: Some Debian Med packages need hinting into testing

[Ivo De Decker]

Control: reopen -1

Hi,

On Mon, Feb 11, 2019 at 10:29:19PM +0200, Adrian Bunk wrote:
> > On Mon, Feb 11, 2019 at 10:19:08AM +0200, Adrian Bunk wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > 
> > > The following source packages build binary-all packages that
> > > are not installable on i386 (only on amd64/arm64/mips64el/ppc64el):
> > > - pbseqlib
> > > - pbgenomicconsensus
> > 
> > Added force-hint for those.
> 
> thanks.
> 
> > > - pbsuite
> > > - pbalign
> > 
> > These cause uninstallability on amd64, so there must be a different issue
> > there.
> 
> They are also waiting for blasr, which requires the pbseqlib
> force-hint above.

Reopening the bug, as these still need to be done.

Ivo

Bug#916642: golang CVE-2019-6486 (DoS in crypto/elliptic)

[Ivo De Decker]

Hi,

On 1/24/19 3:00 PM, Dr. Tobias Quathamer wrote:

Am 24.01.2019 um 09:12 schrieb Emilio Pozuelo Monfort:

On 24/01/2019 08:58, Michael Stapelberg wrote:

Last time, pochu@ (cc'ed) helpfully scheduled binNMUs. pochu, would you be
able to help this time, too?


Sure. Can you give me a list of source packages to binNMU in unstable? If this
is public already, can you do that through a binNMU bug against 
release.debian.org?

Emilio


Hi all,

there is already an outdated binNMU list as bug report available, so
I'm reusing that report. Please ignore the previously attached
binNMU list of that bug report.

This should be a complete and current list of needed binNMUs:


[long list of packages]

I've started scheduling these (it will take some time before the script 
is finished).


Some notes about these binNMUs:

* Some of the packages on the list are binary package names, not 
sources. I didn't schedule those (they were filtered out by the script I 
used to schedule the binNMU). I don't have a lot of time right now to 
check the list of packages, but I already scheduled the source packages 
on the list, because it will take some time to build those.


* I lowered the priority of all these builds, to avoid blocking the 
buildds for some time on slower archs.



Some notes about go and the needs for binNMUs in general:

* Please note that there currently is no reasonable way to do something 
like this for a security issue in stable. This was discusses in this 
thread: https://lists.debian.org/debian-release/2018/07/msg2.html


* We (the release team) generally try to rebuild packages with outdated 
built-using before the release. I'll try to look into doing that in the 
near future.


Cheers,

Ivo

Re: using sid-strict etc for britney

[Ivo De Decker]

Hi,

On 1/19/19 5:41 PM, Niels Thykier wrote:

Holger Levsen:

Hi,

Andreas sent this to the piuparts-devel list while I think it's more
appropriate to discuss this on debian-release@



Hi Holger,

Thanks for forwarding this idea. :)


On Thu, Jan 10, 2019 at 02:38:38PM +0100, Andreas Beckmann wrote:

currently britney uses piuparts regressions comparing testing vs. sid to
block migrations. That's fine, since we should have few false positives
in sid nowadays.
It would be nice if we could use a similar scheme like autopkgtests uses
to delay migration for other tests, like sid-strict or testing2sid.
As in "if your package leaves files after purge, you don't get the
migration reduction from 5 to 2 days"
and for testing2sid (or stable2sid) there may be more false positives
caused by other packages, so it would be great to at least delay
migration by a few days as well, to allow manual inspection of the
failure, I several times didn't manage to file a bug within 2 days of
upload to prevent migration of a buggy package to testing ...


sounds like a splendid idea to me!

How can we get this going?




At its essence, it is a question of updating the PiupartsPolicy in
Britney[1] along with adding relevant test cases (either in "tests/" or
in britney2-tests[2]).

Once that is done, we can merge the code and update the britney wrapper
to fetch the relevant summary.json files from piuparts.d.o.

Hints as to the actual steps:

  * PiupartsPolicy.initialise should load the relevant summary files.
(Difficulty level: copy-paste + rename things)

  * PiupartsPolicy.apply_src_policy_impl should analyse the new files
and determine which delay to apply if any.  If a age delay is to be
applied then the method should now call:
  excuse.add_penalty('piuparts', )

  * TestPiupartsPolicy should be updated to include a case for it.  It
might make sense to have PiupartsPolicy include a note in the
policy_info so the test case can rely on that (rather than having
to setup an AgePolicy as well for verification).

We have a ".gitlab-ci" on the git repo that runs all the basic test
cases for you on push to salsa.  Alternatively, have a look at the
ci/gitlab-ci-runner for how to run the tests manually.


On a related note:

- It would be nice to have detailed information about the binaries 
tested in the export, this would allow britney to use this information 
for binNMUs. Piuparts already tests binNMUs, but the info in the export 
only lists the source, not the binary (or the binary version), so that 
info isn't available yet. This would probably mean an incompatible 
change to the export (which can exist side by side with the current 
one). Do you have an idea about what services are processing this file? 
I know at least britney, tracker, udd and the old PTS have info from 
piuparts.


If the export is changed anyway, it could contain more detailed 
information about what tests failed and the severity of the failures. 
This might allow an easier implementation of the diversified result 
(block, delay, ...)


- Currently, it looks like buster-proposed-updates isn't tested by 
piuparts (which isn't a big deal, as there are no packages in there 
yet). Could this be added as a suite (together with buster2proposed)?


Thanks!

Ivo

Bug#916209: britney: handling of binNMUs in tpu broken

[Ivo De Decker]

Package: release.debian.org
Severity: serious
User: release.debian@packages.debian.org
Usertags: britney


When {testing,stable}-proposed-updates has a binary-only item (binNMU or
missing build that arrived later), britney will use the binaries from unstable
instead, possibly migrating them even if they are from a different source and
should not be a candidate. During the freeze, a binNMU in tpu would cause the
binaries from a newer (blocked) source in unstable to show up in testing. As
this causes britney to potentially migrate random unwanted binaries, I filed
this bug as serious.

This is caused by wrong parsing of MigrationItem and can be fixed by the
attached patch.

Please note that the root cause of this issue is that the excuses calculation
uses detailed information about the binaries and sources involved, but this
information isn't passed on. Only the 'name' of the migration item is passed
on, and later on, britney tries to calculate the set of binaries and sources
again based on the info gathered from parsing this name.

With the attached patch, however, other issues with binNMUs in tpu show up:

When both a new source from unstable and a binNMU from tpu are candidates,
britney might migrate the new source first and then accept the binNMU. This
causes the architecture of the binNMU to have the older binaries from the
binNMU, while other architectures have the newer once. If there are no rdeps,
the older binaries are removed because they are considered old binaries from
smooth updates (because they are built by a different source version).

Allow the binNMU to migrate is clearly wrong, because after the migration of
the new source, the binNMU of the old source should no longer be considered.

Some of this is tested by the following tests in the testsuite:

binnmu-tpu
binnmu-tpu-rdeps
bug-unfiled-2

Additional tests could be useful for combinations with arch: all packages (on
some/all architectures) and binary takeovers (arch: all/any, on some/all
architectures, ...).


As a 'temporary' workaround, it might be good to disable binary-only items
from *pu completely for now, to avoid this issue.

More targeted workarounds could include:

- Only allow binNMUs from *pu with an explicit hint (which would have to be
  used with care).
- Disable binary-only items that contain binaries that are also built by
  source items that are a candidate. This would mean that a new source from
  unstable must be blocked explicitly if you want to allow a binNMU from *pu
  to migrate.
- Always try binary-only items before source items. I don't really know how
  this could be enforced when multiple easy hints are tried or during a hint
  run.

More ideas welcome...

Ivo

>From 67628b80ad208f0eca2262e79eb0d5fd5372b8c8 Mon Sep 17 00:00:00 2001
From: Ivo De Decker 
Date: Tue, 11 Dec 2018 12:37:45 +
Subject: [PATCH] Fix parsing of migration item name for binNMU in tpu

The parsing of migration items should also look for the suite name in the
architecture part. This fixes the parsing for migration items like
some-src/amd64_tpu and some-src/amd64_tpu/1.0-1

Signed-off-by: Ivo De Decker 
---
 britney2/migrationitem.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/britney2/migrationitem.py b/britney2/migrationitem.py
index 1122852..f6b1090 100644
--- a/britney2/migrationitem.py
+++ b/britney2/migrationitem.py
@@ -97,6 +97,9 @@ class MigrationItem(object):
 else:
 self._architecture = 'source'
 
+if '_' in self._architecture:
+self._architecture, suite_name = self._architecture.split('_', 2)
+
 if self._version in self.__class__.get_architectures():
 (self._architecture, self._version) = \
 (self._version, self._architecture)
-- 
2.11.0

Bug#864049: unblock: mate-desktop/1.16.2-2

[Ivo De Decker]

Hi,

On Sat, Jun 03, 2017 at 08:17:00PM +, Niels Thykier wrote:
> >> Please consider unblocking a minor follow-up fix for package mate-desktop
> >>
> >> The DH call until mate-desktop 1.16.2-1 has been missing the "--with gir"
> >> option. The proposed next upload of mate-desktop will fix that. A
> >> .debdiff has been attached.
> >>
> >> unblock mate-desktop/1.16.2-2
> >>
> >> [...]
> > 
> > Please go ahead.
> > 
> > ~Niels
> > 
> 
> Unblocked, thanks.
> 
> ~Niels
> 

This bug was closed by mistake (and reopened). To be clear: this bug is still
waiting for the upload to unstable.

Cheers,

Ivo

Bug#864048: unblock: marco/1.16.1-1

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Sat, Jun 03, 2017 at 06:23:53PM +0200, Mike Gabriel wrote:
> Please consider unblocking package marco ready for upload.
> 
> From upstream we received a last-minute fix for #828077 (mate-panel:
> Mouse focus problem with stack of applications). The underlying cause has
> been fixed in the MATE window manager aka marco.
> 
> 
> unblock marco/1.16.1-1

We're quite close to the release date, so I suggest you upload it now, and
remove the moreinfo tag from this bug once it's in unstable. I'll take a
closer look at that point.

Cheers,

Ivo

Bug#863838: unblock: debian-edu-install/1.926

[Ivo De Decker]

Control: tags -1 confirmed moreinfo d-i

Hi,

On Thu, Jun 01, 2017 at 10:48:21AM +, Holger Levsen wrote:
> On Thu, Jun 01, 2017 at 04:09:35AM +0200, Cyril Brulebois wrote:
> > I'm not sure why we're still having this hardcoded list of versions.
> 
> because: cruft in the way Debian Edu CDs are build/used…

Unblocked.

It still needs the d-i ack for the unblock-udeb.

Cheers,

Ivo

Bug#863796: unblock: e2guardian/3.4.0.3-2

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Wed, May 31, 2017 at 11:58:16AM +0200, Mike Gabriel wrote:
> Please consider unblocking not-yet-uploaded package e2guardian
> 
> Quite recently Google Chrome changed its policy regarding certificate
> requirements. Certs without a subjectAltName field get now rejected.
> 
> In the e2guardian content filter system, there is support for filtering
> SSL encrypted http traffic by decrypting, checking its content and then
> re-encrypting SSL-encrypted content. Whereas some consider this as a
> m-i-t-m attack, in some setups this makes good sense (e.g. in school
> networks).
> 
> For re-encrypting the content, a self-signed set of certs gets used.
> In previous versions, these certs lack the SAN field. With a patch
> from upstream (that they backported to the 3.4 branch of e2guardian esp.
> for Debian 9), this issue has now been fixed.
> 
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862855 for details.
> 
> unblock e2guardian/3.4.0.3-2

We're quite close to the release date, so I suggest you upload it now, and
remove the moreinfo tag from this bug once it's in unstable. I'll take a
closer look at that point.

Cheers,

Ivo

Bug#863569: (pre-approval) unblock: openldap/2.4.44+dfsg-5

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Sun, May 28, 2017 at 11:24:00AM -0700, Ryan Tandy wrote:
> I would like to upload a late-breaking security fix to openldap:
> 
>   * debian/patches/ITS-8655-paged-results-double-free.patch: Fix a double free
> in the MDB backend on a search including the Paged Results control with a
> page size of 0. (ITS#8655) (Closes: #863563)
> 
> A Debian user reported this crash bug in slapd. The default Debian 
> configuration uses the MDB backend and allows unauthenticated users to 
> search the directory; therefore for us this qualifies as a remote DoS.
> 
> With your permission, I'd like to include one additional fix:
> 
>   * ITS-8644-wait-for-slapd-to-start-in-test064.patch: Fix an intermittently
> failing test by waiting for slapd to start before running tests.
> (ITS#8644) (Closes: #770890)
> 
> This issue caused some havoc in the last upload; you may remember that 
> we ended up re-bootstrapping on ppc64el and binNMUing everywhere. The 
> root cause was actually the tight dependency between libldap-2.4-2 and 
> libldap-common, but I think revisiting that should wait for buster. For 
> now, including this patch will improve the reliability of maintenance 
> uploads during stretch's lifetime.
> 
> Both patches have already been reviewed upstream and will be included in 
> the upcoming 2.4.45 release.
> 
> Thanks again for all your work on making stretch great,

Please go ahead with the upload and remove the moreinfo tag from this bug once
the builds on all (relevant) architectures are in unstable.

Cheers,

Ivo

Bug#861580: (pre-approval) unblock: mysql-connector-python/2.1.6

[Ivo De Decker]

Hi,

On Sat, May 20, 2017 at 08:34:00AM +, Niels Thykier wrote:
> Sandro Tosi:
> >> NOTE: the test suite contains certificates that expire in 2018.  If that
> >> causes test failures, then that is an RC bug (as it would mean we would
> >> be unable to compile mysql-connector-python in stretch before its EOL).
> >> AFAICT, said problem would also exists in the current version (except
> >> the expiry reads 2017 instead).
> >>   Please consider replacing the certificates with once that can survive
> >> stretch + stretch-lts's life-time.
> > 
> > that's kinda tricky: what is the lifetime for stretch + stretch-lts?
> > :) should i guess (inferring from previous releases), do you want to
> > give me a date until making those certs valid, something else?
> > 
> 
> (For future cases) I would say 10 years would suffice once the freeze
> has started.  That said, I hope that there will be fewer cases of this
> problem in general. :)
> 
> > As of now tests failure wont make the build fail, so --if that's ok
> > with the RT-- i may continue with keeping those certs as upstream
> > released them.
> 
> Ack, fine with me.  Please go ahead with the certs as is.

Any news on the upload? The release is very close now. More info on the timing
and the deadlines in
https://lists.debian.org/debian-devel-announce/2017/05/msg2.html

Maybe someone can upload this patch as an NMU?

Cheers,

Ivo

Bug#863131: unblock: tomcat-native/1.2.12-2

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Mon, May 22, 2017 at 02:40:01PM +0200, Emmanuel Bourg wrote:
> I'd like to request an unblock for a new version of tomcat-native. Testing
> currently has the 1.2.10 version. The versions 1.2.11 and 1.2.12 are bug
> fix releases improving the stability.

Please go ahead with the upload to unstable. We can consider the unblock once
the package is in unstable. Please remove the moreinfo tag from this bug at
that point.

Please note that we are very close to the release. More info about the
deadlines in
https://lists.debian.org/debian-devel-announce/2017/05/msg2.html

Cheers,

Ivo

Bug#863380: unblock: wireshark/2.2.6+g32dac6a-2

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Fri, May 26, 2017 at 12:25:07AM +0200, Bálint Réczey wrote:
> I have prepared wireshark 2.2.6+g32dac6a-1 in experimental which fixes
> 10 vulnerabilities and other bugs which are not listed here, just on
> the release notes link.
> 
> Changes:
>  wireshark (2.2.6+g32dac6a-1) experimental; urgency=medium
>  .
>* New upstream release
>  - release notes:
>https://www.wireshark.org/docs/relnotes/wireshark-2.2.6.html
>  - security fixes:
>- The IMAP dissector could crash (CVE-2017-7703)
>- The WBXML dissector could enter an infinite loop (CVE-2017-7702)
>- The NetScaler file parser could enter an infinite loop
>  (CVE-2017-7700)
>- The RPCoRDMA dissector enter an infinite loop (CVE-2017-7705)
>- The BGP dissector could enter an infinite loop (CVE-2017-7701)
>- The DOF dissector could enter an infinite loop (CVE-2017-7704)
>- The PacketBB dissector could crash (CVE-2017-7747)
>- The SLSK dissector could enter a long loop (CVE-2017-7746)
>- The SIGCOMP dissector could enter an infinite loop
>  (CVE-2017-7745)
>- The WSP dissector could enter an infinite loop (CVE-2017-7748)
> 
> 
> I believe wireshark point releases very rarely cause regressions due
> to the heavy testing performed upstream and I think it would be safe
> to upload this point release to unstable and let it migrate to
> testing.
> 
> If you wouldn't like to accept the full point release to Stretch I
> will happily backport the security fixes to 2.2.5 and upload that to
> unstable.
> 
> Please share your preference regarding the next upload.

Please go ahead with the upload to unstable and remove the moreinfo tag from
this bug once the builds are done on all the relevant architectures.

Also, please note that we are very close to the release date. More info about
the deadlines in
https://lists.debian.org/debian-devel-announce/2017/05/msg2.html

Cheers,

Ivo

Bug#861900: your mail

[Ivo De Decker]

Hi,

Sorry for the delay in dealing with this request.

On Mon, May 15, 2017 at 07:46:50AM +, PICCA Frederic-Emmanuel wrote:
> I attached the debdiff of the sardana 2.2.2-3 version prepared by the upsteam.
> 
> the changes are:
>  - add themself to Uploaders (at my request).
>  - Remove the dependency on the nexus package (which is broken)
>  - Implement  the nexus functionnaly with the well maintained h5py.
> 
> 
> thanks for considering the pre-approval
> 
> If it is ok, I will upload into unstable.

I'm reluctant to allow this, but as it seems to be a way to get rid of the
dependency on python-nxs, I'm willing to consider it. We are very close to the
release, so I suggest you upload it to unstable, and we can consider the
unblock once it's uploaded.

Please remove the moreinfo tag from this bug once the upload is in unstable.

Cheers,

Ivo

Bug#863459: unblock (pre-approval): tiff/4.0.8

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Sat, May 27, 2017 at 09:48:21AM +0200, László Böszörményi (GCS) wrote:
> Current version of tiff in the archive is 4.0.7 and the package
> already have 28 security patches that got attention (CVE id). Upstream
> released 4.0.8 which contains only security related changes[1]
> including memory leaks, division by zero, undefined behaviour, integer
> overflows and excessive memory allocation fixes.
> There are no major or software configuration changes[2].

Please go ahead and remove the moreinfo tag from this bug once the upload is
in unstable and the builds are done on all the relevant architectures.

Cheers,

Ivo

Bug#863347: unblock: vlc/2.2.6-1~deb9u1

[Ivo De Decker]

Hi,

On Thu, May 25, 2017 at 08:37:00PM +, Niels Thykier wrote:
> > The upstream changes are attached as vlc-2.2.6.diff (updates to the 
> > translations
> > have been stripped). The changes in debian (vlc-debian.stretch.diff) 
> > includes
> > the usual bump of the versions in *.maintscripts and in Breaks + Repalces. 
> > The
> > Breaks + Replaces from libvlc-bin have been removed as they are not 
> > necessary.

> To be honest, it is a bit problematic that we have to bump the version
> of breaks/replaces + conffile handling for every upload.

This actually defeats the purpose of having the version in there. If people
have lines for both jessie(-security) and stretch in their sources.list, vlc
might go back and forth between the versions in jessie and stretch, depending
on the timing of the uploads. This will result in problems.

The only way to properly fix this, is to make sure the version of vlc in
jessie(-security) is always lower than the first version of vlc in stretch
(going forward). You can achieve this by bumping the epoch for vlc in stretch
(but not in jessie), and changing the breaks, replaces etc accordingly.

Cheers,

Ivo

Bug#861376: unblock: variety/0.6.3-4 (pre-upload approval)

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Thu, Apr 27, 2017 at 11:31:39PM -0700, James Lu wrote:
> Attached is a debdiff between 0.6.3-1 (currently in unstable) and 0.6.3-4,
> which I plan to release if this is okay.

Please go ahead with the upload and remove the moreinfo tag from this bug once
the package built on all the relevant architectures in unstable.

Cheers,

Ivo

Bug#861385: Acknowledgement (unblock (pre-approval): khal/1:0.8.4-4)

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Sat, Apr 29, 2017 at 03:24:57PM +0200, Filip Pytloun wrote:
> I see, didn't realized that epoch is not in file names. So new debdiff
> attached and retitling.

> diff -Nru khal-0.8.4/debian/changelog khal-0.8.4/debian/changelog
> --- khal-0.8.4/debian/changelog   2017-01-17 19:30:32.0 +0100
> +++ khal-0.8.4/debian/changelog   2017-04-28 10:28:13.0 +0200
> @@ -1,3 +1,28 @@
> +khal (1:0.8.4-4) unstable; urgency=medium
> +
> +  * Raise epoch to "revert" new upstream version in unstable and pass
> +stretch migration
> +
> + -- Filip Pytloun   Fri, 28 Apr 2017 10:28:13 +0200
> +
> +khal (0.9.5-2) unstable; urgency=medium
> +
> +  * d/copyright: mention presence of
> +0002-Reference-license-from-copyright-file.patch (Closes: #860984)
> +  * d/copyright: add upstream contact
> +  * d/copyright: update copyright year
> +
> + -- Filip Pytloun   Mon, 24 Apr 2017 09:45:57 +0200
> +
> +khal (0.9.5-1) unstable; urgency=medium
> +
> +  * New upstream release
> +  * d/patches: some TZ tests may fail due to Debian's python-tz of older
> +version but with newer TZ definitions, should be removed when 2017.2
> +reaches sid (Closes: #859472)
> +
> + -- Filip Pytloun   Thu, 20 Apr 2017 20:55:06 +0200
> +
>  khal (0.8.4-3) unstable; urgency=medium
>  

Please remove the changes of 0.9.5-1 and 0.9.5-2 from the changelog, as
1:0.8.4-4 doesn't contain these changes. With that change, feel free to upload
to unstable and remove the moreinfo tag from this bug once it's built on all
relevant architectures.

Cheers,

Ivo

Bug#861432: nmu: golang-go.crypto

[Ivo De Decker]

# cloning the bug, see below
clone 861432 -1
reassign -1 notary 0.1~ds1-1
retitle -1 notary: FTBFS with latest golang-go.crypto
severity -1 serious
clone 861432 -2
reassign -2 nomad 0.4.0+dfsg-1
retitle -2 nomad: FTBFS with latest golang-go.crypto
severity -2 serious
clone 861432 -3
reassign -3 packer 0.10.2+dfsg-4
retitle -3 packer: FTBFS with latest golang-go.crypto
severity -3 serious
clone 861432 -4
reassign -4 systemd-docker 0.2.1+dfsg-2
retitle -4 systemd-docker: FTBFS with latest golang-go.crypto
severity -4 serious
clone 861432 -5
reassign -5 docker-swarm 1.2.5+dfsg-2
retitle -5 docker-swarm: FTBFS with latest golang-go.crypto
severity -5 serious
clone 861432 -6
reassign -6 grafana 2.6.0+dfsg-3
retitle -6 grafana: FTBFS with latest golang-go.crypto
severity -6 serious
clone 861432 -7
reassign -7 docker.io 1.13.0~ds1-3
retitle -7 docker.io: FTBFS with latest golang-go.crypto
severity -7 serious
thanks

Hi,

On Fri, Apr 28, 2017 at 06:16:04PM -0500, Michael Lustfield wrote:
> Bug #859655 [3] has been fixed in unstable. This addresses a CVE bug, but also
> requires all reverse build dependencies be rebuilt. After this package has
> migrated to testing, there will be 62-64 packages that need rebuilding as 
> well.
> 
> I have run build tests in both unstable and testing for this update using an
> amd64 sbuild environment. For reference, the results:
> 
> testing:
>   success: 62,  failed: 2 (being addressed)
> unstable
>   success: 107, failed: 7 (unchecked)
> 
> 
> For the moment, I need the 107 packages in this list [1] to rebuilt in 
> unstable.
> ... wanna build? :)

[list of wb commands]

I scheduled the binNMUs. Please note that we currently cannot schedule binNMUs
for arch:all packages. So these are not rebuilt. The other ones should be ok
(with the exception of restic, but you already filed #861431 for that).

> [2] failed (not included above):

Thanks for testing all this.

> notary_0.1~ds1-1 (see buildlogs/notary_0.1~ds1-1)
> nomad_0.4.0+dfsg-1 (see buildlogs/nomad_0.4.0+dfsg-1)
> packer_0.10.2+dfsg-4 (see buildlogs/packer_0.10.2+dfsg-4)
> systemd-docker_0.2.1+dfsg-2 (see buildlogs/systemd-docker_0.2.1+dfsg-2)
> docker-swarm_1.2.5+dfsg-2 (see buildlogs/docker-swarm_1.2.5+dfsg-2)
> grafana_2.6.0+dfsg-3 (see buildlogs/grafana_2.6.0+dfsg-3)
> docker.io_1.13.0~ds1-3 (see buildlogs/docker.io_1.13.0~ds1-3)

I cloned this bug for each of them, to track the issue. It looks like only
packer is in testing. It doesn't seem to have any rdeps, so if it cannot be
fixed, we can just remove it. Obviously, a fix would be better :)

Cheers,

Ivo

Bug#861014: unblock: python-pyelftools/0.24-2

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Sun, Apr 23, 2017 at 07:51:24PM +0200, Tomasz Buchert wrote:
> Please unblock package python-pyelftools
> 
> The package FTBFSes on i386. The version in unstable fixes it.
> 
> unblock python-pyelftools/0.24-2

You changed the debhelper compat version from 9 to 10. That is not appropriate
during the freeze. Please revert this.

Cheers,

Ivo

Bug#860999: unblock: vim/2:8.0.0197-4 (pre-approval)

[Ivo De Decker]

Control: tags -1 confirmed moreinfo

Hi,

On Sun, Apr 23, 2017 at 08:29:50AM -0400, James McCoy wrote:
> * Update Ubuntu release names in syntax highlighting files
>   + Additionally, require word boundaries around release names, so
> stretch isn't mishighlighted as (unsupported) etch. (#859247)

If you are updating this, maybe you could also add support for
jessie-backports-sloppy, stretch-backports and stretch-security.

> * Fix a regression in parsing ctags-generated TAGS files (#859426)
> * Set $TERM to a sane value before running tests.  This fixes test
>   failures when $TERM is an atypical value (like "unknown" in the
>   reproducible builds environment).

Please go ahead with the upload and remove the moreinfo tag from this bug once
the upload is in unstable.

Cheers,

Ivo

Bug#860429: unblock: golang-go.crypto/1:0.0~git20170407.0.55a552f-1

[Ivo De Decker]

Hi,

On Thu, Apr 20, 2017 at 03:45:29AM -0500, Michael Lustfield wrote:
> Here we go...
> 
> The packer failure seems very unsurprising and I expect it to be an easy one 
> to
> deal with. Every other reverse build dependency that ratt detected built
> without failure.

So we could try to see if we can get the fix into testing.

The first issue is that golang-go.crypto contains a lot of unrelated changes
in unstable, which (probably) aren't suitable for an unblock. So these need to
be reverted. So you need to upload a version of golang-go.crypto which is
based on the version in testing, with the patch for CVE-2017-3204 on top.

After that, the rdeps need to be rebuilt and fixed (if necessary). If your
tests are any indication, that shouldn't be a big issue.

When all the rdeps are ok, the whole group of rebuilt/fixed packages can go
into testing. That way we can avoid having to remove the old unfixed ones.

Cheers,

Ivo

Bug#860717: unblock: python-passlib/1.7.1-1

[Ivo De Decker]

Control: tags -1 moreinfo confirmed

Hi,

On Wed, Apr 19, 2017 at 07:38:05PM +1000, Brian May wrote:
> Please unblock package python-passlib
> 
> Fixes a RC FTBFS issue on i386. See #860619.
> 
> The version in unstable is a new upstream version that fixes the problem
> (and was already uploaded). The upstream changelog:
> 
> https://passlib.readthedocs.io/en/stable/history/1.7.html#id1

If this version fixes the FTBFS, can you update the bug metadata to reflect
this?

> Alternatively, if preferred, I could upload a version to
> testing-proposed-updates that includes the upstream patch from:
> 
> https://bitbucket.org/ecollins/passlib/commits/80f838f5771f6753b0e46716ab25b48641aeef89
> 
> Procedure is for me to contact you in either case.

I prefer to fix this via t-p-u, as it's only a change to the tests. Please go
ahead and upload to t-p-u with the patch above and remove the moreinfo tag
from this bug once the package is uploaded.

Cheers,

Ivo

Bug#860773: unblock: pysal/1.13.0-4

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Wed, Apr 19, 2017 at 11:40:33PM +0200, Bas Couwenberg wrote:
> Please unblock package pysal
> 
> It "fixes" #860694 by ignoring test failure on i386 where it's normally
> not built (the source only builds arch:all packages).

Same question as in #860772:

Do you expect the build (including the tests) to work on all other
architectures? If so, this fix is fine.

If it only works on amd64, it might be better to ignore failures on all other
architectures instead of only ignoring it on i386.

Cheers,

Ivo

Bug#860772: unblock: python-geopandas/0.2.1-3

[Ivo De Decker]

Control: tags -1 moreinfo

Hi,

On Wed, Apr 19, 2017 at 11:39:03PM +0200, Bas Couwenberg wrote:
> It "fixes" #860621 by ignoring test failure on i386 where it's normally
> not built (the source only builds arch:all packages)

Do you expect the build (including the tests) to work on all other
architectures? If so, this fix is fine.

If it only works on amd64, it might be better to ignore failures on all other
architectures instead of only ignoring it on i386.

Cheers,

Ivo