/srv/irclogs.ubuntu.com/2016/07/06/#ubuntu-devel.txt

=== funkyHat1 is now known as funkyHat
=== JanC is now known as Guest89378
=== JanC_ is now known as JanC
cpaelzergood morning05:05
pittiGood morning05:50
pitticyphermox: hey!06:11
pitticyphermox: 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 SRU06:12
ubottubug 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/153600806:13
ubottubug 1473903 in multipath-tools (Ubuntu Trusty) "parted will generate two devices when adding one partition on mpath device" [High,Triaged] https://launchpad.net/bugs/147390306:13
flexiondotorgpitti, If you have a moment I need some advice regarding my SRUs.07:37
pittiflexiondotorg: Guten Morgen; what's up?07:38
flexiondotorgMorning.07:38
flexiondotorghttps://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/157478907:38
ubottuLaunchpad bug 1574789 in ubuntu-mate-settings (Ubuntu Xenial) "SRU: xorg.conf.d/90-zap.conf destroys xorg keyboard settings" [High,In progress]07:38
flexiondotorgThat issue has been fixed in Yakkety.07:39
pitti> +rm_conffile /usr/share/X11/xorg.conf.d/90-zap.conf 16.04.507:39
flexiondotorgBut clearly I've not done something correctly to indicate that.07:39
pittiwas this removed in yakkety?07:39
flexiondotorgYes.07:39
pittias that's what caused the regression and reopened the bug07:39
pittiok, then  please say so and close the floating task07:39
pittiso this just needs a follow-up upload to xenial then with the updated patch?07:40
flexiondotorgSo this is a term I need to understand the meaning of.07:41
flexiondotorgWhat is a "task"?07:41
pittievery line with a triangle in the table on the top07:41
flexiondotorgAnd I did upload again, a couple of days ago, to Xenial.07:42
pittithis 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
pittithis currently says that it's in progress in both the devel series and xenial07:42
flexiondotorgThanks for the explanation. I've marked the devel series task as Fix Released.07:46
flexiondotorgpitti, So can you "see" the ubuntu-mate-settings 16.04.5.3 for Xenial?07:49
pittiflexiondotorg: it's in https://launchpad.net/ubuntu/xenial/+queue?queue_state=1 , I suppose you mean that?07:50
pittiflexiondotorg: btw, please don't close/reopen tasks without a comment07:50
flexiondotorgOK, I'll add an appropriate comment.07:51
pittiflexiondotorg: thanks; I accepted the xenial update07:53
flexiondotorgpitti, Thanks for the help.07:55
flexiondotorgI have a similar issue with the SRU07:55
flexiondotorghttps://bugs.launchpad.net/ubuntu-mate/+bug/158116807:55
ubottuLaunchpad bug 1581168 in ubuntu-mate-artwork (Ubuntu) "SRU: GTK3 scrollbars in Radiant-MATE not styled like GTK2" [Undecided,New]07:55
flexiondotorgThat is also fixed in Yakkety already.07:56
pittiflexiondotorg: I added a xenial task; please close it for y then07:58
flexiondotorgpitti, Thanks. I wasn;t able to add the Xenial task. Is that intended?07:58
pittiflexiondotorg: you should be able to as a developer; bdmurray manages these07:59
pittiflexiondotorg: on https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1581168, do you see a "Nominate for series"?07:59
ubottuLaunchpad bug 1581168 in ubuntu-mate-artwork (Ubuntu Xenial) "SRU: GTK3 scrollbars in Radiant-MATE not styled like GTK2" [Undecided,New]07:59
pittithat's the one07:59
flexiondotorgThere was no option to target Xenial.07:59
pittiyou can click it, you should then get some check boxes for trusty etc. (not for xenial any more as I just did that)07:59
flexiondotorgI've added a comment and marked as Fex Released for the dev task.08:03
pittithanks08:04
flexiondotorgpitti, When I try to select a target the only tick box I see is Trunk08:07
flexiondotorgAnd, thank you for helping out pitti. Very much appreciated.08:07
pittiflexiondotorg: oh, then you have the upstream task selected, not the ubuntu task08:07
pittithat's a bit icky indeed, there's no way to select it with clicking08:07
pittiflexiondotorg: try on https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1581168,08:08
ubottuLaunchpad bug 1581168 in ubuntu-mate-artwork (Ubuntu Xenial) "SRU: GTK3 scrollbars in Radiant-MATE not styled like GTK2" [Undecided,New]08:08
flexiondotorgAhhh, penny drop :-)08:08
flexiondotorgRight, understood.08:08
pittii. e. you have to get to the page via the "ubuntu" bug list, not the upstream bug list08:08
flexiondotorgpitti, So can you see ubuntu-mate-artwork (16.04.6.2)?08:16
flexiondotorgIs there anything more I need to do to progress that SRU?08:16
pittiflexiondotorg: no, not in https://launchpad.net/ubuntu/xenial/+queue?queue_state=108:17
flexiondotorgHmm, well I did upload it weeks ago.08:17
pittiflexiondotorg: did you get a REJECT email?08:18
pittihttps://launchpad.net/ubuntu/xenial/+queue?queue_state=4&queue_text=mate08:18
pittinot there eitehr08:18
flexiondotorgI don't recall a rejection. I'll double check. I have the .upload file here:08:19
flexiondotorgSuccessfully uploaded ubuntu-mate-artwork_16.04.6.2.dsc to upload.ubuntu.com for ubuntu.08:19
flexiondotorgSuccessfully uploaded ubuntu-mate-artwork_16.04.6.2.tar.xz to upload.ubuntu.com for ubuntu.08:19
flexiondotorgSuccessfully uploaded ubuntu-mate-artwork_16.04.6.2_source.changes to upload.ubuntu.com for ubuntu.08:19
flexiondotorgOK, it was rejected on June 29th.08:20
flexiondotorgpitti, So should I re-upload 16.04.6.2 or bump the version to 16.04.6.3 and upload?08:21
flexiondotorgI'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
pittiflexiondotorg: reupload .2 please08:22
flexiondotorgOK08:22
pittiflexiondotorg: https://launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+publishinghistory08:23
pittiflexiondotorg: it was never accepted indeed08:23
pittiflexiondotorg: well, maybe call it 16.04.7 to have a slightly saner version number :)08:23
flexiondotorgpitti, I've been getting conflicting feedback on the versions :-)08:24
flexiondotorgI've re-uploaded 16.04.6.208:24
flexiondotorgBut I much prefer a saner version.08:24
flexiondotorgIf another SRU is required I use .708:25
pittiflexiondotorg: so reupload it as 16.04.7 and I'll reject the .6.2?08:25
flexiondotorgpitti, Wilco08:25
flexiondotorgpitti, Done.08:29
cjwatsonOdd_Bloke: Did you notice infinity's comment to the effect that your arm64 image boot log looked more like a powerpc image?09:19
Odd_Blokecjwatson: 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_Blokecjwatson: Which we are doing, so either my understanding is incorrect, or something strange is happening in bos01.09:21
cjwatsonOdd_Bloke: I wouldn't rule out the latter, although historically there's been some confusion between "arm64" and "aarch64" names too I think09:22
cjwatsonvbuilder-g-s-s-production-arm64 appears to set {'architecture': 'aarch64', 'hypervisor_type': 'kvm'}09:23
Odd_BlokeOK, I'll try adding hypervisor_type.09:23
cjwatsonOh, and I said "a powerpc image" above but I guess I actually mean a powerpc guest.09:24
cjwatsonOr ppc64el.09:24
cjwatsonOdd_Bloke: Could be a red herring as it sets that for all arches.09:24
infinityIndeed, 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:25
cjwatsonOdd_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
cjwatsonWell, amd64 anyway.09:26
cjwatsonAh, wait, those are buildd images I'm looking at.09:26
* cjwatson shoves through jq in the hope of being able to read it09:26
cjwatsonOdd_Bloke: Launching on floette though, which is definitely ppc64el.09:42
Odd_Blokecjwatson: The latest one _looks_ like it was put on swirlix03, with that hypervisor_type change.09:43
Odd_BlokeAnd, 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:43
Odd_BlokeBut I've just realised that we're attempting to launch the disk1 image here, not the uefi1 image.09:44
Odd_BlokeSo I'll go and address that next.09:44
cjwatsonDefinitely an improvement.09:45
Odd_BlokeIt's booted and our tests have SSH'd in and everything. \o/09:57
infinity\o/09:57
cjwatsonOh, nice one.  That dnsdomainname test failure isn't particularly scary for this purpose I guess?10:03
cjwatsonOdd_Bloke: And sounds to me like I can reasonably tag the live-build bug v-done?10:05
Odd_Blokecjwatson: Yep, that's not a scary failure; looks like it's v-done to me. :)10:05
cjwatsonDone.10:06
Odd_Blokecjwatson: 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
ubottuLaunchpad bug 1598136 in cloud-images "Fails to produce a loop-mountable FS on powerpc/armhf" [Critical,In progress]10:32
cjwatsonOdd_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
cjwatsonOdd_Bloke: powerpc is somewhat more work; it needs bos02 scalingstack to be deployed first.10:36
cjwatsonOdd_Bloke: infinity possibly could upgrade powerpc to xenial in advance of that.  I don't know what he thinks of that.10:37
infinitydeneed* and fisher* are running ltx-xenial kernels.10:37
infinitylts-xenial, even.10:37
cjwatsonAlso, amd64/i386 are on trusty at the moment, not xenial.10:38
cjwatsonNot even lts-xenial, I think.10:38
Odd_Blokeinfinity: So it's just sagari that isn't?10:38
infinityOdd_Bloke: Indeed, sagari is stuck in the past.10:39
infinityDistant past, at that.10:39
infinityprecise, I think.10:39
cjwatsonSo yeah, notwithstanding what the error message says I think it's actually the precise kernel case that's the problem.10:40
cjwatsonkishi* are on precise, 3.2.10:40
Odd_BlokeYeah, 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
cjwatsonI'll comment on the bug.10:40
infinitykishi 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
infinityAnd sagari should also be able to do the same now.10:41
infinityThe reason it was kept on precise is no longer valid.10:41
cjwatsonI'd really rather not mess with kishi.10:41
infinitycjwatson: Well, I was just suggesting kernel upgrades, not full userspace.  But meh.10:41
cjwatsonBut as for sagari, go nuts.10:41
infinityI'd have done sagari months ago, if I had access to it.10:42
Odd_Blokecjwatson: 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:54
cjwatsonOdd_Bloke: A workaround seems sensible.10:55
mwhudsoni have a package in xenial-proposed that's failed verification10:57
mwhudsonuh i guess i want to upload a new one that has a higher version number anyway, so never mind10:57
=== hikiko is now known as hikiko|bbi
=== hikiko|bbi is now known as hikiko|bbl
=== _salem is now known as salem_
semiosisOdd_Bloke: working on your feedback.  if the test goes well i should push the changes in a few minutes.12:30
semiosisOdd_Bloke: do you know why the config management packages were removed?  where can I read up on that decision?12:30
Odd_Blokesemiosis: 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_Blokesemiosis: So "decision" is generous. ;)12:33
semiosisOdd_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:35
Odd_Blokesemiosis: 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_Blokesemiosis: Which is why I want to split those two conversations up.12:38
Odd_Blokesemiosis: (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:39
semiosisOdd_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:41
Odd_Blokesemiosis: I don't disagree that we should have had to, and it wasn't a decision that I was involved in.12:42
Odd_Blokesemiosis: But we have now released the Vagrant boxes the way they are.12:42
semiosisOdd_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 far12:42
Odd_Blokesemiosis: 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:43
Odd_Blokesemiosis: And so, again, I'm not saying that we won't or can't add in the config management tools.12:44
Odd_Blokesemiosis: But I am saying that we are _definitely_ going to fix shared folders and hostname resolution problems.12:44
semiosisOdd_Bloke: what do you want to do about config management packages then?12:46
Odd_Blokesemiosis: 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:47
semiosisOdd_Bloke: this is highly frustrating, but you give me no choice12:49
semiosisOdd_Bloke: i'll open that bug and see where it goes12:49
rbasakDo we want to go down the route of the Vagrant box's behaviour being different from Ubuntu everywhere else?12:49
Odd_Blokerbasak: The Vagrant box pre-xenial already has all the config management bits included.12:50
semiosisrbasak: 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:50
rbasakWhat does "had config management" mean, OOI? A bunch of packages installed by default? Or something more?12:51
Odd_Blokerbasak: Yeah, puppet, chef etc. installed.12:51
semiosisthats it12:51
rbasaksemiosis: I'd say that developers also probably expect similar behaviour between Vagrant boxes and production.12:51
rbasakI mean - that's the whole point, isn't it?12:51
semiosisrbasak: developers expect vagrant boxes to have config management12:51
Odd_Blokesemiosis: 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
rbasaksemiosis: refusal to look at the bigger picture isn't going to help here.12:52
semiosisrbasak: whats the bigger picture look like to you?12:53
rbasakI 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
rbasakI think both points of view have merit here. The difficulty is that it's generally not possible to meet both set of requirements.12:54
Odd_Blokesemiosis: 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
semiosisthe pre-xenial vagrant boxes had (for many years) met both sets of reqs12:55
rbasakAnd a new release is the right point to make a breaking change, if indeed that is the right thing to do.12:56
=== hikiko|bbl is now known as hikiko
rbasakI 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
rbasakBut 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:57
semiosisOdd_Bloke: i'll try the shell provider as you suggest and let you know12:59
semiosisOdd_Bloke: are you aware of any complaints over the last few years about ubuntu's "bloated" vagrant boxes?12:59
Odd_Blokesemiosis: 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
rbasakLooking 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_BlokeWell, we also only introduced a single point to report Vagrant images earlier this year.13:00
Odd_Bloke*Vagrant image bugs13:01
Odd_BlokeSo we don't really have a historical sense of it regardless.13:01
Odd_BlokeBut we do regularly get complaints about the size of all of our images. :p13:02
semiosisi'm sure!13:02
rbasakWe always get complaints both ways. Users want less bloated images. Other users want their obvious thing in them by default :)13:02
semiosisthanks for going through this with me Odd_Bloke & rbasak.13:07
semiosisi'll open the bug and we'll see where it goes.13:07
cyphermoxnacc: sg3-utils> it's because sg3-utils should not have been synced, it should have been a merge.13:07
rbasaksemiosis: np. Sorry there's no easy answer. I hope you understanding my reasoning as to why.13:07
semiosisOdd_Bloke: is there a link to open a vagrant bug?13:07
semiosisrbasak: 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:09
rbasaksemiosis: 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:12
cyphermoxnacc: fixed it.13:20
caribouinfinity: 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
caribouinfinity: LP: #158448514:03
ubottuLaunchpad 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/158448514:03
caribouI'm trying to figure out a decent way of linking them statically in the package14:04
semiosisOdd_Bloke: i pushed the changes you requested to my branch.  test was successful.14:08
semiosisOdd_Bloke: rbasak: config management bug as we discussed is here: https://bugs.launchpad.net/cloud-images/+bug/159953114:13
ubottuLaunchpad bug 1599531 in cloud-images "Xenial vagrant box is missing puppet/chef/etc config management" [Undecided,New]14:13
=== funkyHat2 is now known as funkyHat
rbasaksemiosis: thank you for filing that14:19
semiosisrbasak: it's my pleasure!14:19
semiosisi 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:21
rbasakUnfortunately bug discussion tends to suffer from sampling bias too, IMHO.14:24
rbasakPeople affected are over-represented compared to everyone else.14:24
=== tyhicks` is now known as tyhicks
semiosisthanks again for all your help with this stuff.  hope i wasn't too argumentative :)14:32
semiosistime to head into the office.  bbl14:32
rbasaksemiosis: no problem. Thank you for caring :)14:36
=== NCommander is now known as mcasadevall
nacccyphermox: thanks!15:00
sil2100cjwatson, 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 hour15:02
michael-vbAfternoon.  Not sure if this is the right place to ask, but someone will probably know what is.15:09
michael-vbI 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-vbI 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.)15:09
michael-vbInteresting - I just booted the guest system twice with a loaded host (rebuilding VirtualBox) and did not get the "low-graphics mode" message.16:04
cjwatsonsil2100: lcy01 often needs a good kicking16:09
cjwatsonsil2100: I've poked it16:12
michael-vbCRITICAL: session_get_login1_session_id: assertion 'session != NULL' failed in the lightdm log file.16:27
michael-vbhttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=81476016:31
ubottuDebian bug 814760 in lightdm "randomly fails to start" [Normal,Open]16:31
=== stub` is now known as stub
=== dpm is now known as dpm-afk
sil2100cjwatson: thanks!17:15
keesTotally 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
keespm18:06
kees(the only direct)18:06
keesyes! that was not meant for here18:06
naccslangasek: 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
ubottuLaunchpad 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/159848918:09
=== mcasadevall is now known as NCommander
slangaseknacc: exit status 10 is an exit value associated with debconf.  Does your SRU introduce any changes to maintainer scripts / debconf prompts?19:13
slangaseknacc: if not, we should triage this as not-a-regression19:13
michael-vbPing, anyone around: the "low graphics mode" issue in a VirtualBox guest.19:17
michael-vbSee above.19:17
=== salem_ is now known as _salem
michael-vbAs 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
naccslangasek: no, there should not be any maintainer script changes; i'll re-verify that, thanks19:26
=== _salem is now known as salem_
fo0barinfinity: btw, following up from a conversation earlier this year, I was able to successfully convert a G4 mini to use grub-ieee1275 instead of yaboot19:32
fo0barinfinity: 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:33
fo0barthe 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 whatsoever19:34
fo0barbut 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 works19:36
michael-vbOh 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-vbGood night.19:41
coreycbarges, 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:43
argescoreycb: ok19:46
argescoreycb: done19:46
coreycbarges, thanks19:49
jderosetyhicks: did you have a chance to look at my revised ecryptfs-utils patch yet? if so, any thoughts on it?20:43
tyhicksjderose: hey - I've been on holiday the last two days and actually just started looking at it a few minutes ago20:47
tyhicksjderose: I'll leave comments in the merge request20:47
jderosetyhicks: awesome, thanks! hope you had a great holiday :)20:50
tyhicksthanks :)20:51
mwhudsonis there a reason a new source package in debian might not be synced to ubuntu by default21:05
mwhudson?21:05
mwhudsonhttps://launchpad.net/debian/+source/snap-confine <- this one, specifically21:06
Laneymwhudson: Does http://people.canonical.com/~ubuntu-archive/auto-sync/current.log have anything to say?21:06
mwhudsonthat version is only a few hours old but the older one didn't sync either21:06
mwhudsonLaney: ah, let's find out!21:06
Laney(yes)21:07
mwhudsonyes21:07
Laney:)21:07
slangasekmwhudson, Laney: oh then I'll just accept it so it's no longer in NEW21:13
slangasek(done)21:13
mwhudsonslangasek: aah21:19
mwhudsonslangasek: the package in NEW was the native one21:19
slangasekmwhudson: yes.  1.0.34-1 > 1.0.34, so it'll still sync over it21:19
mwhudsonoh ok21:19
mwhudsontrue21:19
=== salem_ is now known as _salem

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!