Bug#923400: initramfs-tools: failure inside chroot: W: Couldn't identify type of root file system for fsck hook

[Jonas Smedegaard]

Package: initramfs-tools
Version: 0.133
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Building a system image using multistrap,
including generating an initial ramdisk,
worked fine recently.

Now it fails with this error message:

  W: Couldn't identify type of root file system for fsck hook

It seems to me that git commit a8ed874 intended to extend the code
operating on "auto" mounted filesystems to cover all _except_ root disk,
but that the logic is flipped around so that now it _only_ extends that
to include root disk:

- -   case "$MNT_TYPE" in
- -   auto)
[...]
+   # Ignore filesystem type for /, as it is not available and
+   # therefore never used at boot time
+   if [ "${MNT_DIR}" = "/" ] || [ "${MNT_TYPE}" = "auto" ]; then


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlx2vqoACgkQLHwxRsGg
ASF8ohAAjuJLFgguQyXi0Xp+v2YhFWxqiZxnSBav7/f85S3UjaqUNU3DjXdFv/FJ
7SkzZShmdqGIkpjxGyajRBGbFZzDJkR2Xn7p1T+CcYHvOcUNPfcWzHumc120l9mW
f74frkEC6J/IZX3tFRRXsEZaZ9ZasA16mvoQyL6lXR6ys22gQa3fEVRpGS95jxm2
hH4OorJSLeaGNYiXUMDmav29Aom1We7sojs/fdkQXiSE7Q0nc9jeuOOsSXLkFgKI
EvK88J3YpjuzXGNtwYbVn1QyVAYSAqrDyLyTtjtFwUjQbQc3jy/rYW/DeoTQ8lD2
syKc7e2N0xz02Y3JOQWxMdA+SdlQqeiGkQI7AHL23D0MXLcVkCp9WfWfOAlulpKd
tNrf7+Bc+tSBz4uNy04xP5UzhLcOKOPy1Rxz2ItSd6vZF0BL/4fptMZBMlvqxWsX
f3soeauNDC9F0584K0Fkuhta8jI3KYAJkNOw1omBzjunf8TpnAEKIvr7IfEk9RJp
FnE7TF9fUurxxnZx8crBCzNqFRkwj0oCjno/0HMvNKYbucPaXCD/Oco7aU4/KnbP
YVj5i9V/sfS7f68N3q6tZF09Tcd0IKPkItm7i796GtQRcVwvLpa7CPPMz4WK33bE
P6lP1/ldcx2+THYbL1i4xGhA3S24g4Nn1DSqNZRaZA90cLtZGKU=
=0zMd
-END PGP SIGNATURE-

Bug#923290: ddpo: Please distinguish reproduible state between sid/testing

[Holger Levsen]

Hi Guillem,

thanks for this bug report and X-Debbugs-Cc:ing us!

On Mon, Feb 25, 2019 at 10:53:36PM +0100, Guillem Jover wrote:
> The reproducible build state is currently only provided for «testing»,
> because «sid» contains additional checks that are deemed would annoy
> maintainers.
 
the problem with the unreproducibility issues in unstable currently is
that they are mostly unactionable as the way forward for build path
issues is not yet clear. thus such warnings can and will be seen as annoying.

> I've been aware of this in the past, but was still caught off guard
> when checking my DDPO page and seeing that inetutils was still marked
> as non-reproducible, even though the tests for sid said it was. And
> thought there was some stale data going on.

basically currently we are only targetting testing/buster with our
efforts.

> I think it would be ideal if the reproducible states was shown
> explicitly for both testing and sid, even though for now the sid
> column would just print a sigil for N/A data (‘-’? with an alt text
> mentioning the suite), this would make the information immediately
> obvious. Also I think that in the future the reproducible people
> might want to expose the state for sid too, at which point the N/A
> marker can just be switched to provide the actual state.

I'm not sure N/A will be less confusing as we do have data for
unstable.. but maybe thats a way forward.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#920296: Installs /etc/systemd/system/dbus-org.freedesktop.timesync1.service identical to /lib/systemd/system/systemd-timesyncd.service

[Josh Triplett]

On Wed, Feb 27, 2019 at 01:34:54PM -0300, Felipe Sateler wrote:
> On Wed, Feb 27, 2019 at 12:48 PM Michael Biebl  wrote:
> 
> > On Wed, 23 Jan 2019 14:54:48 -0800 Josh Triplett 
> > wrote:
> > > On Wed, Jan 23, 2019 at 07:52:24PM -0300, Felipe Sateler wrote:
> > > > On Wed, Jan 23, 2019 at 4:15 PM Josh Triplett 
> > wrote:
> > > > > Package: systemd
> > > > > Severity: normal
> > > > >
> > > > > I installed using the Buster Alpha 4 installer, and for some reason I
> > > > > ended up with a file
> > > > > /etc/systemd/system/dbus-org.freedesktop.timesync1.service,
> > identical to
> > > > > /lib/systemd/system/systemd-timesyncd.service. dpkg -S shows it not
> > > > > owned by any package, and searching through maintainer scripts
> > pointed
> > > > > to systemd's postinst. systemd shouldn't install a service in /etc
> > > > > identical to the one already installed in /lib.
> > > > >
> > > >
> > > > All systemd does is enable the service. On my system that leaves a
> > symlink,
> > > > not a regular file.
> > > > Is  /etc/systemd/system/dbus-org.freedesktop.timesync1.service a
> > regular
> > > > file or a symlink?
> > >
> > > It was a regular file.
> >
> > I don't think it's systemctl/systemd which is responsible for creating
> > /etc/systemd/system/dbus-org.freedesktop.timesync1.service as regular file.
> > Maybe a file system issue or the result of the file being copied around.
> 
> 
> > Josh, can you reproduce the issue?
> >
> > What happens if you remove
> > /etc/systemd/system/dbus-org.freedesktop.timesync1.service and run
> > systemctl enable systemd-timesyncd.service (as we do in postinst)
> >
> 
> This is definitely not systemctl's doing:
> 
> % sudo systemctl disable systemd-timesyncd.service
> Removed /etc/systemd/system/dbus-org.freedesktop.timesync1.service.
> Removed /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service.
> % sudo systemctl enable systemd-timesyncd.service
> 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.
> 
> Unfortunately I don't think we have enough information to act on this issue.

Feel free to close this. I don't want to do a reinstallation from
scratch in a VM to attempt to reproduce this.

Bug#923223: XML::Parser::parsefile() uses 2-argument open

[Niko Tyni]

On Wed, Feb 27, 2019 at 05:16:03PM +0100, gregor herrmann wrote:

> 2) This fix would also suite the documentation of tv_imdb which says:
> 
> tv_imdb --imdbdir  [--help] [--quiet]
>[--with-keywords] [--with-plot]
>[--movies-only] [--actors NUMBER]
>[--stats] [--debug]
>[--output FILE] [FILE...]
> 
> (so: pass FILE as an argument, not: read from STDIN, as the testsuite
> does)

The convention in manual pages is that optional arguments are denoted with
brackets. My expections from just the above synopsis would be precisely
the old behaviour (which the test suite apparently relies on): FILE is
optional and STDIN is used if FILE is not supplied.

> So it seems that XML::Parser's parsefile was able to handle '-' with
> the 2-args-open() and fails to do so with the 3-args-open(). This is
> a regression at first glance; although the documentation for open()
> only mentions "<-" or "-" for STDIN in the (one-args- and)
> two-args-form. But yeah, this has the potential to break more code
> out there …

Not sure I follow but I agree with the last sentence at least :)
Clearly '-' needs special handling in XML::Parser if 2-arg open is
converted to 3-arg open.

(Sorry, no tuits for providing a better patch for XML::Parser.)
-- 
Niko Tyni   nt...@debian.org

Bug#920296: Installs /etc/systemd/system/dbus-org.freedesktop.timesync1.service identical to /lib/systemd/system/systemd-timesyncd.service

[Felipe Sateler]

On Wed, Feb 27, 2019 at 12:48 PM Michael Biebl  wrote:

> On Wed, 23 Jan 2019 14:54:48 -0800 Josh Triplett 
> wrote:
> > On Wed, Jan 23, 2019 at 07:52:24PM -0300, Felipe Sateler wrote:
> > > On Wed, Jan 23, 2019 at 4:15 PM Josh Triplett 
> wrote:
> > > > Package: systemd
> > > > Severity: normal
> > > >
> > > > I installed using the Buster Alpha 4 installer, and for some reason I
> > > > ended up with a file
> > > > /etc/systemd/system/dbus-org.freedesktop.timesync1.service,
> identical to
> > > > /lib/systemd/system/systemd-timesyncd.service. dpkg -S shows it not
> > > > owned by any package, and searching through maintainer scripts
> pointed
> > > > to systemd's postinst. systemd shouldn't install a service in /etc
> > > > identical to the one already installed in /lib.
> > > >
> > >
> > > All systemd does is enable the service. On my system that leaves a
> symlink,
> > > not a regular file.
> > > Is  /etc/systemd/system/dbus-org.freedesktop.timesync1.service a
> regular
> > > file or a symlink?
> >
> > It was a regular file.
>
> I don't think it's systemctl/systemd which is responsible for creating
> /etc/systemd/system/dbus-org.freedesktop.timesync1.service as regular file.
> Maybe a file system issue or the result of the file being copied around.


> Josh, can you reproduce the issue?
>
> What happens if you remove
> /etc/systemd/system/dbus-org.freedesktop.timesync1.service and run
> systemctl enable systemd-timesyncd.service (as we do in postinst)
>

This is definitely not systemctl's doing:

% sudo systemctl disable systemd-timesyncd.service
Removed /etc/systemd/system/dbus-org.freedesktop.timesync1.service.
Removed /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service.
% sudo systemctl enable systemd-timesyncd.service
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.

Unfortunately I don't think we have enough information to act on this issue.

-- 

Saludos,
Felipe Sateler

Bug#922815: insserv FATAL while updating as mountkernfs has to be enabled to use service udev

[Ben Hutchings]

On Wed, 2019-02-27 at 03:01 +, Dmitry Bogatov wrote:
> [2019-02-25 05:45] shirish शिरीष 
> > On 24/02/2019, Dmitry Bogatov  wrote:
> > 
> > 
> > 
> > > Interesting, you seems somehow got mountkernfs.sh script removed from
> > > runlevel S.
> > > 
> > > Can you please invoke as root
> > > 
> > >   # update-rc.d mountkernfs.sh enable S
> > > 
> > > and then retry your upgrade.
> > 
> > When I try the command you shared, it says -
> > 
> > root@debian:~# update-rc.d mountkernfs.sh enable S
> > update-rc.d: error: cannot find a LSB script for mountkernfs.sh
> 
> Seems there is no /etc/init.d/mountkernfs.sh on your system.
> 
> Since your init system is systemd, I question, why do you need insserv
> in first place. Do you have bin:initscripts installed?
> 
> My guess is that update-initramfs invokes insserv /if/ it is available,
> and since you have insserv installed, but no initscripts, we get this
> bug.

It does not.

Ben.

> Adding initramfs-tools maintainer into loop. If my guess is correct,
> this issue should be resolved on initramfs side, since making insserv
> depending on initscripts is not nice to user.
-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
   - Bill Gates




signature.asc
Description: This is a digitally signed message part

Bug#870428: libverto1: Upstream has moved

[Sam Hartman]

> "Robbie" == Robbie Harwood  writes:

Robbie> Sam Hartman  writes:
>> I apologize for dropping the ball on this so long.  It looks like
>> there is a 0.3.0 release of verto, which was folded into krb5.
>> However, It looks like there's not an upstream tarball on github
>> for anything past 0.2.6.

Robbie> I'm confused by this comment.

I was totally confused myself and was just wrong.
I sent you a note to that effect, but I think it only went to your CMU
address.

Bug#923244: [Pkg-utopia-maintainers] Bug#923244: Bug#923244: policykit-1: Please support elogind backend

[Michael Biebl]

Hi

Am 27.02.19 um 18:12 schrieb Mark Hindley:
> Micael,
> 
> Thanks. This is very helpful.
> 
> On Wed, Feb 27, 2019 at 02:00:16PM +0100, Michael Biebl wrote:
>> I think, only 3) has a chance to work in Debian (or a slight
>> modification of it).
> 
> Would you specify your slight modification?

What I tried to say is, that I think we should drop libelogind0
completely in Debian. Clients that use libsystemd0 to call sd-login
related functionality should continue to work when elogind is active
without needing recompilation.

Making libelogind0 provide libsystemd0 (e.g. via diversions) is not
going to work (at least not without huge headaches).

So I think the only way forward is to make sure the combination
libsystemd0 + elogind as backend works when it comes to sd-login related
functionality.


Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#923340: RFS: dwarves-dfsg/1.12-2 (RC)

[Domenico Andreoli]

On Wed, Feb 27, 2019 at 02:10:06PM +0100, Adam Borowski wrote:
> On Wed, Feb 27, 2019 at 09:33:43AM +0100, Domenico Andreoli wrote:
> > On Tue, Feb 26, 2019 at 08:15:59PM +0100, Adam Borowski wrote:
> > > On Tue, Feb 26, 2019 at 06:06:18PM +0100, Domenico Andreoli wrote:
> > > > * Package name: dwarves-dfsg
> > > >   Version : 1.12-2
> 
> > > >   * Update copyright to copyright-format/1.0. Closes: #919356.
> 
> > > The new copyright file contains references to GPL-2.0-only and
> > > GPL-2.0-or-later without defining them.
> > 
> > According to https://spdx.org/licenses/ they are defined and supersede
> > GPL-2 and GPL-2+ now deprecated (maybe I should file a bug). OTOH I'm
> > reading that as long as copyright-format is not updated, new ones should
> > not be used.
> 
> SPDX has nothing to the copyright-format.  The latter doesn't care about
> short names at all, merely that 1. every file has a license, and 2. every
> license is defined.
> 
> Thus, "GPL-2", "GPL-2+", "GPL-2.0-only", "GPL-2.0-or-later", "Meow-meow"
> and "Cthulhu-fhtagn" have exactly the same meaning: they're merely
> identifiers that need to be defined elsewhere in the file.  Obviously,
> for human readers we still want GPL to mean GPL -- but it's a syntax vs
> content distinction.

Got it, in my mind the two things were related. There is even a paragraph
that says 

 "For SPDX compatibility, versions with trailing dot-zeroes are
  considered to be equivalent to versions without (e.g., “2.0.0”
  is considered equal to “2.0” and “2”)."

but I cannot ignore the one saying:

 "Use of a standard short name does not override the Debian Policy
  requirement to include the full license text in debian/copyright, nor
  any requirements in the license of the work regarding reproduction of
  legal notices. This information must still be included in the License
  field, either in a stand-alone License paragraph or in the relevant
  files paragraph."

> > I spent quite some time in trying to understand what lintian tries
> > to tell me here. I verified that reshuffling the file does not help
> > either, these errors stay in a similar location, as if lintian had some
> > bug somewhere.
> 
> "references a license, for which no standalone license paragraph exists"

I evidently read too little and assumed too much.

> > I'm uploaded a new version with GPL-2/GPL-2+, should be available shortly.
> 
> I don't see it on mentors yet...

I rewrote history and pushed a new 1.12-2 release to mentors.

Thanks again for the feedback.

Regards,
Domenico

-- 
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13


signature.asc
Description: PGP signature

Bug#923404: Patch

[Francois Marier]

The attached patch seems to fix the problem for me.

Francois

-- 
https://fmarier.org/
diff -u /usr/bin/ssl-cert-check ssl-cert-check 
--- /usr/bin/ssl-cert-check	2019-02-26 21:24:00.0 -0800
+++ ssl-cert-check	2019-02-27 10:04:34.331729364 -0800
@@ -658,9 +658,9 @@
 fi
 
 if [ "${TLSSERVERNAME}" = "FALSE" ]; then
-	TLSFLAG=(s_client -crlf -connect "${1}":"${2}" "${VERSION}")
+	TLSFLAG=(s_client -crlf -connect "${1}":"${2}")
 else
