[05:38] <pitti> Good morning
[06:07]  * pitti checks planet again...
[06:07] <pitti> a name, a name, half a king's ransom for a name!
[06:08] <didrocks> nothing in sight, dear sir
[06:10] <pitti> I like infinity's proposal of "wartier warthog"
[06:12] <infinity> pitti: I prefer wascally wabbit.
[06:12] <infinity> Or wascawy.
[07:06] <dholbach> good morning
[07:06] <diwic> hi! Don't we have a name and archive for w yet?
[07:08] <elfy> diwic: no - not yet
[07:11] <diwic> elfy, ok...I wonder what's taking so long.
[07:15] <elfy> no idea - I'm not Mark ;)
[07:48] <LocutusOfBorg1> bdmurray, ping :)
[07:48] <LocutusOfBorg1> I received a mail regarding a phased-update
[07:48] <LocutusOfBorg1> but I can't login to see it
[07:53] <pitti> wgrant: ah, v-done \o/
[07:53] <LocutusOfBorg1> if anybody can pastebin to me this link https://errors.ubuntu.com/problem/35bb694c581825f0eec62d1fcc38e7654941fbcb
[07:53] <pitti> wgrant: as we do all builds in -proposed, the new mangler is already effective; so we mostly just need to get it into -security now so that we can flip on ddebs in LP?
[07:53] <LocutusOfBorg1> I'll be grateful
[07:53] <LocutusOfBorg1> also https://errors.ubuntu.com/problem/2ff630d95be5b0005424b6f887ba2fd88a4b4781 and https://errors.ubuntu.com/problem/7f00260fc0706bef5a73f0de8b5a91f3e9f5abd3
[07:55] <wgrant> pitti: Indeed, we should published to updates and security and then break lucid^W^Wenable ddebs.
[07:55] <pitti> RIP lucid, it's your last day of duty
[07:55] <wgrant> :'(
[07:55] <pitti> no new gccs for lucid any more :)
[07:55] <wgrant> Hard to believe we're killing off the third LTS already.
[07:56] <wgrant> artigas is still going, though.
[07:56] <wgrant> I don't think its final breath will make it.
[07:56] <wgrant> I'm going to leave it going out of respect, though.
[08:02] <LocutusOfBorg1> lucid ship with kernel 2.6.32, how old I feel
[08:10] <jasabella> hi there :)
[08:12] <jasabella> is the ubuntu kernel tweaked in any way which improves laptop battery life?
[08:30] <LocutusOfBorg1> so nobody with access to errors.ubuntu.com?
[08:32] <seb128> LocutusOfBorg1, define access? the site works fine for me
[08:33] <Laney> I think you need to be in some team to get at the errors themselves
[08:34] <Laney> LocutusOfBorg1: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-May/001039.html I think is what you want to do
[09:06]  * hyperair wonders if it's possible to restart the system dbus daemon without bringing down the rest of the machine
[09:25] <larsu> hyperair: most things assume that dbus is always available, so probably not
[09:26] <lathiat> dbus api supports gracefully reconnecting but probably this code path is poorly if ever tested in most software :P
[09:31] <hyperair> hmm damnit
[09:31] <hyperair> my dbus daemon is consuming 300MB of memory and i want to reclaim that RAM
[09:40] <Odd_Bloke> slangasek: http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/jenkins_kvm/view/head:/should_build.py
[09:52] <LocutusOfBorg1> seb128, Laney the problem is "Sorry, you are not a member of a group that is allowed to see the data from error reports. Please fill out this form to request access."
[09:52] <LocutusOfBorg1> I got two mails from bdmurray bot regarding "Possible regression"
[09:52] <Laney> Suggest you fill out the form
[09:52] <LocutusOfBorg1> I did it :)
[09:53] <Laney> then you'll be able to access these things yourself
[09:53] <Laney> nice
[09:53] <Laney> I don't know who receives those, hopefully shouldn't be long
[09:53] <LocutusOfBorg1> ok, I was wondering about which kind of regression introduced the latest virtualbox update
[09:53] <LocutusOfBorg1> I don't want to have a bad update in the archive
[09:54] <LocutusOfBorg1> I hope somebody will enable me soon
[09:59] <pragomer> how can I set the default language of the ubuntu live cd at gfxboot? it has english as default. where can I change it?
[10:41] <pitti> wgrant, slangasek: do you know whether we need to copy p-c-d to *-security as well? i. e. do the security buildd chroots have -updates enabled?
[10:42] <cjwatson> pitti: We do need to copy it to -security, yes.
[10:48] <shadeslayer> doko_: python 3.4 broken now :'(
[10:51] <LocutusOfBorg1> shadeslayer, in debian is broken too
[10:52] <LocutusOfBorg1> https://buildd.debian.org/status/fetch.php?pkg=virtualbox&arch=amd64&ver=4.3.26-dfsg-3&stamp=1430382229
[10:52] <LocutusOfBorg1> still getting build failures
[10:53] <cjwatson> pitti: Are we otherwise good to go?
[10:54] <pitti> cjwatson: thumbs up from my POV
[10:55] <cjwatson> pitti: Are you able to do the copy?  Otherwise I believe I still can
[10:55] <pitti> cjwatson: yes, can do
[10:57] <pragomer> how to set the default language of the ubuntu live cd at gfxboot menu?
[10:57] <cjwatson> put the language code in question in /isolinux/lang
[10:58] <pitti> cjwatson: sent the copy-package command for vivid, waiting for https://launchpad.net/ubuntu/+source/pkg-create-dbgsym/+publishinghistory before I copy the others
[10:59] <pitti> cjwatson: ah, it's in https://launchpad.net/ubuntu/vivid/+queue?queue_state=1, approving
[10:59] <pitti> ok, pending in vivid-security now, doing the others
[10:59] <cjwatson> pitti: you can use --auto-approve on the copy
[11:00] <pitti> nice
[11:00] <pitti> done: https://launchpad.net/ubuntu/+source/pkg-create-dbgsym/+publishinghistory
[11:01] <pitti> now only the wobbly walrus task is open
[11:01] <pitti> *nnnng* name!
[11:02] <cjwatson> and we can make sure to copy that before anything else once we open
[11:02] <pitti> don't we want to copy everything from vivid-updates anyway?
[11:02] <cjwatson> indeed, we just don't necessarily do that first
[11:11] <cjwatson> wgrant: We have the fixed pkg-create-dbgsym everywhere except *-RELEASE and lucid now.  Can you switch ddebs back on?
[11:12] <wgrant> yep, will do when i'm back from lunch
[11:12] <wgrant> hopefully with a certain word
[11:12] <shadeslayer> LocutusOfBorg1: yeah, that's what I meant
[11:28] <pragomer> In this tutorial they say that language-selection could not be preseeded and has to added to kernel options.
[11:28] <pragomer> https://help.ubuntu.com/community/InstallCDCustomization/PreseedExamples
[11:28] <pragomer> in what file do I add that?
[11:48] <slangasek> pitti: the answer is yes, and I've copied them to the security pocket per wgrant
[11:49] <slangasek> pitti: or possibly you did it before I got to it ;)
[12:28] <pitti> slangasek: right, see my conversation with cjwatson 1.5 hours ago; should be all good now
[12:52] <apw> pitti, yo ... could this failure be you ?  https://launchpadlibrarian.net/205206558/buildlog_ubuntu-vivid-ppc64el.linux_3.19.0-16.16_BUILDING.txt.gz
[12:53] <pitti> apw: ah, it is
[12:54] <pitti> apw: we introduced a new dh_gencontrol wrapper for dbgsyms for bug 1448247, and it seems that interferes with the manual dbgsym creation in the kernel, argh
[12:55] <apw> pitti, yeah we don't have version skew as far as i know, but ... indeed ... blamo
[12:55] <pitti> apw: is that some PPA?
[12:56] <apw> pitti, yep, the canonical-kernel-team/ubuntu/ppa
[12:57] <wgrant> Oh, hm.
[12:57] <wgrant> Maybe this will break anything that uses dh_strip -p but a non-specific dh_gencontrol?
[12:58] <pitti> apw: filed as bug 1450464
[12:58] <pitti> wgrant: no, pretty special to the kernel package
[12:59] <pitti> as that creates -dbgsyms entirely by itself; so it seems at that point the -dbgsym package dir exists, but not its DEBIAN/control
[12:59] <wgrant> h, right.
[12:59] <pitti> which is a bit odd *after* you call dh_gencontrol
[12:59] <pitti> but I figure the -dbgsym isn't in debian/control
[13:00] <wgrant> IIRC they are, but they are built as debs then renamed to ddebs later.
[13:00] <wgrant> But the rename only happens when the ddeb flag is enabled in LP, IIRC.
[13:03]  * pitti goes to fix
[13:04] <pitti> I think I'll let dh_strip place a marker into DEBIAN/, and dh_gencontrol will only process the package if that marker exists
[13:04] <pitti> that seems safest
[13:04] <pitti> that way, if someone else creates a -dbgsym/ our dh_gencontrol won't touch it
[13:04] <wgrant> Yeah, that sounds reasonable.
[13:07] <henrix> pitti: so, if i understood correctly, once that fix is done, i can simply hit the 'retry' button and the kernel should build ok
[13:07] <pitti> henrix: right; I'll test it in https://launchpad.net/~ubuntu-core-dev/+archive/ubuntu/ddeb-test before
[13:08] <henrix> pitti: awesome, thanks!  do you have an ETA for having that fixed?
[13:08] <pitti> henrix: probably best to subscribe to that bug, then you'll know exactly when what happens?
[13:08] <henrix> pitti: ack, will do
[13:08] <pitti> henrix: shouldn't take more than an hour or two for creating a test and the fix, then rebuilding the kernel
[13:09] <henrix> pitti: ok, cool
[13:09] <pitti> henrix: but landing it everywhere might take until Monday, I'm afraid
[13:09] <pitti> henrix: until then, you can of course copy the fixed mangler into the kernel PPA
[13:09] <cjwatson> pitti: why so long?
[13:09] <cjwatson> this seems like it can be a pretty quick test job
[13:09] <pitti> the kernel takes a while to build, doesn't it?
[13:10] <cjwatson> yeah, but would be ready by tomorrow
[13:10] <cjwatson> and I really want new ddebs switched on for W opening
[13:10] <pitti> yeah
[13:10] <pitti> well, let me do that fix first
[13:10] <cjwatson> and TBH an x86 kernel isn't going to take *that* long
[13:10] <pitti> I'll try to get online tomorrow for some time, but we have some things planned
[13:12] <cjwatson> pitti: can William and I sort it out if it looks plausible?
[13:12] <pitti> of course
[13:12] <pitti> it's mostly the SRU/verification mechanics at that point
[13:14] <pitti> cjwatson: anyway, this doesn't block the ddeb flag in LP, does it?
[13:15] <pitti> cjwatson: seems the kernel build will break either way
[13:15] <cjwatson> pitti: I guess that's true, so wgrant could turn that on any time
[13:15] <pitti> *nod*
[13:16] <doko> jamespage, are the openstack packages for 14.04 already compatible with python 2.7.9?
[13:24] <pitti> ok, reproduced with a simple test case
[13:26] <wgrant> Right, given this dseems under control and irrelevant, I might flip it all back on and watch for fireworks.
[13:35] <wgrant> cjwatson: (not enabling it on the silos until the next LP ndt, since the API to make it less arduous is in the rev after what's on prod now)
[13:56] <pitti> wgrant: btw, I cleared https://launchpad.net/~ubuntu-core-dev/+archive/ubuntu/ddeb-test/+packages about an hour ago, but it still says "1.9 GiB (95.91%) of 2.0 GiB"
[13:57] <pitti> wgrant: can I still build a kernel there, or will that fail with ENOSPC or so?
[13:58] <cjwatson> wgrant: yup
[13:59] <cjwatson> pitti: probably waiting for garbage collection; I've doubled its quota
[13:59] <pitti> thanks
[13:59] <pitti> hm, where did my dput to the PPA go..
[13:59] <pitti> henrix, cjwatson, wgrant: test case and fix are in bzr, uploaded to PPA; once it appears and is published I'll copy the kernel there for a test-build
[14:00] <henrix> pitti: great, thanks
[14:02] <pitti> wgrant: hm, might I have broken something by deleting all the packages and uploading ../pkg-create-dbgsym_0.66pitti1_source.changes ? it's a newer version than what I had before, but so far I neither got an accept nor reject
[14:02] <pitti> and it's been 7 minutes now, it usually appears in one minute or so
[14:03] <pitti> ah, and of course there it is, sorry for the noise
[14:28] <pitti> cjwatson, wgrant, henrix: trusty/utopic/vivid SRUs uploaded, vivid kernel building in PPA; the precise backport still causes some trouble, I'll look after that later; I need to run out for a bit for some errands
[14:32] <bdmurray> LocutusOfBorg1: I get the form emails as of recently and will sort out your accesss
[14:34] <bdmurray> LocutusOfBorg1: you should be able to access one of the crashes now, two of them OOPS and I'll look into that today
[14:34] <bdmurray> https://errors.ubuntu.com/problem/35bb694c581825f0eec62d1fcc38e7654941fbcb
[14:43] <LocutusOfBorg1> <3
[15:04] <LocutusOfBorg1> bdmurray,  Linux 3.19.0-031900-generic x86_64
[15:04] <LocutusOfBorg1> the users have a too new kernel that is preventing dkms from compiling
[15:05] <LocutusOfBorg1> so at least https://errors.ubuntu.com/oops/066b8ec0-ef3c-11e4-9f4b-fa163e4aaad4 is invalid
[15:25] <fginther> pitti, do you know why 'build-essential' is explicitly added to the trusty adt testbeds?
[15:26] <fginther> pitti, it is not added to utopic or vivid
[15:27] <fginther> jibel, perhaps you know? ^
[15:39] <infinity> fginther: Because it was there (unintentionally) during trusty development, so there are tests that depend on it, and making the testbed consistent with when the tests were written is easier/saner than auditing all the tests.
[15:40] <pitti> fginther: right, what infinity said; mostly for avoiding breaking trusty tests
[15:40] <fginther> infinity, thanks, that was what I needed to know
[15:41] <pitti> now a lot of them are broken for different reasons :/ but it did help for some at least
[15:41] <infinity> pitti: Where are we at with pkg-create-dbgsym blocking the kernel?  Should I just copy your -proposed uploads to the kernel PPA, so they can be unblocked while we validate?
[15:42] <pitti> infinity: I'm doing test builds in https://launchpad.net/~ubuntu-core-dev/+archive/ubuntu/ddeb-test/+packages
[15:42] <pitti> infinity: sure, we can copy it there, too
[15:42] <pitti> infinity: I haven't tested it with a full kernel yet, just with the small test case (but the error there was exactly the same)
[15:43] <infinity> pitti: Is there a worse potential failure mode than an FTBFS?  Cause I'm okay with burning CPU on a potential FTBFS, less keen on a broken build result.
[15:45] <pitti> infinity: can hardly get worse indeed
[15:51] <infinity> pitti: Okay, all accepted to -proposed.  As soon as the binaries publish, I'll copy to the ckt PPA and retry their failed builds.
[15:51] <pitti> infinity: precise is in the queue as well now (although I wouldn't mind waiting for the test build first -- you can copy p-c-d from my PPA to the kernel PPA rather?)
[15:51] <infinity> pitti: Too late. :P
[15:51] <pitti> ok :)
[18:27] <barry> doko, bdmurray check your email. i think i have the solution
[18:45] <bdmurray> barry: in that conversation, about python-pip, I'd asked about gathering better information with apport. Do you think getting the ~/.pip/pip.log would help? I just happened to run across a report with pip install httpie so got lucky there
[18:46] <barry> bdmurray: i don't think it necessarily helps.  i understand what's going on now.
[18:47] <bdmurray> barry: I don't mean with this specific situation, but generally for future python-pip issues.
[18:47] <barry> bdmurray: ah, in that case, i think it certainly couldn't hurt
[18:51] <bdmurray> barry: okay, and then are you good with overriding the regression since the same issue exists with the release version of python-pip?
[18:53] <barry> bdmurray: i think i don't understand what "override the regression" means.  does it just mean that the two errors will land in the same bucket?
[18:59] <bdmurray> barry: it means that the update of python-pip has stopped phasing and only reached 10% of users - http://people.canonical.com/~ubuntu-archive/phased-updates.html If we override the errors then it will start rephasing at 20%.
[19:00] <bdmurray> and might stop again if new errors are found
[19:00] <barry> bdmurray: then i'm tempted not to override yet.  i want to see what doko thinks about my proposed solution (make python-pip depend on python-pip-whl).  until that happens i think we'll just keep getting errors, albeit perhaps infrequently
[19:01] <bdmurray> barry: got it