[05:43] <pitti> Good morning
[06:49] <desrt> pitti: hello!
[07:11] <pitti> hey desrt, how are you?
[07:12] <desrt> good :)
[08:36] <darkxst> larsu, any chance you could look at some theming issues with nautilus 3.10?
[08:45] <darkxst> larsu, there are two issues, 1. the buttons in the header bar are too small, 2. even though I disabled CSD, the GtkHeaderBar still gets rounded top corners
[08:46] <darkxst> lp:~darkxst/ubuntu/trusty/nautilus/310
[09:00] <Laney> g'morning
[09:00] <pitti> hey Laney
[09:01] <Laney> howdy pitti
[09:01] <Laney> how's it going?
[09:02] <pitti> quite fine indeed, thanks! how about your?
[09:02] <pitti> "you"
[09:03] <seb128> hey Laney, pitti, wie gehts?
[09:03] <seb128> good morning desktopers!
[09:03] <Laney> hey
[09:03] <pitti> bonjour seb128
[09:03] <pitti> seb128: I'm preparing gvfs 1.19.4 FYI
[09:03] <Laney> I'm good, nice climbing session last night
[09:03] <pitti> have it running here, but I need to update its tests for the new libgphoto2 version
[09:03] <seb128> pitti, oh, nice, I was pondering doing that today
[09:03] <seb128> pitti, thanks
[09:03] <Laney> looking forward to canonical-desktop-team climbing in london ;-)
[09:04] <seb128> Laney, do you know a nice place to go climbing in London?
[09:04] <didrocks> climbing? we'll be tortured on top of that? :)
[09:04] <Laney> not somewhere I know, but I found a place that's about 10 minutes from blue fin
[09:09] <larsu> darkxst: I'm afraid I won't have time for this in the next couple of days. But I'll try to get to it
[09:12] <seb128> larsu, hey, good morning, how are you?
[09:12] <seb128> larsu, your indicator-sound patch fixes the dconf write on login, no need to keep avoiding desrt anymore ;-)
[09:12] <larsu> phew!
[09:13] <larsu> seb128: I'm good thanks. How are you?
[09:13] <darkxst> larsu, thanks, I did try look at it, but gtk theming not really my speciality!
[09:13] <seb128> I'm good as well, thanks
[09:13] <darkxst> hi seb128
[09:14] <darkxst> hi Laney, pitti
[09:14] <larsu> darkxst: mine neither :)
[09:15] <seb128> hey darkxst
[09:15] <Laney> hi darkxst
[09:16] <seb128> darkxst, you got that polling bug wrong, the retries are not from fontconfig, they are from g_file_monitor which can't put a monitor on a non existing directory and needs to keep retrying in that case
[09:17] <seb128> darkxst, in any case I'm going to fix it so no need to bother about it
[09:17] <chrisccoulson> yoyoyo
[09:17] <darkxst> seb128, I blame the heat, 44C again today ;(
[09:17] <seb128> oh, a chrisccoulson!
[09:17] <chrisccoulson> hi :)
[09:18] <seb128> darkxst, that doesn't sound nice indeed
[09:18] <seb128> chrisccoulson, how are you?
[09:18] <seb128> chrisccoulson, we don't see you much nowadays, we miss you!
[09:18] <chrisccoulson> seb128, quite tired. but otherwise, not too bad. how are you?
[09:18] <chrisccoulson> heh :)
[09:18] <seb128> I'm good thanks
[09:18] <seb128> how is the oxide work going?
[09:18] <seb128> do you enjoy working on it?
[09:19] <chrisccoulson> seb128, yeah, it's great fun!
[09:19] <chrisccoulson> it certainly keeps me busy ;)
[09:19] <seb128> ;-)
[09:19] <seb128> good that you have fun at least!
[09:24] <dpm> morning seb128 - quick question: while looking at translations relevant for the phone, I've come across a bunch of packages that are in universe and thus can only be translated in the upstream project (e.g. indicator-location, click-update-manager). That's not a problem for translators, but to point them to the right locations, I'd like to better understand what generally happens with these universe packages and if I should be looking at approving tem
[09:24] <dpm> plates if they're promoted to main. Is the general practice to file a MIR for all of them before the release is out? Or are they ok in universe and there is no push to get them promoted?
[09:25] <seb128> dpm, hey
[09:25] <dpm> heya, morning
[09:26] <seb128> dpm, ideally we should have everything used in the touch image promoted
[09:26] <seb128> that didn't happen in saucy but we plan to the promotions for the LTS
[09:26] <seb128> meanwhile not sure what's the best way
[09:27] <seb128> it feels like that translating trunk with the autocommit is a better solution than translating on the Ubuntu side
[09:27] <seb128> we should maybe just do that for all the stuff we are upstream for?
[09:29] <dpm> seb128, I agree, we should do that, but there is no reason not to keep having the templates on the Ubuntu side in addition. Thanks to message sharing, when people translate on the Ubuntu side, translations are automatically shared with the upstream project, and if autocommits are enabled, the .po files are autocommitted there. The benefit of the Ubuntu side is basically more visibility and having all translatable templates in one place
[09:29] <Laney> there's a way to have any package in langpacks i think
[09:29] <seb128> dpm, sounds like a good solution
[09:30] <seb128> Laney, we enabled that a few cycles ago for e.g gnome-panel and then reverted because of some launchpad issues, not sure those have been fixed since
[09:30] <seb128> Laney, https://launchpad.net/ubuntu/+source/gnome-panel/1:3.6.0-0ubuntu2
[09:31] <seb128> https://bugs.launchpad.net/launchpad/+bug/1048556
[09:31] <ubot2> Launchpad bug 1048556 in Ubuntu Translations "Language pack translations export needs to add universe packages to domain map" [High,Triaged]
[09:31] <Laney> why did it get invalidated?
[09:32] <seb128> wgrant says it's working
[09:32] <seb128> so not sure if it got fixed
[09:32] <seb128> or if that's still an issue/more debugging is needed
[09:32] <dpm> yeah, we've never tried since
[09:33] <dpm> I'd like to see it working, but if the packages are going to be MIR'ed in any case, we might as well wait until they are in main
[09:33] <dpm> so that there is no extra effort to import their templates into LP
[09:34] <seb128> dpm, works for me
[09:58] <pitti> larsu, seb128, Laney, didrocks, desrt: is any of you going to FOSDEM by chance?
[09:58]  * pitti ponders going there to meet some people
[09:58] <seb128> pitti, https://wiki.canonical.com/UbuntuEngineering/2014/FOSDEM
[09:58] <seb128> pitti, Laney didrocks desrt larsu are going
[09:59] <Laney> & mlankhor1t
[09:59] <seb128> & Sweetshark
[09:59] <seb128> looking at the list there
[09:59] <seb128> & doko
[09:59] <pitti> ah
[09:59] <Laney> loadsa people
[09:59] <pitti> wow, I didn't know it was *that* official
[09:59] <pitti> I'd go there on my own dime again and stay with a friend in Leuven
[10:00] <larsu> pitti: clearly you *have to* come now :)
[10:00] <pitti> yeah, already talking to Michael :)
[10:01] <larsu> \o/
[10:01] <Laney> that place they've got us staying looks odd
[10:04] <pitti> wow, it's right in the city center
[10:09] <Laney> hahaha
[10:09] <Laney> I was grepping in the old webkit source for the arm64 failure
[10:09] <Laney> tearing my hair out as to where it could come from
[10:10] <czajkowski> Sweetshark: are you alive ?
[10:10] <czajkowski> Laney: mind your pretty hair please
[10:12] <Laney> needs a cut anyway
[10:33] <Laney> ok
[10:33] <Laney> probably dconf time!
[10:34] <seb128> wouhouh
[10:36] <Laney> /nick CrackPu$ha
[11:00] <Laney> hmm
[11:01] <Laney> should we hide webbrowser-app's desktop file on !unity8?
[11:02] <ochosi> speaking from a xubuntu pov, that would be a +1
[11:02] <Laney> if you type 'browser' into the dash it comes first
[11:02] <Laney> but it's not really a browser you want to use yet on non-touch
[11:03] <ochosi> may i quickly ask who's in charge of unity-greeter atm? is it robert or somebdy else?
[11:06] <Laney> yeah, mterry also works on it a bit I think
[11:06] <ochosi> ok, thanks
[11:06] <ochosi> (i'm currently working on a few things for lightdm-gtk-greeter that might also be interesting for unity-greeter)
[11:15] <seb128> Laney, do we install it by default?
[11:15] <Laney> yep
[11:15] <Laney> for webapps
[12:24] <ritz> Sweetshark, hi, wrt https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1200277
[12:24] <ubot2> Launchpad bug 1200277 in libreoffice (Ubuntu) "[LibreOffice] - libreoffice-writer.desktop when drag/drop to desktop, 100% broken. " [Low,Fix released]
[12:24] <ritz> which fix was pushed in ?
[12:28] <dpm> Laney, the licenses shown under "About this phone" on the system settings app. Are they supposed to be parsed for preinstalled click packages, or does it only work for showing licenses shipped in software packaged as .deb?
[12:29] <Laney> It currently does deb package licenses, but I guess should do both eventually
[12:30] <Laney> how can you get it for clicks?
[12:33]  * Laney paws at desrt 
[12:33] <Laney> https://launchpad.net/ubuntu/+source/glib2.0/2.39.3-0ubuntu1
[12:34] <Laney> I'm falling out of love with this testsuite :P
[12:36] <larsu> Laney: sometimes I wonder if tests save more time than we spend on fixing them...
[12:39] <Laney> mmm...
[12:39] <Laney> I don't doubt their utility, but running them seems to be Hard
[12:41] <seb128> larsu, the main goal is not efficiency for us, it's to protect the archive/users from bugs
[12:41]  * walters notes that Continuous has executed the glib tests, the json-glib tests, etc. (all InstalledTests) 20 times today so far alone
[12:42] <Laney> haha
[12:42] <seb128> walters, without issues? seems like you run only part of the tests ;-)
[12:42] <larsu> seb128: yeah, of course. I'm not saying we should get rid of them.
[12:42] <Laney> do you set up the environment somehow?
[12:42] <seb128> walters, desrt confirmed earlier in the week that some of the tests are flaky
[12:42]  * larsu was just thinking out loud
[12:42] <walters> Laney: yes - InstalledTests *run inside the system I ship*
[12:42] <Laney> nod
[12:42] <walters> the process is:  build -> deploy -> test -> more testing
[12:42] <walters> not build -> test in lame chroot -> ship
[12:44] <Laney> make check ought to work too :-)
[12:44] <seb128> walters, those are different tests... we also have integration tests
[12:44] <walters> seb128: no they're not different
[12:44] <walters> glib's InstalledTests is probably 90% of "make check"
[12:45] <seb128> walters, so you get lucky with your setup and land on the right side of a race bug, since some people hit sometime those tests on their normal desktop installation
[12:45] <walters> seb128: oh the tests are *full* of race conditions
[12:45] <walters> but i don't blow up the build just because a few tests are racy
[12:45] <walters> that's just a recipe for pain
[12:45] <seb128> how do you know if the tests fail because of a bug in the lib or a bug in the test?
[12:45] <walters> that requires human intervention
[12:46] <walters> Continuous' status board reminds me all the time that ostree is a bit racy
[12:47] <walters> and that the gtk+ reftest is failing consistently
[12:48] <walters> it would obviously be great if glib's tests were race free
[12:49] <walters> i worked on fixing some of the most egregious ones myself
[12:50] <walters> but not shipping because of a subset of racy tests is just adding pain, IMO
[12:50] <walters> really, software is not either "tested" or "not tested"
[12:50] <walters> there's a continuum
[12:51] <Laney> so you would not run make check during a package build then?
[12:51] <walters> Continuous does not run make check
[12:51] <Laney> I'm talking about for distros
[12:51] <walters> it also doesn't ship packages, but fully assembled atomically upgradable filesystem trees
[12:51] <Laney> what does fedora do?
[12:52] <walters> fedora does the same thing you guys do because rpm and dpkg are exactly the same architecturally and lead to the same design decisions
[12:53] <walters> really the key ingredient is fast and easy rollback
[12:53] <walters> whereas dpkg/rpm are slaves to ever increasing version numbers
[12:54] <walters> with Continuous i have the ability to choose any git commit to build *and ship* at any time
[12:55] <walters> so if a glib commit blew up, I could just choose to ship an earlier one
[12:55] <Laney> it's an interesting facility for sure
[12:56] <Laney> you need to be able to tell if anything was relying on the behaviour you reverted
[12:56] <Laney> I guess a SONAME bump would be the worst case there
[12:58] <walters> i have an "epoch" facility that allows me to force a rebuild arbitrarily even if the git commit didn't change
[12:58] <walters> e.g.: https://git.gnome.org/browse/gnome-continuous/commit/manifest.json?id=2ff148922c5a4fe209026eaa6d94e0735c3ac828
[12:58] <walters> there's also no reason the system couldn't say "hey the soname of this library changed, let me determine its consumers and rebuild them" automatically, it's just code to write
[13:01] <Laney> assuming the rebuild works
[13:01] <Laney> and it can only work for things which are inside the system
[13:01] <Laney> anyway, it is true that reverts are painful for us
[13:02] <Laney> a lot software isn't really designed to go backwards even if the packaging system allowed it
[13:02] <Laney> like if configuration format migration is supported, it'll usually be forwards only
[13:03] <walters> yes, but it shouldn't be hard for the software to keep a version number, and just ignore/delete too new data
[13:03] <walters> if you're talking about caches
[13:04] <walters> for custom binary data like the systemd journal, ignore + append only aspect should work
[13:04] <Laney> it's all solvable if software is designed with forethought
[13:04] <walters> for /home, yes, it is an issue
[13:05] <walters> but basically i've never so far reverted back across a format transition to my knowledge
[13:05] <walters> really it's more "hey this commit is full of garbage and the author is offline for the rest of the day" type of thing
[13:06] <walters> anyways the ulterior motive I have here is I'd love for you guys to investigate OSTree instead of https://wiki.ubuntu.com/ImageBasedUpgrades
[13:06] <walters> that said, back to code
[13:07] <Laney> enjoy
[13:07] <Laney> ta for the discussion
[13:18] <didrocks> Laney: I hope that glib isn't going to regress the Touch image :/
[13:19] <didrocks> and d-conf as well :)
[13:19] <Laney> um
[13:19] <Laney> me too
[13:19] <asac> Laney: did you not see the mail?
[13:20] <seb128> we can't stop working every time a touch test is failing...
[13:21] <asac> we only send the mail after a few days of regression dancing
[13:24] <Laney> If you want to block them then feel free
[13:31] <asac> Laney: you suggest that we do a technical block? We feel that such a hard block is pretty black and white ... we can be smarter and keep more folks moving by just being a bit more conciousness and careful and coordinate and maye do some extra testing while we resurrect the touch image
[13:33] <Sweetshark> czajkowski: sorta, kinda: frantically doing builds ....
[13:35] <pitti> Laney: btw, do you happen to know what's up with https://jenkins.qa.ubuntu.com/job/trusty-adt-glib-networking/ ? close-during-handshake is pretty persistently failing (most of the time on i386, but I've seen it succeed on i386 and fail on amd64, too)
[13:35] <Laney> pitti: I'm writing a report about it, but in short: no :(
[13:35] <pitti> Laney: ack, thanks
[13:37] <pitti> http://people.canonical.com/~ubuntu-archive/component-mismatches.svg -> hah, rhythmbox recommends epiphany-browser now? fun
[13:37] <Laney> it's because of arm64
[13:37] <Laney> been there for a while
[13:38] <pitti> (I was looking for information about libtest-strict-perl : Depends: libdevel-cover-perl but it is not going to be installed)
[13:38] <pitti> ah, new perl in -proposed that makes stuff uninstallable
[13:39] <Laney> there's no better provider of x-www-browser IIRC
[13:39] <pitti> there's always elinks :)
[13:39] <pitti> yeah, except for the "x-" bit..
[13:57] <desrt> walters: try going into gio/tests/ and doing 'while true; do ./gdbus-names; done'
[13:57] <desrt> walters: it'll fail eventually...
[14:19] <hikiko> hi :)
[14:19] <czajkowski> Sweetshark: just wondered if you knew of a way to make exporting of a .odp into a .powerpoint madness actually behave
[14:20] <seb128> hikiko, hey
[14:21] <hikiko> a quick question: I've read that gsettings/gtk/gnome etc use the xft to scale the fonts yesterday, but I'd like to see exactly what happens when the text-scaling-factor gsetting is modified, do you know where I could find the code?
[14:22] <Sweetshark> czajkowski: hmmm, no magic tricks on my mind there sorry :/
[14:23] <czajkowski> boggles
[14:23] <czajkowski> all my  formatting is going out the window
[14:23] <czajkowski> time to go stab it
[14:23] <seb128> hikiko, not sure, it might be in pango if it's fonts
[14:23] <seb128> desrt, larsu: ^ do you know about what hikiko asked there?
[14:24] <desrt> hikiko: gnome-settings-daemon uses it to publish xsettings which the toolkit picks up via GtkSettings
[14:24] <desrt> hikiko: that is what results in the scaling
[14:24] <desrt> if you want to see code look at gnome-settings-daemon/plugins/xsettings
[14:34] <hikiko> desrt, thank you very much, I got a look, but it seems to use the gsettings too :) I'd like to see what happens at a lower level, I mean to see which xft function is called! but anyway, I'll check the .h to find which library's source I need to check out :D thanks!
[14:35]  * Sweetshark runs htop on his 32 core machine.
[14:36] <desrt> hikiko: so gtk picks up the setting and uses it to tell pango what font size to use for its layouts
[14:36] <desrt> hikiko: pango renders via cairo which has freetype as a backend
[14:36] <desrt> (pango is mostly just for laying out text)
[14:36]  * Sweetshark decides he needs to buy a bigger screen. Only seeing cores, no processes.
[14:36] <desrt> Sweetshark: you have a 32 core machine?
[14:36] <desrt> 32 cores or 32 threads?
[14:37]  * desrt reminds himself "oh ya... libreoffice maintainer... makes sense..."
[14:37] <Sweetshark> desrt: two opteron 6272 ...
[14:37] <desrt> Sweetshark: why not 64?
[14:38] <desrt> ah... iirc amd counts cores differently than intel
[14:38] <Sweetshark> desrt: building libreoffice in 18 minutes flat from scratch was considered reasonable, and more cores would have been much more expansive.
[14:38] <desrt> Sweetshark: did you attempt to measure how much each build costs?
[14:39] <desrt> (in terms of electricity consumed)
[14:39] <Sweetshark> desrt: <3minutes with a warm ccache -- in tmpfs obviously.
[14:39] <desrt> obviously
[14:40] <Sweetshark> desrt: well, its cheaper on that machine than on smaller machines as it is faster. For me in europe with green energy (which means at least three times the US price), a build costs some 3-4cents.
[14:41] <desrt> Sweetshark: we pay ~10¢/kWh in ontario... but it depends on the time of day
[14:41] <Sweetshark> desrt: 470watts when compiling hard, 18 minutes, 0.25 cent/KWH
[14:41] <desrt> and year...
[14:41] <desrt> 0.25cent? :)
[14:41] <Sweetshark> desrt: yep. and that is eurocent.
[14:41]  * desrt remembers that thing about the guy and his phonebill
[14:42] <desrt> i think you mean 0.25€ or 25 cent
[14:42] <desrt> not 0.25 cent
[14:42] <desrt> otherwise your rates are very good :)
[14:42] <Sweetshark> desrt: whoops, right.
[14:42] <desrt> that is indeed almost 3x higher than what we pay
[14:42] <ogra_> a european  quater
[14:42] <desrt> TIL
[14:42] <ogra_> :)
[14:46] <Sweetshark> desrt: might be only germany. as you know we move away from nucular towards renewable. and to create the infra for that (net capacity), only endusers are paying an extra tax (regard if you use nuclear or green energy), not the industry (like aluminium production, which uses huge amount. Endusers cant opt-out of that. And THEN, you can opt-in to only draw green energy from that infra -- for which you pay extra.
[14:47] <desrt> it's weird how opinions differ on these topics
[14:47] <desrt> ontario is spinning up new renewables *and* more nuclear in order to move away from coal
[14:48] <desrt> our last coal plant is going offline this year (and is already operating at half capacity)
[14:51] <Sweetshark> desrt: depends on the market I guess -- nuclear and renewables dont really work well together for germany as renewable has fluctuation in output and nuclear has too much latency to fill the gaps (while coal/gas is quicker to adjust). Which is why we need better infra: pump storage plants in the mountains in the south and net capacity to get the wind energy from the coast there.
[14:52] <desrt> Sweetshark: we also have a small army of gas plants... we try not to use those, but they fill in the gaps nicely
[14:53] <desrt> we also have a fair amount of hydroelectric with large resevoirs
[14:55] <desrt> Sweetshark: did you see this concept btw?  http://www.gizmag.com/ares-rail-energy-storage/28395/
[14:55]  * desrt loves it
[14:55] <Sweetshark> desrt: yep, germanys depletable ressources are pretty much ... depleted, so gas means buying it from russia. And hydroelectric, we somehow skipped that, without good reasons mostly (well, dense population was obviously a contributing factor).
[15:01] <Sweetshark> desrt: that pretty awesome. Here is its nemesis: http://oilprice.com/Latest-Energy-News/World-News/Why-did-a-Train-Carrying-Biofuel-Cross-the-Border-24-Times-and-Never-Unload.html -- a train that rode the same cargo (biofuel) from US to Canada and back 24 times purely to collect subsidies ...
[15:01] <Sweetshark> (never loading or unloading inbetween)
[15:01] <desrt> Sweetshark: that was big news here, understandably :)
[15:02] <Sweetshark> ;)
[15:03] <desrt> i think i'd like to live somewhere with a view of that train yard
[15:03] <seb128> Laney, kenvandine, attente: settings meeting time, no mpt or ted around it seems ... do you have any update?
[15:04] <desrt> watching the trains go up and downhill all day with bins full of rocks would be really calming
[15:04] <desrt> and you'd get a really interesting visual representation of power use/consumption patterns throughout the day
[15:04] <desrt> use/generation i mean
[15:04] <Laney> seb128: umm, not unless you want to talk about the AS stuff
[15:04] <Laney> and I want to ask you if you worked on the scrolling test thing
[15:04] <Laney> nothing other than that :-)
[15:04] <attente> seb128, not much besides the dynamic translation bug
[15:04] <seb128> Laney, ken is there, let's have a quick one
[15:05] <Laney> too busy retrying glib builds
[15:05]  * Laney sniggers
[15:05] <seb128> attente, ^ feel free to join or not, your call
[15:05] <Laney> seb128: want to get <person who I forgot> to join?
[15:05] <Laney> Wellark?
[15:06] <seb128> Laney, it's a bit late notice, we should for the next one though
[15:19] <attente> this is the branch: https://code.launchpad.net/~attente/ubuntu-system-settings/language-autopilot
[15:20] <attente> but the select_single call doesn't work
[15:20] <Sweetshark> seb128: fwiw, selfassigned the 'general error' bug and will look into it (esp. if it still is around with 4.2)
[15:20] <seb128> Sweetshark, thanks
[15:20] <seb128> attente, ok, added to my todolist to have a look
[15:20] <attente> seb128, thanks
[15:20] <seb128> yw!
[15:55] <seb128> mdeslaur, hey
[15:55] <mdeslaur> seb128: hey
[15:56] <seb128> mdeslaur, thanks for the nautilus fix! do you plan to upload? if so please wait (I've another fix I want to include)
[15:56] <mdeslaur> yeah, was planning to
[15:56] <seb128> mdeslaur, if you didn't start I can just sneak your patch in my upload
[15:56] <mdeslaur> seb128: can I just give you my debdiff?
[15:56] <seb128> mdeslaur, feel free to commit to the vcs
[15:56] <seb128> or debdiff works
[15:56] <mdeslaur> ok, I'll commit, one sec
[15:56] <seb128> lp:~ubuntu-desktop/nautilus/ubuntu
[15:56] <seb128> debian only style, so easy to checkout ;-)
[15:56] <seb128> thanks
[15:57] <Sweetshark> ugh, does anyone know if xz is somehow broken on armhf? my attempt to build in a trusty pbuilder created today, bail out with some weird error before even starting to build (while the package is fine on amd64) ...
[15:58] <ochosi> mterry: ping
[15:58] <mdeslaur> seb128: commited, thanks
[15:58] <mterry> ochosi, hello?
[15:58] <seb128> Sweetshark, not that I know, we have quite some sources with an orig.tar.xz, we would have noticed if armhf was unable to untar those
[15:58] <ochosi> hi mterry, i heard you're one of those working on unity-greeter
[15:58] <seb128> mdeslaur, thank you ;-)
[15:59] <ochosi> mterry: i just added session_badge support to lightdm-gtk-greeter and wanted to check whether you were interested to make the badge-system compatible between the two greeters
[16:00] <mterry> ochosi, OK...  what are the current incompatibilities?
[16:00] <mterry> Oh, I use a unity-greeter path?
[16:01] <ochosi> mterry: yeah, it's not very "friendly" :)
[16:01] <ochosi> i've implemented a very simple version in gtk-greeter now, it looks in hicolor/scalable/places
[16:01] <ochosi> so ppl can actually very easily add their own badges to their icon-theme and it'll be found
[16:02] <ochosi> i haven't looked into unity-greeter very deeply (i.e. in how far you even [can] use gtk)
[16:02] <ochosi> but i'm using symbolic badges now
[16:02] <ochosi> as opposed to the all-white pngs that unity-greeter uses
[16:03] <Sweetshark> seb128: dpkg-deb: building package `pbuilder-satisfydepends-dummy' in `/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'. \n dpkg-deb (subprocess): compressing data member: lzma error: Cannot allocate memory
[16:03] <ochosi> mterry: if you think this is all mumbo-jumbo and don't actually have time to work on this, it's also fine. i just wanted to point this out (as it seemed that gtk-greeter has an edge over unity-greeter in some respect for the first time)
[16:04] <ochosi> mterry: well, and i like if things/people cooperate :)
[16:04] <seb128> Sweetshark, seems rather than your archive is enough to make xz hits the machine limits
[16:04] <Sweetshark> seb128: looks like it fails when trying to create the dummy package?
[16:04] <seb128> dunno then
[16:04] <mterry> ochosi, well.  The badges used by the unity-greeter are very much in the 'unity' icon style
[16:04] <mterry> ochosi, so I'm not sure how portable they are
[16:05] <seb128> try maybe #ubuntu-devel that's not really desktopish and more people might know there
[16:05] <mterry> ochosi, sorry, you may have to repeat something
[16:05] <ochosi> mterry: no problem, just so you see how it looks here: http://www.zimagez.com/zimage/screenshot-01162014-013359pm.php
[16:06] <ochosi> mterry: as we allow theming (and transparency), the symbolic icons are quite important for us. they look quite similar to the unity-greeter style, they're just 16px instead of 22 (because of -symbolic)
[16:07] <mterry> ochosi, OK.  Do you actually use the icon theme now or do you point at unity-greeter's path?
[16:08] <ochosi> mterry: i decided to go for icon-theme, anyway, i can't rely on unity-greeter to be installed ;)
[16:08] <mterry> ochosi, right.   So you install these icons where / what names?
[16:09] <ochosi> mterry: my loading mechanism is also different. i just use "$session_name"_badge-symbolic.svg, and the location is hicolor/scalable/places
[16:09] <ochosi> the commit is very readable, if you wanna take a look: http://bazaar.launchpad.net/~lightdm-gtk-greeter-team/lightdm-gtk-greeter/trunk/revision/188
[16:10] <Laney> desrt: can you see anything wrong with https://git.gnome.org/browse/glib/commit/glib/tests/asyncqueue.c?id=6d3b83a8c131e190da5db10d81c0d3cc0e3c6768 ?
[16:10] <Laney> this test is seriously shitty with .3
[16:10] <mterry> ochosi, hm.  I think there is a "unity-icon-theme" icon theme that may make more sense.  Since in addition to being symbolic, they have the circle and such.  Very much unity-style icons
[16:11] <mterry> then we could just install $session_name_badge names
[16:11] <ochosi> i think the advantage is not having to check in the code for all alternatives
[16:11] <ochosi> simply symlink files
[16:11] <ochosi> and have a very lean code for loading icons from_icon_name
[16:12] <ochosi> mterry: can you actually make use of the recoloring effect of symbolic svgs in unity-greeter like in gtk3?
[16:14] <mterry> ochosi, what do you mean check in the code for all alternatives?
[16:15] <mterry> ochosi, and what would we want to recolor?
[16:15] <ochosi> mterry: well in the gtk-greeter's case, the icons are recolored automatically according to the gtk-theme (they're basically like font)
[16:16] <ochosi> mterry: and the other thing i meant is checking for all kinds of session names with gnome* and force them to use the gnome-badge
[16:18] <mterry> ochosi, oh, sure.  That's a thing we could do regardless of where we put the icons
[16:18] <ochosi> mterry: yup
[16:19] <ochosi> mterry: actually i've become less sure (while talking to you) whether we can really share the icons in the true sense, cause we can never rely on both greeters being available. so the only thing i can do is offer you the svgs i created
[16:20] <ochosi> mterry: but i suppose those won't make you very happy, cause they're 16px and not all of them are circular (as you mentioned)
[16:20] <mterry> ochosi, we'd have to move the files to unity-icon-theme or some such which the two greeters could depend on
[16:20] <mterry> ochosi, 16px wouldn't matter so much if they are svg
[16:20] <mterry> ochosi, but circle would matter for unity-greeter's purposes
[16:20] <ochosi> mterry: yeah, but i dunno if we can force all desktops to depend on unity-icon-theme
[16:20] <ochosi> redrawing them to be circular could be doable
[16:21] <ochosi> (apart from kde and gnome, they all are already circular)
[16:21] <ochosi> (well, and recovery console)
[16:31] <pitti> seb128: so gnome-clocks will need a sourceful update for new libgweather, I'll look into that (probably just updating to 3.10)
[16:31] <pitti> seb128: you'll still do e-d-s?
[16:31] <seb128> pitti, yes, I didn't do it yet because of the "stop the line" from the touch guys, I don't want to risk creating another issue and having didrocks & co on my back ;-)
[16:32] <pitti> ack
[16:32]  * didrocks has his sniper gun around
[16:32] <pitti> seb128: gnome-panel was already uploaded, gnome-clocks doesn't affect mobile, so I'll start there
[16:32]  * pitti raises shields to maximum
[16:32] <didrocks> ahah ;)
[16:33] <seb128> pitti, danke, hopefully the block is lifted tomorrow and I can upload e-d-s
[16:36] <mterry> ochosi, well, my point is that it wouldn't be all desktops.  Only ones that want the unity-style icons for sessions.  Actual high color versions could be installed in hicolor.  Or kde-styled ones in the kde theme.  Etc
[16:38] <desrt> Laney: ya... i see a couple of things wrong indeed
[16:43] <pitti> seb128: evolution itself is safe, right? (but probably requires e-d-s first)
[16:43] <pitti> why does that need libgweather in the first place..
[16:44] <pitti> err, evolution's Vcs-Bzr: points to evolution-data-server
[16:44]  * pitti adjusts that to https://code.launchpad.net/~ubuntu-desktop/evolution/ubuntu
[16:45] <seb128> pitti, evolution is safe, not sure if it requires new e-d-s, those are only point releases
[16:45] <pitti> trying..
[16:45] <pitti> committed the Vcs-* fix
[16:46] <seb128> pitti, doing the point update? or just a no change rebuild?
[16:46] <pitti> seb128: as you wish
[16:46] <pitti> can do the point update, too
[16:46] <seb128> bonus point for the update? ;-)
[16:46] <seb128> danke!
[16:46] <pitti> doing
[16:48] <pitti> seb128: what was your magic URL again for "give me the Launchpad bug for gnome bug #XXXX"?
[16:48] <seb128> mdeslaur, ok, so the commit I wanted to backport for nautilus has a segfault issue, feel free to upload nautilus with your change ;-)
[16:49] <pitti> my firefox lost my shortcut for that
[16:49] <mdeslaur> seb128: ok, uploading
[16:49] <seb128> pitti, https://bugs.launchpad.net/bugs/bugtrackers/gnome-bugs/<nnn>
[16:49] <seb128> mdeslaur, thanks
[16:49] <pitti> seb128: merci
[16:49] <seb128> pitti, de rien
[16:57] <pitti> +m4_define([geocode_glib_minimum_version], [3.10])
[16:57] <pitti> seb128: meh, that's in universe
[16:57] <seb128> pitti, evolution as well
[16:58] <seb128> oh, no
[16:58] <seb128> still in main
[16:58] <pitti> seb128: that is evolution
[16:58] <seb128> hum
[16:58] <pitti> ah, you mean evolution is in universe
[16:58] <seb128> I though it was demoted yes
[16:58] <pitti> I'll file an MIR
[16:58] <seb128> danke
[16:59] <seb128> they added that depends in a point update?
[17:00] <Laney> srsly
[17:01] <Laney> mclasen did some testsuite changes
[17:01] <Laney> and now life is bad
[17:01] <pitti>         Bug 689055 - Port contact map to geocode-glib 3.10
[17:01] <ubot2> Launchpad bug 689055 in Baltix "Shotwell doesn't respect system locale time format" [Undecided,New] https://launchpad.net/bugs/689055
[17:01] <pitti>                      (Canek Peláez Valdés)
[17:01] <pitti> gnome bug 689055
[17:01] <ubot2> Gnome bug 689055 in general "Port contact map to geocode-glib 3.10" [Normal,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=689055
[17:01] <pitti> probably that?
[17:02] <pitti> hm, no, it was there before; so maybe introduced in 3.10.2 already
[17:02] <seb128> how did it build?
[17:02] <pitti> we have 3.10.1
[17:02] <seb128> ah
[17:02] <pitti> hm, wait
[17:03] <pitti> perhaps it was optional or so; but now it seems required
[17:03] <seb128> https://git.gnome.org/browse/evolution/commit/?h=gnome-3-10&id=7e05000fe5e763681272f1e88960a4ee61fa4b1c
[17:04] <pitti> Requested 'camel-1.2 >= 3.10.3' but version of camel is 3.10.1
[17:04] <pitti> Requested 'libebook-1.2 >= 3.10.3' but version of libebook is 3.10.1
[17:04] <pitti> Requested 'libecal-1.2 >= 3.10.3' but version of libecal is 3.10.1
[17:04] <pitti> Requested 'libedataserver-1.2 >= 3.10.3' but version of libedataserver is 3.10.1
[17:04] <pitti> Requested 'libebackend-1.2 >= 3.10.3' but version of libebackend is 3.10.1
[17:04] <pitti> seb128: ok, sorry, needs e-d-s first
[17:04] <seb128> pitti, no worry, I can have  a look tomorrow when I update e-d-s
[17:05] <pitti>         --disable-contact-maps \
[17:05] <pitti> ah, we have that, so we don't need geoclue-glib; sorry for the noise
[17:05] <seb128> pitti, it also mean I don't drag you into those geocode MIR issues
[17:05] <seb128> ah
[17:05] <seb128> that makes more sense
[17:06] <Sweetshark> seb128: xz is really broken somehow on armhf. Installing fonts-dejavu-core fails too in the pbuilder.
[17:06] <seb128> Sweetshark, or your pbuilder is screwed?
[17:07] <pitti> seb128: ok, I pushed the necessary build dep updates to the packaging bzr
[17:07] <Laney> desrt: I did a build with VERBOSE=1 and got http://paste.ubuntu.com/6763014/
[17:07] <Sweetshark> seb128: http://pastebin.ubuntu.com/6763028/
[17:07] <Sweetshark> seb128: well, pbuilder was created today from scratch.
[17:10] <desrt> Laney: try mclasen... all of these new tests are his :(
[17:10] <desrt> 11:41 <@mclasen> desrt: I didn't pay any attention to such fine details when writing that test...
[17:10] <desrt> 11:43 <@mclasen> but... it got my coverage up by a few percentiles - who cares about robustness when they can have  green in lcov !
[17:10] <Laney> that's reassuring
[17:10] <Laney> the asyncqueue one isn't what I was expecting ...
[17:11] <desrt> there are two obvious problems with that test
[17:11] <desrt> one is the mixing of realtime and monotonic clicks
[17:11] <desrt> *clocks
[17:11] <desrt> the other is placing an upper limit on how long the test takes to run
[17:11] <Laney> the whole "surely it's going to finish in this long" smells
[17:11] <desrt> too many times we've been burnt by that by getting swapped out on a busy builder box
[17:12] <larsu> 10 minutes ought to be enough for every builder box!
[17:12] <desrt> we need to get a rapberri pi with a swap partition on an SD card running the glib testsuite in a loop while building webkit
[17:12] <desrt> larsu: in this case 1 second...
[17:12] <Laney> but yeah, I was expecting it to be an assertion failure there
[17:12] <Laney> GLib (gthread-posix.c): Unexpected error from C library during 'pthread_cond_timedwait': Invalid argument.  Aborting.
[17:12] <Laney> not that
[17:12] <desrt> OH
[17:13] <desrt> nice ;)
[17:13] <desrt> how old is the kernel on that box?
[17:13] <Laney> umm
[17:13] <Laney> http://people.canonical.com/~laney/weird-things/buildlog_ubuntu-trusty-i386.glib2.0_2.39.3-0ubuntu2+laney1_FAILEDTOBUILD.txt.gz
[17:13]  * Laney feeds gedit more hamsters
[17:13] <desrt> uh
[17:14] <desrt> gedit just opened a pile of junk for me
[17:14] <Laney> same
[17:14] <Laney> wtf
[17:15] <desrt> anyway
[17:15] <desrt> Kernel version: Linux tipua 3.2.0-54-generic #82-Ubuntu SMP Tue Sep 10 20:08:42 UTC 2013 x86_64
[17:15] <desrt> not old enough for my theory
[17:15] <desrt> that kernel definitely has full support for monotonic clocks
[17:16] <desrt> so invalid argument could come if we give a bad timeval
[17:17] <Laney> not sure why he used a deprecated function there
[17:18] <desrt> we need to test deprecated code to make sure it still works
[17:18] <desrt> seb128 gets upset if we deprecate something and break it in the same cycle :)
[17:18] <Laney> I'd expect to see a test for the real one as well though ;-)
[17:18] <desrt> there is
[17:18] <desrt> it's in the same test, further up
[17:19] <desrt> mclasen expanded the test to also cover the deprecated versions
[17:19] <Laney> not timeout_pop_unlocked
[17:19] <desrt> right.  only timeout_pop
[17:19] <Laney> ya
[17:19] <Laney> anyway, let me go throw this link at him
[17:20] <desrt> i have a theory
[17:20] <Laney> may want to move over there now
[17:20] <Laney> ah, you did
[17:24] <Sweetshark> seb128: hmm, xz has a point. its kind hard to get memory on a pandaboard if there is a irqbalance process eating 863MB RES ...
[17:27] <Sweetshark> i would consider that not exactly optimal or 'works as expected' though too.
[17:30] <Sweetshark> "hey, im perfectly balancing the load of the threads that you cant start because there is no memory left over all the cores!"
[17:40] <ogra_> Sweetshark, uncompressing should be fine ...
[17:40] <ogra_> compressing is a pain
[17:44] <Sweetshark> ogra_: both ran OOMed here. and when I tried building libreoffice it OOMed when generating the fake dep-package. But even if that would have succeeded, I assume I would not have gone far with that memory ;)
[17:44] <ogra_> is that new ?
[17:45] <ogra_> i mean libO used to build on pandas in the past
[17:46] <Sweetshark> ogra_: the problem was the irqbalance process (outside the pbuilder) gone wild. I just killed it, problem ~solved.
[17:46] <ogra_> i dont get why thats running at all ... we never did that at my times
[17:47] <Sweetshark> ... well, except the mistery of why that process grew to use >800MB
[18:12] <Laney> omg
[18:12] <Laney> seb128: I made it scroll and click
[18:13] <seb128> Laney, nice, did you use click_element()?
[18:13] <Laney> what is that?
[18:13] <Laney> guess not ¬_¬
[18:13] <seb128> (that's what the SDK guys recommended me to use)
[18:14] <Laney> do you mean click_object?
[18:14] <seb128> it's an API that knows to scroll in a listview if needed
[18:14] <seb128> Laney, http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/tests/autopilot/ubuntuuitoolkit/tests/test_emulators.py#L660
[18:14] <seb128> Laney, rather than move() and click()
[18:14] <Laney> no I didn't know about that, only click_object
[18:14] <seb128> k
[18:14] <Laney> let me see if that works
[18:15] <seb128> sorry, that's what I meant when I said "I've things to try on my todolist"
[18:15] <seb128> I would have given you the specific if I understood you were going to look at it again
[18:15] <seb128> that works for lists
[18:15] <Laney> oh it's not a listview
[18:16] <seb128> right, that's what I was going to say
[18:16] <seb128> not sure if there are similar api for other layouts
[18:16] <seb128> that should work in e.g the storage panel (that's a list iirc)
[18:18] <Laney> yup
[18:18] <Laney> can look at that tomorrow
[18:18] <Laney> I just got bored of building glib so wanted to do something that was a bit different
[18:19] <seb128> thanks for looking at that ;-)
[18:19] <seb128> I've it on my list for some days but I keep getting distracted/have too many other things on my todolist
[18:22] <Laney> it's going to take absolutely ages to scroll to each page like this
[18:23] <seb128> how so?
[18:23] <Laney> load u-s-s
[18:23] <seb128> writing the code? or is autopilot slow?
[18:23] <Laney> scroll to about ...
[18:23] <Laney> scroll down to storage
[18:23] <Laney> times the number of tests
[18:23] <seb128> do we need to close/restart between each test?
[18:23] <Laney> I'll probably make them just launch to the about panel straight away
[18:23] <seb128> we could maybe pop/push the page?
[18:23] <Laney> ap wants to do that
[18:24] <seb128> mterry, hey, are robert_ancell or you looking at the unity-greeter ftbfs in trusty? (just pointing it out in case it's not a known issue)
[18:24] <Laney> yay, all of the 'about' tests passed
[18:24] <Laney> including storage
[18:24] <seb128> mterry, it was failing on ppc64el which I assumed was an issue on the arch, but the test rebuild from doko shows the same issue on other archs
[18:24] <seb128> Laney, \o/
[18:25] <mterry> seb128, I think I just fixed that yesterday.  Failed in tests?
[18:25] <seb128> yes
[18:25] <Laney> will mp that tomorrow
[18:25] <Laney> killzone time ;-)
[18:25] <seb128> mterry, https://launchpadlibrarian.net/162156570/buildlog_ubuntu-trusty-i386.unity-greeter_14.04.1-0ubuntu2_FAILEDTOBUILD.txt.gz
[18:25] <seb128> (./unity-greeter-test:5239): Gdk-WARNING **: losing last reference to undestroyed window
[18:25] <mterry> seb128, yup.  Fixed in trunk...
[18:25] <seb128> mterry, upload! ;-)
[18:25] <mterry> seb128, I should get a new 14.04 logo too though...
[18:26] <mterry> seb128, is it urgent?
[18:26] <seb128> mterry, no
[18:26] <seb128> mterry, I mostly noticed because the build failure on ppc64el makes the gtk greeter shows on component mismatch
[18:26] <Laney> build failures should be fixed in the archive really imo
[18:26] <Laney> doko will ping you before long anyway :P
[18:26] <seb128> yeah
[18:26] <seb128> they should
[18:26] <seb128> but that can wait a few days
[18:39] <seb128> attente, indicator-keyboard fails to build in trusty, could you have a look?
[18:39] <czajkowski> Sweetshark: https://joinup.ec.europa.eu/community/osor/news/advocacy-governments-should-choose-odf
[18:39] <seb128> attente, one fails and there is an output "Source ID 16 was not found when attempting to remove it" (which is a new glib warning on invalid g_source_remove() use)
[18:39] <seb128> attente, one *test* fails
[18:39] <seb128> I guess that's the issue
[18:40] <Sweetshark> czajkowski: thx, im somewhat following Gijs. Will you be at fosdem btw?
[18:45] <czajkowski> Sweetshark: hell yeah :D
[18:45] <czajkowski> I really like Gijs articles
[18:45] <czajkowski> some good ones recently
[18:45] <czajkowski> wil be in the NoSQL room on sunday
[18:46] <czajkowski> will have cupcakes :)
[18:46] <attente> seb128, ok
[18:54] <Sweetshark> czajkowski: hmm, cupcakes!1!one!eleven
[18:54] <Sweetshark> czajkowski: will consider to drop by ;)
[19:25] <davmor2> chrisccoulson: https://bugs.launchpad.net/ubuntu-keyboard/+bug/1269912 possible use case for oxide :)
[19:25] <ubot2> Launchpad bug 1269912 in webbrowser-app "maliit not triggered in maps.google.com" [Undecided,New]