-TLSFLAG=(s_client -crlf -connect "${1}":"${2}" -servername "${1}" "${VERSION}")
+TLSFLAG=(s_client -crlf -connect "${1}":"${2}" -servername "${1}")
 fi
 
 echo "" | "${OPENSSL}" "${TLSFLAG[@]}" 2> "${ERROR_TMP}" 1> "${CERT_TMP}"

Bug#743138: [Pkg-utopia-maintainers] Bug#743138: Bug#743138: Bug#743138: [Needs upstream 0.9.10 release] Please only enable ifupdown plugin when ifupdown installed

[Guus Sliepen]

On Wed, Feb 27, 2019 at 10:51:35AM +0100, Michael Biebl wrote:

> > Even better, the plugin could
> > just call system("/sbin/ifquery ") to check whether an
> > interface is managed by ifupdown or not.
> 
> If the idea is to load and run less code in NM, this would mean we have
> to add more. So at a first glance this doesn't look very compelling.
> 
> Also, if we wanted to find devices which should not be touched by NM
> because they are defined in /e/n/i, is ifquery really sufficient to do that?

Yes.

> Say I have a br0 and eth0 in bridge_ports.
> What will ifquery eth0 return in such a case?

If will return an error, because as far as ifupdown itself is concerned,
no interface named eth0 has been defined. Ifupdown doesn't parse
bridge_ports, this is instead handled by /etc/network/if-pre-up.d/bridge
that's in the bridge-utils package. This is unfortunate, it is possible
to make it more visible to ifupdown: for example, when bonding
interfaces (which is similar to briding in the sense that you have a
bond interface and some other interfaces connected to it), the ifenslave
package provides an if-pre-up.d script that allows you to define a bond
interface, and instead of using bond_slaves (the equivalent of
bridge_ports), you can instead give slave interfaces their own iface
definition in /e/n/i and add something like "bond_master bond0" to it.

> Personally, I've never been a fan of the ifupdown plugin in NM. Parsing
> the /e/n/i file is hairy and incomplete.

It basically comes down to the fact that part of the parsing is done by
the plugins, and that there's no way just by looking at /e/n/i to
perfectly know which interfaces are controlled by ifupdown and which are
not.

> Especially the managed=true mode is something I would like to get rid off.
> If we removed managed=true mode, all that would remain from the ifupdown
> plugin is to mark devices as unmanaged by NM if they are defined in
> /e/n/i. In such a case we might consider replacing the handwritten
> parser and just exec ifquery.
> Maybe this could even be replaced by a udev rule which runs ifquery and
> sets ENV{NM_UNMANAGED}='1'

Or maybe set ENV{MANAGER}='ifupdown', to support other ways of managing
networks as well (ifupdown2, wicd, and probably more)? I like this
approach of signalling through udev though, it completely decouples
ifupdown from NetworkManager.

I just did some testing, and just using ifquery as it is now will not be
enough. The reason is that ifquery expects the name of a logical
interface (ie, the name of an iface stanza), and not that of a physical
interface. You can write something like:

allow-hotplug /eth*=eth
iface eth inet dhcp

This will bring up any interface whose name starts with eth (so eth0,
eth1, etc), and use the configuration of the iface eth stanza to
configure them. In this case, "ifquery eth0" would always return an
error, only "ifquery eth" would return zero. OTOH, if eth0 is up, then
"ifquery --state eth0" would return 0, but "ifquery --state eth" would
return an error.

Not confusing enough? The above can still be solved by adding an option
to ifquery to make it query a physical interface. But: you can also
define VLAN interfaces but omit the VLAN trunk interface. Is the
physical (trunk) interface then managed by ifupdown or not?

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#911408: dnsmasq breaks systemd autopkgtest

[Martin Pitt]

Hello all,

Paul Gevers [2018-10-19 21:07 +0200]:
> With a recent upload of dnsmasq the autopkgtest of systemd fails in
> testing when that autopkgtest is run with the binary packages of dnsmasq
> from unstable.

I fixed (or rather, worked around) this recently in
https://github.com/systemd/systemd/pull/11784

I spent several hours trying to configure dnsmasq 2.80 to be an authoritative
zone server with various combinations of --address, --auth-server, --auth-zone,
--local-service, and others, and then gave up. It's not that important, we can
live with the little hack in the networkd test. That worked [1].
(Note, now they fail again, but on a different reason, I'm investigating that in
[2]).

Not sure if this is an actual regression in dnsmasq, I leave it for the package
maintainer to decide whether to close this.

Thanks,

Martin

[1] 
https://ci.debian.net/data/autopkgtest/unstable/amd64/s/systemd/1978562/log.gz
[2] https://github.com/systemd/systemd/pull/11814


signature.asc
Description: PGP signature

Bug#923244: [Pkg-utopia-maintainers] Bug#923244: policykit-1: Please support elogind backend

[Mark Hindley]

Micael,

Thanks. This is very helpful.

On Wed, Feb 27, 2019 at 02:00:16PM +0100, Michael Biebl wrote:
> I think, only 3) has a chance to work in Debian (or a slight
> modification of it).

Would you specify your slight modification?

We are currently liasing with elogind upstream who are making libelogind ABI
compatible with libsystemd. See https://github.com/elogind/elogind/issues/97

Thanks very much.

Mark

Bug#923400: initramfs-tools: failure inside chroot: W: Couldn't identify type of root file system for fsck hook

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2019-02-27 17:45:33)
> Building a system image using multistrap,
> including generating an initial ramdisk,
> worked fine recently.
> 
> Now it fails with this error message:
> 
>   W: Couldn't identify type of root file system for fsck hook
> 
> It seems to me that git commit a8ed874 intended to extend the code
> operating on "auto" mounted filesystems to cover all _except_ root disk,
> but that the logic is flipped around so that now it _only_ extends that
> to include root disk:

Please ignore my guess above: I think I understand now that it was 
intentional to check root disk (I got confused by the comment talking 
about ignoring root and then processing root not skipping it).

Let me clarify my use case: I generate a system image on a fast amd64 
system targeted a slower real device (that's the reason having initramfs 
generated is important).

fstab now unconditionally being distrusted for root disk makes it more 
difficult to build on a different host than intended for target boot.

Would it perhaps make sense to support passing pre-resolved root 
filesystem fstype as an environment variable, taking precedence over 
probing?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#667738: libhttp-daemon-perl: HTTP::Daemon::ClientConn is IPv4 only

[Fabian Grünbichler]

Hello perl maintainers :)

I opened up a MR on salsa[1] to include the patches from upstream's bug
tracker that enable IPv6 support by switching to IO::Socket::IP - it
would be great if somebody can take a look at them and upload the -2
package ;)

Kind Regards,
Fabian

1: 
https://salsa.debian.org/perl-team/modules/packages/libhttp-daemon-perl/merge_requests/1

Bug#923400: initramfs-tools: failure inside chroot: W: Couldn't identify type of root file system for fsck hook

[Ben Hutchings]

Control: severity -1 wishlist
Control: retitle -1 Add option to override filesystem type detection

On Wed, 2019-02-27 at 18:38 +0100, Jonas Smedegaard wrote:
> Quoting Jonas Smedegaard (2019-02-27 17:45:33)
> > Building a system image using multistrap,
> > including generating an initial ramdisk,
> > worked fine recently.
> >
> > Now it fails with this error message:
> > 
> >   W: Couldn't identify type of root file system for fsck hook
> > 
> > It seems to me that git commit a8ed874 intended to extend the code
> > operating on "auto" mounted filesystems to cover all _except_ root disk,
> > but that the logic is flipped around so that now it _only_ extends that
> > to include root disk:

This commit went into version 0.123, before stretch, so if your use
case "worked fine recently" then this is not the change that broke it.

> Please ignore my guess above: I think I understand now that it was 
> intentional to check root disk (I got confused by the comment talking 
> about ignoring root and then processing root not skipping it).
> 
> Let me clarify my use case: I generate a system image on a fast amd64 
> system targeted a slower real device (that's the reason having initramfs 
> generated is important).
> 
> fstab now unconditionally being distrusted for root disk makes it more 
> difficult to build on a different host than intended for target boot.
>
> Would it perhaps make sense to support passing pre-resolved root 
> filesystem fstype as an environment variable, taking precedence over 
> probing?

I don't think this should be an environment variable but it does seem
like a useful option.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
   - Bill Gates




signature.asc
Description: This is a digitally signed message part

Bug#922300: unblock: chef/13.8.7-3, ohai/13.8.0-1

[Stefano Rivera]

Hi Release Team:
> unblock chef/13.8.7-3
> unstable ohai/13.8.0-1
> OR
> remove ruby-cheffish/13.1.0-2

I have a couple of packages that are part of the part of the chef stack
and some were pulled out with it, through no fault of their own.


So, I'd add to that, a

unblock foodcritic/13.1.1-2
unblock ruby-knife-acl/1.0.3-2

Neither of those are critical to the maintenance of ci.debian.org, but
they are of use to people managing Cheffed infrastructure, and don't
have particularly high popcon or bug numbers.

OR

If we don't unblock the chef stack, can we also:

remove chef-zero/13.1.0-2

It seems silly to keep it in the release, without chef.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#923374: root mode doesn't work anymore?

[Daniel Baumann]

On 2/27/19 9:44 AM, Jonas Smedegaard wrote:
> perhaps this is not specific to mmdebstrap but is tied to 
> apt or dpkg, especially the latter seeing major changes recently.

