[01:52] <happyaron> JackYu: ping
[01:54] <JackYu> hapyyaron, pong
[06:58] <didrocks> hey robru, still around to update me on the Unity8/Upstart app launch things?
[06:59] <robru> didrocks, haha. so mirv filed a bug about upstart, and unity8 never landed due to merge conflicts in trunk.
[07:00] <robru> didrocks, also i had a power outage here and it resulted in corruption on my boot drive, so I've spent most of the day reinstalling and recovering my system :-/
[07:01] <didrocks> robru: argh, I hope you can recover :/
[07:01] <didrocks> robru: what's this merge conflicts in trunk? This is for the branch we are waiting on landing?
[07:01] <robru> didrocks, almost there...
[07:02] <didrocks> robru: also, having a link to this branch we wait on for releasing would be appreciated ;)
[07:02] <robru> didrocks, yeah, sil told me the MP that we should watch, and I saw it get approved, and then jenkins failed to merge it due to flaky tests, so I went for a manual merge and there were conflicts, it wouldn't merge after that. I told them on the MP to rebase on trunk
[07:02] <didrocks> making sense
[07:02] <robru> didrocks, https://code.launchpad.net/~aacid/unity8/broken_collapse/+merge/197844
[07:03] <didrocks> robru: excellent thanks!
[07:03] <didrocks> robru: btw, do not add any other landing please until we promote an image
[07:03] <didrocks> especially risky ones like ubuntu-ui-toolkit
[07:03] <robru> didrocks, they told me it fixed test failures ;-)
[07:03] <didrocks> we want to be able to go back to a good state before putting cracks in
[07:03] <didrocks> robru: yeah, fixes and regressions :p
[07:03] <didrocks> (potential at least)
[07:04] <didrocks> apart if they only touch codes in tests/
[07:04] <robru> didrocks, ok, please let t1mp know that you veto'd it, since I already said i would do it
[07:04] <didrocks> robru: will do
[07:04] <didrocks> yeah, look at trunk
[07:04] <didrocks> quite a lot of changes
[07:05] <didrocks> let's hope we can promote an image today
[07:21] <robru> didrocks, ahhhhh, I need the VPN details. is there a wiki for that somewhere?
[07:34] <didrocks> robru: hum, I think I sent an email about that 3 weeks ago :)
[07:35] <didrocks> robru: sent
[07:35] <didrocks> robru: I hope you recovered your emails
[07:36] <robru> didrocks, emails? those are all in gmail!
[07:36] <robru> the cloud is great ;-)
[07:36] <robru> didrocks, yeah, personal files were well backed up, but I lost the system partition, so things like vpn config tokens are gone
[07:40] <didrocks> robru: oh, mine in my ~ dir
[07:41] <didrocks> thanks for network-manager
[07:41] <didrocks> to*
[07:41] <robru> didrocks, where does it hide? i was using network manager...
[07:42] <didrocks> robru: IIRC, it's in gsettings
[07:43] <robru> didrocks, how do I extract gsettings from a not-running user directory? ~/.local where?
[07:43] <didrocks> robru: hum, forget about it? I don't find them in a dconf dump
[07:45] <robru> didrocks, anyways, it's midnight. i'll get back on the VPN tomorrow
[07:45] <didrocks> yep, sounds better :)
[09:02] <seb128> good morning desktopers
[09:02] <seb128> happy friday!
[09:03] <Laney> hey!
[09:03] <Laney> xnox: w o w !
[09:03] <seb128> Laney, hey, how are you?
[09:03] <pitti> bonjour seb128, hey Laney
[09:03] <seb128> pitti, salut, ça va ?
[09:03] <Laney> hey seb128 pitti
[09:03] <pitti> ça va bien !
[09:03] <Laney> pretty decent, glad that it's friday :-)
[09:03] <seb128> Laney, congrats on defeating webkitgtk
[09:04] <Laney> crazy eh?
[09:04] <seb128> ;-)
[09:04] <Laney> just have to test build every future upload on 4 arches from now on
[09:04] <seb128> I'm surprised you didn't go "I never want to upload webkit ever again"
[09:05] <Laney> there is that
[09:05] <seb128> ;-)
[09:06] <larsu> Laney: I don't even think we need it much longer. The web seems to be a passing fad
[09:06] <Laney> port all to oxide
[09:06] <Laney> then deprecate webkitgtk and let attente maintain it
[09:06] <seb128> you guys are just mean to attente!
[09:06] <larsu> attente already had his troll friday last night
[09:06] <seb128> oh, wait, it's friday
[09:06] <seb128> ok then
[09:06] <larsu> haha
[09:07] <larsu> I thought you redeclared them to learn-something-Fridays?
[09:07] <larsu> I guess we all learned how much we like trolling...
[09:07] <seb128> lol, indeed
[09:07] <seb128> larsu, btw, gtk 3.10.6 in the ppa, seems to work fine there
[09:08] <seb128> I'm pondering uploading to trusty today or give it the W.E and upload on monday
[09:09] <larsu> give it the weekend, please :)
[09:09] <Laney> oh, invisible cursor
[09:09] <seb128> k
[09:09] <Laney> haven't had that bug in a couple of weeks :P
[09:09]  * larsu doesn't want to wake up to angry emails on Saturday
[09:09] <seb128> Laney, :-(
[09:09] <seb128> Laney, when did you last update/restart xorg? is that happening at boot/login?
[09:09] <Laney> i just turned it on today
[09:09] <Laney> and after starting the session, don't know if it was there on the greeter
[09:09] <seb128> is that current trusty?
[09:10] <Laney> ish
[09:10] <seb128> no ish
[09:10] <Laney> I think I dist-upgraded yesterday
[09:10] <Laney> not today
[09:10] <seb128> Laney, https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1238410
[09:10] <ubot2`> Launchpad bug 1238410 in X.Org X server "Inconsistent cursor visibility with cursor plugin enabled" [Medium,In progress]
[09:10] <seb128> Laney, it was supposed to be fixed with xorg's update on wednesday
[09:10] <seb128> Laney, can you make sure if you have that version or not?
[09:10] <Laney> xorg-server?
[09:10] <seb128> see comment 24
[09:10] <seb128> on that bug
[09:11] <Laney> ok /me looks
[09:12] <Laney> ah
[09:12] <Laney>   Installed: 2:1.14.3-5ubuntu1
[09:12] <Laney>   Candidate: 2:1.14.4-1ubuntu1
[09:13] <ali1234> tedg: what do we need to do in xfce4-indicator-plugin to handle upstart indicator activation?
[09:13] <ali1234> just system("init ..."); ?
[09:13] <seb128> Laney, I prefer that ;-)
[09:13] <tedg> ali1234, Yeah, did you see the commit to unity-greeter?
[09:13] <ali1234> tedg: yes
[09:13] <Laney> indeed
[09:13] <tedg> ali1234, I think that's the best way.
[09:14] <ali1234> i guess i need to use something that doesn't wait for the process to finish, ie fork()
[09:14] <tedg> ali1234, Though, I'd really recommend switch XFCE over to Upstart User Sessions :-)
[09:14] <ali1234> xubuntu uses upstart
[09:15] <tedg> System session, probably not user session.
[09:15] <ali1234> it uses upstart for the user session
[09:15] <tedg> Really?
[09:15] <ali1234> yes really. we had to get it fixed
[09:15] <tedg> Cool.  Then you shouldn't need to do anything.
[09:15] <ali1234> well, ok then, your new indicators are broken :(
[09:15] <tedg> Oh, you need to emit that event.
[09:15] <ali1234> half the time they don't load up
[09:16] <tedg> So just a "initctl emit-event indicator-service-start"
[09:16] <ali1234> hmm.
[09:16] <tedg> So just a "initctl emit-event indicator-services-start"
[09:16] <tedg> (notice typo in first one)
[09:18] <ali1234> assuming you meant initctl emit
[09:18] <ali1234> is that command supposed to hang forever?
[09:18] <tedg> Yes, sorry it's early :-)
[09:18] <tedg> Shouldn't be forever...
[09:18] <ali1234> oh i see... i already had run the command that starts the job direct
[09:18] <tedg> You can use --no-wait if you want it exit right away.
[09:19] <ali1234> ok. so what should emit this event?
[09:19] <ali1234> the indicator plugin? or something earlier in the session startup?
[09:19] <seb128> Laney, why did you put a block on webkitgtk again? (did I ask before?)
[09:19] <Laney> just to test it
[09:19] <Laney> I'll remove it shortly
[09:19] <seb128> ok
[09:20] <Laney> then start on the g-o-a transition
[09:20] <seb128> \o/
[09:22] <tedg> ali1234, I'd say the indicator plugin, then you can emit the end as well to manage the full lifecycle if it gets added or removed.
[09:24] <ali1234> tedg: ok, thanks.
[09:26] <Laney> oh come on
[09:27] <seb128> Laney, don't tell me that webkit is buggy
[09:27] <Laney> no
[09:27] <Laney> my session won't open
[09:27] <seb128> won't open?
[09:27] <seb128> do you need help debugging?
[09:27] <Laney> greeter goes away, hangs
[09:27] <Laney> well, not hang, but no compiz
[09:28] <Laney> sec, checking logs
[09:28] <seb128> no compiz or no unity?
[09:28] <Laney> both
[09:28] <seb128> hum
[09:33] <Laney> I've got various things like this in logs: (gnome-settings-daemon:3897): Gdk-WARNING **: gnome-settings-daemon: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
[09:33] <ali1234> silly question, but is your hard drive full?
[09:34] <Laney> /dev/sda5       120G  102G   13G  90% /
[09:37] <seb128> Laney, what do you have in your gnome-session.log ?
[09:37] <seb128> Laney, those seems like xorg is closing/have an issue
[09:37] <Laney> a load of those
[09:38] <seb128> does it work to start a guest session?
[09:39] <Laney> no, it's the same
[09:40] <seb128> using nouveau?
[09:40] <Laney> yeah
[09:40] <seb128> well, you can try to ruling out lightdm by going to a vt and do startx : --1 or something
[09:51] <asac> hey ho ... my trusty desktop system just came to stall (no mouse/keyboard input for 20+ seconds) with oneconf-service and x*apt-something looping at 100% at the same time
[09:52] <asac> maybe there is an unfortunate timed cron job that kicks both at the same time?
[09:53] <ogra_> it is just not storm safe
[09:53] <ogra_> check the ropes ;)
[09:53] <seb128> asac, I'm not sure they are croned, they might just react to apt index changes, didrocks probably knows since he wrote oneconf
[09:54] <seb128> ogra_, do you still get s-c to hit that Xerror?
[09:54] <ogra_> seb128, dunno, will test when i'm at the machine
[09:54] <ogra_> (and report back)
[09:54] <seb128> ogra_, thanks (could use debug infos from somebody having the issue)
[09:54] <ogra_> yup
[09:59] <didrocks> they aren't cronned but trigger by dpkg
[09:59] <didrocks> well for oneconf at least
[10:04] <seb128> Laney, did you figure it out?
[10:05] <Laney> no :(
[10:05] <seb128> is startx working?
[10:10] <Laney> It waits for ages and eventually I get a timeout locking .Xauthority
[10:10] <Laney> even if I rm it beforehand
[10:16] <ali1234> tedg: the indicator services don't start up fast enough and i just get an empty panel
[10:22] <tedg> ali1234, Hmm, but they do start?
[10:22] <ali1234> yes
[10:22] <tedg> ali1234, Do you then populate as they come up?
[10:22] <ali1234> no
[10:23] <tedg> ali1234, Are you using the libindicator code?  I thought it handled that.
[10:23] <ali1234> libindicator3, yes
[10:24] <ali1234> it doesn't handle it
[10:25] <ali1234> i'm building with a long delay to see what happens
[10:25] <tedg> K
[10:33] <ali1234> tedg: i see what is happening
[10:34] <ali1234> when it runs "initctl emit indicator-service-start" it hangs, because the service is already running for some reason
[11:00] <ali1234> tedg: libappindicator is falling back to systray for no good reason
[11:05] <Laney> larsu: http://ubuntuone.com/1GS1IppvwNFus6HMOZEXeA ← see the white bars on the toolbar - is that a gtk / theme problem?
[11:08] <ali1234> http://bazaar.launchpad.net/~ted/indicator-application/upstart-job/revision/245
[11:10] <ali1234> tedg: you just broke appindicators for gnome-panel and xubuntu
[11:13] <tedg> ali1234, That's just application indicators, but I expected those folks to use the XDG autostart file.  Happy to change it around.
[11:14] <ali1234> xdg-autostart doesn't work for appindicator-service
[11:14] <ali1234> it immediately exits if nothing is using it
[11:14] <ali1234> actually, i don't see how it can work with upstart either
[11:14] <ali1234> at the very least there's a nasty race condition
[11:17] <ali1234> my logs are full of "service respawning" spam because of this shutdown-if-nothing-is-using-me functionality
[11:17] <ali1234> this is probably why they only load up half of the time too
[11:18] <ali1234> also the indicator-services-end signal doesn't appear to do anything
[11:20] <tedg> Yeah, probably removing those timeouts makes sense now that they're managed by the session management.
[11:20] <ali1234> sometimes they get killed because of respawning too fast
[11:21] <ali1234> i'm not sure if xubuntu is using upstart or xdg-autostart to start these services, but all i know is that half of them are already loaded when i log in, sending the startup event hangs initctl, and appindicator-service is impossible to start or use in any way
[11:21] <larsu> Laney: looks like it, yes. Which version of epiphany is that?
[11:22] <Laney> larsu: it's epiphany-browser 3.8.2-4ubuntu1 from trusty-proposed
[11:22] <larsu> ah okay, that's why I'm not seeing that yet
[11:22] <Laney> just about to unblock webkit, so you'll get it soon :P
[11:23] <larsu> yay
[11:23] <larsu> I'll have a look into that, then. Thanks for pointing it out
[11:23] <Laney> yw
[11:23] <seb128> Laney, you really use web from browsing?
[11:23] <seb128> or did you just test webkit?
[11:23] <Laney> EPARSE
[11:23] <seb128> web = epiphany
[11:23] <Laney> was just to test webkit
[11:23] <Laney> s/from/for/
[11:23] <seb128> oh, right
[11:24] <seb128> do you need extra testers for webkit?
[11:24] <seb128> did you figure out your login issues btw?
[11:24] <Laney> yeah, was a non-executable file which broke an upstart job that blocked the session login
[11:25] <seb128> shrug
[11:25] <seb128> that seems like unreliability
[11:26] <Laney> the design of upstart allows any job to block any other job
[11:26] <Laney> so you'll get things like this, unfortunately
[11:26] <Laney> I'm sure there could be better troubleshooting though
[11:27] <seb128> fair enough, and the real issue seems like your -x file
[11:27] <Laney> yes, I uploaded a fix for that
[11:27] <Laney> you could have like upstart watching for failed job starts or something
[11:28] <Laney> or unity not coming up, and dumping its state to errors
[11:28] <seb128> right
[11:30] <ali1234> tedg: via use of INDICATOR_ALLOW_NO_WATCHERS env var, i was able to make the service work properly
[11:30] <Laney> feel free to bash on webkit but I'm going to unblock it anyway; can fix stuff in release :P
[11:30] <Laney> also, src:webkit can be removed now
[11:30] <tedg> ali1234, Great, that makes sense.  Makes more sense to do it that way.
[11:30] <Laney> well, once it migrates
[11:32] <ali1234> and luckily this timeout is implemented in libindicator3, so it only has to be removed in one place for all of them :)
[11:35] <ogra_> uhm ... so after todays upgrade evolution goes constantly to 100% CPu usage :(
[11:46] <pitti> seb128: FYI, bug 1258458 is a dupe, fixed already two weeks ago
[11:46] <ubot2`> Launchpad bug 1252305 in apport (Ubuntu) "duplicate for #1258458 dpkg-divert not found" [Critical,Fix released] https://launchpad.net/bugs/1252305
[11:47] <pitti> people ought to upgrade their trusty a bit more often :)
[11:57] <seb128> pitti, thanks, we should also block reports from outdated systems (same way apport is doing it)
[11:57] <seb128> ogra_, weird, we didn't change a lot yesterday
[11:57] <seb128> ogra_, what did you get in your round of upgrades?
[11:57] <ogra_> glib perhaps ?
[11:58] <ali1234> Laney: if you put INDICATOR_ALLOW_NO_WATCHERS=yes in /etc/environment this may provide a temporary workaround for missing indicators
[11:58] <ogra_> though the changes dont look like they could cause issues
[11:58] <seb128> I doubt it
[11:58] <seb128> that's only adding some python debug stuff
[11:58] <ogra_> right
[11:58] <seb128> did you get the new webkit?
[11:58] <Laney> ali1234: cheers
[11:58] <ogra_> is it in the archive ? then i should have gotten it
[11:59] <Laney> are you going to do a MP to remove the check?
[11:59] <ogra_> with the new update manager it is really hard to say what i got
[11:59] <ali1234> Laney: yes
[11:59] <Laney> look in /var/log/dpkg.log
[11:59] <ogra_> the list of stuff is completely useless
[11:59] <Laney> webkit migrated about 2 minutes before you mentioned the issue
[12:00] <Laney> so i doubt you have that, unless you're running proposed
[12:00]  * ogra_ wonders why we show the list at all ... it doesnt really help anymore they way it is 
[12:00] <seb128> ogra_, what list?
[12:01] <ogra_> seb128, update-manager
[12:01] <seb128> why is it not useful?
[12:02] <pitti> seb128: yeah, except that whoopsie circumvents that check
[12:02] <seb128> pitti, I wonder if that's a good idea...
[12:02] <ogra_> because it uses weird cryptic package descriptions i would have to decypher first before knowing what i get
[12:02] <seb128> ogra_, we need to put better descriptions in our control files then...
[12:03] <Laney> well... we're asking him for the name of the software
[12:03] <ogra_> the description doesnt say something like "webkit foo bar baz" .... but says "very fast html rendering engine"
[12:04] <ogra_> thats absolutely not helpful without the exact package name ...
[12:04] <ogra_> (i'm making up the texts, just an example)
[12:04] <seb128> you are too technical, that tools is aiming at being user friendly
[12:04] <ogra_> well
[12:05] <ogra_> my mom wouldnt bother ...
[12:05] <ogra_> i wouldnt show that list at all
[12:05] <seb128> the intend is to list end user applications in the main list
[12:05] <seb128> with their icon
[12:05] <seb128> that works quite well
[12:06] <seb128> the technical items are under base OS
[12:06] <ogra_> for the tree apps that get updated along the 200 other packages, yes
[12:06] <ogra_> *three
[12:06] <ogra_> so just show apps with .desktop files or so
[12:07] <ogra_> i think what we show now is confusing
[12:09] <ogra_> btw, no webkit in dpkg.log
[12:09] <seb128> k
[12:09] <seb128> and you can reproduce the bug after restarting evo?
[12:13] <seb128> ogra_, http://ubuntuone.com/32sd5Xmv7NIgIry7ESlXir
[12:13] <seb128> ogra_, that looks a fine list to me...
[12:14] <seb128> ogra_, the security view is a bit weird, on a normal upgrade you would have the technical items under "Ubuntu base"
[12:15] <seb128> but the top of the list is nice, archive manager, desktop sharing, firefox web browser, etc
[12:15] <seb128> those are quite useful descriptions/items
[12:17] <Sweetshark> seb128: https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-quantaltest-20120601/+build/5306216 :(
[12:18] <Sweetshark> seb128: I updated the mdds version to the latest upstream, still happens on the trusty toolchain. I gotta check updating to the latest LO41 is of help otherwise it means digging deeper.
[12:18] <seb128> Sweetshark, can we just build with gcc-4.7 or something?
[12:19] <Sweetshark> seb128: hmm, good point.
[12:19] <Sweetshark> seb128: Ill try.
[12:19] <seb128> Sweetshark, thanks
[12:23] <ogra_> seb128, yes, the top looks fine ... further down not so much ... i would exclude libs and all
[12:25] <ali1234> how do i build libindicator from bzr into a package? http://paste.ubuntu.com/6529519/
[12:32] <seb128> bah, webkit
[12:33] <seb128> dbg = 350M, installed 1.5G
[12:40] <seb128> qengho, hey
[12:40] <seb128> qengho, do you have any news about the autopkgtest blocking chromium in trusty-proposed?
[12:58] <Laney> ali1234: how did you invoke the build?
[12:58] <ali1234> "debuild"
[12:58] <Laney> use bzr bd from bzr-builddeb
[12:59] <ali1234> do i have to commit changes for that to work?
[12:59] <Laney> no, but you have to bzr add new files
[13:00] <ali1234> noted, thanks
[14:05] <desrt> hihi, peeps
[14:20] <seb128> desrt, hey, happy friday!
[14:21] <seb128> Laney, so, I need to do a webkit upload, anything you wanted added there?
[14:24] <desrt> holy crap.  it's friday!
[14:25] <seb128> yeah, a good friday so far
[14:25] <JackYu> :)
[14:25] <seb128> Laney even managed to finally get webkit to build on all archs, including arm*
[14:25] <desrt> building webkit on arm?
[14:26] <JackYu> I'm in the night of Friday...
[14:26] <seb128> JackYu, you shouldn't be on the computer, that's not what friday nights are for!
[14:27] <desrt> ...says seb, who will be here 8 hours from now
[14:27] <JackYu> seb128, that's right. I will go to bed soon:)
[14:28] <larsu> desrt: morning! Should g_settings_get() disallow non-copying format strings? It calls g_variant_unref() after all
[14:28] <larsu> or is that a non-issue with all backends?
[14:28] <desrt> larsu: it's a very complicated question, to which the answer is "yes"
[14:28] <larsu> I find the question quite simple. Patch welcome?
[14:29] <desrt> yes please
[14:29] <desrt> the question is complicated by a few things
[14:29] <larsu> okay. This will break at least evince
[14:29] <desrt> because all backends do in fact support this
[14:29] <desrt> but only 99% of the time
[14:29] <larsu> hm?
[14:29] <desrt> if the gvdb gets replaced and reopened then your string could disappear under you if you unreffed the gvariant
[14:30] <larsu> which happens on writes, doesn't it?
[14:30] <desrt> yup
[14:30] <desrt> which don't happen 99% of the time
[14:30] <desrt> also: you have to do another read on the client side as well
[14:30] <desrt> because that's when it checks for the gvdb needing to be reopened
[14:30] <desrt> in theory it's possible to ensure that this isn't happening in your process
[14:30] <larsu> g_settings_get (settings, "&s", &str); g_settings_set (settings, whatever, bar); /* str is dangling */
[14:30] <desrt> in practice... threads, etc...
[14:30] <larsu> correct? ^
[14:31] <desrt> no.  in this case str would still be OK
[14:31] <larsu> why? Because you still have the old mmap even though the file link is gone`
[14:31] <desrt> yes
[14:31] <desrt> you have still mmaped the unlinked database
[14:31] <larsu> interesting
[14:31] <desrt> so the pointer is still good
[14:31] <desrt> as i said -- it's complicated
[14:31] <desrt> but i agree with your original idea to limit it
[14:31] <larsu> but best avoided...
[14:31] <desrt> yup
[14:32] <larsu> I mean, you can always get 0-copy with g_settings_get_value()
[14:32] <desrt> the other complicating factor: the API for checking format strings for copy-only was added long after g_settings_get()
[14:32] <desrt> precisely.
[14:32] <larsu> I know, I remember when you added it
[14:32] <desrt> also: if you're storing something for which you care about zero-copy in gsettings then you're doing it wrong
[14:32] <larsu> I came across someone doing it today, which is why I started wondering
[14:33] <desrt> ya... so this is an API break
[14:33] <desrt> i recommend doing two patches... first one should throw a critical but not return
[14:33] <larsu> didn't bother you in gmenumodel...
[14:33] <larsu> (same api break)
[14:33] <Laney> seb128: what do you want to upload it for?
[14:33] <Laney> but no
[14:33] <desrt> gmenumodel was very new when i made this break
[14:33] <desrt> gsettings is very old
[14:33] <larsu> fair enough
[14:34] <larsu> I'll do a critical first
[14:34] <larsu> with a note that this won't work much longer :D
[14:34] <desrt> party
[14:34] <larsu> party?
[14:35] <desrt> instead of saying 'awesome' or some other word
[14:35] <larsu> you and your Canadian slang!
[14:35]  * desrt discovers the hard way that bijiben's owncloud notes storage backend is ... unreliable
[14:36] <desrt> "oh... look at all of these text files in my homedir containing useful information... i should turn those into bijiben notes"
[14:36] <desrt> "okay... now i can delete the originals..."
[14:36] <larsu> it does that?!
[14:36] <desrt> larsu: no.  i did that.
[14:36] <larsu> ah. lol.
[14:36] <larsu> I mean, sorry for your data
[14:36] <desrt> "hm.  let's open this again.... hey.... why is this empty?"
[14:37] <desrt> larsu: don't be sorry for me.  mterry is on my side.
[14:37] <Laney> there's a new tomboy?
[14:37] <desrt> Laney: ish?
[14:37] <larsu> Laney: yes, but it destroys your data
[14:37] <desrt> the local storage backend is working nicely, fwiw
[14:37] <desrt> but uh... owncloud... ya
[14:37] <desrt> don't use that :)
[14:38] <Laney> canonical destroyed my tomboy notes too, don't worry
[14:38] <desrt> Laney: it's actually kinda nice.  it looks attractive and is integrated with gnome-shell search
[14:38] <larsu> the reason I went back to editing notes with vi ^^
[14:38] <desrt> (full text)
[14:38] <seb128> Laney, I've been getting debug infos and pinging people about that software-center Xerror that tops e.u.c since raring and Company has a tentative fix
[14:38] <Laney> ok, well I'd rather you get confirmation in a ppa
[14:39] <Sweetshark> anyone having seen stuff like this (on trusty): http://pastebin.com/x4qyVXsD ?
[14:39] <seb128> Laney, are you able to reproduce?
[14:39] <Laney> no
[14:39] <seb128> Laney, I was going to get confirmation through e.u.c stats
[14:39] <Laney> we know a german man who can though
[14:39] <Laney> at least judging by the frequency he complains about it
[14:39] <larsu> desrt: the faux ruled paper is a bit annoying
[14:39] <seb128> ok; let me throw it in a ppa then
[14:39] <desrt> larsu: i actually like that
[14:40] <Laney> i like that fix
[14:40] <seb128> me too ;-)
[14:40] <Laney> there should be a new point release along shortly so we might not need to upload explicitly for it anwyay
[14:40]  * desrt likes dejadup for pulling his ass from the fire once again
[14:40] <Laney> but good to know if it works
[14:40] <seb128> Laney, I really want to SRU that though
[14:40] <seb128> let's go through ppa
[14:40] <Laney> yeah you can do that
[14:42] <larsu> desrt: so g_variant_check_format_string() spews a critical itself, but only for one case
[14:43] <larsu> (when the string contains a & and copy-only is TRUE)
[14:43] <desrt> larsu: sounds fine... critical is totally appropriate here
[14:43] <desrt> just don't bail out of g_settings_get() because of it
[14:43] <desrt> i'd watch for the check() function returning false, and in that case issue -another- critical about "tried to read key 'xyz' from schema 'abc'"
[14:43] <larsu> desrt: I'm okay with that. I just don't like that it does a critical for _one_ case
[14:44] <desrt> to make it very easy to find
[14:44] <desrt> larsu: that does seem odd.  let me look.
[14:44] <larsu> ya, that's what I'm doing
[14:44] <larsu> also, "for the love of all that is good, please don't mark this string for translation..."
[14:44] <desrt> :)
[14:44] <desrt> can you understand why?
[14:45] <larsu> because it's non-trivial to explain correctly?
[14:45] <mterry> desrt, yay!  glad DD worked.  all I ever see is the bugs when it doesn't  :)
[14:45] <desrt> because, as a new translator, i have new appreciation for the pain that translators feel when faced with these kinds of messages
[14:46] <desrt> mterry: the 'restore old version' item in the rightclick menu in nautilus is totally great
[14:46] <larsu> mterry: if that's the case let me add myself publically to the "happy users" list
[14:46] <mterry> desrt, you lost the files outright, eh?  Have you tried the 'restore missing files' option?  It's magic
[14:47] <desrt> mterry: i just noticed that this was added
[14:47] <desrt> was about to complain about how i have to touch the file back into existence
[14:47] <desrt> when did this show up?
[14:47] <mterry> desrt, it's been there a year+ at least
[14:47] <desrt> that's pretty great
[14:47] <mterry> desrt, was a summer of code thing from a 2 years ago maybe
[14:47] <desrt> this is massive win
[14:48] <mterry> larsu, awesome  :)
[14:48] <desrt> mterry: slightly annoying at the same time, though
[14:48] <desrt> mterry: i can't select a file from the list to restore until the scanning is done
[14:48] <desrt> even though the list populates itself as it goes
[14:49] <mterry> desrt, hmm, fair
[14:49] <mterry> it also needs a sweep with the pretty brush
[14:49] <desrt> larsu: so the reason it throws a critical there is because this case is a programmer error
[14:50] <desrt> larsu: the other cases (unexpected type of GVariant shows up) are errors that originate from outside of the program
[14:50] <larsu> desrt: good point. Thanks.
[14:50] <larsu> desrt: no g_settings_get_schema?
[14:50] <desrt> obviously that's not an issue for you with gsettings
[14:50] <desrt> larsu: g_settings_schema_source_lookup iirc
[14:51] <desrt> or do you mean for getting the schema on the settings object itself
[14:51] <larsu> the latter
[14:51] <larsu> g_object_get (settings, "settings-schema",..)
[14:51] <desrt> ya.... that's tricky because of the naming
[14:51] <desrt> i wonder what would happen if i removed the "schema" property
[14:51] <larsu> api break
[14:52] <desrt> it's been deprecated for a while
[14:52] <desrt> i don't know if anyone is actually using it
[14:52] <larsu> I only want the schema id and I've got to jump through hoops for that
[14:52] <desrt> are you inside of gsettings?
[14:52] <larsu> ya
[14:52] <larsu> settings->schema?
[14:52] <desrt> you have a pointer to the schema in your priv
[14:52] <desrt> g_settings_schema_get_id (settings->priv->schema)
[14:53] <Sweetshark> note to self: executing commands that rm -rf /dev is unhealthy. even if done indirectly. even if done from a chroot, if it bind-mounts /dev.
[14:53] <larsu> desrt: thanks
[14:53] <desrt> returns const char*, btw
[14:55] <larsu> g_settings_get should really return a boolean
[14:55] <attente> Laney, all of that language data on the device seems to be compiled into a single private header in qtbase-opensource-src
[14:55]  * desrt readies the cluebat
[14:55] <desrt> larsu: why would a function that is always successful return a boolean?
[14:55] <Laney> attente: o rly?
[14:56] <attente> Laney, yeah.. can't really think of a way to change it short of adding a patch there
[14:56] <larsu> desrt: I knew you'd say that. You want g_error for copying formats in the future?
[14:56] <desrt> larsu: no.  i want you to return.
[14:56] <attente> but it's basically a patch of a generated file on a generated file
[14:56] <attente> *it would be
[14:56] <desrt> larsu: the absolute last thing in the world i want is for people to be checking the return value of every g_settings_get() call
[14:57] <Laney> is english the only one where using the short code gives you the wrong thing?
[14:57] <larsu> desrt: okay, but then you really want g_error (once this critical has been in long enough)
[14:57] <desrt> larsu: ya.  that's fair.
[14:58] <desrt> what we _really_ want is to change all of these g_error() to g_critical() and make g_critical() fatal for developers
[14:58] <attente> Laney, well, it's hard to say, but that's a side-effect of QLocale("en_DK.utf8") being the same of QLocale("en")
[14:58] <desrt> ... if we ever discover a reasonable way to do that
[14:58] <Laney> oh I don't know about the en_DK problem
[14:58] <attente> it's a bit tricky and not obvious how to fix it
[14:59] <attente> the language names themselves, well. i can edit the CLDR and regenerate the header
[15:00] <attente> but in order to make sure a problem like en -> en_DK doesn't occur, i'd have to make sure that all locales possibly output by 'locale -a' have an entry in the CLDR :S
[15:00] <Laney> it's a fallback?
[15:02] <attente> yeah. to explain it a bit more clearly, in u-s-s, how we try to determine what 'en' maps to, is we look through all of the 'en_*' locales, create a QLocale for each, and test for equivalence between that and the QLocale for 'en'
[15:02] <attente> so if we find an 'en_*' that's the same as 'en', we say, "oh! en is en_BLAH!"
[15:03] <attente> but that doesn't work for en because en_DK falls back to en :(
[15:03] <attente> and that's because it's missing in the CLDR
[15:07] <Laney> hmm
[15:22] <Laney> attente: I wonder if we could use icu directly
[15:23]  * ogra_ wonders why locale name mapping is still such a pain ... i still remember when the hardcoded mapping list entered GDM years and years ago to work around this 
[15:23] <Laney> attente: http://paste.ubuntu.com/6530205/
[15:24] <attente> Laney, that's icu output?
[15:24] <Laney> yeah
[15:26] <Laney> attente: http://paste.ubuntu.com/6530218/ give it a play
[15:26] <Laney> boo tab damage :P
[15:34] <attente> Laney, i must be doing something wrong, because i'm getting "en_US_POSIX - English (United States, Computer)" on the device
[15:35] <Laney> for what?
[15:35] <attente> when i run your test program
[15:35] <Laney> with no arguments?
[15:35] <Laney> I did for i in $(locale -i); ./a.out $i; done
[15:36] <Laney> s/-i/-a/
[15:36] <attente> oh ok
[15:36] <Laney> without it just uses your current locale
[15:36] <Laney> which I guess is POSIX for you there
[15:37] <attente> ok, thanks
[15:38] <attente> yeah, that works great!
[15:39] <Laney> exciting
[15:42] <Laney> did we have timeout problems with the libgdata tests before?
[15:47] <seb128> Laney, yes
[15:51] <happyaron> seb128: I'm a bit interest in XDG_CURRENT_SESSION, will there be any side effect if Kylin changes this to their own?
[15:51] <happyaron> bschaefer: hey
[15:51] <seb128> happyaron, yes, they need to patch all the .desktop to tweak their OnlyShowIn
[15:52] <bschaefer> happyaron, hello
[15:52] <happyaron> bschaefer: I want to know what's the status on the xim support?
[15:52] <happyaron> seb128: and including all the Ubuntu/Unity-specific stuff, to make them also show in Kylin sessions, am I right?
[15:53] <bschaefer> happyaron, right now, the bulk of it is done. There are a couple of problems, one being how to insert it into nux correctly
[15:53] <bschaefer> happyaron, hoping to have that in soon
[15:54] <happyaron> bschaefer: where is the branch? I lost the link (which I think you gave me before)
[15:54] <bschaefer> happyaron, hmm for my xim support, I don't think i've actually pushed a branch. As it wont compile with unity with out a little hack
[15:55] <happyaron> ok
[15:55] <bschaefer> i really should push it to a branch though :)
[15:55] <seb128> happyaron, right
[15:56] <happyaron> even if we are not very likely to use fcitx in this LTS, Kylin is very interested to get the fcitx support landed, I've looked at the branch from csslayer and there are quite some stuff changing XIM/related stuff, so I'd like to know your opinion.
[15:56] <happyaron> seb128: I see.
[15:56] <seb128> happyaron, it's doable, we did do it (added Unity where we were using GNOME before), but it's some work
[15:57] <bschaefer> happyaron, yup, the new changes that I will land will be support for preedit rendering
[15:57] <bschaefer> which is something that wasn't there before
[15:58] <happyaron> seb128: but I'd like to avoid that workload, so any other idea? do you think a gsettings key or something like that would work?
[15:58] <seb128> happyaron, what are you trying to do?
[15:58] <seb128> happyaron, is that still the branding stuff?
[15:59] <happyaron> seb128: I would like to find a proper place so that applications specificially support the Kylin flavor can identify it, and other applications do just the same like in Ubuntu.
[15:59] <seb128> happyaron, can't they just dpkg-divert the logos?
[15:59] <happyaron> seb128: it's a bit more than branding. dpkg-divert the logo is ok, but they want to change more.
[16:00] <seb128> happyaron, like?
[16:00] <happyaron> seb128: they'd like to change every "Ubuntu" to "Ubuntu Kylin" if possible, with a very very high priority.
[16:01] <seb128> do we have many "Ubuntu" mentions on our desktop?
[16:01] <happyaron> not many, but have some hard coded places.
[16:02] <happyaron> I'm waiting for a list from them to see how many places they would like to change.
[16:05] <happyaron> in short, we need to find a way to make applications that specifically add the support for Kylin able to identify it easily, and other applications just continue to see the system/desktop as "genuine" Ubuntu. So they can do whatever thing they'd like to with minimal affect on other stuff.
[16:10] <happyaron> seb128: any input?
[16:10] <seb128> happyaron, I don't really understand the problem so not really
[16:10] <xnox> happyaron: can you check what edubuntu does? i believe they customize the session name, while keeping it Ubuntu.
[16:11] <seb128> I was going to say, edubuntu seems like an example to look at
[16:11] <seb128> they do that sort of things
[16:11] <happyaron> ok
[16:11] <xnox> happyaron: alternatively you can add an upstart user session job to export a Kylin specific environment variable.
[16:11] <seb128> but I don't see that many cases where we have an "Ubuntu" specific behaviour
[16:12] <happyaron> seb128: there are quite some third-party software detects if it's running on "Ubuntu", and that's the question.
[16:12] <xnox> happyaron: e.g. it's best if you tell us _what_ you are planning to modify.
[16:12] <seb128> happyaron, is there?
[16:12] <seb128> happyaron, I don't know of any example
[16:12] <xnox> happyaron: becuase deciding on XDG_CURRENT_SESSION
[16:13] <xnox> happyaron: is most lickely the wrong decision for any customizations.
[16:13] <Laney> seb128: can we drop the goa dropping from libgdata?
[16:13] <Laney> it's why gnome-documents/armhf now fails to build
[16:13] <seb128> Laney, I know it's why
[16:13] <Laney> should be ok with the split now, no?
[16:13] <seb128> Laney, if the goa split making libgdata stop pulling in GTK?
[16:14] <Laney> what was the path before?
[16:14] <seb128> what patch?
[16:14] <Laney> path
[16:14] <happyaron> they told us they found several examples that relies on lsb-release's output, and never give an example, and ask to help change stuff for times, :(
[16:14] <Laney> to getting webkitgtk
[16:14] <seb128> oh
[16:14] <seb128> libgdata->libgoa->libwebkitgtk
[16:15] <Laney> I don't see it now
[16:15] <Laney> want to check?
[16:15] <seb128> ok, good
[16:15] <seb128> sure
[16:15] <seb128> is every in trusty-proposed?
[16:15] <seb128> everything
[16:15] <Laney> enough to check that
[16:15] <Laney> update an i386 chroot for example and install libgdata13
[16:16] <seb128> right, on it
[16:16] <Laney> you should see libgoa-1.0-0b
[16:19] <seb128> weird, "  Candidate: 0.14.0-1ubuntu1"
[16:19] <seb128> oh, fr mirror in there
[16:19]  * seb128 changes that
[16:22] <seb128> Laney, +1
[16:22] <seb128> # apt-get install libgdata13 libgtk-3-0-
[16:22] <seb128> 6 upgraded, 47 newly installed
[16:22] <Laney> ok, great, doing
[16:22] <seb128> that split is good news
[16:22] <Laney> yeah it's pretty nice
[16:22] <Laney> well done upstream for doing the library like that
[16:22] <seb128> the armhf hack I tried last cycle was just a hack
[16:23] <seb128> and I was not seeing a solution out of kicking goa out of build options for libgdata/e-d-s
[16:23] <seb128> yeah
[16:24] <Laney> damn, my latest rebuild of libgdata didn't hang
[16:27] <Laney> at least means I can kick builds of the other stuff
[16:47] <seb128> qengho, not there today?
[16:47] <qengho> seb128: there?
[16:47] <qengho> I'm here.
[16:48] <ogra_> where ?
[16:48] <seb128> qengho, I pinged you earlier to know the status of the autopkgtest test issues for chromium, not sure if you saw?
[16:49] <seb128> qengho, anyway if you didn't, what's the status of chromium-browser/trusty (it's still blocked in trust-proposed)
[16:49] <qengho> seb128: I don't see it.  I have #webapps testing a replacement. It should be today.
[16:49] <seb128> qengho, ok, great news, thanks ;-)
[16:49] <seb128> I hope we can get it unblocked next week
[16:50] <seb128> ogra_, if the ppas every clean their backlog and give us a build, https://launchpad.net/~ubuntu-desktop/+archive/ppa/+packages?field.name_filter=webkitgtk&field.status_filter=published&field.series_filter= ... that should fix the software-center issue, testing appreciated if you can give it a run before your holidays
[16:50] <seb128> ogra_, enjoy the holidays btw ;-)
[16:51] <ogra_> heh, i will ... but i'll likely be around at times too
[16:51] <ogra_> in public channels doing non work stuff
[16:51] <seb128> ogra_, like testing s-c (e.g buying games to play :p)
[16:51] <seb128> ?
[16:51] <seb128> ;-)
[16:51] <ogra_> yeah :)
[17:26] <Sweetshark> seb128: building LO4.1 with gcc-4.7 looks good so far. if it completes Ill hand you a pkg on Monday
[17:27] <seb128> Sweetshark, great, thanks!
[17:27] <Sweetshark> (on trusty)
[17:59] <Laney> alright, happy weekend desktoppers!
[18:05] <seb128> Laney, thanks, you too!