[00:02] <RAOF> bryceh: Create the /var/lock directory in your pbuilder chroot; base-files removed it, and pbuilder/sbuilder don't know to create it.
[00:05] <bryceh> mm, the bug that keeps on giving
[05:02] <pitti> Good morning
[05:04] <pitti> dobey: replied as well
[05:15] <RAOF> Good morning pitti!
[05:15] <pitti> hey RAOF, how are you?
[05:16] <RAOF> Alright.
[05:16] <RAOF> Managed to do a little running around lunchtime when it wasn't raining (when I started).  That was nice :)
[05:17] <RAOF> Hows about you?
[05:23] <pitti> still a bit 'oneiric', went to bed rather late
[05:23] <pitti> it seems the Brits finally sent us their bad weather!
[05:23] <RAOF> Hah!
[05:24] <robert_ancell> pitti, can you kick unity-greeter out of the new queue?
[05:24] <pitti> ooh
[05:24] <pitti> robert_ancell: sure
[05:25] <RAOF> Also, Would you be a dear and create a git repository for colord and shared-color-profiles on alioth in collab-maint? :{)
[05:25] <robert_ancell> you can install it and play around with /usr/lib/lightdm/unity-greeter --test-mode
[05:25] <robert_ancell> or be risky like me and actually use it as your greeter :)
[05:25] <RAOF> robert_ancell: Do you have multiple monitors?
[05:26] <robert_ancell> RAOF, no, and no idea how it will behave...
[05:26] <RAOF> My guess is fine — the first time :)
[05:26] <pitti> RAOF: can DDs actually do that, or does it require an admin?
[05:26] <RAOF> Because that's what the current greeter does :)
[05:26] <RAOF> pitti: Any DD can; you've got write access there.
[05:26] <pitti> "create git repo" still sounds like having to tear apart a chicken
[05:27] <RAOF> I suggest re-using the chicken-tearing apparatus found in /git/pkg-cli-apps/create_repo :)
[05:27] <pitti> handy
[05:27] <pitti> ok, doing Robert's NEW, and then getting to that
[05:28] <RAOF> Also, I'd just like to put it on record that I hate copyright, and it should go and die somewhere where I don't have to worry about it.
[05:28] <pitti> duly noted
[05:28] <pitti> I don't actually mind it much as long as it comes with a free license
[05:29] <RAOF> Perhaps I should rephrase: I hate that *other people* don't care as much about copyright as we do, so I run into things like shared-color-profiles.
[05:29] <pitti> robert_ancell: it could do with some copyright/license comment headers in the vala files
[05:29] <robert_ancell> pitti, oh, can do
[05:30] <pitti> robert_ancell: i. e. where did you take the "Copyright: 2011 Canonical Ltd" in debian/copyright from?
[05:30] <pitti> robert_ancell: or did you write it yourself?
[05:30] <robert_ancell> pitti, well, I filled it out manually :)
[05:31] <pitti> robert_ancell: can you please fix Format-Specification: to http://dep.debian.net/deps/dep5/ ?
[05:31] <robert_ancell> pitti, I have copyright headers pushed to master, do you want a new release?
[05:32] <pitti> robert_ancell: that's fine; won't be the last upload in oneiric, I guess
[05:32] <pitti> "New upstream release" is a bit confusing, but </nitpick>
[05:33] <pitti> robert_ancell: lightdm is only a recommends, not a depends?
[05:33] <robert_ancell> pitti, the library is a depends, the daemon not technically
[05:34] <pitti> robert_ancell: so, with the copyright headers and fixed format-specification: I'm happy (neither requires an upload)
[05:36] <robert_ancell> pitti, I've pushed copyright changes to the packaging branch, please check
[05:37] <pitti> robert_ancell: I think it's "Upstream-Name:" now
[05:38] <pitti> and Maintainer: -> Upstream-Contact:
[05:38] <pitti> robert_ancell: and you didn't push the copyright headers yet?
[05:38] <pitti> RAOF: do you mean /git/pkg-cli-apps/setup-repository ?
[05:39] <robert_ancell> whoops updated copyright (dropping those fields as they're optional).  Headers are pushed to lp:unity-greeter
[05:39] <pitti> ah, trunk branch
[05:39] <RAOF> pitti: Yes, I do.  You won't be able to use it as-is, because pkg-cli-apps uses a rather particular setup and that script will set the repository up to publish things to #debian-cli, but the core commands in that are all you need.
[05:39] <pitti> robert_ancell: thanks, looks good
[05:40] <RAOF> The Yamma profiles are Copyright <some year> by those well known contributors, <copyright holders> :(
[05:42] <pitti> RAOF: I created colord.git
[05:43] <pitti> http://anonscm.debian.org/gitweb/?p=collab-maint/colord.git;a=summary doesn't exist yet, I guess it takes a while to catch up?
[05:43] <RAOF> pitti: Rockin.
[05:43] <RAOF> I think it does, yes.
[05:43] <RAOF> Now, to get me access to that…
[05:43]  * RAOF wonders if it would really be *that* much effort to get DD.
[05:44] <pitti> RAOF: DM wouldn't be, anwyay
[05:47] <RAOF> Hm.  That looks positively friendly.
[06:35] <cdbs> Just an FYI, the new gnome-control-center depends on the "glxinfo" command to print details on the GPU in "System Settings"
[06:35] <cdbs> Without the mesa-utils package containing glxinfo, it returns "Unknown"
[06:37] <RAOF> Does it really spawn glxinfo and parse its output, rather than doing a simple GL call?  Ugh.  Anyway, have you filed a bug? :)
[06:38] <smspillaz> bahahahhaaha
[06:38] <smspillaz> wow that reminds me of
[06:38] <smspillaz> ... beryl
[06:39] <RAOF> Heh.  Kernel SRUs are big, and cause lots of bugmail.
[06:43] <smspillaz> I'm making a mental note to note dist upgrade ever
[06:43] <smspillaz> *not
[06:44] <smspillaz> I was just about to upload the compiz release yesterday and then boom, my system hangs halfway through a kernel update and now its trashed
[06:44] <smspillaz> (and by yesterday, I mean 4:30 am, when I was just about to go to bed :/)
[06:46] <pitti> smspillaz: hm, could that still be bug 807306 ?
[06:46] <ubot2> Launchpad bug 807306 in udev "[oneiric] Keyboard & mouse not working in X - incomplete migration to /run" [High,Fix released] https://launchpad.net/bugs/807306
[06:47] <smspillaz> pitti: no, it was because I'm using nouveau and did something the driver didn't like
[06:47] <smspillaz> pitti: basically, nouveau gets cranky if you run out of video memory
[06:48] <smspillaz> pitti: I also get 807306 too, but I have an external mouse, so its not that bad
[06:48] <pitti> that should be fixed now, though
[06:48] <smspillaz> (by trashed, I mean it fails to mount / even though fsck says its fine)
[06:49] <RAOF> *My* laptop started correctly today :)
[06:49] <smspillaz> pitti: basically, its the case of, I had to force power off the machine during a dist-upgrade
[06:49] <smspillaz> that always breaks things :)
[06:55] <smspillaz> RAOF: hm, are we turning on nouveau 3d by default now ?
[06:56] <RAOF> smspillaz: Yes.
[06:57] <smspillaz> nice
[06:58] <smspillaz> is there just a whitelist or ... ?
[07:03] <RAOF> It's just turned on.
[07:03] <smspillaz> ah ok, I didn't know it worked in most places
[07:03] <RAOF> That's part of what we're trying to discover ;)
[07:03] <RAOF> But it works fine on all of *my* hardware, so ship it!
[07:04] <smspillaz> :)
[07:09] <lucazade> on a gts 250 with nouveau3d the system hard freeze after few mins!!
[07:09] <lucazade> so it is hard to install also from livecd
[07:09] <lucazade> :)
[07:10]  * smspillaz dist-upgrades and hopes for the best
[07:10] <smspillaz> from my chroot
[07:16] <smspillaz> wohooo! I have X back again!
[07:16] <smspillaz> isn't it amazing that you can leave your system in complete ruins and somehow recover from that?
[07:22] <RAOF> lucazade: See, that's the sort of feedback we're after.  Well, not exactly, but it's important to know!
[07:24] <lucazade> RAOF: I have this issue from a couple of Ubuntu releases when using experimental-dri
[07:27] <RAOF> Is there a bug on launchpad about this?
[07:27] <lucazade> yes, let me search
[07:28] <RAOF> 'Cause that's where we'll be looking when it comes time to keep 3D enabled or disable it.
[07:28] <smspillaz> RAOF: maybe it would be good to have a whitelist
[07:28] <RAOF> smspillaz: That would be another option.
[07:28] <smspillaz> yeah
[07:28] <smspillaz> I know that the 8600GT does pretty well under average circumstances
[07:28] <smspillaz> I just do insane things to my gpu
[07:29] <lucazade> RAOF: bug 696427 ... gts250 1gb, it is quite recent as card
[07:29] <ubot2> Launchpad bug 696427 in mesa "Unity visual glitches and freeze (libgl1-dri-mesa-experimental)" [Wishlist,Confirmed] https://launchpad.net/bugs/696427
[07:29] <RAOF> lucazade: Ta.
[07:30] <smspillaz> RAOF: I was going to ask you actually, is there a sane way to enable pcsnv at the moment ?
[07:30] <RAOF> smspillaz: Looking to do some CUDA?
[07:30] <RAOF> (No)
[07:30] <smspillaz> mmm, power management actualy
[07:30] <RAOF> Ah!
[07:31] <smspillaz> so that, you know, my house doesn't catch fire for a reason that isn't my inability to cook one day
[07:32] <smspillaz> I had a look into it a week ago but it doesn't like there's a non-crack way of doing it
[07:32] <RAOF> IIRC pscnv doesn't actually play with the rest of the 3D stuff, and the kernel module does things like not use TTM.  If you really want power management you could pull the nouveau kernel patches from the mailing list and build them? :)
[07:32] <smspillaz> yeah, I suppose I could do that
[07:32] <smspillaz> I have to run my own kernel most of the time anyways for wayland stuff soo ...
[07:34] <RAOF> AFAIK the power management code works fine, they're just being a bit paranoid about reverse-engineering stuff that can, you know, /fry your card/
[07:35] <smspillaz> eh, my  card is already frying things
[07:35] <smspillaz> I'm lucky I haven't had to bake it yet though
[07:39] <RAOF> Oh, you've got one of those bakeable laptops too, have you?  Lucky! :)
[07:40] <smspillaz> yeah, the most notorious one
[07:40] <smspillaz> the XPS M1530
[07:40] <smspillaz> same laptop as sabdfl iirc
[07:40] <cdbs> Hi, can someone just rebuild this build https://launchpad.net/ubuntu/+source/unity-greeter/0.0.1-0ubuntu1/+build/2623446 ? The build-dep is now in the archive
[07:40] <cdbs> smspillaz: What's bad about that laptop?
[07:40] <pitti> smspillaz: baking seems to work well for didrocks, though
[07:40] <smspillaz> pitti: indeed, he's done it twice now :)
[07:40] <pitti> cdbs: it's already building
[07:41]  * cdbs refreshes
[07:41] <cdbs> ah okay
[07:41] <cdbs> robert_ancell did that probably :)
[07:42] <smspillaz> cdbs: http://www.engadget.com/2008/07/10/all-nvidia-8400m-8600m-chips-faulty/
[07:43] <smspillaz> the 8600M is basically an overlocked 8400M
[07:43] <smspillaz> only a handful of laptops ship with it
[07:43] <smspillaz> that being the 2008 MacBook Pro and Dell XPS M1530
[07:43] <smspillaz> (which is basically just a 2008 MacBook Pro hardware wise)
[07:43] <cdbs> smspillaz: the news is from 2008
[07:44] <smspillaz> I know :)
[07:44] <cdbs> smspillaz: haven't the chips been replaced since then?
[07:44] <smspillaz> this laptop is from 2008
[07:44] <smspillaz> well, yes
[07:44] <cdbs> yeah, but still, through a product advisory or recall
[07:44] <smspillaz> in most laptops you'll find a fermi or something now
[07:44] <smspillaz> cdbs: nope, they never recalled it
[07:44] <smspillaz> all dell did was extend the warranty for "graphics related issues" and that's only in the US too
[07:45] <cdbs> Seriously, all tech companies think 99% of their target audience and consumer base lives in the US
[07:45] <smspillaz> well, it's only practical to do it in the US
[07:46] <smspillaz> people stateside tend to have the capacity to make the most noise
[07:46] <smspillaz> if you keep them happy you'll usually keep the world happy
[07:53] <rodrigo_> morning
[07:55] <chrisccoulson> good morning everyone
[07:56] <RAOF> Howdie and good morning chrisccoulson.
[07:56] <chrisccoulson> hey RAOF, how are you?
[07:57] <RAOF> I'm an awesome force of nature.
[07:57] <RAOF> Well, perhaps not.
[07:57] <RAOF> But pretty good, anyway :)
[07:57] <chrisccoulson> heh
[07:58] <RAOF> Hows about your fine self?
[08:02] <pitti> hey chrisccoulson
[08:02] <chrisccoulson> hi pitti, how are you?
[08:02] <pitti> pretty well, thanks!
[08:03] <pitti> wasting my time with packaging python3-cairo and then python3-gobject
[08:04] <abhinav-> pitti: python3-cairo ? Does it use GI ?
[08:04] <chrisccoulson> pitti - oh, i thought the python bindings were all disappearing?
[08:05] <pitti> abhinav-: no, it's a static binding; apparently cairo isn't very suitable for GI
[08:05] <abhinav-> Yeah :-|
[08:06] <pitti> might also be a performance issue
[08:06] <pitti> py3cairo is written in cpython
[08:06] <pitti> for throwing buttons around the GI overhead doesn't matter, but for vector drawing it might, but I don't know
[08:08] <abhinav-> Well not having GI bindings for cairo seems a drawback, since Gtk3 removed some of the API just because cairo provides those functionalities. I think Pycairo was lagging behind the C API of cairo
[08:08] <pitti> why drawback?
[08:08] <pitti> it doesn't matter much if you do "import cairo" or "from gi.repository import Cairo"?
[08:09] <pitti> for the "lagging behind", certainly, yes
[08:09] <abhinav-> Yes, so while the current C API of cairo is ready to be augmented with Gtk3, I am not sure same can be done with the Python bindings
[08:10] <abhinav-> I am referring to my experience when I was trying to play around with Gtk3 to add screenshot feature to apport
[08:10] <abhinav-> Althoug it was more than a month ago
[08:13] <RAOF> I wouldn't expect the GI overhead to be a huge issue for cairo; you should generally be doing a small number of calls to produce a large image.
[08:14] <pitti> anyway, py3cairo is there, and GI bindings are not
[08:14] <pitti> so I'm packaging these for now to unblock python3 progress
[08:23] <seb128> hey
[08:24] <pitti> bonjour seb128
[08:24] <seb128> hey pitti
[08:24] <seb128> how are you?
[08:25] <desrt> good morning, gents
[08:25]  * pitti hugs seb128 and desrt
[08:25] <seb128> what are the news today? ;-) I saw an unity greeter upload, did anybody try it?
[08:25] <seb128> hey desrt
[08:25] <pitti> seb128: pretty well, thanks! just got my py3cairo package working
[08:25]  * seb128 hugs pitti
[08:25] <seb128> pitti, \o/
[08:25] <pitti> now off to packging python3-gobject
[08:25] <pitti> seb128: just built/building, needs binNEW still
[08:25] <pitti> (greeter)
[08:25] <seb128> ok
[08:28] <chrisccoulson> hey seb128, how are you?
[08:29] <seb128> hey chrisccoulson, I'm fine thanks, how are you?
[08:29] <chrisccoulson> seb128, good thanks
[08:29] <seb128> chrisccoulson, great work on g-s-d, you won beers for the next UDS ;-)
[08:29] <pitti> argh, LP down
[08:29] <chrisccoulson> heh :-)
[08:30] <chrisccoulson> seb128, i wanted to fix the crash in exit() too, but i'm not sure of the best way to do that yet :/
[08:30] <seb128> do you understand what is wrong and ponder how to fix it? or do you need to figure what is wrong?
[08:30] <chrisccoulson> seb128, yeah, i know what is wrong there
[08:31] <seb128> great
[08:31] <chrisccoulson> 1 of the plugins links against gconf, which creats an exit handler
[08:31] <chrisccoulson> but the plugins get unloaded before exit
[08:31] <seb128> tell rodrigo_ so he doesn't spend time trying to debug it as well
[08:31] <chrisccoulson> so it crashes ;)
[08:31] <chrisccoulson> perhaps desrt has some pointers on what to do there
[08:31] <seb128> he will tell you "don't use gconf" I guess ;-)
[08:32] <chrisccoulson> lol
[08:32] <rodrigo_> chrisccoulson, yes, that seems to be the cause for http://launchpad.net/bugs/788710
[08:32] <ubot2> Ubuntu bug 788710 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV in exit()" [High,In progress]
[08:34] <seb128> chrisccoulson, you fixed bug #805908 right?
[08:34] <ubot2> Launchpad bug 805908 in gnome-settings-daemon "multimedia keys not working" [High,Triaged] https://launchpad.net/bugs/805908
[08:34] <chrisccoulson> seb128, yeah, that ones fixed
[08:34] <seb128> great
[08:34] <chrisccoulson> sorry, i should have checked for existing bugs ;)
[08:34] <seb128> bah, launchpad is ro
[08:36] <chrisccoulson> yeah, if you turn off the keybindings plugin, g-s-d doesn't crash on exit, as that's the only one still using gconf
[08:36] <seb128> that and the gsettings to gconf gateway plugin
[08:38] <chrisccoulson> seb128, oh, that one isn't activated by default here
[08:38] <seb128> hum, indeed, it's not there either
[08:42] <seb128> chrisccoulson, how was g-s-d handling the gconf handler in 2.32 when it was still using gconf?
[08:45] <chrisccoulson> seb128, i think that it just used to exit uncleanly when it lost the connection to the x server (so it wouldn't have unloaded plugins)
[08:45] <seb128> those issues on logout are annoying
[08:46] <seb128> they create lot of apport noise for no real issues
[08:47] <chrisccoulson> seb128, i guess that this would have broken it: http://git.gnome.org/browse/gnome-settings-daemon/commit/gnome-settings-daemon/?id=c3505969ad2bb61863965e49f04000e7773f3231
[08:48] <seb128> well, I will not complain especially if that means gnome-session respawn it when needed ;-)
[08:52] <seb128> ups
[08:53] <seb128> don't ctrl-R in xchat
[08:53] <chrisccoulson> what happens?
[08:53] <Laney> blank bug day mail?
[08:53] <seb128> Laney, evo bug #809379
[08:53] <ubot2> Launchpad bug 809379 in evolution "Evolution is sending a blank body email" [High,Triaged] https://launchpad.net/bugs/809379
[08:53] <Laney> fun
[08:53] <seb128> Laney, you can ctrl-u and read the source ;-)
[08:54] <seb128> it's a display issue
[08:54] <Laney> seb128: not sure I can, using mutt
[08:54] <seb128> oh, you mean the one from pedro
[08:54] <seb128> he resent it
[08:54] <Laney> bad moderators then :P
[08:55] <chrisccoulson> oops ;)
[08:55] <chrisccoulson> lol
[08:55] <seb128> oh indeed
[08:55] <seb128> Laney, the bugsquad list got the second email, not the announce one
[08:55] <seb128> chrisccoulson, tried the ctrl-R? ;-)
[08:56] <chrisccoulson> seb128, yeah ;)
[08:57] <seb128> RAOF, hey, is there known xorg breakage on intel with dual screen?
[08:57] <seb128> on current oneiric
[08:57] <RAOF> seb128: I don't know of any; what are you seeing?
[08:58] <chrisccoulson> oh, i hope my dual screen setup isn't going to break ;)
[08:58] <chrisccoulson> i haven't restarted in several days
[08:58] <seb128> RAOF, it's not me but ronoc is having issues since he upgraded
[08:58] <seb128> ronoc, ^ could you describe how it's broken for you?
[08:59] <RAOF> WFM, modulo compiz *still* being a pile of fail at hotplug.
[08:59] <seb128> RAOF, like bug #808677
[08:59] <ubot2> Launchpad bug 808677 in compiz "Failed to activate external monitor (dual monitor mode)" [High,New] https://launchpad.net/bugs/808677
[08:59] <seb128> RAOF, is that a compiz issue?
[09:00] <RAOF> smspillaz: While you're hear to shout at, when is compiz going to start drawing on *all* of my desktop after I plug a second monitor in?
[09:00] <seb128> or bug #808685
[09:00] <ubot2> Launchpad bug 808685 in compiz "Corrupted display after switching to external monitor (1 active monitor)" [High,New] https://launchpad.net/bugs/808685
[09:01] <seb128> RAOF, well I guess those are rather compiz issues than xorg ones
[09:01] <RAOF> seb128: Right.  That's actually a combination of compiz *still* being totally broken, the crazy “Is your monitor OK” dialog getting continually bigger, and a genuine Xserver bug when the dialog reaches a critical size and crashes the server.
[09:02] <seb128> great combo
[09:02] <chrisccoulson> oh, i get the corrupted display when attaching an external monitor, but it does that in natty too
[09:03] <chrisccoulson> i always have to restart compiz after connecting it, and then it works
[09:03] <RAOF> Yeah.  Compiz 0.9 has hated XRandR since forever.
[09:03] <chrisccoulson> yeah, it's pretty broken
[09:03] <seb128> :-(
[09:03] <chrisccoulson> works in mutter though ;)
[09:03] <seb128> bug #795458 got fixed in the natty sru though
[09:03] <ubot2> Launchpad bug 795458 in unity "Display garbled upon connecting external displays" [High,Fix committed] https://launchpad.net/bugs/795458
[09:03] <RAOF> chrisccoulson: Corrupt, or just black and any compiz drawing (like the window switcher) doesn't get cleared?
[09:04] <seb128> ronoc, wb
[09:04] <chrisccoulson> RAOF, i get compiz drawing correctly in a very small rectangle in one corner of one screen, and the rest of it is black as you describe (with any drawing not getting cleared)
[09:05] <chrisccoulson> ie, i can open an indicator menu, and it's contents get left on the screen after i close it
[09:05] <RAOF> Yeah.  That's compiz failing to be a compositing manager in those areas.
[09:06] <chrisccoulson> if i could figure out how compiz worked, then i would just go ahead and fix it ;)
[09:06] <seb128> it's just code, how hard can it be?! ;-)
[09:09] <chrisccoulson> i tried reading the compiz code once ;)
[09:09] <smspillaz> what's the bug ?
[09:10] <smspillaz> chrisccoulson: RAOF if that's happening you either hve output detection disabled or XineramaGetScreenInfo is returning some very odd values
[09:10] <RAOF> smspillaz: Where you enable a second monitor and compiz doesn't notice that the desktop is bigger and so doesn't actually composite on that.
[09:10] <smspillaz> RAOF: are you running unity ?
[09:10] <RAOF> Yes.
[09:11] <smspillaz> RAOF: I'm pretty sure this was a unity bug where the clip region gets reset incorrectly
[09:11] <RAOF> This is also possible.  Unity knows about the second screen; it draws the panel, dash, etc just fine.
[09:11] <smspillaz> RAOF: unity does some rather ... insane things
[09:11]  * RAOF doesn't really care.  He *does* care that plugging in a second monitor doesn't work.
[09:12] <smspillaz> yep :)
[09:12] <smspillaz> although, I thought we fixed that
[09:12] <smspillaz> njpatel: ^ ?
[09:12] <smspillaz> RAOF: in other news, we should be able to handle the window size > mts case now
[09:12] <RAOF> Yay!
[09:12] <smspillaz> RAOF: the plugin to do that was broken in natty but I fixed it
[09:12] <njpatel> smspillaz, yes?
[09:13] <smspillaz> so we can probably enable it
[09:13] <smspillaz> njpatel: that bug where you plug a second monitor in and it's black, was that a) a unity bug where the clip region was reset incorrectly b) was it fixed ?
[09:13] <smspillaz> since I've heard a multitude of things about it
[09:13] <njpatel> smspillaz, a) no idea, was on yours and jay's plate b) definitely not fixed, just happened to me five times
[09:13] <smspillaz> ok
[09:14] <seb128>     - Display garbled upon restoring original resolution (lp: #795454)
[09:14] <seb128>     - Display garbled upon connecting external displays (lp: #795458)
[09:14] <seb128> were fixed in a sru
[09:14] <RAOF> Yeah, that's a different bug.
[09:14] <njpatel> seb128, different bugs
[09:14] <seb128> right
[09:14] <smspillaz> RAOF: try seeing if you get it without unity on
[09:14] <seb128> so the other ones didn't get fixed
[09:14] <RAOF> smspillaz: I'll do so later.
[09:15] <njpatel> sandybridge is very, er, delicate at the moment
[09:15] <smspillaz> RAOF: :)
[09:15] <njpatel> xv kills my xserver
[09:15] <smspillaz> njpatel: try nouveau
[09:15] <njpatel> smspillaz, on intel?
[09:15] <smspillaz> move a window with metacity, oops, your X server died
[09:15] <njpatel> ah
[09:15] <njpatel> nice
[09:15] <smspillaz> njpatel: yes, try it on intel :)
[09:15] <njpatel> smspillaz, okay, I'll dedicate today to making it work on intel ;)
[09:15] <smspillaz> njpatel: though it won't really have any effect
[09:16] <njpatel> also, my laptop doesn't suspend all the time
[09:16] <smspillaz> njpatel: I did a dist-upgrade yesterday
[09:16] <smspillaz> NEVER AGAIN
[09:16] <smspillaz> it hanged halfway through
[09:16] <njpatel> I just did it this morning, it went fine, I have one more thing working that yesterday
[09:16] <smspillaz> so I thought "well crap, force reset"
[09:16] <smspillaz> nope trashed my system
[09:16] <njpatel> so I should be happy I guess
[09:16] <smspillaz> didnt'
[09:16] <smspillaz>  event boot
[09:17] <smspillaz> had to do some interesting recovery with init=/bin/bash
[09:17] <RAOF> smspillaz: Well, without unity it doesn't suffer that bug.  If only because compiz crashes when I enable the second monitor and then respawns.
[09:17] <njpatel> heh
[09:18] <RAOF> Oh!  Second time lucky.
[09:18] <smspillaz> if there is one good thing about running arch linux for a few months before I switched from fedora to ubuntu it was that you get to learn how to do these things because every single time you do a pacman -Syu world you have to reconfigure your entire system from scratch again
[09:18] <RAOF> Second monitor enabled *and* compiz didn't crash *and* it's actually drawing on *both* heads.
[09:19] <smspillaz> RAOF: so I just hotplugged my monitor like 10 times and I didn't get the bug
[09:19] <smspillaz> and that's without unity
[09:19] <seb128> so unity bog it seems
[09:20] <smspillaz> oh, monitor hotplug is awesome
[09:20] <smspillaz> seb128: well, not conclusively
[09:20] <smspillaz> it could just be on certain hardware that compiz gets that
[09:20] <seb128> well RAOF gets the issue with unity and it seems to work without unity
[09:20] <smspillaz> seb128: I think I need to do more testing
[09:20] <smspillaz> like, checking if I get the issue with unity :)
[09:21] <smspillaz> since I don't usually hotplug this monitor
[09:21] <seb128> I should do some testing as well, my external monitor use is usually "boot with the laptop docked"
[09:21] <seb128> which works fine
[09:21] <njpatel> smspillaz, if you know what it is, any chance of a quick mail to jay cc'ing jason and I so he knows what to fix/where to start?
[09:21] <smspillaz> yeah
[09:21] <smspillaz> njpatel: sure
[09:21] <njpatel> smspillaz, thanks!
[09:21] <smspillaz> np
[09:22] <smspillaz> I wonder if there's a sane way I can work around this 32 character long key limitation in gsettings
[09:23] <smspillaz> that doesn't involve the use of --allow-any-key in glib-compile-schemas
[09:23] <seb128> smspillaz, did you check with desrt?
[09:23] <seb128> smspillaz, why do you need over 32 chars?
[09:23] <smspillaz> desrt: ^ :)
[09:23] <smspillaz> seb128: some of the option names in the plugin metadata in compiz are over 32 chars
[09:24] <smspillaz> maximize_window_horizontally_key
[09:24] <smspillaz> for example
[09:24] <desrt> O_o
[09:24] <smspillaz> I'm more curious to know why that limit exists
[09:24] <desrt> max-win-horiz-key!!
[09:25] <smspillaz> desrt: yeah, I'm not too keen on rewriting half the plugins so they'll work with one settings backend :)
[09:25] <desrt> i think it was a case of "32 ought to be enough for anybody"
[09:25] <desrt> dconf limits names to 65535 characters
[09:25] <desrt> so there's no technical limitation
[09:26] <desrt> i wonder if it was a windows registry consideration.  i'm trying to dig through the history.
[09:26] <jibel> smspillaz, I get that on 3 different intel cards, arrandale, pineview and i915, but only with Unity. monitor hotplugging works fine on unity-2d
[09:26] <smspillaz> since if I change maximize_window_horizontally_key to max-win-horiz-key then I'd need to change bcop to use - instead of _ for delimiting
[09:26] <smspillaz> and then also change anthing like optionGetMaximizeWindowHorizontallyKey to optionGetMaxWinHorizKey
[09:27] <smspillaz> in the source
[09:27] <smspillaz> desrt: yeah, that wouldn't surprise me at all
[09:27] <desrt>     GSettings: merge the schema compiler
[09:27] <desrt> doh.
[09:27] <smspillaz> ahahahah
[09:27] <desrt> i kept the branch around though
[09:27] <desrt> let me check there :)
[09:28] <desrt>     clean up schema compiler
[09:28] <desrt>     
[09:28] <desrt>     enforce key name restrictions
[09:28] <desrt> duh.
[09:28] <desrt> not much better :)
[09:28] <smspillaz> desrt: well, maybe a better question to ask: is allow-any-name going away any time soon ?
[09:29] <desrt> you may not use it
[09:29] <smspillaz> because if that's the case I could just g_setenv ("GSETTINGS_BACKEND", "dconf") and be done with it
[09:29] <smspillaz> desrt: :(
[09:29] <desrt> smspillaz: the problem is that when you install schemas it's fine
[09:29] <desrt> but when someone else does it they're going to run the schema compiler without that switch
[09:29] <desrt> then you're in trouble
[09:29] <smspillaz> ah yeah
[09:30] <smspillaz> I mean, the brutal workaround here
[09:30] <desrt> hold on hold on
[09:30] <smspillaz> is to install all the schemas to $PREFIX/share/compiz/glib-2.0/schemas and then add $PREFIX/share/compiz to $XDG_DATA_DIRS
[09:30] <desrt> i'm doing a bit of research that may lead to a substantial lifting of the restriction
[09:30] <smspillaz> desrt: oh, goodie :)
[09:31] <desrt> if there's no good reason that we picked 32 and it's causing you problems then i'll change it
[09:31] <smspillaz> :)
[09:31] <desrt> let me just check that we won't get burned on windows or something
[09:31] <smspillaz> desrt: it sounds very much like a windows-esque limitation to me
[09:32] <desrt> i just checked with wine's regedit
[09:32] <desrt> there is no such restriction here, at least
[09:32] <desrt> and the wikipedia article on the registry mentions nothing
[09:32] <smspillaz> I can reboot and check on the actual windows
[09:32] <desrt> please do
[09:32] <smspillaz> ok, hang on then
[09:32] <desrt> does lifting it to 64 sound reasonable?
[09:32] <seb128> launchpad is back!
[09:34] <smspillaz> seb128: yay!!!!
[09:35] <smspillaz> desrt: perhaps temporarily, although there could be weird cases where it could be some ridiculously long length
[09:36] <desrt> smspillaz: i think the problem we're hitting is that GSettings was not intended to be used this way
[09:36] <desrt> you're probably the first person auto-generating schemas in this fasion
[09:36] <desrt> *fashion
[09:36] <smspillaz> yeah, I had some fun with xslt
[09:36] <desrt> xslt is a good tool for such a thing :)
[09:36] <smspillaz> its also not very verbose
[09:37] <smspillaz> xsltproc -o org.freedesktop.compiz.plugin.xml gsettings.xslt plugin.xml
[09:37] <smspillaz> error
[09:37] <seb128> somewhat compiz using gsettings make me been nervous
[09:37] <smspillaz> seb128: howso ?
[09:37] <seb128> like any typo in any schemas or any plugin is going to take the desktop down thanks to the "exit on schemas errors"
[09:37] <desrt> oh.  interesting.
[09:38] <desrt> you actually hit a bug in the gsettings compiler
[09:38] <desrt> your key is exactly 32 characters in length
[09:38] <desrt> i did a < where i should have done a <= :)
[09:38] <smspillaz> desrt: oh yeah, I noticed that
[09:38] <desrt> okay.  i'll just fix that, then :)
[09:38] <smspillaz> desrt: at the moment I'm truncating to 32 chars
[09:38] <smspillaz> err
[09:38] <smspillaz> 31
[09:38] <smspillaz> desrt: I know there are other key names that are longer than this though
[09:39] <desrt> smspillaz: i wonder if maybe you should be using dconf :)
[09:39] <smspillaz> directly ?
[09:39] <smspillaz> hmm, probably not a good idea
[09:40] <desrt> GSettings is really intended to be a user-facing API
[09:40] <desrt> not burried in another abstraction layer
[09:40] <smspillaz> yeah, this is true
[09:40] <desrt> in fact, it features some things that make it particularly poorly suited for this 'wrapping' kind of use that you're doing
[09:40] <smspillaz> desrt: perhaps I'll prototype on GSettings first and if its too much of a problem I can just use dconf
[09:40] <desrt> the problem is that the dconf API is not stable
[09:41] <smspillaz> yeah
[09:41] <desrt> and i have some changes planned
[09:41] <smspillaz> desrt: oh, I just checked on windows 7 at least and regedit seems to be fine with a really long key name
[09:41] <desrt> smspillaz: cool.  i'll raise the roof a bit, then
[09:41] <smspillaz> I gave it like 500 chars and it didn't complain
[09:42] <smspillaz> desrt: but good plan, I might just have to use dconf
[09:42] <desrt> okay.  in that case, i'll wait
[09:42] <desrt> i want to consult with mclasen anyway.  maybe he remembers why we picked 32
[09:42] <desrt> he was at the hackfest
[09:42] <smspillaz> yeah
[09:42] <smspillaz> desrt: for now I can just truncate
[09:42] <desrt> vuntz: so were you.  do you remember? :)
[09:42] <smspillaz> that's basically what I'm doing
[09:42] <desrt> smspillaz: that will work badly in the case where you have
[09:43] <desrt> the-key-to-use-for-doing-something-totally-harmless
[09:43] <desrt> and
[09:43] <smspillaz> a_..(32).._a
[09:43] <desrt> the-key-to-use-for-doing-something-really-bad
[09:43] <smspillaz> a_..(32).._b
[09:43] <smspillaz> I know :)
[09:43] <desrt> i suggest hash functions!
[09:43] <desrt> totally helpful when the user pops open the dconf-editor :)
[09:43] <smspillaz> that's a brilliant idea
[09:43] <smspillaz> now nobody will play with the settings
[09:44] <smspillaz> and we can have real lockdown
[09:44] <desrt> hah
[09:44] <desrt> ya right
[09:44] <njpatel> desrt, have a question for you. want to test some file io functions that use async gio internally, need a way, in the tests,  to manually pump those threads (something similar to what we do with g_main....pending etc) any ideas?
[09:44] <desrt> all it means is that overnight someone will write a blog entry about how you have to change key 2jwh23828wjd in order to turn the fire-drawing plugin back on
[09:44] <pitti> wohoo, uploads are back
[09:44] <smspillaz> desrt: wow, I'm actually laughing quite a lot right now
[09:45] <desrt> njpatel: i'm actually in a similar problem right now
[09:45] <smspillaz> desrt: can you imagine the corresponding OMG!Ubuntu! post?
[09:45] <pitti> ... or not; instead of ftp failing right away, it now fails when uploading the source.changes
[09:45] <desrt> njpatel: what i usually do is run the mainloop and each time some 'progress' happens i queue up the next stage
[09:45] <desrt> then at the end i quite the loop
[09:45] <desrt> problem there, of course, is that you could end up locking forever
[09:45] <njpatel> desrt, right
[09:45] <smspillaz> desrt: BRING BACK UR BLING ON COMPIZ! Only a quick cd34w8tdbns83458 away!
[09:45] <desrt> so you add a timeout say....
[09:46] <desrt> but then the question comes what is a good amount for that timeout
[09:46] <njpatel> yep, that's what I've done before but was wondering if there was any magic gio function to make this work :)
[09:46] <desrt> we've been bitten in the past by "reasonable" timeout values on testcases that failed asserts on really fast or really slow hardware
[09:46] <desrt> no.  i don't think so.
[09:46] <desrt> glib really has no way of knowing when some future events could possibly be pending
[09:46] <njpatel> indeed
[09:46] <desrt> since a lot of the time they're freshly introduced to the maincontext from another thread
[09:48] <smspillaz> I wonder how irssi didn't catch that netsplit
[09:48] <njpatel> desrt, alright, thanks, will just try and main the wait/timeout bits a bit nicer to read then
[09:48] <desrt> njpatel: i wouldn't worry too much about it.  after the last week or two the builder admins are getting really good at killing off testcases of glib-based libraries :)
[09:48] <njpatel> hah
[09:49] <cjwatson> um, is anyone else entirely unable to log in using lightdm since the most recent upgrade?
[09:50] <cjwatson> I click on my username and the greeter freezes; in lightdm.log, I see "WARNING: Unknown message from greeter: 7"
[09:50] <cjwatson> and before that it says "pam_open_session -> System error" and "pam_setcred(PAM_ESTABLISH_CRED) -> System error", though I don't know whether that's normal
[09:52] <desrt> delicious
[09:52] <desrt> i love git-bz!!
[09:53] <smspillaz> git-bz ?
[09:53] <desrt> git/bugzilla integration
[09:53] <smspillaz> oh, lovely
[09:53] <desrt> i just typed 'git bz file glib/gsettings HEAD'
[09:53] <desrt> and it opened a bug about my HEAD commit to glib, component gsettings
[09:53] <desrt> pops open vi for bug content
[09:53] <desrt> modifies the commit message to contain a reference to the newly-created bug
[09:53] <smspillaz> I wonder if bzr has something like that
[09:53] <desrt> and attaches the commit
[09:55] <cjwatson> ah, insufficient dependency on liblightdm-gobject-0-0
[09:55]  * desrt -> lunch
[10:02] <rodrigo__> hmm, launchpad failing a lot, on dput and when updating a bug status
[10:02] <pitti> jasoncwarner_: ok, sent the chinese edition mail
[10:02] <chrisccoulson> it's not read only now?
[10:03] <jasoncwarner_> pitti: great, thank you
[10:03] <rodrigo__> chrisccoulson, not anymore, it seems
[10:03] <bryceh> chinese edition?
[10:03] <jasoncwarner_> rodrigo__: hey, are you working on date/time indicator or is that all ted's team now?
[10:03] <pitti> rodrigo__: it just fails later on now, although it's officially back indeed
[10:05] <pitti> rodrigo__: pinged mthaddon in #u-devel
[10:05] <rodrigo__> jasoncwarner_, I guess it's ted's team, haven't worked on it
[10:06] <jasoncwarner_> rodrigo_: thanks.
[10:06] <rodrigo_> pitti, yes, pinged him also on #u1-internal :)
[10:07] <rodrigo_> jasoncwarner_, kenvandine was working on some of it, iirc
[10:07] <pitti> rodrigo_: seems my dput actually worked despite teh "Transfer aborted" error message
[10:07] <rodrigo_> pitti, oh, checking mine, although I submitted it 2/3 times :)
[10:08] <rodrigo_> pitti, yeah, accepted and the other 2 submissions rejected
[10:08]  * pitti binNEWs unity-greeter; have fun trying it out!
[10:09] <cjwatson> (bug 809776 for my lightdm problem this morning)
[10:09] <ubot2> Launchpad bug 809776 in lightdm "needs tighter dependency on liblightdm-gobject-0-0" [Undecided,New] https://launchpad.net/bugs/809776
[10:09] <pitti> cjwatson: thanks, assigning to Robert
[10:10] <pitti> cjwatson: oh, what breaks for you wrt. /run ?
[10:10] <rodrigo_> pitti, they're working on it, both known issues
[10:11] <rodrigo_> changing a bug status just worked
[10:11] <pitti> rodrigo_: yeah, see #u-devel
[10:14] <cjwatson> pitti: er, I just want to get work done rather than worrying about what might break
[10:14] <cjwatson> pitti: nothing breaks yet because I haven't upgraded to it :-)
[10:14] <pitti> cjwatson: ah, ok; I'm not aware of anything that still breaks a running system (except for the libc6 debootstrap failure)
[10:14] <pitti> cjwatson: so if that's just cautionsness and not a know bug, I'm relieved :0
[10:14] <cjwatson> ok, but there was enough of it for a while that I was still steering clear
[10:14] <cjwatson> I expect I'll upgrade this week
[10:15] <pitti> the /run/udev thing sucked a lot indeed
[10:17] <pitti> ah, unity-greeter already looks a lot better than the example-gtk one
[10:17] <chrisccoulson> backporting http://hg.mozilla.org/releases/comm-aurora/rev/e3f147cb26aa is going to be some serious fun
[10:18] <pitti> oh, uh!
[10:18] <rodrigo_> chrisccoulson, why do you think the atexit crash in g-s-d is due to gconf? the only atexit I see in gconf sources is in the daemon, not the library
[10:18] <chrisccoulson> rodrigo_, it comes from corba
[10:18] <chrisccoulson> or orbit
[10:18] <rodrigo_> hmm
[10:18] <chrisccoulson> whatever it's called ;)
[10:18] <rodrigo_> orbit, yes
[10:20] <chrisccoulson> rodrigo_, that handler has caused us problems in the past too, eg https://launchpad.net/ubuntu/+source/seahorse-plugins/2.28.1-0ubuntu4
[10:20] <chrisccoulson> i think that was our most frequently reported bug ;)
[10:22] <ogra_> ch unity-greeter
[10:22] <rodrigo_> right, it calls g_atexit in CORBA_ORB_init, which is indeed called by any gconf client app :(
[10:23] <chrisccoulson> rodrigo_, if we want to stop the crashes, we could hack around this by linking the main g-s-d daemon to gconf ;)
[10:23] <chrisccoulson> (so it never gets unloaded)
[10:23] <rodrigo_> I was thinking of making orbit do its cleanup on exit, but using something else than atexit
[10:24] <rodrigo_> but yes, we could patch g-s-d
[10:25] <rodrigo_> chrisccoulson, ok, I'll cook up a patch to make the daemon link to gconf if the gconf plugin is enabled
[10:26] <chrisccoulson> rodrigo_, perhaps we could declare the cleanup function in orbit with "__attribute__ ((destructor))" so that it gets called when unloaded, rather than on exit?
[10:27] <rodrigo_> yes
[10:27] <rodrigo_> it is a gnu extension though
[10:27] <chrisccoulson> i guess that doesn't matter for us
[10:28] <chrisccoulson> some of the linux-specific parts of firefox use gnu extensions ;)
[10:38] <lool> Hey, I wonder why we have netbook seeds in oneiric, is this still relevant?
[10:42] <lool> ogra_: Would you know whether the netbook seed is still useful in oneiric?
[10:42] <ogra_> lool, its dead
[10:43] <ogra_> not sure if there are still any community projects using it though
[10:44] <lool> ogra_: what do you mean with community projects using it?
[10:44] <ogra_> dunno, there were eeepc images etc rolled by external projects in the past
[10:45] <ogra_> we definitely dont use it in ubuntu anywhere anymore
[10:48] <lool> cjwatson: Is there some Launchpad/germinate setup you have to do to stop using ubuntu-seeds/netbook.oneiric?  do I then remove the branch?
[10:48] <cjwatson> lool: historically we've just stopped using dead branches and let them die
[10:49] <cjwatson> lool: Launchpad does need to change though
[10:49] <cjwatson> I'm removing it from tasksel
[10:49] <lool> thanks
[10:50] <cjwatson> and I guess I might as well do the LP change
[10:50] <lool> is this an archive-adminish thing?
[10:50] <cjwatson> no, requires actual patch to LPcode
[10:51] <lool> eh
[10:51] <cjwatson> albeit not a hard one
[10:52] <lool> do you want me to submit a mp?
[10:53] <cjwatson> well, I'd just started, but if you want to do it instead then by all means feel free :)
[10:53] <cjwatson> do you know what to do though?
[10:53] <cjwatson> it's in cronscripts/publishing/cron.germinate - there are two references to netbook in various cases
[10:53] <lool> no, I would grep around
[10:53] <cjwatson> just remove them both
[10:53] <lool> Ok
[10:54] <cjwatson> (I already have two LP branches I'm trying to land, that's probably enough for one poor platform developer)
[10:58] <rodrigo_> hmm, orbit package is in lp:ubuntu/orbit2, right, that is, no ~u-desktop branch for it, right?
[11:22] <seb128> rodrigo_, right
[11:22] <seb128> chrisccoulson, rodrigo_: we should perhaps update gconf to 3.1
[11:23] <rodrigo_> seb128, the dbus-based version?
[11:23] <seb128> chrisccoulson, rodrigo_: they landed the nokia,intel gconf-on-dbus
[11:23] <rodrigo_> yeah
[11:23] <seb128> i.e stopped using orbit
[11:23] <rodrigo_> I just submitted a fix for orbit though
[11:24] <rodrigo_> but yes, makes sense to move to the dbus gconf
[11:24] <rodrigo_> so we can also remove it from the cd :)
[11:24] <chrisccoulson> oh, i can't upload gconf :(
[11:25] <seb128> rodrigo_, well I was on the "don't change something which doesn't give issues" line
[11:25] <seb128> it's quite some changes
[11:25] <seb128> but on another side gconf is less used nowadays and the dbus version got tested at nokia and intel
[11:25] <rodrigo_> yes
[11:25] <seb128> chrisccoulson, when do you apply for real upload rights? ;-)
[11:26] <seb128> chrisccoulson, you should email cjwatson about having it added to the desktop set I guess
[11:26] <seb128> does anybody know why there is no daily iso image since alpha2?
[11:27] <seb128> there is no log on http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/oneiric/
[11:27] <stgraber> last I checked images were failing to build because of the /run transition
[11:27] <cjwatson> yes
[11:27] <seb128> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/ubuntu/current/livecd-20110705.1-i386.out seems to be ok
[11:27] <cjwatson> slangasek was working on the necessary sysvinit merge yesterday, and I handed him an untested mountall patch to go with it
[11:28] <cjwatson> I don't know how far he got
[11:28] <rodrigo_> oh, orbit also not on the desktop set
[11:28] <seb128> rodrigo_, email cjwatson as well I guess ;-)
[11:28] <seb128> stgraber, where do you see that?
[11:28] <cjwatson> seb128: livefs log> but that's from eight days ago
[11:28] <cjwatson> seb128: it's been discussed on #ubuntu-devel several times
[11:28] <stgraber> seb128: in my e-mails, everyday since the base-files upload
[11:29] <seb128> doh
[11:29] <seb128> cjwatson, I used current which apparently doesn't point the real current
[11:29] <cjwatson> current is the last successful build
[11:29] <cjwatson> latest is the last build, successful or not
[11:29] <chrisccoulson> seb128, want me to take the gconf update?
[11:29] <seb128> cjwatson, ok, makes sense, thanks
[11:30] <seb128> chrisccoulson, if you want sure
[11:30] <seb128> chrisccoulson, thanks!
[11:30] <chrisccoulson> seb128, yeah, i'll do some desktop work for a change ;)
[11:30] <seb128> \o/
[12:03] <lool> mvo: hey; you might want to drop https://code.edge.launchpad.net/~mvo/ubuntu-maintenance-check/python-port now that it's merged in Launchpad; at least that's what a comment in launchpad/cronscripts/publishing/maintenance-check.py says  ;-)
[12:12] <lool> cjwatson: Took me a while to branch and read; I only found one ref to netbook in cronscripts/publishing/cron.germinate, which I removed since this script only cares for the development suite; other scripts mentioning netbook: cronscripts/publishing/maintenance-check.py but that needs to keep knowing about netbook for support period of netbook in lucid, lib/lp/soyuz/scripts/tests/test_cron_germinate.py but the tests are written for a ...
[12:12] <lool> ... development release of natty, it seems they don't need to be changed every release; lib/lp/soyuz/scripts/tests/germinate-test-data/mock-lp-root/cronscripts/publishing/maintenance-check.py is just a symlink and lib/lp/soyuz/scripts/expire_archive_files.py is a list of PPAs with names like ~netbook-remix-team which we should never expire
[12:12] <lool> cjwatson: so just confirming with you that there was really only one place to update in cronscripts/publishing/cron.germinate and then I'll submit; are you running parts of the testsuite to test this?
[12:13] <cjwatson> lool: two refs, one is in all caps
[12:13] <cjwatson> lool: no need to change maintenance-check, cron.germinate is all you need
[12:14] <lool> ah thanks; will grep for NETBOOK too, thanks
[12:14] <cjwatson> lool: there aren't any tests for this, and the LP folks are used to merging platform changes to this script without them
[12:14] <cjwatson> (technically, we own this script, it's just in the LP codebase)
[12:14] <lool> ok
[12:14] <lool> I should really have copied over my vim config which sets ignorecase
[12:16] <rodrigo_> lunch, bbl
[12:19] <mvo> lool: indeed, done
[12:21] <lool> alright, netbook seed removal submitted
[12:22] <seb128> hum, lool is still using gnome-panel and not unity!
[12:22] <seb128> lool, thanks for the upload ;-)
[12:29] <mvo> seb128: says the window-maker user ;)
[12:29] <seb128> mvo, shush!
[12:29] <seb128> ;-)
[12:30]  * mvo hugs seb128
[12:30]  * seb128 hugs mvo
[12:35] <chrisccoulson> woohoo, no g-s-d crash on logout \o/
[12:36] <seb128> chrisccoulson, new gconf?
[12:36] <seb128> chrisccoulson, or did you fix it some other way?
[12:36] <chrisccoulson> seb128, yeah, new gconf
[12:36] <seb128> \o/
[12:36] <chrisccoulson> it seems to be working here, gconfd runs, g-s-d doesn't crash and i can view and edit values in gconf-editor
[12:36] <chrisccoulson> and no liborbit ;)
[12:37] <seb128> seems good
[12:37] <seb128> well at least if gconf breaks nowadays it will not break most of the desktop
[12:39] <chrisccoulson> seb128, ok, i've pushed it to https://code.launchpad.net/~ubuntu-desktop/gconf/ubuntu (if you feel like doing some sponsoring) ;)
[12:39] <seb128> ok, can do
[12:39] <chrisccoulson> thanks
[12:39] <seb128> do you want me to give it a round of local testing as well?
[12:39] <seb128> yw
[12:39] <chrisccoulson> seb128, it's up to you. it seems to be working without issue here
[12:40] <seb128> ok, will just build and install it
[12:40] <seb128> I tend to do that, often it's enough to notice issue in the few hours it takes for building and publishing
[12:40] <chrisccoulson> brb, need to restart xchat ;)
[12:46] <lool> seb128: Eh, I'm actually running unity, but for a while I kept alternate sessions available because I feared being stuck with a broken desktop session and not being able to do any work  ;-)
[12:47] <seb128> :-)
[12:47] <lool> I have unity + unity-2d + classic desktop around ATM, but I think I'm confortable dropping one at this point, I'm not sure which one and how to remove the packages though
[12:47] <lool> is there more risk in unity-2d or in classic GNOME to be uninstallable during dev cycles?
[12:48] <lool> s/uninstallable/not installable
[12:48] <seb128> heh
[12:49] <seb128> they should both be installable out of transitions
[12:49] <seb128> i.e i don't think any of those will stay uninstallable for days
[12:49] <seb128> gnome-panel was on my list to fix for today for example
[12:50] <lool> I thought indicator-* wasn't installable for a long time, but it turned out that I had to remove some obsolete packages
[12:50] <lool> indicator-applet, indicator-applet-appmenu, indicator-applet-session, indicator-applet-complete
[12:51] <seb128> right
[12:51] <seb128> nobody bothered porting indicator-applet to gtk3 yet
[12:51] <seb128> it's low priority since dx cares about unity and GNOME doesn't care about indicators
[12:51] <seb128> so it's neither a priority for dx, the default install or GNOME sessions
[12:52] <seb128> which is a bit unfortunate
[12:52] <lool> hmm it seems installable at the moment, is it actually broken?
[12:53] <lool> ah no, I still have all the -gtk2 applets installed
[12:53] <seb128> it shouldn't be installable
[12:53] <lool> hmm despite gnome-panel using gtk-3
[12:53] <seb128> it depends on a libpanel-applet version which doesn't work with gnome-panel
[12:53] <mterry> seb128, I did get a reply from that guy about signing the CA for indicator-datetime.  He has to ask his employer
[12:53] <seb128> we should perhaps make gnome-panel breaks libpanel-applet
[12:53] <seb128> mterry, urg
[12:54] <seb128> mterry, we should just merge those trivial fix, less than 10 lines fixes are not copyrightable and mark said it's ok to merge
[12:54] <lool> yeah, a breaks sounds sensible
[12:54] <lool> so I guess I should rather drop the gnome-panel based stack than the unity-2d one
[12:55] <seb128> lool, well I wanted to avoid leading to get things that ship a binary and an applet not installable because the applet is broken
[12:55] <mterry> seb128, really?  I thought the latest word on that was legal wanted everything to be CA
[12:56] <lool> seb128: at the same time, if the breaks is on the gnome-panel side, you can assume people are using gnome-panel if they hit the breaks and hence the applet might be important to them
[12:57] <lool> if they installed just the pacakge with the binary which pulled libpanel-applet, but not gnome-panel, they are fine
[12:57] <pitti> mterry: Mark said trivial fixes are ok without CA
[12:57] <seb128> mterry, well, I wish that was stated clearly sometime, but pitti pinged mark about a trivial patch recently asking for confirmation if that was ok to commit without ca and he said ok
[12:58] <mterry> pitti, did he give guidelines for what is trivial?
[12:58] <pitti> an obvious one-liner fix certainly is
[12:58] <mterry> (I suspect this patch qualifies, I'm just curious)
[12:58] <lool> I think Steve gave some
[12:58] <pitti> there's no hard line, of cours; a ten-line patch might be trivial or utterly complicated
[12:59] <lool> I can't find Steve's writeup though
[13:00] <mterry> I suspect this is why legal originally wanted everything to go through CA: programmers will likely make mistakes when making legal judgements about triviality
[13:00] <mterry> But I can push this patch through, it seems to be trivial
[13:00] <seb128> mterry, the other issues is that if that's a trivial fix and only one way to fix the bug what happens
[13:00] <seb128> like the contributor doesn't want to sign and we have no other way to fix the typo
[13:00] <seb128> does it mean we can't fix the bug?
[13:01] <lool> seb128: BTW evolution-exchange failed to build; the new upstream release's diff didn't seem to help with this, albeit it could but I doubt it; gnome-shell also fails to build (can't install build-deps -- something around libclutter is broken)
[13:01] <seb128> mterry, well, what we can do for sure is distro patch any patch
[13:01] <mterry> seb128, I suspect you can just clean room it with someone that hasn't seen the patch
[13:01] <seb128> mterry, distro patches don't need c-a
[13:02] <seb128> lool, thanks, clutter I fixed yesterday but I hit a pango depends bug I fixed, it just needs a retry
[13:02] <seb128> lool, doing the retry
[13:02] <seb128> mterry, so while dx figures if they can merge or not we can distro patch the fix if we want
[13:03] <mterry> seb128, mpt: are there any plans for update-notifier this cycle.  I was porting to gtk3/gdbus/gsettings and didn't want to be wasting my time.
[13:03] <mterry> missed a question mark there
[13:03] <seb128> mvo, ^
[13:03] <seb128> mterry, each time I ask mvo he says he want to replace it the day upstart get session jobs management
[13:03] <mterry> I also note it still has a lot of StatusIcon code
[13:03] <seb128> mterry, which is the case for over a year
[13:03] <mpt> mterry, I don't know why update-notifier would need to use GTK at all at this point, but that's more an mvo question
[13:03] <seb128> mterry, yeah, the statusicon code is for i.e xubuntu
[13:04] <mterry> mpt, for statusicons and I think a reboot question dialog or something
[13:05] <mpt> mterry, it hasn't used a status icon since 9.04. And update-manager could handle the restart dialog itself, couldn't it?
[13:05] <mpt> oh, Xubuntu
[13:05] <mvo> mterry: could you push your port somewhere?
[13:05] <mvo> mpt: yeah, other distros
[13:06] <mvo> mpt: this is why I would love to replace u-n with a bunch of upstart jobs for us and leave the ui bits in universe, but I think we are not there yet.
[13:06] <mterry> mvo, I can.  I'm halfway through the gsettings one, but gdbus and gtk3 are done (relatively easy)
[13:06] <mvo> mterry: nice, I will definitely take it :)
[13:07] <mvo> mterry: especially now that update-manager is using gsettings, some stuff they do in concert
[13:07] <mpt> mterry, my only remaining concern relating to update-notifier is bug 351484
[13:07] <ubot2> Launchpad bug 351484 in update-manager "update-manager options no longer match functionality" [Medium,In progress] https://launchpad.net/bugs/351484
[13:08] <mvo> isn't that more a software-properties issue?
[13:09] <mpt> The UI is, certainly. Would it need any u-n changes?
[13:09] <mvo> fwiw, this is part of the recent work in software-properties trunk to factor out the stuff into dbus
[13:09] <mpt> Or is this a case where I reveal just how thoroughly I don't know what I'm talking about? :-)
[13:10] <mvo> mpt: I don't think that it will actually need u-n changes, I may be wrong, but I'm pretty sure that its just a matter of setting the right gconf/gsetting options from s-p as the normal user (this is not possible currently because it runs as root)
[13:11] <mvo> mpt: heh :) the whole interaction became a bit complicated over time with those root vs user settings mix :/
[13:14] <mterry> mvo, https://code.launchpad.net/~mterry/update-notifier/gtk3-and-gdbus/+merge/67831
[13:14] <mterry> still working on gsettings
[13:15] <seb128> mvo, what is u-n still doing in stock unity session?
[13:15] <seb128> mvo, I'm wondering if it wouldn't be easier to stop using u-n and get whatever it's doing in gsd or something
[13:15] <mvo> seb128: just launching a bunch of applications (like update-manager)
[13:16] <mvo> seb128: its doing apport, the detection of upgradable cdroms, interactive upgrade hooks, reboot (but not on ubuntu), checks for the new distro release and update check
[13:17] <seb128> hum
[13:17] <mvo> seb128: I would love to make each of that a indiviual script that is controlled by something else (like upstart sessions)
[13:17] <seb128> it's probably easier to just keep it this way until we get apport session jobs
[13:17] <seb128> seems like non trivial work to move all those somewhere else
[13:17] <mvo> yeah, its usually relative low maintenance
[13:18]  * mvo nods
[13:28] <seb128> chrisccoulson, is that wanted that you let the libgconf2-dev depends on liborbit2-dev?
[13:29] <chrisccoulson> seb128, oh, no, that's an oversight
[13:29] <seb128> ;-)
[13:29] <chrisccoulson> good spot ;)
[13:29] <seb128> chrisccoulson, did you ask cjwatson about having it added to the desktop set btw?
[13:30] <chrisccoulson> seb128, not just yet
[13:34] <seb128> rodrigo_, did you need orbit2 sponsoring btw?
[13:34] <seb128> pitti, there?
[13:35] <seb128> pitti, the preinst in your py3cairo looks weird
[13:35] <chrisccoulson> wtf, i've only just noticed that i've got no wireless connection since i rebooted :/
[13:35] <seb128> gconf issue?!
[13:39] <ogra_> hmpf, so the new lightdm leaves me with a hardlocked greeter
[13:42] <seb128> ogra_, did you upgrade liblightdm-gobject-0-0 as well?
[13:42] <seb128> bug #809776
[13:42] <ubot2> Launchpad bug 809776 in lightdm "needs tighter dependency on liblightdm-gobject-0-0" [Medium,Triaged] https://launchpad.net/bugs/809776
[13:42] <ogra_> oh, no, i didnt
[13:42] <ogra_> i dist-upgraded though
[13:42] <seb128> try that
[13:42]  * ogra_ checks 
[13:42] <seb128> well that should have done it for you
[13:42] <seb128> they come from the same source so got published together
[13:44] <seb128> cjwatson, if you update sets can you add orbit2 and gconf to the desktop one?
[13:44] <seb128> cjwatson, thanks
[13:45] <cjwatson> seb128: can I have mail please?
[13:45] <seb128> chrisccoulson, rodrigo_: ^
[13:45] <seb128> you guys should send those emails ;-)
[13:45] <cjwatson> I already did orbit2 in response to a mail from rodrigo_
[13:46] <seb128> oh ok
[13:46] <seb128> chrisccoulson, send the gconf email now so it's sorted and you can fix the depends and upload ;-)
[13:47] <chrisccoulson> seb128, ok, 1 second
[13:47] <seb128> 1
[13:47] <chrisccoulson> trying to figure out where my wireless went ;)
[13:47] <seb128> chrisccoulson, is it done yet? ;-)
[13:47] <chrisccoulson> lol
[13:47] <chrisccoulson> cyphermox, i have no wireless since i rebooted this morning ;)
[13:47] <cyphermox> oh, sweet
[13:47] <cyphermox> chrisccoulson: what do you get in syslog?
[13:48] <seb128> chrisccoulson, well at least you use a mailer about to send non empty emails ;-)
[13:48] <cyphermox> heheh
[13:48]  * kenvandine notes not to update today :)
[13:48] <pitti> FWIW, wifi working just fine here
[13:48]  * cyphermox tries to update now
[13:48] <cyphermox> pitti: I haven't updated NM in at least a week, so it might be kernel or something else
[13:48] <cyphermox> chrisccoulson: ^^
[13:49] <cyphermox> chrisccoulson: if you pastebin /var/log/syslog I'll try to figure out what it might be
[13:49] <chrisccoulson> cyphermox, http://paste.ubuntu.com/643268/
[13:50] <chrisccoulson> note, my wireless transmitter appears to be turned off completely, like i've switched it off with the kill switch
[13:51] <cyphermox> yeah
[13:51] <cyphermox> but the killswitch is enabled (eg. not blocking wifi)
[13:51] <chrisccoulson> cyphermox, yeah. my bluetooth adapter is still on too (it controls both)
[13:51] <cyphermox> in case, check if rfkill list shows something blocked, but you don't seem to have the wifi driver loaded or exposing a device
[13:52] <cyphermox> (wlan0 isn't listed)
[13:52] <chrisccoulson> cyphermox, bingo. it works if i modprobe iwlagn
[13:53] <chrisccoulson> i wonder why that's not loaded now ;)
[13:53] <cyphermox> oh boy..
[13:53] <cyphermox> could you please reboot to see if it was just a one-shot?
[13:53] <chrisccoulson> cyphermox, yeah, will do that once i've finished uploading all of the mozilla daily builds
[13:54] <chrisccoulson> could be a little while ;)
[13:54] <cyphermox> otherwise you should open a kernel bug, but iwlagn not loading by itself (or a race) doesn't sound like fun :/
[13:54] <cyphermox> np
[13:54] <cyphermox> I don't happen to have a device with iwlagn here sadly
[13:55]  * ogra_ notices that using startx and firing off unity-2d-panel/-launcher manually gets you funny theme issues 
[13:55] <chrisccoulson> right, time to send my non-empty e-mail :)
[13:56] <seb128> ;-)
[13:56] <cyphermox> pedro_: you there?
[13:56] <cyphermox> seb128: do you also send empty emails now?
[13:57] <seb128> cyphermox, no, but debian-devel-changes and some others are rendered empty there (or at least only part of those)
[13:57] <cyphermox> right, it's rendering
[13:57] <seb128> but I didn't try to send emails today since I'm not sure if they will go out blank or not
[13:58] <cyphermox> care to try a PPA package with two extra patches from git?
[13:58] <pedro_> cyphermox, yup
[13:58] <seb128> can do in a bit if pedro doesn't beat me to it
[13:58] <cyphermox> mine don't go blank :)
[13:58] <cyphermox> ok, hold on
[13:58] <seb128> cyphermox, subscribe to debian-devel-changes
[13:59] <seb128> those seem a good case of display empty
[13:59] <cyphermox> right... but I would have preferred to subscribe to that on my other account, which I can't add because gtk still breaks the account wizard ;D
[14:00] <seb128> which speaking of which I'm just working on
[14:00] <cyphermox> cool
[14:00] <cyphermox> https://launchpad.net/~mathieu-tl/+archive/evolution-staging/+sourcepub/1815878/+listing-archive-extra
[14:00] <cyphermox> seb128: pedro_: that's where I put the e-d-s package ^^
[14:00]  * pedro_ trying
[14:00] <cyphermox> if this doesn't work I'll upload 3.1.3 again.
[14:02] <cyphermox> i think it might be because while I applied the patches to evo to remove camel_stream_printf, I didn't also include the similar patches in eds, this would fix it.
[14:03] <lool> seb128: I'm hitting the lightdm greeter crash too; I suspect it's a .dmrc thing, maybe related to ecryptfs
[14:04] <lool> seb128: I see there's an unchecked call to ldm_user_get_session() which I suspect might be returning NULL
[14:04] <lool> could we have an apport retrace of it?
[14:05]  * pitti restarts the retracers after the LP rollout today
[14:05] <seb128> pitti, thanks
[14:05] <pitti> oh, seems seb128 already did?
[14:05] <pitti> a,h, no
[14:05] <pitti> they are stuck
[14:05] <lool> I'd like to check whether greeters/gtk/lightdm-example-gtk-greeter.c:84 is in the stack trace
[14:06] <lool> I'm getting three new bugs now, gah
[14:06] <pedro_> brb
[14:06] <lool> xterm lost its icon in unity, commands launched from alt-f2 don't inherit the session's environment, and gdm doesn't parse /etc/X11/Xresources/*
[14:09] <pedro_> cyphermox, i'm still seeing the blank email bug
[14:10] <cyphermox> boo.
[14:10] <pedro_> :-(
[14:13] <seb128> lool, the session environment is not a bug
[14:13] <seb128> lool, cf http://anonscm.debian.org/gitweb/?p=pkg-utopia/dbus.git;a=commitdiff;h=83799f5a28ca70077e6fb4b06736740ec763fd00
[14:13] <seb128> lool, well it makes appmenu bug because it's Xsession script needs to be moved before the dbus one
[14:17] <rodrigo_> seb128, already sent mail to cjwatson, and seems he's added it, so trying an upload of orbit2 now
[14:17] <seb128> rodrigo_, right
[14:17] <seb128> once chrisccoulson sends his we are set
[14:17] <seb128> or until the next time we have a source not in the set at least ;-)
[14:18] <chrisccoulson> rodrigo_, you requested orbit? (just so i don't duplicate things)
[14:18] <rodrigo_> chrisccoulson, yes
[14:18] <chrisccoulson> wtf, "LDAP server search problem"
[14:18] <chrisccoulson> probably because i'm hammering my connection ;)
[14:19] <seb128> chrisccoulson, use debsign to remote sign the uploads so you don't need to download and upload the tarballs ;-)
[14:19] <chrisccoulson> yeah, i will start doing that before my ISP cuts me off ;)
[14:20] <lool> seb128: I'm not sure what you mean with the above commit around dbus?
[14:20] <seb128> lool, that's what broke the alt-f2 environment thing
[14:20] <lool> seb128: is it because unity is started by dbus which is started without the env?
[14:21] <lool> seb128: I wonder why we didn't patch the line running STARTUP?
[14:21] <seb128> lool, what are you missing in your environment?
[14:21] <lool> or simply added exec </dev/null
[14:22] <lool> seb128: SSH_AGENT
[14:22] <seb128> lool, that commit means that anything dbus activated will get only things which were in the environment at the time the dbus Xsession script ran
[14:22] <seb128> lool, when, where do you set SSH_AGENT?
[14:22] <seb128> right
[14:22] <lool> seb128: Xsession does it; you're right that this commits breaks it
[14:22] <seb128> it's 90x11
[14:22] <seb128> so after dbus
[14:22] <seb128> lool, talk to smcv I guess
[14:22] <lool> seb128: it used to run ssh-agent dbus-launch ... now it's running them separately
[14:23] <lool> seb128: will do,thanks
[14:23] <seb128> lool, 90x11 needs to be moved before the dbus Xsession script
[14:23] <lool> I'd say that stdin shouldbe closed in another way and this change reverted
[14:23] <seb128> or dbus needs to be moved at 99
[14:23] <seb128> lool, or that
[14:24] <seb128> lool, it's breaking appmenu as well, I would not be surprised if it created other issues
[14:24] <seb128> lool, smcv is on #telepathy if you don't know where to find him on IRC
[14:24] <seb128> not sure if he's on oftc or on other channels
[14:25] <rodrigo_> pitti, did you release a new jockey tarball? if not, should I just add the patch for g-c-c to the package or just wait till you do a release?
[14:30] <lool> seb128: I saw him on #debian-devel, but not around right now
[14:30] <lool> will file a bug with debian
[14:30] <seb128> lool, ok
[14:32] <cyphermox> pedro_: building 3.1.3 again locally, then I'll upload it to my ppa again just in case it would not fix the problem :/
[14:33] <pitti> rodrigo_: oh, sorry; can do it now
[14:33] <pedro_> cyphermox, ok, just ping me and i'll re test , thanks :-)
[14:37] <pitti> rodrigo_: uploaded
[14:40] <GunnarHj> pitti: Hello Martin, other things need my attention, so the demo of the shared scripts idea will have to wait a day or two.
[14:40] <GunnarHj> pitti: On another topic, the MP https://code.launchpad.net/~gunnarhj/language-selector/oneiric/+merge/65531 has been there for a while. Do you have time to take a look?
[14:42] <rodrigo_> pitti, cool, thanks!
[14:53] <lool> seb128: had a good discussion on this with smcv on #debian-devel; don't think it is likely to get fixed properly soon; it seems dbus-launch is insane   :-/
[14:54] <seb128> lool, should the dbus Xsession script maybe moved to 99?
[14:54] <seb128> lool, or 81 at least
[14:55] <lool> No
[14:55] <lool> it wouldn't help
[14:55] <seb128> why?
[14:56] <lool> the only way to restore support for the env, is to move back to the old-style launching, but smcv wanted to replace dbus-launch with a thinner wrapper doing something that everybody agrees upon and is trivial
[14:56] <seb128> well if the variable was set before the dbus Xsession script it would be in the dbus environment
[14:56] <lool> because it's not environment coming from the Xsession.d scripts; the environment is setup on startup
[14:56] <lool> that is, the env var is created by ssh-agent when it starts
[14:56] <lool> so that you need to run exactly "ssh-agent dbus-launch foo"
[14:56] <lool> you can't run them separately
[14:57] <seb128> hum ok
[14:57] <seb128> still seems his commit is breaking things over what it's fixing, I wonder if we should revert
[14:57] <seb128> like it fixes a login manager that nobody is using issue
[14:57] <lool> we could revert; it's only relevant for some odd fdms
[14:57] <lool> dms
[14:57] <lool> nodm and another one
[14:57] <lool> slim
[14:58] <seb128> seems like the issues we get as a side effect are annoying over the original bug
[14:58] <seb128> like nobody ever complained about the issue he fixed before in ubuntu
[14:58] <pitti> GunnarHj: hm, seems I didn't get mailed about that one, looking at it now
[14:58] <seb128> but the "fix" at least broken ssh and appmenu
[14:58] <lool> seb128: yup
[14:58] <seb128> lool, what do you think?
[14:58] <lool> seb128: it's complex
[14:58] <lool> seb128: there are really 3 old issues here
[14:59] <seb128> lool, what would you recommend to do? ;-) I trust you to have a better understanding of the different issues of either solution
[14:59] <mterry> mvo, and https://code.launchpad.net/~mterry/update-notifier/gsettings/+merge/67848
[14:59] <lool> a) dbus-launch is a mess that nobody understands and does weird things; smcv proposes a replacment dbus-session-launch or something which would be simple and that people would understand; it would cover exactly one use case
[14:59] <rodrigo_> is xkb-data on the CD?
[14:59] <lool> b) some dms are doing a bit weak things, like relying on the tty that they are launched from and leaving stdin open
[15:00] <seb128> rodrigo_, yes
[15:00] <lool> c) I'm relying on commands launched over dbus to keep an environment coming from somewhere, but that's pretty weak
[15:00] <rodrigo_> seb128, ok, so for the keyboard layouts, libxklavier seems to read stuff from xkb-data and the xmodmaps from gnome-applets-data
[15:00] <mvo> mterry: \o/
[15:00] <lool> so I will probably stop using the Xsession ssh-agent completely and go back to keychain or something like that, and have every shell launched in xterm setup ssh-agent if needs be
[15:00] <seb128> rodrigo_, gnome-applets-data is not on the CD
[15:00] <seb128> rodrigo_, since gnome-panel etc are not on the CD
[15:01] <rodrigo_> so, missing keyboard layouts (https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/800561) might be because of the missing gnome-applets-data?
[15:01] <ubot2> Ubuntu bug 800561 in gnome-control-center "No way to add other keymap than english on Live CD" [High,Triaged]
[15:01] <pitti> GunnarHj: merged/uploaded, thanks!
[15:01] <seb128> rodrigo_, oh, they are not missing
[15:01] <seb128> rodrigo_, the issue is reverse
[15:01] <lool> the whole Xsession setup feels as old and static as sysvinit
[15:01] <seb128> rodrigo_, there are like 15 english layouts on the liveCD try session for some reason
[15:01] <mvo> mterry: in a meething, but I look right when that is over
[15:01] <seb128> rodrigo_, g-c-c limits the number of layout so it doesn't let you add new ones
[15:01] <lool> seb128: smcv said he will do something in dbus-launch in the short term too, as to keep old-world users like me working
[15:01] <seb128> rodrigo_, if you delete all the english variants it works
[15:01] <lool> but essentially the model is broken
[15:02] <seb128> lool, well it's not only you
[15:02] <lool> I think there was some gnome-session API to set env vars or something, that might be a way forward too, don't know
[15:02] <seb128> lool, you said alt-f2 was broken
[15:02] <rodrigo_> seb128, hmm, so where's the bug, in xkb-data? default config? why do we have so many layouts?
[15:02] <seb128> lool, which uses gio to launch commands
[15:02] <seb128> rodrigo_, why is the question
[15:02] <lool> seb128: alt-f2's environment is lacking Xsession's ssh-agent env, yes
[15:02] <seb128> lool, it's only using gio to run commands
[15:03] <seb128> lool, seems like it impacts gio, gdbus and not only dbus-launch
[15:03] <seb128> lool, well gdbus uses dbus-launch somewhere
[15:03] <lool> hmm maybe
[15:03] <seb128> gdbusaddress.c:  command_line = g_strdup_printf ("dbus-launch --autolaunch=%s --binary-syntax --close-stderr", machine_id);
[15:03] <seb128> lool, ^
[15:03] <lool> gosh
[15:04] <seb128> rodrigo_, so it doesn't happen if you pick "try ubuntu" from the menu you get when pressing a key early in the boot
[15:04] <lool> seb128: the thing is that the old-world model is broken for other cases too
[15:04] <lool> for instance, if any process dies, the whole thing might die
[15:04] <seb128> rodrigo_, it does it you use the "try ubuntu" icon on the ubiquity screen you get by not doing anything and waiting it to boot
[15:05] <seb128> rodrigo_, do you know where it gets the "current active keymaps" list from?
[15:05] <lool> I can't update the environment that got inherite in other running processes
[15:05] <lool> so the keychain approach is a bit nicer to handlethis
[15:05] <seb128> lool, hum
[15:05] <lool> environment inheritance and dbus don't play very well together really
[15:06] <rodrigo_> seb128, /usr/share/xmodmap and/or /usr/share/X11/xkb
[15:06] <seb128> lool, still in practice we didn't have real issues before and we have now
[15:06] <seb128> rodrigo_, well those are a static list, if I boot in french I've french only in the g-c-c dialog
[15:06] <lool> seb128: sure; clearly we're better off reverting, and smcv will do something in this direction
[15:06] <seb128> rodrigo_, if I boot in spanish I've spanish
[15:06] <lool> he will likely implement a different dbus-launch change instead
[15:06] <seb128> rodrigo_, so "current" is coming from somewhere?
[15:06] <lool> but the truth is that it's just the tip of the iceberg
[15:06] <seb128> lool, right, like it's not only dbus-launch
[15:07] <seb128> lool, gio is broken, ie the alt-f2
[15:07] <seb128> well "broken"
[15:07] <seb128> it will not get the correct environment either
[15:07] <lool> seb128: alt-f2 works, just lacks some environment
[15:07] <seb128> well which in practice means no keyring
[15:07] <seb128> no appmenu
[15:07] <seb128> etc
[15:07] <lool> ah is keyring broken too?
[15:07] <lool> I didn't check that
[15:08] <lool> I'm not running it anymore
[15:08] <seb128> well I didn't check
[15:08] <seb128> but it used to rely on some environment as well
[15:08] <lool> I think dbus is working ok
[15:08] <lool> it's just lacking bits from ssh-agent in my case
[15:08] <seb128> lool, thanks for the details, I think I will just revert and wait to see what smcv does in debian
[15:09] <lool> yup
[15:09] <lool> sounds good
[15:09] <seb128> it's the best middle way for us if we don't have anyone wanting to work actively on the issues the change create
[15:09] <lool> and I will move away from ssh-agent in Xsession myself
[15:09] <seb128> kenvandine, ^ I will revert the dbus Xsession script behaviour change, so no need to bother moving appmenu conffiles
[15:15] <lool> seb128: since we're discussing old-cruft...  :-)  I am hitting a bug since I switched to gdm while ligthdm is crashing; it's in gdm's Xsession script which expects a /etc/X11/Xresources file while it's actually a directory in Debian/Ubuntu
[15:15] <lool> lightdm had the same issue, I bet it's a file on Fedora/Solaris and it's a dir on Debian/Ubuntu
[15:15] <lool> I guess we would want to stop having tons of Xsession scripts all over the place, but in practice I suppose I should simply go patch gdm's copy?
[15:17] <seb128> lool, hum, that bug rings a bell
[15:18] <seb128> lool, but yeah, feel free to patch it
[15:18] <kenvandine> seb128, great :)
[15:20] <seb128> lool, if you do a gdm upload can you include another trivial fix?
[15:21] <lool> seb128: sure
[15:23] <seb128> lool, bug #806857
[15:23] <ubot2> Launchpad bug 806857 in gdm "Plymouth integration should use upstream “-background none” option" [Undecided,Confirmed] https://launchpad.net/bugs/806857
[15:23] <seb128> lool, it's just changing "-nr" to "-background none" in one of the patches
[15:25] <m_conley> rodrigo_: ping
[15:26] <lool> seb128: got it, ok
[15:26] <seb128> lool, thanks ;-)
[15:27] <rodrigo_> m_conley, pong
[15:28] <m_conley> rodrigo_: hey - got a minute to help me figure out where my Ubuntu One address book went?  :)  I need it to test my EDS add-on
[15:29] <m_conley> rodrigo_: I understand contacts sync is having a service disruption, so I created a new U1 account.  However, Evolution isn't seeing the Ubuntu One address book.  Firing up e-addressbook-factory shows:  http://pastebin.mozilla.org/1271282
[15:29] <m_conley> rodrigo_: perhaps there's some way to "factory reset" evolution?
[15:30] <rodrigo_> m_conley, last notice I have is that desktopcouch has some keyring problem, so haven't been able to open u1 addressbooks in oneiric for some weeks
[15:30] <m_conley> rodrigo_: ah, I see - so I'm not the only one.  Ok, cool.  :)
[15:30] <rodrigo_> :)
[15:30] <m_conley> rodrigo_: thanks!
[15:31] <Laney> Sweetshark: have you built libo/oneiric since mono 2.10.1 & cli-common 0.8 was uploaded? did it work?
[15:34] <ogra_> hmm, funny, now lightdm just works again
[15:34] <ogra_> i didnt do anything
[15:34] <lool> ogra_: it might be because your .dmrc now has the proper data
[15:35] <BigWhale> Greetngs.
[15:35] <ogra_> lool, well, i upgraded to the latest
[15:35] <lool> ogra_: did you run another dm in the mean time, or did you login in another way?
[15:35] <ogra_> rebooted and couldnt put anything in at the greeter anymore
[15:36] <ogra_> rebooted again and restarted lightdm .. nothing in the logs etc ...
[15:36] <ogra_> then used startx for a while ... now after a reboot lightdm is back to normal
[15:37]  * ogra_ would like to see unity-greeter but apparently installing it isnt enough)
[15:40] <lool> seb128: would you close https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/809900 when reverting the dbus-launch changes?
[15:40] <ubot2> Ubuntu bug 809900 in dbus "Environment of alt-f2 commands not the same as compiz'" [Undecided,New]
[15:41] <seb128> lool, yes
[15:41] <seb128> lool, do you prefer to keep it open to track potential work needed?
[15:42] <lool> seb128: not really, I don't think we will ever have the time to look after this kind of cleanups
[16:09] <seb128> pedro_, do you have a jhbuild?
[16:09] <pitti> good night everyone, Taekwondo time
[16:09] <seb128> 'night pitti
[16:09] <seb128> pitti, oh, I'm off tomorrow and friday btw
[16:09] <pitti> seb128: oh, enjoy
[16:10] <seb128> tomorrow is a national holiday (bastille day)
[16:10] <seb128> then I'm swapping friday
[16:10] <seb128> well I might be around doing some hacking if it rains as they plan, let's see
[16:10] <seb128> pitti, thanks ;-)
[16:11] <pedro_> seb128, I'd say no, is there but 'really' outdated
[16:14] <seb128> pedro_, ok, slacker :p
[16:14] <seb128> pedro_, ok, doing a gtk build for gnome bug 653960
[16:14] <ubot2> Gnome bug 653960 in Sound "audio capplet: device list truncated in input and output tabs" [Normal,Needinfo] http://bugzilla.gnome.org/show_bug.cgi?id=653960
[16:14] <seb128> rodrigo_, ^ or maybe you can try in your jhbuild?
[16:14] <pedro_> seb128, haven't had time to updated it  since you keep kicking at my door
[16:15] <chrisccoulson> seb128, you're slacking tomorrow? ;)
[16:15] <seb128> chrisccoulson, tomorrow and friday!
[16:15] <chrisccoulson> lol
[16:15] <seb128> chrisccoulson, speaking of slacking did you send the gconf email? ;-)
[16:16] <chrisccoulson> seb128, i did, and i was just in the process of uploading ;)
[16:16] <rodrigo_> seb128, yes, coming next on my todo list
[16:16] <seb128> chrisccoulson, don't forget to drop the depends on liborbit2-dev ;-)
[16:16] <seb128> rodrigo_, thanks
[16:16] <chrisccoulson> seb128, done ;)
[16:16] <seb128> rodrigo_, btw sorry was a bit crazy before
[16:17] <seb128> rodrigo_, do you know how the current keymaps list is built?
[16:17] <seb128> rodrigo_, like what says my system has french and english configured?
[16:17] <seb128> rodrigo_, the files you pointed have all the definitions, they don't tell you what is configured?
[16:18] <seb128> chrisccoulson, \o/
[16:18] <dobey> rodrigo_: are you going to do a new evo-couchdb release anytime soon?
[16:20] <rodrigo_> seb128, your selected layouts are in gsettings, the rest is xkb/X11 thing
[16:21] <rodrigo_> dobey, yes, this week probably or beginning of next one
[16:21] <seb128> rodrigo_, well on first login it gets the layout from x11 somewhere
[16:21] <seb128> rodrigo_, do you know if that's libxklavier or something? is that an xprop?
[16:21] <seb128> rodrigo_, the issue for the bug you pointed is to know why the capplet lists a load of english variants
[16:22] <seb128> rodrigo_, do you know if there is any tools I can use to get the values from x11?
[16:22] <dobey> rodrigo_: did you make an updated "enable the u1 entry by default" patch yet? (just checking, not rushing)
[16:22] <rodrigo_> seb128, no, still investigating all that
[16:23] <seb128> rodrigo_, ok
[16:23] <seb128> rodrigo_, I can reproduce the bug if you need help testing
[16:23] <rodrigo_> dobey, no, not yet, will do after the release
[16:23] <rodrigo_> seb128, I am also downloading the live image, to test it myself, so I guess I'll be able to replicate
[16:23] <rodrigo_> if not, I'll ask you
[16:23] <seb128> rodrigo_, ok
[16:24] <seb128> rodrigo_, don't do the same mistake than me, don't press a key on boot :p
[16:24] <dobey> rodrigo_: ok, thanks. please ping me when you do, so i can fix the nightlies :)
[16:24] <seb128> rodrigo_, let it boot until ubiquity and click on "try ubuntu"
[16:24] <seb128> well maybe cjwatson knows better how that work
[16:25] <seb128> cjwatson, do you know if keyboard layouts are set differently if you select "try ubuntu" on the text mode menu from a liveCD compared at if you let it boot and select "try ubuntu" on ubiquity?
[16:26] <seb128> cjwatson, using the second option leads to bug #800561
[16:26] <ubot2> Launchpad bug 800561 in gnome-control-center "No way to add other keymap than english on Live CD" [High,Triaged] https://launchpad.net/bugs/800561
[16:27] <seb128> cjwatson, somewhat GNOME lists all the possible english variants as being configured
[16:27] <seb128> pitti, btw did you see my py3cairo preinst comment before?
[16:28] <seb128> pitti, it seems like a copy from pycairo to handle packaging system changes, shouldn't be required in the new source?
[16:32] <cjwatson> seb128: well, it goes into a different session, so it's possible
[16:33]  * desrt cranks down the ugly by cranking up the evil
[16:33] <cjwatson> seb128: ev knows that code better than I do though
[16:33] <cjwatson> (I mean, it goes into a different session on the way through)
[16:33] <cyphermox> desrt: how evil? :)
[16:34] <desrt> stealing-pointer-to-class-vtable-and-patching-my-own-function-in evil
[16:34] <cyphermox> oh, so happy-fun-fun evil.
[16:35] <seb128> cjwatson, thanks, I should have asked on #ubuntu-devel, doing that now
[16:45] <cyphermox> seb128: pedro_: 3.1.3 (and rebuilding evo) seems to work properly, so I'll upload them again shortly (heading out to lunch, back in a few)
[16:45] <seb128> ok
[16:45] <seb128> did pedro try the ppa build?
[16:45] <seb128> cyphermox, btw I uploaded a fixed gtk
[16:45] <cyphermox> with the patch, he tried, but it didn't fix the problem
[16:46] <cyphermox> I prepared 3.1.3.1.is.3.1.3-0ubuntu1~mtrudel1 for my PPA and it's building now, but locally it all seems good so I'd just upload it
[16:47] <pedro_> looks like evo wants me to use thunderbird :-P
[16:47] <cyphermox> pedro_: well, there is that... since we want to have thunderbird by default, this will ensure it's the case ;D
[16:47] <pedro_> lol
[16:48] <seb128> not being able to add accounts for some weeks was a good way to make sure nobody installed oneiric would try evo
[16:49] <pedro_> at least i didn't lost all my emails like when it migrated to sqlite, that was really bad
[16:50] <seb128> use imap ;-)
[16:51] <seb128> rodrigo_, ok, so we are discussing the keymap issue on #ubuntu-devel
[16:51] <seb128> rodrigo_, but it seems rather an ubiquity issue, so I will reassign there
[16:55] <seb128> rodrigo_, ok, reassigned to ubiquity, you can probably move on to another bug
[17:02] <ricotz> hello
[17:03] <ricotz> is someone looking at the telepathy-glib build failure?
[17:03] <seb128> ricotz, check with infinity on #ubuntu-devel, he did the upload
[17:04] <ricotz> seb128, ok
[17:47] <seb128> re
[17:47] <seb128> lool, you can use the unity-greeter if you want in gdm
[17:47] <seb128> ups
[17:47] <seb128> lightdm
[17:47] <seb128> lool, confirmed it's the simple gtk one which segfault on ecryptfs directories
[17:48] <lool> seb128: Yeah, I bet it's because it can't open .dmrc there
[17:48] <seb128> could be
[17:48] <seb128> you can use the others workaround as well
[18:34] <cyphermox> seb128: about to upload e-d-s now; that will need rebuilds of things like indicator-datetime again though
[18:36] <seb128> cyphermox, did that break abi again?
[18:36] <seb128> cyphermox, did you try to git snapshot eds and evo to see if that worked?
[18:36] <cyphermox> yes. 3.1.3 has libcamel -27, 3.1.3.1 had -28
[18:37] <cyphermox> not git snapshots, but I took all the patches that did stuff other than just cleanup and chaging layout
[18:37] <seb128> hum
[18:37] <cyphermox> I can always do a test with git HEAD
[18:37] <seb128> downgrading abi doesn't seem right
[18:37] <cyphermox> I know :/
[18:38] <seb128> we can keep evo broken for a few days
[18:38] <cyphermox> I'll try some more testing with things in git see if I can pinpoint it to a particular thing broken
[18:39] <seb128> what I would do there is to upgrade both to git, see if it works, if not go on #evolution and ping mbarnes
[18:39] <cyphermox> right
[18:39] <seb128> let's not break abi both way again
[18:39] <cyphermox> I'll push all that to my evolution-staging PPA as before
[18:39] <seb128> oneiric is still in alpha and evo is not default
[18:39] <seb128> thanks
[18:41] <cyphermox> fwiw, what I tested before was with EDS up to 9804a01be7a9db5a30791ee3319a076e94946d72; the rest seemed like just code cleanup and translations
[18:41] <seb128> go on #evolution and ask mbarnes if git trunk is supposed to work
[18:41] <seb128> it's way easier that to try to figure what's wrong on your side
[18:42] <seb128> he should know what the status is
[18:52] <seb128> cyphermox, so are we sure that your ppa version is broken? did somebody else than pedro tested?
[18:52] <cyphermox> no
[18:52] <cyphermox> I
[18:52] <cyphermox> gah
[18:52] <seb128> ok, let me try now
[18:52] <cyphermox> nah
[18:52] <cyphermox> it has 3.1.3.1.is.3.1.3 now
[18:53] <cyphermox> I
[18:53] <cyphermox> enter is too close to apostrophe :)
[18:54] <cyphermox> I'll put the patches in that I believe should have everything work, upload both eds and evo, and then we'll test
[19:01] <seb128> cyphermox, ok, I'm done with other things I was doing so I can do testing, let me know if you get those built somewhere
[19:01] <cyphermox> it's pushed, waiting for it to build
[19:01] <dobey> hrmm, where is that bcurtis character
[19:02] <cyphermox> seb128: amd64 or i386?
[19:02] <seb128> cyphermox, i386
[19:02] <cyphermox> amd64 is already building, i386 will be an hour at least
[19:02] <seb128> dobey, he has not been on IRC for a while it seems
[19:03] <dobey> seb128: yeah, i noticed that :)
[19:04] <seb128> cyphermox, one hour doesn't seem likley
[19:04] <seb128> cyphermox, the builder queue has 19 jobs waiting
[19:04] <cyphermox> right, that's why I added "at least" ;)
[19:04] <seb128> cyphermox, no, I think it's going to be less
[19:04] <cyphermox> ah
[19:05] <cyphermox> it's been taking a little while lately
[19:05] <seb128> where did you upload?
[19:05] <cyphermox> https://launchpad.net/~mathieu-tl/+archive/evolution-staging
[19:05] <seb128> ok
[19:05] <cyphermox> normally, e-d-s updated should be sufficient; let's hope it really will be.
[19:06] <seb128> bah
[19:07] <seb128> it's ricotz and chrisccoulson blocking the builders
[19:07] <chrisccoulson> wassup?
[19:07] <chrisccoulson> wasn't me....
[19:07] <chrisccoulson> ;)
[19:07]  * cyphermox fires up the home builder machine ;)
[19:08] <seb128> chrisccoulson, ubuntu-mozilla-daily building trunk versions
[19:08] <seb128> chrisccoulson, I blame you!
[19:08] <chrisccoulson> i've only got 5 builds going ;)
[19:08] <seb128> "only"
[19:08] <chrisccoulson> actually, 4
[19:08] <seb128> ;-)
[19:08] <ricotz> ;)
[19:08] <seb128> bah, and launchpad timeout
[19:08] <chrisccoulson> you should see them just after i've uploaded the dailies ;)
[19:09] <seb128> I can figure who uploaded a gtranslation update in the gnome3-ppa but I will bet on ricotz
[19:09] <seb128> can't
[19:09] <chrisccoulson> perhaps it's time for me to do another daily build!
[19:09] <seb128> chrisccoulson, no, it's time for you to get dinner! ;-)
[19:09] <chrisccoulson> heh
[19:09] <ricotz> heh
[19:10] <seb128> ricotz, if that's you who did the gtranslator update, is there a need to backport softwares nobody use in that ppa? ;-)
[19:10] <ricotz> i hope some like to package cogl
[19:10] <ricotz> someone*
[19:10] <seb128> ricotz, what about you? ;-)
[19:11] <ricotz> seb128, i added since it was a gtk3 build and now i need to keep it a bit updated :\
[19:11] <ricotz> seb128, hmm
[19:12] <seb128> hum, k, I think it's a bit crazy that the ppa is an oneiric copy
[19:12] <seb128> if users really want oneiric they can as well dist-upgrade ;-)
[19:12] <ricotz> it isnt a oneiric copy
[19:12] <seb128> well it's close
[19:12] <ricotz> it doesnt include 3.1.x
[19:12] <seb128> you seem to backport every single GNOME upload
[19:12] <seb128> or GNOMEish
[19:13] <seb128> well, that's something I guess ;-)
[19:13] <seb128> well I can understand you backport GNOME3
[19:13] <ricotz> right, but still it seems to be heavily used
[19:13] <seb128> but things like gtranslator seem weird
[19:13] <seb128> like not sure we have anybody using that
[19:14] <ricotz> i know
[19:15] <seb128> ricotz, like is there any need to do git pango builds? ;-)
[19:16] <seb128> it's entertaining to watch the builder queue ;-)
[19:16] <seb128> well natty git builds
[19:17] <ricotz> i needed the G_CONST stuff and add it to my scripts
[19:18] <ricotz> but it seems they broke the introspection build
[19:23] <dobey> Laney: ping
[19:23] <Laney> hi
[19:23] <dobey> Laney: hi. is mono-csc a debian/ubuntu-only thing?
[19:23] <Laney> yep
[19:24] <dobey> oh :(
[19:24] <Laney> just carry on using gmcs upstream
[19:25] <seb128> chrisccoulson, you do 3h builds of firefox daily?
[19:25] <seb128> bah, I'm glad the build is done but no wonder we get ppa backlog :p
[19:25] <chrisccoulson> seb128, yeah
[19:25] <chrisccoulson> seb128, it's not as bad as chromium ;)
[19:25] <seb128> right, don't get me started on fta ;-)
[19:26] <kenvandine> hehe
[19:26] <chrisccoulson> (although, i do firefox *and* thunderbird)
[19:26] <kenvandine> seb128, ok, i just finished the last thing i considered a blocker before uploading gwibber to oneiric :)
[19:26] <seb128> kenvandine, oh, don't start smiling, I've noticed gwibber on the list!
[19:26] <seb128> \o/
[19:26] <kenvandine> :)
[19:26] <seb128> somebody was doing a gwibber natty build but it seems done now
[19:26] <Laney> dobey: honestly it's nothing to worry about
[19:27] <Laney> the patch just fixes what was intended to be the case anyway
[19:27] <dobey> Laney: i'm not worried. i'm just saying it sucks
[19:27] <dobey> :)
[19:27] <Laney> how does it suck?
[19:27] <kenvandine> i need to run out to go to meeting my kid's new teachers... but i'll plan to upload it in the morning :)
[19:28] <Laney> it's a convenient way for debian/ubuntu to switch the default profile without upstreams having to care
[19:28] <dobey> Laney: because if anyone downloads random mono app and compiles it on debian/ubuntu, it presumably won't do the right thing
[19:28] <seb128> kenvandine, great ;-)
[19:28] <Laney> untrue
[19:28] <dobey> Laney: then why is that patch needed for libu1?
[19:28] <kenvandine> bbiab
[19:28] <Laney> so that the distribution's copy uses the distribution's default
[19:29] <dobey> why shouldn't any random source i download and compile on ubuntu, not use the ubuntu defaults to compile with?
[19:29] <dobey> (by default)
[19:29] <Laney> because it's an ubuntuism?
[19:30] <Laney> you don't expect everything you do in the packaging to be reflected in the upstream build process
[19:31] <dobey> so if libubuntuone is built against the 4.0 profile, and i'm hacking on banshee from git, it won't work, because when i just do ./autogen.sh && make in banshee, it's going to build against the 2.0 profile, and the libu1 bindings will be 'too new' to use, no?
[19:32] <dobey> i mean, if something changes with default flags in gcc in ubuntu, that gets reflected when I build something written in C
[19:32] <Laney> 2.0 apps cannot use 4.0 libraries
[19:32] <dobey> exactly
[19:32] <dobey> this seems like a problem to me, unless we're going to build for both by default?
[19:34] <Laney> no
[19:36] <dobey> so this is a problem, yes? because i'm having a really hard time understanding how it isn't
[19:36] <Laney> you have to ask your application to use the 4.0 compiler if you are building against 4.0 libraries
[19:37] <Laney> it isn't that hard
[19:37] <Laney> sooner or later upstreams will switch to 4.0 too
[19:38] <dobey> i'm not arguing about the difficulty of passing different arguments to compile against a different profile
[19:38] <dobey> i'm arguing that by default, i shouldn't have to, to build and use an app, on ubuntu
[19:41] <Laney> i don't see how we can guarantee to support this for every single application
[19:41] <Laney> for banshee you can use the daily builds
[19:42] <dobey> using banshee daily builds doesn't help me hack on the source any easier
[19:43] <dobey> if we can't support it, why would we switch the default?
[19:43] <Laney> support what?
[19:43] <dobey> seems like it would be better to keep building as 2.0 for now, for libraries, since the 4.0 apps can still load them?
[19:43] <Laney> look at this build I did today https://launchpad.net/ubuntu/+source/banshee/2.1.0-1ubuntu5
[19:43] <Laney> seems well supported
[19:43] <dobey> support the 4.0 profile
[19:48] <dobey> seems not well supported to me, if i can't download the upstream source of banshee from git, do apt-get build-dep banshee, and end up with a working build after doing ./autogen.sh && make run, with no special config
[19:55] <Laney> no, instead you have to do ./autogen.sh MCS=/usr/bin/mono-csc
[19:55] <Laney> our job is to support everything in the archive. we are doing that.
[20:01] <dobey> that seems broken to me
[20:02] <dobey> we don't require people to do that with other languages when we change the default profiles for them
[20:02] <dobey> we just change the default profile, and if upstream stuff breaks on new ubuntu, then so be it
[20:10] <Laney> i don't think i have ever seen an assertion that all upstream software must be buildable straight off
[20:10] <Laney> what if they start requiring a new library?
[20:12] <dobey> Laney: i'm not saying all upstream software should be buildable
[20:13] <dobey> Laney: i'm saying anything i try to build on ubuntu should use the same defaults as the stuff that's shipped in ubuntu
[20:14] <dobey> there have certainly been many updates in ubuntu over the years that have broken upstream software building
[20:14] <dobey> like the recent gcc update in oneiric did
[20:18] <seb128> cyphermox, bah, eds on i386 failed to upload
[20:20] <cyphermox> failed to upload?
[20:20] <cyphermox> ah I see
[20:22] <seb128> cyphermox, doing a local build now...
[20:22] <cyphermox> ok
[20:22] <seb128> will be easier
[20:24] <cyphermox> I have a local build in my buildd almost done too
[20:44] <seb128> cyphermox, eds from your ppa makes evo segfault on start
[20:44] <cyphermox> yes
[20:44] <cyphermox> em-format-html.c:2946
[20:45] <seb128> hum
[20:45] <seb128> so what's next?
[20:46] <lamalex> mterry, is there any way to control piecemeal what gets restored by deja-dup?
[20:46] <mterry> lamalex, yes.  hold on a sec
[20:46] <mterry> lamalex, https://live.gnome.org/DejaDup/Help/
[20:47] <lamalex> bitchin
[20:47] <mterry> lamalex, basically, right click in nautilus
[20:47] <cyphermox> seb128: I'm looking into it; this is pieces of code touched by the patch I added to eds
[20:48] <seb128> cyphermox, you should just snapshot both eds and evo git rather than backport individual commits
[20:48] <seb128> cyphermox, or diff tarball to trunk and drop it in a patch dir
[20:48] <cyphermox> seb128: that's just something I already had
[20:52] <seb128> cyphermox, is there anything I can help with?
[20:53] <cyphermox> seb128: not that I can think of. I'm doing the diff to have one patch that will make evo / eds be at git HEAD
[20:54] <seb128> ok
[20:54] <cyphermox> my local buildd is fixed now too so I'll just quickly do the builds locally in pbuilder instead of waiting after PPAs
[21:06] <seb128> time to call it a day, by everybody
[22:18] <bryceh> where does the indicator applet write logs?  trying to figure out why I can start banshee from commandline but not indicator (probably nfs' fault)
[22:20] <TheMuso> bryceh: ~/.cache/indicators
[22:21] <bryceh> TheMuso, hmm empty
[22:23] <bryceh> ok, killing the indicator service seems to have restored it
[22:26] <TheMuso> hrm
[22:28] <RAOF> Banshee starts for me, but the indicator doesn't disappear.
[22:28] <RAOF> Incidentally, did anyone else have problems logging in from lightdm today? :)
[22:31] <ogra_> yes, i had a hanging greeter that magically started working again after a while
[22:32] <ogra_> nothing in the logs though :/
[22:32] <RAOF> Oh, maybe I just should have waited longer for it to ask for my password then :)
[22:32] <ogra_> no, i mean after several hours of working under a startx session :P
[22:32] <ogra_> and after a few reboots
[22:34] <RAOF> :)