Interestingly, using --mode=fakechroot works for sid whereas --mode=root
fails (buster fails with fakechroot because of #915559).

Regards,
Daniel

Bug#923411: RFS: scdoc/1.9.0-1

[Birger Schacht]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "scdoc"

* Package name : scdoc
  Version  : 1.9.0-1
  Upstream Author  : Drew DeVault 
* Url  : https://git.sr.ht/~sircmpwn/scdoc
* Licenses : MIT
  Programming Lang : C
  Section  : text

 scdoc is a tool designed to make the process of writing man pages more
 friendly. It reads scdoc syntax from stdin and writes roff to stdout,
suitable
 for reading with man(1).

It builds those binary packages:

  * scdoc

To access further information about this package, visit the following URL:

https://mentors.debian.net/package/scdoc

Alternatively, one can download the package with dget using this command:
dget -x
https://mentors.debian.net/debian/pool/main/s/scdoc/scdoc_1.9.0-1.dsc

Alternatively, you can access package debian/ directory via git from URL:
https://salsa.debian.org/bisco-guest/scdoc.git

More information about scdoc can be obtained from
https://git.sr.ht/~sircmpwn/scdoc


Changes since last upload:

  * New upstream release
  * Refreshed patch
  * d/rules: Pass PCDIR to the install target
  * d/control: Drop Multiarch hint

Regards,
  Birger Schacht

Bug#923412: freecad: After update to 0.18~pre1+dfsg1-4 freecd crashes after start

[Rolf Wuerdemann]

Package: freecad
Version: 0.18~pre1+dfsg1-4
Severity: normal

Dear Maintainer,

after updating freecad (and subpackages) from 0.17 to 0.18~pre1,
freecad stalls after start with the message
"
  Wizard shaft module cannot be loaded
  No module named PartDesignGui
  Traceback (most recent call last):
  File "", line 50, in Initialize
"

the screen of freecad stays gray (no help/starter page, etc), one
can change the preferences, but not too much else. Deleting
local file including config does not help.



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages freecad depends on:
ii  freecad-python2  0.18~pre1+dfsg1-4

Versions of packages freecad recommends:
ii  calculix-ccx  2.11-1+b3
ii  graphviz  2.40.1-5+b2

Versions of packages freecad suggests:
pn  freecad-doc 
ii  povray  1:3.7.0.8-1
pn  python-collada  

-- no debconf information

Bug#923064: [INTL:da] Danish translation of the debconf templates wireshark

[Balint Reczey]

No problem, thanks for updating the translation!

On Wed, Feb 27, 2019 at 6:48 PM Joe Dalton  wrote:
>
> of course sorry about that
>
>
> 
> Den tirs 26/2/19 skrev Balint Reczey :
>
>  Emne: Re: Bug#923064: [INTL:da] Danish translation of the debconf templates 
> wireshark
>  Til: "Joe Dalton" , 923...@bugs.debian.org
>  Dato: tirsdag 26. februar 2019 17.43
>
>  Control: tags -1 moreinfo
>
>  Hi Joe,
>
>  On
>  Sat, Feb 23, 2019 at 8:00 PM Joe Dalton 
>  wrote:
>  >
>  > Package:
>  wireshark
>  > Severity: wishlist
>  > Tags: l10n patch
>  >
>  > Please include the attached Danish
>  wireshark debconf po file.
>  >
>  > joe@debianbuster:~/over/debian/wireshark$
>  msgfmt --statistics -c -v -o /dev/null da.po
>  > da.po: 16 oversatte tekster.
>
>  This looks like the po file
>  for apt-listchanges. Could you please
>  attach
>  the one for wireshark?
>
>  Cheers,
>  Balint
>
>
>  --
>  Balint Reczey
>  Ubuntu &
>  Debian Developer



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#923249: [Pkg-libvirt-maintainers] Bug#923249: libvirt0: libvirt sets disable_ipv6 on bridge, entirely breaking internal IPv6 networking

[Ralf Jung]

Btw, I reported this upstream at
, and made some headway
debugging things there.

; Ralf

Bug#920763: lintian: orig-tarball-missing-upstream-signature interacts poorly with mode=git,pgpmode=gittag

[Felix Lechner]

Hi Daniel,

On Wed, Feb 27, 2019 at 12:03 PM Daniel Kahn Gillmor
 wrote:
>
> I guess if we wanted some version of lintian to be able to check on the
> git tag, we need to have some sort of export (git shallow
> something-or-other?) that could be included in debian/ to recreate a git
> repo that would be sufficient to verify the contents of the files and
> confirm the git signature.

I wrote a Debian tool to create a shipping manifest with file-based
hashes. Would it help to include that at the time of packaging? If the
manifest is signed, we could do away with tarball signatures.

Felix

Bug#923416: advancecomp: CVE-2019-9210

[Salvatore Bonaccorso]

Source: advancecomp
Version: 2.1-1
Severity: important
Tags: security upstream
Forwarded: https://sourceforge.net/p/advancemame/bugs/277/

Hi,

The following vulnerability was published for advancecomp.

CVE-2019-9210[0]:
| In AdvanceCOMP 2.1, png_compress in pngex.cc in advpng has an integer
| overflow upon encountering an invalid PNG size, which results in an
| attempted memcpy to write into a buffer that is too small. (There is
| also a heap-based buffer over-read.)

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-9210
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9210
[1] https://sourceforge.net/p/advancemame/bugs/277/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#865141: more info

[Josip Rodin]

Not only does it not work, it errors out with:

% sudo update-grub
/usr/sbin/grub-probe: error: failed to get canonical path of 
`/dev/mapper/oldvgname-lvroot'.

Which is to say:

% sudo sh -ex /usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg
+ set -e
+ prefix=/usr
+ exec_prefix=/usr
+ datarootdir=/usr/share
+ prefix=/usr
+ exec_prefix=/usr
+ sbindir=/usr/sbin
+ bindir=/usr/bin
+ sysconfdir=/etc
+ PACKAGE_NAME=GRUB
+ PACKAGE_VERSION=2.02~beta3-5+deb9u1
+ host_os=linux-gnu
+ datadir=/usr/share
+ [ x = x ]
+ pkgdatadir=/usr/share/grub
+ export pkgdatadir
+ grub_cfg=
+ grub_mkconfig_dir=/etc/grub.d
+ basename /usr/sbin/grub-mkconfig
+ self=grub-mkconfig
+ grub_probe=/usr/sbin/grub-probe
+ grub_file=/usr/bin/grub-file
+ grub_editenv=/usr/bin/grub-editenv
+ grub_script_check=/usr/bin/grub-script-check
+ export TEXTDOMAIN=grub
+ export TEXTDOMAINDIR=/usr/share/locale
+ . /usr/share/grub/grub-mkconfig_lib
+ prefix=/usr
+ exec_prefix=/usr
+ datarootdir=/usr/share
+ datadir=/usr/share
+ bindir=/usr/bin
+ sbindir=/usr/sbin
+ [ x/usr/share/grub = x ]
+ test x/usr/sbin/grub-probe = x
+ test x/usr/bin/grub-file = x
+ test x = x
+ grub_mkrelpath=/usr/bin/grub-mkrelpath
+ which gettext
+ :
+ grub_tab=
+ test 2 -gt 0
+ option=-o
+ shift
+ argument -o /boot/grub/grub.cfg
+ opt=-o
+ shift
+ test 1 -eq 0
+ echo /boot/grub/grub.cfg
+ grub_cfg=/boot/grub/grub.cfg
+ shift
+ test 0 -gt 0
+ fgrep -qs ${GRUB_PREFIX}/video.lst /etc/grub.d/00_header
+ [ x = x ]
+ id -u
+ EUID=0
+ [ 0 != 0 ]
+ set /usr/sbin/grub-probe dummy
+ test -f /usr/sbin/grub-probe
+ :
+ /usr/sbin/grub-probe --target=device /
/usr/sbin/grub-probe: error: failed to get canonical path of 
`/dev/mapper/oldvgname-lvroot'.
+ GRUB_DEVICE=

Which is to say:

% sudo strace grub-probe --target=device / 2>&1 | grep -E 
'(mapper|vg|lv|dev|mount)'
execve("/usr/sbin/grub-probe", ["grub-probe", "--target=device", "/"], [/* 17 
vars */]) = 0
open("/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libudev.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "nodev\tsysfs\nnodev\trootfs\nnodev\tr"..., 1024) = 311
open("/boot/grub/device.map", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/proc/self/mountinfo", O_RDONLY)  = 3
read(3, "kio rw,nosuid,nodev,noexec,relat"..., 1024) = 717
lstat("/dev", {st_mode=S_IFDIR|0755, st_size=3440, ...}) = 0
lstat("/dev/mapper", {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
lstat("/dev/mapper/oldvgname-lvroot", 0x7ffc7a97ad80) = -1 ENOENT (No such file 
or directory)
write(2, "failed to get canonical path of "..., 63failed to get canonical path 
of `/dev/mapper/oldvgname-lvroot') = 63

So the problem is the info exposed by the running kernel:

% grep oldvgname "/proc/self/mountinfo"
21 0 253:0 / / rw,relatime shared:1 - ext4 /dev/mapper/oldvgname-lvroot 
rw,errors=remount-ro,data=ordered

Once upon a time, one could mess with /etc/mtab in these cases, but that
file is no longer used, it's a symlink into /proc/mounts.

Not sure if this should be reassigned elsewhere then... maybe lvm2 should
try harder to communicate volume group changes to the running kernel?
The device mapper seems to have done its job in updating /dev/mapper,
but it didn't seem to percolate into mountinfo.

btw xref 
https://askubuntu.com/questions/765058/how-do-you-rename-the-volume-group-that-contains-the-root-volume-in-lvm

-- 
 2. That which causes joy or happiness.

Bug#865141: more info

[Josip Rodin]

And in turn this makes subsequent kernel upgrades croak:

% sudo dpkg --configure -a
Setting up linux-image-4.9.0-8-amd64 (4.9.144-3.1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.9.0-8-amd64
/etc/kernel/postinst.d/zz-update-grub:
/usr/sbin/grub-probe: error: failed to get canonical path of 
`/dev/mapper/oldvgname-lvroot'.
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
dpkg: error processing package linux-image-4.9.0-8-amd64 (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 linux-image-4.9.0-8-amd64

-- 
 2. That which causes joy or happiness.

Bug#883939: Reproduce " smbclient failing to connect with default protocol SMB3_11"

[m.foul...@blueyonder.co.uk]

Hi Mathieu,

I'm using an up-to-date debian testing/buster installation with 
smbclient 2:4.9.4+dfsg-3.


Matthew


On Wed, Feb 27, 2019 at 10:51:23PM +0100, Mathieu Parent wrote:

  Le mercredi 27 février 2019, Matthew Foulkes 
  a écrit :
  > I now have a Debian laptop again and can confirm that bug 883939 still
  exists. Nothing has changed. As I have already explained, however, the
  problem I am experiencing seems to be specific to the (outdated?) ONTAP 9
  software running on the NetApp file server. It may not be worth attempting
  to fix it in Debian.

  What's your version of smbclient?

  --
  Mathieu


--
**
 email: m.foul...@blueyonder.co.uk
 phone: 07905 505676
**

Bug#923418: Introduces spurious whitespace after parentheses

[John MacFarlane]

This looks like

https://github.com/jgm/pandoc/issues/4635

which is fixed in recent versions nof pandoc.
2.2.2+

Martin Michlmayr  writes:

> Package: pandoc
> Version: 2.2.1-3+b2
>
> pandoc introduces a space after parentheses under certain
> circumstances:
>
> 65576:tbm@jirafa: ~] cat pandoc
>
> this is a test (e.g.
> why is there a space after the parenthesis?).
>
> 65577:tbm@jirafa: ~] cat pandoc | pandoc
> this is a test ( e.g. why is there a space after the parenthesis?).
>
> -- 
> Martin Michlmayr
> https://www.cyrius.com/

Bug#923414: poppler: CVE-2019-9200

[Salvatore Bonaccorso]

Source: poppler
Version: 0.71.0-2
Severity: important
Tags: security upstream
Forwarded: https://gitlab.freedesktop.org/poppler/poppler/issues/728

Hi,

The following vulnerability was published for poppler.

CVE-2019-9200[0]:
| A heap-based buffer underwrite exists in ImageStream::getLine() located
| at Stream.cc in Poppler 0.74.0 that can (for example) be triggered by
| sending a crafted PDF file to the pdfimages binary. It allows an
| attacker to cause Denial of Service (Segmentation fault) or possibly
| have unspecified other impact.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-9200
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9200
[1] https://gitlab.freedesktop.org/poppler/poppler/issues/728
[2] 
https://research.loginsoft.com/bugs/heap-based-buffer-underwrite-in-imagestreamgetline-poppler-0-74-0/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#923408: lxpanel: weather applet does not update at startup

[Andriy Grytsenko]

>Thanks for fixing the weather applet by using the OpenWeatherMap API.
>Here's another problem though:

>When I start my LXDE session the weather applet does not show the
>temperature etc., but rather says that weather information for my
>location is not available.

Thank you for your report. Actually I am aware of that but unfortunately
time before freeze is so tight that I could not risk to develop reliable
solution as it might take time to develop and test. It will be developed
later so I hope to get it backported to the buster-backports.

Bug#921294: No need to block buster

[Aaron M. Ucko]

Dominik George  writes:

> Correct, will be fixed today.

Fix confirmed, thanks!  I'll reupload with a tightened build dependency
this evening (US/Eastern).

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#890075: ruby-http ftbfs (test failures with 2.5)

[Emanuele Rocca]

On 10/02 09:47, Matthias Klose wrote:
> ruby-http ftbfs for 2.5, but not for 2.3 in unstable:

Note that the bug is not reproducible with ruby-http 3.3.0-2 as tests
have been disabled:

https://salsa.debian.org/ruby-team/ruby-http/commit/728a3fbcc7c59ebb14cb55aa9f084b910d666971
https://salsa.debian.org/ruby-team/ruby-http/commit/6ba2e142ef6952fc905ac2cac7e2eec536433ac3

Reverting the commits above makes ruby-http ftbfs in unstable.

Bug#788674: lxsession: LXDE not loading at login

[Andriy Grytsenko]

This seems to be similar to bug reported against at-spi2-core package
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918776 but with another
problem produced. I would like to hear if this problem is still present
or reproducible on your system. Let us know, please.

Bug#883939: Reproduce " smbclient failing to connect with default protocol SMB3_11"

[Mathieu Parent]

Le mercredi 27 février 2019, Matthew Foulkes  a
écrit :
> I now have a Debian laptop again and can confirm that bug 883939 still
exists. Nothing has changed. As I have already explained, however, the
problem I am experiencing seems to be specific to the (outdated?) ONTAP 9
software running on the NetApp file server. It may not be worth attempting
to fix it in Debian.


What's your version of smbclient?

-- 
Mathieu

Bug#922979: qemu-efi-aarch64: arm64 UEFI image is unpadded which may confuse new users

[dann frazier]

reassign 922979 src:qemu
thanks

On Fri, Feb 22, 2019 at 02:55:22PM +, Alex Bennée wrote:
> With an un-patched QEMU running with:
> 
>   -drive 
> if=pflash,file=/usr/share/qemu-efi-aarch64/QEMU_EFI.fd,format=raw,readonly
> 
> will fail cryptically as the image isn't padded to the device size. The
> qemu-efi-arm package is currently padded:
> 
> $ ls -lh /usr/share/qemu-efi-aarch64/QEMU_EFI.fd 
> /usr/share/AAVMF/AAVMF32_CODE.fd
> -rw-r--r-- 1 root root  64M Nov 26 23:34 /usr/share/AAVMF/AAVMF32_CODE.fd
> -rw-r--r-- 1 root root 2.0M Nov 26 23:34 
> /usr/share/qemu-efi-aarch64/QEMU_EFI.fd

qemu-efi-aarch64 also provides a padded image:

$ dpkg -L qemu-efi-aarch64 | grep AAVMF
/usr/share/AAVMF
/usr/share/AAVMF/AAVMF_CODE.fd
/usr/share/AAVMF/AAVMF_VARS.fd

The unpadded QEMU_EFI.fd is just provided for backwards compatibility.

> Whether fixing the packaging or using a patch like currently being
> discussed on qemu-devel:
> 
>   https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg05934.html

Since that's a QEMU patch, and I don't see anything that needs to be
done in edk2 (the source for qemu-efi-aarch64), I'm reassigning to the
qemu package.

  -dann

Bug#909401: mailutils: don't know what 2047 is

[Poon, Dara]

The example command in the GNU mailutils documentation 
(http://mailutils.org/manual/html_node/mailutils-2047.html) fails, printing 
"mailutils: don't know what 2047 is" as the error message.  Running it with 
strace shows the root cause:

stat("/usr/lib/mailutils/mailutils/mailutils-2047", 0x7ffd569d7770) = -1 ENOENT 
(No such file or directory)


The build process for mailutils-3.4 actually produces an executable file 
mu/libexec/.libs/mailutils-flt2047, but it is never packaged into any .deb.  If 
you build mailutils-3.4 using dpkg-buildpackage, then manually install that 
binary:

# mkdir -p /usr/lib/mailutils/mailutils
# cp ./mu/libexec/.libs/mailutils-flt2047 /usr/lib/mailutils/mailutils/


… then you would be able to run `mailutils flt2047`.  (Note that the command is 
named "flt2047", in contrast to the documentation, which calls it "2047".  
That's an upstream bug.)

Bug#923413: shim-signed: Receiving error message "Failed to set MokSBStateRT: (2) Invalid Parameter"

[Omer Oz]

Package: shim-signed
Version: 1.28+nmu1+0.9+1474479173.6c180c6-1
Severity: normal

Dear Maintainer,

I started receiving "Failed to set MokSBStateRT: (2) Invalid Parameter" error
message before boot screen after installing shim-signed package while upgrading
grub-efi-amd64-signed package.

This error message is displayed even if secure boot is disabled. I can continue
to grub screen after selecting [OK]. However, boot fails due to kernel
signature validation if secure boot is enabled. The system boots without any
issues if secure boot is disabled.

I have already enrolled Debian's cert and the test cert. They are listed in
the output of `moklist --list`.

A similar bug has been filed against Ubuntu as well [1]. It looks like a patch
addressing this issue has been merged to the upstream [2].

Info about my system:

# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 3.0.0 present.
Table at 0x000E.

Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendor: Dell Inc.
Version: 2.11.2
Release Date: 11/07/2018
Address: 0xF
Runtime Size: 64 kB
ROM Size: 16 MB
Characteristics:
PCI is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Function key-initiated network boot is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 2.11

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Dell Inc.
Product Name: Precision Tower 3620
Version: Not Specified
Serial Number: *redacted*
UUID: *redacted*
Wake-up Type: Power Switch
SKU Number: 06B7
Family: Precision

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: Dell Inc.
Product Name: 0MWYPT
Version: A02
Serial Number: *redacted*
Asset Tag: Not Specified
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: Not Specified
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0

--
Thanks,
Omer

[1] https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1644806
[2] https://github.com/rhboot/shim/commit/07bda58



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages shim-signed depends on:
ii  debconf [debconf-2.0]  1.5.70
ii  grub-efi-amd64-bin 2.02+dfsg1-11
ii  grub2-common   2.02+dfsg1-11
ii  mokutil0.2.0-1+b3
ii  shim   0.9+1474479173.6c180c6-1

Versions of packages shim-signed recommends:
pn  secureboot-db  

shim-signed suggests no packages.

-- debconf information:
  shim/title/secureboot:
  shim/secureboot_explanation:
  shim/error/bad_secureboot_key:
  shim/error/secureboot_key_mismatch:
  shim/enable_secureboot: false
  shim/disable_secureboot: true

Bug#923415: libpodofo: CVE-2018-20797

[Salvatore Bonaccorso]

Source: libpodofo
Version: 0.9.6+dfsg-4
Severity: important
Tags: security upstream
Forwarded: https://sourceforge.net/p/podofo/tickets/34/

Hi,

The following vulnerability was published for libpodofo.

CVE-2018-20797[0]:
| An issue was discovered in PoDoFo 0.9.6. There is an attempted
| excessive memory allocation in PoDoFo::podofo_calloc in
| base/PdfMemoryManagement.cpp when called from
| PoDoFo::PdfPredictorDecoder::PdfPredictorDecoder in
| base/PdfFiltersPrivate.cpp.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-20797
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20797
[1] https://sourceforge.net/p/podofo/tickets/34/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#923309: cacti-spine_1.1.37-2~bpo9+1 fails to run under non-root user

[Paul Gevers]

Hi Paul, Allan,

@Paul, Thanks for reporting this issue. Please check the existing
comments in bug 904332

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

@Sven can you please help us and maybe explain how Paul should be using
the cacti-spine binary with these Linux capabilities enabled that we
added in that version by your patch. I guess he needs to install
libcap2-bin and run $(chmod u-s /usr/sbin/spine)

Paul

On 26-02-2019 07:39, Paul Allen wrote:
> Package: cacti-spine
> Version: 1.1.37-1~bpo9+1
> Severity: normal
> 
> Dear Maintainer,
> 
> 
>* What led up to the situation?
> Upgrading from cacti-spine_1.1.37-1~bpo9+1 to 
> cacti-spine_1.1.37-2~bpo9+1 caused execution of cacti-spine for non-root 
> users to break, even with setuid bits set for either just user or all.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Attempted to set setuid bits on /usr/sbin/spine to permit execution 
> by non-root users (eg, cacti). Attempted to debug by running 
> "/usr/sbnin/spine -H=180 -R -S -V=5" and "/usr/sbin/spine -h" as both root 
> and cacti users.
>* What was the outcome of this action?
> /usr/sbin/spine would fail silently when executed by cacti user but 
> would run successfully when executed by root user. Example: 
> cacti@mon1:~# /usr/sbin/spine -H=180 -R -S -V=5
> cacti@mon1:~#
> cacti@mon1:~# /usr/sbin/spine -h
> cacti@mon1:~#
> 
>* What outcome did you expect instead?
> Expected spine to execute successfully for non-root cacti user once 
> setuid bit(s) were set.
> 
> Re-installing cacti-spine_1.1.37-2~bpo9+1 had no effect, Removing and 
> re-adding setuid bits had no effect. Once I rolled the package back to 
> cacti-spine_1.1.37-1~bpo9+1 and set the setuid bit for the user it started 
> executing successfully again for the no-root cacti user with no other changes 
> necessary.
> 
> 
> 
> -- System Information:
> Debian Release: 9.8
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.9.0-6-amd64 (SMP w/16 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages cacti-spine depends on:
> ii  cacti  1.1.38+ds1-1~bpo9+1
> ii  dbconfig-no-thanks 2.0.11~bpo9+1
> ii  debconf [debconf-2.0]  1.5.61
> ii  libc6  2.24-11+deb9u4
> ii  libmariadbclient18 10.1.37-0+deb9u1
> ii  libsnmp30  5.7.3+dfsg-1.7+deb9u1
> ii  ucf3.0036
> 
> cacti-spine recommends no packages.
> 
> Versions of packages cacti-spine suggests:
> ii  snmp-mibs-downloader  1.1+nmu1
> 
> -- no debconf information
> 

Bug#923412: freecad: After update to 0.18~pre1+dfsg1-4 freecd crashes after start

[Kurt Kremitzki]

Hello Rolf,

On 2/27/19 2:01 PM, Rolf Wuerdemann wrote:
> Package: freecad
> Version: 0.18~pre1+dfsg1-4
> Severity: normal
> 
> Dear Maintainer,
> 
> after updating freecad (and subpackages) from 0.17 to 0.18~pre1,
> freecad stalls after start with the message
> <-snip->

This seems similar to an issue reported in the FreeCAD forums [1]. If it
is the same issue, there seems to be a problem with the
update-alternatives scripts. As a temporary workaround, can you try
running `sudo update-alternatives --config freecad` and picking either
the -python2 or -python3 option? You may need to install freecad-python3
first before that command works, if you only have freecad-python2 installed.

[1] https://forum.freecadweb.org/viewtopic.php?f=4=34468

Bug#923412: freecad: After update to 0.18~pre1+dfsg1-4 freecd crashes after start

[Rolf Wuerdemann]

On 27.02.19 21:41, Kurt Kremitzki wrote:
> Hello Rolf,

Hello Kurt,
> 
> On 2/27/19 2:01 PM, Rolf Wuerdemann wrote:
>> Package: freecad
>> Version: 0.18~pre1+dfsg1-4
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> after updating freecad (and subpackages) from 0.17 to 0.18~pre1,
>> freecad stalls after start with the message
>> <-snip->
> 
> This seems similar to an issue reported in the FreeCAD forums [1]. If it
> is the same issue, there seems to be a problem with the
> update-alternatives scripts. As a temporary workaround, can you try
> running `sudo update-alternatives --config freecad` and picking either
> the -python2 or -python3 option? You may need to install freecad-python3
> first before that command works, if you only have freecad-python2 installed.
> 
> [1] https://forum.freecadweb.org/viewtopic.php?f=4=34468
> 

After running update-alternatives freecad works. Thanks for the quick
response!

JFI: Now freecad claims that '/usr/share/freecad/examples' isn't
found.

Best,

   Rolf

-- 
Security is an illusion - Datasecurity twice
Rolf Würdemann   -   ro...@digitalis.org   -   DL9ROW
GnuPG fingerprint:   EEDC BEA9 EFEA 54A9 E1A9  2D54 69CC 9F31 6C64 206A
xmpp: ro...@digitalis.org E1189573 6B4A150C A0C2BF5A 5553F865 0B9CBF7A
  ro...@jabber.ccc.de 64CBBB68 0A3514A4 026FC1E7 5328CE87 AEE2185F



signature.asc
Description: OpenPGP digital signature

Bug#923137: chrony: system call filter (now enabled by default) conflicts not only with mailonchange, but also with log

[Francesco Poli]

On Wed, 27 Feb 2019 14:05:03 +0100 Vincent Blut wrote:

[...]
> On Mon, Feb 25, 2019 at 10:07:28PM +0100, Francesco Poli wrote:
[...]
> >Nothing is added to /var/log/messages when chrony fails to start.
> 
> Ok so I think I can reproduce this issue on a Debian Buster i386 virtual 
> machine. However, to double check that I’m facing the same issue as 
> yours, I’d like you to:
> 
> - stop the chronyd daemon
> # service chrony stop
> 
> - install strace
> # apt install strace
> 
> - use the log directive in chrony.conf (“log measurements” alone 
>   suffices to trigger the issue)
> 
> - execute strace on chronyd
> # strace -o chronyd_debug.txt chronyd -d -F -1
> 
> - don’t forget to attach the chronyd_debug.txt file when you answer ;-)

  # strace -o /tmp/chronyd_debug.txt chronyd -d -F -1
  2019-02-27T21:11:34Z chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK 
+RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
  2019-02-27T21:11:34Z Frequency -63.045 +/- 0.023 ppm read from 
/var/lib/chrony/chrony.drift
  2019-02-27T21:11:34Z Loaded seccomp filter
  Bad system call

File chronyd_debug.txt is attached (gzipped).

[...]
> >So I tried to think about the differences between the box where it
> >fails, and the box where it works.
> >
> >The first difference is the architecture:
> > • the box where it fails is i386
> 
> Indeed, this is due to a missing syscall needed for this architecture 
> (and probably some other 32-bit plateforms) in the seccomp filter.

Ah, that's it (maybe).

> 
> > • the box where it works is amd64
> >However, I suspect that chrony level of abstraction is high enough to
> >make this difference immaterial... Or am I wrong?
> 
> See Above.

OK, so I was wrong!   ;-)

> 
> >The second difference is the init system and might be more relevant:
> > • the box where it fails runs with sysvinit as PID 1
> > • the box where it works runs with systemd as PID 1
> 
> I think it is safe to exclude PID 1 as the cause of this issue.

Funny that I was completely off-track in the search for the relevant
difference...   :p

> 
> Thanks for yout time,

Thanks to you, for your helpfulness and patience!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


chronyd_debug.txt.gz
Description: application/gzip


pgpVwiGGV5WSm.pgp
Description: PGP signature

Bug#677262: lxsession: system beeps (still?) not working under LXDE

[Andriy Grytsenko]

Could you, please, provide output of command 'xset q' on your system?

Bug#923419: openssh-client: ssh-agent returns incorrect signature type for RSA CERTs

[Eldon Koyle]

Package: openssh-client
Version: 1:7.9p1-7
Severity: normal
Tags: fixed-upstream

Dear Maintainer,

There is an issue with the ssh client/ssh-agent that causes RSA CERT
based authentication to fail on the initial attempt when using
ssh-agent.  The problem has been fixed upstream[1] and will be part of
the openssh 8.0 release.  There is also a patch[2] for openssh 7.9
mentioned in the ticket.  I'm hoping this fix can make it into buster.

[1] https://bugzilla.mindrot.org/show_bug.cgi?id=2944
[2] 
https://anongit.mindrot.org/openssh.git/commit/authfd.c?id=007a88b48c97d092ed2f501bbdcb70d9925277be

-- 
Eldon Koyle

Bug#923410: qemu: qemu-debootstrap missed to handle hppa arch

[Helge Deller]

Package: qemu
Version: 3.1+dfsg-4
Severity: normal
Tags: patch

While setting up a hppa debian buildd server, I noticed that the hppa
architecture is not handled in the qemu-debootstrap program. Since hppa
is missing in the list, I noticed another bug in qemu-debootstrap that
the error message is referring to a wrong variable and thus the arch is
not printed.

Can you please apply the trivial patch which is included below in the next 
upload?

Thanks,
Helge


diff -up ./debian/qemu-debootstrap.org ./debian/qemu-debootstrap
--- ./debian/qemu-debootstrap.org   2019-02-27 20:55:49.366838616 +0100
+++ ./debian/qemu-debootstrap   2019-02-27 20:56:44.318469290 +0100
@@ -134,7 +134,7 @@ fi
 
 qemu_arch=""
 case "$deb_arch" in
-  
alpha|arm|armeb|i386|m68k|mips|mipsel|mips64el|ppc64|riscv32|riscv64|sh4|sh4eb|sparc|sparc64|s390x)
+  
alpha|arm|armeb|hppa|i386|m68k|mips|mipsel|mips64el|ppc64|riscv32|riscv64|sh4|sh4eb|sparc|sparc64|s390x)
 qemu_arch="$deb_arch"
   ;;
   amd64)
@@ -156,7 +156,7 @@ case "$deb_arch" in
 qemu_arch="ppc64le"
   ;;
   *)
-die "Sorry, I don't know how to support arch %s" "$arch"
+die "Sorry, I don't know how to support arch %s" "$deb_arch"
   ;;
 esac
 

Bug#921889: debian-policy: recommends an old version of libjs-sphinxdoc

[Gabriele Stilli]

found -1 4.3.0.2

Hi,

unfortunately the bug showed again when the latest libjs-sphinxdoc
1.8.4-1 entered buster.

(debian-policy now Recommends: libjs-sphinxdoc (< 1.8.3.0~))

Not sure we want to undergo all this at every sphinx version bump :-)

Regards
Gabriele Stilli

Bug#805727: lxde: desktop fails to load

[Andriy Grytsenko]

control: tags -1 + moreinfo

Could you, please, clarify if this old issue ever happens again or not?
Thank you very much.

Bug#920763: lintian: orig-tarball-missing-upstream-signature interacts poorly with mode=git,pgpmode=gittag

[Daniel Kahn Gillmor]

On Tue 2019-02-26 16:36:05 -0500, Chris Lamb wrote:
> I'm afraid it would, and would not be visible on lintian.d.o, and
> would also give different results in different environments. Whilst
> there is no strict written policy about this anywhere, this just
> feels "kinda" wrong, alas.

gotcha, thanks for the explanation and scope of what is in-bounds for
lintian.

I guess if we wanted some version of lintian to be able to check on the
git tag, we need to have some sort of export (git shallow
something-or-other?) that could be included in debian/ to recreate a git
repo that would be sufficient to verify the contents of the files and
confirm the git signature.  I don't know how to do that yet though :/

--dkg

Bug#742182: [Pkg-samba-maint] Bug#742182: samba-tool gpo aclcheck always fails with uncaught exception error

[Mathieu Parent]

Control: reopen -1
Control: found -1 2:4.8.2+dfsg-1
Control: found -1 2:4.9.4+dfsg-1

Le mer. 27 févr. 2019 à 14:45, L. van Belle  a écrit :
>
> Please reopen, not fixed in 4.8.9 and 4.9.4.

Done, but but you can do this yourself.

See https://www.debian.org/Bugs/server-control

Regards
-- 
Mathieu Parent

Bug#922004: transition: clamav

[Niels Thykier]

Control: tags -1 confirmed pending

Scott Kitterman:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Even though we are after the transition deadline, we would like to have
> permission to go ahead with the clamav transition.  Typically we keep clamav
> updated in stable for effectiveness reasons and we plan to do the same now.
> In order to do that, we need to do sid/buster first.
> 
> Status of preparations:
> 
> clamav 0.101.1+dfsg-2 is in experimental and has built on all release archs
> for which it has been tried (it's been waiting a week for mips64el/mipsel).
> 
> It's ready for unstable/buster.
> 
> rdepends:
> 
> dansguardian (still and issue for stable, but removed from unstable/buster),
> maintianed fork e2guardian uses clamd, not libclamav, so not an issue.
> 
> libclamunrar: Update split from clamav source and uploaded to experimental.
> 
> python-clamav: Source changes needed.  Patched version uploaded to
> experimental.
> 
> havp: Source changes needed.  New upstream release with fixes uploaded to
> experimental (upstream only incorporates Debian patches and this change).
> 
> c-icap-modules: binNMU only - tested rebuild locally.
> 
> pg-snakeoil: binNMU only - tested rebuild locally.
> 
> 
> Ben file (note: this is what reportbug generated, the auto one is fine):
> 
> title = "clamav";
> is_affected = .depends ~ "libclamav7" | .depends ~ "libclamav9";
> is_good = .depends ~ "libclamav9";
> is_bad = .depends ~ "libclamav7";
> 
> Note that for the packages that need sourceful uploads, I am an uploader, so
> no external maintainer coordination is required.
> 
> Scott K
> 

Please go ahead. :)

Thanks,
~Niels

Bug#923309: cacti-spine_1.1.37-2~bpo9+1 fails to run under non-root user

[Sven Hartge]

On 27.02.19 21:35, Paul Gevers wrote:

> @Paul, Thanks for reporting this issue. Please check the existing
> comments in bug 904332
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904332
> 
> @Sven can you please help us and maybe explain how Paul should be using
> the cacti-spine binary with these Linux capabilities enabled that we
> added in that version by your patch. I guess he needs to install
> libcap2-bin and run $(chmod u-s /usr/sbin/spine)

Yes, but one additional step:

You also need to set the capabilities:

   setcap cap_net_raw+ep /usr/sbin/spine

After that, everything should be back in working order.

If not, then the bug is at a different place. Also the missing setuid
bit and the missing capabilities only prevent the use of the
ICMP-Checker for Host Liveliness Checking, but not the failure to run at
all.

Without those two bits in place, SNMP gathering will still work.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#923356: unblock: prelude-lml/4.1.0-1+b2

[Niels Thykier]

Mattia Rizzolo:
> On Tue, Feb 26, 2019 at 04:24:00PM -0500, Thomas Andrejak wrote:
>> unblock prelude-lml/4.1.0-1+b2
> 
> make this
> 
> unblock prelude-lml/4.1.0-2
> 

Hi,

I have unblocked prelude-lml/4.1.0-2 on the basis that the diff between
-1 and -2 would have been acceptable if it had still been in testing.
Note that this unblock only applies to prelude-lml/4.1.0-2 as it is
currently; if that version cannot migrate to testing then prelude-lml
will not be a part of buster.

Mind you, prelude-lml will not migrate as long as #919869 remains open
AFAICT, it is "just" a question of the bug not being properly closed in
the upload of 4.1.0-2 and that you will have to do that manually.

Thanks,
~Niels

Bug#923346: updates

[Paul Thomas]

OK, a couple of updates.

First, I tracked down line ptp4l call that starts this off, it's the
ioctl(fd, SIOCSHWTSTAMP, ); line 88 in sk.c. I can see if a
standalone program that just does that ioctl has the same affect.

Second, I was able to reproduce this using the mainline 5.0-rc8 kernel.

-Paul

Bug#923417: pspp: CVE-2019-9211

[Salvatore Bonaccorso]

Source: pspp
Version: 1.2.0-2
Severity: normal
Tags: security upstream

Hi,

The following vulnerability was published for pspp.

CVE-2019-9211[0]:
| There is a reachable assertion abort in the function
| write_long_string_missing_values() in data/sys-file-writer.c in
| libdata.a in GNU PSPP 1.2.0 that will lead to denial of service.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-9211
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9211
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1683499

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#883939: Reproduce " smbclient failing to connect with default protocol SMB3_11"

[Matthew Foulkes]

I now have a Debian laptop again and can confirm that bug 883939 still 
exists. Nothing has changed. As I have already explained, however, the 
problem I am experiencing seems to be specific to the (outdated?) ONTAP 
9 software running on the NetApp file server. It may not be worth 
attempting to fix it in Debian.


Regards, Matthew


On Mon, Feb 18, 2019 at 10:38:32AM -0800, Matthew Foulkes wrote:

Hi Mathieu,

I am visiting the US until the end of March and do not have access to 
a computer running Debian at the moment. Sorry. I will be buying a new 
laptop in a couple of weeks and will install Debian when it arrives, 
but cannot help you until then.


Regards, Matthew

On Mon, Feb 18, 2019 at 01:39:23PM +0100, Mathieu Parent wrote:

Hello all,

Are you able to reproduce this bug on latest stretch (2:4.5.16+dfsg-1)
and/or latest buster (2:4.9.4+dfsg-3, -2 is ok).

Regards
--
Mathieu Parent


--
**
email: m.foul...@blueyonder.co.uk
phone: 07905 505676
**


--
**
 email: m.foul...@blueyonder.co.uk
 phone: 07905 505676
**

Bug#923418: Introduces spurious whitespace after parentheses

[Martin Michlmayr]

Package: pandoc
Version: 2.2.1-3+b2

pandoc introduces a space after parentheses under certain
circumstances:

65576:tbm@jirafa: ~] cat pandoc

