[04:36] <m4n1sh> mpt: the privacy panel in system settings is done, but the diagnostics is broken since the package names etc have changed and the whole diagnostic daemon named have been changed, which breaks the build. Any suggestions? That is the only thing stopping your design from going live!
[05:50] <pitti> Good morning
[06:57] <didrocks> good morning
[07:35] <pitti> bonjour didrocks
[07:35] <didrocks> guten morgen pitti
[08:48] <didrocks> hum, is it expected that we no more have "apply systemwide" in the proxy settings?
[08:52] <seb128> didrocks, known bug, patches are welcome ;-)
[08:53] <didrocks> seb128: but it's still applied to the existing user?
[08:53] <seb128> "bug", the capplet got rewritten upstream
[08:53] <seb128> so the patch didn't apply
[08:53] <seb128> and didn't get ported
[08:53] <seb128> didrocks, right, the proxy settings work
[08:53] <seb128> but they are written in gsettings
[08:53] <didrocks> ok
[08:53] <seb128> e.g that's not enough for apt and such
[08:53] <didrocks> not system wide
[08:56] <seb128> didrocks, no
[08:56] <seb128> the current capplet is user settings
[08:56] <seb128> like theme, etc
[08:57] <didrocks> I got it, it's only applied for the user and no root/system settings or apps that don't read GNOME properties
[08:59] <seb128> didrocks, right, which sucks
[08:59] <seb128> we should get that patch back
[08:59] <seb128> ideally upstream if possible
[08:59] <didrocks> yeah, that's not rolling-release like :)
[08:59] <seb128> or at least get the "set proxy" in systemd-service
[09:00] <seb128> will try to see if dsrt wants to do that
[09:00] <Laney> morning
[09:00] <seb128> Laney, hey, how are you?
[09:00] <didrocks> thanks seb128
[09:00] <didrocks> hey Laney
[09:01] <Laney> good thank you
[09:01] <Laney> you?
[09:02] <seb128> good as well ;-)
[09:03] <Laney> back to normality ;-)
[09:37] <seb128> Laney, yeah, "normality", which means "deal with ton of backlog"
[09:38] <seb128> Laney, the Ubuntu didn't stop as much during vUDS that it does during real UDS
[09:39] <seb128> today is backlog's day ;-)
[09:51] <chrisccoulson> hmmm, had a complete monitor configuration fail just now
[09:51] <chrisccoulson> for the first time in ages!
[09:52] <seb128> chrisccoulson, hey, how are you?
[09:52] <seb128> chrisccoulson, what did you do? docked your laptop?
[09:52] <chrisccoulson> hi seb128. i'm good thanks. how are you?
[09:52] <seb128> chrisccoulson, I'm good thanks
[09:52] <chrisccoulson> seb128, yeah, i docked my laptop. normally it gets the configuration right every time (non-mirrored, laptop screen on the left)
[09:52] <seb128> chrisccoulson, weird to see you with some beard btw ;-)
[09:52] <chrisccoulson> but this morning i got a mirrored display, and the resolution was not the optimal one for either screen
[09:53] <chrisccoulson> hah
[09:53] <chrisccoulson> that's what i look like most of the time ;)
[09:53]  * seb128 watches the webkit session yesterday evening
[09:53] <seb128> watched even
[09:53] <chrisccoulson> i'm really liking this now: https://jenkins.qa.ubuntu.com/job/raring-ppa-adt-ubuntu_mozilla_daily_ppa-firefox-trunk/70/
[09:54] <chrisccoulson> it shows me the new failures :)
[09:57] <seb128> chrisccoulson, nice ... you have red on there!
[09:57] <seb128>  36,478 tests
[09:57] <chrisccoulson> seb128, yeah, most of those will be fixed in the next run
[09:57] <seb128> 26 fails
[09:57] <seb128> that's quite good
[09:57] <chrisccoulson> not sure about https://jenkins.qa.ubuntu.com/job/raring-ppa-adt-ubuntu_mozilla_daily_ppa-firefox-trunk/70/ARCH=i386,label=adt/testReport/junit/services.common.tests/unit/test_storage_server_js/ though
[09:58] <chrisccoulson> and https://jenkins.qa.ubuntu.com/job/raring-ppa-adt-ubuntu_mozilla_daily_ppa-firefox-trunk/70/ARCH=amd64,label=adt/testReport/layout.xul.base.src/crashtests/395609_xul/ fails because it needs network access
[10:50] <dholbach> heya
[10:50] <dholbach> where does deja-dup write logs to?
[10:50] <dholbach> when I backup the title says "backup failed" and the text on the dialog says "success"
[10:51] <seb128> dholbach, hey, open a bug against deja-dup with a screenshot or wait for mterry to be there and ping him directly ;-)
[10:51] <dholbach> will do
[10:58] <mpt> m4n1sh, excellent! I'm not an expert on the Apport internals, but Evan Dandrea (ev in #ubuntu-devel) knows all about it.
[10:58] <dholbach> seb128, done
[10:58] <seb128> dholbach, thanks
[12:26] <xnox> Laney: bug 1142751 *sigh*
[12:26] <ubot2`> Launchpad bug 1142751 in ubiquity "Webcam screen broken during installation" [Undecided,New] https://launchpad.net/bugs/1142751
[12:27] <xnox> see the screenshot there.
[12:27] <pitti> look! one embarrassing hack later I have logind working with polkit, automatic ACLs, lightdm, etc.
[12:28] <Laney> xnox: oho
[12:29] <Laney> can you get stderr output to see if gstreamer gives any errors/warnings?
[12:29] <Laney> give the user instructions to get^
[12:31] <seb128> pitti, \o/
[12:31] <seb128> Laney, xnox: wasn't the plan to drop webcam support in ubiquity this cycle?
[12:32] <Laney> not sure what the timescale for that is
[12:35] <tjaalton> cheese is just as broken, so it's a gstreamer bug then?
[12:36] <tjaalton> or libcogl
[12:36] <xnox> tjaalton: well i've asked the reporter to try cheese.
[12:36] <xnox> Laney: the bug was not filed with debug output, let me ask that as well.
[12:36] <tjaalton> cheese works for you?
[12:36]  * xnox trying
[12:37] <xnox> seb128: it could be a bug in gstreamer/stack.
[12:37] <xnox> seb128: Laney: there is a proposal to drop it, but we are not dropping webcam support from whole ubuntu, right?!
[12:37] <Laney> indeed
[12:38] <xnox> (it, being the page in the ubiquity)
[12:38] <xnox> Laney: seb128: if it's removed from ubiquity, i'd love to add it to checkbox or something like that as an optional test.
[12:38] <seb128> xnox, sorry I restarted and don't have the backlog so I lack context, I was speaking specifically about ubiquity, if it's a gstreamer bug we should fix it yes
[12:38] <xnox> to catch regressions.
[12:38] <tjaalton> xnox: bug 1101951
[12:38] <ubot2`> Launchpad bug 1101951 in Cheese "Webcam with cheese not working - shader fails to compile" [High,Confirmed] https://launchpad.net/bugs/1101951
[12:39] <xnox> seb128: well you can read irclogs.ubuntu.com =) but yeah, basically we are investigating a regression condition.
[12:39] <xnox> potential, one.
[12:39] <seb128> xnox, can -> will be able to, it takes some time to update :p
[12:39] <seb128> xnox, k, thanks, I'm stepping out and letting you guys deal with the issue ;-)
[12:40] <xnox> seb128: =)
[12:41] <Laney> so yeah, could be a cogl/driver thing
[12:43] <chrisccoulson> who do i talk to in jibel's absence this week?
[12:43] <chrisccoulson> i'd like to get the firefox tests running on other releases as well, now, as well as enabling the job for the other PPA's
[12:44] <xnox> tjaalton: yeap, cheese fails for me. Google shows that it could be a programming error e.g. http://www.geeks3d.com/20101002/tips-how-to-quickly-test-glsl-shaders-for-ati-on-a-nvidia-system/
[12:44] <xnox> but I am on intel.....
[12:44] <Laney> do you get that same message?
[12:45] <tjaalton> intel here too
[12:45] <xnox> http://paste.ubuntu.com/5593015/
[12:46] <tjaalton> yep
[12:46] <xnox> tjaalton: shouldn't that be protected with "#ifdef GL_ES\n" ?
[12:47]  * xnox would have thought that I have GL_ES support though.....
[12:49] <tjaalton> dunno
[12:51]  * xnox cheated and did codesearch.debian.net and "precission..." is always protected with GL_ES in firefox/qt-x11/etc
[12:53] <mitya57> Laney: why not updating gnome-keyring to 3.7.91? there were some quite important fixes there...
[12:54] <mitya57> like https://git.gnome.org/browse/gnome-keyring/commit/?id=ddb87ccad9
[12:54] <mitya57> and https://git.gnome.org/browse/gnome-keyring/commit/?id=c90a1cca64
[12:54] <Laney> we're not taking 3.8
[12:54] <Laney> but commits can be backported as usual
[12:57] <mitya57> Laney: I don't see any new features/dependencies, so it probably be taken safely
[12:58] <mitya57> *can be taken
[12:58] <seb128> mitya57, do we have any user visible bug report that would be fixed by those commits?
[12:58] <Laney> how much testing have you done?
[12:59] <mitya57> seb128: https://git.gnome.org/browse/gnome-keyring/commit/?id=c90a1cca64 fixes python-secretstorage test suite :)
[12:59] <mitya57> I didn't mention it above ^^
[12:59] <mitya57> and also python-keyring test suite
[12:59] <mitya57> Laney: I'm using the git snapshot for 3 or 4 days
[13:00] <mitya57> If you need bug reports, all three commits are linked to bugs in GNOME bugzilla :)
[13:03] <seb128> we might update to 3.8 once it's out if we go rolling
[13:03] <seb128> otherwise that will probably not be for raring
[13:05] <mitya57> ok...
[13:06] <Laney> xnox: after lunch I'll upgrade clutter-gst-2.0 to the newest release which changes that shader code
[13:06] <Laney> perhaps it'll help
[13:07] <Laney> ref comment #14 in the gnome bug
[13:09] <xnox> "Cogl 1.10 introduced new boilerplate for shaders. This commit cleans up our shaders." that commit removed the offending precission line.
[13:09] <Laney> mitya57: feel free to ask for sponsorship for important cherry-picks like that testfix one
[13:09] <Laney> xnox: yeah, indeed
[13:09] <BigWhale> Is there an #ubuntu-legal for asking those kind of questions? :)
[13:09] <Laney> the hope is there
[13:09]  * Laney → lunch, back in some time (going to the city centre)
[13:10] <xnox> BigWhale: hm?
[13:11] <BigWhale> When I'm collecting debug information for Kazam, I also record information about user home directory path and the location of where Kazam is recording files. Is this something I should let the user know?
[13:12] <BigWhale> DEBUG Utils - Video folder set to: /home/bigwhale/Videos
[13:12] <BigWhale> DEBUG Utils - Picture folder set to: /home/bigwhale/Pictures
[13:12] <BigWhale> These are the lines in question.
[13:12] <BigWhale> There are probably more.
[13:13] <BigWhale> So, someone might be recording picures to /home/joe/my_secret_evil_plan_to_take_over_the_world/pics/
[13:15] <seb128> BigWhale, no need to warn the user about that I think, but why do you need those directories?
[13:16] <xnox> BigWhale: what do you mean by "collecting" is it in the logs? or are they automatically emailed to you?
[13:17] <xnox> BigWhale: there is all sorts of information like that in the logs, and when users upload it to launchpad they have an option to make bugs private and/or editting the logs when sharing those.
[13:17] <BigWhale> It's in the logs if user runs kazam with --debug
[13:17] <BigWhale> seb128, well with --debug I dump a ton of information on screen.
[13:18] <BigWhale> and I had soe problems with XDG so I added these lines.
[13:19] <xnox> BigWhale: as long as those are not automatically uploaded anywhere, you are ok.
[13:19] <xnox> BigWhale: as user is in control of their own log files.
[13:19] <seb128> well
[13:19] <seb128> we do collect such infos with apport
[13:19] <seb128> but we try to anonymise things
[13:19] <seb128> like username and dirs
[13:20] <seb128> BigWhale, do you need the names of the dirs? or only their permissions for example?.
[13:20] <xnox> seb128: but those are not shared outside to people without privacy agreements signed by canonical.
[13:20] <xnox> ;-)
[13:20] <xnox> mostly.
[13:20] <xnox> BigWhale: does kazam have apport hooks at the moment?
[13:21] <BigWhale> yes, but this is not logged anywhere it is just dumped on the screen.
[13:21] <xnox> BigWhale: it's totally fine then =)
[13:38] <BigWhale> Ok, thanks for the advice guys.
[14:18] <seb128> desrt, hey
[14:21] <seb128> pitti, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1152187
[14:21] <ubot2`> Launchpad bug 1152187 in systemd "[MIR] systemd" [Undecided,New]
[14:21] <seb128> just for info ;-)
[14:21] <pitti> \o/
[14:22] <pitti> url 1
[14:22] <pitti> oops
[14:22] <pitti> subscribed
[14:23] <seb128> pitti, danke
[14:23] <seb128> pitti, would be good to update our package, logind has a CVE in 44 (I didn't check if it's distro patched)
[14:23] <pitti> seb128: https://launchpad.net/~ubuntu-core-dev/+archive/logind FYI
[14:23] <pitti> seb128: yeah, updating to 198 is on my TODO list
[14:24] <seb128> pitti, is that the current one? be careful, lennart dropped support for distro specific config files recently
[14:24] <seb128> like /etc/default/locale
[14:24] <desrt> seb128: good morning!
[14:24] <pitti> seb128: yes I know, we'll patch it back in (mbiebl already did)
[14:24] <seb128> great
[14:24] <pitti> bonjour desrt
[14:25] <seb128> desrt, hey, you missed the logind session at vUDS
[14:25] <desrt> i know.  i intended not to go.
[14:25] <desrt> i don't really have any opinion on the topic other than 'yes'
[14:26] <pitti> desrt: oh, there was no debate about the "yes", it was about the "how"
[14:26] <desrt> pitti: ya.  that's the part i don't know anything about :)
[14:26] <pitti> $ pidof console-kit-daemon
[14:26] <pitti> $
[14:26] <pitti> :-)
[14:27] <pitti> and I have ACLs, polkit, etc. working
[14:27] <pitti> I'll run this for some time and check for things that are broken
[14:29] <seb128> desrt, ok, I had you invited because I though you talked to Lennart about running logind without systemd-pid1 and that he recommended against it
[14:29] <seb128> desrt, I was unsure if you had specifics on why
[14:29] <desrt> no
[14:29] <desrt> he just said we'll make our lives difficult
[14:29] <pitti> I found about the "why" the hard way today
[14:29] <seb128> desrt, anyway it seems we had enough people to have a good decisions and pitti already moved along with the ppa ;-)
[14:29] <desrt> but i don't know if that was any more true than when he usually tells us "you will make your life difficult by not having systemd"
[14:30] <pitti> he's right that logind's API doesn't work OOTB without systemd, as it queries cgroups (which we don't manage)
[14:30] <pitti> so I added some cheesy hackery; that needs a security review first, too
[14:30] <pitti> but I wanted to see first how many obstacles there are
[14:51] <pitti> seb128: annoying -- osageorange seems to have stopped sending us cron mail on retracer failures :(
[14:54] <seb128> pitti, right, seems like we missed a few retracers down time recently
[14:56]  * Sweetshark cant help but think "we live in interesting times" reading his inbox ...
[14:56] <kenvandine> dpm, can you point me at an example package that builds QML API docs for developer.ubuntu.com ?
[15:43] <Laney> xnox: care to try http://people.canonical.com/~laney/clutter-gst-2.0/ ?
[15:44] <xnox> Laney: right in a moment.
[15:44] <Laney> merci mon ami
[15:46] <mdeslaur> seb128: nautilus doesn't seem to be saving the view per directory anymore...is that a known issue?
[15:50] <xnox> Laney: works like a charm =) deploy the fix!
[15:53] <Laney> SHIP. IT.
[15:53] <mdeslaur> seb128: PoS...I opened #1152226
[15:57] <mdeslaur> seb128: can we please revert to a sane version of nautilus now? pretty please? :)
[15:59] <mitya57> sane = 3.4?
[15:59] <Laney> 3.8? :)
[16:00] <mitya57> yes, let's *revert* to 3.8 :)
[16:01] <mdeslaur> to a version that doesn't have the retarded split menus, and one that actually has views that work :)
[16:01] <mdeslaur> I'm sure there's a few other things that are missed by others :P
[16:11] <kenvandine> seb128, can you look at dee-qt in sourceNEW too?
[16:11] <kenvandine> seb128, it's a source package rename
[16:11] <kenvandine> from libqtdee
[16:12]  * didrocks announced 200 daily releases on ubuntu-unity, and we didn't break ubuntu (yet)! :)
[16:13] <kenvandine> didrocks, woot!
[16:13] <didrocks> kenvandine: maybe you want to be the first one with friends to break with daily? :-p
[16:13] <kenvandine> haha... that sounds like a challenge!
[16:13] <didrocks> robru: unique window of opportunity there ^
[16:13] <didrocks> :)
[16:14] <jbicha> mdeslaur: views work here :) as far as the menus go that's bug 1130722
[16:14] <ubot2`> Launchpad bug 1130722 in nautilus (Ubuntu) "Change nautilus menu layout in Unity back to the style of 3.4" [Medium,Triaged] https://launchpad.net/bugs/1130722
[16:16] <mdeslaur> jbicha: sorry, views get reset on my laptop, in my vm, and on my test machine...not sure how they are being remembered for you
[16:16] <jbicha> 3.8 brings a modified tree navigation to the list view
[16:16] <GunnarHj> Riddell: ping
[16:16] <jbicha> mdeslaur: do you mean the zoom level?
[16:17] <mdeslaur> jbicha: LP: #1152226
[16:17] <ubot2`> Launchpad bug 1152226 in nautilus (Ubuntu) "nautilus no longer remembers view per directory" [Undecided,New] https://launchpad.net/bugs/1152226
[16:18] <jbicha> mdeslaur: yeah that's a feature, view settings are global now but you can set the default in Nautilus>Preferences>Views
[16:18] <mdeslaur> jbicha: wait, that's a _feature_?
[16:19] <mdeslaur> jbicha: ok, if it's a feature, then that's one more reason to go back to 3.4
[16:20] <jbicha> the GNOME bug wasn't closed though so maybe they'd accept a patch to make that optional but I think global by default isn't a bad idea
[16:20] <mdeslaur> jbicha: of course you don't :P
[16:20] <jbicha> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692830
[16:20] <ubot2`> Debian bug 692830 in wnpp "ITP: nemo -- File manager for cinnamon" [Wishlist,Open]
[16:22] <desrt> GunnarHj: hey.  looking at https://live.gnome.org/Design/SystemSettings/RegionAndLanguage/ChangeProposals and https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-deprecate-language-selector
[16:22] <desrt> GunnarHj: what can you tell me about the current state of things?  has anyone done any work?
[16:23] <jbicha> except for the menu split confusion, I think Nautilus 3.6+ is much more usable for average users and I don't think we're really considering forking Nautilus 3.4
[16:23] <jbicha> anyway, isn't somebody supposed to be doing some qml app thing for that eventually?
[16:24] <mdeslaur> jbicha: I disagree, I think the new nautilus is harder to use for most users. Yeah, a new qml file manager would be nice.
[16:26] <GunnarHj> desrt: The switch language-selector -> g-c-c region is postponed. The reason is that g-c-c 3.6 has issues with the im things, so we are basically using g-c-c 3.4 in 13.04. The code for langpack handling hasn't been written yet, since we don't want to base it on 3.4.
[16:27] <desrt> GunnarHj: i was thinking that a good way to get around this issue would be to hide/disable/remove the keyboard subtab of the region panel for now
[16:27] <desrt> and keep our separate 'keyboard layout' panel
[16:27] <desrt> seems weird to have such an easy-to-workaround thing block the more important work of killing l-s
[16:28] <GunnarHj> desrt: Yeah, but the separate keyboard layout is actually the old GNOME tab.
[16:28] <desrt> i know
[16:28] <desrt> we can keep that status quo for now
[16:28] <GunnarHj> desrt: But the critical thing is to deal with the langpack handling.
[16:28] <desrt> ya.  we'd need to at least add an 'add/remove' button to open the current dialog that l-s has
[16:28] <Riddell> GunnarHj: hi
[16:29] <desrt> and probably modify it so that the 'short list' in the UI is not the way that GNOME uses to pick it but rather all installed language packs
[16:29] <GunnarHj> desrt: Yes.
[16:29] <desrt> mpt: actually... i just realise that this is sort of a bad idea
[16:29] <GunnarHj> Riddell: Hi Jonathan!
[16:29] <desrt> mpt: you give the example of india where the vendor/admin/whatever will want to install all of the indian national languages and have these appear in the list
[16:29] <desrt> what about the case that i have language-pack-en installed?
[16:30] <GunnarHj> Riddell: Wonder if you noticed https://code.launchpad.net/~gunnarhj/ubuntu-seeds/kubuntu.raring/+merge/151132 ?
[16:30] <desrt> do i really want to have 20 items in my list for English (US), (UK), (Canada), (Australia), (New Zealand), (Hong Kong), (Denmark), (...
[16:30] <desrt> and expect to rank those?
[16:30] <Riddell> GunnarHj: mm no, thanks for the ping
[16:31] <GunnarHj> Riddell: The other flavours have made that switch by now.
[16:31] <Riddell> GunnarHj: presumably it's a no brainer can but can remind me again the differences?
[16:32] <GunnarHj> Riddell: im-switch is deprecated and no longer maintained.
[16:32] <GunnarHj> Riddell: Basically they do the same things.
[16:32] <seb128> re
[16:32] <seb128> mdeslaur, yeah, I'm annoyed at nautilus as well
[16:33] <Riddell> GunnarHj: thanks, I'll get Quintasan to do it as he's been looking into input methods recently
[16:33] <GunnarHj> Riddell: There is a simple interface in language-selector, and in language-selector-gnome I changed it to fit im-config. Don't know how you handle the im part now.
[16:34] <Riddell> GunnarHj: no very much :(
[16:34] <GunnarHj> Riddell: Great, then I know that someone looks into it.
[16:35] <seb128> kenvandine, dee-qt NEWed
[16:35] <kenvandine> thanks
[16:35] <seb128> jbicha, hey, btw why wouldn't the new document stuff work in 3.8? did they keep breaking more stuff?
[16:35] <seb128> mdeslaur, I start pondering going back to nautilus 3.4 as well...
[16:37] <mdeslaur> seb128: we could just rename it and use the renamed one in unity, that would allow the gnome folks to get their recent version
[16:37] <seb128> mdeslaur, I was reluctant to do that because of
[16:37] <seb128> 1- things that depends on nautilus >= version
[16:37] <jbicha> seb128: they want to use an actual file in ~/Templates for consistency https://git.gnome.org/browse/nautilus/commit/?id=9323d
[16:37] <seb128> 2- the conflcit
[16:38] <seb128> 3- the fact that there is a public lib
[16:38] <seb128> used by e.g u1
[16:38] <seb128> if the ABI changes that will make life hard for those
[16:38] <mpt> desrt, can you think of a case where you would want to interleave variants of different languages?
[16:39] <seb128> jbicha, k, I'm glad we decided to stay on 3.6, avoiding extra issues this cycle (in fact it would have been wiser to stay on 3.4 but it's late for that)
[16:39] <mpt> desrt, if not, variants could be rearrangable within expanded branches of a treeview, but most people would just rearrange the overall languages being rearrangable as branches.
[16:41] <desrt> mpt: this is starting to sound ugly
[16:41] <desrt> it's also evil from a technical standpoint
[16:41] <seb128> mdeslaur, we could have both while the lib abi is compatible though
[16:41] <desrt> let's say i'm seb
[16:41] <desrt> probably i want fr_FR
[16:42] <desrt> but not fr_CA and all of the other fr_ things
[16:42] <desrt> but this entire list will end up in my LANGUAGES= variable, by your proposal
[16:42] <mdeslaur> seb128: do you have a list of stuff that uses the lib?
[16:42] <seb128> mdeslaur, rdepends libnautilus-extension1a?
[16:43] <mdeslaur> seb128: thanks
[16:43] <desrt> having a LANGUAGES variable with 17 items in it is ... not good
[16:43] <seb128> mdeslaur, those are stuff that either add entries in the nautilus menus, or a tab to the properties, or a submenu
[16:43] <desrt> (which, btw, is the number of english variants)
[16:43] <seb128> mdeslaur, e.g file-roller add unpack archive stuff
[16:44] <mdeslaur> hrm, yeah...that's an important one
[16:45] <marrusl> hey..  i have a question about old gnome libraries: libgnome-desktop-2-17 and libgnomeprint (and printui).  Can one safely assume they'll at least be in the archives (if not main) for the foreseeable future?
[16:45] <mpt> desrt, yes, I'm assuming that if fr_CA is the only fr_ available, that's still better than en
[16:46] <desrt> mpt: but in reality, there is 'fr' available always
[16:47] <desrt> the real reason we have fr_FR, fr_CA, fr_BE, fr_CH, and a dozen others is different locale settings
[16:47] <desrt> and the occasional translation tweak
[16:47] <desrt> but 'fr.po' is 99% of the time the only one
[16:49] <desrt> on my system right now i have 242 mo files from 'fr' and not a single one from one of the variants
[16:49] <desrt> and no matter which variant i select, it will end up using 'fr'
[16:50] <mpt> desrt, so what's the problem then?
[16:51] <desrt> mpt: the problem is that, under your proposal there is no way to tell apart user intention of "i want french french followed by canadian french followed by belgian french followed by swiss french followed by..." and "i just want french damnit, why is this expander widget here?"
[16:53] <GunnarHj> desrt, mpt: Your discussion makes me curious.
[16:54] <GunnarHj> desrt, mpt: The GNOME way to make the lists is based on the fact that they have it all installed to start with.
[16:54] <desrt> which is a remarkably sane way to deal with variants....
[16:54] <GunnarHj> desrt, mpt: In Ubuntu we show the installed langpacks (basically).
[16:55] <GunnarHj> I think it's important to not expose the users to long list of locales.
[16:58] <GunnarHj> The purpose with a language list should be to make it possible for users to choose between available _translations_. That's how we currently do it in Ubuntu, and I hope we'll keep doing so after the switch to g-c-c region.
[16:59] <GunnarHj> translation != langpack != locale
[16:59] <desrt> GunnarHj: the problem is that the idea of translation is poorly defined
[16:59] <desrt> particularly in the presence of language packs
[17:01] <GunnarHj> desrt: We have a definition via /usr/share/language-tools/language-options
[17:01] <GunnarHj> desrt: If you run that script, you get the _translations_ on your box.
[17:03] <GunnarHj> desrt: It gives you e.g. en_GB and en_US but not the huge list of English locales.
[17:04] <chrisccoulson> i've decided that anybody who chooses to work on a JS engine is insane
[17:05] <didrocks> chrisccoulson: oh, that's what the V8 guys are telling :)
[17:05] <GunnarHj> desrt: What was the problem that you and mpt were originally discussing?
[17:05] <chrisccoulson> didrocks, i swear, i'm going to be a V8 expert by the end of the week ;)
[17:06] <didrocks> chrisccoulson: hum, I watch a lot of V8 videos, I doubt being an expert in a week is possible though :p
[17:06] <chrisccoulson> heh
[17:07] <seb128> chrisccoulson, seems like didrocks wants to take over debugging v8 for you? ;-)
[17:07] <chrisccoulson> seb128, hah
[17:08] <chrisccoulson> didrocks, you're more than welcome too ;)
[17:08] <didrocks> chrisccoulson: only if it's the second step of optimization which is involved!
[17:08] <didrocks> I don't care about the first one :p
[17:10] <ogra_> seb128, yo .... how much does the desktop team use pandaboards ? TI killed them and we might not get new X drivers so i'm wondering if we could kill the desktop images on them (keeping server for buildd support though)
[17:11] <desrt> GunnarHj: i still get a list that's too long
[17:12] <desrt> en, en_CA, en_AU, en_GB, en_NZ, en_US
[17:13] <chrisccoulson> ogra_, i use mine a lot (although, with 12.04)
[17:13] <chrisccoulson> i guess i could live without new images ;)
[17:13] <GunnarHj> desrt: That's because those directories exist in /usr/share/locale-langpack
[17:13] <desrt> en_US@piglatin
[17:13] <desrt> lol.
[17:14] <GunnarHj> desrt: But that's excluded since there is no matching locale.
[17:14] <desrt> en@shaw
[17:14] <desrt> nice.
[17:14] <chrisccoulson> didrocks, it's what comes out of the JIT that i'm debugging ;)
[17:15] <GunnarHj> desrt: If we want a shorter list, I suppose that somebody should reconsider the contents of the English langpack.
[17:15] <chrisccoulson> i've even stopped shaving so that i fit the stereotype
[17:15] <seb128> ogra_, hey
[17:15] <desrt> i think the solution is to have a three-tiered system
[17:15] <seb128> ogra_, I'm sure half the team don't use them, especially since we have the nexus which are nice arm builders
[17:16] <desrt> "in use on this system" vs. "installed" vs. "can be installed"
[17:16] <didrocks> chrisccoulson: pfff, first step then, too easy (phew, I'm safe \o/)
[17:16] <seb128> ogra_, but some people do (e.g chrisccoulson and qengho to build/debug chromium)
[17:16] <chrisccoulson> seb128, how much storage do these n7's have then?
[17:16] <GunnarHj> desrt: Wouldn't that make it more complicated?
[17:16] <chrisccoulson> if it's 8GB, then i can't use it to build firefox or chrome :/
[17:17] <chrisccoulson> so if people have spare pandaboards............ ;)
[17:17] <desrt> GunnarHj: yes and no
[17:17] <ogra_> chrisccoulson, not enough for you
[17:17] <desrt> GunnarHj: it would make the UI more complicated but also more manageable
[17:17] <ogra_> and using USB disks is hard on the n7 because it doesnt charge then
[17:17] <Laney> I use mine for testing
[17:17] <seb128> chrisccoulson, keep your pandaboard ;-)
[17:17] <desrt> GunnarHj: i don't know how often people are installing language packs, but i'd guess "not a lot"
[17:17] <seb128> ogra_, do you need some back?
[17:18] <desrt> so maybe we're trying too hard to make that ultra-easy
[17:18] <qengho> ogra_, seb128, I have a Pandaboard, but I use Cr Book almost always.
[17:18] <ogra_> seb128, nope, but i need to make a decision for rarings panda desktop images
[17:18] <ogra_> seb128, it doesnt look like we will get a new PVR driver ... which means no GLES
[17:18] <sabdfl> ogra_, drop pandaboard desktop, if we want a new target, consider exynos
[17:18] <seb128> ogra_, well, we don't have the new xorg so we have working drivers?
[17:19] <GunnarHj> desrt: Currently we have a list of langpacks in language-selector for installing those.
[17:19] <chrisccoulson> i could live without a raring image
[17:19] <ogra_> sabdfl, yay, awesome !
[17:19] <Laney> right, I wouldn't be sad if there was no desktop
[17:19] <seb128> ogra_, +1 with what sabdfl said from me as well
[17:19] <ogra_> (though the mali license situation isnt much better)
[17:19] <GunnarHj> desrt: Then we have language lists in a few places to select among available translations.
[17:19] <Laney> I'm mainly using it as a server
[17:19] <seb128> we use them mostly as builder/remote machines for debugging
[17:19] <chrisccoulson> but i'd like to know that a pandaboard alternative was available, should mine die at some point ;)
[17:19] <seb128> so we don't need a desktop image
[17:19] <ogra_> yeah, i plan to keep the server images anyway
[17:19] <desrt> ogra_: lima.
[17:19] <ogra_> we use the boards as buildds so it makes sense to have a server img around
[17:20] <desrt> ogra_: plus... seriously... have you see the odroid?  it's awesome.
[17:20] <GunnarHj> desrt: how would "in use on this system" make the picture easier?
[17:21] <desrt> GunnarHj: it's somewhat likely that users on a system will speak the same languages as other users on that system
[17:21] <desrt> so we can ask accountsservice for a list of languages in use by other users and use it to preseed our own list
[17:21] <chrisccoulson> didrocks, if it's too easy, you're more than welcome to help me debug it :P
[17:21] <ogra_> desrt, i'm typing this on a chromebook under a wonderfully running unity ;)
[17:21] <desrt> ogra_: i'm guessing you're meaning it's not an x86 chromebook :)
[17:21] <ogra_> (mali600 with teh proprietary libs copied from chromeos though)
[17:22] <didrocks> chrisccoulson: pffff, not even a challenge, won't dare… (ok, I should stop jocking or you will take it seriously) ;)
[17:22] <chrisccoulson> heh
[17:22] <GunnarHj> desrt: That would be possible, of course.
[17:24] <GunnarHj> desrt: But that would require both a 'short' and a 'long' list, just as GNOME has it. Personally I think it's desirable to avoid the short/long list approach.
[17:25] <desrt> GunnarHj: i think i've made a reasonable argument that any sane way of generating a 'short list' represensitive all installed language packs would always be too long to be user-friendly
[17:26] <GunnarHj> desrt: Not sure I agree, as long as the system admin only installs relevant langpacks.
[17:27] <GunnarHj> desrt: The philosophy is to make all installed _translations_ available to the users.
[17:28] <desrt> hmm
[17:28] <desrt> indeed, the situation is bad for english
[17:28] <desrt> but it doesn't seem to be as bad for some other languages
[17:28] <desrt> the 'fr' langpack for example only brings 'fr'
[17:29] <GunnarHj> desrt: Right.
[17:29]  * desrt checks pt and es
[17:29] <desrt> pt brings pt_BR and pt_PT.  not too bad.
[17:29] <desrt> okay.  i'm starting to believe you
[17:29] <GunnarHj> desrt: Agreed about English. So maybe we should ask somebody look into the English langpack?
[17:30] <desrt> es brings... only 'es'
[17:30] <desrt> despite installing 20 locales
[17:31] <GunnarHj> desrt: Yes, since there is only one Spanish translation.l
[17:31]  * desrt tries zh
[17:31] <desrt> only CN HK and TW there, more or less as expected
[17:32]  * desrt wonders if having 'Chinese (Taiwan)' permanently in the UI for all chinese users may be problematic
[17:33] <GunnarHj> desrt: It's not there if you don't install Chinese (Traditional)
[17:33] <desrt> GunnarHj: but then you also lose hong kong
[17:33] <GunnarHj> desrt: True...
[17:33] <desrt> anyway...
[17:33] <desrt> these are obviously fairly minor details
[17:34] <desrt> i have installed language packs for en, fr, es, pt, and both zh and i see only ~10 entries
[17:34] <desrt> more than half of which are english, of course
[17:34] <GunnarHj> desrt: I'm biased, so I certainly tend to defend the current way. ;-)
[17:35] <GunnarHj> desrt: Right, but still managable for the user, isn't it?
[17:35] <desrt> yes.  utterly.
[17:35] <desrt> i expected each of fr, es, pt and zh to be as bad (or worse) than en
[17:35] <desrt> that situation would be bad
[17:35] <GunnarHj> desrt: Agreed. But that's not the case.
[17:36] <desrt> indeed
[17:42] <seb128> grrrrr firefox
[17:43] <seb128> thanks for downloading that iso in /tmp rather than ~/Download
[17:43] <seb128> since I rebooted I can restart the hour download...
[17:44] <qengho> Ugh.  We need a "AND ALSO dequeue all the apport reports that refuse to be sent because I have an old package installed somewhere" button in those crash dialogues,
[18:20] <jbicha> seb128: for gcalctool.desktop, I guess we could use session-migration
[18:20] <seb128> no
[18:20] <seb128> what would you migrate?
[18:20] <seb128> custom desktop launchers?
[18:21] <seb128> like we would need to grep through the user dir .local configs and do weird changes
[18:21] <jbicha> Unity launcher & GNOME Shell favorite
[18:21] <seb128> what if I added an icon on my desktop?
[18:21] <jbicha> my wife for instance had the calculator pinned to her launcher
[18:21] <seb128> or on gnome-panel
[18:21] <seb128> or in xfce
[18:22] <jbicha> we've done it before, I think when Ubuntu One changed its .desktop
[18:22] <seb128> right, and we got burnt by it :p
[18:23] <seb128> what's the issue with renaming back the .desktop?
[18:23] <seb128> dobey pointed that the rename broke also the calculator keybinding
[18:23] <seb128> e.g for those who have a keyboard with that key
[18:23] <jbicha> seb128: just convincing GNOME and getting the freeze exception which is definitely still doable
[18:23] <seb128> hate renames :-(
[18:24] <jbicha> we should have had robert_ancell do it before he turned over maintainership :|
[18:26] <dobey> yeah
[18:27] <seb128> he's the one who did the renaming to start
[18:27] <seb128> I complained to him about it :p
[18:32] <kenvandine> what's up with the amd64 builders?
[18:32] <kenvandine> my builds have said start in 2 hours since this morning :)
[18:34] <chrisccoulson> well, firefox is building on 2 of them
[18:36] <mlankhorst> o.o
[18:36] <dpm> kenvandine, sorry, I was in meetings, and I now have to run. I'll reply on e-mail re: the api docs question
[18:41] <seb128> jbicha, I will talk to didrocks about migration, can you come with the magic to migrate gnome-shell's favorites?
[18:41] <GunnarHj> seb128: Just a dummy question after all the recent noise: Is 13.04 going to be released as originally planned?
[18:41] <seb128> GunnarHj, we don't know, we stick to the plan until decided otherwise
[18:41] <seb128> GunnarHj, discussion is still ongoing, I hope we get a conclusion in the next week
[18:41] <GunnarHj> seb128: Ok...
[18:44] <jbicha> seb128: it should be just as easy as it would be for Unity, but I filed https://bugzilla.gnome.org/show_bug.cgi?id=695382 and will try following up with GNOME
[18:44] <ubot2`> Gnome bug 695382 in general "Rename gnome-calculator.desktop back to gcalctool.desktop" [Normal,Unconfirmed]
[18:44] <seb128> jbicha, thanks
[19:05] <GunnarHj> charles: ping
[19:21] <Quintasan> GunnarHj: ping
[21:10] <desrt> ricotz: https://git.gnome.org/browse/gtk+/commit/?id=4054d531c32d0d28614435fae1d9041b629197bc
[21:10] <desrt> ricotz: why not strncpy?
[21:12]  * desrt supposes nul termination is handled differently in the overflow case there...
[21:17] <ricotz> desrt, hi, this was suppose to only fix the warning and not changing the logic
[21:17] <desrt> fair enough
[21:17] <desrt> plus... the nul case is a good argument to leave it as is
[21:18] <desrt> i forgot that strncpy() totally sucks in this regard
[21:31] <ricotz> desrt, hmm, i see
[21:37] <robert_ancell> mterry, lightdm "All 147 tests passed". OMG trunk finally passes. I can release :)
[21:37] <mterry> robert_ancell, hah!
[21:38] <mterry> robert_ancell, well, hold on
[21:38] <mterry> robert_ancell, this qt5 branch, do you have an opinion on Dave's comments?
[21:38] <mterry> I'd like to squeeze that in if we can
[21:39] <robert_ancell> mterry, I think he's right - it would be safer to add a new entry so upgraders don't get caught out
[21:39] <robert_ancell> can you fix it soon?
[21:43] <mterry> robert_ancell, sure
[21:44] <mterry> robert_ancell, I figured upgraders would know that various things need to be changed between qt4 and qt5 (surely the rest of the upgrade won't be no-changes).  But easy enough to add new role
[21:44] <attente> in what Makefile does dh_auto_test look for the test/check target?
[21:45] <mterry> attente, I think it's buildsystem based.  In the Makefile/autotools buildsystem, it probably just calls make check
[21:45] <robert_ancell> mterry, I don't know enough to say but in general it seems safer to add the new role, there's also some precedence for that as noted by David
[21:47] <mterry> robert_ancell, fixing now
[21:47] <attente> mterry, so if i have a check target, dh_auto_test should find it automatically?
[21:47] <attente> that's not my experience currently for some reason
[21:47] <mterry> attente, if you're using autotools and such
[21:50] <attente> that's the case. but it just echos dh_auto_test without running make check it seems
[21:54] <mterry> robert_ancell, branch updated
[21:54] <robert_ancell> mterry, ta
[21:55] <mterry> attente, put some echos in your top-level check target?
[21:58] <attente> mterry, still not getting called unfortunately
[21:59] <attente> i guess i should just override dh_auto_test
[21:59] <robert_ancell> mterry, did you see David's comment?
[21:59] <mterry> robert_ancell, grr, ok
[22:00] <mterry> robert_ancell, fixed
[22:02] <robert_ancell> mterry, btw, what do you think of lp:~ubuntu-desktop/lightdm/ubuntu? I think it's more effort than it's worth - any opposition to just doing standard uploads?
[22:03] <robert_ancell> or just a /debian dir only branch
[22:03] <mterry> robert_ancell, or inline?  :)
[22:04] <robert_ancell> mterry, yeah, was thinking about that. I don't know if that is a good or a bad thing for lightdm
[22:04] <mterry> robert_ancell, either just debian or standard uploads is fine
[22:04] <mterry> robert_ancell, I have a slight preference for debian/ bzr branches
[22:09] <popey> I am reading kenvandine's blog post and for some reason in my head I'm hearing his accent
[22:09] <kenvandine> hahah
[22:09] <kenvandine> i have an accent?
[22:10] <kenvandine> popey, i thought it was you that had an accent :-p
[22:10] <popey> hah!
[22:10] <kenvandine> hehe
[22:11] <robert_ancell> mterry, Is libqt5v8-5-dev the correct qt5 dev package to depend on?
[22:12] <mterry> robert_ancell, qtbase-dev I believe
[22:12] <mterry> robert_ancell, qtbase5-dev sorry
[22:12] <robert_ancell> ok
[22:43] <robert_ancell> mterry, can you smoke test lp:~robert-ancell/lightdm/ubuntu-1.5.1?
[22:51] <mterry> robert_ancell, k
[23:13] <mterry> robert_ancell, built and runs fine for my simple case
[23:13] <robert_ancell> mterry, ok that's two systems so can't be too bad :)
[23:14] <mterry> robert_ancell, we're past FF though by a couple hours  :)
[23:14] <robert_ancell> mterry, I'm going to #ubuntu-release to beg :)