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#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#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#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, 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#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#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#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#984539: marked as pending in debian-security-support
Hi, On Thu, Mar 18, 2021 at 08:57:17PM +, Utkarsh Gupta wrote: > Bug #984539 in debian-security-support reported by you has been fixed in the > Git repository and is awaiting an upload. You can see the commit > message below and you can check the diff of the fix at: > > https://salsa.debian.org/debian/debian-security-support/-/commit/2693921853d44dd0c19bb25b8f4ffaf3a4d9104d > > > dpkg hook should never fail; Closes: #984539 > You changed the hook invocation to: post-invoke="if [ -x /usr/share/debian-security-support/check-support-status.hook ] ; then /usr/share/debian-security-support/check-support-status.hook ; else /bin/true ; fi" Note that this doesn't actually ensure that it doesn't fail. The 'else' case only happens when the if statement fails, so when the hook doesn't exist. But when the hook script fails for some reason, dpkg will still abort. I think changing it to the following should fix that. post-invoke="if [ -x /usr/share/debian-security-support/check-support-status.hook ] ; then /usr/share/debian-security-support/check-support-status.hook || /bin/true ; fi" 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#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#976471: 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#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#956872: src:frr: fails to migrate to testing for too long: ftbfs on mipsel
Hi, On Thu, Apr 16, 2020 at 09:48:09AM +0200, Paul Gevers wrote: > Subject: src:frr: fails to migrate to testing for too long: ftbfs on mipsel > This bug will trigger auto-removal when appropriate. As with all new > bugs, there will be at least 30 days before the package is auto-removed. Please note that frr will be manually removed from testing in the next few days, because the version in testing is older than the version in stable-proposed-updates (which will go into stable in the next point release). Cheers, Ivo
Bug#958912: devscripts: missing ubuntu release info breaks autopkgtest
package: devscripts version: 2.20.3 severity: serious Hi, It seems the autopkgtest for devscript fails when the current ubuntu version is unknown: https://ci.debian.net/data/autopkgtest/testing/amd64/d/devscripts/5161251/log.gz testUbuntuIncrement ASSERT:error output of dch --no-conf -c "/tmp/shunit.VOe8J9/tmp/changelog" --vendor Ubuntu -i "Version test."\n expected:<> but was: testUbuntuRebuild ASSERT:error output of dch --no-conf -c "/tmp/shunit.VOe8J9/tmp/changelog" --vendor Ubuntu -R "Version test."\n expected:<> but was: When the name of the current ubunto release is unknown, this test should probaby be skipped, instead of failing, as it is not an issue with devscripts. The trigger for this issue is in the releasedate for a new ubuntu release, which is included in the latest distro-info-data, which is not yet in testing (it will probably migrate in a few days). However, this is a bug in the devscript test. The devscripts autopkgtest shouldn't start failing if the data for ubuntu is outdated or missing in testing, stable, oldstable, ... Cheers, Ivo
Bug#958313: libnitrokey: FTBFS on mipsel: symbol changes
package: src:libnitrokey version: 3.4.1-4 severity: serious tags: ftbfs Hi, A binnmu of libnitrokey on mipsel (to bring the versions in sync for multiarch) failed: https://buildd.debian.org/status/package.php?p=libnitrokey Note that only mipsel was rebuilt (because the binNMU version was lower), so it's possible that this issue isn't limited to mipsel. Cheers, Ivo
Bug#923698: gcc-mingw-w64 miscompiles PARI
Hi, Thanks for checking the history. On Sun, Apr 12, 2020 at 01:50:12PM +0200, Bill Allombert wrote: > > Is this stil an issue with the newer versions of gcc-mingw-w64? > > > > Should this bug really be marked as serious? > > Please note that I reported the bug as severity normal but Stephen bumped it > to serious, maybe due to the release. I know (sorry that wasn't clear in my previous mail). > Fortunately I forgot to remove my old logs. > > - my setup reported failure up to March 14 2019 when I switched to gcc > 6.3.0 to avoid the issue. > - I upgraded the box on March 24 2020 to gcc version 8.3-win32 20190406 (GCC) > which passes the test. > - I just tested with 9.3-posix 20200324 and this passes the test too. > > I very much like to see a chaangelog that tell what changed betwee 8.2 > and 8.3 that could have fixed this. So I guess the current version in testing is ok, and the bug can be closed there? If it works on gcc 8.3, does that mean it works with the version in stable as well? The current version in stable was built wit gcc 8.3.0-6. Cheers, Ivo
Bug#923698: gcc-mingw-w64 miscompiles PARI
Hi Stephen, Bill, While looking at RC bugs that have been open for I while, I noticed this one. On Thu, Mar 07, 2019 at 09:07:15AM +0100, Stephen Kitt wrote: > Subject: Re: Bug#923698: gcc-mingw-w64 miscompiles PARI [...] > I don’t have any practical suggestion right now, but given that there’s a > test suite I’ll bisect to identify the source of the problem. Is this stil an issue with the newer versions of gcc-mingw-w64? Should this bug really be marked as serious? Cheers, Ivo
Bug#956276: runescape: downloads unverified binary and runs it
package: runescape severity: serious Hi, It seems runescape downloads a binary and runs it, without verifying its integrity. At least the download happens using https, but no other verification is done. Cheers, Ivo
Bug#956275: runescape: license issue - runscape.png probably undistributable
package: runescape severity: serious Hi, Runescape contains this file: src/runescape.png The copyright file lists this as 'BSD-2-Clause'. What is this based on? The term and conditions on the website (which are mentioned in src/runschape.sh, but not in the copyright file), certainly are not BSD. So the copyright file is wrong. I suspect it doesn't even allow distributing runescape.png. If you think it does, please clarify why you think so in the copyright file. Also, it would be good to clarify (both in the copyright file and in the package description) that this package only contains a download script that downloads the game from the website and runs that, but doesn't contain the actual game. Cheers, Ivo
Bug#953487: fixed in runescape 0.7-1
Control: reopen -1 On Wed, Apr 08, 2020 at 10:20:28PM +, Debian FTP Masters wrote: > runescape (0.7-1) unstable; urgency=medium > . >* New upstream release. (Closes: #953487, #953714) This new version doesn't fix the autobuilding issue: https://buildd.debian.org/status/package.php?p=runescape Looking at the package, I also discovered some other issues, which I will file as separate bugs. Ivo
Bug#895037: libappindicator: deprecated in Debian; AppIndicator based applications, please switch to Ayatana (App)Indicator(s)
Hi Mike, This (obviously) wasn't done for buster, but it might be time to revisit it for bullseye. On Mon, Oct 22, 2018 at 10:13:32AM +, Mike Gabriel wrote: > > On Fri, Apr 06, 2018 at 01:07:39PM +, Mike Gabriel wrote: > > > Package: src:libappindicator > > > Severity: serious > > > > > > The libappindicator package is currently QA team maintained in Debian and > > > shall be phased out hopfully during the buster release cycle. The > > > alternative (maintained upstream and Debian-downstream) is > > > libayatana-appindicator. > > > > > > There is a lot of porting work to do (little patches are required for each > > > application), to let all AppIndicator aware applications build against the > > > new and supported AppIndicator shared lib fork "libayatana-appindicator". > > > > > > For details, please see [1] > > > > > > For a list of applications that require porting and the porting status, > > > see > > > [2] > > > > What's the status of this? Looking at testing, there are still quite a few > > packages remaining that (build-)depend on libappindicator: > > I wish I could give more time to writing patches against the listed > packages. Possibly, I should do a bug filing round first and then add > patches, when I get to working on individual packages. > > > # Broken Depends: [...] > The above list is irrelevant, what counts are the build-deps. Well, this was the output of dak rm. These dependencies need to be resolved someway before the removal can be done. But I suspect your point is that these will be solved when the build-depends (for the same packages) are solved, so it's better to look at the build-depends. [snip] Note that the list of packages with broken build-depends shown by dak rm isn't much shorter than it was a year ago. > > To help the overview of what's still missing, it might be good to add > > blocking > > bugs for every package to this one. It seems this wasn't done. Please add blocking bugs to this bug, so it's easy to see what's missing. Looking at the list of usertagged bugs you mentioned, it seems most of these bugs are listed as fixed. So the remaining packages either don't have a bug, or the bug wasn't usertagged. If you want to get this done for bullseye, please upgrade these bugs to serious. Autoremovals will take care of some of the packages. The rest will need manual fixes. Cheers, Ivo
Bug#931529: Acknowledgement (gnome: Session locking does not possible)
Control: severity -1 important On Wed, Jul 10, 2019 at 09:34:42AM +0200, Charles BLANC ROLIN wrote: > The problem was solved after delete ~/.config/ directory. Downgrading, as there seems to be a workaround. Ivo
Bug#930527: linux-image-4.19.0-5-amd64: when logging out, not the whole screen is erased, leaving private information
Control: severity -1 important Control: fixed -1 5.4.19-1 Control: retitle -1 linux-image-4.19.0-5-amd64: nouveau driver sometimes crashes Hi, Thanks for the clarification. On Mon, Mar 30, 2020 at 01:05:20PM +0200, Vincent Lefevre wrote: > On 2020-03-30 09:06:15 +0200, Ivo De Decker wrote: > > On Sun, Mar 29, 2020 at 09:43:42PM +0200, Vincent Lefevre wrote: > > > I don't think so, except the use of the nouveau driver, of course. > > > But there were no issues for years. I think that problems started > > > to occur after some kernel upgrade. Now, I haven't had any problem > > > since December, I think. > > > > Do you think the problem is gone with the kernel you are running now? > > I don't know. I don't use this machine often, except remotely > (via ssh). But problems with the nouveau driver were common > (and a crash could occur in the nouveau driver even when using > the machine remotely only), and I haven't seen any issue recently, > even the last few times I logged in physically. It seems the main issue you were seeing was (is?) that the nouveau driver wasn't always very stable. I suspect this wasn't limited to logout only. > > What version is that? > > linux-image-5.4.0-4-amd64 5.4.19-1 > > ypig:~> uname -a > Linux ypig 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64 GNU/Linux Ok, let's assume the issue is no longer present there. > > > > Also, I don't think this bug is really 'grave'. Even if private > > > > information remains on the screen, the user can see that, and > > > > take action to avoid it. > > > > > > Not if one logs out remotely. > > > > What do you mean by that? > > I sometimes log in physically, but go away without logging out first > (there are sometimes a good reason, e.g. if some computation program > hasn't finished yet and I had not started it in "screen"). I can > later log in via ssh and kill the X session. Oh. I assumed you were talking about a text console, but it seems you're talking about a graphical login. In any case, I don't think this qualifies as a grave bug, so I'm downgrading it. Cheers, Ivo
Bug#930527: linux-image-4.19.0-5-amd64: when logging out, not the whole screen is erased, leaving private information
Hi, On Sun, Mar 29, 2020 at 09:43:42PM +0200, Vincent Lefevre wrote: > On 2020-03-29 19:10:30 +0200, Ivo De Decker wrote: > > On Fri, Jun 14, 2019 at 04:31:16PM +0200, Vincent Lefevre wrote: > > > When logging out, a part of the previous session is still visible. > > > This might be used to compromise the user's account or leak other > > > private information, depending on what was written on the screen. > > > > What do you mean exactly? Is the screen only erased partially, or not at > > all? > > It was partially erased. > > > Is there something specific about your setup that you think might be > > relevant > > here? > > I don't think so, except the use of the nouveau driver, of course. > But there were no issues for years. I think that problems started > to occur after some kernel upgrade. Now, I haven't had any problem > since December, I think. Do you think the problem is gone with the kernel you are running now? What version is that? > > Also, I don't think this bug is really 'grave'. Even if private information > > remains on the screen, the user can see that, and take action to avoid it. > > Not if one logs out remotely. What do you mean by that? Cheers, Ivo
Bug#930527: linux-image-4.19.0-5-amd64: when logging out, not the whole screen is erased, leaving private information
Hi, On Fri, Jun 14, 2019 at 04:31:16PM +0200, Vincent Lefevre wrote: > When logging out, a part of the previous session is still visible. > This might be used to compromise the user's account or leak other > private information, depending on what was written on the screen. What do you mean exactly? Is the screen only erased partially, or not at all? Is there something specific about your setup that you think might be relevant here? When I try logging in on the console, and then log out, my screen is erased completely. Also, I don't think this bug is really 'grave'. Even if private information remains on the screen, the user can see that, and take action to avoid it. Cheers, Ivo
Bug#929983: ipxe-qemu: virtio booting no longer works after upgrade to buster
Control: tags -1 moreinfo Hi Thorsten, On Wed, Jun 05, 2019 at 01:24:06AM +0200, Thorsten Glaser wrote: > On Tue, 4 Jun 2019, Vagrant Cascadian wrote: > > > Works for me using a virt-manager configured with virtio or the > > hypervisor default for netoworking with the same seabios and ipxe > > Hmm. > > > versions. My system was recently upgraded from stretch to buster. > > This one was a fair bit older, I think it was originally a wheezy, > but I upgraded it step by step as usual. > > > Could you provide more detail about your configured virtual machine? > > I’ll attach the virsh dumpxml output below; I had reinstalled Debian > using an e1000 NIC and netboot in the meantime and reverted to virtio > afterwards, but I’m pretty sure this is reproducible even on other > virtualisation hosts, I will try that tomorrow. Were you able to confirm this? It seems other people are able to netboot with ipxe-qemu and virtio. Cheers, Ivo
Bug#899623: *prod* Please fix omniorb-dfsg bug #899623?
Hi, On Sun, Mar 29, 2020 at 04:13:37PM +0200, Floris Bruynooghe wrote: > On Sat 28 Mar 2020 at 17:28 +0100, Ivo De Decker wrote: > > On Sun, Mar 10, 2019 at 01:59:50PM +, Steve McIntyre wrote: > >> Hi guys, > >> > >> I don't know if you've even seen this RC bug. Could you please update > >> the maintainer address to point to something that works? > > > > Any news on this? Are you still interested in maintaining omniorb-dfsg? > > > > The last maintainer upload was in 2015. Maybe this package should be > > orphaned > > instead? > > Yes, this package should really be orphaned and possibly even removed > now if there are RC bugs and no dependencies for it. I've never been a > DD myself only maintained this for a few years together with Thomas, but > AFAIK both me or Thomas have stopped maintaining this for years now. > IIRC I attempted to orphan this at some point, but it may never have had > the upload and svn seems gone by now too... I filed https://bugs.debian.org/955300 to document that it is orphaned, and will do a QA upload fixing the maintainer address (which is the only RC issue currently). Note that it does have reverse dependencies. > Apologies for not getting the state of the package correctly and the > extra work it causes you. Cheers, Ivo
Bug#952088: fixed in ruby-tins 1.1.0-2
Hi, On Wed, Feb 26, 2020 at 05:08:54PM +, Debian FTP Masters wrote: >[ Lucas Kanashiro ] >* Add b-d on ruby-sync, it is not bundled in ruby anymore (Closes: #952088) Please note that ruby-tins is not migrating to testing, because ruby-sync needs a new source-only upload. Cheers, Ivo
Bug#926539: rootskel: steal-ctty no longer works on at least sparc64
Hi,
On Wed, Jun 26, 2019 at 10:18:37PM +0100, James Clarke wrote:
> (Don't know if this is a blocker for the release, but it should at
> least be reviewed before we release IMO, hence the severity)
>
> On Sun, Apr 07, 2019 at 12:53:35AM +0100, Ben Hutchings wrote:
> > On Sat, 2019-04-06 at 21:33 +0200, John Paul Adrian Glaubitz wrote:
> > > On 4/6/19 6:46 PM, John Paul Adrian Glaubitz wrote:
> > > > My suspicion is that the support multiple consoles in parallel [2]
> > > > introduced
> > > > this particular regression. I haven't done any debugging yet though as
> > > > I'm
> > > > not sure where to start, I haven't touched the rootskel package before
> > > > and
> > > > therefore would be interested in any pointers how to debug this.
> > >
> > > The problem seems to be the fact that the sparc64 kernel uses different
> > > names
> > > for /proc/console and the actual console name:
> > >
> > > root@landau:~# cat /proc/consoles
> > > ttyHV0 -W- (EC p )4:64
> > > tty0 -WU (E )4:1
> > > root@landau:~# readlink /sys/dev/char/4:64
> > > ../../devices/root/f0299a70/f029b788/tty/ttyS0
> >
> > The inconsistent name seems like a kernel bug...
> >
> > > root@landau:~#
> > >
> > > And this is what used to make it work [1]:
> > >
> > > *) # >= 2.6.38
> > > console_major_minor="$(get-real-console-linux)"
> > > console_raw="$(readlink "/sys/dev/char/${console_major_minor}")"
> > > console="${console_raw##*/}"
> > > ;;
> >
> > So maybe rootskel should use that again, but applied to each console's
> > char device number.
> >
> > (Though directly using the symlinks under /dev/char seems cleaner than
> > poking in sysfs.)
>
> Just got a report in #debian-cd of a user running into this issue on
> s390x with Hercules; a subset of the messages sent in conversation are
> below:
>
> [20:12:18]steal-ctty: No such file or directory
> [20:12:29]will go hunt this down once i find time
> [20:12:52](DI buster RC2 / s390x)
> [21:52:40]gruetzkopf: cat /proc/consoles ?
> [21:54:00]should give something like:
> [21:54:00]ttyS0-W- (EC p )4:64
> [21:54:22]rootskel will prefer a console which has the C flag
> [21:55:17]now let's see how to get there
> [21:55:57](note: running in hercules, not real hw or qemu
> where i'd have virtio console)
> [22:01:39]cat /proc/consoles
> [22:01:40]ttyS0-W- (EC p )4:64
> [22:02:05]and ls -l /dev/ttyS0?
> [22:03:06]ls: /dev/ttyS0: No such file or directory
> [22:03:06]oh, fun!
> [22:04:36]and ls -l /sys/dev/char/4:64 ?
> [22:06:06]ls -l /sys/dev/char/4:64
> [22:06:06]lrwxrwxrwx1 root root 0 Jun
> 26 21:05 /sys/dev/char/4:64 -> .
> [22:06:06]./../devices/virtual/tty/sclp_line0
> [22:06:28]ok, so, it's not /dev/ttyS0, it's /dev/sclp_line0?
> [22:06:32](does that exist?)
> [22:06:48]we had an issue like this on sparc64 (#926539)
> [22:07:38]i just found that
> [22:07:53]does that device node exist for you?
> [22:08:13]crw--w1 root root4, 64 Jun
> 26 20:58 /dev/sclp_line0
> [22:08:43](and so does /dev/ttysclp0)
>
> This is the "fault" of drivers/s390/char/sclp_tty.c. I don't know what
> the best fix is; we could also patch the kernel to ensure this shows up
> as /dev/sclp_line0 in /proc/consoles like sparc64 now does for sunhv,
> but I worry now that this might be a game of whack-a-mole and there are
> other character device drivers out there that also suffer from this.
> Perhaps therefore we need to go back to looking up the device name from
> the device number as has been suggested already...
This bug wasn't fixed in time for buster. Is it still present in bullseye? If
so, it might be good to try to fix it this time.
Cheers,
Ivo
Bug#929882: khelpcenter: please add conflict with dhelp and the KDE packages on debian buster
Control: severity -1 important Hi, On Mon, Jun 10, 2019 at 09:43:17PM +0200, Paul Gevers wrote: > Hi khelpcenter maintainers, > > On Sat, 01 Jun 2019 21:30:41 +0200 pnd23 wrote: > > KDE packages install their documentation files in /usr/share/doc/HTML on > > buster > > (in debian 8 this was: /usr/share/doc/kde/HTML). The "dhelp" package erases > > this folder when it rebuilds its index. The KHelpcenter documentation gets > > erased this way. > > This bug got cloned to khelpcenter to make sure that you change your > package to conflict with the unfixed version of dhelp, to prevent the > above issue from happening. I expect that dhelp may be removed from > buster, but if the package isn't removed from the users system, the > issue may still occur. As dhelp isn't in buster, and the version in bullseye is fixed, I'm downgrading this bug. However, adding a conflict (or breaks) against the old (broken) version of dhelp might still be a good thing, so I'm leaving this bug open. Thanks, Ivo
Bug#899623: *prod* Please fix omniorb-dfsg bug #899623?
Hi, On Sun, Mar 10, 2019 at 01:59:50PM +, Steve McIntyre wrote: > Hi guys, > > I don't know if you've even seen this RC bug. Could you please update > the maintainer address to point to something that works? Any news on this? Are you still interested in maintaining omniorb-dfsg? The last maintainer upload was in 2015. Maybe this package should be orphaned instead? Cheers, Ivo
Bug#954992: gdcm: b-dep on cli-common-dev, which is unavailable on mips64el
package: src:gdcm version: 3.0.5-1 severity: serious tags: ftbfs Hi, The latest upload of gdcm to unstable cannot be built on mips64el: https://buildd.debian.org/status/package.php?p=gdcm It build-depends on cli-common-dev, which depends on mono-utils, which is unavailable on mips64el. Please note that this blocks the python3-defaults transition. Cheers, Ivo
Bug#954954: libstdc++6: symbols file on armel incomplete
package: libstdc++6 severity: serious Hi, It seems the symbols file for libstdc++6 is missing some symbols on armel. The build adds these with the latest version. This causes new builds that use these symbols to pick up an (unnecessary) versioned dependency on the latest gcc in unstable. As this bug sometimes causes testing migrations to block on the migration of gcc, and thus interferes with transitions, I'm filing this as serious. This currently is the case with the opencv binNMU on armel, which is blocked behind gcc-10, blocking the python3-defauls transition. Maybe the build should we configured to fail when new symbols are discovered, to avoid similar issues in the future. Thanks! Ivo
Bug#938929: Dependency problem with iptables and libvirt-daemon-system
Control: severity -1 normal Control: tags -1 moreinfo Hi, On Fri, Aug 30, 2019 at 12:45:16PM +0200, Julian Hyordey wrote: > apt show libvirt-daemon-system > Package: libvirt-daemon-system > Version: 5.0.0-4 > Priority: optional > Section: admin > Source: libvirt > Maintainer: Debian Libvirt Maintainers < > pkg-libvirt-maintain...@lists.alioth.debian.org> > Installed-Size: 466 kB > Depends: debconf (>= 0.5) | debconf-2.0, libacl1 (>= 2.2.23), libapparmor1 (>= > 2.6~devel), libaudit1 (>= 1:2.2.1), libblkid1 (>= 2.16), libc6 (>= 2.14), > libcap-ng0 (>= 0.7.9), libdbus-1-3 (>= 1.9.14), libdevmapper1.02.1 (>= > 2:1.02.20), libgnutls30 (>= 3.6.5), libnl-3-200 (>= 3.2.7), libnl-route-3-200 > (>= 3.2.7), libnuma1 (>= 2.0.11), libselinux1 (>= 2.0.82), libvirt0 (>= > 5.0.0), > libxml2 (>= 2.7.4), libyajl2 (>= 2.0.4), adduser, gettext-base, lsb-base, > libvirt-clients (= 5.0.0-4), libvirt-daemon (= 5.0.0-4), iptables (>= 1.8.1-1) > | firewalld, logrotate, policykit-1 > [...] > . > So If I want to migrate from iptables to nftables on my KVM hypervisor, I > can't > remove iptables without removing libvirt-daemon-system. A bit annoying for an > hypervisor. Can't you just install nftables, use it, and leave iptables installed? Ivo
Bug#914636: stringencoder FTFBS: CC_FOR_BUILD turns out to be empty
Control: tags -1 pending Hi, On Sun, Nov 25, 2018 at 09:27:34PM +0100, Helmut Grohne wrote: > stringencoders fails to build from source on the buildds (e.g. > https://buildd.debian.org/status/fetch.php?pkg=stringencoders=arm64=3.10.3%2Bgit20180306-1=1542718062=0). > It seems that the variable CC_FOR_BUILD turns out to be empty. I guess > that the AC_ARG_VAR overrides the previous value and thus makes the > native build fail. I just uploaded an NMU which reverts the patch. That fixes the build. Ivo
