Bug#879729: pk4-replace discards the build commands output

[Guido Günther]

Package: pk4
Version: 3
Severity: wishlist

Hi,
a "pk4-replace" discards the builds output. To diagnose problems it
would be nice to have stdout/stderr either print to stdout/stderr as
well or at least logged to file.
Cheers
 -- Guido

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages pk4 depends on:
ii  debian-keyring  2017.08.28
ii  devscripts  2.17.10
ii  dpkg-dev1.18.24
ii  libc6   2.24-17
ii  systemd-sysv235-2

Versions of packages pk4 recommends:
ii  sbuild  0.73.0-4

pk4 suggests no packages.

-- no debconf information

Bug#879486: Please support "gbp import-dsc" of the downloaded source

[Guido Günther]

Hi,
On Tue, Oct 24, 2017 at 08:48:57AM +0200, Michael Stapelberg wrote:
> Thanks for confirming! Once a new git-buildpackage is uploaded,
> consider blogging about it to let people know about the new
> integration :)

Yeah, for the moment I at least added a hunk to the docs:


https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.special.pk4.html

If at one point we would be able to able to support incremental imports
by recycling an older version in .cache/pk4/ that would be great (and
make it simple for people to patch software among several releases).

Cheers,
 -- Guido

> 
> On Tue, Oct 24, 2017 at 8:42 AM, Guido Günther <a...@sigxcpu.org> wrote:
> > Hi,
> > On Mon, Oct 23, 2017 at 11:00:03PM +0200, Guido Günther wrote:
> >> Hi,
> >> On Mon, Oct 23, 2017 at 10:00:49PM +0200, Michael Stapelberg wrote:
> >> > control: tags -1 + pending
> >> >
> >> > On Mon, Oct 23, 2017 at 9:38 PM, Guido Günther <a...@sigxcpu.org> wrote:
> >> > > Hi,
> >> > > On Sun, Oct 22, 2017 at 12:42:29PM +0200, Michael Stapelberg wrote:
> >> > >> On Sun, Oct 22, 2017 at 12:28 PM, Guido Günther <a...@sigxcpu.org> 
> >> > >> wrote:
> >> > >> > Hi,
> >> > >> > On Sun, Oct 22, 2017 at 11:15:20AM +0200, Michael Stapelberg wrote:
> >> > >> >> Thanks for filing this.
> >> > >> >>
> >> > >> >> On Sun, Oct 22, 2017 at 9:21 AM, Guido Günther <a...@sigxcpu.org> 
> >> > >> >> wrote:
> >> > >> >> > Package: pk4
> >> > >> >> > Version: 2
> >> > >> >> > Severity: wishlist
> >> > >> >> >
> >> > >> >> > Hi,
> >> > >> >> > it would be nice if pk4 would allow to use "gbp import-dsc" to 
> >> > >> >> > unpack
> >> > >> >> > the donwloaded sources in downloadDSCAndUnpack so users:
> >> > >> >> >
> >> > >> >> >- get a git archive right away
> >> > >> >> >- can reuise their gbp configuration such as the configured 
> >> > >> >> > builder,
> >> > >> >> >- pristine-tar, ... right away
> >> > >> >>
> >> > >> >> I think we could introduce a hook which would replace the default
> >> > >> >> behavior of dpkg-source -x, taking as arguments the path to the DSC
> >> > >> >> and the destination directory.
> >> > >> >
> >> > >> > Sounds good.
> >> > >> >
> >> > >> >>
> >> > >> >> I wonder whether the gbp hook should live in the git-buildpackage
> >> > >> >> Debian package, though? That way, you could maintain it directly. 
> >> > >> >> If
> >> > >> >
> >> > >> > Sure. It would be nice if setup for users would the be as simple as
> >> > >> >
> >> > >> >   ln -s /usr/share/doc/git-buildpackage/examples/pk4 
> >> > >> > ~/pk4/pk4.deb822.d/gbp
> >> > >>
> >> > >> Almost:
> >> > >>
> >> > >> mkdir -p ~/.config/pk4/hooks-enabled/unpack/
> >> > >> ln -s /usr/share/pk4/hooks-available/unpack/gbp \
> >> > >> ~/.config/pk4/hooks-enabled/unpack/
> >> > >>
> >> > >> Regarding the symlink target, could we ship
> >> > >> /usr/share/pk4/hooks-available/unpack/gbp in git-buildpackage? That
> >> > >> way, all hooks would be in the same directory. This is similar to how
> >> > >> shell tab completion files are shipped.
> >> > >
> >> > > Shipped now with the next gbp version:
> >> > >
> >> > > https://github.com/agx/git-buildpackage/blob/master/debian/pk4
> >> >
> >> > Neat!
> >> >
> >> > I just committed
> >> > https://github.com/Debian/pk4/commit/797dc0b887abbc482a7a095d687b710509a80816,
> >> > upload to Debian follows in a second.
> >
> > Just tried it and works like a charm. Thanks a lot!
> >  -- Guido
> >
> >> >
> >> > One thing I noticed: the resulting branches are master, pk4 and
> >> > upstream, which the currently checked out branch being 

Bug#879486: Please support "gbp import-dsc" of the downloaded source

[Guido Günther]

Hi,
On Mon, Oct 23, 2017 at 11:00:03PM +0200, Guido Günther wrote:
> Hi,
> On Mon, Oct 23, 2017 at 10:00:49PM +0200, Michael Stapelberg wrote:
> > control: tags -1 + pending
> > 
> > On Mon, Oct 23, 2017 at 9:38 PM, Guido Günther <a...@sigxcpu.org> wrote:
> > > Hi,
> > > On Sun, Oct 22, 2017 at 12:42:29PM +0200, Michael Stapelberg wrote:
> > >> On Sun, Oct 22, 2017 at 12:28 PM, Guido Günther <a...@sigxcpu.org> wrote:
> > >> > Hi,
> > >> > On Sun, Oct 22, 2017 at 11:15:20AM +0200, Michael Stapelberg wrote:
> > >> >> Thanks for filing this.
> > >> >>
> > >> >> On Sun, Oct 22, 2017 at 9:21 AM, Guido Günther <a...@sigxcpu.org> 
> > >> >> wrote:
> > >> >> > Package: pk4
> > >> >> > Version: 2
> > >> >> > Severity: wishlist
> > >> >> >
> > >> >> > Hi,
> > >> >> > it would be nice if pk4 would allow to use "gbp import-dsc" to 
> > >> >> > unpack
> > >> >> > the donwloaded sources in downloadDSCAndUnpack so users:
> > >> >> >
> > >> >> >- get a git archive right away
> > >> >> >- can reuise their gbp configuration such as the configured 
> > >> >> > builder,
> > >> >> >- pristine-tar, ... right away
> > >> >>
> > >> >> I think we could introduce a hook which would replace the default
> > >> >> behavior of dpkg-source -x, taking as arguments the path to the DSC
> > >> >> and the destination directory.
> > >> >
> > >> > Sounds good.
> > >> >
> > >> >>
> > >> >> I wonder whether the gbp hook should live in the git-buildpackage
> > >> >> Debian package, though? That way, you could maintain it directly. If
> > >> >
> > >> > Sure. It would be nice if setup for users would the be as simple as
> > >> >
> > >> >   ln -s /usr/share/doc/git-buildpackage/examples/pk4 
> > >> > ~/pk4/pk4.deb822.d/gbp
> > >>
> > >> Almost:
> > >>
> > >> mkdir -p ~/.config/pk4/hooks-enabled/unpack/
> > >> ln -s /usr/share/pk4/hooks-available/unpack/gbp \
> > >> ~/.config/pk4/hooks-enabled/unpack/
> > >>
> > >> Regarding the symlink target, could we ship
> > >> /usr/share/pk4/hooks-available/unpack/gbp in git-buildpackage? That
> > >> way, all hooks would be in the same directory. This is similar to how
> > >> shell tab completion files are shipped.
> > >
> > > Shipped now with the next gbp version:
> > >
> > > https://github.com/agx/git-buildpackage/blob/master/debian/pk4
> > 
> > Neat!
> > 
> > I just committed
> > https://github.com/Debian/pk4/commit/797dc0b887abbc482a7a095d687b710509a80816,
> > upload to Debian follows in a second.

Just tried it and works like a charm. Thanks a lot!
 -- Guido

