[Touch-packages] [Bug 1910576] Re: [MIR] libbpf (dependency of iproute2)

2021-01-14 Thread Christian Ehrhardt
Thanks, this seems ready for promotion then

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1910576

Title:
  [MIR] libbpf (dependency of iproute2)

Status in iproute2 package in Ubuntu:
  Invalid
Status in libbpf package in Ubuntu:
  Fix Committed

Bug description:
  [Availability]
  libbpf | 0.1.0-1 | groovy/universe  | source
  libbpf | 0.3-2   | hirsute/universe | source

  [Rationale]
  Libbpf is (or is about to become) a dependency for building iproute2 which 
already is in main. Using BPF is becoming more wide-spread. The library allows 
to load and use eBPF programs from user-space (functionality provided by the 
kernel). It is already maintained in main for Debian 
(https://tracker.debian.org/pkg/libbpf)

  [Security]
  Since the code is taken out of the Linux kernel, this should be treated 
similar to the kernel for security. Research uncovered no records about 
security issues.

  [Quality assurance]
  At this point there are no open bug reports against libbpf (except this one) 
in Ubuntu. Also no open bugs found in Debian. Project is taken from the kernel 
source and claims static analysis via LGTM and Coverty. Also has CI via Travis 
(https://travis-ci.com/github/libbpf/libbpf).
  Right now there are no dep-8 tests. Though potentially it should be possible 
to create those, would this really add additional benefit beyond having 
upstream CI?
  A test build on hirsute was showing no warnings beyond lintian complaining 
about things which would be changed if we had delta (unstable as series for 
example). Otherwise was clean.

  [Dependencies]
  libc6: main
  libelf1: main
  zlib1g: main

  [Standards compliance]
  $ lintian --pedantic libbpf_0.3-2.dsc
  P: libbpf source: no-homepage-field
  P: libbpf source: silent-on-rules-requiring-root

  [Maintenance]
  As this is only taking out code from the kernel into a separate library 
package, the maintenance effort should be minimal. Packaging is done in Debian 
and is synced into Ubuntu (no delta).

  [Background information]
  A discourse about why this is packaged outside the kernel can be found at 
https://lwn.net/Articles/836911/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1910576/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1910576] Re: [MIR] libbpf (dependency of iproute2)

2021-01-14 Thread Christian Ehrhardt
[Summary]
MIR Team Ack to src:libbpf
This does not need a security review IMHO, but as outlined below I'd want
security to quickly ACK on that decision - assigning to Seth (security MIR
Team member) for that.
List of specific binary packages to be promoted to main: libbpf0

Required TODOs:
- None

Recommended TODOs:
- Add build and/or autopkgtest tests to the package to spot issues early

[Duplication]
There is no other package in main providing the same functionality.
Some packages that formerly had libbpf code slowly migrate to this lib.
But that isn't duplication it is the right thing to do.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- -dev package will be auto-promoted, but all it's deps are ok as well

[Embedded sources and static linking]
- no embedded source present (this is in fact used to un-embed some
  in other pkg)
- no static linking

[Security]
OK:
- history of CVEs does not look concerning
  No issues on the lib yet, but the kernel backend has some (as one would
  expect for such a dynamic interface)
  https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bpf
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)

Problems:
- does not parse data formats, but no externally controlled ones

I'm unsure if this needs a security review. They are currently rather
busy with those and this package does replace code that was worse in iproute2
(pulling it into main). Since this is driven and in a lot of use by the
bigger kernel community as well as Debian jumping onto this for Buster I think
while I'd appreciate a review we don't strictly need it here as we are
replacing better code.
Also the new iproute needs to go along kernel 5.10 which just appeared in
21.04 so the runway is short.

But I'll want security to do a 5-10 minute read of that reasoning and the code
to agree to that decision. If they do we can go on promoting this immediately.
If security decides that a full review is needed it will go their way as usual.

[Common blockers]
OK:
- does not FTBFS currently
- The package has a team bug subscriber
- no translation present, but none needed for this case (user visible)?
- not a python/go package, no extra constraints to consider int hat regard
- no new python2 dependency

Problems:
- does not have a test suite that runs at build time
- does not have a test suite that runs as autopkgtest
Gladly that is somewhat covered by the upstream travis tests. None of the few
but growing dependencies has higher level tests yet. This isn't a blocker
since this is "just" the lib but certainly a step that would be recommended
to the owning team to add.


[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking is in place
- d/watch is present and looks ok
- Upstream update history is good, but it is yet rather new
- Debian/Ubuntu update history is good
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- Does not have Built-Using

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks


** Changed in: libbpf (Ubuntu)
 Assignee: Christian Ehrhardt  (paelzer) => Seth Arnold (seth-arnold)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1910576

Title:
  [MIR] libbpf (dependency of iproute2)

Status in iproute2 package in Ubuntu:
  Invalid
Status in libbpf package in Ubuntu:
  New

Bug description:
  [Availability]
  libbpf | 0.1.0-1 | groovy/universe  | source
  libbpf | 0.3-2   | hirsute/universe | source

  [Rationale]
  Libbpf is (or is about to become) a dependency for building iproute2 which 
already is in main. Using BPF is becoming more wide-spread. The library allows 
to load and use eBPF programs from user-space (functionality provided by the 
kernel). It is already maintained in main for Debian 
(https://tracker.debian.org/pkg/libbpf)

  [Security]
  Since the code is taken out of the Linux kernel, this should be treated 
similar to the kernel for security. Research uncovered no records about 
security issues.

  [Quality assurance]
  At this point there are no open bug reports against libbpf (except this one) 
in Ubuntu. Also no open bugs found in Debian. Project is taken from the kernel 
source and claims static anal

[Touch-packages] [Bug 1910576] Re: [MIR] libbpf (dependency of iproute2)

2021-01-13 Thread Christian Ehrhardt
** Changed in: iproute2 (Ubuntu)
 Assignee: Kernel Packages (kernel-packages) => (unassigned)

** Changed in: libbpf (Ubuntu)
 Assignee: Kernel Packages (kernel-packages) => Christian Ehrhardt  
(paelzer)

** Changed in: iproute2 (Ubuntu)
   Status: New => Invalid

** Changed in: libbpf (Ubuntu)
   Status: Incomplete => New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1910576

Title:
  [MIR] libbpf (dependency of iproute2)

Status in iproute2 package in Ubuntu:
  Invalid
Status in libbpf package in Ubuntu:
  New

Bug description:
  [Availability]
  libbpf | 0.1.0-1 | groovy/universe  | source
  libbpf | 0.3-2   | hirsute/universe | source

  [Rationale]
  Libbpf is (or is about to become) a dependency for building iproute2 which 
already is in main. Using BPF is becoming more wide-spread. The library allows 
to load and use eBPF programs from user-space (functionality provided by the 
kernel). It is already maintained in main for Debian 
(https://tracker.debian.org/pkg/libbpf)

  [Security]
  Since the code is taken out of the Linux kernel, this should be treated 
similar to the kernel for security. Research uncovered no records about 
security issues.

  [Quality assurance]
  At this point there are no open bug reports against libbpf (except this one) 
in Ubuntu. Also no open bugs found in Debian. Project is taken from the kernel 
source and claims static analysis via LGTM and Coverty. Also has CI via Travis 
(https://travis-ci.com/github/libbpf/libbpf).
  Right now there are no dep-8 tests. Though potentially it should be possible 
to create those, would this really add additional benefit beyond having 
upstream CI?
  A test build on hirsute was showing no warnings beyond lintian complaining 
about things which would be changed if we had delta (unstable as series for 
example). Otherwise was clean.

  [Dependencies]
  libc6: main
  libelf1: main
  zlib1g: main

  [Standards compliance]
  $ lintian --pedantic libbpf_0.3-2.dsc
  P: libbpf source: no-homepage-field
  P: libbpf source: silent-on-rules-requiring-root

  [Maintenance]
  As this is only taking out code from the kernel into a separate library 
package, the maintenance effort should be minimal. Packaging is done in Debian 
and is synced into Ubuntu (no delta).

  [Background information]
  A discourse about why this is packaged outside the kernel can be found at 
https://lwn.net/Articles/836911/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1910576/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1908818] Re: pure packaging of libnss3

2021-01-08 Thread Christian Ehrhardt
That should be this fix:
https://git.launchpad.net/ubuntu/+source/nss/commit/?h=applied/2%253.55-1ubuntu4=c17f28c15519fb4834860c021c078c6ea0d8ab50

Since this is kind of a patch-on-a-plate I'm marking it server-next.

** Tags added: server-next

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to nss in Ubuntu.
https://bugs.launchpad.net/bugs/1908818

Title:
  pure packaging of libnss3

Status in nss package in Ubuntu:
  Fix Released
Status in nss source package in Groovy:
  Triaged

Bug description:
  dpkg -L libnss3
  /.
  /usr
  /usr/lib
  /usr/lib/${DEB_HOST_MULTIARCH}
  /usr/lib/x86_64-linux-gnu
  /usr/lib/x86_64-linux-gnu/libnss3.so
  /usr/lib/x86_64-linux-gnu/libnssutil3.so
  /usr/lib/x86_64-linux-gnu/libsmime3.so
  /usr/lib/x86_64-linux-gnu/libssl3.so
  /usr/lib/x86_64-linux-gnu/nss
  /usr/lib/x86_64-linux-gnu/nss/libfreebl3.chk
  /usr/lib/x86_64-linux-gnu/nss/libfreebl3.so
  /usr/lib/x86_64-linux-gnu/nss/libfreeblpriv3.chk
  /usr/lib/x86_64-linux-gnu/nss/libfreeblpriv3.so
  /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so
  /usr/lib/x86_64-linux-gnu/nss/libnssdbm3.chk
  /usr/lib/x86_64-linux-gnu/nss/libnssdbm3.so
  /usr/lib/x86_64-linux-gnu/nss/libsoftokn3.chk
  /usr/lib/x86_64-linux-gnu/nss/libsoftokn3.so
  /usr/share
  /usr/share/doc
  /usr/share/doc/libnss3
  /usr/share/doc/libnss3/changelog.Debian.gz
  /usr/share/doc/libnss3/copyright
  /usr/share/lintian
  /usr/share/lintian/overrides
  /usr/share/lintian/overrides/libnss3
  /usr/lib/${DEB_HOST_MULTIARCH}/libfreebl3.chk
  /usr/lib/${DEB_HOST_MULTIARCH}/libfreebl3.so
  /usr/lib/${DEB_HOST_MULTIARCH}/libfreeblpriv3.chk

  
  as we can see soft links to libraries do nor resolve ${DEB_HOST_MULTIARCH} to 
x86_64-linux-gnu

  ProblemType: Bug
  DistroRelease: Ubuntu 20.10
  Package: libnss3 2:3.55-1ubuntu3
  ProcVersionSignature: Ubuntu 5.8.0-33.36-generic 5.8.17
  Uname: Linux 5.8.0-33-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu50.3
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Sun Dec 20 14:36:10 2020
  SourcePackage: nss
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1908818/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1909748] Re: Apparmor profile improvements for letsencrypt

2021-01-04 Thread Christian Ehrhardt
FYI - We've united this with a merge for 21.04 that was ongoing.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1909748

Title:
  Apparmor profile improvements for letsencrypt

Status in openldap package in Ubuntu:
  In Progress

Bug description:
  I can see that the slapd apparmor profile goes 90% of the way to
  working out of the box with letsencrypt/certbot, but fails to include
  abstractions/ssl_keys. The attached patch should work support all the
  methods in these abstractions, and should be the default with the
  slapd package.

  Please can you look at including this in future?

  Many thanks,
  Paul.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1909748/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1909748] Re: Apparmor profile improvements for letsencrypt

2021-01-04 Thread Christian Ehrhardt
The apparmor profile isn't in Debian yet and I've seen no effort to do so 
[1][2] yet.
Therefore for now just update the profile we have.

Therefore I proposed [3] which converted your contribution to the
changes that will be needed on the packaging.

P.S. I've spoken to Andreas and he said there was no old deny for
apparmor in Debian, so we should at some point be able to get it there
as well (with the fix then).

[1]: https://salsa.debian.org/paelzer-guest/openldap/-/merge_requests
[2]: https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=yes=openldap
[3]: 
https://code.launchpad.net/~paelzer/ubuntu/+source/openldap/+git/openldap/+merge/395730

** Changed in: openldap (Ubuntu)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1909748

Title:
  Apparmor profile improvements for letsencrypt

Status in openldap package in Ubuntu:
  In Progress

Bug description:
  I can see that the slapd apparmor profile goes 90% of the way to
  working out of the box with letsencrypt/certbot, but fails to include
  abstractions/ssl_keys. The attached patch should work support all the
  methods in these abstractions, and should be the default with the
  slapd package.

  Please can you look at including this in future?

  Many thanks,
  Paul.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1909748/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1909748] Re: Apparmor profile improvements for letsencrypt

2021-01-04 Thread Christian Ehrhardt
FYI - Your change looks fine to me.
I'll take a closer look later to consider where to best push this.

** Tags added: server-next

** Changed in: openldap (Ubuntu)
 Assignee: (unassigned) => Christian Ehrhardt  (paelzer)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1909748

Title:
  Apparmor profile improvements for letsencrypt

Status in openldap package in Ubuntu:
  New

Bug description:
  I can see that the slapd apparmor profile goes 90% of the way to
  working out of the box with letsencrypt/certbot, but fails to include
  abstractions/ssl_keys. The attached patch should work support all the
  methods in these abstractions, and should be the default with the
  slapd package.

  Please can you look at including this in future?

  Many thanks,
  Paul.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1909748/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1908259] Re: TEST-36-NUMAPOLICY fails with qemu 5.2

2021-01-04 Thread Christian Ehrhardt
Thank you, this is indeed ok for Qemu now.
And systemd is all up to you as you get re-started in 2021 - happy new year and 
thanks for your work on this.

** Changed in: qemu (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1908259

Title:
  TEST-36-NUMAPOLICY fails with qemu 5.2

Status in systemd:
  Unknown
Status in qemu package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  In Progress

Bug description:
  Hi,
  this test now fails as seen on ppc here
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/ppc64el/s/systemd/20201214_224336_8b0d8@/log.gz

  + /bin/qemu-system-ppc64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinux-5.8.0-25-generic -drive 
format=raw,cache=unsafe,file=/var/tmp/systemd-test.qFc3xq/default.img -numa 
node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' 
root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 
init=/lib/systemd/systemd console=hvc0 selinux=0  
SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units:
 systemd.unit=testsuite.target systemd.wants=testsuite-36.service 
systemd.wants=end.service  '
  E: QEMU failed with exit code 1
  qemu-system-ppc64: total memory for NUMA nodes (0x0) should equal RAM size 
(0x2000)

  Reproducible in LP infra with systemd 246.6-5ubuntu1 and qemu 5.2

  On other architectures this test is just skipped and ppc happened to complete
  faster so I saw it earlier.

  The same happens on amd64
  + /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinuz-5.8.0-25-generic -drive 
format=raw,cache=unsafe,file=/var/tmp/systemd-test.8Hqpmk/default.img -numa 
node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' 
root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 
init=/lib/systemd/systemd console=ttyS0 selinux=0  
SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units:
 systemd.unit=testsuite.target systemd.wants=testsuite-36.service 
systemd.wants=end.service  '
  qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size 
(0x2000)
  E: QEMU failed with exit code 1 

  
  Isolated this to a test without systemd:
  $ apt install linux-image-generic qemu-system-x86
  $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd 
/boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0'

  Upgrading to 5.2 makes this:
  $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd 
/boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0'
  qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size 
(0x2000)

  The numa spec is indeed a bit short
-numa node,nodeid=0
  If I change this to
-numa node,mem=512M,nodeid=0
  It would work, but that kind of specification is forbidden >=5.1
Parameter -numa node,mem is not supported by this machine type
Use -numa node,memdev instead
  You'd need also something like -M pc-i440fx-5.0 which isn't anything the test
  wants to set in stone I guess.
  Instead using memdev works:
-object memory-backend-ram,id=mem0,size=512M -numa node,memdev=mem0,nodeid=0

  This works fine and is in qemu since quite some time.
  Properly documented since 2.12 but actually available since 2.1 (2014)

  The argument for this test is in test/TEST-36-NUMAPOLICY/test.sh
QEMU_OPTIONS="-numa node,nodeid=0"

  Fixing that to a new form should help.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1908259/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1908259] Re: TEST-36-NUMAPOLICY fails with qemu 5.2

2020-12-15 Thread Christian Ehrhardt
Upstream CI as well as local autopkgtest runs confirm that the new
systemd test code will make the new qemu pass.

# Formerly failing
$ sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest --no-built-binaries -o 
systemd-vs-qemu5.2 --apt-upgrade --apt-pocket=proposed=src:qemu 
--setup-commands="add-apt-repository ppa:ci-trg
...
autopkgtest [17:09:01]: test upstream: ---]
upstream PASS
autopkgtest [17:09:02]: test upstream:  - - - - - - - - - - results - - - - - - 
- - - -
autopkgtest [17:09:03]:  summary
upstream PASS
qemu-system-x86_64: terminating on signal 15 from pid 1783557 (/usr/bin/python3)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1908259

Title:
  TEST-36-NUMAPOLICY fails with qemu 5.2

Status in systemd:
  Unknown
Status in qemu package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Hi,
  this test now fails as seen on ppc here
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/ppc64el/s/systemd/20201214_224336_8b0d8@/log.gz

  + /bin/qemu-system-ppc64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinux-5.8.0-25-generic -drive 
format=raw,cache=unsafe,file=/var/tmp/systemd-test.qFc3xq/default.img -numa 
node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' 
root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 
init=/lib/systemd/systemd console=hvc0 selinux=0  
SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units:
 systemd.unit=testsuite.target systemd.wants=testsuite-36.service 
systemd.wants=end.service  '
  E: QEMU failed with exit code 1
  qemu-system-ppc64: total memory for NUMA nodes (0x0) should equal RAM size 
(0x2000)

  Reproducible in LP infra with systemd 246.6-5ubuntu1 and qemu 5.2

  On other architectures this test is just skipped and ppc happened to complete
  faster so I saw it earlier.

  The same happens on amd64
  + /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinuz-5.8.0-25-generic -drive 
format=raw,cache=unsafe,file=/var/tmp/systemd-test.8Hqpmk/default.img -numa 
node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' 
root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 
init=/lib/systemd/systemd console=ttyS0 selinux=0  
SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units:
 systemd.unit=testsuite.target systemd.wants=testsuite-36.service 
systemd.wants=end.service  '
  qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size 
(0x2000)
  E: QEMU failed with exit code 1 

  
  Isolated this to a test without systemd:
  $ apt install linux-image-generic qemu-system-x86
  $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd 
/boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0'

  Upgrading to 5.2 makes this:
  $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd 
/boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0'
  qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size 
(0x2000)

  The numa spec is indeed a bit short
-numa node,nodeid=0
  If I change this to
-numa node,mem=512M,nodeid=0
  It would work, but that kind of specification is forbidden >=5.1
Parameter -numa node,mem is not supported by this machine type
Use -numa node,memdev instead
  You'd need also something like -M pc-i440fx-5.0 which isn't anything the test
  wants to set in stone I guess.
  Instead using memdev works:
-object memory-backend-ram,id=mem0,size=512M -numa node,memdev=mem0,nodeid=0

  This works fine and is in qemu since quite some time.
  Properly documented since 2.12 but actually available since 2.1 (2014)

  The argument for this test is in test/TEST-36-NUMAPOLICY/test.sh
QEMU_OPTIONS="-numa node,nodeid=0"

  Fixing that to a new form should help.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1908259/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1908259] Re: TEST-36-NUMAPOLICY fails with qemu 5.2

2020-12-15 Thread Christian Ehrhardt
https://github.com/systemd/systemd/pull/17987 was accepted upstream.
I assume with the amount of dependencies that systemd has there is no easy 
"just apply this and upload" that will make anyone happy :-/

But now that everything seems ready I wanted to ask the package
maintainer (who usually has a plan on coming uploads already) when we
could get this applied?

** Changed in: systemd (Ubuntu)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1908259

Title:
  TEST-36-NUMAPOLICY fails with qemu 5.2

Status in systemd:
  Unknown
Status in qemu package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Hi,
  this test now fails as seen on ppc here
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/ppc64el/s/systemd/20201214_224336_8b0d8@/log.gz

  + /bin/qemu-system-ppc64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinux-5.8.0-25-generic -drive 
format=raw,cache=unsafe,file=/var/tmp/systemd-test.qFc3xq/default.img -numa 
node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' 
root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 
init=/lib/systemd/systemd console=hvc0 selinux=0  
SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units:
 systemd.unit=testsuite.target systemd.wants=testsuite-36.service 
systemd.wants=end.service  '
  E: QEMU failed with exit code 1
  qemu-system-ppc64: total memory for NUMA nodes (0x0) should equal RAM size 
(0x2000)

  Reproducible in LP infra with systemd 246.6-5ubuntu1 and qemu 5.2

  On other architectures this test is just skipped and ppc happened to complete
  faster so I saw it earlier.

  The same happens on amd64
  + /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinuz-5.8.0-25-generic -drive 
format=raw,cache=unsafe,file=/var/tmp/systemd-test.8Hqpmk/default.img -numa 
node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' 
root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 
init=/lib/systemd/systemd console=ttyS0 selinux=0  
SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units:
 systemd.unit=testsuite.target systemd.wants=testsuite-36.service 
systemd.wants=end.service  '
  qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size 
(0x2000)
  E: QEMU failed with exit code 1 

  
  Isolated this to a test without systemd:
  $ apt install linux-image-generic qemu-system-x86
  $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd 
/boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0'

  Upgrading to 5.2 makes this:
  $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd 
/boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0'
  qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size 
(0x2000)

  The numa spec is indeed a bit short
-numa node,nodeid=0
  If I change this to
-numa node,mem=512M,nodeid=0
  It would work, but that kind of specification is forbidden >=5.1
Parameter -numa node,mem is not supported by this machine type
Use -numa node,memdev instead
  You'd need also something like -M pc-i440fx-5.0 which isn't anything the test
  wants to set in stone I guess.
  Instead using memdev works:
-object memory-backend-ram,id=mem0,size=512M -numa node,memdev=mem0,nodeid=0

  This works fine and is in qemu since quite some time.
  Properly documented since 2.12 but actually available since 2.1 (2014)

  The argument for this test is in test/TEST-36-NUMAPOLICY/test.sh
QEMU_OPTIONS="-numa node,nodeid=0"

  Fixing that to a new form should help.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1908259/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1908259] Re: TEST-36-NUMAPOLICY fails with qemu 5.2

2020-12-15 Thread Christian Ehrhardt
Tests are somewhat blocked by PPA being under maintenance.
But I have filed the issue upstream for discussion and to trigger their CI.

Issue => https://github.com/systemd/systemd/issues/17986
PR => https://github.com/systemd/systemd/pull/17987

** Bug watch added: github.com/systemd/systemd/issues #17986
   https://github.com/systemd/systemd/issues/17986

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/17986
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1908259

Title:
  TEST-36-NUMAPOLICY fails with qemu 5.2

Status in systemd:
  Unknown
Status in qemu package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Hi,
  this test now fails as seen on ppc here
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/ppc64el/s/systemd/20201214_224336_8b0d8@/log.gz

  + /bin/qemu-system-ppc64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinux-5.8.0-25-generic -drive 
format=raw,cache=unsafe,file=/var/tmp/systemd-test.qFc3xq/default.img -numa 
node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' 
root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 
init=/lib/systemd/systemd console=hvc0 selinux=0  
SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units:
 systemd.unit=testsuite.target systemd.wants=testsuite-36.service 
systemd.wants=end.service  '
  E: QEMU failed with exit code 1
  qemu-system-ppc64: total memory for NUMA nodes (0x0) should equal RAM size 
(0x2000)

  Reproducible in LP infra with systemd 246.6-5ubuntu1 and qemu 5.2

  On other architectures this test is just skipped and ppc happened to complete
  faster so I saw it earlier.

  The same happens on amd64
  + /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinuz-5.8.0-25-generic -drive 
format=raw,cache=unsafe,file=/var/tmp/systemd-test.8Hqpmk/default.img -numa 
node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' 
root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 
init=/lib/systemd/systemd console=ttyS0 selinux=0  
SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units:
 systemd.unit=testsuite.target systemd.wants=testsuite-36.service 
systemd.wants=end.service  '
  qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size 
(0x2000)
  E: QEMU failed with exit code 1 

  
  Isolated this to a test without systemd:
  $ apt install linux-image-generic qemu-system-x86
  $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd 
/boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0'

  Upgrading to 5.2 makes this:
  $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd 
/boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0'
  qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size 
(0x2000)

  The numa spec is indeed a bit short
-numa node,nodeid=0
  If I change this to
-numa node,mem=512M,nodeid=0
  It would work, but that kind of specification is forbidden >=5.1
Parameter -numa node,mem is not supported by this machine type
Use -numa node,memdev instead
  You'd need also something like -M pc-i440fx-5.0 which isn't anything the test
  wants to set in stone I guess.
  Instead using memdev works:
-object memory-backend-ram,id=mem0,size=512M -numa node,memdev=mem0,nodeid=0

  This works fine and is in qemu since quite some time.
  Properly documented since 2.12 but actually available since 2.1 (2014)

  The argument for this test is in test/TEST-36-NUMAPOLICY/test.sh
QEMU_OPTIONS="-numa node,nodeid=0"

  Fixing that to a new form should help.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1908259/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1908259] Re: TEST-36-NUMAPOLICY fails with qemu 5.2

2020-12-15 Thread Christian Ehrhardt
Added qemu task for update-excuse tag to be resolved.

I have a fix prepared that is building/testing right now. If successful
I'll open an upstream issue for it.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1908259

Title:
  TEST-36-NUMAPOLICY fails with qemu 5.2

Status in qemu package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Hi,
  this test now fails as seen on ppc here
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/ppc64el/s/systemd/20201214_224336_8b0d8@/log.gz

  + /bin/qemu-system-ppc64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinux-5.8.0-25-generic -drive 
format=raw,cache=unsafe,file=/var/tmp/systemd-test.qFc3xq/default.img -numa 
node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' 
root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 
init=/lib/systemd/systemd console=hvc0 selinux=0  
SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units:
 systemd.unit=testsuite.target systemd.wants=testsuite-36.service 
systemd.wants=end.service  '
  E: QEMU failed with exit code 1
  qemu-system-ppc64: total memory for NUMA nodes (0x0) should equal RAM size 
(0x2000)

  Reproducible in LP infra with systemd 246.6-5ubuntu1 and qemu 5.2

  On other architectures this test is just skipped and ppc happened to complete
  faster so I saw it earlier.

  The same happens on amd64
  + /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinuz-5.8.0-25-generic -drive 
format=raw,cache=unsafe,file=/var/tmp/systemd-test.8Hqpmk/default.img -numa 
node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' 
root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 
init=/lib/systemd/systemd console=ttyS0 selinux=0  
SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units:
 systemd.unit=testsuite.target systemd.wants=testsuite-36.service 
systemd.wants=end.service  '
  qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size 
(0x2000)
  E: QEMU failed with exit code 1 

  
  Isolated this to a test without systemd:
  $ apt install linux-image-generic qemu-system-x86
  $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd 
/boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0'

  Upgrading to 5.2 makes this:
  $ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd 
/boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0'
  qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size 
(0x2000)

  The numa spec is indeed a bit short
-numa node,nodeid=0
  If I change this to
-numa node,mem=512M,nodeid=0
  It would work, but that kind of specification is forbidden >=5.1
Parameter -numa node,mem is not supported by this machine type
Use -numa node,memdev instead
  You'd need also something like -M pc-i440fx-5.0 which isn't anything the test
  wants to set in stone I guess.
  Instead using memdev works:
