Bug#986509: bind-dyndb-ldap: FTBFS: gcc: error: unrecognized command-line option '-V'
Control: retitle -1 bind-dyndb-ldap: FTBFS with newer bind version in testing
Hi,
On Wed, Apr 07, 2021 at 08:29:54AM +0200, Lucas Nussbaum wrote:
> > conftest.c: In function 'main':
> > conftest.c:40:17: error: 'dns_libinterface' undeclared (first use in this
> > function)
> >40 | printf("%d\n", dns_libinterface);
> > | ^~~~
[...]
> > configure:13361: error: Can't obtain libdns version.
This seems to be caused by the new bind version, and is probably fixed by this
commit upstream:
https://pagure.io/bind-dyndb-ldap/c/f0d75b778ee7bfd0feb368b51027943085a54705?branch=master
Note that there was a new bind upload since then, so there might be more
breakage...
Cheers,
Ivo
Bug#986514: mercurial: FTBFS: dh_auto_test: error: make -j4 check PYTHON=python3.9 "TESTFLAGS=--verbose --timeout 1440 --jobs 4 --blacklist /<>/debian/mercurial.test_blacklist" returned e
Control: tags -1 patch Hi Julien, On Tue, Apr 13, 2021 at 07:35:45PM +0200, Julien Cristau wrote: > On Tue, Apr 13, 2021 at 07:33:04PM +0200, Chris Hofstaedtler wrote: > > * Julien Cristau [210413 17:32]: > > > I'm not sure that's quite correct as it doesn't restore the backwards > > > compatibility that python broke. On the other hand I don't know if > > > python even provides a way for consumers to remain backwards-compatible. > > > Thanks, python... > > > > No: https://bugs.python.org/issue42967#msg387638 and ff. > > > Thanks for the pointer. Seems to me that misguided change should be > reverted. While that may be true, it might be good to change the test anyway, as it's unclear if this behaviour can be relied on in the future (especially if upstream doesn't revert). Thanks, Ivo
Bug#946412: RM: janus/0.10.9-1
Hi, On Thu, Apr 22, 2021 at 02:47:22PM +0200, Jonas Smedegaard wrote: > As tracked in bug#946412, janus is unsuitable for long-term maintained > releases > and should therefore sbe dropped from bullseye now it is frozen. I added a removal hint. Given that you state that it's not suitable for a stable release, it shouldn't be in testing either. I added a block hint to prevent it from coming back after the release. Cheers, Ivo
Bug#987299: unblock: gstreamer1.0/1.18.4-1
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
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
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#987279: nim: amd64 binaries built by maintainer; needs source-ony upload
Federico, On Tue, Apr 20, 2021 at 08:49:54PM +0200, Salvatore Bonaccorso wrote: > The last nim upload seems to have included binary builds for amd64 > which will prevent nim to potentially go to testing (even after > unblocked), as it needs a source-only upload with builds done on > buildds. > > Cf. https://tracker.debian.org/pkg/nim > > * Not built on buildd: arch amd64 binaries uploaded by > federico.cera...@gmail.com > * Not built on buildd: arch all binaries uploaded by > federico.cera...@gmail.com, a new source-only upload is needed to allow > migration I guess something went wrong with the upload, because the changes file has both Distribution: sid and nim (1.4.6-1) experimental; urgency=medium Please check what went wrong to avoid this in the future. In this case, I suspect the upload wasn't meant for bullseye, and it can just stay in unstable (unfortunately). Cheers, Ivo
Bug#987022: unblock: spamassassin/3.4.5~pre1-4
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#987101: RM: ruby-rexml -- ROM; duplicate package, included in libruby2.7
Hi, On Sat, Apr 17, 2021 at 10:30:18PM +0530, Pirate Praveen wrote: > This package duplicates fucntionality embedded in ruby. This is affected by > rc bug #986806 (already fixed in ruby2.7 2.7.3-1). As discussed in the rc > bug above, please remove this package from the archive. Just a note for the ftp-team: As mentioned in the other bug report: dak rm show an rdep problem with ruby-kramdown, but that's not actually the case, because libruby2.7 Provides ruby-rexml: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986806#46 Thanks! Ivo
Bug#953562: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade
Hi Marco, On Thu, Apr 15, 2021 at 02:27:10PM +0200, Marco d'Itri wrote: > On Apr 14, Paul Gevers wrote: > > > The patch looks sensible after reading the discussion in these bugs. Can > > we have an upload soon to have exposure? > Unless there are any objections I will do a libxcrypt upload in a couple > of days. OK, thanks! > I think that I can leave the udeb library in /usr/lib/. Yes. There is no upgrade issue there, and making sure the udeb doesn't change avoids potential issues with the installer. Ivo
Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8
Hi Mattia, On 4/14/21 8:18 PM, Mattia Rizzolo wrote: On Wed, Apr 14, 2021 at 02:22:54PM +0200, Ivo De Decker wrote: So, if that's what you think, should I upload an inkscape with a manual dependency on libpoppler-glib8 >= 20.09.0? Yes, that would be useful. I've just uploaded a new inkscape with this as its only change. https://salsa.debian.org/multimedia-team/inkscape/-/commit/0a6972eebee178f90109c96e568cdce51b7b0276 And I've confirmed with a binary debdiff that the final Depends line in the .deb is as expected. Thanks! It's probably a good idea if you could age the upload so it doesn't wait 20 days, and unblock it (since it's a key package). I added a hint. Ivo
Bug#986758: unblock: systemd/247.3-5
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#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8
Hi, On Tue, Apr 13, 2021 at 06:53:55PM +0200, Mattia Rizzolo wrote: > On Sun, Apr 11, 2021 at 08:02:20PM +0200, Ivo De Decker wrote: > > There is a theoretical and a practical aspect to this issue. From a > > theoretical point of view, the dependency relations should not be stricter > > than necessary, to allow partial upgrades and to avoid complicating > > migration to testing of library transitions. > > Then again, I believe the project at large is moving towards > stricter-than-necessary dependencies (see the implied dh_makeshlibs -V > in dh compat 12, lintian nagging about the Build-Depends-Package in > .symbols files, etc). We'll need to find a middle ground here. The impact will depends on the way the issue is fixed. I guess that's something for bookworm. The main concerns (from my POV) are: - making sure we don't inadvertently create some dependency loop that makes upgrades more difficult (or impossible) - avoiding turning the library transition into a non-smooth one, where all packages have to migrate at the same time > I also don't believe a stricter dependency between libpoppler102 and > libpoppler-glib8 would have any of the issue you mention. I suspect tightening the dependencies between libpoppler-glibX and libpopplerX will cause a lot less issues than artificially bumping the version for all symbols. > > It would create the desired dependency, but I'm not sure if this is better > > than just manually adding it to the 2 remaining packages we are aware of > > (especially at this stage of the freeze). > > > For now, though (and especially for bullseye), I think we should accept > > that we aren't going to solve this issue in general. The best we can do, is > > to try to fix obvious cases where we are aware of the issue. In other cases, > > we'll probably need to advise our users to do a full upgrade instead of a > > partial one. > > So, if that's what you think, should I upload an inkscape with a manual > dependency on libpoppler-glib8 >= 20.09.0? Yes, that would be useful. > (mhh, is there a way to do this without writing it in d/control?). There probably is, but writing it in d/control will be the easiest by far. Thanks, Ivo
Bug#986899: [pre-approval] unblock: apt/2.2.3
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
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#986514: mercurial: FTBFS: dh_auto_test: error: make -j4 check PYTHON=python3.9 "TESTFLAGS=--verbose --timeout 1440 --jobs 4 --blacklist /<>/debian/mercurial.test_blacklist" returned e
control: tags -1 patch Hi Julien, On Wed, Apr 07, 2021 at 08:42:06AM +0200, Lucas Nussbaum wrote: > Source: mercurial > Version: 5.6.1-2 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20210406 ftbfs-bullseye [...] > > ERROR: test-archive.t output changed > > !# Ret was: 0 (test-archive.t) I'm pretty sure this is caused by changes in python 3.9.2 and fixed by this patch from ubuntu: https://patches.ubuntu.com/m/mercurial/mercurial_5.6.1-2ubuntu1.patch Cheers, Ivo
Bug#985455: python3-pkg-resources: fails to upgrade from 'buster': ValueError: not enough values to unpack (expected 4, got 3) in /usr/bin/py3compile
Hi, On Mon, Mar 29, 2021 at 10:26:12PM +0200, Jochen Sprickerhof wrote: > I can reproduce the bug when upgrading python3-joblib before > python3-minimal. This sounds related to #954403. Yeah, and it seems installing the new python3-minimal fixes the issue (even after it happened). So I suspect this bug could be fixed by adding a versioned dependency on python3-minimal to python3-joblib. Cc'ing Graham, who did the last joblib uploads. Cheers, Ivo
Bug#986439: [pre-approval] unblock: node-xmldom/0.5.0-1
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#985958: [pre-approval] unblock: spip/3.2.11-2
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#986835: [pre-approval] unblock: dpkg/1.20.8
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
Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8
Hi Simon, There is a theoretical and a practical aspect to this issue. From a theoretical point of view, the dependency relations should not be stricter than necessary, to allow partial upgrades and to avoid complicating migration to testing of library transitions. On 4/11/21 12:37 PM, Simon McVittie wrote: A way to fix this, is to add a dependency to the newer libpoppler-glib8 as well (as was done for elpa-pdf-tools-server). Obviously, it would be nice to have an elegant way to handle this automatically at build time to make sure the dependencies are correct, without having to add them manually. Should libpoppler102 get a Breaks: libpoppler-glib8 (<< 20.08.0-1~), where that version was the first one to have the libpoppler102 SONAME? That would ensure that the bad partial upgrade you describe can't happen, because if a dependent package uses libpoppler102 ABI directly, and also uses libpoppler indirectly via libpoppler-glib8, then it's the same libpoppler. The issue only happens if the same package depends on both libpoppler and libpoppler-glib, so forcing libpoppler and libpoppler-glib to be upgraded at the same time, is more strict than is theoretically needed. Also, I wonder if this would still allow the reverse issue to happen: If an old inkscape is linked against the old libpoppler-glib8 and libpoppler95, installing libpoppler102 would force libpoppler-glib8 to be upgraded, and the old inkscape would link against the old libpoppler and the new libpoppler-glib, causing the same issue (I didn't test if this happens in practice). Or, would this work? * in src:poppler libpoppler-glib8.symbols.in, bump the version on every symbol to at least 20.08.0-1~ (the version that had the most recent SONAME bump) and upload to unstable This would cause every package that links against libpoppler-glib8, but not (directly) against libpoppler to depend on the newer version of libpoppler-glib8, even if that's not necessary. In practice, this would severely reduce the usefulness of using the symbols file. And make partial upgrades (for users) and smooth updates (for library transitions to testing) much harder. * binNMU the dependent packages elpa-pdf-tools-server, gambas3-gb-poppler and inkscape That way, the binNMU'd versions of the dependent packages would have: Depends: libpoppler-glib8 (>= 20.08.0-1~), libpoppler102 (>= x) and the bad partial upgrade you describe could not happen, because the dependent package (inkscape in your example) would pull in the new libpoppler-glib8 in addition to the new libpoppler102. It would create the desired dependency, but I'm not sure if this is better than just manually adding it to the 2 remaining packages we are aware of (especially at this stage of the freeze). For completeness, maybe it would make sense to give libpoppler-cpp0v5 and libpoppler-qt5-1 the same treatment as libpoppler-glib8 (whatever that is), since they could suffer from the same bug if an application calls into libpoppler both directly and via libpoppler-cpp0v5 or libpoppler-qt5-1 - although I don't know whether that happens in practice. Well, I suspect there are actually quite a lot of these issue a our packages, but that many of them are not usually detected. Doing partial upgrades might result in binaries being (transitively) linked to different (incompatible) version of the same library. Even when that happens, it's not always immediately obvious. In the inkscape example, the issue only shows up when you try to open a pdf, not when you just start the program. So the fact that the programs runs successfully in some cases, doesn't guarantee that the issue isn't present. This issue reminds me of https://bugs.debian.org/962320, which is somewhat similar, because multiple versions of the same boost library are linked into the same binary. In that case, this was detected because some of the packages weren't rebuilt yet, but I suspect it might be possible to trigger a similar issue by doing a partial upgrade of a package that (transitively) pulls in a number of boost libraries. This brings me to the practical aspect of this issue: we try to support partial upgrades, and generate the correct dependency relation to make sure that unsupported combinations of packages can't be installed at the same time. However, we currently don't have a way to generate these dependencies when multiple interdependent libraries are involved. I'm unsure how we could handle this in general, but it certainly would be nice to have a way to do so. For now, though (and especially for bullseye), I think we should accept that we aren't going to solve this issue in general. The best we can do, is to try to fix obvious cases where we are aware of the issue. In other cases, we'll probably need to advise our users to do a full upgrade instead of a partial one. Cheers, Ivo
Bug#969907: Bug#969537: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8
Hi, On Thu, Feb 18, 2021 at 03:33:23PM +, Simon McVittie wrote: > > I'd rather think that the situation happened because > > elpa-pdf-tools-server links both to libpoppler and libpoppler-glib: > > the rebuild against poppler 20.09.0 (i.e. libpoppler102) make > > elpa-pdf-tools-server link to libpoppler102 (forcing the newer > > dependency to it), and setting an old dependency for libpoppler-glib > > because there is no need for a newer version. > > So elpa-pdf-tools-server is linked to libpoppler-glib, and because the > (parts of the) libpoppler-glib API that it uses has not changed for a > while, it is happy with an old version; but then during a partial > upgrade, it can get this > > elpa-pdf-tools-server > \- old libpoppler-glib > | \- libpoppler95 > \- libpoppler102 > > and the two copies of libpoppler fight? > > That seems entirely plausible, and I don't immediately see a way to > fix it without adding Breaks (which would force a lockstep upgrade, > somewhat defeating the purpose of SONAMEs). > > GNOME had similar issues during the libffi transition, where gjs' direct > use of libffi conflicted with its indirect use via GLib, and I think we > ended up adding Breaks to force the broken combinations not to happen. There are 2 other packages in bullseye that depend on both libpoppler and libpoppler-glib: gambas3-gb-poppler and inkscape. This issue is also present in inkscape (I didn't try to reproduce it with gambas3-gb-poppler, but I guess the situation is similar): Install inkscape on a buster system. The pdf David attached can be opened without issue. Upgrade only inkscape to bullseye (letting apt pull in the dependencies, which include libpoppler102 but not the newer libpoppler-glib8). When opening the pdf inkscape closes with an error, and the kernel reports: inkscape[9032]: segfault at 9 ip 7fad9e3e1d3e sp 7fff5127ae30 error 4 in libpoppler-glib.so.8.10.0[7fad9e3c4000+27000] Installing the new libpoppler-glib8 fixes the issue. A way to fix this, is to add a dependency to the newer libpoppler-glib8 as well (as was done for elpa-pdf-tools-server). Obviously, it would be nice to have an elegant way to handle this automatically at build time to make sure the dependencies are correct, without having to add them manually. Cheers, Ivo
Bug#985739: unblock: krb5/1.18.3-5
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#922981: tagging 922981 (ca-certificates-java: /etc/ca-certificates/update.d/jks-keystore doesn't update /etc/ssl/certs/java/cacerts)
Hi Julien, Do you have any comment on the merge request Andreas submitted to ca-certificates, to allow breaking to dependency cycle in ca-certificates-java (see mail quoted below, from #922981)? Thanks, Ivo On Fri, Mar 19, 2021 at 03:04:35AM +0100, Andreas Beckmann wrote: > On Thu, 11 Mar 2021 09:11:37 +0100 Paul Gevers wrote: > > Is it possible that we get this uploaded soon? If you have the fix > > ready, it would be good to have it sooner rather than later as we're in > > the freeze, so it gets a bit of exposure. > > I'd like to get some maintainer feedback on > > https://salsa.debian.org/java-team/ca-certificates-java/-/merge_requests/5 > > https://salsa.debian.org/debian/ca-certificates/-/merge_requests/6 > > I have now run some tests in my piuparts instance by injecting these > packages into buster->bullseye upgrades and have not observed any upgrade > issues related to ca-certificates-java. > > > Andreas >
Bug#953562: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade
Hi,
On Fri, Mar 19, 2021 at 04:52:57PM +0100, Ivo De Decker wrote:
> > > I wonder if all this might be caused by the breaks from libcrypt1 (against
> > > libc6 (<< 2.29-4)). Is there a way to remove the breaks without causing
> > > issues? Maybe this is somewhat similar to the situation in
>
> I tried this with a modified libcrypt1 binary (removing the breaks), and it
> fails (/lib/x86_64-linux-gnu/libcrypt.so.1 is missing after the libc6 unpack).
> I guess that's because of #953562: libc6 shipped
> /lib/x86_64-linux-gnu/libcrypt.so.1 while libcrypt1 ships
> /usr/lib/x86_64-linux-gnu/libcrypt.so.1 Obviously, for dpkg these are 2
> different files, but on a system with merged /usr they are not.
I created a patch to move libcrypt back to /lib, and that seems to solve the
issue. The patch is attached. With this patch, libcrypt1 is installed before
libc6 is upgraded, and the takeover of the library works correctly.
This also fixes #953562, which reported that this move is necessary.
Note that the original move from /lib to /usr/lib was more complicated than my
patch:
https://salsa.debian.org/md/libxcrypt/-/commit/1fb86fde5410088580f8032834037facb26d2d49
I didn't look into the details of the -dev package, because they are not
relevant to this bug. The patch might need to be adapted.
I ran a number of (partial and full) upgrade tests, and they all seem to work
fine. In all cases, libcrypt1 is installed before libc6, and there is no
intermediate situations where libcrypt.so.1 is missing.
> > The problem of removing the break, is that we loose the possibility of
> > downgrades. Is it something acceptable?
>
> Well, I guess if that is the cost of not breaking people's systems on upgrade,
> that sounds like an acceptable trade-off. But I might be overlooking certain
> scenarios.
>
>
> > > https://bugs.debian.org/972936#24: libgcc-s1 takes over binaries from
> > > libgcc1,
> > > but only 'replaces' it, without breaks (note that extra steps had to be
> > > taken
> > > to avoid further issues (adding Important: yes and Protected: yes)).
> >
> > Are this extra-steps basically required to prevent downgrades?
>
> They are required to prevent you from removing libcrypt1 again: on a buster
> system, install such a hypothetical libcrypt1 from bullseye (which takes over
> libcrypt.so.1). Then remove that again. Now libcrypt.so.1 is missing. If the
> breaks is present, libcrypt1 can only be installed together with the new
> libc6, which prevents you from removing libcrypt1 afterwards.
As in #972936, my patch adds Important and Protected, which prevents removal of
libcrypt1 once it's installed.
Cheers,
Ivo
diff --git a/debian/changelog b/debian/changelog
index b5088dc..16d25ff 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+libxcrypt (2:4.4.17-1.1) UNRELEASED; urgency=medium
+
+ * Make sure takeover of libcrypt.so.1 from libc6 works correctly on upgrades
+from buster to bullseye (Closes: #974552):
+- Move the library back from /usr/lib/ to /lib/, because that's where it
+ was in the old libc6 (Closes: #953562)
+- Remove breaks from libcrypt1, to allow installing libcrypt1 before libc6
+ is upgraded
+- Mark libcrypt1 as Important and Protected, to prevent removal after a
+ partial upgrade
+
+ -- Ivo De Decker Tue, 06 Apr 2021 19:46:44 +
+
libxcrypt (1:4.4.17-1) unstable; urgency=medium
* New upstream release.
diff --git a/debian/control b/debian/control
index 35939dd..a2ae60a 100644
--- a/debian/control
+++ b/debian/control
@@ -16,11 +16,8 @@ Architecture: any
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}
-Breaks:
- libc6 (<< 2.29-4),
- libc6.1 (<< 2.29-4) [alpha ia64],
- libc0.1 (<< 2.29-4) [kfreebsd-amd64 kfreebsd-i386],
- libc0.3 (<< 2.29-4) [hurd-i386],
+XB-Important: yes
+Protected: yes
Replaces:
libc6 (<< 2.29-4),
libc6.1 (<< 2.29-4) [alpha ia64],
diff --git a/debian/libcrypt-dev.files b/debian/libcrypt-dev.files
index 94387de..fc172a1 100644
--- a/debian/libcrypt-dev.files
+++ b/debian/libcrypt-dev.files
@@ -1,5 +1,5 @@
/usr/include/
/usr/share/man/
-/usr/lib/*/pkgconfig/
-/usr/lib/*/*.a
-/usr/lib/*/*.so
+/lib/*/pkgconfig/
+/lib/*/*.a
+/lib/*/*.so
diff --git a/debian/rules b/debian/rules
index 2969306..26f2bcd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -34,11 +34,11 @@ CONFFLAGS = --disable-werror --prefix=/usr \
CONFFLAGS_deb = $(CONFFLAGS) \
$(shell DEB_BUILD_MAINT_OPTIONS="hardening=+bindnow" \
dpkg-buildflags --export=configure || true) \
- --libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
+ --libdir=/lib/$(DEB_HOST_MULTIARCH)
CONFFLAGS_udeb = $(CONFFLAGS) \
$(subst -O2,-Os -fomit-frame-pointer,$(shell DEB_BUILD_MAINT_OPTIONS="hardening=-all" \
Bug#986161: fixed in droopy 0.20160830-4
Hi, On Sat, Apr 03, 2021 at 02:17:47PM +, Debian FTP Masters wrote: > Binary: droopy > Architecture: source all Please note that you uploaded binaries. If you want the fix to (potentially) migrate to testing, you'll need to do a new source-only upload (and file an unblock request after that). Cheers, Ivo
Bug#985557: RM: gnucobol -- ROM; wrong version of compiler, breaks compatibility
Control: tags -1 moreinfo Hi, On Fri, Mar 19, 2021 at 04:25:01PM -0600, Al Stone wrote: > Please remove the version of gnucobol in unstable. Per upstream, > this version in not backwards compatible with any prior version. > I made a mistake in packaging it at all. > > An upload of the proper version (3.1.2) is being prepared. Removing a package from unstable and then uploading the same package with a lower version isn't possible. If you want to go back to version 3.x, you'll need to do an upload with a version higher than the current one. Cheers, Ivo
Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade
Hi, On Fri, Mar 19, 2021 at 03:51:34PM +0100, Aurelien Jarno wrote: > > However, in all of my tests, between the unpack of the new libc6 and > > libcrypt1 > > only other unpacks where done, and no dpkg hooks where run. If you have a > > way > > to reproduce the upgrade where dpkg ran the hook in between, that might be > > interesting. Do you still have a list of packages that was installed before > > you started the upgrade? > > Have you tried to install a foreign libc6? It usually makes the upgrade > a bit more tricky and could be what triggers the issue. I installed whois:i386, which pulled in libc6:i386 as well. Feel free to suggest a larger set of i386 for me to try. > > Note that I manually changed the binaries and didn't rebuild glibc, so I > > might > > have made a mistake, but this scenario should certainly be tested before > > something like this is uploaded to unstable. Maybe an upload to experimental > > might allow people to test this more easily? > > > > I Cced the apt maintainers to see if they have other suggestions to get > > apt/dpkg to unpack libcrypt1 before libc6. > > Another (ugly) suggestions we discussed at some point was: > 1) in the preinst copy the existing libcrypt1 library to a private and > add it to ldconfig with lower priority than /usr/lib/$(MULTIARCH) > 2) in the postinst remove these copy and ldconfig configuration. Do you think this is something that you can get to work in a reliable way? > > I wonder if all this might be caused by the breaks from libcrypt1 (against > > libc6 (<< 2.29-4)). Is there a way to remove the breaks without causing > > issues? Maybe this is somewhat similar to the situation in I tried this with a modified libcrypt1 binary (removing the breaks), and it fails (/lib/x86_64-linux-gnu/libcrypt.so.1 is missing after the libc6 unpack). I guess that's because of #953562: libc6 shipped /lib/x86_64-linux-gnu/libcrypt.so.1 while libcrypt1 ships /usr/lib/x86_64-linux-gnu/libcrypt.so.1 Obviously, for dpkg these are 2 different files, but on a system with merged /usr they are not. > The problem of removing the break, is that we loose the possibility of > downgrades. Is it something acceptable? Well, I guess if that is the cost of not breaking people's systems on upgrade, that sounds like an acceptable trade-off. But I might be overlooking certain scenarios. > > https://bugs.debian.org/972936#24: libgcc-s1 takes over binaries from > > libgcc1, > > but only 'replaces' it, without breaks (note that extra steps had to be > > taken > > to avoid further issues (adding Important: yes and Protected: yes)). > > Are this extra-steps basically required to prevent downgrades? They are required to prevent you from removing libcrypt1 again: on a buster system, install such a hypothetical libcrypt1 from bullseye (which takes over libcrypt.so.1). Then remove that again. Now libcrypt.so.1 is missing. If the breaks is present, libcrypt1 can only be installed together with the new libc6, which prevents you from removing libcrypt1 afterwards. Cheers, Ivo
Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade
Hi, On Fri, Nov 20, 2020 at 01:44:50PM +0100, Alois Wohlschlager wrote: > Am Freitag, den 20.11.2020, 09:13 + schrieb Niko Tyni: > > I don't think this is related to the recent perl 5.30 -> 5.32 > > transition. > > The report is about a buster -> bullseye upgrade, and perl in > > bullseye > > was still at 5.30 at the time. > > > > In any case, the report says perl (presumably perl-base as well) was > > still at the buster version when the breakage happened, so it didn't > > have the libcrypt1 dependency. > > This is indeed the case. perl-base was only upgraded to the bullseye > version after I manually fixed the breakage. (Indeed, when I wrote > "Perl" I actually meant "perl-base", but perl itself was also at the > buster version FWIW.) > > > FWIW the breakage can be reproduced just by manually unpacking the > > new > > libc6 on a buster system. > > > > I don't know why it hasn't been encountered earlier. > > I found out by now that the problem actually has been encountered > earlier(#946599, where it broke libc's maintainer scripts). In my case, > it broke the check-support-status hook providd by debian-security- > support. (I'm not sure whether it's such a great idea for dpkg to run > hooks when dependencies are broken, but that's what was happening on my > system.) I filed #984539 against debian-security-support, to make sure the hook never fails. That doesn't fix this bug, but at least it might reduce the potential impact of issues like these. > > Yeah, I missed the libcrypt1 -> libc6 dependency. That prevents this > > option. (I wonder if the circular dependency is a factor in apt > > choosing > > the upgrade order that results in this breakage.) > > I'm not sure what's going on here, as libcrypt1's libc6 Depends should > be satisfied by the buster version. So it seems to me like installing > libcrypt1 before upgrading libc6 should be strictly better than doing > it the other way round, even purely in terms of satisfaction of > dependencies. > > Maybe it's worth investigating why apt decides to proceed the "wrong" > way anyway, should I try setting up a VM to reproduce the problem? I did some upgrade tests starting from the debian-10-generic-amd64-20210208-542.qcow2 cloud image, and in all my tests, apt chooses to unpack libc6 before libcrypt1. However, in all of my tests, between the unpack of the new libc6 and libcrypt1 only other unpacks where done, and no dpkg hooks where run. If you have a way to reproduce the upgrade where dpkg ran the hook in between, that might be interesting. Do you still have a list of packages that was installed before you started the upgrade? Note that even if the hook isn't run or doesn't fail, there is still a period between the unpack of libc6 and libcrypt1 where perl is broken. If other operations are done in between that cause maintainer scripts to run, these could potentially call perl, which will be broken in this case. > > > > Another option might be to have the new libc6 Conflict with old > > > > versions > > > > of Essential:yes packages that need libcrypt1, forcing those > > > > Essential:yes > > > > packages to get upgraded first. A quick check based on libcrypt1 > > > > reverse > > > > dependencies in sid shows perl-base, login and util-linux. I'm > > > > not sure > > > > if this list is exhaustive, though. > > Having libc6 Conflict with one of those packages should be enough, > right? I tried creating libc6 packages with either a conflits or a breaks agains the old perl-base or the old login, and in each case I get this error: E: This installation run will require temporarily removing the essential package libc6:amd64 due to a Conflicts/Pre-Depends loop. This is often bad, but if you really want to do it, activate the APT::Force-LoopBreak option. E: Internal Error, Could not early remove libc6:amd64 (2) So it doesn't look like this will work. Note that I manually changed the binaries and didn't rebuild glibc, so I might have made a mistake, but this scenario should certainly be tested before something like this is uploaded to unstable. Maybe an upload to experimental might allow people to test this more easily? I Cced the apt maintainers to see if they have other suggestions to get apt/dpkg to unpack libcrypt1 before libc6. I wonder if all this might be caused by the breaks from libcrypt1 (against libc6 (<< 2.29-4)). Is there a way to remove the breaks without causing issues? Maybe this is somewhat similar to the situation in https://bugs.debian.org/972936#24: libgcc-s1 takes over binaries from libgcc1, but only 'replaces' it, without breaks (note that extra steps had to be taken to avoid further issues (adding Important: yes and Protected: yes)). Cheers, Ivo
Bug#985408: unblock: mutter/3.38.4-1
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
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
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
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
Bug#985116: libgrokj2k: FTBFS on i386
package: src:libgrokj2k version: 7.6.6-2 severity: serious tags: ftbfs Hi, The latest upload of libgrokj2k to unstable fails on i386: https://buildd.debian.org/status/package.php?p=libgrokj2k Cheers, Ivo
Bug#984539: debian-security-support: dpkg hook should never fail
package: debian-security-support severity: serious Hi, In https://bugs.debian.org/974552 dpkg runs the debian-security-support hook in a situation where perl is broken. This makes the hook fail, and aborts dpkg and apt, leaving the system in a very bad state. More on the exact situation below. Even though debian-security-support clearly isn't at fault here, the debian-security-support should never cause dpkg/apt to fail. Based on that, I think it might be good if debian-security-support would make 2 changes: - in /etc/dpkg/dpkg.cfg.d/debian-security-support, make sure the hook can never fail (eg by adding '|| /bin/true' in the appropriate place) - in /usr/share/debian-security-support/check-support-status.hook check if perl is functional before trying to do anything. If perl is not functional, just do nothing (and exit successfully). This would be somewhat similar to what glibc is doing here: https://salsa.debian.org/glibc-team/glibc/commit/04373a4e6df6b3c61fa4bbf78f8409aadc7d2753 Longer term, it might be useful to investigate whether is might make more sense to use an apt hook instead of a dpkg hook. Ideally this would allow the user to abort the installation before the unsupported package is installed, instead of getting a notice afterwards. Obviously this should be done in a way that doesn't cause apt to abort in the middle of an upgrade. I don't know if apt currently provides an appropriate hook to do this. Some background on the issue in #974552: In buster, libcrypt.so is shipped by libc6. In bullseye, it is shipped by libcrypt1. During the upgrade from buster to bullseye, it seems a situation can occur that causes the new libc6 (without libcrypt.so) to be unpacked before the new libcrypt. At that point, libcrypt.so is missing, so anything that needs it (like perl) is broken. Fixing this issue is what #974552 is about. However, it seems that in some upgrades, the debian-security-support hook is started in such a situation where libcrypt.so is missing. The standard assumption that perl should be functional at all times is broken by this. Clearly, this is not caused by debian-security-support and this should be fixed. Furthermore, there is the risk that maintainer scripts might hit the same issue, even if debian-security-support doesn't. However, it's unclear if the situation can be avoided in all scenarios. If a situation occurs where the debian-security-support hook runs on a broken system, there's no point in trying to do something useful and failing. The best that can be done is making sure dpkg/apt can continue, hoping that the breakage will be fixed later on. Thanks, Ivo
Bug#972936: libgcc-s1 needs Breaks: libgcc1 (<< 1:10)
# clarify issue in 972936 retitle 972936 removal of libgcc-s1 breaks the whole system fixed 972936 10.2.0-16 # # purely cosmetic, as this specific issue is fixed severity 964477 serious thanks Hi, On Wed, Mar 03, 2021 at 11:31:07AM +0100, Matthias Klose wrote: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964477#69 > now claims this is gone with the removal of gcc-8 It seems there is some confusion between #972936 and #964477, as the bug log of #972936 contains some info that's only relevant for #964477. First, bug 972936: The issue as reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972936#5 was fixed in gcc-10 10.2.0-16 with the change suggested by Julian in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972936#24 "Mark libgcc-sN with XB-Important/Protected: yes. Addresses: #972936" I can reproduce the original issue when installing libgcc-s1 from bullseye from snapshot based on this link: deb [check-valid-until=no] https://snapshot.debian.org/archive/debian/20201012T00Z/ bullseye main When installing libgcc-s1 from current bullseye, apt is no longer willing to remove libgcc-s1 (without 'do as I say'). Now bug 964477: This bug can be reproduced based on Ryans script: On a buster system: apt-get install -y --no-install-recommends gcc-8 libc6-dev libreoffice Switch the sources.list to a bullseye snapshot from before the removal of gcc-8 (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964477#64) Then run apt-get -y dist-upgrade to get the error. When trying to upgrade to a current version of bullseye, the issue doesn't show up, because gcc-8 is no longer there. So it seems this issue was resolved with the removal of gcc-8 from testing. I also can confirm that trying to upgrade to a snapshot of bullseye that has gcc-8 works with the packages from Ryan based on this sources entry: deb http://download.opensuse.org/repositories/home:/rpavlik:/bullseye-fix/Debian_Testing/ ./ (which needs https://salsa.debian.org/rpavlik/gcc-upgrade-testcase/-/blob/main/workaround.asc to be accepted by apt) Even though the issue from 964477 is fixed, it's possible that there are similar issue (not related to gcc-8) we are currently unaware of. So it might still be useful to reintroduce the transitional packages, as suggested by David in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964477#41 Finally, I think 964477 should be marked as serious (even though that's purely cosmetic now, as the bug is fixed). Cheers, Ivo
Bug#983010: mdocml breaks debiman autopkgtest: different output
Control: reassign -1 debiman 0.0~git20200217.fc82521-1 Hi, On Thu, Feb 18, 2021 at 07:31:32AM +0100, Paul Gevers wrote: > With a recent upload of mdocml the autopkgtest of debiman fails in > testing when that autopkgtest is run with the binary packages of mdocml > from unstable. It passes when run with only packages from testing. In > tabular form: [...] > === CONT TestToHTML/i3lock > convert_test.go:92: unexpected conversion result: (diff from want → > got): > --- /tmp/debiman-8492488252021-02-18 04:13:33.034473409 + > +++ /tmp/debiman-3766921622021-02-18 04:13:33.034473409 + > @@ -7,67 +7,76 @@ > > > > - > - > + > + > + [...] Hard-coding the exact html output of a dependency that generates html, and expecting that not to change doesn't seem like a robust way to test it functionality, so I think it's clear that the bug is in the autopkgtest of debiman. It's perfectly acceptable for mdocml to generate different html output to represent the data (whether the upload of the new upstream version should have happened during the soft freeze is a different matter, but that's unrelated to this bug). Testing that the html is valid, and contains certain parts of the input might be a more useful test. Cheers, Ivo
Bug#980686: ldc: FTBFS: dh_auto_configure: error: cd bootstrap-stage2
Hi Matthias, On 2/23/21 1:36 AM, Matthias Klumpp wrote: [...] I'll have a look at fixing that. Thanks for the quick fix! Ivo
Bug#980686: ldc: FTBFS: dh_auto_configure: error: cd bootstrap-stage2
Hi Matthias, On Wed, Jan 20, 2021 at 09:48:32PM +0100, Lucas Nussbaum wrote: > Source: ldc > Version: 1:1.24.0-1 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20210120 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. Are you aware of this bug? Looking at https://tests.reproducible-builds.org/debian/history/ldc.html it seems the change that triggered it must have been uploaded fairly recently (probaby in January). Thanks, Ivo
Bug#983018: qdbus: Needs package downgrade from Buster to Bullseye (missing epoch in transitional package)
clone -1 -2 reassign -2 ftp.debian.org retitle -2 dak: version checks for binaries not enforced when binary changes from any to all severity -2 normal tags -2 - pending Hi, On Thu, Feb 18, 2021 at 09:08:46AM +0100, Axel Beckert wrote: > Hi, > > on one system I wondered why qdbus is still on Qt4. Then I noticed that > the version of the Qt4 qdbus package from Buster is higher (!) than the > version of the Qt5 qdbus package in Bullseye: > > $ apt-cache policy qdbus > qdbus: > Installed: 4:4.8.7+dfsg-18+deb10u1 > Candidate: 4:4.8.7+dfsg-18+deb10u1 > Version table: > *** 4:4.8.7+dfsg-20 100 > 100 /var/lib/dpkg/status > 5.15.2-3 990 > 900 https://debian.ethz.ch/debian bullseye/main i386 Packages The current situation: qdbus | 5.15.2-3 | testing | all qdbus | 5.15.2-3 | unstable | all qdbus | 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1 | oldoldstable | amd64, armel, armhf, i386 qdbus | 4:4.8.7+dfsg-11 | oldstable| amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x qdbus | 4:4.8.7+dfsg-18+deb10u1 | stable | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x Normally, version checks should prevent an upload to unstable of a binary that has a lower version than in stable or testing. However, this is checked per architecture, and it seems the check wasn't done because the binary changed from arch: any to arch: all at the same time. This case should probably be checked in dak as well (obviously also for arch: all to arch: any). Cloning the bug to track the issue in dak. Cheers, Ivo
Bug#971129: shim-signed: FTBFS: build-dependency not installable: shim-unsigned (= 15+1533136590.3beb971-7)
Hi Steve, Thanks for the info. On Mon, Feb 15, 2021 at 12:43:33AM +, Steve McIntyre wrote: > >Could you clarify the timing for this, especially the timeline for getting > >the > >signature from Microsoft (as far as that can be predicted)? I'm trying to > >assess if this could become a blocker wrt the actual release. Is it an option > >to release with the current version of shim-signed (ie the one that's also in > >buster) if we don't get the signature in time? > > It's not really an option to release with the old shim at this point, > I'm afraid. That's good to know. I tagged this bug 'is-blocker', to make sure we keep an eye on it. > But there are newer processes in place around getting new > builds signed, so I'm not worrying too much here about delaying the > release. OK. That's encouraging :) > I expect to have things sorted soon. Make sure to let is know if you encounter any issues. Cheers, Ivo
Bug#971129: shim-signed: FTBFS: build-dependency not installable: shim-unsigned (= 15+1533136590.3beb971-7)
Control: tags 978521 pending
Hi Steve,
On Fri, Feb 12, 2021 at 01:35:52AM +, Steve McIntyre wrote:
> On Tue, Feb 09, 2021 at 04:26:02PM +0100, Ivo De Decker wrote:
> >Hi Steve,
> >
> >On Sun, Sep 27, 2020 at 08:39:53PM +0200, Lucas Nussbaum wrote:
> >> During a rebuild of all packages in sid, your package failed to build
> >> on amd64.
> >
> >[...]
> >
> >> > The following packages have unmet dependencies:
> >> > sbuild-build-depends-main-dummy : Depends: shim-unsigned (=
> >> > 15+1533136590.3beb971-7) but it is not going to be installed
> >
> >What is the status of shim(-signed) for bullseye?
> >
> >shim-unsigned has been changed, but there is no corresponding shim-signed
> >(yet). I assume a new signature from microsoft is needed. Or are there more
> >changes to shim-unsigned needed first?
>
> There are some other changes coming, not least switching compiler to
> gcc-10 now we've stabilised.
I'm tagging #978521 ("shim: non-standard gcc/g++ used for build (gcc-9)") as
pending to indicate that you're planning to switch to gcc-10.
> I'm working on new shim uploads at the
> moment, but there's a couple of upstream patches we'll need to take as
> well yet I think. It'll be coming soon, I promise.
Could you clarify the timing for this, especially the timeline for getting the
signature from Microsoft (as far as that can be predicted)? I'm trying to
assess if this could become a blocker wrt the actual release. Is it an option
to release with the current version of shim-signed (ie the one that's also in
buster) if we don't get the signature in time?
Cheers,
Ivo
Bug#981600: nghttp2: util_localtime_date test fails in arch-only build
Control: severity -1 important Hi, On Sun, Feb 07, 2021 at 09:12:53PM +0100, Helmut Grohne wrote: > On Sun, Feb 07, 2021 at 08:51:36PM +0100, Chris Hofstaedtler wrote: > > I'm just passing by, but a local rebuild with `sbuild -d unstable > > -j8 --no-arch-all` did not show this problem (on amd64). There has > > to be more to it. > > Thank you. I retried it to day (sbuild -d unstable --no-arch-all > nghttp2 on amd64) and it failed in the same way. I'm left puzzled what > could be different here. One aspect that certainly is not entirely usual > is that my chroot lives on a large tmpfs. Could that pose any problems? > > Any other details I could add to help better understand the issue? There was an upload of nghttp2 yesterday, which built fine on the buildds, so I'm downgrading this bug. Cheers, Ivo
Bug#982783: fonttools: not buildable on mipsel, mips64el due to circular dependency
package: src:fonttools version: 4.19.1-1 severity: serious tags: ftbfs Hi, The latest upload of fonttools cannot be autobuilt on mipsel and mips64el: https://buildd.debian.org/status/package.php?p=fonttools This is caused by the change from arch: all to arch: any, combined with the fact that fonttools transitively build-depends on itself via the build-dependency on python3-ufolib2. I'm pretty sure that the issue isn't specific to mipsel and mips64el, but it is related to the way dak handles arch: all binaries. Immediately after the upload, the old version was still available, and that was used to build on the other architectures. Those probably started before dinstall cleaned up the old version. If they wouldn't have been started this fast, the same issue would probably have occurred. Possible ways to fix this: - (temporarily) get rid of the build-dep on python3-ufolib2, to break the circular dependency. Once the build is done, the build-dep can be reintroduced - manually upload binaries for mipsel and mips64el. Once they are in unstable, a binNMU can be scheduled to rebuild them on the buildds. There are probably other ways. Cheers, Ivo
Bug#982684: subversion: FTBFS on armhf, mips64el: test failure
package: src:subversion version: 1.14.1-1 severity: serious tags: ftbfs Hi, The latest upload of subversion to unstable fails on armhf and mips64el: https://buildd.debian.org/status/package.php?p=subversion On the first try, it failed on mipsel as well. Maybe the failing test is unreliable? Cheers, Ivo
Bug#980583: ruby-coffee-rails: FTBFS: tests failed
Control: tags -1 patch
Hi,
On Wed, Jan 20, 2021 at 08:24:51PM +0100, Lucas Nussbaum wrote:
> > Failure:
> > AssetsTest#test_coffee-script.js_is_included_in_Sprockets_environment
> > [/<>/test/assets_test.rb:29]:
> > Expected /CoffeeScript\ Compiler/ to match
[long line truncated]
> > rails test test/assets_test.rb:25
Looking at the timing of the failure on
https://tests.reproducible-builds.org/debian/history/ruby-coffee-rails.html
I suspect this is triggered by the coffeescript upload.
This can be fixed by this obvious patch:
diff --git a/test/assets_test.rb b/test/assets_test.rb
index e125eac..9953a7c 100644
--- a/test/assets_test.rb
+++ b/test/assets_test.rb
@@ -26,7 +26,7 @@ class AssetsTest < ActiveSupport::TestCase
@app.assets["coffee-script"].write_to("#{tmp_path}/coffee-script.js")
assert_match "/lib/assets/javascripts/coffee-script.js.erb",
@app.assets["coffee-script"].pathname.to_s
-assert_match "CoffeeScript Compiler",
File.open("#{tmp_path}/coffee-script.js").read
+#assert_match "CoffeeScript Compiler",
File.open("#{tmp_path}/coffee-script.js").read
end
def tmp_path
It might be useful to replace the match with something else to detect
coffeescript.
Cheers,
Ivo
Bug#963319: ruby-em-synchrony: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity
Hi, On Fri, Feb 05, 2021 at 01:46:46PM +0100, Ivo De Decker wrote: > error: 'Access denied for user 'root'@'localhost'' > 2021-01-21 13:20:47 5 [Warning] Access denied for user 'root'@'localhost' > ERROR 1698 (28000): Access denied for user 'root'@'localhost' Note that this seems very similar to #978251. As described in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978251#16 the issue is probably caused by running the tests under fakeroot. > It seems ruby-em-synchrony is only used as a build-dependency for > ruby-faraday. That build-dependency can be removed by disabling the > em-synchrony tests (and updating the coverage settings). Maybe that should be > done, to allow em-synchrony to be removed from bullseye? Cheers, Ivo
Bug#978251: ruby-mysql2: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity
Hi, On Sat, Dec 26, 2020 at 10:48:36PM +0100, Lucas Nussbaum wrote: > Source: ruby-mysql2 > Version: 0.5.3-1 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20201226 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > + cleanup > > + /usr/bin/mysqladmin --user=root --socket=/tmp/tmp.g8cXe135ad/mysql.sock > > shutdown > > 2020-12-26 15:17:41 9 [Warning] Access denied for user 'root'@'localhost' > > /usr/bin/mysqladmin: connect to server at 'localhost' failed > > error: 'Access denied for user 'root'@'localhost'' It looks like the tests don't work anymore under fakeroot. When trying to connect using mysqladmin under fakeroot, this fails. I tried connecting without fakeroot, which works. Looking at the timing of the failure on https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ruby-mysql2.html I suspect that this is triggered by mariadb 10.5. I'm not sure what needs to be changed to make it work under fakeroot. One option is to start mysqld with --skip-grant-tables to disable permission checks. This seems to work for many tests, but the tests that actually test permissions and expect 'permission denied' fail in that case. Maybe it works when doing a network connection and users with login/pw. Cheers, Ivo
Bug#919917: yui-compressor (2.4.8-2.1) fails to install on current sid
Control: severity -1 normal Hi Holger, On Wed, Jan 20, 2021 at 07:11:13PM +, Holger Levsen wrote: > quoting from > https://piuparts.debian.org/sid/fail/libjs-protoaculous_5+nmu1.log > (also attached) > > Setting up yui-compressor (2.4.8-2.1) ... > Setting up libjs-protoaculous (5+nmu1) ... > [warning] /usr/bin/yui-compressor: No java runtime was found > [warning] /usr/bin/yui-compressor: No JAVA_CMD set for run_java, falling > back to JAVA_CMD = java > readlink: missing operand > Try 'readlink --help' for more information. > /usr/bin/yui-compressor: 304: exec: java: not found > dpkg: error processing package libjs-protoaculous (--configure): >installed libjs-protoaculous package post-installation script subprocess > returned error exit status 127 > > Thus the severity raise. I'm pretty sure that this is caused by the circular dependency beween ca-certificates-java, default-jre-headless and openjdk-11-jre-headless, and isn't actually a bug in yui-compressor https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929685 Cheers, Ivo
Bug#975490: u-boot-sunxi: Booting the system got stuck after "Starting kernel ..."
Hi, On Mon, Jan 04, 2021 at 08:27:51PM -0800, Vagrant Cascadian wrote: > >> I'll test on a few of my systems to see if I can reproduce the issue. > > > > I can confirm similar behavior on a pinebook, although the kernel does > > boot and actually load, and eventually displays on the LCD display (if I > > "setenv console" from u-boot commandline). It even responds > > appropriately to ctrl-alt-delete, so it is not a completely hung > > kernel... > > With a locally built version of 2020.10+dfsg-2, I can no longer > reproduce this issue at all. > > Could you try with the new version? Testing/unstable now has version 2021.01+dfsg-2. Benedikt, could you try this version to see if the issue is still there? Thanks, Ivo
Bug#976045: bind9: flaky autopkgtest on ci.debian.net
Hi, On Mon, Dec 07, 2020 at 09:12:25AM +0100, Ondřej Surý wrote: >Hi Paul, >I am pretty sure the culprit is this upstream >issue: https://gitlab.isc.org/isc-projects/bind9/-/issues/2305 >So, the bug should resolve itself when BIND 9.16.10 is uploaded to the >archive. If not, I'll modify the autopkgtest. >Ondrej Testing now has 1:9.16.11-2. I retriggered the tests a number of times earlier today, and one of them failed: https://ci.debian.net/packages/b/bind9/testing/amd64/ https://ci.debian.net/data/autopkgtest/testing/amd64/b/bind9/10370897/log.gz Cheers, Ivo
Bug#971129: shim-signed: FTBFS: build-dependency not installable: shim-unsigned (= 15+1533136590.3beb971-7)
Hi Steve, On Sun, Sep 27, 2020 at 08:39:53PM +0200, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. [...] > > The following packages have unmet dependencies: > > sbuild-build-depends-main-dummy : Depends: shim-unsigned (= > > 15+1533136590.3beb971-7) but it is not going to be installed What is the status of shim(-signed) for bullseye? shim-unsigned has been changed, but there is no corresponding shim-signed (yet). I assume a new signature from microsoft is needed. Or are there more changes to shim-unsigned needed first? Cheers, Ivo
Bug#962485: Please revert CONFIG_MIPS_O32_FP64_SUPPORT change mipsel
Hi, On Mon, Jun 08, 2020 at 08:15:38PM +0300, Adrian Bunk wrote: > On Fri, May 29, 2020 at 11:03:14PM +0200, Aurelien Jarno wrote: > > On 2020-05-28 09:04, YunQiang Su wrote: > > > Adrian Bunk 于2020年5月21日周四 下午3:40写道： > > > > On Thu, May 21, 2020 at 06:41:34AM +0800, YunQiang Su wrote: > > > > > Adrian Bunk 于2020年5月21日周四 上午4:44写道： > > > > > > On Tue, May 19, 2020 at 11:43:30AM +0800, Shengjing Zhu wrote: > > > > > > > > > > > > > > FTR, after giving back golang-1.14 mipsel several times, it's > > > > > > > finally > > > > > > > built, by a longson builder. > > > > > > > So I guess it only occurs on octeon. Since the porterbox eller is > > > > > > > also > > > > > > > octeon, it also can't build any go program. > > > > > > > > > > > > On eller golang-1.14 fails to build both in sid and buster chroots. > > > > > > > > > > > > golang-1.11 also fails to build in a buster chroot with floating > > > > > > point > > > > > > test errors. > > > > > > > > > > > > golang-1.14 gets unbroken by GOMIPS=softfloat. > > > > > > > > > > > > The only kernel configuration change on eller in the buster point > > > > > > release is CONFIG_MIPS_O32_FP64_SUPPORT=y, everything observed would > > > > > > make sense if the problem is that golang-1.11 and golang-1.14 are > > > > > > not compatible with CONFIG_MIPS_O32_FP64_SUPPORT. > > > > > > > > > > It is just support O32_FP64. I don't expect it will have any effect. > > > > > Since currently, the toolchain/libraries are all FPXX. > > > > > > > > Only the gcc/binutils toolchain/libraries or also the Go toolchain? > > > > > > you are right. the current golang still output FP32 object... > > > So, we think that it is buggy. > > > > > > Since Loongson CPU has some strange behaviour, it even can work... > > > Let's try to patch golang to support FPXX or FP64. > > > > > > https://github.com/golang/go/issues/39289 > > > > That's probably a solution for bullseye/sid, however we can't backport > > such changes and rebuild the go world in buster. I therefore think that > > for buster the kernel change has to be reverted. > > What is clear at this point is that the kernel change should be reverted > in buster since it causes a regression (including build failures on > buildds). I am cloning this bug for a revert in the kernel of > https://salsa.debian.org/kernel-team/linux/-/commit/947fbc66183d022fe3de7871dfb262d2b87af826 > > I am marking the version in bullseye as found since we might run into > the same problem again when buster DSAs will be built on machines > running the bullseye kernel after the release of bullseye. It might be > possible to mitigate this problem (e.g. in the kernel or by keeping some > buildd running with the buster kernel), but without an open bug this > issue might get forgotten and then resurface after the bullseye release. Could the mips porters comment on this? Given that we're close to the release of bullseye, I'm not convinced it's a good idea to change this now. Cheers, Ivo
Bug#978388: malcontent: FTBFS: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below
Hi Laurent, On Sat, Dec 26, 2020 at 11:03:41PM +0100, Lucas Nussbaum wrote: > > dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols > > file: see diff output below > > dpkg-gensymbols: warning: debian/libmalcontent-ui-0-0/DEBIAN/symbols > > doesn't match completely debian/libmalcontent-ui-0-0.symbols > > --- debian/libmalcontent-ui-0-0.symbols > > (libmalcontent-ui-0-0_0.10.0-1_amd64) > > +++ dpkg-gensymbolskr7dUJ 2020-12-26 18:40:25.105202461 + > > @@ -1,11 +1,11 @@ > > libmalcontent-ui-0.so.0 libmalcontent-ui-0-0 #MINVER# > > * Build-Depends-Package: libmalcontent-ui-0-dev > > - as_content_rating_id_csm_age_to_value@Base 0.6.0 > > - gs_content_rating_system_to_str@Base 0.6.0 > > - gs_utils_content_rating_age_to_str@Base 0.6.0 > > - gs_utils_content_rating_get_ages@Base 0.6.0 > > - gs_utils_content_rating_get_values@Base 0.6.0 > > - gs_utils_content_rating_system_from_locale@Base 0.6.0 > > +#MISSING: 0.10.0-1# as_content_rating_id_csm_age_to_value@Base 0.6.0 > > +#MISSING: 0.10.0-1# gs_content_rating_system_to_str@Base 0.6.0 > > +#MISSING: 0.10.0-1# gs_utils_content_rating_age_to_str@Base 0.6.0 > > +#MISSING: 0.10.0-1# gs_utils_content_rating_get_ages@Base 0.6.0 > > +#MISSING: 0.10.0-1# gs_utils_content_rating_get_values@Base 0.6.0 > > +#MISSING: 0.10.0-1# gs_utils_content_rating_system_from_locale@Base 0.6.0 > > mct_restrict_applications_dialog_build_app_filter@Base 0.6.0 > > mct_restrict_applications_dialog_get_app_filter@Base 0.6.0 > > mct_restrict_applications_dialog_get_type@Base 0.6.0 > > dh_makeshlibs: error: failing due to earlier errors > > make: *** [debian/rules:7: binary] Error 25 Could you take a look at this, to fix the build? Thanks! Ivo
Bug#969072: dahdi-tools FTBFS on armel/mipsel/hppa/powerpc: pre-grohtml: fatal error: cannot create temporary file: File exists
Control: tags -1 patch pending Hi Colin, On 2/8/21 11:56 PM, Colin Watson wrote: On Mon, Feb 08, 2021 at 07:17:57PM +0100, Ivo De Decker wrote: On Sat, Nov 21, 2020 at 07:06:02PM +0200, Tzafrir Cohen wrote: On abel in a armel chroot the issue is reproduced by running: man -Thtml even on an empty man page. Right now you can try: $ schroot -r -c session:tzafrir-dahdi-tools -- man -Thtml ~tzafrir/test.8 >/dev/null pre-grohtml: fatal error: cannot create temporary file: File exists man: command exited with status 1: /usr/lib/man-db/zsoelim | /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e UTF-8 | tbl | groff -mandoc -Thtml Not reproduced in a armhf chroot there or in a qemu armel chroot on my laptop. When running this with MAN_DISABLE_SECCOMP=1, the issue goes away, so it's caused by the seccomp filter man is setting up when running groff. I guess some system call must be (slightly) different on some of the architectures, and it's not allowed by the filter. So it seems this is a bug in man-db. Ah yes, sorry for missing this. Running strace on abel, it looks like clock_gettime64 is the offending syscall, which means that https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=7315a9475d8fa37af49e9e7ed11e1534f23ef70b should fix this; I've tested that on abel and it seems to do the job. The upstream changes since 2.9.3 are not otherwise especially intrusive (mostly new translations), so I think I'll deal with this by doing a new upstream release and packaging that. I'm working on that now. Thanks for that! I was wondering if there is a way to make it clear that the seccomp filter has actually blocked something, perhaps by showing a warning. That would make it easier to debug something like this in the future. Maybe that should be a separate (wishlist) bug. Cheers, Ivo
Bug#969072: dahdi-tools FTBFS on armel/mipsel/hppa/powerpc: pre-grohtml: fatal error: cannot create temporary file: File exists
reassign -1 man-db retite -1 man: seccomp filter breaks groff on armel/mipsel/hppa/powerpc Hi, On Sat, Nov 21, 2020 at 07:06:02PM +0200, Tzafrir Cohen wrote: >Hi, >On abel in a armel chroot the issue is reproduced by running: > man -Thtml >even on an empty man page. > >Right now you can try: > >$ schroot -r -c session:tzafrir-dahdi-tools -- man -Thtml ~tzafrir/test.8 >>/dev/null >pre-grohtml: fatal error: cannot create temporary file: File exists >man: command exited with status 1: /usr/lib/man-db/zsoelim | >/usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e >UTF-8 | tbl | groff -mandoc -Thtml > >Not reproduced in a armhf chroot there or in a qemu armel chroot on my >laptop. When running this with MAN_DISABLE_SECCOMP=1, the issue goes away, so it's caused by the seccomp filter man is setting up when running groff. I guess some system call must be (slightly) different on some of the architectures, and it's not allowed by the filter. So it seems this is a bug in man-db. Also, note that during package builds, the seccomp filter could be disabled using the env variable, as the build doesn't contain untrusted input. However, that would only be a workaround for the actual issue. This bug was originally filed as serious, because it caused an FTBFS. As there is a workaround for that, I wonder if it should be downgraded. Colin, what do you think? Obviously, it would be nice to have a fix for bullseye. Cheers, Ivo
Bug#976354: git - tests fail with dash
Hi Bastian, On Thu, Dec 03, 2020 at 10:14:10PM +0100, Bastian Blank wrote: > Package: git > Version: 1:2.29.2-1 > Severity: serious > > Some of the tests fail with dash, which is the default /bin/sh in > Debian. Why did you file this bug as serious? As noted in #972457, the build seems to succeed (my tests where done with /bin/sh pointing to dash). Cheers, Ivo
Bug#972457: FTBFS - not ok 3 - progress display breaks long lines #1
Control: severity -1 important Control: tags -1 - moreinfo unreproducible Hi Bastian, On Mon, Feb 08, 2021 at 02:22:31PM +0100, Bastian Blank wrote: > On Mon, Feb 08, 2021 at 10:12:14AM +0100, Ivo De Decker wrote: > > I tried a rebuild of git 1:2.28.0-1, 1:2.29.2-1 and 1:2.30.0-1 in an > > unstable > > chroot on barriere.debian.org, and they all succeeded. It also seems the > > builds on the buildds succeeded for all the versions recently uploaded. > > The problem only shows if > - the tests run in verbose mode and > - the tests directly write output to a terminal. > > In this case the tested git command reads the size of the output and > adjustd itself. Also in this case the test output is colored. > > So plain dpkg-buildpackage is affected, but buildds are not as they > redirect anything to a file. Thanks for the clarification. > > Can you still reproduce this issue? And are you able to reproduce it on a > > porterbox? > > I can't any longer. Somewhere there showed up a "make -O", which forces > all calls to run with output redirected to a file. So it works around > the problem right now. OK. As the package builds fine, I'm downgrading the bug. Cheers, Ivo
Bug#972457: FTBFS - not ok 3 - progress display breaks long lines #1
Control: tags -1 moreinfo unreproducible Hi Bastian, On Sun, Oct 18, 2020 at 08:46:22PM +0200, Bastian Blank wrote: > Subject: FTBFS - not ok 3 - progress display breaks long lines #1 > > Package: git > Version: 1:2.28.0-1 > Severity: serious > > A rebuild of git 1:2.28.0-1 reports test failures and FTBFS on both unstable > and stable. I tried a rebuild of git 1:2.28.0-1, 1:2.29.2-1 and 1:2.30.0-1 in an unstable chroot on barriere.debian.org, and they all succeeded. It also seems the builds on the buildds succeeded for all the versions recently uploaded. Can you still reproduce this issue? And are you able to reproduce it on a porterbox? Cheers, Ivo
Bug#973168: pylint: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.9 3.8" returned exit code 13
Control: tags -1 patch Hi, On Wed, Oct 28, 2020 at 01:28:26AM -0400, Sandro Tosi wrote: > forwarded 973168 https://github.com/PyCQA/pylint/issues/3895 > thanks It seems upstream adjusted the tests to work with python 3.9. Cheers, Ivo
Bug#941867: qt-gstreamer FTBFS: error: invalid cast from type ‘const CapsPtr’ to type ‘GstMiniObject*’
Control: tags -1 patch
On Mon, Dec 21, 2020 at 10:03:53PM +0100, Paul Gevers wrote:
> On Sun, 6 Oct 2019 23:12:00 +0200 Helmut Grohne wrote:
> > qt-gstreamer fails to build from source in unstable on amd64. A build in
> > sbuild ends with:
>
> The reproducibility rebuilds [1] show this happening on all their
> architectures. The bullseye freeze is drawing near. Can this bug please
> be looked into soon?
Arch has 2 patches (in attach) to fix the build with newer versions of
gstreamer. I confirmed that they make the build succeed.
https://github.com/archlinux/svntogit-packages/commits/packages/qt-gstreamer/trunk
Cheers,
Ivo
>From 6e4fb2f3fcfb453c5522c66457ac5ed8c3b1b05c Mon Sep 17 00:00:00 2001
From: George Kiagiadakis
Date: Sat, 7 Sep 2019 10:49:38 +0300
Subject: QGst/caps: compilation fix from
https://bugs.kde.org/show_bug.cgi?id=406676#c2
Because the macro version of gst_caps_copy() confuses the C++ compiler
---
src/QGst/caps.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/QGst/caps.cpp b/src/QGst/caps.cpp
index 3824d82..a15b701 100644
--- a/src/QGst/caps.cpp
+++ b/src/QGst/caps.cpp
@@ -54,7 +54,8 @@ QString Caps::toString() const
void Caps::append(const CapsPtr & caps2)
{
-gst_caps_append(object(), gst_caps_copy(caps2));
+const GstCaps * caps2ptr = caps2;
+gst_caps_append(object(), gst_caps_copy(caps2ptr));
}
CapsPtr Caps::merge(CapsPtr & caps2)
--
cgit v1.2.1
diff --git a/src/QGst/event.cpp b/src/QGst/event.cpp
index 0530f0b..260a909 100644
--- a/src/QGst/event.cpp
+++ b/src/QGst/event.cpp
@@ -125,7 +125,7 @@ Segment SegmentEvent::segment() const
//
TagEventPtr TagEvent::create(const TagList & taglist)
{
-GstEvent * e = gst_event_new_tag(gst_tag_list_copy(taglist));
+GstEvent * e = gst_event_new_tag(gst_tag_list_copy());
return TagEventPtr::wrap(e, false);
}
diff --git a/src/QGst/message.cpp b/src/QGst/message.cpp
index ae845cc..1044b88 100644
--- a/src/QGst/message.cpp
+++ b/src/QGst/message.cpp
@@ -157,7 +157,7 @@ QString InfoMessage::debugMessage() const
TagMessagePtr TagMessage::create(const ObjectPtr & source, const TagList & taglist)
{
-GstMessage *m = gst_message_new_tag(source, gst_tag_list_copy(taglist));
+GstMessage *m = gst_message_new_tag(source, gst_tag_list_copy());
return TagMessagePtr::wrap(m, false);
}
Bug#976539: tagging 976539
Hi, On Sun, Dec 27, 2020 at 04:51:02AM +0100, أحمد المحمودي wrote: > From: أحمد المحمودي > To: cont...@bugs.debian.org > Subject: tagging 976539 > > tags 976539 + fixed-upstream > thanks Upstream fixed this by generating the pdfs using dblatex: https://github.com/rkd77/elinks/pull/64/commits/9e08ea995a0353ae78470c344b68fcefa38b64b3 Ahmed, I noticed you are working on a new upstream version in git. However, it FTBFS in the ci. Would you consider doing an upload based on the current version, with only the pdf fix? Or do you prefer an NMU? Thanks! Ivo
Bug#950094: ipywidgets FTBFS with node-semver 7.1.1-2
Control: tags -1 - patch Hi, On Sat, Feb 06, 2021 at 06:57:32PM +, Gordon Ball wrote: > > This is fixed in git: > > > > https://salsa.debian.org/python-team/packages/ipywidgets/-/commit/23daf45a127b3febe25ecefdbb7148b0f5049990 > > > > Gordon, are you planning to upload this soon? The soft freeze is pretty > > close > > now. > > > > The FTBFS bugs are fixed, in the sense that I have redone the build > system reflecting all the changes that have happened to the parent > libraries, and the basic build sequence runs without error. However, the > resultant object doesn't actually work (yet). Oh. In that case, I'll remove the patch tag, because the (current) patch doesn't actually work correctly. > I'll upload it iff I can get something working before the freeze dates. OK, thanks for you work on this. If this doesn't work out, please send an update to the bug. Cheers, Ivo
Bug#973135: Bug#973070: libsis-base-java: FTBFS: Could not delete the directory targets/unit-test-wd/ch.syst
Hi, On Thu, Oct 29, 2020 at 03:24:29PM +0100, Markus Koschany wrote: > Am 29.10.20 um 15:11 schrieb Andreas Tille: > > Hi, > > > > here is a suggested patch for commons-io that would prevent making the > > test in libsis-base-java fail. > > It seems this is a six year old unresolved upstream bug. > > https://issues.apache.org/jira/browse/IO-449 > > This should be fixed upstream in my opinion and not only in Debian. Other > projects may rely exactly on that behavior. Given that there is no clear consensus about what the exact behaviour should be, I guess it's probably best to disable this test for now. I can confirm that just commenting out the 2 tests in src/test/java/org/codehaus/plexus/components/io/attributes/SymlinkUtilsTest.java fixes the build. As a side node: it seems that some of the builds succeed in the reproducible-builds tests, while others do not. So the issue doesn't show up in all cases. Maybe it's related to the type of filesystem used. https://tests.reproducible-builds.org/debian/history/plexus-io.html Cheers, Ivo
Bug#950094: ipywidgets FTBFS with node-semver 7.1.1-2
Control: tags -1 patch Hi, On Tue, Jan 28, 2020 at 11:43:47PM +0200, Adrian Bunk wrote: > Source: ipywidgets > Version: 6.0.0-6 > Severity: serious > Tags: ftbfs This is fixed in git: https://salsa.debian.org/python-team/packages/ipywidgets/-/commit/23daf45a127b3febe25ecefdbb7148b0f5049990 Gordon, are you planning to upload this soon? The soft freeze is pretty close now. Thanks! Ivo
Bug#946882: blk-availability.service: may fail or unmount filesystems too soon
Control: tags -1 patch Control: retitle -1 blkdeactive hardcodes wrong path to sort On Mon, Dec 16, 2019 at 04:38:45PM -0800, Rob Leslie wrote: > On systems upgraded from stretch and without the usrmerge package installed, > /sbin/blkdeactivate (ExecStop= of blk-availability.service) gives the > following error during system shutdown: > > blkdeactivate[12003]: /sbin/blkdeactivate: line 345: /bin/sort: No such > file or directory It seems blkdeactive hardcodes /bin/sort as path to sort, while the correct path to sort is /usr/bin/sort (which is different on non-usrmerged systems). Obvious patch to fix this attached. Cheers, Ivo diff -Nur lvm2_2.03.11-2/scripts/blkdeactivate.sh.in lvm2_2.03.11-2i/scripts/blkdeactivate.sh.in --- lvm2_2.03.11-2/scripts/blkdeactivate.sh.in 2021-01-08 09:10:11.0 + +++ lvm2_2.03.11-2i/scripts/blkdeactivate.sh.in 2021-02-05 23:54:56.249130804 + @@ -60,7 +60,7 @@ LSBLK="/bin/lsblk -r --noheadings -o TYPE,KNAME,NAME,MOUNTPOINT" LSBLK_VARS="local devtype local kname local name local mnt" LSBLK_READ="read -r devtype kname name mnt" -SORT_MNT="/bin/sort -r -u -k 4" +SORT_MNT="/usr/bin/sort -r -u -k 4" # Do not show tool errors by default (only done/skipping summary # message provided by this script) and no verbose mode by default.
Bug#963319: ruby-em-synchrony: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity
Hi, On Sun, Jun 21, 2020 at 10:07:35PM +0200, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. [...] > > E: Build killed with signal TERM after 150 minutes of inactivity In my tests, it fails with a different error. This error is also present in this log: https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/ruby-em-synchrony_1.0.5-3.rbuild.log.gz ERROR: 1356 View 'mysql.user' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them 2021-01-21 13:20:44 0 [Note] /usr/sbin/mysqld: ready for connections. Version: '10.5.8-MariaDB-3' socket: '/tmp/tmp.obHTfob6Rp/mysql.sock' port: 0 Debian buildd-unstable 2021-01-21 13:20:47 4 [Warning] Access denied for user 'root'@'localhost' /usr/bin/mysqladmin: connect to server at 'localhost' failed error: 'Access denied for user 'root'@'localhost'' 2021-01-21 13:20:47 5 [Warning] Access denied for user 'root'@'localhost' ERROR 1698 (28000): Access denied for user 'root'@'localhost' rake aborted! Command failed with status (1): [./debian/start_services_and_run.sh ruby2.7...] /build/1st/ruby-em-synchrony-1.0.5/debian/ruby-tests.rake:5:in `block in ' /usr/share/rubygems-integration/all/gems/rake-13.0.1/exe/rake:27:in `' Tasks: TOP => default (See full trace by running task with --trace) ERROR: Test "ruby2.7" failed. Exiting. This also leaves running mysqld and memcached processes. These tests should be fixed (or disabled) to fix the FTBFS. It seems ruby-em-synchrony is only used as a build-dependency for ruby-faraday. That build-dependency can be removed by disabling the em-synchrony tests (and updating the coverage settings). Maybe that should be done, to allow em-synchrony to be removed from bullseye? Cheers, Ivo
Bug#976328: src:numad: invalid maintainer address
Control: tags -1 patch Hi gustavo, On Thu, Dec 03, 2020 at 12:20:34PM +0100, Ansgar wrote: > > This message was created automatically by mail delivery software. > > > > A message that you sent could not be delivered to one or more of its > > recipients. This is a permanent error. The following address(es) > > failed: > > > > deb...@jrms.com.ar > > Unrouteable address > I noticed you fixed this in git. Are you planning to do an upload soon? Thanks, Ivo
Bug#957527: mdocml: ftbfs with GCC-10
Control: tags -1 patch
Hi,
The build of mdocml has 2 issues:
> ./configure --build=x86_64-linux-gnu --prefix=/usr
> --includedir=\${prefix}/include --mandir=\${prefix}/share/man
> --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
> --disable-option-checking --disable-silent-rules
> --libdir=\${prefix}/lib/x86_64-linux-gnu
> --libexecdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run
> --disable-maintainer-mode --disable-dependency-tracking
> file config.log: writing...
> make: echo: No such file or directory
> make: *** [/tmp/GmjayNyT:2: all] Error 127
Caused by this line in configure:
CC=`printf "all:\\n\\t@echo \\\$(CC)\\n" | env -i make -sf -`
This doesn't work anymore with the new make. Just replacing it with 'CC=gcc'
fixes this.
On Fri, Apr 17, 2020 at 11:05:52AM +, Matthias Klose wrote:
[...]
> cc -o soelim -Wl,-z,relro -Wl,-z,now soelim.o compat_err.o compat_getline.o
> compat_progname.o compat_reallocarray.o compat_stringlist.o
> /usr/bin/ld: compat_getline.o:./compat_getline.c:5: multiple definition of
> `dummy'; compat_err.o:./compat_err.c:5: first defined here
> /usr/bin/ld: compat_reallocarray.o:./compat_reallocarray.c:5: multiple
> definition of `dummy'; compat_err.o:./compat_err.c:5: first defined here
> collect2: error: ld returned 1 exit status
Many files seem to define the (unused) int dummy. These multiple definitions
aren't allowed anymore with gcc 10. Just removing them fixes this.
The attached patch does both and fixes the FTBFS.
Thanks,
Ivo
--- mdocml-1.14.4.orig/compat_err.c
+++ mdocml-1.14.4/compat_err.c
@@ -2,7 +2,7 @@
#if HAVE_ERR
-int dummy;
+//int dummy;
#else
--- mdocml-1.14.4.orig/compat_fts.c
+++ mdocml-1.14.4/compat_fts.c
@@ -2,7 +2,7 @@
#if HAVE_FTS
-int dummy;
+//int dummy;
#else
--- mdocml-1.14.4.orig/compat_getline.c
+++ mdocml-1.14.4/compat_getline.c
@@ -2,7 +2,7 @@
#if HAVE_GETLINE
-int dummy;
+//int dummy;
#else
--- mdocml-1.14.4.orig/compat_getsubopt.c
+++ mdocml-1.14.4/compat_getsubopt.c
@@ -2,7 +2,7 @@
#if HAVE_GETSUBOPT
-int dummy;
+//int dummy;
#else
--- mdocml-1.14.4.orig/compat_isblank.c
+++ mdocml-1.14.4/compat_isblank.c
@@ -2,7 +2,7 @@
#if HAVE_ISBLANK
-int dummy;
+//int dummy;
#else
--- mdocml-1.14.4.orig/compat_mkdtemp.c
+++ mdocml-1.14.4/compat_mkdtemp.c
@@ -2,7 +2,7 @@
#if HAVE_MKDTEMP
-int dummy;
+//int dummy;
#else
--- mdocml-1.14.4.orig/compat_ohash.c
+++ mdocml-1.14.4/compat_ohash.c
@@ -2,7 +2,7 @@
#if HAVE_OHASH
-int dummy;
+//int dummy;
#else
--- mdocml-1.14.4.orig/compat_progname.c
+++ mdocml-1.14.4/compat_progname.c
@@ -2,7 +2,7 @@
#if HAVE_PROGNAME
-int dummy;
+//int dummy;
#else
--- mdocml-1.14.4.orig/compat_reallocarray.c
+++ mdocml-1.14.4/compat_reallocarray.c
@@ -2,7 +2,7 @@
#if HAVE_REALLOCARRAY
-int dummy;
+//int dummy;
#else
--- mdocml-1.14.4.orig/compat_recallocarray.c
+++ mdocml-1.14.4/compat_recallocarray.c
@@ -2,7 +2,7 @@
#if HAVE_RECALLOCARRAY
-int dummy;
+//int dummy;
#else
--- mdocml-1.14.4.orig/compat_strcasestr.c
+++ mdocml-1.14.4/compat_strcasestr.c
@@ -2,7 +2,7 @@
#if HAVE_STRCASESTR
-int dummy;
+//int dummy;
#else
--- mdocml-1.14.4.orig/compat_stringlist.c
+++ mdocml-1.14.4/compat_stringlist.c
@@ -2,7 +2,7 @@
#if HAVE_STRINGLIST
-int dummy;
+//int dummy;
#else
--- mdocml-1.14.4.orig/compat_strlcat.c
+++ mdocml-1.14.4/compat_strlcat.c
@@ -2,7 +2,7 @@
#if HAVE_STRLCAT
-int dummy;
+//int dummy;
#else
--- mdocml-1.14.4.orig/compat_strlcpy.c
+++ mdocml-1.14.4/compat_strlcpy.c
@@ -2,7 +2,7 @@
#if HAVE_STRLCPY
-int dummy;
+//int dummy;
#else
--- mdocml-1.14.4.orig/compat_strndup.c
+++ mdocml-1.14.4/compat_strndup.c
@@ -2,7 +2,7 @@
#if HAVE_STRNDUP
-int dummy;
+//int dummy;
#else
--- mdocml-1.14.4.orig/compat_strsep.c
+++ mdocml-1.14.4/compat_strsep.c
@@ -2,7 +2,7 @@
#if HAVE_STRSEP
-int dummy;
+//int dummy;
#else
--- mdocml-1.14.4.orig/compat_strtonum.c
+++ mdocml-1.14.4/compat_strtonum.c
@@ -2,7 +2,7 @@
#if HAVE_STRTONUM
-int dummy;
+//int dummy;
#else
--- mdocml-1.14.4.orig/compat_vasprintf.c
+++ mdocml-1.14.4/compat_vasprintf.c
@@ -2,7 +2,7 @@
#if HAVE_VASPRINTF
-int dummy;
+//int dummy;
#else
--- mdocml-1.14.4.orig/configure
+++ mdocml-1.14.4/configure
@@ -40,7 +40,7 @@ MANPATH_DEFAULT="/usr/share/man:/usr/X11
OSNAME=
UTF8_LOCALE=
-CC=`printf "all:\\n\\t@echo \\\$(CC)\\n" | env -i make -sf -`
+CC=gcc
CFLAGS=
LDADD=
LDFLAGS=
Bug#981430: RM: arduino [all] -- ROM; arduino-core abandoned, melted into arduino
Hi, On Mon, Feb 01, 2021 at 08:07:02PM +0100, Carsten Schoenert wrote: > Am 01.02.21 um 19:33 schrieb Ivo De Decker: > > There are 2 packages that depend on arduino-core: > > > > Output from dak rm: > > > > Checking reverse dependencies... > > # Broken Depends: > > arduino-mighty-1284p: arduino-mighty-1284p > > arduino-mk: arduino-mk > > > > Dependency problem found. > > the package arduino-mighty-1284p got fixed about a hour ago by myon. Nice :) > For arduino-mk, I reassigned #981300 which was originally opened against > arduino. > > > I don't know if these still work with the new arduino. If so, they will need > > to be updated to have the right dependency. Otherwise, they will have to be > > removed (at least from testing), as they would become uninstallable if > > arduino-core goes away. > > That's possible true, but we are down to one package that would get > uninstallable right now. Packages are generally not removed by ftp-master if there are still reverse dependencies in unstable, unless you explicitly clarify why you think it would be best to do so anyway. If you think that is the way to go, feel free to remove the moreinfo tag from this bug. > > However, given the timing of the freeze, it might be better to reintroduce > > arduino-core as a transitional package, and deal with the removal after the > > bullseye release. > > The package arduino has already that Provides so there must be something > not working correctly then. If arduino-mk is updated we could also drop > that non needed Provides line too. It seems the depends is versioned (arduino-core (>= 1:1.0+dfsg-8)). An unversioned provides doesn't satisfy a versioned dependency. Apart from that, I don't know if the dak rm dependency checking correctly handles provides. > Any way, looking at the reassigned bug report #981300 there is movement > from Simon John to get the package fixed. So I expect that the potential > uninstall ability will go away soon. OK :) > If arduino will migrate automatically, if the one outstanding package > will get fixed, then I'm fine to wait a bit longer. OK. > I see the following info on the tracker site for arduino > > > Issues preventing migration: > > missing build on all > > arch:all not built yet, autopkgtest delayed > > So I was assuming that any old all cruft is around and that's why I > created this report here. That is correct. You'll need to remove the moreinfo tag from this bug to get it removed. If the fix for arduino-mk is coming soon, it might be best to wait for that. > I also expect arduino will still not migrate > after removing the old all package in unstable due breakage of the > version from arduino-mk in testing. That's also correct. Note that I just pinged #976930 to reset the autoremoval counter, to avoid getting arduino removed over this in a few days. If arduino-mk isn't fixed, it will need to be removed from testing before arduino can migrate. But as you noted in https://bugs.debian.org/981300#45, it can just be fixed by changing that dependency, so that's probably a more elegant way to fix this. Thanks, Ivo
Bug#981430: RM: arduino [all] -- ROM; arduino-core abandoned, melted into arduino
Control: tags -1 moreinfo Hi, On Sun, Jan 31, 2021 at 07:06:13AM +0100, Carsten Schoenert wrote: > the arduino package got a long outstanding overhaul and is now back in > Debian with the most recent version. Thanks for accepting the new > package dependencies to make this possible. > > We now have the situation that britney wont let the new upload migrate > to testing as it thinks the all architecture isn't built yet. > > https://tracker.debian.org/pkg/arduino > > The root for this is the old binary package structure, the old package > of arduino has Architecture 'all' but is now containing architectures > that are platform depended. > So no 'all' based packages for arduino are now built anymore. > > Could you please remove any old cruft of arduino in unstable so the > packages can migrate to testing? There are 2 packages that depend on arduino-core: Output from dak rm: Checking reverse dependencies... # Broken Depends: arduino-mighty-1284p: arduino-mighty-1284p arduino-mk: arduino-mk Dependency problem found. I don't know if these still work with the new arduino. If so, they will need to be updated to have the right dependency. Otherwise, they will have to be removed (at least from testing), as they would become uninstallable if arduino-core goes away. However, given the timing of the freeze, it might be better to reintroduce arduino-core as a transitional package, and deal with the removal after the bullseye release. Cheers, Ivo
Bug#981508: mercurial autopkgtest breaks with newer git
package: mercurial version: 5.6.1-1 severity: serious Hi, The mercurial autopkgtest fails with the latest git: https://ci.debian.net/data/autopkgtest/testing/amd64/m/mercurial/10134722/log.gz It seems the output of git changed in a way that the test didn't expect. I suspect this will be fixed by this upstream change: https://www.mercurial-scm.org/repo/hg/rev/88dfe1c279bb Cheers, Ivo
Bug#948739: gparted should not mask .mount units
Control: tags -1 -pending Hi, On Fri, Jan 29, 2021 at 08:56:01AM -0500, Phillip Susi wrote: > John Paul Adrian Glaubitz writes: > > > Hello! > > > > It looks like this particular issue has been fixed in gparted 1.2.0 which > > was just released a few days ago [1]: > > > >> - Don't try to mask non-existent Systemd \xe2\x97\x8f.service (#129, !64) > > > > Might be an idea to update gparted to version 1.2.0 before the Bullseye > > freeze > > which is coming in Mid-February [2]. > > Thanks... on it. This new upstream version doesn't remove the code masking the systemd units. It just changes it a little. So it doesn't fix this bug. I don't know if there's already an upstream bug describing the issue, but that might be needed to get the bug resolved upstream. Cheers, Ivo
Bug#981484: webext-exteditor: not compatible with current thunderbird
package: webext-exteditor version: 2.0.4-1 severity: serious Hi, Thunderbird 1:78.7.0-1 has 'Breaks: webext-exteditor (<= 2.0.4-1)', which means webext-exteditor doesn't work with it. Cheers, Ivo
Bug#981483: python3-extractor: fails to install "TabError: inconsistent use of tabs and spaces in indentation"
package: python3-extractor version: 1:0.6-8 severity: serious Hi, Piuparts detected an installation error in python3-extractor: Setting up python3.9 (3.9.1-3) ... Setting up python3 (3.9.1-1) ... Setting up python3-extractor (1:0.6-8) ... Sorry: TabError: inconsistent use of tabs and spaces in indentation (extractor.py, line 82) dpkg: error processing package python3-extractor (--configure): installed python3-extractor package post-installation script subprocess returned error exit status 1 Processing triggers for libc-bin (2.31-9) ... Errors were encountered while processing: python3-extractor E: Sub-process /usr/bin/dpkg returned an error code (1) https://piuparts.debian.org/sid/fail/python3-extractor_1:0.6-8.log Cheers, Ivo
Bug#981441: trapperkeeper-scheduler-clojure: FTBFS on all
package: src:trapperkeeper-scheduler-clojure version: 1.1.3-3 severity: serious tags: ftbfs Hi, The latest upload of trapperkeeper-scheduler-clojure to unstable fails on all: https://buildd.debian.org/status/package.php?p=trapperkeeper-scheduler-clojure Cheers, Ivo
Bug#934242: kylin-video: drop (build-)dependency on crystalhd, which will not be in bullseye
Control: clone -1 -2 Control: reassign -2 kylin-video Control: retitle -2 kylin-video: drop (build-)dependency on crystalhd, which will not be in bullseye Hi, On Tue, Dec 22, 2020 at 09:29:03PM +0100, Paul Gevers wrote: > On 21-12-2020 23:32, Jonas Smedegaard wrote: > > Yes, there are still packages depending on it: Someone needs to work > > actively with those still believing the library is more than snakeoil - > > because our mechanisms auto-pressuring packages to to stay alert and in > > line or else get kicked from testing works only on edge packages - > > packages "well connected" in Debian are not affected. > > > > (while the allegory is funny, I really don't mean to imply that the > > mechanisms were _intented_ to treat packages unequally, only that in > > effect it does) > > So, let's inform the kylin-video team that we're about to remove > crystalhd from bullseye. > > @kylin-video team, please drop your Build-Depends on libcrystalhd-dev > and your Depends on libcrystalhd3. If this doesn't happen in a week or > two, kylin-video will be removed from bullseye too. Cloning the bug to track the RC issue in kylin-video. Cheers, Ivo
Bug#980793: bsdowl: piuparts failure
package: bsdowl version: 2.2.2-1 severity: serious Hi, The lastest upload of bsdowl triggers a piuparts failure: https://piuparts.debian.org/sid/fail/bsdowl_2.2.2-1.1.log It seems bsdowl installs files in /usr/share/mk, but that is now a symlink (shipped by bmake), pointing to /usr/share/bmake/mk-netbsd. It looks like this failure might be fixed by moving those files to that directory. Note that the failure was detected in version 2.2.2-1.1, currently in unstable, but version 2.2.2-1 contains the same files, so I'm filing it against that version. Cheers, Ivo
Bug#980267: qdjango: FTBFS on buildds
package: src:qdjango version: 0.6.2-3 severity: serious tags: ftbfs Hi, The latest upload of qdjango to unstable fails on the buildds: https://buildd.debian.org/status/package.php?p=qdjango Cheers, Ivo
Bug#979174: node-express-generator: Incompatible with current node-commander and node-mkdirp
Control: tags -1 + bullseye Hi, On Sun, Jan 03, 2021 at 09:39:56PM +0100, Xavier Guimard wrote: > Package: node-express-generator > Version: 4.0.0-2 > Severity: grave > Tags: sid, ftbfs Tagging bugs only 'sid' and not the tag for testing usually doesn't give the correct result. Adding the bullseye tag as well. Did you add the ftbfs tag by mistake? I don't see an ftbfs anywhere. > Justification: renders package unusable > > node-express-generator isn't compatible with current node-commander, > neither node-mkdirp. As it has no reverse dependency, I suggest to > remove it from Debian If you want the package removed, you should probably file an FTP removal bug. Cheers, Ivo
Bug#980111: pam breaks frr autopkgtest on armhf and ppc64el: non-zero exit status 1
Control: reassign -1 frr/7.4-1 Hi, On Thu, Jan 14, 2021 at 05:00:26PM +0100, Paul Gevers wrote: > With a recent upload of pam the autopkgtest of frr fails in testing on > armhf and ppc64el when that autopkgtest is run with the binary packages > of pam from unstable. It passes when run with only packages from > testing. In tabular form: > >passfail > pamfrom testing1.4.0-2 > frrfrom testing7.4-1 > all others from testingfrom testing > autopkgtest [11:36:52]: test py-frr-reload: [--- Paul gave me access to a machine similart to the one that's running the test on armhf. It looks like it's a race condition in the test itself (or in the frr scripts): The test runs service frr reload and then runs vtysh -c 'show running-config' to check if the output is changed. With the new pam, this command still shows the old config immediately after the reload. A few seconds later, it shows the new config. I suspect the changes in pam affect the timing of some of the steps involved. As it looks like this is an issue in the frr test (or the frr package), I'm reassigning the bugs there. Cheers, Ivo
Bug#979301: namazu2-index-tools: contains namazu.1 manpage after separate arch-indep build
Hi Andreas, On Tue, Jan 05, 2021 at 12:56:24AM +0100, Andreas Beckmann wrote: > during a test with piuparts I noticed your package fails to upgrade from > 'testing'. Thanks for catching this! I wasn't able to find this error in the tests on piuparts.debian.org. The piuparts data passed on the britney says everything is ok. Is this a specific test that you are running, that isn't run on piuparts.debian.org? > [...] > The buildds only perform separate arch and indep builds, while the > maintainer uploaded namazu2-index-tools_2.0.21-22_all.deb seems to stem > from a combined build. So this is actually a bug in the source, which is the same in the version in testing. So this bug actually also affects the version in testing. I'm not adding a 'found' on that version because that would allow the package to migrate to testing, while AIUI, the binaries for the newer version are broken. I guess the only way to express that in the BTS is to clone the bug and reassign one clone to the source in testing and unstable, and leave the other one assigned to the binary in unstable. Cheers, Ivo
Bug#976468: This package only builds Arch:all binary packages
Control: severity -1 important Hi Lucas, Thanks for al your QA work! On Sat, Dec 05, 2020 at 09:45:34PM +0100, Lucas Nussbaum wrote: > This package only builds Arch:all binary packages. Unfortunately, I > don't think that we have a way to indicate that such binary packages > must be built on a specific architecture, and thus avoid a failure on > arm64. > > In those cases, building those packages on amd64 works fine, so the bug > is limited to building arch:all packages on specific architectures. > > I pondered downgrading the severity of those bugs, but in some cases, > it could indicate severe bugs in other packages, or packaging bugs such > as confusing arch:any and arch:all. > > However, I don't object to someone else downgrading them. I'm doing so now. Some of these are probably real bugs somewhere that should be fixed, but the bugs doesn't need to be serious for that. These certainly aren't issues which would merit delaying the release. Note that if it turns out that some of these bugs are in fact caused by real brokenness (other than not being able to build the arch: all packages on arm64), the severity of those specific bugs can obviously be increased again (with a note explaining what exactly is broken). > For reference, here are the packages I ran into in that category: > akuma 976548 > backward-cpp 976582 > bmagic 976517 > dune-localfunctions 976552 > golang-github-disintegration-imaging 976565 > golang-github-labstack-gommon 976578 > golang-github-linuxkit-virtsock 976564 > golang-github-montanaflynn-stats 976562 > golang-github-rcrowley-go-metrics 976543 > golang-github-robertkrimen-otto 976549 > golang-github-shirou-gopsutil 976509 > golang-google-cloud 976507 > jctools 976534 > jnr-ffi 976521 > libcereal 976585 > libmiglayout-java 976546 > multiboot 976502 > nova 976590 > python-fluids 976558 > python-ptrace 976468 > rapidjson 976536 > xenium 976480 > xfonts-100dpi 976571 > xfonts-75dpi 976471 > xfonts-cyrillic 976510 Cheers, Ivo
Bug#979524: debian-reference: build-depends on libopencc2-data, which no longer exists
package: src:debian-reference version: 2.76 tags: bullseye sid ftbfs severity: serious Hi, It seems debian-reference build-depends on libopencc2-data, which no longer exists. Cheers, Ivo
Bug#978670: xserver-xorg-video-ati: FTBFS on mips64el, mipsel
package: src:xserver-xorg-video-ati version: 1:19.1.0-2 severity: serious tags: ftbfs Hi, The latest upload of xserver-xorg-video-ati to unstable fails on mips64el, mipsel: https://buildd.debian.org/status/package.php?p=xserver-xorg-video-ati Cheers, Ivo
Bug#978571: xserver-xorg-video-amdgpu: FTBFS on mips64el, mipsel
package: src:xserver-xorg-video-amdgpu version: 19.1.0-2 severity: serious tags: ftbfs Hi, The latest upload of xserver-xorg-video-amdgpu to unstable fails on mips64el, mipsel: https://buildd.debian.org/status/package.php?p=xserver-xorg-video-amdgpu Cheers, Ivo
Bug#895037: Bug#895038: libappindicator: deprecated in Debian; AppIndicator based applications, please switch to Ayatana (App)Indicator(s)
Hi, On Thu, Dec 10, 2020 at 03:08:00PM +, Simon McVittie wrote: > On Thu, 10 Dec 2020 at 14:37:21 +, Mike Gabriel wrote: > > On Do 10 Dez 2020 15:35:19 CET, Paul Gevers wrote: > > > We're running into the freeze of bullseye soon. The first bug I checked > > > is still only severity important, so is it realistic to get this done > > > before bullseye release? [...] > > > If yes, action is needed, this isn't going to happen > > > magically. At the least raising the blocking bugs to severity serious. > > > > I'd suggest to raise severity of the still open bugs and get libappindicator > > kicked out before the bullseye release. > > > > The fixes are easy to be done. Maintainers can ping me if they have > > problems. > > Raising the blocking bugs to RC as requested. I added some hints to finish this, and now libindicator and libappindicator are no longer in testing. Thanks! Ivo
Bug#963371: isoquery: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2
Control: tags -1 patch On Sun, Jun 21, 2020 at 10:10:05PM +0200, Lucas Nussbaum wrote: > Source: isoquery > Version: 3.2.3-1 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200620 ftbfs-bullseye > > ERROR: integration - Bail out! > > ERROR:integration.c:88:test_integration_add_test_from_files: stdout of > > child process (/integration/iso_15924/all_localized [4191]) failed to > > match: Beng 325 bengal? I suspect this upstream patch fixes it: https://github.com/toddy15/isoquery/commit/bc7899393898a328d92392f80845d622620c8c14 Ivo
Bug#955663: pangox-compat: FTBFS: pangox.c:282:13: error: ‘PangoFontClass’ {aka ‘struct _PangoFontClass’} has no member named ‘find_shaper’
Control: tags -1 patch
On Fri, Apr 03, 2020 at 09:37:53PM +0200, Lucas Nussbaum wrote:
> Subject: pangox-compat: FTBFS: pangox.c:282:13: error: ‘PangoFontClass’
> {aka ‘struct _PangoFontClass’} has no member named ‘find_shaper’
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
The patch from ubuntu seems to fix the build.
Cheers,
Ivo
diff -pruN 0.0.2-5/debian/changelog 0.0.2-5ubuntu2/debian/changelog
--- 0.0.2-5/debian/changelog 2014-09-02 10:37:53.0 +
+++ 0.0.2-5ubuntu2/debian/changelog 2020-09-01 01:29:48.0 +
@@ -1,3 +1,22 @@
+pangox-compat (0.0.2-5ubuntu2) groovy; urgency=medium
+
+ * No-change rebuild to pick up i386
+
+ -- Steve Langasek Mon, 31 Aug 2020 18:29:48 -0700
+
+pangox-compat (0.0.2-5ubuntu1) focal; urgency=medium
+
+ * Stop setting PangoFontClass.find_shaper. It's gone from modern pango, as
+shape engines are no longer used.
+
+ -- William Grant Sun, 05 Jan 2020 21:22:16 +1100
+
+pangox-compat (0.0.2-5build1) eoan; urgency=medium
+
+ * No-change rebuild to drop multiarch-support dependency.
+
+ -- Matthias Klose Sun, 01 Sep 2019 03:41:52 +
+
pangox-compat (0.0.2-5) unstable; urgency=medium
* Use dh-autoreconf during build to support newer architectures.
diff -pruN 0.0.2-5/debian/control 0.0.2-5ubuntu2/debian/control
--- 0.0.2-5/debian/control 2014-09-02 10:39:31.0 +
+++ 0.0.2-5ubuntu2/debian/control 2020-01-05 10:22:16.0 +
@@ -1,13 +1,13 @@
# This file is autogenerated. DO NOT EDIT!
-#
+#
# Modifications should be made to debian/control.in instead.
# This file is regenerated automatically in the clean target.
-
Source: pangox-compat
Section: oldlibs
Priority: extra
-Maintainer: Debian GNOME Maintainers
-Uploaders: Emilio Pozuelo Monfort , Michael Biebl
+Maintainer: Ubuntu Developers
+XSBC-Original-Maintainer: Debian GNOME Maintainers
+Uploaders: Debian GNOME Maintainers , Emilio Pozuelo Monfort , Michael Biebl
Build-Depends: debhelper (>= 8.1.3),
cdbs (>= 0.4.93),
gnome-pkg-tools (>= 0.11),
diff -pruN 0.0.2-5/debian/control.in 0.0.2-5ubuntu2/debian/control.in
--- 0.0.2-5/debian/control.in 2014-09-02 10:32:17.0 +
+++ 0.0.2-5ubuntu2/debian/control.in 2020-01-05 10:22:16.0 +
@@ -1,7 +1,8 @@
Source: pangox-compat
Section: oldlibs
Priority: extra
-Maintainer: Debian GNOME Maintainers
+Maintainer: Ubuntu Developers
+XSBC-Original-Maintainer: Debian GNOME Maintainers
Uploaders: @GNOME_TEAM@
Build-Depends: debhelper (>= 8.1.3),
cdbs (>= 0.4.93),
diff -pruN 0.0.2-5/debian/patches/pango-no-find_shaper.patch 0.0.2-5ubuntu2/debian/patches/pango-no-find_shaper.patch
--- 0.0.2-5/debian/patches/pango-no-find_shaper.patch 1970-01-01 00:00:00.0 +
+++ 0.0.2-5ubuntu2/debian/patches/pango-no-find_shaper.patch 2020-01-05 10:22:16.0 +
@@ -0,0 +1,10 @@
+--- pangox-compat-0.0.2.orig/pangox.c
pangox-compat-0.0.2/pangox.c
+@@ -279,7 +279,6 @@ pango_x_font_class_init (PangoXFontClass
+
+ font_class->describe = pango_x_font_describe;
+ font_class->get_coverage = pango_x_font_get_coverage;
+- font_class->find_shaper = pango_x_font_find_shaper;
+ font_class->get_glyph_extents = pango_x_font_get_glyph_extents;
+ font_class->get_metrics = pango_x_font_get_metrics;
+ font_class->get_font_map = pango_x_font_get_font_map;
diff -pruN 0.0.2-5/debian/patches/series 0.0.2-5ubuntu2/debian/patches/series
--- 0.0.2-5/debian/patches/series 1970-01-01 00:00:00.0 +
+++ 0.0.2-5ubuntu2/debian/patches/series 2020-01-05 10:22:16.0 +
@@ -0,0 +1 @@
+pango-no-find_shaper.patch
Bug#947325: snapd: strict confinement is not enabled
Control: severity -1 important Hi, On Tue, Dec 24, 2019 at 06:33:58PM +0100, Mattia Monga wrote: > Package: snapd > Version: 2.42.1-1 > Severity: grave > Tags: security > Justification: user security hole You didn't really explain how this is a security hole. You just asked for the default setting to be different. Downgrading. Cheers, Ivo > If one installs the example snap hello-world and launches hello-world.evil in > apparmored system the application is NOT strictly confined by default. > > ~$ snap run hello-world.evil > Hello Evil World! > This example demonstrates the app confinement > You should see a permission denied error next > If you see this line the confinement is not working correctly, please file a > bug > > > My snap debug info > > ~$ snap debug confinement > partial > > ~$ snap debug sandbox-features > apparmor: kernel:caps kernel:domain kernel:file kernel:mount > kernel:namespaces kernel:network_v8 kernel:policy kernel:ptrace kernel:query > kernel:rlimit kernel:signal parser:unsafe policy:downgraded > support-level:partial > confinement-options: classic devmode > dbus: mediated-bus-access > kmod: mediated-modprobe > mount:freezer-cgroup-v1 layouts mount-namespace > per-snap-persistency per-snap-profiles per-snap-updates > per-snap-user-profiles stale-base-invalidation > seccomp: bpf-actlog bpf-argument-filtering kernel:allow > kernel:errno kernel:kill_process kernel:kill_thread kernel:log kernel:trace > kernel:trap kernel:user_notif > udev: device-cgroup-v1 tagging > > I believe the default setting should be "strict" or, at least, the package > should have clear documentation on how to enable the strict mode (which, > according to upstream, is the default...) >
Bug#974574: nbdkit: build-depends on libtorrent-rasterbar-dev, which is not in testing
package: nbdkit severity: serious version: 1.22.3-1 Hi, The latest version of nbdkit build-depends on libtorrent-rasterbar-dev. As libtorrent-rasterbar is no longer in testing, this prevents migration to testing. Cheers, Ivo
Bug#926455: mail_autoremovals: incorrect version number in email warning
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#954954: fixed in gcc-10 10-20200402-1
Control: reopen -1 On Thu, Apr 02, 2020 at 01:33:36PM +, Debian FTP Masters wrote: >* Update libstdc++6 symbols file for armel. Closes: #954954. It seems the issue is still present in 10.2.0-6. Thanks, Ivo
Bug#953489: fixed in php-horde-text-filter-jsmin 1.0.2-8
On 7/10/20 8:57 PM, Mike Gabriel wrote: Hi Ivo, Hi Mike, I have asked for white-listing some days back. I have pinged Philipp Kern explicitly once more (he white-listed php-horde-javascriptminify-jsmin just the other day...). I will close this bug, once the white-listing is in place. I am not in a hurry with testing migration, as we need to fix autopkgtests first, anyway. OK. I just wanted to make sure you were aware of the situation. Thanks, Ivo
Bug#953489: fixed in php-horde-text-filter-jsmin 1.0.2-8
Control: reopen -1 On Tue, Jun 30, 2020 at 05:48:37AM +, Debian FTP Masters wrote: >* d/control: Add 'XS-Autobuild: yes' flag. (Closes: #953489). Hi, Adding this isn't enough to allow auto-building. It also needs to be whitelisted as described in https://www.debian.org/doc/manuals/developers-reference/pkgs.html#non-free-buildd As long as this hasn't happened, the autobuild won't happen. So I suggest you do a binary upload in the mean time, to allow the package to migrate to testing. Note that binaries uploaded by maintainers for sources in contrib and non-free are allowed to migrate to testing. Thanks, Ivo
Bug#145257: #145257 Re: why did hypercorn migrate to testing?
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
Bug#962696: please consider renaming package
package: vrms Hi, Please consider changing the name of this package and removing the reference to RMS. As the description says, the package isn't based on the opinions of RMS, but on the DFSG. Thanks, Ivo
Bug#909210: Does it make sense to ship automake-1.15 in bullseye?
Control: severity -1 serious Control: retitle -1 don't ship automake-1.15 in bullseye Hi, On Thu, May 28, 2020 at 09:34:18AM -0700, Vagrant Cascadian wrote: > On 2020-02-04, Vagrant Cascadian wrote: > > On 2019-01-12, Ivo De Decker wrote: > >> On Wed, Sep 19, 2018 at 09:31:13PM +0300, Adrian Bunk wrote: > >>> The 1.15 -> 1.16 changes were relatively minor. > >>> > >>> All FTBFS it caused should already be filed as bugs, > >>> and most have already been fixed. > >>> > >>> So far I haven't seen a single one that would have > >>> been difficult to fix. > >>> > >>> There are currently no reverse (build) dependencies > >>> on automake-1.15 in unstable, and I do not think > >>> there should ever be any. > >> > >> cabextract b-d on automake-1.15 > > > > Unless I've missed some, Seems the only build-depends left in bullseye > > are: > > > > cabextract > > rsyncrypto > > > > I've just submitted patches for both, and marked as blocking this bug. > > I *think* they are now no remaining depends or build-depends on > automake-1.15, seems like it could be removed now? dak rm seems to agree, so I added a testing removal hint (and upgraded this bug so it doesn't come back). It's probably time to file an ftp removal bug for unstable? Cheers, Ivo
Bug#960983: apt-cudf: silently skips installing systemd from Build-Depends
Control: tags -1 moreinfo Hi, On Mon, May 18, 2020 at 07:19:27PM -0700, Ross Vandegrift wrote: > apt-build build-dep with apt-cudf does not install systemd, even when it > appears directly in the Build-Depends of the requested package. Example: > > $ apt-get --simulate build-dep --solver aspcud enlightenment > > No error/warning tells the user that they didn't get everything they wanted. Please provide the output of the command, to show what exactly was proposed by apt-get as a solution. I suspect this might be caused by this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959828 Cheers, Ivo
Bug#960879: aspcud: homepage outdated
package: aspcud Hi, It seems the url of the apcud homepage changed. The new page is https://potassco.org/aspcud/ Cheers, Ivo