> > 
> > One thing I noticed: the resulting branches are master, pk4 and
> > upstream, which the currently checked out branch being master.
> > Shouldn’t the only two branches be pk4 and upstream?
> 
> Yes, that's:
> 
> 
> https://github.com/agx/git-buildpackage/commit/01da1e61b003aa7cb576fbe5755a665a12c3f2ba
> 
> which I should have fixed long ago.
> Cheers,
>  -- Guido
> 
> > 
> > >
> > >> >> you think that’s not a good idea, could you suggest how the hook
> > >> >> should be implemented? I’m envisioning something like this (untested):
> > >> >>
> > >> >> #!/bin/sh
> > >> >> set -e
> > >> >> mkdir -p "$2"
> > >> >> cd "$2"
> > >> >> git init
> > >> >> gbp import-dsc "$1"
> > >> >
> > >> > #!/bin/sh
> > >> > set -e
> > >> > gbp import-dsc "$1" "$2"
> > >> >
> > >> > is enough (gbp will do the rest). That way we could also support
> > >> > incremental imports (that is if the directory is already there we 
> > >> > simply
> > >> > import the new version on top of it so the use can diff between the old
> > >> > an new version.
> > >>
> > >> Note that the pk4 output directories contain the version 

Bug#879486: Please support "gbp import-dsc" of the downloaded source

[Guido Günther]

Hi,
On Mon, Oct 23, 2017 at 10:00:49PM +0200, Michael Stapelberg wrote:
> control: tags -1 + pending
> 
> On Mon, Oct 23, 2017 at 9:38 PM, Guido Günther <a...@sigxcpu.org> wrote:
> > Hi,
> > On Sun, Oct 22, 2017 at 12:42:29PM +0200, Michael Stapelberg wrote:
> >> On Sun, Oct 22, 2017 at 12:28 PM, Guido Günther <a...@sigxcpu.org> wrote:
> >> > Hi,
> >> > On Sun, Oct 22, 2017 at 11:15:20AM +0200, Michael Stapelberg wrote:
> >> >> Thanks for filing this.
> >> >>
> >> >> On Sun, Oct 22, 2017 at 9:21 AM, Guido Günther <a...@sigxcpu.org> wrote:
> >> >> > Package: pk4
> >> >> > Version: 2
> >> >> > Severity: wishlist
> >> >> >
> >> >> > Hi,
> >> >> > it would be nice if pk4 would allow to use "gbp import-dsc" to unpack
> >> >> > the donwloaded sources in downloadDSCAndUnpack so users:
> >> >> >
> >> >> >- get a git archive right away
> >> >> >- can reuise their gbp configuration such as the configured 
> >> >> > builder,
> >> >> >- pristine-tar, ... right away
> >> >>
> >> >> I think we could introduce a hook which would replace the default
> >> >> behavior of dpkg-source -x, taking as arguments the path to the DSC
> >> >> and the destination directory.
> >> >
> >> > Sounds good.
> >> >
> >> >>
> >> >> I wonder whether the gbp hook should live in the git-buildpackage
> >> >> Debian package, though? That way, you could maintain it directly. If
> >> >
> >> > Sure. It would be nice if setup for users would the be as simple as
> >> >
> >> >   ln -s /usr/share/doc/git-buildpackage/examples/pk4 
> >> > ~/pk4/pk4.deb822.d/gbp
> >>
> >> Almost:
> >>
> >> mkdir -p ~/.config/pk4/hooks-enabled/unpack/
> >> ln -s /usr/share/pk4/hooks-available/unpack/gbp \
> >> ~/.config/pk4/hooks-enabled/unpack/
> >>
> >> Regarding the symlink target, could we ship
> >> /usr/share/pk4/hooks-available/unpack/gbp in git-buildpackage? That
> >> way, all hooks would be in the same directory. This is similar to how
> >> shell tab completion files are shipped.
> >
> > Shipped now with the next gbp version:
> >
> > https://github.com/agx/git-buildpackage/blob/master/debian/pk4
> 
> Neat!
> 
> I just committed
> https://github.com/Debian/pk4/commit/797dc0b887abbc482a7a095d687b710509a80816,
> upload to Debian follows in a second.
> 
> One thing I noticed: the resulting branches are master, pk4 and
> upstream, which the currently checked out branch being master.
> Shouldn’t the only two branches be pk4 and upstream?

Yes, that's:


https://github.com/agx/git-buildpackage/commit/01da1e61b003aa7cb576fbe5755a665a12c3f2ba

which I should have fixed long ago.
Cheers,
 -- Guido

> 
> >
> >> >> you think that’s not a good idea, could you suggest how the hook
> >> >> should be implemented? I’m envisioning something like this (untested):
> >> >>
> >> >> #!/bin/sh
> >> >> set -e
> >> >> mkdir -p "$2"
> >> >> cd "$2"
> >> >> git init
> >> >> gbp import-dsc "$1"
> >> >
> >> > #!/bin/sh
> >> > set -e
> >> > gbp import-dsc "$1" "$2"
> >> >
> >> > is enough (gbp will do the rest). That way we could also support
> >> > incremental imports (that is if the directory is already there we simply
> >> > import the new version on top of it so the use can diff between the old
> >> > an new version.
> >>
> >> Note that the pk4 output directories contain the version number, so I
> >> think incremental imports wouldn’t work well.
> >>
> >> >
> >> >> Side note: I think we should be fairly clear about the difference
> >> >> between a gbp-from-dsc repo and a gbp-from-gbp-clone repo, to not
> >> >> confuse our users.
> >> >
> >> > Yeah. I was thinking of putting a .git/gbp.conf into the repo that sets
> >> >
> >> >   [DEFAULT]
> >> >   upstream-branch = upstream
> >> >   debian-branch = pk4
> >> >
> >> > This would
> >> >
> >> >  - make sure we override settings any

Bug#879486: Please support "gbp import-dsc" of the downloaded source

[Guido Günther]

Hi,
On Sun, Oct 22, 2017 at 12:42:29PM +0200, Michael Stapelberg wrote:
> On Sun, Oct 22, 2017 at 12:28 PM, Guido Günther <a...@sigxcpu.org> wrote:
> > Hi,
> > On Sun, Oct 22, 2017 at 11:15:20AM +0200, Michael Stapelberg wrote:
> >> Thanks for filing this.
> >>
> >> On Sun, Oct 22, 2017 at 9:21 AM, Guido Günther <a...@sigxcpu.org> wrote:
> >> > Package: pk4
> >> > Version: 2
> >> > Severity: wishlist
> >> >
> >> > Hi,
> >> > it would be nice if pk4 would allow to use "gbp import-dsc" to unpack
> >> > the donwloaded sources in downloadDSCAndUnpack so users:
> >> >
> >> >- get a git archive right away
> >> >- can reuise their gbp configuration such as the configured builder,
> >> >- pristine-tar, ... right away
> >>
> >> I think we could introduce a hook which would replace the default
> >> behavior of dpkg-source -x, taking as arguments the path to the DSC
> >> and the destination directory.
> >
> > Sounds good.
> >
> >>
> >> I wonder whether the gbp hook should live in the git-buildpackage
> >> Debian package, though? That way, you could maintain it directly. If
> >
> > Sure. It would be nice if setup for users would the be as simple as
> >
> >   ln -s /usr/share/doc/git-buildpackage/examples/pk4 ~/pk4/pk4.deb822.d/gbp
> 
> Almost:
> 
> mkdir -p ~/.config/pk4/hooks-enabled/unpack/
> ln -s /usr/share/pk4/hooks-available/unpack/gbp \
> ~/.config/pk4/hooks-enabled/unpack/
> 
> Regarding the symlink target, could we ship
> /usr/share/pk4/hooks-available/unpack/gbp in git-buildpackage? That
> way, all hooks would be in the same directory. This is similar to how
> shell tab completion files are shipped.

Shipped now with the next gbp version:

https://github.com/agx/git-buildpackage/blob/master/debian/pk4

> >> you think that’s not a good idea, could you suggest how the hook
> >> should be implemented? I’m envisioning something like this (untested):
> >>
> >> #!/bin/sh
> >> set -e
> >> mkdir -p "$2"
> >> cd "$2"
> >> git init
> >> gbp import-dsc "$1"
> >
> > #!/bin/sh
> > set -e
> > gbp import-dsc "$1" "$2"
> >
> > is enough (gbp will do the rest). That way we could also support
> > incremental imports (that is if the directory is already there we simply
> > import the new version on top of it so the use can diff between the old
> > an new version.
> 
> Note that the pk4 output directories contain the version number, so I
> think incremental imports wouldn’t work well.
> 
> >
> >> Side note: I think we should be fairly clear about the difference
> >> between a gbp-from-dsc repo and a gbp-from-gbp-clone repo, to not
> >> confuse our users.
> >
> > Yeah. I was thinking of putting a .git/gbp.conf into the repo that sets
> >
> >   [DEFAULT]
> >   upstream-branch = upstream
> >   debian-branch = pk4
> >
> > This would
> >
> >  - make sure we override settings any branch settings in debian/gbp.conf
> >which we don't care about (since we're not cloning from Vcs-Git:
> >  - Having the default branch named pk4 would make it obvious that this
> >is s.th. special.
> >
> > What do you think? In this case it would rather be more like your script
> > above:
> 
> Sounds good to me.
> 
> >
> > #!/bin/sh
> > set -e
> >
> > if [ ! -d $2 ]; then
> 
> nit: use "$2" here as well
> 
> >
> >   git init "$2"
> >
> >   cat < "$2"/.git/gbp.conf
> 
> I suggest to add as a comment what you wrote above for the benefit of
> readers of the hook :).
> 
> >   [DEFAULT]
> >   upstream-branch = upstream
> >   debian-branch = pk4
> >   EOF
> > fi
> >
> > cd "$2"
> > gbp import-dsc "$1"
> >
> >
> > Does this sound reasonable? I would then also provide a script that can
> > be used with pk4-replace.
> 
> I don’t quite follow. What sort of script is required for that?

Probably not even a script but a post-build hook that cats the name of
the generated changes file to /proc/self/fd/3.
Cheers,
 -- Guido

Bug#750962: [git-buildpackage/master] import-dsc: make sure we don't create 'master' if not needed

[Guido Günther]

tag 750962 pending
thanks

Date:   Mon Oct 23 21:18:18 2017 +0200
Author: Guido Günther 
Commit ID: 01da1e61b003aa7cb576fbe5755a665a12c3f2ba
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=01da1e61b003aa7cb576fbe5755a665a12c3f2ba
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=01da1e61b003aa7cb576fbe5755a665a12c3f2ba

import-dsc: make sure we don't create 'master' if not needed

This way we only get the debian- and upstream-branch in empty repos and
not a pointless 'master' if debian-branch is not set to master.

It also makes sure we don't need --create-missing-branches on empty
repos where it is pointless.

Closes: #750962

  

Bug#878203: AA breaks libvirt when running with kernel 4.13

[Guido Günther]

control: severity -1 minor
control: retitle -1 apparmor logs /proc//cmdline denials on vm shutdown

Hi,
On Mon, Oct 23, 2017 at 06:41:04PM +0200, Michael Biebl wrote:
> Am 23.10.2017 um 18:28 schrieb Guido Günther:
> > Hi,
> > On Mon, Oct 23, 2017 at 06:22:10PM +0200, Michael Biebl wrote:
> >> Am 23.10.2017 um 17:49 schrieb Guido Günther:
> 
> >> This is what I get when I *shut down* a VM in virt-manager:
> >> $ journalctl -f | grep DENIED
> >> Okt 23 18:20:31 pluto audit[8603]: AVC apparmor="DENIED"
> >> operation="open" profile="libvirt-4e5a8920-a2a1-4c6b-b7f1-528c20878cdd"
> >> name="/proc/718/cmdline" pid=8603 comm="qemu-system-x86"
> >> requested_mask="r" denied_mask="r" fsuid=114 ouid=0
> >> Okt 23 18:20:31 pluto kernel: audit: type=1400 audit(1508775631.299:55):
> >> apparmor="DENIED" operation="open"
> >> profile="libvirt-4e5a8920-a2a1-4c6b-b7f1-528c20878cdd"
> >> name="/proc/718/cmdline" pid=8603 comm="qemu-system-x86"
> >> requested_mask="r" denied_mask="r" fsuid=114 ouid=0
> > 
> > I can produce this msg on shutdown (I assumed it to be on VM start) but
> > what does break?
> 
> No idea. I don't see any immediate breakage related to those denials.

Ahh...I didn't see your comment in

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878203#25

and intrigeri's

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878203#30

and the bug title sounded alarming. It's harmless but should be fixed
though.

Cheers,
 -- Guido

Bug#878203: AA breaks libvirt when running with kernel 4.13

[Guido Günther]

Hi,
On Mon, Oct 23, 2017 at 06:22:10PM +0200, Michael Biebl wrote:
> Am 23.10.2017 um 17:49 schrieb Guido Günther:
> 
> > I can't reproduce this here with 4.13.0-1-amd64 and
> > libvirt-daemon-system 3.8.0-3.
> >  -- Guido
> > 
> linux-image-4.13.0-1-amd64 4.13.4-2
> libvirt-daemon-system 3.8.0-3
> 
> This is what I get when I *shut down* a VM in virt-manager:
> $ journalctl -f | grep DENIED
> Okt 23 18:20:31 pluto audit[8603]: AVC apparmor="DENIED"
> operation="open" profile="libvirt-4e5a8920-a2a1-4c6b-b7f1-528c20878cdd"
> name="/proc/718/cmdline" pid=8603 comm="qemu-system-x86"
> requested_mask="r" denied_mask="r" fsuid=114 ouid=0
> Okt 23 18:20:31 pluto kernel: audit: type=1400 audit(1508775631.299:55):
> apparmor="DENIED" operation="open"
> profile="libvirt-4e5a8920-a2a1-4c6b-b7f1-528c20878cdd"
> name="/proc/718/cmdline" pid=8603 comm="qemu-system-x86"
> requested_mask="r" denied_mask="r" fsuid=114 ouid=0

I can produce this msg on shutdown (I assumed it to be on VM start) but
what does break?
 -- Guido

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

Bug#878203: AA breaks libvirt when running with kernel 4.13

[Guido Günther]

Hi,
On Wed, Oct 11, 2017 at 02:10:01AM +0200, Michael Biebl wrote:
> Package: apparmor
> Version: 2.11.0-11
> Severity: serious
> 
> After the kernel upgrade from 4.12 to 4.13 my KVM/libvirt instances
> failed to start:
> Okt 10 19:24:44 pluto libvirtd[673]: 2017-10-10 17:24:44.404+: 797: error 
> : virProcessRunInMountNamespace:1159 : internal error: child reported: Kernel 
> does not provide mount namespace: Permission denied
> 
> Disabling AppArmor made libvirt work again.
> There seems to be an incompatibility between the 4.13 kernel and
> AppArmor. Please reassign if you think this is a bug in the kernel.
> 
> I've decided to mark this as RC, as breaking KVM is a rather severe
> regression which needs to be fixed for buster.
> 
> A quick internet search turns up
> https://forums.opensuse.org/showthread.php/527394-KVM-guest-will-not-start-with-latest-version-of-kernel
> and following that
> https://www.redhat.com/archives/libvir-list/2017-September/msg00546.html

I can't reproduce this here with 4.13.0-1-amd64 and
libvirt-daemon-system 3.8.0-3.
 -- Guido

Bug#879486: Please support "gbp import-dsc" of the downloaded source

[Guido Günther]

Hi,
On Sun, Oct 22, 2017 at 11:15:20AM +0200, Michael Stapelberg wrote:
> Thanks for filing this.
> 
> On Sun, Oct 22, 2017 at 9:21 AM, Guido Günther <a...@sigxcpu.org> wrote:
> > Package: pk4
> > Version: 2
> > Severity: wishlist
> >
> > Hi,
> > it would be nice if pk4 would allow to use "gbp import-dsc" to unpack
> > the donwloaded sources in downloadDSCAndUnpack so users:
> >
> >- get a git archive right away
> >- can reuise their gbp configuration such as the configured builder,
> >- pristine-tar, ... right away
> 
> I think we could introduce a hook which would replace the default
> behavior of dpkg-source -x, taking as arguments the path to the DSC
> and the destination directory.

Sounds good.

> 
> I wonder whether the gbp hook should live in the git-buildpackage
> Debian package, though? That way, you could maintain it directly. If

Sure. It would be nice if setup for users would the be as simple as

  ln -s /usr/share/doc/git-buildpackage/examples/pk4 ~/pk4/pk4.deb822.d/gbp

> you think that’s not a good idea, could you suggest how the hook
> should be implemented? I’m envisioning something like this (untested):
> 
> #!/bin/sh
> set -e
> mkdir -p "$2"
> cd "$2"
> git init
> gbp import-dsc "$1"

#!/bin/sh
set -e
gbp import-dsc "$1" "$2"

is enough (gbp will do the rest). That way we could also support
incremental imports (that is if the directory is already there we simply
import the new version on top of it so the use can diff between the old
an new version.

> Side note: I think we should be fairly clear about the difference
> between a gbp-from-dsc repo and a gbp-from-gbp-clone repo, to not
> confuse our users.

Yeah. I was thinking of putting a .git/gbp.conf into the repo that sets

  [DEFAULT]
  upstream-branch = upstream
  debian-branch = pk4

This would

 - make sure we override settings any branch settings in debian/gbp.conf
   which we don't care about (since we're not cloning from Vcs-Git:
 - Having the default branch named pk4 would make it obvious that this
   is s.th. special.

What do you think? In this case it would rather be more like your script
above:

#!/bin/sh
set -e

if [ ! -d $2 ]; then

  git init "$2"

  cat < "$2"/.git/gbp.conf
  [DEFAULT]
  upstream-branch = upstream
  debian-branch = pk4
  EOF
fi

cd "$2"
gbp import-dsc "$1"


Does this sound reasonable? I would then also provide a script that can
be used with pk4-replace.

Cheers,
 -- Guido

> 
> >
> > Cheers,
> >  -- Guido
> >
> > -- System Information:
> > Debian Release: buster/sid
> >   APT prefers testing
> >   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
> > 'testing-debug'), (500, 'stable-updates'), (500, 'oldoldstable'), (500, 
> > 'unstable'), (500, 'stable'), (1, 'experimental')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
> > LANGUAGE=en_US:en (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> 
> 
> 
> -- 
> Best regards,
> Michael
> 

Bug#879486: Please support "gbp import-dsc" of the downloaded source

[Guido Günther]

Package: pk4
Version: 2
Severity: wishlist

Hi,
it would be nice if pk4 would allow to use "gbp import-dsc" to unpack
the donwloaded sources in downloadDSCAndUnpack so users:

   - get a git archive right away
   - can reuise their gbp configuration such as the configured builder,
   - pristine-tar, ... right away

Cheers,
 -- Guido

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#872864: Checkout upstream signatures as well when using pristine-tar

[Guido Günther]

Hi,
On Fri, Oct 20, 2017 at 02:35:28PM +0100, Chris Lamb wrote:
> Hi Guido,
> 
> > No problem; I personally hadn't seen the blocking pristine-tar issue
> > had been uploaded until now so I thought it might have passed you by
> > too. :)
> 
> Gentle ping on this? Seems like the only piece of the puzzle missing!

Got sidetracked by real life and other gbp bugs like the removal of SGML
support which made it FTBFS. So needed to get 0.9.0 into unstable first
but some of the recent changes in 0.9.0  will help the cause. With this
out of the door I Hope to find another hour to work on this during the
next days.
Cheers,
 -- Guido


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

Bug#761166: [git-buildpackage/master] pq: import pq branch on switch

[Guido Günther]

tag 761166 pending
thanks

Date:   Fri Oct 20 11:29:14 2017 +0200
Author: Guido Günther 
Commit ID: 15510515a5fa98d212082057effb6b002310125e
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=15510515a5fa98d212082057effb6b002310125e
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=15510515a5fa98d212082057effb6b002310125e

pq: import pq branch on switch

Closes: #761166

  

Bug#876800: [git-buildpackage/master] pq: import patches before rebase

[Guido Günther]

tag 876800 pending
thanks

Date:   Wed Oct 18 09:24:18 2017 +0200
Author: Guido Günther 
Commit ID: 680784b0dd2a431392eea653a52c0fb9298d7b88
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=680784b0dd2a431392eea653a52c0fb9298d7b88
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=680784b0dd2a431392eea653a52c0fb9298d7b88

pq: import patches before rebase

if the pq branch doesn't exist yet.

Closes: #876800

  

Bug#877322: git-buildpackage autoremoval

[Guido Günther]

Hi,
On Tue, Oct 17, 2017 at 10:27:03PM +0100, Ian Jackson wrote:
> Guido Günther writes ("Re: Bug#877322: git-buildpackage autoremoval"):
> > On Tue, Oct 17, 2017 at 02:57:33PM +0100, Ian Jackson wrote:
> > > This bug means that the autoremoval robot wants to remove
> > > git-buildpackage.  I'm getting mails about it planning to remove dgit,
> > > to clear the way.
> > > 
> > > Do you intend to upload the docs change to sid soon ?
> > 
> > Yes, before the autoremoval for sure. Sorry for being a pain here but I
> > wanted to give gbp as much exposure as possible in experimental.
> 
> OK, fine.  Thanks for the reassurance.  If the deadline gets closer I
> may ping you again :-).

Sure. I have 1 more bug to go that affects 0.9.x but not 0.8.x that I
want to get done before moving to sid.
Cheers,
 -- Guido

Bug#877322: git-buildpackage autoremoval

[Guido Günther]

Hi Ian,
On Tue, Oct 17, 2017 at 02:57:33PM +0100, Ian Jackson wrote:
> This bug means that the autoremoval robot wants to remove
> git-buildpackage.  I'm getting mails about it planning to remove dgit,
> to clear the way.
> 
> Do you intend to upload the docs change to sid soon ?

Yes, before the autoremoval for sure. Sorry for being a pain here but I
wanted to give gbp as much exposure as possible in experimental.
Cheers,
  -- Guido

> 
> Regards,
> Ian.
> 
> -- 
> Ian Jackson    These opinions are my own.
> 
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
> 

Bug#878812: [pkg-gnupg-maint] Bug#878812: hits bug_at when encrypting to 1A6F3E639A4467E8C3476525DF6D76C44D696F6B

[Guido Günther]

Hi Niibe,
On Tue, Oct 17, 2017 at 12:50:37PM +0900, NIIBE Yutaka wrote:
> Guido Günther <a...@sigxcpu.org> wrote:
> >> > #4  0x556a0f29306f bug_at (gpg)
> >> > #5  0x556a0f243c1e do_we_trust (gpg)
> >> > #6  0x556a0f243fff find_and_check_key (gpg)
> >> > #7  0x556a0f2455b6 find_and_check_key (gpg)
> >> > #8  0x556a0f24b6c2 encrypt_crypt (gpg)
> >> > #9  0x556a0f203563 main (gpg)
> >> > #10 0x7fd58eee12e1 __libc_start_main (libc.so.6)
> >> > #11 0x556a0f2054da _start (gpg)
> [...]
> > I can trivially reproduce this without having mutt involved like:
> >
> > $ gpg  --encrypt --armor --always-trust -r 
> > 1A6F3E639A4467E8C3476525DF6D76C44D696F6B
> > gpg: O j: ... this is a bug (../../g10/pkclist.c:417:do_we_trust)
> > Aborted (core dumped)
> >
> > Where the above key is from the debian-keyring package.
> 
> Could you please try with --debug=8192 option (debug for key lookup)?
> 
> Here, I cannot replicate with Debian's gnupg 2.2.1-2. 
> 
> When key search, it failed as expired, and it didn't go the code path to
> do_we_trust.
> 
> 
> $ /usr/bin/gpg --debug=8192 --encrypt --armor --always-trust -r 
> 1A6F3E639A4467E8C3476525DF6D76C44D696F6B
> gpg: enabled debug flags: lookup
> gpg: DBG: keydb_search: 1 search descriptions:
> gpg: DBG: keydb_search   0: FPR20: '1A6F 3E63 9A44 67E8 C347  6525 DF6D 76C4 
> 4D69 6F6B'
> gpg: DBG: keydb_search: searching keybox (resource 0 of 1)
> gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success
> gpg: DBG: finish_lookup: checking key 4D696F6B (all)(req_usage=2)
> gpg: DBG: checking subkey ED764C3A
> gpg: DBG: subkey has expired
> gpg: DBG: checking subkey 217028C2
> gpg: DBG: usage does not match: want=2 have=1
> gpg: DBG: no suitable subkeys found - trying primary
> gpg: DBG: primary key usage does not match: want=2 have=5
> gpg: DBG: no suitable key found -  giving up
> gpg: DBG: keydb_search: 1 search descriptions:
> gpg: DBG: keydb_search   0: FPR20: '1A6F 3E63 9A44 67E8 C347  6525 DF6D 76C4 
> 4D69 6F6B'
> gpg: DBG: keydb_search: searching keybox (resource 0 of 1)
> gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => EOF
> gpg: 1A6F3E639A4467E8C3476525DF6D76C44D696F6B: skipped: Unusable public key
> gpg: [stdin]: encryption failed: Unusable public key
> gpg: secmem usage: 0/65536 bytes in 0 blocks
> $
> 

Debug log attached.
Cheers,
 -- Guido
gpg: reading options from '/home/agx/.gnupg.laptop/gpg.conf'
gpg: enabled debug flags: lookup
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: LONG_KID: '0A6F5640ADE263B0'
gpg: DBG: keydb_search: searching keyring (resource 0 of 2)
gpg: DBG: keyring_search: need_uid = 0; need_words = 0; need_keyid = 1; 
need_fpr = 0; any_skip = 0
gpg: DBG: keyring_search: initializing offset table. (need_keyid: 1 => 1)
gpg: DBG: keyring_search: searching from start of resource.
gpg: DBG: keyring_search: packet starting at offset 905631 matched descriptor 0
gpg: DBG: keyring_search: returning success
gpg: DBG: keydb_search: searched keyring (resource 0 of 2) => Success
gpg: DBG: finish_lookup: checking key 8C8DDBD2 (one)(req_usage=2)
gpg: DBG:   checking subkey ADE263B0
gpg: DBG:   subkey might be fine
gpg: DBG:   using key ADE263B0
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: LONG_KID: '582CB5D4BD9B5F48'
gpg: DBG: keydb_search: searching keyring (resource 0 of 2)
gpg: DBG: keyring_search: need_uid = 0; need_words = 0; need_keyid = 1; 
need_fpr = 0; any_skip = 0
gpg: DBG: keyring_search: initializing offset table. (need_keyid: 1 => 1)
gpg: DBG: keyring_search: searching from start of resource.
gpg: DBG: keyring_search: packet starting at offset 15866521 matched descriptor 0
gpg: DBG: keyring_search: returning success
gpg: DBG: keydb_search: searched keyring (resource 0 of 2) => Success
gpg: DBG: finish_lookup: checking key 584122D3 (one)(req_usage=2)
gpg: DBG:   checking subkey BD9B5F48
gpg: DBG:   subkey might be fine
gpg: DBG:   using key BD9B5F48
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: LONG_KID: 'CF5E40F944572038'
gpg: DBG: keydb_search: searching keyring (resource 0 of 2)
gpg: DBG: keyring_search: need_uid = 0; need_words = 0; need_keyid = 1; 
need_fpr = 0; any_skip = 0
gpg: DBG: keyring_search: initializing offset table. (need_keyid: 1 => 1)
gpg: DBG: keyring_search: searching from start of resource.
gpg: DBG: keyring_search: packet starting at offset 15863739 matched descriptor 0
gpg: DBG: keyr

Bug#878812: hits bug_at when encrypting to 1A6F3E639A4467E8C3476525DF6D76C44D696F6B

[Guido Günther]

Hi,
On Mon, Oct 16, 2017 at 10:35:15PM +0200, Guido Günther wrote:
> Hi,
> On Mon, Oct 16, 2017 at 10:02:09PM +0200, Guido Günther wrote:
> > Package: gnupg
> > Version: 2.2.1-2
> > Severity: normal
> > 
> > Encrypting to 1A6F3E639A4467E8C3476525DF6D76C44D696F6B makes GPG here
> > segfault like:
> > 
> > $ coredumpctl dump
> >PID: 21438 (gpg)
> >UID: 1000 (agx)
> >GID: 1000 (agx)
> > Signal: 6 (ABRT)
> >  Timestamp: Mon 2017-10-16 21:57:08 CEST (36s ago)
> >   Command Line: gpg --enable-special-filenames --batch --no-sk-comments 
> > --lc-messages en_US.UTF-8 --lc-ctype de_DE.UTF-8 --status-fd 5 --no-tty 
> > --charset utf8 --enable-progress-filter --exit-on-status-write-error 
> > --display :0 --ttyname /dev/pts/5 --ttytype xterm-256color --encrypt 
> > --armor --always-trust -r 1A6F3E639A4467E8C3476525DF6D76C44D696F6B -r 
> > 0DB3932762F78E592F6522AFBB5A2C77584122D3 -r 
> > 0DB3932762F78E592F6522AFBB5A2C77584122D3 --output - -- -&8
> > Executable: /usr/bin/gpg
> >  Control Group: 
> > /user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service
> >   Unit: user@1000.service
> >  User Unit: gnome-terminal-server.service
> >  Slice: user-1000.slice
> >  Owner UID: 1000 (agx)
> >Boot ID: 4ef1bf5cd7da4bfcb061d19089fe468e
> > Machine ID: 15e9777086166538c724eaba52d14fa1
> >   Hostname: bogon
> >Storage: 
> > /var/lib/systemd/coredump/core.gpg.1000.4ef1bf5cd7da4bfcb061d19089fe468e.21438.150818382800.lz4
> >Message: Process 21438 (gpg) of user 1000 dumped core.
> > 
> > Stack trace of thread 21438:
> > #0  0x7fd58eef3fff __GI_raise (libc.so.6)
> > #1  0x7fd58eef542a __GI_abort (libc.so.6)
> > #2  0x556a0f291f09 do_logv (gpg)
> > #3  0x556a0f29290d log_log (gpg)
> > #4  0x556a0f29306f bug_at (gpg)
> > #5  0x556a0f243c1e do_we_trust (gpg)
> > #6  0x556a0f243fff find_and_check_key (gpg)
> > #7  0x556a0f2455b6 find_and_check_key (gpg)
> > #8  0x556a0f24b6c2 encrypt_crypt (gpg)
> > #9  0x556a0f203563 main (gpg)
> > #10 0x7fd58eee12e1 __libc_start_main (libc.so.6)
> > #11 0x556a0f2054da _start (gpg)
> 
> 
> And here's the backtrace from gdb:
> 
> (gdb) bt
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> #1  0x7fd58eef542a in __GI_abort () at abort.c:89
> #2  0x556a0f291f09 in do_logv (level=6, ignore_arg_ptr=, 
> extrastring=0x0, prefmt=, fmt=, 
> arg_ptr=0x7ffc0d74f950) at ../../common/logging.c:859
> #3  0x556a0f29290d in log_log (level=level@entry=6, 
> fmt=fmt@entry=0x556a0f2c72c3 "... this is a bug (%s:%d:%s)\n") at 
> ../../common/logging.c:872
> #4  0x556a0f29306f in bug_at (file=file@entry=0x556a0f2b7a42 
> "../../g10/pkclist.c", line=line@entry=417, func=func@entry=0x556a0f2b87f0 
> <__FUNCTION__.10242> "do_we_trust") at ../../common/logging.c:1074
> #5  0x556a0f243c1e in do_we_trust (trustlevel=, pk=0x1) at 
> ../../g10/pkclist.c:417
> #6  do_we_trust_pre (ctrl=ctrl@entry=0x556a108e0ce0, 
> pk=pk@entry=0x556a108ffbe0, trustlevel=) at 
> ../../g10/pkclist.c:474
> #7  0x556a0f243fff in find_and_check_key (ctrl=ctrl@entry=0x556a108e0ce0, 
> name=name@entry=0x556a108df95c "1A6F3E639A4467E8C3476525DF6D76C44D696F6B", 
> use=use@entry=2, mark_hidden=0, from_file=0, 
> pk_list_addr=pk_list_addr@entry=0x7ffc0d74fb20) at ../../g10/pkclist.c:885
> #8  0x556a0f2455b6 in find_and_check_key (pk_list_addr=0x7ffc0d74fb20, 
> from_file=, mark_hidden=, use=2, 
> name=0x556a108df95c "1A6F3E639A4467E8C3476525DF6D76C44D696F6B", 
> ctrl=0x556a108e0ce0) at ../../g10/pkclist.c:1301
> #9  build_pk_list (ctrl=ctrl@entry=0x556a108e0ce0, 
> rcpts=rcpts@entry=0x556a108df9d0, 
> ret_pk_list=ret_pk_list@entry=0x7ffc0d74fc18) at ../../g10/pkclist.c:1301
> #10 0x556a0f24b6c2 in encrypt_crypt (ctrl=0x556a108e0ce0, filefd=-1, 
> filename=0x7ffc0d75324f "-&8", remusr=0x556a108df9d0, use_symkey=0, 
> provided_keys=0x0, outputfd=-1) at ../../g10/encrypt.c:523
> #11 0x556a0f203563 in main (argc=, argv= out>) at ../../g10/gpg.c:4155


I can trivially reproduce this without having mutt involved like:

$ gpg  --encrypt --armor --always-trust -r 
1A6F3E639A4467E8C3476525DF6D76C44D696F6B
gpg: O j: ... this is a bu

Bug#878812: Segfaults when encrypting to certain keys

[Guido Günther]

Hi,
On Mon, Oct 16, 2017 at 10:02:09PM +0200, Guido Günther wrote:
> Package: gnupg
> Version: 2.2.1-2
> Severity: normal
> 
> Encrypting to 1A6F3E639A4467E8C3476525DF6D76C44D696F6B makes GPG here
> segfault like:
> 
> $ coredumpctl dump
>PID: 21438 (gpg)
>UID: 1000 (agx)
>GID: 1000 (agx)
> Signal: 6 (ABRT)
>  Timestamp: Mon 2017-10-16 21:57:08 CEST (36s ago)
>   Command Line: gpg --enable-special-filenames --batch --no-sk-comments 
> --lc-messages en_US.UTF-8 --lc-ctype de_DE.UTF-8 --status-fd 5 --no-tty 
> --charset utf8 --enable-progress-filter --exit-on-status-write-error 
> --display :0 --ttyname /dev/pts/5 --ttytype xterm-256color --encrypt --armor 
> --always-trust -r 1A6F3E639A4467E8C3476525DF6D76C44D696F6B -r 
> 0DB3932762F78E592F6522AFBB5A2C77584122D3 -r 
> 0DB3932762F78E592F6522AFBB5A2C77584122D3 --output - -- -&8
> Executable: /usr/bin/gpg
>  Control Group: 
> /user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service
>   Unit: user@1000.service
>  User Unit: gnome-terminal-server.service
>  Slice: user-1000.slice
>  Owner UID: 1000 (agx)
>Boot ID: 4ef1bf5cd7da4bfcb061d19089fe468e
> Machine ID: 15e9777086166538c724eaba52d14fa1
>   Hostname: bogon
>Storage: 
> /var/lib/systemd/coredump/core.gpg.1000.4ef1bf5cd7da4bfcb061d19089fe468e.21438.150818382800.lz4
>Message: Process 21438 (gpg) of user 1000 dumped core.
> 
> Stack trace of thread 21438:
> #0  0x7fd58eef3fff __GI_raise (libc.so.6)
> #1  0x7fd58eef542a __GI_abort (libc.so.6)
> #2  0x556a0f291f09 do_logv (gpg)
> #3  0x556a0f29290d log_log (gpg)
> #4  0x556a0f29306f bug_at (gpg)
> #5  0x556a0f243c1e do_we_trust (gpg)
> #6  0x556a0f243fff find_and_check_key (gpg)
> #7  0x556a0f2455b6 find_and_check_key (gpg)
> #8  0x556a0f24b6c2 encrypt_crypt (gpg)
> #9  0x556a0f203563 main (gpg)
> #10 0x7fd58eee12e1 __libc_start_main (libc.so.6)
> #11 0x556a0f2054da _start (gpg)


And here's the backtrace from gdb:

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7fd58eef542a in __GI_abort () at abort.c:89
#2  0x556a0f291f09 in do_logv (level=6, ignore_arg_ptr=, 
extrastring=0x0, prefmt=, fmt=, 
arg_ptr=0x7ffc0d74f950) at ../../common/logging.c:859
#3  0x556a0f29290d in log_log (level=level@entry=6, 
fmt=fmt@entry=0x556a0f2c72c3 "... this is a bug (%s:%d:%s)\n") at 
../../common/logging.c:872
#4  0x556a0f29306f in bug_at (file=file@entry=0x556a0f2b7a42 
"../../g10/pkclist.c", line=line@entry=417, func=func@entry=0x556a0f2b87f0 
<__FUNCTION__.10242> "do_we_trust") at ../../common/logging.c:1074
#5  0x556a0f243c1e in do_we_trust (trustlevel=, pk=0x1) at 
../../g10/pkclist.c:417
#6  do_we_trust_pre (ctrl=ctrl@entry=0x556a108e0ce0, 
pk=pk@entry=0x556a108ffbe0, trustlevel=) at 
../../g10/pkclist.c:474
#7  0x556a0f243fff in find_and_check_key (ctrl=ctrl@entry=0x556a108e0ce0, 
name=name@entry=0x556a108df95c "1A6F3E639A4467E8C3476525DF6D76C44D696F6B", 
use=use@entry=2, mark_hidden=0, from_file=0, 
pk_list_addr=pk_list_addr@entry=0x7ffc0d74fb20) at ../../g10/pkclist.c:885
#8  0x556a0f2455b6 in find_and_check_key (pk_list_addr=0x7ffc0d74fb20, 
from_file=, mark_hidden=, use=2, 
name=0x556a108df95c "1A6F3E639A4467E8C3476525DF6D76C44D696F6B", 
ctrl=0x556a108e0ce0) at ../../g10/pkclist.c:1301
#9  build_pk_list (ctrl=ctrl@entry=0x556a108e0ce0, 
rcpts=rcpts@entry=0x556a108df9d0, ret_pk_list=ret_pk_list@entry=0x7ffc0d74fc18) 
at ../../g10/pkclist.c:1301
#10 0x556a0f24b6c2 in encrypt_crypt (ctrl=0x556a108e0ce0, filefd=-1, 
filename=0x7ffc0d75324f "-&8", remusr=0x556a108df9d0, use_symkey=0, 
provided_keys=0x0, outputfd=-1) at ../../g10/encrypt.c:523
#11 0x556a0f203563 in main (argc=, argv=) at 
../../g10/gpg.c:4155

