[02:42] ScottK, doko_: python-qt4 uploaded [03:07] skaet: sorry I wasn't responsive earlier.. I'm in CEST (UTC+2) right now [03:18] SpamapS, explains why i have to reach you at strange hours in my time :p [03:18] oops sorry, that was targetted for privmsg :P [03:18] * TheLordOfTime hates using irssi, it ignores basic commands. [04:59] slangasek: Thanks. [07:58] infinity: I'm doing a quick test of the lxc in quantal-proposed. If it's all looking good, are you fine with ignoring the 7 days limit and releasing to -updates today? [08:00] * stgraber builds a test container of lucid, oneiric, precise, quantal and raring on i386, amd64, armel and armhf. That should spot any remaining bug or regression in the lxc-ubuntu template [08:50] stgraber: I could be pursuaded. [09:40] I've arranged (if I didn't get it wrong) for pending-sru to stop listing migrations in the development series. People should not now be doing any of that by han. [09:40] *hand [09:40] It'll still list any cleanups that were missed by the automation. [09:44] infinity: tests passed fine on lxc, only current breakage is running the precise cloud image on quantal but according to the bug that'll be fixed next time utlemming spins an ubuntu cloud image [09:45] utlemming: if you're around, do you know when the new precise cloud image will land? The bug description says "That will be fixed by utlemming by Oct 25." [09:50] proposed-migration is now running automatically every time the archive updates [09:50] Output from most recent run (automatically updated): http://people.canonical.com/~ubuntu-archive/proposed-migration/ [09:51] Historical logs: lillypilly:~ubuntu-archive/proposed-migration/log/ [09:52] oh gosh, /this/ output [09:53] ;) [09:53] the RT in Debian sometimes mails pkg-haskell dumps of britney output [09:53] smile and nod [09:54] Heh [09:54] You get used to it [09:54] When slangasek and I joined as ajt's lieutenants, the boot-camp training involved interpreting britney output and doing whatever was necessary to make it work [09:55] Without actually being allowed to change the script [09:56] So eventually I think it just got embedded in our brains [09:57] It'll be more interesting once auto-sync starts [09:57] The output is boring at the moment =) [09:58] Hmm, glibc will take 5h+ to build on everything [09:58] So in theory, if jodh and infinity get everything uploaded in the next couple of hours, I can start auto-syncs just before my end of week [09:59] Maaaaybe. I have a few more iterations to go through here, probably. [09:59] Yeah. [09:59] (After yesterday's meeting, I'd been targetting tomorrow, not today, but I'll see where I go) [10:00] The LP database patch is being deployed at the moment, and I'm running some of the LP tests locally in parallel. [10:00] Also got a bit of a late start today that nearly turned into a sick day. [10:00] * infinity is feeling a bit rough. [10:01] The alternative is that I find out whether the Legoland hotel has good internet access while being climbed over by kids :-) [10:01] Ooo, Legoland! [10:01] (Which, to be fair, I was probably going to end up doing anyway ...) [10:03] cjwatson: I hear their internet access may be.... blocked... sorry, lame lego joke :) [10:03] sigh :) [10:05] Speaking of auto-syncs, is there a way to auto-sync haskell-* from experimental? [10:05] cjwatson, Laney: ^ [10:05] Not automatically (at the moment anyway) [10:06] Though in principle it's possible [10:06] Perhaps you could file a bug on ubuntu-archive-tools for that kind of thing? [10:08] Certainly, will do that. [10:08] Laney: Is that something you'd like to happen too? [10:09] Errrrrrrrrrrrrrrrr [10:09] I have heebie-jeebies [10:10] it's not unknown to upload a version of the compiler there for testing - would be quite terrible to auto-sync that [10:11] So, how will we get all the haskell goodies? [10:12] I'd be vaguely interested in having some scheme where we can auto-sync a nominated package list from experimental [10:12] Which perhaps ought to affect MoM as well [10:12] (It already looks at the sync-blacklist, so this isn't completely out of left field) [10:12] I'm not sure if you can know that a given package will always be safe to sync from experimental without being the sole maintainer [10:12] Of course it would be possible to track and manually sync them, too [10:12] for the haskell case, I'd say write a client script yourself [10:13] Which would allow a degree of sanity-checking [10:13] Yeah, I like the idea of being able to do this, I'm not sure it's sane for haskell. [10:13] * iulian nods. [10:21] jodh: Oh, too late now, but for the record, there's no point in having a "raring" task on bugs you're working on, as an upload to raring would have closed the generic distro task. [10:23] infinity: ah - right. wot no undo? :) [10:24] jodh: No need to undo it. You'll note the generic task just essentially goes away when you add one for the current devel release. [10:24] jodh: Which is a curiously odd way for it all to work out, but meh. Just pointing out you could have skipped that step (so you don't waste your time next time) [10:31] stgraber: So, I don't really want to release that lxc if it's going to break something else. Want to give me a solid nudge when you're sure that's no longer the case? [10:51] * infinity wonders how we haven't opened yet and already have an uninstallable. [10:52] Or, at least, an un-upgradeable. [10:52] (python-sip) [10:52] Uninstallable. [10:52] But it's in python-qt4. [10:52] According to raring_probs anyway [10:56] Oh, the new python-sip provides sip-api-9.0, while python-qt4 wants an older version. [10:56] Shiny. [10:57] ^-- Does that fix it? :P [10:57] Changelog implies that it will. [10:59] * infinity goes for lunch while Yet Another Test Build runs. [11:08] infinity/cjwatson: just pushed libnih_1.0.3-4ubuntu12 to raring. [11:11] jodh: thanks, reviewing [11:12] Let me throw that through a test build before you accept it. [11:13] Right. It looks OK. === doko_ is now known as doko [11:27] jodh: Shouldn't need the sed hackery in debian/rules anymore. And there's also some oddity with dpkg-gensymbols. Otherwise, looks like it's doing what we want. [11:31] * infinity accepts. [11:34] cjwatson: I thought you fixed -changes mails needing to be moderated? [11:34] (somehow) [11:34] * stgraber was just about to mention it [11:35] Not that doing it manually bugs me terribly, but... [11:35] * infinity eats his lunch instead of carin. [11:35] infinity: IS said they had fixed it [11:38] I'm so tempted to put "rarin'" in all my changelogs, and locally hack dpkg-genchanges to s/rarin'/raring/ for the .changes file. [11:40] Hahaha. [11:40] parsechangelog/debian: warning: debian/changelog(l328): found eof where expected first heading [11:40] parsechangelog/debian: error: fatal error occurred while parsing input [11:40] Maybe not. ;) [12:08] doko: do we need this gcc-4.7 to open? [12:10] cjwatson, what do you mean? no, we don't have to wait for the build to finish [12:10] That's what I mean [12:13] cjwatson: Would suck if we did need it, since it doesn't build. ;) [12:14] cjwatson: Oh, that was the previous version. [12:21] wow, I think it's the first time ever that I'll have all my merges done before the archive even opens ;) [12:22] * knome knocks the wood for stgraber [12:22] touchwood [12:22] stgraber: Good, then you can do mine too. ;) [12:22] but it wouldn't help with eglibc :-/ [12:25] infinity: you don't actually have that many but no, I don't want to end up touched-it-last on things like plymouth ;) [12:26] but I'll probably start stealing some once I'm done test building all of mine, not much else to do until UDS anyway [12:32] stgraber, https://launchpad.net/~ubuntu-rebuilds/+archive/py3.3/+builds?build_text=&build_state=failed (although talk with xnox which ones are already fixed in -proposed) [12:32] stgraber: to be honest most of them are done now =) [12:33] doko: stgraber: https://launchpad.net/~ubuntu-rebuilds/+archive/py3.3/+packages is a better view. [12:33] If it's not building and has a red cross, it needs fixing =) [12:34] mathjax, objgraph, shiboken are non-py3.3 specific build failures [12:34] good. I'll take a look at any remaining one once I'm done starting test builds of all my merges and fixing any failure resulting from the test build [12:35] I am unbreaking blender & morse-simulator as they hard-coded themself to 3.2 [12:48] Uh. Why the manual syncs of stuff that'll be auto-synced soon enough anyway? [12:48] Manual uploads, even! [12:49] Huh. Not in Debian yet. [12:49] I suspect he uploads to both simultaneously [12:49] but #-devel [12:49] But in incoming. [12:50] Exactamundo [12:54] ScottK: Hmm, ditto opendkim. Can't we sync that instead? [12:54] cjwatson: Could now. [12:54] Wouldn't be an autosync because it's in experimental, but still. [12:55] (And probably has less risk of knock-on uninstallability than gst*) [12:55] It's dealing with a security issue, so I wanted to get it in the hopper. [13:47] would someone please let whoopsie into proposed? This is a continuation of the changes from yesterday - I just forgot to include the InstallationMedia field. [13:47] It's a one-liner [13:55] ev: Tsk. [13:55] I know, I was so excited when I saw you let the updates in [13:55] and there was already data to play with in the database [13:55] then I noticed that particular field was missing [13:55] smashed my head on the desk a few times, appropriately [13:55] ev: Friends off. Never speaking to you again, etc. [13:55] yes, yes, absolutely [13:56] I'll avoid eye contact [14:14] infinity: looks like libnih is all built now [14:36] cjwatson: Yeah. I'm still back-and-forth with aurel and wookey on glibc, but I think the light at the end of the tunnel is growing. [14:37] * infinity has already cancelled his dinner plans tonight, in anticipation of this taking a while. [15:50] redirect-release-uploads now QAed and landed. I just need to find somebody to arrange a deployment ... [15:52] are we still looking at copies having to be re-done? [15:52] copies to -release [15:53] Laney: How do you mean? [15:53] cjwatson: You suggested before that people hold off on syncing as the redirection might not apply there [15:54] Copies to release will be forbidden (unless you're an archive admin or in ubuntu-release, but please don't); until we get round to updating syncpackage people will need to use -r raring-proposed [15:55] Let me see, I can perhaps do that at least in bzr now [15:56] I suspect it isn't worth rejecting and redoing the syncs already in the queue [15:56] Depends on if any of them look like the sort that could create inconsistencies. [15:57] I'd really like britney to be starting from a known-alrightish position. [15:58] I've committed a change to ubuntu-dev-tools bzr to have syncpackage default to -proposed. [15:59] infinity: Yeah - well, that was why I rejected gst* earlier [15:59] I'll do the same for glib2.0 and pcre3 [16:00] maas and fonts-baekmuk are probably fine [16:00] pidgin-libnotify too [16:00] maas is coped from the ubuntu archive (quantal => raring I guess). Any copy including binaries should be fine (not that it's easy to spot in the UI) [16:00] *copied [16:01] Ah, indeed [16:01] what's the plan for the other uploads currently targeting raring? do you have a way of redirecting them to -proposed post-upload or should they also be rejected and re-uploaded to -proposed? [16:03] Does the /ubuntu/raring poppy trick work for the main archive too, or just PPAs? [16:03] If so, we could wholesale yank them from the queue and reupload them without even having to mangle .changes and re-sign. [16:03] stgraber: I don't have a way to do that [16:03] Err, I guess /ubuntu/raring-proposed :P [16:04] Oh, well, yes, infinity's approach would I think technically work [16:04] Shouldn't be limited to PPAs [16:04] Well, or they could be yanked and reuploaded after your stuff is rolled out. [16:04] Then they'll redirect. [16:04] Also, a good test of the redirection in production. :P [16:05] Yes, very true [16:05] Excited. It's nearly all there! [16:05] though we don't have the signed .changes so we'll need to sign them again before uploading, making LP think whoever does that is the uploader (not that we really care I guess) [16:05] stgraber: It's not ideal. [16:06] We could go through them and see which ones might be problems. [16:07] Oh, we so have the signed changes. [16:07] Where? [16:08] Oh, there's that bug, isn't there ... [16:08] actually, no, I thought that replay attack got fixed [16:09] Oh, no. We only have the .changes if poppy has a sad about it. [16:10] Or I could just be looking at the wrong poppy. [16:11] anyway, from a quick look, the scary ones gdk-pixbuf, alsa-lib and gvfs are the ones I'd suspect may break things [16:11] (based from a very quick apt-cache showsrc on the queue entries) [16:12] So, yeah, we'd need to re-sign either way, so editing .changes or not doesn't make a difference. [16:12] But testing the redirection would be fancy. [16:13] We'll test it quick enough :) [16:13] I'm sure I can come up with a merge [16:13] I have a kmod upload to do. [16:14] I have a bunch ready for upload FWIW :) [16:14] Which is, ironically, being yanked from the quantal rejected queue. :P [16:18] * stgraber -> dinner [16:52] ldb, sssd, tevent and ding-libs in ubuntu-desktop?? that seems a bit weird considering I just added them to the edubuntu seeds. Wondering if the script somehow got confused [16:53] * stgraber starts a raring container to check === yofel_ is now known as yofel [19:24] doko: did you put foundations-r-buildds-usage on the list for re-discussion at UDS-R? [19:25] slangasek, yes, I did propose it [19:25] doko: it doesn't look like the whiteboard has changed; what needs to be rediscussed? [19:26] well, priorities for non-distro builds in times when the buildds are needed for distro [19:27] and resources ... I think armhf buildds, but that might not be necessary when armel gets dropped for raring [19:27] ohh, and temporary resources for test rebuilds for the whole archive [19:28] slangasek, ^^^ [19:28] ScottK: from what I can tell bug 1066892 should be fix committed for precise but can released to -updates for quantal. Does that sound right to you? [19:28] Launchpad bug 1066892 in kde-workspace (Ubuntu Precise) "initial power profiles do not use suspend support" [Critical,In progress] https://launchpad.net/bugs/1066892 [19:28] doko: ok, can you please update the whiteboard with the current set of topics and make sure the right people are subscribed to be able to talk about this? [19:29] what do you guys use to host you torrents of ubuntu [19:29] doko: I'm not sure if the right people are at UDS to let us make any forward progress on questions like non-distro builds [19:29] slangasek, ok, however I'm not sure who would be responsible for qt5-edgers [19:29] I'm fine if this sees some follow-ups in phone calls [19:29] doko: where is that one? I don't see that team name [19:30] doko: We keep getting more ARM buildds, it may not be an issue even without dropping armel. [19:30] infinity: we keep getting more ARM buildds that don't work :P [19:30] was it canonical-qt5-edgers? [19:30] slangasek: Only one of the recent ones doesn't work (and it should after a reinstall). [19:31] doko: tag Zoltan for that, please [19:31] ok [19:33] infinity: buildd capacity / contention has certainly been an ongoing issue regardless, so if we can realistically do some capacity planning I think it's worth having that conversation; I just don't want to have the conversation during UDS if we don't have the right people for it [19:35] slangasek: Oh, I'm not arguing that it's not worth better coordination. But yeah, we did this at UDS once, and it didn't seem to be all that useful, for the reason you state. [19:36] well, at least the resource planning with IS was done [19:36] bdmurray: Yes. [19:40] doko: we do now have an explicit document from Francis Lacoste saying that Ubuntu has priority for the distro build farm. I used this during release prep to drop the priority of the golang-tip builds. From my POV that part of it is a solved problem. [19:40] cjwatson, but you do have to do this per build? [19:41] besides dropping the builds or an entire architecture [19:42] doko: no, per PPA [19:43] slangasek, cjwatson: I don't insist on having a discussion at uds [19:43] now, that doesn't address the PPA build farm - we (explicitly?) don't have an automatic right to priority there [19:43] cjwatson: so to hear PES tell it, flacoste has also given them an SLA, resulting in a rather high overcommit ratio ;) [19:43] ok, so am I allowed to request a downgrade for times of a test rebuild? [19:43] slangasek: that's not what his document says [19:44] so we should make sure to invite PES to that session if we have it, too, in lieu of the phone call that didn't happen last week [19:44] realistically, commitments to all parties can probably only be met by more builders, anyway ... [19:44] doko: for the distro build farm, afaik yes [19:44] cjwatson: right, it may not be in *that* document, but PES believes they were given one ;) [19:44] so we ought to make an effort to sort this out, and UDS is probably as good a time as any to do so [19:45] ok, agreed [19:45] Francis will be there, won't he? [19:45] slangasek, so who to add for PES? [19:45] doko: Tim Chavez and smagoun please [19:45] when I release kde-workspace to quantal should I also use the -d switch as the raring version is less than the one that will go into quantal-updates? [19:46] bdmurray: yes [19:46] slangasek: thanks [20:09] could somebody merge https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/unsubscription-fix/+merge/131473? [20:10] bdmurray: Looking. [20:12] bdmurray: iz done. [21:33] interesting ... [21:34] Unpacking python3-nose (from .../python3-nose_1.1.2-3ubuntu1_all.deb) ... [21:34] dpkg: error processing /var/cache/apt/archives/python3-nose_1.1.2-3ubuntu1_all.deb (--unpack): [21:34] trying to overwrite '/usr/bin/nosetests-python3.3', which is also in package python-nose 1.1.2-3ubuntu1 [21:34] dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) [21:34] Errors were encountered while processing: [21:34] /var/cache/apt/archives/python3-nose_1.1.2-3ubuntu1_all.deb [21:34] E: Sub-process /usr/bin/dpkg returned an error code (1) [21:34] apt-get failed. [21:56] doko: hmm... doesn't look good.