But the ps output already has identified a hang inside of iptables itself
hanging.
The commandline identified it coming from
767 # First install a test chain
768 (rc, out) = cmd([exe, '-N', chain])
Original run command would be:
$ #/home/ubuntu/autopkgtest/runner/autopkgtest --output-dir
/tmp/autopkgtest-work.zn3q26vh/out --timeout-copy=6000 --setup-commands
/home/ubuntu/autopkgtest-cloud/worker-config-production/setup-canonical.sh
--setup-commands
I discussed if maybe it is part of the special net rules
"autopkgtest@lgw01-14.secgroup" that I saw in the command - but
according to Laney/Juliank those are just copies of the default group
for scaling reasons.
--
You received this bug notification because you are a member of Ubuntu
Touch
Note from my debug builds:
TDEBUG: check OSError
GNC: Enter get_netfilter_capabilities
GNC: we are root
GNC: chain ufw-caps-testSqLa5Y
GNC: exe /sbin/iptables
That means it is the first action of the test, just running
/sbin/iptables -N ufw-caps-testSqLa5Y
Nothing else of the python stack was
This ordering is interesting (from a good case):
$ grep -e 'autopkgtest .*\[.*\]: test .*:' -e get_netfilter_capabilities
old-iptables-good.txt
test_get_netfilter_capabilities (tests.unit.test_util.UtilTestCase)
Test get_netfilter_capabilities() ... ok
test_get_netfilter_capabilities
There were a bunch of mentions of that function in bug 1044361 bug 1039729 and
bug 1062521.
And while the issues back then are in the code since version 34 we might again
face something that is special about the network environment that is present
only in the autopkgtest-env for "build-needed"
It is this function our busy loop is in:
1581 static void __nft_build_cache(struct nft_handle *h)
1582 {
1583 »···uint32_t genid_start, genid_stop;
@jdstrand - agreed, but we might need/want to mask the test in UFW thou as the
fix in iptables might need some time. The problem is that I can either make it
skip the single test (need to check if then later on things fail) OR make it a
force-badtest which would be sad as we'd loose so many
A new -N call hangs as well, so I can debug "into" the failure
Here is a strace from start into the looping call
https://paste.ubuntu.com/p/YTQStdg6vm/
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
Backtrce while in the loop
(gdb) bt
#0 0x77b120b82790 in mnl_cb_run () from
/lib/powerpc64le-linux-gnu/libmnl.so.0
#1 0x013b1172e2a8 in mnl_talk (h=0x7fffd658cad0, nlh=,
cb=0x13b11729570 , data=0x7fffd658c5e4) at nft.c:106
#2 0x013b1172e530 in mnl_genid_get (genid=0x7fffd658c5e4,
Fixed in later versions, Rafael will take a HA-POV look at this after FF
in Eoan.
** No longer affects: systemd (Ubuntu Cosmic)
** No longer affects: netplan.io (Ubuntu Cosmic)
** No longer affects: keepalived (Ubuntu Cosmic)
** Changed in: keepalived (Ubuntu)
Status: Triaged => Fix
That would be a change in apparmor to generally help the live system, and much
less an unbound specific issue.
Therefore I added a task for apparmor for the people triaging/fixing that to
take a look.
** Also affects: apparmor (Ubuntu)
Importance: Undecided
Status: New
--
You
I have made good progress on the instance that I got shared.
I have a fix for the busy loop, but while that will be helpful it isn't
avoiding the root-cause and the system will be broken in regard to iptables.
I have submitted an RFC with a long cover letter explaining the situation to
upstream
I have got a reply from upstream, since recently there is a similar fix which
isn't in 1.8.3
I'll update my suggested fix to this one and see how the behavior will be with
that one.
=>
https://git.netfilter.org/iptables/commit/?id=e5cab728c40be88c541f68e4601d39178c36111f
--
You received this
As expected the upstream patch works even better.
It gets -N and -L working.
Most (but not all) the time this might be an issue of the build
permissions.
As now iptables works (correctly) with sudo but not without.
The former hang also only happened with sudo.
Maybe the build in the autopkgtest
@Jamie - you are right and that is exactly the fix that I have up for
review since a few hours in
https://code.launchpad.net/~paelzer/ubuntu/+source/iptables/+git/iptables/+merge/371575
There are no "other cases needing a similar commit", I meant "this fix
also helps other cases that ran into
Review is done, just waiting for the tests to confirm to be ok.
--
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/1840633
Title:
autopkgtests get stuck in Eoan with
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/lvm2/+git/lvm2/+merge/372393
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/1657646
Title:
** Also 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/1843394
Title:
FTBFS in Eoan - Error:
** Changed in: dnsmasq (Ubuntu)
Status: New => In Progress
--
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/1843430
Title:
FTBFS in Eoan due to new glibc - error:
I have had another dev try this on fedora which also has gcc 9.2.1 and
it works there.
But since it fails in "as" which is actually binutils lets add that as a bug
task.
Maybe binutils developers know something about this?
** Summary changed:
- FTBFS in Eoan - Error: operand type mismatch for
@Robie/@Lars (no on CC) - IIRC this was somewhat known and on your list
- are there any updates to the overall case of co-existence (at least
after one another)?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in
Ok, it got spotted and became a component mismatch as expected in the tool run
tonight.
All is fine again, sorry for the noise.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
Public bug reported:
We hit this on a rebuild in Eoan
dhcp.c: In function ‘dhcp_packet’:
dhcp.c:182:17: error: ‘SIOCGSTAMP’ undeclared (first use in this function); did
you mean ‘SIOCGARP’?
182 | if (ioctl(fd, SIOCGSTAMP, ) == 0)
| ^~
|
Thank you for taking the time to report this bug and helping to make
Ubuntu better. I appreciate the quality of this bug report and I'm sure
it'll be helpful to others experiencing the same issue.
This is even slightly worse IMHO as it does stripped mapping.
If on a server you have
$ ll \[a\]/ a
Hi Luke,
thanks for the bug report and your help to make Ubuntu better.
I'm unsure what ssh could/should do differently in this case.
For similar issues there was a gnome PR [1] that went into gnome that should
allow a "yes and remember" kind of use-case. Not sure if that is missing in the
Test build worked, opened an MP [1] and a test PPA [2]
[1]:
https://code.launchpad.net/~paelzer/ubuntu/+source/dnsmasq/+git/dnsmasq/+merge/372548
[2]: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1843430-ftbfs-dnsmasq
** Description changed:
We hit this on a rebuild in Eoan
dhcp.c:
Hrm ??
This updated lvm2 migrated to -release
with the field:
Recommends: thin-provisioning-tools
But I have not seen an update here that it was promoted and it really
seems not in main yet:
root@e:~# apt-cache policy thin-provisioning-tools
thin-provisioning-tools:
Candidate:
The MIR itself (bug 1828887) also got no update.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/1657646
Title:
[20.04] Missing thin-provisioning-tools prevents VG with thin
Note: given that this went into the archive in early July and that nothing but
this section in IPXE broke I lean toward assuming that the ipxe code is broken
or at least (while it worked in the past) not implemented the way it should be
for the assembly to work.
Yet I'm not feeling experienced
I was checking this, but nowadays this works.
Closing and attaching the build log to prove.
** Attachment added: "libseccomp_2.4.1-0ubuntu0.19.10.3_amd64.build"
Setup with mixed PVs (on dasds forced with dasdfmt):
ubuntu@eoan-disktest:~$ sudo pvdisplay
"/dev/vdc1" is a new physical volume of "<6.88 GiB"
--- NEW Physical volume ---
PV Name /dev/vdc1
VG Name
PV Size <6.88 GiB
Allocatable NO
FYI reported upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=25012 and linked in this
bug.
** Bug watch added: Sourceware.org Bugzilla #25012
https://sourceware.org/bugzilla/show_bug.cgi?id=25012
** Also affects: binutils via
https://sourceware.org/bugzilla/show_bug.cgi?id=25012
Hi,
I was asked about a very similar case and needed to debug it.
So I thought I give the issue reported here a try how it looks like today.
virt install creates a guest with a command like:
-drive
I added the conffile changes to the open MP.
Waiting for a review before the upload ..
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/1842436
Title:
[UBUNTU] Avoid creation
FYI: The comparison to Fedora (there it still works) uses binutils
2.31.1-29.fc30.x86_64 still.
--
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/1843394
Title:
FTBFS in
Quoting a post of a ipxe related developer that did a nice check
realizing that e.g. disassembly always lists pushq (and opcode stays the
same) - thanks to Valentine for these checks!:
AFAIU, segment registers
are 16-bit long, however, "pushl" and "pushq" should also be valid and
produce the
Result Eoan:
### Testing suffix '' ###
.code16
push %gs
push %fs
pop %gs
pop %fs
.code32
push %gs
push %fs
pop %gs
pop %fs
.code64
push %gs
push %fs
pop %gs
pop %fs
push.out: file format elf64-x86-64
Disassembly of section .text:
<.text>:
0: 0f a8
Result Disco:
### Testing suffix '' ###
.code16
push %gs
push %fs
pop %gs
pop %fs
.code32
push %gs
push %fs
pop %gs
pop %fs
.code64
push %gs
push %fs
pop %gs
pop %fs
push.out: file format elf64-x86-64
Disassembly of section .text:
<.text>:
0: 0f a8
Slightly extending on that test by Valentine I really think this is a change in
binutils behavior.
Attaching a script to test which I then will add logs from Disco (older 2.32)
and Eoan (2.32.51).
The script does:
- test pop/push with suffixes "" w l q
- test this in code 16/32/64 blocks
**
Summary D vs E:
- no suffix
=> works equally in both releases
=> same opcodes in all .code segments
- suffix "w"
=> works equally in both releases
=> opcodes in .code32/.code64 differ from .code16 (660f..)
=> .code16 matches the non-suffix opcodes (0f..)
- suffix "l"
=> failures in
Working build with V2 at
https://launchpad.net/~paelzer/+archive/ubuntu/bug-1843394-ipxe-ftbfs
--
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/1843394
Title:
FTBFS in
FYI: feedback indicates this is intentional and we'd need to change IPXE.
My experiments showed that the initial idea isn't good, I'll submit a V2 to
IPXE on the thread already linked here.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
Note: the if the solution needs an ifupdown hook like shown in comment
#12 in >=Bionic I'd ask you to take a look for networkd-dispatch (the
final solution for almost all of these bugs is that the upstream project
starts to listen o netlink to pick up late ready IP addresses)
FYI: There seem to
Thanks H.J. Lu,
so the change was intentional just as I thought. I'll add this to the thread
[1] I have with the ipxe people then.
If there is anyone here that wants to help guiding [1] please feel free
to chime in there or let me know here and I can pass the info.
[1]:
Thanks Dan for going deeper on these logs - interesting path differences
that you have spotted!
Thanks Laney for the info on recent changes!
I subscribed stgraber and will give him and the other LXD folks a ping
to chime in here if the mentioned configs/updates ring a bell in regard
to the paths
If you are lazy to look for these commits, feel free to use these links
https://github.com/systemd/systemd/commit/7da377ef16a2112a673247b39041a180b07e973a
https://github.com/systemd/systemd/commit/95355a281c06c5970b7355c38b066910c3be4958
Great, thanks Stephane for confirming that.
@Rbalinx / @xnox - would you want to fix that up as part of the next
systemd upload to Disco then?
Until then we could mark it badtest on armhf as that reflects the
current state correctly and unblocks others until fixed.
--
You received this bug
Until resolved I added a commit to the MP [1] masking current bad systemd tests
in Disco.
That would unblock everyone until this is hopefully resolved in the next upload.
[1]: https://code.launchpad.net/~paelzer/britney/hints-ubuntu-disco-fix-
systemd-ppc-hint-that-never-works/+merge/373200
--
Hmm, there isn't an obvious cgroup/lxd patch in upstream libvirt master
branch atm that would suggest itself as fix to test to apply to libvirt.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
To summarize (out of the noisy test log).
What happens with this patch applied is that libvirt looses its LXC-guest on
the restart of the service.
With the XML from the test this is what happens:
$ virsh define debian/tests/smoke-lxc.xml
$ virsh start sl
$ virsh list
Id Name State
The full 2.4.2 release also fails with:
Traceback (most recent call last):
File "./setup.py", line 28, in
from Cython.Distutils import build_ext
File "/usr/lib/python3/dist-packages/Cython/Distutils/__init__.py", line 1,
in
from Cython.Distutils.build_ext import build_ext
File
Architectures with the fail above: all
Happens after build and self tests on dh_auto_install for python 3.8
On x86 that would be:
ModuleNotFoundError: No module named '_sysconfigdata_m_linux_x86_64-linux-gnu'
--
You received this bug notification because you are a member of Ubuntu
Touch seeded
2.4.2 was released by upstream now on the weekend wrapping up all the changes I
experimented with.
We might try packaging this instead and be better off.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
This moved in python:
3.7:
libpython3.7-minimal:amd64:
/usr/lib/python3.7/_sysconfigdata_m_linux_x86_64-linux-gnu.py
3.8:
libpython3.8-stdlib:amd64:
/usr/lib/python3.8/_sysconfigdata__linux_x86_64-linux-gnu.py
Build depends is: libpython3-all-dev
The file is present - Build-env:
I have tried quickly to just backport [1] but it still fails in a full cross
arch PPA build
OTOH adding those worked in the sbuild env when modifying things manually.
There must be more to it.
[1]:
https://github.com/seccomp/libseccomp/commit/be65b26b67099be2b2b4890d736dbd1ad15adf36
--
You
Oh it now became a real build issue (not on unit tests) by breaking very early
with things like:
arch-x86_64-syscalls.c:63:27: error: ‘__PNR_clock_getres_time64’ undeclared
here (not in a function)
63 | { "clock_getres_time64", __PNR_clock_getres_time64 },
--
You received this bug
Build issue is reproducible on arm64 LP infrastructure builds.
I spawned a canonistack arm64 system to check if it is reproducible
there as well for some debugging how we could fix it.
Interestingly, it does NOT FAIL on focal as-is when building on aarch64.
But as LP builds are against
Arm64:
$ grep NR_open $(dpkg -L linux-libc-dev | xargs) 2>/dev/null
/usr/include/asm-generic/unistd.h:#define __NR_openat 56
/usr/include/asm-generic/unistd.h:__SYSCALL(__NR_openat, sys_openat)
/usr/include/asm-generic/unistd.h:#define __NR_open_by_handle_at 265
Code is on https://github.com/seccomp/libseccomp/tree/release-2.4 now.
But an official release would need 2.4.2 to be tagged by upstream.
But now fixes can be cherry-picked to fix the FTBFS in E+F
** Tags added: server-next
--
You received this bug notification because you are a member of
Continues to FTFBS in LP infra today :-/
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1849785
Title:
FTBFS on i386/ppc64/s390x (Eoan+Focal)
Status in libseccomp:
Offline build worked much better with these, but I still see some arches
fail (see PPA)
PPA: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1849785
-libseccomp-ftbfs/+packages
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed
Only fails on arm64 now (all others good):
15-basic-resolver.c:58:46: error: ‘__NR_open’ undeclared (first use in this
function)
58 | if (seccomp_syscall_resolve_name("open") != __NR_open)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which
Well the answer to the new fails is that we are now "too new" in my
tests I used kernel 5.3 and this is what Focal has. But the final fix
used 5.4-rc levels which brought in all the time64 things.
linux-libc-dev:amd64 5.3.0-21.22
5.3 already has the NR definitions like
Hiho,
keine Angst "von Interesse" ist erst einmal jede Meldung. Ich selbst bin nur
nicht so fit mit dem Druckteil von Samba und Co.
I think we should add cups and system-config-printer bug tasks as I
think this isn't really a samba things.
Ich Fasse mal zusammen:
- printer setup that worked
@Till - does any of this look familiar from a printing POV?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/1849859
Title:
error when connecting to smb server
Status in cups
Debian accepted my MR and 2.4.2 is there.
Unfortunately due to bug 1852389 I had to realize that I can't make it a sync
yet.
I prepared a MP for a proper merge in
https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/375472
--
You received this bug notification
The new issue was discussed upstream already [1] and has a PR [2] this
is targetted at v2.5, but we might pick just the fix [3] for now.
[1]: https://github.com/seccomp/libseccomp/issues/184
[2]: https://github.com/seccomp/libseccomp/pull/182
[3]:
Lol, after completing the python 3.8 fight I'm back at step #2
Arm fails the build still missing __NR_open
15-basic-resolver.c:58:46: error: ‘__NR_open’ undeclared (first use in this
function)
58 | if (seccomp_syscall_resolve_name("open") != __NR_open)
Interim state of the branch pushed to
MP for Ubuntu:
https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/375205
PR for Debian: https://salsa.debian.org/debian/libseccomp/merge_requests/1
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
** Also affects: notary (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to nspr in Ubuntu.
https://bugs.launchpad.net/bugs/1851695
Title:
DEP8 failure/regression in nspr on
Note: I ensured that the ppa uses focal-proposed, now there are even
more issues.
x86:
checking for python extension module directory... Traceback (most recent call
last):
File "", line 20, in
File "/usr/lib/python3.8/sysconfig.py", line 512, in get_path
return get_paths(scheme, vars,
** Summary changed:
- DEP8 failure/regression in arm64 and armhf
+ DEP8 failure/regression in nspr on arm64 and armhf
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to nspr in Ubuntu.
https://bugs.launchpad.net/bugs/1851695
** Bug watch added: Debian Bug tracker #944346
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944346
** Also affects: notary (Debian) via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944346
Importance: Unknown
Status: Unknown
--
You received this bug notification because
We are currently on golang 1.12.12, upstream has fixes in that regard
but while trying to identify I found issue [1] and think this is what we
face atm. There isn't a solution yet and my go-foo is too low.
This also affects Debian [2] and I'll file a bug there as well for awareness.
The tests
This was triggered by:
- sync of newer nspr
- merge of newer nss
They all fail the same way.
I did run this with/without the elements from proposed - it just is
broken before any or "our" changes.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
The test history indicates this might be due to some golang changes and
indeed the entry point to the test is /usr/bin/dh_golang_autopkgtest.
While autopkgtest says:
autopkgtest [10:12:21]: test command1: preparing testbed
as usual.
There actually is no debian/test* at all, so this must be
As I expected this is the actual go build that breaks.
The package atm is also FTBFS in focal with the same error.
Buildlog: http://paste.ubuntu.com/p/dfYqvVhVBh/
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to nspr in
Issue is in systemd, fix known (now).
I'll prep an MP to discuss, but given how much extra churn systemd updates
usually cause this most likely won't be uploaded "on its own"
** Changed in: libseccomp (Ubuntu)
Status: New => Invalid
** Changed in: systemd (Ubuntu)
Status: New =>
Adding a systemd task as I really think this is more a general than a
haproxy specific discussion/bug/feature.
--
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/1855140
Title:
Maybe related discussion https://lists.debian.org/debian-
devel/2019/12/msg00060.html
** 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
An SRU for just a FTBFS seems wrong.
Even keeping it forever in block-proposed seems wrong.
The fixes are known and ready for whoever does a real upload.
The most likely upload is a full backport of the new version which already
includes the fixes.
For whoever does an upload to Eoan what you
This is in Focal, lets close the bug
pango1.0 | 1.44.7-1 | focal | source
** Changed in: pango1.0 (Ubuntu)
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pango1.0
navit actually just naively includes and the error pups up
much below that.
It has #define GDK_ENABLE_BROKEN might that be related?
Build dep is:
libgtk2.0-dev
Which brings in:
libpango1.0-dev | 1.44.7-1 | focal | amd64, arm64, armhf,
i386, ppc64el, s390x
And that has
navit last time built fine in Eoan on 2019-09-10
Comparing the environments between late Eoan and Focal...
The Eoan version of pango-coverage.h doesn't have the include that is
failing me.
** Bug watch added: gitlab.kitware.com/cmake/cmake/issues #19531
Added a pango1.0 task for awareness
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pango1.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1855993
Title:
FTBFS in focal blocking gpsd transition for libgps25
Status in navit
#ubuntu-desktop was helpful:
[11:29] cpaelzer, hey, it's
https://gitlab.kitware.com/cmake/cmake/issues/19531
[11:29] RikMills, ^
[11:29] cpaelzer, we talked about it on friday on #ubuntu-release, we
should backport that patch to cmake
--
You received this bug notification because you are a
** Also affects: cmake (Ubuntu)
Importance: Undecided
Status: New
** Changed in: cmake (Ubuntu)
Assignee: (unassigned) => Rik Mills (rikmills)
** Changed in: cmake (Ubuntu)
Status: New => Triaged
** Description changed:
+ A change in Pango [1] broke builds using GTK2 as
.
** Changed in: pango1.0 (Ubuntu)
Status: New => Won't Fix
** Changed in: navit (Ubuntu)
Status: New => Triaged
** Changed in: navit (Ubuntu)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
--
You received this bug notification because you are a member of Ubu
I reworded the bug Description to be the general discussion that it is.
Waiting for:
- Debian GR [1] to complete as its decision has direct impact on how to handle
this in packages
- Ubuntu systemd maintainers to chime in as this might have been discussed in
other bugs before
[1]:
Subscribing ubuntu-security to monitor this together with us as often enough
they do libseccomp.
IMHO We don't have any urgency to go ahead of upstream, unless a fast re-build
is needed.
** Changed in: libseccomp (Ubuntu)
Importance: Undecided => Medium
** Changed in: libseccomp (Ubuntu
TODO:
a) wait for 2.4.2 and 2.5.0 to be released and pick those
b) if urgent pick and backport [1]
[1]:
https://github.com/seccomp/libseccomp/pull/176/commits/e4d38dcfd44743a55728b336d008ec8e37c1b344
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
And as usual once you know what you search:
=> https://github.com/seccomp/libseccomp/issues/166
** Bug watch added: github.com/seccomp/libseccomp/issues #166
https://github.com/seccomp/libseccomp/issues/166
** Also affects: libseccomp via
https://github.com/seccomp/libseccomp/issues/166
I think this comes from [1] which is in since 5.3.
This will be generated into s390x-linux-gnu/asm/unistd_64.h and such.
on x86-64 it was 220 all along, no change there.
/usr/include/x86_64-linux-gnu/asm/unistd_64.h:#define __NR_semtimedop 220
Well this change made the ID 392 "known" to all architectures (in a try
to sync numbers across everywhere) but it fails on those it isn't
implemented (32bit, ppc, s390x + sparc which we don't have).
The path registering these calls goes
seccomp_rule_add
-> seccomp_rule_add_array
->
Upstream/master branch still is on 4.15-rc7 AND still uses __PNR_* for the
definitions.
I'll open an issue to further discuss it there.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
There isn't a lot of info on the bug to help, but it already seems to be a
config issue.
For those you are better with a community page like askubuntu.com as this is
about fixing bugs in the package and not about guiding to a valid configuration.
A search showed
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
MPs got reviewed and uploaded to D/B SRU queue
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1827253
Title:
[apparmor] missing 'mr' on binary for usage on containers
Thanks for the review Łukasz,
I somewhat agree with your summary. The reason I went on with it was because it
was very low hanging fruit and Simon (Bug reporter) is like "The Ubuntu
community good bug reports role model".
But I agree that the update for everyone (it is always installed) might be
401 - 500 of 1234 matches
Mail list logo
