> Instead, `add-apt-repository` should call `getArchiveSubscriptionURL`
(not `getArchiveSubscriptionURLs`)
this doesn't seem to work correctly.
For example:
In [25]: lp.me.getArchiveSubscriptionURLs()
Out[25]:
btw, I no longer work for Canonical, and this bug doesn't personally
affect me, so it's unlikely I will follow up on this; if anyone does
care about this bug, please feel free to take this over
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which
we briefly discussed this in the backporters mtg and it looks good to
us, however it's backported from 0.188-1 which is currently in lunar-
proposed, so that needs to migrate to lunar-release before we can accept
this backport; feel free to ping us once that's happened.
--
You received this bug
Public bug reported:
[impact]
machinectl read-only does not work
[test case]
On a system where the systemd machines dir is *not* on a btrfs volume
(e.g. it's on a normal ext4 fs), create an image 'test' and then:
$ sudo machinectl image-status test
test
Type: directory
> The patch expands the case where the TERM variable is inherited from
PID 1 when building an execution environment, e.g. for a container. If
problems were to occur, it would be related to the value of TERM in
environments forked off of PID 1.
Eh? That isn't at all what the patch does...
Anyway,
** Description changed:
+ [impact]
+
+ machinectl pull-tar does not work, ever
+
+ [test case]
+
+ see comment 2
+
+ [regression potential]
+
+ problems/failures during pull-tar operation
+
+ [scope]
+
+ needed only in j
+
+ fixed (indirectly) by upstream commit referenced in original
+
Note: this also affects anyone trying to connect to the dev.azure.com
servers (to, for example, git clone g...@ssh.dev.azure.com...)
$ ssh -vv ssh.dev.azure.com
...
debug2: peer server KEXINIT proposal
debug2: KEX algorithms:
** Changed in: elfutils (Ubuntu)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to elfutils in Ubuntu.
https://bugs.launchpad.net/bugs/1987356
Title:
[BPO] elfutils/0.187-1 from
Comments:
1. This adds Suggests: flit, python3-build, python3-tomli,
python3-installer; however, those aren't available in focal.
2. Similiarly, the newly-added package pybuild-plugin-pyproject Depends:
on the python3-{build,installer,tomli} packages, which aren't available
in focal.
3. This
** Changed in: systemd (Ubuntu Hirsute)
Assignee: Dan Streetman (ddstreet) => (unassigned)
** Changed in: systemd (Ubuntu Focal)
Assignee: Dan Streetman (ddstreet) => (unassigned)
** Changed in: systemd (Ubuntu Bionic)
Assignee: Dan Streetman (ddstreet) => (unassigned)
*
I believe the problem is that 'apt-key' uses only the
/etc/apt/trusted.gpg file, while software-properties now (correctly)
creates individual /etc/apt/trusted.gpg.d/*.gpg files for each key
added.
The software-properties AptAuth.py module should probably be changed to
stop using apt-key, and/or
marked verified per comment 10
** Tags removed: verification-needed verification-needed-jammy
** Tags added: verification-done verification-done-jammy
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
** Description changed:
- A customer reported network disconnections on their storage
+ [impact]
+
+ manual disabling of ipv4 DAD (IACD) for static link-local address does
+ not work in jammy
+
+ [test case]
+
+ see 'Reproducer' in original description below
+
+ [regression potential]
+
+
** Description changed:
[impact]
when talking to upstream nameservers, systemd-resolved limits its
advertised max packet size as 512 in its edns0 opt. However, one of the
primary benefits of edns0 is to allow using packet sizes larger than
512, which is the pre-edns0 max packet size.
** Changed in: systemd (Ubuntu Hirsute)
Status: In Progress => Won't Fix
** Changed in: systemd (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
** Changed in: systemd (Ubuntu)
Assignee: Dan Streetman (ddstreet) => (unassigned)
** Changed in: systemd (Ubuntu Bionic)
Assignee: Dan Streetman (ddstreet) => (unassigned)
** Changed in: systemd (Ubuntu Eoan)
Assignee: Dan Streetman (ddstreet) => (unassigned)
*
interestingly, paramiko is also broken when connecting to older servers,
but not for the same reason as this bug. See bug 1973241
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
For reference to anyone coming here with this problem, when connecting
to a remote sshd server you can find what host key algorithms the remote
host uses by using -vv and check the debug output; look first for the
*peer* server KEXINIT proposal (not the earlier *local client* KEXINIT
proposal):
** Changed in: openssl (Ubuntu)
Assignee: Nicolas Bock (nicolasbock) => (unassigned)
** Changed in: openssl (Ubuntu Bionic)
Assignee: Nicolas Bock (nicolasbock) => Bruce Elrick (virtuous-sloth)
** Changed in: openssl (Ubuntu Bionic)
Status: Fix Committed => In Progress
** Tags
** Changed in: systemd (Ubuntu)
Assignee: Dan Streetman (ddstreet) => (unassigned)
** Changed in: systemd (Ubuntu Hirsute)
Assignee: Dan Streetman (ddstreet) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
per comment 6, this should be fixed in jammy, so marking fixed released
there.
** Changed in: systemd (Ubuntu)
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
> It seems this issue may occur not only when receiving addresses on
multiple interfaces, but also when dhcp requests on multiple interfaces
times out and the hook script was called with 'reason' == FAIL.
yep, the try-reload-or-restart is done for those as well and this should
be fixed for those
> I think you have a problem there too.
oh I'm certainly not claiming a 1g default swap is appropriate, that
does seem far, far too small to me and will likely cause widespread
issues beyond just this, I was only saying that tweaking the systemd-
oomd swap % full setting would IMHO not be likely
> it's going to be hard to get around the core issue of oomd counting
pagecache as memory pressure
assuming my quick 10-minute assessment of this bug is correct, of
course...maybe i'm totally wrong about what the problem is ;-)
--
You received this bug notification because you are a member of
> So, maybe the default SwapUsedLimit is not appropriate for Ubuntu
I don't think tweaking that will help much if at all, it's going to be
hard to get around the core issue of oomd counting pagecache as memory
pressure
--
You received this bug notification because you are a member of Ubuntu
wow, looking at the systemd code (even upstream), oomd is counting
pagecache as 'used' memory which is massively unfair as the kernel is
responsible for pagecache use, not userspace, and it's not even accurate
(from a OOM perspective) since the kernel will drop pagecache as memory
pressure
** Merge proposal linked:
https://code.launchpad.net/~ddstreet/software-properties/+git/software-properties/+merge/417981
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
uploaded to bionic queue, thanks!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1940141
Title:
OpenSSL servers can send a non-empty status_request in a
If you'd rather remove the opt-in part, that's fine with me; I can
sponsor the debdiff then with the opt-in parts left out, if that works
for you Bruce and Nicolas.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in
@ubuntu-security since this is openssl, could you give the debdiff a
review? I can sponsor it as a normal SRU if you have no objections (and
the changes look ok to you), as it doesn't really seem like it would
specifically need to go to the -security pocket.
--
You received this bug notification
> It's not needed for actual functionality of the backport but that
assumes that any future backports or fixes don't break this backport
yes i get that, my comment is about whether or not the patch changes any
code *outside* of the self-tests, e.g. the TLSProxy perl code changes.
If that's *only*
The 2nd upstream patch appears to add new functionality, for actually
parsing a certificate request; is that actually needed (outside of the
self-tests)? If not, it shouldn't be included in the backport.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded
> I have update ongoing on esm-infa-staging for it
just to clarify, if the systemd patch isn't added to the actual main
(currently closed) xenial-updates repo, it won't be very much help to
anyone wanting to create new xenial containers on jammy. So, just
patching systemd in the esm repo likely
> I think this commit [1] may be related (landed in systemd v249)
yeah, that commit seems to be intentionally forcing ACD on for
statically configured ipv4, i'm not sure quite why, it seems like a
user-configured setting should be honored; but possibly Yu was trying to
default it to on instead of
> systemd should drop its setting to defer to the file that we have been
carrying in procps for a very long time.
at some point it would be a better idea to drop the procps files and
adjust the systemd defaults where/if needed. The sysctl configuration
hasn't been applied by procps since upstart;
> "so this is fixed already in f and later" - think you mean "b and
later" here?
yes sorry, fixed in b and later
** Description changed:
[impact]
now that jammy has moved to using unified cgroup2, containers started on
jammy must also use unified cgroup2 (since the cgroup subsystems
Public bug reported:
[impact]
now that jammy has moved to using unified cgroup2, containers started on
jammy must also use unified cgroup2 (since the cgroup subsystems can
only be mounted as v1 or v2 throughout the entire system, including
inside containers).
However, the systemd in xenial does
did you find any alternate way to handle this? If not we should probably
review/merge the 247 naming approach, if @slyon approves
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
** Changed in: systemd (Ubuntu Impish)
Assignee: Dan Streetman (ddstreet) => (unassigned)
** Changed in: systemd (Ubuntu Impish)
Status: In Progress => New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to s
per comment 5, released for impish
** Changed in: systemd (Ubuntu Impish)
Status: Fix Committed => Fix Released
** Changed in: systemd (Ubuntu)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
I think we should ignore hirsute since it reaches EOL next week.
--
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/1949970
Title:
attempt to dlopen nonexistent
ubuntu@lp1949970-f:~$ dpkg -l lightdm|grep lightdm
ii lightdm1.30.0-0ubuntu4~20.04.1 amd64Display Manager
ubuntu@lp1949970-f:~$ journalctl -b -g 'unable to dlopen'
-- Logs begin at Tue 2022-01-11 17:28:51 UTC, end at Tue 2022-01-11 18:02:33
UTC. --
Jan 11 17:58:09 lp1949970-f
ubuntu@lp1949970-i:~$ dpkg -l lightdm|grep lightdm
ii lightdm 1.30.0-0ubuntu4
amd64Display Manager
ubuntu@lp1949970-i:~$ journalctl -b -g 'unable to dlopen'
-- Journal begins at Tue 2022-01-11 17:28:57 UTC, ends at Tue 2022-01-11
17:59:05
Also for future reference I think upstream commit
fb3aec45a0de7f71aa6418bd4f9d5f314efb4eb5 fixes this, but I never got a
chance to test it before upgrading.
** Changed in: systemd (Ubuntu Focal)
Status: New => Incomplete
** Changed in: systemd (Ubuntu)
Status: New => Fix Released
it's no longer a problem for me as I've upgraded to
impish, I'm dropping ownership of this, but if anyone else has this
problem (i.e. can reproduce it) please reopen the bug and/or add a
comment.
** Changed in: systemd (Ubuntu Focal)
Assignee: Dan Streetman (ddstreet) => (unassigned)
** Chan
** Changed in: systemd (Ubuntu Focal)
Assignee: (unassigned) => Dan Streetman (ddstreet)
** Changed in: systemd (Ubuntu Focal)
Importance: Undecided => Medium
** Changed in: systemd (Ubuntu Focal)
Status: New => In Progress
--
You received this bug notification be
** Bug watch added: github.com/systemd/systemd/issues #15528
https://github.com/systemd/systemd/issues/15528
** Also affects: systemd via
https://github.com/systemd/systemd/issues/15528
Importance: Unknown
Status: Unknown
** Also affects: systemd (Ubuntu Focal)
Importance:
> Reverting this upstream commit seems to fix the problem:
> https://github.com/systemd/systemd/commit/0299deab53d2a087727a5d04c1500c322c48b63e
lxd and systemd have what I can only describe euphemistically as a
horrible relationship. Instead of carrying another patch on systemd to
get it working
> Is there a ppa with a more recent systemd-resolved to try on focal
yes, https://launchpad.net/~ubuntu-support-team/+archive/ubuntu/systemd
however that includes the entire upstream systemd code, not only
systemd-resolved; i'd suggest you test inside a VM and not on your main
system.
--
You
> It's not something that snapd writes out, it's curious where this
comes from
it's not written out, it's internally handled/added by pid1, and it
*should* be there, because you do want (for example) the mount to be
stopped if its backing device is removed. However when the mount is
stopped, the
Sorry to clarify that, the dep is added to the mount over a daemon-
reload, but only on core:
ddstreet@localhost:~$ systemctl list-dependencies snap-hello\\x2dworld-29.mount
snap-hello\x2dworld-29.mount
● ├─-.mount
● ├─snap.mount
● ├─system.slice
● └─var-lib-snapd.mount
ddstreet@localhost:~$
This added BindsTo is what's causing the problem:
ddstreet@localhost:~$ systemctl show -p BindsTo snap-hello\\x2dworld-29.mount
BindsTo=
ddstreet@localhost:~$ sudo systemctl daemon-reload
ddstreet@localhost:~$ systemctl show -p BindsTo snap-hello\\x2dworld-29.mount
BindsTo=dev-loop6.device
Note one interesting point is that in a core18 system, a squashfs mount
(any loop-based mount, really) includes a dep from the mount to its loop
device, while the non-core system does not:
ddstreet@localhost:~$ cat /etc/issue
Ubuntu Core 18 on \4 (\l)
ddstreet@localhost:~$ systemctl
> @slyon you might want to see if commit
918e6f1c0151429f5095355f4f3f74f16e79724a fixes this
(and there are a couple follow on commits to this)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
@slyon you might want to see if commit
918e6f1c0151429f5095355f4f3f74f16e79724a fixes this
--
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/1949089
Title:
systemd randomly
** Changed in: trusty-backports
Status: New => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1591490
Title:
Please backport apt 1.0.9.2ubuntu2 from utopic
** Changed in: trusty-backports
Status: New => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-themes in Ubuntu.
https://bugs.launchpad.net/bugs/1285783
Title:
Right panel has a transparent
** Changed in: hardy-backports
Status: Incomplete => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to qt4-x11 in Ubuntu.
https://bugs.launchpad.net/bugs/326217
Title:
QT libraries in hardy broken because of
** Changed in: hardy-backports
Status: New => Won't Fix
--
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/313960
Title:
Please update dnsmasq hardy packages to
** Changed in: lucid-backports
Status: New => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to modemmanager in Ubuntu.
https://bugs.launchpad.net/bugs/792301
Title:
Ericsson F5521gw 3G module for Lenovo not
** Changed in: oneiric-backports
Status: New => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tracker in Ubuntu.
https://bugs.launchpad.net/bugs/865907
Title:
Please backport tracker to Oneiric
Status
Hello,
the backports process has recently been updated, please see the new
documentation:
https://wiki.ubuntu.com/UbuntuBackports
I'm closing this bug, but please feel free to open a new bug (or reopen
this bug) using the new process, if appropriate.
** Changed in: bionic-backports
Public bug reported:
FTBFS with new meson:
../meson.build:46:3: ERROR: Object <[BooleanHolder] holds [bool]: False>
of type bool does not support the `+` operator.
** Affects: systemd (Ubuntu)
Importance: High
Assignee: Dan Streetman (ddstreet)
Status: In Progress
** A
** Changed in: systemd (Ubuntu Jammy)
Assignee: (unassigned) => Dan Streetman (ddstreet)
** Changed in: systemd (Ubuntu Impish)
Assignee: (unassigned) => Dan Streetman (ddstreet)
** Changed in: systemd (Ubuntu Jammy)
Importance: Undecided => Medium
** Changed in: system
Public bug reported:
[impact]
after systemd was changed to default to cgroupv2, any container started
on a host that still uses legacy or hybrid cgroup mounts will result in
a container that attempts to use unified cgroup but can't due to all the
controllers being used as v1 in the host kernel.
: Medium
Assignee: Dan Streetman (ddstreet)
Status: In Progress
** Also affects: systemd (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: systemd (Ubuntu Focal)
Assignee: (unassigned) => Dan Streetman (ddstreet)
** Changed in: systemd (Ubuntu Fo
> and in QEMU it seems that this bug is not reproducible
can you provide steps on how this is reproducable then?
--
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/1949089
** Also affects: lightdm (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: lightdm (Ubuntu Bionic)
Importance: Undecided => Low
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lightdm in Ubuntu.
** Description changed:
[impact]
lightdm's pam.d config includes an attempt to dlopen pam_kwallet.so as
well as pam_kwallet5.so, however pam_wallet.so comes from pam-kwallet
which died around Trusty (https://launchpad.net/ubuntu/+source/pam-
kwallet) while pam_kwallet5.so comes from
Public bug reported:
[impact]
lightdm's pam.d config includes an attempt to dlopen pam_kwallet.so as
well as pam_kwallet5.so, however pam_wallet.so comes from pam-kwallet
which died around Trusty (https://launchpad.net/ubuntu/+source/pam-
kwallet) while pam_kwallet5.so comes from kwallet-pam
> the additional information contains valid data.
then I think SRU'ing this would cause a behavior change that could
possibly break someone, which isn't something we should do.
I'd suggest putting the fix behind some opt-in mechanism, so anyone who
is affected can opt-in to the fixed behavior,
> /usr/lib/udev/rules.d/90-pi-bluetooth.rules:14 Invalid value ...
rules provided by pi-bluetooth package, not systemd.
** Package changed: systemd (Ubuntu) => pi-bluetooth (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
> [ 82.230208] Lockdown: systemd-logind: hibernation is restricted;
see man kernel_lockdown.7
you're using UEFI secure boot, which puts the system into 'lockdown',
which disallows (unencrypted) hibernation.
So this isn't a problem with systemd, this requires the kernel to handle
encrypted
You have 16G of memory:
> [0.081527] Memory: 15609664K/16134968K available
But you only seem to have 2G of swap:
[2.770354] Adding 2097148k swap on /swapfile
There is no way hibernation is possible on your system with this setup.
** Changed in: systemd (Ubuntu)
Status: New =>
Ok let's go with option #1 then, just open up systemd-logind to network
access directly by editing the service file.
@mbiebl, do you want to patch this in Debian too, should I open a merge
request in salsa? Obviously if Debian is patched first, that's ideal.
Assuming you're ok with directly
> I like the idea of the kernel command line argument because it is
easy to apply and consistent across install types.
I agree the kernel boot param is absolutely easier, especially in the
context of maas.
TL;DR from me is: I think it's at least worth looking at using a link
file, or some other
> how would one insert such a file during (and early enough) in the
commissioning process?
well, i'll leave that one up to the maas team to answer properly, but i think
there are ways to use custom commissioning scripts:
https://maas.io/docs/commissioning-scripts-reference
or even custom
> udev can produce unpredictable network interface names by default when
multiple devices map to the same slot due to an intermediate bridge.
so, if I understand it right, the MR won't actually fix this for anyone
without additional per-system work, right? specifically, any system with
this
** Bug watch added: github.com/systemd/systemd/issues #20993
https://github.com/systemd/systemd/issues/20993
** Also affects: systemd via
https://github.com/systemd/systemd/issues/20993
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a
*** This bug is a duplicate of bug 1742804 ***
https://bugs.launchpad.net/bugs/1742804
** This bug has been marked a duplicate of bug 1742804
Failed to add PIDs to scope's control group
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which
for later reference, i'd discussed this with nick and asked him to check
if the 'status_request' reply contained any kind of valid data in the
specific cases where this patch will disable it; my concern is if there
is valid data in it, it's possible there are applications out there that
might
your system has kernel warnings and hung task errors, and you appear to
be using an unsupported 5.9 kernel, it seems the problem is there, not
with systemd/udevd.
** Package changed: systemd (Ubuntu) => linux (Ubuntu)
** Changed in: linux (Ubuntu)
Status: New => Invalid
--
You received
> "ubuntu systemd-udevd[911]: Network interface NamePolicy= disabled on
kernel command line, ignoring."
yes..you have disabled it on the kernel command line. I don't understand
what the bug is here?
** Changed in: systemd (Ubuntu)
Status: New => Invalid
--
You received this bug
*** This bug is a duplicate of bug 1944711 ***
https://bugs.launchpad.net/bugs/1944711
I suspect this is due to bug 1944711, which i'll dup this one to; i know
your bug is far older, but since i couldn't reproduce your bug and i'm
not sure if it's the same, i didn't want to take it over with
ded in v246, so
this is fixed in h and later already.
+
+ in b, the function used to parse the /run/systemd/users/* files allows
+ either usernames or uids, so this bug does not exist there
** Changed in: systemd (Ubuntu Focal)
Assignee: (unassigned) => Dan Streetman (ddstreet)
** C
Public bug reported:
[impact]
restarting the systemd-logind service loses all existing sessions
[test case]
ubuntu@test-f:~$ loginctl list-sessions
SESSION UID USER SEAT TTY
3789 1000 ubuntu pts/0
1 sessions listed.
ubuntu@test-f:~$ journalctl -b -u systemd-logind
-- Logs begin
One good point in favor of including systemd-userdbd in Debian/Ubuntu
would be that we only need to adjust the restrictions for that service;
all other systemd-provided services would use (or at least, *should*
use...) systemd-userdbd to get user records. I'm not sure if that is
actually worth
** Description changed:
[impact]
starting in focal, systemd-logind runs sandboxed without any network
access, which breaks any configuration that uses remote servers for user
data, e.g. ldap, nis, etc
A more full discussion is available in the upstream bug report as well
as the
> @Dan: have you actually confirmed, that building and running userdbd
solves those issues with NIS and LDAP?
sorry for the delay in getting back to this.
So, you're correct, userdb doesn't actually help this, it only moves the
problem.
While systemd-userdbd.service does (currently, at least)
you state you have systemd version 245.4-4ubuntu3.13 installed, but your
description shows otherwise:
Package: systemd-container 245.4-4ubuntu3.11
** Changed in: systemd (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch
this was marked fix-released for f/h just due to the tooling matching
the bug number; this was actually reverted as shown in the changelogs
posted in the above comments. I'll just correct f/h to indicate this is
wontfix, and a new bug will or has been opened to fix this correctly.
** Changed in:
as systemd was respun (for focal) due to bug 1942899, and only the one
udev (hwdb) patch was reverted which shouldn't affect this at all, I'm
remarking this as verified still based on testing for the previous
version above.
** Tags removed: verification-needed verification-needed-focal
** Tags
as systemd was respun due to bug 1942899, and only the one udev (hwdb)
patch was reverted which shouldn't affect this at all, I'm remarking
this as verified still based on testing for the previous version above.
** Tags removed: verification-needed verification-needed-focal
** Tags added:
root@lp1853164-b:~# dpkg -l systemd|grep systemd
ii systemd237-3ubuntu10.51 amd64system and service manager
root@lp1853164-b:~# dpkg -l | grep -E 'ifupdown|resolvconf'
ii ifupdown 0.8.17ubuntu1.1 amd64
high level tools to
as systemd was respun due to bug 1942899, and only the one udev (hwdb)
patch was reverted which shouldn't affect this at all, I'm remarking
this as verified still based on testing for the previous version above.
--
You received this bug notification because you are a member of Ubuntu
Touch
heh, please ignore the above comment, the current focal systemd was
respun, but the fix for this was already released for focal, this only
needs bionic verified now :)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd
for the verifications above, i also updated the 'udev' package to the
same version as systemd
** Tags removed: verification-needed verification-needed-focal
verification-needed-hirsute
** Tags added: verification-done verification-done-focal
verification-done-hirsute
--
You received this bug
commit to focal that needed reverting:
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?h=ubuntu-focal=5c1be33900edee94da0dc9a4ade8edcd079b4c85
ubuntu@lp1942899-f:~$ dpkg -l systemd|grep systemd
ii systemd245.4-4ubuntu3.11 amd64system and service manager
commit to hirsute that needed reverting:
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=a21edd743408b5603b0177e9c230c6d6b919e589
ubuntu@lp1942899-h:~$ dpkg -l systemd|grep systemd
ii systemd247.3-3ubuntu3.4 amd64system and service manager
** Description changed:
[impact]
initial patch for LP: #1938259 was incorrect.
[test case]
this bug is only to revert the previous patch
+
+ the upstream commit
+
is:https://github.com/systemd/systemd/pull/20314/commits/55b29d8f130684bf1fd9fdfaef3bcca64b66930e
+
+ checking for
1 - 100 of 2707 matches
Mail list logo
