[02:38] <mfisch> seb128: I looked at the merge for gnome-system-monitor with debian, there's nothing worth merging yet, they took some control file changes from us, that's all really
[05:33] <pitti> Good morning
[05:43] <didrocks> hey pitti
[05:44] <pitti> bonjour didrocks
[06:18] <jibel> good morning
[06:25] <didrocks> salut jibel!
[06:26] <jibel> salut didrocks
[06:51] <didrocks> robru: you will still need to get it deployed ;)
[06:51] <didrocks> robru: so please get kenvandine to do that ;)
[07:28] <seb128> good morning desktopers
[07:31] <pitti> bonjour seb128
[07:32] <seb128> pitti, salut, très bien, c'est vendredi !
[07:32] <seb128> pitti, et toi ?
[07:32] <pitti> seb128: je vais bien aussi. j'attends avec impatience le long week-end
[07:33] <seb128> oui, moi aussi, par contre il pleut encore aujourd'hui :-(
[07:42] <robru> didrocks, yeah, I'll talk to ken tomorrow ;-)
[07:42] <didrocks> robru: you mean today, right? ;)
[07:42] <didrocks> salut seb128!
[07:42] <seb128> didrocks, lut
[07:42] <robru> didrocks, nah... if I have to sleep before then, it still counts as "tomorrow" ;-)
[07:43] <didrocks> robru: tssss, my time clock doesn't agree, we'll still be the same day! :-)
[07:43] <didrocks> people on the wrong side of the world… :p
[08:00] <mitya57> km
[08:00] <mitya57> oops, wrong channel
[08:06] <seb128> mitya57, if that was your password, you need a stronger one :p
[08:07] <mitya57> seb128: it was wrong usage of Android keyboard actually :)
[08:09] <Laney> morning
[08:09] <seb128> Laney, hey, happy friday!
[08:09] <Laney> yay, happy friday to you too!
[08:47] <chrisccoulson> hoppy friday!
[08:48] <seb128> chrisccoulson, hey, happy rainy friday to you!
[08:49] <Laney> ooh hops
[09:10] <chrisccoulson> did cyphermox ever make progress with the nm-applet bug, where the menu stops responding to anything or updating?
[09:10] <chrisccoulson> it's annoying, it happens to me several times per day atm ;)
[09:40] <seb128> chrisccoulson, https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/780602/comments/103
[09:40] <ubot2> Ubuntu bug 780602 in network-manager-applet (Ubuntu Quantal) "nm-applet leaks memory" [High,Fix released]
[09:40] <chrisccoulson> seb128, want some help? :)
[09:41] <seb128> chrisccoulson, you should ask cyphermox but it seems like help would be welcome yes ;-)
[09:41] <chrisccoulson> this issue is seriously annoying now. every time i dock or undock and want to change network configuration, i have to restart nm-applet ;)
[09:42] <seb128> ah, that works?
[09:42] <seb128> I got the bug during the sprint, I fallbacked to use the control center panel to pick my wifi aps :p
[09:42] <chrisccoulson> seb128, yeah, restarting nm-applet works
[09:43] <chrisccoulson> but i have to do that every morning and every evening
[09:45] <seb128> nice
[09:45] <Laney> hasn't annoyed me so much because nm automatically does what i want it to
[09:45] <seb128> well "nice", but good to have somebody able to reproduce the issue
[09:45] <seb128> I run into that but like once every 3 months
[09:45] <Laney> but i'm hitting it atm indeed
[11:16] <Laney> seb128: want to check gsd out of bzr and see if it fixes the permissions for you?
[11:17] <seb128> Laney, sure
[11:18] <Laney> seems to work here
[11:23] <seb128> Laney, worked here with my test user and the patch seems fine to me, +1 for upload ;-)
[11:24] <Laney> rocking
[11:25] <Laney> doing that
[11:43] <dpm> hi pitti, we're testing translations for the clock app on a device with  Ubuntu Touch. We changed /etc/default/locale to fr_FR.UTF-8, but that didn't seem to make any change. Calling the app with LANGUAGE=fr did. What's the best place to define the system language? And the user language?
[11:45] <seb128> dpm, language-selector writes the locale config to ~/.pam_environment
[11:46] <pitti> dpm: I guess you either didn't restart your session or have the lang defined in ... what seb128 said?
[11:46] <seb128> dpm, check /etc/environment as well
[11:46] <pitti> dpm: if you never heard of .pam_environment you can safely delete that file, then it'll fall back to the system-wide default
[11:48] <dpm> great, thanks seb128. pitti I think that must have been it, thanks! /etc/environment on my desktop seems to contain only PATH
[11:48] <pitti> as it should
[11:48] <seb128> dpm, that seems about right, I was pointing it in case, it has been used in the path to store LANG and stuff iirc
[11:48] <dpm> ok, cool
[11:48] <seb128> not sure if some configs have leftovers there
[11:49] <dpm> I think we'll just have to write to /etc/default/locale and restart the session
[11:49] <seb128> "we"?
[11:49] <pitti> dpm: if you just want this for testing, you can also export LANG=fr_FR.UTF-8 (or whatever), and start the app from that terminal
[11:49] <dpm> seb128, I'm testing this with oSoMon on a device. "we" it's actually him, as I don't have a device atm :)
[11:50] <seb128> dpm, ok, I was unsure if you wanted to make a touch app change system defaults or something, that would be wrong
[11:51] <dpm> seb128, no, that's for a demo of Ubuntu Touch in Simplified Chinese. We've only got localizations for a few core apps, and would like to set either the user's or system locale to zh_CN.UTF-8 to load those
[11:51] <seb128> dpm, seems good to me, good luck with that ;-)
[11:51] <dpm> thanks, it's looking good apart from figuring out where to set the locale, apparently :)
[11:52] <dpm> pitti, yeah, that's what he did when he called the app with LANGUAGE. We're trying to set the language not per-app, but rather per-user or system-wide, whatever is easier/makes more sense
[11:53] <pitti> dpm: both make sense in different scenarios; on a (essential) single-user system like phone you probably want /etc/default/locale, though
[11:54] <dpm> pitti, ok, we'll do that for the demo, then
[11:54] <pitti> dpm: note that all that can be done through accountsservice, which hides the actual files to be touched and their format, and on phones we can also allow (via policykit) that normal users can change /etc/default/locale
[11:54] <pitti> (not sure whether we have accountsservice on the phone)
[11:55] <seb128> not sure if it's there yet, but it's planned and we will use it in system settings
[11:56] <dpm> pitti, yeah, that'd be for when we've got everything there and we want to make things properly. But for the demo purposes, we can just write to /etc/default/locale? Or is there any part of that infrastructure we can use already?
[11:56] <pitti> dpm: sure
[11:56] <pitti> dpm: not really; language-selector does, but that needs accountsservice
[11:56] <pitti> you can certainly install that, of course
[11:57] <pitti> dpm: but I think for a demo, easiest thing is /e/d/locale, or ~/.pam_environment
[11:57] <seb128> language-selector will not run on the phone
[11:57] <seb128> easier to just hack the locale file manually imgo
[11:57] <seb128> imho
[11:58] <dpm> actually, once the locale file is changed, is there a way to restart the session on the phone, so that it picks up the new locale?
[12:00] <seb128> ogra_, ^
[12:00] <seb128> dpm, sudo reboot in adb or ssh? ;-)
[12:00] <dpm> ok, cool
[12:02]  * ogra_ looks up
[12:03] <seb128> ogra_, just the 1 line before, do you know how to reboot/restart the session on the touch image?
[12:03] <seb128> ogra_, is there a better way that "reboot" in adb/ssh?
[12:03] <ogra_> i dont think so ...
[12:04] <ogra_> you can try to kill ubuntu-session, it theoretically should respawn but i dont think that was ever tested
[12:05] <ogra_> (there is an upstart job that respawns it but i'm not sure teh script itself  actually exits properly)
[12:05] <seb128> ok
[12:06] <seb128> ogra_, that was in case you knew a better trick ;-)
[12:06] <ogra_> well, try it :)
[12:07]  * ogra_ currently works on the flipped container model ... i dont have a gui running to try myself
[12:07] <seb128> will do in a bit, thanks
[13:14] <jbicha> seb128: did you see that bug 1177995 is still unfixed?
[13:14] <ubot2> Launchpad bug 1177995 in Fontconfig "libfontconfig from Gnome3 staging PPA breaks CSS webfonts in firefox" [Medium,In progress] https://launchpad.net/bugs/1177995
[13:23] <chrisccoulson> jbicha, is that actually in the archive?
[13:24] <chrisccoulson> ah, it is
[13:24] <chrisccoulson> i bet that explains all of these test failures then:
[13:25] <chrisccoulson> https://jenkins.qa.ubuntu.com/job/saucy-adt-firefox/ARCH=amd64,label=adt/lastCompletedBuild/testReport/
[13:25] <chrisccoulson> seb128 ;)
[13:25] <chrisccoulson> they all look font related
[13:28] <chrisccoulson> ooh, more font reftest failures: https://jenkins.qa.ubuntu.com/job/saucy-adt-firefox/ARCH=i386,label=adt/23/#showFailuresLink ;)
[13:29] <chrisccoulson> it's a good job i run this!
[13:38] <cyphermox> chrisccoulson: by all means. I just don't have time to get back to it
[13:38] <cyphermox> chrisccoulson: I did write a small reproducer before... it's an issue in libdbusmenu somewhere
[13:43] <chrisccoulson> cyphermox, yeah, i've ran that for a couple of hours now, and it hasn't triggered it yet
[13:45] <cyphermox> chrisccoulson: it depends of the values for delay and stuff
[13:45] <cyphermox> you got the script from a bzr branch?
[13:47] <chrisccoulson> cyphermox, yeah, the one on the bug
[13:56] <cyphermox> ok
[14:22] <seb128> jbicha, yeah, saw that, I will have a look in a bit
[14:22] <seb128> chrisccoulson, would be even better if we had the result of those tests before landing a new version of the lib...
[14:22] <chrisccoulson> seb128, yeah. i wonder how we could do that?
[14:23] <chrisccoulson> i guess, the answer is to have that block the migration from proposed somehow
[14:23] <Laney> that's the plan
[14:24] <chrisccoulson> but i don't know how the test could distinguish between it being a regression in firefox, or a regression in the platform
[14:24] <chrisccoulson> seeing as this is a new firefox version too ;)
[14:24] <chrisccoulson> (the tests all pass in the raring build)
[14:24] <seb128> well, you would assume that the version in the archive has successful tests
[14:24] <chrisccoulson> seb128, yeah, in this case, firefox is still sat in proposed too :)
[14:24] <seb128> so we should be running the tests from the archive version with the new e.g glib
[14:24] <Laney> you mean both would be in proposed at the same time?
[14:24] <seb128> and flag red when they start failing
[14:25] <Laney> so if you can't tell which regressed I suppose you have to block both until it's fixed
[14:25] <chrisccoulson> yeah, testing the version of firefox in the release pocket with the libraries in proposed would probably be better in this case
[14:26] <Laney> hmm
[14:26] <Laney> you might end up testing something different to what you migrate then
[15:14] <dpm> pitti, seb128, so oSoMoN and I (well actually he) have been playing with setting the locale in touch images, but it seems /etc/default/locale and setting LANG on the shell does not seem to work. Strangely enough, setting LANGUAGE on the shell works. On the other hand, running the app on the desktop does honor LANG. Any idea what could be missing on the localization stack on Touch images?
[15:15] <oSoMoN> dpm: I know what’s going on: LANG is correctly set to zh_CN.UTF-8, but there’s also LANGUAGE that’s set to en_US:en, and it apparently takes precedence over LANG
[15:15] <dpm> aha!
[15:15] <oSoMoN> dpm: if I simply run "LANGUAGE= ubuntu-clock-app", I get the localization correct
[15:16] <oSoMoN> so we need to figure out what sets LANGUAGE, and override it
[15:16] <seb128> oSoMoN, sudo grep LANGUAGE /etc -r
[15:16] <oSoMoN> /etc/environment:LANGUAGE=en_US:en
[15:16] <cyphermox> chrisccoulson: poke
[15:16] <cyphermox> chrisccoulson: http://paste.ubuntu.com/5674309/
[15:17] <cyphermox> reproduced with these changes
[15:17] <dpm> oSoMoN, well spotted, I wonder what's setting it though
[15:17] <cyphermox> let me know if it works for you... might take an hour or so to reach the 10k updates or what that are needed
[15:21] <seb128> dpm, I told you earlier to check /etc/environment :p
[15:21] <oSoMoN> dpm: setting LANG and LANGUAGE in /etc/default/locale fixes the issue partially: when launched from a terminal, the app now shows up in Chinese, however when started from the UI, it still shows up in plain English
[15:21] <dpm> seb128, I did it... but on my desktop ;)
[15:22] <seb128> oSoMoN, restart the shell, it's still with the LANGUAGE env
[15:22] <seb128> I guess
[15:22] <oSoMoN> seb128: I rebooted already, no luck
[15:22] <seb128> and the child inherit the env
[15:22] <seb128> :-(
[15:23] <seb128> oSoMoN, cat you "string /proc/$(pidof SHELLNAME) | grep LANG" ?
[15:23] <seb128> ups
[15:23] <seb128> oSoMoN, cat you "string /proc/$(pidof SHELLNAME)/environ | grep LANG" ?
[15:23] <seb128> where SHELLNAME is the name if your launcher/shell process
[15:23] <seb128> like that would be "compiz" on the normal ubuntu desktop
[15:24] <oSoMoN> mmm, I’ll need to ssh into the device, /proc is not mounted properly when using adb, give me a moment
[15:31] <oSoMoN> seb128: I’m getting "string: command not found", but if I cat the contents of /proc/$(pidof qml-phone-shell)/environ, I can see that LANGUAGE=en_US:en and LANG=en_US.UTF-8
[15:31] <oSoMoN> which explains why apps start in English
[15:31] <seb128> oSoMoN, sorry it's "strings" with a "s"
[15:32] <seb128> oSoMoN, do you have LANGUAGE back in /etc/environment?
[15:32] <oSoMoN> seb128: strings not found either, but nm
[15:32] <seb128> yeah, don't worry about that ;-)
[15:32] <oSoMoN> seb128: yes, in /etc/environment there’s LANG=en_US.UTF-8 and LANGUAGE=en_US:en
[15:34] <seb128> ogra_, ^ do you know what set /etc/environment LANGUAGE on boot of ubuntu touch?
[15:42] <ogra_> seb128, live-build iirc
[15:43] <seb128> ogra_, that doesn't happen in Ubuntu ... is that specific to touch? why is it doing that (that's buggy)
[15:43] <ogra_> seb128, look at the livecd-rootfs source in the live-build/ubuntu-touch subdir
[15:43] <seb128> thanks
[15:43] <ogra_> seb128, because we have taken the setup from the oem build system unmodified
[15:43] <ogra_> and because there is no installer which would usually set it
[15:44] <seb128> oSoMoN, I guess you should override LANGUAGE in ~/.pam_environment
[15:44] <seb128> oSoMoN, just create that file with LANGUAGE=<whatever you need>
[15:45] <seb128> ogra_, is that run at every boot?
[15:45] <seb128> hooks/48-setup-env.chroot:LANGUAGE=en_US:en
[15:45] <ogra_> no, at build time
[15:45] <seb128> hum
[15:45] <seb128> weird
[15:45] <ogra_> yeah
[15:45] <ogra_> oem build system ...
[15:45] <ogra_> :)
[15:45] <seb128> oSoMoN apparently had it coming back after a reboot
[15:46] <seb128> oSoMoN, did you edit /etc/environment to drop that line before?
[15:48] <oSoMoN> seb128: no, I simply overrode it in /etc/default/locale
[15:48] <oSoMoN> seb128: let me try adding it to ~/.pam_environment
[15:49] <seb128> oSoMoN, oh, just edit /etc/environment
[15:49] <seb128> I though you did that before when you spotted the LANGUAGE in it
[15:51] <oSoMoN> yay, parts of the shell and clock app in Chinese after reboot :)
[15:59] <oSoMoN> fun, I’m getting the time and the date localized in Chinese on the lock screen, that’s what I call a customized home screen :)
[16:09] <dpm> oSoMoN, cool. So I've been reading the scrollback, but I'm not sure what finally fixed it. What did you exactly have to do?
[16:10] <seb128> dpm, drop LANGUAGE from /etc/environment
[16:10] <oSoMoN> dpm: I modified the values of LANG and LANGUAGE in /etc/environment and in /etc/default/locale (not sure the latter is really necessary though)
[16:11] <seb128> oSoMoN, you should just have dropped the lines in /etc/environment
[16:11] <seb128> but both work
[16:12] <dpm> oSoMoN, if it's not too much, could you try removing them both from /etc/environment and leave only the one in /etc/default/locale as Seb is mentioning, to see if that works as it's supposed to?
[16:12] <oSoMoN> dpm: sure
[16:12] <dpm> cool, thanks
[16:13] <dpm> seb128, ogra_, what would the best place be to report a bug for /etc/environment not to set the language in the touch images and use only /etc/default/locale (if that's the way it's supposed to be)?
[16:13] <seb128> dpm, <ogra_> seb128, look at the livecd-rootfs source in the live-build/ubuntu-touch subdir
[16:14] <seb128> dpm, so livecd-rootfs ubuntu package
[16:14] <seb128> dpm,  hooks/48-setup-env.chroot:LANGUAGE=en_US:en
[16:14] <dpm> cool, thanks seb128!
[16:14] <seb128> it has that
[16:14] <seb128> we should probably just drop the line
[16:14] <oSoMoN> dpm: I removed both LANG and LANGUAGE from /etc/environment, and kept only LANG in /etc/default/locale, rebooted, but the app is not localized anymore :/
[16:14] <ogra_> as long as it doesnt break anything
[16:15] <ogra_> thats what i was expecting :)
[16:15] <ogra_> we dont use a proper installer and dont have any tool that mimics one yet
[16:15] <seb128> oSoMoN, can you look to /proc/$(pidof qml-phone-shell)/environ again for the LANG LC_* values?
[16:15] <seb128> ogra_, you just force everyone to english
[16:16] <ogra_> no, i dont
[16:16] <seb128> ogra_, if that was =fr:FR I could understand
[16:16] <seb128> but english...
[16:16] <ogra_> whoever implemented that did :)
[16:17] <oSoMoN> seb128: no LANG nor LANGUAGE in there
[16:18] <seb128> oSoMoN, LC_ALL or LC_MESSAGES?
[16:18] <oSoMoN> nor LC_*
[16:19] <ogra_> seb128, the prob i have with changing it is that we are not allowed to introduce any regressions by pmcgowan request ... so ripping it our means we need proper replacement first
[16:19] <ogra_> s/our/out
[16:20] <seb128> oSoMoN, ok, that would need debugging, I will have a look to it next week, add those back to /etc/environment I guess
[16:20] <seb128> oSoMoN, thanks for the testing
[16:20] <seb128> dpm, ^
[16:20] <ogra_> (which i would see being oem-config, but we are apparently not using that so we have to wait for a replacement written from scratch)
[16:20] <dpm> thanks seb128, oSoMoN and ogra_
[16:20] <oSoMoN> np
[16:21] <seb128> ogra_, that's ok, no hurry to "fix" it, the discussed started because oSoMoN et dpm are trying to run a chinese image for demo purpose
[16:21] <dpm> indeed
[16:21] <ogra_> ah
[16:21] <seb128> ogra_, and that forced english config confused them
[16:21] <ogra_> yeah, understood
[16:21] <ogra_> not only them :)
[16:21] <dpm> :)
[16:21] <seb128> discussed->discussion
[16:21] <ogra_> its messy all over the place
[16:22] <ogra_> but fixing it means inventing new wheels :)
[16:26] <didrocks> robru: I guess you'll see that the webapps is in manual publishing mode due to packaging changes (and QA stack being non working)
[16:26] <didrocks> robru: so once you've done the review and tell it's ok, check with kenvandine I guess to publish it :)
[16:28] <didrocks> cyphermox: same for oif, manual publishing
[16:28] <didrocks> mind checking it?
[16:28] <cyphermox> yeah
[16:29] <didrocks> thanks
[16:33] <cyphermox> didrocks: fun, all non-packaging changes
[16:34] <didrocks> cyphermox: look at the publisher.xml
[16:34] <didrocks> cyphermox: the qa stack failed
[16:34] <didrocks> cyphermox: also logs in the console :)
[16:34] <cyphermox> yeah, I know about that part
[16:35] <cyphermox> I mean, oif itself is probably all good
[16:35] <didrocks> cyphermox: yeah, if tests pass and "only" the QA stack failed, there is low chance to have bad test results :)
[16:36] <didrocks> cyphermox: so I would go for publishing personnaly
[16:36] <cyphermox> yeah that's what I meant
[16:36] <cyphermox> I was just commenting that there were no packaging changes, it just didn't publish because the qa stack is still broken
[16:37] <cyphermox> there's a distinct lack of extensive testing for oif though
[16:37] <didrocks> cyphermox: yeah, I think it's good to publish anyway
[16:37] <didrocks> cyphermox: at least, we know that unity is still starting :)
[16:37] <cyphermox> yep
[16:37] <didrocks> that's something!
[16:39] <cyphermox> didrocks: oif publishing
[16:39] <didrocks> thanks!
[16:49] <seb128> kenvandine, hey, where can I find libhud2?
[16:50] <seb128> kenvandine, I was trying to install your samegame game earlier but ran into libhud issue...
[16:58] <kenvandine> seb128, where did you install it from?
[16:58] <kenvandine> the collections PPA?
[16:58] <seb128> kenvandine, yes, well I wget debs and tried to dpkg -i ... maybe I just overlooked on, but I didn't see libhud2 in there
[16:59] <kenvandine> libhud2 is in the daily-build-next as well
[16:59] <seb128> ah
[16:59] <kenvandine> it had been copied to the collections ppa
[16:59] <kenvandine> but i think libhud2 might be a new binary
[16:59] <kenvandine> maybe we need to copy that again
[16:59] <kenvandine> cyphermox, is that new?
[17:00] <kenvandine> yes.. indeed it is new
[17:00] <kenvandine> mhall119_, mind if i copy the new libhud to the collections ppa?
[17:01] <Laney> have a good weekend everyone!
[17:01] <seb128> Laney, thanks, you too!
[17:01] <seb128> Laney, monday is an holiday in .fr, just for info
[17:02] <seb128> not sure if that's on in u.k
[17:02] <Laney> no, the week after for us
[17:02] <seb128> ok
[17:02] <Laney> it'll be an even better weekend for you then :p
[17:02] <seb128> yep ;-)
[17:02] <seb128> and apparently we will even get some sun on saturday and monday
[17:03] <seb128> (not sunday though)
[17:03] <Laney> not so much here http://www.bbc.co.uk/weather/2641170
[17:04] <seb128> :-(
[17:24]  * didrocks waves good evening
[17:25] <didrocks> (and good week-end)
[17:25] <didrocks> see you on *Tuesday* :-)
[17:45] <cyphermox> kenvandine: indeed, libhud2 is new
[18:21] <mhall119_> kenvandine: collections or coreapps/
[18:21] <mhall119_> ?
[18:22] <mhall119_> kenvandine: it almost seems more like something that should go into the SDK team PPA
[18:22] <kenvandine> mhall119_, collection
[18:22] <kenvandine> mhall119_, it is already in the touch images
[18:22] <kenvandine> but people on desktops that want to install it
[18:23] <kenvandine> is it in coreapps ppa?
[18:23] <kenvandine> i know it's in collections
[18:23] <mhall119_> why wouldn't the SDK Team PPA still be the right place?
[18:23] <kenvandine> so we can expect everyone that wants to use the collections ppa on a desktop have the sdk ppa enabled?
[18:24] <mhall119_> that's how they get the ubuntu-ui-toolkit packages, so yeah
[18:24] <kenvandine> doesn't matter to me... i just know the old version was copied into the collections ppa
[18:24] <kenvandine> not necessarily...
[18:24] <kenvandine> they could get that from raring
[18:25] <mhall119_> we're recommending raring users keep using the PPA, since it has newer versions of the SDK that we want them to use
[18:25] <kenvandine> makes sense
[18:26] <kenvandine> we should delete the old one then from the collections ppa
[18:26] <mhall119_> agreed
[18:26] <mhall119_> I need to get christian to move the u1db-qt package into the sdk team's ppa too
[19:39] <sil2100> Dammit!
[20:04] <cyphermox> ugh, unity ci is slooooow
[20:18] <chrisccoulson> cyphermox, figured it out ;)
[20:18] <chrisccoulson> http://bazaar.launchpad.net/~dbusmenu-team/libdbusmenu/trunk.13.10/view/head:/libdbusmenu-glib/menuitem.c#L270
[20:19] <chrisccoulson> it clamps the maximum id to 30000!
[20:19] <chrisccoulson> so this fails when creating items in the panel with higher id's: http://bazaar.launchpad.net/~dbusmenu-team/libdbusmenu/trunk.13.10/view/head:/libdbusmenu-glib/client-menuitem.c#L96
[20:40] <cyphermox> chrisccoulson: I did notice nm-applet itself was usually failing at 30000
[20:40] <cyphermox> chrisccoulson: but with the script I'd get crashes before that
[20:40] <cyphermox> well
[20:40] <cyphermox> *around* 30000; I couldn't make sure it was really exactly that
[20:40] <cyphermox> but this is indeed a very nice find :)
[21:16] <bjsnider> so lucid and oneiric both reached eol on may 9 right?
[21:18] <sarnold> bjsnider: no; lucid _desktop_ eol'd on may 9, but server and associated packages are still supported
[21:18] <sarnold> "It's Complicated": https://wiki.ubuntu.com/LucidLynx/ReleaseManifest
[21:19] <bjsnider> sarnold, right, but if i'm publishing ppa stuff for the desktop i can justifiably quit doing so for lucid and oneiric now
[21:19] <sarnold> bjsnider: right. up to you if you care about lucid.. :)
[21:24] <chrisccoulson> man, it's past beer o'clock and i'm still not finished
[21:24] <sarnold> :(
[21:32] <chrisccoulson> cyphermox, https://code.launchpad.net/~chrisccoulson/libdbusmenu/lp1011073/+merge/164545
[21:39] <cyphermox> yeah!
[21:40] <cyphermox> chrisccoulson: wouldn't it be better to have the ID a uint though?
[21:40] <chrisccoulson> cyphermox, it would. but it's exposed via a public API
[21:41] <cyphermox> ah, right
[21:46] <chrisccoulson> right, BEER TIME!
[21:59] <bkerensa> jasoncwarner: https://wiki.mozilla.org/Apps/WebRT
[22:33] <sil2100> cyphermox: ping, are you still there?
[22:34] <sil2100> Ok, screw it, I finish this up tomorrow, too late today anyway for anything...
[22:34] <sil2100> See you later guys