-object memory-backend-ram,id=mem0,size=512M -numa node,memdev=mem0,nodeid=0

  This works fine and is in qemu since quite some time.
  Properly documented since 2.12 but actually available since 2.1 (2014)

  The argument for this test is in test/TEST-36-NUMAPOLICY/test.sh
QEMU_OPTIONS="-numa node,nodeid=0"

  Fixing that to a new form should help.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1908259/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1908259] [NEW] TEST-36-NUMAPOLICY fails with qemu 5.2

2020-12-15 Thread Christian Ehrhardt
Public bug reported:

Hi,
this test now fails as seen on ppc here
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/ppc64el/s/systemd/20201214_224336_8b0d8@/log.gz

+ /bin/qemu-system-ppc64 -smp 1 -net none -m 512M -nographic -vga none -kernel 
/boot/vmlinux-5.8.0-25-generic -drive 
format=raw,cache=unsafe,file=/var/tmp/systemd-test.qFc3xq/default.img -numa 
node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' 
root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 
init=/lib/systemd/systemd console=hvc0 selinux=0  
SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units:
 systemd.unit=testsuite.target systemd.wants=testsuite-36.service 
systemd.wants=end.service  '
E: QEMU failed with exit code 1
qemu-system-ppc64: total memory for NUMA nodes (0x0) should equal RAM size 
(0x2000)

Reproducible in LP infra with systemd 246.6-5ubuntu1 and qemu 5.2

On other architectures this test is just skipped and ppc happened to complete
faster so I saw it earlier.

The same happens on amd64
+ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel 
/boot/vmlinuz-5.8.0-25-generic -drive 
format=raw,cache=unsafe,file=/var/tmp/systemd-test.8Hqpmk/default.img -numa 
node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' 
root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 
init=/lib/systemd/systemd console=ttyS0 selinux=0  
SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units:
 systemd.unit=testsuite.target systemd.wants=testsuite-36.service 
systemd.wants=end.service  '
qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size 
(0x2000)
E: QEMU failed with exit code 1 


Isolated this to a test without systemd:
$ apt install linux-image-generic qemu-system-x86
$ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel 
/boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd 
/boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0'

Upgrading to 5.2 makes this:
$ /bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -vga none -kernel 
/boot/vmlinuz-5.8.0-25-generic -numa node,nodeid=0 -initrd 
/boot/initrd.img-5.8.0-25-generic -append 'console=ttyS0 selinux=0'
qemu-system-x86_64: total memory for NUMA nodes (0x0) should equal RAM size 
(0x2000)

The numa spec is indeed a bit short
  -numa node,nodeid=0
If I change this to
  -numa node,mem=512M,nodeid=0
It would work, but that kind of specification is forbidden >=5.1
  Parameter -numa node,mem is not supported by this machine type
  Use -numa node,memdev instead
You'd need also something like -M pc-i440fx-5.0 which isn't anything the test
wants to set in stone I guess.
Instead using memdev works:
  -object memory-backend-ram,id=mem0,size=512M -numa node,memdev=mem0,nodeid=0

This works fine and is in qemu since quite some time.
Properly documented since 2.12 but actually available since 2.1 (2014)

The argument for this test is in test/TEST-36-NUMAPOLICY/test.sh
  QEMU_OPTIONS="-numa node,nodeid=0"

Fixing that to a new form should help.

** Affects: qemu (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: update-excuse

** Also affects: qemu (Ubuntu)
   Importance: Undecided
   Status: New

** Tags added: update-excuse

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1908259

Title:
  TEST-36-NUMAPOLICY fails with qemu 5.2

Status in qemu package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Hi,
  this test now fails as seen on ppc here
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/ppc64el/s/systemd/20201214_224336_8b0d8@/log.gz

  + /bin/qemu-system-ppc64 -smp 1 -net none -m 512M -nographic -vga none 
-kernel /boot/vmlinux-5.8.0-25-generic -drive 
format=raw,cache=unsafe,file=/var/tmp/systemd-test.qFc3xq/default.img -numa 
node,nodeid=0 -initrd /boot/initrd.img-5.8.0-25-generic -append ' 
root=/dev/sda1 rw raid=noautodetect rd.luks=0 loglevel=2 
init=/lib/systemd/systemd console=hvc0 selinux=0  
SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-36.units:/usr/lib/systemd/tests/testdata/units:
 systemd.unit=testsuite.target systemd.wants=testsuite-36.service 
systemd.wants=end.service  '
  E: QEMU failed with exit code 1
  qemu-system-ppc64: total memory for NUMA nodes (0x0) should equal RAM size 
(0x2000)

  Reproducible in LP infra with systemd 246.6-5ubuntu1 and qemu 5.2

  On other architectures this test is just skipped and ppc happened to complete
  faster so I saw it earlier.

  The same happens on amd64
  + /bin/qemu-system-x86_64 -smp 

[Touch-packages] [Bug 1907789] Re: 2.35.50 breaks ld -no-pie

2020-12-14 Thread Christian Ehrhardt
FYI - fix submitted to qemu upstream and for now added to the qemu package. If 
upstream eventually prefers a different solution I can refresh it accordingly.
=> https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg03684.html

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1907789

Title:
  2.35.50 breaks ld -no-pie

Status in binutils:
  Fix Released
Status in binutils package in Ubuntu:
  Fix Committed
Status in qemu package in Ubuntu:
  In Progress

Bug description:
  The qemu build reaches (and always did) a step where it tries to link some
  img files. That is done via the command:
$ ld -m elf_i386 -T /<>/pc-bios/optionrom//flat.lds -no-pie -s 
-o multiboot.img multiboot.o

  Recently that still works in Debian [1] but no more in Ubuntu [2].

  I think that the new binutils broke me.
  In hirsute proposed those are at 2.35.50.20201210-0ubuntu1

  The issue is easily isolated, and by copying the two files around I
  found the following:

  Hirsute: 2.35.50.20201210-0ubuntu1 - bad
  Hirsute: 2.35.50.20201207-0ubuntu1 - bad
  Sid: 2.35.1-4  - good
  Groovy:  2.35.1-1ubuntu1   - good
  Focal:   2.34-6ubuntu1 - good

  I'll attach these two files to the bug, just thro them into a directory and
  run the command:
   $ ld -m elf_i386 -T ./flat.lds -no-pie -s -o linuxboot.img linuxboot.o

  If that is an intentional change please guide how this is now supposed
  to work.

  [1]: 
https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A5.2%2Bdfsg-2=1607598738=1
  [2]: 
https://launchpadlibrarian.net/510801929/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILD

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1907789/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1907789] Re: 2.35.50 breaks ld -no-pie

2020-12-14 Thread Christian Ehrhardt
** Also affects: qemu (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: qemu (Ubuntu)
   Status: New => In Progress

** Changed in: qemu (Ubuntu)
 Assignee: (unassigned) => Christian Ehrhardt  (paelzer)

** Changed in: qemu (Ubuntu)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1907789

Title:
  2.35.50 breaks ld -no-pie

Status in binutils:
  Unknown
Status in binutils package in Ubuntu:
  Fix Committed
Status in qemu package in Ubuntu:
  In Progress

Bug description:
  The qemu build reaches (and always did) a step where it tries to link some
  img files. That is done via the command:
$ ld -m elf_i386 -T /<>/pc-bios/optionrom//flat.lds -no-pie -s 
-o multiboot.img multiboot.o

  Recently that still works in Debian [1] but no more in Ubuntu [2].

  I think that the new binutils broke me.
  In hirsute proposed those are at 2.35.50.20201210-0ubuntu1

  The issue is easily isolated, and by copying the two files around I
  found the following:

  Hirsute: 2.35.50.20201210-0ubuntu1 - bad
  Hirsute: 2.35.50.20201207-0ubuntu1 - bad
  Sid: 2.35.1-4  - good
  Groovy:  2.35.1-1ubuntu1   - good
  Focal:   2.34-6ubuntu1 - good

  I'll attach these two files to the bug, just thro them into a directory and
  run the command:
   $ ld -m elf_i386 -T ./flat.lds -no-pie -s -o linuxboot.img linuxboot.o

  If that is an intentional change please guide how this is now supposed
  to work.

  [1]: 
https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A5.2%2Bdfsg-2=1607598738=1
  [2]: 
https://launchpadlibrarian.net/510801929/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILD

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1907789/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1900008] Re: Sessions of screen does not keep running in background

2020-12-13 Thread Christian Ehrhardt
Since this started to seem different between Mate as discussed above I was 
giving a few more terminals I regularly use a try:
- tilix (VTE based) - warns me that I'll close processes under this session, 
keeps screen alive detached
- yakuake (kde based) - warns me that I'll close processes under this session, 
keeps screen alive detached
- konsole - warns me that I'll close processes under this session, keeps screen 
alive detached
- gnome-terminal - no warning, keeps screen alive detached

So screen never totally died in any of those, just remained detached as
one would want/expect.

Since I even tried several KDE based terminals, but not had KDE itself
running (I had default gnome based Desktop). I wonder if there might be
some general KDE-setting that changes how closing sessions work.

@Gustavo - when you get to retry it on a VM as you mentioned, would you
mind trying the same on a KDE-Neon vs a default-Gnome desktop?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/198

Title:
  Sessions of screen does not keep running in background

Status in screen package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  In a new fresh installed 20.04, when I use screen command and close
  the terminal (not closing screen sesion), then I can't recover it with
  screen -x, since does not exist. I can only recover screen sesion if
  the original terminal running screen is not being closed.

  For some reason, this is closing screen session of that user:

  Oct 15 13:32:45 pc-caja2 systemd[1]: session-66.scope: Succeeded.
  Oct 15 13:32:45 pc-caja2 systemd[1]: Stopped Session 66 of user usuario.

  This does not happen in an upgraded system from 18.04 to 20.04.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/screen/+bug/198/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1907893] Re: package openssh-server 1:8.3p1-1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1

2020-12-13 Thread Christian Ehrhardt
Thank you for taking the time to report this bug and helping to make
Ubuntu better.

On upgrading a service this service has to be restarted to pick up the fixes.
Rather rarely a real issue occurs that the newer version does e.g. fail with 
the formerly working configuration.
But most of the time what happens is, that a service was installed, but stays 
unconfigured or experimented with but left in a broken state.

Now on any update of the related packages that service has to be restarted, but 
since its config is incomplete/faulty it fails to restart.
Therefore the update of that package has to consider itself incomplete.

Depending on your particular case there are two solutions:
- either remove the offending package if you don't want to continue using it.
- Or if you do want to keep it please fix the configuration so that re-starting 
the service will work.

Since it seems likely to me that this is a local configuration problem,
rather than a bug in Ubuntu, I'm marking this bug as Incomplete.

If indeed this is a local configuration problem, you can find pointers
to get help for this sort of problem here:
http://www.ubuntu.com/support/community

Or if you believe that this is really a bug, then you may find it
helpful to read "How to report bugs effectively"
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful
if you would then provide a more complete description of the problem,
explain why you believe this is a bug in Ubuntu rather than a problem
specific to your system, and then change the bug status back to New.

** Changed in: openssh (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1907893

Title:
  package openssh-server 1:8.3p1-1 failed to install/upgrade: installed
  openssh-server package post-installation script subprocess returned
  error exit status 1

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  .

  ProblemType: Package
  DistroRelease: Ubuntu 20.10
  Package: openssh-server 1:8.3p1-1
  ProcVersionSignature: Ubuntu 5.8.0-33.36-generic 5.8.17
  Uname: Linux 5.8.0-33-generic x86_64
  ApportVersion: 2.20.11-0ubuntu50.2
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Fri Dec 11 23:16:05 2020
  ErrorMessage: installed openssh-server package post-installation script 
subprocess returned error exit status 1
  InstallationDate: Installed on 2020-12-12 (0 days ago)
  InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022)
  Python3Details: /usr/bin/python3.8, Python 3.8.6, python3-minimal, 
3.8.6-0ubuntu1
  PythonDetails: /usr/bin/python2.7, Python 2.7.18, python-is-python2, 2.7.17-4
  RelatedPackageVersions:
   dpkg 1.20.5ubuntu2
   apt  2.1.10ubuntu0.1
  SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 
255: Missing privilege separation directory: /run/sshd
  SourcePackage: openssh
  Title: package openssh-server 1:8.3p1-1 failed to install/upgrade: installed 
openssh-server package post-installation script subprocess returned error exit 
status 1
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1907893/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1907893] Re: package openssh-server 1:8.3p1-1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1

2020-12-13 Thread Christian Ehrhardt
Hi Marcus,
from your log:
  error: Bind to port 22 on :: failed: Address already in use.
  fatal: Cannot bind any address

This indicates that some local configuration causes another service to run and 
bind port 22 which blocks sshd from (re-)starting.
Sshd itself (the one of the package) would not block itself as it is restarted, 
but anything else on that port will.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1907893

Title:
  package openssh-server 1:8.3p1-1 failed to install/upgrade: installed
  openssh-server package post-installation script subprocess returned
  error exit status 1

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  .

  ProblemType: Package
  DistroRelease: Ubuntu 20.10
  Package: openssh-server 1:8.3p1-1
  ProcVersionSignature: Ubuntu 5.8.0-33.36-generic 5.8.17
  Uname: Linux 5.8.0-33-generic x86_64
  ApportVersion: 2.20.11-0ubuntu50.2
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Fri Dec 11 23:16:05 2020
  ErrorMessage: installed openssh-server package post-installation script 
subprocess returned error exit status 1
  InstallationDate: Installed on 2020-12-12 (0 days ago)
  InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022)
  Python3Details: /usr/bin/python3.8, Python 3.8.6, python3-minimal, 
3.8.6-0ubuntu1
  PythonDetails: /usr/bin/python2.7, Python 2.7.18, python-is-python2, 2.7.17-4
  RelatedPackageVersions:
   dpkg 1.20.5ubuntu2
   apt  2.1.10ubuntu0.1
  SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 
255: Missing privilege separation directory: /run/sshd
  SourcePackage: openssh
  Title: package openssh-server 1:8.3p1-1 failed to install/upgrade: installed 
openssh-server package post-installation script subprocess returned error exit 
status 1
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1907893/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1907789] [NEW] 2.35.50 breaks ld -no-pie

2020-12-11 Thread Christian Ehrhardt
Public bug reported:

The qemu build reaches (and always did) a step where it tries to link some
img files. That is done via the command:
  $ ld -m elf_i386 -T /<>/pc-bios/optionrom//flat.lds -no-pie -s 
-o multiboot.img multiboot.o

Recently that still works in Debian [1] but no more in Ubuntu [2].

I think that the new binutils broke me.
In hirsute proposed those are at 2.35.50.20201210-0ubuntu1

The issue is easily isolated, and by copying the two files around I
found the following:

Hirsute: 2.35.50.20201210-0ubuntu1 - bad
Hirsute: 2.35.50.20201207-0ubuntu1 - bad
Sid: 2.35.1-4  - good
Groovy:  2.35.1-1ubuntu1   - good
Focal:   2.34-6ubuntu1 - good

I'll attach these two files to the bug, just thro them into a directory and
run the command:
 $ ld -m elf_i386 -T ./flat.lds -no-pie -s -o linuxboot.img linuxboot.o

If that is an intentional change please guide how this is now supposed
to work.

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A5.2%2Bdfsg-2=1607598738=1
[2]: 
https://launchpadlibrarian.net/510801929/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILD

** Affects: binutils (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1907789

Title:
  2.35.50 breaks ld -no-pie

Status in binutils package in Ubuntu:
  New

Bug description:
  The qemu build reaches (and always did) a step where it tries to link some
  img files. That is done via the command:
$ ld -m elf_i386 -T /<>/pc-bios/optionrom//flat.lds -no-pie -s 
-o multiboot.img multiboot.o

  Recently that still works in Debian [1] but no more in Ubuntu [2].

  I think that the new binutils broke me.
  In hirsute proposed those are at 2.35.50.20201210-0ubuntu1

  The issue is easily isolated, and by copying the two files around I
  found the following:

  Hirsute: 2.35.50.20201210-0ubuntu1 - bad
  Hirsute: 2.35.50.20201207-0ubuntu1 - bad
  Sid: 2.35.1-4  - good
  Groovy:  2.35.1-1ubuntu1   - good
  Focal:   2.34-6ubuntu1 - good

  I'll attach these two files to the bug, just thro them into a directory and
  run the command:
   $ ld -m elf_i386 -T ./flat.lds -no-pie -s -o linuxboot.img linuxboot.o

  If that is an intentional change please guide how this is now supposed
  to work.

  [1]: 
https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A5.2%2Bdfsg-2=1607598738=1
  [2]: 
https://launchpadlibrarian.net/510801929/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILD

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1907789/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1907789] Re: 2.35.50 breaks ld -no-pie

2020-12-11 Thread Christian Ehrhardt
** Attachment added: "linuxboot.o - build artifact to re-create the issue"
   
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1907789/+attachment/5442724/+files/linuxboot.o

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1907789

Title:
  2.35.50 breaks ld -no-pie

Status in binutils package in Ubuntu:
  New

Bug description:
  The qemu build reaches (and always did) a step where it tries to link some
  img files. That is done via the command:
$ ld -m elf_i386 -T /<>/pc-bios/optionrom//flat.lds -no-pie -s 
-o multiboot.img multiboot.o

  Recently that still works in Debian [1] but no more in Ubuntu [2].

  I think that the new binutils broke me.
  In hirsute proposed those are at 2.35.50.20201210-0ubuntu1

  The issue is easily isolated, and by copying the two files around I
  found the following:

  Hirsute: 2.35.50.20201210-0ubuntu1 - bad
  Hirsute: 2.35.50.20201207-0ubuntu1 - bad
  Sid: 2.35.1-4  - good
  Groovy:  2.35.1-1ubuntu1   - good
  Focal:   2.34-6ubuntu1 - good

  I'll attach these two files to the bug, just thro them into a directory and
  run the command:
   $ ld -m elf_i386 -T ./flat.lds -no-pie -s -o linuxboot.img linuxboot.o

  If that is an intentional change please guide how this is now supposed
  to work.

  [1]: 
https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A5.2%2Bdfsg-2=1607598738=1
  [2]: 
https://launchpadlibrarian.net/510801929/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILD

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1907789/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1907789] Re: 2.35.50 breaks ld -no-pie

2020-12-11 Thread Christian Ehrhardt
** Attachment added: "flat.lds - build artifact to re-create the issue"
   
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1907789/+attachment/5442723/+files/flat.lds

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1907789

Title:
  2.35.50 breaks ld -no-pie

Status in binutils package in Ubuntu:
  New

Bug description:
  The qemu build reaches (and always did) a step where it tries to link some
  img files. That is done via the command:
$ ld -m elf_i386 -T /<>/pc-bios/optionrom//flat.lds -no-pie -s 
-o multiboot.img multiboot.o

  Recently that still works in Debian [1] but no more in Ubuntu [2].

  I think that the new binutils broke me.
  In hirsute proposed those are at 2.35.50.20201210-0ubuntu1

  The issue is easily isolated, and by copying the two files around I
  found the following:

  Hirsute: 2.35.50.20201210-0ubuntu1 - bad
  Hirsute: 2.35.50.20201207-0ubuntu1 - bad
  Sid: 2.35.1-4  - good
  Groovy:  2.35.1-1ubuntu1   - good
  Focal:   2.34-6ubuntu1 - good

  I'll attach these two files to the bug, just thro them into a directory and
  run the command:
   $ ld -m elf_i386 -T ./flat.lds -no-pie -s -o linuxboot.img linuxboot.o

  If that is an intentional change please guide how this is now supposed
  to work.

  [1]: 
https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A5.2%2Bdfsg-2=1607598738=1
  [2]: 
https://launchpadlibrarian.net/510801929/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILD

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1907789/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1906943] Re: package libsasl2-2:i386 2.1.27+dfsg-2 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting configuratio

2020-12-08 Thread Christian Ehrhardt
Hi Alex,
the logs you attached do not hold much more info to debug/analyze your case.
But in general you'd more or less follow the steps mentioned in
=> 
https://askubuntu.com/questions/148715/how-to-fix-package-is-in-a-very-bad-inconsistent-state-error

Could you try those out and see if they help?

** Changed in: cyrus-sasl2 (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu.
https://bugs.launchpad.net/bugs/1906943

Title:
  package libsasl2-2:i386 2.1.27+dfsg-2 failed to install/upgrade:
  package is in a very bad inconsistent state; you should  reinstall it
  before attempting configuration

Status in cyrus-sasl2 package in Ubuntu:
  Incomplete

Bug description:
  Happened during the installation of WineHQ stable

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: libsasl2-2:i386 2.1.27+dfsg-2
  ProcVersionSignature: Ubuntu 5.4.0-56.62-generic 5.4.73
  Uname: Linux 5.4.0-56-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.13
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Sun Dec  6 01:03:26 2020
  ErrorMessage: package is in a very bad inconsistent state; you should  
reinstall it before attempting configuration
  PackageArchitecture: i386
  Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.2ubuntu0.1
  SourcePackage: cyrus-sasl2
  Title: package libsasl2-2:i386 2.1.27+dfsg-2 failed to install/upgrade: 
package is in a very bad inconsistent state; you should  reinstall it before 
attempting configuration
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1906943/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1905790] Re: Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for p11_child

2020-12-03 Thread Christian Ehrhardt
+1 to Timo to not go for "system nssdb" for the cause of this case here.
Also system-wide-trust would be bug 1647285 and is quite a different scope.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ca-certificates in Ubuntu.
https://bugs.launchpad.net/bugs/1905790

Title:
  Make SSSD in 20.04 using OpenSSL and p11-kit (instead of NSS) for
  p11_child

Status in ca-certificates package in Ubuntu:
  New
Status in sssd package in Ubuntu:
  Fix Released
Status in ca-certificates source package in Focal:
  New
Status in sssd source package in Focal:
  New

Bug description:
  [ Impact ]

  SSSD supports in 20.04 two security backends: NSS and OpenSSL
  (speaking in past tense as upstream dropped NSS support completely).

  Those two backends are used for various generic crypto features (so
  they are interchangeable), but also for the management of the PKCS#11
  modules for smart cards.

  In this case, the main problem is that by using NSS it also relies on
  the presence of a "system NSS" database [1] that is something present
  in Fedora and RHEL, but not in ubuntu or generic Linux distributions.

  In order to make SSSD to find a smart card module, we would then need to 
create a such database that mentions a p11kit proxy that will eventually load 
the p11-kit module and then add the card CA certificate to the same DB (see 
more details in [2]).
  And even in such case... It will not work at login phase.

  This is making support for Smart-card based authentication in 20.04
  quite complicated, and hard to implement in professional environments
  (see bug #1865226).

  As per this, recompiling SSSD's p11_child to use OpenSSL (as it
  already happens starting from 20.10) would be enough to make the this
  tool (the one in charge for smartcard authentications and certificate
  matching) to be able to get the smartcard devices from p11-kit allowed
  modules and to check their certificate using CA certificates in the
  ubuntu system ca certificate files (or other configured file).

  One more mayor reason to do this, is also that if we fix 20.04 now to
  use the "proper" method, people who will configure smartcard access
  there via SSSD (not easily possible right now) won't be affected by
  future migrations.

  [ Proposed Implementations ]

  1) Use p11-kit and openssl for p11_child, by changing the build/test system 
(preferred)
     https://salsa.debian.org/3v1n0-guest/sssd/-/commits/p11-kit-p11_child

  2) Build both versions and package things accordingly (hackish)
     https://salsa.debian.org/3v1n0-guest/sssd/-/commits/p11-kit-p11_child-v1

  3) Recompile SSSD completely to use libcrypto as backend

  [ Test case ]

  With a smartcard reader available (and with a card in its slot) as reported 
by:
   $ p11-kit list-modules

  launch:
   $ sudo /usr/libexec/sssd/p11_child --pre -d 10 --debug-fd=2 \
     --nssdb=/etc/ssl/certs/ca-certificates.crt

  The tool should find your card:

  (2020-11-26 21:34:22:020395): [p11_child[100729]] [do_card] (0x4000): Module 
List:
  (2020-11-26 21:34:22:020481): [p11_child[100729]] [do_card] (0x4000): common 
name: [p11-kit-trust].
  (2020-11-26 21:34:22:020497): [p11_child[100729]] [do_card] (0x4000): dll 
name: [/usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so].
  (2020-11-26 21:34:22:020569): [p11_child[100729]] [do_card] (0x4000): 
Description [/etc/ssl/certs/ca-certificates.crt  
PKCS#11 Kit ] Manufacturer [PKCS#11 Kit 
] flags [1] removable [false] token present [true].
  (2020-11-26 21:34:22:020611): [p11_child[100729]] [do_card] (0x4000): common 
name: [opensc-pkcs11].
  (2020-11-26 21:34:22:020646): [p11_child[100729]] [do_card] (0x4000): dll 
name: [/usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so].
  (2020-11-26 21:34:22:025443): [p11_child[100729]] [do_card] (0x4000): 
Description [VMware Virtual USB CCID 00 00   
VMware  ] Manufacturer [VMware  
] flags [7] removable [true] token present [true].
  (2020-11-26 21:34:22:025725): [p11_child[100729]] [do_card] (0x4000): Found 
[MARCO TREVISAN (PIN CNS0)] in slot [VMware Virtual USB CCID 00 00][0] of 
module [1][/usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so].

  Then the tool might fail if the card certificate is not added to the
  ca-certificates.crt, but this is outside the scope of the test case.

  What it matters is that the card is found.

  [ Regression potential ]

  While the change may involve quite different code paths when it comes
  to security features, I think we trust OpenSSL enough to be an
  acceptable crypto backend for PKCS#11 operations. Behavior should not
  change, also assuming that upstream dropped NSS support completely in
  latest release [3], keeping the same functionalities.

  As per a further review of this by xnox [4], we can safely assume that
  SSSD does 

[Touch-packages] [Bug 1904192] Re: ebtables can not rename just created chain

2020-11-30 Thread Christian Ehrhardt
Bfore upgrade:

