[05:38] Good morning [06:07] * pitti checks planet again... [06:07] a name, a name, half a king's ransom for a name! [06:08] nothing in sight, dear sir [06:10] I like infinity's proposal of "wartier warthog" [06:12] pitti: I prefer wascally wabbit. [06:12] Or wascawy. [07:06] good morning [07:06] hi! Don't we have a name and archive for w yet? [07:08] diwic: no - not yet [07:11] elfy, ok...I wonder what's taking so long. [07:15] no idea - I'm not Mark ;) === ara is now known as Guest6469 [07:48] bdmurray, ping :) [07:48] I received a mail regarding a phased-update [07:48] but I can't login to see it [07:53] wgrant: ah, v-done \o/ [07:53] if anybody can pastebin to me this link https://errors.ubuntu.com/problem/35bb694c581825f0eec62d1fcc38e7654941fbcb [07:53] 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] I'll be grateful [07:53] also https://errors.ubuntu.com/problem/2ff630d95be5b0005424b6f887ba2fd88a4b4781 and https://errors.ubuntu.com/problem/7f00260fc0706bef5a73f0de8b5a91f3e9f5abd3 [07:55] pitti: Indeed, we should published to updates and security and then break lucid^W^Wenable ddebs. [07:55] RIP lucid, it's your last day of duty [07:55] :'( [07:55] no new gccs for lucid any more :) [07:55] Hard to believe we're killing off the third LTS already. [07:56] artigas is still going, though. [07:56] I don't think its final breath will make it. [07:56] I'm going to leave it going out of respect, though. [08:02] lucid ship with kernel 2.6.32, how old I feel [08:10] hi there :) [08:12] is the ubuntu kernel tweaked in any way which improves laptop battery life? === iulian is now known as Guest24409 [08:30] so nobody with access to errors.ubuntu.com? [08:32] LocutusOfBorg1, define access? the site works fine for me [08:33] I think you need to be in some team to get at the errors themselves [08:34] 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] hyperair: most things assume that dbus is always available, so probably not [09:26] dbus api supports gracefully reconnecting but probably this code path is poorly if ever tested in most software :P [09:31] hmm damnit [09:31] my dbus daemon is consuming 300MB of memory and i want to reclaim that RAM [09:40] slangasek: http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/jenkins_kvm/view/head:/should_build.py [09:52] 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] I got two mails from bdmurray bot regarding "Possible regression" [09:52] Suggest you fill out the form [09:52] I did it :) [09:53] then you'll be able to access these things yourself [09:53] nice [09:53] I don't know who receives those, hopefully shouldn't be long [09:53] ok, I was wondering about which kind of regression introduced the latest virtualbox update [09:53] I don't want to have a bad update in the archive [09:54] I hope somebody will enable me soon [09:59] 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] 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] pitti: We do need to copy it to -security, yes. [10:48] doko_: python 3.4 broken now :'( [10:51] shadeslayer, in debian is broken too [10:52] https://buildd.debian.org/status/fetch.php?pkg=virtualbox&arch=amd64&ver=4.3.26-dfsg-3&stamp=1430382229 [10:52] still getting build failures [10:53] pitti: Are we otherwise good to go? [10:54] cjwatson: thumbs up from my POV [10:55] pitti: Are you able to do the copy? Otherwise I believe I still can [10:55] cjwatson: yes, can do [10:57] how to set the default language of the ubuntu live cd at gfxboot menu? [10:57] put the language code in question in /isolinux/lang [10:58] 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] cjwatson: ah, it's in https://launchpad.net/ubuntu/vivid/+queue?queue_state=1, approving [10:59] ok, pending in vivid-security now, doing the others [10:59] pitti: you can use --auto-approve on the copy [11:00] nice [11:00] done: https://launchpad.net/ubuntu/+source/pkg-create-dbgsym/+publishinghistory [11:01] now only the wobbly walrus task is open [11:01] *nnnng* name! [11:02] and we can make sure to copy that before anything else once we open [11:02] don't we want to copy everything from vivid-updates anyway? [11:02] indeed, we just don't necessarily do that first [11:11] wgrant: We have the fixed pkg-create-dbgsym everywhere except *-RELEASE and lucid now. Can you switch ddebs back on? [11:12] yep, will do when i'm back from lunch [11:12] hopefully with a certain word [11:12] LocutusOfBorg1: yeah, that's what I meant [11:28] In this tutorial they say that language-selection could not be preseeded and has to added to kernel options. [11:28] https://help.ubuntu.com/community/InstallCDCustomization/PreseedExamples [11:28] in what file do I add that? === MacSlow is now known as MacSlow|lunch === doko_ is now known as doko [11:48] pitti: the answer is yes, and I've copied them to the security pocket per wgrant [11:49] pitti: or possibly you did it before I got to it ;) === soee_ is now known as soee [12:28] slangasek: right, see my conversation with cjwatson 1.5 hours ago; should be all good now === MacSlow|lunch is now known as MacSlow [12:52] 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] apw: ah, it is [12:54] 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:54] bug 1448247 in pkg-create-dbgsym (Ubuntu W-series) "pkg-create-dbgsym creates -dbgsym packages with the source version, not the binary version" [Critical,Fix committed] https://launchpad.net/bugs/1448247 [12:55] pitti, yeah we don't have version skew as far as i know, but ... indeed ... blamo [12:55] apw: is that some PPA? [12:56] pitti, yep, the canonical-kernel-team/ubuntu/ppa [12:57] Oh, hm. [12:57] Maybe this will break anything that uses dh_strip -p but a non-specific dh_gencontrol? [12:58] apw: filed as bug 1450464 [12:58] bug 1450464 in pkg-create-dbgsym (Ubuntu Vivid) "dh_gencontrol wrapper breaks kernel dbgsym generation" [High,In progress] https://launchpad.net/bugs/1450464 [12:58] wgrant: no, pretty special to the kernel package [12:59] 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] h, right. [12:59] which is a bit odd *after* you call dh_gencontrol [12:59] but I figure the -dbgsym isn't in debian/control [13:00] IIRC they are, but they are built as debs then renamed to ddebs later. [13:00] But the rename only happens when the ddeb flag is enabled in LP, IIRC. [13:03] * pitti goes to fix [13:04] 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] that seems safest [13:04] that way, if someone else creates a -dbgsym/ our dh_gencontrol won't touch it [13:04] Yeah, that sounds reasonable. [13:07] 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] henrix: right; I'll test it in https://launchpad.net/~ubuntu-core-dev/+archive/ubuntu/ddeb-test before [13:08] pitti: awesome, thanks! do you have an ETA for having that fixed? [13:08] henrix: probably best to subscribe to that bug, then you'll know exactly when what happens? [13:08] pitti: ack, will do [13:08] henrix: shouldn't take more than an hour or two for creating a test and the fix, then rebuilding the kernel [13:09] pitti: ok, cool [13:09] henrix: but landing it everywhere might take until Monday, I'm afraid [13:09] henrix: until then, you can of course copy the fixed mangler into the kernel PPA [13:09] pitti: why so long? [13:09] this seems like it can be a pretty quick test job [13:09] the kernel takes a while to build, doesn't it? [13:10] yeah, but would be ready by tomorrow [13:10] and I really want new ddebs switched on for W opening [13:10] yeah [13:10] well, let me do that fix first [13:10] and TBH an x86 kernel isn't going to take *that* long [13:10] I'll try to get online tomorrow for some time, but we have some things planned [13:12] pitti: can William and I sort it out if it looks plausible? [13:12] of course [13:12] it's mostly the SRU/verification mechanics at that point [13:14] cjwatson: anyway, this doesn't block the ddeb flag in LP, does it? [13:15] cjwatson: seems the kernel build will break either way [13:15] pitti: I guess that's true, so wgrant could turn that on any time [13:15] *nod* [13:16] jamespage, are the openstack packages for 14.04 already compatible with python 2.7.9? [13:24] ok, reproduced with a simple test case [13:26] Right, given this dseems under control and irrelevant, I might flip it all back on and watch for fireworks. [13:35] 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) === _salem is now known as salem_ [13:56] 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] wgrant: can I still build a kernel there, or will that fail with ENOSPC or so? [13:58] wgrant: yup [13:59] pitti: probably waiting for garbage collection; I've doubled its quota [13:59] thanks [13:59] hm, where did my dput to the PPA go.. [13:59] 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] pitti: great, thanks [14:02] 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] and it's been 7 minutes now, it usually appears in one minute or so [14:03] ah, and of course there it is, sorry for the noise === zyga is now known as zyga-afk [14:28] 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] LocutusOfBorg1: I get the form emails as of recently and will sort out your accesss [14:34] 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] https://errors.ubuntu.com/problem/35bb694c581825f0eec62d1fcc38e7654941fbcb [14:43] <3 [15:04] bdmurray, Linux 3.19.0-031900-generic x86_64 [15:04] the users have a too new kernel that is preventing dkms from compiling [15:05] so at least https://errors.ubuntu.com/oops/066b8ec0-ef3c-11e4-9f4b-fa163e4aaad4 is invalid [15:25] pitti, do you know why 'build-essential' is explicitly added to the trusty adt testbeds? [15:26] pitti, it is not added to utopic or vivid [15:27] jibel, perhaps you know? ^ [15:39] 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] fginther: right, what infinity said; mostly for avoiding breaking trusty tests [15:40] infinity, thanks, that was what I needed to know [15:41] now a lot of them are broken for different reasons :/ but it did help for some at least [15:41] 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] infinity: I'm doing test builds in https://launchpad.net/~ubuntu-core-dev/+archive/ubuntu/ddeb-test/+packages [15:42] infinity: sure, we can copy it there, too [15:42] 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] 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] infinity: can hardly get worse indeed [15:51] 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] 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] pitti: Too late. :P [15:51] ok :) === oSoMoN__ is now known as oSoMoN === zyga-afk is now known as zyga === stth is now known as stth_ === stth_ is now known as stth__ === stth__ is now known as stth === freeflying__ is now known as freeflying === ]reed[ is now known as [reed] === Malsasa is now known as Guest56336 === Malsasa_ is now known as Malsasa === davmor2_ is now known as davmor2 === salem_ is now known as _salem [18:27] doko, bdmurray check your email. i think i have the solution [18:45] 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] bdmurray: i don't think it necessarily helps. i understand what's going on now. [18:47] barry: I don't mean with this specific situation, but generally for future python-pip issues. [18:47] bdmurray: ah, in that case, i think it certainly couldn't hurt [18:51] 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] 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] 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] and might stop again if new errors are found [19:00] 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] barry: got it === fabo_ is now known as fabo === rsalveti_ is now known as rsalveti === _salem is now known as salem_ === \b is now known as benonsoftware === soee_ is now known as soee === salem_ is now known as _salem