NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: 
debian-installer-netboot-images_20170615+deb9u2.b1_all.changes
  ACCEPT

Bug#882576: marked as done (nmu: xerces-c_3.2.0+debian-2)

[Debian Bug Tracking System]

Your message dated Thu, 7 Dec 2017 03:36:50 +0100
with message-id 
and subject line Re: nmu: xerces-c_3.2.0+debian-2
has caused the Debian Bug report #882576,
regarding nmu: xerces-c_3.2.0+debian-2
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
882576: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882576
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Hi,

xerces-c is in transition (#881127) and has built successfully on all
archs except hurd.  However, based on my research into the failure, I
believe this failure may be transient, and would like to request a
binNMU for hurd arch only.

Thanks,
Bill

nmu xerces-c_3.2.0+debian-2 . hurd . unstable . -m "Rebuild due to suspected 
transient failure"



-- System Information:
Debian Release: 9.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
On Fri, 24 Nov 2017 00:32:33 -0500 William Blough  wrote:
> nmu xerces-c_3.2.0+debian-2 . hurd . unstable . -m "Rebuild due to suspected 
> transient failure"

Solved by a give-back.


Andreas--- End Message ---

Bug#881127: transition: xerces-c

[Andreas Beckmann]

Followup-For: Bug #881127

The build for hurd-i386 was now successful, please schedule binNMUs
there, too.


Thanks.

Andreas

Bug#883675: marked as done (nmu: ppl_1:1.2-2 logol_1.7.5-2)

[Debian Bug Tracking System]

Your message dated Wed, 6 Dec 2017 23:49:39 +0100
with message-id 
and subject line Re: Bug#883675: nmu: ppl_1:1.2-2 logol_1.7.5-2
has caused the Debian Bug report #883675,
regarding nmu: ppl_1:1.2-2 logol_1.7.5-2
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
883675: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883675
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu ppl_1:1.2-2 . ANY . unstable . -m "Rebuild against swi-prolog 7.6.2"
nmu logol_1.7.5-2 . ANY . unstable . -m "Rebuild against swi-prolog 7.6.2"

This does not show up as a transition automatically ...


Andreas
--- End Message ---
--- Begin Message ---
On 06/12/17 12:20, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> nmu ppl_1:1.2-2 . ANY . unstable . -m "Rebuild against swi-prolog 7.6.2"
> nmu logol_1.7.5-2 . ANY . unstable . -m "Rebuild against swi-prolog 7.6.2"
> 
> This does not show up as a transition automatically ...

Thanks, scheduled.

Emilio--- End Message ---

Bug#883725: transition: x265

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 06/12/17 21:58, Sebastian Ramacher wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-x265.html
> 
> It's this time of the year again. A new upstream release of x265 with a new
> SONAME bump has arrived. As usual, all reverse dependencies build fine against
> the new version.

Go ahead.

Emilio

Processed: Re: Bug#883725: transition: x265

[Debian Bug Tracking System]

Processing control commands:

> tags -1 confirmed
Bug #883725 [release.debian.org] transition: x265
Added tag(s) confirmed.

-- 
883725: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883725
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

NEW changes in oldstable-new

[Debian FTP Masters]

Processing changes file: 
debian-installer-netboot-images_20150422+deb8u4.b5_amd64.changes
  ACCEPT

NEW changes in stable-new

[Debian FTP Masters]

Processing changes file: 
debian-installer-netboot-images_20170615+deb9u2.b1_source.changes
  ACCEPT

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[Adam D. Barratt]

On Wed, 2017-12-06 at 19:13 +0100, intrigeri wrote:
> intrigeri:
> > At first glance this very much looks like a bug in the custom
> > kernel
> > you're using.
> 
> According to #883703 this bug affects the mainline Linux kernel as
> well so this stretch-pu may break as many use cases at it'll repair
> when running Linux 4.13+ on Stretch :/
> 
> Dear release team, how can we revert this s-p-u? Should I upload
> 2.11.0-3+deb9u2 that reverts to what we had in 2.11.0-3?

I don't think there's a particular need for that currently (and it
wouldn't get accepted until after the point release anyway). We'll ask
ftp-master not to include the package during the point release at the
weekend and in the meantime affected users still have the possibility
to downgrade the package to its current stable version.

Regards,

Adam

Processed: transition: x265

[Debian Bug Tracking System]

Processing control commands:

> forwarded -1 https://release.debian.org/transitions/html/auto-x265.html
Bug #883725 [release.debian.org] transition: x265
Set Bug forwarded-to-address to 
'https://release.debian.org/transitions/html/auto-x265.html'.

-- 
883725: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883725
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#883725: transition: x265

[Sebastian Ramacher]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: forwarded -1 https://release.debian.org/transitions/html/auto-x265.html

It's this time of the year again. A new upstream release of x265 with a new
SONAME bump has arrived. As usual, all reverse dependencies build fine against
the new version.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[intrigeri]

intrigeri:
> At first glance this very much looks like a bug in the custom kernel
> you're using.

According to #883703 this bug affects the mainline Linux kernel as
well so this stretch-pu may break as many use cases at it'll repair
when running Linux 4.13+ on Stretch :/

Dear release team, how can we revert this s-p-u? Should I upload
2.11.0-3+deb9u2 that reverts to what we had in 2.11.0-3?

I'm very sorry for the mess.

Cheers,
-- 
intrigeri

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[intrigeri]

Hi again Fabian & release team,

Fabian Grünbichler:
> On Wed, Dec 06, 2017 at 03:28:03PM +0100, intrigeri wrote:
>> > it potentially breaks systems using a custom/backports/newer kernel
>> > and AA profiles requiring features not supported by the pinned 4.9
>> > feature set.
>> 
>> In this case, "breaks" == the AppArmor confinement becomes weaker,
>> but the application keeps working.

> not the case for all scenarios unfortunately. LXC containers using the
> upstream profiles (and a kernel supporting the needed features) don't
> start anymore:

> apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 
> profile="/usr/bin/lxc-start" name="/" pid=21550 comm="lxc-start" flags="rw, 
> rslave"

Wow, Assuming you're indeed running with the 4.9 feature set I've
uploaded, that's definitely a bug: the 4.9 feature set is supposed to
fully disable mount mediation, so a mount denial should never happen.
At first glance this very much looks like a bug in the custom kernel
you're using.

If you can reproduce this with a pristine 4.13 or 4.14 Debian kernel,
then I'm very sorry and I agree we should revert this s-p-u until this
kernel bug is fixed in mainline; I'll gladly help you report this bug
upstream. If, however, you can't reproduce this bug with a Debian
kernel, well, then it's a bug in the kernel patches you've applied and
I think we should leave s-p-u as-is.

Possibly helpful: can you please share the content of
/etc/apparmor.d/cache/.features on the system that exposes
this problem?

Cheers,
-- 
intrigeri

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[Fabian Grünbichler]

On Wed, Dec 06, 2017 at 03:28:03PM +0100, intrigeri wrote:
> Hi,
> 
> I'll first clarify because it seems to me you're using the same word
> with very different meanings in a comparison:
> 
> Fabian Grünbichler:
> > TL;DR: while pinning the features prevents breakage for people using
> > AA who install a more recent kernel from backports,
> 
> In this case, "breakage" == application stops working after installing
> a newer kernel.
> 
> > it potentially breaks systems using a custom/backports/newer kernel
> > and AA profiles requiring features not supported by the pinned 4.9
> > feature set.
> 
> In this case, "breaks" == the AppArmor confinement becomes weaker,
> but the application keeps working.

not the case for all scenarios unfortunately. LXC containers using the
upstream profiles (and a kernel supporting the needed features) don't
start anymore:

apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 
profile="/usr/bin/lxc-start" name="/" pid=21550 comm="lxc-start" flags="rw, 
rslave"

the profile[1] contains:

mount options=(rw, make-slave) -> **,
mount options=(rw, make-rslave) -> **,

the same profile and container worked fine without feature pinning. this
is not specific to certain container configurations either AFAICT.

> 
> > since
> > both the AA config file itself and the feature set file are conffiles,
> > overriding is not easily possible without conffile modification.
> 
> Right. Sorry I did not think about this Debian derivative use case.
> 

while it is sometimes cumbersome to work around such issues, it is
understandable to not have them on one's radar, especially if the
upstream software does not provide an easy way to extend configuration
files.

> > I'll of course defer to intrigeri and the release team on whether to go
> > ahead as-is, include the patch to allow easier overriding or postpone
> > the apparmor stable update until the next cycle to allow for further
> > discussion.
> 
> I slightly prefer fixing ASAP a non-default use case I want to support
> in Debian (that's what we did in s-p-u already), even if it makes
> a derivative's life slightly harder temporarily when using an much
> more non-default configuration. I would understand if the release team
> prefers to delay this update to a future point release though.
> 

obviously with my downstream hat on, I'd strongly prefer not having to
carry apparmor packages for the remainder of Stretch ;) but if necessary
we will take this route, and work together with upstream and you to get
more easily overridden apparmor config including feature pinning in time
for Buster, hopefully eliminating the need for forked apparmor packages.

> But I can live with both approaches. The vast majority of Stretch
> users are not affected by either of the problems described
> above anyway.

I am glad we noticed it before the point release went live!

1: 
https://github.com/lxc/lxc/blob/d680929bbc07e399ceaf8954c2059bd788905fc7/config/apparmor/abstractions/start-container

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[intrigeri]

Hi,

I'll first clarify because it seems to me you're using the same word
with very different meanings in a comparison:

Fabian Grünbichler:
> TL;DR: while pinning the features prevents breakage for people using
> AA who install a more recent kernel from backports,

In this case, "breakage" == application stops working after installing
a newer kernel.

> it potentially breaks systems using a custom/backports/newer kernel
> and AA profiles requiring features not supported by the pinned 4.9
> feature set.

In this case, "breaks" == the AppArmor confinement becomes weaker,
but the application keeps working.

> since
> both the AA config file itself and the feature set file are conffiles,
> overriding is not easily possible without conffile modification.

Right. Sorry I did not think about this Debian derivative use case.

> I'll of course defer to intrigeri and the release team on whether to go
> ahead as-is, include the patch to allow easier overriding or postpone
> the apparmor stable update until the next cycle to allow for further
> discussion.

I slightly prefer fixing ASAP a non-default use case I want to support
in Debian (that's what we did in s-p-u already), even if it makes
a derivative's life slightly harder temporarily when using an much
more non-default configuration. I would understand if the release team
prefers to delay this update to a future point release though.

But I can live with both approaches. The vast majority of Stretch
users are not affected by either of the problems described
above anyway.

Cheers,
-- 
intrigeri

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[Fabian Grünbichler]

On Sat, Dec 02, 2017 at 07:21:59PM +, Adam D. Barratt wrote:
> Control: tags -1 + pending
> 
> On Sat, 2017-12-02 at 14:37 +0100, intrigeri wrote:
> > Adam D. Barratt:
> > > Please go ahead, bearing in mind that the window for getting fixes
> > > into
> > > the 9.3 point release closes during this weekend.
> > 
> > Thanks, uploaded.
> > 
> 
> Flagged for acceptance.
> 
> Regards,
> 
> Adam
> 

please see #879585 / #882697 for potential fallout caused by this
update.

TL;DR: while pinning the features prevents breakage for people using
AA who install a more recent kernel from backports, it potentially
breaks systems using a custom/backports/newer kernel and AA profiles
requiring features not supported by the pinned 4.9 feature set. since
both the AA config file itself and the feature set file are conffiles,
overriding is not easily possible without conffile modification.

we (a Debian derived hypervisor distribution) are using Debian Stretch
as base, but ship a more recent 4.13-based kernel with full AA support
and LXC with matching AA profiles. pinning the features to those offered
by Stretch's 4.9 kernel would break all user installations using LXC,
and we (as a distribution) could only override this pinning by shipping
our own apparmor packages (which we would like to avoid if possible).

I'll of course defer to intrigeri and the release team on whether to go
ahead as-is, include the patch to allow easier overriding or postpone
the apparmor stable update until the next cycle to allow for further
discussion.

thanks for your time and consideration!

Bug#883675: nmu: ppl_1:1.2-2 logol_1.7.5-2

[Andreas Beckmann]

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

nmu ppl_1:1.2-2 . ANY . unstable . -m "Rebuild against swi-prolog 7.6.2"
nmu logol_1.7.5-2 . ANY . unstable . -m "Rebuild against swi-prolog 7.6.2"

This does not show up as a transition automatically ...


Andreas