ubuntu@g-test:~$ sudo ebtables -t nat -N foo
ubuntu@g-test:~$ sudo ebtables -t nat -E foo bar
ebtables v1.8.5 (nf_tables): Chain 'foo' doesn't exists
Try `ebtables -h' or 'ebtables --help' for more information.


Upgrade:
ubuntu@g-test:~$ sudo apt install iptables
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  libip4tc2 libip6tc2 libxtables12
Suggested packages:
  firewalld nftables
The following packages will be upgraded:
  iptables libip4tc2 libip6tc2 libxtables12
4 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
Need to get 498 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 iptables 
amd64 1.8.5-3ubuntu2.20.10.2 [432 kB]
Get:2 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 libxtables12 
amd64 1.8.5-3ubuntu2.20.10.2 [28.7 kB]
Get:3 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 libip6tc2 
amd64 1.8.5-3ubuntu2.20.10.2 [19.1 kB]
Get:4 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 libip4tc2 
amd64 1.8.5-3ubuntu2.20.10.2 [18.7 kB]
Fetched 498 kB in 0s (1465 kB/s)
(Reading database ... 64660 files and directories currently installed.)
Preparing to unpack .../iptables_1.8.5-3ubuntu2.20.10.2_amd64.deb ...
Unpacking iptables (1.8.5-3ubuntu2.20.10.2) over (1.8.5-3ubuntu2.20.10.1) ...
Preparing to unpack .../libxtables12_1.8.5-3ubuntu2.20.10.2_amd64.deb ...
Unpacking libxtables12:amd64 (1.8.5-3ubuntu2.20.10.2) over 
(1.8.5-3ubuntu2.20.10.1) ...
Preparing to unpack .../libip6tc2_1.8.5-3ubuntu2.20.10.2_amd64.deb ...
Unpacking libip6tc2:amd64 (1.8.5-3ubuntu2.20.10.2) over 
(1.8.5-3ubuntu2.20.10.1) ...
Preparing to unpack .../libip4tc2_1.8.5-3ubuntu2.20.10.2_amd64.deb ...
Unpacking libip4tc2:amd64 (1.8.5-3ubuntu2.20.10.2) over 
(1.8.5-3ubuntu2.20.10.1) ...
Setting up libip4tc2:amd64 (1.8.5-3ubuntu2.20.10.2) ...
Setting up libip6tc2:amd64 (1.8.5-3ubuntu2.20.10.2) ...
Setting up libxtables12:amd64 (1.8.5-3ubuntu2.20.10.2) ...
Setting up iptables (1.8.5-3ubuntu2.20.10.2) ...
Processing triggers for man-db (2.9.3-2) ...
Processing triggers for libc-bin (2.32-0ubuntu3) ...

After upgrade
ubuntu@g-test:~$ sudo ebtables -t nat -N foo2
ubuntu@g-test:~$ sudo ebtables -t nat -E foo2 bar


Thanks, setting verified!

** Tags removed: verification-needed verification-needed-groovy
** Tags added: verification-done verification-done-groovy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1904192

Title:
  ebtables can not rename just created chain

Status in iptables:
  Unknown
Status in iptables package in Ubuntu:
  Fix Released
Status in iptables source package in Groovy:
  Fix Committed
Status in iptables source package in Hirsute:
  Fix Released
Status in iptables package in Debian:
  Unknown
Status in iptables package in Fedora:
  Fix Committed

Bug description:
  [SRU]

   * Changes that went into 1.8.5 ave broken the errno handling.
 In particular loading extensions. Due to that it has become
 impossible to rename rules.

   * Upstream has created a fix and this backports that change to
 Ubuntu
 => 
http://git.netfilter.org/iptables/commit/?id=55b7c71dce7144f4dc0297c17abf0f04879ee247

  [Test Case]

   * # ebtables -t nat -N foo
 # ebtables -t nat -E foo bar
 ebtables v1.8.5 (nf_tables): Chain 'foo' doesn't exists

   * with the fix the above command sequence works

  [Where problems could occur]

   * The change moved code from nft_chain_user_rename to do_commandeb and 
 therefore in theory any ebtables/xtables subcommand could be affected.
 Yet what it does is just resetting the error code in a better place, so 
 while it "could" affect every subcommand it should (tm) not do so.
 

  [Other Info]
   
   * n/a

  
  ---

  Hi,
  I have an issue with ebtables that affects libvirt.
  While initially found in hirsute I had to realize this is broken in
  Groovy and even Bionic (might be a different reason back then) as well right 
now.
  But working in Focal (witch matches my memory of it being good before [1]).

  I was isolating the commands that libvirt runs (identical between Focal
  and Hirsute) to find a simplified trigger. Gladly I found one that leaves
  libvirt and other components out of the equation.
  The following works on focal, but fails on the other releases.

  Note: I checked which tool is in use and in both cases it is 
xtables-nft-multi.
  /usr/sbin/ebtables -> /etc/alternatives/ebtables*
  /etc/alternatives/ebtables -> /usr/sbin/ebtables-nft*
  /usr/sbin/ebtables-nft -> xtables-nft-multi*
  So I converted the libvirt issued commands into xtables-nft-multi just to be
  sure in case a system to compare has other alternatives set.

  Focal (Good):
  

[Touch-packages] [Bug 1905735] Re: ubuntu-image autopkgtests failing since pytohn-debian 0.1.38

2020-11-26 Thread Christian Ehrhardt
Seb has opened: 
https://code.launchpad.net/~seb128/ubuntu-image/+git/ubuntu-image/+merge/394533
It is idential to what I build and tested in 
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4353/+packages
If we don't want to wait and retrigger the tests with the new version, here a 
hint: 
https://code.launchpad.net/~paelzer/britney/+git/hints-ubuntu/+merge/394535

** Bug watch added: Debian Bug tracker #975910
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975910

** Also affects: python-debian (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975910
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python-debian in Ubuntu.
https://bugs.launchpad.net/bugs/1905735

Title:
  ubuntu-image autopkgtests failing since python-debian 0.1.38

Status in python-debian package in Ubuntu:
  Triaged
Status in ubuntu-image package in Ubuntu:
  Fix Committed
Status in python-debian package in Debian:
  Unknown

Bug description:
  In the tests it seems that since some - yet to be found - change ~20th
  Nov the tests of ubuntu-image fail.

  Tests all list those three sub-tests as failing:
   unittests.sh FAIL non-zero exit status 1
   qa   FAIL non-zero exit status 1
   coverage.sh  FAIL non-zero exit status 1

  Fails all seem to be related to some python/pytest/py* change that
  might have slipped in without gating on this test.

  Ubuntu-image itself also isn't new - still the same as in groovy
   ubuntu-image | 1.10+20.10ubuntu2 | groovy | source, all
   ubuntu-image | 1.10+20.10ubuntu2 | hirsute| source, all

  == log start 
===
  Obtaining file:///tmp/autopkgtest.ZuL7Da/build.chY/src
  ERROR: Command errored out with exit status 1:
   command: 
/tmp/autopkgtest.ZuL7Da/build.chY/src/.tox/py38-nocov/bin/python -c 'import 
sys, setuptools, tokenize; sys.argv[0] = 
'"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"'; 
__file__='"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"';f=getattr(tokenize,
 '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', 
'"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info 
--egg-base /tmp/pip-pip-egg-info-yaplrymq
   cwd: /tmp/autopkgtest.ZuL7Da/build.chY/src/
  Complete output (5 lines):
  Traceback (most recent call last):
    File "", line 1, in 
    File "/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py", line 49, in 

  __version__ = str(Changelog(infp).get_version())
  AttributeError: 'Changelog' object has no attribute 'get_version'
  
  ERROR: Command errored out with exit status 1: python setup.py egg_info Check 
the logs for full command output.
  === log end 


  The issue reproducible in local KVM-autopkgtest against hirsute-proposed and 
hirsute-release for me (I mistyped before).
  Example:
   sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest --no-built-binaries 
--apt-upgrade --apt-pocket=proposed --shell-fail 
ubuntu-image_1.10+20.10ubuntu2.dsc --testname=qa -- qemu --qemu-options='-cpu 
host' --ram-size=1536 --cpus 2 ~/work/autopkgtest-hirsute-amd64.img

  
  In terms of similar bug signatures I found
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973227
  Fixed by:
  
https://gitlab.kitware.com/debian/dh-cmake/-/commit/3337c8e0e9ebd109490d3c40f0bd5c1e367bedc8

  Looking for the same issue in ubuntu-image has shown an entry in setup.py
    setup.py:49:__version__ = str(Changelog(infp).get_version())

  And now that we know all that we see
  https://launchpad.net/ubuntu/+source/python-debian/+publishinghistory

  New version in since
  2020-11-20 02:23:27 CET

  That is a perfect match to our bug.


  $ diff -Naur python-debian-0.1.3[78]/lib/debian/changelog.py
  ...
  -def get_version(self):
  -# type: () -> Version
  +def _get_version(self):
  +# type: () -> Optional[Version]
   """Return a Version object for the last version"""
  -return self._blocks[0].version
  +return self._blocks[0].version   # type: ignore
  ...

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-debian/+bug/1905735/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1905735] Re: ubuntu-image autopkgtests failing since pytohn-debian 0.1.38

2020-11-26 Thread Christian Ehrhardt
PPA: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4353/
...

killing the rest as I've seen seb128 to do the same ...

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python-debian in Ubuntu.
https://bugs.launchpad.net/bugs/1905735

Title:
  ubuntu-image autopkgtests failing since python-debian 0.1.38

Status in python-debian package in Ubuntu:
  Triaged
Status in ubuntu-image package in Ubuntu:
  Fix Committed
Status in python-debian package in Debian:
  Unknown

Bug description:
  In the tests it seems that since some - yet to be found - change ~20th
  Nov the tests of ubuntu-image fail.

  Tests all list those three sub-tests as failing:
   unittests.sh FAIL non-zero exit status 1
   qa   FAIL non-zero exit status 1
   coverage.sh  FAIL non-zero exit status 1

  Fails all seem to be related to some python/pytest/py* change that
  might have slipped in without gating on this test.

  Ubuntu-image itself also isn't new - still the same as in groovy
   ubuntu-image | 1.10+20.10ubuntu2 | groovy | source, all
   ubuntu-image | 1.10+20.10ubuntu2 | hirsute| source, all

  == log start 
===
  Obtaining file:///tmp/autopkgtest.ZuL7Da/build.chY/src
  ERROR: Command errored out with exit status 1:
   command: 
/tmp/autopkgtest.ZuL7Da/build.chY/src/.tox/py38-nocov/bin/python -c 'import 
sys, setuptools, tokenize; sys.argv[0] = 
'"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"'; 
__file__='"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"';f=getattr(tokenize,
 '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', 
'"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info 
--egg-base /tmp/pip-pip-egg-info-yaplrymq
   cwd: /tmp/autopkgtest.ZuL7Da/build.chY/src/
  Complete output (5 lines):
  Traceback (most recent call last):
    File "", line 1, in 
    File "/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py", line 49, in 

  __version__ = str(Changelog(infp).get_version())
  AttributeError: 'Changelog' object has no attribute 'get_version'
  
  ERROR: Command errored out with exit status 1: python setup.py egg_info Check 
the logs for full command output.
  === log end 


  The issue reproducible in local KVM-autopkgtest against hirsute-proposed and 
hirsute-release for me (I mistyped before).
  Example:
   sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest --no-built-binaries 
--apt-upgrade --apt-pocket=proposed --shell-fail 
ubuntu-image_1.10+20.10ubuntu2.dsc --testname=qa -- qemu --qemu-options='-cpu 
host' --ram-size=1536 --cpus 2 ~/work/autopkgtest-hirsute-amd64.img

  
  In terms of similar bug signatures I found
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973227
  Fixed by:
  
https://gitlab.kitware.com/debian/dh-cmake/-/commit/3337c8e0e9ebd109490d3c40f0bd5c1e367bedc8

  Looking for the same issue in ubuntu-image has shown an entry in setup.py
    setup.py:49:__version__ = str(Changelog(infp).get_version())

  And now that we know all that we see
  https://launchpad.net/ubuntu/+source/python-debian/+publishinghistory

  New version in since
  2020-11-20 02:23:27 CET

  That is a perfect match to our bug.


  $ diff -Naur python-debian-0.1.3[78]/lib/debian/changelog.py
  ...
  -def get_version(self):
  -# type: () -> Version
  +def _get_version(self):
  +# type: () -> Optional[Version]
   """Return a Version object for the last version"""
  -return self._blocks[0].version
  +return self._blocks[0].version   # type: ignore
  ...

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-debian/+bug/1905735/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1905735] Re: ubuntu-image autopkgtests failing since pytohn-debian 0.1.38

2020-11-26 Thread Christian Ehrhardt
** Description changed:

  In the tests it seems that since some - yet to be found - change ~20th
  Nov the tests of ubuntu-image fail.
  
  Tests all list those three sub-tests as failing:
-  unittests.sh FAIL non-zero exit status 1
-  qa   FAIL non-zero exit status 1
-  coverage.sh  FAIL non-zero exit status 1
+  unittests.sh FAIL non-zero exit status 1
+  qa   FAIL non-zero exit status 1
+  coverage.sh  FAIL non-zero exit status 1
  
  Fails all seem to be related to some python/pytest/py* change that might
  have slipped in without gating on this test.
  
  Ubuntu-image itself also isn't new - still the same as in groovy
-  ubuntu-image | 1.10+20.10ubuntu2 | groovy | source, all
-  ubuntu-image | 1.10+20.10ubuntu2 | hirsute| source, all
- 
+  ubuntu-image | 1.10+20.10ubuntu2 | groovy | source, all
+  ubuntu-image | 1.10+20.10ubuntu2 | hirsute| source, all
  
  == log start 
===
  Obtaining file:///tmp/autopkgtest.ZuL7Da/build.chY/src
- ERROR: Command errored out with exit status 1:
-  command: 
/tmp/autopkgtest.ZuL7Da/build.chY/src/.tox/py38-nocov/bin/python -c 'import 
sys, setuptools, tokenize; sys.argv[0] = 
'"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"'; 
__file__='"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"';f=getattr(tokenize,
 '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', 
'"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info 
--egg-base /tmp/pip-pip-egg-info-yaplrymq
-  cwd: /tmp/autopkgtest.ZuL7Da/build.chY/src/
- Complete output (5 lines):
- Traceback (most recent call last):
-   File "", line 1, in 
-   File "/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py", line 49, in 

- __version__ = str(Changelog(infp).get_version())
- AttributeError: 'Changelog' object has no attribute 'get_version'
- 
+ ERROR: Command errored out with exit status 1:
+  command: 
/tmp/autopkgtest.ZuL7Da/build.chY/src/.tox/py38-nocov/bin/python -c 'import 
sys, setuptools, tokenize; sys.argv[0] = 
'"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"'; 
__file__='"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"';f=getattr(tokenize,
 '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', 
'"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info 
--egg-base /tmp/pip-pip-egg-info-yaplrymq
+  cwd: /tmp/autopkgtest.ZuL7Da/build.chY/src/
+ Complete output (5 lines):
+ Traceback (most recent call last):
+   File "", line 1, in 
+   File "/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py", line 49, in 

+ __version__ = str(Changelog(infp).get_version())
+ AttributeError: 'Changelog' object has no attribute 'get_version'
+ 
  ERROR: Command errored out with exit status 1: python setup.py egg_info Check 
the logs for full command output.
  === log end 

  
+ The issue reproducible in local KVM-autopkgtest against hirsute-proposed and 
hirsute-release for me (I mistyped before).
+ Example:
+  sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest --no-built-binaries 
--apt-upgrade --apt-pocket=proposed --shell-fail 
ubuntu-image_1.10+20.10ubuntu2.dsc --testname=qa -- qemu --qemu-options='-cpu 
host' --ram-size=1536 --cpus 2 ~/work/autopkgtest-hirsute-amd64.img
  
- The issue not reproducible in local KVM-autopkgtest against hirsute-proposed 
and hirsute-release for me atm. Which is odd, but could be due to whatever 
python changes that are being all-in/all-out.
  
  In terms of similar bug signatures I found
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973227
  Fixed by:
  
https://gitlab.kitware.com/debian/dh-cmake/-/commit/3337c8e0e9ebd109490d3c40f0bd5c1e367bedc8
  
  Looking for the same issue in ubuntu-image has shown an entry in setup.py
-   setup.py:49:__version__ = str(Changelog(infp).get_version())
+   setup.py:49:__version__ = str(Changelog(infp).get_version())
  
  And now that we know all that we see
  https://launchpad.net/ubuntu/+source/python-debian/+publishinghistory
  
  New version in since
  2020-11-20 02:23:27 CET
  
  That is a perfect match to our bug.
+ 
+ 
+ $ diff -Naur python-debian-0.1.3[78]/lib/debian/changelog.py
+ ...
+ -def get_version(self):
+ -# type: () -> Version
+ +def _get_version(self):
+ +# type: () -> Optional[Version]
+  """Return a Version object for the last version"""
+ -return self._blocks[0].version
+ +return self._blocks[0].version   # type: ignore
+ ...

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python-debian in Ubuntu.

[Touch-packages] [Bug 1905735] [NEW] ubuntu-image autopkgtests failing since pytohn-debian 0.1.38

2020-11-26 Thread Christian Ehrhardt
Public bug reported:

In the tests it seems that since some - yet to be found - change ~20th
Nov the tests of ubuntu-image fail.

Tests all list those three sub-tests as failing:
 unittests.sh FAIL non-zero exit status 1
 qa   FAIL non-zero exit status 1
 coverage.sh  FAIL non-zero exit status 1

Fails all seem to be related to some python/pytest/py* change that might
have slipped in without gating on this test.

Ubuntu-image itself also isn't new - still the same as in groovy
 ubuntu-image | 1.10+20.10ubuntu2 | groovy | source, all
 ubuntu-image | 1.10+20.10ubuntu2 | hirsute| source, all

== log start ===
Obtaining file:///tmp/autopkgtest.ZuL7Da/build.chY/src
ERROR: Command errored out with exit status 1:
 command: /tmp/autopkgtest.ZuL7Da/build.chY/src/.tox/py38-nocov/bin/python 
-c 'import sys, setuptools, tokenize; sys.argv[0] = 
'"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"'; 
__file__='"'"'/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py'"'"';f=getattr(tokenize,
 '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', 
'"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info 
--egg-base /tmp/pip-pip-egg-info-yaplrymq
 cwd: /tmp/autopkgtest.ZuL7Da/build.chY/src/
Complete output (5 lines):
Traceback (most recent call last):
  File "", line 1, in 
  File "/tmp/autopkgtest.ZuL7Da/build.chY/src/setup.py", line 49, in 

__version__ = str(Changelog(infp).get_version())
AttributeError: 'Changelog' object has no attribute 'get_version'

ERROR: Command errored out with exit status 1: python setup.py egg_info Check 
the logs for full command output.
=== log end 

The issue reproducible in local KVM-autopkgtest against hirsute-proposed and 
hirsute-release for me (I mistyped before).
Example:
 sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest --no-built-binaries 
--apt-upgrade --apt-pocket=proposed --shell-fail 
ubuntu-image_1.10+20.10ubuntu2.dsc --testname=qa -- qemu --qemu-options='-cpu 
host' --ram-size=1536 --cpus 2 ~/work/autopkgtest-hirsute-amd64.img


In terms of similar bug signatures I found
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973227
Fixed by:
https://gitlab.kitware.com/debian/dh-cmake/-/commit/3337c8e0e9ebd109490d3c40f0bd5c1e367bedc8

Looking for the same issue in ubuntu-image has shown an entry in setup.py
  setup.py:49:__version__ = str(Changelog(infp).get_version())

And now that we know all that we see
https://launchpad.net/ubuntu/+source/python-debian/+publishinghistory

New version in since
2020-11-20 02:23:27 CET

That is a perfect match to our bug.


$ diff -Naur python-debian-0.1.3[78]/lib/debian/changelog.py
...
-def get_version(self):
-# type: () -> Version
+def _get_version(self):
+# type: () -> Optional[Version]
 """Return a Version object for the last version"""
-return self._blocks[0].version
+return self._blocks[0].version   # type: ignore
...

** Affects: python-debian (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: ubuntu-image (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: update-excuse

** Tags added: update-excuse

** Also affects: python-debian (Ubuntu)
   Importance: Undecided
   Status: New

** Summary changed:

- autopkgtests failing since 20th Nov
+ ubuntu-image autopkgtests failing since pytohn-debian 0.1.38

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python-debian in Ubuntu.
https://bugs.launchpad.net/bugs/1905735

Title:
  ubuntu-image autopkgtests failing since pytohn-debian 0.1.38

Status in python-debian package in Ubuntu:
  New
Status in ubuntu-image package in Ubuntu:
  New

Bug description:
  In the tests it seems that since some - yet to be found - change ~20th
  Nov the tests of ubuntu-image fail.

  Tests all list those three sub-tests as failing:
   unittests.sh FAIL non-zero exit status 1
   qa   FAIL non-zero exit status 1
   coverage.sh  FAIL non-zero exit status 1

  Fails all seem to be related to some python/pytest/py* change that
  might have slipped in without gating on this test.

  Ubuntu-image itself also isn't new - still the same as in groovy
   ubuntu-image | 1.10+20.10ubuntu2 | groovy | source, all
   ubuntu-image | 1.10+20.10ubuntu2 | hirsute| source, all

  == log start 
===
  Obtaining file:///tmp/autopkgtest.ZuL7Da/build.chY/src
  ERROR: Command errored out with exit status 1:
   command: 
/tmp/autopkgtest.ZuL7Da/build.chY/src/.tox/py38-nocov/bin/python -c 'import 
sys, setuptools, tokenize; sys.argv[0] = 

[Touch-packages] [Bug 1904811] Re: package openssh-server 1:8.2p1-4ubuntu0.1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status

2020-11-20 Thread Christian Ehrhardt
Thank you for taking the time to report this bug and helping to make
Ubuntu better.

On upgrading a service this service has to be restarted to pick up the fixes.
Rather rarely a real issue occurs that the newer version does e.g. fail with 
the formerly working configuration.
But most of the time what happens is, that a service was installed, but stays 
unconfigured or experimented with but left in a broken state.

Now on any update of the related packages that service has to be restarted, but 
since its config is incomplete/faulty it fails to restart.
Therefore the update of that package has to consider itself incomplete.

Depending on your particular case there are two solutions:
- either remove the offending package if you don't want to continue using it.
- Or if you do want to keep it please fix the configuration so that re-starting 
the service will work.

Since it seems likely to me that this is a local configuration problem,
rather than a bug in Ubuntu, I'm marking this bug as Incomplete.

If indeed this is a local configuration problem, you can find pointers
to get help for this sort of problem here:
http://www.ubuntu.com/support/community

Or if you believe that this is really a bug, then you may find it
helpful to read "How to report bugs effectively"
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful
if you would then provide a more complete description of the problem,
explain why you believe this is a bug in Ubuntu rather than a problem
specific to your system, and then change the bug status back to New.

** Changed in: openssh (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1904811

Title:
  package openssh-server 1:8.2p1-4ubuntu0.1 failed to install/upgrade:
  installed openssh-server package post-installation script subprocess
  returned error exit status 1

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  ?

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: openssh-server 1:8.2p1-4ubuntu0.1
  ProcVersionSignature: Ubuntu 5.4.0-54.60-generic 5.4.65
  Uname: Linux 5.4.0-54-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu27.12
  AptOrdering:
   openssh-sftp-server:amd64: Install
   openssh-server:amd64: Install
   ssh-import-id:amd64: Install
   NULL: ConfigurePending
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Wed Nov 18 19:09:53 2020
  ErrorMessage: installed openssh-server package post-installation script 
subprocess returned error exit status 1
  InstallationDate: Installed on 2020-11-11 (7 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.2ubuntu0.1
  SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 
255: /etc/ssh/sshd_config line 35: missing argument.
  SourcePackage: openssh
  Title: package openssh-server 1:8.2p1-4ubuntu0.1 failed to install/upgrade: 
installed openssh-server package post-installation script subprocess returned 
error exit status 1
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1904811/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1904811] Re: package openssh-server 1:8.2p1-4ubuntu0.1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status

2020-11-20 Thread Christian Ehrhardt
Hi,
from your log
SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 255: 
/etc/ssh/sshd_config line 35: missing argument.

That means you (or a program) have modified /etc/ssh/sshd_config and due
to that the update (which needs to restart the server) fails. You can
restore the file to its default [1] or fixup that issue in the config
file manually. Then things should work again.

If you are convinced this indeed is a bug in the package we'd need to
see that config file what exactly is at that line 35.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1904811

Title:
  package openssh-server 1:8.2p1-4ubuntu0.1 failed to install/upgrade:
  installed openssh-server package post-installation script subprocess
  returned error exit status 1

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  ?

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: openssh-server 1:8.2p1-4ubuntu0.1
  ProcVersionSignature: Ubuntu 5.4.0-54.60-generic 5.4.65
  Uname: Linux 5.4.0-54-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu27.12
  AptOrdering:
   openssh-sftp-server:amd64: Install
   openssh-server:amd64: Install
   ssh-import-id:amd64: Install
   NULL: ConfigurePending
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Wed Nov 18 19:09:53 2020
  ErrorMessage: installed openssh-server package post-installation script 
subprocess returned error exit status 1
  InstallationDate: Installed on 2020-11-11 (7 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.2ubuntu0.1
  SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 
255: /etc/ssh/sshd_config line 35: missing argument.
  SourcePackage: openssh
  Title: package openssh-server 1:8.2p1-4ubuntu0.1 failed to install/upgrade: 
installed openssh-server package post-installation script subprocess returned 
error exit status 1
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1904811/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1904192] Re: ebtables can not rename just created chain

2020-11-17 Thread Christian Ehrhardt
** Bug watch added: Debian Bug tracker #975028
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975028

** Also affects: iptables (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975028
   Importance: Unknown
   Status: Unknown

** Changed in: iptables (Ubuntu Groovy)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1904192

Title:
  ebtables can not rename just created chain

Status in iptables:
  Unknown
Status in iptables package in Ubuntu:
  Confirmed
Status in iptables source package in Groovy:
  In Progress
Status in iptables package in Debian:
  Unknown
Status in iptables package in Fedora:
  Confirmed

Bug description:
  [SRU]

   * Changes that went into 1.8.5 ave broken the errno handling.
 In particular loading extensions. Due to that it has become
 impossible to rename rules.

   * Upstream has created a fix and this backports that change to
 Ubuntu
 => 
http://git.netfilter.org/iptables/commit/?id=55b7c71dce7144f4dc0297c17abf0f04879ee247

  [Test Case]

   * # ebtables -t nat -N foo
 # ebtables -t nat -E foo bar
 ebtables v1.8.5 (nf_tables): Chain 'foo' doesn't exists

   * with the fix the above command sequence works

  [Where problems could occur]

   * The change moved code from nft_chain_user_rename to do_commandeb and 
 therefore in theory any ebtables/xtables subcommand could be affected.
 Yet what it does is just resetting the error code in a better place, so 
 while it "could" affect every subcommand it should (tm) not do so.
 

  [Other Info]
   
   * n/a

  
  ---

  Hi,
  I have an issue with ebtables that affects libvirt.
  While initially found in hirsute I had to realize this is broken in
  Groovy and even Bionic (might be a different reason back then) as well right 
now.
  But working in Focal (witch matches my memory of it being good before [1]).

  I was isolating the commands that libvirt runs (identical between Focal
  and Hirsute) to find a simplified trigger. Gladly I found one that leaves
  libvirt and other components out of the equation.
  The following works on focal, but fails on the other releases.

  Note: I checked which tool is in use and in both cases it is 
xtables-nft-multi.
  /usr/sbin/ebtables -> /etc/alternatives/ebtables*
  /etc/alternatives/ebtables -> /usr/sbin/ebtables-nft*
  /usr/sbin/ebtables-nft -> xtables-nft-multi*
  So I converted the libvirt issued commands into xtables-nft-multi just to be
  sure in case a system to compare has other alternatives set.

  Focal (Good):
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 
testrule3-renamed
  

  Groovy/Hirsute (Fail):
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 
testrule3-renamed
  ebtables v1.8.5 (nf_tables): Chain 'testrule3' doesn't exists
  Try `ebtables -h' or 'ebtables --help' for more information.

  What might be the root cause for this?

  -- Old test instructions --

  As I said I was tracking a fail in libvirt so the test instructions initially
  were around that:

  # the following us done as 2nd level guest (to not mess with the host,
  # but works on bare metal jst as much)
  uvt-kvm create --host-passthrough --memory 2048 --cpu 4 --disk 16 
--password=ubuntu hirsute-kvm release=hirsute arch=amd64 label=daily
  # On guest then

  sudo apt update
  sudo apt install uvtool uvtool-libvirt
  uvt-simplestreams-libvirt --verbose sync --source 
http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=hirsute
  uvt-kvm create --disk 5 --machine-type ubuntu --password=ubuntu 
