[01:10] <timob> bazaar.canonical.com
[01:10] <timob> how can I use launchpad bazaar repo behind a proxy?
[01:13] <lifeless> set http_proxy appropriately
[01:14] <timob> lifeless: but doesn't launchpad use the lp scheme?
[01:15] <lifeless> timob: sorry I don't know what you are asking
[02:36] <ari-tczew> please sponsor debdiffs for fakesyncs bug 512430
[03:22] <nigelb> if a package is in bzr in ubuntu, do we submit merge requests/bzr diffs or debdiffs
[03:23] <nigelb> package is gnome-media... main package
[03:26] <TheMuso> nigelb: Submitting bzr merge requests via code.launchpad.net is best.
[03:26] <TheMuso> nigelb: Because the those who work on the packages will receive the request.
[03:27] <nigelb> ah, thanks  :)
[03:28] <nigelb> should I update the changelog and such in this case?
[03:33] <TheMuso> nigelb: Yes, if you update the changelog, the debcommit command can help you fill out the commit log.
[03:34] <nigelb> okay, thanks again :)
[03:34] <TheMuso> You're welcome.
[03:50] <nigelb> okay, this package uses cdbs, I'm expected to create a cdbs patch too?
[03:51] <TheMuso> nigelb: Depends on what your changes are.
[03:51] <nigelb> just adding a patch that gnome upstream dev uploaded to fix a memory leak
[03:52] <TheMuso> nigelb: Right then you shouldn't need to touch anything cdbs related.
[03:53] <nigelb> TheMuso: just make the change and request a merge ?
[03:53] <TheMuso> nigelb: yes once you have committed and pushed back to launchpad.
[03:53] <nigelb> okay :)
[03:53] <nigelb> thanks again
[03:54] <TheMuso> np
[03:58] <nigelb> does the patch command have trouble with white space?
[03:58] <nigelb> I keep getting the error "patch unexpectedly ends in middle of line"
[04:17] <TheMuso> nigelb: You can tell patch to ignore whitespaces, but it sounds like you need to reformat the patch. Since the package uses cdbs, the cdbs-edit-patch command ifs your friend here.
[04:18] <nigelb> TheMuso: just edit the patch the normal cdbs way then?
[04:18] <TheMuso> nigelb: cdbs-edit-patch will put you into a new shell where you can patch/edit your changes. When you exit the shell, cdbs-edit-patch creates the patch for you.
[04:19] <nigelb> TheMuso: yea.  but I wanted to work out the way I can make minimum effort in case I run into a patch with a lot of changes
[04:19] <TheMuso> man cdbs-edit-patch for more info.
[07:00] <pitti> Good morning
[07:00] <pitti> kees: devicekit-disks> superseded by udisks, so should be  fine
[07:01] <mtx_init> hello sir
[07:01] <pitti> kees: Debian> mbiebl and I are co-maintaining both; Debian will get udisks soon as well; our udisks is merely a git snapshot from the Debian packaging branch
[07:02] <pitti> YokoZar: it should be on the default CD, right? we are currently struggling for CD space (7 MB overflown), need to figure that out first; can you please ping the MIR bug to ask for seeding it?
[07:03] <pitti> kees: mirror image symlinks> hmm; seems a matter of taste to me, and I rather don't like them, but *shrug*; did they say why they ought to be there?
[07:05] <kees> pitti: my understanding (upstream was a bit terse) is that the stuff in /dev/disk/by-id is literally everything that is a device, which includes the "internal" devices that devmapper/lvm use (i.e. they each have separate uuids, names, whatever).  but that filesystems are skipped because they're not sensible, I guess.
[07:05] <kees> pitti: I think lvm needs another environment variable from the kernel called "internal" or something, so that it's easy to ignore those devices, etc.
[07:09] <pitti> kees: well, it already identifies those devices (they are named _mimageN and _mlog)
[07:09] <pitti> so that's not hard
[07:09] <pitti> kees: but anyway, I'll update the test suite; thanks for investigating!
[07:44] <YokoZar> pitti: There's a way to trim it so there's no net loss in CD space if needed
[07:46] <pitti> superm1: thanks for fixing dell-recovery!
[08:13] <ttx> pitti: hey, what would be your take on bug 376388 (especially suggested sudo changes at last comment) ?
[08:24] <pitti> ttx: we won't make -H the default; it would break other use cases which rely on having the original $HOME, and general backwards compatibliity
[08:25] <ttx> pitti: that was my sentiment as well, changing well-known behavior to fix a specific use case doesn't seem warranted
[08:25] <ttx> pitti: could you comment on that effect to the bug (if not already done ?)
[08:26] <pitti> ttx: done
[08:26] <ttx> pitti: thx !
[08:28] <dholbach> good morning
[09:32] <jibel> mvo, hello
[09:32] <mvo> hey jibel
[09:32] <jibel> mvo, I fixed the column sorting issues in synaptic but have some question anyway
[09:33] <mvo> jibel: nice! did you put it in a bzr brnach? or as  a patch?
[09:33] <mvo> jibel: questions> sure, fire :)
[09:34] <jibel> mvo, in common/rpackagelister.cc do you remember why there is a call to qsSortByName and then stable_sort. It seems redundant ?
[09:34] <mvo> that is quite possible, let me check the source
[09:40] <mvo> jibel: oh, now I do - IIRC its to have the package names sorted inside e.g. the sections, otherwise it will sort by section only and the package names are more or less random
[09:43] <jibel> mvo, ok got it. question 2: bug 165181
[09:46] <jibel> in the sort function we call isSupported which calls isTrusted which queries the package cache, ... It's rather suboptimal.
[09:46] <mvo> jibel: oh, let me have a look
[09:47] <jibel> mvo, there is no easy fix. Don't you think we'd better disable the sort by "supported" column ?
[09:48] <mvo> jibel: hm, let me have a look
[09:50] <mvo> jibel: did you push the patch for #518509 already somewhere? I will ocmmit it right away :)
[09:52] <jibel> mvo, not yet. I was waiting for this discussion.
[09:53] <mvo> ok
[10:03] <mvo> jibel: let me do a bit of profiling to see if I can come up with a idea
[10:05] <wre> I have found a post http://ubuntuforums.org/showthread.php?p=8834757#post8834757  Maybe you know where to find an answer?
[10:36] <mvo> jibel: I updated the bug and added a prototipish idea
[10:43] <jibel> mvo, thanks, I will have a look at it.
[10:43] <mvo> thanks :)
[10:44] <jibel> mvo, finally I dropped the call to qsort and replaced it by stable_sort which is superior in performance. The interface is more responsive.
[10:44] <mvo> jibel: sweet
[10:44] <jibel> mvo, I commit the changes and let you review it.
[10:44] <jibel> mvo, one more thing
[10:44] <jibel> mvo, you owe me a beer
[10:44] <mvo> jibel: for tests like this i often use a quick and check "clock_t now = clock(); { code; } cerr << time << clock() - now << endl;
[10:44] <mvo> jibel: heh :)
[10:45] <mvo> jibel: (to see if/how much performance difference there is)
[10:45] <mvo> jibel: I will pay up gladly :)
[10:45] <sebner> mvo: thanks for taking care of the dpkg issue :)
[10:45] <mvo> sebner: cheers, but cjwatson was quicker already it seems
[10:46] <sebner> mvo: really? He's a funny guy. Merging dpkg into lucid, then going on holidays and then doing the work nevertheless ^^
[10:48] <mvo> sebner: indeed :) and he enjoyed it!
[10:50] <sebner> mvo: ok, I'll make a test-upload to my PPA(?) and I'll let you know what going on?!
[10:50] <mvo> sebner: I'm not sure its deployed yet
[10:50] <sebner> oh, I'll wait some hours then
[10:51] <sebner> mvo: btw, you are fine that I sync your new scite package?
[10:51] <mvo> sebner: please
[10:51] <sebner> fine :)
[10:52] <mvo> sebner: I meant to write a sync request, but this is much quicker :)
[10:52] <wre> _I have found a post http://ubuntuforums.org/showthread.php?p=8834757#post8834757  Maybe you know where to find an answer?_
[10:52] <sebner> mvo: I did write one but Riddel was faster than incomming ^^, It's still stuck in there :( If it won't make it before FF I'll just make a manual upload
[10:59] <Keybuk> james_w: I keep finding new ways in which having source packages in bzr is awesome
[10:59] <Keybuk> today's
[10:59] <Keybuk> uncommitted/unuploaded changes in the working tree, when a new upload occurs
[10:59] <Keybuk> just bzr pull :)
[11:04] <james_w> \o/
[11:17] <ogra> seb128, so i just wondered why in my development apps all buttons dont have icons, then i found that we apparently dropped the UI to set /desktop/gnome/interface/buttons_have_icons from the appearance applet, how are users that have set that property in the past supposed to change it back ? shouldnt we apply the default when we disable them from setting such a property ?
[11:22] <seb128> why would they want to change it back?
[11:22] <seb128> if they did decide to set it this way
[11:22] <ogra> i wasnt even aware i had changed it, took me a while ... i had changed it when i used my laptop screen instead of the external monitor, to save screen space on the small LCD
[11:23] <seb128> well we default to not having icons now
[11:23] <ogra> its something *i* decide on a usecase base (no idea if others set it because they like it or something)
[11:23] <seb128> so you do have the default
[11:23] <ogra> on all buttons ?
[11:23] <seb128> yes
[11:23] <ogra> woah
[11:23] <seb128> buttons and menus
[11:24] <seb128> it's that way since karmic
[11:24] <ogra> my app menu surely has all icons here
[11:24] <seb128> waking up some 6 months after the change? ;-)
[11:24] <seb128> ogra, you don't use the default then
[11:24] <ogra> and usually cancel buttons have a red circle with a cross
[11:25] <ogra> hmm, i cant imagine to have changed anything apart from the buttons_have_icons when we still had it in appearance ... and only when i used my LCD
[11:25] <seb128> ogra, gconftool --unset /desktop/gnome/interface/buttons_have_icons
[11:25] <seb128> ogra, gconftool --unset /desktop/gnome/interface/buttons_have_icons /desktop/gnome/interface/menus_have_icons
[11:25] <seb128> ogra, that will give you default values for both
[11:26] <seb128> then run some GNOME app, ie gedit
[11:26] <ogra> my app menu still has icons
[11:26] <seb128> the gnome-panel one you mean?
[11:26] <ogra> ah, they are gone from system
[11:26] <ogra> yeah
[11:26] <seb128> only things supposed to have icons are objects
[11:26] <ogra> that makes the UI so much less exciting :P
[11:26] <seb128> the apps categories have been decided to keep icons
[11:27] <seb128> it was really looking weird without those
[11:27] <seb128> but look in an app, ie gedit
[11:27] <ogra> fine then, thanks for the help, i couldnt really imagine we drop icons from buttons
[11:27] <seb128> menus and buttons
[11:27] <seb128> ogra, talk to our design team ;-)
[11:27] <seb128> ogra, though to be fair GNOME did the change, design was just agreeing on it
[11:27] <ogra> i doubt i will convince them to change it back
[11:28] <seb128> no, you are 6 months late for that discussion
[11:28] <ogra> so i'd just waste my breath
[11:28] <ogra> i didnt see it changed
[11:28] <ogra> though the system was a fresh karmic install ...
[11:28] <seb128> you probably didn't do karmic desktop iso testing ;-)
[11:28] <ogra> and afaik the UI applet only applied to toolbars
[11:28] <seb128> ogra, you kept your user config though?
[11:29] <ogra> oh, right, i kept my homedir
[11:29] <seb128> ogra, the ui has both options, toolbar and buttons
[11:29] <ogra> ah, k
[11:29] <seb128> or menus and buttons rather
[11:29] <ogra> right, i remember menus and toolbars
[11:46] <didrocks> is there any documentation page about how ubiquity hook works (or a good example I can look at)?
[12:33] <ari-tczew> please sponsor debdiffs for fakesync [main] bug 512430
[12:49] <mdz> has anyone else seen bug 523176?
[12:49] <mdz> happened with kexec-tools
[12:49] <mdz> ah, /me finds bug 518853
[12:55] <pitti> Keybuk: thanks for the rsyslog upload
[12:55] <pitti> Keybuk: however, does that actually check for EPERM, and not drop privs in that case?
[12:55] <pitti> Keybuk: (otherwise rsyslog would stop working and spin the cpu 100% during upgrades, or when booting an older kernel)
[12:57] <Keybuk> pitti: we don't support booting an older kernel
[12:57] <Keybuk> you'll have bigger problems before you even *get* to rsyslog ;-)
[12:57] <pitti> Keybuk: but we will at least during dist-upgrade?
[12:57] <pitti> Keybuk: then perhaps we should not restart rsyslog during dist-upgrade then?
[12:58] <Keybuk> if there's a bug, we can fix that later
[12:59] <pitti> Keybuk: I booted 2.6.32-10 with that rsyslog configuration, and it just spins the CPU
[12:59] <Keybuk> pitti: feel free to fix it ;-)
[13:00] <pitti> yeah, might do after alpha-3
[13:00] <pitti> anyway, so now the charts should look better
[13:00] <pitti> Keybuk: devicekit-power is gone now as well, FYI (I uploaded a new indicator-session)
[13:00] <Keybuk> the dd won't exist for older kernels anyway?
[13:01] <Keybuk> so the bug is just that it spins rather than not logging kmsg
[13:01] <pitti> Keybuk: out of interest, do you alraedy know what's up with this setupcon/loadkeys/sh thing? or shall I take a look?
[13:01] <pitti> Keybuk: we have the dd process in karmic
[13:01] <Keybuk> pitti: yeah, have a patch I'm about to upload
[13:01] <Keybuk> pitti: we don't have the dd process if you've dist-upgraded ;)
[13:01] <pitti> Keybuk: it spins on EPERM, so it will just stop logging anything
[13:02] <Keybuk> right, the spin on EPERM is clearly a bug
[13:02] <pitti> Keybuk: why wouldn't we? it's started in karmic?
[13:02] <Keybuk> if you reboot into an older kernel, it won't be there, etc.
[13:02] <pitti> right, on lucid's rsyslog
[13:03] <Keybuk> lucid's rsyslog is the only one that'll spin
[13:05] <c_korn> can someone please enqueue scilab again ? build just takes a while. see the last comment. it took 6.5h on Debian: https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/511864
[13:33] <Laibsch> mvo: hello
[13:34] <Laibsch> @all: hello
[13:34] <Laibsch> mvo: I'm available for further testing of update-manager if you want
[13:34] <Laibsch> things are as they were yesterday
[14:11] <dholbach> rickspencer3, seb128, pitti: simple scan is seriously good stuff!
[14:11] <dholbach> just tested it :)
[14:15] <kirkland> cjwatson: hi there ... i have a eucalyptus sru upload for karmic-proposed ... could you accept for karmic-proposed?
[14:16] <seb128> dholbach, yeah, robert_ancell rocks
[14:16] <dholbach> now it just needs cropping and I'm all set :)
[14:19] <sebner> dholbach: thanks for the git-core ACK :)
[14:20] <Daviey> cjwatson: I want to use dh_apport, but it doesn't seem to be installed..  I'm running 1.12-0ubuntu5, but it doesn't seem to anywhere.  Am i being daft?
[14:22] <geser> Keybuk: does the most recent udev upload fix the current CHROOTWAIT build problems? "E: Could not perform immediate configuration on 'udev'.Please see man 5 apt.conf under APT::Immediate-Configure for details. (2)"
[14:24] <jdub> Keybuk: should #513919 (no /dev/null breaks mountall) fix booting without an initrd?
[14:24] <mathiaz> james_w: hi!
[14:25] <rickspencer3> dholbach, yes ... robert_ancell is impressive indeed!
[14:25] <mathiaz> james_w: could you kick an import of the puppet package in lucid?
[14:27] <seb128> Daviey, do you have dh-apport installed?
[14:28] <rickspencer3> mvo, thanks! you are the bestest!
[14:33] <mvo> rickspencer3: :) for XB-Softwarecenter-Appname: in debian/control ?
[14:33] <Daviey> seb128: I didn't realise it was a seperate binary package, *doh*
[14:33] <rickspencer3> mvo, I haven't even seen that yet!
[14:34] <rickspencer3> I was talking about "Featured"
[14:36] <pitti> dholbach: indeed, I love it
[14:37] <mvo> rickspencer3: thanks!
[14:53] <Keybuk> geser: I don't know what caused those chrootwait build problems
[14:53] <Keybuk> and no, but lamont apparently fixed the chroots
[14:53] <Keybuk> jdub: yes
[15:07] <jdub> Keybuk: bonus -- will test on my linode :)
[15:16] <jdub> Keybuk: woo, thanks for that fix!
[15:19] <Keybuk> jdub: I'm still not quite sure why it doesn't work of course
[15:19] <Keybuk> since if you're running 2.6.32 you have devtmpfs auto-mounted on /dev
[15:19] <Keybuk> and mountall will just reuse that
[15:19] <Keybuk> so you should never end up with no /dev/null
[15:20] <jdub> Keybuk: perhaps linode's kernel config?
[15:20] <Keybuk> jdub: possibly
[15:21] <Keybuk> smoser: I was meaning to ask you that at some point
[15:23] <smoser> Keybuk, its non-trivial for me to test now , as our kernels have devtmpfs :)
[15:23] <jdub> Keybuk: http://www.gnome.org/~jdub/2010/config-2.6.32-linode23.txt
[15:23] <smoser> i'd need to grab an old kernel, which would be possible.
[15:24] <Keybuk> smoser: right, I was trying to remember whether it was accurate that you'd forgotten devtmpfs
[15:24] <Keybuk> jdub: # CONFIG_DEVTMPFS is not set
[15:24] <Keybuk> jdub: FAIL
[15:25] <Keybuk> jdub: that kernel config deserves to be smothered with a pillow by some TV presenter nobody's ever heard of
[15:47] <micahg> are the amd64 lucid chroots broke?
[15:48] <micahg> nm
[15:52] <lamont> Keybuk: I went with the "can I reproduce it in a current chroot?  ... well then, trivial fix."  OTOH, do-release-upgrade may get to understand it in full detail
[15:53] <lamont> so why does my inspiron 1520 just plain not like to boot when the ipod is plugged into the USB port at boot?
[15:53] <lamont> stupid firmware
[15:53] <lamont> Keybuk: and I gave back everything in CHROOTWAIT on all 6 architectures
[15:54] <lamont> but not ppas
[15:54] <Keybuk> lamont: the question is why did they decide to break *today*?
[15:54] <Keybuk> there wasn't a new udev or anything
[15:57] <lamont> Keybuk: NEAT.
[15:57] <lamont> le sigh
[15:57] <lamont> I do have the old tarballs, if anyone wants them (for a few days anyway)
[16:07] <tseliot> slangasek, Keybuk: I think we might want to include these commits in our plymouth package: http://cgit.freedesktop.org/plymouth/commit/?id=8ccb7f17549c3a6e6199420cf90c8c0a2e1af666 and http://cgit.freedesktop.org/plymouth/commit/?id=33b761ebe04e032741966afdd4058b717e96b08a
[16:11] <geser> Keybuk: from the log I still had open I see a download of udev 151-3 in the upgrade part (and udev 151-3 was uploaded today by Sarvatt)
[16:11] <Keybuk> geser: ah ok
[16:13] <geser> Keybuk: therefore I first assumed that your upload of udev 151-4 (4 hours after the upload of -3) was meant to fix this
[16:13] <Keybuk> tseliot: I saw, I'm doing a plymouth update before alpha 3 anyway
[16:13] <Keybuk> geser: I don't know the cause
[16:14] <tseliot> Keybuk: me too, with the new theme and (hopefully) vga16fb support
[16:25] <slangasek> Keybuk: I think you probably missed my earlier ping regarding bug #518352 - architecture-wise, can you tell me what is *supposed* to be happening in this case?
[16:26] <Keybuk> plymouth is supposed to switch to vt7 and use a text plugin that keeps the screen black until passphrases are required, etc.
[16:27] <Keybuk> this isn't all quite right yet
[16:27] <slangasek> ok
[16:27] <Keybuk> we're basically not doing things architecturally the same way as RH
[16:27] <Keybuk> we always want plymouth running
[16:27] <Keybuk> and always want plymouth to have an active splash screen
[16:27] <Keybuk> at some point we just want to switch from that being a very plain text one to being a graphical one
[16:27] <Keybuk> (when we have the graphics driver)
[16:28] <Keybuk> either way, we should be always on vt7
[16:28] <slangasek> oh.  are you writing that code before FF? :)
[16:28] <Keybuk> no
[16:28] <Keybuk> it's a bug fix ;)
[16:29] <slangasek> heh
[16:29] <Keybuk> it's not so much writing code, but calling the code we have in the right order
[16:31] <slangasek> so plymouthd would automatically switch vt and blank screen on startup, and then look for a fb on --show-splash?
[16:31] <Keybuk> slangasek: don't really know yet
[16:31] <Keybuk> I think that's probably easiest and minimum effort
[16:31] <slangasek> "don't really know" - that makes me nervous wrt FF, then, given how many problems users are having with plymouth today
[16:31] <Keybuk> it's nothing to do with FF
[16:32] <Keybuk> plymouth was in ages ago, now we just fix bugs
[16:32] <cjwatson> kirkland: could you ask somebody not on holiday? :)
[16:33] <slangasek> it's the kind of bug fix that is likely to have knock-on effects, and I don't even understand the set of (critical) bugs that are already outstanding
[16:33] <kirkland> cjwatson: no problem
[16:33] <Keybuk> cjwatson: only if you actually go *on* holiday and stop reading IRC ;-)
[16:33] <kirkland> cjwatson: someone got to it already, though
[16:33] <Keybuk> slangasek: fortunately we have another alpha, and two betas yet
[16:33] <Keybuk> slangasek: so lots of testing
[16:33] <cjwatson> Keybuk: if I don't do Debian work when on holiday, I'm not sure when I'm supposed to do it ;-)
[16:35] <Keybuk> cjwatson: that sounds a lot like a modern Busman's Holiday
[16:35] <cjwatson> fear not, I have had plenty of non-computer time
[16:35] <cjwatson> not least due to some kind of bug confining me to bed all day yesterday
[16:36] <cjwatson> (holidays, eh?)
[16:36] <Keybuk> a Debian bug?
[16:36] <davmor2> debiflu
[16:36] <cjwatson> not unless they've learned how to jump the species barrier
[16:37] <Keybuk> slangasek: I'm not trying to work around the definition of Feature Freeze, btw.
[16:37] <Keybuk> I'm not saying plymouth isn't a bit buggy right now, but as a feature (and package) it is in
[16:37] <Keybuk> it's just a bit buggy
[16:38] <slangasek> Keybuk: right - it's just buggy to the point that I'm hearing half our own desktop team has removed it from their systems so they can get work done
[16:38] <Keybuk> that seems both in the letter *and* spirit of ff
[16:38] <Keybuk> slangasek: sure, but that's the case with anything critical
[16:38] <Keybuk> or anything run during boot
[16:38] <Keybuk> my minor bugs always have major impact to some people :p
[16:39] <Keybuk> unfortunately this means that all my specs and all my bugs end up OMGCRITICALZ!
[16:39] <Keybuk> which doesn't really help matters at all
[16:39] <slangasek> well, we can probably expect similar ratios for testers outside the desktop team... so they aren't going to be there to actually test the other fixes to plymouth if they've written plymouth off before that
[16:40] <slangasek> not that I have a solution for this - the solution would have to involve fixing the bugs which I can't reproduce
[16:40] <Keybuk> slangasek: so your saying I should only get two months to do all my feature development *and* bug fixing for any given release?
[16:40] <Keybuk> perhaps a boot feature freeze before UDS?
[16:41] <slangasek> no, I'm expressing concern about the current state of plymouth
[16:41] <Keybuk> (the same could be argued for anything the foundations team maintain)
[16:41] <Keybuk> the state is pretty good
[16:41] <Keybuk> there's a single bug
[16:41] <Keybuk> it's just a nice juicy one
[16:41] <Keybuk> (things end up on the wrong VT or inbetween VTs)
[16:42] <slangasek> what would "in between VTs" look like, and what's it caused by?  (to try to confirm that's what the flood of bugs I can't make sense of is about)
[16:43] <Keybuk> in between VTs would look like X drawing graphically on the VT
[16:43] <Keybuk> while input seems to go to the underlying kernel VC
[16:43] <Keybuk> and that input potentially crashing the X server
[16:44] <Keybuk> on the wrong VT would look very similar
[16:44] <Keybuk> except on the wrong VT, X would be very clearly on tty1
[16:44] <Keybuk> very clearly graphical
[16:44] <Keybuk> just that input is also going to getty
[16:44] <Keybuk> and when getty times out and respawns, it kills X
[16:44] <Keybuk> in between X looks like it's on VT7, and VT switching appears to confirm
[16:44] <Keybuk> but the text ends up on tty7 under X despite nothing else being on there
[16:45] <slangasek> ok
[16:45] <Keybuk> a VT switch away from X and back to X may often cure the in between problem
[16:45] <Keybuk> (or crash the X server :p)
[16:45] <apw> with lpia not being in lucid, do i need transitional packages for those off to something else (kernel wise) or will the installer magic things
[16:45] <Keybuk> it's all apw's fault really
[16:45] <Keybuk> since the kernel shouldn't ever let this happen <g>
[16:45] <slangasek> apw: "neither"?
[16:46] <pitti> kirkland: I did an SRU round earlier today, including euca
[16:46] <apw> Keybuk, hey thanks, i like being to blame, makes me feel powerful
[16:46] <kirkland> pitti: rocking, thank you!
[16:46] <Keybuk> slangasek: it would be a huge help if you could own any bugs related to things like cryptsetup, asking for input, etc.
[16:46] <apw> slangasek, so ... the user will find out from the release notes, and i don't need to care about transitions for it ?
[16:46] <Keybuk> I'll own the "plymouth kills kittens" ones
[16:47] <Keybuk> since I have all three major hardware here, and should be able to test
[16:47] <Keybuk> and know the problem very well anyway
[16:47] <slangasek> Keybuk: I can do that; are there any input bugs that are untriaged / unclaimed right now?
[16:47] <Keybuk> slangasek: I'm still ~600 bugs behind
[16:48] <slangasek> (I still feel some responsibility for "kills kittens", since I did upload that reintroduced it)
[16:48] <slangasek> ok
[16:48] <Keybuk> I haven't dedicated much effort to my bugs folder (other than clearing the easy ones) since it was before FF :p
[16:48] <slangasek> apw: must be, I think; there's no way to switch the whole install architecture
[16:48] <Keybuk> and I had a spec not yet at B/A
[16:48] <apw> slangasek, thanks ... makes my life pretty easy
[16:48] <slangasek> apw: so there's no point in having just the kernel try to handle transitions
[16:48] <apw> slangasek, figured as much, but nice to have it confirmed
[16:51] <sebner> mighty cjwatson (on holiday) .. mvo told me that you already took care of the dpkg backport?! At least uploading to my PPA doesn't work yet
[16:52] <ivoks> slangasek: have a minute?
[16:52] <slangasek> ivoks: sure
[16:52] <ivoks> slangasek: bug 315770
[16:53] <ivoks> slangasek: is there a reason why libio-socket-ssl-perl can't be in main?
[16:54] <ivoks> i can't tell from bug comment, other than it was discussed on irs
[16:54] <ivoks> irc
[16:54] <cjwatson> sebner: I mailed mvo+lamont a diff; it's not within my power to get it deployed
[16:54] <slangasek> ivoks: no, just the general principle that if we keep pulling everything into main without thinking about if it's really needed, we get everything in main and a burnt-out security team
[16:54] <cjwatson> sebner: I assume/hope that it's on lamont's to-do list somewhere, although I didn't actually test the diff ...
[16:54] <slangasek> (and my mirror gets fat, and I don't like that either)
[16:55] <slangasek> ivoks: why do you need it in main?
[16:55] <ivoks> slangasek: we are pushing new cluster stack in main
[16:55] <ivoks> slangasek: one of stonithd features uses perl ssl
[16:55] <sebner> cjwatson: oh, ok. thanks for the hint! You can attach it to the bug I made if you want too
[16:56] <ivoks> slangasek: i could check which one exactly and get back to you
[16:56] <cjwatson> sebner: if it isn't done by the time I get back from holiday, I will; otherwise I've done as much as I intend to do this week
[16:56] <ivoks> slangasek: so that we can discuss this fruther
[16:56] <apw> slangasek, can i assume you have a master todo list which includes something about lpia for the release notes or should i file a LP
[16:56] <bdrung> can a core-dev sponsor the hdparm merge (bug #516249). maybe dholbach?
[16:56] <cjwatson> sebner: it wouldn't particularly help anyone to have it attached anyway; lamont is the person who needs it
[16:56] <dholbach> bdrung: no time, sorry
[16:56] <slangasek> ivoks: no particular reason to discuss it with me, I'm not on the MIR team
[16:56] <ivoks> slangasek: ok
[16:56] <slangasek> apw: please file a bug on the ubuntu-release-notes project
[16:56] <apw> slangasek, ack
[16:56] <ivoks> slangasek: i just wanted to check if there was a special reason, thanks
[16:58] <sebner> cjwatson: aye, thanks again for your work!
[17:22] <apw> pitti there is something wierd about the two short bars in my burn-down chart (http://people.canonical.com/~pitti/workitems/canonical-kernel-team.html).  Note that the bar is red then green then red.  Its not at all clear that should be possible and i wonder at the veracity of the other bars as a result, are they overlapping more than they should perhaps?
[17:42] <ScottK> lamont: Still need testing on postfix 2.7?
[17:43] <lamont> ScottK: well, I have 2.7.0-1 ready to upload once I test it locally... you're welcome to bang on the ppa RC copy modulo known bugs there
[17:43] <lamont> planning to upload -1 today sometime
[17:44] <ScottK> lamont: OK.  I'll probably wait then (I'm dug out enough from last week to have a little time, but if it can wait, better)
[17:45] <lamont> cjwatson: dpkg 1.15.5.6ubuntu1 build-deps xz-utils, which build-deps libtool 2.2 (>> 1.5.26-1ubuntu1 in hardy).  NFW we're backporting libtool.... can haz patch without xz-utils depends?
[17:49] <Keybuk> cjwatson: I'm going out on a limb here, but have you broken man-db?
[17:49] <Keybuk> this could explain the recent udev failure
[17:49] <Keybuk> man-db bombed out of its trigger because the dpkg database was still locked (by, err, dpkg!)
[17:50] <mpt> tremolux, hi, how's Back+Forward going?
[17:51] <Keybuk> (it might be misblame, but it was the last thing to write to the console and got an update about the point things started breaking)
[17:51] <tremolux> mpt: howdy, it's in progress, have a branch at lp:~gary-lasker/software-center/back-forward-nav
[17:51] <mpt> cool
[17:51] <mpt> tremolux, do you have Back and Forward GtkActions that the buttons hook into?
[17:53] <tremolux> mpt: no, just handling the presses directly currently
[17:53] <mpt> tremolux, I'm asking because I was wondering how easy it would be to add equivalent menu items and keyboard shortcuts
[17:54] <tremolux> mpt: ah yes, it would be easier if I used GtkActions, indeed
[17:55] <mpt> tremolux, I guess that can be left until after Feature Freeze, though
[17:55] <tremolux> mpt: yes, it should be straightforward to convert to use them
[17:56] <mpt> okie dokie
[17:56] <tremolux> mpt: right now I have the nav history queues and management classes in place, and currently wiring in the actual navigations themself
[17:56] <tremolux> themselves
[17:56] <mpt> neat
[17:56] <mpt> I'll let you get on with it :-)
[17:57] <tremolux> mpt: alright, talk later  :)
[18:00] <lamont> cjwatson: so I built dpkg 1.15.5.6ubuntu1~0.CAT.8.04 without xz-utils, and dep: base-files (>= 4.0.0)
[18:00] <lamont> that actually was able to build itself
[18:00] <mpt> tremolux, <https://wiki.ubuntu.com/SoftwareCenter?action=diff&rev2=336&rev1=334> reflects what we discussed last Monday, i.e. that Back/Forward covers "Get Software" and individual software sources therein, but nothing outside that.
[18:00] <lamont> after installing
[18:01] <pitti> lamont: should we manually retry amd64 builds which got busted by this udev thing, or will you give them back wholesale?
[18:01] <seb128> lamont, the amd64 buildds are broken, known issue?
[18:01] <\sh> oh you know already about the amd64 buildds ;)
[18:01] <lamont> pitti: mass given back already, this would be the "so fresh chroots only fixed it temporarily" thing
[18:01] <seb128> pitti, I got a build failure 5 minutes ago, is that supposed to be fixed or not?
[18:01] <lamont> seb128: as of now, yeah
[18:01] <pitti> https://edge.launchpad.net/ubuntu/+source/gnome-user-share/2.28.2-4ubuntu2/+build/1513922
[18:02] <pitti> didn't catch this one then
[18:02] <tremolux> mpt: would you be terribly upset if the navigation is within the Get Software view only, for first cut?
[18:02] <pitti> nor totem
[18:02] <seb128> https://edge.launchpad.net/ubuntu/+source/libubuntuone/0.2.2-0ubuntu1/+build/1514198
[18:02] <mpt> tremolux, no
[18:02] <seb128> ^ nor this one
[18:02] <pitti> lamont: how difficult is it to do another mass give-back?
[18:03] <tremolux> mpt: as I dug into it, it became much harder to include the sources items in the scope of the nav history
[18:03] <lamont> mvo: you about?
[18:03] <Keybuk> pitti: amd64 has *rebusted*
[18:03] <lamont> pitti: without the fix? it's trivial and pointless
[18:03] <pitti> ah
[18:04] <seb128> should we retry builds or not?
[18:04] <Keybuk> I think we need mvo to understand why APT is refusing to continue
[18:05] <tremolux> mpt: it's not impossible and it shouldn't be terribly hard to expand the new nav history classes that I've added to do it
[18:05]  * sebner thinks lamont is quite the workhorse where :)
[18:05] <tremolux> mpt: but it added an extra level of complexity that I wanted to avoid for first cut
[18:06] <tremolux> mpt: to me, it seems most useful when navigating the many screens of Get Software
[18:06] <mpt> yeah
[18:07] <mpt> ok, I'll revert the changes I just linked to :-)
[18:07] <tremolux> mpt: oh, sorry
[18:07] <mpt> np
[18:07] <tremolux> mpt: don't lose them tho  ;)
[18:08] <tremolux> mpt: I should have pinged you about it early yesterday when I started to realize this, my bad
[18:09] <mpt> Reverted but not lost.
[18:09] <mpt> https://wiki.ubuntu.com/SoftwareCenter?action=diff&rev2=337&rev1=336
[18:15] <tremolux> mpt: actually, now that I look back at this, I'm a little confused by the (reverted) test case description - the test case includes navigation to the "Installed Software" section, but the section above (I thought) implies just tracking navigation within the "Get Software" screens
[18:16] <tremolux> mpt: my branch currently shows the nav buttons only when in the "Get Software" section, and tracks navigation within it only
[18:17] <pitti> Keybuk: do your bootcharting scripts have a hack for the wallpaper cache?
[18:18] <Keybuk> pitti: no
[18:18] <pitti> Keybuk: I just uploaded didrock's ubiquity hook to copy it from the live system, so if you have one, you can drop it
[18:18] <Keybuk> where possible, the boot chart scripts don't have any hacks
[18:18] <pitti> ah, good
[18:18] <Keybuk> ie. the point is to test the actual instal
[18:18] <mpt> tremolux, sorry, that was an error that I corrected at the same time as the changes, and then I reverted the correction. Re-fixed it now.
[18:18] <pitti> Keybuk: right, just wanted to make sure
[18:18] <Keybuk> the post-install scripts are all about adding things like the broadcom driver, bootchart, etc.
[18:20] <Keybuk> lamont: the only loop I can find in that tree is the old udev -> initramfs-tools -> udev one
[18:20] <Keybuk> which has been there since the DAWN OF TIME
[18:20] <Keybuk> and that's only a Depends not a Pre-Depends
[18:20] <mathiaz> Keybuk: pitti: I'm still confused about the MIR - should a wiki page be written or not?
[18:21] <mathiaz> kees: ^^
[18:21] <Keybuk> mathiaz: "the MIR" ?
[18:21] <Keybuk> lamont: http://launchpadlibrarian.net/39315255/buildlog_ubuntu-lucid-i386.upstart_0.6.5-2_CHROOTWAIT.txt.gz
[18:21] <mathiaz> Keybuk: sorry - completion to fast
[18:21] <Keybuk> i386 busted itself again
[18:21] <pitti> mathiaz: you don't need to any more, but if you want to, that's fine
[18:22] <mathiaz> pitti: the first point in the notes sections refers to the report - https://wiki.ubuntu.com/MainInclusionProcess
[18:22] <tremolux> mpt: ah great, thanks!
[18:22] <lamont> mvo: bzr pull lp:~lamont/launchpad-buildd/chroot-scripts/; chroot-scripts/make-chroot.sh -d lucid might be faster if you have a quick archive
[18:22] <lamont> s/pull/branch/
[18:22] <pitti> mathiaz: right, which describes exactly that it's not required any more :)
[18:22] <mathiaz> pitti: from someone *writting* a MIR request I still think it makes sense to write a wiki page
[18:23] <pitti> mathiaz: that was discussed on u-devel@ a while ago; as I said, if you think it's easier for you to write the wiki page, go ahead
[18:23] <mathiaz> pitti: ok - thanks
[18:24] <mvo> lamont: thanks, I have it now and can reporduce
[18:24] <mvo> reproduce even
[18:25] <Keybuk> mvo: the only loop I can find in the dep tree is the udev -> initramfs-tools -> udev one
[18:25] <Keybuk> but that's been there like, forever
[18:26] <mvo> Keybuk: thanks, I have not looked in details yet, just reproduced :)
[18:33] <pitti> crimsun, TheMuso`: JFYI, I committed a small change to pulseaudio bzr (so please pull before committing/uploading)
[18:34] <Keybuk> mvo: anyway, feel free to upload any fixes you need ;-)
[18:34]  * sebner is wondering why sparc now has chroot problems too
[18:35] <mvo> Keybuk: thanks, it seems to be the new mountall dependency on udev
[18:35] <mvo> well, that is causing it, next bit is to figure out how to fix it
[18:35] <Keybuk> mvo: why would that cause the problem
[18:36] <Keybuk> wouldn't this mean that *anything* depending on udev can cause the issue?
[18:37] <sladen> Keybuk: there's is a Pre-Depends loop with  openoffice.org-filter-binfilter -> openoffice.org-core  which breaks stuff
[18:38] <sladen> Keybuk: mvo: bug #516727 if you can work out how to fix that to allow smooth upgrades
[18:39] <mvo> Keybuk: sort of, the problem is that something essential pulled udev in now and apt like to do immediate configuration on this stuff. to minimize the risk of breakage. but this is one of the side-effects, that is sometimes is too eager and falls over
[18:40] <Keybuk> mvo: ah
[18:40] <Keybuk> feel free to drop that then
[18:40] <Keybuk> though mountall won't work without udev installed
[18:40] <Keybuk> (or configured, in fact)
[18:40] <superm1> kirkland, I think today's your archive admin day.. would you mind kicking mythtv out of binary new so that the other myth* packages can build again against it?
[18:41] <kirkland> superm1: done
[18:41] <mvo> Keybuk: thanks, I see what I can do (either by fiddling dependencies or hit apt with a hammer)
[18:42] <superm1> kirkland, thanks (and sorry for your frontend that you just upgraded :))
[18:42] <kirkland> superm1: :-P
[18:42] <kirkland> superm1: my wife is ready for mythtv normalcy again
[18:51] <mdeslaur> pitti: I've just uploaded a "security" symptom to apport-symptoms. Do you think we could get a new version uploaded before FF?
[18:56] <cjwatson> lamont: I think ditching the xz-utils build-dep would be OK
[18:58] <cjwatson> anyone have a build log for that man-db thing Keybuk was talking about?  I did sync a new upstream version of man-db, but I didn't change the trigger logic in any meaningful way AFAIK
[19:03] <kees> mvo: /win 13
[19:03] <kees> mvo: er, ping, about update-manager
[19:03] <kees> mvo: I'd like to add a small script to it, since it ships the bulk of the update-motd scripts.
[19:07] <mvo> kees: sure
[19:07] <mvo> kees: /win 12
[19:07] <ari-tczew> please upload 4 debdiffs for fake sync bug 512430 thanks
[19:07] <mvo> kees: feel free to commit directly if its trivial
[19:08] <mvo> kees: otherwise, just create a branch and I will merge
[19:09] <kees> mvo: okay, cool
[19:10] <juliank> mvo: Don't forget the python-apt upload, if you haven't done it already.
[19:15] <mvo> juliank: I'm working on it, I think its fully backward compatible now, but I want to do some further tests
[19:17] <juliank> mvo: Except for apt_pkg.Version which is a class now, it should be fully compatible. But I have not seen anyone complaining about apt_pkg.Version since it changed last summer.
[19:18] <ari-tczew> mvo: do you will fix problem with udev/pbuilder today before FF?
[19:18] <mvo> ari-tczew: the immediate-configure problem that the buidds have? or is that a different one?
[19:19] <juliank> cjwatson: You have been selected for receiving the first python-apt API transition bug, for germinate. It should come tommorow, with a patch.
[19:19] <mvo> juliank: right, its pretty good, when testing with the release upgrader I had some issues, it uses a lot of the p-apt code
[19:20] <mvo> I think they are fixed now
[19:20] <juliank> mvo: I tested gnome-app-install and software-center, and they worked (except on Debian kFreeBSD, but this is not relevant here)
[19:20] <ari-tczew> mvo: pbuilder @ E: Could not perform immediate configuration on 'udev'.Please see man 5 apt.conf under APT::Immediate-Configure for details. (2)
[19:20] <mvo> ari-tczew: yeah, I just uploaded a new util-linux that hopefully fixes it
[19:21] <mvo> juliank: ok, my next candidate is gdebi, but I'm pretty confident that this will work
[19:21] <juliank> mvo: Should I open bugs for the python-apt transition in Ubuntu as well and link them to the ones in the Debian BTS?
[19:21] <juliank> mvo: I believe I already used gdebi with the new python-apt.
[19:21] <mvo> (phone)
[19:38] <nixternal> how can I get lp:debian/experimental/koffice updated with what is in debian experimental? really don't want to have to do this big arse merge manually
[19:48] <leonardr> DktrKranz: i mentioned this to slangasek earlier, but the new launchpadlib is available for you to package at your convenience
[19:48] <leonardr> i'll be staying on irc in case you have questions
[19:50] <ari-tczew> please sponsor this merge before FF !! bug 523375 thanks!
[20:06] <lamont> mvo: were you serious in that SMS? and do I need to handhold it?
[20:09] <tormod> pitti, can e.g. you please bless the sync request in bug 520163 ?
[20:10] <lamont> mvo: would "apt-get dist-upgrade -o Apt::Immediate-Configure=false" in an apt.conf.d/foo file in the tarball be sufficient to get past the current pain?
[20:12] <ari-tczew> main sponsors needed!!!
[20:13]  * micahg just saw a blog post about that ari-tczew :)
[20:14] <ari-tczew> micahg, I don't understand :>
[20:14] <directhex> seb128, moonlight 2.1 packaging is mostly done, but is blocking on the mozilla team providing something resembling a xulrunner-dev 1.9.2
[20:15]  * \sh just had a look on mom...and mom is again pregnant with twins
[20:17] <micahg> directhex: I think it's done from my end, I think asac said something in the timeframe of 'soon' for an upload :)
[20:17] <micahg> ari-tczew: I read something recently about the lack of main-sponsors
[20:17] <directhex> micahg, yeah, that's what i heard a week or two ago regarding a list of Depends: for plugins. featurefreeze is *tomorrow*
[20:20] <mvo> lamont: that should be enough (the tarball thing)
[20:20] <lamont> ta
[20:20] <mvo> lamont: if you build util-linux by hand and install it in the archive it would work as well
[20:21] <lamont> mvo: except for the "install it in the archive" part
[20:21] <lamont> there is no abi for that
[20:21] <elmo> lamont: I think he means the chroot archive
[20:21] <lamont> ah, but still requires building it
[20:35] <ari-tczew> [ new upstream @ merge ] Bug 523375 please sponsor it ;-) thanks!
[20:44] <tseliot> slangasek: shall I retry my builds? I got a "chroot problem": http://launchpadlibrarian.net/39316569/buildlog_ubuntu-lucid-i386.nvidia-graphics-drivers_195.36.03-0ubuntu1_CHROOTWAIT.txt.gz
[20:45] <ivoks> everybody gets that :/
[20:45] <tseliot> slangasek, lamont: ^^ this was on palmer and crested
[20:45] <tseliot> oh
[20:45] <lamont> tseliot: it's everywhere, and why the whole farm is on manual atm
[20:46] <DktrKranz> slangasek: I'm about to upload python-launchpadlib_1.5.5-1, dinstall is running so it will take ~1,5h to be accepted, I hope it's not a problem for you.
[20:46] <tseliot> lamont: ok, so (for me) it's just a matter of waiting until all is fixed, right?
[20:47] <lamont> yes
[20:47] <tseliot> lamont: ok, thanks. I'll retrigger the build tomorrow, I guess
[20:49] <lamont> tseliot: if it's not in a ppa, it'll get requeued once the fix gets published (next publisher run, I expect)
[20:50] <tseliot> lamont: no, it's not in a ppa, it's in lucid. Great news, thanks again :-)
[20:52] <tormod> ari-tczew, try contacting directly a dev who has uploaded that package earlier
[20:53] <lamont> so, um, when does the publisher usually run?
[20:56] <lamont> there.  that ends the "ZOMG in CHROOTWAIT" queries. :-p
[20:56] <slangasek> DktrKranz: sounds good to me, thanks :)
[20:59] <ari-tczew> where is ttx :(
[21:00] <slangasek> not in front of tty?
[21:07] <lamont> dear world.  build farm back online, chewing on your NOMNOMNOM lucid builds
[21:12] <ivoks> thanks
[21:12] <geser> \o/
[21:15]  * ogra hugs lamont 
[21:15] <sebner> lamont is tehh FIXX0R!
[21:16] <lamont> sebner: mvo is teh fix0r... I just get to drive sometimes
[21:16]  * mvo hugs lamont
[21:17] <lamont> mvo: so... it's been that way in that package for sometime, was it the whole switch to upstart that exposes it?  and is apt going to change so that's not totally fatal the next time around? or ??
[21:17] <lamont> because I don't think I can drop that dep until upstart is there, right?
[21:18] <lamont> (speaking of debian)
[21:19] <\sh> world thanks lamont and mvo :)
[21:19] <mvo> it got triggered because mountall grew a new dep on udev, and yes, it really should handle the situation more gracefully
[21:19] <mvo> what its doing is not fatal
[21:19] <sebner> lamont: btw, already got time to look at the dpkg fix from cjwatson?
[21:19] <mvo> if the immediate-configure fails
[21:20] <lamont> sebner: that's waiting for testing on dogfood prior to lobbing it into production
[21:20] <lamont> fwiw, we get to ignore the FFE mess for alien-arena
[21:20] <lamont> I got it blessed
[21:21] <sebner> lamont: heh, it's a little bit annoying but no real problem filing and getting it approved so I don't really mind
[21:22] <lamont> sebner: ok.  if you want to go the FFE route and upload, works for me. - I was planning on just signing it and stuffing it
[21:23] <kirkland> lamont: are the buildd's hosed?
[21:23] <kirkland> lamont: http://launchpadlibrarian.net/39320067/buildlog_ubuntu-lucid-i386.ecryptfs-utils_83-0ubuntu1_CHROOTWAIT.txt.gz
[21:23] <sebner> lamont: *IF* you can sort it out before FF it's even better but don't feel any pressure. You don't *have to* do it right now if you have other stuff to do
[21:23] <lamont> kirkland: that should have been given back
[21:23] <\sh> kirkland: you are too late ;)
[21:24] <micahg> lamont: you didn't say the chroot problem was fixed, did you?
[21:24] <lamont> micahg: let me guess, it's back?
[21:24] <micahg> https://launchpad.net/~mozillateam/+archive/ffox35/+build/1514312/+files/buildlog_ubuntu-lucid-i386.totem_2.29.4-0ubuntu3~ffox36~lucid1_CHROOTWAIT.txt.gz
[21:24] <lamont> kirkland: you'll note that 0ubuntu2 is current.
[21:25]  * ScottK thinks we have ~20 minutes until the publisher run finishes ....
[21:25] <kirkland> lamont: 0ubuntu2 of what?
[21:25] <lamont> ecryptfs-utils
[21:26] <lamont> you know, the log you just threw at me from ages ago when the lucid chroot tarball was h0rked.
[21:26] <kirkland> lamont:  82-0ubuntu2
[21:26] <lamont> meh
[21:26] <kirkland> lamont: i uploaded 83-0ubuntu1
[21:26] <kirkland> lamont: hmm, that log file is just a few minutes old
[21:26] <lamont> dear mvo.  hating you. kthx
[21:27] <mvo> *weeh*
[21:27] <lamont> mvo: so... you comfortable with us just running with the hack for all builds for a little while you find the real answer?
[21:27] <lamont> deadlines and all that
[21:28] <lamont> but you understand the hack at least 3 orders of magnitude better than me
[21:28] <mvo> lamont: sure - what was it you did earlier? build util-linux manually?
[21:28] <mvo> it will do no harm
[21:28] <lamont> hacked tarball, uploaded, manual the world, punch util-linux to the top, let it build, restore old buildd
[21:28] <lamont> oh. wait.
[21:29] <lamont> let me guess... the installed util-linux needs to be the fixed one, right?
[21:32] <lamont> mvo: ^^
[21:33] <mvo> lamont: once util-linux (the new version) makes it into the archive all should be good again, is the new util-linux build and published?
[21:33] <lamont> built and published
[21:33] <lamont> OTOH, just building tarballs to make sure
[21:34] <mvo> :(
[21:34] <mvo> its not on archive.u.c (at least I can not see it on my system) yet
[21:36] <primes2h> cr3: Hello, are you around?
[21:37] <lamont> mvo: so... published != published.
[21:37]  * lamont goes to scrape the internal mirror to be sure
[21:38] <primes2h> cr3: Did you have a look at the translation issue ? bug #514401
[21:38] <mvo> heh :) that makes it harder for me to test, it did work in my test env
[21:40] <primes2h> cr3: It would be nice to have it fixed in time for Lucid.
[21:40] <cr3> primes2h: thanks for the reminder, but the current trunk of the project has security issues which need to be resolved before I can push the new version
[21:41] <nixternal> anyone know if the current daily installer is working? been broken the past couple of days
[21:41] <cr3> primes2h: I will have that ready in time for lucid, even though I might need a ffe. I just hope this will be in time for translations to kick in
[21:42] <kirkland> lamont: will builds auto retry, or do i need to push?
[21:42] <lamont> autoretry for !ppa
[21:42] <lamont> (already given back)
[21:44] <primes2h> cr3: Ok, I hope so. Tell me if you need help for anything. :-)
[21:45] <primes2h> cr3: Thanks.
[21:56] <mvo> juliank: sorry, no upload today, the gdebi-gtk InstallProgressAdapter is not working, I need to debug that first (it appears something with updateInterface/waitChild is not yet ok)
[21:59] <DktrKranz> mvo: need more testing hands on gdebi side?
[22:00] <lamont> sigh.  that first NOMNOMNOM announcement would be the packages missing the publisher by 4 minutes.
[22:00] <lamont> so given that it runs in 2 min, and takes 20+ to get past lucid, I think it's breaktime
[22:02] <mvo> DktrKranz: gdebi is ok, I'm testing the new python-apt, its doing a good job of compatiblity, but its not 100% there yet
[22:03] <DktrKranz> ah, ok. Don't hesitate to ask if you need help ;)
[22:03] <mvo> :)
[22:03] <mvo> thanks!
[22:05] <lamont> right.  ;40 is too long, mvo I let them go, will verify things once the load settles out again
[22:17] <DktrKranz> slangasek: python-launchpadlib accepted, all yours ;)
[22:19] <slangasek> DktrKranz: cheers!
[22:19] <lamont> ok.  NOW lucid is NOMNOM
[22:23] <mvo> lamont: for me pbuilder update is happy, that used to fail with the pre-conf error - are the buildd chroots happy too?
[22:23] <ScottK> mvo: Stuff is building
[22:23] <lamont> yeah - ubuntu2 finally showed
[22:23] <seb128> mvo, lamont: good work!
[22:24] <mvo> nice
[22:25] <lifeless> is anyone interested in ubuntu-bug accepting program names? e.g. ubuntu-bug apt-cache
[22:26] <micahg> lifeless: already ubuntu-bug `which apt-cache` should work
[22:26] <lifeless> it doesn't, but its not intuitive
[22:27] <lifeless> ubuntu-bug has the users PATH, so it could check this itself.
[22:28] <micahg> lifeless: bug 447751
[22:29] <micahg> thanks lamont, mvo for the builders :)
[22:29] <lifeless> micahg: thanks
[22:37] <Riddell> mysql still not fixed?  can't it just gain an epoch and be quickly sorted?
[22:42] <directhex> dpkg-deb: building package `moonlight-plugin-mozilla' in `../moonlight-plugin-mozilla_2.1-0ubuntu1~pre~ppa1_amd64.deb'.
[22:42] <unimatrix> what's going to happen in Lucid if ATI doesn't come up with a working fglrx driver for the new X server ?
[22:43] <seb128> directhex, oh, nice moonlight
[22:43] <directhex> which is preferable, whilst waiting for xulrunner-dev 1.9.2 - ship a package built against 1.9.1 with known functionality missing in ff3.6, or sit on the package & wait?
[22:44] <directhex> seb128, i'm about to upload to ppa & test
[22:45] <seb128> directhex, I would say check with #ubuntu-mozilla for xulrunner update
[22:46] <seb128> if that's coming rsn wait
[22:46] <seb128> otherwise build with 1.9.1 for now
[23:30] <crimsun> pitti: noted (& pulled), thanks.
[23:35] <tormod> slangasek, can you please ack this sync? bug 520163
[23:49] <leonardr> DktrKranz, have you done any work on the new launchpadlib release?
[23:49] <leonardr> (ie packaging it)
[23:50] <ScottK> leonardr: It was uploaded to Debian earlier today
[23:50] <leonardr> ScottK, great, thank you
[23:57]  * sebner looks for a core-dev sponsoring an easy merge
[23:57] <sebner> before FF ;)
[23:58] <sebner> https://bugs.edge.launchpad.net/ubuntu/+source/jinja2/+bug/523540