Hello everyone and thank you very much for detailed feedback. I am going
to purse the path you recommended, that is, a separate packages for
keyrings and APT configuration. It definitely makes more sense than
this script.
What should we do with the package in Plucky though?
--
You received this
Hello Timo. I've performed the verification on jammy and noble by
installing the package from proposed, then checking whether the package
cuda-toolkit has NVIDIA maintainers, and then checking that there is a
NVIDIA repository with policy 400.
--
You received this bug notification because you are
** Tags removed: verification-needed-jammy verification-needed-noble
** Tags added: verification-done verification-done-jammy verification-done-noble
** Tags removed: verification-done
** Attachment added: "Script to preform verification"
https://bugs.launchpad.net/ubuntu/+source/add-nvidia-r
** Attachment added: "Verification output"
https://bugs.launchpad.net/ubuntu/+source/add-nvidia-repositories/+bug/2089830/+attachment/5858921/+files/add-nvidia-repositories-sru-verification
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to U
** Description changed:
[ Impact ]
* add-nvidia-repositories is a convenience tool for enabling NVIDIA
repositories. It's targeted primarily to users who need to use NVIDIA
CUDA and other libraries for artificial intelligence / machine learning
/ GPU compute tasks. It is our understa
Public bug reported:
[ Impact ]
* add-nvidia-repositories is a convenience tool for enabling NVIDIA
repositories. It's targeted primarily to users who need to use NVIDIA
CUDA and other libraries for artificial intelligence / machine learning
/ GPU compute tasks. It is our understanding that majo
Public bug reported:
Request for package: add-nvidia-repositories
PPA: https://launchpad.net/~virtustom/+archive/ubuntu/add-nvidia-repositories
Source (native):
https://code.launchpad.net/~cloud-images/cloud-images/+git/add-nvidia-repositories
add-nvidia-repositories provides a script that slig
** Description changed:
A CPC test build of a jammy image with 6.8 edge kernel revealed that
AppArmor profiles are missing for 6.8 kernel in livecd-rootfs, leading
to fall back to generic AppArmor profiles which don't contain
configuration for io_uring. This leads to `snap debug seeding` o
Public bug reported:
A CPC test build of a jammy image with 6.8 edge kernel revealed that
AppArmor profiles are missing for 6.8 kernel in livecd-rootfs, leading
to fall back to generic AppArmor profiles which don't contain
configuration for io_uring. This leads to `snap debug seeding` output
non-e
Thanks Neil, I'll let you handle the upstream. I think what you have in
the MP is fine.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2040483
Title:
AppArmor denies crun sending signals to container
Sorry, I missed the conmon-podman denial. Would you mind making a PR to
the upstream with your changes with issue you posted linked? I think
Lucas will not have time until end of week.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
ht
Also, thanks for linking the podman issue. I'll try to merge patch
upstream similar to moby and containerd.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2040483
Title:
AppArmor denies crun sending
@neil-aldur, did you forget to attach the debdiff?
By restricting the signal set you also restrict what $SIG you can put to
"podman kill --signal $SIG".
I did not realize that there's a podman reference profile as well, but
since podman doesn't try to kill the container by itself, I wonder if it
@lucaskanashiro: This patch is for golang-github-containers-common
source package. This source package produces golang-github-containers-
common-dev binary package, which is just source code on filesystem. But
podman binary package, which is produced from libpod source package, has
golang-github-co
@lucaskanashiro,
I think you are trying top stop the container too soon after it's
created. The container receives SIGTERM from docker before is sets up
signal handlers, and because it's PID 1, the signal is ignored. Runc
then kills it with SIGKILL after 10s.
Try with sleep:
root@cloudimg:~# tim
** Description changed:
[ Impact ]
* On mantic and noble, when run as root, podman cannot stop any
container running in background because crun is being run with a new
profile introduced in AppArmor v4.0.0 that doesn't have corresponding
signal receive rule container's profile.
** Description changed:
[ Impact ]
- * On mantic and noble, when run as root, podman cannot stop any
+ * On mantic and noble, when run as root, podman cannot stop any
container running in background because crun is being run with a new
profile introduced in AppArmor v4.0.0 that doesn't
** Description changed:
- Mantic's system podman containers are completely broken due to bug
- 2040082. However, after fixing that (rebuilding with the patch, or a
- *shht don't try this at home* hack [1]), the AppArmor policy still
- causes bugs:
+ [ Impact ]
+
+ * On mantic and noble, when run
** Merge proposal linked:
https://code.launchpad.net/~virtustom/ubuntu/+source/golang-github-containers-common/+git/golang-github-containers-common/+merge/465117
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpa
** Also affects: golang-github-containers-common (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2040483
Title:
AppArmor denies crun sending signal
I'll copy the workaround I mentioned in #2039294 here:
As a temporary workaround, put the file I have attached to
/etc/apparmor.d/docker-default and load it with "apparmor_parser -Kr
/etc/apparmor.d/docker-default". It will make dockerd skip loading its
builtin profile as docker-default. It will a
There's a fix proposed to upstream: https://github.com/moby/moby/pull/47749
The commit message describes the cause.
These bugs have the same cause:
- https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2039294
- https://bugs.launchpad.net/ubuntu/+source/libpod/+bug/2040483
The latter doesn'
There's a similar issue with runc (and containerd and docker) reported
here https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2039294
I've opened PRs with a fix upstream:
- https://github.com/containerd/containerd/pull/10123
- https://github.com/moby/moby/pull/47749
I think I'll need to wor
Forgot to attach the profile. Attached here.
** Attachment added: "docker-default"
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2039294/+attachment/5769855/+files/docker-default
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to U
As a temporary workaround, put the file I have attached to
/etc/apparmor.d/docker-default and load it with "apparmor_parser -Kr
/etc/apparmor.d/docker-default". This will make dockerd skip loading its
builtin profile and use this one instead. The only difference between
the builtin one and this one
Public bug reported:
Since version 3.121ubuntu1 adduser's postinst script creates
/etc/adduser.conf.dpkg-save file on debootstrap's root filesystem, that
is, even when /etc/adduser.conf doesn't exist prior to package
installation.
Because of the change below the postinst script changes packaged
/
Understood. Submitted new one:
https://bugs.launchpad.net/ubuntu/+source/ca-certificates-
java/+bug/1953121
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1406483
Title:
Possible to install (and trig
Public bug reported:
This is a fresh report of https://bugs.launchpad.net/ubuntu/+source/ca-
certificates-java/+bug/1406483 with same steps to reproduce. Currently
it can be reproduced in both impish and jammy.
ca-certificates-java installs /etc/ca-certificates/update.d/jks-keystore
that's being
The fix synced from Debian checks for JDK (or JRE) directories under
/usr/lib/jvm and updates PATH with first found JRE. But it only checks
hardcoded paths with java version up to Java 9. On Impish, ca-
certificates-java package version is 20190909 and it is checks up to
java version 11. So when in
This is not correct. The advice applies only to enabling debug messages
in modules, but how does one enable debug messages kernel image? For
example one could want to see debug messages from kernel/module.c which
is not in any module, and the kernel parameter would be:
dyndbg="file kernel/module
Successfully tested docker.io on hirsute.
With docker.io 20.10.7-0ubuntu1~21.04.2 from hirsute:
$ sudo docker run ubuntu:impish apt-get remove - --allow-remove-essential
e2fsprogs
(Reading database ... 4386 files and directories currently installed.)
Removing e2fsprogs (1.46.3-1ubuntu3) ...
31 matches
Mail list logo
