Another odd detail I have seen that your error is
internal error: unable to execute QEMU command 'blockdev-remove-medium': Tray
of device 'sata0-0-0' is not open
But your cdrom isn't sata at all
--
You received this bug notification be
Now I arrived at the same case you had - a slightly off-defaults guest
that booted into the ISO again as we have configured it to do it that
way. And now - while booted into the ISO you want to detach. Actually
that won't work on a physical device either, the CD will refuse to eject
as it is in use
I also booted the - no installed - centos7 and inserted the ISO into the
virtual CD.
Then (as your example had tray='open') I ejected the (Virtual) CD via `eject
-m`.
Now I have:
Detaching in that state still works fine in both s
Maybe your new examples have used the actual defaults (q35 and sata
cdrom) and therefore the recent error messages are that way. But even
assuming that still too much is somewhat odd here and I fail to recreate
the issue :-/
Sorry, I really tried to get a hold on this issue but there must be more
This still somewhat is the case blocking things from -proposed.
Tests still fail in
Ubuntu-Impish:
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/p/puppetdb/20210510_122706_91fc7@/log.gz
Current Debian:
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/puppetdb/126725
Hi Harry,
thanks for the testcase, this indeed looks interesting.
virtiofsd is still rather new and growing extra features/fixes all the
time. The jump from qemu 5.0 -> 5.2 also had plenty of changes there,
maybe you'd hit one of those and this might (eventually) be a bug in the
recent upstream.
Hmm, my testing environment has let me down on this (not enough memory
atm and too slow second level virt). I'll need to look into this again
later on with a real host that I can re-deploy to groovy/hirsute for
this test.
I've looked at patches and mailing list a bit and found no obvious fix that
Public bug reported:
Systemd 248.3-1ubuntu1 is rather new, but had 5 successful tests on armhf
before now slipping into a bad mode.
Now it seems all tests failed in boot-and-services by hanging until killed by
VirtSubproc.Timeout of autokgtest.
The last [1] test log has a bit more, it shows a py
I was adding a few of the blocked packages as incomplete tasks to have
this bug update-excuse show up in excuses. Right now until we know
better I'd consider this a systemd issue.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:/
As I said I tried to recreate this, but it worked.
It was fine under Focal/5.4.0-53-generic Host with the Impish-armhf container.
Upgrading the host to impish it Impish/5.11.0-16-generic still works fine.
It seems it only fails in autopkgtest infrastructure, not sure why yet
:-/
--
You received
Public bug reported:
The test of dogtag-pki is failing on the nss 3.63 that is in impish proposed.
Example:
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/s390x/d/dogtag-pki/20210516_212719_e6522@/log.gz
Bad:
Installing CA into /var/lib/pki/pki-tomcat.
Installation failed: ('Con
FYI by tjaaltonen - there's another crasher in 3.66 on ppc64el..
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989410
So 3.66 won't be the "take this and it works" solution.
** Bug watch added: Debian Bug tracker #989410
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989410
--
You re
While we wait for 3.67 and maybe (Thanks Timo) for [1] I have ensured that we
have a 3.66 test build.
=> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4577/+packages
The check of it's delta also showed that we can drop a bit of it nowadays.
=>
https://code.launchpad.net/~paelzer/ub
Yeah Dmitry, thanks for reminding everyone about it.
But TBH I have not had the feeling that the feeling that the kernel team
(which needs to do it) had started working/thinking on this case.
@Kernel Team - ping is this on your radar at all or did it fall through
the cracks?
--
You received thi
Hi,
thanks for ruling out the type of the machine and the attachment.
But as I said above I didn't see the same with centos7 guests.
To be sure I had then forced the tray='open' for sata and ide cases but was
not hitting the issue either.
Neither on qemu 4.2 nor on 5.2 reproduced this for me so
I was able to verify that a merge of 3.66 would on Ubuntu trigger the
very same bug that Debian has blocking the dogtag-pki test on powerpc64.
=> https://autopkgtest.ubuntu.com/results/autopkgtest-impish-ci-train-
ppa-service-4577/impish/ppc64el/d/dogtag-
pki/20210608_031158_a9d4a@/log.gz
--
You
There is another fix in master that belongs to
https://bugzilla.mozilla.org/show_bug.cgi?id=1566124 - I've bumped my
PPA build to include both as it is worth a try if this fixes the current
ppc64 issues in v3.66.
Build of 3.66-1ubuntu1~impishppa2 started, later on I'll let the
autopkgtests run.
*
Public bug reported:
Hi,
as seen in
https://launchpadlibrarian.net/536144995/buildlog_ubuntu-impish-ppc64el.xrdp_0.9.15-1_BUILDING.txt.gz
https://launchpadlibrarian.net/536175263/buildlog_ubuntu-impish-s390x.xrdp_0.9.15-1_BUILDING.txt.gz
This currently fails to build on ppc64el and s390x.
Upstre
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983843 is the
corresponding Debian bug
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1931225
Title:
0.9.15 is FTFBS on ppc64el and s390x
To manage
Public bug reported:
Hi,
I've found this to fail to build in update-excuses.
It turns out that on s390x it actually builds fine, but the following
self-tests that are executed make konclude run into a segfault.
Example failing log:
https://launchpadlibrarian.net/542007740/buildlog_ubuntu-impish-
FYI for some reasons this worked in Debian
https://buildd.debian.org/status/fetch.php?pkg=konclude&arch=s390x&ver=0.7.0%2B1137%7Edfsg-1&stamp=1618864031&raw=0
So it could (unproven theory) be due to the different default compiler
version?
** Tags added: update-excuse
--
You received this bug no
Also blocking isc-dhcp now, added a task
** Also affects: isc-dhcp (Ubuntu)
Importance: Undecided
Status: New
** Changed in: isc-dhcp (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Public bug reported:
The bug here is mostly for tracking and the update-excuse tag.
I've reported it to Debian already at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989589
And at upstream:
https://sourceforge.net/p/gptfdisk/mailman/gptfdisk-general/thread/CAATJJ0LdpVeVGMMaYUe995%3DZFtuJu6
As it turns out gdisk/sgdisk have since the dawn of time written labels
byte-swapped on s390x.
We'll continue to help in the upstream discussion and once a solution is
available consider backporting (or not as it might wreak more havoc than not).
Affected are all releases since Xenial and also n
Fix in https://sourceforge.net/p/gptfdisk/code/merge-requests/26/
** Bug watch added: Debian Bug tracker #989589
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989589
** Also affects: gdisk (Debian) via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989589
Importance: Unknown
Public bug reported:
This package only has arch:all binaries which are not meant to be tested
on i386 where this currently fails due to some non-i386 dependencies.
Merging this MP would fix it:
https://code.launchpad.net/~paelzer/britney/+git/hints-ubuntu/+merge/403885
This bug mostly exists fo
Hi Robert,
thanks for chiming in - I have to admit that I'm dedicated to other tasks this
week so I beg your pardon for taking a while to digest all that good data that
you added.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https
Public bug reported:
Hi,
I spotted this while checking excuses for +1 duty.
Lintian-brush currently is affected by a set of issues:
Ubuntu tests
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/l/lintian-brush/20210524_182220_e891a@/log.gz
Debci Tests:
https://ci.debian.net/
Public bug reported:
This is due to qemu-kvm not existing on all architectures, but actually
more so as the upstream project behind qemu-web-desktop is somewhat
x86-only.
I've reported the problem and suggested solutions at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989638
** Affects: qem
Public bug reported:
Ubuntu https://launchpad.net/ubuntu/+source/gdebi/0.9.5.7+nmu5 is an FTBFS
https://launchpadlibrarian.net/542966965/buildlog_ubuntu-impish-amd64.gdebi_0.9.5.7+nmu5_BUILDING.txt.gz
The same https://launchpad.net/ubuntu/+source/gdebi/0.9.5.7+nmu4 worked
as it was builds against
This feels like a circle with nss/2:3.66-1ubuntu1~impishppa2 in
https://launchpad.net/~ci-train-ppa-
service/+archive/ubuntu/4577/+packages now ppc64 works but s390x fails
with (on the surface) the same symptom as it started with in 3.63 :-/
I retriggered the tests to see if that is flaky or repro
** Branch linked: lp:~paelzer/gdebi/gdebi-fix-glib-2.68
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1931394
Title:
With glib2 2.68 gdebi is an FTBFS (hangs)
To manage notifications about this bug
Reproducible, ppc64 is fixed and s390x broken by the latest 3.66 + fixes from
master.
Links:
https://autopkgtest.ubuntu.com/results/autopkgtest-impish-ci-train-ppa-service-4577/impish/s390x/d/dogtag-pki/20210609_065306_2e698@/log.gz
https://autopkgtest.ubuntu.com/results/autopkgtest-impish-ci-trai
Without the recent PPC fixes s390x was broken as well, so I'm not saying "the
ppc fixes broke s390x":
https://autopkgtest.ubuntu.com/results/autopkgtest-impish-ci-train-ppa-service-4577/impish/s390x/d/dogtag-pki/20210608_073451_f187d@/log.gz
Instead there seems to be a new crash affecting s390x t
Public bug reported:
clisp segfaults wehn compiling xindy in impish
for i in src tex2xindy user-commands; do /usr/bin/make -C $i all || exit 1; done
make[1]: Entering directory '/<>/src'
sed 's|@MODULEDIR[@]|/usr/lib/xindy/modules|g' <./defaults.xdy.in >defaults.xdy
/usr/bin/clisp -q -E iso-8859-
Attaching a full backtrace of the fail.
** Attachment added: "Detailed backtrace of the fail (long thanks to the lisp
paradigms)"
https://bugs.launchpad.net/ubuntu/+source/xindy/+bug/1931531/+attachment/5503785/+files/clisp-xindy-fail.log
--
You received this bug notification because you ar
This is resolved from bionic onwards
clisp | 1:2.49-8.1| precise/universe |
source, amd64, i386, powerpc
clisp | 1:2.49-9ubuntu1 | trusty/universe |
source, amd64, armhf, i386, powerpc
clisp | 1:2.49-9ubuntu1
Thank you Rod, trying to pick this up for Impish in a few days.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1931243
Title:
FTBFS in Impish on s390x
To manage notifications about this bug go to:
h
** Tags added: update-excuse
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1931531
Title:
clisp crashed in impish compiling xindy
To manage notifications about this bug go to:
https://bugs.launchpa
Clisp error:
/home/ubuntu/clisp-2.49.20180218+really2.49.92/src/lispbibl.d:6673:6: error:
#error oint_addr_mask does not cover CODE_ADDRESS_RANGE !!
6673 | #error oint_addr_mask does not cover CODE_ADDRESS_RANGE !!
|
--
You received this bug notification because you are a member of Ub
Note:
On Debian s390x xindy build doesn't even start to build as it has missing
build-depdencies.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1931531
Title:
clisp crashed in impish compiling xindy
The code for the error in clisp is:
/* Verify the oint_addr_shift value w.r.t. the autoconfigured CODE_ADDRESS_RANGE
and MALLOC_ADDRESS_RANGE values. */
#if !defined(WIDE_SOFT)
/* The CODE_ADDRESS_RANGE needs to be checked because we store code
pointers in Lisp objects (cf. macro ThePseu
I've built the same in Hirsute, just as broken :-/
Last successful build was in Focal.
Note Focal has the same clisp version and only two debian packaging
versions bumped for xindy.
So I'll start at Focal trying to find a working environment.
build impish version of clisp in impish - fail
build im
Good build log:
https://launchpadlibrarian.net/440395396/buildlog_ubuntu-eoan-s390x.clisp_1%3A2.49.20180218+really2.49.92-3build3_BUILDING.txt.gz
Happened mid Eoan on 2019-09-05 so final Eoan might be just as bad as
focal.
Build xindy/clisp in Disco - same fail
Build xindy/clisp in Eoan - same fa
As last resort I have built the latest clisp from upstream
without packaging magic just the way upstream intends to.
But since the last version from upstream is more than a decade old from
2010-07-07 maybe the time has come to ignore it.
Latest release still is that from
https://ftp.gnu.org/pub/g
** Attachment added: "upstream tarball of clisp failing the same way"
https://bugs.launchpad.net/ubuntu/+source/xindy/+bug/1931531/+attachment/5503834/+files/clsip-clean-fail.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
http
For Reference - the failed builds that had me start to look at this:
https://launchpad.net/ubuntu/+source/clisp/1:2.49.20180218+really2.49.92-3build5
https://launchpad.net/ubuntu/+source/xindy/2.5.1.20160104-10
--
You received this bug notification because you are a member of Ubuntu
Bugs, which i
I'll time-box my activity for now, since it works on other platforms
a removal might be too hard.
But if you happen to find other related issues please add them here so that
when it gets too much it can be considered to be removed.
For the sake of not fully giving up I've reported it upstream at:
Hi,
First of all there are two services - and maybe outlining the difference and
the reasoning will help here.
# Reasons
It is fair to say that probably >99% of the users are not using open-
iscsi and therefore having the daemon started on install (and it is
default installed for cases that need
Yeah that is the mentioned workaround that we have identified before
wrapped up nicely for consumption. Still - like many others - I'd want
to understand the problem :-)
And BTW I wanted to mention a lot of thanks to everyone participating so far!
It makes me feel proud of our user community to wo
The puzzling bit here is that libvirtd is the service that is ran as root by
systemd.
I'm not seeing why the kind of user that calls virt-manager/virsh would make
any difference.
As the problem so far seemed to be on the service side.
And it still is for your log
Jun 8 14:59:20 notebook kernel:
Testcase:
# Setup Ldap/SSSD based on the tests
sudo apt install sssd sssd-ldap slapd ldap-utils openssl expect lsb-release
virt-manager ubuntu-dev-tools
echo "*;*;*;Al-2400;libvirt" | sudo tee -a /etc/security/group.conf
sudo pull-lp-source sssd
cd sssd-2.4.1
head -n -5 debian/tests/ldap-user
Maybe the setup is a bit broken as I was rather rude and direct setting this up.
I've seen two things:
1. I was seeing that the PID on this denial was always changing
2. I found that this crashed libvirt like
Jun 14 09:36:44 ldap.example.com libvirtd[4585]: Illegal status in __nss_next.
Jun 14 09
Update Repro steps:
- add a pre-upgrade
- virt-manager isn't needed, install a few less deps
- use non interactive install
# Repro
sudo apt update; sudo apt dist-upgrade -y
sudo apt install -y sssd sssd-ldap slapd ldap-utils openssl expect lsb-release
libvirt-clients libvirt-daemon-system ubun
Theory/Summary:
- the sssd login makes libvirt need to resolve a uid/gid as it isn't known
locally
- once that worked it isn't re-done later on
- To resolve it it needs to bind a unix socket
Jun 14 11:25:24 ldap.example.com kernel: audit: type=1400
audit(1623669923.999:144): apparmor="DENIED" o
Status: Confirmed => Triaged
** Changed in: libvirt (Ubuntu Focal)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
** Changed in: libvirt (Ubuntu Focal)
Assignee: Christian Ehrhardt (paelzer) => Ubuntu Security Team
(ubuntu-security)
--
You received this bug no
** Description changed:
+ [Impact]
+
+ * libvirt in Focal in some cases e.g. with non local users
+needs to resolve those users. When trying to do so it fails
+due to apparmor isolation and breaks badly.
+
+ * In later and former releases this issue isn't triggered,
+but it is unkn
I prepared the SRU Template in the description of this bug and furthermore
a PPA: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4582
@Robert - While it is just a single apparmor line added it would still
be great if you could give this PPA an A/B comparison before we kick off
the rea
:-) NP Seth - Yes the "local" was only for manual workarounds in this bug.
And the proposed fix is in the right place for the package.
The abstractions, or generally other places for that rule are interesting.
Because as I stated above while I now finally can recreate it in Focal it is
gone in l
Limiting the rules is always good, so I went back to the repro setup.
I was trying various limitations for userdb- like:
@Seth - Thanks for the hint to check the addr element, now that I've
found the root cause in systemd we can be sure what the pattern will
look like.
I have found that the follo
We could consider adding that to libvirt's profile directly.
Or to add it to `abstractions/nameservice` as it is nss means that trigger this.
Is that really the right place?
In the latter case I'd still need a libvirt SRU as it didn't need and
include abstractions/nameservice up to now.
@Seth wha
** Tags added: qemu-21.10
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** Changed in: qemu (Ubuntu)
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.ne
Ping, I know the queue is full and resources scarce but we are really
waiting for this to have at least one release (21.10) out in the field
before hitting an LTS (22.04) with it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:/
This now shows up in compoenent mismatches (Impish) and can be promoted.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1930207
Title:
[MIR] prips package
To manage notifications about this bug go t
All three issues are Fixed in version lintian-brush/0.106
lintian-brush | 0.106 | impish-proposed/universe | source, all
But that will be stuck in proposed for now as there is a new test issue
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/l/lintian-brush/20210614_0
** Tags removed: server-next
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1891202
Title:
Multipathd hangs with long iscsi target names in Ubuntu 18.04
To manage notifications about this bug go to:
** Tags removed: server-next
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1825712
Title:
bind9 is compiled without support for EdDSA DNSSEC keys
To manage notifications about this bug go to:
https
** Changed in: openssh (Ubuntu)
Assignee: Colin Watson (cjwatson) => (unassigned)
** Changed in: openssh (Ubuntu Trusty)
Status: Triaged => Won't Fix
** Tags removed: server-next
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ub
** Tags removed: server-next
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1792298
Title:
keepalived: MISC healthchecker's exit status is erroneously treated as
a permanent error
To manage notifi
** Tags removed: server-next
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1761096
Title:
dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed
To manage notifications about this bu
Thanks Seth and Robert,
I'll follows Seth advise and for now propose (B) being the fix for libvirt.
But I'll add a task for apparmor (which carries abstraction/namespace) as that
still might be an avenue worthwhile to follow independent to this libvirt fix.
If more people speak up or we find more
FYI MP
https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/libvirt/+merge/404124
updated with the more restricted rule.
I also updated the PPA with the new rule.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bug
Thank you, thereby this is ready to be promoted.
It is not yet in component mismatches, so @utkarsh please pull it in somehow.
** Changed in: python-aws-requests-auth (Ubuntu)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which i
I got a proposed RFC for the fix from Ioanna (thanks!) which I have reviewed.
But there is nothing sent to upstream for discussion so far.
I'll bump the tag to 22.04 to manage expecations of anyone else looking
at this, but I'm happy to apply if we can get it upstream before 21.10
feature freeze.
** Tags removed: libvirt-21.10
** Changed in: libvirt (Ubuntu)
Status: Incomplete => Invalid
** Changed in: libvirt (Ubuntu)
Assignee: Canonical Server Team (canonical-server) => (unassigned)
** Changed in: libvirt (Ubuntu)
Milestone: ubuntu-19.10 => None
--
You received this b
Public bug reported:
With qemu 6.0 you'll see issues with hotplug on attach-device (there are
more cases than the examples show)
attach-device hotplug-rng.xml+ uvt-kvm ssh --insecure impish-kvm 'virsh -c
qemu:///system attach-device impish-2nd-hotplug hotplug-rng.xml'
error: Failed to attach dev
** Tags added: libvirt-21.10 qemu-21.10
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1932264
Title:
qemu 6.0 breaks libvirt <7.2
To manage notifications about this bug go to:
https://bugs.launchpa
The dependencies already are (and would stay)
iptables (>= 1.8.1-1) | firewalld
from Package: libvirt-daemon-system.
This is very much the same in Debian where we have kept it enabled.
Therefore I can enable the support in libvirt without pushing anything into
main that isn't supposed to be ther
FYI - Uploaded to Focal-unapproved
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890858
Title:
AppArmor profile causes QEMU/KVM - Not Connected
To manage notifications about this bug go to:
https:
** Tags added: server-next
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1931063
Title:
Include powerpc port upstream fixes to librpmem 1.10 on pmdk package
To manage notifications about this bug g
Thanks for the review Alex!
SDL as qemu backend is in many cases inferior to GTK which we continue
to use and recommend as default. But at the same time there are over and
over some edge cases where SDL would be beneficial to users. For those
we wanted and will be able to enable it now - that will
FYI I added the package subscription while we intend to complete this to
not miss it later.
BTW it might be time for the dependency stats of the day on this topic
comparing v1 and v2:
Mid 2017:
dep-sdl1.2: 400
b-dep-sdl1.2: 327
Mid2020
dep-sdl2: 179
b-dep-sdl2: 154
dep-sdl1.2: 379
b-dep-sdl1.2:
Thanks for the quick test, works for me as well.
The global verification-done tag might be needed as well for the tools to work,
adding that back.
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https
Cups rightfully includes nameservices like:
#include
After our analysis in bug 1890858 I think it is fair to request an SRU
update apparmor in Focal (only needed there, see bug 1890858 for
details). As it would fix this element in Cups and actually
The apparmor section of this is now properly covered in bug 1932537,
therefore I'm dropping the apparmor task from this one.
** No longer affects: apparmor (Ubuntu)
** No longer affects: apparmor (Ubuntu Focal)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
We finally got an answer to our questions/pings (thanks Simon)
=> https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q2/015134.html
TL;DR: this might be wanted new behavior :/ ?!
@Laney - You initially started this when we have faced this bug
I wonder now if we should indeed drop our d
As crazy as it seems after all the time we can now enable SDL without pulling
it into main (as we have done some splits of runtime modules and -gui
components in the past years).
I'll first try to implement it that way.
--
You received this bug notification because you are a member of Ubuntu
Bu
Yeah I'm also not entirely sure.
But I'm assuming that the maintainers insight into all the interactions is
better than mine and therefore tend to follow.
About the "why the difference DHCPv6 vs SLAAC" I think that is fine
because the code now allows to behave different (reasonable). And the
defa
Yes that should be fine, it was discussed and reviewed with that in
mind.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1915445
Title:
[MIR] python-aws-requests-auth package
To manage notifications
** Changed in: libsdl2 (Ubuntu)
Status: New => In Progress
** Changed in: libsdl2 (Ubuntu)
Status: In Progress => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1256185
Title:
** Changed in: flatpak (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1812456
Title:
[MIR] libflatpak0
To manage notifications about this bug go to:
https:/
Hi Billy,
thanks for the ping!
Before in comment #9 it was reported that our current
reproducer/testcase wasn't present on Bionic/Focal. Also some of the fix
was "make it as it was in focal" so soemthing is odd here.
Do you happen to have a non-charm based way to trigger the issue on
Focal that w
Thanks Alex,
I'll rebase and polish it and hand it over to a team member for review then.
But what I'd still need is some written out test steps for the SRU process.
Since you have just verified it would you mind adding a statement here that I
could copy into the SRU template then?
** Tags added
$ git tag --contains dbeb20a667e82e4efb8b26b24a0ec641dab5c857
v7.11
ipset | 6.34-1 | bionic | source, amd64, arm64, armhf, i386,
ppc64el, s390x
ipset | 7.5-1~exp1 | focal| source, amd64, arm64, armhf, ppc64el,
riscv64, s390x
ipset | 7.6-2 | groovy | so
** Changed in: ipset (Ubuntu Bionic)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1918936
Title:
ipset does NSS lookups even if ports are numeric
To manage notificati
I have wrapped you all of this up in MPs that should do it.
I have scripts to do most of that, so it was fast and easy to do and applies
cleanly.
But it is the openstacks team package and I don't want to interfere too much.
OTOH from here - if they like it - they can more or less checkout&upload.
I have rebased and finalized the MP for this:
https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/libvirt/+merge/395778
This is now open for review by the Team.
Furthermore I have opened a new PPA to have up-to-date test builds.
new PPA:
https://launchpad.net/~ci-train-ppa-service/+ar
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1891202
Title:
Multipathd hangs with long iscsi target names in Ubuntu 18.04
To manage notifications about this bug go
Thanks for the feedback Stefan (and the Help Dan).
I'll mark the bug as invalid then as there is nothing to fix in a package for
it.
** Changed in: init-system-helpers (Ubuntu)
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, wh
Just a warning, the debdiff is wrong 2.1.71-0ubuntu2 needs to be
2.1.71-0ubuntu1.1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1865037
Title:
make the service fail gracefully if unable to load mod
201 - 300 of 10728 matches
Mail list logo