this is a test (e.g.
why is there a space after the parenthesis?).

65577:tbm@jirafa: ~] cat pandoc | pandoc
this is a test ( e.g. why is there a space after the parenthesis?).

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#923330: jajuk: Fails to start with Java Runtime Environment 1.7 minimum required. You use a JVM ext.JVM@23fc625e

[Werner Mahr]

Am Mittwoch, 27. Februar 2019, 00:56:12 CET schrieben Sie:
> Am 26.02.19 um 21:34 schrieb Markus Koschany:
> > Thanks for reporting and the hint how to fix this problem. I'll take a
> > closer look soon.
> 
> Unfortunately there is another issue that prevents jajuk from starting.
> This appears to be the same one which affects triplea as well.
> 
> https://bugs.debian.org/911078

That's correct. I've seen your message exactly 1 minute after trying the fix 
from git.

-- 
MfG usw.

Werner Mahr

Bug#922731: llvm-toolchain-7: Unjustified API breakage introduced by Debian patch

[Sylvestre Ledru]

I was waiting for 7.1.0 but as it isn't coming, I will upload it now

S


Le 26/02/2019 à 23:58, Svante Signell a écrit :

ping!

On Wed, 2019-02-20 at 12:51 +0100, Svante Signell wrote:

On Wed, 2019-02-20 at 09:21 +0100, Sylvestre Ledru wrote:

