[00:00] <RAOF> Wasn't there some flash-not-working-right with the new eglibc?
[00:02] <slangasek> yes, but that shouldn't hang the browser
[00:02] <slangasek> but the flash issue is one of the two fixed in -0ubuntu2
[00:03] <hrw> RAOF: ok, disabled all plugins
[00:05] <hrw> ok, not hangs now so far. just waiting for packets which got stuck in queue to this 33600 modem which whole conference is using
[00:06] <hrw> thanks
[00:08] <hrw> ok, was too optimisti ;( but ignore me - I lack mood to debug it - its too late in day
[00:09] <slangasek> hrw: just in case, please try upgrading libc6 when you have a chance (just published)
[00:10] <hrw> slangasek: I will
[00:12] <hrw> once will get there with elinks ;D
[00:13] <slangasek> heh
[00:26] <hrw> ok, ubuntu2 installed, reboot to get them reloaded
[00:30] <hrw> yay! much better
[03:33] <nigelb> I didn't expect a bourbon ping in this channel :)
[03:33] <nigelb> Problems of having that as a safe word ^-^
[05:56]  * pitti retries the webkit build which causes so much uninstallability; the i386 build hit -ENOMEM
[06:01]  * micahg hopes a rebuild helps
[06:16] <pitti> it's on a different buildd now
[06:16] <pitti> can only cross fingers
[06:16] <pitti> we really need a real staging area, such as -proposed
[06:17] <RAOF> I thought precise-proposed was already open, for exactly that reason?
[06:17] <pitti> yes, we just didn't start using it yet
[06:17] <pitti> everyone uses PPAs
[06:17] <RAOF> Yeah, I'm not entirely sure why :)
[06:18] <pitti> but we can't do binary copies from them
[06:18] <pitti> would be better to use precise-proposed, for new X.org, eglibc, gtk, glib etc. versions
[06:18] <pitti> I guess we just need to start trying
[06:18] <pitti> it's some extra overhead as they need to be hand-approved, but archive admins wouldn't actually need to read debdiffs
[06:23] <RAOF> We can do binary copies from (specially calibrated) PPAs, but you're right; they're not available to all.
[06:24] <RAOF> Is it trivial to auto-approve everything in precise-proposed until release?
[06:26] <broder> i wonder if my pre-release backports patch already covers this...
[06:26] <broder> let me look
[06:27] <broder> although i suspect you want s/release/archive freeze/ or something
[06:27] <ajmitch> broder: the one for opening up backports next week or so? :)
[06:27] <broder> yup!
[06:28] <ajmitch> what are the restrictions going to be on uploading new packages there?
[06:30] <broder> uh, i believe the plan approved by the TB was that all uploads would land in UNAPPROVED
[06:30] <broder> like they do now
[06:31] <broder> so that might not help RAOF's problem
[06:31] <broder> though i will note that currently it is not possible to upload to a non-RELEASE pocket if a release is not either frozen or stable
[06:31] <ajmitch> are pre-release uploads to backports likely to be copied to the main archive for q when it opens?
[06:31] <RAOF> Not really RAOF's problem; I'm a canonical employee, so can request a super-PPA that *can* be binary-copied from.
[06:32] <broder> heh, fine
[06:32] <broder> ajmitch: they *will* be copied to q. that's part of the rules
[06:32] <RAOF> But a problem in general, yes :)
[06:32] <ajmitch> broder: ah, excellent :)
[06:32] <broder> though "copy" may actually be "script bumping the version number and re-uploading"
[06:32] <ajmitch> either way, it's useful
[06:33] <broder> the approved plan also auto-files bugs against backports if a change to the release pocket should "supersede" a change in backports
[06:33] <broder> to tell us that we need to do a merge
[06:33] <ajmitch> it means less bugging the release team for FFEs for new packages
[06:33] <broder> right. in general, the intent is to remove some of the pressure for FFEs all aroudn
[06:33] <broder> or at least part of the intent
[06:34] <broder> https://lists.ubuntu.com/archives/technical-board/2011-November/001137.html is my post with the updated proposal based on TB feedback
[06:34] <broder> the stuff at the end of the e-mail is more interesting/relevant than the quote
[06:34] <ajmitch> thanks
[06:36] <broder> pitti: ^ fyi, when i was looking into the pre-release backports stuff, i discovered that you can only upload to a non-RELEASE pocket if the series status is FROZEN, CURRENT, or SUPPORTED, so we can't actually use -proposed right now
[06:36] <pitti> broder: oh, so that was it
[06:36] <pitti> because we did use devel-proposed in the last days of a release heavily, but at that time it was FROZEN
[06:37] <broder> yeah, i'm surprised we didn't notice it, though, since we've been using 0-day srus fairly heavily lately
[08:08] <dholbach> good morning
[08:25] <dholbach> It's Sponsorship Friday! :)
[08:25] <dholbach> @pilot in
[08:26] <seb128> @pilot in
[08:26]  * dholbach hugs seb128
[08:26] <dholbach> let's see how many pilots we can fit into the topic ;-)
[08:26] <seb128> dholbach, let's drive carefully, it's snowing out there ;-)
[08:27] <dholbach> haha
[09:08] <tjaalton> same here, haven't tried figuring out why
[09:10] <apw> presumably its s/w center that won't install, so it gets removed and to remove it we lose ubuntu-desktop
[09:10]  * apw will try and reinstall it shortly
[09:10]  * diwic runs upgrade instead of dist-upgrade today.
[09:11] <seb128_> could somebody reject https://code.launchpad.net/~tkluck/ubuntu/oneiric/gnome-shell/fix-bluetooth-device-switch/+merge/89040
[09:13] <apw>  libwebkitgtk-1.0-0 : Depends: libwebkitgtk-1.0-common (>= 1.7.5) but 1.7.4-0ubuntu1 is to be installed
[09:13] <seb128> apw, wait on the i386 build to success so the arch:all binaries are available, amd64 built first
[09:14] <apw> this new interdep between arches is just causing chaos
[09:14] <seb128> apw, it's not new?
[09:14] <seb128> it's there since ubuntu is there
[09:14] <seb128> but yeah, it's annoying
[09:17] <seb128> dholbach, can you set https://code.launchpad.net/~tkluck/ubuntu/oneiric/gnome-shell/fix-bluetooth-device-switch/+merge/89040 to merged or rejected or something?
[09:17] <seb128> dholbach, the fix got uploaded in a sru but I can't edit the merge request
[09:17] <dholbach> seb128, no, but I think pitti can
[09:18] <dholbach> and now fixing a bug from 2007-10-11, thanks Pojar George :)
[09:19] <seb128> dholbach, I hate how we can't edit those buggy merge requests ourself :-( do you know if anybody in launchpad is working on solving that issue?
[09:20] <dholbach> I think somebody is, but I forgot the bug number and stuff
[09:21] <seb128> dholbach, ok, don't bother
[09:21] <apw> seb128, the new multiarch dep between i386 and amd64 is new
[09:21] <apw> the randomly wanting to deinstall things is not new indeed, but we are triggering it in a whole lot of new ways now
[09:21] <seb128> apw, well in this case it's not multiarch, it's good all arch:all built on i386 and binaries depending on common = binary:Version
[09:22] <apw> ahh i see, my error
[09:22] <seb128> we should teach people to just use upgrade :p
[09:22] <apw> yeah except that doesn't work either
[09:22] <apw> in fact there is nothing safe one can do, pretty much ever
[09:22] <seb128> apw, well it will list those webkit binaries as on hold until they are built on i386
[09:22] <apw> and stupidly the most dangerous information is always off the top of ones screen
[09:23] <seb128> doing upgrade is a safe bet
[09:23] <seb128> then try dist-upgrade and see the few potential issues
[09:23] <seb128> upgrade at least helps to clear the one screen set of upgrade issues
[09:23] <apw> though you'll just end up with a hybrid pig over time
[09:23] <seb128> and let you with a small comprehensive set
[09:23] <apw> perhaps we should reorder the list, so removes are last
[09:23] <apw> then i might notice them :)
[09:23] <seb128> yeah
[09:24] <apw> or perhaps we could mark ubuntu-desktop in some way as 'ask them to type the alphabet backwards before allowing me to be deinstalled'
[09:24] <seb128> or we should make dist-upgrade do an upgrade first and show you the remaining part for confirmation then
[09:24] <apw> yeah, perhaps i'll alias it to that and see how that plays out
[09:25] <apw> how much less often i host my machine
[09:25] <apw> seb128, i thought the issue with using upgrade && dist-upgrade was that recommends arn't done for upgrades
[09:26] <apw> so you end up having to do like upgrade && dist-upgrade && install ubuntu-desktop^ to get a full install
[09:26] <seb128> oh, maybe
[09:26] <seb128> so screwed either way? ;-)
[09:26] <apw> that was kinda my point.  you do one and everyone tells you the other is the only safe one ... but clearly thats NP complete
[09:27] <dholbach> looking at mame now
[09:27]  * dholbach hugs jamespage
[09:28] <dholbach> jamespage, seb128: I wonder if we're going to set the record of most concurrent patch pilots today :)
[09:28] <seb128> ;-)
[09:28] <jamespage> **\o/**
[09:29] <seb128> cjwatson, on https://bugs.launchpad.net/ubuntu/+source/vim/+bug/856779 you wrote that you were going to sponsor to oneiric-proposed, it seems that didn't happen ... did you change your mind (i.e found a bug with the update) or was there an issue with the upload (i.e you forgot or it got rejected or something)
[09:31] <seb128> could somebody reject https://code.launchpad.net/~snicksie/ubuntu/oneiric/gdb/fix-for-typo-conjuction/+merge/86026 ?
[09:32] <seb128> could somebody set https://code.launchpad.net/~3v1n0/ubuntu/oneiric/bamf/libreoffice-fixes/+merge/85199 as merged?
[09:37] <seb128> looking to https://bugs.launchpad.net/ubuntu/+source/jackd2/+bug/911342
[09:37] <dholbach> looking at unity-mail
[09:46] <jamespage> looking at bacula lzo support
[09:47] <dholbach> can somebody please mark https://code.launchpad.net/~geoubuntu/ubuntu/precise/tvtime/tvtime-1.0.2-fix_fulscreen_crash/+merge/92027 as 'rejected'? pitti or cjwatson maybe? (explanation in last comment)
[09:47] <dholbach> ciao fabbione - auguri! :)
[09:49] <fabbione> dholbach: thanks dude :)
[09:49] <dholbach> taking a look at gedit-developer-plugins
[10:06] <jamespage> looking at nova
[10:07] <dholbach> WAH Launchpad DB offline
[10:09] <Daviey> jamespage: nova?
[10:09] <jamespage> Daviey: looked at - zul has it in hand!
[10:09] <jamespage> unsub'ed sponsors
[10:11] <Daviey> cool
[10:15] <jamespage> looking at dahdi-linux
[10:29] <jamespage> looking at celt upgrade - no action required from sponsors so unsubscribing.
[10:31] <cjwatson> apw: your query didn't get through, so I'm not sure what you were talking about :)
[10:32] <cjwatson> seb128: upgrade isn't intrinsically safe, BTW, because it means your system will forget about new Recommends that were introduced by the packages it did manage to upgrade
[10:33] <apw> cjwatson, does a subsequent apt-get install ubuntu-desktop^ fix the missing recommends ?
[10:33] <seb128> cjwatson, yeah, apw pointed that as well, I didn't notice that until today, thanks ;-)
[10:33] <cjwatson> dholbach: tvtime> done
[10:34] <seb128> cjwatson, can you do those as well?
[10:34] <seb128> could somebody reject https://code.launchpad.net/~snicksie/ubuntu/oneiric/gdb/fix-for-typo-conjuction/+merge/86026 ?
[10:34] <seb128> could somebody set https://code.launchpad.net/~3v1n0/ubuntu/oneiric/bamf/libreoffice-fixes/+merge/85199 as merged?
 dholbach, can you set https://code.launchpad.net/~tkluck/ubuntu/oneiric/gnome-shell/fix-bluetooth-device-switch/+merge/89040 to merged or rejected or something?
[10:34] <seb128>  
[10:35] <cjwatson> seb128: gdb, bamf> done
[10:35] <seb128> cjwatson, thanks ;-) oh and did my question gvim went through? I timeouted at some point
[10:35] <cjwatson> apw: provided that the only Recommends in question are within the ubuntu-desktop task, which is likely to cover some but not all
[10:36] <cjwatson> seb128: yeah, I was just paging through the easy stuff in scrollback before looking at the stuff I'd have to think about ...
[10:36] <seb128> cjwatson, ok, thanks ;-)
[10:36] <cjwatson> seb128: my mailbox says the vim upload was rejected without explanation
[10:36] <cjwatson> perhaps a mistake by somebody?  it should still be resurrectable from the REJECTED queue if somebody wants to ...
[10:36] <seb128> cjwatson, can you reject https://code.launchpad.net/~tkluck/ubuntu/oneiric/gnome-shell/fix-bluetooth-device-switch/+merge/89040 as well? thanks
[10:37] <cjwatson> a few ntfs-config uploads were rejected without explanation around the same time
[10:37] <apw> cjwatson, i had an overlapping apt-get update or similar break an inprogress dist-upgrade; this stopped the dist-upgrade dead in its tracks with a lock failure, but also left the system with 'E: Internal Error, No file name for libpam0g', install -f didn't fix it, i had to hand dpkg -i the file in /var/cache/apt/archive to recover
[10:37] <seb128> cjwatson, hum, did you get an accept,waiting in the queue and then rejected later? i.e it got rejected by somebody?
[10:37] <cjwatson> seb128: gnome-shell> done, though maybe you could leave a more detailed explanation in that case
[10:38] <seb128> cjwatson, doing so
[10:38] <cjwatson> apw: wacky, that should just have been impossible
[10:38] <cjwatson> seb128: accept/reject> no
[10:38] <cjwatson> just waited in the queue for a while and was then rejected
[10:38] <cjwatson> in retrospect I suspect that somebody fumble-fingered the web interface and didn't notice
[10:38] <cjwatson> it can be all too easy
[10:39] <seb128> right
[10:39] <apw> cjwatson, tjat was my feeling :/  still in case you see it agian, dpkg -i is your friend
[10:39] <seb128> do you still have the source? will you reupload?
[10:39] <cjwatson> seb128: LP still has it - it's in the rejected queue
[10:40] <cjwatson> pitti or RAOF could resurrect it from there
[10:40] <seb128> cjwatson, ok, thanks
[10:40] <seb128> I will check with them
[10:40] <cjwatson> https://launchpad.net/ubuntu/oneiric/+queue?queue_state=4&queue_text=
[10:47] <cjwatson> tjaalton: it is annoyingly slow; in that ~12h there's the delay of Debian publishing the package (unavoidable, IIRC up to 6 hours or so) and then a possible delay of up to 7 hours before LP notices.  https://bugs.launchpad.net/launchpad/+bug/812597
[10:48] <om26er> dholbach, Hey! can you please sponsor this https://code.launchpad.net/~om26er/ubuntu/oneiric/nux/sru-888039
[10:51] <tjaalton> cjwatson: yeah I was able to sync them maybe an hour ago
[10:51] <tjaalton> thanks for the bug, subscribed
[10:53] <seb128> dholbach, om26er: I can look at the nux sru
[10:54] <om26er> seb128, great, this https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz/sru-764330/+merge/92296 as well
[10:54] <om26er> both should improve the overall performance of oneiric
[10:54] <seb128> om26er, I'm less sure about this one
[10:54] <seb128> dvv had https://code.launchpad.net/~vanvugt/ubuntu/oneiric/compiz/fix-763005-oneiric/+merge/90254 in the queue before you
[10:55] <om26er> seb128, dvv handed me the patch since the initial patch created a regression
[10:55] <seb128> om26er, can you merge both, test if the update work and resubmit yours?
[10:55] <seb128> om26er, should we drop the one I just pointed then?
[10:56] <om26er> seb128, this branch seems to fix another bug,
[10:56] <om26er> seb128, should i merge his fix in as well?
[10:57] <seb128> om26er, I'm confused by you saying that his fix is buggy
[10:57] <seb128> is it buggy or not?
[10:57] <om26er> seb128, its not buggy, its fine
[10:58] <seb128> om26er, ok, can you include this one as well in your update? no need to do 2 different srus and wait  week between those
[10:58] <om26er> seb128, yes doing that now, thanks
[10:58] <seb128> om26er, thank you
[11:11] <Sweetshark> requesting jonos rockstar skills urgently for https://plus.google.com/u/0/115750270177636397262/posts/9fNFpwRW3XK
[11:29] <dholbach> jamespage, seb128: I'll take a break from Sponsorship Friday and leave a few items for others now :)
[11:30] <jamespage> dholbach, ack
[11:30] <dholbach> I'd still love to see the topic overflow :-P
[11:30] <seb128> dholbach, same here, lunch time
[11:30] <seb128> dholbach, what was the count when we started? we are to 48
[11:31] <dholbach> seb128, yesterday when I sent the reminder mail it was 66
[11:31] <seb128> dholbach, ok, progress, still some way to do but for a morning it's not bad ;-)
[11:31] <dholbach> in my notes I have 9
[11:31] <om26er> seb128, this https://code.launchpad.net/~om26er/ubuntu/oneiric/compiz/perf-sru/+merge/92444 :)
[11:31] <seb128> dholbach, enjoy your lunch!
[11:31] <dholbach> you too :)
[11:32] <seb128> om26er, thanks, did you test run it? maybe put it in a ppa for the w.e, I doubt any sru member will approve it before monday anway
[11:32] <seb128> om26er, I will upload it to the queue today but still would be good maybe to get a bit of extra testing meanwhile
[11:32] <om26er> seb128, I have tested the patches from his ppa, I am going to put it into my ppa and test these two patches
[11:33] <Laney> can someone make https://code.launchpad.net/~l3on/ubuntu/oneiric/pdf-presenter-console/sru-922752/+merge/90606 go away from the queue? dholbach nacked it
[11:34] <om26er> Wellark, Hi
[11:34] <seb128> cjwatson, ^
[11:34] <cjwatson> Laney: done
[11:35] <Laney> ty
[11:35] <om26er> Wellark, can you please look into bug 930088 and tell what info would be needed.
[11:37] <Laney> cleaned two items without doing any work ;-)
[12:27] <jml> how does one tell if a particular package is on the CD?
[12:30] <glenn> When a patch is supplied to debian upstream, what exactly are the steps to get it into the ubuntu package?
[12:34] <glenn> there is a bug on launchpad, and a patch in the debian branch of the package
[12:34] <cjwatson> jml: grep the .manifest and/or .list files alongside the CD images
[12:35] <jml> cjwatson: thanks.
[12:36] <cjwatson> glenn: has it actually been uploaded to Debian?
[12:37] <glenn> cjwatson: good question :)
[12:37] <cjwatson> or committed to a branch maintained by the Debian maintainer?
[12:38] <glenn> cjwatson: yeah the patch was supplied on github, and the maintainer put it in
[12:38] <cjwatson> maybe URLs would help :-)
[12:38] <glenn> its in the bug report :)
[12:38] <glenn> https://bugs.launchpad.net/ubuntu/+source/fail2ban/+bug/920995
[12:39] <cjwatson> so not yet uploaded to Debian
[12:39] <glenn> can i see that in the debian packages list?
[12:39] <cjwatson> http://packages.qa.debian.org/fail2ban
[12:40] <cjwatson> given that we aren't carrying any Ubuntu patches to fail2ban, I think the simplest answer is to wait for it to be uploaded to Debian, and then sync it
[12:40] <cjwatson> https://wiki.ubuntu.com/SyncRequestProcess
[12:40] <glenn> cjwatson: is the fail2ban package on ubuntu a complete debian copy ?
[12:40] <cjwatson> yes
[12:41] <cjwatson> this advice only applies to precise; if it needs to be fixed in stable releases too, then https://wiki.ubuntu.com/StableReleaseUpdates
[12:42] <glenn> cjwatson: well, the exit status wasnt complient to lsb init
[12:42] <cjwatson> I understand that it is a bug
[12:42] <glenn> cjwatson: yeah it is
[12:42] <glenn> cjwatson: my first fixed bug though :)
[12:43] <cjwatson> there are however many bugs that we cheerfully don't fix in stable releases; there is a higher threshold for making any change there
[12:43] <glenn> yeah im reading the link
[12:43] <cjwatson> in any case, I carefully didn't express any opinion about whether this one should be fixed in stable releases or not, because I haven't thought about it enough
[12:43] <cjwatson> but the links above should help
[12:44] <glenn> cjwatson: so you actually saw the bugs i created
[12:44] <cjwatson> well, only when you linked to it
[12:44] <glenn> ah ok
[12:44] <glenn> this is new to me so im trying to find out the workflow
[12:44] <cjwatson> I don't have any involvement with fail2ban
[12:44] <cjwatson> just offering general advice
[12:46] <glenn> cjwatson: the sablereleaseupdates dont mention anything about lsb compliance
[12:46] <glenn> +t
[12:47] <cjwatson> nor should they
[12:47] <cjwatson> the SRU guidance offers general advice on the kinds of things that are suitable for stable updates; its purpose isn't to enumerate all the things that might be considered severe enough
[12:47] <cjwatson> you're meant to apply judgement :-)
[12:48] <glenn> cjwatson: severe severe... i wouldnt call it severe.. was just bad init script coding :)
[12:48] <glenn> its a bug though
[12:48] <cjwatson> sure; most bugs I fix, I only fix in the development release
[12:49] <glenn> so precise?
[12:49] <glenn> or onerice
[12:49] <cjwatson> precise
[12:49] <glenn> k k
[12:49] <glenn> so you fixed the kernel bug to?
[12:49] <glenn> with 3.2.0-14
[12:49] <cjwatson> huh?
[12:49]  * cjwatson <- not a kernel hacker
[12:49] <glenn> im using preseed, and it didnt work for 5 days
[12:49] <glenn> after alpha2
[12:49] <glenn> nm then :)
[12:49] <cjwatson> the installer was broken for a few hours due to kernel ABI desync; not five days, I don't know what that's about
[12:50] <cjwatson> probably nothing to do with me :)
[12:50] <glenn> cjwatson: i had to wait the whole weekend before preseed could install linux-virtual
[12:50] <glenn> and some more days
[12:50] <glenn> it was failing on the wget with a weird error while it was on the repo's
[12:52] <glenn> but thanks for your answers regarding the package
[12:52] <glenn> :)
[12:58] <glenn> cjwatson: is it correct that if the package was uploaded to debian and the debianimport for precise wasnt frozen yet, it wouldt have been auto-synced? and becuase of that i would now have to make a sync request?
[13:02] <cjwatson> glenn: correct
[13:03] <glenn> cjwatson: thats pretty cool :)
[13:04] <jibel> sbeattie, could you look at bug 930115 . regression in lucid
[14:00] <seb128> grrrrrr
[14:00] <seb128> sorry guys
[14:00] <seb128> https://launchpadlibrarian.net/92511991/buildlog_ubuntu-precise-i386.webkit_1.7.5-0ubuntu1_FAILEDTOBUILD.txt.gz
[14:01] <seb128> "/usr/bin/ld: failed to set dynamic section sizes: Memory exhausted"
[14:01] <seb128> lamont, is there any way to get webkit i386 sent to build on a beefy builder?
[14:01] <seb128> we are going to have that amd64 installability issue for at least another 8 hours
[14:01] <seb128> since that build failed again
[14:02] <cjwatson> Does a sufficiently beefy builder exist?
[14:02] <lamont> what is the failure mode
[14:02] <lamont> doh
[14:02] <seb128> cjwatson, I don't know, what can we do if not? :-(
[14:02] <seb128> cjwatson, it built on amd64
[14:02] <cjwatson> Good question
[14:02] <cjwatson> We could perhaps assign an amd64 builder to i386 temporarily
[14:03] <cjwatson> Although I'd be surprised if there weren't already i386 builders in the same class
[14:03] <lamont> seb128: I'd like to see someone analyze it, but roseapple and allspice are both G6's with what should be plenty of RAM
[14:03] <glenn> cjwatson: the fail2ban package was just uploading to debian-unstable. could you show me an example requestsync commandliner for me on how to request a sync for it?
[14:03] <lamont> and swap
[14:03] <seb128> lamont, well my local built leaded to a ld using a bit over 3gb of ram
[14:03] <cjwatson> glenn: 'requestsync fail2ban precise'
[14:03] <lamont> penguins, antartic bases, elements, fruits, starnames.  later is better
[14:04] <lamont> seb128: file an RT about it mentioning RAM needs, and the builder that failed it?
[14:04] <seb128> lamont, if that helps...
[14:04] <cjwatson> so it requires PAE on i386, basically?
[14:05] <lamont> then get some buildd admin (webops?) to stuff the bunch on manual, score you through the roof, and automaticize allspice, and then the rest once it gets your package
[14:05] <seb128> I could also retry the build and see if I get lucky, but each retry takes some 8 hours and we have amd64 in uninstallable stable due to arch all,any mismatches
[14:05] <lamont> nice
[14:05] <seb128> lamont, so rt is the way to go?
[14:05] <seb128> sending one...
[14:05] <cjwatson> lamont: allspice is amd64 right now
[14:06] <lamont> roseapple
[14:06] <cjwatson> I can try it on roseapple now if there's a credible hope that it should succeed there
[14:06] <cjwatson> which builders has it failed on so far?
[14:06] <cjwatson> grr, just loading that build log has rendered firefox entirely unresponsive
[14:06] <lamont> cjwatson: roseapple or allspice should build it just fine, I expect
[14:07] <seb128> cjwatson, that built was vernadsky
[14:07] <seb128> let me see the previous one
[14:07] <lamont> I suspect that the "not-roseapple" i386 builders all have about 512MB of swap, and 2-4GB of RAM
[14:09] <lamont> seb128: and the ticket will be a dup of another one that says "review the RAM/SWAP on the builders and make it sane"
[14:09] <lamont> hints as to what amount of VM is "sane" are very much helpful in that process
[14:09] <seb128> cjwatson, I didn't keep the email from the previous build
[14:10] <cjwatson> ok
[14:10] <seb128> cjwatson, lamont: do we need a r-t or not?
[14:10] <cjwatson> just waiting for https://launchpad.net/ubuntu/+archive/test-rebuild-20120201/+build/3169749 to finish on roseapple
[14:10] <cjwatson> we should have an RT so that we don't have to fight with selecting the right builder in future
[14:10] <seb128> ok
[14:10] <lamont> seb128: not particularly for your rebuild, but yes, please file one about the memory footprint of webkit
[14:11] <lamont> mixed in with all that is the presumption that you've already asked yourself "is it sane that ld needs 3GB to link this beast?"
[14:11] <glenn> cjwatson: its telling me the versions are the same, but it was accepted in debian unstable with a newer version..
[14:11] <glenn> glenn: should i wait a bit?
[14:12] <cjwatson> seb128: try ld --no-keep-memory
[14:12] <lamont> -d unstable
[14:12] <glenn> mm
[14:12] <cjwatson> glenn: yes, you'll need to wait for a while
[14:12] <cjwatson> simplest to just make a note to try it tomorrow
[14:12] <glenn> lamont: tried that already, didnt help
[14:12] <glenn> cjwatson: thanks again
[14:12] <cjwatson> and yes, you will need -d unstable
[14:12] <cjwatson> but LP needs to have imported the package first
[14:13] <glenn> k k
[14:13] <lamont> ah.  that makes it make sense.  thanks cjwatson
[14:13] <glenn> how much hardware does a amd64 builder have?
[14:13] <lamont> about 2U
[14:13] <lamont> :)
[14:13] <cjwatson> seb128: possibly --reduce-memory-overheads too
[14:13] <lamont> glenn: they vary
[14:13]  * lamont -> town
[14:13] <glenn> who pays for it? :)
[14:13] <glenn> ubuntu?
[14:14] <cjwatson> Canonical
[14:14] <cjwatson> seb128: webkit building on roseapple now, build farm back on autuo
[14:14] <cjwatson> *auto
[14:15] <glenn> cjwatson: are you at the ubuntu office? or where is ur working spot
[14:15] <cjwatson> glenn: most Ubuntu developers work from home
[14:15] <cjwatson> including me
[14:15] <glenn> cjwatson: but your doing it for free right
[14:15] <cjwatson> No, I'm employed by Canonical
[14:15] <seb128> cjwatson, ok, thanks, I will have a look to --no-keep-memory and --reduce-memory-overheads
[14:16] <seb128> cjwatson, lamont: rt #50818
[14:17] <didrocks> hey, for speeding up the call for testing on compiz, is it possible to get a higher build score on those two builds: https://launchpad.net/~didrocks/+archive/ppa/+build/3201504 and https://launchpad.net/~didrocks/+archive/ppa/+build/3201498 ?
[14:20] <cjwatson> didrocks: done
[14:20] <didrocks> cjwatson: thanks :)
[14:26] <glenn> who would someone want to use a builder from canonical, and not your own pc?
[14:27] <cjwatson> Your own PC can't easily build packages for multiple architectures and publish them on ppa.launchpad.net for people to use conveniently
[14:30] <smoser> I wonder if someone here could give some quick advice.
[14:30] <smoser> bug 321091
[14:31] <smoser> if the user does not have mysql installed (apparently also true with postgresql) and types 'apt-get install bacula-director-mysql', then they'll also get mysql.
[14:31] <smoser> mysql will not be running at the time when bacula's db-config tries to populate mysql.
[14:32] <smoser> it would seem that "Pre-Depends" would satisfy this, but "You should not specify a Pre-Depends entry for a package before this has been discussed on the debian-devel mailing list"
[14:39] <smoser> cjwatson, i'm sure you can provide the right answer, so at your convienence, i'd appreciate it.
[14:59]  * ppisati -> reboot
[15:09] <slangasek> smoser: which maintainer script is db-config being called from?  if it's from the .config script, a pre-depends doesn't help at all
[15:11] <smoser>   dbc_go bacula-director-mysql $@
[15:11] <smoser> is in postinst
[15:11] <slangasek> smoser: *never* use pre-depends for something needed in the postinst - simple depends is always sufficient :)
[15:11] <smoser> wait. but also in .config
[15:12] <slangasek> right, so neither depends or pre-depends helps
[15:13] <smoser> slangasek, given the warning in the debian manual, i wasn't going to just shove it in there without testing..
[15:13] <smoser> so you have an idea on what would be correct there?
[15:13] <smoser> i'm mainly just curios. its been around for quite a while.
[15:13] <cjwatson> config *must* only use Essential packages and debconf
[15:15] <cjwatson> the config script seems to only use db-config if it's available, which is in principle ok
[15:16] <cjwatson> unless it also needs mysql to be available at *that* point; the bug report isn't terribly clear to me
[15:21] <slangasek> cjwatson: db-config-foo could be available at .config time without the database backend itself being available
[15:21] <cjwatson> right, I thought of that part-way through
[15:23] <cjwatson> the only suggestion I have is to check for db presence as well at config time, and make sure the config db_inputs are repeated in the postinst so that if they can't be preconfigured due to lack of database at preconfiguration time then the questions are at least asked when the postinst is run
[15:23] <cjwatson> there is no way to fix this using dependency relationships
[15:29] <smoser> cjwatson, slangasek gracias.
[15:40] <roadmr> kelemengabor: are you here?
[15:40] <kelemengabor> roadmr: yes
[15:40] <kelemengabor> feel free to ask :)
[15:41] <roadmr> kelemengabor: thanks! our package (checkbox) imported a bunch of .po files but they contain some commented, duplicate definitions at the end of the files
[15:41] <roadmr> kelemengabor: these are keeping it from building properly :( a quick fix is to delete all those entries (always at the end of the file)
[15:42] <roadmr> kelemengabor: I wanted to ask if that's OK, or if there's a better way to handle this
[15:42] <roadmr> kelemengabor: it looks like our PO files are wrong as described in LP bug 333281, but that is Fix Released so I'm not sure why we're getting those bad POs
[15:43] <kelemengabor> looking...
[15:43] <roadmr> thanks!
[15:43] <kelemengabor> which branch has this files?
[15:44] <roadmr> kelemengabor: https://code.launchpad.net/~roadmr/ubuntu/precise/checkbox/0.13.1-retry
[15:47] <dholbach> seb128, jamespage: still just the three of us? :)
[15:47] <kelemengabor> in general, the presence of such commented old strings should mean no problem, and LP keeps such in case they are reused sometime in the future. duplicates should not really happen, so this may be a toolchain bug
[15:48] <seb128> @pilot out
[15:48] <seb128> dholbach, no, just the 2 of you :p
[15:48] <roadmr> kelemengabor: so in principle it would be OK to remove them?
[15:48] <seb128> sorry I need to get some desktop stuff done ;-)
[15:48] <dholbach> bah
[15:48] <kelemengabor> roadmr: yes
[15:48] <roadmr> kelemengabor: I notice this doesn't happen with the checkbox trunk, so I'll look at the differences between the branches more closely, but if all else fails I'll delete them with confidence
[15:49] <roadmr> kelemengabor: thanks for your help!
[15:49] <jamespage> dholbach, hrm - yes - I have been a little sidetracked this afternoon as well
[15:49] <jamespage> managed to work through ~8 items this morning tho
[15:49] <dholbach> nice :)
[15:51] <slangasek> cjwatson: jhunt and I have a pty question for you :)
[15:52]  * cjwatson holds up a copy of Stevens as a makeshift shield
[15:53] <jhunt> cjwatson: looking at bug 922754, the question is whether we can
[15:53] <jhunt> rework the while loop in log_read_watch().
[15:54] <jhunt> If we only call this once a process has exited, even though the fd
[15:54] <jhunt> is non-blocking, EAGAIN/EWOULDBLOCK shouldn't occur right?
[15:55] <slangasek> cjwatson: my contention is that, if the process we care about has existed, and you receive EAGAIN on the pty, that's definitive that the fd was leaked and we should ignore it
[15:55] <slangasek> because if there's anything in the kernel buffer, the kernel would return it immediately instead of returning EAGAIN
[15:55] <cjwatson> hm, you may be right
[15:56] <jhunt> and if so, we could use this to display a warning if debug is
[15:56] <jhunt> enabled to state the app is not well-behaved or something.
[15:56] <cjwatson> it's possible that I was simply knee-jerking on read in a while loop -> check for EAGAIN
[15:56] <cjwatson> I think Steve's contention is correct
[15:57] <slangasek> also, s/existed/exited/
[15:58] <jhunt> thanks.
[15:58] <jhunt>  
[15:59]  * jhunt goes to watch the unit test firework display...
[16:12] <hallyn> hi all - bug 930181 appears to be another libc fallout (this time due to its headers)?
[16:28] <jhunt> slangasek, cjwatson: looks good so far - and yes, we can produce a
[16:28] <jhunt> warning if a service such as openssh leaks an fd when the associated job
[16:28] <jhunt> is stopped.
[16:36] <slangasek> jhunt: yay :)
[16:44] <didrocks> cjwatson: may I annoy you again for a priority bump on https://launchpad.net/~didrocks/+archive/ppa/+build/3202028 please?
[16:46] <slangasek> hallyn: probably linked to the eglibc update, but header changes like that are rarely accidental or erroneous; are you sure this isn't either a regression in linux-libc-dev (i.e., the kernel side), or simply a bug in qemu-kvm's include usage?
[16:49] <diwic> seb128, ping
[16:50] <seb128> diwic, pong
[16:50] <diwic> diwic, can you clarify that the decision to remove the login sound applied to the session-login sound (long jungle like sound) and not the system-ready sound (drums)?
[16:50] <diwic> seb128 even
[16:51] <seb128> diwic, I confirm that
[16:51] <seb128> diwic, I think the system ready sound was just never implemented in lightdm by lack of time,other priorities
[16:52] <diwic> seb128, thanks. So it seems like most people think we should have a system-ready sound but not a session-login sound
[16:52] <seb128> I would tend to agree with that
[16:52] <seb128> login sound is the annoying one
[16:52] <diwic> seb128, that just leaves the live-CD without sound
[16:52] <cjwatson> didrocks: sure, done
[16:52] <didrocks> cjwatson: thanks again :)
[16:52] <seb128> diwic, which is great ;-)
[16:52] <diwic> seb128, ...unless you're blind
[16:53] <seb128> diwic, well, we could turn on login sound on the liveCD easily
[16:53] <seb128> and for a11y installs
[16:53] <diwic> seb128, that could be something to consider at least
[16:53] <ev> jdstrand: still reading through it, but thank you massively for such a comprehensive review of whoopsie.
[16:54] <jdstrand> ev: you're welcome. I wanted to spend a good chunk of time on it which was hard to come by. sorry for the delay
[16:54] <ev> no worries at all
[16:57] <dholbach> @pilot out
[17:03] <hrw> side effect of updating eglibc - irssi session stopped resolving IPs. restart of irssi solved problem
[17:30] <slangasek> hrw: new upstream versions of eglibc frequently cause nss ABI changes, yes; there's no good way to force a restart of arbitrary user processes that might be affected, but the "you must reboot to finish the upgrade" flag should have been set
[17:32] <doko> slangasek, how is this set?
[17:34] <slangasek> doko: /usr/share/update-notifier/notify-reboot-required - which I see that libc6 doesn't touch, after all
[17:35] <slangasek> doko: so this would be a good thing to add, IMHO
[17:36] <doko> ok, I'll add this for upgrades to 2.15
[17:36]  * micahg also got warned about gdm on upgrade for glibc
[17:36] <micahg> ah, I see why, I have it installed, but it wasn't running
[17:49] <jamespage> @pilot out
[17:56] <slangasek> micahg: warned> blah, yes, that needs improving then
[17:57] <micahg> slangasek: want a bug?
[17:57] <slangasek> micahg: yeah
[17:59] <micahg> slangasek: bug 930304
[18:00] <quadrispro> micahg, here I am, still here
[18:01] <quadrispro> micahg, whay were you saying about old glew transitions?
[18:01] <quadrispro> s/whay/what/
[18:02] <micahg> quadrispro: we never finished the glew 1.6 transition and as such currently have glew1.5 and glew (1.6) in precise
[18:02] <quadrispro> yes, I understand
[18:03] <quadrispro> micahg, so you mean it had better to defer this to precise+1?
[18:07] <quadrispro> micahg, did you read my message?
[18:08] <micahg> quadrispro: well, not necessarily, but I'd just suggest taking whichever one is more stable, also as seb128 mentioned unity is prone to issues with glew migrations
[18:09] <micahg> and just keep in mind, there's more than just the glew rdepends
[18:11] <quadrispro> ok, let's wait for feedback/suggestions from ubuntu-release
[18:18] <seb128> cjwatson, still around?
[18:20] <micahg> seb128: as I mentioned in -desktop, webkit is still broke on i386 (failed due to symbols changing) which means dist-upgrades on amd64 are broke still
[18:20] <seb128> micahg, right, I'm doing another update and that's why I just pinged cjwatson
[18:20] <seb128> I will need the i386 build to go to the right builder
[18:20] <micahg> ah, ok, cool, thanks
[18:20] <seb128> since some builders run out of ram calling ld
[18:21] <seb128> he did it for me earlier but the build failed on a stupid .symbols cpp difference between archs
[18:21] <seb128> - _ZN7WebCore12TextIterator29getLocationAndLengthFromRangeEPNS_7ElementEPKNS_5RangeERmS6_@Base 1.7.4
[18:21] <seb128> + _ZN7WebCore12TextIterator29getLocationAndLengthFromRangeEPNS_7ElementEPKNS_5RangeERjS6_@Base 1.7.5-0ubuntu1
[18:21] <seb128> stupid cpp mangling :-(
[18:21] <micahg> ah, that's a per arch difference that existed already?
[18:22] <seb128> well I reverted a (regex) use by error but there is a new symbol added which had the same issue
[18:22] <seb128> I'm pondering just using -c1 instead of -c4 to be safe there, I don't want to fail another build
[18:22] <seb128> will do that
[18:23] <micahg> just don't forget to revert it for the next upstream release
[18:23] <cjwatson> seb128: have you uploaded it yet?
[18:23] <cjwatson> (dinnertime here, be quick :-) )
[18:23] <seb128> cjwatson, no, I wanted to talk to you
[18:24] <seb128> I've it ready, but I guess if I upload it will be too late to do your magic
[18:24] <cjwatson> I can switch to manual first
[18:24] <cjwatson> did you try the ld options I suggested?
[18:24] <seb128> cjwatson, not yet, webkit builds take over 6 hours on my box
[18:24] <cjwatson> ok
[18:25] <cjwatson> seb128: upload away and tell me when you've done so
[18:25] <seb128> but the build on the buildd would have worked
[18:25] <seb128> ok, on my way
[18:27] <seb128> cjwatson, uploaded
[18:31] <cjwatson> seb128: ok, it should build when the current build on roseapple completes
[18:31] <cjwatson> I have to go for dinner now, might be half an hour or so until I have time to re-auto the other buildds
[18:32] <glenn> enjoy ur dinner :)
[18:32] <glenn> im off too weekend
[18:32] <glenn> ciao
[18:33] <seb128> cjwatson, thanks a lot
[18:34] <seb128> micahg, <micahg> just don't forget to revert it for the next upstream release
[18:34] <hallyn> interesting - if i switch desktops at just the right time while 'debuild -S' is going, and gpg-agent is running, the pop-up asking my pwd apparently dies (without my seeing it) and debuild stops with bad passphrase
[18:35] <seb128> micahg, I did revert and update the .symbols in the vcs, I just don't want to risk getting it wrong again today
[18:35] <seb128> micahg, or we will keep the issue over the w.e
[18:35] <micahg> seb128: sounds good, thanks :)
[18:35] <seb128> yw
[18:37] <bdmurray> Where / how do I submit a change to lptools?
[18:37] <seb128> bdmurray, google says https://launchpad.net/lptools
[18:37] <seb128> bdmurray, ?
[18:38] <seb128> bdmurray, https://code.launchpad.net/~lptools/lptools/trunk
[18:38] <seb128> bdmurray, same way that for any other launchpad vcs I guess?
[18:38] <bdmurray> hmm debcheckout used something different
[18:41] <bkerensa> slangasek: Do you know much about what was causing the "Waiting 60 more seconds for network configuration" bug?
[18:41] <bdmurray> bkerensa: its a one time thing on first boot and is being looked at
[18:42] <slangasek> that one should already be fixed in the dailies
[18:42] <bkerensa> bdmurray: Hmm ok well it is hitting me everytime I boot in so not one time for me
[18:42] <bkerensa> :D
[18:42]  * slangasek sighs at bug #508083 having been marked "triaged", yet left assigned to the wrong package
[18:54] <bdmurray> slangasek: which term log did you look at?
[18:55] <slangasek> bdmurray: the one from jibel's autoupgrade test
[18:56] <slangasek> bdmurray: can you think of a good way to suppress reports of that particular crash if it happens in the middle of a release upgrade?  Or should we just make sure cron is stopped before unpacking libc6?
[18:56] <bdmurray> I'd think apport would report this as an apport-crash bug about cron so term.log wouldn't be available
[18:57]  * slangasek nods
[18:58] <slangasek> cjwatson: upgrade issue with libnih1 and libc6... libnih1 doesn't pre-depend on libc6, so the new libnih1 can be unpacked before the libc6 providing the symbols it requires... which will handily render init broken.  Should libnih1 pre-depend?
[19:04] <bdmurray> slangasek: looking at the crash file there might be some information that gives it away as happening during an upgrade.  DistroRelease is 12.04 but the kernel is 3.0.0
[19:24]  * lamont wonders what is STOMPING on resolv.conf with 127.0.0.1 for the nameserver
[19:25] <micahg> resolvconf?
[19:26] <lamont> possibly
[19:26] <lamont> bind9's RESOLVCONF=no
[19:28] <jdstrand> lamont: that would presumably be network manager's personal dnsmasq: https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns-resolving
[19:31] <cjwatson> slangasek: I think so, this is basically a case of (transitively-)Essential packages needing to promote Depends to Pre-Depends
[19:31] <cjwatson> which is something I've agreed with Santiago in the past as being necessary
[19:32] <slangasek> bdmurray: I don't think I'd like us to have to use kernel version and release version as a proxy for this, because that means we'd have to maintain that list in release-1 versions of apport
[19:32] <slangasek> cjwatson: ok - think I should go ahead with that change then?
[19:33] <lamont> jdstrand: bind9 has port 53 on the box.  it also doesn't want to be the resolver
[19:33] <bdmurray> slangasek: oh I'd thought of using a bug pattern but yes it'd need to be updated per release
[19:33] <cjwatson> slangasek: yeah
[19:34] <slangasek> bdmurray: bug pattern only blocks once they try to submit, yes?  Since this is "not actually a bug", I'd rather that users never got prompted
[19:35] <cjwatson> stopping cron during release upgrades sounds sensible ...
[19:35] <bdmurray> slangasek: that is correct
[19:35] <slangasek> bdmurray, cjwatson: right, I think stopping cron before unpack is probably the better way to go
[19:35] <cjwatson> (during the whole thing?  cron jobs might well be using arbitrary stuff that will be unconfigured for sizeable amounts of the duration)
[19:35] <jdstrand> lamont: aiui if you still have this in /etc/NetworkManager/NetworkManager.conf 'dns=dnsmasq', then resolvconf is in effect for dnsmasq via nm. you might want to comment out that option if you still have it
[19:36] <jdstrand> not sure if you need to restart nm, presumably so
[19:36] <lamont> jdstrand: ah ha!
[19:36] <lamont> so what do I want to set it to?
[19:37] <lamont> just comment, got it
[19:37] <slangasek> cjwatson: oh, technically, we've managed to make it so that runlevel is not part of transitive essential on Ubuntu, so hmm
[19:37] <jdstrand> lamont: comment it out: #dns=dnsmasq
[19:37] <lamont> and # for comments.  that answers the other
[19:37] <slangasek> can still do the pre-depends, but
[19:37] <slangasek> I think apt would be happier if something essential pre-depended on upstart
[19:37] <slangasek> (such as in the current debian-devel discussion)
[19:38] <slangasek> might need to have the pre-depends on a transitional basis for upgrades regardless
[19:38] <lamont> jdstrand: lrwxrwxrwx 1 root root 9 Feb 10 12:38 /usr/sbin/dnsmasq -> /bin/true
[19:38] <jdstrand> lamont: if not rebooting you might need to kill off the dnsmasq and maybe other stuff
[19:38] <lamont> nah, I fixed dnsmasq a while ago
[19:38] <jdstrand> heheh
[19:39] <cjwatson> slangasek: it's true that upstart isn't Essential, but I think that's kind of artificial
[19:40] <slangasek> lamont: so there's a bug in that NM, if it fails to launch dnsmasq on port 53 for whatever reason, should not then call resolvcon
[19:40] <slangasek> f
[19:40] <cjwatson> it caused too many problems when we tried; but the point of using Pre-Depends is to enable the "works even when unconfigured" property of Essential packages, and I think that upstart should behave as if it were Essential
[19:40] <lamont> slangasek: that saves me filing it
[19:40] <slangasek> lamont: I didn't say there was a bug report, I don't know if there is ;)
[19:41] <lamont> bah
[19:41] <lamont> I shall check
[19:41] <slangasek> lamont: I'm simply declaring that this is a bug, a conclusion that you seem to have already reached :-)
[19:41] <slangasek> cjwatson: well, I believe that if something Essential had a pre-depends on upstart, apt's rules about immediate configuration would have made libnih1's dependency a non-issue
[19:41] <slangasek> AIUI
[19:41] <lamont> I also need to reboot for the lastest stuff, and see if unity 3d is still unusable for me
[19:41] <cjwatson> I think it may only propagate that down one level
[19:42] <cjwatson> and it doesn't seem like something we should rely on for individual package correctness anyway
[19:44] <cjwatson> Incidentally, does unpacking the new libc break the old libnih?
[19:44] <slangasek> cjwatson: but, er, consider that libc6's preinst is trying to invoke the runlevel command
[19:44] <slangasek> which is not essential
[19:44] <slangasek> and not in a pre-dep of libc6
[19:44] <cjwatson> oh argh, I see
[19:44] <slangasek> so "correct"ness may vary
[19:45] <cjwatson> well, that means that runlevel must act as if it is essential, regardless of anything else
[19:45] <cjwatson> so any libraries it depends on have to use Pre-Depends, strictly
[19:45] <zanfur> sorry to intrude, just asking for directions -- where do I go for guidance in ubuntu packaging?
[19:46] <slangasek> heh, yes, unpacking the new libc does break libnih as well
[19:46] <slangasek> stupid GLIBC_PRIVATE
[19:46] <slangasek> but probably breaks it less than the converse
[19:48] <doko> hmm, I checked that the type of the used private symbol didn't change
[19:55] <slangasek> doko: probably not between oneiric and precise... what about from lucid to precise?
[19:56] <slangasek> well, it probably doesn't matter
[19:56] <slangasek> the symbol is only used when libnih aborts ;)
[19:56] <slangasek> so yes, unpacking libc6 first should be safe
[19:56] <lamont> I suppose I'll see if I can get dnsmasq and bind9 to coexist nicely on my machine
[19:57] <slangasek> lamont: does it matter? :)
[19:58] <slangasek> lamont: you have bind9 on 127.0.0.1, and you don't want it to be used as your resolver.  To actually care about dnsmasq being used makes you a corner case on a 6-dimensional hypercube
[20:15] <keyzs> unity is crap
[20:16] <keyzs> all lefty
[20:16] <keyzs> and for tv
[20:16] <keyzs> now i dont love ubuntu
[20:17] <keyzs> focus on user
[20:17] <keyzs> not on code gurus
[21:49] <tomreyn> hi, i'm looking at https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule and am trying to understand when the freeze is for debian imported packages to go into the "precise" stable release. since this table lists various sates for various freezes for various releases i'm having a hard time coming up with a definitive answer.
[21:49] <tomreyn> can one of you help me out?
[21:50] <broder> tomreyn: there are a couple stages of how we handle imports. we've already stopped automatically importing packages from debian testing (that's DebianImportFreeze), so any subsequent imports have to be manually requested - but still can be
[21:51] <broder> next week we hit FeatureFreeze, at which point imports either have to only fix bugs (not introduce features) or be approved by the release team
[21:52] <tomreyn> broder: i see "LTS DebianimportFreeze", is precise an LTS?
[21:52] <broder> yes
[21:52] <tomreyn> okay i wasn't aware
[21:53] <broder> we do LTS releases every 2 years in the spring (6.06, 8.04, 10.04, and now 12.04)
[21:54] <tomreyn> oh right
[21:54] <tomreyn> i remember there was some discussion that some release should have been LTS but wasn't in the end, but i forgot the details
[21:56] <tomreyn> broder: so when's the point where even requests for bugfix only updates (debian imports) will be denied?
[21:57] <tomreyn> is this UnseededUniverseFinalFreeze?
[21:57] <broder> depends on the package. for packages included on any of our CDs, we stop taking any updates at FinalFreeze except for critical bugs
[21:57] <broder> for packages in universe that aren't on CDs, yeah, UnseededUniverseFinalFreeze
[22:03] <tomreyn> thanks for your help
[22:07] <tomreyn> broder: actually i have another question related to this: so we released megaglest 3.6.0.3 (a bugfix) a few days ago, it's not in debian testing yet (but in sid, and should migrate to testing in 4 days). how do we request for it to be pulled into ubuntu for 12.04?
[22:07] <broder> tomreyn: use the requestsync script in ubuntu-dev-tools (available in both debian and ubuntu)
[22:08] <tomreyn> okay, are there limitations as to who can use it?
[22:08] <tomreyn> well i'll rtfm
[22:08] <broder> you just need a launchpad account
[22:08] <tomreyn> cool
[22:29] <bkerensa> slangasek: Do you know what "Source branch format does not support stacking, using format:
[22:29] <bkerensa>   Branch format 7
[22:29] <bkerensa> " means?
[22:32] <broder> can i get an ~ubuntu-branches member to change the status of https://code.launchpad.net/~jtaylor/ubuntu/oneiric/subversion/sasl-crash-881862/+merge/85228 to merged?
[22:37] <slangasek> bkerensa: the branch your branch is based from needs to have 'bzr upgrade' run
[22:38] <bkerensa> slangasek: I'm assuming whomever maintains that package would be the one to do that?
[22:39] <slangasek> bkerensa: what branch are you getting that error on?
[22:39] <bkerensa> slangasek: ubuntu-wallpapers
[22:39] <slangasek> bkerensa: what *branch*, not what package :)
[22:40] <slangasek> http://bazaar.launchpad.net/~ubuntu-art-pkg/ubuntu-wallpapers/ubuntu ?
[22:40] <bkerensa> slangasek: https://code.launchpad.net/~ubuntu-branches/ubuntu/precise/ubuntu-wallpapers/precise
[22:40] <slangasek> ok, let's have a look-see
[22:41] <bkerensa> I was proposing a merge to fix a bug
[22:41] <bkerensa> https://code.launchpad.net/~bkerensa/ubuntu/precise/ubuntu-wallpapers/fix-for-296538/+register-merge
[22:41] <slangasek> hmm
[22:41] <slangasek> Standalone tree (format: 2a)
[22:42] <slangasek> the target branch seems to have the right format
[22:42] <bkerensa> yeah it was saying something about that when I merged
[22:42] <slangasek> but maybe that's not the default stacking branch listed for the package
[22:43] <bkerensa> hmm
[22:45] <slangasek> yes, the associated upstream branch (lp:ubuntu-wallpapers) is an old format
[22:45] <bkerensa> ahh
[22:47] <slangasek> and I'm pretty sure that's a dead branch / team; I'll see about getting someone to upgrade the branch
[22:48] <bkerensa> ok
[22:55] <slangasek> bkerensa: were you able to successfully register the merge request, or did this issue block you?
[22:56] <bkerensa> slangasek: My merge request is registered
[22:57] <slangasek> ok
[22:57] <bkerensa> I will big dholbach to review it tonight
[22:57] <bkerensa> :D
[22:57] <slangasek> then you can safely ignore the message ;)
[22:57] <bkerensa> bug*
[23:04] <bdmurray> slangasek: do you have an opinion about blocking package install failures from persistent live media?
[23:23] <slangasek> bdmurray: I don't think so - how about if I adopt your opinion, whatever it is? :)
[23:35] <bryceh> bdmurray, sounds like a good idea to me
[23:36] <bdmurray> bryceh: right you worked on some weird issues in previous releases right?
[23:36] <bdmurray> I just can't decide if we are just hiding other issues though
[23:39] <bryceh> bdmurray, yeah related to nvidia driver installation failures
[23:41] <bryceh> that class of issue tended to hit things that required updating the boot loader when installing them
[23:41] <bryceh> I've not seen any similar issues lately the past two releases, so would guess the root problem got solved, but I don't actually know.
[23:42] <bdmurray> I believe that was fixed in casper
[23:42] <bryceh> bdmurray, do you see a lot of reports about persistent live media package install failures?
[23:43] <bdmurray> bryceh: that would be a good thing to know but its hard to find out
[23:45] <bdmurray> bryceh: you might need to check the dmesg attachment, I'm not certain the description has enough information