[00:24] <blue0488> how do you get freenode chat in empathy?
[01:11] <TheMuso> pitti: Thanks for that synaptic invocation code, however I am dealing with C++ which means I will have to do a little more fiddling to get the same functionality, and since its a universe package, I am more enclined to simply disable the install functionality of paprefs.
[01:47] <trip0> how does xsplash work?
[01:47] <trip0> does it require gdm?
[02:09] <TheMuso> trip0: Gdm loads xsplash via dbus when gdm starts, then the session script loads xsplash when the user logs in using gdm.
[02:09] <TheMuso> trip0: I think thats how it works anyway.
[02:12] <trip0> TheMuso: so [login-manager] needs to start xsplash via dbus
[02:12] <trip0> is xsplash a deamon or somthing?
[02:12] <trip0> daemon*
[02:29] <TheMuso> trip0: Not sure. I think gnome-session signals it to be killed over dbus though.
[03:25] <ion> keybuk: Here’s an untested implementation. It probably breaks your system and leaks memory, but it’s a start. Hey, at least it compiles without warnings. :-P http://heh.fi/patches/mountall/
[03:26] <ion> keybuk: I’ll have a better capability to test mountall patches as soon as i can get my system to run *some* version of mountall. ;-)
[03:26] <ion> keybuk: As in, boot using it
[06:03] <dholbach> good morning
[06:07]  * slangasek waves
[06:07] <dholbach> hiya slangasek
[06:11] <liw> hello, mister Holbach, mister Langasek
[06:12] <dholbach> Señor Wirzenius?
[06:12] <dholbach> Como estas? :)
[06:12] <liw> que? :)
[06:21]  * poningru provides a flower for dholbach to wear
[06:51] <poolie> could i get some ubuntu python maintainers to look at bug 392355?
[06:51] <poolie> it seems to fairly seriously break programs that build compiled extensions on karmic
[07:25]  * YokoZar has been waiting for python2.6 binary to be in sync with source package version so he can update ia32-libs all day now...
[07:27] <dholbach> https://edge.launchpad.net/ubuntu/+source/python2.6/2.6.2-0ubuntu4/+build/1188649
[07:27] <dholbach> Missing build dependencies: libreadline6-dev
[07:28] <dholbach> YokoZar: ^
[07:28] <YokoZar> Hmm yeah...should that take all day?
[07:28] <YokoZar> Since the depend needs to finish first
[07:28] <dholbach> the build depends is missing
[07:29] <YokoZar> Does that mean the build depends is being rebuilt?
[07:29] <dholbach> aha
[07:29] <dholbach> https://edge.launchpad.net/ubuntu/+source/readline6
[07:29] <dholbach> it's in universe
[07:29] <dholbach> python2.6 is obviously in main
[07:30] <dholbach> not sure that requires a MIR
[07:30] <dholbach> but it's something the archive admins should look into
[07:30] <pitti> Good morning
[07:30] <dholbach> hopefully we won't have 2 readline versions in main for karmic
[07:30] <dholbach> hi pitti
[07:31] <pitti> TheMuso: OOI, how is it harder in C++? Anyway, I'm fine with just disabling it
[07:33] <YokoZar> So this is basically a chain of 5 blockers that lead me to readline6 now: Some patches to wine (failing to build) --> needs ia32-libs update --> needs new python2.6 --> needs libreadline6-dev --> needs an MIR
[07:35] <pitti> YokoZar: just needs a MIR bug, not a full wiki page; it's just a new version after all
[07:35] <YokoZar> Ahh ok
[07:35] <YokoZar> Poke doko for me he caused this ;)
[07:41] <slangasek> pitti: OTOH, does this mean we're stuck with two versions of readline on the CDs now, or is someone taking responsible for transitioning us to readline6?
[07:41] <slangasek> heh, "taking responsible"
[07:41] <pitti> slangasek: wine isn't on the CD?
[07:41] <YokoZar> no but python2.6 is
[07:41] <slangasek> pitti: readline6 needs an MIR because of python2.6; everything else uses readline6
[07:41] <pitti> ah, I see
[07:41] <slangasek> 5
[07:41] <YokoZar> The only thing this has to do with Wine is that python2.6 failing to build is blocking ia32-libs
[07:41] <pitti> $ apt-cache rdepends libreadline5|wc -l
[07:42] <pitti> 325
[07:42] <pitti> we might not finish that in karmic..
[07:42] <slangasek> yep - so why do we want to start it, I wonder
[07:42] <pitti> it's an extra 150 kB, so it won't kill us, but perhaps it's possible to build python2.6 with libreadline5?
[07:43] <slangasek> the change was made in an Ubuntu point revision - so yes, it should be possible
[07:43] <pitti> right, in http://launchpadlibrarian.net/30822021/python2.6_2.6.2-0ubuntu3_2.6.2-0ubuntu4.diff.gz
[07:44] <pitti> that pulled in new upstream code
[07:44] <slangasek> ah, hmm
[07:44] <slangasek> mvo: morning!
[07:44] <pitti> but nothing that seems to check the version of libreadline
[07:44] <mvo> hey slangasek
[07:44] <slangasek> mvo: does it alarm you if I greet you eagerly? :-)
[07:45] <YokoZar> We could just try an upload with the older version and see if it still works ;)
[07:45] <mvo> slangasek: it does :P
[07:45] <pitti> slangasek: so yes, should be possible
[07:45] <slangasek> mvo: do you think you could take a look at https://launchpad.net/ubuntu/+source/vips/7.18.1-1ubuntu3/+build/1207710 ? regression introduced by the zlib1g change, only affects !64-bit archs :/
[07:45] <YokoZar> slangasek  has a pile of work for mvo I bet
[07:45] <mvo> slangasek: startling even
[07:45]  * slangasek grins
[07:45] <mvo> slangasek: *weh* sure, I have a look
[07:46] <slangasek> mvo: in the future I will try to greet you eagerly when I'm not asking you to do work
[07:46] <slangasek> to put you more at ease
[07:46] <YokoZar> (and lull you into a trap)
[07:46] <mvo> :)
[07:47]  * mvo makes a pot of tea and attacks the zlib problem
[07:47] <poolie> mvo, over here
[07:47] <poolie> i was just going to ask you about https://edge.launchpad.net/ubuntu/+source/python2.6/2.6.2-0ubuntu4/+build/1188649
[07:47]  * mvo waves to YokoZar
[07:48] <pitti> slangasek: I'll change python2.6
[07:48] <slangasek> pitti: ok
[07:48] <mvo> pitti: so you take care of the above build-failure?
[07:49] <mvo> (or is there another python2.6 change in the works)
[07:49] <pitti> mvo: it's in depwait
[07:49] <pitti> mvo: or what do you mean?
[07:49] <mvo> pitti: it seems that libreadline6-dev is in universe
[07:49] <pitti> mvo: right, that's what we just discussed, I'll change it back to 5
[07:50] <mvo> pitti: thanks, I missed the earlier part of the discussion (joined too late)
[07:50] <mvo> poolie: ^--- pitti deals with it :)
[07:50]  * pitti hugs mvo
[07:50]  * pitti hugs poolie, too
[07:50]  * mvo hugs pitti
[07:50] <pitti> poolie: you wrote an awesome VCS, you deserve some help :-P
[07:51] <YokoZar> pitti: thanks ;)  Nice to have the german crew working on this through the night
[07:51] <pitti> "night"?
[07:51] <pitti> I already slept in, until 8:30..
[07:51] <YokoZar> Yes, real time is where I live.
[07:52] <poolie> :)
[07:52] <poolie> thanks pitti
[07:53] <poolie> i don't desperately need it fixed but i'd like if someone could at least triage it
[07:58] <YokoZar> slangasek: what do you think of including some of the various thumbnailers that are stuck in universe onto the CD?
[07:58] <slangasek> eh?
[07:58] <slangasek> I think this is late in the cycle to be proposing new features to squeeze onto the CD
[07:59] <YokoZar> Well one I proposed at UDS (gnome-exe-thumbnailer)
[07:59] <YokoZar> but when I was making it I found gnome-raw-thumbnailer (gives thumbnails of digital camera raw files) and two other minor ones
[08:06] <poolie> pitti, mvo, so how about https://launchpad.net/bugs/392355 (sorry to nag)
[08:08] <slangasek> YokoZar: installing gnome-exe-thumbnailer pulls in 600K of installed packages onto my system when I try to install it; this really should have been seeded earlier in the cycle, IMHO
[08:09] <slangasek> YokoZar: you can file a bug against ubuntu-meta and/or start a discussion on ubuntu-devel -- either of those is better than trying to persuade me personally to seed it :)
[08:09] <YokoZar> How about I give up in despair and come to the next UDS with a petition to switch to memory sticks and DVDs ;)
[08:10] <mvo> poolie: no problem, its more a doko type question, but I can have a look too. I probably need a bit (because I need to compare old/new python-defaults)
[08:10] <poolie> cool, thankyou
[08:11] <cjwatson> oh, I reassigned it to python2.6 on the assumption that it was probably a problem with the code there
[08:11] <cjwatson> if it belongs on python-defaults after all, feel free to reassign it back ...
[08:13] <YokoZar> Does ubuntu have anything like a build/test farm for different arches that developers can get shell access to?  I seem to remember Debian having something like this
[08:15] <slangasek> Canonical has porter machines that employees can access; unfortunately there are no porter machines open to the Ubuntu community
[08:17] <YokoZar> slangasek: thanks
[08:22] <pitti> slangasek: hm, python2.6 is FTBFS
[08:22] <pitti> make[1]: *** No rule to make target `libpython2.6.so', needed by `python'.  Stop.
[08:22] <pitti> but nothing that points to the libreadline change..
[08:22] <slangasek> yuck?
[08:22] <pitti> so I better not upload this
[08:22] <slangasek> if you insist :-)
[08:23]  * pitti uploads to his PPA to check whether it's some local issue
[09:20] <liw> hm, the new gdm greeter in karmic does not have any (visible?) way to invoke failsafe sessions
[09:20] <liw> gnome-session: Fatal IO error 11 (Resurssi ei tilapäisesti ole käytettävissä) on X server :0.0.
[09:20] <liw> that's ... intriguing
[09:21] <pitti> liw: choose a user, then choose xterm session?
[09:21] <liw> pitti, how do I choose xterm session?
[09:21] <pitti> liw: in the session chooser in the bottom bar
[09:22] <liw> I haven't got one
[09:22] <pitti> liw: did you choose a user first?
[09:23] <liw> er, sorry, mea culpa
[09:23] <liw> (that was confusing to me)
[09:23] <liw> anyway, the real problem is that my SO's account can't log in
[09:25] <liw> this has been going on for a few days, but I've only had time to look at it now
[09:30] <liw> hm, I created another account, and it, too, fails to log in via gdm
[09:33] <poolie> hi liw
[09:33] <poolie> thanks for looking at it cjwatson
[09:33] <liw> hi poolie
[09:34] <dpm> hi pitti, good morning. Thanks for copying the listed jaunty langpacks to -updates. May I ask you to also copy the 'es' language pack? The Spanish guys did some last minute testing and posted a message on the list (http://tinyurl.com/m87dto), but they didn't CC you. It would be quite good to have it in -updates, since that particular one solves quite a lot of bugs (sorry for not getting the list of languages all at once)
[09:35] <pitti> dpm: done
[09:35] <dpm> pitti: thanks!
[09:48] <liw> does anyone else have a problem with logging in with accounts other than their own? (easy to test: create new account with 'adduser tomjon' and then switch user to it)
[09:49] <liw> bug #426159 is the one I reported about this
[09:51] <seb128> no issue there to log with different accounts
[09:51] <seb128> and gnome-session didn't change for a while I doubt it's due to it
[09:51] <seb128> look into your Xorg.n.log?
[09:52] <seb128> the .xsession-errors has lot of display not available errors, could be xorg crashing for you
[09:54] <liw> why would it crash for tomjon but not liw?
[09:55] <davmor2> liw: it doesn't like tomjon
[09:56] <seb128> does it crash for tomjon if you try to start that session first?
[09:56] <seb128> it could be a "second xorg session is crashing" sort of issue
[09:56] <liw> seb128, I did not have another session open when logging into tomjon
[09:56] <seb128> ok so I don't know
[09:56] <seb128> would be useful to have gnome-session debug log
[09:57] <seb128> do you get the issue if you run gnome-session?
[09:57] <liw> how do I get a gnome-session debug log? how do I run gnome-session?
[10:00] <mvo> slangasek: so, the problem with the zlib stuff is that off64_t is not defined on 32bit machines unless USE_LARGEFILE64 is used. I can add a #if _FILE_OFFSET_BITS ==64 && !defined(_LARGEFILE64_SOURCE) #define off64_t off_t #endif #endif - also I have to say that I don't really like this, its getting ugly and this messing around is not to my liking
[10:01] <seb128> liw, start a non GNOME session either by selecting the debug one in gdm or using startx
[10:01] <seb128> liw, and run gnome-session --debug
[10:08] <liw> seb128, attached to bug
[10:08] <seb128> looking
[10:09] <liw> seb128, and it got reassigned to xorg-server
[10:09] <seb128> right, chrishcoulson seems to think the same thing than me
[10:10] <seb128> liw, when you run gnome-session by hand does it start normally?
[10:11] <seb128> liw, do you use compiz for your normal user?
[10:11] <liw> seb128, nope, it dies before anything shows up (like panels), in a few seconds
[10:11] <seb128> liw, can you start the debug session and just run compiz there?
[10:12] <seb128> I would say that compiz makes your xorg crash
[10:12] <seb128> you might not be using it with your normal configured session?
[10:12] <liw> seb128, I use metacity with my account liw, not compiz; compiz won't start on this machine
[10:12] <seb128> well the gnome-session log shows that it tries starting
[10:12] <liw> I'll see what starting it manually does
[10:12] <seb128> thanks
[10:13] <seb128> if that crashes xorg you know what the difference and the issue is
[10:14] <liw> it's dead. dead I tell you. dead, dead, dead. dead as a 3D accelerated dodo.
[10:14] <liw> i.e., X crashes after running compiz manually from tomjon's xterm session
[10:16] <seb128> liw, ok, so it's an xorg bug, adding the Xorg.0.log to the bug would be useful
[10:16] <seb128> look to /var/crash too if there is a .crash about it
[10:16] <seb128> compiz does some capability detection on start but that should not crash xorg
[10:17] <liw> removing compiz does not prevent the problem, though
[10:17] <seb128> how removing it?
[10:18] <seb128> you can run gconf-editor and change /desktop/gnome/session/required_components/windowmanager
[10:18] <mvo> cjwatson: could you please double check http://paste.ubuntu.com/267107/ ? it fixes a ftbfs for 32bit plattforms where off64_t is not always defined (I'm not too happy about it, but I don't see a really cleaner way - testing #if __off64_t_defined would be possible but even more ugly)
[10:18] <liw> I removed the compiz package
[10:18] <seb128> it's gnome-wm by default which tries to be clever but you can set any wm you want there
[10:19] <liw> oh, but there's a million compiz packages
[10:20] <liw> there, removing all of them fixed it
[10:21] <mvo> cjwatson: alternatively we can just revert my upload and see what upstream comes up with
[10:22] <seb128> liw, still add your xorg infos to the bug it should not crash
[10:22] <liw> seb128, I already did
[10:22] <seb128> ok
[10:29] <sistpoty|work> mvo: I guess you should at least at !defined(off64_t) to it, so that zlib.h can be included twice
[10:29] <sistpoty|work> add even
[10:31] <cjwatson> mvo: I think I'd prefer it if we had a zlib_off64_t define which is defined to off_t [_FILE_OFFSET_BITS=64] or off64_t [_LARGEFILE64_SOURCE], rather than scribbling over off64_t itself
[10:32] <cjwatson> mvo: seems less likely to cause failures elsewhere
[10:32] <cjwatson> mvo: (adjust name of zlib_off64_t to whatever seems locally suitable, of course)
[10:32] <mvo> cjwatson: yeah, that makes sense, I create a new diff now
[10:32] <mvo> sistpoty|work: thanks
[10:32] <cjwatson> the problem with #define off64_t is that off64_t is actually a typedef elsewhere
[10:32] <cjwatson> and so it seems likely that you'd create weirdness ...
[10:34] <mvo> cjwatson: agreed, I did test, but of course not all cases, so being careful is better
[10:46] <mvo> cjwatson: does http://paste.ubuntu.com/267126/ look ok?
[10:47] <liw> would it be simpler to just #include sys/types.h or whatever defines off*_t? or is that harmful from namespace pollution reasons?
[10:48] <liw> oh, no, I misunderstood the probelm
[10:48] <cjwatson> mvo: yeah, that's what I was thinking and looks better to me
[10:49] <mvo> cjwatson: great, thanks a lot for your review
[10:51] <geser> btw: just curious why does it happen at all on 32bit? from a quick look at features.h and unistd.h off64_t should be defined in the _LARGEFILE64_SOURCE case?
[11:15] <cjwatson> geser: you've got it the wrong way round; it happens on 32-bit and when _FILE_OFFSET_BITS=64 but *not* _LARGEFILE64_SOURCE
[11:16] <cjwatson> _FILE_OFFSET_BITS=64 means "just make everything 64-bit, don't bother with the separate *64 versions of things"
[11:21] <geser> ah
[11:31] <lool> Is there a way to do a touch in a patch?
[11:31] <pitti> lool: not that I know of; but you could patch the file to just have a newline or so?
[11:32] <lool> Yeah, I was looking for something a bit more elegant but that will do
[11:33] <lool> thanks
[12:30] <TheMuso> pitti: Well not harder, just got to do things differently.
[12:51] <Keybuk> the PPA system hates me, it keeps giving my builds scores like "4" and says it'll build in 27 weeks
[12:52] <Daviey> Keybuk: you need to pay, and get a private PPA with automatic natural scores :)
[12:52] <maxb> I thought 4 was the special score auto-assigned to rebuild archives?
[12:52] <Keybuk> Daviey: fortunately being a TB member means I can fiddle the scores myself ;)
[12:53] <maswan> Keybuk: Buy a new shiny bladecenter full of neat bl460c g6 blades with plenty of ram, those are speedy. ;)
[12:53] <Keybuk> maswan: ?! on my salary !!
[12:53] <Daviey> Keybuk: hah
[12:53] <maswan> (also, gives incentive to someone else to fix the issues I've found so far ;) )
[13:12] <hyperair> seb128: did you request a sync, or should i?
[13:12] <seb128> neither of those, I will sync it today I was waiting for the binary to be on the mirrors
[13:17] <hyperair> ah. okay then
[13:23] <TomaszD> hyperair, hey. So, how about fixing another translation problem today huh? :) gdebi is ready and waiting :P
[13:24] <seb128> ready to what?
[13:32] <hyperair> TomaszD: maybe next week
[13:33] <TomaszD> seb128, to get fixed ;)
[13:33] <TomaszD> hyperair, ok
[13:33] <hyperair> if nobody has already fixed it by then =)
[13:33] <hyperair> out of curiosity, what's wrong with gdebi?
[13:34] <TomaszD> hyperair, not really sure, seems to be that there are similar symptoms to nautilus-share
[13:34] <TomaszD> but not much else I can tell
[13:40] <hyperair> it's probably a one-liner change
[13:40] <hyperair> lemme test this out
[13:42] <hyperair> TomaszD: as i thought. a one-liner change.
[13:42] <hyperair> TomaszD: today's your lucky day. i got gdebi fixed =)
[13:43] <TomaszD> hyperair, awesome! thanks!
[13:43] <hyperair> is there a bug for this?
[13:44] <TomaszD> hyperair, https://bugs.launchpad.net/ubuntu-translations/+bug/425812
[13:44] <TomaszD> hyperair, I'm curious, was that a POTFILES.in breakage?
[13:44] <hyperair> TomaszD: no. not at all.
[13:45] <hyperair> TomaszD: gtkbuilder is a screwed thing when it comes to translations. =\
[13:45] <TomaszD> well it's a good thing the whole GNOME project isn't moving to... well shit
[13:45] <hyperair> seb128: if i'm going to have to manually set_translation_domain for every gtk builder object i have, i believe gtkbuilder is the one at fault.
[13:46] <seb128> right
[13:46] <seb128> how did you fix the nautilus-share one?
[13:46] <hyperair> by setting the translation domain
[13:46] <hyperair> the same thing goes for gdebi
[13:46] <hyperair> i poked around totem's code and found that it also does the gtk_builder_set_translation_domain function
[13:47] <Keybuk> slangasek: system-config-printer's udev-configure-printer hook - does that *need* to be a udev hook?
[13:47] <Keybuk> slangasek: or, to phrase the question better
[13:47] <seb128> it's weird, other software work fine without that
[13:47] <seb128> ie update-manager, alacarte
[13:47] <Keybuk> does that binary do anything which could affect the configuration of the device in such a way that other applications or tools using that device should wait for it to be complete?
[13:47] <hyperair> seb128: seriously?
[13:48] <seb128> well I just looked to alacarte and it only does the gettext domain call
[13:48] <seb128> same for update-manager
[13:48] <hyperair> hmm
[13:48] <hyperair> how strange, eh..
[13:48] <hyperair> nowhere else?
[13:48] <hyperair> at all?
[13:48] <seb128> I think things coming from nautilus are special because nautilus change the gettext domain
[13:48] <TomaszD> seb128, neither update-manager nor alacarte work fine
[13:48] <seb128> but standalone applications should just work
[13:48] <TomaszD> alacarte is also broken
[13:48] <TomaszD> I just checked
[13:49] <seb128> TomaszD, categories are translated there
[13:49] <TomaszD> seb128, yes, but "Menus", "Items", all the buttons are not
[13:49] <hyperair> seb128: make sure you look at the parts that are *only* specified in the .ui file, not parts which are modified by the app
[13:49] <seb128> right
[13:49] <hyperair> seb128: nautilus-share and gdebi's issues were like that.
[13:49] <hyperair> and i don't think gdebi has any change of translation domains
[13:49] <seb128> right
[13:49] <hyperair> by the way, glade worked perfectly wrt translation domains
[13:49] <TomaszD> update-manager has the same problem really, it was just mudded slightly because the template wasn't regenerated
[13:50] <seb128> I'm wondering if pygtk is not broken
[13:50] <seb128> TomaszD, that has nothing to do with templates
[13:50] <hyperair> maybe a test app would be good..
[13:50] <TomaszD> I know, but the old strings which were translated a long time ago don't show up as translated seb128
[13:50] <seb128> TomaszD, and?
[13:50] <TomaszD> so that leads me to believe that there is an additional problem, ie. gtkbuilder one
[13:51] <seb128> well C softwares are not broken
[13:51] <hyperair> let's try gtkmm
[13:51] <TomaszD> alright, I thought update-manager was a python application, not a C app
[13:52] <seb128> it is a python application
[13:52] <TomaszD> ok, so it was just a general comment about C apps
[13:52] <seb128> ?
[13:52] <TomaszD> yours
[13:52] <TomaszD> nevermind :)
[13:52] <seb128> I say I didn't notice an issue with C softwares
[13:52] <seb128> so I would blame pygtk rather than gtk
[13:52] <TomaszD> right, that's what I was trying clumsily to refer to
[13:54] <TomaszD> what else is there using gtkbuilder, I believe computer-janitor and usbcreator need looking into as well
[13:57] <liw> TomaszD, er, what? what's up with c-j?
[13:58] <TomaszD> liw, sorry I'm losing track of my bug mail, it would seem you have fixed the issue
[13:58] <TomaszD> :)
[13:58] <liw> ok
[13:58] <seb128> doesn't seem a gtk issue in any case, ld preloading the jaunty version does no difference
[13:59] <TomaszD> liw, but! if this app is using gtkbuilder, you might want to look at the hints about about this "gtk_builder_set_translation_domain" thing
[13:59] <TomaszD> *above about
[14:00] <liw> I don't want to read through lots of backlog, please summarize
[14:00] <TomaszD> liw, "...i'm going to have to manually set_translation_domain for every gtk builder object i have..."
[14:01] <TomaszD> liw, might be a bug somewhere, but this seems to be a good workaround
[14:01] <seb128> that's not what he wrote exactly
[14:01] <seb128> and I would rather focus on finding the pygtk issue than workarounding every software
[14:02] <TomaszD> that's reasonable, but there is no guarantee of finding the issue, and shipping with untranslatable apps isn't a nice prospect, at least that's how I see it
[14:05] <liw> if it can't be fixed in pygtk, then file bugs, but please wait with that until pygtk is deemed unfixable for karmic
[14:05] <TomaszD> sure, I'll try to remember that
[14:07] <liw> thanks
[14:10] <seb128> TomaszD, why wouldn't it be fixable, there is months before karmic
[14:10] <seb128> I think it's a matter of debugging for one hour or so
[14:12] <TomaszD> seb128, you know, I'm freaking out because the release of GNOME is near (I'm an upstream translator), I'm probably influenced by that
[14:13] <seb128> TomaszD, we will have 2.28.1 in karmic
[14:13] <TomaszD> seb128, well that's a relief
[14:14] <seb128> TomaszD, http://bugzilla.gnome.org/show_bug.cgi?id=574520
[14:18] <soren> cjwatson: Bug #425922 looks like something in your domain to me. Would you agree?
[14:20] <TomaszD> seb128, so it's not a bug, it's just a specific way of handling translations?
[14:21] <cjwatson> soren: yes, probably
[14:21] <soren> cjwatson: Would you mind terribly if I reassigned bugs about the avahi magic in Eucalyptus to you?
[14:22] <seb128> TomaszD, not sure yet
[14:22] <TomaszD> ok
[14:23] <seb128> ogra__, could you push your tomboy changes to bzr?
[14:23] <cjwatson> soren: ok by me
[14:24] <ogra> seb128, is that really needed ? they should hit debian today with a new upstream
[14:24] <seb128> ogra: what? updating bzr when you upload a package maintained in bzr? yes
[14:24] <ogra> ok
[14:24] <seb128> the reason I ask it's because rodrigo ask us about it
[14:24] <ogra> ok
[14:24] <seb128> it seems to block him in online service changes
[14:25] <ogra> will do before end of my day
[14:25] <seb128> heh
[14:25] <seb128> rodrigo is waiting on it now
[14:25] <seb128> it's blocking him to do changes
[14:25] <ogra> i'm in meetings
[14:25] <seb128> *shrug*
[14:25] <seb128> if you don't do it properly please don't change desktop packages and ask for sponsoring next time
[14:26] <seb128> we will fix this one now
[14:26] <ogra> i'm on it
[14:26] <seb128> ok thanks
[14:26] <soren> cjwatson: Cool, will do.
[14:28] <engla> DktrKranz: Hey! kupfer-ping! Is it viable to update c10 in ubu karmic with a spanish translation file (complete). And should I make a c10.1 release or is c10-2 by you to prefer?
[14:33] <hyperair> seb128: gtkmm fails as well
[14:33] <seb128> I'm a bit puzzled by that
[14:33] <seb128> the jaunty gtk makes no difference
[14:34] <hyperair> see for yourself: http://dl.getdropbox.com/u/169656/testgtkbuilder-0.1.tar.gz
[14:35] <hyperair> i've only added pl.po translating "button" to "bla" for testing purposes, but you can copy it over to your locale and update LINGUAS to test
[14:35] <ogra> seb128, pushed
[14:35] <hyperair> seb128: ^^
[14:35] <seb128> ogra: thanks
[14:36] <blackxored> there will be improvements for flash in karmic?
[14:36] <seb128> hyperair, ok
[14:37] <directhex> seb128, do i need to do the full FFe paperwork for an upstream update to one of f-spot's deps?
[14:38] <seb128> directhex, which one?
[14:38] <directhex> seb128, flickrnet
[14:38] <seb128> directhex, no such source in karmic
[14:39] <Laney> seb128: libflickrnet
[14:45] <seb128> directhex, Laney: synced
[14:45] <Laney> you beaut
[14:45] <Laney> now we need to untransition f-spot
[14:46] <Laney> s/un//
[14:46] <directhex> Laney, what changes are there other than that? can it just be synced too?
[14:46] <Laney> no, there's some patch from lool that we didn't apply in sid
[14:46] <seb128> Laney, like direct sync from debian or do we have other changes?
[14:46] <seb128> ok
[14:46] <Laney> the gnome-screensaver fixes he did I didn't apply
[14:47] <seb128> I though that had been sent to debian too
[14:47] <seb128> I guess next round then
[14:47] <Laney> yeah I thought I'd wait for upstream
[14:47] <Laney> but there's no reason we couldn't apply them in patches/
[14:47] <Laney> but it's been uploaded to sid anyway so we need to merge
[14:49] <Laney> oh, those changes didn't get uploaded to Karmic... we could just sync if they aren't critical
[14:49] <Laney> seb128: what do you think?
[14:50] <seb128> let's sync and see if it builds? ;-)
[14:50] <Laney> it will build just fine, but lool wanted to avoid the gnome-screensaver build dep
[14:50] <Laney> sync+possible ubuntu1 sounds good to me
[14:51] <seb128> did debian add this one?
[14:51] <directhex> in this case "debian" is Laney
[14:51] <Laney> yeah, and its what is in 0ubuntu1 now
[14:51] <seb128> ok
[14:51] <seb128> directhex, I know but he's not uploader, the sponsor might do changes
[14:51]  * Laney doesn't know how important avoiding the build dep is
[14:52] <seb128> the build-dep is already in karmic so that will not change a lot
[14:52] <seb128> and it's minor, it's just to make the buildd work easier
[14:52] <Laney> ok then
[14:52] <lool> Laney: It's ok if it gets dropped in the end  :)
[14:52] <Laney> lool: It was applied upstream wasn't it?
[14:52] <lool> this stuff was merged upstream so just use the new configure flags when the new upstream release supports it
[14:53] <lool> Yes
[14:53] <Laney> will do then
[14:53] <lool> thanks
[15:03] <DktrKranz> engla: -2
[15:04] <engla> hey. ok
[15:09] <DktrKranz> engla: btw, did you contact upstream asking to integrate it?
[15:11] <DktrKranz> engla: c11 is out, I guess ulrik will release 12 soon, and I'll update it in Debian when that happens.
[15:12] <engla> DktrKranz: Pardon the missed introduction! ; I'm ulrik
[15:12] <DktrKranz> engla: whoops :)
[15:12] <engla> I should have said, hi, it's me
[15:13] <RainCT> Keybuk: I asked you before about D-Bus. Apparently there is a default timeout value which can be overriden when doing a call - do you happen to know where that is defined?
[15:13]  * DktrKranz kicks himself for not using /whois 
[15:14] <Keybuk> RainCT: in the headers
[15:14] <Keybuk> dbus/dbus-connection-internal.h:#define _DBUS_DEFAULT_TIMEOUT_VALUE (25 * 1000)
[15:14] <Keybuk> this is not a userspace interface
[15:15] <Keybuk> from the API, supplying "-1" for any timeout value means "the default"
[15:15] <Keybuk> supplying "0" means "immediately timeout"
[15:15] <Keybuk> supplying anything from 1...INT_MAX-1 means "this many ms"
[15:15] <Keybuk> and INT_MAX means "never timeout"
[15:16] <RainCT> Keybuk: thanks! :)
[15:17] <directhex> hm, by my sums, karmic's mono footprint is about the same as gutsy's, and over 10 meg smaller than intrepid's
[15:40] <superm1> slangasek, something went wrong with the hash sum mismatch in apt during the last mythbuntu cd build.  can you take a look at it? http://people.canonical.com/~ubuntu-archive/cd-build-logs/mythbuntu/karmic/daily-live-20090908.log
[15:45] <TomaszD> superm1, sorry to bother you, but where can I find the template for mythbuntu-control-centre or mythbuntu-common for karmic?
[15:45] <superm1> TomaszD, i'm not sure translation support is fully in place yet for karmic
[15:45] <superm1> everything got rewritten
[15:45] <TomaszD> superm1, oh, ok.
[15:45] <superm1> TomaszD, would you be able to help get things in order?
[15:46] <superm1> do you have experience with such things?
[15:46] <TomaszD> superm1, not really. I'm just a translator.
[15:46] <superm1> TomaszD, ah okay.  will try to let you know when things are sorted out then
[15:46] <TomaszD> superm1, but what needs to be done, is the gettext domain not set, are the strings not marked for translation?
[15:49] <superm1> TomaszD, since it's a universe package, the translations need to be shipped in it, and the package hasn't been prepped for that
[15:52] <TomaszD> superm1, if you don't hear from me then I wasn't able to do much
[15:52] <TomaszD> :)
[16:02] <Keybuk> huh
[16:02] <Keybuk> PPA has been saying "starting in 1 minute" for over an hour now
[16:02] <soren> A microsoft minute.
[16:03] <pitti> Keybuk: with a queue size of 468, good luck..
[16:03]  * amitk had heard of "A New York minute". What is a microsoft minute?
[16:04] <Keybuk> pitti: several of the buildds are sitting idle though
[16:05] <soren> amitk: It's hard to say. http://www.urbandictionary.com/define.php?term=Microsoft+Minute
[16:07] <YokoZar> pitti: Are you going to end up having to include libreadline6 for python2.6?
[16:16] <pitti> YokoZar: I think we can revert it back to 5
[16:16] <pitti> but it fails to build (for other reasons), so I can't actually upload it
[16:16] <pitti> this needs doko, I'm afraid
[16:17] <ogra> OMG we're screwed without doko !
[16:18] <ogra> (and /me wholeheartedly means it ... )
[16:19] <RainCT> uhm.. stupid question, why is the netbook remix download 950MB big?
[16:19] <pitti> absolutely
[16:20] <pitti> RainCT: it's just meant to be < 1 GB
[16:20] <pitti> RainCT: unlike ubuntu desktop, it's not meant to be distributed on CDs, but installed from USB stick
[16:20] <RainCT> but shouldn't it be smaller than the desktop thing?
[16:20] <pitti> just in resolution :)
[16:21] <pitti> (FWIW, I'd love if it was smaller...)
[16:21] <ogra> Riddell, more langpacks :)
[16:21] <pitti> ogra: tab disease
[16:21] <ogra> heh
[16:21] <ogra> RainCT, indeed
[16:21]  * sistpoty|work only has a 512 Mb USB stick and feels outdated... OTOH he doesn't have a netbook as well *g*
[16:22] <ogra> thanks for mentioning :)
[16:24] <RainCT> oh well, then have dynamic img generation for each language on request :P
[16:24]  * RainCT hides
[16:24] <RainCT> pitti, ogra: well, thx for the info
[16:25] <jdstrand> slangasek: hi! so I'd like to add some items to the release notes for karmic. I see https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview, but wasn't sure if that was the right place. (I feel like I am missing something obvious...)
[16:25] <ogra> RainCT, well, evand is such a slacker and didnt implement that yet in usb-creator :P
[16:25] <jdstrand> slangasek: where is the right place to add them?
[16:42] <seb128> is anybody around who has enough clue about -Bsymbolic-functions to understand why it makes evolution memos crash?
[16:43] <seb128> and would it be considered bad taste to build evolution without that option?
[16:47] <TomaszD> seb128, looks like alacarte got fixed upstream http://ftp.gnome.org/pub/GNOME/sources/alacarte/0.12/alacarte-0.12.3.news
[16:47] <TomaszD> :)
[16:47] <seb128> TomaszD, right, I discussed with cosimoc on IRC earlier
[16:47] <TomaszD> seb128, ah
[16:47] <seb128> I asked him to test on fc11 since he's using that
[16:48] <seb128> to make sure that was not an ubuntu bug
[16:48] <seb128> and he had the issue too
[16:52] <seb128> kees, hey, do you know about -Bsymbolic-functions? ;-)
[16:52] <sistpoty|work> seb128: -Bsymbolic-functions means that symbols (referring to functions) resolved within that thing won't be looked up dynamically iirc
[16:53] <seb128> sistpoty|work, <mbarnes> wonder if this is related to the fact that CompEditor is defined in a private library that both the main application and calender module statically links to
[16:53] <seb128> sistpoty|work, would that be an issue?
[16:53] <sistpoty|work> seb128: could well be
[16:54] <seb128> sistpoty|work, do you have any idea what would be the right way to fix that?
[16:54]  * seb128 is thinking to build without -Bsymbolic-functions for now
[16:54] <sistpoty|work> seb128: not without looking at the code actually... is any of these a weak symbol (and hence probably meant to be overriden by the other)?
[16:54] <seb128> I just fear to be tracked by the security team or whoever decided we need to set that on by default
[16:54] <seb128> dunno
[16:54] <seb128> http://bugzilla.gnome.org/show_bug.cgi?id=594473 is the issue
[16:55] <seb128> "(evolution:10798): GLib-GObject-WARNING **: cannot register existing type `CompEditor'"
[16:55] <seb128> is what is displayed when trying to open a memo on karmic
[17:14] <cjwatson> http://edos.debian.net/weather/ is a great visualisation
[17:14] <cjwatson> we should run this on Ubuntu
[17:15] <sistpoty|work> seb128: fwiw -Bsymbolic-functions indeed seems to cause this problem
[17:16] <sistpoty|work> seb128: the expansion of G_DEFINE_TYPE yields (among others) one non-static function: http://paste.ubuntu.com/267378/
[17:16] <sistpoty|work> seb128: which in turn registers the type, unless the static volatile variable is set
[17:17] <sistpoty|work> seb128: so if that function is resolved at runtime (as without -Bsymbolic-functions) it will resolve to the very same function and hence have the same static volatile variable
[17:18] <sistpoty|work> seb128: with -Bsymbolic-functions, these will be two different functions and hence two calls to  g_type_register_static_simple
[17:18] <sistpoty|work> (sorry, the g_type_register_static_simple is the next line, which I skipped already in pastebin)
[17:19] <sistpoty|work> seb128: but I wouldn't know by hand how to best solve this, apart from linking against the static library only once - if that's possible
[17:19] <seb128> ok, thanks for the explanations!
[17:19] <sistpoty|work> np
[17:19] <seb128> I think I will just turn the option for now as a workaround and let upstream deal with the build system changes
[17:19] <seb128> btw do you know why we have this flag on by default on ubuntu?
[17:20] <sistpoty|work> not really, maybe for faster loading times? But I guess kees certainly does know ;)
[17:21] <seb128> ok
[17:21] <seb128> sistpoty|work, thanks again!
[17:21] <sistpoty|work> no problem ;)
[17:23] <james_w> seb128: I believe the desired way to turn things of is to add an explanation to the CompilerFlags wiki page with the package name and a reference to the bug report that prompted the chane
[17:24] <james_w> https://wiki.ubuntu.com/CompilerFlags
[17:26] <seb128> james_w, thanks
[17:32] <cjwatson> pitti: I've unhosed the desktop package sets now - should be much more sensible-looking
[17:33] <pitti> cjwatson: nice, thanks! (If only I knew where to look in the first place.. :-) )
[17:33] <cjwatson> for the contents?
[17:34] <pitti> is it possible with edit_acls.py?
[17:34] <cjwatson> yes
[17:34] <cjwatson> ./edit_acl.py -P karmic-ubuntu-desktop query
[17:34] <cjwatson> for instance
[17:34] <cjwatson> sorry, any documentation that is present is more by luck than judgement
[17:34] <pitti> oh, that's what I tried an hour ago
[17:34]  * pitti updates branch
[17:34] <pitti> ah, great!
[17:34] <cjwatson> I wrote this code today, so you will need to be up to date, yes ;-)
[17:35] <cjwatson> the sets are generated from seeds, more or less, so at this point I think I can safely say that any oddness you see comes from there
[17:35] <slangasek> Keybuk: udev-configure-printer - I really have no idea, I've only just noticed it
[17:35] <pitti> cjwatson: oh, in that new system, would it pe possible to restrict uploads of language-{pack,support} to ~ubuntu-langpack?
[17:35] <Keybuk> because if it doesn't directly affect the device node
[17:36] <Keybuk> and doesn't store anything in the udev db
[17:36] <Keybuk> it can be done as an Upstart job
[17:36] <cjwatson> pitti: we could special-case the language packs, yes, although I sort of feel that core-dev ought to be able to upload them in an emergency
[17:36] <pitti> cjwatson: ok, true that
[17:36] <cjwatson> but we could put them in a package set that is uploadable by ~ubuntu-langpack too
[17:36] <pitti> it's just prone to be overwritten
[17:36] <Keybuk> slangasek:   start on filesystem and usb-device-added ...
[17:37] <slangasek> superm1: that apt hash mismatch is our standard "we don't have locking completely right on mirroring on antimony" bug; it should fix itself on the next build, or I can trigger a rebuild
[17:37] <pitti> especially since for karmic the stuff gets uploaded automatically
[17:37] <Keybuk> slangasek:   start on filesystem and <whatever subsystem lp are in>-device-added
[17:37] <cjwatson> pitti: it's technically possible to make it a restricted set, certainly
[17:37] <slangasek> jdstrand: release notes for karmic - open bugs against the ubuntu-release-notes project, please
[17:37] <cjwatson> pitti: can you mail the TB list about it?
[17:38] <cjwatson> pitti: (PS I'm not sure whether restricted sets will have a useful effect until we stop having component permissions in there too)
[17:38] <pitti> cjwatson: will do; although there's something to be said for emergency fixes, I'll note that
[17:38] <pitti> cjwatson: will send after our meeting
[17:47] <jdstrand> slangasek: thanks
[17:49] <superm1> slangasek, would you mind triggering a rebuild then? there was some stuff I particularly wanted to test on what would have been on that build
[17:50] <hyperair> seb128: you made any progress with the gtkbuilder issue?
[17:51] <seb128> upstream seems to advice to call set_translation_domain in every pygtk software
[17:52] <seb128> http://bugzilla.gnome.org/show_bug.cgi?id=574520
[17:53] <hyperair> but that's pygtk.
[17:53] <hyperair> what about the gtkmm one i linked you to?
[17:55] <seb128> hyperair, I've no clue about gtkmm it might have the same issue
[18:09] <slangasek> superm1: I think that one worked
[18:10] <superm1> slangasek, yup i see a  good one now.  thanks
[18:21] <mterry> kees, re: rsyslog hang, do you do anything special to make it hang?  Like, a special sequence of stop/restart/start or under extreme load, or whatever?  Having a hard time casually trying to reproduce.
[18:25] <slangasek> Keybuk: so upstart has a way to specify that a rule should be run when a given device is added via udev?
[18:25] <slangasek> Keybuk: I guess that doesn't solve the problem for distros still stuck using sysvinit? :)
[18:25] <kees> mterry: generally it's happened across package upgrades.
[18:26] <mterry> kees, OK
[18:27] <ScottK> cjwatson: I've just read the backscroll on the TB meeting and I'd like to chat with you about the team for Kubuntu upload rights when you have a moment.
[18:29] <pitti> cjwatson: sent
[18:29] <Keybuk> slangasek: yes
[18:29] <Keybuk> you get <subsystem>-device-added and <subsystem>-device-removed
[18:29] <cjwatson> ScottK: hi
[18:30] <ScottK> cjwatson: I don't think kubuntu-ninjas is the team you want.  We use that for access to the private PPA where we stage uploads, but there all uploads from there to the archive get a core-dev review first and there are people who I am confident are not ready for direct upload rights on that team.
[18:31] <cjwatson> ok
[18:31] <ScottK> cjwatson: I think what's needed is a new kubuntu-dev team that would (at least initially) be a subset of kubuntu-ninjas.
[18:31] <cjwatson> all right, fine by me
[18:31] <cjwatson> none of that is getting applied to upload privileges until it clears the owners of the respective teams + TB anyway
[18:32] <cjwatson> the Kubuntu package set has an archive permission of ubuntu-core-dev attached to it, so no change currently
[18:32] <ScottK> OK
[18:32] <ScottK> cjwatson: Is there something I need to do to document this or have you got the action.
[18:32] <cjwatson> what we'll need to know is how the team is managed, since if it's owned by anyone other than TB/DMB, it amounts to a delegation of upload rights
[18:32] <cjwatson> err, a delegation of the ability to grant upload rights
[18:32] <ScottK> Right.
[18:32] <cjwatson> I have an action to start some mail conversations already - I'll make sure you're included on the Kubuntu one
[18:33] <ScottK> I'd suggest it to be initially owned by DMB and have the current core-dev in kubuntu-ninjas on it.
[18:33] <ScottK> OK
[18:33] <ScottK> There are some I'm comfortable with immediately adding, but we ought to have some process for that beyond ScottK says.
[18:33] <ScottK> Thanks.
[18:34] <ScottK> cjwatson: Also Riddell is offline until Thursday, so don't expect quick reaction from hime.
[18:34] <ScottK> hime/him
[18:37]  * Night-Horse away
[18:37] <cjwatson> ScottK: been dragging on for months so I'll live ;-)
[18:38] <rgreening> pitti: ping
[18:41] <smoser> jjohansen, i was supposed to ask in your kernel meeting, but forgot/missed.
[18:41] <smoser> you're working on getting a karmic-ified ec2 kernel, right ?
[18:41] <jjohansen> yes
[18:42] <jjohansen> it is currently failing to link
[18:42] <jjohansen> karmic has some patches that aren't in mainline, that the xen patches need to be updated for
[18:42] <jjohansen> I have high hopes of getting it up today
[18:42] <mathiaz> cjwatson: hi - about the ubuntu-server team role in archive reorg - what do you need from me?
[18:44] <smoser> jjohansen, you rock. thanks.
[18:44] <jjohansen> smoser: I'll let you know as soon as I have an aki
[18:46] <cjwatson> mathiaz: at some point, it would be good for the server team to figure out a team that consists of those people who should be able to upload server-related packages, and talk to the TB about its membership practices
[18:47] <mathiaz> cjwatson: ok - anything related to server-related package sets?
[18:47] <mathiaz> cjwatson: who's gonna decide what goes in there?
[18:47] <cjwatson> that's set up, determined from seeds
[18:48] <cjwatson> bzr get lp:ubuntu-archive-tools && cd ubuntu-archive-tools && ./edit_acl.py -P karmic-ubuntu-server query
[18:48] <mathiaz> cjwatson: great - thanks
[18:49] <mathiaz> cjwatson: so the ubuntu-server-dev team would have people that have upload rights to the packages listed above^^?
[18:52] <cjwatson> that's the idea
[18:56] <Keybuk> pitti: If I mark something Won't Fix, I would appreciate you at least talking to me first before undoing that
[19:05] <Amaranth> cjwatson: how does that work with packages that end up in more than one seed?
[19:06] <cjwatson> Amaranth: they may go in multiple package sets, and therefore be uploadable by multiple teams
[19:06] <cjwatson> (see the spec)
[19:16] <Keybuk> ion: *cough*
[19:16] <Keybuk> looks like, err
[19:17] <Keybuk> s/starting udev/started udev/ in /etc/init/udevtrigger.conf
[20:14] <arand> kees: regarding bug #418135 , I was thinking of trying to pick together debdiffs for intrepid and hardy (just adding the 61-patch), or do you have other plans regarding that?
[20:14] <kees> arand: yeah, that's what I was going to try too.  had a bunch of other stuff to do first, though.
[20:16] <arand> kees: But would me poking in it help?
[20:16] <kees> arand: yeah, absolutely; if you can prepare the debdiffs that'd be great.  they need to be tested too, if possible.
[20:17] <arand> kees: Ok, I'll try to do as much as I can.
[20:17] <kees> cool
[20:44] <RainCT> uhm usb-creator-gtk is broken.. how do I install the netbook remix now :/
[20:54] <mok0> RainCT: Install Xubuntu on your netbook...
[20:55] <mok0> RainCT: It's sooooo nice
[20:56] <RainCT> Heh. Nit
[20:57] <RainCT> * Heh. Not my netbook, btw, but my neighbour's.   I haven't gt one yet.
[20:57] <mok0> RainCT: Oh... does your neighbor know about this? :-P
[20:58] <mok0> RainCT: you can use dd to put the image on the usb stick
[20:59] <mok0> usb-creator-gtk is just a wrapper around that :-)
[20:59] <RainCT> mok0: I installed Ubuntu on an old laptop of the girlfriend of his son (who had heard about free software before thanks to another LoCo member who is all the time doing conferences and stuff :)), and she (with the help of office asking for 200€ for activation) now convinced him that Ubuntu is awesome :P
[20:59] <mok0> RainCT: yay
[21:01] <RainCT> usb creator in jaunty doesn't support .img, awesome
[21:02] <RainCT> mok0: okay, so what's that command? :)ç
[21:02] <mok0> RainCT: arhgh I have too google
[21:02] <kirkland> ogra: ping, regarding qemu-kvm
[21:03] <mok0> https://help.ubuntu.com/community/Installation/FromImgFiles
[21:03] <mok0> perhaps
[21:04] <mok0> RainCT: in the Mac OSX section it tells you have to do it with dd
[21:04] <mok0> s/have/how
[21:08] <RainCT> mok0: ah great, thanks!
[21:38] <kirkland> ogra: http://pastebin.com/f94d727b
[21:38] <kirkland> ogra: that's the build annoyance I'm seeing, hoping you can fix for me
[21:40] <ebroder> Anybody from ubuntu-sru who could look at bug #330766?
[22:05] <ion> keybuk: Heh
[22:06] <Keybuk> what moron invented a syntax that changes behaviour depending on the *tense* of the config file
[22:06] <Keybuk> oh
[22:06] <Keybuk> me
[22:06] <ion> :-P
[22:06]  * Night-Horse away
[22:06] <ion> Thanks for the information! We appreciate it!
[22:07] <cjwatson> Keybuk: you should require correct use of the subjunctive mode too
[22:07] <cjwatson> er, mood
[22:07] <cjwatson> "let variable be value" or some such
[22:07] <ion> keybuk: So, that change, and i should be able to use the ubuntu-boot updates (and have a booting system)?
[22:08] <ion> Or at least a system i’d be humanly able to fix :-)
[22:08] <cjwatson> for bonus points, make the subjunctive have some kind of counterfactual meaning
[22:08] <Keybuk> ion: you can just upgrade now
[22:08] <Keybuk> the fix is in ubuntu-boot
[22:09] <Keybuk> though I would appreciate before/after bootcharts
[22:09] <ion> How about a config parser that uses a wigger mode on Mondays, a rastafarian mode on Tuesdays, a pirate mode on Wednesdays etc?
[22:09] <ion> keybuk: Alright
[22:10] <ion> yarr, start on startup, ye scurvy dog
[22:10] <Keybuk> avast apache
[22:10]  * Keybuk senses an initctl easter egg
[22:11] <ion> :-)
[22:58] <jdstrand> slangasek: I'm looking at https://bugs.launchpad.net/ubuntu-release-notes/+bugs for submitting a bug, as you advised ealier. What I see there seems to be bugs and not features. I have some feature items to add to the release notes. is that still the appropriate place?
[23:00] <slangasek> jdstrand: mmm, the release notes don't discuss features
[23:00] <jdstrand> slangasek: I might be using the wrong term then, sorry
[23:00] <slangasek> jdstrand: the https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview that you looked at before carries through to release time, but is not what we link to as "release notes"
[23:01] <jdstrand> slangasek: where do I go to add new features? I seem to remember we had something in the wiki in the past that talked about all the cool new stuff going on
[23:01] <slangasek> sure, that's the page
[23:01] <slangasek> https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview
[23:01] <jdstrand> slangasek: ok thanks :)
[23:04] <ScottK> slangasek: What do you think about having LP do a test rebuild of Karmic now that we're past FF?  I'm opportinistically finding a fair number of gcc 4.4 related build failures.  I think a rebuild would be helpful.
[23:05] <ScottK> slangasek: I think Universe could definitely use it.
[23:06] <ScottK> Trying to fix the cyphesis-cpp FTBFS I've found issues in 3 of 4 packages I touched.
[23:06]  * ScottK tosses in a reminder about wfmath/426401
[23:08] <slangasek> ScottK: in favor of it; though there's been turnover in the IS team so I'm not sure what the odds are of actually getting that rebuild going in the short term
[23:09] <cjwatson> we can do test rebuilds without much IS involvement now, although I don't think we can make them use their own output yet
[23:09] <wgrant> LP rebuilds are a little less heavyweight than the old ones.
[23:09] <wgrant> Right, they don't publish at this point.
[23:09] <cjwatson> I can kick one off tomorrow, if having the PPAs MUNCHED TO DEATH won't inconvenience anyone too badly
[23:10] <cjwatson> somebody might want to mail me a reminder though
[23:10] <ScottK> cjwatson: Even that would have surfaced two of the three issues I found, so I think it's good.
[23:10] <wgrant> cjwatson: The priority issue is fixed -- they will score way behind even retried PPA builds.
[23:10] <cjwatson> I wown't have time to actually deal with the output though
[23:10] <cjwatson> wgrant: ah, cool
[23:10] <wgrant> Even behind langpacks, in fact.
[23:10] <ScottK> cjwatson: As long as the output is available, it'll be a useful QA tool.
[23:12] <slangasek> cjwatson: who are the set of people who can do that? buildd admins?
[23:13] <wgrant> There is an LP issue at the moment which will cause some of those builds to fail to upload, but that shouldn't matter due to the lack of publishing.
[23:15] <cjwatson> slangasek: I can't remember at the moment; seems plausible but my browser just died and I want to go to bed rather than rebooting it. :-)
[23:15] <wgrant> ('some' being only those that haven't succeeded before)
[23:16] <slangasek> ok. :)
[23:16] <cjwatson> slangasek: at the very least I would expect anyone in the TB to be able to do it
[23:16] <cjwatson> but I'll see if I can track down more precise permissions for you later ...
[23:18]  * ScottK gets back on the road.