[00:09] <dtchen> hyperair: / TheMuso: all set
[00:09] <dtchen> tested with two devices, does the right thing
[00:10] <TheMuso> dtchen: ok cool.
[00:32]  * mneptok punches directhex in the face
[00:32] <mneptok> YOU ARE GREEN DRAZI!
[00:33]  * slangasek scratches his head
[00:33] <mneptok> slangasek: http://doctormo.wordpress.com/2009/04/08/foss-tribalism-in-the-community/
[00:34] <mneptok> slangasek: directhex earns the comment win :)
[00:34] <TheMuso> slangasek: Since I'm almost done for my working day here, and since I'm away for the easter weekend, and since kernel freeze is tomorrow, I'll need exceptions for linux-ports and linux-rt, which will only be rebases. Shall I file a bug to make it formal?
[00:34] <slangasek> I see. :)
[00:35] <slangasek> TheMuso: hmm, how long after kernel freeze are the rebases expected to get done?
[00:35] <TheMuso> slangasek: not till next monday evening my time at the absolute earliest
[00:35] <slangasek> TheMuso: are those packages up-to-date with the linux package currently in the archive?
[00:36] <TheMuso> slangasek: yes they are
[00:36] <slangasek> ok
[00:36] <slangasek> on the bright side, your Monday evening is early
[00:36] <slangasek> yes, please file a bug to remind us that it's coming
[00:36] <TheMuso> Ok will do.
[00:39] <directhex> mneptok, i'd hope slangasek of all people would get an obscure babylon 5 reference
[00:39] <slangasek> Yes.
[00:43] <directhex> especially since i was out-obscured last time :/
[00:46] <mneptok> directhex: between slangasek and myself, it's a tight net to slip through :)
[00:46] <TheMuso> dtchen: I'm going to upload that suspend/resume change for pulse now, since I am about to head off for the easter weekend, unless you want me to hold off, and you get someone else to sponsor the uploads.
[00:46] <dtchen> TheMuso: it's set for upload
[00:46] <TheMuso> dtchen: ok thanks.
[00:47] <dtchen> hyperair: thanks for being on top of it. unfortunately editing files using my phone is somewhat subpar ;)
[00:51] <TheMuso> dtchen: is there a problem with the file?
[00:51] <dtchen> TheMuso: no, my bzr branch is fine.
[00:51] <TheMuso> dtchen: ah ok I just thought there was an error you found relating to use of your phone or some such. :)
[00:52]  * TheMuso does a quick test build.
[00:56] <slangasek> mneptok: I don't think I contribute much there, as I wouldn't have seen the comment at all without being pointed to it... :)
[00:59] <TheMuso> slangasek: ok bug filed, ubuntu-release subscribed.
[00:59] <slangasek> TheMuso: saw it, thanks :)
[00:59] <TheMuso> Ok pulse uploaded, I'm outa here. Happy easter all
[00:59] <slangasek> have a good weekend!
[00:59] <TheMuso> Will do, checking out plenty of live music.
[01:11] <slangasek> kirkland: do you recall why python-moinmoin was among the packages dropped when you cleaned up the server seed?
[01:11] <slangasek> kirkland: asking because it's not seeded anywhere else under Ubuntu, it's currently in main only because kubuntu has not yet merged that change
[01:12] <slangasek> (also because python-moinmoin serecommends: fckeditor from universe, so I need to know which side of that to clean up)
[01:14] <cjwatson> slangasek: oh, I think that recommendation was new in the merge I sponsored recently; if you need to, it probably wouldn't be disastrous to drop it to a suggests
[01:14] <cjwatson> it makes the moin GUI editor work
[01:14] <slangasek> yeah, it looked wrong to me as a Recommends
[01:14] <slangasek> then I went to look at the seed to see in what circumstances python-moinmoin is pulled in, and became Confused
[01:16] <slangasek> cjwatson: should we poke python-moinmoin back into the ubuntu seeds somewhere?
[01:17] <maxb> moinmoin was using an embedded copy of fckeditor until recently. Personally I hate the GUI editor, but some people might see it as a standard part of a Moin install?
[01:18] <slangasek> ah
[01:18] <cjwatson> wasn't it disabled?
[01:18] <slangasek> in 1.6.2-1 it was
[01:20] <cjwatson> one reason I can think of to keep it is that we almost certainly run it on some of our own servers
[01:20] <cjwatson> IIRC including the GUI editor
[01:22] <slangasek> well, first of all, having moin in main only because of the accident that the kubuntu seed hasn't merged that change isn't good - this should be seeded in the dvd seed?
[01:24] <cjwatson> maybe better one of the platform supported-server seeds
[01:25] <slangasek> supported-misc-servers, then?
[01:26] <cjwatson> sounds plausible
[01:27] <slangasek> ok; that leaves fckditor as an open question
[01:27] <slangasek> e
[01:34] <savvas> just so I don't have a guilt for 6 months, do you think I made the right decision to set bug 356935 as invalid? it's too late for such changes right?
[01:35] <slangasek> savvas: barring major bugs in the version we currently have in jaunty, yes
[01:36] <savvas> no bugs whatsoever unfortunately, that little application is damn good, and getting better every time :)
[01:37] <savvas> I guess the live backup can wait for 6 months hehe
[01:40] <LaserJock_> dang, Ubuntu just keeps getting easier and easier to install
[01:41] <slangasek> sorry, we'll try harder for karmic
[01:41] <LaserJock_> :)
[01:42] <savvas> does anyone happen to know which application configuration the installer asks you to import?
[01:42] <savvas> is there a list of these apps?
[01:43] <LaserJock_> it just did firefox, evolution, and pidgin for me
[01:45] <savvas> same :\
[01:45] <savvas> imagine going through the whole 500-600 application configuration folders in my home I gathered this past few years :P
[01:45] <savvas> *these
[01:55] <slangasek> cjwatson: so with that decided, we still need to figure out whether we want fckeditor by default (MIR) or not (upload).
[01:56] <cjwatson> security review might take a while, I guess
[01:56] <cjwatson> I'm happy to have it out given the lateness
[01:56] <cjwatson> want me to upload that?
[01:56] <slangasek> I can
[01:56] <slangasek> I already have it here
[01:57] <cjwatson> ok
[01:57] <cjwatson> beware debian/control.in
[01:58] <slangasek> noted :)
[02:00] <cjwatson> slangasek: my fix for 44194 hasn't had any confirmation that it actually fixes the bug yet, but Lars reckons it doesn't break anything. Do you think I should go ahead and upload what I have?
[02:00] <slangasek> cjwatson: yeah
[02:03] <slangasek> calc: did the OOo upload happen?
[02:04] <slangasek> calc: doesn't appear to have - it's now late, 2 hours past the official deadline?
[02:06]  * slangasek afks for dinner
[02:09] <calc> slangasek: i ran into git eating my brain issue, i am ready to upload now
[02:10] <calc> i'll stage it all on chinstrap and then get into the archive in ~ 2hr (need both packages)
[02:30] <calc> slangasek: around 1hr left until its uploaded to the archive itself
[02:33] <tedg> Is it worth working on some final bugs (not crashers) or is it time to give up?
[02:44] <calc> slangasek: i also disabled sparc in the build (at least afaict), so we probably should remove the sparc binaries from the archive after it is done building
[03:37] <calc> slangasek: done
[03:40] <slangasek> calc: ok; in that case we could drop the sparc binaries immediately anyway
[03:41] <calc> slangasek: ok
[03:42] <calc> they both just got accepted
[03:43] <calc> so if you want to nuke the jaunty sparc binaries go ahead :)
[04:26] <calc> slangasek: could i get you to accept ooo-thumbnailer into universe? :)
[04:30] <calc> slangasek: it closes bug 25827 but I managed to forget to mention it in the changelog :(
[04:43] <ScottK> slangasek: Any ideas on why we stopped building usplash for ia64 last year?
[04:44] <ScottK> I don't see anything in debian/changelog
[04:45] <ScottK> Currently all of Kubuntu except kubuntu-meta is built on IA64, so the completionist in me is a bit frustrated.
[05:24] <slangasek> ScottK: no idea on that one, no
[05:24] <slangasek> calc: does ooo-thumbnailer have an ack from motu-release?
[05:25] <slangasek> actually... either way, I'm not going to get to it tonight
[05:29] <calc> slangasek: ok, i'll ping motu-release
[05:30] <slangasek> ok
[05:32] <slangasek> calc: btw, there are a number of reverse-build-deps of libitext-java that don't seem to have gotten MIRs yet; do you have any information about bouncycastle, libpdfrenderer-java, junitperf, or should I write up the MIRs from scratch?
[05:34] <calc> reverse-build-deps? i must be confused or something
[05:34] <calc> why would reverse-build-deps (things that use a library) need to be moved into main
[05:36] <slangasek> calc: er, I mean build-deps
[05:39] <calc> but no i didn't know anything about its changing, it has been in main for a while now and didn't realize it grew new build-deps
[05:39] <slangasek> I'm not sure they're new
[05:39] <calc> oh
[05:40] <calc> hmm either their new or someone demoted them after it built for intrepid i suppose
[05:40] <slangasek> or libitext-java never had to be rebuilt after being promoted
[05:40] <slangasek> actually, libitext-java was uploaded once since promotion... and is dep-wait.
[05:40] <calc> oh hmm i forgot about that
[05:41] <calc> yea so it either had things demoted or it grew new build-deps
[05:41] <slangasek> no, the package has *never* built successfully in main
[05:41] <slangasek> the binary that's in main is the same version that was originally promoted
[05:42] <calc> hmm how did it get in the archive at all, since the previous upload was a ubuntu change
[05:42] <slangasek> it was built in universe
[05:42] <slangasek> *before* it was promoted
[05:42] <calc> er 1.4.5-3 was promoted
[05:42] <slangasek> oh
[05:42] <slangasek> ok, then they are new build-deps
[05:42] <slangasek> sorry; I was trying to go by debian/changelog, which says nothing about the new deps at all
[05:42] <calc> then 1.4.5-3ubuntu1 was uploaded 6 months later
[05:42] <calc> ok
[05:42] <slangasek> heh, ok :)
[05:43] <slangasek> in that case, I can probably cull these build-deps for jaunty
[05:43] <calc> so whoever requested sync should have written the MIRs
[05:43] <calc> because it would have required an override of the ubuntu changes to have been synced
[05:43] <slangasek> yes, quite
[05:43] <calc> bug 299000
[05:44] <calc> it was matthias
[05:44] <calc> lol
[05:44] <slangasek> yep
[05:46] <slangasek> well, he was right that the Ubuntu change was integrated in the Debian package :)
[05:46] <slangasek> I'll write up the MIRs
[05:46] <calc> ok
[05:46] <calc> i could do it tomorrow, but i'm about to head to bed for tonight
[05:47] <slangasek> that's fine; these are high on my list of things to kill off for release, I'll take care of it before bed
[05:48] <calc> ok
[05:49] <slangasek> that, or kill off the build-deps if I determine they're expendable :)
[05:49] <StevenK> Mmmm. Red-shirt Build-Depends
[05:50] <slangasek> absolutely!
[08:21] <hyperair> dtchen: regarding the pulseaudio hook, the get_pulse_users i wrote that time misses out of a few pulseaudio instances, especially if you've killed pulseaudio before and don't prepend /usr/bin to it.
[08:22] <hyperair> dtchen: could you take the current get_pulse_users() function from the debdiff i proposed?
[08:22] <hyperair> dtchen: to summarize, get_pulse_users() { ps -C pulseaudio -o user=; }
[08:22] <hyperair> dtchen: i think that works much better than using awk
[08:41] <slangasek> soren: dendrobates mentioned last week you would be providing the fix for bug #347622; is that done now, or is the bug still outstanding?
[08:47] <seb128> DOH
[08:47] <seb128> slangasek: already frozen?!?
[08:48] <slangasek> seb128: yep - but if you need something pushed in, we'll do the usual dance of course
[08:48] <slangasek> fusa, then?
[08:49] <seb128> slangasek: please accept fusa, it undo the string freeze breakage of the previous upload
[08:49] <slangasek> sure
[08:49] <seb128> thanks
[08:49] <seb128> I was sort of expect to get work done today
[08:49] <seb128> ie upload quite a lot
[08:49] <seb128> you are just putting extra review load on your shoulder but if you are fine with that ;-)
[08:50] <slangasek> yep, that's the routine
[08:50] <slangasek> the alternative is that everyone makes "one last upload" with "just a small change that can't hurt"
[08:51] <bryce> so nice having the release manager in my time zone :-)
[08:51] <slangasek> heh
[08:51] <slangasek> that's UTC-10, right?
[08:52] <liw> bryce, no no, it's so nice having a release manager who never sleeps
[08:52] <liw> we should have more vampires develop Ubuntu
[08:52] <liw> "Ubuntu: Linux not just for human beings"
[08:55] <slangasek> tseliot: do you agree with pitti's proposal in bug #351394?
[08:56] <tseliot> let me check
[08:58] <tseliot> slangasek: I think I can migrate users without transitional packages when they do the upgrade through Update Manager and bug them to death with debconf if they upgrade from the command line
[08:58] <tseliot> which is what nvidia-common should do
[08:58] <slangasek> oh, nvidia-common already does this?
[09:00] <tseliot> slangasek: yes but it doesn't migrate users with the 177 driver yet though. It should be a trivial change
[09:00] <slangasek> ok
[09:01] <tseliot> slangasek: no, wait it should already do that (since revision 9): https://code.launchpad.net/~albertomilone/nvidia-common/main
[09:02] <bryce> is kde using Qt4.4 or 4.5 in jaunty?
[09:02] <slangasek> bryce: 4.5
[09:02] <bryce> hrm
[09:03] <bryce> https://bugs.kde.org/show_bug.cgi?id=187356#c21 (in ref to our bug #350120)
[09:05] <nixternal> bryce: there is no easy way of fixing the issues due to Kubuntu deciding to use Qt 4.5 (imho it was a bad decision)
[09:05] <nixternal> I would have to say that 350120 is more than likely a Qt/Kubuntu bug more so than an x bug...we knew the warning of using Qt4.5 with KDE <4.3
[09:06] <bryce> nixternal: thanks, that's what I was wondering
[09:06] <bryce> nixternal: what package should this be filed against?
[09:06] <nixternal> qt
[09:07] <savvas> does anyone know the answer to bug 358271? is it actually a bug?
[09:07] <nixternal> woo, kubuntu isn't the only ones to make that mistake of using 4.5, I see gentoo did too :)
[09:08] <bryce> nixternal: hmm no such package 'qt'.  'qt4-x11'?
[09:08] <nixternal> ya, that's it
[09:08] <bryce> awesome thanks
[09:08] <nixternal> np
[09:15] <savvas> cjwatson: I'd like your comment for b ug 358271 when you find some time (since you were the last person that changed console-setup)
[09:24] <tkamppeter> slangasek, hi
[09:26] <tkamppeter> slangasek: I have uploaded HPLIP 3.9.2-3ubuntu4 and as it finished uploading I saw your e-mail that you have frozen the RC. So it missed the freeze for seconds. Can you pass it through?
[09:27] <slangasek> tkamppeter: it will be reviewed by the release team; there are no free passes for "almost" making the freeze cutoff, given that the official freeze deadline was several hours ago :)
[09:32] <tkamppeter> slangasek: sorry, if someone reports a problem I will put out a SRU.
[09:33] <ogra> slangasek, could you do me a favour and trigger a ports-live build (none of our fixes from yesterday seems to have made it on the 09 image)
[09:34] <ogra> *seem
[09:36] <slangasek> lool: ^^ could you do that, maybe? I'm trying to find my bed
[09:37] <seb128> 'night slangasek
[09:37] <lool> slangasek: Happy to
[09:37] <lool> slangasek: Have a good night
[09:37] <slangasek> "trying" is still the operative word ;)
[09:38] <ogra> slangasek, i can do it myself, i just dont like to do it without asking during freezes ;) sleep tight
[09:38]  * lool throws a bed on slangasek 
[09:40] <slangasek> ogra: oh; "can you" vs. "can I" :-)
[09:40] <ogra> slangasek, yeah, sorry, you were still up ... GO TO BED NOW !!!
[09:40] <ogra> ;)
[09:42] <lool> slangasek, ogra: Kicking an ubuntu live build for armel
[09:43] <ogra> thanks
[09:43] <lool> (I verified the proper versions of casper, flash-kernel, and gnome-keyring are on the cdimage mirror; however I can't check on the buildds)
[09:45] <lool> cjwatson: ogra reminded me that we shouldn't run for armel alone; will finish this run though, and I don't intend to run another full ports_daily-live build unless you say otherwise
[09:47] <tseliot> doko: any ideas as to why this happens when dist-upgrading to Jaunty (the program works well in Jaunty)? https://bugs.launchpad.net/ubuntu/+source/nvidia-common/+bug/346099
[09:48] <tseliot> it's no longer private now
[10:00] <cjwatson> slangasek: ooh, confirmation of 44194
[10:00]  * cjwatson offers up a quick prayer of thanks
[10:01] <cjwatson> savvas: eek; will look, thanks
[10:01] <cjwatson> debian/changelog:284:  * Removed debconf support for grp:alts_toggle, grp:ctrls_toggle,
[10:03] <StevenK> root@mangled:~# deluser ...
[10:03] <StevenK> Warning: Removing group `users', since no other user is part of it.
[10:03]  * StevenK gives adduser a penalty card for 'lying'
[10:06] <savvas> cjwatson: thanks :)
[11:29] <IntuitiveNipple> Do we have anyone to push an openjdk bug-fix? archive freeze is upon us and I haven't had a response from doko
[11:41] <doko> tseliot: this should be gone, afaik
[11:41] <doko> IntuitiveNipple: which one
[11:42] <IntuitiveNipple> doko: oh, you're there :) I emailed you and subscribed you to bug #344705
[11:42] <IntuitiveNipple> doko: thought you may be on vacation
[11:42] <tseliot> doko: ok, thanks
[11:44] <doko> IntuitiveNipple: ok, looking
[11:45] <IntuitiveNipple> doko: thanks :)
[12:15] <ogra> seb128, why is gnome-keyring started in two places ?
[12:15] <ogra> (pam starts it from gdm and xdg has an autostart file)
[12:16] <seb128> not sure, they have different purpose
[12:16] <seb128> the pam thing allows to automatically unlock it
[12:16] <seb128> when entering your password on the login screen
[12:16] <ogra> we're trying to track down the 100% CPU usage on arm atm
[12:16] <ogra> and were wondering if a race could happen here
[12:16] <seb128> the autostart is because you need to get it started when doing autologin or not using gdm too
[12:17] <ogra> its also confusing that we see it running with different options on different systems
[12:17] <seb128> open upstream bugs
[12:17] <ogra> lool sees --start if not using gdm
[12:17] <seb128> I don't know the details
[12:17] <ogra> i see --daemonize --login on my laptop
[14:44] <lool> Hmm I wonder why printf '%c' 0xff doesn't output the same as printf '\xff'
[14:46] <BUGabundo> seb128 is not here?
[14:46] <BUGabundo> is update to pidgin is crashing XMPP and SSL
[14:46] <BUGabundo> pidgin (1:2.5.5-1ubuntu7)   * debian/patches/71_upstream_change_fix_ssl_crasher.patch:
[14:47] <calc> BUGabundo: file a bug with apport crash information :)
[14:47] <BUGabundo> doing so
[14:47] <BUGabundo> I have the .crash for it
[14:47] <BUGabundo> just don't have dbg symbols
[14:47] <BUGabundo> UM is running so I have to way to install it
[14:48] <BUGabundo> seb128: ping
[14:48] <BUGabundo> (02:46:31 PM) freenode: is update to pidgin is crashing XMPP and SSL
[14:48] <BUGabundo> (02:46:47 PM) freenode: pidgin (1:2.5.5-1ubuntu7)   * debian/patches/71_upstream_change_fix_ssl_crasher.patch:
[14:48] <seb128> BUGabundo: contextless ping warning
[14:49] <BUGabundo> sorry for the noise
[14:49] <seb128> ?
[14:49] <IntuitiveNipple> lool: shell doesn't support leading 0x ?
[14:49] <IntuitiveNipple> lool: correction, %c only consumes first character, so you get the 0
[14:50] <ogra> yeah, doesnt that need to be %s ?
[14:50] <seb128> BUGabundo: did you have question or ...?
[14:51] <BUGabundo> seb128: its just that patch is making pidgin crash
[14:51] <BUGabundo> I just got the .crash and bt full
[14:51] <BUGabundo> reporning now on LP
[14:51] <seb128> BUGabundo: are you sure you don't have bug #357949 rather?
[14:51]  * BUGabundo looks
[14:51] <BUGabundo> that's what happens
[14:52] <BUGabundo> but I just got it before lunch!
[14:52]  * seb128 grrr at user filing ton of duplicates
[14:52] <BUGabundo> it was fine until then
[14:52] <BUGabundo> this bug is 18h old
[14:52] <lool> IntuitiveNipple: Indeed; quite counter-intuitive when compared to printf '%i' 0xff
[14:52] <lool> IntuitiveNipple: thanks
[14:52] <seb128> BUGabundo: and you did restart pidgin after upgrade since yesterday before that?
[14:52] <IntuitiveNipple> printf '\xXX' prints the single character with code 0xXX, whereas '%c' prints the ASCII char at index 0 of the relevant argument
[14:53] <BUGabundo> of course
[14:53] <lool> ogra: I wanted to output a byte with the value 0xff, %s would have output "0xff"
[14:53] <IntuitiveNipple> lool: Yeah, that could get confusing!
[14:53] <BUGabundo> just added my bt full to that bug
[14:53] <ogra> lool, ah
[14:53] <lool> IntuitiveNipple: I think %c in C is just like %i or %d, not like %s -- which is why i was confused
[14:54] <lool> Anyway \xff works fine
[14:54] <IntuitiveNipple> lool: convoluted but this works: printf "\x$(printf '%x' 0xff)"
[14:55]  * lool fails to see the point :)
[14:55] <IntuitiveNipple> lool: just because it can :p
[14:55] <IntuitiveNipple> lool: might be useful in some weird string-processing scenario :)
[14:56] <lool> I would just find %c much easier if it wasn't %.1s
[14:56] <IntuitiveNipple> lool: yeah, that'd have to guess the argument type was a hex-expressed byte
[14:58] <BUGabundo> seb128: renaming ~/.purple/icons/ seems to work
[14:58] <lool> (It does for %i and %d!)
[15:00] <IntuitiveNipple> yeah, that is almost looking like a bug
[15:00] <seb128> BUGabundo: I told you that's the same bug ;-)
[15:00] <IntuitiveNipple> since it says 'printf uses the C format specifiers'
[15:00] <BUGabundo> thanks for the tip seb128
[15:01] <lool> I guess it wont every be changed for compatibility purposes
[15:01] <IntuitiveNipple> possibly not, but... "...all C format specifications ending with one of diouxXfeEgGcs, with ARGUMENTs converted to proper type first..."
[15:01] <seb128> BUGabundo: you're welcome
[15:02] <IntuitiveNipple> lool: Is it bash you're working with?
[15:03] <IntuitiveNipple> lool: bug #225637
[15:03] <lool> Eh
[15:04] <IntuitiveNipple> "POSIX requires the current behavior"
[15:04] <lool> IntuitiveNipple: It's zsh
[15:08] <IntuitiveNipple> lool: http://www.zsh.org/mla/workers/2004/msg00356.html
[15:12]  * Hobbsee mourns the loss of working pidgin
[15:12] <ogra> use drums
[15:13] <BUGabundo> Hobbsee: it is workable
[15:13] <BUGabundo> if you like to loose all your old avatars
[15:13] <Hobbsee> BUGabundo: how does one fix it so it doens't segfault when it's trying to connect?
[15:13] <lool> right
[15:13] <seb128> Hobbsee: https://bugs.edge.launchpad.net/ubuntu/+source/pidgin/+bug/357949
[15:13] <BUGabundo> Hobbsee: rename ~/.purple/icons/
[15:14] <seb128> or remove the gst plugin which lead to the crash
[15:14] <Hobbsee> ah, lovely.
[15:14]  * BUGabundo rather rename... hope I can get it back later.... I love too much my avatar cache
[15:17] <seb128> BUGabundo: just rremove /usr/lib/gstreamer-0.10/libgstladspa.so
[16:22] <ogra> tedg, should pidgins contact list minimize into the notifier applet ?
[16:22] <Hobbsee> ogra: I wish!
[16:22]  * ogra never uses pidgin ... 
[16:23] <tedg> ogra, into the messaging menu?  Yes, it should.  Assuming you have the plugin enabled of course.
[16:23] <ogra_babbage> only here on the test machine for IRC
[16:23] <tedg> Hobbsee: That got fixed with the 0.1.5 upload of indicator-applet and libindicate.
[16:23] <ogra_babbage> tedg: well, thats a fresh jaunty install, shouldnt it be enabled by default ?
[16:23] <Hobbsee> ah ha.  excellent.
[16:24] <ogra_babbage> the buddy list definately minimizes to teh windowlist here
[16:24] <tedg> ogra_babbage: Yes.  Is it up to date?
[16:24] <ogra_babbage> built this afternoon (UTC)
[16:24] <tedg> ogra_babbage: Oh, minimizes?  It'll minimize to the window list, if you close it, it'll go into the menu.
[16:24] <ogra_babbage> if i close it it shuts down pidgin
[16:25] <ogra_babbage> it only minimizes to the applet if i click on the submenu in the applet
[16:26] <ogra_babbage> oh, now it doesnt
[16:26] <ogra_babbage> weird
[16:26] <ogra_babbage> tedg: ignore me, seems it does what it should, though i'm sure it just closed when i tried that before
[16:26]  * tedg hacked into ogra_babbage's machine and fixed it ;)
[16:27] <ogra_babbage> might that have to do with the fact that i wasnt connected before ?
[16:27] <tedg> You should really change that password...
[16:27] <ogra_babbage> damned ... i shouldnt have blogged it :)
[16:27] <tedg> ogra_babbage: Yes, I think that Pidgin does take that into account.  If you're completely offline it closes.
[16:28] <ogra_babbage> ah, ok then it DTRT
[17:05] <cr3> anyone happen to know since when apt-transport-https has been in ubuntu-standard?
[17:05] <cr3> err, "in" as in a dependency of the ubuntu-standard meta package :)
[17:06] <james_w> just this release
[17:06] <cody-somerville> Earlier this release cycle I believe
[17:06] <cr3> james_w: excellent, that saved me quite a bit of searching :)
[17:13] <cjwatson> cr3: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.jaunty/revision/1296
[17:34] <plars> pitti_: awake?
[17:59] <Ampelbein> hmm. apport on intrepid states: "upload() got an unexpected keyword argument 'staging'"
[18:02] <james_w> do you have a backtrace?
[18:05] <dendrobates> slangasek: we have a problem with the upload of eucalyptus soren made yesterday.
[18:05] <dendrobates> slangasek: he introduced a critical bug.
[18:05] <slangasek> dendrobates: I saw a new bug opened, yes
[18:06] <dendrobates> slangasek: this basically completely breaks eucalyptus.  Is there any way I can get this in?
[18:06] <slangasek> dendrobates: yes, please get the fix uploaded
[18:06] <dendrobates> it is uploaded.
[18:06] <Ampelbein> james_w: no. http://paste.ubuntu.com/147778/ is all i get.
[18:06] <dendrobates> slangasek: ^^^
[18:06] <Ampelbein> states network error, but i can connect to launchpad without problems.
[18:07] <slangasek> dendrobates: ok, then I'll review it as soon as I can
[18:07] <dendrobates> slangasek: thanks much.
[18:08] <kees> james_w: excellent reply to the PolicyKit design "bug".  we'll have to use that as a FAQ if it comes up again.
[18:11] <Ng> asac: I'm going a bit crazy here... thunderbird should be able to see gnome-vfs shares, right?
[18:11] <ion_> kees: URL please.
[18:14] <kees> ion_: https://bugs.edge.launchpad.net/bugs/358086
[18:14] <ion_> Thanks
[18:28] <kees> slangasek: which MIRs are critical to release still?
[18:29] <slangasek> kees: the ones that show up with 'Ubuntu Jaunty' on https://bugs.launchpad.net/~ubuntu-mir/+subscribedbugs
[18:29] <slangasek> (I'm not done filing all the ones that apply, unfortunately)
[18:49]  * kees face-palms
[18:57] <IntuitiveNipple> I've just helped a user solve a fail-at-initrd stage bug with jaunty. It was failing to find the root partition. Eventually we worked out that udev wasn't building its db. Then the user recalled seeing a message scroll past during boot "udevadm trigger is not premitted while udev is unconfigured" and it turned out that dpkg hasn't completed configuring before the system was rebooted.
[18:58] <IntuitiveNipple> Where precisely should that be posted against?
[19:00] <ion_> Oh noes, the fonts are blurry again. I wonder which package caused it? I have installed many sets of upgrades since the previous reboot/login. Setting lcdfilter as lcdlegacy doesn’t work anymore.
[19:04] <kees> IntuitiveNipple: sounds like the install/upgrade didn't finish before you rebooted.
[19:04] <IntuitiveNipple> kees: not me; the user. apparently the system restart icon came up and so he rebooted
[19:05] <kees> IntuitiveNipple: ah, so "please reboot" happened even though a package failed to install?
[19:05] <kees> IntuitiveNipple: check the dpkg logs and figure out if it was udev or linux that failed, and open it against that package.
[19:06] <kees> it does seem that the update-notifier file should only be put in place if the postinst finishes successfully.  :(
[19:06] <IntuitiveNipple> kees: apparently so. Took a while to diagnose it because he was stuck in the initrd busybox, but the fix was a live-CD env, chroot to the install, and "dpkg --configure -a"
[19:06] <slangasek> does the notification icon know not to launch if dpkg is still running?
[19:06] <IntuitiveNipple> I'm wanting to post a bug but not sure which package to put it against. I found another report of the same issue in forums
[19:07] <kees> slangasek: not sure
[19:07] <kees> IntuitiveNipple: you could open it against both udev and linux :)
[19:10] <IntuitiveNipple> kees: I'm sure Scott would love that!
[19:11] <kees> IntuitiveNipple: heh, well both of those packages drop the "please reboot" file, so they likely both need to be fixed.
[19:12] <IntuitiveNipple> I'll quote you in the bug report then!
[19:12] <kees> IntuitiveNipple: well, please include the logs of the failure too. :)
[19:13] <IntuitiveNipple> kees: there's not much of those since it was initrd, but I've got something from a forum post.
[19:13] <kees> IntuitiveNipple: the package update logs, I mean
[19:13] <kees> IntuitiveNipple: i.e. figure out what state the system was in prior to rebooting
[19:15] <IntuitiveNipple> kees: ah ok... the user reported he updates every day, so the diff was between yesterday and today
[19:16] <kees> IntuitiveNipple: have them include /var/log/dpkg.log
[19:19] <IntuitiveNipple> kees: too late unfortunately - the user had to go to 'karate' ... I suspect he'll be taking out some frustration for the bug :)
[19:20] <slangasek> kees: mumble
[19:21] <slangasek> kees: ok, I guess I'll hack the crap out of libitext to disable libpdfrenderer?
[19:22] <kees> slangasek: I'm really really against libpdfrenderer.  fixing PDF vulnerabilities is hugely time-consuming.  :(
[19:22] <slangasek> ok
[19:23] <Keybuk> IntuitiveNipple, kees: definitely not a bug in udev or linux
[19:23] <Keybuk> well, maybe linux
[19:23] <Keybuk> but not udev
[19:23] <IntuitiveNipple> Keybuk: ok, I didn't think so... what would you suggest?
[19:23] <Keybuk> if you get "udevadm not permitted" inside your initramfs, something called update-initramfs without depending on initramfs-tools!
[19:23] <kees> Keybuk: ah-ha
[19:23] <Keybuk> (initramfs-tools depends on udev obv.)
[19:24] <IntuitiveNipple> hmmm, so maybe initramfs-tools then? My main aim is to keep this on the radar in case others hit it, since it looks like a rare corner-case
[19:24] <Keybuk> no, not initramfs-tools
[19:24] <Keybuk> initramfs-tools is fine
[19:24] <IntuitiveNipple> and the explanation isn't obvious
[19:24] <Keybuk> it's a bug on whatever package *called* initramfs-tools from its postinst
[19:24] <Keybuk> without depending on initramfs-tools
[19:24] <IntuitiveNipple> I think i'll assign it to "Ubuntu" :0
[19:24] <Keybuk> that would be unhelpful
[19:25] <Keybuk> please don't do that
[19:25] <Keybuk> instead grep /var/lib/dpkg/info/*.postinst and look for calls to update-initramfs
[19:25] <Keybuk> and check each of the packages to make sure they have Depends: initramfs-tools
[19:25] <Keybuk> if you find some which don't, file bugs on them
[19:28] <IntuitiveNipple> I'll need the user to return to be able to do that/
[19:28] <james_w> kees: thanks
[19:35] <IntuitiveNipple> Keybuk: what source/script issues that "... not permitted...' text - I couldn't find it grep-ing the initrd or the udev package, but the user may not have reported it correctly
[19:35] <kees> Keybuk: ntfs-3g
[19:36] <kees> for i in $(grep update-initramfs *.{post,pre}{rm,inst} | cut -d: -f1 | perl -pe 's/\.(post|pre)(inst|rm)//' | sort -u); do apt-cache depends --recurse $i | grep Depends | grep -q initramfs-tools || echo $i; done
[19:36] <slangasek> kees: pdfrenderer build-dep axed
[19:36]  * kees hugs slangasek
[19:37] <Keybuk> kees: can you fix it?
[19:38] <kees> Keybuk: we're in freeze, but if slangasek says "yes"
[19:38] <slangasek> yes
[19:40] <jcole> fyi guys, installing flashplugin-nonfree on jaunty 64bit installs the 32bit plugin
[19:40] <kees> jcole: by design
[19:40] <LordKow> yes it does
[19:40] <jcole> kees: why
[19:40] <LordKow> adobe's 64-bit version is still in development and is unstable.
[19:41] <kees> jcole: because the 64bit plugin is still in beta.
[19:41] <jcole> kees: hmm, its always worked fine for me
[19:42] <LordKow> but not everyone, and it's not something ubuntu can maintain/fix
[19:42] <jcole> kees: is there a 64 bit package in ubuntu?
[19:43] <jcole> kees: its not like other beta software doesnt exist in the repos ;)
[19:43] <kees> jcole: there is no officially supported 64bit flash plugin.
[19:43] <kees> in ubuntu
[19:44] <kees> jcole: I wish it did, though :)
[19:44] <kees> jcole: I've been running the 64bit plugin for a few months now, and it's rock-solid for me.
[19:45] <LaserJock> bryce: I just had another lockup, this time on i386. I think maybe I'm going to go back to the -intel assumption
[19:45] <jcole> kees: same here... who says its unstable? or does unstable=beta
[19:46] <kees> jcole: the problem is that Adobe hasn't officially released it, so tracking it as it updates is harder.
[19:46] <kees> Keybuk: just to be sure I understand, this is the only thing that needs changing, right?
[19:46] <kees> -Depends: ${shlibs:Depends}
[19:46] <kees> +Depends: ${shlibs:Depends}, initramfs-tools
[19:46] <james_w> Ampelbein: is your python-launchpad-bugs package at 0.3.5?
[19:47] <bryce> LaserJock: bug #?
[19:47] <LaserJock> bryce: don't have one as of yet, I don't know what the heck to even write
[19:47] <Keybuk> kees:
[19:47] <Keybuk> kees: yup
[19:47] <Keybuk> it's a simple dependency issue
[19:47] <jcole> kees: i have problems with the 32 bit plugin... for example, when i close firefox, i will still hear sound and see a bunch of nspluginwrapper processes that i have to kill manually... ive never had that problem after switching to the 64bit version
[19:47] <LaserJock> bryce: it just seems to lock up when I do too many things at once
[19:48] <Keybuk> because of the move of udev from /etc/udev/rules.d to /lib/udev/rules.d it became important that things don't muck around with udevadm while udev is mid-air
[19:48] <slangasek> kees: ok, how's odt2txt look to you for a MIR candidate?  (would like to know if it has a shot before writing up the MIR)
[19:48] <kees> jcole: agreed.
[19:48] <jcole> kees: if you ask me, the 32bit plugin is unstable
[19:48] <Keybuk> ie. Depend on udev if you use it
[19:48] <kees> jcole: I blame nspluginwrapper :)
[19:48] <jcole> kees: it also locks up my sound card
[19:48] <Keybuk> and as a result, Depend on initramfs-tools too
[19:48] <kees> slangasek: one sec
[19:48] <kees> jcole: that I blame on pulseaudio.  ;)
[19:51] <jcole> kees: even though the 64bit version is "beta", its more stable than the 32bit version... so why not put a more stable version in the repos for 64 bit users?
[19:52] <slangasek> because we're releasing in three weeks and are not going to rearrange the package based on one anecdotal report that the 64-bit version is more stable
[19:52] <slangasek> sorry, two weeks
[19:53] <kees> slangasek: ntfs-3g uploaded
[19:54] <slangasek> ok, will snag it
[19:54] <kees> jcole: asac is the best person to answer that; he has a plan for what will be happening in karmic
[19:54] <kees> slangasek: odt2txt looks probably okay, though I'm cringing at the embedded zip processor...
[19:56] <jcole> slangasek: understood, and another name could be ia64-flashplugin-nonfree... the reason of it not being in repos because its "beta" doesnt make sense to ,e when we have lots of other experimental software in the repos (ie: samba4)
[19:56] <jcole> s/,e/me
[19:57] <kees> (jcole: ia64 != x86_64)
[19:57] <jcole> kees: heh, sorry
[19:57] <jcole> kees: i didnt mean itanium
[19:57] <kees> jcole: anyway, the issue is that no one stepped up to handle it in jaunty
[19:58] <kees> jcole: asac has plans for doing it karmic though
[19:59] <IntuitiveNipple> kees: looks like fuse-utils is affected too
[19:59] <slangasek> right; samba4 is there because there's a Debian maintainer for it, whereas for flash we have a hard enough time getting one package maintained sensibly
[20:01] <Stskeeps> http://s41.radikal.ru/i094/0904/90/4db739743759.jpg
[20:01] <Stskeeps> err. sorry, ignore that
[20:01] <Keybuk> pretty
[20:01] <kees> IntuitiveNipple: I see initramfs-tools in the depends for fuse-utils
[20:02] <Keybuk> kees: weird, I don't
[20:02] <kees> Keybuk: fuse-utils -> udev -> initramfs-tools
[20:02] <IntuitiveNipple> kees: hmmm, strange
[20:02] <Keybuk> ah, good point
[20:02] <Keybuk> yes, it's fine to depend on udev or initramfs-tools
[20:02] <alex-weej_> is Hibernate supposed to use a normal file if no swap partition is enabled?
[20:03] <Keybuk> alex-weej_: no
[20:03] <kees> Keybuk: so you're saying a package must declare its own Depend on udev/initramfs-tools if it uses it, not just via a recursive depend?
[20:03] <alex-weej_> Keybuk: ok, critical bug in jaunty then
[20:03] <Keybuk> alex-weej_: which is critical?
[20:03] <Keybuk> kees: recursive is fine
[20:03] <Keybuk> kees: dpkg postinst ordering reasons, not esoteric
[20:04] <kees> Keybuk: okay, then I think my cmdline above should find them all, and only ntfs-3g popped out
[20:04] <slangasek> it's not "fine", it's brittle; it works as long as the recursive depends is there
[20:04] <Keybuk> alex-weej_: are you saying that hibernate is creating a file for you?
[20:04] <slangasek> and starts failing as soon as the thing you were relying on to do the depending for you no longer does
[20:04] <alex-weej_> Keybuk: i accidentally hit Hibernate instead of Suspend in FUSA menu, something printed on the console "no swap partition enabled, try swapon -a" but the disk just churned away for > 10 minutes before i gave up and forced a reboot
[20:04] <alex-weej_>  = lost data
[20:04] <Keybuk> alex-weej_: that doesn't sound that Critical to me
[20:05] <alex-weej_> data loss = critical
[20:05] <Keybuk> it sounds like "don't do that then" with a low or medium bug
[20:05] <Keybuk> then it's a critical bug that Ubuntu loses data if I hit my computer with a lump-hammer?
[20:05] <Keybuk> *you* powered off your computer
[20:05] <Keybuk> if you'd left it alone, it might have recovered
[20:05] <Keybuk> and I'd be surprised if it lost data in the process, hibernate usually involves a sync
[20:05] <kees> slangasek: if that's so, then these need something: watershed cryptsetup dmsetup kbd linux-ubuntu-modules-*
[20:05] <slangasek> kees: those all invoke update-initramfs but don't depend on initramfs-tools?
[20:06] <alex-weej_> Keybuk: what on EARTH could it be doing to my disk for 10 minutes? i was more worried that it was writing RAM to my data partitions than anything else
[20:06] <kees> $ grep update-initramfs cryptsetup.*
[20:06] <kees> cryptsetup.postinst:	if [ -x /usr/sbin/update-initramfs ]; then
[20:06] <kees> cryptsetup.postinst:		update-initramfs -u
[20:06] <kees> $ apt-cache show cryptsetup | grep Depends
[20:06] <kees> Depends: libc6 (>= 2.8), libdevmapper1.02.1 (>= 2:1.02.20), libgcrypt11 (>= 1.4.0), libgpg-error0 (>= 1.4), libpopt0 (>= 1.14), libuuid1 (>= 1.05), dmsetup
[20:06] <Keybuk> alex-weej_: it wouldn't have done that, it's more likely it was simply paging
[20:06] <slangasek> linux-ubuntu-modules-* no longer exists
[20:06] <alex-weej_> i don't have a swap partition
[20:06] <alex-weej_> how could it page?
[20:07] <IntuitiveNipple> It's bug #358654
[20:07] <Keybuk> alex-weej_: it can still flush the cache and then have to reload everything file-backed from disk
[20:07] <slangasek> kees: dmsetup doesn't appear to even recursively depend on initramfs-tools?
[20:07] <alex-weej_> it doesn't take 10 minutes to bring my system up from cold
[20:08] <kees> slangasek: odd, my lum is purged, but I still have dpkg info files for it.
[20:08] <Keybuk> alex-weej_: by all means file a bug
[20:08] <Keybuk> but please realise that it's *NOT* critical
[20:08] <cody-somerville> Does amd64 use the generic kernel?
[20:08] <Keybuk> cody-somerville: amd64 has its own kernel
[20:08] <slangasek> it has its own kernel, which is called "-generic"
[20:08] <kees> slangasek: ah! apt-cache depends is following Breaks
[20:08] <slangasek> kees: right :)
[20:08] <Keybuk> alex-weej_: you powered off your own machine - so at best, you could file a critical bug on yourself ;)
[20:09] <cody-somerville> Keybuk, whats it called?
[20:09] <cody-somerville> linux-amd64 doesn't seem to exist
[20:09] <Keybuk> cody-somerville: generic iirc
[20:09] <kees> cody-somerville: linux-generic
[20:09] <slangasek> Keybuk: how long should one sit in front of a hung machine before it's reasonable to conclude it's not coming back, then?
[20:09] <alex-weej_> Keybuk: by that logic any bug that causes a system hang but doesn't kill the power is not critical
[20:09] <IntuitiveNipple> cody-somerville: it's a different arch; same package names
[20:10] <Keybuk> alex-weej_: you said the disk was active
[20:10] <Keybuk> doesn't sound like a hang, simply sounds like it was busy
[20:10] <Keybuk> it's certainly a bug
[20:10] <alex-weej_> Keybuk: and in a normal "hang" situation, it's difficult to tell whether anything is "active"
[20:10] <alex-weej_> well the keyboard fails to respond
[20:11] <kees> Keybuk, slangasek: list seems to include: dmsetup cryptsetup kbd watershed.  shall I shove each of those?
[20:12] <IntuitiveNipple> kees: do you want to add them to the bug report, or shall I? They're currently in a comment
[20:12] <kees> IntuitiveNipple: I can add them
[20:12] <IntuitiveNipple> kees: ok
[20:13] <IntuitiveNipple> Do we have a way to search the archive to identify other packages that we may not have installed that also need patching?
[20:14] <kees> Keybuk: watershed only Recommends udev -- was there a reason to try to keep its Depends light?
[20:16] <kees> Keybuk: and cryptsetup has initramfs-tools as a Suggests
[20:18] <kees> slangasek: let me know what you think; I'm nervous to make these changes post-freeze for the less-obvious cases.
[20:19] <slangasek> kees: Depends is the only way to enforce package configuration prior to the postinst being run, which is what we're trying to achieve; I think these are all "obvious" cases
[20:19] <kees> slangasek: okay
[20:21] <kees> slangasek: and you think I should even add it for those that Depend on udev already?
[20:22] <slangasek> kees: I think those are not worth bothering with right now because the transitive dep does take care of it
[20:22] <slangasek> but we should eventually fix those rather than relying on another package to guarantee us something we should be depending on directly
[20:30] <dendrobates> slangasek: soren did not actually up load eucalyptus, he wanted approval first.  it is on chinstrap chinstrap:~soren/upload/  and in his ppa.
[20:30] <dendrobates> slangasek: sorry for the bad information.
[20:30] <slangasek> is it signed?
[20:32] <dendrobates> slangasek: yes.
[20:32] <slangasek> dendrobates: could you throw it at the queue for me? :)
[20:32] <dendrobates> slangasek: yes.
[20:40] <kees> slangasek: cryptsetup, devmapper, kbd, watershed all uploaded.
[20:44] <dendrobates> slangasek: uploaded
[20:44] <IntuitiveNipple> kees: looks like just in time another user is reporting it too
[20:45] <IntuitiveNipple> and there were two others that came and went before we could investigate this afternoon, too
[21:16] <geser> anyone here using (g)vim and bicyclerepair?
[21:25] <gopogo> ubuntu jaunty is  not detecting windows during installation
[21:26] <gopogo> why its nort detecting windwows during installation
[21:32] <hyperair> gopogo: dunno, but this isn't the right place. head to #ubuntu.
[21:32] <hyperair> gopogo: sorry i meant #ubuntu+1
[21:32] <hyperair> you might like to file a bug too
[22:00] <dtchen> hyperair: yes, i'll queue it, thanks
[22:00] <hyperair> dtchen: alright thanks
[22:10] <DBO> bryce, do you mind talking a bit of intel xorg with me?
[22:11] <DBO> erm, actually I'll take this to #ubuntu-x
[22:18] <ScottK> cprov: Would you please tell me why usplash no longer gets built on ia64?
[22:19] <pwnguin> itanium?
[22:19] <ScottK> Yep.
[22:19] <cprov> ScottK, I don't know, but i can quickly check for you.
[22:19] <ScottK> cprov: Thanks.
[22:19] <kirkland> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/nut/+bug/357583
[22:19] <kirkland> slangasek: trivial debdiff attached, ubuntu-release subscribed
[22:20] <cprov> ScottK: pas-ed -> %usplash: amd64 armel i386 lpia powerpc sparc
[22:22] <slangasek> dendrobates: oh, in fact, eucalyptus was uploaded already
[22:23] <dendrobates> slangasek: yeah, I misuderstood sorens message.
[22:24] <slangasek> well, I'll just review the one of them. :)
[22:24] <ScottK> cprov: Thanks.
[22:24] <slangasek> kirkland: ack
[22:24] <cprov> ScottK: usplash was recently enabled for lpia, last time it was allowed to build in ia64 was in hardy
[22:24] <cprov> https://edge.launchpad.net/ubuntu/hardy/+source/usplash/0.5.19
[22:24] <ScottK> cprov: We've got the same problem on ia64.
[22:24] <kirkland> slangasek: ack = message received, or go ahead with upload?
[22:25] <slangasek> kirkland: well, both; no reason to wait for review prior to uploading to the queue
[22:25] <kirkland> slangasek: synack
[22:34] <dtchen> hyperair: i'll just reopen 202089 and sub the relevant parties
[22:35] <hyperair> dtchen: okay
[22:48] <dtchen> slangasek: do you prefer that i subscribe ubuntu-main-sponsors for https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/202089/comments/127 ?
[22:55] <slangasek> lool, persia: the VFP-optimized libs are still 'in progress'?
[22:56] <lool> slangasek: 2 are in the canonical-arm-dev PPA, but gtk+ doesn't want to complete building
[22:56] <persia> slangasek, I'm hoping to pass the other two to lool today for testing there as well.
[22:56] <slangasek> which 2 are in the PPA right now?
[22:56] <slangasek> more to the point, why are they not uploaded to jaunty?
[22:57] <slangasek> dtchen: prefer relative to what?
[22:57] <persia> slangasek, pango and gtk+, and because they might break something.
[22:57] <dtchen> slangasek: simply finding a sponsor
[22:57] <lool> slangasek: Actually gtk+ just built an hour ago
[22:58] <slangasek> persia: but, er, of course they might break something; if they're going to be uploaded to jaunty at all, it should be sooner rather than later?
[22:58] <slangasek> dtchen: ah; then I have no preference at all, unless you're trying to tag me to be a sponsor ;)
[22:58] <persia> slangasek, OK.  I'll just seek sponsorship for the other two, rather than passing them through lool.
[22:59] <lool> slangasek: I wanted to run them before pushing to the archive and perhaps breaking builds etc.
[23:00] <slangasek> lool: if you're specifically concerned that the new packages are going to break arm itself, then that's fine, do what you need to in order to QA them - if it was a question of general breakage, though, better to get more eyeballs on the packages
[23:01] <slangasek> but in any case, they need to get to the archive soon
[23:01] <radix> slangasek: hi, I have (sad to say) some changes that I'd like to nominate for jaunty for landscape-client. they're bugfix-only. I've prepared everything: should I subscribe ubuntu-release to the bug?
[23:01] <lool> slangasek: My plan was to upload them to PPA, run them, push to archive; cdimage/debian-cd kept me busy and gtk took longer to build than expected, so it's not done yet, sorry
[23:01] <slangasek> radix: if they're bugfix-only, please get the package uploaded to jaunty and it can be reviewed from there in the unapproved queue
[23:02] <radix> slangasek: oh, okay, so I'll get a regular main uploader to do that?
[23:02] <slangasek> lool: sounds like things are on track from here, so no worries
[23:02] <slangasek> radix: yes
[23:02] <radix> sorry for the distraction. thanks very much
[23:05] <Keybuk_> I like hard locks just before RC
[23:07] <radix> are there any main sponsors that could take a look at bug #358744 for me?
[23:18] <lool> slangasek: Pushed pango; gtk failed QA (missing one substitution, so I've pushed it again)
[23:19] <slangasek> ok