Bug#989193: fixed in apparmor-profiles-extra 1.34

[Paul Wise]

On Wed, 09 Jun 2021 07:18:32 + intrigeri wrote:

>* apt-cacher-ng: allow link operations on the contents of the cache 
> directory
>  (Closes: #989193). Thanks to Eduard Bloch  for the patch.

Here is a little bump to postpone the autoremoval so the fix gets into testing.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#990158: shim-signed-common: No UEFI boot with error "Could not create MokListXRT"

[Steve McIntyre]

Hi Ayke,

Thanks for your bug report, and apologies for the problem :-/

On Mon, Jun 21, 2021 at 09:00:15PM +0200, Ayke Halder wrote:
>Package: shim-signed-common
>Version: 1.33+15+1533136590.3beb971-7
>Severity: critical
>Justification: breaks the whole system
>
>Dear Maintainer,
>
>## What led up to the situation?
>
>Upgrade:
>
>* shim-signed:amd64 (1.33+15+1533136590.3beb971-7,
>1.36~1+deb10u1+15.4-5~deb10u1)
>* shim-signed-common:amd64 (1.33+15+1533136590.3beb971-7,
>1.36~1+deb10u1+15.4-5~deb10u1)
>
>System: Dell T5600 with BIOS Revision A19
>
>
>## What was the outcome of this action?
>
>System is unbootable on booting via UEFI. System shows error message and then
>powers off immediately:
>
>"Could not create MokListXRT: Out of Resources
>Something has gone seriously wrong: import_mok_state() failed: Out of
>Resources"
>
>
>## What outcome did you expect instead?
>
>A normal booting system loading GRUB.
>
>
>## Also reproducible with Debian Live-Installations-Image
>
>On affected hardware like "Dell T5600" doing a UEFI boot from USB with …
>
>* debian-live-10.10.0-amd64-standard.iso does *not* work.
>* debian-live-10.9.0-amd64-standard.iso works.
>
>
>## Related resources
>
>Might be related to:
>
>* https://bugzilla.suse.com/show_bug.cgi?id=1185261

Yes, it looks like exactly the same problem. :-(

Several of the shim maintainers in various distributions are now
seeing reports like this. It seems that lots of machines are short of
space to store the new MokListXRT variable. Since the buster update
this weekend, yours is the second problem report I've seen.

Ubuntu have a patch to disable the variable mirroring here. I was not
expecting we'd need it, but it looks like I was wrong.

In terms of making your system boot, I'd suggest temporarily one of:

 * switch back to an older shim-signed package
 * disable Secure Boot and remove shim-signed

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

Bug#987461: libuima-adapter-soap-java is empty

[tony mancill]

On Tue, Jun 22, 2021 at 07:57:13AM +0900, Hideki Yamane wrote:
> Hi,
> 
> On Mon, 21 Jun 2021 11:52:14 -0700
> tony mancill  wrote:
> > I saw the note in the changelog that Breaks is in fact there to remove
> > the empty package, but it's not happening for me when I try to upgrade
> > locally.  My test case is to install uima-utils (which will install
> > libuima-adapter-soap-java via Recommends) and then try to upgrade the
> > binaries to 2.10.2-4 using dpkg.  
> 
>  Well, it would remove libuima-adapter-soap-java if I've tested it
>  on chroot env as below.
> 
> # apt install /tmp/libuima-core-java_2.10.2-4_all.deb 
> (snip)
> The following packages will be REMOVED:
>   libuima-adapter-soap-java
> The following packages will be upgraded:
>   libuima-core-java
> 1 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
> Need to get 0 B/1513 kB of archives.
> After this operation, 12.3 kB disk space will be freed.
> 
> 
> > The only way I can make this work is remove libuima-adapter-soap-java
> > manually.  Are you sure that Breaks is necessary?  apt-get autoremove
> > will clean up libuima-adapter-soap-java at some point.
> 
>  Okay, libuima-adapter-soap-java is empty now, just manual autoremove
>  is fine. 

Ah, I should have tested with apt.  I see that it works fine.

> > I took a look at policy to see if Breaks + Replaces should be used in
> > this situation, but I'm not sure it really applies (although I think it
> > would work better than just Breaks).  Still, I'm unsure about the need
> > for Breaks for this empty package clean-up use case.
> 
>  I don't think "Replaces" to be used in this situation since it
>  does not provide any fuctions as same as previous one.

Agreed.

> > Any concerns if I drop the Breaks before the upload?
> 
>  None, please go ahead for bullseye :)

My apologies if using Breaks in this way is a common pattern.  I am
simply not familiar with it.  If you have used the pattern before, I
will upgrade the package as-is, since your way is cleaner.  Otherwise, I
will remove the Breaks.

Thank you for the response.  I will upload once I hear back from you.

Thank you!
tony


signature.asc
Description: PGP signature

Bug#987461: libuima-adapter-soap-java is empty

[Hideki Yamane]

Hi,

On Mon, 21 Jun 2021 11:52:14 -0700
tony mancill  wrote:
> I saw the note in the changelog that Breaks is in fact there to remove
> the empty package, but it's not happening for me when I try to upgrade
> locally.  My test case is to install uima-utils (which will install
> libuima-adapter-soap-java via Recommends) and then try to upgrade the
> binaries to 2.10.2-4 using dpkg.  

 Well, it would remove libuima-adapter-soap-java if I've tested it
 on chroot env as below.

# apt install /tmp/libuima-core-java_2.10.2-4_all.deb 
(snip)
The following packages will be REMOVED:
  libuima-adapter-soap-java
The following packages will be upgraded:
  libuima-core-java
1 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 0 B/1513 kB of archives.
After this operation, 12.3 kB disk space will be freed.


> The only way I can make this work is remove libuima-adapter-soap-java
> manually.  Are you sure that Breaks is necessary?  apt-get autoremove
> will clean up libuima-adapter-soap-java at some point.

 Okay, libuima-adapter-soap-java is empty now, just manual autoremove
 is fine. 

> I took a look at policy to see if Breaks + Replaces should be used in
> this situation, but I'm not sure it really applies (although I think it
> would work better than just Breaks).  Still, I'm unsure about the need
> for Breaks for this empty package clean-up use case.

 I don't think "Replaces" to be used in this situation since it
 does not provide any fuctions as same as previous one.
 

> Any concerns if I drop the Breaks before the upload?

 None, please go ahead for bullseye :)



-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Processed: Re: Bug#990123: [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.1

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 iptables-netflow-dkms
Bug #990123 
[iptables-netflow-dkms,linux-headers-4.19.0-17-amd64,linux-headers-4.19.0-17-i686-pae]
 [buster regression] iptables-netflow-dkms: No more compiles since 
linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream 
kernel API regression in 4.19.191?)
Warning: Unknown package 'linux-headers-4.19.0-17-i686-pae'
Bug reassigned from package 
'iptables-netflow-dkms,linux-headers-4.19.0-17-amd64,linux-headers-4.19.0-17-i686-pae'
 to 'iptables-netflow-dkms'.
No longer marked as found in versions linux/4.19.194-1, iptables-netflow/2.3-5, 
and iptables-netflow/2.5.1-2.
Ignoring request to alter fixed versions of bug #990123 to the same values 
previously set
> found -1 2.3-5
Bug #990123 [iptables-netflow-dkms] [buster regression] iptables-netflow-dkms: 
No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function 
‘ref_module’" (Upstream kernel API regression in 4.19.191?)
Marked as found in versions iptables-netflow/2.3-5.
> notfound -1 2.5.1-2
Bug #990123 [iptables-netflow-dkms] [buster regression] iptables-netflow-dkms: 
No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function 
‘ref_module’" (Upstream kernel API regression in 4.19.191?)
Ignoring request to alter found versions of bug #990123 to the same values 
previously set

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

Bug#990123: [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.19.191?)

[Axel Beckert]

Control: reassign -1 iptables-netflow-dkms
Control: found -1 2.3-5
Control: notfound -1 2.5.1-2

Hi Salvatore,

Salvatore Bonaccorso wrote:
> On Mon, Jun 21, 2021 at 01:33:01PM +0200, Axel Beckert wrote:
> > Since kernel packages linux-{image,headers}-4.19.0-17-*, at least with
> > -amd64 and -i686-pae, iptables-netflow-dkms no more compiles its kernel
> > module upon kernel installation:
> > 
> > In file included from /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:75:
> > /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c: In function 
> > ‘register_ct_events’:
> > /var/lib/dkms/ipt-netflow/2.3/build/compat.h:173:21: error: implicit 
> > declaration of function ‘ref_module’; did you mean ‘use_module’? 
> > [-Werror=implicit-function-declaration]
> >  # define use_module ref_module
> >  ^~
> > /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:5399:3: note: in 
> > expansion of macro ‘use_module’
> >use_module(THIS_MODULE, netlink_m);
> >^~
> > 
> > Reading the kernel changelog, there are a few very suspicious entries
> > listed under upstream version 4.19.191:
> > 
> > - modules: mark ref_module static
> > - modules: mark find_symbol static
> > - modules: mark each_symbol_section static
> > 
> > One of the commits above (8745aa4e resp. 7ef5264d) states:
> > 
> >   ref_module isn't used anywhere outside of module.c.
> > 
> > Which is only seems true if you ignore any third-party kernel modules
> > out there.
[…]
> 7ef5264de773 ("modules: mark ref_module static") indeed is likely to
> cause the issue, or basically the patchset around that.

Thanks for that confirmation.

> That initially landed in 5.9-rc1,

Right, I saw that the list of tags including that change on Github. I
though wondered why 2.5.1-2 works in Sid/Bullseye but not on Buster —
but probably because the current #ifdefs just don't expect that fix
being needed for any kernel before 5.9.

> There is some background here:
> 
> https://lore.kernel.org/lkml/20200730061027.29472-1-...@lst.de/
> https://lore.kernel.org/stable/ymxnxqzcp0g1f...@kroah.com/

Thanks for that! I didn't really expected license enforcing to be the
background. With that background I do understand that change much
more. :-)

> That said, upstream won't really revert those changes.

Understandable. I'm though surprised that this got backported. But I
guess the pain without it is bigger than this one precise cut.

> So in my biased view, what would be needed for buster indeed would be
> an equivalent approach in buster for iptables-netflow unbreaking this
> regression similar as done in 2.5.1-1 wit the
> 
> cherry-pick-adfc6318-fix-compilation-for-5.9-workaround-ref_module-unexport.patch

Thanks for pointing out that this patch is already in 2.5.1-1.

I actually forgot that I had to solve this already once in the past
(probably because the solution was submitted as pull request upstream
against 2.5.1) and since 2.5.1-2 didn't work on buster either, I
didn't expect it to be more or less fixed already. But in the end it's
hopefully just replacing

#if LINUX_VERSION_CODE < KERNEL_VERSION(5,9,0)

with a bit more complex condition including further constraints.

> I had no time to check if the patch applies and what changes need to
> be done,

No need to worry. That's not your job but mine. :-)

> but basically what was added there fo fix compilation with Linux 5.9
> (which introduced the above changes initially) would need as well
> for the 4.19.y stable series.

Ack.

Thanks again.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: PGP signature

Bug#990123: [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.19.191?)

[Salvatore Bonaccorso]

Control: affects -1 + release.debian.org

Hi Axel,

