[04:28] <jsing> @xnox you won't want to backport riscv64 cgo from 1.16 to 1.15 - https://github.com/4a6f656c/go/tree/riscv64-cgo-1.15 has diffs if you want them
[04:28] <udevbot> Error: "xnox" is not a valid command.
[04:38] <amurray> jamespage: thanks - if you could please update LP #1898547 with details regarding this test verification for neutron-linuxbridge-agent against iptables 1.8.5-3ubuntu3 in hirsute that would be great as I have done the SRU template stuff (if you could also review that that'd be awesome) so am waiting on autopkgtests to let it migrate into release in hirsute before subscribing ubuntu-sponsors for the groovy SRU
[06:24] <alkisg> Hi, I'm trying to locate the git source of "slick-greeter" in launchpad so that I propose a branch for LP #1902879
[06:24] <alkisg> For e.g. ipxe it's there: https://git.launchpad.net/ubuntu/+source/ipxe
[06:24] <alkisg> But a similar URL for slick-greeter doesn't exist... where can I find it?
[07:42] <cpaelzer> mvo: good morning, I anted to ping you on https://code.launchpad.net/~paelzer/apt-clone/apt-clone-fix-fails-early-cycle/+merge/393310 to learn if it makes sense to wait on you on that or if you feel "no more responsible"
[07:43] <cpaelzer> I don't mind either way, but wanted to avoid this hanging for to too long because I wait for something that won't happen
[07:43] <mvo> cpaelzer: sure, looking
[07:45] <mvo> cpaelzer: I take care of it
[07:52] <cpaelzer> thank you mvo
[11:21] <xnox> jsing:  i do want to do that. Last time I've used that tree, it ftbfs on all arches. Maybe I messed up, and I guess I should try again.
[11:24] <xnox> Laney:  i slightly feel to like just merge ubuntu/master into ubuntu/groovy => given everything that was done so far are SRU/bugfixes etc.
[11:25] <Laney> xnox: for what?
[11:25] <Laney> livecd-rootfs or?
[11:25] <xnox> oh, sorry, yes livecd-rootfs
[11:26] <xnox> it's vmdk image fixes, hyperv image fixes, bootloader cloud image fixes, riscv64 image fixes
[11:26] <xnox> i think i will do that, and write a nice changelog with all the bug references.
[11:27] <Laney> if you fancy writing up all those SRU bugs, be my guest
[11:27] <Laney> they all seem appropriate to me
[11:33] <Laney> xnox: did you notice that riscv64 server-preinstalled failed in cdimage
[11:33] <Laney> ?
[11:33] <Laney> also, that vorlo_n enabled that for focal and it's failing there too?
[11:35] <Laney> 2020-11-05 09:03:53 URL:https://launchpadlibrarian.net/505319619/livecd.ubuntu-cpc.disk1.img.xz [722747248/722747248] -> "/srv/cdimage.ubuntu.com/scratch/ubuntu-server/hirsute/daily-preinstalled/live/armhf+raspi.disk1.img.xz"
[11:35] <xnox> Laney:  yes, riscv64 server-preinstalled is speculative cron.
[11:35] <Laney> lol
[11:35] <Laney> I see a problem there
[11:36] <Laney> :D
[11:36] <xnox> Laney:  i don't think it works at all. and it's cronned to see what's failing and start fixing it up.
[11:36] <xnox> Laney:  i don't think we have chosen what bootloader to put on it yet.
[11:36] <Laney> right, this is 'start fixing it up'
[11:36] <Laney> things like don't try to call it armhf+raspi eh
[11:36] <xnox> that would be a start, yes =)
[11:37] <xnox> waveform:  Laney: after hyperv changes; have we built hirsute raspi desktop arm64 and does it still work fine? expectation is that i did decouple raspi & hyperv images correctly, but i'm raising that as a regression potential.
[11:37] <xnox> for the livecd-rootfs sru
[11:38] <Laney> I think I would have left focal out until devel is working, then turned that on and tried to start backporting stuff
[11:38] <Laney> um
[11:38] <Laney> I didn't try a daily, would be good to I guess
[12:00] <xnox> ta dah https://code.launchpad.net/~xnox/livecd-rootfs/+git/livecd-rootfs/+merge/393380
[12:02] <Laney> ah no misread, that's not what happened, we didn't even try to download riscv64 artifacts
[12:39] <seb128> sil2100, could we back out systemd back to proposed due to bug #1902879? I think the SRU isn't important enough to justify bricking systems, we should sort if out before moving back to updates. Settings the SRU % to 0 isn't helping much since that's enforced in update-manager only atm, users from apt still get the update
[12:39] <seb128> ddstreet, ^
[12:42] <Laney> cute, logind now outputs those nice linkified messages to the journal
[13:15] <kbr> Hiya. It's been a few years since I've done any ubuntu packaging work... There are a few rust packages in focal which could benefit from a rebuild with current cargo, as they have conflicting files right now. (LP: #1868517)
[13:15] <kbr> Does this qualify for a SRU?
[13:21] <jsing> xnox: it definitely works on riscv64, think I would have tested on amd64 as well.. but if you hit problems feel free to let me know
[13:47] <seb128> ddstreet, bug #1903036 claims to be a SRU regression from the recent systemd/focal SRU
[13:49] <seb128> rbalint, hey, is bug #1902832 on your list for this week. Should we maybe move the SRU out of updates back to proposed until the issue is figured out?
[13:50] <seb128> rbalint, there was another user reporting the issue and some details added to the bug since yesterday
[15:15] <rbalint> seb128, sil2100 I'm ok with moving glibc back to -proposed, while i believe this is not a standard procedure
[15:18] <seb128> rbalint, what do you mean by not standard? I think it's not uncommon to avoid getting more users hit by a regression, it's not a solution by itself though and doesn't mean we avoid doing the real fix then
[15:22] <rbalint> seb128, forget it, i'm ok with putting it back to proposed
[15:23] <seb128> rbalint, thanks
[15:26] <seb128> rbasak, hey, can I convince you to let the yaru-theme/focal SRU in? we need to get the shell one unblocked but that doesn't need to be blocked on that
[15:26] <seb128> rbalint, the yaru update is blocking some snap work to land that we would like to see available now
[15:43] <Laney> kbr: Sounds like it would qualify to me
[15:48] <mfo> vorlon, hey o/ looking for ubiquity & partman-crypto reviewers bug 1898129 and bug 1895351. should i request someone as reviewer in the merge requests, or just let Ubuntu Installer Team there, and wait a little more? (it's been 1-2 months, but that's understandable as we were previously in groovy's freezes.) thanks.
[15:49] <mfo> i just rebased/pushed them.
[15:53] <sil2100> rbalint: by 'glibc' you mean 'systemd', right?
[15:54] <ogra> did they merge that in as well now ?
[15:54] <ogra> 🙂
[15:59] <xnox> jsing:  cool.
[16:41] <seb128> sil2100, ^ any opinion on the glibc revert to proposed for bug #1902832? it's less of a major issue than the systemd one but I think we should either get someone to investigate actively the regression or revert
[16:44] <rbalint> seb128, sil2100 let me investigate it in the next hours
[16:58] <sil2100> seb128, rbalint: since this is a big update, I'd appreciate if rbalint could take a look at it and assess how bad it is and how hard it would be to fix
[16:58] <sil2100> Like with some revert etc.
[17:03] <kbr> I have a number of packages that are broken in focal due to a build-dep cargo having a bug. cargo was fixed in focal-security and focal-updates - do I restrict the build-dep to a fixed version or do I go with a no-change rebuild?
[17:50] <Laney> juliank: can I use apt patterns with dcmd to only install the packages I've already got installed? to get something close to dpkg -iO
[18:05] <juliank> Laney: I don't think so
[18:07] <juliank> Laney: Depending on what you're looking for you can just do apt install --only-upgrades <path to changes>; or apt --with-source <path to changes> install '?installed?archive(local-deb)'
[18:08] <juliank> the latter can downgrade I suppoe
[18:08] <juliank> ah no
[18:08] <juliank> that's
[18:08] <juliank> install '?installed?archive(local-deb)'/local-deb for downgrades
[18:08] <juliank> So summary answer: You can do what you want with apt directly, but not with dcmd I suppose
[18:09] <Laney> Yeah maybe the first one will work, thanks!
[18:09] <juliank> heh the latter one is closest to your request :D
[18:10] <juliank> the latter apt one that is :D
[18:10] <juliank> I use debi -u insted of apt install --only-upgrades for muscle memory reasons
[18:13] <Laney> oic, now I know what --with-source does
[18:15] <juliank> It's magic
[18:52] <ahasenack> hi, does anybody have a clue why apt remove ./*.deb ended up installing the deb? I know that removing a local deb filename makes no sense, but I wanted to see what would happen. And this was unexpected to me: https://pastebin.ubuntu.com/p/dkVq7mqvrd/
[19:09] <juliank> ahasenack: probably code path not flipping the default operation correctly
[19:09] <juliank> But kind of borderline ok behavior
[19:33] <seb128> sil2100, rbalint, thx
[19:35] <seb128> rbalint, any idea why it's happening only with the new glibc if it's a lftp bug?
[19:37] <rbalint> seb128, i'm looking into the changes, can't tell yet
[19:37] <seb128> k
[19:54] <rbalint> seb128, sil2100 The memory handling error can be observed with valgrind with the older libc6 package, too, it just does not crash lftp presumably due to a 'luckier' memory allocation layout.
[19:55] <seb128> k, good, so not a regression in glibc
[19:55] <seb128> rbalint, thanks for investigating!
[20:23] <mwhudson> xnox: oh argh
[20:25] <mwhudson> xnox: i guess either we stay on 1.14 everywhere or stay on 1.14 for riscv64 only
[20:25] <mwhudson> xnox: hopefully we'll have 1.16 by release...
[20:32] <bdmurray> xnox: https://pastebin.ubuntu.com/p/B57H44qKNY/
[22:54] <Sargun> Is there a plan to backport this to systemd 237 (18.04), so it'll work with the 5.8 HWE? https://github.com/systemd/systemd/pull/16420
[23:40] <amurray> jamespage: hey any chance you could look at doing the SRU verification for LP #1898547 - the iptables update is now in groovy-proposed and is waiting on someone to tag it verification-done-groovy so it can migrate