=== funkyHat1 is now known as funkyHat
=== JanC is now known as Guest89378
=== JanC_ is now known as JanC
[05:05] <cpaelzer> good morning
[05:50] <pitti> Good morning
[06:11] <pitti> cyphermox: hey!
[06:12] <pitti> cyphermox: can you please follow up on bug 1536008  and bug 1473903? these belong to trusty's parted update, but the tasks of the latter are completely off and psusi said that it's wrong, and the former is v-failed; as it stands, I'd just remove this SRU
[06:13] <ubottu> bug 1536008 in parted (Ubuntu Trusty) "ISST-LTE: parted command shows "device-mapper: table ioctl on failed: No such device or address" error" [High,Fix committed] https://launchpad.net/bugs/1536008
[06:13] <ubottu> bug 1473903 in multipath-tools (Ubuntu Trusty) "parted will generate two devices when adding one partition on mpath device" [High,Triaged] https://launchpad.net/bugs/1473903
[07:37] <flexiondotorg> pitti, If you have a moment I need some advice regarding my SRUs.
[07:38] <pitti> flexiondotorg: Guten Morgen; what's up?
[07:38] <flexiondotorg> Morning.
[07:38] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1574789
[07:38] <ubottu> Launchpad bug 1574789 in ubuntu-mate-settings (Ubuntu Xenial) "SRU: xorg.conf.d/90-zap.conf destroys xorg keyboard settings" [High,In progress]
[07:39] <flexiondotorg> That issue has been fixed in Yakkety.
[07:39] <pitti> > +rm_conffile /usr/share/X11/xorg.conf.d/90-zap.conf 16.04.5
[07:39] <flexiondotorg> But clearly I've not done something correctly to indicate that.
[07:39] <pitti> was this removed in yakkety?
[07:39] <flexiondotorg> Yes.
[07:39] <pitti> as that's what caused the regression and reopened the bug
[07:39] <pitti> ok, then  please say so and close the floating task
[07:40] <pitti> so this just needs a follow-up upload to xenial then with the updated patch?
[07:41] <flexiondotorg> So this is a term I need to understand the meaning of.
[07:41] <flexiondotorg> What is a "task"?
[07:41] <pitti> every line with a triangle in the table on the top
[07:42] <flexiondotorg> And I did upload again, a couple of days ago, to Xenial.
[07:42] <pitti> this bug has three tasks: "ubuntu-mate" upstream, u-m-s for "ubuntu" (called "floating" task as it usually applies to the current devel series, not to a particular series), and one task for "ubuntu xenial"
[07:42] <pitti> this currently says that it's in progress in both the devel series and xenial
[07:46] <flexiondotorg> Thanks for the explanation. I've marked the devel series task as Fix Released.
[07:49] <flexiondotorg> pitti, So can you "see" the ubuntu-mate-settings 16.04.5.3 for Xenial?
[07:50] <pitti> flexiondotorg: it's in https://launchpad.net/ubuntu/xenial/+queue?queue_state=1 , I suppose you mean that?
[07:50] <pitti> flexiondotorg: btw, please don't close/reopen tasks without a comment
[07:51] <flexiondotorg> OK, I'll add an appropriate comment.
[07:53] <pitti> flexiondotorg: thanks; I accepted the xenial update
[07:55] <flexiondotorg> pitti, Thanks for the help.
[07:55] <flexiondotorg> I have a similar issue with the SRU
[07:55] <flexiondotorg> https://bugs.launchpad.net/ubuntu-mate/+bug/1581168
[07:55] <ubottu> Launchpad bug 1581168 in ubuntu-mate-artwork (Ubuntu) "SRU: GTK3 scrollbars in Radiant-MATE not styled like GTK2" [Undecided,New]
[07:56] <flexiondotorg> That is also fixed in Yakkety already.
[07:58] <pitti> flexiondotorg: I added a xenial task; please close it for y then
[07:58] <flexiondotorg> pitti, Thanks. I wasn;t able to add the Xenial task. Is that intended?
[07:59] <pitti> flexiondotorg: you should be able to as a developer; bdmurray manages these
[07:59] <pitti> flexiondotorg: on https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1581168, do you see a "Nominate for series"?
[07:59] <ubottu> Launchpad bug 1581168 in ubuntu-mate-artwork (Ubuntu Xenial) "SRU: GTK3 scrollbars in Radiant-MATE not styled like GTK2" [Undecided,New]
[07:59] <pitti> that's the one
[07:59] <flexiondotorg> There was no option to target Xenial.
[07:59] <pitti> you can click it, you should then get some check boxes for trusty etc. (not for xenial any more as I just did that)
[08:03] <flexiondotorg> I've added a comment and marked as Fex Released for the dev task.
[08:04] <pitti> thanks
[08:07] <flexiondotorg> pitti, When I try to select a target the only tick box I see is Trunk
[08:07] <flexiondotorg> And, thank you for helping out pitti. Very much appreciated.
[08:07] <pitti> flexiondotorg: oh, then you have the upstream task selected, not the ubuntu task
[08:07] <pitti> that's a bit icky indeed, there's no way to select it with clicking
[08:08] <pitti> flexiondotorg: try on https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1581168,
[08:08] <ubottu> Launchpad bug 1581168 in ubuntu-mate-artwork (Ubuntu Xenial) "SRU: GTK3 scrollbars in Radiant-MATE not styled like GTK2" [Undecided,New]
[08:08] <flexiondotorg> Ahhh, penny drop :-)
[08:08] <flexiondotorg> Right, understood.
[08:08] <pitti> i. e. you have to get to the page via the "ubuntu" bug list, not the upstream bug list
[08:16] <flexiondotorg> pitti, So can you see ubuntu-mate-artwork (16.04.6.2)?
[08:16] <flexiondotorg> Is there anything more I need to do to progress that SRU?
[08:17] <pitti> flexiondotorg: no, not in https://launchpad.net/ubuntu/xenial/+queue?queue_state=1
[08:17] <flexiondotorg> Hmm, well I did upload it weeks ago.
[08:18] <pitti> flexiondotorg: did you get a REJECT email?
[08:18] <pitti> https://launchpad.net/ubuntu/xenial/+queue?queue_state=4&queue_text=mate
[08:18] <pitti> not there eitehr
[08:19] <flexiondotorg> I don't recall a rejection. I'll double check. I have the .upload file here:
[08:19] <flexiondotorg> Successfully uploaded ubuntu-mate-artwork_16.04.6.2.dsc to upload.ubuntu.com for ubuntu.
[08:19] <flexiondotorg> Successfully uploaded ubuntu-mate-artwork_16.04.6.2.tar.xz to upload.ubuntu.com for ubuntu.
[08:19] <flexiondotorg> Successfully uploaded ubuntu-mate-artwork_16.04.6.2_source.changes to upload.ubuntu.com for ubuntu.
[08:20] <flexiondotorg> OK, it was rejected on June 29th.
[08:21] <flexiondotorg> pitti, So should I re-upload 16.04.6.2 or bump the version to 16.04.6.3 and upload?
[08:22] <flexiondotorg> I'm assuming a rejection means 16.04.6.2 is not referenced in the archive anywhere and the same version can be re-uploaded?
[08:22] <pitti> flexiondotorg: reupload .2 please
[08:22] <flexiondotorg> OK
[08:23] <pitti> flexiondotorg: https://launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+publishinghistory
[08:23] <pitti> flexiondotorg: it was never accepted indeed
[08:23] <pitti> flexiondotorg: well, maybe call it 16.04.7 to have a slightly saner version number :)
[08:24] <flexiondotorg> pitti, I've been getting conflicting feedback on the versions :-)
[08:24] <flexiondotorg> I've re-uploaded 16.04.6.2
[08:24] <flexiondotorg> But I much prefer a saner version.
[08:25] <flexiondotorg> If another SRU is required I use .7
[08:25] <pitti> flexiondotorg: so reupload it as 16.04.7 and I'll reject the .6.2?
[08:25] <flexiondotorg> pitti, Wilco
[08:29] <flexiondotorg> pitti, Done.
[09:19] <cjwatson> Odd_Bloke: Did you notice infinity's comment to the effect that your arm64 image boot log looked more like a powerpc image?
[09:21] <Odd_Bloke> cjwatson: I did, yeah; AIUI, we should register images with metadata {"architecture": "aarch64"} and OpenStack should work out that when we attempt to launch that image, we want arm64.
[09:21] <Odd_Bloke> cjwatson: Which we are doing, so either my understanding is incorrect, or something strange is happening in bos01.
[09:22] <cjwatson> Odd_Bloke: I wouldn't rule out the latter, although historically there's been some confusion between "arm64" and "aarch64" names too I think
[09:23] <cjwatson> vbuilder-g-s-s-production-arm64 appears to set {'architecture': 'aarch64', 'hypervisor_type': 'kvm'}
[09:23] <Odd_Bloke> OK, I'll try adding hypervisor_type.
[09:24] <cjwatson> Oh, and I said "a powerpc image" above but I guess I actually mean a powerpc guest.
[09:24] <cjwatson> Or ppc64el.
[09:24] <cjwatson> Odd_Bloke: Could be a red herring as it sets that for all arches.
[09:25] <infinity> Indeed, hard to say what the image was, but it was clearly a ppc64 guest.
[09:25] <infinity> (powerpc or ppc64el is meaningless before the kernel boots)
[09:26] <cjwatson> Odd_Bloke: https://jenkins.canonical.com/xenial-cloud-images/job/16.04-Perform-Pre-Publish-Testing/ARCH=arm64,TEST=basic-ubuntu/1/artifact/debug.log/*view*/ does seem to show a whole lot more metadata for other arches.
[09:26] <cjwatson> Well, amd64 anyway.
[09:26] <cjwatson> Ah, wait, those are buildd images I'm looking at.
[09:26]  * cjwatson shoves through jq in the hope of being able to read it
[09:42] <cjwatson> Odd_Bloke: Launching on floette though, which is definitely ppc64el.
[09:43] <Odd_Bloke> cjwatson: The latest one _looks_ like it was put on swirlix03, with that hypervisor_type change.
[09:43] <Odd_Bloke> And, yes, https://jenkins.canonical.com/xenial-cloud-images/job/16.04-Perform-Pre-Publish-Testing/ARCH=arm64,TEST=basic-ubuntu/4/artifact/debug/cloud-info/console-log/*view*/ looks more like it.
[09:44] <Odd_Bloke> But I've just realised that we're attempting to launch the disk1 image here, not the uefi1 image.
[09:44] <Odd_Bloke> So I'll go and address that next.
[09:45] <cjwatson> Definitely an improvement.
[09:57] <Odd_Bloke> It's booted and our tests have SSH'd in and everything. \o/
[09:57] <infinity> \o/
[10:03] <cjwatson> Oh, nice one.  That dnsdomainname test failure isn't particularly scary for this purpose I guess?
[10:05] <cjwatson> Odd_Bloke: And sounds to me like I can reasonably tag the live-build bug v-done?
[10:05] <Odd_Bloke> cjwatson: Yep, that's not a scary failure; looks like it's v-done to me. :)
[10:06] <cjwatson> Done.
[10:32] <Odd_Bloke> cjwatson: We're seeing https://bugs.launchpad.net/cloud-images/+bug/1598136 which would probably be fixed by building on a buildd with a post-trusty kernel; how close are we to having powerpc and armhf building on post-trusty buildds?  (I'm guessing that we'd already have it for armhf if we were require_virtualized=True?)
[10:32] <ubottu> Launchpad bug 1598136 in cloud-images "Fails to produce a loop-mountable FS on powerpc/armhf" [Critical,In progress]
[10:36] <cjwatson> Odd_Bloke: armhf is already on wily for virt, indeed.  The blocker for devirt was the xenial bug we just sorted out, followed by getting IS to switch scalingstack over to that, a bit of testing, and flipping the switch.  Probably not too far now.
[10:36] <cjwatson> Odd_Bloke: powerpc is somewhat more work; it needs bos02 scalingstack to be deployed first.
[10:37] <cjwatson> Odd_Bloke: infinity possibly could upgrade powerpc to xenial in advance of that.  I don't know what he thinks of that.
[10:37] <infinity> deneed* and fisher* are running ltx-xenial kernels.
[10:37] <infinity> lts-xenial, even.
[10:38] <cjwatson> Also, amd64/i386 are on trusty at the moment, not xenial.
[10:38] <cjwatson> Not even lts-xenial, I think.
[10:38] <Odd_Bloke> infinity: So it's just sagari that isn't?
[10:39] <infinity> Odd_Bloke: Indeed, sagari is stuck in the past.
[10:39] <infinity> Distant past, at that.
[10:39] <infinity> precise, I think.
[10:40] <cjwatson> So yeah, notwithstanding what the error message says I think it's actually the precise kernel case that's the problem.
[10:40] <cjwatson> kishi* are on precise, 3.2.
[10:40] <Odd_Bloke> Yeah, I wouldn't be surprised if the trusty kernel was new enough to solve it.
[10:40] <Odd_Bloke> (Especially given that it works on amd64/i386 :p)
[10:40] <cjwatson> I'll comment on the bug.
[10:41] <infinity> kishi could be upgraded to lts-trusty, I suspect.  I could steal one from the console and test, or ask a WeBop to proxy and play with me.
[10:41] <infinity> And sagari should also be able to do the same now.
[10:41] <infinity> The reason it was kept on precise is no longer valid.
[10:41] <cjwatson> I'd really rather not mess with kishi.
[10:41] <infinity> cjwatson: Well, I was just suggesting kernel upgrades, not full userspace.  But meh.
[10:41] <cjwatson> But as for sagari, go nuts.
[10:42] <infinity> I'd have done sagari months ago, if I had access to it.
[10:54] <Odd_Bloke> cjwatson: infinity: This is currently blocking any new yakkety dailies; do you expect we'll be unblocked in the next couple of days, or should we get a workaround in place that we can remove once we are unblocked?
[10:55] <cjwatson> Odd_Bloke: A workaround seems sensible.
[10:57] <mwhudson> i have a package in xenial-proposed that's failed verification
[10:57] <mwhudson> uh i guess i want to upload a new one that has a higher version number anyway, so never mind
=== hikiko is now known as hikiko|bbi
=== hikiko|bbi is now known as hikiko|bbl
=== _salem is now known as salem_
[12:30] <semiosis> Odd_Bloke: working on your feedback.  if the test goes well i should push the changes in a few minutes.
[12:30] <semiosis> Odd_Bloke: do you know why the config management packages were removed?  where can I read up on that decision?
[12:33] <Odd_Bloke> semiosis: Pretty much all of the changes were because Vagrant moved from being built as a special snowflake to just the base cloud image wrapped up in a Vagrant box.
[12:33] <Odd_Bloke> semiosis: So "decision" is generous. ;)
[12:35] <semiosis> Odd_Bloke: well it's unfortunate for the users that care was not taken to preserve the expected functionality of a vagrant base box, like synced folders and config management packages working out of the box.  i want to get the config management stuff added back without delay.
[12:38] <Odd_Bloke> semiosis: I'm not convinced that we should be shipping all of the config management stuff, but I am convinced that we should get synced folders and hostnames working.
[12:38] <Odd_Bloke> semiosis: Which is why I want to split those two conversations up.
[12:39] <Odd_Bloke> semiosis: (I'm not saying I _couldn't_ be convinced, but I don't want to block behaviour that _is_ fundamental to Vagrant functioning for everyone because we're discussing behaviour that isn't fundamental)
[12:41] <semiosis> Odd_Bloke: i dont mean to be argumentative, but it seems like you should have to justify removing stuff that has been in ubuntu's vagrant boxes for years.
[12:42] <Odd_Bloke> semiosis: I don't disagree that we should have had to, and it wasn't a decision that I was involved in.
[12:42] <Odd_Bloke> semiosis: But we have now released the Vagrant boxes the way they are.
[12:42] <semiosis> Odd_Bloke: if people could've even booted the xenial boxes they would've reported that config management was missing, but the xenial boxes were so broken people couldn't even get that far
[12:43] <Odd_Bloke> semiosis: And so we need to be aware that there are now users (including some in bug reports), who are using them as they currently are, and are happy with them.
[12:44] <Odd_Bloke> semiosis: And so, again, I'm not saying that we won't or can't add in the config management tools.
[12:44] <Odd_Bloke> semiosis: But I am saying that we are _definitely_ going to fix shared folders and hostname resolution problems.
[12:46] <semiosis> Odd_Bloke: what do you want to do about config management packages then?
[12:47] <Odd_Bloke> semiosis: I'd suggest pulling those lines out of your existing MP, filing a bug about them being missing and (once your current MP is merged) filing an MP with just these changes.
[12:49] <semiosis> Odd_Bloke: this is highly frustrating, but you give me no choice
[12:49] <semiosis> Odd_Bloke: i'll open that bug and see where it goes
[12:49] <rbasak> Do we want to go down the route of the Vagrant box's behaviour being different from Ubuntu everywhere else?
[12:50] <Odd_Bloke> rbasak: The Vagrant box pre-xenial already has all the config management bits included.
[12:50] <semiosis> rbasak: that's how it's been for a long time.  were people complaining that the vagrant boxes had config management?  no, because that's expected of a vagrant base box.
[12:51] <rbasak> What does "had config management" mean, OOI? A bunch of packages installed by default? Or something more?
[12:51] <Odd_Bloke> rbasak: Yeah, puppet, chef etc. installed.
[12:51] <semiosis> thats it
[12:51] <rbasak> semiosis: I'd say that developers also probably expect similar behaviour between Vagrant boxes and production.
[12:51] <rbasak> I mean - that's the whole point, isn't it?
[12:51] <semiosis> rbasak: developers expect vagrant boxes to have config management
[12:52] <Odd_Bloke> semiosis: There's no documentation to suggest that it's expected of a Vagrant base box; https://www.vagrantup.com/docs/boxes/base.html says "only a bare minimum set of software for Vagrant to function", and "Perhaps Chef, Puppet, etc. but not strictly required."
[12:52] <rbasak> semiosis: refusal to look at the bigger picture isn't going to help here.
[12:53] <semiosis> rbasak: whats the bigger picture look like to you?
[12:54] <rbasak> I think there's a classic conflict here. "Vagrant" users expect the same "Vagrant" experience across all distros. "Ubuntu" users expect the same "Ubuntu" experience across all "Ubuntu".
[12:54] <rbasak> I think both points of view have merit here. The difficulty is that it's generally not possible to meet both set of requirements.
[12:55] <Odd_Bloke> semiosis: If I understand correctly (which is by no means guaranteed :), all we would really be requiring people to do is add a shell provider line with "apt-get install (vagrant|chef|...)" to their Vagrantfile; is that accurate?
[12:55] <semiosis> the pre-xenial vagrant boxes had (for many years) met both sets of reqs
[12:56] <rbasak> And a new release is the right point to make a breaking change, if indeed that is the right thing to do.
=== hikiko|bbl is now known as hikiko
[12:57] <rbasak> I bet the developers who use Vagrant and expect puppet to be installed there would also find it convenient for images on (eg. EC2) to also have puppet installed by default.
[12:57] <rbasak> But if we extended that to everything, then we'd have another set of users complain about how bloated the images are.
[12:57] <Odd_Bloke> (As a side note, we've already had one user comment on the size of my test Vagrant box with these packages added back in)
[12:59] <semiosis> Odd_Bloke: i'll try the shell provider as you suggest and let you know
[12:59] <semiosis> Odd_Bloke: are you aware of any complaints over the last few years about ubuntu's "bloated" vagrant boxes?
[13:00] <Odd_Bloke> semiosis: If it does work, I expect not including them may actually lead to less downloading, because you'd only be pulling in the one config management tool you use.
[13:00] <rbasak> Looking solely at complaints from existing Vagrant users is sampling bias. How many users are using different tooling because the current images didn't suit their needs? We don't hear from those.
[13:00] <Odd_Bloke> Well, we also only introduced a single point to report Vagrant images earlier this year.
[13:01] <Odd_Bloke> *Vagrant image bugs
[13:01] <Odd_Bloke> So we don't really have a historical sense of it regardless.
[13:02] <Odd_Bloke> But we do regularly get complaints about the size of all of our images. :p
[13:02] <semiosis> i'm sure!
[13:02] <rbasak> We always get complaints both ways. Users want less bloated images. Other users want their obvious thing in them by default :)
[13:07] <semiosis> thanks for going through this with me Odd_Bloke & rbasak.
[13:07] <semiosis> i'll open the bug and we'll see where it goes.
[13:07] <cyphermox> nacc: sg3-utils> it's because sg3-utils should not have been synced, it should have been a merge.
[13:07] <rbasak> semiosis: np. Sorry there's no easy answer. I hope you understanding my reasoning as to why.
[13:07] <semiosis> Odd_Bloke: is there a link to open a vagrant bug?
[13:09] <semiosis> rbasak: yes i do understand.  you're right about a new release being the place for a breaking change.  we'll see what people say in the bug comments.
[13:12] <rbasak> semiosis: thanks. https://bugs.launchpad.net/cloud-images/+filebug might be a good starting place unless Odd_Bloke has somewhere else in mind. We can always move it later.
[13:20] <cyphermox> nacc: fixed it.
[14:03] <caribou> infinity: do you remember a discussion you had with tinoco & mdeslaur about ABI issues with libnss_winbind (samba) & requirement to statically link those two modules ?
[14:03] <caribou> infinity: LP: #1584485
[14:03] <ubottu> Launchpad bug 1584485 in samba (Ubuntu) "Upgrading samba to latest security fixes together with winbind in nsswitch.conf can harm entire OS" [High,In progress] https://launchpad.net/bugs/1584485
[14:04] <caribou> I'm trying to figure out a decent way of linking them statically in the package
[14:08] <semiosis> Odd_Bloke: i pushed the changes you requested to my branch.  test was successful.
[14:13] <semiosis> Odd_Bloke: rbasak: config management bug as we discussed is here: https://bugs.launchpad.net/cloud-images/+bug/1599531
[14:13] <ubottu> Launchpad bug 1599531 in cloud-images "Xenial vagrant box is missing puppet/chef/etc config management" [Undecided,New]
=== funkyHat2 is now known as funkyHat
[14:19] <rbasak> semiosis: thank you for filing that
[14:19] <semiosis> rbasak: it's my pleasure!
[14:21] <semiosis> i hope people comment there.  i'm really interested to see what people have to say.  Odd_Bloke's shell provisioner idea works great, so that is a suitable workaround (now documented in the bug) for people who need config management on the vagrant box.
[14:24] <rbasak> Unfortunately bug discussion tends to suffer from sampling bias too, IMHO.
[14:24] <rbasak> People affected are over-represented compared to everyone else.
=== tyhicks` is now known as tyhicks
[14:32] <semiosis> thanks again for all your help with this stuff.  hope i wasn't too argumentative :)
[14:32] <semiosis> time to head into the office.  bbl
[14:36] <rbasak> semiosis: no problem. Thank you for caring :)
=== NCommander is now known as mcasadevall
[15:00] <nacc> cyphermox: thanks!
[15:02] <sil2100> cjwatson, infinity: hey guys! Do we always have so many disabled amd64 builders? We just landed new langpack packages in the overlay and they're waiting for free amd64 builders since an hour
[15:09] <michael-vb> Afternoon.  Not sure if this is the right place to ask, but someone will probably know what is.
[15:09] <michael-vb> I have the following problem with my VirtualBox Ubuntu 16.04 guest with development Guest Additions installed: when I start the guest I get the message "The system is running in low-graphics mode" (on VT 2) even though the X server is running fine (on VT 7).
[15:09] <michael-vb> I would very much like to know exactly what logic triggers that message so I can work out why I am triggering it and change whatever is responsible (I am the developer of the VirtualBox guest driver and Additions installer).
[15:09] <michael-vb> (By the way, I am away from the keyboard for a bit, but experience says that answers usually take a while on IRC, so probably no problem.)
[16:04] <michael-vb> Interesting - I just booted the guest system twice with a loaded host (rebuilding VirtualBox) and did not get the "low-graphics mode" message.
[16:09] <cjwatson> sil2100: lcy01 often needs a good kicking
[16:12] <cjwatson> sil2100: I've poked it
[16:27] <michael-vb> CRITICAL: session_get_login1_session_id: assertion 'session != NULL' failed in the lightdm log file.
[16:31] <michael-vb> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814760
[16:31] <ubottu> Debian bug 814760 in lightdm "randomly fails to start" [Normal,Open]
=== stub` is now known as stub
=== dpm is now known as dpm-afk
[17:15] <sil2100> cjwatson: thanks!
[18:06] <kees> Totally up to us, except that I need to be there all day 25 and 26 (I imagine flights back would happen on the 27th, though ugh, the return flight leaves at 6:26)
[18:06] <kees> pm
[18:06] <kees> (the only direct)
[18:06] <kees> yes! that was not meant for here
[18:09] <nacc> slangasek: would you have any advice on how to handle LP: #1598489? again, it's marking php7.0 SRU as leading to a regression, but it's not clear to me how that's possible (in this case). And not enough info in teh bug. Is it appropriate for me to chagne the tags and just work the bug, or should I leave it in the current tags until I have a definitive answer?
[18:09] <ubottu> Launchpad bug 1598489 in php7.0 (Ubuntu) "package php7.0-common 7.0.8-0ubuntu0.16.04.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 10" [Undecided,Incomplete] https://launchpad.net/bugs/1598489
=== mcasadevall is now known as NCommander
[19:13] <slangasek> nacc: exit status 10 is an exit value associated with debconf.  Does your SRU introduce any changes to maintainer scripts / debconf prompts?
[19:13] <slangasek> nacc: if not, we should triage this as not-a-regression
[19:17] <michael-vb> Ping, anyone around: the "low graphics mode" issue in a VirtualBox guest.
[19:17] <michael-vb> See above.
=== salem_ is now known as _salem
[19:26] <michael-vb> As I said, this may well be the wrong place to ask, but in that case I would love to know the right place (or person).
[19:26] <nacc> slangasek: no, there should not be any maintainer script changes; i'll re-verify that, thanks
=== _salem is now known as salem_
[19:32] <fo0bar> infinity: btw, following up from a conversation earlier this year, I was able to successfully convert a G4 mini to use grub-ieee1275 instead of yaboot
[19:33] <fo0bar> infinity: grub-install has no concept of non-prep setups, so I mostly adapted ideas from http://cynic.cc/blog/posts/running_grub2_on_powerpc_macs/
[19:34] <fo0bar> the bootstrap partition was way too small for a full grub + modules, so I had to pare down the modules.  and "splash" messes up VT handoff (or lack thereof) and results in no video whatsoever
[19:36] <fo0bar> but grub + pared modules + stub grub.cfg which searches for the root UUID partition and hands off to its grub.cfg, plus /etc/default/grub removing splash works
[19:41] <michael-vb> Oh well, getting late.  Will try again tomorrow.  If anyone can answer, feel free to ping me by e-mail, at michael dot thayer at oracle and I will be very grateful.
[19:41] <michael-vb> Good night.
[19:43] <coreycb> arges, can you reject my python-oslo.concurrency upload for wily?  I need to upload a new version with an i386 patch for the cloud archive.
[19:46] <arges> coreycb: ok
[19:46] <arges> coreycb: done
[19:49] <coreycb> arges, thanks
[20:43] <jderose> tyhicks: did you have a chance to look at my revised ecryptfs-utils patch yet? if so, any thoughts on it?
[20:47] <tyhicks> jderose: hey - I've been on holiday the last two days and actually just started looking at it a few minutes ago
[20:47] <tyhicks> jderose: I'll leave comments in the merge request
[20:50] <jderose> tyhicks: awesome, thanks! hope you had a great holiday :)
[20:51] <tyhicks> thanks :)
[21:05] <mwhudson> is there a reason a new source package in debian might not be synced to ubuntu by default
[21:05] <mwhudson> ?
[21:06] <mwhudson> https://launchpad.net/debian/+source/snap-confine <- this one, specifically
[21:06] <Laney> mwhudson: Does http://people.canonical.com/~ubuntu-archive/auto-sync/current.log have anything to say?
[21:06] <mwhudson> that version is only a few hours old but the older one didn't sync either
[21:06] <mwhudson> Laney: ah, let's find out!
[21:07] <Laney> (yes)
[21:07] <mwhudson> yes
[21:07] <Laney> :)
[21:13] <slangasek> mwhudson, Laney: oh then I'll just accept it so it's no longer in NEW
[21:13] <slangasek> (done)
[21:19] <mwhudson> slangasek: aah
[21:19] <mwhudson> slangasek: the package in NEW was the native one
[21:19] <slangasek> mwhudson: yes.  1.0.34-1 > 1.0.34, so it'll still sync over it
[21:19] <mwhudson> oh ok
[21:19] <mwhudson> true
=== salem_ is now known as _salem