On Mon, Jun 21, 2021 at 01:33:01PM +0200, Axel Beckert wrote:
> Package: 
> iptables-netflow-dkms,linux-headers-4.19.0-17-amd64,linux-headers-4.19.0-17-i686-pae
> Severity: serious
> Version: iptables-netflow/2.3-5
> Version: iptables-netflow/2.5.1-2
> Version: linux/4.19.194-1
> Tags: buster
> Forwarded: https://github.com/aabc/ipt-netflow/issues/177
> 
> Since kernel packages linux-{image,headers}-4.19.0-17-*, at least with
> -amd64 and -i686-pae, iptables-netflow-dkms no more compiles its kernel
> module upon kernel installation:
> 
> In file included from /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:75:
> /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c: In function 
> ‘register_ct_events’:
> /var/lib/dkms/ipt-netflow/2.3/build/compat.h:173:21: error: implicit 
> declaration of function ‘ref_module’; did you mean ‘use_module’? 
> [-Werror=implicit-function-declaration]
>  # define use_module ref_module
>  ^~
> /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:5399:3: note: in expansion 
> of macro ‘use_module’
>use_module(THIS_MODULE, netlink_m);
>^~
> 
> Reading the kernel changelog, there are a few very suspicious entries
> listed under upstream version 4.19.191:
> 
> - modules: mark ref_module static
> - modules: mark find_symbol static
> - modules: mark each_symbol_section static
> 
> One of the commits above (8745aa4e resp. 7ef5264d) states:
> 
>   ref_module isn't used anywhere outside of module.c.
> 
> Which is only seems true if you ignore any third-party kernel modules
> out there.
> 
> So why is the kernel API suddenly removing API-code used by third-party
> modules inmidst a stable update? This looks like a regression to me.  I
> thought that stable updates only change the ABI, but not the API. (Well,
> at least upstream and in Debian. :-)
> 
> I also tried the iptables-netflow-dkms 2.5.1-2 from Bullseye on Buster,
> but it fails to build the kernel module for 4.19.0-17-* when as well.
> 
> 2.5.1-2 though still works fine on Sid/Bullseye, hence marked as found
> in the version in Sid, but tagged buster. In case this causes issues in
> the BTS or the release team scripts, please rather remove 2.5.1-2 from
> the "found" versions instead of removing the buster tag — unless the
> same regression gets introduced into Sid and Bullseye as well.
> 
> Debian kernel maintainers: If this 3rd-party-module-breaking regression
> was really intended and won't be fixed, please reassign the bug to
> iptables-netflow-dkms only.
> 
> I also reported this issue to iptables-netflow upstream at
> https://github.com/aabc/ipt-netflow/issues/177 as I think it at least
> should update the version based ifdef checks in something which looks
> like a similar issue in kernel 5.13, see
> https://github.com/aabc/ipt-netflow/commit/5aae3791922bd3df878605b15e83ea48a4bd096c
> which is part of iptables-netflow upstream's 2.6 release, not yet
> packaged due to the freeze for bullseye.
> 
> I'll try and see if I can get that fix backported to the package in
> buster (and if needed, later to the one in bullseye as well) and will
> see if it actually helps in this case, too.
> 
> JFTR: dkms from buster-backports (as reported below) is only installed
> as I needed it for the iptables-netflow-dkms package from bullseye. It
> happened with dkms from buster before as well.

7ef5264de773 ("modules: mark ref_module static") indeed is likely to
cause the issue, or basically the patchset around that. That initially
landed in 5.9-rc1, and recently got backported upstream to 4.19.191.

There is some background here:

https://lore.kernel.org/lkml/20200730061027.29472-1-...@lst.de/

and

https://lore.kernel.org/stable/ymxnxqzcp0g1f...@kroah.com/

That said, upstream won't really revert those changes. 

So in my biased view, what would be needed for buster indeed would be
an equivalent approach in buster for iptables-netflow unbreaking this
regression similar as done in 2.5.1-1 wit the

cherry-pick-adfc6318-fix-compilation-for-5.9-workaround-ref_module-unexport.patch

patch.

I had no time to check if the patch applies and what changes need to
be done, but basically what was added there fo fix compilation with
Linux 5.9 (which introduced the above changes initially) would need as
well for the 4.19.y stable series.

Regards,
Salvatore

Processed: Re: Bug#990123: [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.1

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + release.debian.org
Bug #990123 
[iptables-netflow-dkms,linux-headers-4.19.0-17-amd64,linux-headers-4.19.0-17-i686-pae]
 [buster regression] iptables-netflow-dkms: No more compiles since 
linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream 
kernel API regression in 4.19.191?)
Warning: Unknown package 'linux-headers-4.19.0-17-i686-pae'
Added indication that 990123 affects release.debian.org
Warning: Unknown package 'linux-headers-4.19.0-17-i686-pae'

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

Bug#922981: tagging 922981 (ca-certificates-java: /etc/ca-certificates/update.d/jks-keystore doesn't update /etc/ssl/certs/java/cacerts)

[Paul Gevers]

Hi Julien,

On Tue, 18 May 2021 21:38:46 +0200 Paul Gevers  wrote:
> On 08-04-2021 19:33, Julien Cristau wrote:
> > I've started to look at it, I'm afraid building up context on this
> > stuff to understand what it's doing is going to take a while...
> 
> Just a friendly ping. Did you get anywhere with this yet?

Another month has passed and we now have a *tentative* release date. Is
there any progress on this bug? The patch is tested according to Andreas.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990000: marked as done (tor: CVE-2021-34548 CVE-2021-34549 CVE-2021-34550)

[Debian Bug Tracking System]

Your message dated Mon, 21 Jun 2021 19:02:13 +
with message-id 
and subject line Bug#99: fixed in tor 0.3.5.15-1
has caused the Debian Bug report #99,
regarding tor: CVE-2021-34548 CVE-2021-34549 CVE-2021-34550
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.)


-- 
99: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=99
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: tor
Version: 0.4.5.8-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

CVE-2021-34548[1], CVE-2021-34549[2] and CVE-2021-34550[3].

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-2021-34548
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-34548
[1] https://security-tracker.debian.org/tracker/CVE-2021-34549
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-34549
[2] https://security-tracker.debian.org/tracker/CVE-2021-34550
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-34550

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore
--- End Message ---
--- Begin Message ---
Source: tor
Source-Version: 0.3.5.15-1
Done: Peter Palfrader 