> 
> 
> I'm using the debian keyring to provide that key:
> 
> keyring /usr/share/keyrings/debian-keyring.gpg
> 
> Cheers,
>  -- Guido
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
> 'testing-debug'), (500, 'stable-updates'), (500, 'oldoldstable'), (500, 
> 'unstable'), (500, 'stable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en

Bug#878812: Segfaults when encrypting to certain keys

[Guido Günther]

Package: gnupg
Version: 2.2.1-2
Severity: normal

Encrypting to 1A6F3E639A4467E8C3476525DF6D76C44D696F6B makes GPG here
segfault like:

$ coredumpctl dump
   PID: 21438 (gpg)
   UID: 1000 (agx)
   GID: 1000 (agx)
Signal: 6 (ABRT)
 Timestamp: Mon 2017-10-16 21:57:08 CEST (36s ago)
  Command Line: gpg --enable-special-filenames --batch --no-sk-comments 
--lc-messages en_US.UTF-8 --lc-ctype de_DE.UTF-8 --status-fd 5 --no-tty 
--charset utf8 --enable-progress-filter --exit-on-status-write-error --display 
:0 --ttyname /dev/pts/5 --ttytype xterm-256color --encrypt --armor 
--always-trust -r 1A6F3E639A4467E8C3476525DF6D76C44D696F6B -r 
0DB3932762F78E592F6522AFBB5A2C77584122D3 -r 
0DB3932762F78E592F6522AFBB5A2C77584122D3 --output - -- -&8
Executable: /usr/bin/gpg
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service
  Unit: user@1000.service
 User Unit: gnome-terminal-server.service
 Slice: user-1000.slice
 Owner UID: 1000 (agx)
   Boot ID: 4ef1bf5cd7da4bfcb061d19089fe468e
Machine ID: 15e9777086166538c724eaba52d14fa1
  Hostname: bogon
   Storage: 
/var/lib/systemd/coredump/core.gpg.1000.4ef1bf5cd7da4bfcb061d19089fe468e.21438.150818382800.lz4
   Message: Process 21438 (gpg) of user 1000 dumped core.

Stack trace of thread 21438:
#0  0x7fd58eef3fff __GI_raise (libc.so.6)
#1  0x7fd58eef542a __GI_abort (libc.so.6)
#2  0x556a0f291f09 do_logv (gpg)
#3  0x556a0f29290d log_log (gpg)
#4  0x556a0f29306f bug_at (gpg)
#5  0x556a0f243c1e do_we_trust (gpg)
#6  0x556a0f243fff find_and_check_key (gpg)
#7  0x556a0f2455b6 find_and_check_key (gpg)
#8  0x556a0f24b6c2 encrypt_crypt (gpg)
#9  0x556a0f203563 main (gpg)
#10 0x7fd58eee12e1 __libc_start_main (libc.so.6)
#11 0x556a0f2054da _start (gpg)


I'm using the debian keyring to provide that key:

keyring /usr/share/keyrings/debian-keyring.gpg

Cheers,
 -- Guido


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gnupg depends on:
ii  dirmngr 2.2.1-2
ii  gnupg-l10n  2.2.1-2
ii  gnupg-utils 2.2.1-2
ii  gpg 2.2.1-2
ii  gpg-agent   2.2.1-2
ii  gpg-wks-client  2.2.1-2
ii  gpg-wks-server  2.2.1-2
ii  gpgsm   2.2.1-2
ii  gpgv2.2.1-2

gnupg recommends no packages.

Versions of packages gnupg suggests:
pn  parcimonie  
pn  xloadimage  

-- no debconf information

Bug#878799: CVE-2017-1000256/LSN-2017-0002: TLS certificate verification disabled for clients

[Guido Günther]

Source: libvirt
Version: CVE-2017-1000256/LSN-2017-0002: TLS certificate verification disabled 
for clients
Severity: important
Tags: security

Description
---

The default_tls_x509_verify (and related) parameters in qemu.conf
control whether the TLS servers in QEMU request & verify
certificates from clients. This works as a simple access control
system for QEMU servers by requiring the CA to issue certs to
permitted clients. This use of client certificates is disabled by
default, since it requires extra work to issue client certificates.
Unfortunately the libvirt code was using these configuration
parameters when setting up both TLS clients and servers in QEMU. The
result was that TLS clients for character devices and disk devices
had verification turned off, meaning they would ignore any errors
while validating the server certificate.

https://www.redhat.com/archives/libvirt-announce/2017-October/msg1.html


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#758464: SELinux policy updated

[Guido Günther]

Version: libvirt/3.0.0-4

Hi,
On Fri, Feb 06, 2015 at 09:18:18AM +, Russell Coker wrote:
> reassign 758464 libvirt-bin
> thanks
> 
> This bug has been accepted as an upstream issue.  Please verify that Jessie 
> has the fixed version of virsh.

This was fixed upstream ages ago so closing.
Cheers,
 -- Guido

Bug#878299: [Pkg-libvirt-maintainers] Bug#878299: libvirt-daemon: Live migration with qemu - not working with copy-storage-xx on stretch

[Guido Günther]

Hi,
On Thu, Oct 12, 2017 at 02:01:45PM +0200, Jan Sechovec wrote:
> Package: libvirt-daemon
> Version: 3.0.0-4
> Severity: normal
> 
> Dear Maintainer,
> 
> after dist-upgrade from jessie to stretch live migrations with 
> --copy-storage-all stopped working.
> There is no usable error/warning log message, migration process waits for 
> something, that will not 
> happen (until killed).
> 
> example: 
> virsh migrate --live virtual qemu+ssh://dest-host/system --verbose 
> --persistent --copy-storage-all
> 
> We're using local LVM logical volumes for virtuals:
> 
> 
>   
>   
>   
>   
> 
> 
> Volumes exists on both source and target side (no problems with this setup 
> until upgrade to stretch, 
> it worked fine on squeeze/wheezy/jessie distros.
> 
> Migration without copying of data finishes successfuly, problem appears only 
> with --copy-storage-all 
> and --copy-storage-inc. 
> 
> When running with LIBVIRT_DEBUG=1, last executed action is Perform3 in 
> virDomainMigrateVersion3Full,
> then only waiting. Transmitting of storage data never starts. I've tried 
> migration between 
> stretch->jessie, stretch->stretch, jessie-> stretch  hosts, none of these 
> worked. When migrating from 
> jessie to stretch, it gets even worse - after a while, the migrated virtual 
> freezes until the 
> migration virsh process is killed (after killing it starts responding again).
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796122#59

That's why I've merged them. Thanks for adding the above details and
trying various combinations! I currently don't have the resources to
work on migration related bugs (although it's on my todo list since
quite some tme) so if somebody wants do dig into this (maybe checking
upstream commit logs and trying patches) that would be great.
 -- Guido

Bug#704097: RFP: travis-client-tools -- command line client and a Ruby library to interface with a Travis CI service

[Guido Günther]

Hi,
On Wed, Mar 27, 2013 at 04:43:39PM -0400, Yaroslav Halchenko wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: travis-client-tools
>   Version : 1.2.0
>   Upstream Author : Konstantin Haase
> * URL : https://github.com/travis-ci/travis
> * License : MIT/X
>   Programming Lang: Ruby
>   Description : command line client and a Ruby library to interface with 
> a Travis CI service
> 
> The travis gem includes both a command line client and a Ruby library to
> interface with a Travis CI service. Both work with travis-ci.org, 
> travis-ci.com
> or any custom Travis CI setup you might have.
> 
> It supports
> - General API Commands
> console endpoint login raw sync token whatsup whoami
> - Repository Commands
> disable enable encrypt history logs open restart show status
> 
> and having it in Debian would help to avoid crafting castom quick scripts
> to e.g. fetch the travis build logs: http://paste.debian.net/245255/
> ;-)

This needs ruby-gh and ruby-pusher-client packaged first. The later
needs ruby-websocket which does not seem to be packaged either.

Cheers,
 -- Guido

> 
> (Un)fortunately there is already a package in Debian with 'travis' name:
> travis: trajectory analyzer and visualizer

Bug#878153: [Pkg-libvirt-maintainers] Bug#878153: libvirt-daemon-system: frequent AppArmor denials for ptrace of some unconfined process

[Guido Günther]

Hi,
On Tue, Oct 10, 2017 at 02:54:50PM +0100, Simon McVittie wrote:
> Package: libvirt-daemon-system
> Version: 3.7.0-4
> Severity: normal
> 
> In recent uses of libvirtd (I would guess the last couple of weeks) I get
> frequent AppArmor denials from libvirtd attempting to trace some
> unconfined process:
> 
> Oct 10 14:35:58 perpetual kernel: audit: type=1400 
> audit(1507642558.099:2336): apparmor="DENIED" operation="ptrace" 
> profile="/usr/sbin/libvirtd" pid=14324 comm="libvirtd" requested_mask="trace" 
> denied_mask="trace" peer="unconfined"
> Oct 10 14:35:58 perpetual kernel: audit: type=1400
> audit(1507642558.099:2337): apparmor="DENIED" operation="ptrace"
> profile="/usr/sbin/libvirtd" pid=14324 comm="libvirtd"
> requested_mask="trace" denied_mask="trace" peer="unconfined"

This happens since you're running 4.13 (which is not in testing yet AFAIK).

> 
> Unfortunately, AppArmor logs the system call that caused the denial for
> some operations, but apparently not for this one; so we can't know
> anything about the target process.
> 
> Some clues: I only get these when a VM is running. With one session://
> VM and no system:// VMs running, I get these denials in consecutive pairs,
> one pair every 3 seconds.
> 
> I believe this indicates either an actual ptrace operation, or mutating
> process state by writing into /proc (which is also audited as "ptrace"
> under at least some kernel versions). requested_mask="trace" indicates
> that libvirtd is trying to write or change the state of some other,
> unconfined process, as opposed to reading state which would be
> requested_mask="read", or being traced by an unconfined process which
> would be requested_mask="tracedby" or requested_mask="readby".
> 
> A workaround is to add this to the AppArmor profile (although this does
> let libvirtd trace unconfined processes like for example dbus-daemon and
> network-manager, which would be bad if there is meant to be a security
> boundary between them):
> 
> ptrace peer=unconfined,
> 
> This might be 
> https://www.redhat.com/archives/libvir-list/2017-September/msg00546.html
> in which case it's fixed in 3.8.0. If so, I'll close this when I've
> upgraded.


Yes, this should be fixed in 3.8.0, see #877926. The version in sid
doesn't fix all issues related to that but I want it to migrate first
before fixing the remaining apparmor glitch related to dnsmasq.

Cheers,
 -- Guido

Bug#877322: [git-buildpackage/master] docs: Move to xml

[Guido Günther]

tag 877322 pending
thanks

Date:   Mon Oct 2 20:45:45 2017 +0200
Author: Guido Günther 
Commit ID: d75fbd465a34378b88db2f3e067088e08d5f2cba
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=d75fbd465a34378b88db2f3e067088e08d5f2cba
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=d75fbd465a34378b88db2f3e067088e08d5f2cba

docs: Move to xml

Closes: #877322

  

Bug#876399: pbuilder: B20autopkgtest hook script uses removed adt-run commands

[Guido Günther]

Hi Mattia,

On Wed, Oct 04, 2017 at 09:44:18PM +0200, Mattia Rizzolo wrote:
> On Wed, Oct 04, 2017 at 08:59:34PM +0200, Guido Günther wrote:
> > Attached patch supports both adt-rn and autopkgtest so we can continue
> > to build in wheezy and jessie.
> 
> ooohhh, I remembered there were some simple bugs lying around while I
> was doing the upload, but I didn't actually looked to the bug list and
> instead only fixed the FTBFS in the upload I did today...
> 
> 
> Thank you very much for the patch, much appreciated!
> Just, I noticed that you introduced an AUTOPKGTEST_OPTIONS without any
> kind of migration from ADT_OPTIONS.  Could you please consider that as
> well in your patch?  Also take care that ADT_OPTIONS is also mentioned
> before the hunks you modified.

Thanks for having a look. It falls back to ADT_OPTION for
AUTOPKGTEST_OPTIONS but uses ADT_OPTIONS for the adt-run in case someone
wants different sets of options for the two.
 -- Guido

> 
> > I doubled the while invocations instead of special casing even more
> > options so it stays easier to extend.
> 
> That's fine in something so short :)
> 
> -- 
> regards,
> Mattia Rizzolo
> 
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


From 7ee94bd2ce69b6b68315f17e066c7f9be27ab7ef Mon Sep 17 00:00:00 2001
Message-Id: <7ee94bd2ce69b6b68315f17e066c7f9be27ab7ef.1507221883.git@sigxcpu.org>
From: =?UTF-8?q?Guido=20G=C3=BCnther?= <a...@sigxcpu.org>
Date: Wed, 4 Oct 2017 19:29:52 +0200
Subject: [PATCH] B20aupkgtest: Prefer autopkgtest over adt-run

autopkgtest 5.0 dropped support for adt-run. Cater for that but still
allow to use adt-run in older chroot.

Closes: #876399
---
 examples/B20autopkgtest | 40 +---
 1 file changed, 25 insertions(+), 15 deletions(-)

diff --git a/examples/B20autopkgtest b/examples/B20autopkgtest
index e2c3758..bef32b6 100644
--- a/examples/B20autopkgtest
+++ b/examples/B20autopkgtest
@@ -46,11 +46,12 @@ if [ ! -f debian/files ]; then
 exit 1
 fi
 
-if [ -n "${ADT_OPTIONS:-}" ] ; then
-echo "*** Using provided ADT_OPTIONS $ADT_OPTIONS ***"
+OPTS="${AUTOPKGTEST_OPTIONS:-$ADT_OPTIONS}"
+if [ -n "${OPTS}" ]; then
+echo "*** Using provided AUTOPKGTEST_OPTIONS ${OPTS} ***"
 fi
 
-# try to launch adt-run in a new PID namespace so several testsuites can run
+# try to launch autopkgtest in a new PID namespace so several testsuites can run
 # in parallel, newpid exists in jessie and newer only though
 unset newpid_name
 if ! apt-cache policy newpid | grep -q 'newpid:' ; then
@@ -64,22 +65,31 @@ fi
 # pbuilder's pbuilder-satisfydepends-classic
 apt-get install -y "${APTGETOPT[@]}" autopkgtest apt-utils pbuilder $newpid_name
 
-# since autopkgtest 3.16 the --tmp-dir option is gone, make sure
-# we've --output-dir available though before using it
-if adt-run --help | grep -q -- --output-dir 2>/dev/null ; then
-OUTPUT_OPTION='--output-dir'
-else
-OUTPUT_OPTION='--tmp-dir'
-fi
-
 mkdir -p "$BUILDDIR/autopkgtest.out"
 
-$newpid_name adt-run \
-${OUTPUT_OPTION} "$BUILDDIR/autopkgtest.out" \
+if which autopkgtest >/dev/null; then
+  $newpid_name autopkgtest \
+--output-dir "$BUILDDIR/autopkgtest.out" \
 --summary "$BUILDDIR/autopkgtest.summary" \
 "$BUILDDIR"/*.deb \
---built-tree "${PWD}" \
-${ADT_OPTIONS:-} --- adt-virt-null || EXIT=$?
+"${PWD}" \
+${OPTS} -- autopkgtest-virt-null || EXIT=$?
+else
+  # since autopkgtest 3.16 the --tmp-dir option is gone, make sure
+  # we've --output-dir available though before using it
+  if adt-run --help | grep -q -- --output-dir 2>/dev/null ; then
+  OUTPUT_OPTION='--output-dir'
+  else
+  OUTPUT_OPTION='--tmp-dir'
+  fi
+
+  $newpid_name adt-run \
+  ${OUTPUT_OPTION} "$BUILDDIR/autopkgtest.out" \
+  --summary "$BUILDDIR/autopkgtest.summary" \
+  "$BUILDDIR"/*.deb \
+  --built-tree "${PWD}" \
+  ${ADT_OPTIONS} --- adt-virt-null || EXIT=$?
+fi
 
 # collect autopkgtest output in a single file so pbuilder automatically copies it
 tar -caf "$BUILDDIR/autopkgtest.tar.gz" "$BUILDDIR/autopkgtest.out"
-- 
2.14.1

Bug#874052: pbuilder: B20autopkgtest, hook script fails within a Jessie chroot due bashism

[Guido Günther]

control: -1 tags +patch

Hi,
On Sat, Sep 02, 2017 at 03:00:04PM +0200, Carsten Schoenert wrote:
> Package: pbuilder
> Version: 0.228.8
> Severity: normal
> 
> Dear Maintainer,
> 
> I heavily use the hook script B20autopkgtest from the shipped examples scripts
> within pbuilder package within my local builds to test potentially uploads of
> packages.
> 
> And this works perfectly within current chroot environments for unstable
> ans also for Stretch. But within a Jessie chroot the hook script is
> failing due some bashism inside without a shebang of /bin/bash
> 
> > ...
> > dpkg-genchanges: not including original source code in upload
> > I: copying local configuration
> > I: user script /home/pbuilder/build/cow.13852/tmp/hooks/B20autopkgtest 
> > starting
> > + cd /build/icedove-52.3.0/debian/..
> > + [ ! -f debian/tests/control ]
> > + [ ! -f debian/files ]
> > + [ -n  ]
> > + unset newpid_name
> > + apt-cache policy newpid
> > + grep -q newpid:
> > + echo The newpid package seems to be available, considering for 
> > installation
> > The newpid package seems to be available, considering for installation
> > + newpid_name=newpid
> > /tmp/hooks/B20autopkgtest: 65: /tmp/hooks/B20autopkgtest: Bad substitution
> 
> Using checkbashism is showing exactly this line using Bash syntax.
> 
> > carsten@i5:/usr/share/doc/pbuilder/examples  $ checkbashisms B20autopkgtest 
> > possible bashism in B20autopkgtest line 65 (bash arrays, ${name[0|*|@]}):
> > apt-get install -y "${APTGETOPT[@]}" autopkgtest apt-utils pbuilder 
> > $newpid_name
> 
> I changed the shebang to using /bin/bash and the script is also working in a
> Jessie chroot again.

The script used APTGETOPT which is also used in other scripts as array
but all use /bin/bash so lets use that for B20autopkgtest too. Patch
attached.
Cheers,
 -- Guido
>From d3e9ba3ddc4b1199788bb23d9cdd09ebf69887a0 Mon Sep 17 00:00:00 2001
Message-Id: 
From: =?UTF-8?q?Guido=20G=C3=BCnther?= 
Date: Wed, 4 Oct 2017 21:02:39 +0200
Subject: [PATCH] B20autopkgtest: Use /bin/bash

Closes: #874052
---
 examples/B20autopkgtest | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/examples/B20autopkgtest b/examples/B20autopkgtest
index 279a26e..7b7b543 100644
--- a/examples/B20autopkgtest
+++ b/examples/B20autopkgtest
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 # Copyright © 2012 Christoph Berg 
 #   © 2013 Michael Prokop 
 #   © 2015 Mattia Rizzolo 
-- 
2.14.1

Bug#876399: pbuilder: B20autopkgtest hook script uses removed adt-run commands

[Guido Günther]

control: tags -1 +patch

Hi,
On Thu, Sep 21, 2017 at 12:24:09PM -0700, Diane Trout wrote:
> On Thu, 2017-09-21 at 20:57 +0200, Mattia Rizzolo wrote:
> > On Thu, Sep 21, 2017 at 11:14:05AM -0700, Diane Trout wrote:
> > > I was trying to build some packages in sid and discovered that the
> > > chroot B20autopkgtest hook script was using /usr/bin/adt-run which
> > > has
> > > been removed in autopkgtest 5.0
> > 
> > oh, thanks for the bug!
> > 
> 
> I quickly ported B20autopkgtest to use the autopkgtest commands.
> 
> Although I didn't add checks to fail back to adt commands, so, it'll
> only work with sufficiently new versions of autopkgtest. 
> 
> autopkgtest 4.4 in testing has both adt- and autopkgtest- commands, 5.0
> only has the autopkgtest- commands.

Attached patch supports both adt-rn and autopkgtest so we can continue
to build in wheezy and jessie.

I doubled the while invocations instead of special casing even more
options so it stays easier to extend.

Cheers,
 -- Guido
>From af42f6c8ccabecb880abe9de480f181856a73a63 Mon Sep 17 00:00:00 2001
Message-Id: 
From: =?UTF-8?q?Guido=20G=C3=BCnther?= 
Date: Wed, 4 Oct 2017 19:29:52 +0200
Subject: [PATCH] B20aupkgtest: Prefer autopkgtest over adt-run

autopkgtest 5.0 dropped support for adt-run. Cater for that but still
allow to use adt-run in older chroot.
---
 examples/B20autopkgtest | 35 ++-
 1 file changed, 22 insertions(+), 13 deletions(-)

diff --git a/examples/B20autopkgtest b/examples/B20autopkgtest
index e2c3758..279a26e 100644
--- a/examples/B20autopkgtest
+++ b/examples/B20autopkgtest
@@ -50,7 +50,7 @@ if [ -n "${ADT_OPTIONS:-}" ] ; then
 echo "*** Using provided ADT_OPTIONS $ADT_OPTIONS ***"
 fi
 
-# try to launch adt-run in a new PID namespace so several testsuites can run
+# try to launch autopkgtest in a new PID namespace so several testsuites can run
 # in parallel, newpid exists in jessie and newer only though
 unset newpid_name
 if ! apt-cache policy newpid | grep -q 'newpid:' ; then
@@ -64,22 +64,31 @@ fi
 # pbuilder's pbuilder-satisfydepends-classic
 apt-get install -y "${APTGETOPT[@]}" autopkgtest apt-utils pbuilder $newpid_name
 
-# since autopkgtest 3.16 the --tmp-dir option is gone, make sure
-# we've --output-dir available though before using it
-if adt-run --help | grep -q -- --output-dir 2>/dev/null ; then
-OUTPUT_OPTION='--output-dir'
-else
-OUTPUT_OPTION='--tmp-dir'
-fi
-
 mkdir -p "$BUILDDIR/autopkgtest.out"
 
-$newpid_name adt-run \
-${OUTPUT_OPTION} "$BUILDDIR/autopkgtest.out" \
+if which autopkgtest >/dev/null; then
+  $newpid_name autopkgtest \
+--output-dir "$BUILDDIR/autopkgtest.out" \
 --summary "$BUILDDIR/autopkgtest.summary" \
 "$BUILDDIR"/*.deb \
---built-tree "${PWD}" \
-${ADT_OPTIONS:-} --- adt-virt-null || EXIT=$?
+"${PWD}" \
+${AUTOPKGTEST_OPTIONS:-} -- autopkgtest-virt-null || EXIT=$?
+else
+  # since autopkgtest 3.16 the --tmp-dir option is gone, make sure
+  # we've --output-dir available though before using it
+  if adt-run --help | grep -q -- --output-dir 2>/dev/null ; then
+  OUTPUT_OPTION='--output-dir'
+  else
+  OUTPUT_OPTION='--tmp-dir'
+  fi
+
+  $newpid_name adt-run \
+  ${OUTPUT_OPTION} "$BUILDDIR/autopkgtest.out" \
+  --summary "$BUILDDIR/autopkgtest.summary" \
+  "$BUILDDIR"/*.deb \
+  --built-tree "${PWD}" \
+  ${ADT_OPTIONS:-} --- adt-virt-null || EXIT=$?
+fi
 
 # collect autopkgtest output in a single file so pbuilder automatically copies it
 tar -caf "$BUILDDIR/autopkgtest.tar.gz" "$BUILDDIR/autopkgtest.out"
-- 
2.14.1

Bug#877391: Please add apparmor profile

[Guido Günther]

Hi Daniel,
On Sun, Oct 01, 2017 at 04:09:16PM -0400, Daniel Richard G. wrote:
> Hi Guido,
> 
> On Sun, 2017 Oct  1 12:28+0200, Guido Günther wrote:
> > Package: chromium
> > Version: 61.0.3163.100-2
> > Severity: wishlist
> > Tags: patch
> > 
> > Hi,
> >
> > I'd be great if Debian would ship an apparmor profile for chromium. The
> > attached profile was mostly prepared by Daniel Richard and is based on
> > the one in Ubuntu so I assume it has seen quiet some exposure to real
> > world usage. It works here nicely here. I'm sure there will be tweaks
> > needed over time so feel free to cc' me and Richard on apparmor related
> > issues. If this shouldn't work out we can always disable it again.
> 
> I had a look at your additions to the profile. Some comments:
> 
> * As mentioned in the earlier bug report, we should add the abstractions
>   file to Debian as well (though not necessarily the same file as Ubuntu
>   has). I'd like to move the aliases into an include file, eventually,
>   and that one would probably make the most sense.

Maintaining a single file is IMHO simpler than splitting this up with no
other users but I'm not tied to this.

> 
> * This line gave me pause:
> 
> + @{PROC}/@{pid}/task/@{tid}/status rw,
> 
>   I've seen denials from the lack of this line, but have hesitated to
>   add this. I'm quite suspicious of Chromium wanting write access to
>   this proc file of unrelated processes, and would want more information
>   as to why this is needed before allowing this.
> 
>   (@{pid} and @{tid} will one day represent actual kernel variables, but
>   for now they remain basically equivalent to "[0-9]*".)

(yeah, it's a pitty these are currently patterns and not real variables
i apparmor).

> 
>   I've found no issues with this access being denied, and would have in
>   fact added this line with a "deny" qualifier if that didn't also
>   disallow such access to Chromium's own processes.

I'm o.k. using a deny rule instead to silence the denials.

> * The new lines for "tr" and "head": As much as possible, I try to keep
>   lists of similar items in alphabetical order, because it's more work
>   to maintain lists when there isn't a well-defined ordering.
> 
> * The rest looks reasonable, the sort of AppArmor footprint increment
>   that Chromium usually follows.

Thanks for your feedback - makes sense. Feel free to update the patch
accordingly. That said I think it's o.k. to be applied and patched in a
followup.

Cheers,
 -- Guido

Bug#742829: closed by intrigeri <intrig...@debian.org> (Bug#742829: fixed in apparmor 2.10.95-8)

[Guido Günther]

Hi,
On Fri, Sep 29, 2017 at 04:09:02PM -0400, Daniel Richard G. wrote:
> On Fri, 2017 Sep 29 00:18+0200, Guido Günther wrote:
> >
> > Attaching to this the report is fine. I can handle it from there.
> 
> Okay, greatly appreciated. My current profile is attached. Please Cc: me
> on the new bug report.
> 
> As it happens, this file is identical to the current version of the
> profile in the apparmor-profiles Git repository, with the exception of
> the Debian alias lines.
> 
> It seems that the AppArmor folks accepted my changes in the merge
> request, not by approving the merge, but by applying the changes to a
> new version-specific copy in the repo. They added a few more things of
> their own, which I have in turn merged into my/this copy.
> 
> I never heard anything from them about this, however; I learned about
> this only now that I diffed my profile with their latest. Their process
> could certainly stand to be more transparent.

This is #877391 against chromium. I've added some rules to allow access
to some more files that popped up as denials and pulled in the browser
abstraction verbatim.

Thanks!
 -- Guido


> # Author: Jamie Strandboge <ja...@canonical.com>
> #include 
> 
> # Debian compatibility aliases
> # https://bugs.debian.org/742829
> #
> alias /etc/chromium-browser/ -> /etc/chromium/,
> alias /usr/bin/chromium-browser -> /usr/bin/chromium,
> alias /usr/lib/chromium-browser/chromium-browser-sandbox -> 
> /usr/lib/chromium/chrome-sandbox,
> alias /usr/lib/chromium-browser/chromium-browser -> 
> /usr/lib/chromium/chromium,
> alias /usr/lib/chromium-browser/ -> /usr/lib/chromium/,
> 
> # We need 'flags=(attach_disconnected)' in newer chromium versions
> /usr/lib/chromium-browser/chromium-browser flags=(attach_disconnected) {
>   #include 
>   #include 
>   #include 
>   #include 
>   #include 
>   #include 
>   #include 
>   #include 
> 
>   # This include specifies which ubuntu-browsers.d abstractions to use. Eg, if
>   # you want access to productivity applications, adjust the following file
>   # accordingly.
>   #include 
> 
>   # Networking
>   network inet stream,
>   network inet6 stream,
>   @{PROC}/[0-9]*/net/if_inet6 r,
>   @{PROC}/[0-9]*/net/ipv6_route r,
> 
>   # Should maybe be in abstractions
>   /etc/mime.types r,
>   /etc/mailcap r,
>   /etc/mtab r,
>   /etc/xdg/xubuntu/applications/defaults.list r,
>   owner @{HOME}/.local/share/applications/defaults.list r,
>   owner @{HOME}/.local/share/applications/mimeinfo.cache r,
> 
>   @{PROC}/[0-9]*/fd/ r,
>   @{PROC}/filesystems r,
>   @{PROC}/ r,
>   @{PROC}/[0-9]*/task/[0-9]*/stat r,
>   owner @{PROC}/[0-9]*/cmdline r,
>   owner @{PROC}/[0-9]*/io r,
>   owner @{PROC}/[0-9]*/setgroups w,
>   owner @{PROC}/[0-9]*/{uid,gid}_map w,
>   @{PROC}/[0-9]*/smaps r,
>   owner @{PROC}/[0-9]*/stat r,
>   @{PROC}/[0-9]*/statm r,
>   owner @{PROC}/[0-9]*/status r,
>   owner @{PROC}/[0-9]*/task/[0-9]*/status r,
>   deny @{PROC}/[0-9]*/oom_{,score_}adj w,
>   @{PROC}/sys/kernel/yama/ptrace_scope r,
>   @{PROC}/sys/net/ipv4/tcp_fastopen r,
> 
>   # Newer chromium needs these now
>   /etc/udev/udev.conf r,
>   /sys/devices/**/uevent r,
>   /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq r,
>   /sys/devices/system/node/node*/meminfo r,
>   /sys/devices/pci[0-9]*/**/class r,
>   /sys/devices/pci[0-9]*/**/device r,
>   /sys/devices/pci[0-9]*/**/irq r,
>   /sys/devices/pci[0-9]*/**/resource r,
>   /sys/devices/pci[0-9]*/**/vendor r,
>   /sys/devices/pci[0-9]*/**/removable r,
>   /sys/devices/pci[0-9]*/**/block/**/size r,
>   /sys/devices/virtual/block/**/removable r,
>   /sys/devices/virtual/block/**/size r,
>   /sys/devices/virtual/tty/tty*/active r,
>   # This is requested, but doesn't seem to actually be needed so deny for now
>   deny /run/udev/data/** r,
> 
>   # Needed for the crash reporter
>   owner @{PROC}/[0-9]*/auxv r,
> 
>   # chromium mmaps all kinds of things for speed.
>   /etc/passwd m,
>   /usr/share/fonts/truetype/**/*.tt[cf] m,
>   /usr/share/fonts/**/*.pfb m,
>   /usr/share/mime/mime.cache m,
>   /usr/share/icons/**/*.cache m,
>   owner /{dev,run}/shm/pulse-shm* m,
>   owner @{HOME}/.local/share/mime/mime.cache m,
>   owner /tmp/** m,
> 
>   @{PROC}/sys/kernel/shmmax r,
>   owner /{dev,run}/shm/{,.}org.chromium.* mrw,
>   owner /{,var/}run/shm/shmfd-* mrw,
> 
>   /usr/lib/chromium-browser/*.pak mr,
>   /usr/lib/chromium-browser/locales/* mr,
> 
>   # Noisy
>   deny /usr/lib/chromium-browser/** w,
> 
>   capability sys_admin,
>   capability sys_chroot,
>   capability sys_ptrace,
> 
>   # Allow ptracing ourselves
>   ptrace (trace

Bug#877391: Please add apparmor profile

[Guido Günther]

Package: chromium
Version: 61.0.3163.100-2
Severity: wishlist
Tags: patch

Hi,
I'd be great if Debian would ship an apparmor profile for chromium. The
attached profile was mostly prepared by Daniel Richard and is based on
the one in Ubuntu so I assume it has seen quiet some exposure to real
world usage. It works here nicely here. I'm sure there will be tweaks
needed over time so feel free to cc' me and Richard on apparmor related
issues. If this shouldn't work out we can always disable it again.

Cheers,
 -- Guido

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages chromium depends on:
ii  chromium-common  61.0.3163.100-2
ii  libasound2   1.1.3-5
ii  libatk1.0-0  2.26.0-2
ii  libavcodec57 7:3.3.4-1
ii  libavformat577:3.3.4-1
ii  libavutil55  7:3.3.4-1
ii  libc62.24-17
ii  libcairo21.14.10-1
ii  libcups2 2.2.4-7
ii  libdbus-1-3  1.11.16+really1.10.22-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.3-1
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.12.3-0.2
ii  libfreetype6 2.8-0.2
ii  libgcc1  1:7.2.0-5
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.54.0-1
ii  libgtk2.0-0  2.24.31-2
ii  libharfbuzz0b1.4.2-1
ii  libicu57 57.1-6
ii  libjpeg62-turbo  1:1.5.2-2
ii  liblcms2-2   2.8-4
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.16-1
ii  libnss3  2:3.32-2
ii  libopus0 1.2~alpha2-1
ii  libpango-1.0-0   1.40.12-1
ii  libpangocairo-1.0-0  1.40.12-1
ii  libpng16-16  1.6.32-1
ii  libpulse011.0-2
ii  libre2-3 20170101+dfsg-1
ii  libsnappy1v5 1.1.7-1
ii  libstdc++6   7.2.0-5
ii  libvpx4  1.6.1-3
ii  libwebp6 0.6.0-3
ii  libwebpdemux20.6.0-3
ii  libwebpmux3  0.6.0-3
ii  libx11-6 2:1.6.4-3
ii  libx11-xcb1  2:1.6.4-3
ii  libxcb1  1.12-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.14-3
ii  libxdamage1  1:1.1.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-4
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.29-2.1
ii  libxss1  1:1.2.2-1+b2
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-2

Versions of packages chromium suggests:
ii  chromium-driver61.0.3163.100-2
pn  chromium-l10n  
pn  chromium-shell 
pn  chromium-widevine  

-- Configuration Files:
/etc/apparmor.d/usr.bin.chromium changed [not included]

-- no debconf information
>From 3d35e9547fae383afd004608c9da646377caab66 Mon Sep 17 00:00:00 2001
Message-Id: <3d35e9547fae383afd004608c9da646377caab66.1506853631.git@sigxcpu.org>
From: =?UTF-8?q?Guido=20G=C3=BCnther?= 
Date: Sat, 30 Sep 2017 11:26:15 +0200
Subject: [PATCH] Add apparmor profile

The profile is based on the Ubuntu one and the one provided by Daniel
Richard G.
---
 debian/apparmor/usr.bin.chromium | 304 +++
 debian/chromium.install  |   2 +
 debian/control   |   1 +
 debian/rules |   1 +
 4 files changed, 308 insertions(+)
 create mode 100644 debian/apparmor/usr.bin.chromium

diff --git a/debian/apparmor/usr.bin.chromium b/debian/apparmor/usr.bin.chromium
new file mode 100644
index 000..472664d
--- /dev/null
+++ b/debian/apparmor/usr.bin.chromium
@@ -0,0 +1,304 @@
+# Author: Jamie Strandboge 
+#include 
+
+# Debian compatibility aliases
+# https://bugs.debian.org/742829
+#
+alias /etc/chromium-browser/ -> /etc/chromium/,
+alias /usr/bin/chromium-browser -> /usr/bin/chromium,
+alias /usr/lib/chromium-browser/chromium-browser-sandbox -> /usr/lib/chromium/chrome-sandbox,
+alias /usr/lib/chromium-browser/chromium-browser -> /usr/lib/chromium/chromium,
+alias /usr/lib/chromium-browser/ -> /usr/lib/chromium/,
+
+# We need 'flags=(attach_disconnected)' in newer chromium versions
+/usr/lib/chromium-browser/chromium-browser flags=(attach_disconnected) {
+  #include 
+  #include 
+  #include 
+  #include 
+  #include 
+  #include 
+  #include 
+  #include 
+
+  # Browser specific abstratctions
+  #include 
+  #include 
+  

Bug#742829: closed by intrigeri <intrig...@debian.org> (Bug#742829: fixed in apparmor 2.10.95-8)

[Guido Günther]

Hi Daniel,
On Fri, Sep 29, 2017 at 04:09:02PM -0400, Daniel Richard G. wrote:
> On Fri, 2017 Sep 29 00:18+0200, Guido Günther wrote:
> >
> > Attaching to this the report is fine. I can handle it from there.
> 
> Okay, greatly appreciated. My current profile is attached. Please Cc: me
> on the new bug report.
> 
> As it happens, this file is identical to the current version of the
> profile in the apparmor-profiles Git repository, with the exception of
> the Debian alias lines.
> 
> It seems that the AppArmor folks accepted my changes in the merge
> request, not by approving the merge, but by applying the changes to a
> new version-specific copy in the repo. They added a few more things of
> their own, which I have in turn merged into my/this copy.
> 
> I never heard anything from them about this, however; I learned about
> this only now that I diffed my profile with their latest. Their process
> could certainly stand to be more transparent.

> # Author: Jamie Strandboge <ja...@canonical.com>
> #include 
> 
> # Debian compatibility aliases
> # https://bugs.debian.org/742829
> #
> alias /etc/chromium-browser/ -> /etc/chromium/,
> alias /usr/bin/chromium-browser -> /usr/bin/chromium,
> alias /usr/lib/chromium-browser/chromium-browser-sandbox -> 
> /usr/lib/chromium/chrome-sandbox,
> alias /usr/lib/chromium-browser/chromium-browser -> 
> /usr/lib/chromium/chromium,
> alias /usr/lib/chromium-browser/ -> /usr/lib/chromium/,
> 
> # We need 'flags=(attach_disconnected)' in newer chromium versions
> /usr/lib/chromium-browser/chromium-browser flags=(attach_disconnected) {
>   #include 
>   #include 
>   #include 
>   #include 
>   #include 
>   #include 
>   #include 
>   #include 
> 
>   # This include specifies which ubuntu-browsers.d abstractions to use. Eg, if
>   # you want access to productivity applications, adjust the following file
>   # accordingly.
>   #include 

This file is currently not included in Debian's apparmor
package. @intrigeri, can this be added? I assume we don't want other
packages to mess around in abstractions? If not I can pull the code from
that file into the profile.

I'm attaching a patch against chromium here for reference.
Cheers,
 -- Guido

> 
>   # Networking
>   network inet stream,
>   network inet6 stream,
>   @{PROC}/[0-9]*/net/if_inet6 r,
>   @{PROC}/[0-9]*/net/ipv6_route r,
> 
>   # Should maybe be in abstractions
>   /etc/mime.types r,
>   /etc/mailcap r,
>   /etc/mtab r,
>   /etc/xdg/xubuntu/applications/defaults.list r,
>   owner @{HOME}/.local/share/applications/defaults.list r,
>   owner @{HOME}/.local/share/applications/mimeinfo.cache r,
> 
>   @{PROC}/[0-9]*/fd/ r,
>   @{PROC}/filesystems r,
>   @{PROC}/ r,
>   @{PROC}/[0-9]*/task/[0-9]*/stat r,
>   owner @{PROC}/[0-9]*/cmdline r,
>   owner @{PROC}/[0-9]*/io r,
>   owner @{PROC}/[0-9]*/setgroups w,
>   owner @{PROC}/[0-9]*/{uid,gid}_map w,
>   @{PROC}/[0-9]*/smaps r,
>   owner @{PROC}/[0-9]*/stat r,
>   @{PROC}/[0-9]*/statm r,
>   owner @{PROC}/[0-9]*/status r,
>   owner @{PROC}/[0-9]*/task/[0-9]*/status r,
>   deny @{PROC}/[0-9]*/oom_{,score_}adj w,
>   @{PROC}/sys/kernel/yama/ptrace_scope r,
>   @{PROC}/sys/net/ipv4/tcp_fastopen r,
> 
>   # Newer chromium needs these now
>   /etc/udev/udev.conf r,
>   /sys/devices/**/uevent r,
>   /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq r,
>   /sys/devices/system/node/node*/meminfo r,
>   /sys/devices/pci[0-9]*/**/class r,
>   /sys/devices/pci[0-9]*/**/device r,
>   /sys/devices/pci[0-9]*/**/irq r,
>   /sys/devices/pci[0-9]*/**/resource r,
>   /sys/devices/pci[0-9]*/**/vendor r,
>   /sys/devices/pci[0-9]*/**/removable r,
>   /sys/devices/pci[0-9]*/**/block/**/size r,
>   /sys/devices/virtual/block/**/removable r,
>   /sys/devices/virtual/block/**/size r,
>   /sys/devices/virtual/tty/tty*/active r,
>   # This is requested, but doesn't seem to actually be needed so deny for now
>   deny /run/udev/data/** r,
> 
>   # Needed for the crash reporter
>   owner @{PROC}/[0-9]*/auxv r,
> 
>   # chromium mmaps all kinds of things for speed.
>   /etc/passwd m,
>   /usr/share/fonts/truetype/**/*.tt[cf] m,
>   /usr/share/fonts/**/*.pfb m,
>   /usr/share/mime/mime.cache m,
>   /usr/share/icons/**/*.cache m,
>   owner /{dev,run}/shm/pulse-shm* m,
>   owner @{HOME}/.local/share/mime/mime.cache m,
>   owner /tmp/** m,
> 
>   @{PROC}/sys/kernel/shmmax r,
>   owner /{dev,run}/shm/{,.}org.chromium.* mrw,
>   owner /{,var/}run/shm/shmfd-* mrw,
> 
>   /usr/lib/chromium-browser/*.pak mr,
>   /usr/lib/chromium-browser/locales/* mr,
> 
>   # Noisy
>   deny /usr/lib/chromium-browser/** w,
> 
>   capabil

Bug#877322: git-buildpackage: FTBFS: openjade:E: cannot open "/usr/share/gtk-doc/data/gtk-doc.dsl" (No such file or directory)

[Guido Günther]

Hi,
On Sat, Sep 30, 2017 at 04:32:46PM +0200, Andreas Beckmann wrote:
> Source: git-buildpackage
> Version: 0.8.18
> Severity: serious
> Justification: fails to build from source
> 
> Hi,
> 
> after some recent change in sid, git-buildpackage in sid and
> experimental started to FTBFS:
> 
> [...]
> make -C docs
> make[3]: Entering directory '/build/git-buildpackage-0.8.18/docs'
> echo '' > version.ent
> docbook-2-html -s local manual.sgml
> openjade:W: feature "online" not supported
> openjade:W: feature "query" only partially supported
> openjade:E: cannot open "/usr/share/gtk-doc/data/gtk-doc.dsl" (No such file 
> or directory)

The gtk-doc package dropped the stylesheet in 1.26. gtk-doc maintainers
can this be added back please?
Cheers,
 -- Guido

> openjade:E: specification document does not have the DSSSL architecture as a 
> base architecture
> Building Debian Packages with 
> git-buildpackageGuidoGuentheragx@sigxcpu.orgVersion: 0.8.18Introduction  
> Welcome to git-buildpackage (short gbp), a system that integrates the
>   Debian package build
>   system with Git. The most
>   recent version of this manual can be found here.
>   This is what gbp can do for you:
> Initially import an existing Debian package into GitIncrementally import 
> new versions of a Debian
>   package into Git e.g. for importing NMUs or to maintain
>   downstream modificationsImport new upstream versions from tarballs with 
> optionally filters appliedRecreate the upstream tarball from information 
> stored in GitMaintain a consistent branch and tag naming within a Git 
> repository, across
> [...]
> 
> full log attached
> 
> 
> Andreas

Bug#875423: [Pkg-openssl-devel] Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)

[Guido Günther]

Hi,
On Fri, Sep 22, 2017 at 12:21:26AM +0200, Kurt Roeckx wrote:
> On Mon, Sep 11, 2017 at 12:30:30PM +0200, Raphael Hertzog wrote:
> > But in Debian testing, we have real end-users (direct and through
> > "rolling" derivatives) and they should not have to be impacted by this
> > experiment IMO.
> 
> I have to admit that I didn't consider derivatives that take a
> snapshot of testing, and we also seem to have a large amount of
> people that do use testing. My intention was to target the more
> advanced users, and having it in testing might be affecting more
> people than I thought.
> 
> So I am considering to only disable it in unstable and not in
> testing.

Please do. At least having it in unstable will allow us to use pinning
so one can again talk to not up to date services (which there are plenty
of).

Cheers,
 -- Guido

> 
> I'm actually surprised how few things broke.
> 
> 
> Kurt

Bug#876647: dh-apparmor: Please support /etc/apparmor.d/apache

[Guido Günther]

Hi,
On Sat, Sep 30, 2017 at 07:39:23AM +0200, intrigeri wrote:
> Hi,
> 
> Guido Günther:
> > if a package drops a file into /etc/apparmor.d/apache we should do a
> 
> >   apparmor_parser -r 
> > /etc/apparmor.d/usr.lib.apache2.mpm-prefork.apache2
> 
> I can't find any such profile in current sid. Apparently since a few

Since it's still sitting in new ;)


https://anonscm.debian.org/cgit/pkg-giraffe/kopano-webapp.git/commit/?id=7310d19e1de2bb028f81a5971de724e7af62d5a5

> years it's rather something like "if a package drops a file in
> /etc/apparmor.d/apache2.d then we should reload the usr.sbin.apache2
> profile". Right?

Exactly!

> 
> > Since dh-apparmor has all the logic to detect that aa is in use it
> > would be great if it would handle this case as well.
> 
> Agreed, this would be a nice addition! :)
> 
> FTR I don't use AppArmor for Apache personally so there's very little
> chance I work on this any time soon. Patches are welcome.
> 
> > This would make sure we handle things like #872266 too once fixed.
> 
> Now you make me curious: I don't understand how this is related.

I just meant to say that once dh-apparmor unloads profiles this would
then automatically work for the above case as well once added to
dh-apparmor. So we get consistency within Debian (rather than having
some applications unload the profile on removal while others don't).
Cheers,
 -- Guido

Bug#876731: stretch-pu: package osinfo-db/0.20170225-3~deb9u1

[Guido Günther]

Hi,
On Fri, Sep 29, 2017 at 06:45:37PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2017-09-25 at 12:43 +0200, Guido Günther wrote:
> > I'd like to update osinfo-db in stretch. This would allow us to have
> > up
> > to date information for operating system installs with e.g. gnome-
> > boxes
> > by adding new data for recent centos, ubuntu and freebsd releases as
> > well as updating existing ones.
> > 
> > This version also included all our debian/patches/.
> > 
> > Since it's a new upstream version I've attached the full diff. Note
> > that
> > osinfo-db was split out from libosinfo to facilitate this kind of
> > upgrades.
> > 
> 
> Please go ahead, bearing in mind that the window for 9.2 closes during
> this weekend.

Uploaded. Thanks!
 -- Guido

Bug#742829: closed by intrigeri <intrig...@debian.org> (Bug#742829: fixed in apparmor 2.10.95-8)

[Guido Günther]

Hi,
On Thu, Sep 28, 2017 at 05:20:51PM -0400, Daniel Richard G. wrote:
> On Thu, 2017 Sep 28 22:07+0200, Guido Günther wrote:
> >
> > I would have hoped you'd simply report wishlist bug against chromium
> > with the new profile attached? This gives us a bug to track for futher
> > discussion. I'd do it myself but my profile is less well tested since
> > I just hacked it up a couple of days ago.
> 
> Lately, I'm not in a good position to get so involved here. Replying to
> inquiries is one thing; opening new bugs and starting new discussions
> is another.
> 
> I'll provide the profile, but someone else would have to handle the
> bug/discussion legwork needed to get it into Debian.

Attaching to this the report is fine. I can handle it from there.
 -- Guido

Bug#742829: closed by intrigeri <intrig...@debian.org> (Bug#742829: fixed in apparmor 2.10.95-8)

[Guido Günther]

Hi,
On Thu, Sep 28, 2017 at 03:07:15PM -0400, Daniel Richard G. wrote:
> On Thu, 2017 Sep 28 11:21+0200, Guido Günther wrote:
> >
> > > That would amount to the Debian Chromium maintainers becoming the
> > > new upstream for the profile. (Apparmor is basically maintained by
> >
> > Or maybe people caring about the chromium profile like you, me and
> > others in this thread.
> 
> You still need someone to actually upload it to Debian. It doesn't do
> much good if I have a current profile in GitHub somewhere and
> Debian/Ubuntu fail to pick it up.
> 
> > > I don't know any of the Debian-Chromium folks to have a sense of
> > > what they're open to; would you?
> >
> > Unfortunately not.
> >
> > > I'll be happy to provide that updated Chromium profile if you
> > > want it.
> >
> > Could you attach this to new bug against Chromium. If you'd be willing
> > to maintain the profile longterm I'd add that to the report too.
> 
> I'll be happy to attach it; just let this thread know the new bug
> number.
> 
> Before that, however, you may want to bring this up on a Debian mailing
> list, to get a feel for things.

I would have hoped you'd simply report wishlist bug against chromium
with the new profile attached? This gives us a bug to track for futher
discussion. I'd do it myself but my profile is less well tested since I
just hacked it up a couple of days ago.
Cheers,
 -- Guido

Bug#742829: closed by intrigeri <intrig...@debian.org> (Bug#742829: fixed in apparmor 2.10.95-8)

[Guido Günther]

Hi,
On Wed, Sep 27, 2017 at 04:47:27PM -0400, Daniel Richard G. wrote:
> On Wed, 2017 Sep 27 22:26+0200, Guido Günther wrote:
> >
> > Great! I'm a big fan of doing things upstream but from my pov I'd
> > consider apparmor or chromium to be upstream not Ubuntu. What about
> > filing a bug against the Debian chromium package with an updated
> > profile as a start? We can then take it from there and file another
> > one against apparor once it proves working for more people.
> 
> That would amount to the Debian Chromium maintainers becoming the new
> upstream for the profile. (Apparmor is basically maintained by

Or maybe people caring about the chromium profile like you, me and
others in this thread.

> Canonical, so also Ubuntu, and Google pretty surely will never touch
> this.) If they're willing, I can hardly see how they could do worse
> than Ubuntu.
> 
> And if it does work out, then that would be a basis to have Ubuntu ship
> the Debian profile instead of its own (neglected) version.
> 
> I don't know any of the Debian-Chromium folks to have a sense of what
> they're open to; would you?

Unfortunately not.

> I'll be happy to provide that updated Chromium profile if you want it.

Could you attach this to new bug against Chromium. If you'd be willing to
maintain the profile longterm I'd add that to the report too.

Cheers,
 -- Guido

Bug#742829: closed by intrigeri <intrig...@debian.org> (Bug#742829: fixed in apparmor 2.10.95-8)

[Guido Günther]

Hi Richard,
On Wed, Sep 27, 2017 at 03:49:48PM -0400, Daniel Richard G. wrote:
> Hi Guido!
> 
> On Wed, 2017 Sep 27 15:31+0200, Guido Günther wrote:
> > 
> > I stumbled across this today again since I was looking for a chromium
> > profile and still had one in /etc/apparmor.d/usr.bin.chromium-browser
> > so it seems the fix for 742829 didn't remove existing files:
> > 
> >$ dpkg -S /etc/apparmor.d/usr.bin.chromium-browser 
> >apparmor-profiles: /etc/apparmor.d/usr.bin.chromium-browse
> > 
> > So I ended up writing the same fixes in that were already suggested
> > here and I wonder why we can't just ship a profile if it's working
> > for people?
> 
> You'll get no argument from me :)  The main difficulty I've had is
> getting upstream (Ubuntu) to accept patches to fix the profile whenever
> Chromium's footprint gets bigger.

Great! I'm a big fan of doing things upstream but from my pov I'd
consider apparmor or chromium to be upstream not Ubuntu. What about
filing a bug against the Debian chromium package with an updated profile
as a start? We can then take it from there and file another one against
apparor once it proves working for more people.
Cheers,
 -- Guido

> 
> Case in point: No one's looked at this (old) merge request since it
> was posted, even though I was told to file a merge request to get
> my fixes in:
> 
> 
> https://code.launchpad.net/~skunk/apparmor-profiles/+git/apparmor-profiles/+merge/321802
> 
> I wouldn't mind officially maintaining the Chromium profile myself,
> given that I already do so for my own use and would like to see others
> benefit as well.
> 
> > That said I'd rather see this shipped with the chromium package so we
> > could reassign this (or open a separate report).
> 
> I'd like to see this happen too, if for no other reason than that the
> Chromium profile is currently maintained in a sort of no-man's land on
> the Ubuntu side.
> 

Bug#742829: closed by intrigeri <intrig...@debian.org> (Bug#742829: fixed in apparmor 2.10.95-8)

[Guido Günther]

control: reopen -1 742829

Hi,
On Wed, Sep 27, 2017 at 03:31:26PM +0200, Guido Günther wrote:
> Hi,
> On Sat, Dec 17, 2016 at 03:21:07PM +, Debian Bug Tracking System wrote:
> > This is an automatic notification regarding your Bug report
> > which was filed against the apparmor-profiles package:
> > 
> > #742829: Chromium browser profile not adapted to Debian packaging
> > 
> > It has been closed by intrigeri <intrig...@debian.org>.
> 
> I stumbled across this today again since I was looking for a chromium
> profile and still had one in /etc/apparmor.d/usr.bin.chromium-browser so
> it seems the fix for 742829 didn't remove existing files:
> 
>$ dpkg -S /etc/apparmor.d/usr.bin.chromium-browser 
>apparmor-profiles: /etc/apparmor.d/usr.bin.chromium-browse
> 
> So I ended up writing the same fixes in that were already suggested here
> and I wonder why we can't just ship a profile if it's working for people?
> 
> That said I'd rather see this shipped with the chromium package so we
> could reassign this (or open a separate report).
> 
> Cheers,
>  -- Guido

Bug#876800: git-buildpackage: gbp pq import recommends 'rebase', but rebase recommends 'import'

[Guido Günther]

Hi dkg,
On Tue, Sep 26, 2017 at 02:32:38AM -0400, Daniel Kahn Gillmor wrote:
> Package: git-buildpackage
> Version: 0.9.0~exp6
> Severity: normal
> 
> Dear Maintainer,
> 
> Consider the following frustrating interaction with gbp pq:
> 
> 0 dkg@alice:~/src/libreswan/libreswan$ gbp pq rebase
> gbp:error: Rebase must be run from the patch-queue branch. Try 'import' 
> instead.
> 1 dkg@alice:~/src/libreswan/libreswan$ gbp pq import
> gbp:error: Patch queue branch 'patch-queue/master'. already exists. Try 
> 'rebase' instead.
> 1 dkg@alice:~/src/libreswan/libreswan$ gbp pq rebase
> gbp:error: Rebase must be run from the patch-queue branch. Try 'import' 
> instead.
> 1 dkg@alice:~/src/libreswan/libreswan$
> 
> 
> If i didn't already know about "gbp pq switch" i might have been stuck
> in that loop for days! :P

Let's hope the loop leaks a tiny bit of memory each time so OOM can come
to the rescue at one point!

> This seems like new (mis)behavior to me.  I'm pretty sure that with
> some other recent version "gbp pq rebase" from the master branch was
> effectively first a "switch" followed by a "rebase"

It's a side effect of 2320e1969145546688a6cd06d82fbeed78897046. I'll fix
that.
Cheers,
 -- Guido

Bug#876744: Multiple CVEs in sam2p

[Guido Günther]

Package: sam2p
X-Debbugs-CC: t...@security.debian.org 
secure-testing-t...@lists.alioth.debian.org
Severity: grave
Tags: security

Hi,

the following vulnerabilities were published for sam2p.

CVE-2017-14637[0]:
| In sam2p 0.49.3, there is an invalid read of size 2 in the parse_rgb
| function in in_xpm.cpp. However, this can also cause a write to an
| illegal address.

CVE-2017-14636[1]:
| Because of an integer overflow in sam2p 0.49.3, a loop executes
| 0x times, ending with an invalid read of size 1 in the
| Image::Indexed::sortPal function in image.cpp. However, this also
| causes memory corruption because of an attempted write to the invalid
| d[0xfffe] array element.

CVE-2017-14628[2]:
| In sam2p 0.49.3, a heap-based buffer overflow exists in the
| pcxLoadImage24 function of the file in_pcx.cpp.

CVE-2017-14629[3]:
| In sam2p 0.49.3, the in_xpm_reader function in in_xpm.cpp has an
| integer signedness error, leading to a crash when writing to an
| out-of-bounds array element.

CVE-2017-14630[4]:
| In sam2p 0.49.3, an integer overflow exists in the pcxLoadImage24
| function of the file in_pcx.cpp, leading to an invalid write operation.

CVE-2017-14631[5]:
| In sam2p 0.49.3, the pcxLoadRaster function in in_pcx.cpp has an
| integer signedness error leading to a heap-based buffer overflow.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-14637
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14637
[1] https://security-tracker.debian.org/tracker/CVE-2017-14636
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14636
[2] https://security-tracker.debian.org/tracker/CVE-2017-14628
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14628
[3] https://security-tracker.debian.org/tracker/CVE-2017-14629
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14629
[4] https://security-tracker.debian.org/tracker/CVE-2017-14630
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14630
[5] https://security-tracker.debian.org/tracker/CVE-2017-14631
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14631

Please adjust the affected versions in the BTS as needed.

Bug#876731: stretch-pu: package osinfo-db/0.20170225-3~deb9u1

[Guido Günther]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi,
I'd like to update osinfo-db in stretch. This would allow us to have up
to date information for operating system installs with e.g. gnome-boxes
by adding new data for recent centos, ubuntu and freebsd releases as
well as updating existing ones.

This version also included all our debian/patches/.

Since it's a new upstream version I've attached the full diff. Note that
osinfo-db was split out from libosinfo to facilitate this kind of
upgrades.

O.k. to upload to stretch-p-u?
Cheers,
 -- Guido


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/Makefile b/Makefile
index 6ff9b5c..1846f7a 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,11 @@
 
 VPATH = .
 
-TODAY = $(shell date +"%Y%m%d")
+ifdef SOURCE_DATE_EPOCH
+TODAY = $(shell date --utc --date="@$(SOURCE_DATE_EPOCH)" +"%Y%m%d")
+else
+TODAY = $(shell date +"%Y%m%d")
+endif
 
 OSINFO_DB_EXPORT = osinfo-db-export
 OSINFO_DB_IMPORT = osinfo-db-import
@@ -27,6 +31,8 @@ ARCHIVE = osinfo-db-$(TODAY).tar.xz
 
 ZANATA = zanata-cli
 
+XMLLINT = xmllint
+
 V = 0
 
 V_I18N = $(V_I18N_$(V))
@@ -79,7 +85,7 @@ clean:
 	rm -f $(DATA_FILES) $(SCHEMA_FILES) po/POTFILES.in po/osinfo-db.pot
 
 po/POTFILES.in:
-	$(V_GEN) find data -name *.xml.in > $@
+	$(V_GEN) find data -name *.xml.in | LC_ALL=C sort > $@
 
 po/osinfo-db.pot: po/POTFILES.in $(DATA_FILES_IN)
 	$(V_GEN) cd po && $(INTLTOOL_UPDATE) --gettext-package $(GETTEXT_PACKAGE) --pot
@@ -114,3 +120,10 @@ update-po:
   fi; \
 done
 
+check: $(DATA_FILES) $(SCHEMA_FILES)
+	for xml in `find data -name '*.xml' | sort`; do \
+	  if ! $(XMLLINT) --relaxng data/schema/osinfo.rng --noout $$xml; then \
+	exit 1; \
+	  fi; \
+	done
+
diff --git a/README b/README
index b2822cb..9f2f3af 100644
--- a/README
+++ b/README
@@ -17,6 +17,21 @@ Dependencies
 - Required:
   - osinfo-db-tools
   - intltool
+- Optional:
+  - xmllint (from libxml2) -- for testing
+
+Build reproducibility
+=
+
+To build libosinfo reproduciblity, you should export the SOURCE_DATE_EPOCH[0]
+environment variable to the build system. For example:
+
+$ export SOURCE_DATE_EPOCH="$(date +%s)"
+$ ./configure [...]
+$ make
+[...]
+
+[0] https://reproducible-builds.org/specs/source-date-epoch/
 
 Patch submissions
 =
diff --git a/data/install-script/fedoraproject.org/fedora-kickstart-desktop.xml.in b/data/install-script/fedoraproject.org/fedora-kickstart-desktop.xml.in
index 6f53299..bdc9f5d 100644
--- a/data/install-script/fedoraproject.org/fedora-kickstart-desktop.xml.in
+++ b/data/install-script/fedoraproject.org/fedora-kickstart-desktop.xml.in
@@ -176,13 +176,13 @@ useradd -G wheel  # Add user
 if test -z ''; then
 passwd -d  # Make user account passwordless
 else
-echo  |passwd --stdin 
+echo '' |passwd --stdin 
 fi
 
 if test -z ''; then
 passwd -d root # Make root account passwordless
 else
-echo  |passwd --stdin root
+echo '' |passwd --stdin root
 fi
 
 # Set user avatar
diff --git a/data/install-script/opensuse.org/opensuse-autoyast-desktop.xml.in b/data/install-script/opensuse.org/opensuse-autoyast-desktop.xml.in
index 04399b5..6554eb6 100644
--- a/data/install-script/opensuse.org/opensuse-autoyast-desktop.xml.in
+++ b/data/install-script/opensuse.org/opensuse-autoyast-desktop.xml.in
@@ -31,7 +31,7 @@
 xmlns:xsl="http://www.w3.org/1999/XSL/Transform;
 version="1.0">
 
-
+
 
 
   
@@ -119,7 +119,7 @@
   
   
 true
- resume=/dev/vda1 splash=silent quiet showopts
+resume=/dev/vda1 splash=silent quiet showopts
 false
 false
 false
@@ -215,18 +215,16 @@
 

Bug#876668: postinst is inconsistent

[Guido Günther]

control: reopen -1

Hi,
On Sun, Sep 24, 2017 at 07:26:45PM +0200, Mattia Rizzolo wrote:
> Hi Guido!
> 
> On Sun, Sep 24, 2017 at 06:58:07PM +0200, Guido Günther wrote:
> > Package: kopano-webapp-apache2
> 
> I can't find the package you mention below in the debian archive.  There
> is a kopano source package, with a binary that suggests kopano-webapp,
> but no kopano-webapp-apache2.
> 
> I'm closing this bug, as I believe you are running something that is not
> from the debian archive.

kopano-webapp is in NEW and so I think it makes sense to use the bug
tracker already to make sure things don't get lost (or is this
considered bad practice?).
Cheers,
 -- Guido

Bug#876668: postinst is inconsistent

[Guido Günther]

Package: kopano-webapp-apache2
Version: 3.3.1-1
Severity: normal

The postinst enables two apache modules (ssl and rewrite) but not
kopano-webapp itself. This is inconsistent. Either enable the whole site
or do nothing at all.
Cheers,
 -- Guido


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#876647: dh-apparmor: Please support /etc/apparmor.d/apache

[Guido Günther]

Package: dh-apparmor
Version: 2.11.0-11
Severity: wishlist

Hi,
if a package drops a file into /etc/apparmor.d/apache we should do a

  apparmor_parser -r /etc/apparmor.d/usr.lib.apache2.mpm-prefork.apache2

if apparmor is enabled. Since dh-apparmor has all the logic to detect
that aa is in use it would be great if it would handle this case as
well. This would make sure we handle things like #872266 too once fixed.
Cheers,
 -- Guido


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

dh-apparmor depends on no packages.

dh-apparmor recommends no packages.

Versions of packages dh-apparmor suggests:
pn  apparmor-easyprof  

-- no debconf information

Bug#874663: Document +dfsg as extenson when repacking upstream sources

[Guido Günther]

Hi,
On Fri, Sep 08, 2017 at 06:44:03PM +0100, Simon McVittie wrote:
> On Fri, 08 Sep 2017 at 16:10:44 +0200, Guido Günther wrote:
> > when upstream tarballs need to be repacked because they contain non-dfsg
> > free data appending '+dfsg' to the upstream version seems common
> > practice. However some packages append '.dfsg', others use
> > +dfsg and there are more formats around.
> 
> It's a coincidence that you should mention this today. I've just run
> into a situation where routinely appending +dfsg causes brokenness:
> 
> * upstream releases iortcw 1.51
> * I package iortcw 1.51+dfsg1-1
> * upstream releases iortcw 1.51b
> * I package iortcw 1.51b+dfsg1-1
> * oops! 1.51b+dfsg1 << 1.51+dfsg1, because b << +
> * workaround: I had to relabel upstream's release as 1.51.b
> 
> This made me think that we should maybe only be doing this when
> a *pre-existing* upstream version needs to be repacked. For example,
> if foo/1.2.3 is found to be non-free after it is already in the
> archive, the maintainer would repack it as 1.2.3+dfsg to get a new
> orig.tar for the same upstream version; but when upstream releases
> foo/1.2.4, even if the non-freeness has not been fixed, the
> maintainer would repack it as 1.2.4 rather than 1.2.4+dfsg.
> 
> That would make +dsfg into a temporary hack a bit like the +really
> (anti-)pattern, rather than something long-lived that is routinely
> applied to upstreams whose release tarballs are not entirely Free
> (ioquake3 and its non-commercial bytecode compiler, gcc/make and
> their non-DFSG docs, anything that bundles RFCs, etc.).
> 
> I notice that make and gcc don't routinely decorate their version numbers
> in this way, and perhaps they're right to not do so.
> 
> > This would make it simpler for tools like lintian or gbp to detect repacked
> > tarballs (in this case we don't want to attach the upstream signature to
> > the chages file).
> 
> Why would the maintainer of such a package want to (arrange for uscan
> to) rename the signature to foo_1.2.3.orig.tar.gz.asc where it would be
> picked up by gbp? The signature is never going to validate successfully on
> the orig tarball, so there is no point in doing that rename.

That's basically the point: make it simple for people and tools to
figure out that it is a repacked tarball and therefore e.g. the
signature doesn't need to be attached. It also makes it simple for other
tools down the chain that there shouldn't be a signature (e.g. lintian
which warns about missing upstream signatures doesn't do so if it finds
+dfsg in the tarball name). Another reason is that people might want to
grab the upstream tarball when examining things (e.g. security issues)
since the Debian tarball isn't complete.

> For repacked packages, if uscan is used at all, it would seem best for
> debian/watch to instruct uscan to download the signature, use it to
> verify the non-repacked tarball, repack the tarball excluding problematic
> files, and *not* rename the signature to the name that contains .orig.
> gbp won't see it, and is happy.

That's ok for uscan -> gbp but not for e.g. lintian checking later if
there should be a signature.

> Lintian can detect that the tarball was repacked by looking inside
> at the first few tar members - a repacked tarball is meant to
> contain only a foo_1.2.3.orig/ directory (devref §6.7.8.2.4) and
> non-repacked tarballs are unlikely to do so. In this case, ignoring
> debian/upstream/signing-key.asc for the purposes of deciding whether there
> ought to be an upstream signature would seem like a good Lintian
> feature request?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871957#36

Cheers,
 -- Guido

Bug#876480: Don't ship /usr/share/doc/kopano-server/example-config/zcontacts.inf

[Guido Günther]

Package: kopano-server
Version: 8.3.4-2
Severity: minor

The identical file is shipped in /etc/mapi/zcontacts.inf by
kopano-contacts.
 -- Guido

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages kopano-server depends on:
ii  dbconfig-common  2.0.9
ii  debconf  1.5.63
pn  kopano-common
pn  kopano-libs  
ii  libc62.24-17
ii  libcomerr2   1.43.6-1
ii  libgcc1  1:7.2.0-5
ii  libgsoap-2.8.49  2.8.49-1
ii  libgssapi-krb5-2 1.15.1-2
ii  libicu57 57.1-6
ii  libk5crypto3 1.15.1-2
ii  libkrb5-31.15.1-2
ii  libldap-2.4-22.4.45+dfsg-1
ii  libmariadbclient18   10.1.26-1
ii  libpam0g 1.1.8-3.6
ii  libssl1.11.1.0f-5
ii  libstdc++6   7.2.0-5
ii  libuuid1 2.29.2-5
ii  lsb-base 9.20170808
pn  mariadb-client | default-mysql-client | virtual-mysql-clien  
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages kopano-server recommends:
pn  mariadb-server | default-mysql-server  

kopano-server suggests no packages.

Bug#875892: apache2 needs attach_disconnected

[Guido Günther]

Hi,
On Wed, Sep 20, 2017 at 04:50:08PM +0200, intrigeri wrote:
> Control: reassign -1 libapache2-mod-apparmor
> Control: tag -1 + upstream
> Control: forwarded -1 
> https://code.launchpad.net/~intrigeri/apparmor/apache2-attach_disconnected/+merge/331065
> 
> Hi,
> 
> Guido Günther:
> > Patch attached (I'd send this upstream but bzr).
> 
> Thanks, forwarded!
> 
> Does libapache2-mod-apparmor break apache2 startup when the profile is
> in complain mode (the default)? If yes, then I'll cherry-pick this.
> Otherwise it'll wait for the next upstream release (I'm trying to
> focus on policy that's enabled by default).

The default is confined so next upstream release is perfectly o.k. from
my side. Thanks for forwarding this!
 -- Guido

Bug#876071: [Pkg-libvirt-maintainers] Bug#876071: Bug#876071: libvirt-daemon-system: Mount namespace and AppArmor confinement are incompatible => breaks networking

[Guido Günther]

Hi,
On Mon, Sep 18, 2017 at 11:13:02AM +0200, intrigeri wrote:
> Hi,
> 
> Guido Günther:
> > control: forwarded -1 
> > https://www.redhat.com/archives/libvir-list/2017-September/msg00457.html
> 
> > I saw the same on Friday and used the patch reference above (which
> > basically does the same, you were on cc: ;)…
> 
> Oops, sorry! Email sent to my +libvirt@ email address lands into
> a folder dedicated to libvir-l...@redhat.com, that I admit I read only
> from time to time given the amount of traffic :/

…and I missed to add Acked-By for your ACKs since I didn't read the ML
first. Sorry.

> > Should that make a difference? Did you check if the vm profile did get
> > recreated correclt?
> 
> My bad again: adding attach_disconnected is enough once I delete the
> VM profile to force it to be updated. (But by the way, off-topic:
> shouldn't this happen automatically when the template is updated?)

In my naive world I would expect the profile to be deleted on VM
shutdown. virt-aa-helper even has a -D option and I enabled (this instead
of only unloading the profile) with the current upload.
Cheers,
 -- Guido

> 
> At least this bug documents the problem for Debian users :)
> 
> Thanks!
> 
> ___
> Pkg-libvirt-maintainers mailing list
> pkg-libvirt-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers

Bug#863266: bug 863266 is forwarded to https://bugzilla.redhat.com/show_bug.cgi?id=1432684

[Guido Günther]

Hi,
On Mon, Sep 18, 2017 at 10:15:33AM +0200, Marc Haber wrote:
> On Fri, Sep 15, 2017 at 12:18:12PM +0200, Guido Günther wrote:
> > Let's reassign to the kernel then.
> > 
> > Dear kernel maintainers. The symptom is that libvirt fails to detect
> > ports already in use for spice. See
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1432684#c17
> > 
> > for a simple testcase not involving libvirt at all. I'll post the
> > summary (by Cole Robinson) here:
> 
> Patches on http://www.spinics.net/lists/netdev/msg454644.html and
> onwards, four pieces, all needed. I verified that they fix the issue on
> Debian stable with a vanilla 4.13.2 kernel.

Thanks for testing and following up on this. Hopefully we'll see this in
the Debian kernels soon.
Cheers,
 -- Guido

Bug#876071: [Pkg-libvirt-maintainers] Bug#876071: libvirt-daemon-system: Mount namespace and AppArmor confinement are incompatible => breaks networking

[Guido Günther]

control: forwarded -1 
https://www.redhat.com/archives/libvir-list/2017-September/msg00457.html

Hi,
On Mon, Sep 18, 2017 at 09:33:45AM +0200, intrig...@debian.org wrote:
> Package: libvirt-daemon-system
> Version: 3.7.0-2
> Severity: normal
> 
> Hi,
> 
> since some fairly recent sid upgrade, my VMs don't get network
> anymore and my logs contain lots of:
> 
>   kernel: audit: type=1400 audit(1505719435.761:27425226): apparmor="DENIED" 
> operation="file_perm" info="Failed name lookup - disconnected path" error=-13 
> profile="libvirt-213ff882-ce4b-035d-e2b1-9059d66cd67d" name="dev/net/tun" 
> pid=25947 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=119 
> ouid=0
> 
> I've tried passing flags=(attach_disconnected) in
> /etc/apparmor.d/libvirt/TEMPLATE.qemu but that did not fix the bug for
> some reason, so I've reverted this change.

I saw the same on Friday and used the patch reference above (which
basically does the same, you were on cc: ;)…

> 
> My current workaround is to disable private mount namespaces in
> /etc/libvirt/qemu.conf:
> 
>   namespaces = [ ]
> 
> FWIW the network these VMs are connected to looks like:
> 
> 
>   routed
>   054fadcc-23da-4014-94e7-cdde77924045
>   
>   
> […]
> 

… however I'm using


  
  
  
  


Should that make a difference? Did you check if the vm profile did get
recreated correclt?
Cheers,
 -- Guido

> 
> Cheers!
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (500, 'stable-updates'), (500, 
> 'oldstable-updates'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), 
> (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.12.0-2-amd64 (SMP w/4 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 /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages libvirt-daemon-system depends on:
> ii  adduser  3.116
> ii  debconf  1.5.63
> ii  gettext-base 0.19.8.1-4
> ii  init-system-helpers  1.49
> ii  iptables 1.6.1-2
> ii  libacl1  2.2.52-3+b1
> ii  libapparmor1 2.11.0-10
> ii  libaudit11:2.7.7-1+b2
> ii  libblkid12.29.2-5
> ii  libc62.24-17
> ii  libcap-ng0   0.7.7-3+b1
> ii  libdbus-1-3  1.11.16+really1.10.22-1
> ii  libdevmapper1.02.1   2:1.02.142-1
> ii  libnl-3-200  3.2.27-2
> ii  libnl-route-3-2003.2.27-2
> ii  libnuma1 2.0.11-2.1
> ii  libselinux1  2.7-2
> ii  libvirt-clients  3.7.0-2
> ii  libvirt-daemon   3.7.0-2
> ii  libvirt0 3.7.0-2
> ii  libxml2  2.9.4+dfsg1-4
> ii  libyajl2 2.1.0-2+b3
> ii  logrotate3.11.0-0.1
> ii  lsb-base 9.20170808
> ii  policykit-1  0.105-18
> 
> Versions of packages libvirt-daemon-system recommends:
> ii  bridge-utils  1.5-14
> ii  dmidecode 3.1-1
> ii  dnsmasq-base  2.77-2
> ii  ebtables  2.0.10.4-3.5+b1
> ii  iproute2  4.9.0-2
> ii  parted3.2-17
> 
> Versions of packages libvirt-daemon-system suggests:
> ii  apparmor2.11.0-10
> pn  auditd  
> ii  nfs-common  1:1.3.4-2.1+b1
> ii  pm-utils1.4.1-17
> ii  radvd   1:2.16-3
> ii  systemd 234-3
> pn  systemtap   
> pn  zfsutils
> 
> -- debconf information:
>   libvirt-daemon-system/id_warning: true
> 
> -- 
> intrigeri
> 
> ___
> Pkg-libvirt-maintainers mailing list
> pkg-libvirt-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers

Bug#876038: python-dateutil: tzical is not thread-safe

[Guido Günther]

Hi,
On Sun, Sep 17, 2017 at 08:38:32PM +0200, Jonas Smedegaard wrote:
> Package: python-dateutil
> Version: 2.6.1-1
> Severity: normal
> Tags: patch
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> tzical is not thread-safe, affecting VObject and consequently Radicale:
> https://github.com/Kozea/Radicale/issues/675
> 
> Upstream adopted a patch, but it seems they do not expect to issue any
> further bugfix releases for several months:
> https://github.com/dateutil/dateutil/pull/430

Too bad python-dateutil is not pushing out things more frequently:

https://github.com/dateutil/dateutil/issues/452

> Please therefore consider cherry-picking upstream fix from above link.

Will do. 
Cheers,
 -- Guido

Bug#875892: apache2 needs attach_disconnected

[Guido Günther]

Package: apparmor-profiles
Version: 2.11.0-10
Severity: normal
Tags: patch

otherwise we fail with

   apparmor="ALLOWED" operation="file_mmap" info="Failed name lookup - 
disconnected path" error=-13 profile="/usr/sbin/apache2" name="" pid=13777 
comm="apache2" requested_mask="rw" denied_mask="rw" fsuid=0 ouid=0

Patch attached (I'd send this upstream but bzr).
 -- Guido
>From e1baa8286065f0ebd830e1dbfb970f3089b45f94 Mon Sep 17 00:00:00 2001
Message-Id: 
From: =?UTF-8?q?Guido=20G=C3=BCnther?= 
Date: Fri, 15 Sep 2017 18:26:07 +0200
Subject: [PATCH] apache2: use attach_disconnected

otherwise we fail with

apparmor="ALLOWED" operation="file_mmap" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/apache2" name="" pid=13777 comm="apache2" requested_mask="rw" denied_mask="rw" fsuid=0 ouid=0
---
 profiles/apparmor.d/usr.sbin.apache2 | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/profiles/apparmor.d/usr.sbin.apache2 b/profiles/apparmor.d/usr.sbin.apache2
index 25a147f..987a100 100644
--- a/profiles/apparmor.d/usr.sbin.apache2
+++ b/profiles/apparmor.d/usr.sbin.apache2
@@ -1,7 +1,7 @@
 # Author: Marc Deslauriers 
 
 #include 
-/usr/sbin/apache2 {
+/usr/sbin/apache2 flags=(attach_disconnected) {
 
   # This profile is completely permissive.
   # It is designed to target specific applications using mod_apparmor,
@@ -84,7 +84,7 @@
   /** mrwlkix,
 
 
-  ^DEFAULT_URI {
+  ^DEFAULT_URI flags=(attach_disconnected) {
 #include 
 #include 
 
@@ -92,7 +92,7 @@
 /** mrwlkix,
   }
 
-  ^HANDLING_UNTRUSTED_INPUT {
+  ^HANDLING_UNTRUSTED_INPUT flags=(attach_disconnected) {
 #include 
 
 / rw,
-- 
2.14.1

Bug#875890: Please consider shipping /etc/apparmor.d/usr.sbin.mysqld from upstream

[Guido Günther]

Package: mariadb-server
Version: 10.1.26-1
Severity: wishlist

Hi,
it would be great if the package would ship upstream's profile (even if
only in complain mode like upstream does). This would help to iron out
the issues in the profile.

The current file file that starts like:

# This file is intensionally empty to disable apparmor by default for newer
# versions of MariaDB, while providing seamless upgrade from older versions
# and from mysql, where apparmor is used.

# By default, we do not want to have any apparmor profile for the MariaDB
# server. It does not provide much useful functionality/security, and causes
# several problems for users who often are not even aware that apparmor
# exists and runs on their system.

is a bit discouraging.

Cheers,
 -- Guido

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-updates'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages mariadb-server depends on:
pn  mariadb-server-10.1  
pn  mariadb-server-10.3  

mariadb-server recommends no packages.

mariadb-server suggests no packages.

Bug#863266: bug 863266 is forwarded to https://bugzilla.redhat.com/show_bug.cgi?id=1432684

[Guido Günther]

control: reassign -1 linux
control: found -1 linux/4.12.6-1
control: affects -1 libvirt-daemon-system

Hi,
On Fri, Sep 15, 2017 at 11:30:55AM +0200, Marc Haber wrote:
> On Sat, Sep 09, 2017 at 12:21:01PM +0200, Guido Günther wrote:
> > forwarded 863266 https://bugzilla.redhat.com/show_bug.cgi?id=1432684
> 
> That's it. Will try reverting 319554f284dda9f2737d09df82ba3610bd8ddea3
> in my kernel.

Let's reassign to the kernel then.

Dear kernel maintainers. The symptom is that libvirt fails to detect
ports already in use for spice. See

https://bugzilla.redhat.com/show_bug.cgi?id=1432684#c17

for a simple testcase not involving libvirt at all. I'll post the
summary (by Cole Robinson) here:

# This bit of code helps demonstrate the issue. There's definitely
#  something weird going on. The port check logic is adapted from
#  libvirt's code, I can't speak to all the bits there.
# 
# In a separate terminal, qemu-kvm -vnc 127.0.0.1:0 to grab port 5900. Then do 
this:
# 
# $ gcc bind-collision.c && ./a.out
# bind: Address already in use
# AF_INET check failed.
# $ gcc -D CHECK_IPV6 bind-collision.c && ./a.out
# AF_INET6 success
# AF_INET success
# $ gcc bind-collision.c && ./a.out
# AF_INET success
#
# By default the script will just check to see if we can bind to ipv4
# 5900. When qemu is holding that port, this check rightfully
# fails. When we compile with -D CHECK_IPV6, this adds ipv6 checking
# first. This succeeds, and then all subsequent ipv4 checks also
# succeed, which seems wrong.

Cheers,
 -- Guido

Bug#875834: [Pkg-libvirt-maintainers] Bug#875834: glusterfs-common should not be required by libvirt-daemon

[Guido Günther]

Hi,
On Fri, Sep 15, 2017 at 12:15:52AM +0200, Michael Biebl wrote:
> Package: libvirt-daemon
> Version: 3.7.0-2
> Severity: normal
> 
> glusterfs-common is a rather heavy dependency pulling in another 20M
> including dependencies.
> 
> Please make glusterfs-common optional. glusterfs support is only useful
> in special case setups and should not be required by default.

That would mean moving

/usr/lib/libvirt/storage-backend/libvirt_storage_backend_gluster.so

to a separate package. Makes sense. And while at that we can move

/usr/lib/libvirt/storage-backend/libvirt_storage_backend_rbd.so
/usr/lib/libvirt/storage-backend/libvirt_storage_backend_iscsi.so
/usr/lib/libvirt/storage-backend/libvirt_storage_backend_sheepdog.so
/usr/lib/libvirt/storage-backend/libvirt_storage_backend_mpath.so
/usr/lib/libvirt/storage-backend/libvirt_storage_backend_zfs.so

too so we can move the suggests and recommends of these packages to 
dependencies.
Cheers,
 -- Guido

Bug#797086: [git-buildpackage/master] Add tag command

[Guido Günther]

tag 797086 pending
thanks

Date:   Thu Sep 14 14:35:39 2017 +0200
Author: Guido Günther 
Commit ID: db5c6700943706aa5f68e67769144b3a1efca8c5
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=db5c6700943706aa5f68e67769144b3a1efca8c5
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=db5c6700943706aa5f68e67769144b3a1efca8c5

Add tag command

by splitting out the code from buildpackage

This is shorter than running

 gbp buildpackage --git-tag-only

Closes: #797086

  

Bug#875762: [Pkg-libvirt-maintainers] Bug#875762: Does not follow /etc/network/interfaces includes

[Guido Günther]

On Thu, Sep 14, 2017 at 02:57:04PM +0200, martin f krafft wrote:
> also sprach Guido Günther <a...@sigxcpu.org> [2017-09-14 13:27 +0200]:
> > Libvirt itself does not interface parsing. It relies on augeas for
> > that (and I thought that would be fixed in stretch).
> 
> Yes, augeas parses this, but augeas also works fine:
> 
>   root@eugene:/etc/network/interfaces.d# augtool print 
> /files/etc/network/interfaces.d/
>   /files/etc/network/interfaces.d
>   /files/etc/network/interfaces.d/local-wan
>   /files/etc/network/interfaces.d/local-wan/#comment = "The primary network 
> interface"
>   /files/etc/network/interfaces.d/local-wan/auto
>   /files/etc/network/interfaces.d/local-wan/auto/1 = "wan"
>   /files/etc/network/interfaces.d/local-wan/iface = "wan"
>   /files/etc/network/interfaces.d/local-wan/iface/family = "inet"
>   /files/etc/network/interfaces.d/local-wan/iface/method = "static"
>   […]
> 
> So this is likely a netcf issue, actually. Should I reassign to
> libnetcf1?

Yeah, pleae do. I meant to say netcf not augeas in the first place.
 -- Guido

> 
> -- 
>  .''`.   martin f. krafft <madduck@d.o> @martinkrafft
> : :'  :  proud Debian developer
> `. `'`   http://people.debian.org/~madduck
>   `-  Debian - when you have better things to do than fixing systems
>  
> i welcome your constructive criticism and corrections.

Bug#875762: [Pkg-libvirt-maintainers] Bug#875762: Does not follow /etc/network/interfaces includes

[Guido Günther]

control: reassign -1 augeas

Hi,
On Thu, Sep 14, 2017 at 01:09:15PM +0200, martin f krafft wrote:
> Package: libvirt-daemon
> Version: 3.0.0-4
> Severity: normal
> 
> libvirtd does not follow the "new" /e/n/i include directive.
> Interfaces that are defined in included files won't be available to
> libvirtd.

Libvirt itself does not interface parsing. It relies on augeas for
that (and I thought that would be fixed in stretch).
Cheers,
 -- Guido

Bug#875456: [Pkg-giraffe-maintainers] Bug#875456: libvmime: FTBFS on non-Linux: no getThreadId implementation

[Guido Günther]

Hi,
On Tue, Sep 12, 2017 at 09:12:40PM -0400, Aaron M. Ucko wrote:
> "Aaron M. Ucko"  writes:
> 
> >   /«PKGBUILDDIR»/src/vmime/platforms/posix/posixHandler.cpp:243:3: error: 
> > #error We have no implementation of getThreadId() for this platform!
> 
> Thanks for the quick fix!  Alas, the Hurd build still failed because
> Mach has its own API for this functionality:
> 
>   /<>/src/vmime/platforms/posix/posixHandler.cpp:244:12: error: 
> 'SYS_thr_self' was not declared in this scope
> 
> It looks like it should work to call mach_thread_self() from
> .  However, please bear in mind that you'll
> then need to pass the result to mach_port_deallocate per
> https://bugs.launchpad.net/sbcl/+bug/723581 .

Can you send a patch tested on hurd?
 -- Guido

Bug#872573: Stopping libvirtd.service does not properly stop all (dnsmasq) processes

[Guido Günther]

control: tags -1 +wontfix

Hi Micheal,
On Fri, Aug 18, 2017 at 08:47:09PM +0200, Michael Biebl wrote:
> Package: libvirt-daemon-system
> Version: 3.6.0-1
> Severity: normal
> File: /lib/systemd/system/libvirtd.service
> 
> libvirtd.service uses KillMode=process, this means, it's up to the main
> process to kill all child processes properly. This doesn't seem to be
> the case for libvirtd
> 
> # systemctl status libvirtd
> ● libvirtd.service - Virtualization daemon
>Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor 
> preset: enabled)
>Active: active (running) since Fri 2017-08-18 20:08:30 CEST; 37min ago
>  Docs: man:libvirtd(8)
>http://libvirt.org
>  Main PID: 689 (libvirtd)
> Tasks: 18 (limit: 32768)
>CGroup: /system.slice/libvirtd.service
>├─ 689 /usr/sbin/libvirtd
>├─1529 /usr/sbin/dnsmasq 
> --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
> --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
>└─1530 /usr/sbin/dnsmasq 
> --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
> --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
> 
> # systemctl stop libvirtd
> # systemctl status libvirtd
> ● libvirtd.service - Virtualization daemon
>Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor 
> preset: enabled)
>Active: inactive (dead) since Fri 2017-08-18 20:46:35 CEST; 1s ago
>  Docs: man:libvirtd(8)
>http://libvirt.org
>   Process: 689 ExecStart=/usr/sbin/libvirtd $libvirtd_opts (code=exited, 
> status=0/SUCCESS)
>  Main PID: 689 (code=exited, status=0/SUCCESS)
> Tasks: 2 (limit: 32768)
>CGroup: /system.slice/libvirtd.service
>├─1529 /usr/sbin/dnsmasq 
> --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
> --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
>└─1530 /usr/sbin/dnsmasq 
> --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
> --dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
> 
> See, how the dnsmasq processes are still running after stopping the
> service.

This is itentional since the networks continue to run. Once you stop the
network the dnsmasq instance goes away too. Otherwise daemon restarts
would break VM connectivity.
Cheers,
 -- Guido

Bug#871957: [lintian] orig-tarball-missing-upstream-signature should exclude repacks

[Guido Günther]

Hi,
On Sun, Sep 10, 2017 at 05:01:17PM +0100, Chris Lamb wrote:
> Hi Guido,
> 
> > control: reopen -1
> 
> It's not closed yet - still pending release! ;)
> 
> > See #874663. Looking at filter in debian/copyright and at the dir name
> > of the tarball¹ (as Simon suggested)
> 
> This bit...
> 
>   Lintian can detect that the tarball was repacked by looking inside
>   at the first few tar members - a repacked tarball is meant to
>   contain only a foo_1.2.3.orig/ directory (devref §6.7.8.2.4)
> 
> Don't see a reference to filtering debian/copyright however?

That part is in #874663. It's in uscan's manpage:

 Files-Excluded or Files-Excluded-component stanzas are set in
 debian/copyright to make mk-origtargz invoked from uscan
 remove files from the upstream tarball and repack it.
 See "COPYRIGHT FILE EXAMPLES" and mk-origtargz(1).

So if there's a Files-Excluded* in debian/copyright the upstream tarball
was filtered.
Cheers,
 -- Guido

Bug#871957: [lintian] orig-tarball-missing-upstream-signature should exclude repacks

[Guido Günther]

control: reopen -1

Hi Chris,
On Sun, Sep 10, 2017 at 01:26:35PM +0100, Chris Lamb wrote:
> forcemerge 871957 874659
> thanks
> 
> Hi Guido,
> 
> > orig-tarball-missing-upstream-signature should exclude repacks
> 
> This was fixed in #874659. :)

I think this is (unfortunately) not enough to detect a repacked
tarball - although it will already detect lots of repacked tarballs, so
thankgs for that.

See #874663. Looking at filter in debian/copyright and at the dir name
of the tarball¹ (as Simon suggested) are other indicators.
Cheers,
 -- Guido


¹ 
https://www.debian.org/doc/manuals/developers-reference/ch06.en.html#repackagedorigtargz

Bug#874793: gbp-dch: Please add "Gbp-Dch: Paragraph"

[Guido Günther]

Hi,
On Sat, Sep 09, 2017 at 06:34:22PM +0200, Julian Andres Klode wrote:
> Package: git-buildpackage
> Version: 0.8.18
> Severity: wishlist
> 
> In APT, we tend to write very long commit messages and mostly
> just use the summary. Sometimes, like for stable updates, we
> add more details, and it would be useful to have a way to
> use the first paragraph of a commit message rather than just
> all or summary.

You can use a customization for this. See

/usr/share/doc/git-buildpackage/examples/wrap_cl.py

for an example.
Cheers,
 -- Guido

Bug#874666: uscan: please rename downloaded signature to .asc

[Guido Günther]

Hi,
On Sat, Sep 09, 2017 at 12:20:46AM +0900, Osamu Aoki wrote:
> Hi,
> 
> On Fri, Sep 08, 2017 at 04:35:35PM +0200, Guido Günther wrote:
> > Package: devscripts
> > Version: 2.17.9
> > Severity: wishlist
> > 
> > Hi,
> > while uscan handle .gpg, gpg, .asc, … dpkg expects .asc so it would be
> > great if uscan would rename to .asc when signature verification is
> > successful.
> 
> Please wait for the next version coming up this weekend ;-)

Awesome. Thanks!
 -- Guido

Bug#874667: uscan: please remove upstream signature when repacking tarballs

[Guido Günther]

Package: devscripts
Version: 2.17.9
Severity: wishlist
File: /usr/bin/uscan

Hi,
the upstream signture will no longer verify successfully if uscan
repacks the tarball using the information from debian/copyright. In this
case uscan should remove the signature to make sure no other tools pick
it up by accident and fail signature verification later on.
Cheers,
 -- Guido


-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBSIGN_KEYID=0xB999CDB58C8DDBD2

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.18.24
ii  libc6 2.24-17
ii  libfile-homedir-perl  1.00-1
ii  perl  5.26.0-5
ii  python3   3.5.3-3

Versions of packages devscripts recommends:
ii  apt 1.5~rc1
ii  at  3.1.20-3
ii  curl7.55.1-1
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2017.08.28
ii  dput-ng [dput]  1.15
ii  dupload 2.9.0
ii  equivs  2.1.0
ii  fakeroot1.22-1
ii  file1:5.32-1
ii  gnupg   2.1.23-2
ii  gnupg2  2.1.23-2
ii  libdistro-info-perl 0.17
ii  libdpkg-perl1.18.24
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.047-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.20-1
ii  liburi-perl 1.72-1
ii  libwww-perl 6.15-2
ii  licensecheck3.0.30-1
ii  lintian 2.5.52
ii  man-db  2.7.6.1-2
ii  patch   2.7.5-1+b2
ii  patchutils  0.3.4-2
ii  python3-debian  0.1.30
ii  python3-magic   1:5.32-1
ii  python3-unidiff 0.5.4-1
ii  sensible-utils  0.0.10
ii  strace  4.15-2
ii  unzip   6.0-21
ii  wdiff   1.2.2-2
ii  wget1.19.1-4
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
pn  adequate 
ii  autopkgtest  4.4
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-4
ii  build-essential  12.3
pn  check-all-the-things 
pn  cvs-buildpackage 
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
ii  gnuplot  5.0.7+dfsg1-1
ii  gnuplot-x11 [gnuplot]5.0.7+dfsg1-1
ii  gpgv 2.1.23-2
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
ii  mozilla-devscripts   0.47
ii  mutt 1.8.3+neomutt20170609-2+b1
ii  openssh-client [ssh-client]  1:7.5p1-10
pn  piuparts 
ii  quilt0.63-8.1
ii  ratt 0.0~git20160202.0.a14e2ff-1+b2
pn  reprotest
pn  svn-buildpackage 
ii  w3m  0.5.3-34

-- no debconf information

Bug#874666: uscan: please rename downloaded signature to .asc

[Guido Günther]

Package: devscripts
Version: 2.17.9
Severity: wishlist

Hi,
while uscan handle .gpg, gpg, .asc, … dpkg expects .asc so it would be
great if uscan would rename to .asc when signature verification is
successful.
Cheers,
 -- Guido

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBSIGN_KEYID=0xB999CDB58C8DDBD2

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.18.24
ii  libc6 2.24-17
ii  libfile-homedir-perl  1.00-1
ii  perl  5.26.0-5
ii  python3   3.5.3-3

Versions of packages devscripts recommends:
ii  apt 1.5~rc1
ii  at  3.1.20-3
ii  curl7.55.1-1
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2017.08.28
ii  dput-ng [dput]  1.15
ii  dupload 2.9.0
ii  equivs  2.1.0
ii  fakeroot1.22-1
ii  file1:5.32-1
ii  gnupg   2.1.23-2
ii  gnupg2  2.1.23-2
ii  libdistro-info-perl 0.17
ii  libdpkg-perl1.18.24
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.047-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.20-1
ii  liburi-perl 1.72-1
ii  libwww-perl 6.15-2
ii  licensecheck3.0.30-1
ii  lintian 2.5.52
ii  man-db  2.7.6.1-2
ii  patch   2.7.5-1+b2
ii  patchutils  0.3.4-2
ii  python3-debian  0.1.30
ii  python3-magic   1:5.32-1
ii  python3-unidiff 0.5.4-1
ii  sensible-utils  0.0.10
ii  strace  4.15-2
ii  unzip   6.0-21
ii  wdiff   1.2.2-2
ii  wget1.19.1-4
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
pn  adequate 
ii  autopkgtest  4.4
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-4
ii  build-essential  12.3
pn  check-all-the-things 
pn  cvs-buildpackage 
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
ii  gnuplot  5.0.7+dfsg1-1
ii  gnuplot-x11 [gnuplot]5.0.7+dfsg1-1
ii  gpgv 2.1.23-2
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
ii  mozilla-devscripts   0.47
ii  mutt 1.8.3+neomutt20170609-2+b1
ii  openssh-client [ssh-client]  1:7.5p1-10
pn  piuparts 
ii  quilt0.63-8.1
ii  ratt 0.0~git20160202.0.a14e2ff-1+b2
pn  reprotest
pn  svn-buildpackage 
ii  w3m  0.5.3-34

-- no debconf information

Bug#874663: Document +dfsg as extenson when repacking upstream sources

[Guido Günther]

Package: debian-policy
Version: 4.1.0.0
Severity: wishlist

Hi,
when upstream tarballs need to be repacked because they contain non-dfsg
free data appending '+dfsg' to the upstream version seems common
practice. However some packages append '.dfsg', others use
+dfsg and there are more formats around.

It would be great if policy could recommend +dfsg as the default
(falling back to +dfsg if there was a packaging error (i.e. some
files slip through and the package was rejected by ftp-masters).

This would make it simpler for tools like lintian or gbp to detect repacked
tarballs (in this case we don't want to attach the upstream signature to
the chages file).
Cheers,
 -- Guido

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages debian-policy depends on:
ii  libjs-sphinxdoc  1.5.6-2

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
pn  doc-base  

-- no debconf information

Bug#874659: orig-tarball-missing-upstream-signature should not trigger on repacked tarballs

[Guido Günther]

Package: lintian
Version: 2.5.52
Severity: normal

Hi,
We can't use the signatures for these. We don't have a recommended
mechanisms to detect these but looking for +dfsg in the upstream version
and looking for a filter in debian/copyright should catch most of these.
Cheers,
 -- Guido

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lintian depends on:
ii  binutils  2.28-6
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.18.24
ii  file  1:5.32-1
ii  gettext   0.19.8.1-4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2+b2
ii  libdpkg-perl  1.18.24
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.0-5
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.72-1
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.63-2+b2
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.26.0-5
ii  t1utils   1.40-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b4

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.24
ii  libhtml-parser-perl3.72-3+b2
ii  libtext-template-perl  1.46-1

-- no debconf information

Bug#863266: Re: Bug#863266: [Pkg-libvirt-maintainers] Bug#863266: libvirt-daemon: spice port conflict - multiple VMs want Port 5900

[Guido Günther]

Hi Marc,
On Sun, Aug 13, 2017 at 10:51:25AM +0200, Marc Haber wrote:
> found #863266 3.6.0-1
> thanks
> 
> On Thu, Aug 03, 2017 at 11:32:37AM -0300, Guido Günther wrote:
> > Thanks for checking. I'll close the bug for sid then at least. I have no
> > idea yet how the kernel enters the game on stretch though.
> 
> I still have the issue on current sid. I am, however, also running a
> current kernel, 4.12.7 at the moment.

Could this be the problem you're seeing:

https://bugzilla.redhat.com/show_bug.cgi?id=1489854

It seems we're somehow not tracking ports over daemon restarts
anymore. If it is your problem it should go away if you

 - shut down all vms
 - restart libvirtd

Port allocation should now work _until_ you restart libvirtd again. If
this is the issue I'll mark this bug as forwarded.
Cheers,
 -- Guido

Bug#874550: git-buildpackage: Please copy the orig tarball gpg/pgp signature (.pgp/.asc) while building the source package

[Guido Günther]

Hi,
On Thu, Sep 07, 2017 at 12:52:22PM +0200, Laurent Bigonville wrote:
> Le 07/09/17 à 12:33, Guido Günther a écrit :
> > Hi,
> > On Thu, Sep 07, 2017 at 12:16:15PM +0200, Guido Günther wrote:
> > > control: retitle -1 Please symlink upstream signature file to 
> > > ../build-area as well
> > > 
> > > Hi,
> > > On Thu, Sep 07, 2017 at 12:03:27PM +0200, Laurent Bigonville wrote:
> > > > Le 07/09/17 à 11:06, Guido Günther a écrit :
> > > > > Hi Laurent,
> > > > > On Thu, Sep 07, 2017 at 10:55:14AM +0200, Laurent Bigonville wrote:
> > > > > > Package: git-buildpackage
> > > > > > Version: 0.9.0~exp4
> > > > > > Severity: normal
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > It's now possible to include the gpg/pgp signature of the original
> > > > > > upstream tarball in the source (.dsc) package.
> > > > > > 
> > > > > > Currently, gbp buildpackage -S is not copying that file when 
> > > > > > preparing
> > > > > > the source package that means that dpkg is not adding it to the .dsc
> > > > > > file.
> > > > > > 
> > > > > > gbp buildpackags -S should copy this (and maybe check if the name 
> > > > > > of the
> > > > > > file is OK).
> > > > > The "-S" is passed verbatim to the builder (dpkg-buildpackage, sbuild,
> > > > > pbuilder, ...). I assume you want gbp to checkout the signature when
> > > > > building a tarball (#872864)?
> > > > I think this is related, but not completely the same, I don't see the
> > > > signature being commited in the pristine-tar branch here.
> > > …it's not implemented yet
> > > 
> > > > My setup here is the following:
> > > > 
> > > > The orig tarball and its signature (.pgp) is in the ../tarballs 
> > > > directory,
> > > > when running gbp buildpackage -S, the orig tarball is symliked (or 
> > > > generated
> > > > if it's absent) to the ../build-area directory.
> > > > 
> > > > The thing is, that the signature file is not copied at the same time in 
> > > > that
> > > > ../build-area directory
> > > Yeah, the symlinking is a different case. Let's keep it as a separate
> > > bug.
> > One more thing. It seems dpkg-source wants these alsways named as
> > .asc but you're writing (.pgp) above - is that a
> > typo or should uscan rename this to .asc right away?
> uscan downloads the file as .pgp even if the upstream file is .asc, when
> using pgpsigurlmangle
> 
> I guess that's a bug in uscan?

I think so. Could you file that one as well please? (since my knowledge
is based on what's in the manpages and what I read from the source, I
didn't get around to try to add upstream signatures myself to an upload
yet).

We should try to standardize on one thing and since dpkg-source uses
.asc and has the final say it's probably best to use that one. Otherwise
we'll end up with lots of different heuristics.

Cheers,
 -- Guido

Bug#874550: git-buildpackage: Please copy the orig tarball gpg/pgp signature (.pgp/.asc) while building the source package

[Guido Günther]

Hi,
On Thu, Sep 07, 2017 at 12:16:15PM +0200, Guido Günther wrote:
> control: retitle -1 Please symlink upstream signature file to ../build-area 
> as well
> 
> Hi,
> On Thu, Sep 07, 2017 at 12:03:27PM +0200, Laurent Bigonville wrote:
> > Le 07/09/17 à 11:06, Guido Günther a écrit :
> > > Hi Laurent,
> > > On Thu, Sep 07, 2017 at 10:55:14AM +0200, Laurent Bigonville wrote:
> > > > Package: git-buildpackage
> > > > Version: 0.9.0~exp4
> > > > Severity: normal
> > > > 
> > > > Hi,
> > > > 
> > > > It's now possible to include the gpg/pgp signature of the original
> > > > upstream tarball in the source (.dsc) package.
> > > > 
> > > > Currently, gbp buildpackage -S is not copying that file when preparing
> > > > the source package that means that dpkg is not adding it to the .dsc
> > > > file.
> > > > 
> > > > gbp buildpackags -S should copy this (and maybe check if the name of the
> > > > file is OK).
> > > The "-S" is passed verbatim to the builder (dpkg-buildpackage, sbuild,
> > > pbuilder, ...). I assume you want gbp to checkout the signature when
> > > building a tarball (#872864)?
> > 
> > I think this is related, but not completely the same, I don't see the
> > signature being commited in the pristine-tar branch here.
> 
> …it's not implemented yet
> 
> > 
> > My setup here is the following:
> > 
> > The orig tarball and its signature (.pgp) is in the ../tarballs directory,
> > when running gbp buildpackage -S, the orig tarball is symliked (or generated
> > if it's absent) to the ../build-area directory.
> > 
> > The thing is, that the signature file is not copied at the same time in that
> > ../build-area directory
> 
> Yeah, the symlinking is a different case. Let's keep it as a separate
> bug.

One more thing. It seems dpkg-source wants these alsways named as
.asc but you're writing (.pgp) above - is that a
typo or should uscan rename this to .asc right away?

Cheers,
 -- Guido

Bug#874550: git-buildpackage: Please copy the orig tarball gpg/pgp signature (.pgp/.asc) while building the source package

[Guido Günther]

control: retitle -1 Please symlink upstream signature file to ../build-area as 
well

Hi,
On Thu, Sep 07, 2017 at 12:03:27PM +0200, Laurent Bigonville wrote:
> Le 07/09/17 à 11:06, Guido Günther a écrit :
> > Hi Laurent,
> > On Thu, Sep 07, 2017 at 10:55:14AM +0200, Laurent Bigonville wrote:
> > > Package: git-buildpackage
> > > Version: 0.9.0~exp4
> > > Severity: normal
> > > 
> > > Hi,
> > > 
> > > It's now possible to include the gpg/pgp signature of the original
> > > upstream tarball in the source (.dsc) package.
> > > 
> > > Currently, gbp buildpackage -S is not copying that file when preparing
> > > the source package that means that dpkg is not adding it to the .dsc
> > > file.
> > > 
> > > gbp buildpackags -S should copy this (and maybe check if the name of the
> > > file is OK).
> > The "-S" is passed verbatim to the builder (dpkg-buildpackage, sbuild,
> > pbuilder, ...). I assume you want gbp to checkout the signature when
> > building a tarball (#872864)?
> 
> I think this is related, but not completely the same, I don't see the
> signature being commited in the pristine-tar branch here.

…it's not implemented yet

> 
> My setup here is the following:
> 
> The orig tarball and its signature (.pgp) is in the ../tarballs directory,
> when running gbp buildpackage -S, the orig tarball is symliked (or generated
> if it's absent) to the ../build-area directory.
> 
> The thing is, that the signature file is not copied at the same time in that
> ../build-area directory

Yeah, the symlinking is a different case. Let's keep it as a separate
bug.

Thanks for the clarification.
 -- Guido

Bug#874550: git-buildpackage: Please copy the orig tarball gpg/pgp signature (.pgp/.asc) while building the source package

[Guido Günther]

Hi Laurent, 
On Thu, Sep 07, 2017 at 10:55:14AM +0200, Laurent Bigonville wrote:
> Package: git-buildpackage
> Version: 0.9.0~exp4
> Severity: normal
> 
> Hi,
> 
> It's now possible to include the gpg/pgp signature of the original
> upstream tarball in the source (.dsc) package.
> 
> Currently, gbp buildpackage -S is not copying that file when preparing
> the source package that means that dpkg is not adding it to the .dsc
> file.
> 
> gbp buildpackags -S should copy this (and maybe check if the name of the
> file is OK).

The "-S" is passed verbatim to the builder (dpkg-buildpackage, sbuild,
pbuilder, ...). I assume you want gbp to checkout the signature when
building a tarball (#872864)?

Cheers,
 -- Guido

> 
> Regards,
> 
> Laurent Bigonville
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.13.0-rc7-amd64 (SMP w/8 CPU cores)
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages git-buildpackage depends on:
> ii  devscripts 2.17.9
> ii  git1:2.14.1-3
> ii  man-db 2.7.6.1-2
> ii  python33.5.3-3
> ii  python3-dateutil   2.6.1-1
> ii  python3-pkg-resources  36.2.7-2
> ii  python3-six1.10.0-4
> 
> Versions of packages git-buildpackage recommends:
> ii  pristine-tar  1.41
> ii  python3-requests  2.18.1-1
> ii  sbuild0.73.0-4
> 
> Versions of packages git-buildpackage suggests:
> ii  python3-notify2  0.3-3
> ii  sudo 1.8.21-1
> ii  unzip6.0-21
> 
> -- no debconf information
> 

Bug#870719: thunderbird: migration from 45 (GTK2) to 52 (GTK3) produces regressions on Jessie

[Guido Günther]

Hi,
On Tue, Sep 05, 2017 at 02:36:24PM +0200, Alex ARNAUD wrote:
> Le 05/09/2017 à 13:20, Guido Günther a écrit :
> > Hi Alex,
> > On Tue, Sep 05, 2017 at 12:04:00PM +0200, Alex ARNAUD wrote:
> > > Dear maintainer,
> > > 
> > > What is the state of this bug?
> > 
> > Could you pinpoint the root cause? Is this in thunderbird itself or a
> > bug in GTK+3 in Jessie?
> 
> The root cause is the migration from GTK2 to GTK3 on Jessie. This release of
> Debian is not ready for this change due to those issues:
> - gnome-orca (screenreader) is shipped in version 3.14 that doesn't support
> Thunderbird GTK3
> - HighContrast from Mate theme doesn't fully support GTK3 on Debian Jessie.

Thanks for the update! Although not-ready doesn't describe what is
lacking and doesn't support neither. I'm nitpicking on this since it's
not clear to me that Thunderbird will support GTK+2 long enough so we
might have to switch at some point.

AFAIK Carsten intends to switch back to GTK+2 for Jessie but it would be
great if you could go hunting for patches since we might be forced to
switch to GTK+3 at some point in the future.

Cheers,
 -- Guido

Bug#870719: thunderbird: migration from 45 (GTK2) to 52 (GTK3) produces regressions on Jessie

[Guido Günther]

Hi Alex,
On Tue, Sep 05, 2017 at 12:04:00PM +0200, Alex ARNAUD wrote:
> Dear maintainer,
> 
> What is the state of this bug?

Could you pinpoint the root cause? Is this in thunderbird itself or a
bug in GTK+3 in Jessie?
Cheers,
 -- Guido

> 
> Best regards.
> -- 
> Alex ARNAUD
> Visual-Impairment Project Manager
> Hypra - "Humanizing technology"
> 
> On Wed, 23 Aug 2017 18:22:10 +0200 =?UTF-8?Q?Rapha=c3=abl_POITEVIN?=
>  wrote:
> > On Fri, 4 Aug 2017 16:00:27 +0200 Alex ARNAUD  wrote:
> > > Package: thunderbird
> > > Version: 1:52.2.1-4~deb8u1
> > > Tags: a11y jessie
> > > Severity: important
> > >
> > > Dear Thunderbird maintainer,
> > >
> > > On Debian 8, the recent migration from Thunderbird 45 to Thunderbird 52
> > > has produced a migration from GTK2 to GTK3.
> > >
> > > The migration from GTK2 to GTK3 produces two regressions :
> > >
> > > 1) When composing mail in text mode the Orca screen reader repeats two
> > > times each line
> > >
> > > 2) When you use the HighContrast theme "twisty" arrows are no longer
> > > visible as reported upstream :
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1376756
> > >
> > >
> > > I've compiled Thunderbird 52 from Debian with GTK2 instead of GTK3 and
> > > it solves those issues.
> > >
> > > Best regards.
> > > --
> > > Alex ARNAUD
> > > Visual-Impairment Project Manager
> > > Hypra - "Humanizing technology"
> > 
> > I do agree. This is a important a11y regression for visually impaired
> > people.
> > 
> > Regards,
> > 
> > Raphaël
> > 
> > 
> 

Bug#874039: [Pkg-libvirt-maintainers] Bug#874039: Package description is very old and insufficient

[Guido Günther]

Hi,
On Sat, Sep 02, 2017 at 11:12:38AM +, Amr Ibrahim wrote:
> Package: virt-manager
> 
> Hello,
> 
> The package description of virt-manager is very old. It does not say 
> anything about libvirt, qemu or LXC. It even mentions that the GUI is 
> experimental, which is not the case any more.
> 
> I suggest changing it to:
> 
> 1- From the Github page:
> 
> Virtual Machine Manager
> 
> This application provides a graphical tool for managing virtual machines 
> via the libvirt library.
> 
> The front-end of the application uses the GTK / Glade libraries for all 
> user interaction components. The back-end uses libvirt for managing 
> QEMU/KVM and Xen virtual machines, as well as LXC containers. The UI is 
> primarily tested with KVM, but is intended to be reasonably portable to 
> any virtualization back-end libvirt supports.
> 
> Several command line tools are also provided:
> 
> virt-install: Create new libvirt virtual machines
> virt-clone: Duplicate existing libvirt virtual machines
> virt-xml: Edit existing libvirt virtual machines/manipulate libvirt XML
> virt-convert: Convert VMX or OVF configs to libvirt virtual machines
> 
> OR,
> 2- From the homepage:
> 
> The virt-manager application is a desktop user interface for managing 
> virtual machines through libvirt. It primarily targets KVM VMs, but also 
> manages Xen and LXC (linux containers). It presents a summary view of 
> running domains, their live performance & resource utilization 
> statistics. Wizards enable the creation of new domains, and 
> configuration & adjustment of a domain’s resource allocation & virtual 
> hardware. An embedded VNC and SPICE client viewer presents a full 
> graphical console to the guest domain.
> 
> About virt-manager’s supporting tools:
> 
> virt-install is a command line tool which provides an easy way to 
> provision operating systems into virtual machines.
> 
> virt-clone is a command line tool for cloning existing inactive guests. 
> It copies the disk images, and defines a config with new name, UUID and 
> MAC address pointing to the copied disks.
> 
> virt-xml is a command line tool for easily editing libvirt domain XML 
> using virt-install’s command line options.
> 
> virt-convert is a command line tool for converting OVF and VMX VM 
> configurations to run with libvirt.

The package description can indeed use a remake but I currently don't
see how mentioning GTK / Glade etc improves on the current. Can you send
patches against debian/control to show your intend?
Cheers,
 -- Guido

Bug#874043: [Pkg-libvirt-maintainers] Bug#874043: Package description is very old and insufficient

[Guido Günther]

control: tags -1 +pending

Hi,
On Sat, Sep 02, 2017 at 11:20:52AM +, Amr Ibrahim wrote:
> Package: virt-viewer
> 
> Hello,
> 
> The package description is very old. I suggest changing it to:
> 
> Virt Viewer
> 
> It provides a graphical viewer for the guest OS display.
> 
> virt-viewer is a lightweight user interface for interacting with the 
> graphical display of virtualized guest OS. It can display VNC or SPICE, 
> and uses libvirt to lookup the graphical connection details.
> 
> The viewer can connect directly to both local and remotely hosted guest 
> OS, optionally using SSL/TLS encryption.

I've added spice to the list of protocols. If you want some more details
changed let me know (and preferably send a patch).

Cheers,
 -- Guido

Bug#872864: Checkout upstream signatures as well when using pristine-tar

[Guido Günther]

Hi,
On Sat, Sep 02, 2017 at 07:43:31AM +0100, Chris Lamb wrote:
> Chris Lamb wrote:
> 
> > > We should checkout the upstream signatures from the pristine-tar branch
> > > as well.
> >
> > This blocks on support in pristine-tar (now pending release).
> 
> … which is now in unstable as pristine-tar 1.41 :)

Yept, and I was working on a patch even before that ;) But now that
Debconf is over things are progressing much more slowly due to RL.
 -- Guido

Bug#873597: virt-manager: gir1.2-spice-client-gtk-3.0 package has been renamed to gir1.2-spiceclientgtk-3.0

[Guido Günther]

Hi,
On Thu, Aug 31, 2017 at 04:41:26PM +0200, Christoph Anton Mitterer wrote:
> On Thu, 2017-08-31 at 16:31 +0200, Guido Günther wrote:
> > Hmm...this one is in gir1.2-spiceclientglib-2.0. Can you install that
> > one in see if it works then?
> 
> Indeed... that fixes the problem :)

I'll add this to the dependencies then. Thanks!
 -- Guido

> 
> Cheers,
> Chris.

Bug#873597: virt-manager: gir1.2-spice-client-gtk-3.0 package has been renamed to gir1.2-spiceclientgtk-3.0

[Guido Günther]

Hi,
On Thu, Aug 31, 2017 at 03:31:19PM +0200, Christoph Anton Mitterer wrote:
> On Thu, 2017-08-31 at 10:00 +0200, Guido Günther wrote:
> > You could try strace to see
> > if
> > the typelib file gets picked up.
> 
> No, doesn't seem it would:
> $ strace -f virt-manager 2>&1 | grep typelib
> o
> pen("/usr/lib/x86_64-linux-gnu/girepository-1.0/LibvirtGLib-
> 1.0.typelib", O_RDONLY) = 4
> open("/usr/lib/x86_64-linux-
> gnu/girepository-1.0/LibvirtGLib-1.0.typelib", O_RDONLY) = 4
> open("/usr/
> lib/x86_64-linux-gnu/girepository-1.0/LibvirtGLib-1.0.typelib",
> O_RDONLY) = 3
> open("/usr/lib/x86_64-linux-gnu/girepository-1.0/GLib-
> 2.0.typelib", O_RDONLY) = 3
> open("/usr/lib/x86_64-linux-
> gnu/girepository-1.0/Libosinfo-1.0.typelib", O_RDONLY) = 7
> open("/usr/li
> b/x86_64-linux-gnu/girepository-1.0/Libosinfo-1.0.typelib", O_RDONLY) =
> 7
> open("/usr/lib/x86_64-linux-gnu/girepository-1.0/Libosinfo-
> 1.0.typelib", O_RDONLY) = 5
> open("/usr/lib/x86_64-linux-
> gnu/girepository-1.0/libxml2-2.0.typelib", O_RDONLY) = 5
> open("/usr/lib/
> x86_64-linux-gnu/girepository-1.0/Gio-2.0.typelib", O_RDONLY) = 5
> open("
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GObject-2.0.typelib",
> O_RDONLY) = 5
> [pid 24020] open("/usr/lib/x86_64-linux-gnu/girepository-
> 1.0/Gtk-3.0.typelib", O_RDONLY) = 5
> [pid 24020]
> open("/usr/lib/girepository-1.0/Gtk-2.0.typelib", O_RDONLY) = 5
> [pid
> 24020] open("/usr/lib/x86_64-linux-gnu/girepository-1.0/Gtk-
> 3.0.typelib", O_RDONLY) = 5
> open("/usr/lib/girepository-1.0/Gtk-
> 2.0.typelib", O_RDONLY) = 5
> open("/usr/lib/x86_64-linux-
> gnu/girepository-1.0/Gtk-3.0.typelib", O_RDONLY) = 4
> open("/usr/lib/x86_
> 64-linux-gnu/girepository-1.0/xlib-2.0.typelib", O_RDONLY) = 4
> open("/us
> r/lib/x86_64-linux-gnu/girepository-1.0/Gdk-3.0.typelib", O_RDONLY) = 4
> 
> open("/usr/lib/x86_64-linux-gnu/girepository-1.0/cairo-1.0.typelib",
> O_RDONLY) = 4
> open("/usr/lib/x86_64-linux-gnu/girepository-1.0/Pango-
> 1.0.typelib", O_RDONLY) = 4
> open("/usr/lib/x86_64-linux-
> gnu/girepository-1.0/GdkPixbuf-2.0.typelib", O_RDONLY) = 4
> open("/usr/li
> b/x86_64-linux-gnu/girepository-1.0/GModule-2.0.typelib", O_RDONLY) = 4
> 
> open("/usr/lib/x86_64-linux-gnu/girepository-1.0/Atk-1.0.typelib",
> O_RDONLY) = 4
> open("/usr/lib/x86_64-linux-gnu/girepository-1.0/GdkX11-
> 3.0.typelib", O_RDONLY) = 8
> open("/usr/lib/girepository-1.0/GdkX11-
> 2.0.typelib", O_RDONLY) = 8
> open("/usr/lib/x86_64-linux-
> gnu/girepository-1.0/GdkX11-3.0.typelib", O_RDONLY) = 8
> open("/usr/lib/g
> irepository-1.0/GdkX11-2.0.typelib", O_RDONLY) = 8
> open("/usr/lib/x86_64
> -linux-gnu/girepository-1.0/GdkX11-3.0.typelib", O_RDONLY) = 7
> [pid
> 24020] open("/usr/lib/x86_64-linux-gnu/girepository-1.0/Vte-
> 2.91.typelib", O_RDONLY) = 19
> [pid 24020] open("/usr/lib/x86_64-linux-
> gnu/girepository-1.0/Vte-2.91.typelib", O_RDONLY) = 19
> [pid 24020]
> open("/usr/lib/x86_64-linux-gnu/girepository-1.0/Vte-2.91.typelib",
> O_RDONLY) = 18
> [pid 24020] open("/usr/lib/x86_64-linux-gnu/girepository-
> 1.0/GtkVnc-2.0.typelib", O_RDONLY) = 19
> [pid 24020]
> open("/usr/lib/x86_64-linux-gnu/girepository-1.0/GtkVnc-2.0.typelib",
> O_RDONLY) = 19
> [pid 24020] open("/usr/lib/x86_64-linux-gnu/girepository-
> 1.0/GtkVnc-2.0.typelib", O_RDONLY) = 18
> [pid 24020]
> open("/usr/lib/x86_64-linux-gnu/girepository-1.0/GVnc-1.0.typelib",
> O_RDONLY) = 18
> [pid 24020] open("/usr/lib/x86_64-linux-gnu/girepository-
> 1.0/SpiceClientGtk-3.0.typelib", O_RDONLY) = 19
> [pid 24020]
> open("/usr/lib/x86_64-linux-gnu/girepository-1.0/SpiceClientGtk-
> 3.0.typelib", O_RDONLY) = 19
> [pid 24020] open("/usr/lib/x86_64-linux-
> gnu/girepository-1.0/SpiceClientGtk-3.0.typelib", O_RDONLY) = 18

This is o.k.

> [pid
> 24020] open("/usr/lib/x86_64-linux-gnu/girepository-
> 1.0/SpiceClientGLib-2.0.typelib", O_RDONLY) = -1 ENOENT (No such file
> or directory)
> [pid 24020] open("/usr/lib/girepository-
> 1.0/SpiceClientGLib-2.0.typelib", O_RDONLY) = -1 ENOENT (No such file
> or directory)

Hmm...this one is in gir1.2-spiceclientglib-2.0. Can you install that
one in see if it works then?
 -- Guido

> 
> 
> 
> >  Note that this is likely not related to
> > virt-manager but rather to how libgirepository picks up things.
> 
> So reassigning?
> 
> 
> Cheers,
> Chris.

Bug#872354: [git-buildpackage/master] patch_series: don't let "git mailinfo" sanitize the subject

[Guido Günther]

tag 872354 pending
thanks

Date:   Thu Aug 31 13:30:18 2017 +0200
Author: Guido Günther 
Commit ID: b2092c1e2c9a25d2a480c75e4cfb42235f86a0e8
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=b2092c1e2c9a25d2a480c75e4cfb42235f86a0e8
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=b2092c1e2c9a25d2a480c75e4cfb42235f86a0e8

patch_series: don't let "git mailinfo" sanitize the subject

This would strip away text in []. This improves the import/export round
trip.

Closes: #872354

  

Bug#873804: CVE-2017-11541

[Guido Günther]

Hi Romain,

Thanks for the prompt reply!

On Thu, Aug 31, 2017 at 01:16:35PM +0200, Romain Francoise wrote:
> Hi,
> 
> On Thu, Aug 31, 2017 at 12:52:12PM +0200, Guido Günther wrote:
> > I've sent the attached patch upstream. I'd like to incorporate this into
> > an upload to wheezy at one point. Shall I handle sid, stretch or jessie
> > as well?
> 
> No, thank you. This vulnerability and the others have already been fixed
> upstream for some time and an upcoming upstream version will include the
> fixes. We're just waiting for upstream to lift the embargo...

O.k. Any idea when upstream will do this?

Cheers,
 -- Guido

Bug#873804: CVE-2017-11541

[Guido Günther]

Hi,
On Thu, Aug 31, 2017 at 12:39:17PM +0200, Guido Günther wrote:
> Package: tcpdump
> X-Debbugs-CC: t...@security.debian.org 
> secure-testing-t...@lists.alioth.debian.org
> Severity: important
> Tags: security
> 
> Hi,
> 
> the following vulnerability was published for tcpdump.
> 
> CVE-2017-11541[0]:
> | tcpdump 4.9.0 has a heap-based buffer over-read in the lldp_print
> | function in print-lldp.c, related to util-print.c.

I've sent the attached patch upstream. I'd like to incorporate this into
an upload to wheezy at one point. Shall I handle sid, stretch or jessie
as well? Given the impact of the issue an update to stretch and jessie
is probably more suitable for a point release (which wheezy does not have).
Cheers,
 -- Guido
From: =?utf-8?q?Guido_G=C3=BCnther?= <a...@sigxcpu.org>
Date: Mon, 28 Aug 2017 18:53:20 +0200
Subject: CVE-2017-11541: safeputs: check length first

Put the lenght check before accessing s since we might otherwise
read from a memory area we're not supposed to read.

Addresses CVE-2017-11541 with the testcase from

https://github.com/hackerlib/hackerlib-vul/tree/master/tcpdump-vul/heap-buffer-overflow/util-print
---
 util-print.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/util-print.c b/util-print.c
index 5db042a..34fc2e0 100644
--- a/util-print.c
+++ b/util-print.c
@@ -902,7 +902,7 @@ safeputs(netdissect_options *ndo,
 {
 	u_int idx = 0;
 
-	while (*s && idx < maxlen) {
+	while (idx < maxlen && *s) {
 		safeputchar(ndo, *s);
 		idx++;
 		s++;

Bug#873805: CVE-2017-11542

[Guido Günther]

Hi,
On Thu, Aug 31, 2017 at 12:39:33PM +0200, Guido Günther wrote:
> Package: tcpdump
> X-Debbugs-CC: t...@security.debian.org 
> secure-testing-t...@lists.alioth.debian.org
> Severity: important
> Tags: security
> 
> Hi,
> 
> the following vulnerability was published for tcpdump.
> 
> CVE-2017-11541[0]:
> | tcpdump 4.9.0 has a heap-based buffer over-read in the lldp_print
> | function in print-lldp.c, related to util-print.c.

I've sent the attached patch upstream. I'd like to incorporate this into
an upload to wheezy at one point. Shall I handle sid, stretch or jessie
as well? Given the impact of the issue an update to stretch and jessie
is probably more suitable for a point release (which wheezy does not have).
Cheers,
 -- Guido
From: =?utf-8?q?Guido_G=C3=BCnther?= <a...@sigxcpu.org>
Date: Mon, 28 Aug 2017 19:22:27 +0200
Subject: CVE-2017-11542: pimv1_print: prevent out of bounds read

In case of an invalid type there's no bounds check when parsing the
version field. Add this unconditionally.

This fixes CVE-2017-11542 with the testcase from

https://github.com/hackerlib/hackerlib-vul/tree/master/tcpdump-vul/heap-buffer-overflow/print-pim

while

https://wiki.wireshark.org/SampleCaptures?action=AttachFile=get=IGMP+dataset.pcap

still passes
---
 print-pim.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/print-pim.c b/print-pim.c
index 2552595..674dddb 100644
--- a/print-pim.c
+++ b/print-pim.c
@@ -306,7 +306,7 @@ pimv1_print(netdissect_options *ndo,
 			pimv1_join_prune_print(ndo, [8], len - 8);
 		break;
 	}
-	if ((bp[4] >> 4) != 1)
+	if (ND_TTEST(bp[4]) && (bp[4] >> 4) != 1)
 		ND_PRINT((ndo, " [v%d]", bp[4] >> 4));
 	return;
 

Bug#873806: CVE-2017-11543

[Guido Günther]

Package: tcpdump
X-Debbugs-CC: t...@security.debian.org 
secure-testing-t...@lists.alioth.debian.org
Severity: important
Tags: security

Hi,

the following vulnerability was published for tcpdump.

CVE-2017-11541[0]:
| tcpdump 4.9.0 has a heap-based buffer over-read in the lldp_print
| function in print-lldp.c, related to util-print.c.

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-2017-11541
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11541

Please adjust the affected versions in the BTS as needed.

Note that I've not been able to reproduce the vulnerability with the
pcap file provided at


https://github.com/hackerlib/hackerlib-vul/tree/master/tcpdump-vul/global-overflow/print-sl

but given this has a CVE I figured it's safer to bring this to your
attention anyway.

Bug#873805: CVE-2017-11542

[Guido Günther]

Package: tcpdump
X-Debbugs-CC: t...@security.debian.org 
secure-testing-t...@lists.alioth.debian.org
Severity: important
Tags: security

Hi,

the following vulnerability was published for tcpdump.

CVE-2017-11541[0]:
| tcpdump 4.9.0 has a heap-based buffer over-read in the lldp_print
| function in print-lldp.c, related to util-print.c.

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-2017-11541
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11541

Please adjust the affected versions in the BTS as needed.

Bug#873804: CVE-2017-11541

[Guido Günther]

Package: tcpdump
X-Debbugs-CC: t...@security.debian.org 
secure-testing-t...@lists.alioth.debian.org
Severity: important
Tags: security

Hi,

the following vulnerability was published for tcpdump.

CVE-2017-11541[0]:
| tcpdump 4.9.0 has a heap-based buffer over-read in the lldp_print
| function in print-lldp.c, related to util-print.c.

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-2017-11541
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11541

Please adjust the affected versions in the BTS as needed.

Bug#873597: virt-manager: gir1.2-spice-client-gtk-3.0 package has been renamed to gir1.2-spiceclientgtk-3.0

[Guido Günther]

Hi,
On Wed, Aug 30, 2017 at 09:44:46PM +0200, Christoph Anton Mitterer wrote:
> On Wed, 2017-08-30 at 21:34 +0200, Guido Günther wrote:
> > You have gir1.2-spiceclientgtk-3.0 installed?
> Yes
> 
> # dpkg -l gir1.2-spiceclientgtk-3.0
> [snip snap]
> ii  gir1.2-spiceclientgtk-3.0 0.34-1amd64 
> GTK3
> widget for SPICE clients (GObject-Introspection)

It seems it has moved to a multiarch location:

$ dpkg -L gir1.2-spiceclientgtk-3.0
/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/girepository-1.0
/usr/lib/x86_64-linux-gnu/girepository-1.0/SpiceClientGtk-3.0.typelib
/usr/share
/usr/share/doc
/usr/share/doc/gir1.2-spiceclientgtk-3.0
/usr/share/doc/gir1.2-spiceclientgtk-3.0/changelog.Debian.gz
/usr/share/doc/gir1.2-spiceclientgtk-3.0/changelog.gz
/usr/share/doc/gir1.2-spiceclientgtk-3.0/copyright
$ dpkg -L gir1.2-spice-client-gtk-3.0
/.
/usr
/usr/lib
/usr/lib/girepository-1.0
/usr/lib/girepository-1.0/SpiceClientGtk-3.0.typelib
/usr/share
/usr/share/doc
/usr/share/doc/gir1.2-spice-client-gtk-3.0
/usr/share/doc/gir1.2-spice-client-gtk-3.0/changelog.Debian.gz
/usr/share/doc/gir1.2-spice-client-gtk-3.0/changelog.gz
/usr/share/doc/gir1.2-spice-client-gtk-3.0/copyright

but this shouldn't make any difference. You could try strace to see if
the typelib file gets picked up. Note that this is likely not related to
virt-manager but rather to how libgirepository picks up things.


> 
> 
> 
> 
> >  virt-viewer works?
> Uhm I haven't had that installed before,... so not sure whether it
> would have worked then, but now it says:
> Failed to connect: No virtual machine found

Confusing since it only acts on running VMs. I've sent a patch upstream
to turn this into:

 Failed to connect: No running virtual machine found

Cheers,
 -- Guido

Bug#873597: virt-manager: gir1.2-spice-client-gtk-3.0 package has been renamed to gir1.2-spiceclientgtk-3.0

[Guido Günther]

Hi,
On Wed, Aug 30, 2017 at 09:07:18PM +0200, Christoph Anton Mitterer wrote:
> Connections still seem to fail, e.g. I get a
> 
> "Error connecting to graphical console:
> Error opening Spice console, SpiceClientGtk missing"

You have gir1.2-spiceclientgtk-3.0 installed? virt-viewer works?

> 
> In the VM console window.
> 
> Cheers,
> Chris.

Bug#866818: libdbd-mysql-perl: CVE-2017-10788

[Guido Günther]

Hi,
On Wed, Aug 30, 2017 at 12:51:24PM -0400, Antoine Beaupre wrote:
> On Mon, Aug 28, 2017 at 02:56:36PM +0200, Guido Günther wrote:
> > I've pinged upstream again why the patch is still pending:
> > 
> > https://github.com/perl5-dbi/DBD-mysql/issues/120#issuecomment-325342844
> 
> After reviewing the original advisory and the suggested patch, I have
> opened that PR in:
> 
> https://github.com/perl5-dbi/DBD-mysql/pull/142
> 
> ... and will ship that in the coming LTS upload.

Great. Note that the original patch author is unhappy about the current
upstream handling of security fixes and is proposing a fork:

https://www.nntp.perl.org/group/perl.dbi.dev/2017/08/msg8030.html

This might be a timely coincidence but I don't think so.
Cheers,
 -- Guido

> 
> A.
> 
> -- 
> If it's important for you, you'll find a way.
> If it's not, you'll find an excuse.
> - Unknown

Bug#866818: libdbd-mysql-perl: CVE-2017-10788

[Guido Günther]

Hi,
On Sun, Jul 02, 2017 at 09:15:39AM +0200, Salvatore Bonaccorso wrote:
> Source: libdbd-mysql-perl
> Version: 4.028-2
> Severity: important
> Tags: security upstream
> 
> Hi,
> 
> the following vulnerability was published for libdbd-mysql-perl.
> 
> CVE-2017-10788[0]:
> | The DBD::mysql module through 4.043 for Perl allows remote attackers to
> | cause a denial of service (use-after-free and application crash) or
> | possibly have unspecified other impact by triggering (1) certain error
> | responses from a MySQL server or (2) a loss of a network connection to
> | a MySQL server. The use-after-free defect was introduced by relying on
> | incorrect Oracle mysql_stmt_close documentation and code examples.
> 
> Related discussions in [1] and [2]. [2] contains a proposed patch.
> 
> 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-2017-10788
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-10788
> [1] http://seclists.org/oss-sec/2017/q2/443
> [2] https://github.com/perl5-dbi/DBD-mysql/issues/120
> 
> Please adjust the affected versions in the BTS as needed.

I've pinged upstream again why the patch is still pending:

https://github.com/perl5-dbi/DBD-mysql/issues/120#issuecomment-325342844

Cheers,
 -- Guido

Bug#866821: libdbd-mysql-perl: CVE-2017-10789

[Guido Günther]

Hi,
On Sun, Jul 02, 2017 at 09:26:07AM +0200, Salvatore Bonaccorso wrote:
> Source: libdbd-mysql-perl
> Version: 4.028-2
> Severity: important
> Tags: security upstream
> 
> Hi,
> 
> the following vulnerability was published for libdbd-mysql-perl.
> 
> CVE-2017-10789[0]:
> | The DBD::mysql module through 4.043 for Perl uses the mysql_ssl=1
> | setting to mean that SSL is optional (even though this setting's
> | documentation has a "your communication with the server will be
> | encrypted" statement), which allows man-in-the-middle attackers to
> | spoof servers via a cleartext-downgrade attack, a related issue to
> | CVE-2015-3152.
> 
> Related upstream report handling this as a subtask at [1] and
> respective pull request with fixes for the issues discussed in [1] at
> [2].
> 
> 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-2017-10789
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-10789
> [1] https://github.com/perl5-dbi/DBD-mysql/issues/110
> [2] https://github.com/perl5-dbi/DBD-mysql/pull/114

While a patch for this was upstream in 4.042 (around
b6be72f321e920419bdc5c86998d9b9cb26c6791) upstream reverted _all_
changes of back to 4.041.

Bug#868773: khal FTBFS: AssertionError: assert not OSError(6, 'No such device or address')

[Guido Günther]

Hi,
On Tue, Jul 18, 2017 at 03:41:33PM +0300, Adrian Bunk wrote:
> Source: khal
> Version: 1:0.9.6-1
> Severity: serious
> 
> https://buildd.debian.org/status/fetch.php?pkg=khal=all=1:0.9.6-1=1500381224=0
> 
> ...
> === FAILURES 
> ===
>  test_import_from_stdin 
> 
> 
> runner = 
> 
> def test_import_from_stdin(runner):
> ics_data = 'This is some really fake icalendar data'
> 
> with mock.patch('khal.controllers.import_ics') as mocked_import:
> runner = runner()
> result = runner.invoke(main_khal, ['import'], input=ics_data)
> 
> >   assert not result.exception
> E   AssertionError: assert not OSError(6, 'No such device or address')
> E+  where OSError(6, 'No such device or address') =  OSError(6, 'No such device or address')>.exception
> 
> tests/cli_test.py:505: AssertionError
>  test_printics_read_from_stdin 
> _
> 
> runner = 
> 
> def test_printics_read_from_stdin(runner):
> runner = runner(command='printics')
> result = runner.invoke(main_khal, ['printics'], 
> input=_get_text('cal_d'))
> >   assert not result.exception
> E   AssertionError: assert not OSError(6, 'No such device or address')
> E+  where OSError(6, 'No such device or address') =  OSError(6, 'No such device or address')>.exception
> 
> tests/cli_test.py:683: AssertionError
> == 2 failed, 261 passed, 7 skipped, 3 xfailed in 9.52 seconds 
> ==
> E: pybuild pybuild:283: test: plugin distutils failed with: exit code=1: cd 
> /<>/.pybuild/pythonX.Y_3.6/build; python3.6 -m pytest tests
> dh_auto_test: pybuild --test --test-pytest -i python{version} -p 3.6 3.5 
> returned exit code 13
> debian/rules:26: recipe for target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Error 25

Any chance this gets fixed? It would be great to have a recent khal in
unstable/testing.
 -- Guido

Bug#872864: Checkout upstream signatures as well when using pristine-tar

[Guido Günther]

Package: git-buildpackage
Version: 0.9.0~exp4~2.gbpa7b96a
Severity: wishlist

We should checkout the upstream signatures from the pristine-tar branch
as well.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-1-amd64 (SMP w/4 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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages git-buildpackage depends on:
ii  devscripts 2.17.9
ii  git1:2.14.0-1
ii  man-db 2.7.6.1-2
ii  python33.5.3-3
ii  python3-dateutil   2.6.0-1
ii  python3-pkg-resources  36.0.1-1
ii  python3-six1.10.0-4

Versions of packages git-buildpackage recommends:
ii  cowbuilder0.85
ii  pbuilder  0.228.7
ii  pristine-tar  1.40
ii  python3-requests  2.12.4-1
ii  sbuild0.73.0-4

Versions of packages git-buildpackage suggests:
ii  python3-notify2  0.3-3
ii  sudo 1.8.20p2-1
ii  unzip6.0-21

-- no debconf information

Bug#872524: git-buildpackage: documenting import from upstream git

[Guido Günther]

Hi,

Thanks for the updates!

On Fri, Aug 18, 2017 at 04:37:02PM +1000, Vincent McIntyre wrote:
> Package: git-buildpackage
> Version: 0.8.18
> Severity: minor
> Tags: patch
> 
> thanks
> 
> Hi,
> I was looking in the manual for information on starting from scratch
> with an upstream git and found it a little terse for newbies like me.
> Please would you consider applying the attached patches.
> The published version [1] was tagged 0.9.0~exp3 but the text
> is the same in the sid version.
> 
> I was not quite sure what to say about the --no-checkout argument;
> something like this seems appropriate

It's mostly an optimization, we check out a branch based on v1.0 later
so there's no need to checkout out anything…

> 
>The debian/sid branch will start
>empty. Over time only debian packaging changes will be added here,
>usually just the debian/ directory.

You don't have only the debian/ directory on the debian-branch, it has
upstram + debian/. I'm happy to incorporate another patch for that.

Cheers,
 -- Guido

> 
> but I may be misunderstanding.
> 
> I also have a related question. The upstream repository has no tags;
> what should one tell gpb to do in this case?
> One can invent versions like 0~yymmdd [2] and apply such tags
> locally but that doesn't seem quite right.
> 
> 
> Kind regards
> Vince
> 
> [1] 
> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM-GIT
> [2] https://www.debian.org/doc/manuals/maint-guide/first.en.html#namever

Bug#872351: git-buildpackage: [pq] Please make the --abbrev= configurable

[Guido Günther]

Hi,
On Wed, Aug 16, 2017 at 06:28:16PM -0700, Chris Lamb wrote:
> Hi Guido,
> 
> > Thanks! Can you update docs/manpages/gbp-pq{,-rpm}.sgml as well?
> 
> With pleasure. Updated patch attached.

Thanks for the update. I've fixed a syntax error in config.py (attached)
but afterwards there are still test suite errors. I'll have look once
back from vacation.
Cheers,
 -- Guido
>From 75e18fc5bb4831df924bc708130b0a6ab311a230 Mon Sep 17 00:00:00 2001
Message-Id: <75e18fc5bb4831df924bc708130b0a6ab311a230.1502933971.git@sigxcpu.org>
From: Chris Lamb <la...@debian.org>
Date: Wed, 16 Aug 2017 18:28:16 -0700
Subject: [PATCH] pq: make --abbrev= configurable
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Closes: #872351
Signed-off-by: Guido Günther <a...@sigxcpu.org>
---
 docs/manpages/gbp-pq-rpm.sgml | 13 +
 docs/manpages/gbp-pq.sgml | 13 +
 gbp/config.py |  5 -
 gbp/scripts/common/pq.py  |  8 
 gbp/scripts/pq.py |  4 +++-
 gbp/scripts/pq_rpm.py |  7 ---
 6 files changed, 41 insertions(+), 9 deletions(-)

diff --git a/docs/manpages/gbp-pq-rpm.sgml b/docs/manpages/gbp-pq-rpm.sgml
index 63a8501a..b8535e6f 100644
--- a/docs/manpages/gbp-pq-rpm.sgml
+++ b/docs/manpages/gbp-pq-rpm.sgml
@@ -23,6 +23,7 @@
   --packaging-dir=DIRECTORY
   --spec-file=FILEPATH
   --upstream-tag=TAG-FORMAT
+  --abbrev=num
   --force
   --[no-]patch-numbers
   
@@ -157,6 +158,18 @@
   
 
   
+  
+--abbrev=NUM
+
+
+  
+	  When exporting a patch queue abbreviate commit, instead of showing the
+	  full 40-byte hexadecimal object name in header lines, show only a
+	  partial prefix of length NUM. This is
+	  useful when existing patches were not generated by .
+  
+
+  
   
 --force
 
diff --git a/docs/manpages/gbp-pq.sgml b/docs/manpages/gbp-pq.sgml
index 9b06ca3e..3af503c0 100644
--- a/docs/manpages/gbp-pq.sgml
+++ b/docs/manpages/gbp-pq.sgml
@@ -26,6 +26,7 @@
   --topic=topic
   --time-machine=num
   --[no-]drop
+  --abbrev=num
   --force
   --meta-closes=bug-close-tags
   --meta-closes-bugnum=bug-number-format
@@ -200,6 +201,18 @@
   a successful export
 
   
+  
+--abbrev=NUM
+
+
+  
+	  When exporting a patch queue abbreviate commit, instead of showing the
+	  full 40-byte hexadecimal object name in header lines, show only a
+	  partial prefix of length NUM. This is
+	  useful when existing patches were not generated by .
+  
+
+  
   
 --force
 
diff --git a/gbp/config.py b/gbp/config.py
index 80506090..ee44e3ff 100644
--- a/gbp/config.py
+++ b/gbp/config.py
@@ -101,7 +101,8 @@ class GbpOptionParser(OptionParser):
 @cvar def_config_files: config files we parse
 @type def_config_files: dict (type, path)
 """
-defaults = {'allow-unauthenticated': 'False',
+defaults = {'abbrev': 7,
+'allow-unauthenticated': 'False',
 'arch': '',
 'author-date-is-committer-date': 'False',
 'author-is-committer': 'False',
@@ -343,6 +344,8 @@ class GbpOptionParser(OptionParser):
 'drop':
 "In case of 'export' drop the patch-queue branch "
 "after export. Default is '%(drop)s'",
+'abbrev':
+"abbreviate commits to this length. default is '%(abbrev)s'",
 'commit':
 "commit changes after export, Default is '%(commit)s'",
 'rollback':
diff --git a/gbp/scripts/common/pq.py b/gbp/scripts/common/pq.py
index e9502ea3..cf98a6cb 100644
--- a/gbp/scripts/common/pq.py
+++ b/gbp/scripts/common/pq.py
@@ -185,7 +185,7 @@ def write_patch_file(filename, commit_info, diff):
 DEFAULT_PATCH_NUM_PREFIX_FORMAT = "%04d-"
 
 
-def format_patch(outdir, repo, commit_info, series, numbered=True,
+def format_patch(outdir, repo, commit_info, series, abbrev, numbered=True,
  path_exclude_regex=None, topic='', name=None, renumber=False,
  patch_num_prefix_format=DEFAULT_PATCH_NUM_PREFIX_FORMAT):
 """Create patch of a single commit"""
@@ -235,14 +235,14 @@ def format_patch(outdir, repo, commit_info, series, numbered=True,
 patch = None
 if paths:
 diff = repo.diff('%s^!' % commit_info['id'], paths=paths, stat=80,
- summary=True, text=True, abbrev=7, renames=False)
+ summary=True, text=True, abbrev=abbrev, renames=False)
 patch = write_patch_file(filepath, commit_info, diff)
 if patch:
 series.append(patch)
 return patch
 
 
-def format_diff(outdir, filename, repo, start, end, path_exclude_regex=No