Bug#923382: libseqlib: FTBFS (dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file)

[Santiago Vila]

Package: src:libseqlib
Version: 1.1.2+dfsg-2
Severity: serious
Tags: ftbfs

Hello Andreas et al.

I tried to build this package in buster but it failed:


[...]
 debian/rules build-arch
dh build-arch
   dh_update_autotools_config -a
   dh_autoreconf -a
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
libtoolize: 'AC_PROG_RANLIB' is rendered obsolete by 'LT_INIT'
configure.ac:17: installing './compile'
configure.ac:19: installing './config.guess'
configure.ac:19: installing './config.sub'
configure.ac:4: installing './missing'
src/Makefile.am: installing './depcomp'
   dh_auto_configure -a
./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu 
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of g++... none
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... none
checking for ranlib... ranlib
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu 
format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... 
func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... (cached) ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared 
libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is 

Bug#923209: RFS: heaptrack/1.1.0+20180922.gitf752536-3.1 [NMU]

[Chris Lamb]

Hi Nicholas,

> Maybe it's obvious, but perhaps the developer's reference and
> wiki/PackageSalvaging would benefit from the addition of "Things to do
> before NMUing…for a team maintained package, […]  It's a
> trivial bit of work I'd be happy to do...

Go for it :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#923340: RFS: dwarves-dfsg/1.12-2 (RC)

[Domenico Andreoli]

On Tue, Feb 26, 2019 at 08:15:59PM +0100, Adam Borowski wrote:
> On Tue, Feb 26, 2019 at 06:06:18PM +0100, Domenico Andreoli wrote:
> > * Package name: dwarves-dfsg
> >   Version : 1.12-2
> 
> > Changes since the last upload:
> > 
> > dwarves-dfsg (1.12-2) unstable; urgency=medium
> > 
> >   * Convert to dh.
> >   * Fix Homepage and Vcs-Git.
> >   * Fix depends on debhelper >= 10.
> >   * Remove trailing spaces from the Debian changelog.
> >   * Update copyright to copyright-format/1.0. Closes: #919356.
> 
> Hi!

Hi,

> The new copyright file contains references to GPL-2.0-only and
> GPL-2.0-or-later without defining them.

According to https://spdx.org/licenses/ they are defined and supersede
GPL-2 and GPL-2+ now deprecated (maybe I should file a bug). OTOH I'm
reading that as long as copyright-format is not updated, new ones should
not be used.

Anyway, this is what I get if I switch to GPL-2 and GPL-2+ everywhere:

W: dwarves-dfsg source: missing-license-paragraph-in-dep5-copyright gpl-2+ 
(paragraph at line 102)
N: 
N:The files paragraph in the machine readable copyright file references a
N:license, for which no standalone license paragraph exists.
N:
N:Refer to
N:https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ for
N:details.
N:
N:Severity: normal, Certainty: possible
N:
N:Check: source-copyright, Type: source
N: 
W: dwarves-dfsg source: missing-license-paragraph-in-dep5-copyright gpl-2 
(paragraph at line 94)

I spent quite some time in trying to understand what lintian tries
to tell me here. I verified that reshuffling the file does not help
either, these errors stay in a similar location, as if lintian had some
bug somewhere.