We believe that the bug you reported is fixed in the latest version of
tor, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 990...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Peter Palfrader  (supplier of updated tor package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 18 Jun 2021 10:27:26 +0200
Source: tor
Architecture: source
Version: 0.3.5.15-1
Distribution: buster-security
Urgency: medium
Maintainer: Peter Palfrader 
Changed-By: Peter Palfrader 
Closes: 99
Changes:
 tor (0.3.5.15-1) buster-security; urgency=medium
 .
   * New upstream version, fixing several (security) issues (closes: #99).
 For a full list see the upstream changelog.  It includes:
 - Don't allow relays to spoof RELAY_END or RELAY_RESOLVED cell on
   half-closed streams. Previously, clients failed to validate which
   hop sent these cells: this would allow a relay on a circuit to end
   a stream that wasn't actually built with it.
   Bugfix on 0.3.5.1-alpha. This issue is also tracked as TROVE-2021-
   003 and CVE-2021-34548.
 - Detect more failure conditions from the OpenSSL RNG code.
   Previously, we would detect errors from a missing RNG
   implementation, but not failures from the RNG code itself.
   Fortunately, it appears those failures do not happen in practice
   when Tor is using OpenSSL's default RNG implementation.
   Bugfix on 0.2.8.1-alpha. This issue is also tracked as
   TROVE-2021-004. Reported by Jann Horn at Google's Project Zero.
 - Resist a hashtable-based CPU denial-of-service attack against
   relays. Previously we used a naive unkeyed hash function to look
   up circuits in a circuitmux object. An attacker could exploit this
   to construct circuits with chosen circuit IDs, to create
   collisions and make the hash table inefficient. Now we use a
   SipHash construction here instead. Bugfix on
   0.2.4.4-alpha. This issue is also tracked as TROVE-2021-005 and
   CVE-2021-34549. Reported by Jann Horn from Google's Project Zero.
 - Fix an out-of-bounds memory access in v3 onion service descriptor
   parsing. An attacker could exploit this bug by crafting an onion
   service descriptor that would crash any client that tried to visit
   it. Bugfix on 0.3.0.1-alpha. This issue is also
   tracked as TROVE-2021-006 and CVE-2021-34550. Reported by Sergei
   Glazunov from Google's Project Zero.
Checksums-Sha1:
 08eeead59d5386910a3833ada2a63b7d6cdec84f 1968 tor_0.3.5.15-1.dsc
 6dfbd329281627c3b680da6d6bc160e830410f17 7136322 tor_0.3.5.15.orig.tar.gz
 55ac245c9df8d4e27075d783ee84c81adc4b008c 51228 tor_0.3.5.15-1.diff.gz
Checksums-Sha256:
 73dec977ceaf471fc6081249b848914309793b81b9ccb88ac57455e

Bug#989631: marked as done (nettle: CVE-2021-3580: Remote crash in RSA decryption via manipulated ciphertext)

[Debian Bug Tracking System]

Your message dated Mon, 21 Jun 2021 19:02:07 +
with message-id 
and subject line Bug#989631: fixed in nettle 3.4.1-1+deb10u1
has caused the Debian Bug report #989631,
regarding nettle: CVE-2021-3580: Remote crash in RSA decryption via manipulated 
ciphertext
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.)


-- 
989631: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989631
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: nettle
Version: 3.7.2-3
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for nettle.

CVE-2021-3580[0]:
| Remote crash in RSA decryption via manipulated ciphertext

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-2021-3580
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3580
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1967983
[2] 
https://git.lysator.liu.se/nettle/nettle/-/commit/0ad0b5df315665250dfdaa4a1e087f4799edaefe
[3] 
https://git.lysator.liu.se/nettle/nettle/-/commit/485b5e2820a057e873b1ba812fdb39cae4adf98c
[4] 
https://git.lysator.liu.se/nettle/nettle/-/commit/485b5e2820a057e873b1ba812fdb39cae4adf98c

Regards,
Salvatore
--- End Message ---
--- Begin Message ---
Source: nettle
Source-Version: 3.4.1-1+deb10u1
Done: Magnus Holmgren 

We believe that the bug you reported is fixed in the latest version of
nettle, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 989...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Magnus Holmgren  (supplier of updated nettle package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 11 Jun 2021 19:53:20 +0200
Source: nettle
Architecture: source
Version: 3.4.1-1+deb10u1
Distribution: buster-security
Urgency: high
Maintainer: Magnus Holmgren 
Changed-By: Magnus Holmgren 
Closes: 985652 989631
Changes:
 nettle (3.4.1-1+deb10u1) buster-security; urgency=high
 .
   * Fix for CVE-2021-3580 - potential crash on invalid input to the RSA
 decryption functions (Closes: #989631).
   * Fix for CVE-2021-20305 - bug in ECDSA signature verification that
 could lead to a denial of service attack (via an assertion failure) or
 possibly incorrect results, backported from 3.7.2 by Marc Deslauriers
  (Closes: #985652).
Checksums-Sha1:
 23fa2e1210934c2bf273688cc0eb85828dec108c 2290 nettle_3.4.1-1+deb10u1.dsc
 56a81ed4a8d35489d8bddd99d5262fe3958a52b4 1947053 nettle_3.4.1.orig.tar.gz
 32e42277da6045ef07b31a163f1479cd7a36eefd 2476 nettle_3.4.1.orig.tar.gz.asc
 a70315a26f6b06c637c2d5fbd46998b5d2162874 26508 
nettle_3.4.1-1+deb10u1.debian.tar.xz
 c835ffcaeeacce3c2ddc7027cfcd6e712a75212c 6072 
nettle_3.4.1-1+deb10u1_source.buildinfo
Checksums-Sha256:
 b38c9a78ae0732a94d06dbc811479f6ee8357bd47604dfa92f0d0801b148eebc 2290 
nettle_3.4.1-1+deb10u1.dsc
 f941cf1535cd5d1819be5ccae5babef01f6db611f9b5a777bae9c7604b8a92ad 1947053 
nettle_3.4.1.orig.tar.gz
 07b265366b46bc67950da3f34687235eaa85c45b326e42bb7c9b58830b651d28 2476 
nettle_3.4.1.orig.tar.gz.asc
 b847de5ccd50b9bc0aa56dd7fe750c224683174676dde69c86f62bece52ff4ba 26508 
nettle_3.4.1-1+deb10u1.debian.tar.xz
 ad09746fc846ae3df71208bde6f999c60439f26622b15adbc869e0690d6adcf8 6072 
nettle_3.4.1-1+deb10u1_source.buildinfo
Files:
 da1cbe8255a65c63d4d9fb18c960b512 2290 libs optional nettle_3.4.1-1+deb10u1.dsc
 9bdebb0e2f638d3b9d91f7fc264b70c1 1947053 libs optional nettle_3.4.1.orig.tar.gz
 ad85955beeebd9807bd5f5b45cd4f70e 2476 libs optional 
nettle_3.4.1.orig.tar.gz.asc
 65059423e88d34c1dd5359728d0c829a 26508 libs optional 
nettle_3.4.1-1+deb10u1.debian.tar.xz
 19338059add839d800e725b30ab9f161 6072 libs optional 
nettle_3.4.1-1+deb10u1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEzSoHOzhhVBcKQILo1PIZv+yZhIkFAmDJAMEACgkQ1PIZv+yZ
hIm9nw//c2DYojSV2TKCqRttfyOz82DXoGh30Kp2U9q6l66t+ySiM+v7Qu6HzEer
Dkq+zaqCetZRoaJMnuFK8i3YjQ5IeQN/hAJvjpCXIN50mZaBdjSlnv2X/DP7bl7j
W3UXQSvMQMLkTk7nqV50v4JcVn+6MkJZNUpmDsL21mqRcXGOb4hWZVF+cPEQxV

Bug#990158: shim-signed-common: No UEFI boot with error "Could not create MokListXRT"

[Ayke Halder]

Package: shim-signed-common
Version: 1.33+15+1533136590.3beb971-7
Severity: critical
Justification: breaks the whole system

Dear Maintainer,


## What led up to the situation?

Upgrade:

* shim-signed:amd64 (1.33+15+1533136590.3beb971-7,
1.36~1+deb10u1+15.4-5~deb10u1)
* shim-signed-common:amd64 (1.33+15+1533136590.3beb971-7,
1.36~1+deb10u1+15.4-5~deb10u1)

System: Dell T5600 with BIOS Revision A19


## What was the outcome of this action?

System is unbootable on booting via UEFI. System shows error message and then
powers off immediately:

"Could not create MokListXRT: Out of Resources
Something has gone seriously wrong: import_mok_state() failed: Out of
Resources"


## What outcome did you expect instead?

A normal booting system loading GRUB.


## Also reproducible with Debian Live-Installations-Image

On affected hardware like "Dell T5600" doing a UEFI boot from USB with …

* debian-live-10.10.0-amd64-standard.iso does *not* work.
* debian-live-10.9.0-amd64-standard.iso works.


## Related resources

Might be related to:

* https://bugzilla.suse.com/show_bug.cgi?id=1185261



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

Kernel: Linux 5.10.0-0.bpo.7-amd64 (SMP w/32 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages shim-signed-common depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  mokutil0.3.0+1538710437.fb6250f-1

shim-signed-common recommends no packages.

shim-signed-common suggests no packages.

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

Bug#987461: libuima-adapter-soap-java is empty

[tony mancill]

On Sat, Jun 19, 2021 at 07:46:28AM -0700, tony mancill wrote:
> On Sat, Jun 19, 2021 at 10:29:25PM +0900, Hideki Yamane wrote:
> >  So let's remove its binary package and add Breaks: to it.
> >  MR is here, could someone review it, please?
> >  https://salsa.debian.org/java-team/uimaj/-/merge_requests/1
> 
> Thank you for addressing this.  I will handle the merge and upload.
> 
> Just one quick question...  Why is the Breaks necessary?  Is it there to
> force removal of libuima-adapter-soap-java when libuima-core-java is
> upgraded?

Hi,

I saw the note in the changelog that Breaks is in fact there to remove
the empty package, but it's not happening for me when I try to upgrade
locally.  My test case is to install uima-utils (which will install
libuima-adapter-soap-java via Recommends) and then try to upgrade the
binaries to 2.10.2-4 using dpkg.  

dpkg: regarding libuima-core-java_2.10.2-4_all.deb containing libuima-core-java:
 libuima-core-java breaks libuima-adapter-soap-java (<< 2.10.2-4)
  libuima-adapter-soap-java (version 2.10.2-3) is present and installed.

The only way I can make this work is remove libuima-adapter-soap-java
manually.  Are you sure that Breaks is necessary?  apt-get autoremove
will clean up libuima-adapter-soap-java at some point.

I took a look at policy to see if Breaks + Replaces should be used in
this situation, but I'm not sure it really applies (although I think it
would work better than just Breaks).  Still, I'm unsure about the need
for Breaks for this empty package clean-up use case.

From https://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks:

> Neither Breaks nor Conflicts should be used unless two packages cannot
> be installed at the same time or installing them both causes one of
> them to be broken or unusable. Having similar functionality or
> performing the same tasks as another package is not sufficient reason
> to declare Breaks or Conflicts with that package.

Any concerns if I drop the Breaks before the upload?

Thanks,
tony


signature.asc
Description: PGP signature

Bug#990140: upgrade-reports: lxc-attach does not start with apparmor problem after ugrade to 10.10

[Bernd Breuer]

Hi Paul,

thanks for your immediate response.

Your assumption is right, booting into kernel 4.19.0-16 causes
lxc-attach to behave as expected, no more apparmor related errors.

Cheers Bernd


Am 21.06.21 um 19:06 schrieb Paul Gevers:

Hi Bernd,

Thanks for your report.

On 21-06-2021 18:04, Bernd Breuer wrote:

after the recent upgrade to Buster 10.10 (including a kernel upgrade) the 
command 'lxc-attach' (out of the Linux Container (lxc) set of commands), typed 
in like

"sudo lxc-attach "

stopped working with the error message

"lxc-attach: : lsm/lsm.c: lsm_process_label_set_at: 174 Operation not 
permitted - Failed to set AppArmor label "unconfined"

The conainer itself is starting, but apparmor related config lines like

"lxc.apparmor.profile = unconfined"

produce the above mentioned error, also on another machine after the
same packages upgrade.

I expect lxc-attach to provide me a root shell in the running lxc-container 
like  it was the case before the recent upgrade.

As we didn't upgrade lxc during the point release, this *may* be caused
by the updated Linux kernel. What happens if you reboot using the
previous kernel?

Paul

Bug#987461: marked as pending in uimaj

[Tony Mancill]

Control: tag -1 pending

Hello,

Bug #987461 in uimaj reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/java-team/uimaj/-/commit/035375ad019b8d65469db2a48f6bc3e0c0d45c5e


Drop libuima-adapter-soap-java and add Breaks: to it (Closes: #987461)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/987461

Processed: Bug#987461 marked as pending in uimaj

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #987461 [libuima-adapter-soap-java] libuima-adapter-soap-java is empty
Added tag(s) pending.

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

Processed: [bts-link] source package src:python-enable

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> #
> # bts-link upstream status pull for source package src:python-enable
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> # https://bts-link-team.pages.debian.net/bts-link/
> #
> user debian-bts-l...@lists.debian.org
Setting user to debian-bts-l...@lists.debian.org (was 
debian-bts-l...@lists.debian.org).
> # remote status report for #951888 (http://bugs.debian.org/951888)
> # Bug title: python-enable FTBFS with swig 4.0.1
> #  * https://github.com/enthought/enable/issues/360
> #  * remote status changed: open -> closed
> #  * closed upstream
> tags 951888 + fixed-upstream
Bug #951888 [src:python-enable] python-enable FTBFS with swig 4.0.1
Bug #972023 [src:python-enable] python-enable ftbfs with python3.9 as supported 
python3 version
Added tag(s) fixed-upstream.
Added tag(s) fixed-upstream.
> usertags 951888 - status-open
Usertags were: status-open.
There are now no usertags set.
> usertags 951888 + status-closed
There were no usertags set.
Usertags are now: status-closed.
> # remote status report for #972023 (http://bugs.debian.org/972023)
> # Bug title: python-enable ftbfs with python3.9 as supported python3 version
> #  * https://github.com/enthought/enable/issues/360
> #  * remote status changed: open -> closed
> #  * closed upstream
> tags 972023 + fixed-upstream
Bug #972023 [src:python-enable] python-enable ftbfs with python3.9 as supported 
python3 version
Bug #951888 [src:python-enable] python-enable FTBFS with swig 4.0.1
Ignoring request to alter tags of bug #972023 to the same tags previously set
Ignoring request to alter tags of bug #951888 to the same tags previously set
> usertags 972023 - status-open
Usertags were: status-open.
There are now no usertags set.
> usertags 972023 + status-closed
There were no usertags set.
Usertags are now: status-closed.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
951888: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951888
972023: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972023
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: duplicate

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # try two
> forcemerge 990072 990140
Bug #990072 {Done: Salvatore Bonaccorso } [src:linux] 
lxc-attach fails after debian 10.10 update
Bug #990075 {Done: Salvatore Bonaccorso } [src:linux] 
lxc-attach fails after debian 10.10 update
Bug #990089 {Done: Salvatore Bonaccorso } [src:linux] 
linux-image-4.19.0-17-amd64: lxc-attach fails with Failed to set AppArmor label 
unconfined
Bug #990107 {Done: Salvatore Bonaccorso } [src:linux] 
linux-image-4.19.0-17-amd64: lxc-attach Operation not permitted - Failed to set 
AppArmor label
Bug #990140 [src:linux] upgrade-reports: lxc-attach does not start with 
apparmor problem after ugrade to 10.10
Severity set to 'serious' from 'normal'
Marked Bug as done
Added indication that 990140 affects release.debian.org,lxc
Marked as fixed in versions linux/4.19.194-2.
Marked as found in versions linux/4.19.194-1.
Added tag(s) upstream, buster, moreinfo, fixed-upstream, and confirmed.
Bug #990075 {Done: Salvatore Bonaccorso } [src:linux] 
lxc-attach fails after debian 10.10 update
Bug #990089 {Done: Salvatore Bonaccorso } [src:linux] 
linux-image-4.19.0-17-amd64: lxc-attach fails with Failed to set AppArmor label 
unconfined
Bug #990107 {Done: Salvatore Bonaccorso } [src:linux] 
linux-image-4.19.0-17-amd64: lxc-attach Operation not permitted - Failed to set 
AppArmor label
Merged 990072 990075 990089 990107 990140
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
990072: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990072
990075: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990075
990089: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990089
990107: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990107
990140: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990140
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#989749: marked as done (kore: flaky amd64 autopkgtest: regularly times out after 2:47 h)

[Debian Bug Tracking System]

Your message dated Mon, 21 Jun 2021 17:03:34 +
with message-id 
and subject line Bug#989749: fixed in kore 4.1.0-3
has caused the Debian Bug report #989749,
regarding kore: flaky amd64 autopkgtest: regularly times out after 2:47 h
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.)


-- 
989749: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989749
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: kore
Version: 4.0.1-5
Severity: serious
Tags: bulleye-ignore
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky timeout

Dear maintainer(s),

Your package has an autopkgtest, great. However, I looked into
the history of your autopkgtest [1] and I noticed it fails regularly on
amd64. I copied some of the output at the bottom of this report. It hits
the autopkgtest time out after 2hours and 47 minutes. Successful runs
pass in a couple of minutes. Weirdly enough, all the failures where the
timeout happened is ci-worker13, which is our most powerful host, and as
such we run 8 parallel debci instances there. The same host also sees
successful runs. Do you have any idea what in the kore test could be
hanging?

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

[Release team member hat on: as we are so late in the freeze, I don't
want this bug to kick kore out of bulleye, although I still appreciate a
fix or work around. Hence, the bulleye-ignore tag.]

[1] https://ci.debian.net/packages/k/kore/testing/amd64/

https://ci.debian.net/data/autopkgtest/testing/amd64/k/kore/12824802/log.gz

autopkgtest [22:19:09]: test myapp: [---
created myapp/src/myapp.c
created myapp/conf/myapp.conf
created myapp/conf/build.conf
created myapp/.gitignore
created dh2048.pem
myapp created successfully!
WARNING: DO NOT USE THE GENERATED DH PARAMETERS AND CERTIFICATES IN
PRODUCTION
active flavordev
output type  dso
kore binary  /usr/bin/kore
kore features-DKORE_USE_PGSQL -DKORE_USE_TASKS -I/usr/include/postgresql
autopkgtest [01:05:50]: ERROR: timed out on command "su -s /bin/bash
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.4kfgq6b2/downtmp/build.2hy/src"; mkdir
-p -m 1777 -- "/tmp/autopkgtest-lxc.4kfgq6b2/downtmp/myapp-artifacts";
export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.4kfgq6b2/downtmp/myapp-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.4kfgq6b2/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.4kfgq6b2/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=48; unset
LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY
LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; chmod
+x
/tmp/autopkgtest-lxc.4kfgq6b2/downtmp/build.2hy/src/debian/tests/myapp;
touch /tmp/autopkgtest-lxc.4kfgq6b2/downtmp/myapp-stdout
/tmp/autopkgtest-lxc.4kfgq6b2/downtmp/myapp-stderr;
/tmp/autopkgtest-lxc.4kfgq6b2/downtmp/build.2hy/src/debian/tests/myapp
2> >(tee -a /tmp/autopkgtest-lxc.4kfgq6b2/downtmp/myapp-stderr >&2) >
>(tee -a /tmp/autopkgtest-lxc.4kfgq6b2/downtmp/myapp-stdout);" (kind: test)
autopkgtest [01:05:51]: test myapp: ---]



OpenPGP_signature
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
Source: kore
Source-Version: 4.1.0-3
Done: Shih-Yuan Lee (FourDollars) 

We believe that the bug you reported is fixed in the latest version of
kore, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 989...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Shih-Yuan Lee (FourDollars)  (supplier of updated kore 
package)

(This m

Bug#990026: Commonly-in-use characters

[Matthias Urlichs]

So far, we identified "/" and "=" as characters which definitely should 
be restored in order to not break our installations.


--
-- Matthias Urlichs




OpenPGP_signature
Description: OpenPGP digital signature

Bug#989069: nvidia-driver: Crash when displayport is plugged.

[Christian Marillat]

On 25 mai 2021 08:10, Andreas Beckmann  wrote:

[...]

>> Bug already reported upstream here :
>
> Not much we can do here :-( (besides not migrating this version to bullseye)

Seems to be fixed :

https://forums.developer.nvidia.com/t/465-24-02-page-fault/175782/135

Christian

Bug#897707: Should this package be removed from Debian?

[Timo Röhling]

Control: user debian...@lists.debian.org
Control: usertag -1 + proposed-removal

Given that this RC bug and #892288 have been unresolved for several
years and the last upload dates back to 2016 with multiple upstream
releases since, I believe this package should be considered for QA
removal.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#989731: marked as done (postgresql-13-q3c: drop Conflicts+Replaces: postgresql-q3c)

[Debian Bug Tracking System]

Your message dated Mon, 21 Jun 2021 14:20:29 +
with message-id 
and subject line Bug#989731: fixed in postgresql-q3c 2.0.0-5
has caused the Debian Bug report #989731,
regarding postgresql-13-q3c: drop Conflicts+Replaces: postgresql-q3c
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.)


-- 
989731: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989731
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: postgresql-13-pgsphere
Version: 1.1.1+2020-10-20-1
Severity: serious
Control: clone -1 -2
Control: reassign -2 postgresql-13-q3c 2.0.0-4
Control: retitle -1 postgresql-13-q3c: drop Conflicts+Replaces: postgresql-q3c

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984555#44
Markus Demleitner  wrote:

> One thing that needs to be
> ensured, though, is that on upgrades, the old pgsphere packages do
> not get removed until the operator asks dpkg to explicitly.  Perhaps
> stating the obvious, here's what needs to happen when upgrading from,
> say pg 11 to 13:
> 
> (1) normal dist-upgrade pulls in (hopefully) postgres-13, keeps
> postgres-11 running as normal (hence, pgsphere-11 must still be
> there).
> (2) operator runs pg_upgrade (for which both pg-13 and pg-11 must be
> present with all necessary extensions)
> (3) the last step of pg_upgrade is to make pg-13 the default db server,
> and pg-11 isn't started any more
> (4) the operator can now purge postgres-11 together with the
> version 11 extensions.

This is currently not possible, since postgresql-13-pgsphere has
Conflicts+Replaces: postgresql-pgsphere (<< 1.1.1+2020)
(and C+R: postgresql-q3c (<< 2.0.0-2) for postgresql-13-q3c).
I do not know if other extension packages have the same bug.
(gavodachs2-server seems to be one of the few packages actually needing
some extensions (pgsphere and q3c) and thus exhibiting upgrade errors.)

I think these Conflicts+Replaces can be safely dropped, since all files
in these packages are in versioned (/13/) paths and therefore cannot
cause file conflicts with the unversioned package in buster that ships
everything (but documentation) in versioned (/11/) paths.
But I may be overlooking something ...

Andreas
--- End Message ---
--- Begin Message ---
Source: postgresql-q3c
Source-Version: 2.0.0-5
Done: Ole Streicher 

We believe that the bug you reported is fixed in the latest version of
postgresql-q3c, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 989...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ole Streicher  (supplier of updated postgresql-q3c package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 21 Jun 2021 15:37:28 +0200
Source: postgresql-q3c
Architecture: source
Version: 2.0.0-5
Distribution: unstable
Urgency: medium
Maintainer: Debian PostgreSQL Maintainers 
Changed-By: Ole Streicher 
Closes: 989731
Changes:
 postgresql-q3c (2.0.0-5) unstable; urgency=medium
 .
   * Remove Conflitcs+Replaces: postgresql-pgsphere (Closes: #989731)
Checksums-Sha1:
 59b35bd8386b734499d8fd32f12f23f4ebb2dac6 2193 postgresql-q3c_2.0.0-5.dsc
 436880605a49959817044f187d8d7ff0e6527bf3 4556 
postgresql-q3c_2.0.0-5.debian.tar.xz
Checksums-Sha256:
 2644ffbd9170f49d8e2a2c7708d7538078e4d06d821b773c3001a84aa6bcbc7b 2193 
postgresql-q3c_2.0.0-5.dsc
 c26c28b477c212e410f8fab77191997c9fa470464e6eaa8bbc65d514917982ce 4556 
postgresql-q3c_2.0.0-5.debian.tar.xz
Files:
 1b0e8f76e815af988dc892d7bd96ec3e 2193 database optional 
postgresql-q3c_2.0.0-5.dsc
 79b38e64cb4aec02c9cde98b5ce91bcf 4556 database optional 
postgresql-q3c_2.0.0-5.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuvxshffLFD/utvsVcRWv0HcQ3PcFAmDQlq8ACgkQcRWv0HcQ
3PcEDw//XfFFPGUf+u2S72nQtqNz7TnpAgcmYJb5tXGeJjtfMSRoC37qZndPDTNa
7NhSgCDELMAmrVbdeHWUU7ipDvqzsmZwshxYTWuh0TmPxEA1Zh/MU2ZBmO5+Olhh
DdqJ9yxtBSBbvbnSYaJZtWl8uC6W++IPKrZC7f9cZPdSxdRcTYu4uD8n27tlnNQ7
FKoOxclBMUayoEJGJpuP22uGfGKnwBv0w4uTnpHdPnOZKmdZKLx9arRpgB2rEv+b
gJjgRivCz2G3L7LS5iIr06L/M6Mk5ynA1HtPyAeHJOmtxRWJ8L/xCYdffZ7vZfoT
9RcwbkGPKMPk2xOTbz4P1MjSdXgxdgyPU5uXMGXDRwr+3wzvRWPvQQKJRix/Lgz1
o2gJNduo+0yEDw1j2kuBAt0jOxoQdDOpHJ55h/yKiKzuxys9BX2qjg0KeauFSjDI
CsrZBjKAjDcIyAwlHD

Bug#989732: marked as done (postgresql-13-pgsphere: drop Conflicts+Replaces: postgresql-pgsphere)

[Debian Bug Tracking System]

Your message dated Mon, 21 Jun 2021 15:54:52 +0200
with message-id <860266c8-670f-97ca-b852-954ef8389...@debian.org>
and subject line Bug#989732: fixed in pgsphere 1.1.1+2020-10-20-2
has caused the Debian Bug report #989732,
regarding postgresql-13-pgsphere: drop Conflicts+Replaces: postgresql-pgsphere
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.)


-- 
989732: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989732
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: postgresql-13-pgsphere
Version: 1.1.1+2020-10-20-1
Severity: serious
Control: clone -1 -2
Control: reassign -2 postgresql-13-q3c 2.0.0-4
Control: retitle -1 postgresql-13-q3c: drop Conflicts+Replaces: postgresql-q3c

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984555#44
Markus Demleitner  wrote:

> One thing that needs to be
> ensured, though, is that on upgrades, the old pgsphere packages do
> not get removed until the operator asks dpkg to explicitly.  Perhaps
> stating the obvious, here's what needs to happen when upgrading from,
> say pg 11 to 13:
> 
> (1) normal dist-upgrade pulls in (hopefully) postgres-13, keeps
> postgres-11 running as normal (hence, pgsphere-11 must still be
> there).
> (2) operator runs pg_upgrade (for which both pg-13 and pg-11 must be
> present with all necessary extensions)
> (3) the last step of pg_upgrade is to make pg-13 the default db server,
> and pg-11 isn't started any more
> (4) the operator can now purge postgres-11 together with the
> version 11 extensions.

This is currently not possible, since postgresql-13-pgsphere has
Conflicts+Replaces: postgresql-pgsphere (<< 1.1.1+2020)
(and C+R: postgresql-q3c (<< 2.0.0-2) for postgresql-13-q3c).
I do not know if other extension packages have the same bug.
(gavodachs2-server seems to be one of the few packages actually needing
some extensions (pgsphere and q3c) and thus exhibiting upgrade errors.)

I think these Conflicts+Replaces can be safely dropped, since all files
in these packages are in versioned (/13/) paths and therefore cannot
cause file conflicts with the unversioned package in buster that ships
everything (but documentation) in versioned (/11/) paths.
But I may be overlooking something ...

Andreas
--- End Message ---
--- Begin Message ---

Source: pgsphere
Source-Version: 1.1.1+2020-10-20-2
Done: Ole Streicher 

We believe that the bug you reported is fixed in the latest version of
pgsphere, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 989...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ole Streicher  (supplier of updated pgsphere package)

(This message was generated manually since I used the wrong bug id in 
d/changelog)



Format: 1.8
Date: Mon, 21 Jun 2021 15:29:03 +0200
Source: pgsphere
Architecture: source
Version: 1.1.1+2020-10-20-2
Distribution: unstable
Urgency: medium
Maintainer: Debian PostgreSQL Maintainers

Changed-By: Ole Streicher 
Closes: 989731
Changes:
 pgsphere (1.1.1+2020-10-20-2) unstable; urgency=medium
 .
   * Remove Conflitcs+Replaces: postgresql-pgsphere (Closes: #989731)
Checksums-Sha1:
 b2c7516366882d29dd5a8697f04fe3545168e6b5 2230
pgsphere_1.1.1+2020-10-20-2.dsc
 4551552bde5f6ea3dd53d8297d2893df97173cdf 4064
pgsphere_1.1.1+2020-10-20-2.debian.tar.xz
Checksums-Sha256:
 2916696b2beb8da9f4e1a2b9addbbff72225a38b24ffd9f72bab70bea2ca0435 2230
pgsphere_1.1.1+2020-10-20-2.dsc
 e1d4de133f1ce19d8c24d2e927a94c4913574d9509d1f8e469c3ff9df71113f6 4064
pgsphere_1.1.1+2020-10-20-2.debian.tar.xz
Files:
 66f1fd138c1f9e59c69a7b4cc0fe5cbb 2230 database optional
pgsphere_1.1.1+2020-10-20-2.dsc
 f7af61ce75e7898c3673baff2391802b 4064 database optional
pgsphere_1.1.1+2020-10-20-2.debian.tar.xz--- End Message ---

Bug#989731: marked as done (postgresql-13-q3c: drop Conflicts+Replaces: postgresql-q3c)

[Debian Bug Tracking System]

Your message dated Mon, 21 Jun 2021 13:48:29 +
with message-id 
and subject line Bug#989731: fixed in pgsphere 1.1.1+2020-10-20-2
has caused the Debian Bug report #989731,
regarding postgresql-13-q3c: drop Conflicts+Replaces: postgresql-q3c
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.)


-- 
989731: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989731
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: postgresql-13-pgsphere
Version: 1.1.1+2020-10-20-1
Severity: serious
Control: clone -1 -2
Control: reassign -2 postgresql-13-q3c 2.0.0-4
Control: retitle -1 postgresql-13-q3c: drop Conflicts+Replaces: postgresql-q3c

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984555#44
Markus Demleitner  wrote:

> One thing that needs to be
> ensured, though, is that on upgrades, the old pgsphere packages do
> not get removed until the operator asks dpkg to explicitly.  Perhaps
> stating the obvious, here's what needs to happen when upgrading from,
> say pg 11 to 13:
> 
> (1) normal dist-upgrade pulls in (hopefully) postgres-13, keeps
> postgres-11 running as normal (hence, pgsphere-11 must still be
> there).
> (2) operator runs pg_upgrade (for which both pg-13 and pg-11 must be
> present with all necessary extensions)
> (3) the last step of pg_upgrade is to make pg-13 the default db server,
> and pg-11 isn't started any more
> (4) the operator can now purge postgres-11 together with the
> version 11 extensions.

This is currently not possible, since postgresql-13-pgsphere has
Conflicts+Replaces: postgresql-pgsphere (<< 1.1.1+2020)
(and C+R: postgresql-q3c (<< 2.0.0-2) for postgresql-13-q3c).
I do not know if other extension packages have the same bug.
(gavodachs2-server seems to be one of the few packages actually needing
some extensions (pgsphere and q3c) and thus exhibiting upgrade errors.)

I think these Conflicts+Replaces can be safely dropped, since all files
in these packages are in versioned (/13/) paths and therefore cannot
cause file conflicts with the unversioned package in buster that ships
everything (but documentation) in versioned (/11/) paths.
But I may be overlooking something ...

Andreas
--- End Message ---
--- Begin Message ---
Source: pgsphere
Source-Version: 1.1.1+2020-10-20-2
Done: Ole Streicher 

We believe that the bug you reported is fixed in the latest version of
pgsphere, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 989...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ole Streicher  (supplier of updated pgsphere package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 21 Jun 2021 15:29:03 +0200
Source: pgsphere
Architecture: source
Version: 1.1.1+2020-10-20-2
Distribution: unstable
Urgency: medium
Maintainer: Debian PostgreSQL Maintainers 
Changed-By: Ole Streicher 
Closes: 989731
Changes:
 pgsphere (1.1.1+2020-10-20-2) unstable; urgency=medium
 .
   * Remove Conflitcs+Replaces: postgresql-pgsphere (Closes: #989731)
Checksums-Sha1:
 b2c7516366882d29dd5a8697f04fe3545168e6b5 2230 pgsphere_1.1.1+2020-10-20-2.dsc
 4551552bde5f6ea3dd53d8297d2893df97173cdf 4064 
pgsphere_1.1.1+2020-10-20-2.debian.tar.xz
Checksums-Sha256:
 2916696b2beb8da9f4e1a2b9addbbff72225a38b24ffd9f72bab70bea2ca0435 2230 
pgsphere_1.1.1+2020-10-20-2.dsc
 e1d4de133f1ce19d8c24d2e927a94c4913574d9509d1f8e469c3ff9df71113f6 4064 
pgsphere_1.1.1+2020-10-20-2.debian.tar.xz
Files:
 66f1fd138c1f9e59c69a7b4cc0fe5cbb 2230 database optional 
pgsphere_1.1.1+2020-10-20-2.dsc
 f7af61ce75e7898c3673baff2391802b 4064 database optional 
pgsphere_1.1.1+2020-10-20-2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuvxshffLFD/utvsVcRWv0HcQ3PcFAmDQlZAACgkQcRWv0HcQ
3Pd9bg//TSgiHczYxt/7011tzl8fpwxqyN3cH0l826hCLwfpBZB9p9teDpi53vma
Xu99bdzRMW1xTJrAFRDc3k3UIuHJjWEya39gEI6Yem8hM3vGmknG5FdzmP501SEh
aUb0ol2r80HzzKro6kk5Z+/1SWo0j4vdmngIwaTnEQX/chdv9Hem79ERHWNx5taj
lk31TqEJfFO/g6bWP3Q1PiI+dap70fmzlBGwPlFrZAjueMlUZcyQbkZ/yJamki6U
dO17X+17L6vMu4c8q6L0/wCwBKccgUhDcSYWCGNxFab7l/lCv5MUQ7WWFpkwRuY/
Q5h0tpjU707wzRUbSLlvUlWfiaByDLB0yXWZvXMiPeW5u08LA0upM1NDOo/X7mnc
1DajQaW7nwepmV+FgdZ+vS+x3QGzObGfSiR5hxb1s1gX1

Bug#989731: marked as pending in postgresql-q3c

[Ole Streicher]

Control: tag -1 pending

Hello,

Bug #989731 in postgresql-q3c reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/postgresql/postgresql-q3c/-/commit/2e7c5a6ec5d0c66a82f27f43f2f8df1d42ba2db1


Remove Conflitcs+Replaces: postgresql-pgsphere

Closes: #989731


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/989731

Processed: Bug#989731 marked as pending in postgresql-q3c

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #989731 [postgresql-13-pgsphere] postgresql-13-q3c: drop 
Conflicts+Replaces: postgresql-q3c
Ignoring request to alter tags of bug #989731 to the same tags previously set

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

Processed: Bug#989731 marked as pending in pgsphere

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #989731 [postgresql-13-pgsphere] postgresql-13-q3c: drop 
Conflicts+Replaces: postgresql-q3c
Added tag(s) pending.

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

Bug#989731: marked as pending in pgsphere

[Ole Streicher]

Control: tag -1 pending

Hello,

Bug #989731 in pgsphere reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/postgresql/pgsphere/-/commit/f43a8809f78aead16d2a62714d0094f18a1c9272


Remove Conflitcs+Replaces: postgresql-pgsphere

Closes: #989731


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/989731

Processed: found 990123 in iptables-netflow/2.3-5, found 990123 in iptables-netflow/2.5.1-2 ...

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # Version tracking seems to not have worked properly in the initial bug 
> submission
> found 990123 iptables-netflow/2.3-5
Bug #990123 
[iptables-netflow-dkms,linux-headers-4.19.0-17-amd64,linux-headers-4.19.0-17-i686-pae]
 [buster regression] iptables-netflow-dkms: No more compiles since 
linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream 
kernel API regression in 4.19.191?)
Warning: Unknown package 'linux-headers-4.19.0-17-i686-pae'
Marked as found in versions iptables-netflow/2.3-5.
Warning: Unknown package 'linux-headers-4.19.0-17-i686-pae'
> found 990123 iptables-netflow/2.5.1-2
Bug #990123 
[iptables-netflow-dkms,linux-headers-4.19.0-17-amd64,linux-headers-4.19.0-17-i686-pae]
 [buster regression] iptables-netflow-dkms: No more compiles since 
linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream 
kernel API regression in 4.19.191?)
Warning: Unknown package 'linux-headers-4.19.0-17-i686-pae'
Marked as found in versions iptables-netflow/2.5.1-2.
Warning: Unknown package 'linux-headers-4.19.0-17-i686-pae'
> found 990123 linux/4.19.194-1
Bug #990123 
[iptables-netflow-dkms,linux-headers-4.19.0-17-amd64,linux-headers-4.19.0-17-i686-pae]
 [buster regression] iptables-netflow-dkms: No more compiles since 
linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream 
kernel API regression in 4.19.191?)
Warning: Unknown package 'linux-headers-4.19.0-17-i686-pae'
Marked as found in versions linux/4.19.194-1.
Warning: Unknown package 'linux-headers-4.19.0-17-i686-pae'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
990123: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990123
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#990107: marked as done (linux-image-4.19.0-17-amd64: lxc-attach Operation not permitted - Failed to set AppArmor label)

[Debian Bug Tracking System]

Your message dated Mon, 21 Jun 2021 12:02:07 +
with message-id 
and subject line Bug#990072: fixed in linux 4.19.194-2
has caused the Debian Bug report #990072,
regarding linux-image-4.19.0-17-amd64: lxc-attach Operation not permitted - 
Failed to set AppArmor label
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.)


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

Package: src:linux
Version: 4.19.194-1
Severity: normal

Since upgrading to linux-image-4.19.0-17-amd64 from 
linux-image-4.19.0-16-amd64, I can no longer enter my lxc container with 
the command 'lxc-attach'. It fails with the message:


lxc-attach: shire: lsm/lsm.c: lsm_process_label_set_at: 174 Operation 
not permitted - Failed to set AppArmor label 
"lxc-shire_//&:lxc-shire_<-var-lib-lxc>:

unconfined"

Reverting to linux-image-4.19.0-16-amd64 version 4.19.181-1 (the 
previous kernel) fixes the issue.


The lxc config for this container is the following:

lxc.include = /usr/share/lxc/config/common.conf
lxc.include = /usr/share/lxc/config/userns.conf
lxc.arch = linux64
lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1
lxc.idmap = u 0 10 90
lxc.idmap = g 0 10 90
lxc.rootfs.path = dir:/var/lib/lxc/shire/rootfs
lxc.uts.name = shire
lxc.net.0.type = empty
lxc.mount.entry=/data/home home none bind 0 0
lxc.mount.entry=/data/mail var/mail none bind 0 0

And the auto-generated AppArmor profile:

#include 
profile "lxc-shire_" 
flags=(attach_disconnected,mediate_deleted) {

  ### Base profile
  capability,
  dbus,
  file,
  network,
  umount,

  # Allow us to receive signals from anywhere.
  signal (receive),

  # Allow us to send signals to ourselves
  signal peer=@{profile_name},

  # Allow other processes to read our /proc entries, futexes, perf 
tracing and
  # kcmp for now (they will need 'read' in the first place). 
Administrators can

  # override with:
  #   deny ptrace (readby) ...
  ptrace (readby),

  # Allow other processes to trace us by default (they will need 'trace' in
  # the first place). Administrators can override with:
  #   deny ptrace (tracedby) ...
  ptrace (tracedby),

  # Allow us to ptrace ourselves
  ptrace peer=@{profile_name},

  # ignore DENIED message on / remount
  deny mount options=(ro, remount) -> /,
  deny mount options=(ro, remount, silent) -> /,

  # allow tmpfs mounts everywhere
  mount fstype=tmpfs,

  # allow hugetlbfs mounts everywhere
  mount fstype=hugetlbfs,

  # allow mqueue mounts everywhere
  mount fstype=mqueue,

  # allow fuse mounts everywhere
  mount fstype=fuse,
  mount fstype=fuse.*,

  # deny access under /proc/bus to avoid e.g. messing with pci devices 
directly

  deny @{PROC}/bus/** wklx,

  # deny writes in /proc/sys/fs but allow binfmt_misc to be mounted
  mount fstype=binfmt_misc -> /proc/sys/fs/binfmt_misc/,
  deny @{PROC}/sys/fs/** wklx,

  # allow efivars to be mounted, writing to it will be blocked though
  mount fstype=efivarfs -> /sys/firmware/efi/efivars/,

  # block some other dangerous paths
  deny @{PROC}/kcore rwklx,
  deny @{PROC}/sysrq-trigger rwklx,

  # deny writes in /sys except for /sys/fs/cgroup, also allow
  # fusectl, securityfs and debugfs to be mounted there (read-only)
  mount fstype=fusectl -> /sys/fs/fuse/connections/,
  mount fstype=securityfs -> /sys/kernel/security/,
  mount fstype=debugfs -> /sys/kernel/debug/,
  deny mount fstype=debugfs -> /var/lib/ureadahead/debugfs/,
  mount fstype=proc -> /proc/,
  mount fstype=sysfs -> /sys/,
  mount options=(rw, nosuid, nodev, noexec, remount) -> /sys/,
  deny /sys/firmware/efi/efivars/** rwklx,
  # note, /sys/kernel/security/** handled below
  mount options=(ro, nosuid, nodev, noexec, remount, strictatime) -> 
/sys/fs/cgroup/,


  # deny reads from debugfs
  deny /sys/kernel/debug/{,**} rwklx,

  # allow paths to be made slave, shared, private or unbindable
  # FIXME: This currently doesn't work due to the apparmor parser 
treating those as allowing all mounts.

#  mount options=(rw,make-slave) -> **,
#  mount options=(rw,make-rslave) -> **,
#  mount options=(rw,make-shared) -> **,
#  mount options=(rw,make-rshared) -> **,
#  mount options=(rw,make-private) -> **,
#  mount options=(rw,make-rprivate) -> **,
#  mount options=(rw,make-unbindable) -> **,
#  mount options=(rw,make-runbindable) -> **,

  # allow bind-mounts of anything except /proc, /sys and /dev
  mount options=(rw,bind) /[^spd]*{,/**},
  mount options=(rw,bind) /d[^e]*{,/**},
  mount options=(rw,bind) /de[^v]*{,/**},
  mount options=(rw,bin

Bug#990089: marked as done (linux-image-4.19.0-17-amd64: lxc-attach fails with Failed to set AppArmor label unconfined)

[Debian Bug Tracking System]

Your message dated Mon, 21 Jun 2021 12:02:07 +
with message-id 
and subject line Bug#990072: fixed in linux 4.19.194-2
has caused the Debian Bug report #990072,
regarding linux-image-4.19.0-17-amd64: lxc-attach fails with Failed to set 
AppArmor label unconfined
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.)


-- 
990072: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990072
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:linux
Version: 4.19.194-1
Severity: normal

Dear Maintainer,

After upgrading from linux-image-4.19.0-16-amd64 to linux-image-4.19.0-17-amd64
attaching an unprivileged linux container fails with the message:
lxc-attach: debian-buster-amd64-basic: lsm/lsm.c: lsm_process_label_set_at: 174
Operation not permitted - Failed to set AppArmor label "unconfined"
Rebooting into linux-image-4.19.0-16-amd64 with no other changes, the lxc
system works as expected.

Regrads,
Mark Grant



-- Package-specific info:
** Version:
Linux version 4.19.0-17-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.194-1 (2021-06-10)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-17-amd64 root=/dev/mapper/priam--vg-root ro

** Not tainted

** Kernel log:
[   14.211487] snd_hda_codec_realtek hdaudioC0D0:  Rear Mic=0x18
[   14.211554] snd_hda_codec_realtek hdaudioC0D0:  Line=0x1a
[   14.351839] input: HDA Intel PCH Front Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input10
[   14.351896] input: HDA Intel PCH Rear Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input11
[   14.351941] input: HDA Intel PCH Line as 
/devices/pci:00/:00:1f.3/sound/card0/input12
[   14.351981] input: HDA Intel PCH Line Out as 
/devices/pci:00/:00:1f.3/sound/card0/input13
[   14.352023] input: HDA Intel PCH Front Headphone as 
/devices/pci:00/:00:1f.3/sound/card0/input14
[   14.352071] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1f.3/sound/card0/input15
[   14.352116] input: HDA Intel PCH HDMI/DP,pcm=7 as 
/devices/pci:00/:00:1f.3/sound/card0/input16
[   14.352164] input: HDA Intel PCH HDMI/DP,pcm=8 as 
/devices/pci:00/:00:1f.3/sound/card0/input17
[   14.352214] input: HDA Intel PCH HDMI/DP,pcm=9 as 
/devices/pci:00/:00:1f.3/sound/card0/input18
[   14.352257] input: HDA Intel PCH HDMI/DP,pcm=10 as 
/devices/pci:00/:00:1f.3/sound/card0/input19
[   14.562406] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: 
errors=remount-ro
[   14.743100] EXT4-fs (sda1): mounting ext2 file system using the ext4 
subsystem
[   14.815334] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
[   15.862180] audit: type=1400 audit(1624175633.583:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=651 
comm="apparmor_parser"
[   15.864947] audit: type=1400 audit(1624175633.583:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=651 comm="apparmor_parser"
[   15.876271] audit: type=1400 audit(1624175633.595:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=650 
comm="apparmor_parser"
[   15.879040] audit: type=1400 audit(1624175633.595:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=650 
comm="apparmor_parser"
[   15.881633] audit: type=1400 audit(1624175633.595:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=650 
comm="apparmor_parser"
[   15.916140] audit: type=1400 audit(1624175633.635:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/lxc-start" pid=654 
comm="apparmor_parser"
[   15.920983] audit: type=1400 audit(1624175633.639:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="virt-aa-helper" pid=649 
comm="apparmor_parser"
[   15.972116] audit: type=1400 audit(1624175633.691:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lxc-container-default" 
pid=659 comm="apparmor_parser"
[   15.975071] audit: type=1400 audit(1624175633.691:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lxc-container-default-cgns" 
pid=659 comm="apparmor_parser"
[   15.977826] audit: type=1400 audit(1624175633.691:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="lxc-container-default-with-mounting" pid=659 comm="apparmor_parser"
[   16.845248] usb 1-8: reset high-speed USB device number 3 using xhci_hcd
[   17.604508] new mount o

Bug#990072: marked as done (lxc-attach fails after debian 10.10 update)

[Debian Bug Tracking System]

Your message dated Mon, 21 Jun 2021 12:02:07 +
with message-id 
and subject line Bug#990072: fixed in linux 4.19.194-2
has caused the Debian Bug report #990072,
regarding lxc-attach fails after debian 10.10 update
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.)


-- 
990072: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990072
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: lxc
Version: 1:3.1.0+really3.0.3-8
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Applied latest apt updates (debian 10.10) and rebooted.  After reboot, 
lxc-attach doesn't work.

from /var/log/apt/history.log:

Start-Date: 2021-06-19  12:27:42
Commandline: apt-get dist-upgrade
Requested-By: matthew (1011)
Install: linux-headers-4.19.0-17-common:amd64 (4.19.194-1, automatic), 
linux-headers-4.19.0-17-amd64:amd64 (4.19.194-1, automatic), 
linux-image-4.19.0-17-amd64:amd64 (4.19.194-1, automatic)
Upgrade: libapt-inst2.0:amd64 (1.8.2.2, 1.8.2.3), apt:amd64 (1.8.2.2, 1.8.2.3), 
mariadb-common:amd64 (1:10.3.27-0+deb10u1, 1:10.3.29-0+deb10u1), 
linux-compiler-gcc-8-x86:amd64 (4.19.181-1, 4.19.194-1), libklibc:amd64 
(2.0.6-1, 2.0.6-1+deb10u1), libcpupower1:amd64 (4.19.181-1, 4.19.194-1), 
libapt-pkg5.0:amd64 (1.8.2.2, 1.8.2.3), shim-helpers-amd64-signed:amd64 
(1+15+1533136590.3beb971+7+deb10u1, 1+15.4+5~deb10u1), linux-image-amd64:amd64 
(4.19+105+deb10u11, 4.19+105+deb10u12), libgcrypt20:amd64 (1.8.4-5, 
1.8.4-5+deb10u1), linux-headers-amd64:amd64 (4.19+105+deb10u11, 
4.19+105+deb10u12), libhogweed4:amd64 (3.4.1-1, 3.4.1-1+deb10u1), 
apt-utils:amd64 (1.8.2.2, 1.8.2.3), shim-unsigned:amd64 
(15+1533136590.3beb971-7+deb10u1, 15.4-5~deb10u1), shim-signed:amd64 
(1.33+15+1533136590.3beb971-7, 1.36~1+deb10u1+15.4-5~deb10u1), libnettle6:amd64 
(3.4.1-1, 3.4.1-1+deb10u1), libxml2:amd64 (2.9.4+dfsg1-7+deb10u1, 
2.9.4+dfsg1-7+deb10u2), libmariadb3:amd64 (1:10.3.27-0+deb10u1, 
1:10.3.29-0+deb10u1), libgnutls30:amd64 (3.6.7-4+deb10u6, 3.6.7-4+deb10u7), 
linux-kbuild-4.19:amd64 (4.19.181-1, 4.19.194-1), klibc-utils:amd64 (2.0.6-1, 
2.0.6-1+deb10u1), libglib2.0-0:amd64 (2.58.3-2+deb10u2, 2.58.3-2+deb10u3), 
shim-signed-common:amd64 (1.33+15+1533136590.3beb971-7, 
1.36~1+deb10u1+15.4-5~deb10u1), linux-cpupower:amd64 (4.19.181-1, 4.19.194-1), 
base-files:amd64 (10.3+deb10u9, 10.3+deb10u10)
End-Date: 2021-06-19  12:29:41


$ lxc-attach mar-mon1
lxc-attach: mar-mon1: lsm/lsm.c: lsm_process_label_set_at: 174 Operation not 
permitted - Failed to set AppArmor label 
"lxc-mar-mon1_//&:lxc-mar-mon1_<-var-lib-lxc>:unconfined"

The lxc-config file contains

lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1

The generated apparmor seems unchanged when I compare it to containers on a 
server I didn't reboot. 
I did reboot 2 servers after this debian update, and both have this problem.


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

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

Versions of packages lxc depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libcap21:2.25-2
ii  libgnutls303.6.7-4+deb10u7
ii  liblxc11:3.1.0+really3.0.3-8
ii  libseccomp22.3.3-4
ii  libselinux12.8-1+b1
ii  lsb-base   10.2019051400

Versions of packages lxc recommends:
ii  apparmor   2.13.2-10
ii  bridge-utils   1.6-2
pn  debootstrap
ii  dirmngr2.2.12-1+deb10u1
pn  dnsmasq-base   
ii  gnupg  2.2.12-1+deb10u1
ii  iproute2   4.20.0-2+deb10u1
ii  iptables   1.8.2-4
pn  libpam-cgfs
pn  lxc-templates  
ii  lxcfs  3.0.3-2
ii  openssl1.1.1d-0+deb10u6
pn  rsync  
pn  uidmap 

Versions of packages lxc suggests:
pn  btrfs-progs  
pn  lvm2 
pn  python3-lxc  

-- debconf information excluded
--- End Message ---
--- Begin Message ---
Source: linux
Source-Version: 4.19.194-2
Done: Salvatore Bonaccorso 

We believe that the bug you reported is fixed in the latest version of
linux, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments ple

Bug#990075: marked as done (lxc-attach fails after debian 10.10 update)

[Debian Bug Tracking System]

Your message dated Mon, 21 Jun 2021 12:02:07 +
with message-id 
and subject line Bug#990072: fixed in linux 4.19.194-2
has caused the Debian Bug report #990072,
regarding lxc-attach fails after debian 10.10 update
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.)


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

Package: lxc
Version: 1:3.1.0+really3.0.3-8
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Applied latest apt updates (debian 10.10) and rebooted.  After reboot, 
lxc-attach doesn't work.

from /var/log/apt/history.log:

Start-Date: 2021-06-19  12:27:42
Commandline: apt-get dist-upgrade
Requested-By: matthew (1011)
Install: linux-headers-4.19.0-17-common:amd64 (4.19.194-1, automatic), 
linux-headers-4.19.0-17-amd64:amd64 (4.19.194-1, automatic), 
linux-image-4.19.0-17-amd64:amd64 (4.19.194-1, automatic)
Upgrade: libapt-inst2.0:amd64 (1.8.2.2, 1.8.2.3),apt:amd64  (1.8.2.2, 1.8.2.3), 
mariadb-common:amd64 (1:10.3.27-0+deb10u1, 1:10.3.29-0+deb10u1), 
linux-compiler-gcc-8-x86:amd64 (4.19.181-1, 4.19.194-1), libklibc:amd64 
(2.0.6-1, 2.0.6-1+deb10u1), libcpupower1:amd64 (4.19.181-1, 4.19.194-1), 
libapt-pkg5.0:amd64 (1.8.2.2, 1.8.2.3), shim-helpers-amd64-signed:amd64 
(1+15+1533136590.3beb971+7+deb10u1, 1+15.4+5~deb10u1), linux-image-amd64:amd64 
(4.19+105+deb10u11, 4.19+105+deb10u12), libgcrypt20:amd64 (1.8.4-5, 
1.8.4-5+deb10u1), linux-headers-amd64:amd64 (4.19+105+deb10u11, 
4.19+105+deb10u12), libhogweed4:amd64 (3.4.1-1, 3.4.1-1+deb10u1), 
apt-utils:amd64 (1.8.2.2, 1.8.2.3), shim-unsigned:amd64 
(15+1533136590.3beb971-7+deb10u1, 15.4-5~deb10u1), shim-signed:amd64 
(1.33+15+1533136590.3beb971-7, 1.36~1+deb10u1+15.4-5~deb10u1), libnettle6:amd64 
(3.4.1-1, 3.4.1-1+deb10u1), libxml2:amd64 (2.9.4+dfsg1-7+deb10u1, 
2.9.4+dfsg1-7+deb10u2), libmariadb3:amd64 (1:10.3.27-0+deb10u1, 
1:10.3.29-0+deb10u1), libgnutls30:amd64 (3.6.7-4+deb10u6, 3.6.7-4+deb10u7), 
linux-kbuild-4.19:amd64 (4.19.181-1, 4.19.194-1), klibc-utils:amd64 (2.0.6-1, 
2.0.6-1+deb10u1), libglib2.0-0:amd64 (2.58.3-2+deb10u2, 2.58.3-2+deb10u3), 
shim-signed-common:amd64 (1.33+15+1533136590.3beb971-7, 
1.36~1+deb10u1+15.4-5~deb10u1), linux-cpupower:amd64 (4.19.181-1, 4.19.194-1), 
base-files:amd64 (10.3+deb10u9, 10.3+deb10u10)
End-Date: 2021-06-19  12:29:41


$ lxc-attach mar-mon1
lxc-attach: mar-mon1: lsm/lsm.c: lsm_process_label_set_at: 174 Operation not permitted - Failed to set 
AppArmor label 
"lxc-mar-mon1_//&:lxc-mar-mon1_<-var-lib-lxc>:unconfined"

The lxc-config file contains

lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1

The generated apparmor seems unchanged when I compare it to containers on a 
server I didn't reboot.
I did reboot 2 servers after this debian update, and both have this problem.


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

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

Versions of packages lxc depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libcap21:2.25-2
ii  libgnutls303.6.7-4+deb10u7
ii  liblxc11:3.1.0+really3.0.3-8
ii  libseccomp22.3.3-4
ii  libselinux12.8-1+b1
ii  lsb-base   10.2019051400

Versions of packages lxc recommends:
ii  apparmor   2.13.2-10
ii  bridge-utils   1.6-2
pn  debootstrap
ii  dirmngr2.2.12-1+deb10u1
pn  dnsmasq-base   
ii  gnupg  2.2.12-1+deb10u1
ii  iproute2   4.20.0-2+deb10u1
ii  iptables   1.8.2-4
pn  libpam-cgfs
pn  lxc-templates  
ii  lxcfs  3.0.3-2
ii  openssl1.1.1d-0+deb10u6
pn  rsync  
pn  uidmap 

Versions of packages lxc suggests:
pn  btrfs-progs  
pn  lvm2 
pn  python3-lxc  
--- End Message ---
--- Begin Message ---
Source: linux
Source-Version: 4.19.194-2
Done: Salvatore Bonaccorso 

We believe that the bug you reported is fixed in the latest version of
linux, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 990...@bugs.d

Bug#990123: [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.19.191?)

[Axel Beckert]

Package: 
iptables-netflow-dkms,linux-headers-4.19.0-17-amd64,linux-headers-4.19.0-17-i686-pae
Severity: serious
Version: iptables-netflow/2.3-5
Version: iptables-netflow/2.5.1-2
Version: linux/4.19.194-1
Tags: buster
Forwarded: https://github.com/aabc/ipt-netflow/issues/177

Since kernel packages linux-{image,headers}-4.19.0-17-*, at least with
-amd64 and -i686-pae, iptables-netflow-dkms no more compiles its kernel
module upon kernel installation:

In file included from /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:75:
/var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c: In function 
‘register_ct_events’:
/var/lib/dkms/ipt-netflow/2.3/build/compat.h:173:21: error: implicit 
declaration of function ‘ref_module’; did you mean ‘use_module’? 
[-Werror=implicit-function-declaration]
 # define use_module ref_module
 ^~
/var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:5399:3: note: in expansion of 
macro ‘use_module’
   use_module(THIS_MODULE, netlink_m);
   ^~

Reading the kernel changelog, there are a few very suspicious entries
listed under upstream version 4.19.191:

- modules: mark ref_module static
- modules: mark find_symbol static
- modules: mark each_symbol_section static

One of the commits above (8745aa4e resp. 7ef5264d) states:

  ref_module isn't used anywhere outside of module.c.

Which is only seems true if you ignore any third-party kernel modules
out there.

So why is the kernel API suddenly removing API-code used by third-party
modules inmidst a stable update? This looks like a regression to me.  I
thought that stable updates only change the ABI, but not the API. (Well,
at least upstream and in Debian. :-)

I also tried the iptables-netflow-dkms 2.5.1-2 from Bullseye on Buster,
but it fails to build the kernel module for 4.19.0-17-* when as well.

2.5.1-2 though still works fine on Sid/Bullseye, hence marked as found
in the version in Sid, but tagged buster. In case this causes issues in
the BTS or the release team scripts, please rather remove 2.5.1-2 from
the "found" versions instead of removing the buster tag — unless the
same regression gets introduced into Sid and Bullseye as well.

Debian kernel maintainers: If this 3rd-party-module-breaking regression
was really intended and won't be fixed, please reassign the bug to
iptables-netflow-dkms only.

I also reported this issue to iptables-netflow upstream at
https://github.com/aabc/ipt-netflow/issues/177 as I think it at least
should update the version based ifdef checks in something which looks
like a similar issue in kernel 5.13, see
https://github.com/aabc/ipt-netflow/commit/5aae3791922bd3df878605b15e83ea48a4bd096c
which is part of iptables-netflow upstream's 2.6 release, not yet
packaged due to the freeze for bullseye.

I'll try and see if I can get that fix backported to the package in
buster (and if needed, later to the one in bullseye as well) and will
see if it actually helps in this case, too.

JFTR: dkms from buster-backports (as reported below) is only installed
as I needed it for the iptables-netflow-dkms package from bullseye. It
happened with dkms from buster before as well.

-- System Information:
Debian Release: 10.10
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable'), 
(400, 'proposed-updates-debug'), (400, 'proposed-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-12-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages iptables-netflow-dkms depends on:
ii  dkms2.8.4-3~bpo10+1
ii  libc6   2.28-10
ii  libc6-dev   2.28-10
ii  libxtables-dev  1.8.2-4
ii  pkg-config  0.29-6

Versions of packages iptables-netflow-dkms recommends:
ii  iptables  1.8.2-4

Versions of packages iptables-netflow-dkms suggests:
ii  irqtop  2.3-5
ii  nfdump  1.6.17-1

-- no debconf information

Bug#990089: linux-image-4.19.0-17-amd64: lxc-attach fails with Failed to set AppArmor label unconfined

[Salvatore Bonaccorso]

Hi,

On Mon, Jun 21, 2021 at 10:24:31AM +0100, Gmail wrote:
> Salvatore,
> 
> On Sun, 2021-06-20 at 20:39 +0200, Salvatore Bonaccorso wrote:
> > Hi Mark,
> > 
> > On Sun, Jun 20, 2021 at 10:44:29AM +0100, Mark Grant wrote:
> > > Package: src:linux
> > > Version: 4.19.194-1
> > > Severity: normal
> > > 
> > > Dear Maintainer,
> > > 
> > > After upgrading from linux-image-4.19.0-16-amd64 to linux-image-
> > > 4.19.0-17-amd64
> > > attaching an unprivileged linux container fails with the message:
> > > lxc-attach: debian-buster-amd64-basic: lsm/lsm.c:
> > > lsm_process_label_set_at: 174
> > > Operation not permitted - Failed to set AppArmor label "unconfined"
> > > Rebooting into linux-image-4.19.0-16-amd64 with no other changes,
> > > the lxc
> > > system works as expected.
> > 
> > I think this is the same issue as in #990072, would you be able to
> > test the patch as commited
> > https://salsa.debian.org/kernel-team/linux/-/commit/d3fc7c8514bed949d8797cfd3a50a1bed95629c0
> > ?
> > 
> I can confirm that the patch fixed the problem. Many thanks.

Again, thanks. An update is pending and will be released once we have
the builds.

Regards,
Salvatore

Bug#990119: vip-manager: systemd service file uses incorrect parameter syntax

[Chris Hofstaedtler]

Hi,

it appears not only have the numbers of dashes changed, but also the
actual parameter names.

In the current service file, I see:
ExecStart=/usr/bin/vip-manager -ip="${VIP_IP}" -iface="${VIP_IFACE}" 
-key="${VIP_KEY}" -host="${VIP_HOST}" -type="${VIP_TYPE}" 
-endpoint="${VIP_ENDPOINT}" -mask="${VIP_MASK}"

Whats actually working is:
ExecStart=/usr/bin/vip-manager --ip="${VIP_IP}" --interface="${VIP_IFACE}" 
--trigger-key="${VIP_KEY}" --trigger-value="${VIP_HOST}" 
--dcs-type="${VIP_TYPE}" --dcs-endpoints="${VIP_ENDPOINT}" 
--netmask="${VIP_MASK}"

Note that this also causes deprecation warnings:

vip-manager: Parameter "VIP_KEY" has been deprecated, please use 
"VIP_TRIGGER_KEY" instead
vip-manager: Conflicting settings: key or VIP_KEY and trigger-key or 
VIP_TRIGGER_KEY are both specified…
vip-manager: Parameter "VIP_TYPE" has been deprecated, please use 
"VIP_DCS_TYPE" instead
vip-manager: Conflicting settings: type or VIP_TYPE and dcs-type or 
VIP_DCS_TYPE are both specified…
vip-manager: Parameter "VIP_MASK" has been deprecated, please use "VIP_NETMASK" 
instead
vip-manager: Conflicting settings: mask or VIP_MASK and netmask or VIP_NETMASK 
are both specified…
vip-manager: Parameter "VIP_ENDPOINT" has been deprecated, please use 
"VIP_DCS_ENDPOINTS" instead
vip-manager: Conflicting settings: endpoint or VIP_ENDPOINT and dcs-endpoints 
or VIP_DCS_ENDPOINTS are both specified…
vip-manager: Parameter "VIP_IFACE" has been deprecated, please use 
"VIP_INTERFACE" instead
vip-manager: Conflicting settings: iface or VIP_IFACE and interface or 
VIP_INTERFACE are both specified…
vip-manager: Parameter "VIP_HOST" has been deprecated, please use 
"VIP_TRIGGER_VALUE" instead
vip-manager: Conflicting settings: host or VIP_HOST and trigger-value or 
VIP_TRIGGER_VALUE are both specified…

But at least it starts and works.

Thanks,
Chris

Bug#990089: linux-image-4.19.0-17-amd64: lxc-attach fails with Failed to set AppArmor label unconfined

[Gmail]

Salvatore,

On Sun, 2021-06-20 at 20:39 +0200, Salvatore Bonaccorso wrote:
> Hi Mark,
> 
> On Sun, Jun 20, 2021 at 10:44:29AM +0100, Mark Grant wrote:
> > Package: src:linux
> > Version: 4.19.194-1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > After upgrading from linux-image-4.19.0-16-amd64 to linux-image-
> > 4.19.0-17-amd64
> > attaching an unprivileged linux container fails with the message:
> > lxc-attach: debian-buster-amd64-basic: lsm/lsm.c:
> > lsm_process_label_set_at: 174
> > Operation not permitted - Failed to set AppArmor label "unconfined"
> > Rebooting into linux-image-4.19.0-16-amd64 with no other changes,
> > the lxc
> > system works as expected.
> 
> I think this is the same issue as in #990072, would you be able to
> test the patch as commited
> https://salsa.debian.org/kernel-team/linux/-/commit/d3fc7c8514bed949d8797cfd3a50a1bed95629c0
> ?
> 
I can confirm that the patch fixed the problem. Many thanks.

Regards,
Mark

> Regards,
> Salvatore

Bug#990119: vip-manager: systemd service file uses incorrect parameter syntax

[Chris Hofstaedtler]

Package: vip-manager
Version: 1.0.1-3+b2
Severity: serious

Dear Maintainer,

thanks for maintaining the vip-manager package.

I've noticed that the service file
/lib/systemd/system/vip-manager.service uses options with one dash
(ex: `-ip=a.b.c.d`), but the vip-manager binary expects two dashes
(`--ip=a.b.c.d`).

I believe old vip-manager versions used one dash, but apparently
this has changed, and the Debian patch "service_file.patch" needs to
be updated.

Setting severity serious, because the default service file appears
broken.

Thanks,
Chris

Bug#989731: Bug#989732: Shall I upload?

[Christoph Berg]

Re: Ole Streicher
> would you upload the packages with C+R removed soon? Or shall I do? I'd like
> to have that fixed before the final freeze.

Sorry I haven't got to these yet.

If you could upload them, that would be nice.

Thanks,
Christoph

Bug#990072: Update

[Salvatore Bonaccorso]

Hi Matthew,

On Sun, Jun 20, 2021 at 11:14:57PM -0400, Matthew Darwin wrote:
> kernel 4.19.194-1a~test resolved the issue
> 
> Applied
> https://lore.kernel.org/stable/20210614102643.875096...@linuxfoundation.org/
> using the process described at
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html

Many thanks for confirming.

Regards,
Salvatore

Bug#978361: marked as done (hg-git: FTBFS: tests failed)

[Debian Bug Tracking System]

Your message dated Mon, 21 Jun 2021 08:33:31 +
with message-id 
and subject line Bug#978361: fixed in hg-git 0.10.1-1
has caused the Debian Bug report #978361,
regarding hg-git: FTBFS: tests failed
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.)


-- 
978361: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978361
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: hg-git
Version: 0.9.0-2
Severity: serious
Justification: FTBFS on amd64
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201226 ftbfs-bullseye

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.

Relevant part (hopefully):
> make[2]: Entering directory '/<>'
> cd tests && python3 run-tests.py --with-hg=`which hg` --blacklist 
> /<>/debian/hg-git.test_blacklist
> running 41 tests using 4 parallel processes 
> sss
> --- /<>/tests/test-file-removal.t
> +++ /<>/tests/test-file-removal.t.err
> @@ -2,6 +2,16 @@
>$ . "$TESTDIR/testutil"
>  
>$ git init gitrepo
> +  hint: Using 'master' as the name for the initial branch. This default 
> branch name
> +  hint: is subject to change. To configure the initial branch name to use in 
> all
> +  hint: of your new repositories, which will suppress this warning, call:
> +  hint: 
> +  hint:  git config --global init.defaultBranch 
> +  hint: 
> +  hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
> +  hint: 'development'. The just-created branch can be renamed via this 
> command:
> +  hint: 
> +  hint:  git branch -m 
>Initialized empty Git repository in $TESTTMP/gitrepo/.git/
>$ cd gitrepo
>$ echo alpha > alpha
> @@ -96,6 +106,16 @@
>  
>$ cd ..
>$ git init --bare gitrepo2
> +  hint: Using 'master' as the name for the initial branch. This default 
> branch name
> +  hint: is subject to change. To configure the initial branch name to use in 
> all
> +  hint: of your new repositories, which will suppress this warning, call:
> +  hint: 
> +  hint:  git config --global init.defaultBranch 
> +  hint: 
> +  hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
> +  hint: 'development'. The just-created branch can be renamed via this 
> command:
> +  hint: 
> +  hint:  git branch -m 
>Initialized empty Git repository in $TESTTMP/gitrepo2/
>  
>$ hg clone gitrepo hgrepo | grep -v '^updating'
> 
> ERROR: test-file-removal.t output changed
> !..
> --- /<>/tests/test-git-submodules.t
> +++ /<>/tests/test-git-submodules.t.err
> @@ -2,6 +2,16 @@
>$ . "$TESTDIR/testutil"
>  
>$ git init gitrepo1
> +  hint: Using 'master' as the name for the initial branch. This default 
> branch name
> +  hint: is subject to change. To configure the initial branch name to use in 
> all
> +  hint: of your new repositories, which will suppress this warning, call:
> +  hint: 
> +  hint:  git config --global init.defaultBranch 
> +  hint: 
> +  hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
> +  hint: 'development'. The just-created branch can be renamed via this 
> command:
> +  hint: 
> +  hint:  git branch -m 
>Initialized empty Git repository in $TESTTMP/gitrepo1/.git/
>$ cd gitrepo1
>$ echo alpha > alpha
> @@ -10,6 +20,16 @@
>$ cd ..
>  
>$ git init gitsubrepo
> +  hint: Using 'master' as the name for the initial branch. This default 
> branch name
> +  hint: is subject to change. To configure the initial branch name to use in 
> all
> +  hint: of your new repositories, which will suppress this warning, call:
> +  hint: 
> +  hint:  git config --global init.defaultBranch 
> +  hint: 
> +  hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
> +  hint: 'development'. The just-created branch can be renamed via this 
> command:
> +  hint: 
> +  hint:  git branch -m 
>Initialized empty Git repository in $TESTTMP/gitsubrepo/.git/
>$ cd gitsubrepo
>$ echo beta > beta
> 
> ERROR: test-git-submodules.t output changed
> !
> --- /<>/tests/test-hg-author.t
> +++ /<>/tests/test-hg-author.t.err
> @@ -2,6 +2,16 @@
>$ . "$TESTDIR/testutil"
>  
>$ git init gitrepo
> +  hint: Using 'master' as the name for the initial branch. This default 
> branch name
> +  hint: is subject to change. To configure the initial branch name to use in 
> all
> +  hint: of your new repositories, which will suppress this warning, call:
> +  hint: 
> +  hint:  git config --global init.defaultBranch 
> +  hint: 
> +  hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
> +  hint: 'development'. The just-creat

Bug#982459: mdadm --examine in chroot without /proc,/dev,/sys mounted corrupts host's filesystem

[Patrick Cernko]

Hi,

On 18.06.21 12:48, Patrick Cernko wrote:


I will try to reproduce the bug now with one of /dev or /sys mounted and 
check if it still occurs or not. I will send my report about this later 
as this will take some time again.




I could reproduce the bug with /dev *NOT* mounted in chroot. It seems 
independent of /sys being mounted in chroot.


Best Regards,
--
Patrick Cernko 
Joint Administration: Information Services and Technology
Max-Planck-Institute fuer Informatik & Softwaresysteme



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#989731: Shall I upload?

[Ole Streicher]

Dear Christoph,

would you upload the packages with C+R removed soon? Or shall I do? I'd 
like to have that fixed before the final freeze.


Cheers

Ole