[01:50] <amurray> jamespage: jdstrand has uploaded my iptables updates for hirsute and groovy - groovy is still in unapproved but hirsute is in -proposed - could you please verify this resolves the issue with neutron-linuxbridge-agent? (I have checked it via the simple iptables-restore test in the bug)
[01:52] <amurray> jamespage: but I don't have a configured install of openstack/neutron to test that neutron-linuxbridge-agent itself is happier with this change so it would be good to get this verified as well if possible
[09:10] <jamespage> amurray: yep we can do that
[09:10] <jamespage> we had an alternative reproducer as well
[09:17] <mwhudson> cpaelzer__: "Merge with Debian unstable (LP: #9999999)" :)
[09:39] <cpaelzer__> did that get into the changelog mwhudson - grml
[09:39] <cpaelzer__> thanks for the ping
[09:40] <cpaelzer__> and sorry
[09:47] <cpaelzer__> ok my pre upload checker now has a detection for this case
[09:47] <cpaelzer__> and since it was in proposed still I have uploaded a fixed ubuntu2
[09:47] <cpaelzer__> thanks again mwhudson
[10:20] <alkisg> Hi, a very recent update in 18.04 (maybe accountmanager or systemd) makes slick-greeter segfault, so MATE users get black screens. I'll start searching which update exactly caused it, but did anyone already report it?
[10:35] <seb128> it's annoying that python-apt blows up every cycle until it's updated to include the new codename :-/
[10:39] <Unit193> Too bad it can't steal from distro-info-data...
[10:51] <alkisg> The black screen (slick-greeter segfault) in 18.04 is caused by the systemd update
[10:51] <alkisg> "Bump the memlock limit"
[10:53] <alkisg> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830746
[10:55] <Laney> sounds similar to the lightdm-gtk-greeter thing seb128 was looking into
[10:58] <alkisg> I also found a related lightdm bug about memory limits causing segfaults there: https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/1662244
[10:59] <alkisg> I commented in https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830746/comments/16, let's see...
[10:59] <seb128> alkisg, what systemd update?
[10:59] <alkisg> seb128: see 1830746
[10:59] <alkisg> It was sent to 18.04 a couple of days ago
[11:00] <alkisg> It's enforcing some memory limits that lightdm doesn't like, causing the greeters to segfault
[11:00] <seb128> that bug is old
[11:00] <seb128> you mean https://launchpad.net/ubuntu/+source/systemd/245.4-4ubuntu3.3 ?
[11:00] <seb128> that is recent
[11:01] <alkisg> apt changelog systemd, in 18.04, shows 1830746
[11:01] <alkisg> It's systemd 237-3ubunt10.43
[11:01] <alkisg> Signed Wed, 07 Oct 2020
[11:01] <seb128> thx
[11:04] <seb128> bah, gnome-boxes isn't working for me anymore
[11:04] <seb128> libvirt-machine.vala:275: Failed to connection to system libvirt: Unable to open qemu+unix:///system: Failed to connect socket to '/var/run/libvirt/libvirt-sock-ro': No such file or directory
[11:04] <seb128> does that error ring a bell to anyone?
[11:11] <alkisg> Putting * soft memlock 262144 in /etc/security/limits.conf avoids the segfault. Should all lightdm users put that manually there, or should we expect an update?
[11:12] <seb128> alkisg, you should reach to ddstreet and the SRU team to get the systemd SRU blocked probably until that's sorted out
[11:12] <seb128> sil2100, ^
[11:12] <seb128> alkisg, is there a launchpad report for the slick-greeter issue yet?
[11:12] <cpaelzer> seb128: rings a few bells, let me check with you which it could be in your case
[11:13] <alkisg> seb128, a related lightdm report is this: https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/1662244
[11:13] <cpaelzer> seb128: does the socket not exist at all OR is it there and just something can't access
[11:13] <alkisg> It was characterized as "invalid" because the reported had manually played with memory limits, but it's the same problem; now they're enforced by systemd
[11:13] <alkisg> *the reporter
[11:14] <alkisg> I've cross-linked the two bug reports with appropriate comments
[11:14] <seb128> cpaelzer, /var/run/libvirt doesn't exists
[11:14] <seb128> alkisg, we would need a new report from the systemd regression I think
[11:15] <cpaelzer> seb128: service not started maybe?
[11:16] <cpaelzer> seb128: do you have pkg libvirt-daemon-system istalled?
[11:16] <cpaelzer> +n
[11:16] <seb128> cpaelzer, what packag... no, I don't
[11:16] <seb128> shouldn't that we pulled it through some depends?
[11:16] <cpaelzer> that is what brings the service files and anything else that you need to run, so get this installed
[11:17] <cpaelzer> seb128: yes if the dependencies of what you installed are correct :-)
[11:17] <seb128> it's weird, gnome-boxes was working until a week ago
[11:17] <seb128> and according to my dpkg.log* that didn't get uninstalled
[11:17] <seb128> like that was never installed
[11:17] <seb128> I wonder what changed :/
[11:18] <cpaelzer> seb128: there are three entry points to libvirt a) libvirt-daemon-system (what most packages should depend on) b) libvirt-clients (if you jsut want the CLI but server is remote) and c) libvirt-daemon (the binaries, but to drive it your own way)
[11:18] <alkisg> I tried 'sudo apport-bug /var/crash/_usr_sbin_slick-greeter.110.crash', and it displayed the initial apport dialog, but then nothing; what's the correct command to open a new launchpad bug while including the crash dump?
[11:18] <seb128> alkisg, that probably submit to errors.ubuntu.com
[11:19] <cpaelzer> seb128: I have a suspicion - they might have changed their dep to "libvirt-daemon-driver-qemu" which expresses that they want that particuar virtualization of the many it supports
[11:19] <seb128> cpaelzer, I think gnome-boxes might do c) ?
[11:19] <cpaelzer> but that does not bring in (a) but only (c) to allow non default .service solution
[11:20] <cpaelzer> seb128: they are indeed (c) and they were back to at least focal
[11:20] <cpaelzer> but if a solution goes (c) then it needs to take care itself to start the daemon somehow
[11:20] <cpaelzer> not sure what happened on that part
[11:21] <seb128> cpaelzer, should 'sudo libvirtd' work or is that naive and I need some arguments?
[11:21] <seb128> 2020-11-04 11:20:52.930+0000: 24979: error : virGetUserID:848 : invalid argument: Failed to parse user 'libvirt-qemu'
[11:21] <cpaelzer> there is more to do
[11:21] <cpaelzer> the default config needs some help to fit your case
[11:22] <seb128> well, I was just trying to figure out if the issue is that libvirtd errors out
[11:22] <cpaelzer> if it would be the service that we provide the systemctl status would show
[11:22] <cpaelzer> but in your case you need to find if/how gnome-boxe start their local version
[11:22] <seb128> cpaelzer, my journal has
[11:22] <seb128> nov. 04 12:20:18 sebxps libvirtd[24864]: Failed to open file '/sys/kernel/security/apparmor/profiles': Permission denied
[11:22] <seb128> nov. 04 12:20:18 sebxps libvirtd[24864]: Failed to read AppArmor profiles list '/sys/kernel/security/apparmor/profiles': Permission denied
[11:22] <cpaelzer> and start/debug that
[11:22] <cpaelzer> they probably start the daemon under the users permission
[11:23] <seb128> which match time where I tried to start gnome-boxes
[11:23] <cpaelzer> which can work, but you won't have appamor isolation (and many other things)
[11:23] <seb128> k, so probably not the error I'm looking for
[11:25] <seb128> cpaelzer, thanks for the help, I installed libvirt-daemon-system and that warning is gone but gnome-boxes still segfaults so I think it was maybe a redherring and I'm hitting a bug in boxes itself
[11:25] <seb128> I learnt a bit on the way though :)
[11:30] <cpaelzer> yw seb128
[11:45] <seb128> alkisg, you basically need https://github.com/linuxmint/slick-greeter/commit/f9af95ea3f.patch cherry picked, I'm also wondering if it means lightdm-gtk-greeter is going to hit the issue now on bionic & focal
[11:45] <seb128> ddstreet, ^ opinion since you did the systemd SRU?
[12:28] <ahasenack> sergiodj: congrats on becoming an Ubuntu Core Developer! :)
[12:41] <sil2100> seb128: thanks for the heads up
[12:44] <sil2100> alkisg: as per my comment on the bug, could you fill in a new bug for this and tag it 'regression-update'?
[12:45] <seb128> sil2100, it's bricking user systems, I would argue we should back that version out of updates back to proposed until that's sorted out
[12:54] <ricotz> what is the interval this site is expect to be updated? https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[12:54] <sil2100> seb128: I'll try to address this after my current meeting
[12:55] <sil2100> (since I'm having an interview)
[13:02] <alkisg> sil2100: sure, I'll do it this afternoon or tomorrow morning
[13:03] <alkisg> Thank you both
[13:14] <seb128> ricotz, those details have never been clear to me,I think when there is archive publisher cycle done which is probably every hour or so
[13:15] <seb128> ricotz, the recent updates have been failed on a an http error 500 from https://people.canonical.com/~ubuntu-archive/proposed-migration/log/groovy/2020-11-04/12:38:14.log
[13:15] <ricotz> seb128, I see, if that is the case, then something seems broken ;)
[13:15] <ricotz> ah ok
[13:16] <seb128> I mentied it on #ubuntu-release now
[13:17] <ricotz> thanks
[13:26] <alkisg> sil2100, seb128: I filed LP bug 1902879, thank you :)
[13:27] <seb128> alkisg, thanks
[14:46] <sergiodj> ahasenack: thanks :)
[15:10] <seb128> rbalint, bug 902832 claims to a regression from the recent bionic glibc SRU, could you have a look?
[15:14] <seb128> rbalint, sorry one digit missed when copying, bug #1902832
[15:18] <rbalint> seb128, thanks, will look into that soon
[15:19] <rbalint> sil2100, could you please stop phasing glibc until this is triaged?
[16:43] <max12345> Hi, newb question, There are bugs at https://bugs.launchpad.net/package and https://bugs.launchpad.net/ubuntu/+source/package and they're different, how is that?
[16:46] <cjwatson> max12345: The first of those represents an upstream project; the second represents a package in Ubuntu
[16:46] <ogra> the former are upstream projects (original developers, no dirsto packaging) ... the latter one is the ubuntu package in the distro
[16:46] <ogra> *distro
[16:46] <ogra> (also ... *snap* ... )
[16:47] <cjwatson> max12345: like, "the Linux kernel" (/linux) is not necessarily quite the same thing as "the Linux kernel in Ubuntu" (/ubuntu/+source/linux).  The kernel doesn't track its upstream bugs in Launchpad as it happens, but some projects do.
[16:49] <max12345> cjwatson: thanks you! that makes sense.
[19:20] <seb128> is there any documentation on how the Ubuntu ISO builds are done (components involved, how they are called, etc) or on how to locally set up and drive the process?
[19:20] <seb128> something which could be used to do local build testing e.g livecd-rootfs changes
[19:21] <seb128> xnox, mwhudson, sil2100, you might know? you have experience working on image builds, unsure how you usually test your changes?
[19:23] <mwhudson> seb128: it's definitely a pain
[19:24] <mwhudson> seb128: for subiquity i have a script that repacks the iso with a new subiquity snap
[19:24] <mwhudson> it could be adapted to be more generic
[19:24] <seb128> mwhudson, I don't want to repack an iso though, I want to fix/produce a new one for the desktop installer
[19:26] <mwhudson> seb128: are you talking about on your system or what steps have to be taken to start making a new image type on cdimage.ubuntu.com
[19:27] <mwhudson> on your system it really is easier to repack an ISO, for the new desktop installer i'd take a live server installer iso, replace the filesystem and installer squashfses and repack
[19:28] <mwhudson> making a new image type means changes to ubuntu-cdimage, and probably some scripts and config i don't have access to
[19:30] <seb128> mwhudson, we already have a new image 'canary' which was set up by didrocks and j_ible some cycles ago
[19:30] <seb128> mwhudson, I'm trying to understand how the image is built to be able to tweak it and also fix the build which was broken after changes in how kernels are handled from what I've been told
[19:31] <mwhudson> seb128: ok, so ubuntu-cdimage is the place to start
[19:31] <seb128> mwhudson, I'm not familiar with the process so would be nice to be able to test locally my changes to livecd-rootfs instead of submitting poke in the dark fixes
[19:31] <mwhudson> seb128: it has a concept of a "project" (or at least i think that's what it's called)
[19:32] <mwhudson> building a project means starting a livefs build per arch on launchpad, downloading the results, building a pool and using our fork of debian-cd-ubuntu to turn it into an ISO
[19:33] <mwhudson> seb128: livecd-rootfs changes i usually just test by doing a livefs build on launchpad and inspecting the artefacts, not putting them on an ISO
[19:33] <mwhudson> depends a bit what you are doing though
[19:34] <mwhudson> i have a script for starting a livefs build: https://paste.ubuntu.com/p/HmNk7y7xYY/
[19:35] <seb128> mwhudson, I was trying to start by driving livecd-rootfs by doing similar to what is described on https://chenhan1218.github.io/post/2016-07-06-763254/
[19:36] <mwhudson> seb128: oh right, running livecd-rootfs locally is another nest of vipers
[19:36] <mwhudson> the cpc team have some scripts for this iirc, i've never used them though
[19:37] <seb128> do you know who from cpc I could try to ping about that?
[19:37] <seb128> it's a bit annoying that it's undocumented
[19:37] <seb128> I wonder how many people had to refigure the details out by themself :/
[19:37] <mwhudson> rcj might still be around?
[19:38] <seb128> mwhudson, thanks for the help, I will keep poking!
[19:39] <mwhudson> seb128: the alternative is to read the launchpad-buildd source, figure out how it drives live-build and repeat that by hand
[19:39] <mwhudson> i've done this in the past but forget the details now
[19:40] <mwhudson> seb128: good luck
[19:40] <seb128> thx
[19:45] <rcj> seb128: You can use our tools that recreate the LP build env as faithfully in AWS or multipass as we can using https://github.com/chrisglass/ubuntu-old-fashioned
[19:45] <rcj> The 'bartender' script automates things further https://github.com/chrisglass/ubuntu-old-fashioned/blob/master/scripts/ubuntu-bartender/ubuntu-bartender
[19:45] <seb128> rcj, ah, great, thanks for the url, the description looks like what I want :)
[19:47] <rcj> seb128: and we've checked with cjwatson and wgrant in the past to ensure we're running the same commands from launchpad-buildd, etc to make this a decent development platform without the need to wait for livecd-rootfs ppa publication and let you drop into the lxd container when things go sideways.
[19:48] <seb128> rcj, that's exactly what I needed :)
[20:06] <tribaal> rcj: oh wow, that thing lives on :)
[20:07] <tribaal> (that URL highlighted :) )
[21:07] <rcj> tribaal: Hey man, how are you doing?
[21:07] <rcj> We keep patching it ;)
[21:09] <Odd_Bloke> It's becoming more and more old fashioned by the day.
[23:43] <xnox> mwhudson:  how can godefaults to 1.15 work in hirsute-proposed? are you gonna keep riscv64 on 1.14? I was hoping to skip 1.14 and go for 1.16 later...... however debian will be frozen at that point in time.
[23:44] <xnox> mwhudson:  do we need to upload golang-defaults that makes it 1.15 everywhere, and 1.14 on riscv64? i've tried to do cherrypicks of all the fixes from 1.16 to 1.15 even with jsing backport/patches and it failed to build for me =(
[23:44] <xnox> (on all arches)