hirsute-2nd-lvm release=hirsute arch=amd64 label=daily
  uvt-kvm wait hirsute-2nd-lvm
  virsh shutdown hirsute-2nd-lvm
  virsh edit hirsute-2nd-lvm
  # add this to the network
    
  
    
  virsh start hirsute-2nd-lvm
    error: Failed to start domain hirsute-2nd-nwfilter
    error: internal error: applyDHCPOnlyRules failed - spoofing not protected!

  FYI: Get helpful log details with these in /etc/libvirt/libvirtd.conf
  log_filters="1:util.firewall"
  log_outputs="1:syslog:libvirtd"

  -- --

  [1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037

To manage notifications about this bug go to:
https://bugs.launchpad.net/iptables/+bug/1904192/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1904192] Re: ebtables can not rename just created chain

2020-11-17 Thread Christian Ehrhardt
The issue was confirmed and a fix now committed to the upstream repository.
=> 
http://git.netfilter.org/iptables/commit/?id=55b7c71dce7144f4dc0297c17abf0f04879ee247

@Alex will you (as usual) do the upload of that - will eventually be
Groovy and Hirsute that needs this.

** Also affects: iptables (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Description changed:

+ [SRU]
+ 
+  * Changes that went into 1.8.5 ave broken the errno handling.
+In particular loading extensions. Due to that it has become
+impossible to rename rules.
+ 
+  * Upstream has created a fix and this backports that change to
+Ubuntu
+=> 
http://git.netfilter.org/iptables/commit/?id=55b7c71dce7144f4dc0297c17abf0f04879ee247
+ 
+ [Test Case]
+ 
+  * # ebtables -t nat -N foo
+# ebtables -t nat -E foo bar
+ebtables v1.8.5 (nf_tables): Chain 'foo' doesn't exists
+ 
+  * with the fix the above command sequence works
+ 
+ [Where problems could occur]
+ 
+  * The change moved code from nft_chain_user_rename to do_commandeb and 
+therefore in theory any ebtables/xtables subcommand could be affected.
+Yet what it does is just resetting the error code in a better place, so 
+while it "could" affect every subcommand it should (tm) not do so.
+
+ 
+ [Other Info]
+  
+  * n/a
+ 
+ 
+ ---
+ 
  Hi,
  I have an issue with ebtables that affects libvirt.
  While initially found in hirsute I had to realize this is broken in
  Groovy and even Bionic (might be a different reason back then) as well right 
now.
  But working in Focal (witch matches my memory of it being good before [1]).
  
  I was isolating the commands that libvirt runs (identical between Focal
  and Hirsute) to find a simplified trigger. Gladly I found one that leaves
  libvirt and other components out of the equation.
  The following works on focal, but fails on the other releases.
  
  Note: I checked which tool is in use and in both cases it is 
xtables-nft-multi.
  /usr/sbin/ebtables -> /etc/alternatives/ebtables*
  /etc/alternatives/ebtables -> /usr/sbin/ebtables-nft*
  /usr/sbin/ebtables-nft -> xtables-nft-multi*
  So I converted the libvirt issued commands into xtables-nft-multi just to be
  sure in case a system to compare has other alternatives set.
  
  Focal (Good):
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 
testrule3-renamed
  
  
  Groovy/Hirsute (Fail):
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 
testrule3-renamed
  ebtables v1.8.5 (nf_tables): Chain 'testrule3' doesn't exists
  Try `ebtables -h' or 'ebtables --help' for more information.
  
  What might be the root cause for this?
  
- 
  -- Old test instructions --
  
  As I said I was tracking a fail in libvirt so the test instructions initially
  were around that:
- 
  
  # the following us done as 2nd level guest (to not mess with the host,
  # but works on bare metal jst as much)
  uvt-kvm create --host-passthrough --memory 2048 --cpu 4 --disk 16 
--password=ubuntu hirsute-kvm release=hirsute arch=amd64 label=daily
  # On guest then
  
  sudo apt update
  sudo apt install uvtool uvtool-libvirt
  uvt-simplestreams-libvirt --verbose sync --source 
http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=hirsute
  uvt-kvm create --disk 5 --machine-type ubuntu --password=ubuntu 
hirsute-2nd-lvm release=hirsute arch=amd64 label=daily
  uvt-kvm wait hirsute-2nd-lvm
  virsh shutdown hirsute-2nd-lvm
  virsh edit hirsute-2nd-lvm
  # add this to the network
-   
- 
-   
+   
+ 
+   
  virsh start hirsute-2nd-lvm
-   error: Failed to start domain hirsute-2nd-nwfilter
-   error: internal error: applyDHCPOnlyRules failed - spoofing not protected!
+   error: Failed to start domain hirsute-2nd-nwfilter
+   error: internal error: applyDHCPOnlyRules failed - spoofing not protected!
  
  FYI: Get helpful log details with these in /etc/libvirt/libvirtd.conf
  log_filters="1:util.firewall"
  log_outputs="1:syslog:libvirtd"
  
  -- --
  
  [1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1904192

Title:
  ebtables can not rename just created chain

Status in iptables:
  Unknown
Status in iptables package in Ubuntu:
  Confirmed
Status in iptables source package in Groovy:
  New
Status in iptables package in Fedora:
  Confirmed

Bug description:
  [SRU]

   * Changes that went into 1.8.5 ave broken the errno handling.
 In particular loading extensions. Due to that it has become
 impossible to rename rules.

   * Upstream has created a fix and this backports that change to
 Ubuntu
 => 

[Touch-packages] [Bug 1903484] Re: package python-six 1.14.0-2 failed to install/upgrade: installed python-six package post-installation script subprocess returned error exit status 127

2020-11-17 Thread Christian Ehrhardt
>From your log:
  /var/lib/dpkg/info/python-six.postinst: 6: pycompile: not found

The missing binary pycompile is of pkg:python2

And python-six in Focal has:
  Depends: python2:any (<< 2.8), python2:any (>= 2.7~)

According to your log you should have python2-minimal:amd64 2.7.17-2ubuntu4
Which provides the missing binary.

So everything should work, but it didn't.

Could you check the following things on your system:
# which pycompile
/usr/bin/pycompile
# dpkg --verify python2
# dpkg -S pycompile
...
python2-minimal: /usr/bin/pycompile
# ll /usr/bin/pycompile
-rwxr-xr-x 1 root root 11895 Mar 13  2020 /usr/bin/pycompile*

If your output is different that might be an indicator what is wrong.
But with the logs so far I fail to see the root cause.

** Changed in: six (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to six in Ubuntu.
https://bugs.launchpad.net/bugs/1903484

Title:
  package python-six 1.14.0-2 failed to install/upgrade: installed
  python-six package post-installation script subprocess returned error
  exit status 127

Status in six package in Ubuntu:
  Incomplete

Bug description:
  Plz fix this bug

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: python-six 1.14.0-2
  ProcVersionSignature: Ubuntu 5.4.0-52.57-generic 5.4.65
  Uname: Linux 5.4.0-52-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.11
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Thu Nov  5 21:00:52 2020
  Dependencies:
   
  DuplicateSignature:
   package:python-six:1.14.0-2
   Setting up python-six (1.14.0-2) ...
   /var/lib/dpkg/info/python-six.postinst: 6: pycompile: not found
   dpkg: error processing package python-six (--configure):
installed python-six package post-installation script subprocess returned 
error exit status 127
  ErrorMessage: installed python-six package post-installation script 
subprocess returned error exit status 127
  InstallationDate: Installed on 2020-10-22 (17 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  PackageArchitecture: all
  Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.2ubuntu0.1
  SourcePackage: six
  Title: package python-six 1.14.0-2 failed to install/upgrade: installed 
python-six package post-installation script subprocess returned error exit 
status 127
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/six/+bug/1903484/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1903484] Re: package python-six 1.14.0-2 failed to install/upgrade: installed python-six package post-installation script subprocess returned error exit status 127

2020-11-17 Thread Christian Ehrhardt
Forgot, also:
dpkg --verify python2-minimal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to six in Ubuntu.
https://bugs.launchpad.net/bugs/1903484

Title:
  package python-six 1.14.0-2 failed to install/upgrade: installed
  python-six package post-installation script subprocess returned error
  exit status 127

Status in six package in Ubuntu:
  Incomplete

Bug description:
  Plz fix this bug

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: python-six 1.14.0-2
  ProcVersionSignature: Ubuntu 5.4.0-52.57-generic 5.4.65
  Uname: Linux 5.4.0-52-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.11
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Thu Nov  5 21:00:52 2020
  Dependencies:
   
  DuplicateSignature:
   package:python-six:1.14.0-2
   Setting up python-six (1.14.0-2) ...
   /var/lib/dpkg/info/python-six.postinst: 6: pycompile: not found
   dpkg: error processing package python-six (--configure):
installed python-six package post-installation script subprocess returned 
error exit status 127
  ErrorMessage: installed python-six package post-installation script 
subprocess returned error exit status 127
  InstallationDate: Installed on 2020-10-22 (17 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  PackageArchitecture: all
  Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.2ubuntu0.1
  SourcePackage: six
  Title: package python-six 1.14.0-2 failed to install/upgrade: installed 
python-six package post-installation script subprocess returned error exit 
status 127
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/six/+bug/1903484/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1904192] Re: ebtables can not rename just created chain

2020-11-16 Thread Christian Ehrhardt
** Bug watch added: Red Hat Bugzilla #1898130
   https://bugzilla.redhat.com/show_bug.cgi?id=1898130

** Also affects: iptables (Fedora) via
   https://bugzilla.redhat.com/show_bug.cgi?id=1898130
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1904192

Title:
  ebtables can not rename just created chain

Status in iptables:
  Unknown
Status in iptables package in Ubuntu:
  Confirmed
Status in iptables package in Fedora:
  Unknown

Bug description:
  Hi,
  I have an issue with ebtables that affects libvirt.
  While initially found in hirsute I had to realize this is broken in
  Groovy and even Bionic (might be a different reason back then) as well right 
now.
  But working in Focal (witch matches my memory of it being good before [1]).

  I was isolating the commands that libvirt runs (identical between Focal
  and Hirsute) to find a simplified trigger. Gladly I found one that leaves
  libvirt and other components out of the equation.
  The following works on focal, but fails on the other releases.

  Note: I checked which tool is in use and in both cases it is 
xtables-nft-multi.
  /usr/sbin/ebtables -> /etc/alternatives/ebtables*
  /etc/alternatives/ebtables -> /usr/sbin/ebtables-nft*
  /usr/sbin/ebtables-nft -> xtables-nft-multi*
  So I converted the libvirt issued commands into xtables-nft-multi just to be
  sure in case a system to compare has other alternatives set.

  Focal (Good):
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 
testrule3-renamed
  

  Groovy/Hirsute (Fail):
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 
testrule3-renamed
  ebtables v1.8.5 (nf_tables): Chain 'testrule3' doesn't exists
  Try `ebtables -h' or 'ebtables --help' for more information.

  What might be the root cause for this?


  -- Old test instructions --

  As I said I was tracking a fail in libvirt so the test instructions initially
  were around that:

  
  # the following us done as 2nd level guest (to not mess with the host,
  # but works on bare metal jst as much)
  uvt-kvm create --host-passthrough --memory 2048 --cpu 4 --disk 16 
--password=ubuntu hirsute-kvm release=hirsute arch=amd64 label=daily
  # On guest then

  sudo apt update
  sudo apt install uvtool uvtool-libvirt
  uvt-simplestreams-libvirt --verbose sync --source 
http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=hirsute
  uvt-kvm create --disk 5 --machine-type ubuntu --password=ubuntu 
hirsute-2nd-lvm release=hirsute arch=amd64 label=daily
  uvt-kvm wait hirsute-2nd-lvm
  virsh shutdown hirsute-2nd-lvm
  virsh edit hirsute-2nd-lvm
  # add this to the network

  

  virsh start hirsute-2nd-lvm
error: Failed to start domain hirsute-2nd-nwfilter
error: internal error: applyDHCPOnlyRules failed - spoofing not protected!

  FYI: Get helpful log details with these in /etc/libvirt/libvirtd.conf
  log_filters="1:util.firewall"
  log_outputs="1:syslog:libvirtd"

  -- --

  [1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037

To manage notifications about this bug go to:
https://bugs.launchpad.net/iptables/+bug/1904192/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1904192] Re: ebtables can not rename just created chain

2020-11-16 Thread Christian Ehrhardt
FYI: via the libvirt discussion it was reported that
- legacy 2.0.11 works on fedora (for us as well on Ubuntu)
- 1.8.4 works on RHEL8 (we have 1.8.5 that fails)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1904192

Title:
  ebtables can not rename just created chain

Status in iptables:
  Unknown
Status in iptables package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  I have an issue with ebtables that affects libvirt.
  While initially found in hirsute I had to realize this is broken in
  Groovy and even Bionic (might be a different reason back then) as well right 
now.
  But working in Focal (witch matches my memory of it being good before [1]).

  I was isolating the commands that libvirt runs (identical between Focal
  and Hirsute) to find a simplified trigger. Gladly I found one that leaves
  libvirt and other components out of the equation.
  The following works on focal, but fails on the other releases.

  Note: I checked which tool is in use and in both cases it is 
xtables-nft-multi.
  /usr/sbin/ebtables -> /etc/alternatives/ebtables*
  /etc/alternatives/ebtables -> /usr/sbin/ebtables-nft*
  /usr/sbin/ebtables-nft -> xtables-nft-multi*
  So I converted the libvirt issued commands into xtables-nft-multi just to be
  sure in case a system to compare has other alternatives set.

  Focal (Good):
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 
testrule3-renamed
  

  Groovy/Hirsute (Fail):
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 
testrule3-renamed
  ebtables v1.8.5 (nf_tables): Chain 'testrule3' doesn't exists
  Try `ebtables -h' or 'ebtables --help' for more information.

  What might be the root cause for this?


  -- Old test instructions --

  As I said I was tracking a fail in libvirt so the test instructions initially
  were around that:

  
  # the following us done as 2nd level guest (to not mess with the host,
  # but works on bare metal jst as much)
  uvt-kvm create --host-passthrough --memory 2048 --cpu 4 --disk 16 
--password=ubuntu hirsute-kvm release=hirsute arch=amd64 label=daily
  # On guest then

  sudo apt update
  sudo apt install uvtool uvtool-libvirt
  uvt-simplestreams-libvirt --verbose sync --source 
http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=hirsute
  uvt-kvm create --disk 5 --machine-type ubuntu --password=ubuntu 
hirsute-2nd-lvm release=hirsute arch=amd64 label=daily
  uvt-kvm wait hirsute-2nd-lvm
  virsh shutdown hirsute-2nd-lvm
  virsh edit hirsute-2nd-lvm
  # add this to the network

  

  virsh start hirsute-2nd-lvm
error: Failed to start domain hirsute-2nd-nwfilter
error: internal error: applyDHCPOnlyRules failed - spoofing not protected!

  FYI: Get helpful log details with these in /etc/libvirt/libvirtd.conf
  log_filters="1:util.firewall"
  log_outputs="1:syslog:libvirtd"

  -- --

  [1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037

To manage notifications about this bug go to:
https://bugs.launchpad.net/iptables/+bug/1904192/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1904192] Re: ebtables can not rename just created chain

2020-11-15 Thread Christian Ehrhardt
FYI
Since I started on this with libvirt and the libvirt people were helpful as 
always in debugging this I also pinged the ML since this issue should affect 
libvirt in any place where it runs with the new ebtables.
https://www.redhat.com/archives/libvir-list/2020-November/msg00790.html


@Oibaf - thanks for reporting this upstream. Does it affect you in another 
use-case/context than libvirt?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1904192

Title:
  ebtables can not rename just created chain

Status in iptables:
  Unknown
Status in iptables package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  I have an issue with ebtables that affects libvirt.
  While initially found in hirsute I had to realize this is broken in
  Groovy and even Bionic (might be a different reason back then) as well right 
now.
  But working in Focal (witch matches my memory of it being good before [1]).

  I was isolating the commands that libvirt runs (identical between Focal
  and Hirsute) to find a simplified trigger. Gladly I found one that leaves
  libvirt and other components out of the equation.
  The following works on focal, but fails on the other releases.

  Note: I checked which tool is in use and in both cases it is 
xtables-nft-multi.
  /usr/sbin/ebtables -> /etc/alternatives/ebtables*
  /etc/alternatives/ebtables -> /usr/sbin/ebtables-nft*
  /usr/sbin/ebtables-nft -> xtables-nft-multi*
  So I converted the libvirt issued commands into xtables-nft-multi just to be
  sure in case a system to compare has other alternatives set.

  Focal (Good):
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 
testrule3-renamed
  

  Groovy/Hirsute (Fail):
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 
testrule3-renamed
  ebtables v1.8.5 (nf_tables): Chain 'testrule3' doesn't exists
  Try `ebtables -h' or 'ebtables --help' for more information.

  What might be the root cause for this?


  -- Old test instructions --

  As I said I was tracking a fail in libvirt so the test instructions initially
  were around that:

  
  # the following us done as 2nd level guest (to not mess with the host,
  # but works on bare metal jst as much)
  uvt-kvm create --host-passthrough --memory 2048 --cpu 4 --disk 16 
--password=ubuntu hirsute-kvm release=hirsute arch=amd64 label=daily
  # On guest then

  sudo apt update
  sudo apt install uvtool uvtool-libvirt
  uvt-simplestreams-libvirt --verbose sync --source 
http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=hirsute
  uvt-kvm create --disk 5 --machine-type ubuntu --password=ubuntu 
hirsute-2nd-lvm release=hirsute arch=amd64 label=daily
  uvt-kvm wait hirsute-2nd-lvm
  virsh shutdown hirsute-2nd-lvm
  virsh edit hirsute-2nd-lvm
  # add this to the network

  

  virsh start hirsute-2nd-lvm
error: Failed to start domain hirsute-2nd-nwfilter
error: internal error: applyDHCPOnlyRules failed - spoofing not protected!

  FYI: Get helpful log details with these in /etc/libvirt/libvirtd.conf
  log_filters="1:util.firewall"
  log_outputs="1:syslog:libvirtd"

  -- --

  [1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037

To manage notifications about this bug go to:
https://bugs.launchpad.net/iptables/+bug/1904192/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1904192] [NEW] ebtables can not rename just created chain

2020-11-13 Thread Christian Ehrhardt
Public bug reported:

Hi,
I have an issue with ebtables that affects libvirt.
While initially found in hirsute I had to realize this is broken in
Groovy and even Bionic (might be a different reason back then) as well right 
now.
But working in Focal (witch matches my memory of it being good before [1]).

I was isolating the commands that libvirt runs (identical between Focal
and Hirsute) to find a simplified trigger. Gladly I found one that leaves
libvirt and other components out of the equation.
The following works on focal, but fails on the other releases.

Note: I checked which tool is in use and in both cases it is xtables-nft-multi.
/usr/sbin/ebtables -> /etc/alternatives/ebtables*
/etc/alternatives/ebtables -> /usr/sbin/ebtables-nft*
/usr/sbin/ebtables-nft -> xtables-nft-multi*
So I converted the libvirt issued commands into xtables-nft-multi just to be
sure in case a system to compare has other alternatives set.

Focal (Good):
/usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
/usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 
testrule3-renamed


Groovy/Hirsute (Fail):
/usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
/usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 
testrule3-renamed
ebtables v1.8.5 (nf_tables): Chain 'testrule3' doesn't exists
Try `ebtables -h' or 'ebtables --help' for more information.

What might be the root cause for this?


-- Old test instructions --

As I said I was tracking a fail in libvirt so the test instructions initially
were around that:


# the following us done as 2nd level guest (to not mess with the host,
# but works on bare metal jst as much)
uvt-kvm create --host-passthrough --memory 2048 --cpu 4 --disk 16 
--password=ubuntu hirsute-kvm release=hirsute arch=amd64 label=daily
# On guest then

sudo apt update
sudo apt install uvtool uvtool-libvirt
uvt-simplestreams-libvirt --verbose sync --source 
http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=hirsute
uvt-kvm create --disk 5 --machine-type ubuntu --password=ubuntu hirsute-2nd-lvm 
release=hirsute arch=amd64 label=daily
uvt-kvm wait hirsute-2nd-lvm
virsh shutdown hirsute-2nd-lvm
virsh edit hirsute-2nd-lvm
# add this to the network
  

  
virsh start hirsute-2nd-lvm
  error: Failed to start domain hirsute-2nd-nwfilter
  error: internal error: applyDHCPOnlyRules failed - spoofing not protected!

FYI: Get helpful log details with these in /etc/libvirt/libvirtd.conf
log_filters="1:util.firewall"
log_outputs="1:syslog:libvirtd"

-- --

[1]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037

** Affects: iptables (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1904192

Title:
  ebtables can not rename just created chain

Status in iptables package in Ubuntu:
  New

Bug description:
  Hi,
  I have an issue with ebtables that affects libvirt.
  While initially found in hirsute I had to realize this is broken in
  Groovy and even Bionic (might be a different reason back then) as well right 
now.
  But working in Focal (witch matches my memory of it being good before [1]).

  I was isolating the commands that libvirt runs (identical between Focal
  and Hirsute) to find a simplified trigger. Gladly I found one that leaves
  libvirt and other components out of the equation.
  The following works on focal, but fails on the other releases.

  Note: I checked which tool is in use and in both cases it is 
xtables-nft-multi.
  /usr/sbin/ebtables -> /etc/alternatives/ebtables*
  /etc/alternatives/ebtables -> /usr/sbin/ebtables-nft*
  /usr/sbin/ebtables-nft -> xtables-nft-multi*
  So I converted the libvirt issued commands into xtables-nft-multi just to be
  sure in case a system to compare has other alternatives set.

  Focal (Good):
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 
testrule3-renamed
  

  Groovy/Hirsute (Fail):
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -N testrule3
  /usr/sbin/xtables-nft-multi ebtables --concurrent -t nat -E testrule3 
testrule3-renamed
  ebtables v1.8.5 (nf_tables): Chain 'testrule3' doesn't exists
  Try `ebtables -h' or 'ebtables --help' for more information.

  What might be the root cause for this?


  -- Old test instructions --

  As I said I was tracking a fail in libvirt so the test instructions initially
  were around that:

  
  # the following us done as 2nd level guest (to not mess with the host,
  # but works on bare metal jst as much)
  uvt-kvm create --host-passthrough --memory 2048 --cpu 4 --disk 16 
--password=ubuntu hirsute-kvm release=hirsute arch=amd64 label=daily
  # On guest then

  sudo apt update
  sudo apt install uvtool uvtool-libvirt
  

[Touch-packages] [Bug 1902540] Re: hirsute fails on add-apt-repository

2020-11-06 Thread Christian Ehrhardt
Fixed by https://launchpad.net/ubuntu/+source/python-apt/2.1.3ubuntu3
migrating after some work on dependencies.

Note cloud and lxd images do not yet contain this, so you'll need to
update before add-apt-repository or wait another day or two.

Thanks everyone.

** Changed in: python-apt (Ubuntu)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python-apt in Ubuntu.
https://bugs.launchpad.net/bugs/1902540

Title:
  hirsute fails on add-apt-repository

Status in python-apt package in Ubuntu:
  Fix Released
Status in software-properties package in Ubuntu:
  Invalid

Bug description:
  On a fully updated hirsute add-apt-repository fails, example:

  root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321
  Traceback (most recent call last):
File "/usr/bin/add-apt-repository", line 330, in 
  addaptrepo = AddAptRepository()
File "/usr/bin/add-apt-repository", line 35, in __init__
  self.distro.get_sources(self.sourceslist)
File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in 
get_sources
  raise NoDistroTemplateException(
  aptsources.distro.NoDistroTemplateException: Error: could not find a 
distribution template for Ubuntu/hirsute

  The PPA seems not to matter (all trigger it) and if I manually add PPA
  sources list and GPG key it works. So maybe software-properties just
  needs to learn about hirsute?

  Or is there another components (like distro-info or such) that needs a
  bump for this to work?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1902540/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1902540] Re: hirsute fails on add-apt-repository

2020-11-03 Thread Christian Ehrhardt
FYI - Until this migrated into groovy the quick-fix with the attached diff is:
$ wget -q https://launchpadlibrarian.net/505009270/fix-hirsute-python-apt.diff 
-O - | sudo patch -p1

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python-apt in Ubuntu.
https://bugs.launchpad.net/bugs/1902540

Title:
  hirsute fails on add-apt-repository

Status in python-apt package in Ubuntu:
  Triaged
Status in software-properties package in Ubuntu:
  Invalid

Bug description:
  On a fully updated hirsute add-apt-repository fails, example:

  root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321
  Traceback (most recent call last):
File "/usr/bin/add-apt-repository", line 330, in 
  addaptrepo = AddAptRepository()
File "/usr/bin/add-apt-repository", line 35, in __init__
  self.distro.get_sources(self.sourceslist)
File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in 
get_sources
  raise NoDistroTemplateException(
  aptsources.distro.NoDistroTemplateException: Error: could not find a 
distribution template for Ubuntu/hirsute

  The PPA seems not to matter (all trigger it) and if I manually add PPA
  sources list and GPG key it works. So maybe software-properties just
  needs to learn about hirsute?

  Or is there another components (like distro-info or such) that needs a
  bump for this to work?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1902540/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1902540] Re: hirsute fails on add-apt-repository

2020-11-03 Thread Christian Ehrhardt
** Changed in: python-apt (Ubuntu)
 Assignee: Steve Langasek (vorlon) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python-apt in Ubuntu.
https://bugs.launchpad.net/bugs/1902540

Title:
  hirsute fails on add-apt-repository

Status in python-apt package in Ubuntu:
  Triaged
Status in software-properties package in Ubuntu:
  Invalid

Bug description:
  On a fully updated hirsute add-apt-repository fails, example:

  root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321
  Traceback (most recent call last):
File "/usr/bin/add-apt-repository", line 330, in 
  addaptrepo = AddAptRepository()
File "/usr/bin/add-apt-repository", line 35, in __init__
  self.distro.get_sources(self.sourceslist)
File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in 
get_sources
  raise NoDistroTemplateException(
  aptsources.distro.NoDistroTemplateException: Error: could not find a 
distribution template for Ubuntu/hirsute

  The PPA seems not to matter (all trigger it) and if I manually add PPA
  sources list and GPG key it works. So maybe software-properties just
  needs to learn about hirsute?

  Or is there another components (like distro-info or such) that needs a
  bump for this to work?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1902540/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1902540] Re: hirsute fails on add-apt-repository

2020-11-02 Thread Christian Ehrhardt
Ok, I see that there is an upload for it that would fix this in

   1 python-apt (2.1.3ubuntu3) hirsute; urgency=medium  
  
   2
  
   3   * Add hirsute to the Ubuntu template.
  
   4
  
   5  -- Steve Langasek   Mon, 26 Oct 2020 16:28:01 
-0700 

But it is stuck in excuses breaking apt-clone and sshuttle autopkgtests.
Since Steve (thanks) prepped that upload I'll subscribe him so he can close the 
bug once python-apt moves.

** Changed in: python-apt (Ubuntu)
   Status: Confirmed => Triaged

** Changed in: python-apt (Ubuntu)
 Assignee: (unassigned) => Steve Langasek (vorlon)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python-apt in Ubuntu.
https://bugs.launchpad.net/bugs/1902540

Title:
  hirsute fails on add-apt-repository

Status in python-apt package in Ubuntu:
  Triaged
Status in software-properties package in Ubuntu:
  Invalid

Bug description:
  On a fully updated hirsute add-apt-repository fails, example:

  root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321
  Traceback (most recent call last):
File "/usr/bin/add-apt-repository", line 330, in 
  addaptrepo = AddAptRepository()
File "/usr/bin/add-apt-repository", line 35, in __init__
  self.distro.get_sources(self.sourceslist)
File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in 
get_sources
  raise NoDistroTemplateException(
  aptsources.distro.NoDistroTemplateException: Error: could not find a 
distribution template for Ubuntu/hirsute

  The PPA seems not to matter (all trigger it) and if I manually add PPA
  sources list and GPG key it works. So maybe software-properties just
  needs to learn about hirsute?

  Or is there another components (like distro-info or such) that needs a
  bump for this to work?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1902540/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1902540] Re: hirsute fails on add-apt-repository

2020-11-02 Thread Christian Ehrhardt
Ok, checking the recent tests it seems that vorlon and juliank are on it 
already.
So I can hold back (to not make things more confusing) and let them handle it.

The attachment here in comment #6 can serve as a workaround until
resolved.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python-apt in Ubuntu.
https://bugs.launchpad.net/bugs/1902540

Title:
  hirsute fails on add-apt-repository

Status in python-apt package in Ubuntu:
  Triaged
Status in software-properties package in Ubuntu:
  Invalid

Bug description:
  On a fully updated hirsute add-apt-repository fails, example:

  root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321
  Traceback (most recent call last):
File "/usr/bin/add-apt-repository", line 330, in 
  addaptrepo = AddAptRepository()
File "/usr/bin/add-apt-repository", line 35, in __init__
  self.distro.get_sources(self.sourceslist)
File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in 
get_sources
  raise NoDistroTemplateException(
  aptsources.distro.NoDistroTemplateException: Error: could not find a 
distribution template for Ubuntu/hirsute

  The PPA seems not to matter (all trigger it) and if I manually add PPA
  sources list and GPG key it works. So maybe software-properties just
  needs to learn about hirsute?

  Or is there another components (like distro-info or such) that needs a
  bump for this to work?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1902540/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1902540] Re: hirsute fails on add-apt-repository

2020-11-02 Thread Christian Ehrhardt
It seems that data is parsed from /usr/share/python-apt/templates/Ubuntu.info
class SourcesList(object):
""" represents the full sources.list + sources.list.d file """

def __init__(self,
 withMatcher=True,
 matcherPath="/usr/share/python-apt/templates/"):


Which also is part of Source: python-apt

I added hirsute manually there (as attached) and things started working.

** Patch added: "add hirsute to python-apt 
/usr/share/python-apt/templates/Ubuntu.info"
   
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1902540/+attachment/5430564/+files/fix-hirsute-python-apt.diff

** Changed in: python-apt (Ubuntu)
   Status: New => Confirmed

** Changed in: software-properties (Ubuntu)
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python-apt in Ubuntu.
https://bugs.launchpad.net/bugs/1902540

Title:
  hirsute fails on add-apt-repository

Status in python-apt package in Ubuntu:
  Triaged
Status in software-properties package in Ubuntu:
  Invalid

Bug description:
  On a fully updated hirsute add-apt-repository fails, example:

  root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321
  Traceback (most recent call last):
File "/usr/bin/add-apt-repository", line 330, in 
  addaptrepo = AddAptRepository()
File "/usr/bin/add-apt-repository", line 35, in __init__
  self.distro.get_sources(self.sourceslist)
File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in 
get_sources
  raise NoDistroTemplateException(
  aptsources.distro.NoDistroTemplateException: Error: could not find a 
distribution template for Ubuntu/hirsute

  The PPA seems not to matter (all trigger it) and if I manually add PPA
  sources list and GPG key it works. So maybe software-properties just
  needs to learn about hirsute?

  Or is there another components (like distro-info or such) that needs a
  bump for this to work?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1902540/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1902540] Re: hirsute fails on add-apt-repository

2020-11-02 Thread Christian Ehrhardt
Yeah still present for me as well in a new hirsute container of today :-/
Thanks for double checking as Bryce/Sergio as that is excluding a lot of 
caching/net-setup/... questions.


>From the debugging I know that the self-detect is right
self.codename == hirsute

But the list in self.sourceslist.matcher.templates does not contain a hirsute.
That comes from /usr/lib/python3/dist-packages/aptsources/sourceslist.py from 
src:python-apt.
Maybe the bug is over there and adding a task for that can help to trigger the 
right people (or there maybe is even a bug open already).

** Also affects: python-apt (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1902540

Title:
  hirsute fails on add-apt-repository

Status in python-apt package in Ubuntu:
  New
Status in software-properties package in Ubuntu:
  Confirmed

Bug description:
  On a fully updated hirsute add-apt-repository fails, example:

  root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321
  Traceback (most recent call last):
File "/usr/bin/add-apt-repository", line 330, in 
  addaptrepo = AddAptRepository()
File "/usr/bin/add-apt-repository", line 35, in __init__
  self.distro.get_sources(self.sourceslist)
File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in 
get_sources
  raise NoDistroTemplateException(
  aptsources.distro.NoDistroTemplateException: Error: could not find a 
distribution template for Ubuntu/hirsute

  The PPA seems not to matter (all trigger it) and if I manually add PPA
  sources list and GPG key it works. So maybe software-properties just
  needs to learn about hirsute?

  Or is there another components (like distro-info or such) that needs a
  bump for this to work?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1902540/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1902540] Re: hirsute fails on add-apt-repository

2020-11-02 Thread Christian Ehrhardt
Throwing a debug in the failing code:

# find the distro template
for template in self.sourceslist.matcher.templates:
print("Try '%s': self.is_codename(template.name) '%s' && self.id >> 
'%s' == '%s' << template.distribution" % (template.name, 
self.is_codename(template.name), self.id, template.distribution))
if (self.is_codename(template.name) and
template.distribution == self.id):
print("yeah! found a template")
self.source_template = template
break
if self.source_template is None:
raise NoDistroTemplateException(
"Error: could not find a distribution template for %s/%s" %
(self.id, self.codename))


Gives me:
Try 'bullseye': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu' 
== 'Debian' << template.distribution
Try 'bullseye/updates': self.is_codename(template.name) 'False' && self.id >> 
'Ubuntu' == 'Debian' << template.distribution
Try 'bullseye-updates': self.is_codename(template.name) 'False' && self.id >> 
'Ubuntu' == 'Debian' << template.distribution
Try 'bullseye-proposed-updates': self.is_codename(template.name) 'False' && 
self.id >> 'Ubuntu' == 'Debian' << template.distribution
Try 'buster': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu' == 
'Debian' << template.distribution
Try 'buster/updates': self.is_codename(template.name) 'False' && self.id >> 
'Ubuntu' == 'Debian' << template.distribution
Try 'buster-updates': self.is_codename(template.name) 'False' && self.id >> 
'Ubuntu' == 'Debian' << template.distribution
Try 'buster-proposed-updates': self.is_codename(template.name) 'False' && 
self.id >> 'Ubuntu' == 'Debian' << template.distribution
Try 'stretch': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu' 
== 'Debian' << template.distribution
Try 'stretch/updates': self.is_codename(template.name) 'False' && self.id >> 
'Ubuntu' == 'Debian' << template.distribution
Try 'stretch-updates': self.is_codename(template.name) 'False' && self.id >> 
'Ubuntu' == 'Debian' << template.distribution
Try 'stretch-proposed-updates': self.is_codename(template.name) 'False' && 
self.id >> 'Ubuntu' == 'Debian' << template.distribution
Try 'jessie': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu' == 
'Debian' << template.distribution
Try 'jessie/updates': self.is_codename(template.name) 'False' && self.id >> 
'Ubuntu' == 'Debian' << template.distribution
Try 'jessie-updates': self.is_codename(template.name) 'False' && self.id >> 
'Ubuntu' == 'Debian' << template.distribution
Try 'jessie-proposed-updates': self.is_codename(template.name) 'False' && 
self.id >> 'Ubuntu' == 'Debian' << template.distribution
Try 'wheezy': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu' == 
'Debian' << template.distribution
Try 'wheezy/updates': self.is_codename(template.name) 'False' && self.id >> 
'Ubuntu' == 'Debian' << template.distribution
Try 'wheezy-updates': self.is_codename(template.name) 'False' && self.id >> 
'Ubuntu' == 'Debian' << template.distribution
Try 'wheezy-proposed-updates': self.is_codename(template.name) 'False' && 
self.id >> 'Ubuntu' == 'Debian' << template.distribution
Try 'squeeze': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu' 
== 'Debian' << template.distribution
Try 'squeeze-proposed-updates': self.is_codename(template.name) 'False' && 
self.id >> 'Ubuntu' == 'Debian' << template.distribution
Try 'squeeze/updates': self.is_codename(template.name) 'False' && self.id >> 
'Ubuntu' == 'Debian' << template.distribution
Try 'lenny': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu' == 
'Debian' << template.distribution
Try 'lenny-proposed-updates': self.is_codename(template.name) 'False' && 
self.id >> 'Ubuntu' == 'Debian' << template.distribution
Try 'lenny/updates': self.is_codename(template.name) 'False' && self.id >> 
'Ubuntu' == 'Debian' << template.distribution
Try 'etch': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu' == 
'Debian' << template.distribution
Try 'etch-proposed-updates': self.is_codename(template.name) 'False' && self.id 
>> 'Ubuntu' == 'Debian' << template.distribution
Try 'etch/updates': self.is_codename(template.name) 'False' && self.id >> 
'Ubuntu' == 'Debian' << template.distribution
Try 'sarge': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu' == 
'Debian' << template.distribution
Try 'sarge-proposed-updates': self.is_codename(template.name) 'False' && 
self.id >> 'Ubuntu' == 'Debian' << template.distribution
Try 'sarge/updates': self.is_codename(template.name) 'False' && self.id >> 
'Ubuntu' == 'Debian' << template.distribution
Try 'stable': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu' == 
'Debian' << template.distribution
Try 'testing': self.is_codename(template.name) 'False' && self.id >> 'Ubuntu' 
== 'Debian' << template.distribution
Try 'sid': 

[Touch-packages] [Bug 1902540] [NEW] hirsute fails on add-apt-repository

2020-11-02 Thread Christian Ehrhardt
Public bug reported:

On a fully updated hirsute add-apt-repository fails, example:

root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321
Traceback (most recent call last):
  File "/usr/bin/add-apt-repository", line 330, in 
addaptrepo = AddAptRepository()
  File "/usr/bin/add-apt-repository", line 35, in __init__
self.distro.get_sources(self.sourceslist)
  File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in 
get_sources
raise NoDistroTemplateException(
aptsources.distro.NoDistroTemplateException: Error: could not find a 
distribution template for Ubuntu/hirsute

The PPA seems not to matter (all trigger it) and if I manually add PPA
sources list and GPG key it works. So maybe software-properties just
needs to learn about hirsute?

Or is there another components (like distro-info or such) that needs a
bump for this to work?

** Affects: software-properties (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1902540

Title:
  hirsute fails on add-apt-repository

Status in software-properties package in Ubuntu:
  New

Bug description:
  On a fully updated hirsute add-apt-repository fails, example:

  root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321
  Traceback (most recent call last):
File "/usr/bin/add-apt-repository", line 330, in 
  addaptrepo = AddAptRepository()
File "/usr/bin/add-apt-repository", line 35, in __init__
  self.distro.get_sources(self.sourceslist)
File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in 
get_sources
  raise NoDistroTemplateException(
  aptsources.distro.NoDistroTemplateException: Error: could not find a 
distribution template for Ubuntu/hirsute

  The PPA seems not to matter (all trigger it) and if I manually add PPA
  sources list and GPG key it works. So maybe software-properties just
  needs to learn about hirsute?

  Or is there another components (like distro-info or such) that needs a
  bump for this to work?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1902540/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1902135] Re: package openssh-server 1:8.2p1-4ubuntu0.1 failed to install/upgrade: el subproceso instalado paquete openssh-server script post-installation devolvió el código de sa

2020-10-30 Thread Christian Ehrhardt
Hi,
thanks for the report but IMHO there is not much to do, port 22 is SSHs port 
and it is right to default to it. If your local configuration has port 22 bound 
to something else (Docker in your case) you need to adapt the configuration of 
either (ssh in its half installed state or your docker/images).

There is not much the ssh (package) could do IMHO.

So this looks like a local configuration problem, rather than a bug in
Ubuntu.

You can find pointers to get help for this sort of problem here:
http://www.ubuntu.com/support/community

Since we use this bug tracker to track bugs in Ubuntu, rather than
configuration problems, I'm marking this bug as Invalid. This helps us
to focus on fixing bugs in Ubuntu.

If you believe that this is really a bug, then you may find it helpful
to read "How to report bugs effectively"
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful
if you would then provide a more complete description of the problem,
explain why you believe this is a bug in Ubuntu rather than a problem
specific to your system, and then change the bug status back to New.

** Changed in: openssh (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1902135

Title:
  package openssh-server 1:8.2p1-4ubuntu0.1 failed to install/upgrade:
  el subproceso instalado paquete openssh-server script post-
  installation devolvió el código de salida de error 1

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  just following the installation guide
  
https://community.home-assistant.io/t/installing-home-assistant-supervised-on-debian-10/200253

  it crashed installing openssh-server, because docker already have the
  port 22 binded

  ProblemType: Package
  DistroRelease: Ubuntu 20.04
  Package: openssh-server 1:8.2p1-4ubuntu0.1
  ProcVersionSignature: Ubuntu 5.4.0-52.57-generic 5.4.65
  Uname: Linux 5.4.0-52-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.10
  AptOrdering:
   ncurses-term:amd64: Install
   openssh-sftp-server:amd64: Install
   openssh-server:amd64: Install
   ssh-import-id:amd64: Install
   NULL: ConfigurePending
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Thu Oct 29 21:04:55 2020
  ErrorMessage: el subproceso instalado paquete openssh-server script 
post-installation devolvió el código de salida de error 1
  InstallationDate: Installed on 2020-10-29 (0 days ago)
  InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu3
   apt  2.0.2ubuntu0.1
  SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 
255: Missing privilege separation directory: /run/sshd
  SourcePackage: openssh
  Title: package openssh-server 1:8.2p1-4ubuntu0.1 failed to install/upgrade: 
el subproceso instalado paquete openssh-server script post-installation 
devolvió el código de salida de error 1
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1902135/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1902109] Re: rsync uses lchmod and fails in Ubuntu >= 20.10 if /proc isn't mounted

2020-10-30 Thread Christian Ehrhardt
Awesome, thanks for updating the bug tasks and tracking bug already
Alkis!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1902109

Title:
  rsync uses lchmod and fails in Ubuntu >= 20.10 if /proc isn't mounted

Status in GLibC:
  Unknown
Status in glibc package in Ubuntu:
  New
Status in rsync package in Ubuntu:
  Triaged

Bug description:
  Rsync in Ubuntu 20.10 fails when /proc isn't mounted, while it worked before.
  This happens because AC_CHECK_FUNC(lchmod) returns "yes" in 20.10, while it 
returned "no" before.

  Steps to reproduce:

  # Emulate /proc not being mounted
  $ mount --bind / /mnt
  $ chroot /mnt rsync -a /bin/ls .
  rsync: [receiver] failed to set permissions on "/.ls.CDExhu": Operation not 
supported (95)
  rsync error: some files/attrs were not transferred (see previous errors) 
(code 3) at main.c(1330) [sender=3.2.3]

  I reported this issue upstream in
  https://github.com/WayneD/rsync/issues/109 but the rsync developer
  says it's a problem in libc, and it might well be.

  Simple C code to reproduce the problem without rsync:

  printf("lchmod returned: %d\n", lchmod("/tmp/ls", 0755));

  If /tmp/ls is e.g. mode=0123, and needs to be changed, lchmod fails
  when /proc isn't mounted, yet it succeeds if it is mounted.

  Python had a similar issue, and they ended up avoiding
  AC_CHECK_FUNC(lchmod) under Linux:

  https://bugs.python.org/issue34652
  
https://github.com/python/cpython/commit/69e96910153219b0b15a18323b917bd74336d229#diff-49473dca262eeab3b4a43002adb08b4db31020d190caaad1594b47f1d5daa810R3140

  ```c
  if test "$MACHDEP" != linux; then
AC_CHECK_FUNC(lchmod)
  fi
  ```

  So I'm not sure which package is causing the bug here. Should autoconf
  return false? Should libc implement lchown without the bug? Or should
  rsync skip lchmod under Linux, like python did?

To manage notifications about this bug go to:
https://bugs.launchpad.net/glibc/+bug/1902109/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1901295] Re: python3-chardet breaks install of python-chardet

2020-10-27 Thread Christian Ehrhardt
Maintainers are free to remove python2 if there are no reverse dependencies 
left for the obvious unsupportability.
This happened here in [1] to resolve [2]

There also is no installation candidate left in a recent archive. Maybe
replaces/breaks was a bit too much (as users like you could be happy to
keep the old one around on an upgrade). But I'm unsure about the policy
on such cleanups, maybe it was intentional to remove old no more
supported bits. If you read the Debian bug I linked that makes sense.

This isn't jsuta n Ubuntu/Debian decision, also all upstream archives/support 
for 2.x have ended.
I'm unsure what to do here, asking you to get your application that depends on 
it upgraded?

[1]: 
https://salsa.debian.org/python-team/packages/chardet/-/commit/5b4be98c3c408e1b73f94f8fb133bb7ceadec81f
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936289

** Bug watch added: Debian Bug tracker #936289
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936289

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python3-chardet in Ubuntu.
https://bugs.launchpad.net/bugs/1901295

Title:
  python3-chardet breaks install of python-chardet

Status in python3-chardet package in Ubuntu:
  Confirmed

Bug description:
  I'm trying to install python-chardet (for python-2.7), but it fails
  because latest python3-chardet breaks python-chardet. I fail to
  understand why the python3 version of chardet would break the
  python2.7 version of the same module.

  PS: I know that python2.7 is not supported anymore, but I have an
  application that depends on it, and I need to install it, and that's
  now impossible because of this bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-chardet/+bug/1901295/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1901295] Re: python3-chardet breaks install of python-chardet

2020-10-27 Thread Christian Ehrhardt
I can confirm the behavior

** Changed in: python3-chardet (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python3-chardet in Ubuntu.
https://bugs.launchpad.net/bugs/1901295

Title:
  python3-chardet breaks install of python-chardet

Status in python3-chardet package in Ubuntu:
  Confirmed

Bug description:
  I'm trying to install python-chardet (for python-2.7), but it fails
  because latest python3-chardet breaks python-chardet. I fail to
  understand why the python3 version of chardet would break the
  python2.7 version of the same module.

  PS: I know that python2.7 is not supported anymore, but I have an
  application that depends on it, and I need to install it, and that's
  now impossible because of this bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-chardet/+bug/1901295/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1899852] Re: Cannot assign requested address: AH00072: make_sock: could not bind to address

2020-10-19 Thread Christian Ehrhardt
Thank you for taking the time to report this bug and helping to make
Ubuntu better.

Since it seems likely to me that this is a local configuration problem,
rather than a bug in Ubuntu, I'm marking this bug as Incomplete.

If indeed this is a local configuration problem, you can find pointers
to get help for this sort of problem here:
http://www.ubuntu.com/support/community

Or if you believe that this is really a bug, then you may find it
helpful to read "How to report bugs effectively"
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful
if you would then provide a more complete description of the problem,
explain why you believe this is a bug in Ubuntu rather than a problem
specific to your system, and then change the bug status back to New.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1899852

Title:
   Cannot assign requested address: AH00072: make_sock: could not bind
  to address

Status in apache2 package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  Hello,

  Let's first list my configuration items:
  * apache2 2.4.29-1ubuntu4.14
  * release: Ubuntu 18.04.5 LTS

  Upon reboot, the following message is seen in apache2.service logs:

  -- Unit apache2.service has begun starting up.
  Oct 14 12:18:32 SERVER apachectl[3833]: (99)Cannot assign requested address: 
AH00072: make_sock: could not bind to address [REDACTED IPV6.33]:443
  Oct 14 12:18:32 SERVER apachectl[3833]: no listening sockets available, 
shutting down
  Oct 14 12:18:32 SERVER apachectl[3833]: AH00015: Unable to open logs
  Oct 14 12:18:32 SERVER apachectl[3833]: Action 'start' failed.
  Oct 14 12:18:32 SERVER apachectl[3833]: The Apache error log may have more 
information.
  Oct 14 12:18:33 SERVER systemd[1]: apache2.service: Control process exited, 
code=exited status=1
  Oct 14 12:18:33 SERVER systemd[1]: apache2.service: Failed with result 
'exit-code'.
  Oct 14 12:18:33 SERVER systemd[1]: Failed to start The Apache HTTP Server.

  The apache2 configuration is using the ipv4 and ipv6 present on the server:
  /etc/apache2/ports.conf:Listen :443
  /etc/apache2/ports.conf:Listen :443
  /etc/apache2/ports.conf:Listen [REDACTED IPV6::33]:443
  /etc/apache2/ports.conf:Listen [REDACTED IPV6::35]:443

  and the /etc/network/interfaces looks like this (no netplan):
  # Additional IPs that are used to serve https traffic for
  # releases.ubuntu.com so that archive doesn't respond on 443.
  auto bond0:1
  iface bond0:1 inet static
  address .247/32
  # Using up/down to avoid LP:1347246.
  up /sbin/ip addr add REDACTED IPV6::33/128 dev $IFACE preferred_lft 0
  down /bin/ip addr del REDACTED IPV6::33/128 dev $IFACE preferred_lft 0

  # Additional IPs that are used to serve *.clouds.archive.ubuntu.com
  # with HTTPProtocolOptions unsafe, which is needed to work around
  # cloud-init bug LP:1868232 (cRT#125271).
  auto bond0:2
  iface bond0:2 inet static
  address .245/32
  # Using up/down to avoid LP:1347246.
  up /sbin/ip addr add REDACTED IPV6::35/128 dev $IFACE preferred_lft 0
  down /bin/ip addr del REDACTED IPV6::35/128 dev $IFACE preferred_lft 0

  I was surprised that the apache2.service does not contain a
  After=network-online.target

  $ systemctl show apache2.service | grep -E '(Wants|Require|After|Before)'
  RemainAfterExit=no
  Requires=system.slice sysinit.target -.mount
  Before=multi-user.target shutdown.target
  After=basic.target sysinit.target systemd-journald.socket system.slice 
network.target nss-lookup.target systemd-tmpfiles-setup.service 
remote-fs.target -.mount
  RequiresMountsFor=/var/tmp /tmp

  $ systemctl show network.target | grep "^After"
  After=network-pre.target ifup@bond0.service ifup@ens2f0.service 
ifup@ens2f1.service systemd-resolved.service ufw.service networking.service 
systemd-networkd.service

  So I was wondering if the "ifup@bond0" was enough as a dependency
  here, to be sure to have the ipv6 up and running or if we would need
  something like "ifup@bond0:2" and "ifup@bond0:1" as part of the list
  of the services in the network.target "After" list.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1899852/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1899852] Re: Cannot assign requested address: AH00072: make_sock: could not bind to address

2020-10-19 Thread Christian Ehrhardt
Now to your actual question of "how to order after a given bond interface", 
that is actually a systemd-networkd/systemd question (reminder question, not a 
bug - so not a bug report actually).

I'll add bug tasks but think they are incomplete as that is a
config/consulting question more than anything else.

** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: apache2 (Ubuntu)
   Status: New => Invalid

** Changed in: systemd (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1899852

Title:
   Cannot assign requested address: AH00072: make_sock: could not bind
  to address

Status in apache2 package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  Hello,

  Let's first list my configuration items:
  * apache2 2.4.29-1ubuntu4.14
  * release: Ubuntu 18.04.5 LTS

  Upon reboot, the following message is seen in apache2.service logs:

  -- Unit apache2.service has begun starting up.
  Oct 14 12:18:32 SERVER apachectl[3833]: (99)Cannot assign requested address: 
AH00072: make_sock: could not bind to address [REDACTED IPV6.33]:443
  Oct 14 12:18:32 SERVER apachectl[3833]: no listening sockets available, 
shutting down
  Oct 14 12:18:32 SERVER apachectl[3833]: AH00015: Unable to open logs
  Oct 14 12:18:32 SERVER apachectl[3833]: Action 'start' failed.
  Oct 14 12:18:32 SERVER apachectl[3833]: The Apache error log may have more 
information.
  Oct 14 12:18:33 SERVER systemd[1]: apache2.service: Control process exited, 
code=exited status=1
  Oct 14 12:18:33 SERVER systemd[1]: apache2.service: Failed with result 
'exit-code'.
  Oct 14 12:18:33 SERVER systemd[1]: Failed to start The Apache HTTP Server.

  The apache2 configuration is using the ipv4 and ipv6 present on the server:
  /etc/apache2/ports.conf:Listen :443
  /etc/apache2/ports.conf:Listen :443
  /etc/apache2/ports.conf:Listen [REDACTED IPV6::33]:443
  /etc/apache2/ports.conf:Listen [REDACTED IPV6::35]:443

  and the /etc/network/interfaces looks like this (no netplan):
  # Additional IPs that are used to serve https traffic for
  # releases.ubuntu.com so that archive doesn't respond on 443.
  auto bond0:1
  iface bond0:1 inet static
  address .247/32
  # Using up/down to avoid LP:1347246.
  up /sbin/ip addr add REDACTED IPV6::33/128 dev $IFACE preferred_lft 0
  down /bin/ip addr del REDACTED IPV6::33/128 dev $IFACE preferred_lft 0

  # Additional IPs that are used to serve *.clouds.archive.ubuntu.com
  # with HTTPProtocolOptions unsafe, which is needed to work around
  # cloud-init bug LP:1868232 (cRT#125271).
  auto bond0:2
  iface bond0:2 inet static
  address .245/32
  # Using up/down to avoid LP:1347246.
  up /sbin/ip addr add REDACTED IPV6::35/128 dev $IFACE preferred_lft 0
  down /bin/ip addr del REDACTED IPV6::35/128 dev $IFACE preferred_lft 0

  I was surprised that the apache2.service does not contain a
  After=network-online.target

  $ systemctl show apache2.service | grep -E '(Wants|Require|After|Before)'
  RemainAfterExit=no
  Requires=system.slice sysinit.target -.mount
  Before=multi-user.target shutdown.target
  After=basic.target sysinit.target systemd-journald.socket system.slice 
network.target nss-lookup.target systemd-tmpfiles-setup.service 
remote-fs.target -.mount
  RequiresMountsFor=/var/tmp /tmp

  $ systemctl show network.target | grep "^After"
  After=network-pre.target ifup@bond0.service ifup@ens2f0.service 
ifup@ens2f1.service systemd-resolved.service ufw.service networking.service 
systemd-networkd.service

  So I was wondering if the "ifup@bond0" was enough as a dependency
  here, to be sure to have the ipv6 up and running or if we would need
  something like "ifup@bond0:2" and "ifup@bond0:1" as part of the list
  of the services in the network.target "After" list.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1899852/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1900008] Re: Sessions of screen does not keep running in background

2020-10-19 Thread Christian Ehrhardt
Thanks Axel,
I think I didn't closed a terminal windows with anything other but CTRL+D for 
years (which is an implicit call to exit), but you are absolutely right. It 
could be "click on the X on the window decoration to close the terminal".
Thanks for making me see that ... :-)

@Gustavo - never the less please speak up what exactly is-done/happens
in your case as we are still making assumptions.

** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/198

Title:
  Sessions of screen does not keep running in background

Status in screen package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  In a new fresh installed 20.04, when I use screen command and close
  the terminal (not closing screen sesion), then I can't recover it with
  screen -x, since does not exist. I can only recover screen sesion if
  the original terminal running screen is not being closed.

  For some reason, this is closing screen session of that user:

  Oct 15 13:32:45 pc-caja2 systemd[1]: session-66.scope: Succeeded.
  Oct 15 13:32:45 pc-caja2 systemd[1]: Stopped Session 66 of user usuario.

  This does not happen in an upgraded system from 18.04 to 20.04.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/screen/+bug/198/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1744328] Re: libfreebl3.so should be public, not in the nss subdir

2020-10-19 Thread Christian Ehrhardt
FYI since comment #6 not a lot happened in Debian other than other bugs
being merged.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to nss in Ubuntu.
https://bugs.launchpad.net/bugs/1744328

Title:
  libfreebl3.so should be public, not in the nss subdir

Status in nss package in Ubuntu:
  Fix Released
Status in nss package in Debian:
  New

Bug description:
  Hi,
  I tried to move the chrony dependency from tomcrypt to libnss to avoid 
universe dependencies.
  While doing so I found that libfreebl3 is not "normally" linkable being 
outside the normal ld paths.

  E.g. sample program
  #include 
  #include 
  #include 
  int main(int argc, char **argv) {
  NSSLOWHASH_Begin(NSSLOWHASH_NewContext(NSSLOW_Init(), HASH_AlgSHA512));
  return 0;
  }

  Build:
  gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
-Wmissing-prototypes -Wall -pthread -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/nss -I/usr/include/nspr -o docheck docheck.c -lfreebl3 
-Wl,-Bsymbolic-functions -Wl,-z,relro -v -Wl,-v -L/usr/lib/x86_64-linux-gnu/nss

  Then:
  ldd docheck
  will give you
  libfreebl3.so => not found

  Obviously a link into /usr/lib/x86_64-linux-gnu/ fixes the issue but
  needs some more consideration if that is the thing we want (there
  might be a reason it is where it is).

  Note: Required to go on with the chrony MIR which is rather urgent to
  be sorted out as it has a lot of other dependencies that need to be
  adapted.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nss/+bug/1744328/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1897744] Re: VerifyHostKeyDNS not working due to missing trust-ad flag

2020-10-14 Thread Christian Ehrhardt
I just re-debugged into the same case - now marked as dup.
You might consider using 
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1898590/comments/7 as 
test steps to verify that once uploaded to focal-proposed.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1897744

Title:
  VerifyHostKeyDNS not working due to missing trust-ad flag

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  In Progress

Bug description:
  [impact]

  without trust-ad resolv.conf option, glibc will strip AD from systemd-
  resolved responses. one thing this will prevent working is ssh
  VerifyHostKeyDNS

  [test case]

  setup a target system to ssh into, and create a SSHFP DNS record for
  its public key. on a different source system, setup dns to enable
  DNSSEC, and attempt to ssh to the target system using the
  VerifyHostKeyDNS=yes option.

  setup of the SSHFP is out of scope for this bug, but e.g.:
  https://en.wikipedia.org/wiki/SSHFP_record
  https://tools.ietf.org/html/rfc4255

  [regression potential]

  regressions would likely involve DNS lookup failures, probably if
  DNSSEC is enabled but possibly even without, and likely when the
  application requesting the dns lookup processes the response AD.

  [scope]

  this is needed only in focal.

  glibc first stripped the AD in version 2.31, so this is not needed in
  bionic or earlier.

  this was added upstream in commit a742f9828ea which was included in
  v246, so this is fixed already in groovy.

  [original description]

  Hi,

  1)
  Description:  Ubuntu 20.04.1 LTS
  Release:  20.04

  2)
  systemd:245.4-4ubuntu3.2

  3)
  I set VerifyHostKeyDNS to YES and hosts are automatically verified via sshfp.

  4)
  I still get the security question
  Matching host key fingerprint found in DNS.
  Are you sure you want to continue connecting (yes/no/[fingerprint])?

  The issue is known and fixed in systemd v246.
  https://github.com/systemd/systemd/pull/16072

  Best regards
  Daniel

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1897744/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1898590] Re: Verify DNS fingerprints not working

