[06:10] <didrocks> good morning
[07:00] <pitti> desrt: I don't know off-hand, let me look
[07:08] <didrocks> guten morgen pitti
[07:13] <mitya57> hi tkamppeter__
[07:13] <mitya57> did you see my patch in bug 1069324?
[07:13] <ubot2`> Launchpad bug 1069324 in hplip (Ubuntu) "diagnose_queues.py crashed with NameError in su_sudo(): global name 'utils' is not defined" [Medium,Triaged] https://launchpad.net/bugs/1069324
[07:14] <mitya57> if you are going to do an upload, please include it
[07:17] <mitya57> ah, that patch also exists in debian experimental, will now forward it
[07:58] <chrisccoulson> good morning everyone
[07:58] <didrocks> hey chrisccoulson! how are you?
[07:58] <chrisccoulson> didrocks, yeah, not too bad thanks
[07:58] <chrisccoulson> oh, yippee! another API break: https://launchpadlibrarian.net/122148213/buildlog_ubuntu-quantal-amd64.firefox-trunk_19.0~a1~hg20121105r112304-0ubuntu1~umd1_FAILEDTOBUILD.txt.gz
[07:59] <chrisccoulson> \o/
[07:59] <chrisccoulson> i *love* these
[07:59] <chrisccoulson> :/
[08:03] <chrisccoulson> lol @ https://twitter.com/Queen_UK/status/265713941517303808
[08:07] <didrocks> chrisccoulson: I don't remember, did you need another stacktrace for me for thunderbird hanging?
[08:08] <chrisccoulson> didrocks, yes please :)
[08:08] <didrocks> chrisccoulson: http://paste.ubuntu.com/1336807/
[08:08] <didrocks> all threads for your own pleasure :)
[08:10] <chrisccoulson> didrocks, thanks. do you still have it open in gdb?
[08:10] <didrocks> chrisccoulson: no, I needed to start getting my emails for the day :/
[08:10] <chrisccoulson> ah, that's ok
[08:11] <didrocks> chrisccoulson: I can try to stuck it once more if you need more info
[09:04] <robru> pitti: ping
[09:04] <tkamppeter> mitya57, thank you very much. I will apply it soon.
[09:05] <pitti> hey robru, how are you? made it back in one piece?
[09:05] <robru> pitti: nope! I am still in CPH ;-)
[09:05] <robru> pitti: my flight is thursday.
[09:05] <pitti> robru: oh right, I forgot
[09:05] <pitti> found a couch?
[09:06] <robru> pitti: yeah, I am staying in a student dorm. it is quite an experience here ;-)
[09:06] <robru> pitti: I need to tap into your vast knowledge of pygobject
[09:07] <robru> pitti: http://bazaar.launchpad.net/~unity-team/libunity/trunk/view/head:/src/unity-lens-private.vala#L100 here is some vala code that overrides an object's constructor in order to set some construct-only properties that the default constructor won't do. is there any way to achieve this in python?
[09:08] <pitti> robru: yes, it's working exactly the same way
[09:08] <pitti> foo = Dee.SharedModel(prop1=value1, prop2=value2, ...)
[09:08] <pitti> this is calling the GObject constructor
[09:09] <seb128> hey desktopers
[09:09] <pitti> Dee.SharedModel.new() would call the specific ctor instead
[09:09] <didrocks> salut seb128
[09:09] <mitya57> tkamppeter, thanks
[09:09] <pitti> hey seb128, salut
[09:09] <seb128> hey didrocks, pitti, mitya57, robru
[09:09] <robru> pitti: really? Ahhhhhhhhhhh you have to use kwargs! I was trying positional args and it kept telling me that there was a maximum of 1 arg to the constructor
[09:09] <robru> hey seb128
[09:09] <pitti> robru: actually, the GObject ctor takes no positional args at all
[09:10] <pitti> robru: so this works as long as the specific ctor does nothing else than allocating the object and set properties (which any well-behaved ctor should do)
[09:10] <robru> pitti: I was doing foo=GObject.new(Dee.Peer) and that worked to create a Dee.Peer, but it warned about construct-only properties not being set
[09:10] <pitti> robru: ah, I haven't actually tried that one; it might work with using kwargs there
[09:11] <pitti> robru: but Dee.Peer(prop1=..., ...) looks a bit nicer IMHO
[09:11] <pitti> LMAO @ https://plus.google.com/101824923181156392444/posts/1N6PcSMKL4g
[09:12] <robru> pitti: hmmmm, yes the kwargs do seem to be working now that I've tried that. thanks!
[09:12] <mitya57> hey seb128
[09:13] <larsu> robru, sometimes the "_new" convenience methods look a bit nicer: for example Gio.ThemedIcon.new("quit") instead of Gio.ThemedIcon(name="quit")
[09:13] <robru> larsu: yes, that was precisely the problem; the _new method for this particular object is broken and accepts no arguments, so I'm trying to work around that.
[09:13] <robru> brb
[09:15] <pitti> larsu: that's precisely the difference: Class() -> Gobject constructor Class.new -> calling class_new() ctor
[09:16] <larsu> pitti, yep. For a properly written foo_new this should be exactly the same, though
[09:16] <pitti> larsu: not quite, as _new() might take positional arguments and might set additional properties which the GObject ctor won't
[09:17] <pitti> e. g. you can write Gtk.Button.new_with_label('foo') or Gtk.Button(label='foo')
[09:17] <larsu> true, I meant when giving the same properties to g_object_new
[09:17] <pitti> *nod*
[09:17] <larsu> in any case, foo_new should at least take all construct-only properties as positional args
[09:17] <larsu> otherwise it's worhless
[09:17] <larsu> *worthless
[09:18] <pitti> right; that seems to be a bug in dee
[09:21] <seb128> pitti, bug in dee, mhr3 will tell you that's non-sense ;-)
[09:21] <mhr3> damn right! :P
[09:21] <pitti> oh sorry, "undocumented feature" of course!
[09:21] <mhr3> you're holding it wrong :)
[09:48] <robru> back
[09:49] <robru> pitti: thanks again
[09:52] <pitti> no worries
[11:24] <seb128> didrocks, https://launchpad.net/ubuntu/+source/bamf ... not sure if the SRU team still does pocket copies from <n-1>-updates to <devel> but could you check and get the current version uploaded to R if they don't?
[11:32] <didrocks> seb128: I kept an eye on those, bamf is not the only one is that case. Some were copied, other weren't. I plan to fix that by eow
[11:32] <didrocks> (also, funny to see fast propagation of bamf, just few days in proposed after all ;))
[11:34] <robru> didrocks, why haven't i seen any photos of myself from copenhagen yet???
[11:35] <robru> I seem to remember somebody snapping a few ;-)
[11:35] <didrocks> robru: want to be on g+? ;)
[11:36] <robru> didrocks, haha, sure ;-)
[11:37] <didrocks> robru: will do later today then! ;)
[11:37] <pitti> robru: I have some of you
[11:37] <pitti> robru: http://piware.de/fotos/UDS-Kopenhagen-Oct2012/
[11:37] <robru> pitti, oh no, these may limit my career ;-)
[11:37] <pitti> nah, all safe!
[11:38] <pitti> not quite as cool as seb128 in http://piware.de/fotos/UDS-Kopenhagen-Oct2012/slide_47.html, of course :)
[11:39] <robru> seb128 is a badass ;-)
[12:04] <seb128> back from lunch
[12:05] <seb128> didrocks, ok, no hurry, I just wanted to point it, SRU team has been talking in the past of stopping the pocket copies ... I will check with them what's their official position there
[12:05] <didrocks> seb128: would be good to have an official position, yeah :)
[12:05] <seb128> pitti, robru: come on, I'm even smiling on that one ;-)
[12:12] <GunnarHj> pitti: Can you please take a look at my response to your comment at https://code.launchpad.net/~gunnarhj/indicator-datetime/days-months/+merge/132643
[12:12] <GunnarHj> Want to make sure that I'm not missing anything.
[12:24] <pitti> GunnarHj: right, I understand the purpose of that patch
[12:25] <pitti> GunnarHj: I just don't have a strong opinion on whether or not we should go down that route, but it's fine for me
[12:29] <GunnarHj> pitti: Ok. Your talk about translations just made me wonder. Thanks.
[12:29] <pitti> GunnarHj: I mean the localized month/weekday names
[12:29] <GunnarHj> pitti: Yes, I realize that now.
[12:30] <pitti> e. g. with LANG=fr_FR.UTF-8 and LC_TIME=en_US.UTF-8, right now you should get "Tue", but with that patch "Mar"
[12:31] <pitti> because it would take the short/long week day names from the French locale, not the English one?
[12:33] <pitti> seb128: do you want https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-arm-input-sensor-drivers for raring? if so, could you milestone it, or would you mind if I do?
[12:33]  * pitti wants his WIs to appear on https://launchpad.net/~pitti/+upcomingwork
[12:33] <seb128> pitti, yes for raring, feel free to do it
[12:33] <seb128> pitti, danke ;-)
[12:34] <pitti> fini
[12:34] <pitti> (is that acceptable for "done"?)
[12:35] <chrisccoulson> oh, perfect. 18 days vacation actually does fit perfectly in to the whole of december :)
[12:35] <didrocks> seb128: if you are on paperwork mood, can you accetp
[12:35] <pitti> chrisccoulson: ffox better doesn't get major holes/bugs in December then :)
[12:35] <didrocks> accept* those blueprints milestoned for raring:
[12:35] <seb128> pitti, (it's acceptable ;-)
[12:35] <seb128> chrisccoulson, great
[12:36] <chrisccoulson> pitti, yeah, else i'll just end up working ;)
[12:36] <didrocks> https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-ps-processes
[12:36] <didrocks> https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-ps-uife-ffe-sru
[12:36] <pitti> but I find that splitting holidays into several smaller chunks is more relaxing, as it decreases the chances of having to work after all
[12:36] <seb128> didrocks, ok
[12:36] <didrocks> seb128: thanks!
[12:37] <seb128> yw ;-)
[12:37] <pitti> with didrocks' new TL credentials he should actually be able to target specs, etc
[12:37] <didrocks> pitti: I wasn't able yesterday, do you know on which team I should be?
[12:37] <seb128> pitti, well, you need a good chunk off work to really disconnect from work as well...
[12:37] <pitti> est-ce que c'est l'équipe "ubuntu-drivers" ?
[12:38] <didrocks> pitti: should I just bother cjwatson with it? :)
[12:38] <pitti> seb128, didrocks: hang on, let's sort out the perms properly
[12:38] <seb128> k
[12:38] <pitti> didrocks: try now
[12:38] <desrt> pitti: i decided to go ahead and just push the glib changes yesterday
[12:39] <desrt> so anyone with an old pygobject will be broken...
[12:39] <pitti> hey desrt, how are you
[12:39] <desrt> pitti: good
[12:39] <desrt> needing coffee :)
[12:39] <pitti> desrt: ah, I can't yet bump the glib dep in pygobject
[12:39] <didrocks> pitti: \o/ working :) thanks!
[12:39] <seb128> desrt, you could have waited for friday :p
[12:39] <pitti> desrt: as glib doesn't do post-release version bumps
[12:39] <pitti> desrt: I'm holding back the gpollfd patch until after the next glib release for that
[12:40] <desrt> pitti: we theoretically do post-release bumps
[12:40] <desrt> i just forget a lot :)
[12:40] <pitti> ah, heh
[12:40] <desrt> lemme do that n ow
[12:41] <desrt> okay
[12:44] <seb128> it would be nice if somebody would fix GNOME's #commits
[12:44] <desrt> ya... our #commits are terrible... always containing lots of #bugs and #regressions
[12:44]  * seb128 slaps desrt
[12:45] <desrt> oh.  sorry.  forgot the @seb128 ? :)
[12:46] <seb128> desrt, #itsnotfridayyet
[12:46] <seb128> srly! ;-)
[12:51] <pitti> desrt: cheers! actually, the benefit of that is that all the "interesting" api changes are already in, so bumping the dep in pygobject now will ensure that it's working :)
[12:53] <pitti> actually, I don't need 3.7.2; 3.4.2 would be sufficient as well, I backported all the annotation fixes I'm depending on
[12:54] <pitti> err, what am I talking about; I mean 2.35.2 vs. 2.34.2
[12:56] <pitti> so GNOME 3.6.2 is due next week, good; then the glib fixes will land
[13:01] <desrt> pitti: only if they are backported?
[13:03] <larsu> hm, indicator-appmenu assumes that xids are only ever used once.... there goes 2h of debugging in a totally wrong place :(
[13:04] <pitti> desrt: we'll just get 2.34.2 into exprerimental and raring?
[13:04] <pitti> desrt: oh, misunderstood you -- I already applied the annotation fixes to the glib-2-34 branch
[13:04] <desrt> interesting.
[13:04] <desrt> seb didn't say anything about taking the new stable glib
[13:04] <pitti> why wouldn't we get it into raring?
[13:04]  * desrt should push all of his crap there ;)
[13:06] <pitti> I thought we'd even track 2.35 in raring
[13:06] <desrt> not until january, i think
[13:06] <desrt> seb doesn't want to pull it in until i'm back from vacation
[13:07] <pitti> so, seems fine
[13:07] <pitti> I'm only relying on what's in glib-2-34 for current pygobject
[13:07] <desrt> cool
[13:07] <pitti> desrt: I'd love to land the gpollfd patch, if I can cherry-pick the boxing to glib-2-34?
[13:08] <pitti> it should be quite harmless; or are even API additions banned?
[13:08] <desrt> pitti: i'm a no-new-API-on-stable-branches kind of guy
[13:08] <pitti> ack
[13:08] <pitti> good, holding that back then until we get 2.35
[13:08] <desrt> pitti: maybe you could ask mclasen
[13:09] <desrt> he loves new API on stable branches ;)
[13:09] <pitti> lol
[13:09] <pitti> nah, I'm not going to second-guess you until I found the least strict maintainer
[13:09] <pitti> it's not really hurting, it's more a matter of pride and cleaning up
[13:10]  * desrt starts a new (daily?) ritual
[13:11] <desrt> digging through last night's 'jhbuild tinderbox' logs, filing bugs
[13:11] <GunnarHj> pitti: Re your comment at 13:30:31: Yes, exactly so.
[13:15] <pitti> Laney: ah, I had a lot of gvfs changes staged up in ubuntu:gvfs
[13:15]  * pitti fiddles with the branch to merge the last uploads
[13:15] <pitti> I guess using UDD is not working very well
[13:17] <larsu> desrt, morning :)  Any idea why indicator-appmenu doesn't destroy its internal data structures until 5 seconds after BAMF told it a window disappeared? The comment isn't really helpful: "Timeout to finally cleanup the window.  Causes is to ignore glitches that come from BAMF/WNCK."
[13:18] <larsu> that's really buggy, because it breaks menus that appear on the same xid less than 5 seconds after the old one disappeared
[13:19] <desrt> larsu: that's not possible
[13:19] <larsu> what isn't?
[13:19] <desrt> unless you mean that an xid was being reused
[13:19] <larsu> yes
[13:19] <larsu> that's exactly what happens
[13:20] <larsu> bug 1075263
[13:20] <ubot2`> Launchpad bug 1075263 in Application Menu Indicator "Items of a menubar built from GMenu do not always work" [High,Triaged] https://launchpad.net/bugs/1075263
[13:20] <desrt> this sounds like a bamf issue....
[13:20] <larsu> why? The question is the timeout
[13:20] <desrt> indicator-appmenu doesn't really care about xid at all
[13:21] <desrt> it treats the BamfWindow itself as the identifier
[13:21] <larsu> yes it does, it has a hash table of xid->window menus
[13:21] <desrt> if bamf is reusing BamfWindow structures on the basis of two windows happening to have the same xid....
[13:21] <desrt> ohhhh.
[13:21] <desrt> sorry.  was thinking hud.
[13:21] <rodrigo_> how do I downgrade a package in a PPA to the previous version it had in the PPA?
[13:21]  * desrt didn't write the appmenu code
[13:22] <larsu> desrt, nope. The bug is definitely caused by the timeout
[13:22] <larsu> desrt, you were the last one who touched it ;)  And tedg is not online yet ...
[13:22] <larsu> but nevermind, I'll ask ted when he comes on
[13:22] <larsu> just thought you might have an idea
[13:22] <desrt> larsu: my answer is that it should be keyed by BamfWindow (via qdata?) instead of xid
[13:22] <desrt> treating xid as an identifier is trouble
[13:23] <larsu> desrt, agreed, and that's what my fix will be. I'm just wondering about the timeout thing
[13:23] <desrt> i have no idea
[13:23] <desrt> better wait until ted's awake?
[13:23] <larsu> yup
[13:24] <desrt> i'm guessing it's because bamf sometimes issues spurious events and we want to ignore them?
[13:24] <desrt> but only based on what you said :)
[13:27] <desrt> pitti: were you planning to get systemd into the archive soon?
[13:28] <desrt> or is that something you completely lost interest in?
[13:28] <pitti> I'm not sure who will work on that
[13:28] <desrt> k
[13:28] <pitti> no, I'm interested in it; I want a current udev
[13:28]  * desrt wants to be able to build gnome-settings-daemon....
[13:28] <pitti> it requires a bit of coordination though, as Debian's systemd is way behind as well (due to the freeze, presumably)
[13:38]  * desrt wonders if perhaps he will need to start maintaining a PPA for dependencies of jhbuild....
[13:39] <seb128> desrt, good luck to whoever set up a ppa replacing user's init system ;-)
[13:40] <desrt> seb128: pitti did it back in the day.  i installed it and didn't even notice the difference.
[13:40] <desrt> init systems just aren't that important....
[13:40] <desrt> system services, on the other hand...
[13:40] <pitti> desrt: well, you would once you tried to upgrade a package with an upstart job (as that fails with that PPA)
[13:41] <desrt> pitti: ya... i was in a pretty stock desktop-only world
[13:41] <desrt> i don't even think i had sshd installed...
[13:41] <pitti> desrt: you'll have a lot of upstart jobs on a default desktop system, though; e. g. cups
[13:42] <desrt> as if i print :p
[13:43] <pitti> neither do I, but cups (or any package shipping an upstart job) fails to install/upgrade with systemd
[13:43] <pitti> we need a shim for what dh_installinit does to work with upstart
[13:44] <desrt> oh.  ow.
[13:44] <desrt> so looks like debian has a libsystemd-login-dev package...
[13:46] <desrt> and it works.  excellent!
[14:03] <Laney> pitti: doh, sorry
[14:03] <Laney> that matches my experience with trying to stage changes sadly
[14:03] <pitti> Laney: no problem
[14:04] <pitti> I merged my changes, now fixing the new failure with py3.3
[14:05] <Laney> I usually do check for desktop team branches though
[14:05] <pitti> gvfs has been the "UDD example" that we picked
[14:05] <pitti> because it was in sync with Debian for a while, and still very close
[14:05] <pitti> so our ~ubuntu-desktop branches got outdated very often after each sync
[14:06] <pitti> so again, no harm done, just pointing out that we should try UDD on gvfs
[14:07] <Laney> will try to remember
[14:09] <pitti> Laney: and if not, bzr merge is at least infinitely better than merge-o-matic :0
[14:34] <jbicha> seb128: I think we should drop the 02_title_update.patch from ibus, it was added for bug 596058
[14:34] <ubot2`> Launchpad bug 596058 in One Hundred Paper Cuts "Rename Menu item Ibus preferences to "Keyboard Input Methods"" [Low,Fix released] https://launchpad.net/bugs/596058
[14:35] <seb128> jbicha, hey, does it create any issue or is misleading?
[14:35] <jbicha> since we don't use menus like that any more & they didn't update the program's titlebar to match anyway
[14:37] <seb128> jbicha, what part of the patch? renaming the desktop entry from "IBus Preferences" to "Keyboard Input Methods" still make sense imho, users don't know what "IBus" is and shouldn't have to know
[14:39] <jbicha> I think for most purposes, the new Input Sources part of System Settings 3.6 is adequate for setting up ibus
[14:39] <seb128> jbicha, so you think we should hide the .desktop from the dash?
[14:39] <seb128> e.g use us NoDisplay=true?
[14:40] <seb128> what about non GNOME desktops?
[14:41] <jbicha> no, I'm not sure about hiding it at this point; my objections were that the patch was incomplete & the rationale for the patch was based on the obsolete menu system
[14:42] <seb128> jbicha, what part of the patch? I think the .desktop renaming makes sense, it gives a better title for the entry in gnome-shell/unity-dash/...
[14:42] <seb128> not sure about the code changes though
[14:43] <jbicha> the titlebar should match the .desktop
[14:43] <seb128> jbicha, what about fixing the titlebar instead? ;-)
[14:46] <jbicha> there isn't any packagekit integration yet that I can see so a user may very well need to know that the system is called ibus to install the input method they need
[14:58] <desrt> chrisccoulson: is our e-d-s thunderbird stuff upstream or ubuntu-specific?
[14:59] <desrt> chrisccoulson: e-d-s 3.7.1 breaks thunderbird
[15:02] <seb128> desrt, I'm so glad we decided to not update GNOME ;-)
[15:03] <chrisccoulson> desrt, yeah, that's just an addon we ship
[15:03] <desrt> seb128: unstable cycle is unstable, kthx :p
[15:03] <chrisccoulson> I LOVE EDS!
[15:03] <seb128> desrt, unwhat? I forgot what that means
[15:03]  * seb128 pets rolling stable cycle
[15:03] <desrt> sure :p
[15:04] <seb128> desrt, joke aside the "oh, updating e-d-s broke tb" is really something I would like to try avoiding over time ... not sure yet how we get there though
[15:05] <seb128> I guess the reply is "have a testcase upstream in GNOME that test clients and reject commits if they break them"
[15:05] <seb128> or something around that line
[15:05] <desrt> seb128: won't help us much when the breakage is in our custom addons
[15:06] <seb128> desrt, well, that's a "client"
[15:06] <seb128> don't provide an api if you don't want people to use it...
[15:06] <desrt> software interactions are more complicated than that....
[15:06] <pitti> *cough* kernel *cough*
[15:07] <desrt> the kernel is hilarious, imho
[15:07] <desrt> on one hand they harp on about 100% stable APIs forever
[15:07] <desrt> on the other hand, their module API is changing every release
[15:08] <desrt> stable APIs are sure easy when you have absolute separation between yourself and the thing that you are trying to be stable with respect to
[15:09] <seb128> well, GNOME has a tendency to go too far on the other side "incompatible changes are ok as long as we fix our known rdepends as the same time" ... those are still incompatible and they are people out there you don't know about and that you might break
[15:09] <seb128> well anyway
[15:09] <seb128> not something we will change today by a discussion on IRC
[15:09] <desrt> seb128: that behaviour is really a feature of the gnome3 days
[15:09] <seb128> so let's go back to work ;-)
[15:10] <desrt> and it's still early in the 3 major cycle :)
[15:10] <seb128> desrt, it's good for GNOME as a desktop, it's bad for GNOME as a platform
[15:10] <desrt> by the time we have 3.30 everyone will be complaining about about how nothing ever changes :p
[15:10] <desrt> *again
[15:10] <achiang> desrt: the kernel promise is that *internal* APIs are subject to change, but external APIs (sysfs, ioctl, etc.) are pretty much "forever" FSOV "forever"
[15:11] <seb128> desrt, by that time I guess "real world" will start using GTK3 for their apps :p
[15:11] <desrt> achiang: fsov -> fsvo?
[15:11] <achiang> oops, yeah, typo
[15:11] <desrt> seb128: i look forward to those days with a sense of fear :p
[15:11] <seb128> ;-)
[15:12]  * desrt enjoys pointless irc discussions while bisecting...
[15:16] <seb128> pitti, impressive gvfs upload
[15:17] <desrt> seb128: libsoup is going to have to be on the new-this-cycle list, btw
[15:17] <pitti> seb128: heh
[15:17] <Laney> can we keep that list on the pad?
[15:17] <seb128> desrt, that's a sloppy path ... next you will want e-d-s ... I start wondering if we should hold on old glib
[15:18] <seb128> hold->stay
[15:18] <desrt> seb128: you're kidding, right? :p
[15:18] <seb128> desrt, no
[15:18] <desrt> seb128: it's not the glib<->libsoup thing that's the issue
[15:18] <desrt> it's the libsoup<->gvfs thing
[15:18] <seb128> tell me more about it
[15:18] <desrt> the two masters don't currently build against each other
[15:18] <seb128> why?
[15:19] <desrt> since gvfs uses private libsoup API and libsoup just put its symbol export list under more formal control
[15:19] <desrt> https://bugzilla.gnome.org/show_bug.cgi?id=595176
[15:19] <ubot2`> Gnome bug 595176 in Misc "Private symbols are exported in the shared libraries" [Normal,Resolved: fixed]
[15:20] <pitti> bonsoir tout le monde!
[15:20] <desrt> pitti: ciao
[15:20] <seb128> pitti, bonsoir
[15:20] <desrt> seb128: it's theoretically possible that the gvfs changes can be made without using new libsoup API...
[15:20] <desrt> and in fact, as it is, keeping old libsoup actually avoids the problem entirely
[15:20] <seb128> desrt, thanks for the warning
[15:20] <desrt> but the fix may change that...
[15:21] <seb128> I will keep it on my "to watch" list
[15:24] <desrt> seb128: btw: the reason i am noticing all this crap is because i'm running a pretty complete jhbuild desktop under the new glib
[15:24]  * larsu hopes never to get on the "to watch" list of seb128
[15:24] <desrt> no major issues related to all the glib breaking
[15:24] <seb128> larsu, ;-)
[15:25] <desrt> seb128: another to-watch for you is this trivial issue: https://bugzilla.gnome.org/show_bug.cgi?id=687763
[15:25] <ubot2`> Gnome bug 687763 in gobject "libxul apps (Firefox, thunderbird) regressed by automatic g_type_init() ctor" [Normal,Unconfirmed]
[15:26] <desrt> could be fixed by a well-placed "//" in libxul :)
[15:27] <seb128> desrt, I'm sure chrisccoulson will like that ;-)
[15:30] <chrisccoulson> normally when i see "chrisccoulson will like that", i take that as my cue to run ;)
[15:31] <BigWhale> I just noticed that software updater has only "restart" button. I hope someone already repoted this bug... I have to xkill it :/
[15:32] <larsu> BigWhale, right click on launcher->quit. Not having a close button is a design decision...
[15:32] <larsu> (to keep a reminder open that you should restart)
[15:32] <mpt> BigWhale, it's a not a firm decision, but I'm not sure what a "Don't Restart Now" button would do exactly
[15:32] <mpt> (Would it remind you in 1 hour? etc)
[15:33] <BigWhale> Never remind again, remind later, restart would be the best
[15:33]  * larsu votes for red session menu icon
[15:33] <desrt> larsu: voting for red?  better hide from kenvandine ;)
[15:34] <larsu> not in NC, obviously ;)
[15:35] <larsu> that's all he cares about !
[15:37] <mpt> chrisccoulson, hi. Is bug 705893 what causes all Firefox and Thunderbird menus to open initially as tiny stubs, and then inflate?
[15:37] <ubot2`> Launchpad bug 705893 in Global menubar extension "Should delay menu opening whilst processing menu updates" [Low,Triaged] https://launchpad.net/bugs/705893
[15:42] <chrisccoulson> mpt, ja
[15:51] <mpt> chrisccoulson, thanks. Unrelated question: Would you have any objection to making <https://launchpad.net/globalmenu-extension> part of the <https://launchpad.net/ubuntu-menu-bar> project group? It would help the Systems team find menu-related bugs that happen to manifest only in Firefox/Thunderbird.
[15:54] <chrisccoulson> mpt, i guess that should be ok, although i can't click on the link at the moment (debugging browser in gdb) :)
[15:55] <chrisccoulson> i suppose i could just view it in epiphany though ;)
[15:56] <chrisccoulson> mpt, yeah, that looks ok
[15:56] <seb128> chrisccoulson, view it in "web" you mean? :p
[15:56] <chrisccoulson> hah!
[16:13] <dupondje> could someone take a look @ https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1073649 please? Have no idea where to start debugging :)
[16:13] <ubot2`> Launchpad bug 1073649 in lightdm (Ubuntu) "lightdm visible on tty1, and console visible in lightdm" [Undecided,New]
[16:19] <seb128> dupondje, what video driver do you use?
[16:19] <dupondje> seb128: nouveau
[16:20] <dupondje> its always resolved after restarting lightdm, so it looks like a race condition somewhere ?
[16:22] <seb128> dupondje, I know about https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/873495 but I guess it's not the same issue if you use nouveau
[16:22] <ubot2`> Launchpad bug 873495 in lightdm (Ubuntu Precise) "LightDM fails to start after nvidia-current or nvidia-current-updates are installed (upstart job issue)" [High,Triaged]
[16:27] <seb128> hum, firefox wooopsed
[16:33] <dupondje> seb128: lightdm starts always :) but some issues :p
[16:34] <robru> pitti, I'm trying to write a test case that tests that some libsoup code I have is generating a correct multipart/form-data message for upload. libsoup is generating a random value to use as the form data separator. Are you aware of a way that I could mock that out to return the same value each time for easier testing?
[16:48] <mpt> chrisccoulson, finished debugging? :-)
[17:51] <didrocks> yummi regexp for the end of day: "((lp:?|bug)[ #]*|#|https://launchpad.net/bugs/)(\d{5,})" ;)
[17:52] <seb128> didrocks, you can do better I'm sure!
[17:52] <mlankhorst> bug didrocks!
[17:53] <didrocks> seb128: yeah, I've done worse, but it's almost 7PM :p
[17:54] <didrocks> it matches http://paste.ubuntu.com/1337882/, see how kind I'm with our committers ;)
[17:56] <seb128> didrocks, the launchpad guys are not so nice for .changes entries ;-)
[17:56] <seb128> didrocks, you are giving your committers bad habits, they will get bitten when trying to do uploads ;-)
[17:57] <didrocks> seb128: heh, well, it's not that much additional work and I know real world, you know… where everyone is not like us! :-)
[17:58] <seb128> ;-)
[17:58] <didrocks> that enables to catch --fixes lp: and others commit message without bug associated :)
[18:19] <qengho> kenvandine: uh oh, a new version of chromium-browser stable, 23.somethingorother.
[18:20]  * qengho hurries more.
[18:27] <kenvandine> qengho, uh oh :)
[18:32] <seb128> qengho, what, it's out and not the in archive yet? build faster! :p
[18:36] <kenvandine> seb128, i bet it'll break webapps integration
[18:36] <kenvandine> it'll need a little work
[18:37] <kenvandine> but qengho knows who to yell at about fixing that
[18:37] <kenvandine> :)
[18:37] <seb128> kenvandine, well, breaking webapps integration, firefox did that today so let's play it fair and do the same to chrome :p
[18:38] <kenvandine> hehe
[19:32] <dobey> desrt: any idea why dconf-service would be using 237 MB RES?
[19:33] <desrt> dobey: there's a leak
[19:33] <desrt> dobey: fixed upstream, waiting for seb128 to SRU it
[19:33] <dobey> ah ok
[19:44] <attente> desrt: i'm getting a strange stack trace
[19:49] <desrt> oh?
[19:52] <attente> http://fpaste.org/kYUP/
[19:52] <attente> frame #4 and #5 being relevant
[19:53] <attente> is this a possible thing to happen?
[20:06] <attente> it's calling this implementation, g_menu_attribute_hash_iter_get_next
[20:07] <attente> still not sure why g_quark_from_string is getting called though
[20:12] <desrt> attente: could be a tailcall?
[20:14] <attente> desrt: not really sure
[20:17] <desrt> if you are saying that the function in question does not call the funciton that it appears to be calling then probably it's a tailcall occuring in a 3rd function that you have to guess about
[20:17] <desrt> look at the listed line number and check what's there
[20:21] <attente> oh... i was looking at the wrong line number...
[20:24] <desrt> :)