[03:03] <jderose> is it expected that when doing a vivid encrypted home folder install (ecryptfs), grub should prompt you for a passphrase at boot?
[03:03] <jderose> is this a regression, or have things just changed in terms of how the encrypted swap partition gets unlocked?
[03:10] <cyphermox> jderose: no, I don't think you should get prompted on boot for anything when it's for an encrypted home folder.
[03:11] <cyphermox> especially since that would break having multiple users with encrypted home folders, unless they shared a password for swap :P
[03:12] <jderose> cyphermox: gotcha, thanks... looking into it now. this was from a System76 "golden imaged" installed under qemu in oem-mode... so seeing if it's an issue on normal installs
[03:12] <cyphermox> I may be wrong though -- if it's not working you might want to make sure your image is up to date I guess?
[03:12] <jderose> also noticed there were a number of packages marked as auto-removable after this too, so that might be related
[03:16] <jderose> cyphermox: i could see entering the passphrase (potentially) making sense when resuming from suspend, but you're right that it really doesn't make sense when cold-booting a potentially multi-user system
[03:18] <cyphermox> even if you resume, you have no guarantee the same user is trying to resume, again on a multi-user system
[03:18] <jderose> yeah, true
[03:18] <cyphermox> not that I expect multi-user to be such a common use case, but still :)
[03:19] <jderose> hmm, didn't happen on a normal user install. might be related to my work-around for oem-config-gtk and friends not being installed after doing an oem-mode install
[03:33] <jderose> seems like when i `sudo apt-get install ubiquity-frontend-gtk oem-config-gtk` to work around them being missing after doing an oem install from the latest daily iso, i might need to use --no-install-recommends... without it, some suspect looking packages are being drug in
[03:36] <tyhicks> jderose: hey - just passing through but, no, there's nothing in Ubuntu proper that would cause you to be prompted at boot for an ecryptfs encrypted home directory
[03:36] <jderose> yup, --no-install-recommends seems to solve it. likely there is an underlying bug here, but probably something that will (for most users, even oem install) resolve itself after the next iso build
[03:37] <jderose> tyhicks: gotcha, thanks!
[03:40]  * jderose now tries a normal user bare-metal install...
[03:49] <jderose> normal user install seems fine... no passphrase prompt from grub, no autoremove-able packages after the install completes
[03:57] <tyhicks> good to hear
[03:58]  * tyhicks steps away
[06:52] <flexiondotorg> Is world currently being rebuilt?
[06:52] <elfy> doesn't appear to be so
[06:53] <elfy> we did a rebuild a few ago it seems
[06:53] <elfy> still got issues - though hardware does boot and shutdown properly
[06:53] <flexiondotorg> flexiondotorg, OK, I'm going to kick a rebuild of Ubuntu MATE then.
[06:53] <elfy> vbox fails miserably
[06:53] <flexiondotorg> elfy, What issues are most pressing for you?
[06:54] <elfy> kvm works as you boot the try from the first menu and not the fancy dialogue
[06:54] <flexiondotorg> elfy, I'm aware of VBox falling in a heap on restart. I did some testing to pitti regarding that.
[06:54] <flexiondotorg> elfy, That issue about trying a live session from the Ubiquity DM is still there?
[06:55] <flexiondotorg> That is why I was going to rebuild, I thought that was fixed.
[06:56] <elfy> kvm 32 bit works from the fancy dialogue, 64 bit in kvm from there fails to start desktop
[06:56] <flexiondotorg> elfy, OK. Thanks.
[06:56] <elfy> I'm not sure if the various fixes infinity was waiting for actually landed or not
[06:56]  * flexiondotorg is conflicted. Not sure if a rebuild is wise.
[06:57] <elfy> well - it might be useful if you want to see if you get different fail points I suppose
[06:57] <flexiondotorg> elfy, Just got to that place with my thinking.
[06:57]  * flexiondotorg is rebuilding.
[06:59] <flexiondotorg> elfy, The powerpc testers has found bugs with partitioning in Ubiquity. Can you do some partitioning tests on x86 to see if this is a general issue?
[06:59] <elfy> not now - my little window of checking stuff before work is almost closed - sorry
[07:00] <flexiondotorg> elfy, OK. I'll try and do it later too :)
[07:02] <elfy> flexiondotorg: actually - any sort of partitioning in live or a particular sort?
[07:02] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1446792
[07:13] <elfy> flexiondotorg: looks ok - it's installing after resizing and creating new partition now
[07:22] <elfy> well I guess pitti et all will carry on trying to fix this all
[07:24] <pitti> I pretty much gave up on vbox
[07:24] <elfy> mmm
[07:25] <pitti> if you shut down X, the X driver leaves teh graphics cards in a broken state
[07:25] <elfy> well I get fails in kvm too
[07:25] <pitti> I only see these vertical stripes garbage, and that's it
[07:25] <elfy> oh I don't get that - just some text sitting there :)
[07:25] <pitti> that doesn't look like something we can fix today (and not me personally, I have no clue about X drivers)
[07:26] <pitti> elfy: even with latest casper?
[07:26] <elfy> I am at least positive about hardware - that works :)
[07:26] <pitti> yep, we are testing real hardware and qemu here with every change
[07:27] <elfy> pitti: no idea what casper it is - was expecting a global rebuild overnight - didn't appear to be one, we did a xubuntu one seemingly
[07:27] <infinity> elfy: Yeah, global rebuild didn't happen because things ended up trapped in -proposed, and I'm waiting on a last PAM fix.
[07:27] <elfy> pitti: well running xubuntu in kvm I get various results
[07:27] <elfy> infinity: ack
[07:27] <infinity> pitti: Any ideas about the ubuntu-system-settings-online-accounts autopkgtest failure?
[07:28] <pitti> infinity: not yet; I started a local run, I'll look at it first thing after breakfast
[07:28] <pitti> infinity: it seems odd that it started failing on /sbin/initctl yesterday; perhaps a fallback path when the primary code path stopped working
[07:29] <elfy> well - real life calls me off to work now - I'll catch up on the fun later
[09:43] <flexiondotorg> pitti, I know you've decide to give fixing VirtualBox restarts a pass for 15.04. But what component is the bug actually in? Ubiquity, Casper, etc?
[09:43] <flexiondotorg> pitti, I've had a bugs raised against Ubuntu MATE and I want to file it correctly.
[09:48] <pitti> flexiondotorg: not sure, virtualbox-guest-x11 perhaps? but I figure we don't have that installed by default, I figure it falls back to some generic -vesa driver or whatever
[09:49] <flexiondotorg> pitti, virtualbox-gues-x11 is not installed by default but the dkms moule is part of the kernel package now.
[09:49] <flexiondotorg> pitti, This is the squashfs error I am refering too.
[09:51] <pitti> flexiondotorg: for that I'd start with casper for now (we don't know the real reason yet, but it's a good place to start)
[09:51] <flexiondotorg> pitti, Thanks.
[10:02] <Odd_Bloke> I see that the new pam has hit vivid-proposed; when will it migrate?
[10:14] <Odd_Bloke> infinity: ^ ?
[10:14] <infinity> Odd_Bloke: Ideally soon.
[10:48] <rbasak> Looks like the openssh dep8 test failed due to an unrelated timeout.
[10:49] <rbasak> Ah, and already rerun and passed this time. Thanks.
[10:56] <rbasak> Odd_Bloke: FYI, pam is in the release pocket now.
[10:57] <Odd_Bloke> rbasak: Great, thanks!
[10:58] <Odd_Bloke> Now we play the waiting (for mirrors) game.
[11:11] <rbasak> Your image builds depend on mirrors?
[11:15] <Odd_Bloke> We build the base image on the buildds, but then the rest happens on jerff which will hit the mirrors.
[11:16] <rbasak> Oh. Waiting for mirrors for images to mirror, rather than for the new pam to mirror. I understand now.
[11:58] <infinity> Rebuilding the world now.  Hopefully these are final.
[11:59] <elfy> infinity: I popped in from work at just exactly the right time to see what was happening it seems :)
[12:42] <infinity> LocutusOfBorg1: ^-- This is the vbox upload that you should be able to merge entirely into Debian.
[12:43] <Riddell> what's new in these images?
[12:43] <infinity> Riddell: Depends on when your last one was.  Diffing your manifests would help.
[12:44] <infinity> Riddell: At the very least, there's a PAM fix, but might also be ubiquity and other bits.
[12:44]  * Riddell plays the pam pam tune on spotify
[13:19] <flexiondotorg> infinity, Does the new virtualbox package fix this? -> https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1434579
[13:38] <infinity> flexiondotorg: Yes.
[13:39] <flexiondotorg> Excellent. Will test.
[13:39] <infinity> flexiondotorg: There will still be one "useless" item listed, but it will now let you install the x11 driver, which makes it all work.
[13:39] <flexiondotorg> infinity, Great. Many thanks.
[14:12] <LocutusOfBorg1> infinity, <3
[14:13] <infinity> LocutusOfBorg1: If you pull that into sid, we'll just sync it back to w-series and kill the ubuntu fork.
[14:13] <infinity> LocutusOfBorg1: Should be Debian-friendly, I didn't do anything that would break non-Ubuntu.
[14:14] <LocutusOfBorg1> you removed .gitattributes... weir
[14:14] <LocutusOfBorg1> d
[14:14] <LocutusOfBorg1> should I really drop it?
[14:15] <LocutusOfBorg1> -changelog merge=dpkg-mergechangelogs
[14:15] <infinity> LocutusOfBorg1: Oh, that's because I build with "dpkg-buildpackage -i -I", which excludes VCS files.
[14:15] <LocutusOfBorg1> ack
[14:18] <LocutusOfBorg1> http://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=87db86590cc380594238c9b6746fb0bc278ec244
[14:19] <LocutusOfBorg1> I gave you credits, I hope it is all ok
[14:20] <infinity> LocutusOfBorg1: Looks good, though you didn't need to apply the gitattributes removal.  Not that it matters to keep it either, I imagine.
[14:20] <LocutusOfBorg1> http://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=28524c4dabd28a27c947eb0bde322272b4729462
[14:20] <LocutusOfBorg1> Already rebased and pushed :)
[14:20] <LocutusOfBorg1> I noticed it while posting here
[14:20]  * LocutusOfBorg1 wonders if somebody will make him stop using push -f
[14:21] <infinity> LocutusOfBorg1: Shiny.
[14:25] <LocutusOfBorg1> infinity, do you plan to do the same for debian?
[14:29] <infinity> LocutusOfBorg1: Which?  Include the drivers in the kernel?  Probably not.  But my changes are harmless in that case.
[14:29] <infinity> LocutusOfBorg1: The package layout is designed to prefer kernel-provided drivers if they're installed, and dkms if not, so it'll all Just Work.
[14:35] <LocutusOfBorg1> yep I know, but having the module provided by the kernel for debian too will avoid many bug reports about problems in building
[14:35] <LocutusOfBorg1> when different kernels are used
[15:02] <infinity> LocutusOfBorg1: Yeah, would be a conversation to have with the Debian kernel team, but I think they prefer to stick closer to vanilla upstream.
[15:03] <LocutusOfBorg1> so next question, what about asking vbox people to upstream their module?
[15:20] <wxl> backlog suggests there's vm probs again?
[15:21] <flexiondotorg> infinity, Do you anticipate that the rebuilds that ran earlier are the last spins before final?
[15:22] <infinity> flexiondotorg: That's the hope.
[15:25] <jderose> when using an encrypted home directory, is anyone getting prompted by a grub- esque dialog to unlock the cryptoswap prior to lightdm coming up?
[15:26] <flexiondotorg> infinity, Great. Looking good for Ubuntu MATE so far :)
[15:27] <flexiondotorg> jderose, I haven't got to the test case yet.
[15:27] <flexiondotorg> jderose, Will feedback to you when I do.
[15:29] <jderose> flexiondotorg: cool, thanks. it might be related to doing an oem insall, still trying to narrow it down.
[15:31] <flexiondotorg> jderose, So oem install with encrpyted home is the test case?
[15:32] <jderose> not using encrypted home directory during oem-mode install itself, but i'm setting it up during the frist-user-run-config
[15:33] <flexiondotorg> jderose, Understood.
[15:47] <Odd_Bloke> Is that unapproved isc-dhcp anything to worry about?
[15:50] <infinity> Odd_Bloke: It'll be an SRU.
[15:50] <rbasak>    * debian/patches/dhcp-getifaddrs.patch: use getifaddrs
[15:50] <rbasak>      for getting nic addresses rather than /proc/net (LP: #1446767)
[15:51] <rbasak> Odd_Bloke: https://launchpad.net/ubuntu/vivid/+queue?queue_state=1 to see unapproved stuff if you don't know about that already.
[15:54] <Odd_Bloke> rbasak: Aha, thanks!
[15:54] <Odd_Bloke> infinity: \o/
[15:58] <flexiondotorg> jderose, I've tested on i386 and amd64. I can't reproduce.
[15:59] <jderose> flexiondotorg: i haven't been able to reproduce it doing a normal, manual install, so i think it's related to my image mastering tools
[16:22] <flexiondotorg> jderose, What flavour BTW?
[16:23] <jderose> flexiondotorg: ubuntu desktop
[16:23] <flexiondotorg> jderose, OK.
[16:24] <jderose> flexiondotorg: you're testing mate, correct?
[16:24] <flexiondotorg> jderose, I am. But I just did some testing with stock Ubunut. Will try your test case on stock Ubuntu now.
[16:26] <jderose> so far i've only been able to reproduce imaging from our imaging server. there are a number of things i do slightly differently than ubiquity, so it might be one of those differences. like we do gpt partitioning even when the drive is < 2TB
[16:30] <flexiondotorg> jderose, imaging server?
[16:31] <jderose> yeah, the imaging system that System76 uses. which i also wrote... so probably my goof :P
[16:34] <flexiondotorg> jderose, Ah, so you work for System76?
[16:34] <jderose> yup :)
[16:34] <flexiondotorg> jderose, Nice :)
[16:35] <flexiondotorg> jderose, Testsed stock Ubuntu. oem install, first boot encrypted home. All good.
[16:37] <jderose> flexiondotorg: yeah, i had the same results.
[16:43] <wxl> pitti: is there still another ubiquity fix coming? folks still complaining about bug 1445587
[16:44] <jderose> ah ha, seems like it's related to gpt partitioning. the only thing i changed was to make the imager use mbr partitioning, an now there are no problems
[16:45] <jderose> pitti: are you aware of any issues with systemd + encrypted home directory + gpt partitioning? i see a message in syslog from systemd about the cryptoswap failing because of dependencies
[16:45] <elfy> wxl: and are you completely sure they have latest image, there are still issues with vbox afaik also
[16:46] <wxl> elfy: well they say 20150422.1, so… but yeah, it is vbox
[16:47] <elfy> right - from what I've read in logs etc - vbox issue is an issue and will be tomorrow too
[16:47] <elfy> but I'm just me obviously
[16:47] <pitti> wxl: not right now; on hardware and qemu it seems working fairly well now
[16:48] <wxl> pitti: elfy: well, the guy did reference vbox, so
[16:48] <elfy> pitti: hardware works for me on both arch's, qemu seems ok, vb hard reboot still
[16:48] <infinity> wxl: Yeah, it's still broken in virtualbox, and we're not going to be fixing that for release.
[16:49] <teward> infinity: is a fix scheduled at some point?
[16:49] <wxl> infinity: i'll request a new bug be filed
[16:50] <wxl> teward: did you test recently with vmware? it would be nice to know if it's an issue
[16:50] <infinity> teward: That would imply we know why vbox is sad.
[16:50] <teward> wxl: not recently, i need an image, hence my asking in -quality if there's been a 'final image' available for download
[16:50] <teward> (my prior VM exploded itself)
[16:50] <wxl> teward: well we've had about a billion rebuilds, so based on history we may never have a final :) just go grab it!
[16:51] <teward> heh
[16:51] <pitti> jderose: not aware of that, no
[16:51] <teward> wxl: which image, beta 2?
[16:51] <teward> or current daily
[16:51] <wxl> teward: vivid final. dailies are building currently.
[16:51] <pitti> jderose: hang on -- that's ecryptfs, right?
[16:51] <wxl> teward: and desktop! not alternate. i've got another issue with it i'm trying to track down at this time.
[16:51] <jderose> pitti: i'm still digging into this, but as far as i can tell, it only happens when using gpt partitioning... with mbr partitioning, it works fine
[16:51] <pitti> jderose: might that still be bug 953875?
[16:52] <pitti> jderose: ok, something else then
[16:52] <infinity> wxl: Nothing is building currently...
[16:52] <wxl> infinity: well, that's what i meant.
[16:52] <pitti> jderose: I have a hunch what's wrong -- maybe the gpt generator saw the underlying incomplete swap partition and tried to activate it
[16:52] <teward> wxl: i'd need a link then for the final image, i don't have a link and i don't see one in standard locations.
[16:52] <pitti> jderose: but journalctl appreciated
[16:53] <wxl> teward: zsync i'm assuming?
[16:53] <infinity> teward: Which flavour?
[16:53] <teward> wxl: yes.
[16:53] <teward> infinity: Lubuntu
[16:53] <teward> although I need a zsync for Ubuntu Server as well
[16:53] <wxl> teward: amd64?
[16:53] <infinity> http://cdimage.ubuntu.com/lubuntu/daily-live/20150422/
[16:53] <teward> infinity: thanks
[16:53] <infinity> http://cdimage.ubuntu.com/ubuntu-server/daily/20150422/
[16:53] <infinity> ie: where you'd expect.
[16:53] <wxl> yeah what he said
[16:53] <wxl> until we schedule another rebuild
[16:53] <wxl> :)(
[16:54] <teward> infinity: i didn't see the date folder when i went through
[16:54] <teward> i blame browser cache
[16:54] <jderose> pitti: i looked at /etc/fstab, /etc/crypttab, and they seem correct. happen to have instructions somewhere on how best to get you what you need with journalctl?
[16:54] <pitti> jderose: do you actually have the intended cryptswap1 partition?
[16:55] <jderose> yup
[16:55] <pitti> jderose: just its output up to the point when it hangs would be useful
[16:55] <pitti> jderose: ok, so the original bug got fixed I guess
[16:55] <infinity> wxl: I have no intention of rebuilding anything, but if you need to break just lubuntu, that's your call.
[16:55] <jderose> as far as i can tell, yes, but i don't know all the details of that bug
[16:55] <wxl> infinity: i was kidding, dear :)
[16:55] <infinity> wxl: We're at the point where any bugs found should just be SRUs and mentioned in release notes if they're annoying enough.
[16:55] <teward> wxl: as soon as zsync pulls the image down i'll let you know and then go beat it with a stick :)
[16:57] <jderose> pitti: oh, also, in case you didn't read back... this issue is that with gpt partitioning i get prompted by a grub-esque/debconf-esque dialog to enter my passphrase to unlock the cryptoswap, prior to lightdm coming up
[16:58] <pitti> jderose: hm, that seems unusual; would you mind filing a bug with the defails how you installed, the logs, etc?
[16:58] <jderose> so cryptoswap is working correctly, minus the unlock prompt that (afaik) should never be there
[16:59] <pitti> need to disappear soon today, I'm afraid
[16:59] <pitti> jderose: yeah, I suppose that
[16:59] <jderose> yup, will do that shortly
[16:59] <pitti> 's a /dev/urandom device
[16:59] <pitti> ergo no password
[16:59] <pitti> jderose: please attach fstab, crypttab, and output of sudo blkid
[17:00] <jderose> k, will do after i isolate the steps to reproduce it a bit better
[17:00] <teward> wxl: do you have the bug for the virtualbox issue you now want me to test on a VMware environment?  In addition to the shutdown/restart of live bug that was just pinged to me in -quality
[17:00] <teward> (I already have the shutdown/restart bug on screen)
[17:00] <wxl> teward: that's the one actually
[17:00] <teward> heh
[17:01] <teward> wxl: specificity is golden, by the way :p
[17:01] <teward> i'll check this as soon as zsync is done
[17:01]  * wxl moves over to -quality
[17:01] <jamespage> why is oslo.db seeded in desktop and kubuntu?
[17:01]  * jamespage scratches his head
[17:02] <jamespage> well it needs fixing
[17:02] <infinity> jamespage: It's not on images.
[17:02] <jamespage> infinity, good-oh
[17:02] <infinity> jamespage: Just in supported, I assume due to build-deps or something.
[17:02] <jamespage> righty
[17:23] <slangasek> infinity: is it safe for me to do a sync-mirrors right now? (snappy pre-publications)
[17:45] <slangasek> infinity, cjwatson: does regeneration of Task fields still require a non-null publication in the release pocket?
[17:46] <cjwatson> slangasek: yes, though it can be something trivial like a section override
[17:47] <cjwatson> slangasek: I did some work recently which would make that easier to fix, but not complete yet
[17:47] <Riddell> meh my kubuntu.org announce leaked onto the rss feed again, sorry :(
[17:51] <slangasek> cjwatson: well I happen to have a package that I needed to let out of the unapproved queue, so this will do the trick
[18:02] <slangasek> should autopkgtest be unblocked for release?
[18:02] <slangasek> I guess it's a safe bet that libreoffice shouldn't ;P
[18:18] <jderose> pitti: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1447282
[18:18] <jderose> fyi, booting with init=/sbin/upstart seems to reliably work-around the problem
[20:16] <kenvandine> please reject ubuntu-system-settings, that should have gone to the overlay ppa
[20:17] <cyphermox> kenvandine: too late for that I think
[20:17] <Ukikie> dput without dest?
[20:17] <cyphermox> well, it's in proposed anyway
[20:17] <kenvandine> right
[20:17] <kenvandine> Ukikie, no, silo wasn't configured for the overlay ppa
[20:17] <cjwatson> it can be removed from -proposed
[20:18]  * kenvandine is glad we have proposed :)
[20:18] <cjwatson> can even be copied into the overlay ppa if you want
[20:18] <cjwatson> (and if robru is happy with me doing that)
[20:18] <kenvandine> cjwatson, i can fix it myself :)
[20:18] <kenvandine> thx though
[20:18] <robru> cjwatson: kenvandine oh just copying it to the overlay is the easiest thing...
[20:18] <cjwatson> well, doing it via citrain entails rebuild+reupload
[20:18] <cjwatson> copying way more efficient
[20:18] <kenvandine> ok, please copy it :)
[20:19] <robru> cjwatson: no need to rebuild, but it is a hassle to change the silo destination and republish
[20:19] <cjwatson> ah right
[20:19] <cjwatson> anyway, I'll copy+delete
[20:19] <robru> cjwatson: yeah if you can copy it that's easiest, thanks a bunch!
[20:19] <kenvandine> cjwatson, thanks!
[20:19] <kenvandine> robru, i'll be sure to check that column from now on :)
[20:20] <robru> kenvandine: thanks
[20:20] <kenvandine> i'll go ahead an run the merge job
[20:20] <cjwatson> copied and deleted
[20:20] <kenvandine> thanks!
[21:42] <slangasek> robru: so how did ubuntu-system-settings end up in vivid-proposed instead of the overlay ppa?  Are there silos still missing a reconfigure?
[21:42] <slangasek> cjwatson: does deleting ubuntu-system-settings from vivid-proposed prevent us from re-copying it to w-proposed from the overlay ppa when w opens?  (Since we're meant to sync the lot from the overlay into w)
[21:43] <robru> slangasek: because Ken assigned, built, and published the silo himself and he didn't configure for the overlay ppa.
[21:44] <slangasek> robru: oh.  which makes me realize, we haven't really talked through dual publications for stable-phone-overlay/vivid + w... we probably need to revisit that again
[21:44] <cjwatson> slangasek: no
[21:44] <cjwatson> slangasek: it's just like resurrecting a deletion using a copy-with-binaries, which we know we can do
[21:44] <slangasek> robru: ok.  can we make the overlay ppa the default target, please?  At least so long as vivid is the default release
[21:44] <slangasek> cjwatson: ok
[21:44] <robru> slangasek: right, so we still have that dual publishing code, it's a little bit-rotty but it shouldn't be hard to resurrect
[21:45] <slangasek> robru: I seem to recall that last time we were dual publishing, we still had some inconsistencies in how we were versioning packages etc
[21:46] <slangasek> sorry, when I say "dual publishing" I don't mean just the publishing of one silo to two targets, but the general question of making sure the changes land in both places
[21:46] <robru> slangasek: i don't think so? I remember working on the version-mangling code... It injected "~utopic" at the time so the version numbers matched but utopic was always lower
[21:47] <slangasek> robru: anyway, it occurs to me that even if we don't want it today, after tomorrow we /do/ want all uploads to the overlay ppa to also land in w-proposed
[21:47] <slangasek> at least initially
[21:48] <robru> slangasek: the problem is the spreadsheet. I'm not sure i can make cells default to non-blank, and even if i can, it wouldn't distinguish between vivid or others.
[21:48] <robru> Eg rtm would also default to overlay, which would explode
[21:49] <slangasek> robru: we could change the meaning of an empty cell, and require an explicit 'ubuntu' target to override?
[21:50] <robru> slangasek: more spreadsheet code? :-/
[21:50] <slangasek> robru: hmm is that where the code for this lives?  well
[21:50] <slangasek> robru: let's not worry about it just yet then, maybe kenvandine was a one-off ;)
[21:51] <robru> slangasek: well, Jenkins defines "empty dest PPA" to mean Ubuntu archive...
[21:51] <slangasek> robru: right, so you could change the definition on the jenkins side instead of on the spreadsheet?
[21:51] <robru> slangasek: just would get ugly quick to change it, corner cases etc.
[21:51] <robru> slangasek: Hmmmmmmm i suppose.
[21:52] <robru> slangasek: i don't think it's necessary, rsalveti already knows, so do mirv and sil and i... Now ken knows, not many other people assign silos
[21:53] <robru> slangasek: is it OK to wait and see if it happens again?
[21:54] <slangasek> robru: sure
[21:54] <robru> slangasek: great, thanks. I can focus on spreadsheet replacement ;-)
[23:01] <slangasek> infinity: ill-timed ping
[23:02] <slangasek> infinity: ubuntu-core needs an upload of livecd-rootfs to fix a hook that's forcibly removing python from the images.  The only change is to an ubuntu-core-specific hook.  Can I squeeze this into the archive under the wire, or should I upload it only to the ubuntu-core image ppa?
[23:13] <slangasek> infinity: ^^ fyi, self-accepting into -proposed but not unblocking; I'll leave that to your judgement