2020-10-14 Thread Christian Ehrhardt
*** This bug is a duplicate of bug 1897744 ***
https://bugs.launchpad.net/bugs/1897744

@Dan - now I saw your update - that might have shortened my dnssec trip :-)
It indeed is a duplicate of that - marking as such.

** This bug has been marked a duplicate of bug 1897744
   VerifyHostKeyDNS not working due to missing trust-ad flag

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1898590

Title:
  Verify DNS fingerprints not working

Status in systemd:
  Unknown
Status in glibc package in Ubuntu:
  Invalid
Status in openssh package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  New
Status in openssh package in Debian:
  Unknown

Bug description:
  When setting in /etc/ssh/ssh_config VerifyHostKeyDNS to yes the fingerprints 
are fetched, but the result is always:
  debug1: found n insecure fingerprints in DNS
  With dig +dnssec -tsshfp hostname the result is ok: ad flg is set.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1898590/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1898590] Re: Verify DNS fingerprints not working

2020-10-14 Thread Christian Ehrhardt
*** This bug is a duplicate of bug 1897744 ***
https://bugs.launchpad.net/bugs/1897744

Summary:
- we understand what happened
- we have a workaround for users by changing a config
- we have a systemd change that can be considered to be backported by the 
systemd package maintainers

** Tags removed: server-next

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1898590

