Bug#986650: winetricks: move from contrib to main
Package: winetricks Version: 0.0+20210206-1 Severity: normal Hi, a recent threat on debian-devel [1] revealed that winetricks falls into the same category as other packages that are happily sitting in main. Specifically, winetricks not only allows to download non-free software but also DFSG-free software like dxvk or faudio. As such it is in the same category as many other packages in main that allow to download both free and non-free binaries from the internet if the user requests it to do so. Since other packages that allow to download and run non-free stuff are allowed in main I think winetricks can be uploaded to main. The advantage would be that this would make it easier for our users to install winetricks. Thanks! cheers, josch [1] https://lists.debian.org/20210404091701.eum2iid4ffvpfn3v@frifot
Bug#983427: libpam-runtime: please add support for DPKG_ROOT
Package: libpam-runtime
Version: 1.4.0-4.1
Severity: wishlist
Tags: patch
User: debian-d...@lists.debian.org
Usertags: dpkg-root-support
Hi,
since dpkg 1.18.5, dpkg sets the variable DPKG_ROOT when invoking
maintainer scripts. Usually that variable is empty but when calling dpkg
with --root and --force-script-chrootless, dpkg will set DPKG_ROOT to
the new root directory. In that mode, maintainer scripts are called
without chroot(1) around them, and thus have to be able to possibly
operate on the path from DPKG_ROOT instead of working on /. This is
useful for bootstrapping, creating chroots for foreign architectures
where utilities from inside the chroot cannot be executed, avoiding
dependency loops between postinst scripts, installation without
requiring superuser privileges and for creating installations that do
not even contain dpkg. See
https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap for more
information.
To see the problem, you can run:
$ mmdebstrap --mode=chrootless --variant=custom --include=libpam-runtime
unstable /dev/null
[...]
Setting up libpam-runtime (1.4.0-4.1) ...
open(/var/lib/pam/seen) failed: Permission denied at /usr/sbin/pam-auth-update
line 232, line 11.
dpkg: error processing package libpam-runtime (--configure):
installed libpam-runtime package post-installation script subprocess returned
error exit status 13
Errors were encountered while processing:
libpam-runtime
E: Sub-process /usr/bin/dpkg returned an error code (1)
The following patch fixes the problem:
diff --git a/debian/libpam-runtime.postinst b/debian/libpam-runtime.postinst
index 518e8d24..053fdae2 100644
--- a/debian/libpam-runtime.postinst
+++ b/debian/libpam-runtime.postinst
@@ -29,7 +29,7 @@ then
done
fi
-pam-auth-update --package $force
+pam-auth-update --root "$DPKG_ROOT" --package $force
if [ -n "$force" ]; then
rm -f /etc/pam.d/common-auth.pam-old \
diff --git a/debian/local/pam-auth-update b/debian/local/pam-auth-update
index 6d17ab72..18fd898c 100644
--- a/debian/local/pam-auth-update
+++ b/debian/local/pam-auth-update
@@ -82,6 +82,11 @@ while ($#ARGV >= 0) {
$force = 1;
} elsif ($opt eq '--package') {
$package = 1;
+ } elsif ($opt eq '--root') {
+ my $rootdir = shift @ARGV;
+ $savedir = "$rootdir/$savedir";
+ $confdir = "$rootdir/$confdir";
+ $inputdir = "$rootdir/$inputdir";
} elsif ($opt eq '--remove') {
while ($#ARGV >= 0) {
last if ($ARGV[0] =~ /^--/);
Possibly, more is needed to correctly implement DPKG_ROOT support, but
with above patch, it is possible to run above mmdebstrap command
successfully.
Thanks!
cheers, josch
Bug#983425: debconf: please add support for DPKG_ROOT
Package: debconf Version: 1.5.74 Severity: wishlist Tags: patch User: debian-d...@lists.debian.org Usertags: dpkg-root-support Hi, since dpkg 1.18.5, dpkg sets the variable DPKG_ROOT when invoking maintainer scripts. Usually that variable is empty but when calling dpkg with --root and --force-script-chrootless, dpkg will set DPKG_ROOT to the new root directory. In that mode, maintainer scripts are called without chroot(1) around them, and thus have to be able to possibly operate on the path from DPKG_ROOT instead of working on /. This is useful for bootstrapping, creating chroots for foreign architectures where utilities from inside the chroot cannot be executed, avoiding dependency loops between postinst scripts, installation without requiring superuser privileges and for creating installations that do not even contain dpkg. See https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap for more information. Currently, missing support for DPKG_ROOT in debconf is the single biggest blocker in making all Essential:yes packages successfully install with --root and --force-script-chrootless. Me and Helmut Grohne happened to work on adding DPKG_ROOT support to debconf at the same time, so now we have two patches which both work. helmut: https://salsa.debian.org/josch/debconf/-/commit/4336c589fd6cb25e20f1753986bc86a74b668846 josch: https://salsa.debian.org/josch/debconf/-/commit/b84d965da3c56f33fed7e4f0899bc21c34578fcd Could you review either and give us feedback so that we can prepare a patch that is fit for inclusion into debconf? To try it out, you have to install the changed debconf package directly on your machine and *not* into the chroot, because in chrootless mode, the maintainer script will call the tools as they are installed on the machine running it. You can see how it currently fails by running: mmdebstrap --mode=chrootless --variant=custom --include=debconf unstable /dev/null [...] Setting up debconf (1.5.74) ... debconf: DbDriver "passwords" warning: could not open /var/cache/debconf/passwords.dat: Permission denied debconf: DbDriver "config": could not write /var/cache/debconf/config.dat-new: Permission denied dpkg: error processing package debconf (--configure): installed debconf package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: debconf E: Sub-process /usr/bin/dpkg returned an error code (1) However, with the changes from above commits, the command will succeed. Thanks! cheers, josch
Bug#983421: init-system-helpers: please respect DPKG_ROOT when checking for /usr/sbin/policy-rc.d
Package: init-system-helpers
Version: 1.60+nmu1
Severity: wishlist
Tags: patch
User: debian-d...@lists.debian.org
Usertags: dpkg-root-support
Hi,
if dpkg (since 1.18.5) is run with --force-script-chrootless, it sets
the variable DPKG_ROOT to the directory into which dpkg will install the
requested packages. This is useful for bootstrapping, creating chroots
for foreign architectures where utilities from inside the chroot cannot
be executed, avoiding dependency loops between postinst scripts,
installation without requiring superuser privileges and for creating
installations that do not even contain dpkg. See
https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap for more
information.
Currently, when maintainer scripts are run, /usr/sbin/policy-rc.d is
checked to avoid starting services. But instead, the scripts should
check "$DPKG_ROOT/usr/sbin/policy-rc.d". In normal situations, the
$DPKG_ROOT variable is empty, so this will work as usual. But if dpkg is
run with --root and --force-script-chrootless then /usr/sbin/policy-rc.d
from the new root directory will be used.
Please consider applying the following patch:
diff --git a/script/deb-systemd-invoke b/script/deb-systemd-invoke
index d8dab1a..67e3e1d 100755
--- a/script/deb-systemd-invoke
+++ b/script/deb-systemd-invoke
@@ -58,6 +58,9 @@ if (@ARGV < 2) {
}
my $policyhelper = '/usr/sbin/policy-rc.d';
+if (defined $ENV{DPKG_ROOT} && $ENV{DPKG_ROOT} ne "") {
+$policyhelper = $ENV{DPKG_ROOT} . $policyhelper;
+}
my @units = @ARGV;
my $action = shift @units;
if (-x $policyhelper) {
diff --git a/script/invoke-rc.d b/script/invoke-rc.d
index 71cc3f1..ca1bdbe 100755
--- a/script/invoke-rc.d
+++ b/script/invoke-rc.d
@@ -23,7 +23,7 @@
# Constants
RUNLEVELHELPER=/sbin/runlevel
-POLICYHELPER=/usr/sbin/policy-rc.d
+POLICYHELPER=$DPKG_ROOT/usr/sbin/policy-rc.d
INITDPREFIX=/etc/init.d/
RCDPREFIX=/etc/rc
Thanks!
cheers, josch
Bug#983412: libc-bin: please add support for DPKG_ROOT to the postinst
Package: libc-bin
Version: 2.31-9
Severity: wishlist
Tags: patch
User: debian-d...@lists.debian.org
Dear maintainers,
this is a followup on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910685
and makes libc-bin work with DPKG_ROOT set. Namely, the call to ldconfig
has to respect "$DPKG_ROOT" as it would otherwise attempt to modify the
real root instead of the new root directory.
Note, that this is again not a full solution because this will only work
when building a similar architecture chroot. It is still an improvement
of the status quo and having DPKG_ROOT work for same-architecture
chroots is already useful.
To test, I run:
mmdebstrap --mode=chrootless --variant=custom
--include=bsdutils,coreutils,debianutils,diffutils,dpkg,findutils,grep,gzip,hostname,init-system-helpers,ncurses-base,ncurses-bin,perl-base,sed,tar,libc-bin
unstable /dev/null
Without the patch this fails with:
ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Permission denied
With the patch above command succeeds. The patch:
diff --git a/debian/debhelper.in/libc-bin.postinst
b/debian/debhelper.in/libc-bin.postinst
index 802a3ad0..7fc320c5 100644
--- a/debian/debhelper.in/libc-bin.postinst
+++ b/debian/debhelper.in/libc-bin.postinst
@@ -40,15 +40,15 @@ update_to_current_default() {
}
if [ "$1" = "configure" ] && [ "$2" = "" ] ; then
- install_from_default /usr/share/libc-bin/nsswitch.conf /etc/nsswitch.conf
+ install_from_default "$DPKG_ROOT/usr/share/libc-bin/nsswitch.conf"
"$DPKG_ROOT/etc/nsswitch.conf"
fi
if [ "$1" = "configure" ] && [ "$2" != "" ]; then
- update_to_current_default /usr/share/libc-bin/nsswitch.conf
/etc/nsswitch.conf
+ update_to_current_default "$DPKG_ROOT/usr/share/libc-bin/nsswitch.conf"
"$DPKG_ROOT/etc/nsswitch.conf"
fi
if [ "$1" = "triggered" ] || [ "$1" = "configure" ]; then
- ldconfig || ldconfig --verbose
+ ldconfig -r "$DPKG_ROOT/" || ldconfig --verbose -r "$DPKG_ROOT/"
exit 0
fi
Note, that adding DPKG_ROOT is not strictly necessary for
update_to_current_default because currently, DPKG_ROOT will only be used
for initial installations and not for upgrades.
Thanks!
cheers, josch
Bug#981834: ITP: ocaml-cpu -- Pin current process to given core number
Package: wnpp Severity: wishlist Owner: Johannes 'josch' Schauer X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: ocaml-cpu Version : 2.0.0 Upstream Author : Francois Berenger * URL : https://github.com/UnixJunkie/cpu * License : LGPL-2.1+-with-linking-exception Programming Lang: OCaml Description : Pin current process to given core number This library can also get the number of CPU cores online. This is a dependency of ocaml-parany: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981827
Bug#981827: ITP: ocaml-parany -- Generalized map reduce for parallel computers
Package: wnpp Severity: wishlist Owner: Johannes 'josch' Schauer X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: ocaml-parany Version : 8.0.0 Upstream Author : Francois Berenger * URL : https://github.com/UnixJunkie/parany * License : LGPL-2.1+-with-linking-exception Programming Lang: OCaml Description : Generalized map reduce for parallel computers Parallelize any kind of computation. Generalized map reduce for parallel computers (not distributed computing). Can process a very large file in parallel on a multicore computer; provided there is a way to cut your file into independent blocks (the "demux" function). Can process in parallel an infinite stream of elements. This package is for situations where the existing ocaml parmap doesn't work on 32bit architectures. See https://github.com/rdicosmo/parmap/issues/46 for details.
Bug#981021: devscripts: debsign fails to sign dsc if buildinfo was already signed
Package: devscripts
Version: 2.20.5
Severity: normal
Control: block 977674 by -1
Hi,
if an unsigned changes file contains references to a signed buildinfo
file and an unsigned dsc file, then running "debsign --no-re-sign" will
sign the changes file but leave the dsc unsigned. As a result, running
dscverify on the signed changes file will produce an error.
I suspect the culprit is the following function from debsign:
maybesign_buildinfo() {
[...]
if check_already_signed "$buildinfo" "buildinfo"; then
echo "Leaving current signature unchanged." >&2
return
fi
if [ -n "$dsc" ]; then
maybesign_dsc "$signas" "$remotehost" "$dsc"
withtempfile buildinfo "$buildinfo" fixup_buildinfo "$dsc"
fi
[...]
The function maybesign_buildinfo() is responsible for handling both
buildinfo and dsc files but it immediately returns if the buildinfo was
already signed and thus the dsc never gets signed.
This is currently blocking bug #977674 in sbuild.
Thanks!
cheers, josch
Bug#981008: devscripts: dscverify ignores GNUPGHOME
Package: devscripts
Version: 2.20.5
Severity: normal
Hi,
dscverify ignores the GPGHOME environment variable. Instead it hardcodes
$ENV{HOME}/.gnupg/trustedkeys.gpg.
Second bug: modern gpg doesn't use trustedkeys.gpg but pubring.kbx.
It seems that trustedkeys.gpg is an implementation detail of gpg and
should not be relied upon.
Thanks!
cheers, josch
Bug#980527: dpkg: libdpkg-perl feature request: add a function that can parse the Source field
Package: dpkg
Version: 1.20.5
Severity: wishlist
Hi,
in the debrebuild script from devscripts we use the following code
snippet:
if ($srcpkgname =~ / /) {
# In some cases such as binNMUs, the source field contains a version in
# the form:
# mscgen (0.20)
($srcpkgname, $srcpkgver) = split / /, $srcpkgname, 2;
# Add a simple control check to avoid the worst surprises and stop obvious
# cases of garbage-in-garbage-out.
die("Unexpected source package name: ${srcpkgname}\n")
if $srcpkgname =~ m{[ \t_/\(\)<>!\n%&\$\#\@]};
# remove the surrounding parenthesis from the version
$srcpkgver =~ s/^\((.*)\)$/$1/;
}
as prompted by Mattia Rizzolo in [1] I'm proposing to add a function
that is able to parse a Source field with a source package name and a
possible version in brackets to libdpkg-perl.
Thanks!
cheers, josch
[1] https://salsa.debian.org/debian/devscripts/-/merge_requests/212#note_214079
Bug#979493: Error: Rule failed to generate the following targets: _doc/_html/highlight.pack.js
Package: ocaml-odoc Version: 1.5.1+dfsg-2+b1 Severity: grave Justification: renders package unusable Hi Ralf, as you probably remember, I brought up the odoc problem before here: https://gitlab.com/irill/dose3/-/merge_requests/1#note_475481814 I now investigated further and it seems that the package has an autopkgtest (yay!) so I triggered that and it failed with the same error message that I got: https://ci.debian.net/data/autopkgtest/unstable/amd64/o/ocaml-odoc/9469763/log.gz Since the logs are removed after some time, here the last lines from the log: autopkgtest [02:11:21]: test odoc-on-odoc: [--- File series fully applied, ends at patch debian/patches/no-vendored-js-highlight File "_doc/_html/_unknown_", line 1, characters 0-0: Error: Rule failed to generate the following targets: - _doc/_html/highlight.pack.js autopkgtest [02:11:26]: test odoc-on-odoc: ---] autopkgtest [02:11:26]: test odoc-on-odoc: - - - - - - - - - - results - - - - - - - - - - odoc-on-odoc FAIL non-zero exit status 1 autopkgtest [02:11:27]: summary odoc-on-odoc FAIL non-zero exit status 1 [ I also took the liberty to add salsaci to the ocaml-odoc repository on salsa and it seems there is also a FTBFS which I was unable to trigger locally using sbuild: https://salsa.debian.org/ocaml-team/ocaml-odoc/-/pipelines/216353 ] This makes me believe that this is probably not a problem with my system but with the ocaml-odoc package itself. A minimal test that triggers this error message is this shell script: --%<-- #!/bin/sh mkdir "$1/test" cat << END > "$1/test/dune-project" (lang dune 2.0) (name test) (generate_opam_files true) (package (name test)) END chroot "$1" sh -c 'cd /test && dune build @doc' -->%-- Which I passed to mmdebstrap with the first timestamp from snapshot.debian.org in which the ocaml-odoc package existed to see whether maybe this is a regression and this used to work in the beginning: $ mmdebstrap --aptopt='Acquire::Check-Valid-Until "false"' \ --variant=apt unstable --include=ocaml-odoc,ocaml-dune,ocaml-nox \ --customize-hook=/tmp/test.sh \ /dev/null http://snapshot.debian.org/archive/debian/20200624T145103Z/ But even back in June 2020 I got the same error message as from the autopkgtest on debci run above. I didn't try with the opam version yet. Maybe it works there. Nobody else (build-)depends on ocaml-odoc yet, so this problem is probably not super important unless we want to generate documentation for the next dose3 release. Thanks! cheers, josch
Bug#979115: snapshot.debian.org: please only update the list of available timestamps after the sync is complete
Package: snapshot.debian.org Severity: normal Hi, for the newest timestamp that one can find via http://snapshot.debian.org/archive/debian/ it can happen that some of the files in it return a 404. Maybe new timestamps are added to the web interface before the download of all content is complete? The webinterface should only show new timestamps once all their content is completely available for download. Thanks! cheers, josch
Bug#978024: regression: 4.11.1 broke dose3 on bytecode arches
Source: ocaml Version: 4.11.1-3 Severity: important Hi, my package botch FTBFS on armel, mips64el and mipsel: https://buildd.debian.org/status/package.php?p=botch The reason is, that when calling dose-deb-coinstall it fails with "unknown option --verbose". Upon further investigation, it turns out, that the dose3 source package builds invalid binaries on armel, mips64el and mipsel. You can reproduce the problem by building dose3 on a mipsel porter box with: $ apt-get source dose3 --build You then end up with the following identical working binaries: dose3-5.0.1/_build/applications/deb-coinstall.byte dose3-5.0.1/debian/tmp/usr/bin/dose-deb-coinstall But surprisingly, this one is different and also doesn't work as expected: $ dose3-5.0.1/debian/dose-extra/usr/bin/dose-deb-coinstall --help unknown option --help Funnily, the other non-working binaries, have the exact same md5sum: $ find dose3-5.0.1/ -type f -print0 | xargs -0 md5sum | grep 0261218e050b5c5c7ee1988fd1d4e5da 0261218e050b5c5c7ee1988fd1d4e5da dose3-5.0.1/debian/dose-extra/usr/bin/dose-deb-coinstall 0261218e050b5c5c7ee1988fd1d4e5da dose3-5.0.1/debian/dose-extra/usr/bin/dose-ceve 0261218e050b5c5c7ee1988fd1d4e5da dose3-5.0.1/debian/dose-distcheck/usr/bin/dose-distcheck I don't understand how this problem or what makes these three different from the other utilities built by the dose3 source package or how the error is only introduced when moving the binaries from debian/tmp to debian/dose-*. The reason I'm filing this bug against the ocaml source package is, that I bisected Debian unstable and found out, that the problem was not present when compiling dose3 at snapshot.d.o timestamp 20201012T150222Z and was first seen in timestamp 20201014T150244Z. The few timestamps between those two cannot be tested because the build dependencies were not installable for a while due to an upgrade of ocaml and the involved binNMU rebuilds. At the end of this mail I attached a diff between the package list at the still working snapshot timestamp 20201012T150222Z and the first failing 20201014T150244Z. As far as ocaml packages go, ocaml itself updated from 4.08.1 to 4.11.1 so I think this is likely the suspect. Maybe you have an idea of how to proceed? Thanks! cheers, josch $ diff debbisect.20201012T150222Z.pkglist debbisect.20201014T150244Z.pkglist 19,20c19,20 19,20c19,20 < cpp-1010.2.0-13 < cppo 1.6.6-2 --- > cpp-1010.2.0-15 > cppo 1.6.6-2+b1 41c41 < g++-1010.2.0-13 --- > g++-1010.2.0-15 43,44c43,44 < gcc-1010.2.0-13 < gcc-10-base:armel 10.2.0-13 --- > gcc-1010.2.0-15 > gcc-10-base:armel 10.2.0-15 53c53 < hevea 2.34-2 --- > hevea 2.34-2+b1 62,63c62,63 < libasan6:armel10.2.0-13 < libatomic1:armel 10.2.0-13 --- > libasan6:armel10.2.0-15 > libatomic1:armel 10.2.0-15 72c72 < libbrotli1:armel 1.0.9-2 --- > libbrotli1:armel 1.0.9-2+b1 76,77c76,77 < libbz2-ocaml 0.6.0-10+b1 < libbz2-ocaml-dev 0.6.0-10+b1 --- > libbz2-ocaml 0.6.0-10+b2 > libbz2-ocaml-dev 0.6.0-10+b2 85c85 < libcc1-0:armel10.2.0-13 --- > libcc1-0:armel10.2.0-15 96c96 < libcudf-ocaml-dev 0.9-1 --- > libcudf-ocaml-dev 0.9-1+b1 109,110c109,110 < libextlib-ocaml 1.7.7-2 < libextlib-ocaml-dev 1.7.7-2 --- > libextlib-ocaml 1.7.7-2+b1 > libextlib-ocaml-dev 1.7.7-2+b1 113c113 < libfindlib-ocaml 1.8.1-1+b1 --- > libfindlib-ocaml 1.8.1-2 118,119c118,119 < libgcc-10-dev:armel 10.2.0-13 < libgcc-s1:armel 10.2.0-13 --- > libgcc-10-dev:armel 10.2.0-15 > libgcc-s1:armel 10.2.0-15 124c124 < libglib2.0-0:armel2.66.0-2 --- > libglib2.0-0:armel2.66.1-1 127c127 < libgomp1:armel10.2.0-13 --- > libgomp1:armel10.2.0-15 176c176 < libocamlgraph-ocaml-dev 1.8.8-1.1+b1 --- > libocamlgraph-ocaml-dev 1.8.8-1.1+b2 203c203 < libpython3-stdlib:armel 3.8.2-3 --- > libpython3-stdlib:armel 3.8.6-1 206c206 < libre-ocaml-dev 1.9.0-1 --- > libre-ocaml-dev 1.9.0-1+b1 214,216c214,216 < libseccomp2:armel 2.4.4-1 < libselinux1:armel 3.1-2 < libselinux1-dev:armel 3.1-2 --- > libseccomp2:armel 2.4.4-1+b1 > libselinux1:armel 3.1-2+b1 > libselinux1-dev:armel 3.1-2+b1 227,228c227,228 < libstdc++-10-dev:armel10.2.0-13 < libstdc++6:armel 10.2.0-13 --- > libstdc++-10-dev:armel10.2.0-15 > libstdc++6:armel 10.2.0-15 244c244 < libubsan1:armel 10.2.0-13 --- > libubsan1:armel 10.2.0-15 260,261c260,261 < libxml2:armel 2.9.10+dfsg-6 < libxml2-dev:armel 2.9.10+dfsg-6 --- > libxml2:armel 2.9.10+dfsg-6.1 > libxml2-dev:armel
Bug#974825: dash: Relies on /usr/share/man/man1/ existing
Package: dash Version: 0.5.11+git20200708+dd9ef66-2 Severity: important Tags: patch Control: block #972571 by -1 Hi, this report is similar to https://bugs.debian.org/606756 from 2010. I also am removing documentation in /usr/share/man and this leads for the dash postinst to fail. To reproduce my findings, run: $ mmdebstrap --variant=apt --dpkgopt=path-exclude='/usr/share/man/*' unstable /dev/null Using the dpkg path-exclude functionality, no directory exists in /usr/share/man/ to save space. When running the above you will receive the following error: Setting up dash (0.5.11+git20200708+dd9ef66-2) ... No diversion 'diversion of /bin/sh by bash', none removed. Adding 'diversion of /bin/sh to /bin/sh.distrib by dash' No diversion 'diversion of /usr/share/man/man1/sh.1.gz by bash', none removed. Adding 'diversion of /usr/share/man/man1/sh.1.gz to /usr/share/man/man1/sh.distrib.1.gz by dash' ln: failed to create symbolic link '/usr/share/man/man1/sh.1.gz.tmp': No such file or directory dpkg: error processing package dash (--install): installed dash package post-installation script subprocess returned error exit status 1 The following patch to dash fixes the problem: --- a/debian/dash.postinst +++ b/debian/dash.postinst @@ -132,8 +132,10 @@ if [ $debconf ]; then db_get dash/sh if [ "$RET" = true ]; then claim_binsh /bin/sh dash + if [ -d /usr/share/man/man1/ ]; then claim_binsh /usr/share/man/man1/sh.1.gz dash.1.gz \ /usr/share/man/man1/sh.distrib.1.gz + fi else unclaim_binsh /bin/sh dash unclaim_binsh /usr/share/man/man1/sh.1.gz dash.1.gz \ Thanks! cheers, josch
Bug#974068: aho-corasick: useless description, no man page, no --help output
Package: aho-corasick Version: 0.6.9-1 Severity: important Hi, the package description says: > Description-en: Fast multiple substring searching with finite state machines > This package contains the following binaries built from the Rust crate > "aho-corasick": > - aho-corasick-dot Okay, so this tool is like grep? Or what? I installed it and found: $ man aho-corasick-dot No manual entry for aho-corasick-dot See 'man 7 undocumented' for help when manual pages are not available. When I run "aho-corasick-dot --help" I get something that looks like a graphviz dot graph. What is this tool doing? Also, when I use codesearch: https://codesearch.debian.net/search?q=This+package+contains+the+following+binaries+built+from+the+Rust+crate&literal=1 Then there are a lot of packages which just say "This package contains the following binaries built from the Rust crate" in their long description. How is this useful? Thanks! cheers, josch
Bug#973405: fakeroot on amd64 stopped supporting armel, armhf and mipsel chroots
Package: fakeroot
Version: 1.25.2-1
Severity: important
Hi,
I'm the maintainer of mmdebstrap which uses fakeroot and fakechroot to
also create foreign architecture chroots. Doing something like this
worked fine until 2020-09-15:
$ mmdebstrap --mode=fakechroot --variant=apt --arch=armhf sid ./sid-chroot
With amd64 on my machine I also tried other architectures and as of
today, the following arches result in an infinite timeout with above
command: armel, armhf, mipsel and s390x.
For armhf I was able to bisect Debian using snapshot.debian.net and find
out that the first snapshot timestamp that produces the timeout is
2020-09-15 06:00:00+01:00. For the other architectures, I am not able to
produce a precise timestamp because fakeroot suffered from #971070 and
thus I was unable to test two weeks of snapshot.d.o data.
To run the precise command producing the infinite hang, try creating a
armhf chroot using mmdebstrap (I'm unaware of another tool that is able
to create foreign architecture chroots using fakeroot and fakechroot):
$ mmdebstrap --mode=fakechroot --variant=apt --arch=armhf unstable
/tmp/debian-unstable
You have to ctrl+C above command at the "Installing..." step because
that one will stall forever. Then run:
$ fakechroot fakeroot sh -c 'env QEMU_LD_PREFIX=/tmp/debian-unstable
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/arm-linux-gnueabihf/fakechroot:/usr/lib/arm-linux-gnueabihf/libfakeroot
/usr/sbin/chroot debian-unstable dpkg --install /var/cache/apt/archives/*.deb'
If I run above via strace, then the last lines are:
1830621 msgget(0x223a3efb, IPC_CREAT|0600) = 6881280
1830621 msgget(0x223a3efc, IPC_CREAT|0600) = 6914049
1830621 getpid()= 1830621
1830621 semget(0x223a3efd, 1, IPC_CREAT|0600) = 3506176
1830621 semtimedop(3506176, [{0, -1, SEM_UNDO}], 1, NULL) = 0
1830621 msgsnd(6881280, {1,
"\0\0\0\0\3\0\0\0\335\356\33\0\1\0\0\0\350\3\0\0\350\3\0\0.0\313\0\0\0\0\0"...},
1088, 0) = 0
1830613 <... msgrcv resumed> {1,
"\0\0\0\0\3\0\0\0\335\356\33\0\1\0\0\0\350\3\0\0\350\3\0\0.0\313\0\0\0\0\0"...},
1096, 0, 0) = 1088
1830613 msgrcv(6881280,
A workaround for this problem is to explicitly use fakeroot-tcp. The
command will be much slower but it will finish successfully. So it seems
only fakeroot-sysv is broken between amd64 and armel, armhf, mipsel and s390x.
Thanks!
cheers, josch
Bug#973325: apt starts installing packages before it has ordered them
Package: apt Version: 2.1.11 Severity: important Hi, as agreed on IRC here my bugreport. I noticed this when running mmdebstrap in chrootless mode: $ ./mmdebstrap --mode=chrootless --variant=custom --include=bsdutils,coreutils,debianutils,diffutils,dpkg,findutils,grep,gzip,hostname,init-system-helpers,ncurses-base,ncurses-bin,perl-base,sed,tar unstable /dev/null [...] Reading package lists... Building dependency tree... Suggested packages: debconf-doc debconf-utils whiptail | dialog libterm-readline-gnu-perl libgtk3-perl libnet-ldap-perl perl debconf-kde-helper diffutils-doc wdiff apt debsig-verify mlocate | locate less glibc-doc libc-l10n locales rng-tools krb5-doc krb5-user sensible-utils bzip2 ncompress xz-utils tar-scripts tar-doc Recommended packages: bsdextrautils apt-utils debconf-i18n libidn2-0 libgpg-error-l10n krb5-locales The following NEW packages will be installed: bsdutils coreutils debconf debianutils diffutils dpkg findutils gcc-10-base grep gzip hostname init-system-helpers libacl1 libattr1 libbz2-1.0 libc6 libcom-err2 libcrypt1 libgcc-s1 libgcrypt20 libgmp10 libgpg-error0 libgssapi-krb5-2 libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 liblz4-1 liblzma5 libnsl2 libnss-nis libnss-nisplus libpcre2-8-0 libpcre3 libselinux1 libssl1.1 libsystemd0 libtinfo6 libtirpc-common libtirpc3 libzstd1 ncurses-base ncurses-bin perl-base sed tar zlib1g 0 upgraded, 47 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/19.2 MB of archives. After this operation, 74.5 MB of additional disk space will be used. Selecting previously unselected package gcc-10-base:amd64. (Reading database ... 0 files and directories currently installed.) Preparing to unpack .../gcc-10-base_10.2.0-15_amd64.deb ... Unpacking gcc-10-base:amd64 (10.2.0-15) ... Setting up gcc-10-base:amd64 (10.2.0-15) ... Selecting previously unselected package libcrypt1:amd64. (Reading database ... 9 files and directories currently installed.) Preparing to unpack .../libcrypt1_1%3a4.4.17-1_amd64.deb ... Unpacking libcrypt1:amd64 (1:4.4.17-1) ... Selecting previously unselected package libc6:amd64. Preparing to unpack .../libc6_2.31-4_amd64.deb ... Unpacking libc6:amd64 (2.31-4) ... Selecting previously unselected package libgcc-s1:amd64. Preparing to unpack .../libgcc-s1_10.2.0-15_amd64.deb ... Unpacking libgcc-s1:amd64 (10.2.0-15) ... Selecting previously unselected package libnss-nis:amd64. Preparing to unpack .../libnss-nis_3.1-4_amd64.deb ... Unpacking libnss-nis:amd64 (3.1-4) ... Selecting previously unselected package libnsl2:amd64. Preparing to unpack .../libnsl2_1.3.0-2_amd64.deb ... Unpacking libnsl2:amd64 (1.3.0-2) ... Selecting previously unselected package libtirpc3:amd64. Preparing to unpack .../libtirpc3_1.2.6-3_amd64.deb ... Unpacking libtirpc3:amd64 (1.2.6-3) ... Selecting previously unselected package libgssapi-krb5-2:amd64. Preparing to unpack .../libgssapi-krb5-2_1.17-10_amd64.deb ... Unpacking libgssapi-krb5-2:amd64 (1.17-10) ... Selecting previously unselected package libcom-err2:amd64. Preparing to unpack .../libcom-err2_1.45.6-1_amd64.deb ... Unpacking libcom-err2:amd64 (1.45.6-1) ... Selecting previously unselected package libk5crypto3:amd64. Preparing to unpack .../libk5crypto3_1.17-10_amd64.deb ... Unpacking libk5crypto3:amd64 (1.17-10) ... Selecting previously unselected package libkrb5support0:amd64. Preparing to unpack .../libkrb5support0_1.17-10_amd64.deb ... Unpacking libkrb5support0:amd64 (1.17-10) ... Selecting previously unselected package libkrb5-3:amd64. Preparing to unpack .../libkrb5-3_1.17-10_amd64.deb ... Unpacking libkrb5-3:amd64 (1.17-10) ... Selecting previously unselected package libkeyutils1:amd64. Preparing to unpack .../libkeyutils1_1.6.1-2_amd64.deb ... Unpacking libkeyutils1:amd64 (1.6.1-2) ... Selecting previously unselected package libssl1.1:amd64. Preparing to unpack .../libssl1.1_1.1.1h-1_amd64.deb ... Unpacking libssl1.1:amd64 (1.1.1h-1) ... Selecting previously unselected package libtirpc-common. Preparing to unpack .../libtirpc-common_1.2.6-3_all.deb ... Unpacking libtirpc-common (1.2.6-3) ... Setting up libtirpc-common (1.2.6-3) ... Selecting previously unselected package libnss-nisplus:amd64. (Reading database ... 411 files and directories currently installed.) Preparing to unpack .../libnss-nisplus_1.3-4_amd64.deb ... Unpacking libnss-nisplus:amd64 (1.3-4) ... dpkg: dependency problems prevent configuration of libcom-err2:amd64: libcom-err2:amd64 depends on libc6 (>= 2.17); however: Package libc6:amd64 is not configured yet. dpkg: error processing package libcom-err2:amd64 (--configure): dependency problems - le
Bug#973305: apt-get throws error when run with --simulate and APT::Immediate-Configure set to "false"
Package: apt Version: 2.1.11 Severity: important Hi, as discussed on IRC, I'm writing up the recent problem found by the mmdebstrap CI tests: https://ci.debian.net/data/autopkgtest/testing/arm64/m/mmdebstrap/7787391/log.gz https://ci.debian.net/data/autopkgtest/testing/arm64/m/mmdebstrap/7790646/log.gz https://ci.debian.net/data/autopkgtest/unstable/amd64/m/mmdebstrap/7789206/log.gz The apt output from the last log: E: Couldn't configure debconf:amd64, probably a dependency cycle. W: Could not perform immediate configuration on 'libssl1.1:amd64'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) E: Could not configure 'libc6:amd64'. W: Could not perform immediate configuration on 'libkrb5-3:amd64'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) E: Could not configure 'libc6:amd64'. W: Could not perform immediate configuration on 'libgssapi-krb5-2:amd64'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) E: Could not configure 'libc6:amd64'. W: Could not perform immediate configuration on 'libtirpc3:amd64'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) E: Could not configure 'libc6:amd64'. W: Could not perform immediate configuration on 'libnsl2:amd64'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) E: Could not configure 'libc6:amd64'. W: Could not perform immediate configuration on 'libnss-nis:amd64'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) E: Couldn't configure debconf:amd64, probably a dependency cycle. W: Could not perform immediate configuration on 'libnss-nisplus:amd64'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) E: Couldn't configure debconf:amd64, probably a dependency cycle. W: Could not perform immediate configuration on 'libc6:amd64'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) E: Couldn't configure debconf:amd64, probably a dependency cycle. E: apt-get --yes -oApt::Get::Download-Only=true -oAPT::Get::Simulate=true dist-upgrade -oAPT::Status-Fd=<$fd> -oDpkg::Use-Pty=false failed To reproduce this problem with mmdebstrap, run: $ mmdebstrap --dry-run --variant=apt unstable /dev/null Particularly, the problem does *not* occur without --dry-run. Normal installation works fine. To reproduce the problem without mmdebstrap, use: $ cat << END > apt.conf > Apt::Architecture "amd64"; > Apt::Architectures "amd64"; > Dir "/tmp/apt"; > Dir::State::Status "/tmp/apt/var/lib/dpkg/status"; > Dir::Etc::Trusted "/etc/apt/trusted.gpg"; > Dir::Etc::TrustedParts "/etc/apt/trusted.gpg.d/"; > APT::Immediate-Configure "false"; > END $ mkdir -p /tmp/apt/etc/apt $ echo "deb http://deb.debian.org/debian unstable main" > /tmp/apt/etc/apt/sources.list $ mkdir -p /tmp/apt/var/lib/apt/lists/partial $ mkdir -p /tmp/apt/var/lib/dpkg/ $ touch /tmp/apt/var/lib/dpkg/status $ APT_CONFIG=apt.conf apt-get --yes -oAPT::Get::Simulate=true dist-upgrade [...] E: Conf Broken libpam0g:amd64 E: Conf Broken libpam-modules:amd64 E: Conf Broken adduser:amd64 E: Conf Broken libssl1.1:amd64 $ echo $? 100 Thanks! cheers, josch
Bug#973261: libhdf5-openmpi-dev: installing requires /proc being mounted
Package: libhdf5-openmpi-dev Version: 1.10.6+repack-2 Severity: wishlist Hi, when installing libhdf5-openmpi-dev in a chroot that doesn't have /proc mounted, one will get the following error: Setting up libhdf5-openmpi-dev (1.10.6+repack-2) ... /var/lib/dpkg/info/libhdf5-openmpi-dev.postinst: line 56: /dev/fd/63: No such file or directory dpkg: error processing package libhdf5-openmpi-dev (--configure): installed libhdf5-openmpi-dev package post-installation script subprocess returned error exit status 1 The problem is, that the postinst script uses the bash-feature to write: while read x; do ... done < <(cmd2 args ...) Fortunately, these instances can easily be rewritten as: cmd2 args | while read x; do ... done Please consider making this change. Thanks! cheers, josch
Bug#973029: debhelper: allowing verbose gmock builds
Package: debhelper Version: 13.1 Severity: wishlist Hi, I'm unsure which component should best take care of this, so please re-assign as needed. The high-level problem: For our our ROS packages, upstream uses GMock to run build and run tests. This requires including /usr/src/googletest/ as a CMake subproject and building parts of it. It turns out, that this build will not be done verbosely and thus blhc as run by salsa CI will fail. We approached CMake upstream about this issue [1] and they suggested to just run our builds with make VERBOSE=1. Indeed this produces the verbose output that makes blhc happy. The problem is, that we now have to have this boilerplate for all ROS packages using GMock (we use --buildsystem=pybuild): override_dh_auto_build: dh_auto_build -- --build-args=VERBOSE=1 Since we want project-wide verbose build logs anyways (right?), maybe this kind of thing can be implemented for all of Debian "somewhere". Maybe in debhelper? Thanks! cheers, josch [1] https://gitlab.kitware.com/cmake/cmake/-/issues/21360
Bug#972401: nmu: dose3_5.0.1-14+b3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, currently, my package botch FTBFS on OCaml bytecode architectures because dose3 tools are broken there: https://buildd.debian.org/status/package.php?p=botch&suite=sid To reproduce the error, install dose-extra on armel and run "dose-deb-coinstall --help". I rebuilt dose3 on armel and the problem was gone -- probably fixed by the current OCaml transition. nmu dose3_5.0.1-14+b3 . armel mips64el mipsel alpha hppa ia64 m68k powerpc sh4 sparc64 x32 . unstable . -m "rebuild to fix broken bytecode executables" Thanks! cheers, josch
Bug#971070: fakeroot 1.25.1-1 breaks mmdebstrap
Package: fakeroot Version: 1.25.1-1 Severity: important Dear fakeroot maintainers, your recent upload of fakeroot broke my package mmdebstrap in a way that I do not yet understand. See for example this CI test which uses fakeroot via fakechroot: https://ci.debian.net/data/autopkgtest/testing/amd64/m/mmdebstrap/7190912/log.gz I get an even different error when running mmdebstrap locally with the new fakeroot version on my system: $ mmdebstrap --variant=apt --mode=fakechroot unstable /dev/null fakechroot: nested operation is not supported E: need working fakechroot binary If I downgrade fakeroot like this: $ sudo apt install fakeroot=1.24-1 libfakeroot=1.24-1 then everything works fine again. Maybe you can shed some light on the situation about what might've changed between 1.24-1 and 1.25.1-1 that leads to these problems? Thanks! cheers, josch
Bug#969956: hurd: replace build profile noprof with pkg.hurd.noprof
Source: hurd Version: 1:0.9.git20200718-1 Severity: normal Hi, src:hurd uses the build profile "noprof" which is not documented: https://wiki.debian.org/BuildProfileSpec Please replace it with a source-package-specific build profile like pkg.hurd.noprof. Thanks! cheers, josch
Bug#969605: snapshot.debian.org: please make it possible to figure out which timestamp one is currently using
Package: snapshot.debian.org Severity: wishlist Hi, this wishlist bug was made in the context of the development of debbisect: https://salsa.debian.org/debian/devscripts/-/merge_requests/177/ Currently it is possible to pass an arbitrary timestamp of the form %Y%m%dT%H%M%SZ in a snapshot.d.o URL and one will still get some results. This is cool but it would be nice if there was a way to find out which snapshot timestamp one actually ended up using. Given two timestamps X and Y which are closer together than six hours, it is currently very hard to determine (one would have to download and compare Packages and Sources files) whether one is looking at the same snapshot or different snapshots. In the context of debbisect, knowing the precise timestamp one is currently investigating would help in determining which snapshot to investigate next. This wishlist bug could either be solved by - documenting how an arbitrary date is turned into a snapshot timestamp (this would probably require a machine readable list of all snapshot timestamps -- see #969603) or by - providing an API function which turns an arbitrary date into a snapshot timestamp Thanks! cheers, josch
Bug#969603: snapshot.debian.org: please provide a machine readable list of snapshot timestamps
Package: snapshot.debian.org Severity: wishlist Hi, this wishlist bug was made in the context of the development of debbisect: https://salsa.debian.org/debian/devscripts/-/merge_requests/177/ Currently, the debbisect tool makes use of the feature of snapshot.d.o which allows to request an arbitrary timestamp and still get valid data. The debbisect tool stops when two timestamps are closer than six hours apart. While this works reasonably well, it currently makes it impossible to implement a way where the user can skip a certain snapshot because we don't know which snapshot a timestamp was resolving to and we cannot compute the next snapshot before or after the skipped one. Thus my wishlist bug: please provide a machine readable way to retrieve all timestamps that snapshot.d.o collected data for. Thanks! cheers, josch
Bug#969331: rviz: [rospack] Error: no such package media_export
Package: rviz Version: 1.14.1+dfsg-1 Severity: grave Justification: renders package unusable Hi, starting rviz on Debian unstable currently yields the following output: [ INFO] [1598885512.042478573]: rviz version 1.14.1 [ INFO] [1598885512.042531596]: compiled against Qt version 5.14.2 [ INFO] [1598885512.042547093]: compiled against OGRE version 1.9.0 (Ghadamon) [ INFO] [1598885512.052974842]: Forcing OpenGl version 0. [ INFO] [1598885512.592152405]: Stereo is NOT SUPPORTED [ INFO] [1598885512.592246596]: OpenGl version: 4.6 (GLSL 4.6). [rospack] Error: no such package media_export [librospack]: error while executing command zsh: segmentation fault rviz Maybe triggered by this line? https://sources.debian.org/src/ros-rviz/1.14.1+dfsg-1/src/rviz/ogre_helpers/render_system.cpp/?hl=316#L318 According to the package.xml, rviz depends on media_export but that one is not packaged yet? Thanks! cheers, josch -- System Information: Debian Release: bullseye/sid APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rviz depends on: ii fonts-liberation 1:1.07.4-9 ii libboost-filesystem1.71.0 1.71.0-6+b2 ii libboost-thread1.71.0 1.71.0-6+b2 ii libc6 2.31-2 ii libclass-loader1d 0.5.0-1 ii libconsole-bridge0.4 0.4.3+dfsg-1 ii libgcc-s1 10.2.0-3 ii libimage-transport0d 1.12.0-1+b1 ii libinteractive-markers2d 1.12.0-3 ii liblaser-geometry0d1.6.5-1+b1 ii libmessage-filters1d 1.15.8+ds1-1 ii libogre-1.9.0v51.9.0+dfsg1-12+b1 ii libopengl0 1.3.1-1 ii libqt5core5a 5.14.2+dfsg-4 ii libqt5gui5 5.14.2+dfsg-4 ii libqt5svg5 5.14.2-2 ii libqt5widgets5 5.14.2+dfsg-4 ii librosconsole3d1.14.2-1 ii libroscpp-serialization0d 0.7.2-2 ii libroscpp3d1.15.8+ds1-1 ii libroslib0d1.15.4-2 ii librostime1d 0.7.2-4 ii librviz5d 1.14.1+dfsg-1 ii libstdc++6 10.2.0-3 ii libtf2-2d 0.7.2-3 ii libtinyxml2-8 8.0.0+dfsg-2 ii liburdf1d 1.13.2-2 ii liburdfdom-world 1.0.3-1 rviz recommends no packages. rviz suggests no packages. -- no debconf information
Bug#969232: AttributeError: 'GTlsClientConnectionGnutls' object has no attribute 'set_advertised_protocols'
Package: python3-nbxmpp
Version: 1.0.1-1
Severity: normal
Hi,
when starting gajim I got the following traceback:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/nbxmpp/tcp.py", line 140, in
_on_connect_finished
self._on_connected()
File "/usr/lib/python3/dist-packages/nbxmpp/tcp.py", line 143, in
_on_connected
self.notify('connected')
File "/usr/lib/python3/dist-packages/nbxmpp/util.py", line 491, in notify
func(self, signal_name, *args, **kwargs)
File "/usr/lib/python3/dist-packages/nbxmpp/client.py", line 424, in
_on_connected
self.set_state(StreamState.CONNECTED)
File "/usr/lib/python3/dist-packages/nbxmpp/client.py", line 239, in set_state
self._xmpp_state_machine()
File "/usr/lib/python3/dist-packages/nbxmpp/client.py", line 576, in
_xmpp_state_machine
self._con.start_tls_negotiation()
File "/usr/lib/python3/dist-packages/nbxmpp/tcp.py", line 175, in
start_tls_negotiation
tls_client.set_advertised_protocols(['xmpp-client'])
AttributeError: 'GTlsClientConnectionGnutls' object has no attribute
'set_advertised_protocols'
The problem got fixed by upgrading gir1.2-glib-2.0 on my system from
1.58.3-2 to 1.64.1-1. So somewhere a version constraint is missing.
Thanks!
cheers, josch
Bug#968571: apt: print-uri and apt-helper documentation enhancements
Package: apt Version: 2.1.10 Severity: wishlist Hi, some possible improvements to documentation as mentioned on IRC. 1. add more information to the --help output of apt-helper: a) multiple things can be downloaded in the same call 17:05 < juliank> download-file [ uri target-path [hash...] ]... b) Checksum-FileSize: or SHA256: can be added at the end c) target is the output filename and not a directory 2. make it clear that nothing will be printed with --print-uris in case the file that is to be downloaded already exists. Currently the docs say "Instead of fetching the files to install their URIs are printed". Independent of whether the resulting files already exists, they will not get downloaded and thus my expectation from reading this sentence is, that nothing gets downloaded with --print-uris anyways, then their URIs are *always* printed. With the current behavior the only reliable way to retrieve filenames is to execute "apt-get download --print-uris" in a new and empty directory. Since this is the *only* reliable way, maybe that information should also be documented. Thanks! cheers, josch
Bug#968217: python is priority:standard but not installable
Package: python Version: 2.7.17-2 Severity: grave Justification: renders package unusable Hi, the python package is currently uninstallable in Debian unstable: output-version: 1.2 report: - package: python version: 2.7.17-2 architecture: amd64 status: broken reasons: - missing: pkg: package: libpython-stdlib version: 2.7.17-2 architecture: amd64 unsat-dependency: libpython2-stdlib (= 2.7.17-2) depchains: - depchain: - package: python version: 2.7.17-2 architecture: amd64 depends: libpython-stdlib (= 2.7.17-2) Maybe this is intentional because of the imminent removal of python 2. What is problematic here is, that python is also priority:standard. My package mmdebstrap is a debootstrap replacement and in addition to being able to install packages with priorities required and important, it can also install all packages with priority standard. If a package from the priority:standard set is not installable, then this also breaks the unit tests and autopkgtest of mmdebstrap and thus, python not being installable is currently blocking my mmdebstrap development. I see several ways to resolve this: - fix the installability problem (there seems to be a version mismatch) - remove the python package - adjust the priority to something less important than "standard" - add a rule to mmdebstrap to ignore a package named python Since the uninstallability has now been a thing for over a week, I'm filing this bug to inquire about the best way forward. Thanks! cheers, josch
Bug#964501: alot: Fix mailcap rendering for e-mails without `Content-Type` header
Package: alot
Version: 0.9.1-1
Severity: normal
Hi,
currently, alot is unable to handle emails without a Content-Type
header (traceback at the end of this mail).
Luckily there is a patch that fixes this problem:
https://github.com/pazz/alot/commit/2348014eb6d654ef123c6c353d2dc4306f226305
Can we backport this patch?
If you don't have time in the next few days, then I can also do an NMU,
just tell me what works for you. :)
Thanks!
cheers, josch
Traceback (most recent call last):
File "/home/josch/git/alot/alot/ui.py", line 277, in apply_commandline
await apply_this_command(c)
File "/home/josch/git/alot/alot/ui.py", line 725, in apply_command
self._error_handler(e)
File "/home/josch/git/alot/alot/ui.py", line 160, in _error_handler
self.notify(msg, priority='error')
File "/home/josch/git/alot/alot/ui.py", line 624, in notify
self.update()
File "/home/josch/git/alot/alot/ui.py", line 668, in update
self.mainloop.draw_screen()
File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 586, in
draw_screen
canvas = self._topmost_widget.render(self.screen_size, focus=True)
File "/usr/lib/python3/dist-packages/urwid/widget.py", line 144, in
cached_render
canv = fn(self, size, focus=focus)
File "/usr/lib/python3/dist-packages/urwid/decoration.py", line 226, in render
canv = self._original_widget.render(size, focus=focus)
File "/usr/lib/python3/dist-packages/urwid/widget.py", line 144, in
cached_render
canv = fn(self, size, focus=focus)
File "/usr/lib/python3/dist-packages/urwid/container.py", line 1085, in render
body = self.body.render((maxcol, maxrow-ftrim-htrim),
File "/home/josch/git/alot/alot/buffers/buffer.py", line 19, in render
return self.body.render(size, focus)
File "/usr/lib/python3/dist-packages/urwid/widget.py", line 144, in
cached_render
canv = fn(self, size, focus=focus)
File "/usr/lib/python3/dist-packages/urwid/listbox.py", line 470, in render
middle, top, bottom = self.calculate_visible(
File "/usr/lib/python3/dist-packages/urwid/listbox.py", line 356, in
calculate_visible
focus_widget, focus_pos = self._body.get_focus()
File "/home/josch/git/alot/alot/walker.py", line 39, in get_focus
return self._get_at_pos(self.focus)
File "/home/josch/git/alot/alot/walker.py", line 72, in _get_at_pos
widget = self._get_next_item()
File "/home/josch/git/alot/alot/walker.py", line 85, in _get_next_item
next_widget = self.containerclass(next_obj, **self.kwargs)
File "/home/josch/git/alot/alot/widgets/search.py", line 26, in __init__
self.rebuild()
File "/home/josch/git/alot/alot/widgets/search.py", line 60, in rebuild
width, part = build_text_part(partname, self.thread,
File "/home/josch/git/alot/alot/widgets/search.py", line 145, in
build_text_part
content = prepare_string(name, thread, maxw)
File "/home/josch/git/alot/alot/widgets/search.py", line 213, in
prepare_string
s = content(thread)
File "/home/josch/git/alot/alot/widgets/search.py", line 188, in
prepare_content_string
lastcontent = ' '.join(m.get_body_text() for m in msgs)
File "/home/josch/git/alot/alot/widgets/search.py", line 188, in
lastcontent = ' '.join(m.get_body_text() for m in msgs)
File "/home/josch/git/alot/alot/db/message.py", line 280, in get_body_text
return extract_body_part(self.mime_part)
File "/home/josch/git/alot/alot/db/utils.py", line 501, in extract_body_part
rendered_payload = render_part(
File "/home/josch/git/alot/alot/db/utils.py", line 368, in render_part
parms = tuple('='.join(p) for p in part.get_params())
TypeError: 'NoneType' object is not iterable
Bug#964391: alot: Fix utf8 encoding with a text/plain mailcap entry.
Package: alot Version: 0.9.1-1 Severity: normal Hi, currently, alot is unable to handle emails with: Content-Type: text/plain; charset="utf-8"; format="flowed" Example: "Mit freundlichen Gr��en" gets rendered where it should say "Mit freundlichen Grüßen" Luckily there is a patch that fixes this problem: https://github.com/pazz/alot/commit/37395809db473fb9a4157084a5b1ea3165914556 Can we backport this patch? If you don't have time in the next few days, then I can also do an NMU, just tell me what works for you. :) Thanks! cheers, josch
Bug#963788: systemd: please make user order and ids of systemd and systemd-timesyncd reproducible
Source: systemd
Severity: normal
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
Hi,
the packages systemd and systemd-timesyncd depend on each other. This
means, that they form a dependency cycle and it is impossible to figure
out whether the postinst script of systemd or systemd-timesyncd should
be executed first. But depending on which postinst script is executed
first, the systemd-{journal,network,resolve} users from the systemd
postinst and the systemd-timesync user from the systemd-timesyncd
package will end up with differing user ids because they are chosen
sequentially, starting with 101. In addition to the user ids, the order
of users and their associated groups will differ in /etc/shadow,
/etc/passwd, /etc/group and associated files.
This is problem for reproducible installations because the exact same
package set, consisting of systemd and systemd-timesyncd can result in a
different system after installation.
Thanks!
cheers, josch
Bug#962741: apt: illegal package name in EDSP Provides field when installing from *.deb
Package: apt Version: 2.1.6 Severity: normal Hi, steps to reproduce: $ cd /tmp $ equivs-build /usr/share/doc/equivs/examples/webserver.ctl $ APT_EDSP_DUMP_FILENAME=/tmp/dump.edsp apt install --simulate --solver dump /tmp/webserver-dummy_1.0_all.deb $ grep webserver-dummy /tmp/dump.edsp Install: webserver-dummy:amd64 Package: webserver-dummy Source: webserver-dummy Provides: /tmp/webserver-dummy_1.0_all.deb (= 1.0), httpd, httpd, httpd The problem is, that the full path of the *.deb file is added to the EDSP Provides field but even the package filename by itself is not a valid package name. Consequently, apt-cudf will error out when it receives such an EDSP file. Thanks! cheers, josch
Bug#961909: ghostscript: PDFA_def.ps references srgb.icc with relative path
Package: ghostscript Version: 9.27~dfsg-2+deb10u3 Severity: normal Hi, using /usr/share/ghostscript/9.27/lib/PDFA_def.ps I can convert a PDF into PDF/A-1b like so: $ env --chdir=/usr/share/color/icc/ghostscript/ gs -dBATCH -dNOPAUSE \ > -dSAFEGR -dPDFA=1 -sProcessColorModel=DeviceRGB -dPDFACompatibilityPolicy=1 > -sDEVICE=pdfwrite -sOutputFile=/tmp/out.pdf \ > /usr/share/ghostscript/9.27/lib/PDFA_def.ps \ > in.pdf Using "env --chdir" as well as using an absolute path for OutputFile is necessary because PDFA_def.ps references srgb.icc with a relative path in /usr/share/color/icc/ghostscript/ -- this means that unless the command is executed in /usr/share/color/icc/ghostscript/, PDFA_def.ps is useless and must be edited to contain the right absolute path to srgb.icc. I propose to either: - move PDFA_def.ps to /usr/share/doc/*/examples because it's a file that cannot be used immediately but has to be edited first - patch PDFA_def.ps to include the full path to /usr/share/color/icc/ghostscript/srgb.icc so that it can be used from any directory Thanks! cheers, josch
Bug#958751: libguestfs-tools: guestfish fails on arm64
Package: libguestfs-tools Version: 1:1.40.2-7+b1 Severity: important Hi, running guestfish on arm64 fails. See for example the result of my genext2fs autopkgtest on arm64: https://ci.debian.net/data/autopkgtest/testing/arm64/g/genext2fs/5128192/log.gz I was able to reproduce the problem on the arm64 porterbox and re-ran guestfish with LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1. Probably relevant output: /usr/bin/qemu-system-aarch64 \ -global virtio-blk-pci.scsi=off \ -no-user-config \ -enable-fips \ -nodefaults \ -display none \ -machine virt,gic-version=host,accel=kvm:tcg \ -cpu host \ -m 1024 \ -no-reboot \ -rtc driftfix=slew \ -kernel /var/tmp/.guestfs-3341/appliance.d/kernel \ -initrd /var/tmp/.guestfs-3341/appliance.d/initrd \ -object rng-random,filename=/dev/urandom,id=rng0 \ -device virtio-rng-pci,rng=rng0 \ -device virtio-scsi-pci,id=scsi \ -drive file.file.filename=/tmp/libguestfs6x5WRv/overlay1.qcow2,file.driver=qcow2,file.backing.file.locking=off,cache=unsafe,id=hd0,if=none \ -device scsi-hd,drive=hd0 \ -drive file=/var/tmp/.guestfs-3341/appliance.d/root,snapshot=on,id=appliance,cache=unsafe,if=none,format=raw \ -device scsi-hd,drive=appliance \ -device virtio-serial-pci \ -serial stdio \ -chardev socket,path=/tmp/libguestfs6AGQyv/guestfsd.sock,id=channel0 \ -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ -append "panic=1 console=ttyAMA0 earlyprintk=pl011,,0x900 ignore_loglevel efi-rtc=noprobe edd=off udevtimeout=6000 udev.event-timeout=6000 no_timer_check printk.time=1 cgroup_disable=memory usbcore.nousb cryptomgr.notests tsc=reliable 8250.nr_uarts=1 root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=linux" WARNING: Image format was not specified for '/tmp/libguestfs6x5WRv/overlay1.qcow2' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. Could not access KVM kernel module: No such file or directory qemu-system-aarch64: failed to initialize KVM: No such file or directory qemu-system-aarch64: Back to tcg accelerator qemu-system-aarch64: gic-version=host requires KVM According to this output, the problem seems to be, that guestfish calls qemu with -machine virt,gic-version=host,accel=kvm:tcg but without kvm, the gic-version=host argument seems to be invalid. This seems to be the relevant part in the source code: https://sources.debian.org/src/libguestfs/1:1.40.2-7/lib/launch-direct.c/?hl=509#L509 Accordingly, the problem vanishes if I run guestfish with LIBGUESTFS_BACKEND_SETTINGS=force_tcg. Thanks! cheers, josch
Bug#958362: pdfrw: fails with python 3.7+ -- abandoned upstream
Source: pdfrw Version: 0.4-2 Severity: grave Justification: renders package unusable Hi, the package fails with Python 3.7 and newer. Starting from Python 3.7, StopIteration is a RuntimeError (see PEP 479). But pdfrw still uses StopIteration: https://github.com/pmaupin/pdfrw/issues/145 https://github.com/pmaupin/pdfrw/issues/199 This package recently got its python2 package removed but since tests are disabled, nobody noticed that its tests fail with Python 3.7+: https://github.com/pmaupin/pdfrw/issues/198 https://github.com/pmaupin/pdfrw/issues/197 Other upstream bugs indicating that the package is broken on Python3: https://github.com/pmaupin/pdfrw/issues/193 https://github.com/pmaupin/pdfrw/issues/170 Upstream didn't close bugs for two years and the last commit was more than two years ago. Upstream admits not having time at the moment here: https://github.com/pmaupin/pdfrw/issues/195 And is looking for additional maintainers here: https://github.com/pmaupin/pdfrw/issues/191 In this state, pdfrw should not be included in the next Debian stable release. Thanks! cheers, josch -- System Information: Debian Release: bullseye/sid APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#956076: ITP: plakativ -- print poster from PDF across multiple pages to glue together
Package: wnpp Severity: wishlist Owner: Johannes 'josch' Schauer * Package name: plakativ Version : 0.2 Upstream Author : Johannes 'josch' Schauer * URL : https://gitlab.mister-muffin.de/josch/plakativ * License : GPL3 Programming Lang: Python Description : print poster from PDF across multiple pages to glue together You have a page as a PDF and you want to make a poster from it but you only have a normal office printer, so you need to print the PDF across multiple pages that you can glue together later. The resulting PDF will contain a lossless version of the original, split across multiple pages. In addition to a regular grid, it can also generate complex layouts that make nearly optimal use of paper area to avoid paper waste. In contrast to PosteRazor, the input is a PDF file and not a raster image. This is especially important for posters, as scaling up raster images will create pixelation artifacts. In contrast to pdfposter there is a GUI that previews the result, borders for glueing are taken into account, no superfluous empty pages are produced and the complex layouter will save paper.
Bug#955373: python-miio: stuck in experimental because of python3-construct
Source: python-miio Version: 0.4.4-1 Severity: normal The package build depends on python3-construct (>= 2.9.45) but only version 2.8.16 is in unstable.
Bug#954871: genext2fs: please package the new upstream release
Package: genext2fs Version: 1.4.1-4 Severity: wishlist Hi, upstream released a new version 1.4.2 it would be nice if it could be packaged. Thanks! cheers, josch
Bug#954374: libc6: please make maintainerscript compatible with busybox
Package: libc6 Version: 2.30-2 Severity: wishlist Hi, would it be possible to make the libc6 preinst maintainer script compatible with busybox? Currently the preinst script calls "readlink -m" which is not supported by busybox. Hence the following error will be thrown: BusyBox v1.30.1 (Debian 1:1.30.1-4) multi-call binary. Usage: readlink [-fnv] FILE Display the value of a symlink -f Canonicalize by following all symlinks -n Don't add newline -v Verbose I tried to prepare a patch for the preinst script but ran into a FTBFS: x86_64-linux-gnu-gcc-9 -shared -static-libgcc -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2 -B/<>/build-tree/amd64-libc/csu/ -Wl,--version-script=/<>/build-tree/amd64-libc/libnss_files.map -Wl,-soname=libnss_files.so.2 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -L/<>/build-tree/amd64-libc -L/<>/build-tree/amd64-libc/math -L/<>/build-tree/amd64-libc/elf -L/<>/build-tree/amd64-libc/dlfcn -L/<>/build-tree/amd64-libc/nss -L/<>/build-tree/amd64-libc/nis -L/<>/build-tree/amd64-libc/rt -L/<>/build-tree/amd64-libc/resolv -L/<>/build-tree/amd64-libc/mathvec -L/<>/build-tree/amd64-libc/support -L/<>/build-tree/amd64-libc/nptl -Wl,-rpath-link=/<>/build-tree/amd64-libc:/<>/build-tree/amd64-libc/math:/<>/build-tree/amd64-libc/elf:/<>/build-tree/amd64-libc/dlfcn:/<>/build-tree/amd64-libc/nss:/<>/build-tree/amd64-libc/nis:/<>/build-tree/amd64-libc/rt:/<>/build-tree/amd64-libc/resolv:/<>/build-tree/amd64-libc/mathvec:/<>/build-tree/amd64-libc/support:/<>/build-tree/amd64-libc/nptl -o /<>/build-tree/amd64-libc/nss/libnss_files.so /<>/build-tree/amd64-libc/csu/abi-note.o -Wl,--whole-archive /<>/build-tree/amd64-libc/nss/libnss_files_pic.a -Wl,--no-whole-archive -Wl,--start-group /<>/build-tree/amd64-libc/linkobj/libc.so /<>/build-tree/amd64-libc/libc_nonshared.a -Wl,--as-needed /<>/build-tree/amd64-libc/elf/ld.so -Wl,--no-as-needed -Wl,--end-group /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libselinux.so: undefined reference to `gettid@GLIBC_2.30' collect2: error: ld returned 1 exit status Thus, I'm now reporting this wishlist bug here before further working on a fix. Would you be willing to accept a change that makes the preinst script of libc6 compatible with readlink from busybox? Thanks! cheers, josch -- System Information: Debian Release: bullseye/sid APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#953861: debootstrap: buildd variant uselessly includes libgcc1
Package: debootstrap Version: 1.0.121 Severity: normal Hi, steps to reproduce: $ sudo debootstrap --variant=buildd unstable debian-unstable The resulting chroot will include the package libgcc1 *and* libgcc-s1. The former is useless because the latter provides the former. Thanks! cheers, josch -- System Information: Debian Release: bullseye/sid APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debootstrap depends on: ii wget 1.20.1-1.1 Versions of packages debootstrap recommends: ii arch-test 0.15-2 ii debian-archive-keyring 2019.1 ii gnupg 2.2.19-2 Versions of packages debootstrap suggests: pn squid-deb-proxy-client ii ubuntu-keyring [ubuntu-archive-keyring] 2018.09.18.1-5 -- debconf-show failed
Bug#953617: E: Release file for ... is expired
Package: debootstrap Version: 1.0.121 Severity: normal Hi, the autopkgtest of debuerreotype fails because debootstrap attempts to run "apt-get update". See this log for details: https://ci.debian.net/data/autopkgtest/testing/amd64/d/debuerreotype/4521193/log.gz E: Release file for http://snapshot.debian.org/archive/debian/20170101T00Z/dists/stretch/InRelease is expired (invalid since 1158d 0h 32min 57s). Updates for this repository will not be applied. Thanks! cheers, josch -- System Information: Debian Release: bullseye/sid APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debootstrap depends on: ii wget 1.20.1-1.1 Versions of packages debootstrap recommends: ii arch-test 0.15-2 ii debian-archive-keyring 2019.1 ii gnupg 2.2.19-2 Versions of packages debootstrap suggests: pn squid-deb-proxy-client ii ubuntu-keyring [ubuntu-archive-keyring] 2018.09.18.1-5 -- debconf-show failed
Bug#953594: debootstrap: not anymore possible to do stable debootstrap from snapshot.d.o
Package: debootstrap Version: 1.0.121 Severity: normal Hi, when I debootstrap a stable release from snapshot.d.o, the security mirror gets added to the sources.list and an upgrade is performed. There is no option to prevent this from happening. This means that I cannot anymore create a chroot of a specific stable snapshot with debootstrap because debootstrap will enforce an upgrade from the current security mirror. I think it should be possible to use debootstrap for this purpose. Thanks! cheers, josch -- System Information: Debian Release: bullseye/sid APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debootstrap depends on: ii wget 1.20.1-1.1 Versions of packages debootstrap recommends: ii arch-test 0.15-2 ii debian-archive-keyring 2019.1 ii gnupg 2.2.19-2 Versions of packages debootstrap suggests: pn squid-deb-proxy-client ii ubuntu-keyring [ubuntu-archive-keyring] 2018.09.18.1-5 -- no debconf information
Bug#953593: debootstrap: --no-check-gpg and --keyring options not working with Debian stable chroots
Package: debootstrap Version: 1.0.121 Severity: normal Hi, the --keyring and --no-check-gpg options do not seem to be passed on to "apt-get update". When I try to debootstrap with these options I get in my debootstrap.log: Ign:1 http://127.0.0.1:8000/debian stable InRelease Hit:2 http://127.0.0.1:8000/debian stable Release Ign:3 http://127.0.0.1:8000/debian stable Release.gpg Get:4 http://security.debian.org/debian-security stable/updates InRelease [65.4 kB] Get:5 http://security.debian.org/debian-security stable/updates/main amd64 Packages [182 kB] Get:6 http://security.debian.org/debian-security stable/updates/main Translation-en [96.0 kB] Reading package lists... E: The repository 'http://127.0.0.1:8000/debian stable Release' is not signed. The rest of debootstrap before worked fine because I used --no-check-gpg but it fails at this step. Same with the --keyring option. Thanks! cheers, josch -- System Information: Debian Release: bullseye/sid APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debootstrap depends on: ii wget 1.20.1-1.1 Versions of packages debootstrap recommends: ii arch-test 0.15-2 ii debian-archive-keyring 2019.1 ii gnupg 2.2.19-2 Versions of packages debootstrap suggests: pn squid-deb-proxy-client ii ubuntu-keyring [ubuntu-archive-keyring] 2018.09.18.1-5 -- no debconf information
Bug#953592: mmdebstrap: autopkgtest fails
Package: mmdebstrap Version: 0.6.0-4 Severity: normal mmdebstrap compares its output to debootstrap in its autopkgtest. But currently, debootstrap fails to create a stable chroot for mirrors without translations enabled. This breaks the autopkgtest of mmdebstrap. -- System Information: Debian Release: bullseye/sid APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mmdebstrap depends on: ii apt 1.9.10 ii perl 5.30.0-9 Versions of packages mmdebstrap recommends: ii arch-test 0.15-2 ii fakechroot 2.19-3.2 ii fakeroot1.24-1 ii gpg 2.2.19-2 ii mount 2.34-0.1 ii uidmap 1:4.5-1.1 Versions of packages mmdebstrap suggests: ii binfmt-support2.2.0-2 ii dpkg-dev 1.19.7 ii perl-doc 5.30.0-9 ii proot 5.1.0-1.3 ii qemu-user 1:3.1+dfsg-8+deb10u4 ii qemu-user-static 1:4.2-3 -- debconf-show failed
Bug#953588: debootstrap: fails for mirrors without translations
Package: debootstrap Version: 1.0.121 Severity: normal Hi, recent debootstrap fails silently if the given mirror does not contain translations. From debootstrap.log: Ign:1 http://127.0.0.1/debian stable InRelease Hit:2 http://127.0.0.1/debian stable Release Ign:4 http://127.0.0.1/debian stable/main Translation-en Ign:4 http://127.0.0.1/debian stable/main Translation-en Ign:4 http://127.0.0.1/debian stable/main Translation-en Err:4 http://127.0.0.1/debian stable/main Translation-en 404 File not found [IP: 127.0.0.1 80] Get:5 http://security-cdn.debian.org/debian-security stable/updates InRelease [65.4 kB] Get:6 http://security-cdn.debian.org/debian-security stable/updates/main amd64 Packages [182 kB] Get:7 http://security-cdn.debian.org/debian-security stable/updates/main Translation-en [96.0 kB] Fetched 343 kB in 1s (501 kB/s) Reading package lists... E: Failed to fetch http://127.0.0.1/debian/dists/stable/main/i18n/Translation-en 404 File not found [IP: 127.0.0.1 80] E: Some index files failed to download. They have been ignored, or old ones used instead. Another problem is, that this happens silently after the message "I: Base system installed successfully." I noticed the problem because my shell is printing the exit status of the last command but other users might just think that debootstrap finished successfully. There should definitely be some kind of error message when apt fails. Best including either the reason or a pointer to debootstrap.log which is currently not documented in the man page. Thanks! cheers, josch -- System Information: Debian Release: bullseye/sid APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debootstrap depends on: ii wget 1.20.1-1.1 Versions of packages debootstrap recommends: ii arch-test 0.15-2 ii debian-archive-keyring 2019.1 ii gnupg 2.2.19-2 Versions of packages debootstrap suggests: pn squid-deb-proxy-client ii ubuntu-keyring [ubuntu-archive-keyring] 2018.09.18.1-5 -- debconf-show failed
Bug#953404: debootstrapping testing and stable results in exit 100
Package: debootstrap Version: 1.0.120 Severity: grave Justification: renders package unusable Hi, steps to reproduce: $ sudo debootstrap --variant=minbase stable debian-stable [...] $ echo $? 100 It works for unstable though. Thanks! cheers, josch -- System Information: Debian Release: bullseye/sid APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debootstrap depends on: ii wget 1.20.1-1.1 Versions of packages debootstrap recommends: ii arch-test 0.15-2 ii debian-archive-keyring 2019.1 ii gnupg 2.2.19-2 Versions of packages debootstrap suggests: pn squid-deb-proxy-client ii ubuntu-keyring [ubuntu-archive-keyring] 2018.09.18.1-5 -- no debconf information
Bug#953260: E: Could not perform immediate configuration on 'libgcc1:amd64'.
Package: apt Version: 1.9.10 Severity: normal Hi, recently mmdebstrap gained a new feature called --simulate which will call apt with -oAPT::Get::Simulate=true. While this works fine in Debian stable, it fails in current testing and unstable. To reproduce the problem consider the Packages file at the end of this mail and the following mmdebstrap command: ./mmdebstrap --verbose --dry-run --variant=essential . debian.tar "deb [trusted=yes] copy://$(pwd)/repo/ main ." [...] Reading package lists... Building dependency tree... The following additional packages will be installed: gcc-10-base libc6 libcrypt1 libgcc-s1 libgcc1 The following NEW packages will be installed: gcc-10-base libc-bin libc6 libcrypt1 libgcc-s1 libgcc1 0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded. Inst gcc-10-base (10-20200222-1 localhost [amd64]) Conf gcc-10-base (10-20200222-1 localhost [amd64]) Inst libgcc-s1 (10-20200222-1 localhost [amd64]) [] Inst libc6 (2.29-10 localhost [amd64]) [] Inst libgcc1 (1:10-20200222-1 localhost [amd64]) [] Inst libcrypt1 (1:4.4.15-1 localhost [amd64]) Conf libgcc1 (1:10-20200222-1 localhost [amd64]) Conf libcrypt1 (1:4.4.15-1 localhost [amd64]) Conf libc6 (2.29-10 localhost [amd64]) Conf libgcc-s1 (10-20200222-1 localhost [amd64]) Inst libc-bin (2.29-10 localhost [amd64]) Conf libc-bin (2.29-10 localhost [amd64]) E: Could not configure 'libc6:amd64'. E: Could not perform immediate configuration on 'libgcc1:amd64'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) The apt command executed by mmdebstrap is essentialy: APT_CONFIG=foo apt-get --yes -oApt::Get::Download-Only=true -oAPT::Get::Simulate=true install libc-bin And where foo contains stuff along the lines of: Apt::Architecture "amd64"; Apt::Architectures "amd64"; Dir "/tmp/mmdebstrap.Dt_RUrBC0g"; Dir::State::Status "/tmp/mmdebstrap.Dt_RUrBC0g/var/lib/dpkg/status"; Dir::Etc::Trusted "/etc/apt/trusted.gpg"; Dir::Etc::TrustedParts "/etc/apt/trusted.gpg.d/"; pkgCacheGen::ForceEssential ","; I don't even know whether you care about this but the dependency situation seems trivial so maybe this is actually an important bug? Thanks! cheers, josch Package: libc-bin Version: 2.29-10 Architecture: amd64 Depends: libc6 Essential: yes Filename: foo MD5sum: bar Package: libc6 Version: 2.29-10 Architecture: amd64 Depends: libgcc1, libcrypt1 Filename: foo MD5sum: bar Package: libcrypt1 Version: 1:4.4.15-1 Architecture: amd64 Depends: libc6 Filename: foo MD5sum: bar Package: libgcc1 Version: 1:10-20200222-1 Architecture: amd64 Depends: gcc-10-base, libgcc-s1, libc6 Filename: foo MD5sum: bar Package: gcc-10-base Version: 10-20200222-1 Architecture: amd64 Filename: foo MD5sum: bar Package: libgcc-s1 Version: 10-20200222-1 Architecture: amd64 Depends: gcc-10-base, libc6 Filename: foo MD5sum: bar
Bug#952523: udd/autoremovals.cgi: please allow inspecting the dependency chain to the buggy package
Package: qa.debian.org Severity: wishlist Hi, I just got an autoremoval on by package src:botch: botch: buggy deps gtksourceview2, flagged for removal in 29.7 days Since I never heard of the package gtksourceview2 in my whole time as a DD I was puzzled why this package affected mine in the first place. One possible dependency chain seems to be: src:botch -> libatdgen-ocaml-dev -> src:ocaml-atd -> menhir -> src:menhir -> coq -> src:coq -> liblablgtksourceview2-ocaml-dev -> libgtksourceview2.0-dev -> src:gtksourceview2 This is useful information for me because now I know which other packages I might want to contribute to, to solve this issue. Unfortunately, it is not easy to get this reverse dependency chain. Maybe it could be printed into autoremovals.cgi by default or there could be a parameter so that one could retrieve it? For the record, I obtained above chain by first creating a dependency graph including all dependency, build-dependency and builds-from relationships like this: $ dose-ceve -T grml --deb-builds-from --deb-native-arch=amd64 debsrc://Sources deb://Packages > /tmp/graph.xml And then extracted the shortest path from src:botch to src:gtksourceview2 using: $ botch-graph-shortest-path /tmp/graph.xml /tmp/out.xml --source realpackage:src:botch --target realpackage:src:gtksourceview2 Maybe there is an easier way but even if it is out of scope for autoremovals.cgi to also show one of the dependency paths, maybe a recipe of how to compute such a path could be documented somewhere? Thanks! cheers, josch
Bug#952522: udd/autoremovals.cgi: please make it clear that the packages in "deps" lines are source packages
Package: qa.debian.org Severity: wishlist Hi, some lines in https://udd.debian.org/cgi-bin/autoremovals.cgi have the pattern: foo: buggy deps bar, flagged for removal in X days As the maintainer of foo (in my current case foo is src:botch) I was wondering how it was possible for my package foo to depend on bar. I generated the reverse dependency closure for foo but the package bar did not show up. In #debian-release I then learned that bar is actually a source package. Please adjust the above line to make this clear. The fact that the line talked about a dependency (I assume that this is what deps stands for) made me think that bar was a binary package because there are no dependencies on source packages. Here some ideas: foo: buggy deps on source bar, flagged for removal in X days foo: buggy deps on src:bar, flagged for removal in X days foo: buggy deps on package(s) building from bar, flagged for removal in X days I would've attached a patch but was blocked by #952521 :) Thanks! cheers, josch
Bug#952521: udd/autoremovals.cgi: please add path to sources
Package: qa.debian.org Severity: wishlist Hi, I don't know how others reach https://udd.debian.org/cgi-bin/autoremovals.cgi but I either use my browser history or use the first result in an online search which is usually: https://lists.debian.org/debian-devel-announce/2013/09/msg6.html I also looked at udd.debian.org but could not find how to get from there to autoremovals.cgi. In any case I am unable to figure out how to contribute to autoremovals.cgi. From looking at the output I am not told where the source code producing the output is hosted nor where I should report bugs to. On #debian-release I was told to report a bug against qa.debian.org but if this is correct, then that information should either be directly part of the output of autoremovals.cgi or be reachable from the source of autoremoval.cgi or whereever the source is hosted. Neither a search on codesearch.debian.net nor on salsa showed any hits when I searched for autoremovals. Thanks! cheers, josch
Bug#951737: ITP: ros-diagnostics -- Robot Operating System (ROS) stack for collecting, publishing, analyzing and viewing diagnostics data
Package: wnpp Severity: wishlist Owner: Johannes 'josch' Schauer * Package name: ros-diagnostics Version : 1.9.3 Upstream Author : Open Source Robotics Foundation * URL : https://wiki.ros.org/diagnostics * License : BSD Programming Lang: C++ Description : Robot Operating System (ROS) stack for collecting, publishing, analyzing and viewing diagnostics data The diagnostics system is designed to collect information from hardware drivers and robot hardware to users and operators for analysis, troubleshooting, and logging. The diagnostics stack contains tools for collecting, publishing, analyzing and viewing diagnostics data. The diagnostics toolchain is built around the /diagnostics topic. On this topic, hardware drivers and devices publish diagnostic_msgs/DiagnosticArray messages with the device names, status and specific data points. The diagnostic_updater and self_test packages allow nodes to collect and publish diagnostics data. The diagnostic_aggregator can categorize and analyze diagnostics at runtime. Operators and developers can view the diagnostics data using the rqt_robot_monitor package. The diagnostic_analysis package can convert diagnostics logs to CSV files for examination and after-the-fact analysis. The package will be maintained under the science team umbrella.
Bug#951736: ITP: ros-perception-pcl -- PCL (Point Cloud Library) ROS interface stack
Package: wnpp Severity: wishlist Owner: Johannes 'josch' Schauer * Package name: ros-perception-pcl Version : 1.7.0 Upstream Author : Open Source Robotics Foundation * URL : http://wiki.ros.org/perception_pcl * License : BSD Programming Lang: C++ Description : PCL (Point Cloud Library) ROS interface stack Upstream moved the code that so far was packaged in Debian as src:ros-pcl-conversions into ros-perception-pcl together with other components. So here we package ros-perception-pcl which builds the binary packages that were formerly built by src:ros-pcl-conversions and a few more. The package will be maintained under the science team umbrella.
Bug#951308: alot: needs versioned dependency on a higher python3-gpg version
Package: alot
Version: 0.9-1
Severity: normal
Hi,
with python3-gpg 1.12.0-4 I get the following error when opening alot:
Traceback (most recent call last):
File "/usr/share/alot/alot/crypto.py", line 261, in
_decrypt_verify_with_context
encrypted, verify=True)
File "/usr/lib/python3/dist-packages/gpg/core.py", line 432, in decrypt
raise errors.BadSignatures(verify_result, results=results)
gpg.errors.BadSignatures: C91B325B77F252FB: No public key
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/alot", line 11, in
load_entry_point('alot==0.9', 'console_scripts', 'alot')()
File "/usr/share/alot/alot/__main__.py", line 137, in main
UI(dbman, cmdstring)
File "/usr/share/alot/alot/ui.py", line 141, in __init__
self.mainloop.run()
File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 286, in run
self._run()
File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 384, in _run
self.event_loop.run()
File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 1340, in run
reraise(*exc_info)
File "/usr/lib/python3/dist-packages/urwid/compat.py", line 58, in reraise
raise value
File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 1354, in
wrapper
rval = f(*args,**kargs)
File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 1313, in
_twisted_idle_callback
callback()
File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 572, in
entering_idle
self.draw_screen()
File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 586, in
draw_screen
canvas = self._topmost_widget.render(self.screen_size, focus=True)
File "/usr/lib/python3/dist-packages/urwid/widget.py", line 144, in
cached_render
canv = fn(self, size, focus=focus)
File "/usr/lib/python3/dist-packages/urwid/decoration.py", line 226, in render
canv = self._original_widget.render(size, focus=focus)
File "/usr/lib/python3/dist-packages/urwid/widget.py", line 144, in
cached_render
canv = fn(self, size, focus=focus)
File "/usr/lib/python3/dist-packages/urwid/container.py", line 1086, in render
focus and self.focus_part == 'body')
File "/usr/share/alot/alot/buffers/buffer.py", line 19, in render
return self.body.render(size, focus)
File "/usr/lib/python3/dist-packages/urwid/widget.py", line 144, in
cached_render
canv = fn(self, size, focus=focus)
File "/usr/lib/python3/dist-packages/urwid/listbox.py", line 471, in render
(maxcol, maxrow), focus=focus)
File "/usr/lib/python3/dist-packages/urwid/listbox.py", line 416, in
calculate_visible
next, pos = self._body.get_next( pos )
File "/usr/share/alot/alot/walker.py", line 46, in get_next
return self._get_at_pos(start_from + self.direction)
File "/usr/share/alot/alot/walker.py", line 72, in _get_at_pos
widget = self._get_next_item()
File "/usr/share/alot/alot/walker.py", line 85, in _get_next_item
next_widget = self.containerclass(next_obj, **self.kwargs)
File "/usr/share/alot/alot/widgets/search.py", line 26, in __init__
self.rebuild()
File "/usr/share/alot/alot/widgets/search.py", line 61, in rebuild
self.structure[partname])
File "/usr/share/alot/alot/widgets/search.py", line 145, in build_text_part
content = prepare_string(name, thread, maxw)
File "/usr/share/alot/alot/widgets/search.py", line 213, in prepare_string
s = content(thread)
File "/usr/share/alot/alot/widgets/search.py", line 188, in
prepare_content_string
lastcontent = ' '.join(m.get_body_text() for m in msgs)
File "/usr/share/alot/alot/widgets/search.py", line 188, in
lastcontent = ' '.join(m.get_body_text() for m in msgs)
File "/usr/share/alot/alot/db/message.py", line 266, in get_body_text
return extract_body(self.get_email())
File "/usr/share/alot/alot/db/message.py", line 105, in get_email
f.read(), self._session_keys)
File "/usr/share/alot/alot/db/utils.py", line 306, in
decrypted_message_from_bytes
session_keys)
File "/usr/share/alot/alot/db/utils.py", line 263, in
decrypted_message_from_message
_handle_encrypted(m, m, session_keys)
File "/usr/share/alot/alot/db/utils.py", line 176, in _handle_encrypted
sigs, d = crypto.decrypt_verify(payload, session_keys)
File "/usr/share/alot/alot/crypto.py", line 226, in decrypt_verify
return _decrypt_verify_with_context(ctx, encrypted)
File "/usr/share/alot/alot/crypto.py", line 266, in
_decrypt_verify_with_context
(plaintext, _, _) = ctx.decrypt(encrypted, verify=False)
File "/usr/lib/python3/dist-packages/gpg/core.py", line 431, in decrypt
for s in verify_result.signatures):
AttributeError: 'NoneType' object has no attribute 'signatures'
The problem is solved by upgrading python3-gpg to 1.13.1-6. Thus, alot
should gain a versioned dependency.
Thanks!
cheers, josch
Bug#951296: apt: please "apt-key is-trusted" command
Package: apt
Version: 1.8.4
Severity: wishlist
Hi,
this bug is a follow up of
https://lists.debian.org/20200207000348.neeqjzu3qx6zwnul@crossbow
mmdebstrap wants to have an answer to the question "does apt trust this
key" and it would be nice if the answer would come from apt directly
because what I'm currently doing, is to manually invoke gpg on whatever
I find in /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/, list the
fingerprints and check whether the fingerprint I am looking for is in
the result or not.
DonKult proposed the following patch:
diff --git a/cmdline/apt-key.in b/cmdline/apt-key.in
@@ -781,6 +781,16 @@ case "$command" in
warn_on_script_usage
foreach_keyring_do 'list_keys_in_keyring' --fingerprint "$@"
;;
+is-trusted)
+ merge_all_trusted_keyrings_into_pubring
+ if [ "$#" = '0' -o "$(aptkey_execute "$GPG_SH" --keyring
"${GPGHOMEDIR}/pubring.gpg" --with-colons --list-keys "$@"
2>/dev/null | grep -c '^pub:')" != "$#" ]; then
+ exit 1
+ fi
+ ;;
+list-fingerprints)
+ setup_merged_keyring
+ aptkey_execute "$GPG" --with-colons --list-keys 2>/dev/null | grep
'^fpr:' | cut -d':' -f 10
+ ;;
export|exportall)
warn_on_script_usage
merge_all_trusted_keyrings_into_pubring
For my purposes I basically don't care whether apt gives me the key
material itself or just a list of fingerprints as proposed above. The
only improvement would be, if I could also pass a keyring filename
because with the above I would still have to run gpg to extract the
fingerprint from the filename I have.
Something like this would be ideal:
$ apt-key is-trusted /usr/share/keyrings/debian-archive-keyring.gpg
$ echo $?
0
Thanks!
cheers, josch
Bug#947863: lxc: apparmor denied mount with unprivileged lxc
Package: lxc
Version: 1:3.1.0+really3.0.4-2
Severity: normal
Hi,
when booting into a system started with unprivileged lxc, I'm getting
the following errors:
[5.818300] audit: type=1400 audit(1577840118.455:15): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=388 comm="(md-udevd)"
flags="rw, rslave"
[5.842226] audit: type=1400 audit(1577840118.479:16): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=389 comm="(md-udevd)"
flags="rw, rslave"
[5.875326] audit: type=1400 audit(1577840118.511:17): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=390 comm="(md-udevd)"
flags="rw, rslave"
[5.894556] audit: type=1400 audit(1577840118.531:18): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=391 comm="(md-udevd)"
flags="rw, rslave"
[5.919489] audit: type=1400 audit(1577840118.555:19): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=392 comm="(md-udevd)"
flags="rw, rslave"
[6.368326] audit: type=1400 audit(1577840119.003:20): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=398 comm="(modprobe)"
flags="rw, rslave"
[6.390053] audit: type=1400 audit(1577840119.027:21): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=400 comm="(d-logind)"
flags="rw, rslave"
[6.400681] audit: type=1400 audit(1577840119.035:22): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=405 comm="(modprobe)"
flags="rw, rslave"
[6.406682] audit: type=1400 audit(1577840119.043:23): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=406 comm="(d-logind)"
flags="rw, rslave"
[6.416232] audit: type=1400 audit(1577840119.051:24): apparmor="DENIED"
operation="mount" info="failed flags match" error=-13
profile="lxc-container-default-cgns" name="/" pid=409 comm="(modprobe)"
flags="rw, rslave"
These errors keep repeating. The only way to silence them I found so far
is to disable apparmor. But maybe the default lxc apparmor profile could
be adjusted to prevent these errors?
To reproduce the problem, please see the attached shell script which you
can run without superuser privileges if you have
kernel.unprivileged_userns_clone set to 1. After running the script, the
errors above can be seen in qemu.log.
Thanks!
cheers, josch
#!/bin/sh
# Copyright 2019 Johannes 'josch' Schauer
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in all
# copies or substantial portions of the Software.
set -exu
# Reasons to use qemu:
# - can also be run with autopkgtest backends that do not support
# - can be run without superuser privileges outside of autopkgtest
if [ -z ${AUTOPKGTEST_TMP+x} ]; then
# if AUTOPKGTEST_TMP is not set, then this script is probably not
# executed under autopkgtest, choose unshare mode for mmdebstrap so
# that this script can be run without superuser privileges
MODE="unshare"
else
# since AUTOPKGTEST_TMP is set, we assume that this script is executed
# under autopkgtest --> switch to the temporary directory
cd "$AUTOPKGTEST_TMP"
# We have to use root mode on salsa ci because:
# - unshare mode fails because /sys is mounted read-only
#and ker
Bug#946980: parmap: segmentation fault on 32bit architectures after ocaml upgrade from 4.05.0 to 4.08.1
Source: parmap Version: 1.0~rc10-3+b1 Severity: important Control: block 946817 by -1 Hi, my package src:botch FTBFS on 32 bit architectures because of parmap: https://buildd.debian.org/status/package.php?p=botch the build_graph utility is run with two jobs and segfaults when the result of the two jobs is getting joined. I bisected snapshot.d.o to figure out where this problem comes from. The last good snapshot timestamp is 20191102T012021Z. Then there are several days where the build dependencies of src:botch cannot be satisfied. One of the first timestamps where build dependencies can be satisfied again is 20191110T012021Z eight days later. But with that timestamp, the segfault starts happening. At the end of this mail is the version diff of the packages that changed between these two timestamps. Maybe something was introduced by the ocaml upgrade that broke parmap? Thanks! cheers, josch 1177,1178c1177,1178 < cpp-9 9.2.1-16 i386 < cppo 1.6.6-1 i386 --- > cpp-9 9.2.1-18 i386 > cppo 1.6.6-1+b1 i386 1190,1191c1190,1191 < dose-builddebcheck 5.0.1-14 i386 < dose-extra 5.0.1-14 i386 --- > dose-builddebcheck 5.0.1-14+b1 i386 > dose-extra 5.0.1-14+b1 i386 1194c1194 < dwz 0.13-1 i386 --- > dwz 0.13-2 i386 1202c1202 < g++-9 9.2.1-16 i386 --- > g++-9 9.2.1-18 i386 1204,1205c1204,1205 < gcc-9 9.2.1-16 i386 < gcc-9-base 9.2.1-16 i386 --- > gcc-9 9.2.1-18 i386 > gcc-9-base 9.2.1-18 i386 1215c1215 < hostname 3.22 i386 --- > hostname 3.23 i386 1222,1225c1222,1225 < libasan5 9.2.1-16 i386 < libatdgen-ocaml 2.0.0-3+b1 i386 < libatdgen-ocaml-dev 2.0.0-3+b1 i386 < libatomic1 9.2.1-16 i386 --- > libasan5 9.2.1-18 i386 > libatdgen-ocaml 2.0.0-3+b2 i386 > libatdgen-ocaml-dev 2.0.0-3+b2 i386 > libatomic1 9.2.1-18 i386 1229,1230c1229,1230 < libbiniou-ocaml 1.2.0-1 i386 < libbiniou-ocaml-dev 1.2.0-1 i386 --- > libbiniou-ocaml 1.2.0-1+b1 i386 > libbiniou-ocaml-dev 1.2.0-1+b1 i386 1236,1237c1236,1237 < libbz2-ocaml 0.6.0-10 i386 < libbz2-ocaml-dev 0.6.0-10 i386 --- > libbz2-ocaml 0.6.0-10+b1 i386 > libbz2-ocaml-dev 0.6.0-10+b1 i386 1244,1245c1244,1245 < libcap2 1:2.25-2 i386 < libcc1-0 9.2.1-16 i386 --- > libcap2 1:2.27-1 i386 > libcc1-0 9.2.1-18 i386 1249c1249 < libcudf-ocaml-dev 0.7-5+b1 i386 --- > libcudf-ocaml-dev 0.7-5+b2 i386 1254,1255c1254,1255 < libdose3-ocaml 5.0.1-14 i386 < libdose3-ocaml-dev 5.0.1-14 i386 --- > libdose3-ocaml 5.0.1-14+b1 i386 > libdose3-ocaml-dev 5.0.1-14+b1 i386 1257,1258c1257,1258 < libeasy-format-ocaml 1.2.0-1+b1 i386 < libeasy-format-ocaml-dev 1.2.0-1+b1 i386 --- > libeasy-format-ocaml 1.2.0-1+b2 i386 > libeasy-format-ocaml-dev 1.2.0-1+b2 i386 1261,1262c1261,1262 < libextlib-ocaml 1.7.6-1 i386 < libextlib-ocaml-dev 1.7.6-1 i386 --- > libextlib-ocaml 1.7.6-1+b1 i386 > libextlib-ocaml-dev 1.7.6-1+b1 i386 1266c1266 < libfindlib-ocaml 1.8.1-1 i386 --- > libfindlib-ocaml 1.8.1-1+b1 i386 1270,1271c1270,1271 < libgcc-9-dev 9.2.1-16 i386 < libgcc1 1:9.2.1-16 i386 --- > libgcc-9-dev 9.2.1-18 i386 > libgcc1 1:9.2.1-18 i386 1276c1276 < libglib2.0-0 2.62.2-2 i386 --- > libglib2.0-0 2.62.2-3 i386 1278,1279c1278,1279 < libgnutls30 3.6.10-3 i386 < libgomp1 9.2.1-16 i386 --- > libgnutls30 3.6.10-4 i386 > libgomp1 9.2.1-18 i386 1286c1286 < libharfbuzz0b 2.6.2-1 i386 --- > libharfbuzz0b 2.6.4-1 i386 1292c1292 < libitm1 9.2.1-16 i386 --- > libitm1 9.2.1-18 i386 1299c1299 < liblz4-1 1.9.1-2 i386 --- > liblz4-1 1.9.2-1 i386 1303,1304c1303,1304 < libmmap-ocaml 1.1.0-1 i386 < libmmap-ocaml-dev 1.1.0-1 i386 --- > libmmap-ocaml 1.1.0-1+b1 i386 > libmmap-ocaml-dev 1.1.0-1+b1 i386 1316c1316 < libocamlgraph-ocaml-dev 1.8.8-1.1 i386 --- > libocamlgraph-ocaml-dev 1.8.8-1.1+b1 i386 1325,1326c1325,1326 < libparmap-ocaml 1.0~rc10-3 i386 < libparmap-ocaml-dev 1.0~rc10-3 i386 --- > libparmap-ocaml 1.0~rc10-3+b1 i386 > libparmap-ocaml-dev 1.0~rc10-3+b1 i386 1339,1340c1339,1340 < libquadmath0 9.2.1-16 i386 < libre-ocaml-dev 1.7.3-2 i386 --- > libquadmath0 9.2.1-18 i386 > libre-ocaml-dev 1.7.3-2+b1 i386 1354,1355c1354,1355 < libstdc++-9-dev 9.2.1-16 i386 < libstdc++6 9.2.1-16 i386 --- > libstdc++-9-dev 9.2.1-18 i386 > libstdc++6 9.2.1-18 i386 1357c1357 < libsystemd0 242-7 i386 --- > libsystemd0 242-8 i386 1361c1361 < libtiff5 4.0.10+git191003-1 i386 --- > libtiff5 4.1.0-1 i386 1364c1364 < libubsan1 9.2.1-16 i386 --- > libubsan1 9.2.1-18 i386 1366c1366 < libudev1 242-7 i386 --- > libudev1 242-8 i386 1380c1380 < libxmlm-ocaml-dev 1.3.0-2 i386 --- > libxmlm-ocaml-dev 1.3.0-2+b1 i386 1386,1389c1386,1389 < libyojson-ocaml 1.7.0-1 i386 < libyojson-ocaml-dev 1.7.0-1 i386 < libzip-ocaml 1.08-1 i386 < libzip-ocaml-dev 1.08-1 i386 --- > libyojson-ocaml 1.7.0-1+b1 i386 > libyojson-ocaml-dev 1.7.0-1+b1 i386 > libzip-ocaml 1.09-2 i386 > libzip-ocaml-dev 1.09-2 i386 1394c1394 < m4 1.4.18-2 i386 --- > m4 1.4.18-4 i386 1402,1407c1402,1407 < ocaml-base-nox 4.05.0-12 i386 < ocaml-compiler-libs 4.05.0-12 i386 < ocaml-findlib 1.8.1-1 i386 < ocaml-interp 4.05.0-12 i386 < ocaml-nox 4.05.0-12 i386 < ocamlbuild 0.14.0-1 i386 --- > ocaml-base-nox 4.08.
Bug#946565: regression: Could NOT find Boost (missing: python3)
Package: libboost-python1.67-dev Version: 1.67.0-15 Severity: important Hi, I'm using the following CMakeLists.txt: cmake_minimum_required(VERSION 3.13) project(foo) find_package(PythonLibs 3 REQUIRED) find_package(Boost 1.45.0 COMPONENTS "python3" REQUIRED) Everything works fine on Debian Buster with libboost-python1.67-dev version 1.67.0-13: -- The C compiler identification is GNU 8.3.0 -- The CXX compiler identification is GNU 8.3.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.7m.so (found suitable version "3.7.3", minimum required is "3") -- Boost version: 1.67.0 -- Found the following Boost libraries: -- python3 -- Configuring done -- Generating done -- Build files have been written to: /tmp The problem only occurs after upgrading to 1.67.0-15 from unstable: -- The C compiler identification is GNU 8.3.0 -- The CXX compiler identification is GNU 8.3.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.7m.so (found suitable version "3.7.5", minimum required is "3") CMake Error at /usr/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find Boost (missing: python3) (found suitable version "1.67.0", minimum required is "1.45.0") Call Stack (most recent call first): /usr/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake-3.15/Modules/FindBoost.cmake:2161 (find_package_handle_standard_args) CMakeLists.txt:4 (find_package) -- Configuring incomplete, errors occurred! See also "/tmp/CMakeFiles/CMakeOutput.log". Please fix this regression. Thanks! cheers, josch
Bug#944929: initramfs-tools: postinst fails when run under fakechroot
Package: initramfs-tools
Version: 0.132
Severity: normal
Hi,
mmdebstrap is a replacement for debootstrap and also supports fakechroot
as a way to avoid becoming root to produce a chroot tarball. Currently,
the postinst script of initramfs-tools fails during installation of a
linux kernel package. I inserted a "set -x" before installing
linux-image-amd64 and this is the result:
Setting up linux-image-5.3.0-2-amd64 (5.3.9-2) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.3.0-2-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-5.3.0-2-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-5.3.0-2-amd64
I: /initrd.img is now a symlink to boot/initrd.img-5.3.0-2-amd64
/etc/kernel/postinst.d/apt-auto-removal:
W: Unable to read /tmp/7fbrozPKb6 - RealFileExists (2: No such file or
directory)
W: Unable to read /tmp/7fbrozPKb6 - RealFileExists (2: No such file or
directory)
W: Unable to read /tmp/7fbrozPKb6 - RealFileExists (2: No such file or
directory)
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.3.0-2-amd64
+ PREREQS=
+ prereqs
+ echo
+ exit 0
+ PREREQS=
+ . /usr/share/initramfs-tools/hook-functions
+ mkdir -p /var/tmp/mkinitramfs_9jv3H9/lib/systemd
+ copy_exec /lib/systemd/systemd-udevd /lib/systemd
+ local src target x nonoptlib ret
+ src=/lib/systemd/systemd-udevd
+ target=/lib/systemd
+ copy_file binary /lib/systemd/systemd-udevd /lib/systemd
+ local type src target link_target
+ type=binary
+ src=/lib/systemd/systemd-udevd
+ target=/lib/systemd
+ [ -f /lib/systemd/systemd-udevd ]
+ [ -d /var/tmp/mkinitramfs_9jv3H9//lib/systemd ]
+ target=/lib/systemd/systemd-udevd
+ target=/usr/lib/systemd/systemd-udevd
+ [ -e /var/tmp/mkinitramfs_9jv3H9//usr/lib/systemd/systemd-udevd ]
+ mkdir -p /var/tmp/mkinitramfs_9jv3H9//usr/lib/systemd
+ [ -h /lib/systemd/systemd-udevd ]
+ [ n = y ]
+ cp -pP /lib/systemd/systemd-udevd
/var/tmp/mkinitramfs_9jv3H9//usr/lib/systemd/systemd-udevd
+ ldd /lib/systemd/systemd-udevd
+ sed -e
/\//!d;
/linux-gate/d;
/=>/ {s/.*=>[[:blank:]]*\([^[:blank:]]*\).*/\1/};
s/[[:blank:]]*\([^[:blank:]]*\) (.*)/\1/
+ echo /usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so
+ sed -e
s#/lib/\([^/]*/\)\?\(tls\|i686\|sse2\|neon\|vfp\).*/\(lib.*\)#/lib/\1\3#
+ nonoptlib=/usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so
+ echo /usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so
+ sed -e s#-linux-gnu/\(tls\|i686\|sse2\|neon\|vfp\).*/\(lib.*\)#-linux-gnu/\2#
+ nonoptlib=/usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so
+ [ -e /usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so ]
+ copy_file library /usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so
+ local type src target link_target
+ type=library
+ src=/usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so
+ target=/usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so
+ [ -f /usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so ]
+ return 2
+ ret=2
+ [ 2 = 1 ]
+ return 1
E: /usr/share/initramfs-tools/hooks/udev failed with return 1.
update-initramfs: failed for /boot/initrd.img-5.3.0-2-amd64 with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-5.3.0-2-amd64 (--configure):
installed linux-image-5.3.0-2-amd64 package post-installation script
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-amd64:
linux-image-amd64 depends on linux-image-5.3.0-2-amd64 (= 5.3.9-2); however:
Package linux-image-5.3.0-2-amd64 is not configured yet.
dpkg: error processing package linux-image-amd64 (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
linux-image-5.3.0-2-amd64
linux-image-amd64
As you can see, the postinst script tries to copy libfakeroot-sysv.so
into the initramfs. This fails because libfakeroot-sysv.so is only
available outside the chroot but not inside of it. Additionally,
libfakeroot-sysv.so should probably not be part of the initramfs. Maybe
some code should be added to skip inclusion of the library?
Thanks!
cheers, josch
Bug#944729: libguestfs: Please add an autopkgtest
Source: libguestfs Version: 1:1.40.2-2+b10 Severity: wishlist Tags: patch Hi, it would be great if src:libguestfs would include an autopkgtest, so that we regularly verify that basic functionality still works and as yet another example of how to use libguestfs from a script. I attached a patch which first creates a tarball containing a Debian unstable chroot and then uses guestfish to create a disk image with extlinux. Lastly, qemu is used to boot the image and we verify that everything works by connecting to it via ssh. If you want to verify that all of this works you can run: $ sudo debian/tests/extlinux In principal, all the tools the script uses can also work without superuser privileges. But due to limitations on ci.debian.net and salsa-ci, we cannot use linux user namespaces and need root instead. If you want to run the script on your local machine without root permissions, then replace --mode=root with --mode=unshare in the autopkgtest and then run the script without sudo in front. It will work just as well. I also added a debian/salsa-ci.yml but that one is not useful yet, because libguestfs seems too large for salsa-ci. See: https://salsa.debian.org/salsa/support/issues/175 Thanks! cheers, josch >From a650d5c1f9bc260996e25079d50114cb7dbddc5a Mon Sep 17 00:00:00 2001 From: Johannes 'josch' Schauer Date: Thu, 14 Nov 2019 11:21:03 +0100 Subject: [PATCH] add autopkgtest --- debian/salsa-ci.yml | 14 ++ debian/tests/control | 2 + debian/tests/extlinux | 99 +++ 3 files changed, 115 insertions(+) create mode 100644 debian/salsa-ci.yml create mode 100644 debian/tests/control create mode 100644 debian/tests/extlinux diff --git a/debian/salsa-ci.yml b/debian/salsa-ci.yml new file mode 100644 index 0..ab4d9f016 --- /dev/null +++ b/debian/salsa-ci.yml @@ -0,0 +1,14 @@ +--- +include: + - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml + - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml + +variables: + SALSA_CI_DISABLE_APTLY: 1 + SALSA_CI_DISABLE_AUTOPKGTEST: 0 + SALSA_CI_DISABLE_BLHC: 1 + SALSA_CI_DISABLE_LINTIAN: 1 + SALSA_CI_DISABLE_PIUPARTS: 1 + SALSA_CI_DISABLE_REPROTEST: 1 + SALSA_CI_DISABLE_BUILD_PACKAGE_ALL: 1 + SALSA_CI_DISABLE_BUILD_PACKAGE_ANY: 1 diff --git a/debian/tests/control b/debian/tests/control new file mode 100644 index 0..a46476f58 --- /dev/null +++ b/debian/tests/control @@ -0,0 +1,2 @@ +Tests: extlinux +Depends: libguestfs-tools, mmdebstrap, linux-image-amd64, openssh-client diff --git a/debian/tests/extlinux b/debian/tests/extlinux new file mode 100644 index 0..e2f39ef84 --- /dev/null +++ b/debian/tests/extlinux @@ -0,0 +1,99 @@ +#!/bin/sh + +set -exu + +ssh="ssh -oUserKnownHostsFile=/dev/null -oStrictHostKeyChecking=no -i id_rsa -T" + +pkgs="linux-image-amd64,openssh-server,systemd-sysv,libpam-systemd,policykit-1" +pkgs="$pkgs,iproute2,util-linux,e2fsprogs,ifupdown,net-tools,netbase" +pkgs="$pkgs,iputils-ping,isc-dhcp-client,lvm2,parted,cryptsetup" +pkgs="$pkgs,dropbear-initramfs,busybox,fdisk,mmdebstrap,udev" + +# we have to use root mode on salsa CI because: +# - unshare mode fails because /sys is mounted read-only +#and kernel.unprivileged_userns_clone is not set to 1 +# - fakechroot mode fails because of failing postinst of linux-image-amd64 +# - proot mode produces wrong permissions +mmdebstrap --mode=root --variant=apt --include=$pkgs \ + --customize-hook='chroot "$1" passwd --delete root' \ + --customize-hook='chroot "$1" useradd --home-dir /home/user --create-home user' \ + --customize-hook='chroot "$1" passwd --delete user' \ + --customize-hook='echo host > "$1/etc/hostname"' \ + --customize-hook='echo "127.0.0.1 localhost host" > "$1/etc/hosts"' \ + --customize-hook='echo "/dev/sda1 / auto errors=remount-ro 0 1" > "$1/etc/fstab"' \ + unstable debian-unstable.tar + +cat << END > extlinux.conf +default linux +timeout 0 + +label linux +kernel /vmlinuz +append initrd=/initrd.img root=/dev/sda1 net.ifnames=0 console=ttyS0 +END + +cat << END > interfaces +auto lo +iface lo inet loopback + +auto eth0 +iface eth0 inet dhcp +END + +[ -e ./id_rsa ] && [ -e ./id_rsa.pub ] || ssh-keygen -q -t rsa -f ./id_rsa -N "" + +#LIBGUESTFS_BACKEND_SETTINGS=force_tcg +#libguestfs-test-tool || true +#export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 +guestfish -N debian-unstable.img=disk:1G -- \ + part-disk /dev/sda mbr : \ + part-set-bootable /dev/sda 1 true : \ + mkfs ext2 /dev/sda1 : \ + mount /dev/sda1 / : \ + tar-in debian-unstable.tar / : \ + extlinux / : \ + mkdir /root/.ssh : \ + copy-in id_rsa.p
Bug#944465: wordpress: missing dependency on iputils-ping
Source: wordpress Version: 5.2.4+dfsg1-1 Severity: normal Hi, the script setup-mysql runs the tool ping but the wordpress package does not depend on iputils-ping. Thanks! cheers, josch
Bug#941103: ironic-inspector: requires construct << 2.9
Source: ironic-inspector Version: 8.2.2-1 Severity: normal Hi, ironic-inspector cannot operate with python-construct 2.9 or later. This is even the case for currently unpackaged upstream versions 9.1 of ironic-inspector. Unfortunately, this blocks python-miio from entering unstable (currently only in experimental) which needs a current version of python-construct. Rather than downgrading python-miio to also work with an old python-construct version, I think ironic-inspector should work with the recent version of python-construct. Thanks! cheers, josch
Bug#939303: matplotlib2: FTBFS unsatisfied b-d on python-pyshp
Source: matplotlib2 Version: 2.2.3-6 Severity: serious Justification: fails to build from source Hi, src:matplotlib2 currently FTBFS because its build dependencies cannot be satisfied in Debian unstable. It follows some evidence: $ dose-builddebcheck --explain --failures --deb-native-arch amd64 --checkonly=matplotlib2 Packages_main_amd64 Sources output-version: 1.2 native-architecture: amd64 report: - package: matplotlib2 version: 2.2.3-6 architecture: any,all type: src status: broken reasons: - missing: pkg: package: python-mpltoolkits.basemap version: 1.2.0+dfsg-1 architecture: amd64 unsat-dependency: python-pyshp:amd64 depchains: - depchain: - package: matplotlib2 version: 2.2.3-6 architecture: any,all type: src depends: python-mpltoolkits.basemap:amd64 binary-packages: 90294 source-packages: 30649 broken-packages: 1 Or the debcheck results: https://qa.debian.org/dose/debcheck/src_unstable_main/1567400407/packages/matplotlib2.html This failure is also important, because matplotlib2 is necessary to compile build-essential. See the dependency graph here: http://paste.debian.net/1098490/ Thanks! cheers, josch
Bug#934753: dropbear-initramfs: please add an autopkgtest
Package: dropbear-initramfs Severity: wishlist Hi, when I upgraded my Squeeze box to Jessie, remote unlocking via dropbear in my initramfs stopped working. This is a remote host in a datacenter, so I cannot directly investigate the issue. I propose to add an autopkgtest for dropbear-initramfs to make sure that the functionality continues to work even as the packages around it change over time. I attached a shell script which uses qemu to prepare a system that has an unencrypted /boot and / and swap on an LVM on luks, which I guess is the classical layout. If you like the script, then I could prepare a patch against src:dropbear which implements an autopkgtest that runs the script. Thanks! cheers, josch #!/bin/sh set -exu ssh="ssh -oUserKnownHostsFile=/dev/null -oStrictHostKeyChecking=no -i id_rsa" pkgs="linux-image-amd64,openssh-server,systemd-sysv,libpam-systemd,policykit-1" pkgs="$pkgs,iproute2,util-linux,e2fsprogs,ifupdown,net-tools,netbase" pkgs="$pkgs,iputils-ping,isc-dhcp-client,lvm2,parted,cryptsetup" pkgs="$pkgs,dropbear-initramfs,busybox,fdisk,mmdebstrap,udev" mmdebstrap --mode=unshare --variant=apt --include=$pkgs \ --customize-hook='chroot "$1" passwd --delete root' \ --customize-hook='chroot "$1" useradd --home-dir /home/user --create-home user' \ --customize-hook='chroot "$1" passwd --delete user' \ --customize-hook='echo host > "$1/etc/hostname"' \ --customize-hook='echo "127.0.0.1 localhost host" > "$1/etc/hosts"' \ --customize-hook='echo "/dev/sda1 / auto errors=remount-ro 0 1" > "$1/etc/fstab"' \ unstable debian-unstable.tar fallocate -l 2G crypt.img cat << END > extlinux.conf default linux timeout 0 label linux kernel /vmlinuz append initrd=/initrd.img root=/dev/sda1 console=ttyS0 END cat << END > interfaces auto lo iface lo inet loopback auto ens3 iface ens3 inet dhcp END [ -e ./id_rsa ] && [ -e ./id_rsa.pub ] || ssh-keygen -q -t rsa -f ./id_rsa -N "" guestfish -N debian-unstable.img=disk:2G -- \ part-disk /dev/sda mbr : \ part-set-bootable /dev/sda 1 true : \ mkfs ext2 /dev/sda1 : \ mount /dev/sda1 / : \ tar-in debian-unstable.tar / : \ extlinux / : \ mkdir /root/.ssh : \ copy-in id_rsa.pub /root/ : \ mv /root/id_rsa.pub /root/.ssh/authorized_keys : \ chown 0 0 /root/.ssh/authorized_keys : \ copy-in extlinux.conf / : \ copy-in interfaces /etc/network qemu-img convert -O qcow2 debian-unstable.img debian-unstable.qcow2 qemu-system-x86_64 -enable-kvm -m 4G -net user,hostfwd=tcp::10022-:22 \ -net nic -nographic -serial mon:stdio \ -drive file=debian-unstable.qcow2 \ -drive file=crypt.img,format=raw >qemu1.log &1 & QEMUPID=$! trap "kill $QEMUPID" EXIT TIMESTAMP=$(sleepenh 0 || [ $? -eq 1 ]) TIMEOUT=3 i=0 while true; do rv=0 $ssh -p 10022 -o ConnectTimeout=$TIMEOUT root@localhost echo success || rv=1 [ $rv -eq 0 ] && break # if the command before took less than $TIMEOUT seconds, wait the remaining time TIMESTAMP=$(sleepenh $TIMESTAMP $TIMEOUT || [ $? -eq 1 ]); i=$((i+1)) if [ $i -ge 10 ]; then break fi done if [ $i -eq 10 ]; then echo "timeout reached: unable to connect to qemu via ssh" exit 1 fi $ssh -p 10022 root@localhost << 'SSHSCRIPT' set -exu cat << END | sfdisk /dev/sdb label: gpt unit: sectors start= 2048, size=2048, type=21686148-6449-6E6F-744E-656564454649 start= 4096, size= 999424, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4 start=1003520,type=CA7D7CCB-63ED-4C53-861C-1742536059CC END fdisk -l printf myinsecurepassphrase | cryptsetup luksFormat /dev/sdb3 - printf myinsecurepassphrase | cryptsetup luksOpen /dev/sdb3 mycrypt pvcreate /dev/mapper/mycrypt vgcreate myvg /dev/mapper/mycrypt lvcreate --name swap --size 15M myvg mkswap /dev/myvg/swap swapon /dev/myvg/swap lvcreate --name root --size 1G myvg mkfs.ext4 /dev/myvg/root mkfs.ext2 /dev/sdb2 BOOTUUID=`blkid -s UUID -o value /dev/sdb2` SDB3UUID=`blkid -s UUID -o value /dev/sdb3` SWAPUUID=`blkid -s UUID -o value /dev/myvg/swap` mount /dev/myvg/root /mnt # need to use /dev/null on stdin because of #934199 mmdebstrap --debug --mode=root --variant=apt unstable /mnt "/mnt/etc/apt/apt.conf.d/99no-install-recommends" cat > "/mnt/etc/apt/apt.conf.d/99autoremove" << END APT::AutoRemove::SuggestsImportant false; APT::AutoRemove::RecommendsImportant false; END mkdir -p "/mnt/etc/default" cat > "/mnt/etc/default/grub" << 'END' GRUB_DEFAULT=0 GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT="quiet" GRUB_CMDLINE_LINUX="ip=:ens3:dhcp cgroup_enable=memory swapaccount=1 console=ttyS0 " END cat > "/mnt/etc/fstab" << END /dev/myvg/root / autoerrors=remount-ro 0 1 UUID=$BOOTUUID /boot autodefaults 0 2 /dev/myvg/swap none
Bug#934713: os-prober: missing dependency on mount
Package: os-prober Version: 1.76 Severity: important Hi, The script /usr/lib/os-probes/50mounted-tests calls the `umount` utility which resides in the mount package. But os-prober does not depend on mount and thus one might get this error message: Generating grub configuration file ... Found linux image: /boot/vmlinuz-5.2.0-2-amd64 Found initrd image: /boot/initrd.img-5.2.0-2-amd64 /usr/lib/os-probes/50mounted-tests: 10: umount: not found rmdir: failed to remove '/var/lib/os-prober/mount': Device or resource busy The mount package used to be Essential:yes. Since version 2.29.2-3 it is not essential anymore and os-prober should depend on it. Thanks! cheers, josch
Bug#934453: curl: SSL routines:tls12_check_peer_sigalg:wrong signature type
Package: curl Version: 7.65.3-1 Severity: normal Hi, steps to reproduce: $ sudo debootstrap --include=curl,ca-certificates unstable debian-unstable [...] $ sudo chroot debian-unstable curl -vvv https://www.daserste.de * Trying 8.248.97.252:443... * TCP_NODELAY set * Connected to www.daserste.de (8.248.97.252) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (OUT), TLS alert, handshake failure (552): * error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type * Closing connection 0 curl: (35) error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type This also happens with other domains. I hope this is actually a curl issue and not my own stupidity but this problem only occurs with curl and not wget or firefox and the domain from above has an A+ rating on ssllabs.com, so I guess it is properly configured. Thanks! cheers, josch
Bug#933515: ITP: r-cran-tufte -- Tufte's Styles for R Markdown Documents
Package: wnpp Severity: wishlist Owner: Johannes 'josch' Schauer * Package name: r-cran-tufte Version : 0.5 Upstream Author : Yihui Xie * URL : https://cran.r-project.org/package=tufte * License : MIT Programming Lang: GNU R Description : Tufte's Styles for R Markdown Documents Provides R Markdown output formats to use Tufte styles for PDF and HTML output. The Tufte handout style is a style that Edward Tufte uses in his books and handouts. Tufte’s style is known for its extensive use of sidenotes, tight integration of graphics with text, and well-set typography. This style has been implemented in LaTeX and HTML/CSS, respectively. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-tufte
Bug#930212: libmupdf-dev: undefined reference when linking
Package: libmupdf-dev
Version: 1.14.0+ds1-4
Severity: grave
Justification: renders package unusable
Hi,
it does not seem to be possible to use the static library from
libmupdf-dev at all.
Consider the following minimal test case:
#include "mupdf/fitz.h"
#include "mupdf/pdf.h"
#include
#include
int main(int argc, char **argv)
{
fz_context *ctx;
ctx = fz_new_context(NULL, NULL, FZ_STORE_UNLIMITED);
if (!ctx)
{
fprintf(stderr, "cannot initialise context\n");
exit(1);
}
return 0;
}
Lets compile it:
$ gcc $(pkg-config --cflags --libs --static mupdf) test.c -o out
/usr/bin/ld: cannot find -lopenjpeg
collect2: error: ld returned 1 exit status
So one bug that should be fixed is that the supplied pkg-config file
isn't working. This should be fixed but is not the RC bug I'm reporting
here. Lets try to pass the options manually:
$ gcc -I/usr/include/freetype2 -I/usr/include/libpng16 -lmupdf -ljbig2dec
-ljpeg -lz -lm -lfreetype -lpng16 -lm -lz -lm -lz test.c
/usr/bin/ld: /tmp/ccCPwEIx.o: in function `main':
test.c:(.text+0x26): undefined reference to `fz_new_context_imp'
collect2: error: ld returned 1 exit status
So it seems the shipped static library is useless? I hope I'm wrong and
made a silly mistake.
Thanks!
cheers, josch
Bug#928986: CloudCompare: error while loading shared libraries: libQCC_IO_LIB.so:
Package: cloudcompare Version: 2.10.1-1 Severity: grave Justification: renders package unusable Hi, after installing the package, when attempting to start CloudCompare I get the following error message: CloudCompare: error while loading shared libraries: libQCC_IO_LIB.so: cannot open shared object file: No such file or directory Indeed that file seems to be contain in no binary package in the archive? Thanks! cheers, josch -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cloudcompare depends on: ii libboost-atomic1.67.0 1.67.0-11 ii libboost-chrono1.67.0 1.67.0-11 ii libboost-date-time1.67.0 1.67.0-11 ii libboost-system1.67.0 1.67.0-10 ii libboost-thread1.67.0 1.67.0-11 ii libc6 2.28-2 ii libcgal13 4.12-1 ii libgcc1 1:8.2.0-9 ii libgl11.1.0-1 ii libglu1-mesa [libglu1]9.0.0-2.1 ii libgmp10 2:6.1.2+dfsg-4 ii libgmpxx4ldbl 2:6.1.2+dfsg-4 ii libgomp1 8.2.0-9 ii libmpfr6 4.0.1-1 ii libpdal-base7 1.8.0+ds-1+b2 ii libpdal-util7 1.8.0+ds-1+b2 ii libqt5concurrent5 5.11.3+dfsg-2 ii libqt5core5a 5.11.3+dfsg-2 ii libqt5gui55.11.3+dfsg-2 ii libqt5opengl5 5.11.3+dfsg-2 ii libqt5printsupport5 5.11.3+dfsg-2 ii libqt5widgets55.11.3+dfsg-2 ii libstdc++68.2.0-9 cloudcompare recommends no packages. cloudcompare suggests no packages. -- debconf-show failed
Bug#928682: botch: Recommend wget
Package: botch Version: 0.21-6 Severity: normal botch-download-pkgsrc uses wget and thus botch should at least recommend it
Bug#928448: unblock: mmdebstrap/0.4.1-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hello release team! I'm here to talk about an eventual unblock request of my package mmdebstrap. In this context I want to discuss with you, which changes will still be permitted at this time of the freeze. It is very unlikely that any of these changes will break anything because mmdebstrap is intensively tested in 91 different scenarios, exercising all reasonably testable code-paths according to the Devel::Cover Perl module. If these patches cannot be part of the initial Buster release, they should definitely go into the next point release. I would not say that any of these are of RC severity but they they are not less than important severity either. Each of these fixes is targeted and minimal and does not break any interfaces. mmdebstrap has no reverse-Depends (but some reverse-Recommends). I find especially support for old apt versions and derivative distributions important. If you tell me to go ahead, then I would need: unblock mmdebstrap/0.4.1-3 All the patches I list in the following are attached to this mail as part of a debdiff where I applied all of them. 1. 0001-cleanup-auxfiles-after-running-apt-get-update-or-oth.patch This closes #927151. The workaround is a manual rm of the auxfiles directory. This problem only occurs when producing a Debian chroot with an apt version before the auxfiles directory existed. 2. 0002-chdir-before-apt-get-update-to-accomodate-for-apt-1..patch Another fix is for apt (<< 1.5) which will attempt to chdir() after an "apt update" which might fail if that directory is not readable by the user running apt (apt bug #860738). The workaround is to start mmdebstrap from a world readable directory. 3. 0003-add-Dir-State-Status-to-apt-config-for-apt-1.3.patch For apt apt (<< 1.3) it is necessary to explicitly set the Dir::State::Status or otherwise, the dpkg status database outside the chroot will be used. There exists no equivalent workaround. 4. 0004-chmod-0755-on-qemu-user-static-binary.patch On Ubuntu, the binfmt mechanism seems to require that interpreters are marked executable. This requirement does not seem to exist on Debian which is why the executable bit was originally not set for the qemu-user-static binary. There is no workaround. 5. 0005-chdir-to-parent-of-root-before-remove_tree-to-preven.patch This is similar to (2.) because the function remove_tree of the perl module File::Path also attempts to chdir to the current directory before removing a completely different directory. This chdir will fail if the current directory is not readable by the user running the function. The workaround is to start mmdebstrap from a world readable directory. 6. 0006-Only-error-out-on-W-and-Err-lines-on-apt-get-update.patch This closes #928079. Instead of using exit codes, apt communicates failure using "W:" and "Err:" lines on standard output (apt bugs #778357, #776152, #696335 and #745735). But sometimes, maintainer scripts also emit non-fatal "W:" lines. The workaround is to install the affected packages after mmdebstrap finished manually. diff -Nru mmdebstrap-0.4.1/debian/changelog mmdebstrap-0.4.1/debian/changelog --- mmdebstrap-0.4.1/debian/changelog 2019-03-18 14:46:01.0 +0100 +++ mmdebstrap-0.4.1/debian/changelog 2019-05-04 23:48:19.0 +0200 @@ -1,3 +1,15 @@ +mmdebstrap (0.4.1-3) unstable; urgency=medium + + * Backport patches from upstream: + - cleanup auxfiles *after* running apt-get update (closes: #927151) + - chdir() before 'apt-get update' for apt (<< 1.5) + - chdir() before remove_tree() + - add Dir::State::Status to apt config for apt (<< 1.3) + - chmod 0755 on qemu-user-static binary for Ubuntu + - Only error out on W: and Err: lines (closes: #928079) + + -- Johannes 'josch' Schauer Sat, 04 May 2019 23:48:19 +0200 + mmdebstrap (0.4.1-2) unstable; urgency=medium * Mark autopkgtest as flaky (closes: #924854) diff -Nru mmdebstrap-0.4.1/debian/patches/0001-cleanup-auxfiles-after-running-apt-get-update-or-oth.patch mmdebstrap-0.4.1/debian/patches/0001-cleanup-auxfiles-after-running-apt-get-update-or-oth.patch --- mmdebstrap-0.4.1/debian/patches/0001-cleanup-auxfiles-after-running-apt-get-update-or-oth.patch 1970-01-01 01:00:00.0 +0100 +++ mmdebstrap-0.4.1/debian/patches/0001-cleanup-auxfiles-after-running-apt-get-update-or-oth.patch 2019-05-04 23:44:01.0 +0200 @@ -0,0 +1,49 @@ +From b2d5a45932a303a65baa4ec5081c5fa1f4fa80a5 Mon Sep 17 00:00:00 2001 +From: Johannes 'josch' Schauer +Date: Tue, 23 Apr 2019 13:28:55 +0200 +Subject: [PATCH 1/6] cleanup auxfiles *after* running apt-get update or + otherwise it will be re-created + +--- + coverage.sh | 2 -- + mmdebstrap | 12 ++-- + 2 files changed, 6 insertions(+), 8 deletions(-) + +--- a/coverage.sh b/
Bug#926324: unblock: sbuild/0.78.1-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package sbuild as discussed in #926161. Debdiff attached.
unblock sbuild/0.78.1-2
diff -Nru sbuild-0.78.1/debian/changelog sbuild-0.78.1/debian/changelog
--- sbuild-0.78.1/debian/changelog 2019-02-09 07:25:07.0 +0100
+++ sbuild-0.78.1/debian/changelog 2019-04-03 14:08:12.0 +0200
@@ -1,3 +1,16 @@
+sbuild (0.78.1-2) unstable; urgency=medium
+
+ [ Mike Gabriel ]
+ * debian/patches: Add support-gzip-in-wheezy.patch. The gzip command
+in Debian wheezy lacks support for the --keep cmdline option, so
+avoid using it. (closes: #926161)
+
+ [ Aurelien Jarno ]
+ * debian/patches: Add fix-disk-space-directory-check.patch. The right
+directory has to be checked inside the chroot. (closes: #923484)
+
+ -- Johannes 'josch' Schauer Wed, 03 Apr 2019 14:08:12
+0200
+
sbuild (0.78.1-1) unstable; urgency=medium
* New upstream release.
diff -Nru sbuild-0.78.1/debian/patches/fix-disk-space-directory-check.patch
sbuild-0.78.1/debian/patches/fix-disk-space-directory-check.patch
--- sbuild-0.78.1/debian/patches/fix-disk-space-directory-check.patch
1970-01-01 01:00:00.0 +0100
+++ sbuild-0.78.1/debian/patches/fix-disk-space-directory-check.patch
2019-04-03 13:59:20.0 +0200
@@ -0,0 +1,25 @@
+Description: test $pkgbuilddir inside the chroot instead of $dscdir outside of
it
+Author: Aurelien Jarno
+
+--- a/lib/Sbuild/Build.pm
b/lib/Sbuild/Build.pm
+@@ -2776,16 +2776,14 @@ sub check_space {
+ my $sum = 0;
+
+ my $dscdir = $self->get('DSC Dir');
++return -1 unless (defined $dscdir);
++
+ my $build_dir = $self->get('Build Dir');
+ my $pkgbuilddir = "$build_dir/$dscdir";
+
+ # if the source package was not yet unpacked, we will not attempt to
compute
+ # the required space.
+-unless( defined $dscdir && -d $dscdir)
+-{
+- return -1;
+-}
+-
++return -1 unless ($self->get('Session')->test_directory($pkgbuilddir));
+
+ my ($space, $spacenum);
+
diff -Nru sbuild-0.78.1/debian/patches/series
sbuild-0.78.1/debian/patches/series
--- sbuild-0.78.1/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ sbuild-0.78.1/debian/patches/series 2019-04-03 13:59:20.0 +0200
@@ -0,0 +1,2 @@
+fix-disk-space-directory-check.patch
+support-gzip-in-wheezy.patch
diff -Nru sbuild-0.78.1/debian/patches/support-gzip-in-wheezy.patch
sbuild-0.78.1/debian/patches/support-gzip-in-wheezy.patch
--- sbuild-0.78.1/debian/patches/support-gzip-in-wheezy.patch 1970-01-01
01:00:00.0 +0100
+++ sbuild-0.78.1/debian/patches/support-gzip-in-wheezy.patch 2019-04-03
13:58:53.0 +0200
@@ -0,0 +1,16 @@
+Description: gzip in wheezy lacks --keep option, so avoid using it.
+Author: Mike Gabriel
+
+--- a/lib/Sbuild/ResolverBase.pm
b/lib/Sbuild/ResolverBase.pm
+@@ -1445,8 +1445,8 @@
+ closedir($dh);
+ }
+
+-system('gzip', '--keep', '--force', 'Packages') == 0 or die "gzip failed:
$?\n";
+-system('gzip', '--keep', '--force', 'Sources') == 0 or die "gzip failed:
$?\n";
++system('gzip -c --force Packages > Packages.gz') == 0 or die "gzip failed:
$?\n";
++system('gzip -c --force Sources > Sources.gz' ) == 0 or die "gzip failed:
$?\n";
+
+ my $packages_md5 = hash_file('Packages', 'md5sum');
+ my $sources_md5 = hash_file('Sources', 'md5sum');
Bug#925588: calibre sets ebook-edit as default editor for docx files
Package: calibre
Version: 3.39.1+dfsg-2
Severity: important
Hi,
I'm unsure where the bug exactly is, so please reassign as necessary.
Steps to reproduce:
Before installing calibre:
$ python3 -c 'import mailcap;
print(mailcap.findmatch(mailcap.getcaps(),"application/vnd.openxmlformats-officedocument.wordprocessingml.document"))'
("soffice --nologo --writer '/dev/null'", {'view': "soffice --nologo
--writer '%s'", 'edit': "soffice --nologo --writer '%s'", 'test': 'test -n
"$DISPLAY"', 'description': '"Office Open XML Document"', 'nametemplate':
'%s.docx', 'lineno': 651})
After installing calibre:
python3 -c 'import mailcap;
print(mailcap.findmatch(mailcap.getcaps(),"application/vnd.openxmlformats-officedocument.wordprocessingml.document"))'
('ebook-edit /dev/null', {'view': 'ebook-edit %s', 'test': 'test -n
"$DISPLAY"', 'lineno': 86})
It seems that installing calibre leaves my /etc/mailcap in a state that
makes ebook-edit the default program for opening docx files. I assume
you agree that is undesirable when libreoffice is also installed?
Thanks!
cheers, josch
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf
Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages calibre depends on:
ii calibre-bin 3.39.1+dfsg-2
ii fonts-liberation 1:1.07.4-7
ii imagemagick 8:6.9.10.23+dfsg-2
ii imagemagick-6.q16 [imagemagick] 8:6.9.10.8+dfsg-1
ii libjpeg-turbo-progs 1:1.5.2-2+b1
ii libjs-coffeescript 1.12.8~dfsg-1
ii libjs-mathjax2.7.4+dfsg-1
ii optipng 0.7.7-1
ii poppler-utils0.63.0-2
ii python-apsw 3.16.2-r1-2+b2
ii python-chardet 3.0.4-1
ii python-cherrypy3 8.9.1-2
ii python-css-parser1.0.4-1
ii python-cssselect 1.0.3-1
ii python-cssutils 1.0.2-1
ii python-dateutil 2.6.1-1
ii python-dbus 1.2.8-2+b1
ii python-feedparser5.2.1-1
ii python-html5-parser 0.4.4-1+b1
ii python-html5lib 1.0.1-1
ii python-lxml 4.2.3-1
ii python-markdown 2.6.9-1
ii python-mechanize 1:0.2.5-3
ii python-msgpack 0.5.6-1+b1
ii python-netifaces 0.10.4-1+b1
ii python-pil 5.2.0-2
ii python-pkg-resources 39.2.0-1
ii python-pyparsing 2.2.0+dfsg1-2
ii python-pyqt5 5.11.3+dfsg-1+b3
ii python-pyqt5.qtsvg 5.11.3+dfsg-1+b3
ii python-pyqt5.qtwebkit5.11.3+dfsg-1+b3
ii python-regex 0.1.20180609-1+b1
ii python-routes2.4.1-1
ii python2.72.7.15-4
ii xdg-utils1.1.3-1
Versions of packages calibre recommends:
pn python-dnspython
Versions of packages calibre suggests:
pn python-unrardll
-- debconf-show failed
Bug#924929: unblock: mmdebstrap/0.4.1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package mmdebstrap The mmdebstrap autopkgtest caused problems on Debian CI. See #924854. Attached there is a minimal patch that just marks the autopkgtest as flaky. unblock mmdebstrap/0.4.1-1 diff -Nru mmdebstrap-0.4.1/debian/changelog mmdebstrap-0.4.1/debian/changelog --- mmdebstrap-0.4.1/debian/changelog 2019-03-01 14:53:42.0 +0100 +++ mmdebstrap-0.4.1/debian/changelog 2019-03-18 14:46:01.0 +0100 @@ -1,3 +1,9 @@ +mmdebstrap (0.4.1-2) unstable; urgency=medium + + * Mark autopkgtest as flaky (closes: #924854) + + -- Johannes 'josch' Schauer Mon, 18 Mar 2019 14:46:01 +0100 + mmdebstrap (0.4.1-1) unstable; urgency=medium * new upstream release diff -Nru mmdebstrap-0.4.1/debian/tests/control mmdebstrap-0.4.1/debian/tests/control --- mmdebstrap-0.4.1/debian/tests/control 2019-02-24 00:48:41.0 +0100 +++ mmdebstrap-0.4.1/debian/tests/control 2019-03-18 14:45:02.0 +0100 @@ -1,3 +1,3 @@ Tests: testsuite Depends: mmdebstrap, arch-test, fakechroot, fakeroot, mount, uidmap, proot, qemu-user, qemu-user-static, binfmt-support, dpkg-dev, grep-dctrl, curl, python3, sudo, debootstrap -Restrictions: needs-root, allow-stderr +Restrictions: needs-root, allow-stderr, flaky
Bug#921924: fakechroot: mv(1) cannot be used inside fakechroot
Package: fakechroot Version: 2.19-3.2 Severity: grave Justification: renders package unusable Control: block -1 by 915559 Hi, currently, it is not possible to use the mv(1) tool from coreutils within fakechroot. Since mv is also used in the dash and apt postinst scripts, this means that: - fakechroot is unfit for a debootstrap-like scenario - shell scripts using mv will not work inside fakechroot Since one of the main uses of fakechroot is to be used together with debootstrap and since the mv tool is such an essential utility, I'm marking this bug with RC severity. Steps to reproduce: $ fakechroot fakeroot -s fakeroot.state debootstrap --variant=fakechroot unstable debian-unstable [...] W: Failure while configuring required packages. W: See /home/josch/debian-unstable/debootstrap/debootstrap.log for details (possibly the package dash is at fault) And from the log: Setting up dash (0.5.10.2-5) ... No diversion 'diversion of /bin/sh by bash', none removed. Adding 'diversion of /bin/sh to /bin/sh.distrib by dash' mv: cannot move '/bin/sh.tmp' to '/bin/sh': No such file or directory dpkg: error processing package dash (--configure): installed dash package post-installation script subprocess returned error exit status 1 To reproduce it manually: fakechroot fakeroot -s fakeroot.state chroot debian-unstable mv /bin/sh.tmp /bin/sh mv: cannot move '/bin/sh.tmp' to '/bin/sh': No such file or directory The problem is, that coreutils directly invokes the renameat2 systemcall instead of its glibc wrapper function. fakechroot cannot intercept system calls, so the bare renameat2 call will be executed. From wrapping the above in strace: [pid 8332] renameat2(AT_FDCWD, "/bin/sh.tmp", AT_FDCWD, "/bin/sh", RENAME_NOREPLACE) = -1 ENOENT (No such file or directory) As one can see, the paths did not get adjusted by fakechroot. There is a bug against coreutils which backports a patch from coreutils upstream that fixes this problem. The issue is tracked in #915559. Thanks! cheers, josch
Bug#921814: lintian: spelling_exceptions() only considers binary packages
Package: lintian Version: 2.6.0 Severity: normal Hi, the function spelling_exceptions() only considers binary packages to add exceptions to the spell checking. This leads to situation where tags like spelling-error-in-patch-description are emitted depending on whether a binary package was added to the lintian call. An example is the src:alot package where we used to have an override for spelling-error-in-patch-description but then discovered that lintian will complain about an unused tag when we also add the binary package: $ lintian --pedantic --display-info --display-experimental alot_0.8-1.dsc alot_0.8-1_amd64.changes I: alot source: out-of-date-standards-version 4.2.1 (released 2018-08-25) (current is 4.3.0) I: alot source: testsuite-autopkgtest-missing X: alot source: upstream-metadata-file-is-missing I: alot source: unused-override spelling-error-in-patch-description debian/patches/0003-alot-UnicodeEncodeError-for-search-queries-with-non-.patch alot a lot N: 0 tags overridden; 1 unused override $ lintian --pedantic --display-info --display-experimental alot_0.8-1.dsc I: alot source: out-of-date-standards-version 4.2.1 (released 2018-08-25) (current is 4.3.0) I: alot source: testsuite-autopkgtest-missing X: alot source: upstream-metadata-file-is-missing N: 1 tag overridden (1 warning) I think what instead should happen is, that the function also considers the source package, specifically the Source and Binary fields. Thanks! cheers, josch
Bug#921345: ITP: python-miio -- Python library for interfacing with Xiaomi smart appliances
Package: wnpp Severity: wishlist Owner: Johannes 'josch' Schauer * Package name: python-miio Version : 0.4.4 Upstream Author : Teemu Rytilahti * URL : https://python-miio.readthedocs.io/ * License : GPL3 Programming Lang: Python Description : Python library for interfacing with Xiaomi smart appliances This library (and its accompanying cli tool) is used to interface with devices using Xiaomi’s miIO protocol: * Xiaomi Mi Robot Vacuum (miio.vacuum) * Xiaomi Mi Home Air Conditioner Companion (miio.airconditioningcompanion) * Xiaomi Mi Air Purifier (miio.airpurifier) * Xiaomi Aqara Camera (miia.aqaracamera) * Xiaomi Mi Smart WiFi Socket (miio.chuangmi_plug) * Xiaomi Chuangmi Plug V1 (1 Socket, 1 USB Port) (miio.chuangmi_plug) * Xiaomi Chuangmi Plug V3 (1 Socket, 2 USB Ports) (miio.chuangmi_plug) * Xiaomi Smart Power Strip V1 and V2 (WiFi, 6 Ports) (miio.powerstrip) * Xiaomi Philips Eyecare Smart Lamp 2 (miio.philips_eyecare) * Xiaomi Philips LED Ceiling Lamp (miio.ceil) * Xiaomi Philips LED Ball Lamp (miio.philips_bulb) * Xiaomi Philips Zhirui Smart LED Bulb E14 Candle Lamp (miio.philips_bulb) * Xiaomi Philips Zhirui Bedroom Smart Lamp (miio.philips_moonlight) * Xiaomi Universal IR Remote Controller (Chuangmi IR) (miio.chuangmi_ir) * Xiaomi Mi Smart Pedestal Fan V2, V3, SA1 and ZA1 (miio.fan) * Xiaomi Mi Air Humidifier (miio.airhumidifier) * Xiaomi Mi Water Purifier (Basic support: Turn on & off) (miio.waterpurifier) * Xiaomi PM2.5 Air Quality Monitor (miio.airqualitymonitor) * Xiaomi Smart WiFi Speaker (miio.wifispeaker) * Xiaomi Mi WiFi Repeater 2 (miio.wifirepeater) * Xiaomi Mi Smart Rice Cooker (miio.cooker) * Xiaomi Smartmi Fresh Air System (miio.airfresh) * Yeelight light bulbs (miio.yeelight)
Bug#920701: diffoscope: Please document and allow to disable automatic inclusion of dbgsym packages
Package: diffoscope Version: 108 Severity: wishlist Hi, steps to reproduce: Input: two directories dirA and dirB with some sbuild build artifacts, so .changes file, .buildinfo file, .deb and .dbgsym packages. Command: diffoscope dirA/foo.deb dirB/foo.deb Expectation: diffoscope accesses dirA/foo.deb and dirB/foo.deb and recursively analyses its content to show the differences. Reality: diffoscope tries to be clever and also accesses dirA/foo.dbgsym and dirB/foo.dbgsym in addition to the explicitly specified input files in an attempt to produce more useful output. The problems are: - I assume that most people would expect that if they give two files to a "diff" command, then that command will only use these two files as input and will not implicitly add other files. - If I wanted diffoscope to also consider the .dbgsym packages, then I would've given diffoscope the .changes file and not the .deb files directly - I have a package with a 180 MB .dbgsym package. I cancelled diffoscope after it was running for over two hours. Even when I add --exclude-command=objdump, diffoscope will still take 3 minutes, because extracting two 180 MB xz-archives takes a while. Only when I copy the .deb packages elsewhere, is diffoscope done in 1.5 minutes. - This behaviour is not documented - This behaviour cannot be switched off I suggest to at least: - document this behaviour because I find it extremely unexpected for a diff program to consider other input files outside the ones that were explicitly specified - add an option to switch off this behaviour because I don't want to always have to copy my .deb packages elsewhere to achieve reasonable runtimes Though personally I would instead remove this magic completely or change the default for the following reasons: - even if it's documented, the current default behaviour is still unexpected for a diff program - if the user wants diffoscope to consider the .dbgsym packages, then they can just ask for a comparison of the .changes file instead - after it has been switched off by default, there could be a command line argument to switch this behaviour on for the users who want or need it Thanks! cheers, josch
Bug#919563: devscripts: simplify annotate-output
Package: devscripts
Version: 2.19.2
Severity: wishlist
Hi,
please correct me if I'm wrong but could annotate-output not be greatly
simplified by using this proof-of-concept:
handler () {
while IFS= read -r line || [ -n "$line" ]; do
printf "%s %s: %s\n" "$(date --iso-8601=seconds)" "$1"
"$line"
done
}
{ "$@" 2>&1 1>&3 3>&- | handler E; } 3>&1 1>&2 | handler O
So the script would loose some complexity and would not have as much
stuff in the background anymore like processes and temporary files it
needs to clean up. It could:
- remove cleanup exit trap
- no temporary directory
- no temporary fifos
- no background processes to start and cleanup
Am I missing an obvious reasons why fifos are used instead?
Thanks!
cheers, josch
Bug#918664: linux-latest: please provide a meta package for a sane architecture-specific default
Source: linux-latest Version: 4.17+95 Severity: wishlist Hi, please provide an architecture-specific meta package which depends on a sane default of a kernel image on that architecture. For example: Package: linux-image Depends: linux-image-powerpc64 [ppc64], linux-image-parisc [hppa], linux-image-armmp [armhf], linux-image-686 [i386], ... I know that the right kernel image is not a function of the Debian architecture alone. But this meta-package is not supposed to replace kernel selection for d-i or the like. It is meant to be one central place to encode a sane default mapping in the Debian linux kernel package instead of (poorly) replicating such a mapping in individual packages. Examples: https://sources.debian.org/src/autopkgtest/5.7/tools/autopkgtest-build-qemu/?hl=118#L100 https://sources.debian.org/src/supermin/5.1.19-4/debian/control/?hl=26#L17 https://sources.debian.org/src/live-build/1:20180925/scripts/build/installer_debian-installer/?hl=330#L317 https://sources.debian.org/src/fai/5.7.3/conf/NFSROOT/?hl=64#L49 https://sources.debian.org/src/propellor/5.5.0-2/src/Propellor/Property/Machine.hs/?hl=192#L186 https://sources.debian.org/src/libguestfs/1:1.38.6-2/debian/control/?hl=53#L52 https://sources.debian.org/src/nbdkit/1.8.2-1/debian/control/?hl=25#L23 https://sources.debian.org/src/python-diskimage-builder/2.16.0-1/diskimage_builder/elements/debian-minimal/package-installs.yaml/?hl=3#L1 https://sources.debian.org/src/debootstick/2.1/scripts/create-image/target/pc/packages/?hl=11#L14 I stumbled across this problem because I was about to write some similar logic in my own upstream project mmdebstrap. I thought that instead, such a default mapping from Debian architecture to sensible linux kernel image default should live in the linux-latest source package. Thanks! cheers, josch
Bug#918002: xml2: please include examples in the package
Package: xml2 Version: 0.5-2 Severity: normal Hi, one of the reasons to include documentation in the Debian package instead of referring to an online URL is that the remote resource might disappear anytime. This just happened with http://dan.egnor.name/xml2/ref and http://dan.egnor.name/xml2/examples that are referenced from the xml2 man page. But archive.org still has them, so it should be possible to retrieve them from there and add them to the package. Thanks! cheers, josch
Bug#917920: fakechroot: fails to find libsystemd-shared-240.so when installin systemd
Package: fakechroot Version: 2.19-3 Severity: normal Hi, when installing systemd under fakechroot one currently gets the following error during package configuration. Setting up systemd (240-2) ... Created symlink /etc/systemd/system/getty.target.wants/getty@tty1.service → /lib/systemd/system/getty@.service. Created symlink /etc/systemd/system/multi-user.target.wants/remote-fs.target → /lib/systemd/system/remote-fs.target. Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /lib/systemd/system/systemd-timesyncd.service. Created symlink /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → /lib/systemd/system/systemd-timesyncd.service. systemd-machine-id-setup: error while loading shared libraries: libsystemd-shared-240.so: cannot open shared object file: No such file or directory dpkg: error processing package systemd (--configure): installed systemd package post-installation script subprocess returned error exit status 127 Setting up dmsetup (2:1.02.155-1) ... Errors were encountered while processing: systemd E: Sub-process /usr/bin/dpkg returned an error code (1) A workaround is to add "/lib/systemd" to LD_LIBRARY_PATH. But maybe there is a better solution. Anyways, this should work out-of-the-box. Thanks! cheers, josch
Bug#917773: shadow: doesn't respect SOURCE_DATE_EPOCH
Source: shadow Severity: normal User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps Hi, the /etc/shadow as created by debootstrap does not respect the SOURCE_DATE_EPOCH environment variable anymore. This bug was formerly fixed in #857803. Steps to reproduce: $ sudo SOURCE_DATE_EPOCH=0 debootstrap --variant=minbase unstable debian-unstable $ sudo cat debian-unstable/etc/shadow root:*:17895:0:9:7::: daemon:*:17895:0:9:7::: bin:*:17895:0:9:7::: sys:*:17895:0:9:7::: sync:*:17895:0:9:7::: games:*:17895:0:9:7::: man:*:17895:0:9:7::: lp:*:17895:0:9:7::: mail:*:17895:0:9:7::: news:*:17895:0:9:7::: uucp:*:17895:0:9:7::: proxy:*:17895:0:9:7::: www-data:*:17895:0:9:7::: backup:*:17895:0:9:7::: list:*:17895:0:9:7::: irc:*:17895:0:9:7::: gnats:*:17895:0:9:7::: nobody:*:17895:0:9:7::: _apt:*::0:9:7::: So some parts of shadow respect SOURCE_DATE_EPOCH (the user _apt is created with a lastchange field of zero) but other parts do not (the remaining users). Unfortunately I don't have time to debug this problem right now but my hunch is, that the culprit is a line like this: https://sources.debian.org/src/shadow/1:4.5-1.1/src/pwconv.c/?hl=268#L268 Instead, spent.sp_lstchg should be set to the return value of the gettime() function. Thanks! cheers, josch
Bug#917407: python3.7: different pyc depending on how python3.7 is installed
Source: python3.7 Severity: minor User: reproducible-bui...@lists.alioth.debian.org Usertags: toolchain Hi, I noticed that the pyc files generated by Python 3.7 (but not by earlier Python versions) is different depending on how the package is installed. I use __init__.cpython-37.pyc as an example but other .pyc files also differ. With debootstrap --include: $ sudo SOURCE_DATE_EPOCH=1545769394 LC_ALL=C.UTF-8 debootstrap --variant=minbase --include=python3 unstable debian-unstable $ md5sum debian-unstable/usr/lib/python3.7/collections/__pycache__/__init__.cpython-37.pyc df6fe61fe176e4858ce2062233d2280e debian-unstable/usr/lib/python3.7/collections/__pycache__/__init__.cpython-37.pyc Installing with apt after a minbase debootstrap: $ sudo SOURCE_DATE_EPOCH=1545769394 LC_ALL=C.UTF-8 debootstrap --variant=minbase unstable debian-unstable $ sudo SOURCE_DATE_EPOCH=1545769394 LC_ALL=C.UTF-8 chroot debian-unstable apt-get install python3 $ md5sum debian-unstable/usr/lib/python3.7/collections/__pycache__/__init__.cpython-37.pyc 2c6fdc51b035428a3881f3eef70e3a5b debian-unstable/usr/lib/python3.7/collections/__pycache__/__init__.cpython-37.pyc Manually installing with dpkg (in an order that respects Pre-Depends): $ sudo SOURCE_DATE_EPOCH=1545769394 LC_ALL=C.UTF-8 debootstrap --variant=minbase unstable debian-unstable $ sudo SOURCE_DATE_EPOCH=1545769394 LC_ALL=C.UTF-8 chroot debian-unstable apt install bzip2 file libexpat1 libmagic-mgc libmagic1 libmpdec2 libreadline7 libsqlite3-0 libssl1.1 mime-support readline-common xz-utils $ sudo SOURCE_DATE_EPOCH=1545769394 LC_ALL=C.UTF-8 chroot debian-unstable apt-get install --download-only python3 $ sudo SOURCE_DATE_EPOCH=1545769394 LC_ALL=C.UTF-8 chroot debian-unstable sh -c "cd /var/cache/apt/archives; dpkg -i libpython3.7-minimal_3.7.2~rc1-1_amd64.deb python3.7-minimal_3.7.2~rc1-1_amd64.deb" $ sudo SOURCE_DATE_EPOCH=1545769394 LC_ALL=C.UTF-8 chroot debian-unstable sh -c "cd /var/cache/apt/archives; dpkg -i python3-minimal_3.7.1-3_amd64.deb" $ sudo SOURCE_DATE_EPOCH=1545769394 LC_ALL=C.UTF-8 chroot debian-unstable sh -c "cd /var/cache/apt/archives; dpkg -i libpython3.7-stdlib_3.7.2~rc1-1_amd64.deb libpython3-stdlib_3.7.1-3_amd64.deb python3_3.7.1-3_amd64.deb python3.7_3.7.2~rc1-1_amd64.deb" $ md5sum debian-unstable/usr/lib/python3.7/collections/__pycache__/__init__.cpython-37.pyc 2c6fdc51b035428a3881f3eef70e3a5b debian-unstable/usr/lib/python3.7/collections/__pycache__/__init__.cpython-37.pyc So manually installing with dpkg in the right order yields the same hash as with apt. So despite bug #917386 this might not be an apt bug. I found that depending on the postinstall that is executed, the hash is different. So I removed __init__.cpython-37.pyc and then ran dpkg-reconfigure for several packages. Here are the hashes of __init__.cpython-37.pyc depending on the postinst that got run: python3.7: c06080cb5a72be8e409814025236f097 python3.7-minimal: df6fe61fe176e4858ce2062233d2280e python3-minimal: b940cc549d39dd3e521a41b8eba3a295 python3: b940cc549d39dd3e521a41b8eba3a295 Debian policy §6.2 requires idempotency for individual maintainer scripts which is not violated here. Nevertheless I would argue, that it would make sense for different Python3 maintainer scripts not to leave the same files with different content depending on which maintainer script is being run. As by the analysis above, there exist at least five different ways that pyc files can end up. For the sake of reproducibility, there should probably only be one result independent on how Python3 is installed. Thanks! cheers, josch
Bug#917386: apt: Difference in installation depending on real tty or not
Package: apt Version: 1.8.0~alpha3 Severity: normal Hi, this bug shows how apt leaves the system in a different state depending on whether its stdout/stderr are connected to a real tty or not. I'm not appending my package versions or apt config because to reproduce this problem, we are using apt from an up-to-date Debian chroot: $ sudo debootstrap --variant=minbase unstable debian-unstable $ sudo SOURCE_DATE_EPOCH=1545769394 LC_ALL=C.UTF-8 chroot debian-unstable apt-get --yes install python3 $ md5sum debian-unstable/usr/lib/python3.7/collections/__pycache__/__init__.cpython-37.pyc 2c6fdc51b035428a3881f3eef70e3a5b debian-unstable/usr/lib/python3.7/collections/__pycache__/__init__.cpython-37.pyc You can remove the "debian-unstable" directory and repeat this step as often as you want. The md5sum will remain the same. Now try the same thing but connect the stdout and stderr to "cat": $ sudo debootstrap --variant=minbase unstable debian-unstable $ sudo SOURCE_DATE_EPOCH=1545769394 LC_ALL=C.UTF-8 chroot debian-unstable apt-get --yes install python3 2>&1 | cat $ md5sum debian-unstable/usr/lib/python3.7/collections/__pycache__/__init__.cpython-37.pyc df6fe61fe176e4858ce2062233d2280e debian-unstable/usr/lib/python3.7/collections/__pycache__/__init__.cpython-37.pyc Again, you can repeat this as often as you want, the md5sum will remain stable. Some observations: - SOURCE_DATE_EPOCH has to be set for reproducible output - LC_ALL has to be set. Without it, the md5sum of the second test will be equal to the first even if stderr and stdout get redirected (why??) - the pyc get compiled in the postinst of the Python packages but a different pyc gets compiled by different postinst scripts. To verify this, try to remove a pyc and then invoke different postints. I thus speculate, that the problem might be that in both scenarios, the postinst scripts get invoked in different order. - there are more pyc files that differ. The example I picked is just one with a lot of differences. So this might just as well be a bug in the Python packages where the postinst scripts should output the same pyc independent of which postinst script is being invoked. But right now I don't even know whether postinst invokation order is the culprit and all I see is a difference when invoking apt differently. Thus I'm filing the bug with apt first. Thanks! cheers, josch
Bug#916913: libpcl-dev: PCLConfig.cmake fails to find eigen
Package: libpcl-dev Version: 1.9.1+dfsg1-2 Severity: grave Justification: renders package unusable Hi, a CMakeLists.txt with "find_package(PCL REQUIRED)" will currently result in: CMake Warning at /usr/lib/x86_64-linux-gnu/cmake/pcl/PCLConfig.cmake:159 (find_package): By not providing "FindEigen.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "Eigen", but CMake did not find one. Could not find a package configuration file provided by "Eigen" with any of the following names: EigenConfig.cmake eigen-config.cmake Add the installation prefix of "Eigen" to CMAKE_PREFIX_PATH or set "Eigen_DIR" to a directory containing one of the above files. If "Eigen" provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): /usr/lib/x86_64-linux-gnu/cmake/pcl/PCLConfig.cmake:313 (find_eigen) /usr/lib/x86_64-linux-gnu/cmake/pcl/PCLConfig.cmake:544 (find_external_library) src/ros/CMakeLists.txt:22 (find_package) CMake Error at /usr/lib/x86_64-linux-gnu/cmake/pcl/PCLConfig.cmake:59 (message): common is required but eigen was not found Call Stack (most recent call first): /usr/lib/x86_64-linux-gnu/cmake/pcl/PCLConfig.cmake:362 (pcl_report_not_found) /usr/lib/x86_64-linux-gnu/cmake/pcl/PCLConfig.cmake:544 (find_external_library) src/ros/CMakeLists.txt:22 (find_package) -- Configuring incomplete, errors occurred! But libeigen3-dev is installed. For a full failing build log see: https://api.travis-ci.org/v3/job/470351936/log.txt Thanks! cheers, josch
Bug#915934: libeigen3-dev: cannot build with Eigen anymore after upgrade of gcc-8 to 8.2.0-11
Package: libeigen3-dev
Version: 3.3.5-2
Severity: grave
Justification: renders package unusable
Hi,
steps to reproduce:
--%<---
#include "eigen3/Eigen/Eigen"
int main(int argc, char* argv[]) { return 0; }
-->%---
$ gcc main.cc
In file included from /usr/include/eigen3/Eigen/SparseCore:50,
from /usr/include/eigen3/Eigen/Sparse:26,
from /usr/include/eigen3/Eigen/Eigen:2,
from main.cc:1:
/usr/include/eigen3/Eigen/src/SparseCore/SparseBlock.h: In member function
'Eigen::internal::sparse_matrix_block_impl::BlockType&
Eigen::internal::sparse_matrix_block_impl::operator=(const BlockType&)':
/usr/include/eigen3/Eigen/src/SparseCore/SparseBlock.h:216:33: error: expected
primary-expression before '>' token
return operator=(other);
^
This did not happen with snapshot 20181207T090635Z where src:gcc-8
packages were still in version 8.2.0-10. It started happening one
dinstall later in snapshot 20181207T153749Z where src:gcc-8 version
8.2.0-11 got uploaded.
Thanks!
cheers, josch
Bug#915913: autopkgtest: please document what the syntax of the Features field is
Package: autopkgtest Version: 5.6 Severity: normal Hi, from here: https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst it says: > Features: feature-name [, another-feature-name ...] > Declares some additional capabilities or good properties of the > tests defined in this stanza. Any unknown features declared will be > completely ignored. See below for the defined features. > > Features are separated by commas and/or whitespace. then further below under "defined features" it says: > test-name > Set an explicit test name for the log heading and the ``summary`` file > for a ``Test-Command:`` inline test. When not given, these are > enumerated like ``command1``. But this does not explain the syntax of how a test name is actually specified. Does one just write it in the Features field? Or is it test-name:thename or does one have to quote something? Please document what the right syntax is. My use case: I have a test that uses Test-Command but the output becomes hard to understand if tests are just named command1, command2 and so forth. Thus I want to give them meaningful names. Unfortunately under "Test-Command" it also says "This is mutually exclusive with the ``Tests:`` field". Is there a practical reason why these fields are mutually exclusive? Naively, I would've expected, that when Test-Command is given, then it doesn't look for a script but instead executes the command but that it anyways takes the test name from the "Tests" field. It seems unnecessarily complicated to require the test-name feature thing. Thanks! cheers, josch
Bug#915874: rename(1): incorrect note since glibc 2.28
Package: manpages Version: 4.16-1 Severity: normal Hi, currently, the manpage for rename(2) states: Note: There is no glibc wrapper for renameat2(); see NOTES. and further down under NOTES: Glibc does not provide a wrapper for the renameat2() system call; call it using syscall(2). but version 2.28 introduced a renameat2() wrapper as can be seen in the corresponding section of its NEWS file: * The renameat2 function has been added, a variant of the renameat function which has a flags argument. If the flags are zero, the renameat2 function acts like renameat. If the flag is not zero and there is no kernel support for renameat2, the function will fail with an errno value of EINVAL. This is different from the existing gnulib function renameatu, which performs a plain rename operation in case of a RENAME_NOREPLACE flags and a non-existing destination (and therefore has a race condition that can clobber the destination inadvertently). So please correct the man page accordingly, as glibc 2.28 is now in unstable. Thanks! cheers, josch
Bug#915695: libmpfr-dev: please also install mpfr.pc
Package: libmpfr-dev Version: 4.0.1-1 Severity: wishlist Hi, Since 4.0.0, MPFR also ships a pkg-config file which is generated from mpfr.pc.in. Please consider installing mpfr.pc in libmpfr-dev. Thanks! cheers, josch
Bug#915559: coreutils: Use renameat2 from glibc instead of syscall
Package: coreutils Version: 8.30-1 Severity: normal Tags: patch Control: block #909612 by -1 Hi, recently (2018-11-29), glibc 2.28 was accepted in unstable. It adds a wrapper for the renameat2 syscall. That wrapper is necessary for fakechroot because fakechroot cannot intercept system calls but uses a preloaded library to intercept library calls. Up to coreutils 8.30, mv(1) uses the renameat2 syscall which makes mv(1) fail under fakechroot. See #909612. Now that glibc 2.28 offers the renameat2 library function as a wrapper to the syscall, coreutils added support for choosing the library function instead of the syscall if the former is available: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=c50cf67bd7ff70525f3cb4074f0d9cc1f5c6cf9c I don't know if another coreutils release is likely to happen before the freeze but if it isn't please consider the attached patch which backports the commit from the gnulib git to coreutils 8.30. Without this patch, fakechroot is currently not very useful because the mv(1) tool is unusable inside fakechroot. Most prominently, apt uses mv(1) inside its postinst script, so its impossible to install apt inside fakechroot and thus one cannot setup a sensible system. Thanks! cheers, josch diff -Nru coreutils-8.30/debian/changelog coreutils-8.30/debian/changelog --- coreutils-8.30/debian/changelog 2018-08-29 22:20:06.0 +0200 +++ coreutils-8.30/debian/changelog 2018-12-04 20:49:07.0 +0100 @@ -1,3 +1,11 @@ +coreutils (8.30-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Add patch that uses renameat2 from glibc instead of the syscall if +available (closes: #XX) + + -- Johannes 'josch' Schauer Tue, 04 Dec 2018 20:49:07 +0100 + coreutils (8.30-1) unstable; urgency=low * New upstream version diff -Nru coreutils-8.30/debian/patches/prefer-renameat2-from-glibc-over-syscall.patch coreutils-8.30/debian/patches/prefer-renameat2-from-glibc-over-syscall.patch --- coreutils-8.30/debian/patches/prefer-renameat2-from-glibc-over-syscall.patch 1970-01-01 01:00:00.0 +0100 +++ coreutils-8.30/debian/patches/prefer-renameat2-from-glibc-over-syscall.patch 2018-12-04 20:49:07.0 +0100 @@ -0,0 +1,40 @@ +From: Johannes 'josch' Schauer +Date: Tue, 4 Dec 2018 20:57:48 +0100 +X-Dgit-Generated: 8.30-1.1 318c43f7b611cf7d81a45a768482227ac7500832 +Subject: Prefer renameat2 from glibc over syscall if available + +This is necessary for fakechroot to be able to overwrite renameat2 which +is used by mv(1) from coreutils. See #909612 + +This patch is based on a patch by Andreas Henriksson +which was accepted in gnulib git: + +https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=c50cf67bd7ff70525f3cb4074f0d9cc1f5c6cf9c + +--- + +--- coreutils-8.30.orig/lib/renameat2.c coreutils-8.30/lib/renameat2.c +@@ -77,7 +77,10 @@ renameat2 (int fd1, char const *src, int + int ret_val = -1; + int err = EINVAL; + +-#ifdef SYS_renameat2 ++#ifdef HAVE_RENAMEAT2 ++ ret_val = renameat2 (fd1, src, fd2, dst, flags); ++ err = errno; ++#elif defined SYS_renameat2 + ret_val = syscall (SYS_renameat2, fd1, src, fd2, dst, flags); + err = errno; + #elif defined RENAME_EXCL +--- coreutils-8.30.orig/m4/renameat.m4 coreutils-8.30/m4/renameat.m4 +@@ -15,7 +15,7 @@ AC_DEFUN([gl_FUNC_RENAMEAT], + AC_REQUIRE([gl_STDIO_H_DEFAULTS]) + AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS]) + AC_CHECK_HEADERS([linux/fs.h]) +- AC_CHECK_FUNCS_ONCE([renameat]) ++ AC_CHECK_FUNCS_ONCE([renameat renameat2]) + if test $ac_cv_func_renameat = no; then + HAVE_RENAMEAT=0 + elif test $REPLACE_RENAME = 1; then diff -Nru coreutils-8.30/debian/patches/series coreutils-8.30/debian/patches/series --- coreutils-8.30/debian/patches/series2017-10-02 19:31:47.0 +0200 +++ coreutils-8.30/debian/patches/series2018-12-04 20:49:07.0 +0100 @@ -3,3 +3,4 @@ 72_id_checkngroups.patch 85_timer_settime.patch 99_kfbsd_fstat_patch.patch +prefer-renameat2-from-glibc-over-syscall.patch
Bug#914515: dpkg: please provide an interface to bootstrap dpkg from zero
Package: dpkg Version: 1.19.2 Severity: wishlist Hi, lintian recently tagged mmdebstrap with uses-dpkg-database-directly because mmdebstrap contains the string "/var/lib/dpkg" in several places. Instead of overwriting the lintian tag in mmdebstrap, dpkg could also gain an interface which avoids mmdebstrap having to do anything with /var/lib/dpkg inside the chroot. Specifically, what mmdebstrap does is the following: - create /var/lib/dpkg, /var/lib/dpkg/triggers, /var/lib/dpkg/info, /var/lib/dpkg/alternatives and /var/lib/dpkg/updates because dpkg throws an error if these directories are not present - an empty /var/lib/dpkg/status because dpkg refuses to work without the file being present - adds architectures to /var/lib/dpkg/arch because $(dpkg --add-architecture) doesn't work without any packages inside the chroot - cleans up leftover /var/lib/dpkg/lock-frontend and /var/lib/dpkg/lock This could be avoided if: - dpkg would not complain anymore about non-existing directories but instead create them if they don't exist yet - dpkg would not complain about a non-existing status file but create an empty one if it doesn't exist yet - allow $(dpkg --add-architecture) to work in places other than / - add an interface to clean up /var/lib/dpkg Thanks! cheers, josch
Bug#914415: libguestfs-tools: at least recommend a kernel image
Package: libguestfs-tools Version: 1:1.38.4-1 Severity: normal Hi, when one runs guestfish on a system without a kernel installed (like a container) one gets the error message below. This is because guestfish runs supermin with --copy-kernel. Thus, having a kernel image available is required for some functionality of libguestfs-tools and the package should at least Recommends such a linux kernel image package. Thanks! cheers, josch *IMPORTANT NOTICE * * When reporting bugs, include the COMPLETE, UNEDITED * output below in your bug report. * PATH=/tmp/autopkgtest.8wcFTU/autopkgtest_tmp/bin:/bin:/usr/bin SELinux: sh: 1: getenforce: not found guestfs_get_append: (null) guestfs_get_autosync: 1 guestfs_get_backend: direct guestfs_get_backend_settings: [] guestfs_get_cachedir: /var/tmp guestfs_get_hv: /usr/bin/qemu-system-x86_64 guestfs_get_memsize: 500 guestfs_get_network: 0 guestfs_get_path: /usr/lib/x86_64-linux-gnu/guestfs guestfs_get_pgroup: 0 guestfs_get_program: libguestfs-test-tool guestfs_get_recovery_proc: 1 guestfs_get_smp: 1 guestfs_get_sockdir: /tmp guestfs_get_tmpdir: /tmp guestfs_get_trace: 0 guestfs_get_verbose: 1 host_cpu: x86_64 Launching appliance, timeout set to 600 seconds. libguestfs: launch: program=libguestfs-test-tool libguestfs: launch: version=1.38.6 libguestfs: launch: backend registered: unix libguestfs: launch: backend registered: uml libguestfs: launch: backend registered: libvirt libguestfs: launch: backend registered: direct libguestfs: launch: backend=direct libguestfs: launch: tmpdir=/tmp/libguestfsA2hE2h libguestfs: launch: umask=0002 libguestfs: launch: euid=1000 libguestfs: is_openable: /dev/kvm: No such file or directory libguestfs: begin building supermin appliance libguestfs: run supermin libguestfs: command: run: /usr/bin/supermin libguestfs: command: run: \ --build libguestfs: command: run: \ --verbose libguestfs: command: run: \ --if-newer libguestfs: command: run: \ --lock /var/tmp/.guestfs-1000/lock libguestfs: command: run: \ --copy-kernel libguestfs: command: run: \ -f ext2 libguestfs: command: run: \ --host-cpu x86_64 libguestfs: command: run: \ /usr/lib/x86_64-linux-gnu/guestfs/supermin.d libguestfs: command: run: \ -o /var/tmp/.guestfs-1000/appliance.d supermin: version: 5.1.19 supermin: package handler: debian/dpkg supermin: acquiring lock on /var/tmp/.guestfs-1000/lock supermin: build: /usr/lib/x86_64-linux-gnu/guestfs/supermin.d supermin: reading the supermin appliance supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/base.tar.gz type gzip base image (tar) supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/daemon.tar.gz type gzip base image (tar) supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/excludefiles type uncompressed excludefiles supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/hostfiles type uncompressed hostfiles supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/init.tar.gz type gzip base image (tar) supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/packages type uncompressed packages supermin: build: visiting /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/udev-rules.tar.gz type gzip base image (tar) supermin: mapping package names to installed packages supermin: resolving full list of package dependencies supermin: build: 217 packages, including dependencies supermin: build: 11375 files supermin: build: 6809 files, after matching excludefiles supermin: build: 6812 files, after adding hostfiles supermin: build: 6812 files, after removing unreadable files supermin: build: 6820 files, after munging supermin: kernel: looking for kernel using environment variables ... supermin: kernel: looking for kernels in /lib/modules/*/vmlinuz ... supermin: kernel: looking for kernels in /boot ... supermin: failed to find a suitable kernel (host_cpu=x86_64). I looked for kernels in /boot and modules in /lib/modules. If this is a Xen guest, and you only have Xen domU kernels installed, try installing a fullvirt kernel (only for supermin use, you shouldn't boot the Xen guest with it). libguestfs: error: /usr/bin/supermin exited with error status 1, see debug messages above libguestfs: closing guestfs handle 0x5563e1035b80 (state 0) libguestfs: command: run: rm libguestfs: command: run: \ -rf /tmp/libguestfsA2hE2h -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppA
Bug#914413: supermin: should at least suggest a kernel package
Package: supermin Version: 5.1.19-3 Severity: wishlist Hi, when using supermin with --copy-kernel on a system without a kernel (like inside a container) then supermin will fail with: > supermin: kernel: looking for kernel using environment variables ... > supermin: kernel: looking for kernels in /lib/modules/*/vmlinuz ... > supermin: kernel: looking for kernels in /boot ... > supermin: failed to find a suitable kernel (host_cpu=x86_64). > > I looked for kernels in /boot and modules in /lib/modules. > > If this is a Xen guest, and you only have Xen domU kernels > installed, try installing a fullvirt kernel (only for > supermin use, you shouldn't boot the Xen guest with it). Since having a kernel image available is required for some use of supermin, it should at least suggest a kernel package in its dependencies. Thanks! cheers, josch -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages supermin depends on: ii apt 1.7.0 ii cpio 2.12+dfsg-6 ii e2fsprogs1.44.3-1 ii libc62.27-6 ii libcom-err2 1.44.3-1 ii libext2fs2 1.44.3-1 supermin recommends no packages. supermin suggests no packages. -- no debconf information
Bug#914378: with Python 3.7: RuntimeError: generator raised StopIteration
Source: python-pygraphviz Version: 1.4~rc1-1+b2 Severity: grave Tags: patch Justification: renders package unusable Hi, steps to reproduce: $ python3 --version Python 3.7.1 $ python3 -c 'import pygraphviz; A=pygraphviz.AGraph(); A.graph_attr.keys()' Traceback (most recent call last): File "/usr/lib/python3/dist-packages/pygraphviz/agraph.py", line 1743, in iteritems ah = gv.agnxtattr(self.handle, self.type, ah) StopIteration: agnxtattr The above exception was the direct cause of the following exception: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/pygraphviz/agraph.py", line 1733, in keys return list(self.__iter__()) File "/usr/lib/python3/dist-packages/pygraphviz/agraph.py", line 1736, in __iter__ for (k, v) in self.iteritems(): RuntimeError: generator raised StopIteration This problem does not happen with snapshot 20181121T102052Z but does happen with snapshot 20181121T232318Z. There is only one change between chroots made from these two snapshots, the following packages have been upgraded from version 3.6.7-1 to 3.7.1-1: libpython3-stdlib, libpython3.6-minimal, libpython3.6-stdlib, python3, python3-minimal, python3.6, python3.6-minimal Thus I conclude that this problem was introduced because of the upgrade of Python from 3.6 to 3.7. Upstream has a fix here: https://github.com/pygraphviz/pygraphviz/commit/b5df022700669ae496f65d20dd9cd387d6af948e I backported that commit on top of the version of python-pygraphviz from Debian unstable. Please find the patch attached. I see that this package did not see an upload since January 2017. If you are okay with me NMU-ing the package for this fix, then please tell me. Alternatively, this bug can also be fixed by packaging the latest upstream version 1.5 of pygraphviz which includes the above commit. Thanks! cheers, josch diff -Nru python-pygraphviz-1.4~rc1/debian/changelog python-pygraphviz-1.4~rc1/debian/changelog --- python-pygraphviz-1.4~rc1/debian/changelog 2017-01-08 21:03:20.0 +0100 +++ python-pygraphviz-1.4~rc1/debian/changelog 2018-11-22 19:31:03.0 +0100 @@ -1,3 +1,10 @@ +python-pygraphviz (1.4~rc1-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix StopIteration with Python 3.7 + + -- Johannes 'josch' Schauer Thu, 22 Nov 2018 19:31:03 +0100 + python-pygraphviz (1.4~rc1-1) unstable; urgency=medium * New upstream release candidate diff -Nru python-pygraphviz-1.4~rc1/debian/patches/catch_stopiterations_created_by_c_code python-pygraphviz-1.4~rc1/debian/patches/catch_stopiterations_created_by_c_code --- python-pygraphviz-1.4~rc1/debian/patches/catch_stopiterations_created_by_c_code 1970-01-01 01:00:00.0 +0100 +++ python-pygraphviz-1.4~rc1/debian/patches/catch_stopiterations_created_by_c_code 2018-11-22 19:30:55.0 +0100 @@ -0,0 +1,174 @@ +From b5df022700669ae496f65d20dd9cd387d6af948e Mon Sep 17 00:00:00 2001 +From: Dan Schult +Date: Thu, 2 Aug 2018 21:32:47 -0400 +Subject: [PATCH] catch StopIterations created by C code + +--- a/pygraphviz/agraph.py b/pygraphviz/agraph.py +@@ -374,8 +374,10 @@ class AGraph(object): + nh = gv.agfstnode(self.handle) + while nh is not None: + yield Node(self, nh=nh) +-nh = gv.agnxtnode(self.handle, nh) +-raise StopIteration ++try: ++nh = gv.agnxtnode(self.handle, nh) ++except StopIteration: ++return + + iternodes = nodes_iter + +@@ -597,8 +599,10 @@ class AGraph(object): + yield Node(self, t) + else: + yield Node(self, s) +-eh = gv.agnxtedge(self.handle, eh, nh) +-raise StopIteration ++try: ++eh = gv.agnxtedge(self.handle, eh, nh) ++except StopIteration: ++return + + def neighbors(self, n): + """Return a list of the nodes attached to n.""" +@@ -627,8 +631,14 @@ class AGraph(object): + yield (e[0], e[1], e.name) + else: + yield e +-eh = gv.agnxtout(self.handle, eh) +-nh = gv.agnxtnode(self.handle, nh) ++try: ++eh = gv.agnxtout(self.handle, eh) ++except StopIteration: ++break ++try: ++nh = gv.agnxtnode(self.handle, nh) ++except StopIteration: ++return + elif nbunch in self: # if nbunch is a single node + n = Node(self, nbunch) + nh = n.handle +@@ -639,7 +649,10 @@ class AGraph(object): + yield (e[0], e[1], e.name) + else: + yield e +-eh = gv.agnxtout(self
Bug#914282: O: multistrap -- multiple repository bootstrap based on apt
Package: wnpp Severity: normal I intend to orphan the multistrap package. The package description is: A debootstrap replacement with multiple repository support, using apt to handle all dependency issues and conflicts. . Multistrap includes support for native and foreign architecture bootstrap environments. Foreign bootstraps only need minimal configuration on the final device. Also supports cleaning up the generated bootstrap filesystem to remove downloaded packages and hooks to modify the files in the bootstrap filesystem after the packages have been unpacked but before being configured. . Unlike debootstrap, multistrap relies on working versions of dpkg and apt outside the final filesystem. If dpkg supports MultiArch, foreign architecture libraries can be installed, where available. I took over multistrap maintainership in 2016 because it provides many advantages over debootstrap because it uses apt as a backend. This in turn allows multiple repositories, resolution of complex dependencies and installing foreign architecture packages. Unfortunately I was never very happy with the codebase which led me to a big 1500-line-diff rewrite of the codebase: https://gitlab.mister-muffin.de/josch/multistrap/commit/ff96767b2f6a574e2651768225ad61557880e12f Followed by a 1842-line-diff commit which even more restructured the codebase: https://gitlab.mister-muffin.de/josch/multistrap/commit/cd5dfbbbf2435bae8fc34ac32ee7d716c24bada8 But I still wasn't happy and realized that to make myself happy, I would have to change behaviour of multistrap that would make its interface incompatible with earlier versions. In the end, I ended up with a complete rewrite and out came my package mmdebstrap: https://tracker.debian.org/pkg/mmdebstrap Similar to multistrap it uses apt at its core but in contrast to multistrap it doesn't offer a configuration file system. Unfortunately I'm very happy with mmdebstrap and thus I now decided to not spend more time into multistrap. I did a last upload that fixes a FTBFS issue and its last outstanding RC bug but after that it's now orphaned.
Bug#914271: lintian: Rationale behind hyphen-in-upstream-part-of-debian-changelog-version
Package: lintian Version: 2.5.112 Severity: normal Hi, my package rss-bridge was just tagged with hyphen-in-upstream-part-of-debian-changelog-version. The description text reads: N: The upstream version in the debian changelog contains one ore more N: hyphens. While that is okay according to policy, some tools may croak. Why is this a lintian warning at all? Either we know tools that fail to properly parse Debian versions and in this case we should: - file bugs against the tools in question - list these tools in the lintian warning Or there are no tools which fail to properly parse Debian versions in which case this lintian tag is useless. Assuming it's the first case, could you please at least extend the warning message with a list of tools that do not implement proper Debian version parsing? I don't think it's useful to fix a problem by curing the symptoms instead of the cause. If packages now change their versioning style in response to this lintian tag, then lintian has successfully helped to hide a bug in other software projects. Thanks! cheers, josch
Bug#914264: O: pdf2htmlex -- Converts PDF to HTML while retaining most formatting
Package: wnpp Severity: normal I intend to orphan the pdf2htmlex package. The package description is: pdf2htmlEX converts PDF to HTML while retaining text, format and style as much as possible by making use of HTML5, JavaScript and modern CSS features. Even difficult content like PDFs with embedded fonts, multicolumn documents, scientific papers with complicated figures and mathematical formulas will mostly be represented correctly. Fallback mode generates HTML pages which do not require any JavaScript to view them correctly at the expense of a larger file size. Upstream has been looking for a new maintainer for nearly two years now: http://pdf2htmlex.blogspot.com/2016/12/looking-for-new-maintainer.html An upstream bug indicates that nobody new has been found: https://github.com/coolwanglu/pdf2htmlEX/issues/726 The last commit by upstream was Dec 11, 2016: https://github.com/coolwanglu/pdf2htmlEX/commits/master But the package suffers from two RC bugs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883525 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878598 Fixing these problems requires a deep understanding of the software which I do not have nor the time to acquire it. I'm thus orphaning the package in the hopes that somebody else picks up the pieces. Thanks! cheers, josch
Bug#914260: dgit-infrastructure: dgit clone fails with "Out of memory, malloc failed"
Package: dgit-infrastructure Severity: normal Hi, steps to reproduce: $ dgit clone botch canonical suite name for unstable is sid fetching existing git history remote: error: Out of memory, malloc failed (tried to allocate 62249792 bytes) remote: error: failed to read delta base object 0432987b4a858414dc8eeb10a7099faa00d01cd9 at offset 4044255 from ./objects/pack/pack-1e252a6e629ce6b62c73834d2b23ffd52a2b6e6c.pack remote: error: failed to read object 1c78662e27418ec296e513f5940075dd8f9a4fb8 at offset 33158599 from ./objects/pack/pack-1e252a6e629ce6b62c73834d2b23ffd52a2b6e6c.pack remote: warning: suboptimal pack - out of memory remote: fatal: packed object 0432987b4a858414dc8eeb10a7099faa00d01cd9 (stored in ./objects/pack/pack-1e252a6e629ce6b62c73834d2b23ffd52a2b6e6c.pack) is corrupt remote: aborting due to possible repository corruption on the remote side. fatal: protocol error: bad pack header dgit: failed command: git fetch -p -n -q https://git.dgit.debian.org/botch '+refs/tags/archive/debian/*:refs/dgit-fetch/debian/tags/archive/debian/*' '+refs/tags/debian/*:refs/dgit-fetch/debian/tags/debian/*' '+refs/dgit/sid:refs/dgit-fetch/debian/dgit/sid' dgit: error: subprocess failed with error exit status 128 Thanks! cheers, josch
Bug#913803: python3-pykdl: PyKDL fails to import
Package: python3-pykdl Version: 1.4.0-6 Severity: grave Justification: renders package unusable Steps to reproduce: $ python3 Python 3.6.6 (default, Jun 27 2018, 14:44:17) [GCC 8.1.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from PyKDL import * Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'sip' Probably just a missing dependency? -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-pykdl depends on: ii libc6 2.27-6 ii libgcc1 1:8.2.0-8 ii liborocos-kdl1.4 1.4.0-5 ii libpython3.6 3.6.6-1 ii libstdc++68.2.0-8 ii python3 3.6.6-1 python3-pykdl recommends no packages. python3-pykdl suggests no packages. -- no debconf information