I also expected they to be repeated as many times as in the files (yes,
I'm using --no-tag-display-limit -i) but they are not and so at certain
point I gave up.

I'm uploaded a new version with GPL-2/GPL-2+, should be available shortly.

Thanks for reviewing.

Regards,
Domenico

-- 
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13


signature.asc
Description: PGP signature

Bug#923378: unblock: spampd/2.53-1

[Michael Meskes]

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

Please unblock package spampd

Yes, I know it is a new upstream version, but all versions of spampd starting
with 2.40 had a breaking bug in LMTP processing for multiple recipients
(re-introducing the bug originally reported in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395355). When upstream
learned this, he released a new and fixed version. 

The only other change in the new upstream version is a fix for a warning
message that we had a very similar patch for. The only change is that upstream
put the initialization in question at a different line of the source file.

Finally I fixed an oversight by myself that upstream pointed out. The standard
way of calling spampd lacked the option "--setsid". I seem to have forgotten
the option when the prior patched-in solution was removed.

debdiff is attached.

Thanks

Michael

unblock spampd/2.53-1

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.20.0-trunk-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru spampd-2.52/changelog.txt spampd-2.53/changelog.txt
--- spampd-2.52/changelog.txt   2018-11-10 10:24:14.0 +0100
+++ spampd-2.53/changelog.txt   2019-02-25 12:49:09.0 +0100
@@ -1,6 +1,11 @@
 SpamPD Change Log
 -
 
+2.53 (25-Feb-19)
+
+- Fix LMTP delivery with multiple recipients 
(https://github.com/mpaperno/spampd/issues/23 & 
https://github.com/mail-in-a-box/mailinabox/issues/1523)
+- Fix Warning for "Use of uninitialized value in string" 
(https://github.com/mpaperno/spampd/issues/22)
+
 2.52 (10-Nov-18)
 
 - Override Net::Server's HUP handling, just restart children 
(https://github.com/mpaperno/spampd/pull/20).
@@ -10,17 +15,11 @@
 
 2.51 (01-May-18)
 
-- Fix listening to IP address, broken in 2.50 "Unix ports" feature.  (#18)
-- Add --setsid option to start server with setsid if running in background 
(#18)
 - Fix listening to IP address, broken in 2.50 "Unix ports" feature.  
(https://github.com/mpaperno/spampd/pull/18)
 - Add --setsid option to start server with setsid if running in background 
(https://github.com/mpaperno/spampd/pull/18)
 
 2.50 (30-Apr-18)
 
-- Replace IO::Socket::INET with IO::Socket::IP for IPv6 support (#9).
-- Unix ports (ability to listen on UNIX sockets) (#13).
-- Add X-Envelope-* headers before Received (#14).
-- Add /usr/local/bin and /usr/local/sbin to PATH (#17).
 - Replace IO::Socket::INET with IO::Socket::IP for IPv6 support 
(https://github.com/mpaperno/spampd/pull/9).
 - Unix ports (ability to listen on UNIX sockets) 
(https://github.com/mpaperno/spampd/pull/13).
 - Add X-Envelope-* headers before Received 
(https://github.com/mpaperno/spampd/pull/14).
diff -Nru spampd-2.52/debian/changelog spampd-2.53/debian/changelog
--- spampd-2.52/debian/changelog2018-11-21 12:24:59.0 +0100
+++ spampd-2.53/debian/changelog2019-02-26 12:16:46.0 +0100
@@ -1,3 +1,11 @@
+spampd (2.53-1) unstable; urgency=medium
+
+  * New upstream version 2.53
+  * Use the --setsid argument to make sure the process is correctly detached.
+  * Bumped Standards-Version, no changes needed.
+
+ -- Michael Meskes   Tue, 26 Feb 2019 12:16:46 +0100
+
 spampd (2.52-1) unstable; urgency=medium
 
   * New upstream version 2.52 (Closes: #849543)
diff -Nru spampd-2.52/debian/control spampd-2.53/debian/control
--- spampd-2.52/debian/control  2018-11-21 12:21:27.0 +0100
+++ spampd-2.53/debian/control  2019-02-26 12:16:46.0 +0100
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Michael Meskes 
 Build-Depends: debhelper (>= 11), quilt, dh-exec
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
 Homepage: https://github.com/mpaperno/spampd
 
 Package: spampd
diff -Nru spampd-2.52/debian/patches/20-proto-warning.patch 
spampd-2.53/debian/patches/20-proto-warning.patch
--- spampd-2.52/debian/patches/20-proto-warning.patch   2018-11-21 
12:22:45.0 +0100
+++ spampd-2.53/debian/patches/20-proto-warning.patch   1970-01-01 
01:00:00.0 +0100
@@ -1,10 +0,0 @@
 spampd-2.52/spampd.pl.orig 2018-11-10 10:24:14.0 +0100
-+++ spampd-2.52/spampd.pl  2018-11-12 08:32:59.0 +0100
-@@ -145,6 +145,7 @@
- return 0 unless defined($_ = $self->_getline);
- s/[\r\n]*$//;
- $self->{state} = $_;
-+$self->{proto} = "(unknown)";
- if (s/^(l|h)?he?lo\s+//i) {  # mp: find helo|ehlo|lhlo
-   # mp: determine protocol
-   if (s/^helo\s+//i) {
diff -Nru spampd-2.52/debian/patches/series spampd-2.53/debian/patches/series
--- spampd-2.52/debian/patches/series   2018-11-21 12:24:02.0 +0100
+++ 

Bug#922815: insserv FATAL while updating as mountkernfs has to be enabled to use service udev

[shirish शिरीष]

at bottom :-

On 27/02/2019, Dmitry Bogatov  wrote:
>



>
> Seems there is no /etc/init.d/mountkernfs.sh on your system.
>
> Since your init system is systemd, I question, why do you need insserv
> in first place. Do you have bin:initscripts installed?
>
> My guess is that update-initramfs invokes insserv /if/ it is available,
> and since you have insserv installed, but no initscripts, we get this
> bug.
>
> Adding initramfs-tools maintainer into loop. If my guess is correct,
> this issue should be resolved on initramfs side, since making insserv
> depending on initscripts is not nice to user.
> --
> Note, that I send and fetch email in batch, once every 24 hours.
>  If matter is urgent, try https://t.me/kaction
>
> --
>

Dear Dimity,

You are right on both counts. Indeed systemd is pid 0 on my system.

In answer to your query, I attempted -

$ aptitude why insserv
i   rcconf  Depends sysv-rc
i A sysv-rc Depends insserv (> 1.12.0-10)

Does this answer the question ?

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#923168: initscripts: Old cruft in initscripts postinst

[Pierre Ynard]

> Thank you very much for your research and patches. Can you please
> re-submit your patches in format, generated by `git format-patch'?
>
> What you included is `git show` output, which is not possible to apply
> directly. Thank you again.

Here you go.

-- 
Pierre Ynard
From 289d898ca707be223d4220951cdc3753d21e2df6 Mon Sep 17 00:00:00 2001
From: Pierre Ynard 
Date: Sun, 24 Feb 2019 17:29:36 +0100
Subject: [PATCH 1/2] Remove write-only variable left over from legacy
 migration postinst code

The code using that workaround is long gone.
---
 debian/initscripts.postinst | 6 --
 1 file changed, 6 deletions(-)

diff --git a/debian/initscripts.postinst b/debian/initscripts.postinst
index c6ac94d..4ed27ec 100755
--- a/debian/initscripts.postinst
+++ b/debian/initscripts.postinst
@@ -9,12 +9,6 @@ set -e
 . /lib/init/tmpfs.sh
 . /lib/init/mount-functions.sh
 
-# Set this as a variable to hide from lintian the fact that we're removing
-# it; otherwise, a wrong lintian check + ftp fatal autoreject prevents us
-# from uploading this legitimate code, even though the previous upload was
-# accepted without incident.
-devshm=/dev/shm
-
 case "$1" in
   configure)
 	PREV_VER=$2
-- 
2.1.4

From 2f1e2ebf9e6154acabb419789ee193678e221300 Mon Sep 17 00:00:00 2001
From: Pierre Ynard 
Date: Sun, 24 Feb 2019 17:39:16 +0100
Subject: [PATCH 2/2] Clean up unused leftover legacy migration code from
 postinst

The postinst code using this was long cleaned up itself.
---
 debian/initscripts.postinst | 34 --
 1 file changed, 34 deletions(-)

diff --git a/debian/initscripts.postinst b/debian/initscripts.postinst
index 4ed27ec..ad0eb4d 100755
--- a/debian/initscripts.postinst
+++ b/debian/initscripts.postinst
@@ -20,40 +20,6 @@ esac
 
 umask 022
 
-compat_link () {
-	SRC=$1
-	DEST=$2
-
-	ssrc="$(stat -L --format="%d %i" "$SRC" 2>/dev/null || :)"
-	sdest="$(stat -L --format="%d %i" "$DEST" 2>/dev/null || :)"
-
-	if [ -n "$ssrc" ] && [ "$ssrc" != "$sdest" ]; then
-		echo "guest environment detected: Linking $DEST to $SRC"
-		(
-			if [ -e $DEST ]; then
-if [ -L $DEST ]; then
-	echo "$DEST is already a symlink; not replacing with link to $SRC"
-	exit 0
-elif [ -d $DEST ]; then
-	rmdir $DEST || exit 1
-else
-	echo "$DEST isn't a directory or a symlink"
-	exit 1
-fi
-			fi
-			ln -fs $SRC $DEST
-		) || {
-			echo "Can't symlink $DEST to $SRC; please fix manually."
-			return 1
-		}
-		if which restorecon >/dev/null 2>&1; then
-			restorecon "$DEST"
-		fi
-	fi
-
-	return 0
-}
-
 # In 2.88dsf-23 the "mountoverflowtmp" script was dropped entirely.
 if dpkg --compare-versions "$PREV_VER" lt-nl "2.88dsf-23" ; then
 update-rc.d -f mountoverflowtmp remove >/dev/null
-- 
2.1.4

Bug#873086: ifupdown script disables IPv6 on parent of VLAN interface

[Roman Mamedov]

Hello,

I just hit this bug as well. From what I see this has been fixed in 1.5-16,
but Stretch currently contains 1.5-13+deb9u1. And 1.5-16 is not available in
any archive. The Buster version is 1.6-2. Is it possible to push the fixed
version to Stretch?

Thanks

-- 
With respect,
Roman

Bug#873086: ifupdown script disables IPv6 on parent of VLAN interface

[Roman Mamedov]

Hello,

Actually, both 1.6-2 and 1.5-16 still disable IPv6 on the parent interface for
me, in a config like this:

iface br-test inet static
  address 192.168.9.101
  netmask 255.255.255.0
  bridge-ports eth1.1008

After "ifup br-test", /proc/sys/net/ipv6/conf/eth1/disable_ipv6 is set to 1.

-- 
With respect,
Roman

Bug#923374: root mode doesn't work anymore?

[Jonas Smedegaard]

Quoting Daniel Baumann (2019-02-27 05:18:53)
> with previous version of mmdebstrap, I used to do:
> 
>   sudo mmdebstrap sid sid http://deb.debian.org/debian
> 
> which then automatically uses 'root mode'.
> 
> Now I get this instead:
> 
> ---snip---
> I: automatically chosen mode: root
> I: chroot architecture amd64 is equal to the host's architecture
> I: running apt-get update...
> done
> Get:1 http://deb.debian.org/debian sid InRelease [242 kB]
> Get:2 http://deb.debian.org/debian sid/main amd64 Packages [8366 kB]
> Fetched 8608 kB in 2s (4984 kB/s)
> Reading package lists...
> W: Download is performed unsandboxed as root as file
> '/root/sid/var/lib/apt/lists/partial/deb.debian.org_debian_dists_sid_InRelease'
> couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission
> denied)
> apt-get update failed at /usr/bin/mmdebstrap line 569.
> ---snap---
> 
> Looking at the manpage I coudn't find anything obvious that I'm doing
> wrong. If there is, maybe the default behaviour could be made more
> user-friendly to 'just work'[tm]? Or is there a bug in 'root mode'?

I noticed such error message yesterday when running apt update inside a 
chroot - so perhaps this is not specific to mmdebstrap but is tied to 
apt or dpkg, especially the latter seeing major changes recently.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#923379: u-boot: Dreamplug fails to detect SPI and USB

[Leigh Brown]

Package: u-boot
Version: 2019.01+dfsg-1
Severity: important
Tags: upstream

Dear Maintainer,

I flashed u-boot 2019.01+dfsg-1 on my Dreamplug. I found that u-boot was
unable to detect the SPI flash on the device (and thus could not read
the u-boot environment). It could also not detect the usb storage.

On booting, the following output is observed:

8<
U-Boot 2019.01+dfsg-1 (Jan 15 2019 - 00:36:19 +)
Marvell-DreamPlug

oC:   Kirkwood 88F6281_A1
DRAM:  512 MiB
Loading Environment from SPI Flash... Invalid bus 0 (err=-19)
*** Warning - spi_flash_probe_bus_cs() failed, using default environment

In:serial
Out:   serial
Err:   serial
Net:   egiga0
Error: egiga0 address not set.
, egiga1
Error: egiga1 address not set.

88E1116 Initialized on egiga0
88E1116 Initialized on egiga1
IDE:   ide_preinit failed
Hit any key to stop autoboot:  0
=> usb start
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
 ERROR: NOT USB_CONFIG_DESC a3
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008c80
EHCI timed out on TD - token=0x80008c80
2 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
8<

I then compiled u-boot from the upstream git tree and tried various
versions.  The results are as follows:

v2018.01 all works
v2018.07 all works
v2018.09 all works
v2018.11 USB fails
v2019.01 SPI flash fails, USB fails

I then bisected both issues.  The USB issue was caused by the following
commit:

commit 93b283d49f933f95f3a6f40762936f454ac655a8
Author: Adam Ford 
Date:   Thu Aug 16 13:23:11 2018 -0500

ARM: CPU: arm926ejs: Consolidate cache routines to common file

Four different boards had different options for enabling cache
that were virtually all the same.  This consolidates these
common functions into arch/arm/cpu/arm926ejs/cache.c

This also has the positive side-effect of enabling cache on
the Davinci (da850) boards.

Signed-off-by: Adam Ford 
[trini: Add mach-at91 to the list of consolidations]
Signed-off-by: Tom Rini 

I used the following patch to temporarily fix up the issue (I am no
expert on ARM so cannot say whether this is in any way correct):

iff --git a/arch/arm/mach-kirkwood/cpu.c b/arch/arm/mach-kirkwood/cpu.c
index d54de53f31..8a065d73ae 100644
--- a/arch/arm/mach-kirkwood/cpu.c
+++ b/arch/arm/mach-kirkwood/cpu.c
@@ -291,7 +291,6 @@ int arch_misc_init(void)
temp |= (1 << 22);
writefr_extra_feature_reg(temp);
 
-   icache_enable();
/* Change reset vector to address 0x0 */
temp = get_cr();
set_cr(temp & ~CR_V);
diff --git a/include/configs/dreamplug.h b/include/configs/dreamplug.h
index f4d717213c..6348935c68 100644
--- a/include/configs/dreamplug.h
+++ b/include/configs/dreamplug.h
@@ -79,4 +79,6 @@
 #define CONFIG_SYS_ATA_IDE0_OFFSET MV_SATA_PORT0_OFFSET
 #endif /*CONFIG_MVSATA_IDE*/
 
+#define CONFIG_SYS_DCACHE_OFF
+
 #endif /* _CONFIG_DREAMPLUG_H */

I then bisected the SPI flash issue, and found it was caused by the
following commit:

commit 6aaf76beb131c2ff2b7184c2d63c2c63e5ab339c
Author: Chris Packham 
Date:   Wed Nov 21 22:22:23 2018 +1300


arm: kirkwood: configs: dreamplug: Convert to DM_SPI

Enable CONFIG_DM_SPI=y and CONFIG_DM_SPI_FLASH=y in the defconfig.

Signed-off-by: Chris Packham 
Reviewed-by: Stefan Roese 
Signed-off-by: Stefan Roese 

I don't know enough about u-boot to easily diagnose this issue.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: armel (armv5tel)

Kernel: Linux 4.19.7+
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- no debconf information

Bug#918206: Pandas

[Andreas Tille]

Dear Rebecca,

On Wed, Feb 27, 2019 at 07:25:26AM +, Rebecca N. Palmer wrote:
> On 27/02/2019 07:00, Andreas Tille wrote:
> > Dear Rebecca,
> > I do not think that there is any
> > need for a separate branch.  Just stick to the debian branch.
> 
> It's needed because the debian branch contains the attempt at packaging 0.24
> described earlier in this thread, which it's now too late for.

You are right.  Considering the branching jungle (Yaroslav, could you possibly
cleanup branches that are not used any more?) I'd prefer if you would move the
0.24 packaging to some separate branch (debian-experimental is covered but may
be debian-0.24 or something like this?) and keep branch debian for what we are
really releasing.

Thanks again for your work on this

Andreas.

-- 
http://fam-tille.de

Bug#923381: x2broker: [INTL:fr] French debconf templates translation

[Jean-Pierre Giraud]

Package: x2broker
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french translation, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind Regards

jipege



fr.po.gz
Description: application/gzip

Bug#923380: progress-linux: [INTL:fr] French debconf templates translation

[Jean-Pierre Giraud]

Package: progress-linux
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french translation, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind Regards

jipege



fr.po.gz
Description: application/gzip

Bug#910902: Please test again: my_print_defaults and Akonadi for a freash installation

[Otto Kekäläinen]

Looks like this has never been in the core package:

https://packages.debian.org/search?searchon=contents=resolveip=path=unstable=any
/usr/bin/resolveipmariadb-server-10.0 [arm64], mariadb-server-10.1
[powerpc], mariadb-server-10.3 [ei ia64, powerpc, s390, sparc],
mariadb-server-5.5 [sparc, arm64], mysql-server-5.5 [sparc, ia64,
s390, arm64], mysql-server-5.7 [ei hurd-i386, ia64, kfreebsd-i386,
s390, sparc, sparc64], percona-xtradb-cluster-server-5.5 [sparc,
arm64]

Moving the file requires some consideration for backwards
compatibility etc. Would you like to take a look at this and try to
come up with a solution?

See https://wiki.debian.org/Teams/MySQL/patches on how to use Salsa-CI
to test and submit patches.

Bug#923420: coreutils: mv broken when file system doesn't support RENAME_NOREPLACE

[Johannes Schauer]

Hi Felix,

Quoting Felix Geyer (2019-02-27 23:16:15)
> With those distro patches from version 8.30-2 mv fails on filesystems that 
> don't
> support the renameat2 RENAME_NOREPLACE flag.
> I noticed this because coreutils 8.30-2 breaks autopkgtest with the qemu 
> runner
> which calls mv on a 9p filesystem.
> 
> renameatu.patch is the offender as it only changes renameat2() calls to 
> renameatu()
> in lib/ but not in src/.
> As a result some tools call the glibc renameat2() instead of the gnulib one 
> which
> has appropriate fallbacks.
> I haven't checked what other tools are exactly affected (calls are in mv.c, 
> shred.c
> and copy.c).
> 
> After an extended debugging session,

wow, that must've been a "fun" session until you figured out what was wrong!

Unfortunately, I'm still on holidays until March 3, so I cannot look into the
situation before then due to very limited internet access in the Swedish
mountains.

I'm sorry I missed this issue my patch created on filesystems that don't
support the RENAME_NOREPLACE flag. :(

cheers, josch


signature.asc
Description: signature

Bug#923418: Introduces spurious whitespace after parentheses

[Martin Michlmayr]

* John MacFarlane  [2019-02-27 14:15]:
> This looks like
> 
> https://github.com/jgm/pandoc/issues/4635
> 
> which is fixed in recent versions nof pandoc.
> 2.2.2+

Yeah, sounds like it.

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#923210: bash-completion: postinst and postrm generate find warnings

[Gabriel F. T. Gomes]

On Sun, Feb 24 2019, Daniel Lewart wrote:
> Package: bash-completion
> Version: 1:2.8-5
> Severity: minor
> Tags: patch
> 
> Both "apt install bash-completion" and "apt purge bash-completion"
> generate the following warning:
>   find: '/etc/bash_completion.d/': No such file or directory
> 
> The cause is that postinst and postrm assume that
> /etc/bash_completion.d exists.
> 
> Patch is attached.

Thanks.

I have a comment about a hunk in the patch and a question, here:

Is it safe to upload such a change so close to the freeze?  I'm always
worried about unforeseen side-effects.

> diff -ru a/debian/postinst b/debian/postinst
> --- a/debian/postinst 2018-12-21 19:23:09.0 -0600
> +++ b/debian/postinst 2019-02-24 00:00:00.0 -0600
> @@ -4,19 +4,21 @@
>  
>  case "$1" in
>  configure)
> -# let's remove old bash-completion conffiles
> -for f in $(find /etc/bash_completion.d/ -type f -name "*.dpkg-*"); do
> -dpkg-maintscript-helper rm_conffile ${f%.dpkg-*} 1:1.3-1 -- "$@"
> -done
> +if [ -d /etc/bash_completion.d ]; then
> +# let's remove old bash-completion conffiles
> +for f in $(find /etc/bash_completion.d/ -type f -name 
> "*.dpkg-*"); do
> +dpkg-maintscript-helper rm_conffile ${f%.dpkg-*} 1:1.3-1 -- 
> "$@"
> +done

OK.

> -if dpkg --compare-versions "$2" le "1:2.1-3"; then
> -if [ -d /etc/bash_completion.d/helpers ]; then
> -rmdir --ignore-fail-on-non-empty 
> /etc/bash_completion.d/helpers 2>/dev/null
> +if dpkg --compare-versions "$2" le "1:2.1-3"; then
> +if [ -d /etc/bash_completion.d/helpers ]; then
> +rmdir --ignore-fail-on-non-empty 
> /etc/bash_completion.d/helpers 2>/dev/null
> +fi
> +# disabled from Ubuntu, third party packages might have 
> installed things here
> +#if [ -d /etc/bash_completion.d ]; then
> +#rmdir --ignore-fail-on-non-empty /etc/bash_completion.d 
> 2>/dev/null
> +#fi
>  fi
> -# disabled from Ubuntu, third party packages might have 
> installed things here
> -#if [ -d /etc/bash_completion.d ]; then
> -#rmdir --ignore-fail-on-non-empty /etc/bash_completion.d 
> 2>/dev/null
> -#fi
>  fi
>   ;;
>  abort-upgrade|abort-remove|abort-deconfigure)

Is this hunk needed?  The test (-d /etc/bash_completion.d/helpers) is
not likely to produce the warnings you mentioned.

> diff -ru a/debian/postrm b/debian/postrm
> --- a/debian/postrm   2018-12-21 19:23:09.0 -0600
> +++ b/debian/postrm   2019-02-24 00:00:00.0 -0600
> @@ -5,10 +5,12 @@
>  case "$1" in
>  purge)
>   rm -f /etc/bash_completion
> -# let's remove old bash-completion conffiles
> -for f in $(find /etc/bash_completion.d/ -type f -name "*.dpkg-*"); do
> -dpkg-maintscript-helper rm_conffile ${f%.dpkg-*} 1:1.3-1 -- "$@"
> -done
> + if [ -d /etc/bash_completion.d ]; then
> +# let's remove old bash-completion conffiles
> +for f in $(find /etc/bash_completion.d/ -type f -name 
> "*.dpkg-*"); do
> +dpkg-maintscript-helper rm_conffile ${f%.dpkg-*} 1:1.3-1 -- 
> "$@"
> +done
> + fi
>   ;;
>  remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
>   ;;

OK.

Bug#920519: ITA: mtx -- controls tape autochangers

[Carsten Leonhardt]

Control: retitle -1 ITA: mtx -- controls tape autochangers

I'm going to adopt mtx, probably as part of the Bacula packaging team.

Bug#923422: psmisc: pstree segfault with threads (patch included)

[Charles Samuels]

Package: psmisc 
Version: 22.21-2.1+b2 
Severity: normal

Dear Maintainer,

When I run pstree on my busy servers, it usually SIGSEGVs before outputting
anything.

This is because pstree is calling `fclose(f)` on an `f` that may 
be null, which is not permitted:

   The behaviour of fclose() is undefined if the stream parameter is
   an illegal pointer, or is  a  descriptor  already
   passed to a previous invocation of fclose().

(quoting man fclose)

-- System Information:
Debian Release: 9.7
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/64 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages psmisc depends on:
ii  libc62.24-11+deb9u3
ii  libselinux1  2.6-3+b3
ii  libtinfo56.0+20161126-1+deb9u2

psmisc recommends no packages.

psmisc suggests no packages.

-- no debconf informationdiff -ur psmisc-22.21/src/pstree.c psmisc-22.21-fixed/src/pstree.c
--- psmisc-22.21/src/pstree.c	2014-02-02 05:59:07.0 +
+++ psmisc-22.21-fixed/src/pstree.c	2019-02-27 23:19:40.611866628 +
@@ -819,7 +819,9 @@
 }
 /* Fall back to old method */
 sprintf(threadname, "{%.*s}", COMM_LEN, comm);
-fclose(file);
+if (file) { 
+fclose(file);
+}
 return threadname;
 }

Bug#921889: debian-policy: recommends an old version of libjs-sphinxdoc

[Sean Whitton]

Hello Gabriele,

On Wed 27 Feb 2019 at 10:56PM +01, Gabriele Stilli wrote:

> unfortunately the bug showed again when the latest libjs-sphinxdoc
> 1.8.4-1 entered buster.
>
> (debian-policy now Recommends: libjs-sphinxdoc (< 1.8.3.0~))
>
> Not sure we want to undergo all this at every sphinx version bump :-)

Once #658238 is resolved, it won't be necessary.  See comments in
debian-policy's d/rules.

I've made another upload.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#923423: texlive-fonts-extra installation hangs

[Vincent Lefevre]

Package: texlive-fonts-extra
Version: 2018.20190227-1
Severity: serious

Installation of texlive-fonts-extra 2018.20190227-1 hangs.

Here's px information:

# px 5553
/usr/bin/dpkg
  --status-fd
  80
  --no-triggers
  --unpack
  --auto-deconfigure
  --recursive
  /tmp/apt-dpkg-install-mos7uq

kernel(0) root
  init(1) root
lightdm(915)  root
  lightdm(1525)   root
zsh(1547) vinc17
  fvwm2(1629) vinc17
sh(1745)  vinc17
  xterm(1746) vinc17
zsh(1750) vinc17
  su(1839)root
bash(1841)root
  aptitude(2012)  root
--> dpkg(5553)root

17m01s ago dpkg was started, at 2019-02-28T00:48:45+01:00.
1.5% has been its average CPU usage since then, or 15s/17m01s

Other processes started close to dpkg(5553):
  [kworker/0:1-events](5351) was started 2m57s before dpkg(5553)
  [kworker/u17:0-kcryptd](5540) was started 1.0s before dpkg(5553)
  [kworker/4:2](5771) was started 2m19s after dpkg(5553)
  [kworker/u16:1-events_unbound](5928) was started 4m21s after dpkg(5553)
  [kworker/5:2-mm_percpu_wq](6068) was started 5m06s after dpkg(5553)

Users logged in when dpkg(5553) started:
  vinc17 from 155.133.131.76
  vinc17 from :0

2019-02-28T01:05:46.585799: Now invoking lsof, this can take over a minute on a 
big system...
2019-02-28T01:05:47.098503: lsof done, proceeding.

File descriptors:
  stdin : [CHR] /dev/pts/16
  stdout: [CHR] /dev/pts/16
  stderr: [CHR] /dev/pts/16

Network connections:

Inter Process Communication:
  aptitude(2012): [FIFO] pipe

For a list of all open files, do "sudo lsof -p 5553", or "sudo watch lsof -p 
5553" for a live view.

-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 2880 2019-02-27 03:14:07 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 2018-09-02 14:32:33 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 2019-02-27 01:08:59 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 2019-02-27 01:08:59 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 2018-09-02 20:20:53 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 2019-02-27 01:08:59 
/usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 2019-02-27 01:08:59 /usr/share/texmf/web2c/updmap.cfg 
-> /var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5089 2019-02-27 03:13:40 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 2014-10-21 02:46:09 mktex.cnf
-rw-r--r-- 1 root root 475 2018-09-02 20:20:53 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), 

Bug#910902: Please test again: my_print_defaults and Akonadi for a freash installation

[Sandro Knauß]

Control: tags -1 -moreinfo
Control: retitle -1 resolveip is missing for a fresh installation of Akonadi

Hey,

Okay I made the initial test late December and checked against 10.1. I now 
checked again and you are right my_print_defaults is now found in the -core 
package.

Bit this the command is not successfully:
 "/usr/bin/mysql_install_db" "--defaults-file= --force --basedir=/usr --
datadir=/home/siducer/.local/share/akonadi/db_data/"

it fails because /usr/bin/resolveip is missing in core package.

hefee

> If you look at
> https://packages.debian.org/stretch/amd64/mariadb-server-core-10.1/filelist
> there is no my_print_defaults
> 
> However since 10.3 there is:
> https://packages.debian.org/sid/amd64/mariadb-server-core-10.3/filelist
>   /usr/bin/my_print_defaults
>   ..
>   /usr/share/man/man1/my_print_defaults.1.gz
> 
> Your question is the other way around. Can you please test again if
> this is actually a issue with MariaDB 10.3 or something else? Are you
> using the MariaDB from official Debian repositories?



signature.asc
Description: This is a digitally signed message part.

Bug#923421: start-stop-daemon: matching only on non-root pidfile /run/sogo/sogo.pid is insecure

[Niels Nowatzki]

Package: sogo
Version: 4.0.5-3
Severity: important

Dear Maintainer,

i just ran in a problem which was already reported on other packages (#921557 
and #921016).
When i try to restart or stop sogod the initscript throws an error message as 
seen in the subject
and ceases to operate.

The attached patch resembles the solution of #921016 and works for me.

In other notes: The severity should probably really be "serious", but i could 
not easily find out 
how to feed it to the BTS.

Thanks for your good work,
niels
 

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages sogo depends on:
ii  adduser   3.118
ii  gnustep-base-runtime  1.26.0-4
ii  libc6 2.28-7
ii  libcurl3-gnutls   7.64.0-1
ii  libgcc1   1:8.2.0-21
ii  libglib2.0-0  2.58.3-1
ii  libgnustep-base1.26   1.26.0-4
ii  libgnutls30   3.6.6-2
ii  liblasso3 2.6.0-2+b2
ii  libmemcached111.0.18-4.2
ii  libobjc4  8.2.0-21
ii  libsbjson2.3  2.3.2-4+b1
ii  libsope1  4.0.5-2
ii  lsb-base  10.2018112800
ii  memcached 1.5.6-1
ii  sogo-common   4.0.5-3
ii  tmpreaper 1.6.14
ii  zip   3.0-11+b1

sogo recommends no packages.

Versions of packages sogo suggests:
pn  postgresql | default-mysql-server | virtual-mysql-server  

-- Configuration Files:
/etc/init.d/sogo changed [not included]
/etc/sogo/sogo.conf [not included] 

-- no debconf information
diff -u orig/debian/sogo.init patch/debian/sogo.init
--- orig/debian/sogo.init   2019-02-27 22:13:00.809760064 +0100
+++ patch/debian/sogo.init  2019-02-27 22:17:41.581975621 +0100
@@ -74,12 +74,12 @@
;;
   stop)
log_daemon_msg "Stopping $DESC" "$NAME"
-   start-stop-daemon --stop --oknodo --pidfile $PIDFILE 
--retry=TERM/20/KILL/5
+   start-stop-daemon --stop --oknodo --pidfile $PIDFILE 
--retry=TERM/20/KILL/5 --user $USER
log_end_msg 0
;;
   restart|force-reload)
log_daemon_msg "Restarting $DESC" "$NAME"
-   start-stop-daemon --stop --oknodo --pidfile $PIDFILE 
--retry=TERM/20/KILL/5
+   start-stop-daemon --stop --oknodo --pidfile $PIDFILE 
--retry=TERM/20/KILL/5 --user $USER
 # Ensure run directory's existence and permissions
if [ ! -d /run/sogo ]; then
 install -o $USER -g $GROUP -d /run/sogo

Bug#923420: coreutils: mv broken when file system doesn't support RENAME_NOREPLACE

[Felix Geyer]

Package: coreutils
Version: 8.30-2
Severity: serious

Hi,

With those distro patches from version 8.30-2 mv fails on filesystems that don't
support the renameat2 RENAME_NOREPLACE flag.
I noticed this because coreutils 8.30-2 breaks autopkgtest with the qemu runner
which calls mv on a 9p filesystem.

renameatu.patch is the offender as it only changes renameat2() calls to 
renameatu()
in lib/ but not in src/.
As a result some tools call the glibc renameat2() instead of the gnulib one 
which
has appropriate fallbacks.
I haven't checked what other tools are exactly affected (calls are in mv.c, 
shred.c
and copy.c).

After an extended debugging session,
Felix

Bug#923374: root mode doesn't work anymore?

[Johannes Schauer]

Hi Daniel,

Quoting Daniel Baumann (2019-02-27 05:18:53)
> with previous version of mmdebstrap, I used to do:
> 
>   sudo mmdebstrap sid sid http://deb.debian.org/debian
> 
> which then automatically uses 'root mode'.
> 
> Now I get this instead:
> 
> ---snip---
> I: automatically chosen mode: root
> I: chroot architecture amd64 is equal to the host's architecture
> I: running apt-get update...
> done
> Get:1 http://deb.debian.org/debian sid InRelease [242 kB]
> Get:2 http://deb.debian.org/debian sid/main amd64 Packages [8366 kB]
> Fetched 8608 kB in 2s (4984 kB/s)
> Reading package lists...
> W: Download is performed unsandboxed as root as file
> '/root/sid/var/lib/apt/lists/partial/deb.debian.org_debian_dists_sid_InRelease'
> couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission
> denied)
> apt-get update failed at /usr/bin/mmdebstrap line 569.
> ---snap---
> 
> Looking at the manpage I coudn't find anything obvious that I'm doing
> wrong. If there is, maybe the default behaviour could be made more
> user-friendly to 'just work'[tm]? Or is there a bug in 'root mode'?

hrm... this is odd.

The commandline you quote works fine for me and a very similar one runs fine in
the qemu testsuite and CI. The former executes mmdebstrap as root in a qemu
virtual machine and the latter directly on the host. Both evidently work fine:

https://ci.debian.net/packages/m/mmdebstrap/

Could you try to reproduce the error inside a minimal chroot? Currently, I'm
not able to reproduce it.

What you tried should indeed 'just work'[tm]. Something is broken.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#923423: texlive-fonts-extra installation hangs

[Vincent Lefevre]

Control: severity -1 important
Control: retitle -1 texlive-fonts-extra installation hangs for 19 minutes

On 2019-02-28 01:06:28 +0100, Vincent Lefevre wrote:
> Package: texlive-fonts-extra
> Version: 2018.20190227-1
> Severity: serious
> 
> Installation of texlive-fonts-extra 2018.20190227-1 hangs.
[...]

It eventually resumed. In the /var/log/dpkg.log file:

[...]
2019-02-28 00:49:41 install texlive-bibtex-extra:all 2018.20190207-1 
2018.20190227-1
2019-02-28 00:49:41 status half-installed texlive-bibtex-extra:all 
2018.20190207-1
2019-02-28 00:50:27 status unpacked texlive-bibtex-extra:all 2018.20190227-1
2019-02-28 00:50:27 install texlive-extra-utils:all 2018.20190207-1 
2018.20190227-1
2019-02-28 00:50:27 status half-installed texlive-extra-utils:all 
2018.20190207-1
2019-02-28 00:50:55 status unpacked texlive-extra-utils:all 2018.20190227-1
2019-02-28 00:50:55 install texlive-font-utils:all 2018.20190207-1 
2018.20190227-1
2019-02-28 00:50:55 status half-installed texlive-font-utils:all 2018.20190207-1
2019-02-28 00:51:00 status unpacked texlive-font-utils:all 2018.20190227-1
2019-02-28 00:51:01 install texlive-fonts-extra:all 2018.20190207-1 
2018.20190227-1
2019-02-28 00:51:01 status half-installed texlive-fonts-extra:all 
2018.20190207-1
2019-02-28 01:10:50 status unpacked texlive-fonts-extra:all 2018.20190227-1
2019-02-28 01:10:50 install texlive-fonts-recommended:all 2018.20190207-1 
2018.20190227-1
2019-02-28 01:10:50 status half-installed texlive-fonts-recommended:all 
2018.20190207-1
2019-02-28 01:11:49 status unpacked texlive-fonts-recommended:all 
2018.20190227-1
[...]

So that's about 19 minutes with almost no CPU/disk/network activity.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#919590: RFS: openliberty/18.0.0.4 [ITP]

[Michael Zhang]

Hi,

>From the last email, changes such as:
"Long description is missing. Short description far exceeds 80 chars.
source/format being "3.0 (native)" is also questionable."

were requested and have been corrected. As for the unacceptable lines in d/rules, we are currently in the midst of changing the build process to include the creation of the binaries (ex. *.jar).

I've also modified my package openliberty:

 * Package name: openliberty
   Version : 19.0.0.1-1ubuntu1
   Upstream Author : https://groups.io/g/openliberty
 * URL : https://openliberty.io/
 * License : EPL-1.0
   Section : java

  It builds those binary packages:

openliberty - Server runtime for Java developers

  To access further information about this package, please visit the following URL:

  https://mentors.debian.net/package/openliberty

  Alternatively, one can download the package with dget using this command:

dget -x https://mentors.debian.net/debian/pool/main/o/openliberty/openliberty_19.0.0.1-1ubuntu1.dsc
  More information about openliberty can be obtained from https://www.example.com.

  Changes since the last upload:

  openliberty (19.0.0.1-1ubuntu1) unstable; urgency=medium

  * Fixed many lintian errors and warnings
  * Added template argument in 'create' script
  * Added java weak dependency
  * Added SystemD service files for instance servers

 -- Michael Zhang   Mon, 25 Feb 2019 22:38:40 +
We are currently looking into the debian policy manuals and lintian errors for more improvements on our package. We also appreciate any more constructive criticism to help us get this package up-to-standard for the Debian repository.Yours Sincerely,

 
  Michael Zhang
   Software Developer Test (WAS Install Team)
 Phone: 1-9054133415
 E-mail: michael.zh...@ibm.com
 

 

Bug#921600: docker.io: use of iptables-legacy is incompatible with nftables-based iptables

[Arnaud Rebillout]

On Thu, 7 Feb 2019 23:42:32 + "brian m. carlson"
 wrote:
>
> Moreover, this package probably needs to conflict with the new iptables
> package, since it cannot usefully work in conjunction with it.

>From what I see, the iptables package provides both iptables-legacy and
iptables-nft. The docker.io packages depends on iptables for
iptables-legacy (but can't work with iptables-nft). So we can't add a
conflict in this case, unless I miss something?

However there's also the nftables packages, and if I understand you
correctly we should add a conflict with nftables?

And then again, that wouldn't help in your situation, as the package ufw
you mention depends on iptables, not on nftables.

  Arnaud

Bug#904111: Susan picked You!!

[Lina Nageb Mohammed Fewella]

From: Lina Nageb Mohammed Fewella
Sent: Thursday, February 28, 2019 4:02 AM
To: i...@mail.com
Subject: Susan picked You!!

Mrs Susan picked you Reply To 
mrssusan...@gmail.com  for more details

Bug#923425: Chase gives incorrect file path

[Nick Taylor]

Package: chase
Version: 0.5.2


When the link is in a different folder than the target file, the
resultant path to the target file given by chase turns out to be incorrect.
Here is a transcript:

In this example, the files are located in the folder 
/media/MyBook/Hostshare/GIFS
The links are located in the folder  /media/MyBook/Hostshare/GIFS

cd /media/MyBook/Hostshare/GIFS/GIFLINKS
/media/MyBook/Hostshare/GIFS/GIFLINKS$ chase achtagDu6Blo
chase: /media/MyBook/Hostshare/GIFS/GIFLINKS/IJa7b9jy.gif: No such file or 
directory

The filename IJa7b9jy.gif does exist in the folder 
/media/MyBook/Hostshare/GIFS, but
not in  /media/MyBook/Hostshare/GIFS/GIFLINKS

I am using Debian GNU/Linux 9.7 (stretch) kernel 4.9.0-8-amd64 and (Debian 
GLIBC 2.24-11+deb9u3) 2.24




 

Bug#923423: texlive-fonts-extra installation hangs

[Norbert Preining]

reassign 923423 dpkg
thanks

On Thu, 28 Feb 2019, Vincent Lefevre wrote:
> It eventually resumed. In the /var/log/dpkg.log file:
> 
> [...]
> 2019-02-28 00:49:41 install texlive-bibtex-extra:all 2018.20190207-1 
> 2018.20190227-1
> 2019-02-28 00:49:41 status half-installed texlive-bibtex-extra:all 
> 2018.20190207-1
> 2019-02-28 00:50:27 status unpacked texlive-bibtex-extra:all 2018.20190227-1

Nothing I can do about it, please ask dpkg maintainers what is going on.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#923417: pspp: CVE-2019-9211

[Ben Pfaff]

On Wed, Feb 27, 2019 at 10:31:58PM +0100, Salvatore Bonaccorso wrote:
> Source: pspp
> Version: 1.2.0-2
> Severity: normal
> Tags: security upstream
> 
> Hi,
> 
> The following vulnerability was published for pspp.
> 
> CVE-2019-9211[0]:
> | There is a reachable assertion abort in the function
> | write_long_string_missing_values() in data/sys-file-writer.c in
> | libdata.a in GNU PSPP 1.2.0 that will lead to denial of service.

I fixed this on PSPP master with commit 0b842a843537 ("sys-file-writer:
Remove assertions based on file position.").

As has become usual, this bug was reported to Debian and Red Hat and
MITRE and never to me, the upstream author.  If you know any way to
de-anonymize whoever is actually finding these bugs, I'd appreciate it.
Whoever it is deserves education.

Bug#923426: pal FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: pal
Version: 0.4.3-8.1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

pal fails to cross build from source, because it does not pass cross
tools to make. The easiest way of fixing that - using dh_auto_build -
does not fix that entirely, because the upstream Makefile hard codes the
build architecture pkg-config. The attached patch makes pal cross
buildable. Please consider applying it.

Helmut
diff -u pal-0.4.3/debian/changelog pal-0.4.3/debian/changelog
--- pal-0.4.3/debian/changelog
+++ pal-0.4.3/debian/changelog
@@ -1,3 +1,12 @@
+pal (0.4.3-8.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ cross.patch: Make pkg-config substitutable.
++ Let dh_auto_build pass cross tools to make.
+
+ -- Helmut Grohne   Wed, 27 Feb 2019 18:57:54 +0100
+
 pal (0.4.3-8.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u pal-0.4.3/debian/patches/series pal-0.4.3/debian/patches/series
--- pal-0.4.3/debian/patches/series
+++ pal-0.4.3/debian/patches/series
@@ -11,0 +12 @@
+cross.patch
diff -u pal-0.4.3/debian/rules pal-0.4.3/debian/rules
--- pal-0.4.3/debian/rules
+++ pal-0.4.3/debian/rules
@@ -24,7 +24,7 @@
 build-arch: build-stamp
 build-stamp: $(QUILT_STAMPFN)
dh_testdir
-   $(MAKE) "CFLAGS=$(CFLAGS)"
+   dh_auto_build -- "CFLAGS=$(CFLAGS)"
touch $@
 
 .PHONY: clean
--- pal-0.4.3.orig/debian/patches/cross.patch
+++ pal-0.4.3/debian/patches/cross.patch
@@ -0,0 +1,24 @@
+--- pal-0.4.3.orig/src/Makefile
 pal-0.4.3/src/Makefile
+@@ -2,9 +2,9 @@
+ 
+ include Makefile.defs
+ 
+-INCLDIR = -I${prefix}/include `pkg-config --cflags glib-2.0`
++INCLDIR = -I${prefix}/include `$(PKG_CONFIG) --cflags glib-2.0`
+ LIBDIR  =
+-LIBS= `pkg-config --libs glib-2.0` -lreadline -lncursesw
++LIBS= `$(PKG_CONFIG) --libs glib-2.0` -lreadline -lncursesw
+ 
+ SRC = main.c colorize.c output.c input.c event.c rl.c html.c latex.c \
+   add.c edit.c del.c remind.c search.c manage.c
+--- pal-0.4.3.orig/src/Makefile.defs
 pal-0.4.3/src/Makefile.defs
+@@ -5,6 +5,7 @@
+ # want to change this to /usr/local
+ prefix = /usr
+ CC  = gcc
++PKG_CONFIG ?= pkg-config
+ 
+ PAL_VERSION = 0.4.3
+ 

Bug#923210: bash-completion: postinst and postrm generate find warnings

[Daniel Lewart]

Gabriel,

> > Both "apt install bash-completion" and "apt purge bash-completion"
> > generate the following warning:
> >   find: '/etc/bash_completion.d/': No such file or directory

> > The cause is that postinst and postrm assume that
> > /etc/bash_completion.d exists.

> Is it safe to upload such a change so close to the freeze?  I'm always
> worried about unforeseen side-effects.

The patch might be easier to understand by ignoring indentation:

diff -br a/debian/postinst b/debian/postinst
6a7
> if [ -d /etc/bash_completion.d ]; then
19a21
> fi
diff -br a/debian/postrm b/debian/postrm
7a8
> if [ -d /etc/bash_completion.d ]; then
11a13
> fi

I think it is safe, but I defer to you.

> ...
> Is this hunk needed?  The test (-d /etc/bash_completion.d/helpers) is
> not likely to produce the warnings you mentioned.

Absolutely.  The warnings come from the following line in both
post{inst,rm}:
for f in $(find /etc/bash_completion.d/ -type f -name "*.dpkg-*");
do

Thank you!
Dam

Bug#923424: Build yafaray with qt5

[Alexey Loginov]

Package: yafaray
Version: yafaray_0.1.2+really0.1.2~beta5-2

There is qt5: https://github.com/YafaRay/Core

Bug#919628: Apply Julia's LLVM patches

[Mo Zhou]

Hi Sylvestre,

Should I file freeze exception requests against llvm-6.0 and julia,
so that we will have some more time to work on this?

On Fri, Feb 22, 2019 at 08:41:14AM +0100, Sylvestre Ledru wrote:
> Hello,
> 
> I started the work ( 
> https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/commit/408f329cd84ad41cef7fc41ee4ac2b4b4573945f
> ) on that but:
> 
> * some patches didn't apply
> 
> * some are breaking the builds
> 
> I will try to finish this week end
> 
> Anyway, this should not prevent you to move back to llvm packages as
> 
> I took this fix  "Fix a baseline violation on armhf (Closes: #914268)"
> 
> Cheers,
> 
> S
> 
> 
> Le 22/02/2019 à 00:55, Mo Zhou a écrit :
> > Hi Sylvestre,
> > 
> > Any chance for getting this into Buster? If there is any, I'd like
> > to apply for freeze exception early, especially for the next Julia
> > LTS release 1.0.4 (likely to come out before 1st March)
> > 
> > On Fri, Feb 08, 2019 at 08:46:06AM +0100, Sylvestre Ledru wrote:
> > > Wahou, better than I was expecting! Many thanks!
> > > 
> > > I will take as much as possible! Thanks
> > > 
> > > S
> > > 
> > > 
> > > Le 08/02/2019 à 07:47, Mo Zhou a écrit :
> > > > Hi Sylvestre,
> > > > 
> > > > Please cherry-pick at least: (8) (12) (13) (14) (15)
> > > > 
> > > > Recommended to include: (1) (2) (4) (5) (11)
> > > > 
> > > > Feel free to ignore: (6) (9) (16) (17)
> > > > 
> > > > I have no idea about: (3) (7) (10)
> > > > 
> > > > https://github.com/JuliaLang/julia/tree/master/deps/patches
> > > > I've listed patches for llvm 6.0.1
> > > > 
> > > > 
> > > > 
> > > > 
> > > > (1) [unwind] llvm-D27629-AArch64-large_model_6.0.1
> > > > 
> > > >   Fix unwind info relocation with large code model on AArch64
> > > >   https://reviews.llvm.org/D27629
> > > > 
> > > > (2) [performance] llvm-D34078-vectorize-fdiv
> > > > 
> > > >   Enable support for floating-point division reductions
> > > >   https://reviews.llvm.org/D34078
> > > > 
> > > > (3) [nvptx] llvm-6.0-NVPTX-addrspaces
> > > > 
> > > >   No idea about this patch.
> > > > 
> > > > (4) [performance regression] llvm-D42262-jumpthreading-not-i1
> > > > 
> > > >   For details see Julia commit: 
> > > > e94a1f8b08e0bc3b8093d8f1dc2bf3c8f5d59519
> > > >   merged upstream: https://reviews.llvm.org/D42262
> > > > 
> > > > (5) [???] llvm-PPC-addrspaces
> > > > 
> > > >   merged upstream: https://reviews.llvm.org/D43781
> > > > 
> > > > (6) [ignore: mingw] llvm-6.0.0_D27296-libssp
> > > >   [ignore: mingw] llvm-6.0-D44650
> > > > 
> > > > (7) [???] llvm-D46460
> > > > 
> > > >   still under review: https://reviews.llvm.org/D46460
> > > > 
> > > > (8) [???] llvm-rL327898
> > > > 
> > > >   
> > > > https://github.com/JuliaLang/julia/blob/master/deps/patches/llvm-rL327898.patch
> > > >   Fixes Julia issues: #27055 #27080 #27032 #27603
> > > > 
> > > > (9) [ignore: compiler complain] llvm-6.0-DISABLE_ABI_CHECKS
> > > > 
> > > > (10) [profiling] llvm-OProfile-line-num
> > > > 
> > > > (11) [profiling] llvm-D44892-Perf-integration
> > > > 
> > > >merged upstream: https://reviews.llvm.org/D44892
> > > > 
> > > > (12) [bug fix] llvm-D49832-SCEVPred
> > > >[bug fix] llvm-rL323946-LSRTy
> > > > 
> > > >   Add LLVM patches for bugs introducing illegal ptrtoint
> > > >   rL323946 [LSR] Don't force bases of foldable formulae to the 
> > > > final type.
> > > >   D49832   [SCEV] Don't expand Wrap predicate using inttoptr in ni 
> > > > addrspaces
> > > > 
> > > > (13) llvm-D50010-VNCoercion-ni
> > > > 
> > > >   Fixes julia issue: #28360 (#28362)
> > > >   https://reviews.llvm.org/D50010
> > > > 
> > > > (14) llvm-D50167-scev-umin
> > > > 
> > > >   Add LLVM patch to explicitly represent umin in SCEV (#28403)
> > > >   Fix mix-type arithmetic detection in umin/max expansion (#28465)
> > > >   Fixes #28464
> > > >   Fixes #28379
> > > >   Fixes #28388
> > > > 
> > > > (15) llvm-rL326967-aligned-load
> > > > 
> > > >   Fixes incorrect codegen: #28726
> > > > 
> > > > (16) [ignore: win64] llvm-D51842-win64-byval-cc
> > > > 
> > > > (17) [...] llvm-D57118-powerpc
> > > > 
> > > >   https://reviews.llvm.org/D57118
> > > > 

Bug#923429: texlive-lang-french: Upgrading the package uninstalls it.

[Nicolas Patrois]

Package: texlive-lang-french
Severity: important

Dear Maintainer,

For some reason, upgrading this package (and some others from texlive)
uninstalls it.



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.17.0-3-686-pae (SMP w/3 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:fr:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages texlive-lang-french depends on:
it  tex-common6.10
ii  texlive-base  2018.20190207-1

texlive-lang-french recommends no packages.

texlive-lang-french suggests no packages.

Bug#923374: root mode doesn't work anymore?

[Johannes Schauer]

Hi Daniel,

after staring at the log output for a while longer, I now have a theory:

Quoting Johannes Schauer (2019-02-28 00:11:42)
> > Get:1 http://deb.debian.org/debian sid InRelease [242 kB]
> > Get:2 http://deb.debian.org/debian sid/main amd64 Packages [8366 kB]
> > Fetched 8608 kB in 2s (4984 kB/s)
> > Reading package lists...
> > W: Download is performed unsandboxed as root as file
> > '/root/sid/var/lib/apt/lists/partial/deb.debian.org_debian_dists_sid_InRelease'
> > couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission
> > denied)
> > apt-get update failed at /usr/bin/mmdebstrap line 569.

You probably have the permissions of /root set up such that it's non-readable
by any non-root user?

This would explain the error message because it would not allow the _apt user
to perform any operation in any subdirectory of /root including your chroot
directory.

Can you confirm that mmdebstrap root mode works if you are putting your chroot
directory somewhere where also non-root users have read permissions?

That would also mean that this is not a new problem but one that always has
existed. You probably not attempted to put the chroot into /root before you
upgraded to version 0.4.0?

You could also test if disabling the apt sandboxing feature fixes the problem
for you by adding the following option to mmdebstrap:

--aptopt='APT::Sandbox::User "root"'

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#923427: mergechanges: Regression: --indep/source mangles/breaks (valid?) Binary fields

[Salvatore Bonaccorso]

Package: devscripts
Version: 2.19.3
Severity: serious
Justification: regression

Hi

Not sure on the severity, but better safe than sorry, please downgrade
as needed or see it fitting better.

I had prepared an upload where I issued mergechanges --indep on the
_amd64.changes to produce a changes to include only source packages
and architecture-independent packages.

$ mergechanges --indep -f linux_4.9.161-1_amd64.changes 
linux_4.9.161-1_amd64.changes 
Error: acpi-modules-4.9.0-9-amd64-di not found in Binary field  
 
b4ae0b22174cb1c7bf009bfcf0deaee8 10304 debian-installer extra 
acpi-modules-4.9.0-9-amd64-di_4.9.161-1_amd64.udeb

This seems related to the change included in the 2.19.3 version, as
the version in stretch creates the _multi.changes correctly.

I'm attaching the original amd64.changes, plus the multi.changes
produced with 2.17.6+deb9u2 and the multi.changes.broken produced with
(2.19.3).

Regards,
Salvatore


linux_4.9.161-1_amd64.changes.xz
Description: application/xz


linux_4.9.161-1_multi.changes.xz
Description: application/xz


linux_4.9.161-1_multi.changes.broken.xz
Description: application/xz

Bug#923428: fastqc fails it's autopkg tests

[Matthias Klose]

Package: src:fastqc
Version: 0.11.8+dfsg-1
Severity: important
Tags: sid buster

fastqc fails it's autopkg tests according to
https://ci.debian.net/data/packages/unstable/amd64/f/fastqc/latest-autopkgtest/log.gz

ailed to process toy.sam
htsjdk.samtools.util.RuntimeIOException: java.io.IOException: Stream closed
at
htsjdk.samtools.SamReaderFactory$SamReaderFactoryImpl.open(SamReaderFactory.java:448)
at uk.ac.babraham.FastQC.Sequence.BAMFile.(BAMFile.java:64)
at
uk.ac.babraham.FastQC.Sequence.SequenceFactory.getSequenceFile(SequenceFactory.java:100)
at
uk.ac.babraham.FastQC.Sequence.SequenceFactory.getSequenceFile(SequenceFactory.java:62)
at 
uk.ac.babraham.FastQC.Analysis.OfflineRunner.processFile(OfflineRunner.java:152)
at 
uk.ac.babraham.FastQC.Analysis.OfflineRunner.(OfflineRunner.java:121)
at 
uk.ac.babraham.FastQC.FastQCApplication.main(FastQCApplication.java:316)
Caused by: java.io.IOException: Stream closed
at 
java.base/java.io.BufferedInputStream.getInIfOpen(BufferedInputStream.java:165)
at 
java.base/java.io.BufferedInputStream.fill(BufferedInputStream.java:252)
at 
java.base/java.io.BufferedInputStream.read1(BufferedInputStream.java:292)
at 
java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:351)
at
htsjdk.samtools.util.BlockCompressedInputStream.readBytes(BlockCompressedInputStream.java:583)
at
htsjdk.samtools.util.BlockCompressedInputStream.isValidFile(BlockCompressedInputStream.java:443)
at htsjdk.samtools.SamStreams.isBAMFile(SamStreams.java:51)
at
htsjdk.samtools.SamReaderFactory$SamReaderFactoryImpl.open(SamReaderFactory.java:374)
... 6 more
autopkgtest [08:36:51]: test run-unit-test: ---]
autopkgtest [08:36:51]: test run-unit-test:  - - - - - - - - - - results - - - -
- - - - - -
run-unit-testFAIL non-zero exit status 1
autopkgtest [08:36:51]:  summary

Bug#923249: [Pkg-libvirt-maintainers] Bug#923249: libvirt0: libvirt sets disable_ipv6 on bridge, entirely breaking internal IPv6 networking

[Guido Günther]

Hi,
On Wed, Feb 27, 2019 at 10:08:24PM +0100, Ralf Jung wrote:
> Btw, I reported this upstream at
> , and made some headway
> debugging things there.

Cool, thanks!
 -- Guido

Bug#915559: bug#34681: mv fails when renaming on external drive in coreutils 8.30-2

[Pádraig Brady]

On 27/02/19 14:20, Derek Dongray wrote:
> When trying to use mv to rename a file on an external drive using coreutils
> 8.30-2 on a debian system (Linux version 4.19.0-3-amd64), the rename fails
> with the error message:
> 
> mv: cannot move 'file1' to a subdirectory of itself 'file2'
> 
> Downgrading to coreutils 8.30-1, the rename executes as expected.
> 
> The following is the result of running a test script. The folder '/backup'
> is an external drive using the ZFS fileystems (zfs-zed 0.7.12-3), but I
> have seen a report on superuser.com (
> https://superuser.com/questions/1409618/renaming-a-file-with-mv-cannot-move-to-a-subdirectory-of-itself)
> that this also happens with NTFS external drives.
> 
> root@capella:~# ./mv-bug
> + apt install -y --allow-downgrades coreutils=8.30-1
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> coreutils is already the newest version (8.30-1).
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> + cd /backup
> + touch t
> + ls s t
> ls: cannot access 's': No such file or directory
> t
> + mv t s
> + ls s t
> ls: cannot access 't': No such file or directory
> s
> + rm s t
> rm: cannot remove 't': No such file or directory
> + cd /root
> + apt install -y coreutils=8.30-2
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following packages will be upgraded:
>   coreutils
> 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> Need to get 2,707 kB of archives.
> After this operation, 4,096 B disk space will be freed.
> Get:1 http://ftp.uk.debian.org/debian sid/main amd64 coreutils amd64 8.30-2
> [2,707 kB]
> Fetched 2,707 kB in 1s (2,729 kB/s)
> apt-listchanges: Reading changelogs...
> (Reading database ... 226704 files and directories currently installed.)
> Preparing to unpack .../coreutils_8.30-2_amd64.deb ...
> Unpacking coreutils (8.30-2) over (8.30-1) ...
> Setting up coreutils (8.30-2) ...
> Processing triggers for install-info (6.5.0.dfsg.1-4+b1) ...
> Processing triggers for man-db (2.8.5-2) ...
> + cd /backup
> + touch t
> + ls s t
> ls: cannot access 's': No such file or directory
> t
> + mv t s
> mv: cannot move 't' to a subdirectory of itself, 's'
> + ls s t
> ls: cannot access 's': No such file or directory
> t
> + rm s t
> rm: cannot remove 's': No such file or directory
> root@capella:~#

That sounds like unsupported renameat2()
is not falling back to rename()

The only change in debian is:
  coreutils (8.30-2) unstable; urgency=medium
* Use renameat glibc function that can be intercepted by fakechroot
  (Closes: https://bugs.debian.org/915559 )
* Above requires autoreconf turned on again

A quick scan of the patches shows that the name was changed
to renameatu() in gnulib, but copy.c still calls renameat2()
and thus now doesn't have the fallback.

To be clear this seems to only be an issue in the debian patch.

cheers,
Pádraig