Title:
  Verify DNS fingerprints not working

Status in systemd:
  Unknown
Status in glibc package in Ubuntu:
  Invalid
Status in openssh package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  New
Status in openssh package in Debian:
  Unknown

Bug description:
  When setting in /etc/ssh/ssh_config VerifyHostKeyDNS to yes the fingerprints 
are fetched, but the result is always:
  debug1: found n insecure fingerprints in DNS
  With dig +dnssec -tsshfp hostname the result is ok: ad flg is set.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1898590/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1898590] Re: Verify DNS fingerprints not working

2020-10-14 Thread Christian Ehrhardt
*** This bug is a duplicate of bug 1897744 ***
https://bugs.launchpad.net/bugs/1897744

TL;DR:
one affected by this upgrade triggered behavior change needs to set
  options edns0 trust-ad
in /etc/resolv.conf to fix the issue.

And as usual, once you already know what things are about - then (but only then 
:-/ ) you find the important related issues - reported by Laney \o/
Subscribing him to the bug FYI

Debian bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960023
I'll add a bug link to Debian.
Discussed and declared to be systed issue and asked to file upstream.

Which led to ...

Systemd
https://github.com/systemd/systemd/issues/15767
This is fixed in newer systemd and will set trust-ad
I'll add a systemd task to consider backporting this to Focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1898590

Title:
  Verify DNS fingerprints not working

Status in systemd:
  Unknown
Status in glibc package in Ubuntu:
  Invalid
Status in openssh package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  New
Status in openssh package in Debian:
  Unknown

Bug description:
  When setting in /etc/ssh/ssh_config VerifyHostKeyDNS to yes the fingerprints 
are fetched, but the result is always:
  debug1: found n insecure fingerprints in DNS
  With dig +dnssec -tsshfp hostname the result is ok: ad flg is set.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1898590/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1898590] Re: Verify DNS fingerprints not working

2020-10-14 Thread Christian Ehrhardt
*** This bug is a duplicate of bug 1897744 ***
https://bugs.launchpad.net/bugs/1897744

ok up/downgrading just "libc6" is enough to trigger.

I also found that libc6 from Eoan version 2.30-0ubuntu2.2 is good.
So it is new in 2.31!

The changelog mentions soem DNSSEC
https://sourceware.org/legacy-ml/libc-announce/2020/msg1.html

"* The DNS stub resolver will optionally send the AD (authenticated
  data) bit in queries if the trust-ad option is set via the options
  directive in /etc/resolv.conf (or if RES_TRUSTAD is set in
  _res.options).  In this mode, the AD bit, as provided by the name
  server, is available to applications which call res_search and
  related functions.  In the default mode, the AD bit is not set in
  queries, and it is automatically cleared in responses, indicating a
  lack of DNSSEC validation.  (Therefore, the name servers and the
  network path to them are treated as untrusted.)"

Once I knew that it was a small step and I found that
  options edns0 trust-ad
in /etc/resolv.conf indeed fixes the issue.

I'm not sure if openssh would be entitled to set  RES_TRUSTAD is set in 
_res.options.
Maybe not as that is more a decision of the admin setting up and configuring 
the system than the openssh software.

Therefore I think this is actually a little detail that upgraders that
use dnssec for openssh (and maybe others) via libc6 resolv need to
consider.

** Bug watch added: Debian Bug tracker #960023
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960023

** Also affects: openssh (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960023
   Importance: Unknown
   Status: Unknown

** Bug watch added: github.com/systemd/systemd/issues #15767
   https://github.com/systemd/systemd/issues/15767

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/15767
   Importance: Unknown
   Status: Unknown

** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: systemd (Ubuntu)
   Status: New => Fix Released

** Also affects: glibc (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: openssh (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Focal)
   Importance: Undecided
   Status: New

** No longer affects: glibc (Ubuntu Focal)

** Changed in: openssh (Ubuntu)
   Status: Confirmed => Invalid

** No longer affects: openssh (Ubuntu Focal)

** Changed in: glibc (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1898590

Title:
  Verify DNS fingerprints not working

Status in systemd:
  Unknown
Status in glibc package in Ubuntu:
  Invalid
Status in openssh package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  New
Status in openssh package in Debian:
  Unknown

Bug description:
  When setting in /etc/ssh/ssh_config VerifyHostKeyDNS to yes the fingerprints 
are fetched, but the result is always:
  debug1: found n insecure fingerprints in DNS
  With dig +dnssec -tsshfp hostname the result is ok: ad flg is set.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1898590/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1898590] Re: Verify DNS fingerprints not working

2020-10-14 Thread Christian Ehrhardt
As a first step I tried to make sure this actually is a change in openssh.
Because my reading of the issues referred above has shown that not all of the 
verification is done inside ssh but partially in glibc.

So I upgraded on the bionic test system step by step.

The upgrade dependency list for openssh-client is "libc-bin libc6
libgssapi-krb5-2 libkrb5-3 libkrb5support0 locales"

I found that the bug is reproducible with openssh-client
1:7.6p1-4ubuntu0.3 running against the newer glibc.

I can switch in/out the reported bug be switching on a Bionic system between 
glibc
2.27-3ubuntu1.2 - Bionic - Good
2.31-0ubuntu9.1 - Focal - Bad

** Also affects: glibc (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1898590

Title:
  Verify DNS fingerprints not working

Status in glibc package in Ubuntu:
  New
Status in openssh package in Ubuntu:
  Confirmed

Bug description:
  When setting in /etc/ssh/ssh_config VerifyHostKeyDNS to yes the fingerprints 
are fetched, but the result is always:
  debug1: found n insecure fingerprints in DNS
  With dig +dnssec -tsshfp hostname the result is ok: ad flg is set.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1898590/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1898590] Re: Verify DNS fingerprints not working

2020-10-14 Thread Christian Ehrhardt
Something helpful for anyone looking into this later I found what seems
a good testcase without requiring too much a local setup (of a dnssec
dns server):


To get unbound (brute force) do:
apt install unbound
sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved
sudo systemctl enable unbound-resolvconf
sudo systemctl enable unbound
# set 127.0.0.1
vim /etc/resolv.conf 

Now this should show the ad flag as reported:
$ dig salsa.debian.org -t sshfp
...
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

$ ssh -v -o "VerifyHostKeyDNS=yes" t...@salsa.debian.org


This indeed (as reported), does show the changed behavior (clean LXD 
containers, just changes as mentioned above, edns0 set by default):

Bionic:
debug1: found 4 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS

Focal:
debug1: found 4 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
The authenticity of host 'salsa.debian.org (209.87.16.44)' can't be established.
ED25519 key fingerprint is SHA256:OAD3pGSwcODIthxF+zIRvPTZ8UCJAYI75E42XDfGr84.
Matching host key fingerprint found in DNS.


** Changed in: openssh (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1898590

Title:
  Verify DNS fingerprints not working

Status in openssh package in Ubuntu:
  Confirmed

Bug description:
  When setting in /etc/ssh/ssh_config VerifyHostKeyDNS to yes the fingerprints 
are fetched, but the result is always:
  debug1: found n insecure fingerprints in DNS
  With dig +dnssec -tsshfp hostname the result is ok: ad flg is set.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1898590/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1898590] Re: Verify DNS fingerprints not working

2020-10-14 Thread Christian Ehrhardt
Turns out this seems to be a never ending story and you might have found
a comeback of that issue for your particular configuration as you say
this worked on 18.04 but fails on 20.04.

This goes way back
https://bugzilla.mindrot.org/show_bug.cgi?id=1455
Or half way back
https://trac.macports.org/ticket/49007
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618863
https://bugzilla.mindrot.org/show_bug.cgi?id=2119

Other more recent similar issues were around "options edns0" being required to 
be set for this to work now:
https://github.com/NixOS/nixpkgs/issues/12470
https://exanames.typepad.com/blog/2009/06/one-more-thing-to-do-with-dnssec-ssh.html
https://bugzilla.redhat.com/show_bug.cgi?id=1630180
https://bugzilla.redhat.com/show_bug.cgi?id=1878166
Note: that option was the default for /etc/resolv.conf on Bionic/Focal for me.

Various working setups seem to have been affected by 7.5
https://lists.mindrot.org/pipermail/openssh-bugs/2017-April/017631.html
https://lists.mindrot.org/pipermail/openssh-unix-dev/2018-January/036600.html
https://bugzilla.mindrot.org/show_bug.cgi?id=2708

But Bionic -> Focal is openssh version 7.6 -> 8.3

Multiple of the above and some other references refer to requiring ldns support.
That clearly is in openssh since ~v6 but we don't enable it at build time
   libldns support: no
Is that required and is it now more required than before - I don't know :-/


Sorry, all that I could provide so far was a collection of a (disturbing) 
history of that feature.

** Bug watch added: OpenSSH Portable Bugzilla #1455
   https://bugzilla.mindrot.org/show_bug.cgi?id=1455

** Bug watch added: trac.macports.org #49007
   http://trac.macports.org/ticket/49007

** Bug watch added: Debian Bug tracker #618863
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618863

** Bug watch added: OpenSSH Portable Bugzilla #2119
   https://bugzilla.mindrot.org/show_bug.cgi?id=2119

** Bug watch added: github.com/NixOS/nixpkgs/issues #12470
   https://github.com/NixOS/nixpkgs/issues/12470

** Bug watch added: Red Hat Bugzilla #1630180
   https://bugzilla.redhat.com/show_bug.cgi?id=1630180

** Bug watch added: Red Hat Bugzilla #1878166
   https://bugzilla.redhat.com/show_bug.cgi?id=1878166

** Bug watch added: OpenSSH Portable Bugzilla #2708
   https://bugzilla.mindrot.org/show_bug.cgi?id=2708

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1898590

Title:
  Verify DNS fingerprints not working

Status in openssh package in Ubuntu:
  Confirmed

Bug description:
  When setting in /etc/ssh/ssh_config VerifyHostKeyDNS to yes the fingerprints 
are fetched, but the result is always:
  debug1: found n insecure fingerprints in DNS
  With dig +dnssec -tsshfp hostname the result is ok: ad flg is set.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1898590/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1898590] Re: Verify DNS fingerprints not working

2020-10-13 Thread Christian Ehrhardt
** Tags added: server-next

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1898590

Title:
  Verify DNS fingerprints not working

Status in openssh package in Ubuntu:
  New

Bug description:
  When setting in /etc/ssh/ssh_config VerifyHostKeyDNS to yes the fingerprints 
are fetched, but the result is always:
  debug1: found n insecure fingerprints in DNS
  With dig +dnssec -tsshfp hostname the result is ok: ad flg is set.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1898590/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1892559] Re: [MIR] ccid libpam-pkcs1 libpcsc-perl opensc pcsc-tools pcsc-lite

2020-10-08 Thread Christian Ehrhardt
Hi Seth and Joy,
I see you cleared the list a lot - awesome!
You have subscribed and pinged the remaining ones which is a reasonable 
approach as most might be no more real issues as of today.

I'm ok for the Ubuntu side of the pcsc-lite bugs now, what still needs
to be addressed is https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=930530

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pcsc-lite in Ubuntu.
https://bugs.launchpad.net/bugs/1892559

Title:
  [MIR] ccid libpam-pkcs1 libpcsc-perl opensc pcsc-tools pcsc-lite

Status in ccid package in Ubuntu:
  New
Status in opensc package in Ubuntu:
  Incomplete
Status in pam-pkcs11 package in Ubuntu:
  New
Status in pcsc-lite package in Ubuntu:
  New
Status in pcsc-perl package in Ubuntu:
  Invalid
Status in pcsc-tools package in Ubuntu:
  Invalid

Bug description:
  ==> ccid <==
  [Availability]
  ccid is in universe, and builds on all architectures.

  [Rationale]
  The desktop team and security team are interested in bringing smartcard
  authentication to enterprise desktop environments.

  [Security]
  No CVEs for ccid are listed in our database.
  Doesn't appear to bind to a socket.
  No privileged executables, but does have udev rules.
  Probably needs a security review.

  [Quality assurance]
  No test suite.
  Does require odd hardware that we'll probably need to buy.
  I don't see debconf questions.
  ccid is well maintained in Debian by upstream author.
  One open wishlist bug in BTS, harmless.

  One open bug in launchpad, not security, but looks very frustrating
  for the users. The upstream author was engaged but it never reached
  resolution.  https://bugs.launchpad.net/ubuntu/+source/ccid/+bug/1175465

  Has a debian/watch file.
  Quilt packaging.

  P: ccid source: no-dep5-copyright
  P: ccid source: package-uses-experimental-debhelper-compat-version 13

  [Dependencies]
  Minimal dependencies, in main

  [Standards compliance]
  Appears to satisfy FHS and Debian policy

  [Maintenance]
  The desktop team will subscribe to bugs, however it is expected that the
  security team will assist with security-relevant questions.

  [Background information]
  ccid provides drivers to interact with usb-connected smart card readers.

  ==> libpam-pkcs11 <==
  [Availability]
  Source package pam-pkcs11 is in universe and builds on all architectures.

  [Rationale]
  The desktop team and security team are interested in bringing smartcard
  authentication to enterprise desktop environments.

  [Security]
  No CVEs in our database.
  Doesn't appear to bind to sockets.
  No privileged executables (but is a PAM module).
  As a PAM module this will require a security review.

  [Quality assurance]
  The package does not call pam-auth-update in its postinst #1650366
  Does not ask questions during install.
  One Ubuntu bug claims very poor behaviour if a card isn't plugged in.
  No Debian bugs.
  Occasional updates in Debian by long-term maintainer.
  Does require odd hardware that we'll probably need to buy.
  Does not appear to run tests during build.
  Has scary warnings in the build logs.
  Has a debian/watch file.

  Ancient standards version; other smaller lintian messages, mostly
  documentation problems.

  Quilt packaging.

  [Dependencies]
  Depends on libcurl4, libldap-2.4-2, libpam0g, libpcsclite1, libssl1.1
  All are in main.

  [Standards compliance]
  The package does not call pam-auth-update in its postinst #1650366
  Otherwise looks to conform to FHS and Debian policies

  [Maintenance]
  The desktop team will subscribe to bugs, however it is expected that the
  security team will assist with security-relevant questions.

  [Background information]
  This PAM module can use CRLs and full-chain verification of certificates.
  It can also do LDAP, AD, and Kerberos username mapping.

  ==> libpcsc-perl <==
  [Availability]
  Source package pcsc-perl is in universe, builds for all architectures,
  plus i386

  [Rationale]
  The desktop team and security team are interested in bringing smartcard
  authentication to enterprise desktop environments.

  [Security]
  There are no cves for pcsc-perl in our database.
  No privileged executables.
  Doesn't appear to bind to sockets.
  Probably needs a security review.

  [Quality assurance]
  Library package not intended to be used directly.
  No debconf questions.
  No bugs in Debian.
  No bugs in Ubuntu.
  Does require odd hardware that we'll probably need to buy.
  Tests exist, not run during the build; probably can't run during the build.
  Includes debian/watch file.
  A handful of lintian issues
  Quilt packaging.

  [Dependencies]
  libpcsc-perl depends upon libpcsclite1, libc6, perl, perlapi-5.30.0.
  All are in main.

  [Standards compliance]
  One oddity, Card.pod is stored in 
/usr/lib/x86_64-linux-gnu/perl5/5.30/Chipcard/PCSC/
  Many other perl packages have .pod files in these directory trees so maybe
  it's fine, but it 

[Touch-packages] [Bug 857651] Re: Unable to hide users from login screen / user switcher

2020-09-28 Thread Christian Ehrhardt
Since so many components are involved a fix/change might have been missed.
And since I recently didn't hear anything about this otherwise rather hot bug I 
was giving focal a try.

It turns out that this was indeed improved. Only the user of pkg:ifmail user 
fdt name "Fidonet" is still visible. All other formerly affected packages are 
good in Focal.
I can't (without digging through history a lot) say what fixed that but I'll 
update the bug tasks accordingly. Setting Focal fixed and marking Bionic/Xenial 
as still affected releases.
The backport tasks for those packages are incomplete thou as it is unclear 
which change in which package fixed it for Focal.

Note: This is only speaking for the "default config" of Ubuntu Desktop
as in 20.04 we know that certain environments will behave differently
(e.g. KDE never was affected).

