[04:43] <infinity> mwhudson: Example?
=== icey is now known as Guest40513
=== icey_ is now known as icey
[07:44] <infinity> stgraber:
[07:44] <infinity> + lxc launch ubuntu-daily:disco/amd64 docker -c security.nesting=true
[07:44] <infinity> Creating docker
[07:44] <infinity> Error: Failed container creation: The requested image couldn't be found
[07:44] <infinity> stgraber: ^-- Is that on us or you?
[08:25] <mwhudson> infinity: it seems to be fixed now
[08:25] <mwhudson> infinity: we don't have cloud images yet do we?
[08:29] <mwhudson> xnox: is that boost::python soname change going to turn up in debian at some point?
[08:30] <mwhudson> i don't know if i should be forwarding all the patches i've made because of it along
[08:41] <mwhudson> ok maybe i won't locally testbuild this package that took four hours to fail on launchpad
[08:47] <infinity> mwhudson: Local might be a lot faster, if you've not doing it in a VM.
[08:47] <infinity> mwhudson: l1tf has crippled our cloud.
[08:47] <mwhudson> infinity: i guess if the s390x build passes in my ppa i'll upload it :)
[08:48] <infinity> mwhudson: I'm still waiting on my s390x laptop in the mail.
[08:48] <mwhudson> infinity: did you buy a power9 machine in the end?
[08:48] <infinity> mwhudson: I don't have a p9, no.  doko bought one for home use, I believe.
[08:48] <mwhudson> you were looking into it though?
[08:49] <infinity> Not seriously.  My place is too small for server-class hardware.  Would be too loud, probably.
[08:49] <infinity> Unless they have a desktop part that can be cooled quietly now, I haven't looked.
[08:49] <mwhudson> ah ok
[08:50] <mwhudson> i wonder if i could put something in the half rack at my coworking space if i asked nicely...
[08:51] <infinity> Hrm, actually, https://raptorcs.com/TALOSIILITE/ might be something I could cool with a reasonably quiet solution.
[08:51] <infinity> Still a lot of money, though.
[08:53] <infinity> Like, an obnoxious amount of money.
[08:54] <infinity> Need POWER9 to become popular enough that the likes of MSI and ASUS make board and drive prices down.
[08:56] <ginggs> "now more affordable than ever"
[09:02] <doko> not yet arrived
[09:03] <doko> infinity: feeling bored and want to look at the vim ftbfs?
[09:04] <infinity> doko: There is no vim FTBFS.
[09:04] <infinity> doko: Or did you just upload a rebuild?
[09:05] <infinity> doko: So you did.  But also, there's no FTBFS. :P
[09:05] <infinity> doko: It would have been nice if you'd let the previous one migrate first, though.
[09:08] <doko> no-change uploads ...
[09:09] <doko> apparently succeeded with a give-back. now docker.io autopkg test failures
[09:10] <infinity> Yeah, that's known.
[09:10] <infinity> I'll bump my hint to ignore that for now.
[09:11] <infinity> Also going to resurrent the old vim after checking an old excuses to make sure it also only had the docker regression.
[09:42] <doko> rbasak: updated the anki issue
[10:00] <infinity> + SNAPPY_STORE_NO_CDN=1 snap download --channel=stable/ubuntu-19.04 gnome-3-26-1604
[10:00] <infinity> error: cannot download snap "gnome-3-26-1604": no snap revision available as specified
[10:00] <infinity> Laney: ^-- Who's in charge of making sure that's a thing?
[10:00] <infinity> willcooke: ^
[10:01] <Laney> I dunno, probably kenvandine
[10:01] <infinity> kenvandine: ^
[10:01] <Laney> I guess that could be in NRCP, and/or something that the release team can do - should be scriptable I'd have thought
[10:02] <Laney> unless it involves clicking on a web sight
[10:02] <infinity> Probably scriptable.  Permissions could be an issue.
[10:02] <infinity> But should likely be there as a "bug so-and-so" task at least.
[10:03] <infinity> I assume I'll have the same issue with lxd's snap when I try a server build.
[10:03] <Laney> That becomes annoying across multiple flavours
[10:03] <infinity> mwhudson: Oh, will I also have issues with the subiquity snap?
[10:04]  * infinity asked, after queueing up a build. :P
[10:05] <willcooke> yeah ken I think
[10:05] <willcooke> you're up early infinity
[10:05] <mwhudson> infinity: don't think so
[10:05] <mwhudson> willcooke: i need to reply to your mail
[10:05] <willcooke> thx mwhudson
[10:05] <infinity> willcooke: Did you just assume my timezone?
[10:06] <infinity> mwhudson: Does subiquity not pull from a per-release channel like the other things do, or have you already published something to 19.04?
[10:06] <willcooke> infinity, I'm hearing that you don't like me asking about your timezone, and I will be mindful of the impact of my assumptions in the future
[10:07] <infinity> willcooke: That sensitivity training is really paying off.
[10:07] <willcooke> :D
[10:07] <mwhudson> infinity: i don't think it pulls from the per-release channel
[10:08] <mwhudson> infinity: i guess you'll find out!
[10:08] <infinity> mwhudson: Oh, you just use snap download.  How... Novel.
[10:08] <infinity> (with no qualifiers)
[10:08] <mwhudson> i am to innovate
[10:08] <mwhudson> *aim
[10:10] <Laney> I thought that was required by Steve's policy
[10:10] <infinity> It is.
[10:10] <infinity> But subiquity predates that policy by a lot.
[10:11] <infinity> It's also a unique snowflake in that it's on *images*, but not the installed system.
[10:12] <infinity> Anyhow, we should definitely sort out how to scrape a list of all snaps that are included in default installs of all flavours, how to script publishing them to ubuntu-XX.XX, and for bonus points, how to get some release people permissions to do that.
[10:12] <infinity> Cause running another command or 7 during opening is fine, blocking ISO builds on poking more people sucks.
[10:16] <Laney> for snap in $(awk '/seed/ { print $1 }' ~ubuntu-archive/public_html/germinate-output/*.disco/all.snaps); do mangle_the_snap ${snap}; done
[10:20] <Laney> This becomes more interesting if there's ever an upstream published snap in there
[10:20] <infinity> I thought the magic policy didn't allow that.
[10:20] <infinity> Or maybe I misread that bit.
[10:21] <Laney> "a snap should have as its publisher either the upstream, or the Ubuntu developer community"
[10:21] <infinity> Ahh, well then.
[10:22] <infinity> Fun indeed if we have to manage channels, or hamstring our own process while we beg them to.
[10:25] <rbasak> doko: thanks!
[10:36] <infinity> Wimpress: I assume you're going to have similar snap issues in MATE, unless you've already taken care of it.
[10:37] <infinity> Wimpress: (See above, re things needing to be published to the right ubuntu-19.04 channel)
[10:48] <alkisg> Hi, this allows one to install ubuntu 32bit in uefi mode: (1) boot 64bit live cd under uefi, (2) at the grub menu, remove the 64bit cd and insert the 32bit cd, (3) continue booting.
[10:48] <alkisg> My question is, how hard would it be to have grub-efi-amd64 in the 32bit live CDs, so that they boot under uefi directly?
[10:49] <infinity> alkisg: There are no 32-bit CDs anymore.
[10:50] <alkisg> infinity: for all flavors? 18.04 is the last one that ships them?
[10:50] <infinity> alkisg: For most.
[10:50]  * alkisg is using ubuntu mate
[10:51] <infinity> alkisg: MATE 18.10 was amd64-only.
[10:51] <alkisg> But Ubuntu MATE 18.04.5 will still ship for 32bit, right?
[10:51] <infinity> Yes.
[10:51] <alkisg> It'd be nice to have it bootable under uefi...
[10:51] <infinity> But we're not likely to make changes like that in a point release.
[10:51] <alkisg> Gotcha
[10:52] <alkisg> Thank you
[10:52] <infinity> We also don't want to encourage people to install i386, especially on amd64 hardware.
[10:52] <infinity> As we're evaluating removing it entirely.
[10:52] <alkisg> In some cases it's still necessary unfortunately
[10:52] <alkisg> I.e. when the 64bit machine is a template for netbooting 32bit machines (ltsp)
[10:53] <infinity> Long Mode has been around as long as Ubuntu itself has.
[10:53] <infinity> Netbooting 14 year old machines is noble, but eventually, we're going to drop support for them.
[10:54] <alkisg> Sure, it's understandable, but until schools get 64bit hardware we'll just have to make do
[10:54] <infinity> We've already dropped support for most 32-bit x86 just by virtue of changing our baseline to i686 w/ PAE.
[10:54] <alkisg> We still have like 10000 of them still running ubuntu mate 18.04 32 bit
[10:54] <infinity> The gap between i686+PAE and i686+LM is only a few years of usable hardware.
[10:54] <alkisg> Few years = 10000 pcs, unfortunately :)
[10:54] <alkisg> Pentium 4's, mostly
[10:54] <infinity> Sure, it sucks to have hardware from that era that you want supported forever, but forever just isn't realistic is all I'm saying. :/
[10:55] <alkisg> Understandable; I'm not asking for any policy changes
[10:55] <infinity> And P4s are costing you more in power than you know.  You should maybe look into pushing for replacements on that basis.
[10:55] <alkisg> We'll make do with what you guys offer
[10:55] <infinity> The P4 eats power like mad.
[10:56] <alkisg> Unfortunately the organizations that maintain the schools hardware don't really understand power economics
[10:56] <infinity> :(
[10:56] <infinity> Unfortunate indeed.
[10:57] <alkisg> Some times the money for those 2 (computers vs electricity) even come from different ministries
[10:57] <infinity> Cause running a P4 for over a decade probably wasted enough power to replace the machine twice over with a low power all-in-one AMD or Intel laptop-cpu-in-a-desktop-formfactor type thing.
[10:57] <alkisg> So it's extremely hard to convince a ministry to pay money so that it saves more money from the other ministry
[10:59] <infinity> I hear you.  There's nothing worse than budget politics.  In either government or corporations.
[10:59] <infinity> Trying to get A to pay B's bills is right up there with insanity like "use all your budget or we won't give you any next year" and similar things that make NO SENSE to people just trying to be cost-effective.
[11:00] <alkisg> Exactly... actually the main reason we managed to get ubuntu to so many PCs was because they didn't bother to support their hardware/software, so ubuntu/ltsp was the only thing that worked there :)
[11:01] <alkisg> The good thing was that even when some schools bought newer computers, they opted again for ubuntu/ltsp
[11:04] <infinity> alkisg: Anyhow, I make no guarantees that we're dropping i386 right away, but it's going to happen "soon", so you've either got 4 years (6 with ESM) of support left for 18.04 or, if you're really lucky, 6 (8 w/ ESM) for 20.04.
[11:05] <infinity> alkisg: Knowing that, it's best you start talking to people about hardware replacements sooner rather than later, given how slowly governments move when you start talking about money. :P
[11:05]  * alkisg hopes that's more than enough
[11:10] <alkisg> Ouch, ubiquity tried to install grub-efi-amd64-signed, which isn't available for i386, instead of grub-efi-amd64. Oh well.
[11:20] <alkisg> Oh it checks /sys/firmware/efi/fw_platform_size instead of `dpkg --print-architecture`... I'll sed it :)
[11:25] <cjwatson> It has to check the firmware arch, because the bitness of grub-efi-* has to match the bitness of the firmware, not the bitness of userspace.
[11:25] <alkisg> cjwatson: it's amd64 in both cases; the difference is in 'signed' vs not
[11:26] <alkisg> And -signed doesn't exist in i386 installations at all
[11:26] <cjwatson> Right, but dpkg --print-architecture would absolutely be wrong.
[11:26] <cjwatson> Unless you're doing that just for the purpose of dropping the -signed part.
[11:26] <cjwatson> Still needs to check the fw bitness because grub-efi-ia32 is a thing too.
[11:27] <cjwatson> (albeit a pretty undermaintained thing)
[11:27] <infinity> Now, a fair argument could be made that amd64-signed should exist on i386 too.
[11:27] <infinity> But that ship has sailed for bionic.
[11:28] <infinity> Although, we also don't sign i386 kernels, so meh.
[11:30]  * alkisg just removed the -signed part there and waits to see if ubiquity will now succeed...  i.e. sudo sed 's/-signed"/"/' -i /user/share/grub-installer/grub-installer
[11:34] <alkisg> Meh. Got past that part, failed a bit later, "EFI variables are not supported on this system". Probably not worth the trouble. :)
[11:35] <infinity> mwhudson: Hrm, your server-live filesystem build broke in a spectacular way. :P
[11:36] <infinity> + chroot binary/boot/squashfs.dir apt-get update
[11:36] <infinity> chroot: failed to run command 'apt-get': No such file or directory
[11:36] <infinity> Well done.
[12:16] <alkisg> So, CONFIG_EFI_MIXED isn't enabled on 32bits, and it's causing efivars to be disabled... http://lkml.iu.edu/hypermail/linux/kernel/1403.0/01370.html
[12:18] <xnox> ew
[12:37] <doko> cpaelzer: postgresql-10 shows some triggered autopkg test failures in disco
[12:52] <infinity> doko, cpaelzer: postgresql-common needs to recognize 19.04... Uploading just that fix for now to unblock the world, but we probably also want to transition to psql-11 later in the cycle to match buster.
[13:09] <kenvandine> infinity: i'll get that track opened for all the seeded snaps
[13:09] <infinity> kenvandine: All, all, or all the Ubuntu ones?
[13:10] <infinity> kenvandine: (MATE and Budgie have some too, unsure if you have permissions there)
[13:10] <kenvandine> all the ones we seed for desktop
[13:10] <kenvandine> i shouldn't have permissions for those
[13:10] <infinity> Kay.
[13:21] <kenvandine> infinity: done
[13:21] <kenvandine> infinity: i created stable/ubuntu-19.04 tracks for gnome-3-26-1604 gtk-common-themes gnome-logs gnome-calculator gnome-characters gnome-system-monitor
[13:47] <infinity> kenvandine: Ta.
[13:55] <stgraber> infinity: ubuntu-daily:disco is the Ubuntu cloud image in the daily stream, so that's on foundations
[13:55] <infinity> stgraber: Kay.
[13:56] <infinity> stgraber: Also, do you need to make a stable/ubuntu-19.04 track for lxd for image buildy purposes?
[13:56] <infinity> stgraber: (If you already have, ignore me, I haven't checked)
[13:56] <stgraber> infinity: done already, juliank/rcj went to complain about that yesterday :)
[13:56] <infinity> stgraber: Kay. :)
[13:56] <infinity> How do I even check that?
[13:57] <infinity> 'snap info lxd' is amazingly verbose, but doesn't seem to show me THAT bit of info.
[13:58] <rcj> infinity: the only way I can tell is by running `snap download --channel stable/ubuntu-19.04 lxd` successfully.
[13:58] <stgraber> infinity: other than through snap refresh, no idea, it doesn't even show up on rev list or anything on my side because it's an open+closed channel
[13:58] <rcj> If you aren't the publisher of the snap I don't think we can see it
[13:58] <stgraber> ah yeah, download would work
[13:59] <stgraber> rcj: even as the publisher, once it's closed, it's not particularly visible :)
[13:59] <rcj> interesting
[14:55] <infinity> kenvandine: Huzzah, ubuntu-desktop ISOs built after you fixed that. Thanks!
[14:55] <kenvandine> infinity: great, no problem
[15:09] <coreycb> sil2100: hi o/ we have 3 (small) uploads in the cosmic unapproved queue that are urgent for openstack. any chance you could take a look?
[15:24] <cpaelzer> infinity: doko: ahasenack: yes we want pg-11 eventually and 19.04 must be known
[15:24] <cpaelzer> ahasenack: since I'm away until monday would you check if we can help infinity atm?
[15:25] <ahasenack> someone said he was fixing it, no?
[15:25]  * ahasenack checks history
[15:26] <ahasenack> infinity: do you still need something right now for postgresql-common?
[15:26] <infinity> ahasenack: No, I did it.
[15:27] <ahasenack> ok
[16:28] <vorlon> rbasak: udisks2 (sorry, was off yesterday) - looks to me like someone should've bumped the hint when publishing 2.7.6-3ubuntu0.2...
[16:53] <rbasak> vorlon: the thing is I had only gone as far as determining that the failures weren't caused by an SRU being proposed. To add or bump a force-badtest I have to additionally investigate the rdeps failures themselves, and that's a much more significant effort. It didn't seem appropriate to block releasing an SRU on that.
[16:53] <rbasak> vorlon: based on the history it looks like something changed causing the test to start failing.
[16:54] <rbasak> So a force-badtest might not be appropriate. The positive result might be valid for all I know.
[16:59] <vorlon> rbasak: the tests were already failing with 0.1 because of a regression outside of the udisks2 package, and a badtest hint was added for it.  Then 0.2 was SRUed, and the tests were still failing, and it was released without the hint being updated
[16:59] <vorlon> if it was good enough to ignore the test failures for the previous revision of udisks2 and to allow this SRU to be released with these failures, it's good enough to ignore them for revdeps also
[17:02] <rbasak> vorlon: looks like you've looked deeper than I did yesterday, thanks. I think I'm raising more of a process point though - it seems burdensome to add force-badtests to get the excuses clear before releasing an SRU. Perhaps this should be wider than the SRU team to get things through quicker - uploaders could do the investigation. Otherwise it seems that I make very little progress during an SRU shift.
[17:07] <vorlon> rbasak: the only reason it's burdensome here is because someone /previously/ released a udisks2 SRU without updating the hint.  In this case it turns out that was a security update, which is a separate problem (we mean to be running autopkgtests for the security proposed ppa but this isn't implemented yet).  But if the system is working well, at the time a member of the team decides that an
[17:07] <vorlon> autopkgtest failure is ignorable, that gets documented with a badtest hint, so that later SRUs don't get slowed down by it
[17:07] <vorlon> rbasak: also in this case I knew udisks2 was a problematic package, so I grepped the existing hints file to find the previous hint that hadn't been updated
[17:47] <coreycb> tjaalton: vorlon: I think sil2100 may be out so figured i'd ask the friday folks. we have 3 (small) uploads in the cosmic unapproved queue that are urgent for openstack. any chance you could take a look? we also would like to get bug 1778771 released to bionic-updates if possible before friday.
[17:47] <ubottu> bug 1778771 in horizon (Ubuntu Bionic) "Backups panel is visible even if enable_backup is False" [High,Fix committed] https://launchpad.net/bugs/1778771
[17:52] <vorlon> coreycb: which are the urgent ones in cosmic unapproved?
[17:54] <coreycb> vorlon: that would be useful :) cinder, barbican and aodh
[17:56] <vorlon> coreycb: test case on LP: #1799406 is unclear, can you please flesh that out?
[17:56] <ubottu> Launchpad bug 1799406 in Aodh "Alarms fail on Rocky" [Undecided,In progress] https://launchpad.net/bugs/1799406
[18:01] <coreycb> vorlon: ok that's all set now
[18:03] <dosaboy> vorlon: hey, if i may ... bionic sru in lp 1778771 has been verified and baking for > 7 days any chance we can get it out/
[18:03] <ubottu> Launchpad bug 1778771 in Ubuntu Cloud Archive queens "Backups panel is visible even if enable_backup is False" [High,Fix committed] https://launchpad.net/bugs/1778771
[18:04] <vorlon> dosaboy: dude I released that a whole 9 minutes ago
[18:04] <dosaboy> vorlon: whoooooah
[18:04] <vorlon> ;)
[18:04] <dosaboy> thanks!
[19:40] <vorlon> coreycb: LP: #1798917 also lacks a test case
[19:40] <ubottu> Launchpad bug 1798917 in cinder (Ubuntu) "[SRU] Cinder backup of a volume is in error state with fail_reason: data must be bytes" [High,Triaged] https://launchpad.net/bugs/1798917
[19:41] <coreycb> vorlon: it has one it's just short
[19:42] <vorlon> oh :)
[19:42] <vorlon> ok
[20:20] <mwhudson> infinity: whaat
[20:28] <mwhudson> infinity: ok i have no idea why that broke
=== HeadlessHorseman is now known as Unit193
=== led_dark_2 is now known as led_dark_1