I wonder if it really makes sense to keep podman in the Ubuntu
repositories, at least if it's going to stay in universe? It's the sort
of software that people who use it are going rely on being secure and
up-to-date, and so far at least it has been quite a fast-moving target.
I'm not normally a
Ah, looks like upstream bug https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=940219 is the answer to my problem..
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865642
Title:
package dma 0.11-2
I'm dealing with a very similar bug building containers with jammy beta.
If there's an existing /etc/dma/dma.conf, I get the above error message.
Oddly, attempting to strace or add too much debug to the .postinst or
.config scripts makes the problem go away, which makes it seem like some
sort of
Hit the same thing trying to upgrade a bionic container to jammy in
systemd-nspawn :(
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1938088
Title:
acpi-support prevents Groovy and Hirsute booting
The bug has been periodically tripping me up for years, but recently I
discovered that it has basically stopped my elderly uncle from using
Libreoffice (which defaults to GTK file picker on Xubuntu at least) on
bionic. Priority really needs to be higher, at least if the intent is
for Ubuntu to be
This is due to "ProtectHome=yes" in the .service file; the workaround is
to add:
[Service]
ProtectHome=no
In e.g. /etc/systemd/system/fstrim.service.d/allow-home.conf
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The other option in u-a might be to split Unattended-Upgrade::Allowed-
Origins into "Automatic origins" and "permitted origins", so only
packages in the former will be automatically installed, but upgraded
dependencies could be pulled from the latter if required?
--
You received this bug
I suppose there's an argument to be made that if the user is prepared to
periodically manually install non-security updates, then they should be
prepared to check for held back security updates too. I tend to work
from the command-line so don't know what the GUI interface(s) allow and
indicate in
Digging a bit further - this machine was manually dist-upgraded on
30-May-2021 (it has -updates enabled, but is set to install only
security updates automatically.) That update pulled in libglvnd
1.3.2-1~ubuntu0.20.04.1 (source for libegl1, libglvnd0, etc.)
To upgrade to webkit2gtk
OK, have manually rolled back the system to previous state (the old
versions of the packages were still available on my apt-cacher-ng
server), and run unattended-upgrades in debug mode - file attached. I
guess the key lines are:
sanity check failed for:
OK, here is dpkg.log section from one machine:
2022-03-05 14:45:14 startup archives unpack
2022-03-05 14:45:14 install libopengl0:amd64 1.3.2-1~ubuntu0.20.04.1
2022-03-05 14:45:14 status triggers-pending libc-bin:amd64 2.31-0ubuntu9.2
2022-03-05 14:45:14 status half-installed libopengl0:amd64
Unfortunately I've already done that on the two affected machines and
didn't make a note of the output. I will try to dig out the dpkg logs.
As I said, the extra dependency on libopengl0 seemed to be the issue.
It's also just possible I took a snapshot or backup so I can roll back
and retry - I
Fixed by
https://github.com/iputils/iputils/commit/e2e9a2dd4639924614bdbee43907a49134e8da19
it seems.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1892108
Title:
ping prints ip address octets
I've rebuilt my 'LAN services' container with the packages linked here,
and nothing seems to have exploded over the last hour or so. Not sure if
that constitutes extensive testing :) As it seems stable I'll leave it
running indefinitely to catch any wrinkles..
--
You received this bug
Note that lightdm in focal seems to have problems with v1 policies too,
at least in some cases: https://github.com/google/fscrypt/issues/203 .
** Bug watch added: github.com/google/fscrypt/issues #203
https://github.com/google/fscrypt/issues/203
--
You received this bug notification because
Note that in particular, lightdm seems have to problems when using v1
policies, see https://github.com/google/fscrypt/issues/203. I had to
upgrade one focal laptop to v2 policies to get lightdm to work -
although oddly I had no problems on another, and I can't see the
difference between them.
I
Bug #1901709 should be fixed by a resync, too. I don't know how many
people other than me are mad enough to be running nfs servers in
containers ..
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This commit actually didn't reliably fix this bug, but given the length
of time here, I've opened a new bug #1950906
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1451797
Title:
rc.local should
Public bug reported:
The fix for bug #1451797 introduced /lib/systemd/system/rc-
local.service.d/debian.conf with the intent that rc.local would always
run after the network was fully online. However, it only has an After=
line, without actually pulling in network-online.target. Systemd docs
say:
The long-term solution to all of this tediousness is probably for
seccomp to be able to give some indication if a syscall is "new":
https://github.com/seccomp/libseccomp/issues/286
** Bug watch added: github.com/seccomp/libseccomp/issues #286
https://github.com/seccomp/libseccomp/issues/286
I think the long test case in #5 now works. Note that later versions of
crun have worked around the problem:
https://github.com/containers/crun/pull/672
Still worth fixing, though, I think, as it is likely to cause further
problems as more code starts to use close_range.
--
You received this
Still working out kinks in the above, but here's a simpler one. Needs
running in an nspawn container again (steps 1-2 above); should either
succeed (no output) or print "function not implemented", but without
seccomp support nspawn will block it and it will print "not permitted"
#include
It's not going to be simple I'm afraid, at least for the original
problem! "scmp_sys_resolver close_range" will quickly test whether
current seccomp has support for close_range (prints "-1" if not
supported, "436" otherwise - at least on x86_64.) Ubuntu seccomp
maintainers have been pretty happy
Can confirm rebuilding seccomp in focal with the relevant bits of the
above two commits allows me to whitelist close_range in systemd-nspawn,
solving my problem.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://github.com/seccomp/libseccomp/pull/322/ (or at least parts of
it) probably required too.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1944436
Title:
Please backport support for
Public bug reported:
Please backport support for the "close_range" syscall .. may be as
simple as cherrypicking
https://github.com/seccomp/libseccomp/commit/01e5750e7c84bb14e5a5410c924bed519209db06
from upstream. I've hit problems running buildah in a systemd-nspawn
container, but this will
Bug #1926267 is related.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1810565
Title:
Ubuntu 16.04 to Ubuntu18.04 upgrade fails on snap debug connectivity
without logging any useful logs
To
This hit me trying to run a container upgrade in an environment where
snapd wasn't running. Not a supported situation I'm sure but the extra
logging would be good - just capturing the "snap debug connectivity"
output and dumping to log would be fine..
--
You received this bug notification
Bug #1810565 related.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1926267
Title:
do-release-upgrade failed silently after failed to connect to snap
service
To manage notifications about this
I'm seeing something similar to this (messages more like those in
underlying debian bug report) - in this case triggered by a script which
sshs in (invoking unison) twice in quick succession. Underlying hardware
is an ARM board which may a little slow, don't know if that helps to
trigger race?
Upstream bug, I assume: https://github.com/blueman-
project/blueman/issues/1210
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871336
Title:
blueman-tray crashed with FileNotFoundError in
I guess this is a race condition? Lockfile being removed by previous
instance between the file being read and the is_running check or remove
call?
** Bug watch added: github.com/blueman-project/blueman/issues #1210
https://github.com/blueman-project/blueman/issues/1210
--
You received this
It's just possible that the commit linked may fix
https://github.com/systemd/systemd/issues/12313 as well ..
** Bug watch added: github.com/systemd/systemd/issues #12313
https://github.com/systemd/systemd/issues/12313
--
You received this bug notification because you are a member of Ubuntu
LGTM!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1883447
Title:
nspawn on some 32-bit archs blocks _time64 syscalls, breaks upgrade to
focal in containers
To manage notifications about this
Ah, my apologies - hadn't spotted that it was a recently introduced bug!
On Tue, 9 Feb 2021, 22:20 Steve Beattie, <1915...@bugs.launchpad.net>
wrote:
> Hello Steve,
>
> Thanks for reporting this issue. In this case, it is believed that the
> vulnerability was introduced in screen 4.7.0 (via
>
>
Marking public as this is already known; might as well avoid dupes..
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1915205
Title:
CVE-2020-9366
To manage notifications about this bug go to:
*** This bug is a security vulnerability ***
Public security bug reported:
screen <4.8.0 has a buffer overflow that can be triggered by program
output. It doesn't seem to be clear yet how exploitable it is:
https://nvd.nist.gov/vuln/detail/CVE-2020-9366
Ah, looks like I don't need to do anything for focal's systemd-nspawn
other than add openat2 to SyscallFilters= in the .nspawn file. With
that, and the seccomp from the PPA, everything seems OK - thank you!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
OK, this is getting complicated. seccomp 2.5.0 and systemd-nspawn both
have bugs which when combined cause most/all syscall filters to actually
be disabled! See
https://github.com/seccomp/libseccomp/issues/273#issuecomment-668458070
So I think your new packages are probably OK, but as they pull
Attached is a trivial test case, needs to be run in a container by a
container manager that uses seccomp for syscall filtering (e.g. nspawn.)
It should either silently succeed or print "openat2: Function not
implemented" ; if seccomp combined with the container manager (e.g.
nspawn) blocks the
Hmm, I tested with libseccomp2_2.5.1-0ubuntu0.20.04.1_test4_amd64.deb
from the PPA and it doesn't seem to fix the openat2 problem - just
realised I should have added I'm now using focal not bionic for my
container host.. will try to investigate why once I'm back on my desktop
machine.
--
You
Any progress on this? I've just run into it again, and due to my
appalling memory have spent two hours debugging and now discovered my
own bug report again :/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Fix might well be as simple as adding "After=grub-common.service" to
/lib/systemd/system/grub-initrd-fallback.service - it's worked for one
boot so far, which is obviously not a great test of a race condition :)
It does seem to lead to sequential ordering of the two jobs, though:
Jan 08 20:31:26
Public bug reported:
On focal, it appears systemd can run /etc/init.d/grub-common in parallel
with /lib/systemd/system/grub-initrd-fallback.service. Both of these
invoke grub-editenv for different reasons, apparently resulting in race
conditions that generate messages like this:
Jan 08 18:07:15
** Attachment added: "/etc/initramfs-tools/scripts/local-top/btrfs-lvm"
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1848180/+attachment/5447426/+files/local-top.script
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
OK, attached are some initramfs scripts:
local-top.hook -> /etc/initramfs-tools/hooks/btrfs-lvm
local-top.script -> /etc/initramfs-tools/scripts/local-top/btrfs-lvm
I've tried to make them reasonably generic, the root fs is examined on
initramfs creation, component btrfs devices extracted and
I'm seeing this on focal as well. Running vgchange when the initramfs
crashes to shell no longer seems to work - it just hangs. I have to add
break=mount to kernel command line and do it there. Now working on
hacking something into /etc/initramfs-tools/scripts/local-top/ -
@Gabriele, that should
Public bug reported:
Not sure what happened here, this line might be key:
- Run install hook of "lxd" snap if present (run hook "install": cannot
perform operation: mount --rbind /home /tmp/snap.rootfs_FrMoDy//home:
Permission denied)
If I remember correctly, /home is a symlink on this
I've gone through the upstream bug
https://github.com/borgbackup/borg/issues/4829 and not found any data
which could be used as a test case. While the description of the bug
there is quite detailed, I think one would have to be incredibly
familiar with borg internals & code to create a reproducer.
Given this is a *known data corrupting bug* declared by upstream, it
would seem really odd to hold up the release for bionic and focal, where
the solution is just an upgrade to the upstream version containing the
fix! (I can possibly see the argument for being more careful with
cherrypicked
Public bug reported:
Trying to use kernel nfs server in containers generally works, but
generates dmesg warnings as follows:
[ 23.392559] NFSD: attempt to initialize umh client tracking in a container
ignored.
[ 23.395065] NFSD: attempt to initialize legacy client tracking in a
container
Still broken in bionic in 2020!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/882878
Title:
With IPv6 disabled, openssh will not forward X connections
To manage notifications about this bug go to:
This has just happened on yet another machine. It seems to occur if
there's a snapshot of root volume in existence? Any chance of a fix?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1859829
Title:
Actually, I recommend not looking at 2.5.0 or master until
https://github.com/seccomp/libseccomp/issues/273 is fixed! Definitely a
security issue.
** Bug watch added: github.com/seccomp/libseccomp/issues #273
https://github.com/seccomp/libseccomp/issues/273
--
You received this bug
Public bug reported:
The version of libseccomp2 in bionic does not know about the openat2
syscall.
In my particular usecase, I was trying to run podman/buildah in an
nspawn container, using fuse-overlayfs. This leads to peculiar failure
modes as described in this issue:
This bug also seems to generate "Assertion
'clock_gettime(map_clock_id(clock_id), ) == 0' failed at src/basic
/time-util.c:55, function now(). Aborting" in various places if you try
to boot an existing 20.04 container on bionic with systemd-nspawn.
--
You received this bug notification because
Thinking about it, it probably only applies to arm, or at least to 32
bit archs (I think 64bit archs use 64-bit time already.) I'll try and
find a reference for that ..
** Summary changed:
- nspawn blocks _time64 syscalls, breaks upgrade to focal in containers
+ nspawn on arm blocks _time64
https://patchwork.kernel.org/patch/10756415/ is the upstream kernel
patch it seems.
** Summary changed:
- nspawn on arm blocks _time64 syscalls, breaks upgrade to focal in containers
+ nspawn on some 32-bit archs blocks _time64 syscalls, breaks upgrade to focal
in containers
** Description
Public bug reported:
This may only affect armhf, but I can't see why it should.
Recent Linux kernels introduced a number of new syscalls ending in
_time64 to fix Y2038 problem; it appears recent glibc, including the
version in focal, test for the existence of these. systemd-nspawn in
bionic
Public bug reported:
The following upstream commit
https://github.com/systemd/casync/commit/8d30d6d8ebe4b12e251fe4b72d1a2e6f3121b994
makes the build require meson >= 0.47, but the package in 20.04 still
build-depends on 0.40. Just hit this trying to backport to bionic, which
generates error
This has just bitten me again on yet another machine - is it ever going
to be fixed? If it helps I suspect it's something to do with having
snapshots kicking around ..
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Public bug reported:
Per the "important notes" section of the borg docs:
https://borgbackup.readthedocs.io/en/stable/changes.html
"Pre-1.1.11 potential index corruption / data loss issue
A bug was discovered in our hashtable code, see issue #4829. The code is used
for the client-side chunks
Upstream bug: https://github.com/borgbackup/borg/issues/4829
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1877844
Title:
data corruption issue in all versions before 1.1.11
To manage
Just reported my own bug #1870783 - my server appears to hang (without
above message), but eventually successfully boots after ~ 180 secs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1859829
Title:
Do you also see slow shutdowns? One of my servers which has other
problems with this patch (bug #1870783) has been seen to get stuck
shutting down / rebooting showing a message about (I think) lvmetad
(hard to tell due to very small server console truncating message) ..
systemd eventually times it
Public bug reported:
2.02.176-4.1ubuntu3.18.04.2 causes at least one of my servers to hang on
boot for ~ 3 minutes. adding debug=y to kernel command line seems to
show the last script was init-top/udev. Downgrading to
2.02.176-4.1ubuntu3 resolves the problem.
Possibly related to bug #1859829 and
That would be excellent - thanks! IGLX is one of those things probably
not many people use, but those of us who do kind of really need it. It
also seems to be a thing in HPC / research circles:
https://www.phoronix.com/scan.php?page=news_item=Xorg-IGLX-Potential-
Bye-Bye
FWIW, I'm now (finally)
OK, I think this is not a (huge) bug .. looking at saned code, it tries
to bind v6 and v4 sockets separately. If /proc/sys/net/ipv6/bindv6only
isn't set, binding v6 will also bind v4, making the later explicit v4
bind fail.
The second process is probably the one responsible for avahi
Still seeing this in 18.04! Gave up, disabled /etc/init.d/saned, and
used the systemd socket service - but this doesn't seem to advertise the
saned server.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Any news on this? Recent upgrade has removed my patches to dnsmasq, and
I'm hitting this again. Still convinced the Ubuntu-specific patch to
systemd-resolved is flawed as well.
I will try to get brain back into gear to have at look at this all
again. If nothing else, would be good to SRU the
Just tested on bionic, looks good - thanks everyone!
** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
OK, so my kernel didn't have seccomp support compiled in and systemd
just silently fails to set seccomp filters in that case.
Have now reproduced the bug on an armhf disco VM, and verified that the
package in proposed, 240-6ubuntu5.8 fixes it.
** Tags removed: verification-needed-disco
** Tags
OK, I've had a go, but oddly I can't reproduce this in a disco VM at the
moment, which makes testing the fix tricky..
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1840640
Title:
sync_file_range
@vorlon, will do my best to test the disco version, but I don't
currently have an ARM disco environment, and usual health battles mean
it'll probably be a struggle to set one up - I'll have a go though!
The bionic version I will of course be all over :)
--
You received this bug notification
Can't check at the moment, but details should have been added by apport.
Is it possible arm64 abi is different from armhf (32bit?)
On Thu, 3 Oct 2019, 22:41 Dan Streetman,
wrote:
> I'm having trouble reproducing this on a Bionic nspawn container on
> arm64; what host release, and container
Looks like this may finally have been fixed in Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774560
** Bug watch added: Debian Bug tracker #774560
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774560
--
You received this bug notification because you are a member of Ubuntu
Aha ..
https://github.com/systemd/systemd/blob/master/src/shared/ethtool-
util.c#L279
Reads current WOL settings and doesn't set them again if not necessary -
we're back the r8169 driver or the BIOS possibly not quite initializing
something correctly on start-up, which an explicit ioctl to set
Interestingly, if I enable WOL by hand with ethtool (even though ethtool
is showing it as already enabled), it works.
/sys/class/net/laneth0/device/power/wakeup shows "disabled" if I let
systemd enable WOL via the .link file, but after doing it manually with
ethtool it shows "enabled."
Note that
Public bug reported:
Latest in the eternal saga of WOL problems with r8169 on certain
platforms. 4.15.0-58 (bionic) worked; installing the latest HWE
(5.0.0-25) stops wakeonlan working.
lspci output:
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor
DRAM Controller
Would it be possible to add a flag to AvahiPublishFlags to allow the
application to request the required behaviour on a per-service basis? I
can't see any options for Pidgin that don't require pretty radical
restructuring of its codebase (more discussion at
Thanks for the explanation. Pidgin probably needs to keep the source
address matching partly for security, and also possibly to disambiguate
users. Binding to the advertised address probably wouldn't work in this
case, as the target wouldn't have a route back for the global address
prefix.
I
** Bug watch added: github.com/lathiat/avahi/issues #243
https://github.com/lathiat/avahi/issues/243
** Also affects: avahi via
https://github.com/lathiat/avahi/issues/243
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of
I found a mailing list post which mentioned this, but no replies:
https://lists.freedesktop.org/archives/avahi/2010-March/001863.html
It actually causes problems for Pidgin in certain circumstances, see bug
#1841621.
--
You received this bug notification because you are a member of Ubuntu
Just found bug #1102906 raised against avahi for this behaviour years
ago..
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1841621
Title:
Bonjour messages not received if one party has global ipv6
Just realised that the heat had addled my brain - this will get the link
local address of target, not the originator. We could enumerate link
local addresses on the originator and add a field to the mdns text
record, but by definition those addresses are only valid on a particular
interface, and
Proof of concept of getting link local address for a specific ifindex.
** Attachment added: "getif.c"
https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1841621/+attachment/5285029/+files/getif.c
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Looking at the source, when browsing/resolving mdns, we get an interface
ID passed to the callback. So it should be possible call
if_indextoname() on that, then walk getifaddr() output to find the
interface and then its link-local address, and that add that to the list
of IPs ...
--
You received
May be a long-standing avahi problem, but Pidgin may need to work around
it:
https://lists.freedesktop.org/archives/avahi/2010-March/001863.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1841621
https://github.com/lathiat/avahi/blob/1cc2b8e8d62e939b8bd683f795794878863931af
/avahi-core/iface.c#L707][1]
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1841621
Title:
Bonjour messages not
(For those trying to work around this, just disabling IPv6 through
sysctl doesn't necessarily help - some combination of Network Manager
and avahi seems to manage to advertise a link-local address even in this
instance. v6 support can be turned off separately in avahi-daemon.conf)
--
You
Public bug reported:
Something in the stack - Pidgin or avahi - gets confused if one machine
has a global IPv6 address and the other only has a link-local address.
Pidgin sees the global address advertised by mDNS, but connections come
from the link-local address, and it rejects them because of
The "obvious fix" (attached) does indeed solve the problem - haven't
done enough testing as of yet to be sure there are no weird
consequences.
** Description changed:
I have machine with the following nspawn file:
--
[Network]
MACVLAN=laneth0
[Exec]
PrivateUsers=false
--
Public bug reported:
I have machine with the following nspawn file:
--
[Network]
MACVLAN=laneth0
[Exec]
PrivateUsers=false
--
if I start it with systemctl start systemd-nspawn@name, all works as
expected.
If I start manually with systemd-nspawn -M name -b, I seem to correctly
get a new
I'm utterly confused about what the support policy actually is .. is
"Supported:" in universe still updated/meaningful? Apparently I have 123
unsupported packages on bionic, including things like apcupsd, iftop,
fatrace, distcc, systemd-container ..?
--
You received this bug notification because
Just found this, still very confused .. is "Supported:" in universe
still updated/meaningful? Apparently I have 123 unsupported packages on
bionic, including things like apcupsd, iftop, fatrace, distcc, systemd-
container ..? Hard to get a grasp on current support policies.
--
You received this
Test packages in case anyone wants them:
https://www.dropbox.com/sh/gxuy14k1t2chwbu/AABKX2idDrGu2R3Fwio0DAOTa?dl=0
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1840640
Title:
sync_file_range fails
Public bug reported:
ARM has two sync_file_range syscalls, sync_file_range and
sync_file_range2. The former is apparently not used, and glibc calls the
latter whenever a userspace program calls sync_file_range. I'm guessing
systemd-nspawn doesn't know this, because the follow code consistently
Well, touch wood, something I've done has made things happier. I moved
everything from the cache directory to a subfolder, made it
inaccessible, removed apt lists from clients and ran apt-get update,
then linked all the original cache files into _import and made acng
reimport them.
The first time
I was seeing the dreaded "503 Inconsistent file state" talking to the
canonical (sorry) package repositories. As I said, there are no explicit
upstream proxies, but who knows what the ISP is doing (this would be a
big argument in favour of running apt-get over https to my mind..)
Anyway, at the
acng seems totally broken in bionic. I'm not knowingly behind a proxy -
can't completely rule out ISP doing something evil though. Anyone have
any pointers on this? Very few google hits, nothing on bugs.debian.org
that I can see, very little activity for acng on salsa.debian.org ..
--
You
1 - 100 of 331 matches
Mail list logo