** Also affects: ifmail (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: ceph (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: lightdm (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: accountsservice (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: netqmail (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: sddm (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: ifmail (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: ceph (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: lightdm (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: accountsservice (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: netqmail (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: sddm (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** No longer affects: accountsservice (Ubuntu Xenial)

** No longer affects: accountsservice (Ubuntu Bionic)

** Changed in: ceph (Ubuntu Xenial)
   Status: New => Incomplete

** Changed in: ceph (Ubuntu Bionic)
   Status: New => Incomplete

** Changed in: ceph (Ubuntu)
   Status: Triaged => Fix Released

** No longer affects: ifmail (Ubuntu Xenial)

** No longer affects: ifmail (Ubuntu Bionic)

** No longer affects: lightdm (Ubuntu Xenial)

** No longer affects: lightdm (Ubuntu Bionic)

** Changed in: libvirt (Ubuntu)
   Status: Triaged => Fix Released

** Changed in: libvirt (Ubuntu Xenial)
   Status: New => Incomplete

** Changed in: libvirt (Ubuntu Bionic)
   Status: New => Incomplete

** Changed in: netqmail (Ubuntu Xenial)
   Status: New => Incomplete

** Changed in: netqmail (Ubuntu Bionic)
   Status: New => Incomplete

** Changed in: netqmail (Ubuntu)
   Status: Triaged => Fix Released

** No longer affects: sddm (Ubuntu Xenial)

** No longer affects: sddm (Ubuntu Bionic)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/857651

Title:
  Unable to hide users from login screen / user switcher

Status in accountsservice:
  Unknown
Status in SDDM:
  Fix Released
Status in accountsservice package in Ubuntu:
  Triaged
Status in ceph package in Ubuntu:
  Fix Released
Status in ifmail package in Ubuntu:
  Triaged
Status in libvirt package in Ubuntu:
  Fix Released
Status in lightdm package in Ubuntu:
  Triaged
Status in netqmail package in Ubuntu:
  Fix Released
Status in sddm package in Ubuntu:
  Fix Released
Status in ceph source package in Xenial:
  Incomplete
Status in libvirt source package in Xenial:
  Incomplete
Status in netqmail source package in Xenial:
  Incomplete
Status in ceph source package in Bionic:
  Incomplete
Status in libvirt source package in Bionic:
  Incomplete
Status in netqmail source package in Bionic:
  Incomplete

Bug description:
  Users that I have appended to the 'hidden-users' field in
  /etc/lightdm/users.conf are not actually hidden. They are still listed
  on the login screen and in Unity's user switching menu.

  ProblemType: Bug
  DistroRelease: Ubuntu 11.10
  Package: lightdm 0.9.7-0ubuntu1
  ProcVersionSignature: Ubuntu 3.0.0-11.18-generic 3.0.4
  Uname: Linux 3.0.0-11-generic x86_64
  ApportVersion: 1.23-0ubuntu1
  Architecture: amd64
  Date: Fri Sep 23 11:44:29 2011
  InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Beta amd64 (20110413)
  SourcePackage: lightdm
  UpgradeStatus: Upgraded to oneiric on 2011-09-23 (0 days ago)
  mtime.conffile..etc.lightdm.users.conf: 2011-09-23T08:46:55.039175

To manage notifications about this bug go to:
https://bugs.launchpad.net/accountsservice/+bug/857651/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : 

[Touch-packages] [Bug 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Christian Ehrhardt
Tested the change - works as expected, prepping an MP

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Christian Ehrhardt
That patch by Christian Bolz is already applied (which seems reasonable after 
that much time),
but when merging 3.0 the old patch for bug 1824812 should have been dropped.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Christian Ehrhardt
As refrence, it is a re-occurrence of
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1824812 , look
who filed that bug :-)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Christian Ehrhardt
https://gitlab.com/apparmor/apparmor/-/commit/61c27d8808f0589beb6a319cc04073e8bb32d860

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Christian Ehrhardt
And we are back with Christian Bolz :-)

commit 61c27d8808f0589beb6a319cc04073e8bb32d860
Author: Christian Boltz 
Date:   Fri Jun 21 19:22:15 2019 +0200

Fix and simplify setting SFS_MOUNTPOINT

The question is why isn't this in the apparmor 3.0 package in groovy-
proposed ?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: Apparmor 3.0.0 does not load profiles in containers anymore

2020-09-22 Thread Christian Ehrhardt
Isn't that "Not starting AppArmor in container" message just in:

/lib/apparmor/apparmor.systemd
   -> /lib/apparmor/rc.apparmor.functions
  -> function is_container_with_internal_policy()

That looks unchanged (except a comment) but it behaves differently:


root@testguest-apparmor-good:~# . /usr/lib/apparmor/rc.apparmor.functions
root@testguest-apparmor-good:~# is_container_with_internal_policy
root@testguest-apparmor-good:~# echo $?
0

root@testguest-apparmor-bad:~# . /usr/lib/apparmor/rc.apparmor.functions
root@testguest-apparmor-bad:~# is_container_with_internal_policy
root@testguest-apparmor-bad:~# echo $?
1

Looking into what happens in detail ...


good:
+ SFS_MOUNTPOINT=/sys/kernel/security/apparmor
+ local ns_stacked_path=/sys/kernel/security/apparmor/.ns_stacked

bad:
+ SFS_MOUNTPOINT=/sys/kernel/security/
+ local ns_stacked_path=/sys/kernel/security//.ns_stacked

Once we know that we can see that it is missing in the bad case

good:
root@testguest-apparmor-good:~# grep MODULE 
/usr/lib/apparmor/rc.apparmor.functions
MODULE=apparmor
SFS_MOUNTPOINT="${SECURITYFS}/${MODULE}"
if [ -f "${SECURITYFS}/${MODULE}/profiles" ]; then
SFS_MOUNTPOINT="${SECURITYFS}/${MODULE}"
MODULE=apparmor
/sbin/modprobe -qr $MODULE

bad:
root@testguest-apparmor-bad:~# grep MODULE 
/usr/lib/apparmor/rc.apparmor.functions
SFS_MOUNTPOINT="${SECURITYFS}/${MODULE}"

So whatever took away the modprobe from
/usr/lib/apparmor/rc.apparmor.functions also removed the variable, but
that has broken function is_container_with_internal_policy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-22 Thread Christian Ehrhardt
Bad case:

$ ./repro.sh bad
+ '[' bad == bad ']'
+ echo 'Bad case: Using apparmor from proposed'
Bad case: Using apparmor from proposed
+ BADCASE=1
+ lxc stop --force testguest-apparmor-bad
+ lxc delete --force testguest-apparmor-bad
+ lxc launch ubuntu-daily:groovy/amd64 testguest-apparmor-bad --profile default 
--profile kvm
Creating testguest-apparmor-bad
Starting testguest-apparmor-bad
+ sleep 30s
+ lxc exec testguest-apparmor-bad runlevel
N 5
+ lxc exec testguest-apparmor-bad -- bash -c 'H=`cat /etc/hostname`; if [ -f 
/var/lib/cloud/instance/boot-finished ]; then echo "LXD container $H ready"; 
else echo "LXD container $H not ready yet"; exit 2; fi'
LXD container testguest-apparmor-bad ready
+ lxc exec testguest-apparmor-bad --env DEBIAN_FRONTEND=noninteractive -- bash 
-c 'apt-get --allow-unauthenticated --assume-yes -o 
Dpkg::Options::='\''--force-confdef'\'' -o 
Dpkg::Options::='\''--force-confold'\'' install apparmor-utils'
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following package was automatically installed and is no longer required:
  libfreetype6
Use 'apt autoremove' to remove it.
The following additional packages will be installed:
  python3-apparmor python3-libapparmor
Suggested packages:
  vim-addon-manager
The following NEW packages will be installed:
  apparmor-utils python3-apparmor python3-libapparmor
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 157 kB of archives.
After this operation, 966 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu groovy/main amd64 python3-libapparmor 
amd64 2.13.3-7ubuntu6 [26.7 kB]
Get:2 http://archive.ubuntu.com/ubuntu groovy/main amd64 python3-apparmor amd64 
2.13.3-7ubuntu6 [78.6 kB]
Get:3 http://archive.ubuntu.com/ubuntu groovy/main amd64 apparmor-utils amd64 
2.13.3-7ubuntu6 [51.4 kB]
Fetched 157 kB in 0s (385 kB/s)   
Selecting previously unselected package python3-libapparmor.
(Reading database ... 31714 files and directories currently installed.)
Preparing to unpack .../python3-libapparmor_2.13.3-7ubuntu6_amd64.deb ...
Unpacking python3-libapparmor (2.13.3-7ubuntu6) ...
Selecting previously unselected package python3-apparmor.
Preparing to unpack .../python3-apparmor_2.13.3-7ubuntu6_amd64.deb ...
Unpacking python3-apparmor (2.13.3-7ubuntu6) ...
Selecting previously unselected package apparmor-utils.
Preparing to unpack .../apparmor-utils_2.13.3-7ubuntu6_amd64.deb ...
Unpacking apparmor-utils (2.13.3-7ubuntu6) ...
Setting up python3-libapparmor (2.13.3-7ubuntu6) ...
Setting up python3-apparmor (2.13.3-7ubuntu6) ...
Setting up apparmor-utils (2.13.3-7ubuntu6) ...
Processing triggers for man-db (2.9.3-2) ...
+ lxc exec testguest-apparmor-bad -- aa-status
apparmor module is loaded.
28 profiles are loaded.
28 profiles are in enforce mode.
   /snap/snapd/9279/usr/lib/snapd/snap-confine
   /snap/snapd/9279/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /usr/bin/man
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/NetworkManager/nm-dhcp-helper
   /usr/lib/connman/scripts/dhclient-script
   /usr/lib/snapd/snap-confine
   /usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /{,usr/}sbin/dhclient
   lsb_release
   man_filter
   man_groff
   nvidia_modprobe
   nvidia_modprobe//kmod
   snap-update-ns.lxd
   snap.lxd.activate
   snap.lxd.benchmark
   snap.lxd.buginfo
   snap.lxd.check-kernel
   snap.lxd.daemon
   snap.lxd.hook.configure
   snap.lxd.hook.install
   snap.lxd.hook.remove
   snap.lxd.lxc
   snap.lxd.lxc-to-lxd
   snap.lxd.lxd
   snap.lxd.migrate
   tcpdump
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
+ '[' 1 -eq 1 ']'
+ lxc exec testguest-apparmor-bad -- bash -c 'echo '\''deb 
http://archive.ubuntu.com/ubuntu/ groovy-proposed restricted main multiverse 
universe'\'' >> /etc/apt/sources.list'
+ lxc exec testguest-apparmor-bad --env DEBIAN_FRONTEND=noninteractive -- bash 
-c 'apt-get --allow-unauthenticated --assume-yes -o 
Dpkg::Options::='\''--force-confdef'\'' -o 
Dpkg::Options::='\''--force-confold'\'' update'
Hit:1 http://security.ubuntu.com/ubuntu groovy-security InRelease
Get:2 http://archive.ubuntu.com/ubuntu groovy InRelease [267 kB]
Get:3 http://security.ubuntu.com/ubuntu groovy-security/universe amd64 c-n-f 
Metadata [116 B]
Get:4 http://security.ubuntu.com/ubuntu groovy-security/multiverse amd64 c-n-f 
Metadata [116 B]
Hit:5 http://archive.ubuntu.com/ubuntu groovy-updates InRelease
Get:6 http://archive.ubuntu.com/ubuntu groovy-backports InRelease [89.2 kB]
Get:7 http://archive.ubuntu.com/ubuntu groovy-proposed InRelease [118 kB]
Get:8 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages [969 kB]
Get:9 http://archive.ubuntu.com/ubuntu groovy/main Translation-en [507 kB]
Get:10 http://archive.ubuntu.com/ubuntu groovy/main amd64 

[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-22 Thread Christian Ehrhardt
It seems it comes down to a change in /lib/apparmor/apparmor.systemd
which now refuses to load profiles when running in a container.

Example with 3.0:
$ /lib/apparmor/apparmor.systemd reload
Not starting AppArmor in container

Example with 2.x
 /lib/apparmor/apparmor.systemd reload
Restarting AppArmor
Reloading AppArmor profiles 

This also explains why snap profiles work, the are loaded by snapd and
not by apparmor.service.

I'll attach a repro script and full logs of good and bad case.

** Attachment added: "repro script comparing current and proposed apparmor 
version"
   
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+attachment/5413150/+files/apparmor-repro.sh

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  Apparmor 3.0.0 does not load profiles in containers anymore

Status in apparmor package in Ubuntu:
  Confirmed

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-22 Thread Christian Ehrhardt
FYI - other testing might miss this as "starting a guest on groovy"
works with the new versions, but it will be without apparmor. Migrating
from focal or a pre-upgrade groovy shows the issues broken by apparmor
not being enabled.

** Changed in: apparmor (Ubuntu)
   Status: Incomplete => New

** Changed in: apparmor (Ubuntu)
   Importance: Low => High

** Tags added: block-proposed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

Status in apparmor package in Ubuntu:
  New

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-22 Thread Christian Ehrhardt
I have backed up this container and its snapshot for later and re-run
the whole automation which got me that bad state.

That allowed me to run my automation again without removing this
container (in case we need it for debugging later). So I ran everything
again to check if it would happen again with the version now in groovy
proposed.

Ok it ran into the same issues again so it is reproducible with the current 
version in proposed.
Since in the tests have plenty of systems involved I need to cut it down and 
simplify it to just one ...

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

Status in apparmor package in Ubuntu:
  New

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-22 Thread Christian Ehrhardt
Ok, I have definitely a snapshot left that has "conserved" the bad
state.

$ lxc stop testkvm-groovy-from
$ lxc restore testkvm-groovy-from orig
$ lxc start testkvm-groovy-from
$ lxc exec testkvm-groovy-from
# aa-status
apparmor module is loaded.
15 profiles are loaded.
15 profiles are in enforce mode.
   /snap/snapd/9279/usr/lib/snapd/snap-confine
   /snap/snapd/9279/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   snap-update-ns.lxd
   snap.lxd.activate
   snap.lxd.benchmark
   snap.lxd.buginfo
   snap.lxd.check-kernel
   snap.lxd.daemon
   snap.lxd.hook.configure
   snap.lxd.hook.install
   snap.lxd.hook.remove
   snap.lxd.lxc
   snap.lxd.lxc-to-lxd
   snap.lxd.lxd
   snap.lxd.migrate
0 profiles are in complain mode.
0 profiles are in kill mode.
0 profiles are in unconfined mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.
0 processes are in kill mode.

While silly this gets me back to normal from here
# aa-enforce /etc/apparmor.d/*
# aa-status
apparmor module is loaded.
32 profiles are loaded.
32 profiles are in enforce mode.
...


You see that we now have more than twice as much loaded

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

Status in apparmor package in Ubuntu:
  Incomplete

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-22 Thread Christian Ehrhardt
Hi Christian Bolz o/
I'd have such rules but this isn't the problem here as that would matter only 
much later.
I libvirtd itself isn't confined it refuses to go on confining the guests and 
that is here the problem.

The current question really comes down to "how did I manage to have
everything but snaps loose enforce mode"?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

Status in apparmor package in Ubuntu:
  Incomplete

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-22 Thread Christian Ehrhardt
I knew from my former tests:
1. apparmor 3.0 = bad
2. downgrading to 2.13.3-7ubuntu6 and back up to 3.0 = good
3. aa-enforce + service restart = good

I checked the logs on the affected systems how this got into the bad
state:

$ grep -E 'configure (lib)?(apparmor|libvirt)' /var/log/dpkg.log
2020-09-16 05:56:09 configure libapparmor1:amd64 3.0.0~beta1-0ubuntu1 
2020-09-16 05:56:18 configure apparmor:amd64 3.0.0~beta1-0ubuntu1 
2020-09-16 05:57:31 configure libvirt-daemon-system-systemd:amd64 
6.6.0-1ubuntu2 
2020-09-16 05:57:31 configure libvirt0:amd64 6.6.0-1ubuntu2 
2020-09-16 05:57:33 configure libvirt-clients:amd64 6.6.0-1ubuntu2 
2020-09-16 05:57:36 configure libvirt-daemon:amd64 6.6.0-1ubuntu2 
2020-09-16 05:57:36 configure libvirt-daemon-driver-qemu:amd64 6.6.0-1ubuntu2 

2020-09-16 05:57:36 configure libvirt-daemon-system:amd64 6.6.0-1ubuntu2 
2020-09-16 05:58:05 configure apparmor-utils:amd64 3.0.0~beta1-0ubuntu1 
2020-09-17 14:04:17 configure libvirt-daemon-system-dbgsym:amd64 6.6.0-1ubuntu2 

2020-09-17 14:04:17 configure libvirt0-dbgsym:amd64 6.6.0-1ubuntu2 
2020-09-17 14:04:17 configure libvirt-daemon-driver-qemu-dbgsym:amd64 
6.6.0-1ubuntu2 
2020-09-17 14:04:17 configure libvirt-clients-dbgsym:amd64 6.6.0-1ubuntu2 
2020-09-17 14:04:17 configure libvirt-daemon-dbgsym:amd64 6.6.0-1ubuntu2 
2020-09-22 06:56:34 configure apparmor:amd64 3.0.0~beta1-0ubuntu5 

It seems I had:
1. groovy container
2. upgrade to proposed (including libapparmor1 / apparmor 3.0)
3. install libvirt

I was trying to recreate the above with a new container as of today:
1. groovy container (2.13.3-7ubuntu6, all still confined)
2. upgrade to proposed (3.0.0~beta1-0ubuntu5, all still confined)
3. install libvirt (confinement working well)

Hmm, something must have been different.
I know I have used container snapshots when I ran into that - I need to sort 
out in what order that happened and if it would occur again.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

Status in apparmor package in Ubuntu:
  Incomplete

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895060] Re: [FFe] apparmor 3 upstream release

2020-09-22 Thread Christian Ehrhardt
Sorry, while being about evaluating the new apparmor this got posted to
the wrong bug :-/

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895060

Title:
  [FFe] apparmor 3 upstream release

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  As per the draft upstream release notes[1]:

  AppArmor 3.0 is a major new release of the AppArmor user space that makes
  an important change to policy development and support. Its focus is
  transitioning policy to the new features ABI and as such other new features
  have been limited.

  Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the
  newer AppArmor 3 style policy which requires the declaration of a features
  abi. As such AppArmor 3.0 will be a short lived release, and will not
  receive long term support. The following AppArmor 3.1 feature release is
  planned to be a regular release, please take this into account when
  including AppArmor 3.0 into a distro release.

  As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3
  to Ubuntu and provide these new capabilities to users and system
  administrators. The short support lifespan of Ubuntu 20.10 ensures that
  there is alignment with the limited support lifetime of AppArmor 3.0 from
  upstream, whilst giving good exposure and opportunity to test and exercise
  the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight
  of new features provided by AppArmor 3.0 include:

  - Policy now must declare the feature abi it was developed for if it is to
    use any new features. This ensures that old policy will not become
    incompatible with new kernels that support additional AppArmor features.
  - The use of profile names that are based on pathnames are deprecated.
  - Support for new kernel features (requires appropriate features abi
    tagging in policy)
    - upstream v8 network socket rules
    - xattr attachment conditionals
    - capabilities PERFMON and BPF
  - Improved compiler warnings and semantic checks
  - aa-status rewritten in C (previously was python) with additional features
    - supports use in systems/images where python is not available
    - supports kill, unconfined and mixed profile modes
  - Rewritten aa-notify (previously was perl, now python3)
    - shared backend with other python tools
    - support use of aa.CONFDIR instead of hard coded /etc/apparmor
    - improved message layout
  - Improved support for kernels that support LSM stacking
  - New utility aa-features-abi to extract and work with kernel abi features
  - New utility aa-load to load binary policy without calling the
    apparmor_parser
  - Support for profile modes
    - enforce (default when no mode flag is supplied)
    - kill (experimental)
    - unconfined (experimental)

  The use of the new AppArmor profile feature ABI includes a default
  configuration (for the Ubuntu packaged version of AppArmor proposed in this
  FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures
  that all profiles provided in AppArmor3 for groovy will conform to this
  feature set and that upgrades to the kernel version (say to 5.8) that may
  include newer AppArmor confinement features will not result in additional
  policy denials as a result (since say the existing profile did not specify
  a rule for a new AppArmor feature which is now supported by the upgraded
  kernel). This ensures that there will be no regressions in application
  behaviour as a result of AppArmor kernel feature upgrades.

  TESTING

  This has been extensively tested by the security team - this includes
  following the documented Ubuntu merges test plan[2] for AppArmor and the
  extensive QA Regression Tests[3] for AppArmor as well. This ensures that the
  various applications that make heavy use of AppArmor (LXD, docker, lxc,
  dbus, libvirt, snapd etc) have all been exercised and no regressions have
  been observed. All tests have passed and demonstrated both apparmor and the
  various applications that use it to be working as expected.

  BUILD LOGS

  This is currently uploaded to groovy-proposed, build logs can be found on
  Launchpad at:
  https://launchpad.net/ubuntu/+source/apparmor/3.0.0~beta1-0ubuntu1

  INSTALL LOG

  See attached
  
(https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+attachment/5411197/+files
  /groovy-proposed-apparmor-install.log) for a log showing install of
  the packages from groovy-proposed

  [1] https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.0
  [2] https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor
  [3] 
https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895060/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post 

[Touch-packages] [Bug 1895060] Re: [FFe] apparmor 3 upstream release

2020-09-22 Thread Christian Ehrhardt
I knew from my former tests:
1. apparmor 3.0 = bad
2. downgrading to 2.13.3-7ubuntu6 and back up to 3.0 = good
3. aa-enforce + service restart = good

I checked the logs on the affected systems how this got into the bad
state:

$ grep -E 'configure (lib)?(apparmor|libvirt)' /var/log/dpkg.log 
2020-09-16 05:56:09 configure libapparmor1:amd64 3.0.0~beta1-0ubuntu1 
2020-09-16 05:56:18 configure apparmor:amd64 3.0.0~beta1-0ubuntu1 
2020-09-16 05:57:31 configure libvirt-daemon-system-systemd:amd64 
6.6.0-1ubuntu2 
2020-09-16 05:57:31 configure libvirt0:amd64 6.6.0-1ubuntu2 
2020-09-16 05:57:33 configure libvirt-clients:amd64 6.6.0-1ubuntu2 
2020-09-16 05:57:36 configure libvirt-daemon:amd64 6.6.0-1ubuntu2 
2020-09-16 05:57:36 configure libvirt-daemon-driver-qemu:amd64 6.6.0-1ubuntu2 

2020-09-16 05:57:36 configure libvirt-daemon-system:amd64 6.6.0-1ubuntu2 
2020-09-16 05:58:05 configure apparmor-utils:amd64 3.0.0~beta1-0ubuntu1 
2020-09-17 14:04:17 configure libvirt-daemon-system-dbgsym:amd64 6.6.0-1ubuntu2 

2020-09-17 14:04:17 configure libvirt0-dbgsym:amd64 6.6.0-1ubuntu2 
2020-09-17 14:04:17 configure libvirt-daemon-driver-qemu-dbgsym:amd64 
6.6.0-1ubuntu2 
2020-09-17 14:04:17 configure libvirt-clients-dbgsym:amd64 6.6.0-1ubuntu2 
2020-09-17 14:04:17 configure libvirt-daemon-dbgsym:amd64 6.6.0-1ubuntu2 
2020-09-22 06:56:34 configure apparmor:amd64 3.0.0~beta1-0ubuntu5 


It seems I had:
1. groovy container
2. upgrade to proposed (including libapparmor1 / apparmor 3.0)
3. install libvirt

I was trying to recreate the above with a new container as of today:
1. groovy container (2.13.3-7ubuntu6, all still confined)
2. upgrade to proposed (3.0.0~beta1-0ubuntu5, all still confined)
3. install libvirt (confinement working well)

Hmm, something must have been different.
I know I have used container snapshots when I ran into that - I need to sort 
out in what order that happened and if it would occur again.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895060

Title:
  [FFe] apparmor 3 upstream release

Status in apparmor package in Ubuntu:
  Fix Committed

Bug description:
  As per the draft upstream release notes[1]:

  AppArmor 3.0 is a major new release of the AppArmor user space that makes
  an important change to policy development and support. Its focus is
  transitioning policy to the new features ABI and as such other new features
  have been limited.

  Apprmor 3.0 is a bridge release between older AppArmor 2.x policy and the
  newer AppArmor 3 style policy which requires the declaration of a features
  abi. As such AppArmor 3.0 will be a short lived release, and will not
  receive long term support. The following AppArmor 3.1 feature release is
  planned to be a regular release, please take this into account when
  including AppArmor 3.0 into a distro release.

  As such, Ubuntu 20.10 provides a great opportunity to introduce AppArmor3
  to Ubuntu and provide these new capabilities to users and system
  administrators. The short support lifespan of Ubuntu 20.10 ensures that
  there is alignment with the limited support lifetime of AppArmor 3.0 from
  upstream, whilst giving good exposure and opportunity to test and exercise
  the new features in AppArmor 3.x on the road to Ubuntu 22.04. A highlight
  of new features provided by AppArmor 3.0 include:

  - Policy now must declare the feature abi it was developed for if it is to
    use any new features. This ensures that old policy will not become
    incompatible with new kernels that support additional AppArmor features.
  - The use of profile names that are based on pathnames are deprecated.
  - Support for new kernel features (requires appropriate features abi
    tagging in policy)
    - upstream v8 network socket rules
    - xattr attachment conditionals
    - capabilities PERFMON and BPF
  - Improved compiler warnings and semantic checks
  - aa-status rewritten in C (previously was python) with additional features
    - supports use in systems/images where python is not available
    - supports kill, unconfined and mixed profile modes
  - Rewritten aa-notify (previously was perl, now python3)
    - shared backend with other python tools
    - support use of aa.CONFDIR instead of hard coded /etc/apparmor
    - improved message layout
  - Improved support for kernels that support LSM stacking
  - New utility aa-features-abi to extract and work with kernel abi features
  - New utility aa-load to load binary policy without calling the
    apparmor_parser
  - Support for profile modes
    - enforce (default when no mode flag is supplied)
    - kill (experimental)
    - unconfined (experimental)

  The use of the new AppArmor profile feature ABI includes a default
  configuration (for the Ubuntu packaged version of AppArmor proposed in this
  FFE) for the AppArmor features within the 5.4 Linux kernel - this ensures
  that all 

[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-21 Thread Christian Ehrhardt
Yeah and the comment above this function pointed the right way:

Good case (libvirt is enforced):
oot@testkvm-groovy-to:~# aa-status 
apparmor module is loaded.
31 profiles are loaded.
31 profiles are in enforce mode.
   /snap/snapd/9279/usr/lib/snapd/snap-confine
   /snap/snapd/9279/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /usr/bin/man
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/NetworkManager/nm-dhcp-helper
   /usr/lib/connman/scripts/dhclient-script
   /usr/lib/snapd/snap-confine
   /usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /{,usr/}sbin/dhclient
   libvirtd
   libvirtd//qemu_bridge_helper
   lsb_release
   man_filter
   man_groff
   nvidia_modprobe
   nvidia_modprobe//kmod
   snap-update-ns.lxd
   snap.lxd.activate
   snap.lxd.benchmark
   snap.lxd.buginfo
   snap.lxd.check-kernel
   snap.lxd.daemon
   snap.lxd.hook.configure
   snap.lxd.hook.install
   snap.lxd.hook.remove
   snap.lxd.lxc
   snap.lxd.lxc-to-lxd
   snap.lxd.lxd
   snap.lxd.migrate
   tcpdump
   virt-aa-helper
0 profiles are in complain mode.
0 profiles are in kill mode.
0 profiles are in unconfined mode.
1 processes have profiles defined.
1 processes are in enforce mode.
   /usr/sbin/libvirtd (14751) libvirtd
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.
0 processes are in kill mode.


Bad case libvirt (and plenty of other things) are not confined:
# aa-status 
apparmor module is loaded.
15 profiles are loaded.
15 profiles are in enforce mode.
   /snap/snapd/9279/usr/lib/snapd/snap-confine
   /snap/snapd/9279/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   snap-update-ns.lxd
   snap.lxd.activate
   snap.lxd.benchmark
   snap.lxd.buginfo
   snap.lxd.check-kernel
   snap.lxd.daemon
   snap.lxd.hook.configure
   snap.lxd.hook.install
   snap.lxd.hook.remove
   snap.lxd.lxc
   snap.lxd.lxc-to-lxd
   snap.lxd.lxd
   snap.lxd.migrate
0 profiles are in complain mode.
0 profiles are in kill mode.
0 profiles are in unconfined mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.
0 processes are in kill mode.


As if only snap profiles are loaded.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

Status in apparmor package in Ubuntu:
  Incomplete

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-21 Thread Christian Ehrhardt
This gets me back to a working system
  $ aa-enforce /etc/apparmor.d/usr.sbin.libvirtd
  $ systemctl restart libvirtd

And this also explains why on the system where I re-installed libvirt things 
might have worked.
The re-install runs dh_apparmor which has loaded and enforced it.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

Status in apparmor package in Ubuntu:
  Incomplete

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-21 Thread Christian Ehrhardt
Sorry my system broke down in various way stalling debugging of this for a few 
days.
Back on it ...

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

Status in apparmor package in Ubuntu:
  Incomplete

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-17 Thread Christian Ehrhardt
This is the failing function

 221 /* returns -1 on error or profile for libvirtd is unconfined, 0 if 
complain  
 222  * mode and 1 if enforcing. This is required because at present you cannot 
  
 223  * aa_change_profile() from a process that is unconfined.  
  
 224  */
  
 225 static int 
  
 226 use_apparmor(void) 
  
 227 {  
  
 228 int rc = -1;   
  
 229 char *libvirt_daemon = NULL;   
  
 230
  
 231 if (virFileResolveLink("/proc/self/exe", _daemon) < 0) {   
  
 232 virReportError(VIR_ERR_INTERNAL_ERROR, 
  
 233"%s", _("could not find libvirtd"));
  
 234 return rc; 
  
 235 }  
  
 236
  
 237 /* If libvirt_lxc is calling us, then consider apparmor is used
  
 238  * and enforced. */
  
 239 if (strstr(libvirt_daemon, "libvirt_lxc")) 
  
 240 return 1;  
  
 241
  
 242 if (access(APPARMOR_PROFILES_PATH, R_OK) != 0) 
  
 243 goto cleanup;  
  
 244
  
 245 /* First check profile status using full binary path. If that fails
  
 246  * check using profile name.   
  
 247  */
  
 248 rc = profile_status(libvirt_daemon, 1);
  
 249 if (rc < 0) {  
  
 250 rc = profile_status("libvirtd", 1);
  
 251 /* Error or unconfined should all result in -1 */  
  
 252 if (rc < 0)
  
 253 rc = -1;   
  
 254 }  
  
 255
  
 256  cleanup:  
  
 257 VIR_FREE(libvirt_daemon);  
  
 258 return rc; 
  
 259 }

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

Status in apparmor package in Ubuntu:
  Incomplete

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it 

[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-17 Thread Christian Ehrhardt
Lookup fails:

(gdb) fin
Run till exit from #0  virSecurityDriverLookup (name=name@entry=0x0, 
virtDriver=virtDriver@entry=0x7fffd26ae1b2 "QEMU") at 
../../../src/security/security_driver.c:50
virSecurityManagerNew (name=name@entry=0x0, 
virtDriver=virtDriver@entry=0x7fffd26ae1b2 "QEMU", flags=flags@entry=10) at 
../../../src/security/security_manager.c:182
182 ../../../src/security/security_manager.c: No such file or directory.
Value returned is $2 = (virSecurityDriver *) 0x77fad4c0 



This goes via
AppArmorSecurityManagerProbe

Good:
Value returned is $3 = 0

Bad:
Value returned is $5 = -2

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

Status in apparmor package in Ubuntu:
  Incomplete

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-17 Thread Christian Ehrhardt
Need to check the init of the bunch in qemuSecurityInit and qemuSecurityNew.
But that happens at daemon start and not later when probing caps.


virQEMUDriverConfigLoadSecurityEntry load this from config and it  includes 
apparmor in both:
/etc/libvirt/qemu.conf:#   security_driver = [ "selinux", "apparmor" ]


So the initialization must go wrong in the bad case.

virSecurityManagerNew loooks up the driver via virSecurityDriverLookup(name, 
virtDriver);
Then it calls virSecurityManagerNewDriver


Already differs here:
bad:
Thread 17 "daemon-init" hit Breakpoint 1, virSecurityManagerNew 
(name=name@entry=0x0, virtDriver=virtDriver@entry=0x7fffea6ae1b2 "QEMU", 
flags=flags@entry=10)
at ../../../src/security/security_manager.c:180
180 ../../../src/security/security_manager.c: No such file or directory.
(gdb) c
Continuing.

Thread 17 "daemon-init" hit Breakpoint 2, virSecurityDriverLookup 
(name=name@entry=0x0, virtDriver=virtDriver@entry=0x7fffea6ae1b2 "QEMU") at 
../../../src/security/security_driver.c:50
50  ../../../src/security/security_driver.c: No such file or directory.
(gdb) c
Continuing.

Thread 17 "daemon-init" hit Breakpoint 3, virSecurityManagerNewDriver 
(drv=0x77fad4c0 , 
virtDriver=virtDriver@entry=0x7fffea6ae1b2 "QEMU", flags=8)
at ../../../src/security/security_manager.c:78
78  ../../../src/security/security_manager.c: No such file or directory.
(gdb) c
Continuing.

Thread 17 "daemon-init" hit Breakpoint 3, virSecurityManagerNewDriver 
(drv=0x77fad640 , virtDriver=0x7fffea6ae1b2 "QEMU", 
flags=flags@entry=8)
at ../../../src/security/security_manager.c:78
78  in ../../../src/security/security_manager.c


Good:
Thread 17 "daemon-init" hit Breakpoint 1, virSecurityManagerNew 
(name=name@entry=0x0, virtDriver=virtDriver@entry=0x7f694365e1b2 "QEMU", 
flags=flags@entry=10)
at ../../../src/security/security_manager.c:180
180 ../../../src/security/security_manager.c: No such file or directory.
(gdb) c
Continuing.

Thread 17 "daemon-init" hit Breakpoint 2, virSecurityDriverLookup 
(name=name@entry=0x0, virtDriver=virtDriver@entry=0x7f694365e1b2 "QEMU") at 
../../../src/security/security_driver.c:50
50  ../../../src/security/security_driver.c: No such file or directory.
(gdb) c
Continuing.

Thread 17 "daemon-init" hit Breakpoint 3, virSecurityManagerNewDriver 
(drv=0x7f694ff5cae0 , 
virtDriver=virtDriver@entry=0x7f694365e1b2 "QEMU", flags=10)
at ../../../src/security/security_manager.c:78
78  ../../../src/security/security_manager.c: No such file or directory.
(gdb) c
Continuing.

Thread 17 "daemon-init" hit Breakpoint 3, virSecurityManagerNewDriver 
(drv=0x7f694ff5c640 , virtDriver=0x7f694365e1b2 "QEMU", 
flags=flags@entry=10)
at ../../../src/security/security_manager.c:78
78  in ../../../src/security/security_manager.c


P.S. I might need a debug build going further yet I'm unsure if installing that 
might change the bug conditions.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

Status in apparmor package in Ubuntu:
  Incomplete

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: 

[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-17 Thread Christian Ehrhardt
Good:
(gdb) p *((virSecurityStackDataPtr)(((virQEMUDriverPtr)conn->privateData 
)->securityManager->privateData))->itemsHead->securityManager
$7 = {parent = {parent = {parent_instance = {g_type_instance = {g_class = 
0x7f430805ddf0}, ref_count = 1, qdata = 0x0}}, lock = {lock = {__data = {__lock 
= 0, __count = 0, __owner = 0, 
  __nusers = 0, __kind = 512, __spins = 0, __elision = 0, __list = 
{__prev = 0x0, __next = 0x0}}, __size = '\000' , "\002", 
'\000' , 
__align = 0}}}, drv = 0x7f435aadfae0 , flags 
= 10, virtDriver = 0x7f43541e71b2 "QEMU", privateData = 0x0}
(gdb) p *((virSecurityStackDataPtr)(((virQEMUDriverPtr)conn->privateData 
)->securityManager->privateData))->itemsHead->next->securityManager
$8 = {parent = {parent = {parent_instance = {g_type_instance = {g_class = 
0x7f430805ddf0}, ref_count = 1, qdata = 0x0}}, lock = {lock = {__data = {__lock 
= 0, __count = 0, __owner = 0, 
  __nusers = 0, __kind = 512, __spins = 0, __elision = 0, __list = 
{__prev = 0x0, __next = 0x0}}, __size = '\000' , "\002", 
'\000' , 
__align = 0}}}, drv = 0x7f435aadf7c0 , flags = 
10, virtDriver = 0x7f43541e71b2 "QEMU", privateData = 0x7f430807b180}


Bad:
(gdb) p *((virSecurityStackDataPtr)(((virQEMUDriverPtr)conn->privateData 
)->securityManager->privateData))->itemsHead->securityManager
$9 = {parent = {parent = {parent_instance = {g_type_instance = {g_class = 
0x7f8b0c0259e0}, ref_count = 1, qdata = 0x0}}, lock = {lock = {__data = {__lock 
= 0, __count = 0, __owner = 0, 
  __nusers = 0, __kind = 512, __spins = 0, __elision = 0, __list = 
{__prev = 0x0, __next = 0x0}}, __size = '\000' , "\002", 
'\000' , 
__align = 0}}}, drv = 0x7f8b572d24c0 , flags = 8, 
virtDriver = 0x7f8b501d91b2 "QEMU", privateData = 0x0}
(gdb) p *((virSecurityStackDataPtr)(((virQEMUDriverPtr)conn->privateData 
)->securityManager->privateData))->itemsHead->next->securityManager
$10 = {parent = {parent = {parent_instance = {g_type_instance = {g_class = 
0x7f8b0c0259e0}, ref_count = 1, qdata = 0x0}}, lock = {lock = {__data = {__lock 
= 0, __count = 0, __owner = 0, 
  __nusers = 0, __kind = 512, __spins = 0, __elision = 0, __list = 
{__prev = 0x0, __next = 0x0}}, __size = '\000' , "\002", 
'\000' , 
__align = 0}}}, drv = 0x7f8b572d27c0 , flags = 
10, virtDriver = 0x7f8b501d91b2 "QEMU", privateData = 0x7f8b0c07add0}


See virSecurityDriverNop vs virAppArmorSecurityDriver in the above
output

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

Status in apparmor package in Ubuntu:
  Incomplete

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-17 Thread Christian Ehrhardt
for (i = 0; sec_managers[i]; i++) {
...
   VIR_DEBUG("Initialized caps for security driver \"%s\" with "

Good:
- apparmor
- dac

Bad:
- none
- dac

In function virQEMUDriverCreateCapabilities.
So it isn't probing apparmor because it isn't even in the list.

That list is from "qemuSecurityGetNested"
qemuSecurityGetNested == virSecurityManagerGetNested
-> virSecurityStackGetNested(mgr)

The latter iterates on the list priv->itemsHead which is from the
security manager.

That in turn is from driver->securityManager of
virQEMUDriverGetCapabilities(driver)
 virCapsPtr virQEMUDriverCreateCapabilities(virQEMUDriverPtr driver)

(gdb) bt
#0  virSecurityStackGetNested (mgr=mgr@entry=0x7f8b0c00dde0) at 
../../../src/security/security_stack.c:613
#1  0x7f8b5704f2b8 in virSecurityManagerGetNested (mgr=0x7f8b0c00dde0) at 
../../../src/security/security_manager.c:1035
#2  0x7f8b50133970 in virQEMUDriverCreateCapabilities 
(driver=0x7f8b0c051550) at ../../../src/qemu/qemu_conf.c:1344
#3  0x7f8b50133c18 in virQEMUDriverGetCapabilities (driver=0x7f8b0c051550, 
refresh=) at ../../../src/qemu/qemu_conf.c:1397
#4  0x7f8b5019e0b8 in qemuConnectGetCapabilities (conn=) at 
../../../src/qemu/qemu_driver.c:1328
#5  0x7f8b57171953 in virConnectGetCapabilities (conn=0x7f8b28004050) at 
../../../src/libvirt-host.c:467
#6  0xa51f16ec in remoteDispatchConnectGetCapabilities 
(server=0xa5c1d080, msg=0xa5c2bc80, ret=0x7f8b48000e60, 
rerr=0x7f8b51be6920, client=0xa5c2c070)
at ./remote/remote_daemon_dispatch_stubs.h:766
#7  remoteDispatchConnectGetCapabilitiesHelper (server=0xa5c1d080, 
client=0xa5c2c070, msg=0xa5c2bc80, rerr=0x7f8b51be6920, args=0x0, 
ret=0x7f8b48000e60)
at ./remote/remote_daemon_dispatch_stubs.h:748
#8  0x7f8b5707d470 in virNetServerProgramDispatchCall (msg=0xa5c2bc80, 
client=0xa5c2c070, server=0xa5c1d080, prog=0xa5c25810)
at ../../../src/rpc/virnetserverprogram.c:430
#9  virNetServerProgramDispatch (prog=0xa5c25810, 
server=server@entry=0xa5c1d080, client=0xa5c2c070, msg=0xa5c2bc80) 
at ../../../src/rpc/virnetserverprogram.c:302
#10 0x7f8b570825a8 in virNetServerProcessMsg (msg=, 
prog=, client=, srv=0xa5c1d080) at 
../../../src/rpc/virnetserver.c:137
#11 virNetServerHandleJob (jobOpaque=0xa5bf97f0, opaque=0xa5c1d080) at 
../../../src/rpc/virnetserver.c:154
#12 0x7f8b56f901e2 in virThreadPoolWorker (opaque=) at 
../../../src/util/virthreadpool.c:163
#13 0x7f8b56f8f769 in virThreadHelper (data=) at 
../../../src/util/virthread.c:233
#14 0x7f8b56c61590 in start_thread (arg=0x7f8b51be7640) at 
pthread_create.c:463
#15 0x7f8b56b6c223 in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

Status in apparmor package in Ubuntu:
  Incomplete

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] Re: 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-17 Thread Christian Ehrhardt
It seems once fixed the system is ok and I can't get into the bad state
again :/

I tried on another bad system (withotu changing back to the former version)
1. A restart of the service
2. Trying to force capabilities reset (remove cache) + service restart

None of these got it into the good case, so I might be able to debug
here what happens when probing.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

Status in apparmor package in Ubuntu:
  Incomplete

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895967] [NEW] 3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

2020-09-17 Thread Christian Ehrhardt
Public bug reported:

Hi,
I stumbled over this due to automatic tests checking proposed.
I found that Focal no more could migrate to Groovy with:

$ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
error: unsupported configuration: Security driver model 'apparmor' is not 
available

I looked after it and found that while all former releases detected
apparmor correctly:

$ virsh capabilities | grep -C 3 secmodel

  


  apparmor
  0


  dac
  0
  +64055:+108
  +64055:+108


Now on groovy that didn't work anymore:


  none
  0


  dac
  0
  +64055:+108
  +64055:+108


Since 3.0 is only in proposed:
# apt-cache policy apparmor
apparmor:
  Installed: 2.13.3-7ubuntu6
  Candidate: 3.0.0~beta1-0ubuntu1
  Version table:
 3.0.0~beta1-0ubuntu1 500
500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages
 *** 2.13.3-7ubuntu6 500
500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
100 /var/lib/dpkg/status
I installed the former version.


$ apt install apparmor=2.13.3-7ubuntu6
$ rm /var/cache/libvirt/qemu/capabilities/*
$ systemctl restart libvirtd

And it works again.

Interestingly going back to 3.0 then works and keeps working.
Therefore maybe it is a red-herring and I'll consider it incomplete & low prio 
for now until I know more (allowing others that might see the same to find this 
bug and chime in).

** Affects: apparmor (Ubuntu)
 Importance: Low
 Status: Incomplete

** Changed in: apparmor (Ubuntu)
   Status: New => Incomplete

** Changed in: apparmor (Ubuntu)
   Importance: Undecided => Low

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1895967

Title:
  3.0.0~beta1-0ubuntu1 in Groovy breaks Libvirt/Qemu/KVM

Status in apparmor package in Ubuntu:
  Incomplete

Bug description:
  Hi,
  I stumbled over this due to automatic tests checking proposed.
  I found that Focal no more could migrate to Groovy with:

  $ virsh migrate --unsafe --live fguest qemu+ssh://10.162.30.163/system
  error: unsupported configuration: Security driver model 'apparmor' is not 
available

  I looked after it and found that while all former releases detected
  apparmor correctly:

  $ virsh capabilities | grep -C 3 secmodel
  

  
  
apparmor
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Now on groovy that didn't work anymore:

  
none
0
  
  
dac
0
+64055:+108
+64055:+108
  

  Since 3.0 is only in proposed:
  # apt-cache policy apparmor
  apparmor:
Installed: 2.13.3-7ubuntu6
Candidate: 3.0.0~beta1-0ubuntu1
Version table:
   3.0.0~beta1-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu groovy-proposed/main amd64 
Packages
   *** 2.13.3-7ubuntu6 500
  500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages
  100 /var/lib/dpkg/status
  I installed the former version.

  
  $ apt install apparmor=2.13.3-7ubuntu6
  $ rm /var/cache/libvirt/qemu/capabilities/*
  $ systemctl restart libvirtd

  And it works again.

  Interestingly going back to 3.0 then works and keeps working.
  Therefore maybe it is a red-herring and I'll consider it incomplete & low 
prio for now until I know more (allowing others that might see the same to find 
this bug and chime in).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1895967/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1894619] Re: [2.82 regression] router announcements have 'forever' lifetime by default

2020-09-17 Thread Christian Ehrhardt
The tests confirmed the issue that Iain reported and that the fix works.
Also no other issues popped up in the NM test using it.
autopkgtest [08:47:12]:  summary
wpa-dhclient PASS
nm.pyPASS
killswitches-no-urfkill PASS
urfkill-integration  PASS

And while https://bileto.ubuntu.com/excuses/4266/groovy.html looks
pretty bad after we skip the known badtests not much is left and of
those nothing seems to be due to this change.

I replied upstream hoping they will accept the change so we can then push it to 
groovy (sooner or later we have to even without upstream saying "yes" but I'd 
prefer to pick exactly what is committed).
=> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q3/014387.html

Actually since this holds back other things, let us upload to groovy now
(it essentially reverts to old behavior) but come back in a week to
potentially update to whatever upstream did by then.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1894619

Title:
  [2.82 regression] router announcements have 'forever' lifetime by
  default

Status in dnsmasq package in Ubuntu:
  Triaged

Bug description:
  The default lifetime was changed to 1 day in 2.82 in the change
  corresponding to this changelog entry:

  Change default lease time for DHCPv6 to one day.

  Fine, but the same commit also did this:

Alter calculation of preferred and valid times in router
advertisements, so that these do not have a floor applied
of the lease time in the dhcp-range if this is not explicitly
specified and is merely the default.

  And that change is buggy and causes advertisements to have infinite
  lifetime, when you are using the default.

  See this thread

http://lists.thekelleys.org.uk/pipermail/dnsmasq-
  discuss/2020q3/014341.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1894619/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1895576] Re: boot-and-services in tests-in-lxd autopkgtest fails in groovy on s390x

2020-09-17 Thread Christian Ehrhardt
For now the hint is in groovy, but the next systemd upload needs to
resolve it one (fix) or the other (mark this one as flaky) way.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1895576

Title:
  boot-and-services in tests-in-lxd autopkgtest fails in groovy on s390x

Status in systemd package in Ubuntu:
  New

Bug description:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-
  groovy/groovy/s390x/s/systemd/20200903_184028_2bbdf@/log.gz

  ...
  test_rsyslog (__main__.ServicesTest) ... FAIL
  test_tmp_cleanup (__main__.ServicesTest) ... ok
  test_tmp_mount (__main__.ServicesTest) ... ok
  test_udev (__main__.ServicesTest) ... skipped 'udev does not work in 
containers'

  ==
  FAIL: test_rsyslog (__main__.ServicesTest)
  --
  Traceback (most recent call last):
File 
"/tmp/autopkgtest.15TVnz/build.ZVh/real-tree/debian/tests/boot-and-services", 
line 120, in test_rsyslog
  self.assertRegex(log, 'systemd.*Reached target Graphical Interface')
  ...

  Interestingly it does not fail locally on an s390x Focal VM running 
boot-and-services in LXD.
  Kernel:
  Linux juju-d7a408-generic-21 5.4.0-14-generic 

  Also interestingly it is passing with cryptsetup/2:2.3.3-1ubuntu5
  glibc/2.32-0ubuntu2.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1895576/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1894619] Re: [2.82 regression] router announcements have 'forever' lifetime by default

2020-09-16 Thread Christian Ehrhardt
FYI: builds complete - Running the test builds of network-
manager_1.26.2-1ubuntu1.dsc in groovy against the proposed and the PPA
version.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1894619

Title:
  [2.82 regression] router announcements have 'forever' lifetime by
  default

Status in dnsmasq package in Ubuntu:
  Triaged

Bug description:
  The default lifetime was changed to 1 day in 2.82 in the change
  corresponding to this changelog entry:

  Change default lease time for DHCPv6 to one day.

  Fine, but the same commit also did this:

Alter calculation of preferred and valid times in router
advertisements, so that these do not have a floor applied
of the lease time in the dhcp-range if this is not explicitly
specified and is merely the default.

  And that change is buggy and causes advertisements to have infinite
  lifetime, when you are using the default.

  See this thread

http://lists.thekelleys.org.uk/pipermail/dnsmasq-
  discuss/2020q3/014341.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1894619/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1894619] Re: [2.82 regression] router announcements have 'forever' lifetime by default

2020-09-16 Thread Christian Ehrhardt
Ok changed MP and PPA to work for 1.0 source

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1894619

Title:
  [2.82 regression] router announcements have 'forever' lifetime by
  default

Status in dnsmasq package in Ubuntu:
  Triaged

Bug description:
  The default lifetime was changed to 1 day in 2.82 in the change
  corresponding to this changelog entry:

  Change default lease time for DHCPv6 to one day.

  Fine, but the same commit also did this:

Alter calculation of preferred and valid times in router
advertisements, so that these do not have a floor applied
of the lease time in the dhcp-range if this is not explicitly
specified and is merely the default.

  And that change is buggy and causes advertisements to have infinite
  lifetime, when you are using the default.

  See this thread

http://lists.thekelleys.org.uk/pipermail/dnsmasq-
  discuss/2020q3/014341.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1894619/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1894619] Re: [2.82 regression] router announcements have 'forever' lifetime by default

2020-09-16 Thread Christian Ehrhardt
Arrr 1.0 source, need to apply differently 

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1894619

Title:
  [2.82 regression] router announcements have 'forever' lifetime by
  default

Status in dnsmasq package in Ubuntu:
  Triaged

Bug description:
  The default lifetime was changed to 1 day in 2.82 in the change
  corresponding to this changelog entry:

  Change default lease time for DHCPv6 to one day.

  Fine, but the same commit also did this:

Alter calculation of preferred and valid times in router
advertisements, so that these do not have a floor applied
of the lease time in the dhcp-range if this is not explicitly
specified and is merely the default.

  And that change is buggy and causes advertisements to have infinite
  lifetime, when you are using the default.

  See this thread

http://lists.thekelleys.org.uk/pipermail/dnsmasq-
  discuss/2020q3/014341.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1894619/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1894619] Re: [2.82 regression] router announcements have 'forever' lifetime by default

2020-09-16 Thread Christian Ehrhardt
BTW I randomly picked the latter patch of the two as no one seems to
have jumped on the first one and said "yes let us apply it".

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1894619

Title:
  [2.82 regression] router announcements have 'forever' lifetime by
  default

Status in dnsmasq package in Ubuntu:
  Triaged

Bug description:
  The default lifetime was changed to 1 day in 2.82 in the change
  corresponding to this changelog entry:

  Change default lease time for DHCPv6 to one day.

  Fine, but the same commit also did this:

Alter calculation of preferred and valid times in router
advertisements, so that these do not have a floor applied
of the lease time in the dhcp-range if this is not explicitly
specified and is merely the default.

  And that change is buggy and causes advertisements to have infinite
  lifetime, when you are using the default.

  See this thread

http://lists.thekelleys.org.uk/pipermail/dnsmasq-
  discuss/2020q3/014341.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1894619/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1894619] Re: [2.82 regression] router announcements have 'forever' lifetime by default

2020-09-16 Thread Christian Ehrhardt
The patch suggested at 
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q3/014346.html 
isn't applied yet.
I guess this waits for feedback if it worked before they apply it.

To get this going here a PPA and an associated MP:
PPA: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4266
MP: 
https://code.launchpad.net/~paelzer/ubuntu/+source/dnsmasq/+git/dnsmasq/+merge/390832

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1894619

Title:
  [2.82 regression] router announcements have 'forever' lifetime by
  default

Status in dnsmasq package in Ubuntu:
  Triaged

Bug description:
  The default lifetime was changed to 1 day in 2.82 in the change
  corresponding to this changelog entry:

  Change default lease time for DHCPv6 to one day.

  Fine, but the same commit also did this:

Alter calculation of preferred and valid times in router
advertisements, so that these do not have a floor applied
of the lease time in the dhcp-range if this is not explicitly
specified and is merely the default.

  And that change is buggy and causes advertisements to have infinite
  lifetime, when you are using the default.

  See this thread

http://lists.thekelleys.org.uk/pipermail/dnsmasq-
  discuss/2020q3/014341.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1894619/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1892559] Re: [MIR] ccid libpam-pkcs1 libpcsc-perl opensc pcsc-tools pcsc-lite

2020-09-16 Thread Christian Ehrhardt
Sorry, I forgot to update one section for pcsc-lite on packaging:

- important open bugs (crashers, etc) in Debian or Ubuntu

There are quite some:
https://bugs.launchpad.net/ubuntu/+source/pcsc-lite/+bugs?field.searchtext=crash=Search%3Alist=NEW%3Alist=INCOMPLETE_WITH_RESPONSE%3Alist=INCOMPLETE_WITHOUT_RESPONSE%3Alist=CONFIRMED%3Alist=TRIAGED%3Alist=INPROGRESS%3Alist=FIXCOMMITTED=_reporter=_dupes=on_patch=_no_package==-date_last_updated=0

Also this one should be fixed or at least checked
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930530

I have already had that in my overall summary, just the details were
missing.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pcsc-lite in Ubuntu.
https://bugs.launchpad.net/bugs/1892559

Title:
  [MIR] ccid libpam-pkcs1 libpcsc-perl opensc pcsc-tools pcsc-lite

Status in ccid package in Ubuntu:
  New
Status in opensc package in Ubuntu:
  Incomplete
Status in pam-pkcs11 package in Ubuntu:
  New
Status in pcsc-lite package in Ubuntu:
  New
Status in pcsc-perl package in Ubuntu:
  Invalid
Status in pcsc-tools package in Ubuntu:
  Invalid

Bug description:
  ==> ccid <==
  [Availability]
  ccid is in universe, and builds on all architectures.

  [Rationale]
  The desktop team and security team are interested in bringing smartcard
  authentication to enterprise desktop environments.

  [Security]
  No CVEs for ccid are listed in our database.
  Doesn't appear to bind to a socket.
  No privileged executables, but does have udev rules.
  Probably needs a security review.

  [Quality assurance]
  No test suite.
  Does require odd hardware that we'll probably need to buy.
  I don't see debconf questions.
  ccid is well maintained in Debian by upstream author.
  One open wishlist bug in BTS, harmless.

  One open bug in launchpad, not security, but looks very frustrating
  for the users. The upstream author was engaged but it never reached
  resolution.  https://bugs.launchpad.net/ubuntu/+source/ccid/+bug/1175465

  Has a debian/watch file.
  Quilt packaging.

  P: ccid source: no-dep5-copyright
  P: ccid source: package-uses-experimental-debhelper-compat-version 13

  [Dependencies]
  Minimal dependencies, in main

  [Standards compliance]
  Appears to satisfy FHS and Debian policy

  [Maintenance]
  The desktop team will subscribe to bugs, however it is expected that the
  security team will assist with security-relevant questions.

  [Background information]
  ccid provides drivers to interact with usb-connected smart card readers.

  ==> libpam-pkcs11 <==
  [Availability]
  Source package pam-pkcs11 is in universe and builds on all architectures.

  [Rationale]
  The desktop team and security team are interested in bringing smartcard
  authentication to enterprise desktop environments.

  [Security]
  No CVEs in our database.
  Doesn't appear to bind to sockets.
  No privileged executables (but is a PAM module).
  As a PAM module this will require a security review.

  [Quality assurance]
  The package does not call pam-auth-update in its postinst #1650366
  Does not ask questions during install.
  One Ubuntu bug claims very poor behaviour if a card isn't plugged in.
  No Debian bugs.
  Occasional updates in Debian by long-term maintainer.
  Does require odd hardware that we'll probably need to buy.
  Does not appear to run tests during build.
  Has scary warnings in the build logs.
  Has a debian/watch file.

  Ancient standards version; other smaller lintian messages, mostly
  documentation problems.

  Quilt packaging.

  [Dependencies]
  Depends on libcurl4, libldap-2.4-2, libpam0g, libpcsclite1, libssl1.1
  All are in main.

  [Standards compliance]
  The package does not call pam-auth-update in its postinst #1650366
  Otherwise looks to conform to FHS and Debian policies

  [Maintenance]
  The desktop team will subscribe to bugs, however it is expected that the
  security team will assist with security-relevant questions.

  [Background information]
  This PAM module can use CRLs and full-chain verification of certificates.
  It can also do LDAP, AD, and Kerberos username mapping.

  ==> libpcsc-perl <==
  [Availability]
  Source package pcsc-perl is in universe, builds for all architectures,
  plus i386

  [Rationale]
  The desktop team and security team are interested in bringing smartcard
  authentication to enterprise desktop environments.

  [Security]
  There are no cves for pcsc-perl in our database.
  No privileged executables.
  Doesn't appear to bind to sockets.
  Probably needs a security review.

  [Quality assurance]
  Library package not intended to be used directly.
  No debconf questions.
  No bugs in Debian.
  No bugs in Ubuntu.
  Does require odd hardware that we'll probably need to buy.
  Tests exist, not run during the build; probably can't run during the build.
  Includes debian/watch file.
  A handful of lintian issues
  Quilt packaging.

  [Dependencies]
  

[Touch-packages] [Bug 1892559] Re: [MIR] ccid libpam-pkcs1 libpcsc-perl opensc pcsc-tools pcsc-lite

2020-09-16 Thread Christian Ehrhardt
## pcsc-lite ##

[Summary]
Mir Team ACK under the condition that the required TODOs are resolved.
While the owning Team should look at that security can already start
a review.

This does need a security review, so I'll assign ubuntu-security

list specific binary packages to be promoted to main: pcscd,
libpcsclite1

Clarifications:
- @Seth - the filing is done as if one would only need libpcsclite1 but Joy
  said in comment #12 that pcscd is also needed.
  Could you clarify which is true as the security risk increases if we add
  the daemon as well.
  For now I'll go on as if the daemon would be part of it.

Required TODOs:
- The package has no team bug subscriber - please fix
- Please look into open bugs and crashes before we promote.
  Do a bug-scrub and ensure we know what is outdated and no more true
  and what else is still an issue. This can be seen as preview to the
  latter maintenance - so don't skip all of them due to "don't have
  the HW" :-)

[Duplication]
There is no other package in main providing the same functionality.
Note: Joy checked if the other bits can do it without but it is required.
See comment #12.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- one -dev package that will be auto-promoted but no bad deps from there

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking

[Security]
OK:
- history of CVEs does not look too concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop

Problems:
- does parse data formats
- does open a port
- does deal with system authentication (eg, pam), etc)

This needs a security review, before doing so please clarify if the daemon
pcscsd is part of the scope.

[Common blockers]
OK:
- does not FTBFS currently
- no translation present, but none needed for this case (user visible)?
- not a python/go package, no extra constraints to consider int hat regard

Problems:
- does not have a test suite that runs at build time
- does not have a test suite that runs as autopkgtest
  We have talked about tests before, no reason to re-iterate
- The package has no team bug subscriber - please fix

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking is in place
- d/watch is present and looks ok
- Upstream update history is good
- Debian/Ubuntu update history is good
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- Does not have Built-Using

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks

** Changed in: pcsc-lite (Ubuntu)
 Assignee: Christian Ehrhardt  (paelzer) => Ubuntu Security Team 
(ubuntu-security)

** Bug watch added: Debian Bug tracker #930530
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930530

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pcsc-lite in Ubuntu.
https://bugs.launchpad.net/bugs/1892559

Title:
  [MIR] ccid libpam-pkcs1 libpcsc-perl opensc pcsc-tools pcsc-lite

Status in ccid package in Ubuntu:
  New
Status in opensc package in Ubuntu:
  Incomplete
Status in pam-pkcs11 package in Ubuntu:
  New
Status in pcsc-lite package in Ubuntu:
  New
Status in pcsc-perl package in Ubuntu:
  Invalid
Status in pcsc-tools package in Ubuntu:
  Invalid

Bug description:
  ==> ccid <==
  [Availability]
  ccid is in universe, and builds on all architectures.

  [Rationale]
  The desktop team and security team are interested in bringing smartcard
  authentication to enterprise desktop environments.

  [Security]
  No CVEs for ccid are listed in our database.
  Doesn't appear to bind to a socket.
  No privileged executables, but does have udev rules.
  Probably needs a security review.

  [Quality assurance]
  No test suite.
  Does require odd hardware that we'll probably need to buy.
  I don't see debconf questions.
  ccid is well maintained in Debian by upstream author.
  One open wishlist bug in BTS, harmless.

  One open bug in launchpad, not security, but looks very frustrating
  for the users. The upstream author was engaged but it never reached
  resolution.  https://bugs.launchpad.net/ubuntu/+source/ccid/+bug/1175465

  Has a debian/watch file.
  Quilt packaging.

  P: ccid source: no-dep5-copyright
  P: ccid source: package-uses-experimental-debhelper-compat-version 13

  [Dependencies]
  Minimal dependencies, in

  1   2   3   4   5   6   7   8   9   >