[04:56] <TheMuso> pitti: Good morning.
[05:48] <BigWhale> is it really morning if it's still dark outside? :>
[06:10] <pitti> RAOF: https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-color-management-next-steps has some alpha-2 WIs; is that still coming along, or should we postpone that to Q?
[06:12] <pitti> TheMuso: any progress on the java at-spi2 stuff? alpha-2 gets really close, and this is something we want to roll out early I think
[06:12] <pitti> well, "early", we are mid-way through the release :)
[06:13] <TheMuso> pitti: Actually working on it now, just rolling a multi-arch enabled atk wrapper, and will then build a new openjdk with atk wrapper substituted for java-access-bridge. nce built, I'll test it first thing Monday, and if successful, will push openjdk changes next Monday.
[06:13] <pitti> TheMuso: ah, sweet! thanks
[06:23] <RAOF> pitti: I'd still like to do the "calibrate" button WI, but that's likely to miss A2.  The rest is much less important.
[06:27] <pitti> RAOF: but that's done?
[06:27] <pitti> RAOF: oh, should that be reopened and renamed "fix calibrate button" then?
[06:28] <RAOF> It's the second work-item - add PackageKit support to the calibrate button.
[06:29] <pitti> oh, silly me; will change it back
[06:30] <RAOF> Heh.  Conflicting blueprint changes!
[06:30] <TheMuso> And now that openjdk-6 is building, I'm done for the day, given that this will take ages to build, and I can't really do unity/ubiquity testing easily while it builds. :)
[06:30] <pitti> RAOF: so the shared-color-targets and icc-profiles one can/should be postoned?
[06:31] <pitti> TheMuso: enjoy the weekend!
[06:31] <RAOF> They can be postponed, yeah.
[06:34] <pitti> bryce: do you know if inkscape is planning to migrate to lcms2 at some point? lcms1 is dead upstream
[06:35] <pitti> tkamppeter: is cups conversion to lcms2 still realistic for alpha-2? (bug 885324)
[06:35] <ubot2> Launchpad bug 885324 in cups "Completely replace lcms1 by lcms2 in Ubuntu" [High,In progress] https://launchpad.net/bugs/885324
[07:21] <didrocks> goog morning
[07:29] <bryce> pitti, I don't think so (at least I haven't heard any mention of it) but I'll ask around
[07:30] <bryce> pitti, no mention of it on http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies or on Roadmap
[07:35] <pitti> hey didrocks, ca va?
[07:35] <pitti> bryce: thanks
[07:36] <didrocks> pitti: ça va, fighting yesterday evening with the new heater (just installed before the rally) which broke apparently :/
[07:37] <didrocks> so 18°C in the main room. Will need to send it back to the store tomorrow (35 kgs, will have another "fun trip") :)
[07:37] <didrocks> pitti: and you, how are you?
[07:37] <bryce> pitti, if it is changed, it may not make it for Precise though
[07:37] <pitti> bryce: ok; not a biggie, I think, as long as it works
[07:38] <pitti> didrocks: quite fine, thanks; my jaw is getting better, and precise works again, too :)
[07:38] <pitti> apparently doko's test eglibc triggered the SVG loader crash
[07:38] <didrocks> pitti: heh :) do you have any idea how the indicator-keyboard is picking some keyboard?
[07:38] <didrocks> as unity-greeter reset to the default, I select the "French one"
[07:39] <pitti> didrocks: fairly well, yes; how do you mean "pick"? the default value? or changing it?
[07:39] <didrocks> but the French one is not the one we set by default (which is french (alternative))
[07:39] <pitti> didrocks: oh, the unity greeter touches keyboard layout? I thought it doesn't any more
[07:39]  * didrocks looks if something was uploaded since yesterday
[07:40] <pitti> didrocks: hang on, I'm afraid I don't follow
[07:40] <didrocks> pitti: ok, so, since yesterday with the new unity-greeter:
[07:40] <didrocks> when you enter unity-greeter, it discares your keyboard configuration
[07:41] <didrocks> and reset to "usa"
[07:41] <pitti> so that's the system-wide default, not the per-user one, I take it?
[07:41] <pitti> from /etc/default/keyboard ?
[07:41] <didrocks> which is why some people (on the french forum), can't log in, because they don't see the indicator reset to usa
[07:41] <didrocks> let me check
[07:41] <didrocks> no
[07:41] <pitti> oh, we have a keyboard indicator in lightdm now? checking..
[07:41] <didrocks> my system one is:
[07:41] <didrocks> XKBMODEL="pc105"
[07:41] <didrocks> XKBLAYOUT="fr"
[07:41] <didrocks> XKBVARIANT="oss"
[07:41] <didrocks> XKBOPTIONS=""
[07:41] <didrocks> yeah, the keyboard indicator is there
[07:42] <pitti> ah, so we do
[07:42] <pitti> didn't notice
[07:42] <didrocks> I didn't notice until I saw I couldn't log in :)
[07:42] <pitti> that doesn't make a lot of sense, though
[07:42] <didrocks> and a lot of people can't test precise right now because of that
[07:42] <didrocks> (because it's resetted to usa here)
[07:42] <pitti> didrocks: so, I indeed don't know what the greeter kb indicator does, or why it's even there
[07:43] <didrocks> pitti: and the thing is that it presents 3 keyboards for "French"
[07:43] <pitti> the greeter should use the per-user default layout as in the old gdm 2
[07:43] <pitti> or not change it at all
[07:43] <didrocks> and in those choice, there is not the french default which is french (alternatives)
[07:43] <didrocks> need to go to g-c-c to set it again
[07:44] <pitti> didrocks: so I suppose that indicator tries to read the gsettings key, which is unset
[07:44] <pitti> didrocks: erk, the unity greeter changes the user settings, too?
[07:44] <pitti> that is all wrong
[07:44] <didrocks> yeah
[07:44] <didrocks> to usa
[07:44] <didrocks> which is even worse on an azerty keyboard :)
[07:45] <pitti> bug 834487, bug 783827
[07:45] <ubot2> Launchpad bug 834487 in unity-greeter "Add keyboard layout indicator to unity-greeter" [Medium,Fix released] https://launchpad.net/bugs/834487
[07:45] <ubot2> Launchpad bug 783827 in unity-greeter "Keyboard layout not set in greeter" [High,Fix released] https://launchpad.net/bugs/783827
[07:45] <didrocks> and there is no choice with the french keyboard in the indicator with the french "default"
[07:46] <didrocks> those are "released"
[07:46] <pitti> didrocks: yes, those are the bugs which introduced the indicator
[07:47] <pitti> didrocks: I think you should reopen 783827
[07:48] <pitti> didrocks: I just tested it, want me to do it and comment?
[07:49] <didrocks> for the second issue, the french default keyboard not being proposed in the dropdown, I think this is an issue with the indicator-keyboard itself, isn't it?
[07:49] <pitti> yes, I guess so
[07:49] <pitti> also, the list is really horrible
[07:50] <pitti> one level, way too long
[07:50] <didrocks> indeed, way too long, but not what we use in France :)
[07:50] <didrocks> we should remove all the other options
[07:50] <didrocks> and keep what we have in France
[07:50] <didrocks> maybe usa
[07:50] <didrocks> and that's it! :-)
[07:52] <didrocks> hum, can't reopen the upstream task on bug #783827
[07:52] <ubot2> Launchpad bug 783827 in unity-greeter "Keyboard layout not set in greeter" [High,Fix released] https://launchpad.net/bugs/783827
[07:55] <pitti> didrocks: no, neither can I; I reopened the disto task now wiht a commen
[07:55] <pitti> t
[07:56] <pitti> and pointed to that in the other bug and the MP
[07:56] <tkamppeter> pitti, conversion of CUPS is rather small, it will happen at least for FF. When exactly is a2? I could ask Otani whether he could do it in time.
[07:57] <didrocks> pitti: you reopened? you didn't get any error? weird :) (as I reopened it before, see the comment before yours ;))
[07:57] <pitti> tkamppeter: Feb 02; but it's not really an a2 blocker, b1 is fine, too
[07:57] <tkamppeter> pitti, now where Otanis has ported Poppler (bug 885324).
[07:57] <ubot2> Launchpad bug 885324 in cups "Completely replace lcms1 by lcms2 in Ubuntu" [High,In progress] https://launchpad.net/bugs/885324
[07:57] <pitti> didrocks: the distro task, not the upstream one
[07:57] <didrocks> yeah, I did it for the distro task as well :)
[07:58] <didrocks> (but seems launchpad is now smart about it, he just added mterry assignment and milestoned, and ignored the status changed as it was already done, it used to error before ;))
[07:59] <pitti> didrocks: well, that was me :)
[08:00] <didrocks> pitti: you meant reopen, which is:
[08:00] <didrocks> Changed in unity-greeter (Ubuntu):
[08:00] <pitti> oh, I know what you mean
[08:00] <didrocks> status: Fix Released → Triaged
[08:00] <pitti> it filtered out the duplicate reopening, yes
[08:00] <didrocks> yeah ;)
[08:00] <pitti> didrocks: on https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-unity-quality, who is "amber"?
[08:01] <pitti> https://launchpad.net/~amber doesn't look like an appropriate assignee
[08:01] <didrocks> pitti: https://wiki.ubuntu.com/AmberGraner
[08:01] <didrocks> hum, I didn't take the note during uds, let me try to find her
[08:01] <pitti> didrocks: ah, fixed
[08:01] <pitti> akgraner
[08:01] <didrocks> yep
[08:01] <didrocks> thanks :)
[08:02] <pitti> didrocks: "Help on the tarmac autopilot integration", is there something missing there?
[08:03]  * pitti was looking at http://status.ubuntu.com/ubuntu-precise/u/didrocks-precise-alpha-2.html and wonders how we can take some stuff off you
[08:04] <didrocks> pitti: yeah, I relaunch the subject, I made some stuff, but now that evan is back, I hope he can finish what he started
[08:04] <didrocks> pitti: I sent an email 2 days ago, no answer, but let's wait for a week :)
[08:04] <pitti> *nod*
[08:05] <didrocks> pitti: my overall trend is good: http://status.ubuntu.com/ubuntu-precise/u/didrocks.html
[08:05] <didrocks> pitti: I think I can reshuffle some stuff from alpha2 to later if you want
[08:05] <didrocks> the mandatory one is "Put some blessed Unity settings in gnome-control-center in an unity panel
[08:05] <didrocks> (in my opinion)
[08:05] <pitti> didrocks: yes, it is; I mainly wanted to ask whether you are comfortable with your remaining items, or would like to drop some
[08:05] <pitti> didrocks: yes, I agree; that's a2 matter
[08:06] <pitti> didrocks: I did that with everyone last week, don't worry :)
[08:06] <didrocks> pitti: I regularly watch them, seems ok, but I can put "implement ubiquity integration" to later :)
[08:06] <didrocks> it's the only one I'm unsure about for this cycle
[08:06] <didrocks> especially with the fact that the ISD side is dropped
[08:06] <didrocks> (yeah, oneconf always get dropped for 3rd part every cycle :()
[08:07] <pitti> ok, moved
[08:07] <pitti> (to b1)
[08:07] <didrocks> ok, the rest should be ok for alpha2 IMHO
[08:07] <pitti> thanks
[08:08] <pitti> I guess we won't do much about compiz/unity startup speed after all?
[08:08] <pitti> I overheard some conversations last week that we can't build in some plugins, and also don't drop some?
[08:08] <didrocks> pitti: yeah, the gsettings won't give much with the benchmark I did with the ini backend
[08:08] <didrocks> yeah, I discussed that with sam, we will even add one more plugin to fix a bug :/
[08:09] <didrocks> (we really started from nothing and add one plugin after another in natty)
[08:09] <didrocks> and for static linking, it will bring issues
[08:09] <didrocks> (see my comment on the blueprint)
[08:09] <pitti> adding tracepoints might help to see whether plugin loading is just generally slow, or whether one takes an inordinate amount of time
[08:09] <didrocks> so, the last thing I can do is to see which plugins takes time to load
[08:09] <didrocks> indeed
[08:10] <didrocks> I need to that manually, nothing is built in right now, I think about doing that during alpha2 freeze
[08:10] <didrocks> (after this compiz release)
[08:11] <pitti> meh, editing whiteboards really sucks with the new LP
[08:11] <tkamppeter> pitti, I want to ask you something about the new cups-filters package on OpenPrinting.
[08:11] <pitti> the edit field keeps jumping to a mini format
[08:11] <pitti> tkamppeter: go ahead :)
[08:12] <tkamppeter> pitti, as this is the upstream home of the PDF filters now, and it even contains some improvements on the filters which are not in the add-on package CUPS is using in debian/local/, I would like to use it in Precise.
[08:12] <pitti> tkamppeter: right; I thought that was the plan all along
[08:13] <tkamppeter> pitti, problem is that it is a new package and as CUPS is synced wioth Debian it would need to go through a lot of formalizm to arrive in both distros. What should we do here?
[08:13] <pitti> tkamppeter: why formalism?
[08:14] <pitti> tkamppeter: we can just upload it to Debian (the earlier the better), wait until it's through NEW, and then sync
[08:14] <pitti> tkamppeter: if that takes too long, we have to fork cups for the time being
[08:14] <pitti> but NEW doesn't take that long in Debian any more, a couple of days usually
[08:15] <pitti> tkamppeter: it's by and large a splitout of what cups already ships, isn't it?
[08:16] <tkamppeter> pitti, yes, it does not contain anything totally new. It is waht CUPS contains with only some development, no new concepts.
[08:16] <pitti> tkamppeter: right; so I don't see any trouble with NEW or MIRs or anythign
[08:16] <pitti> I'm happy to check the packaging and upload it to Debian
[08:17] <tkamppeter> pitti, I want to do the first release of the upstream package in the next days, but I am waiting for larsu's bannertopdf filter.
[08:17] <tkamppeter> pitti, immediately after this first release I would package it and make it available to you.
[08:18] <pitti> tkamppeter: you can also work on packaging in parallel, and then just add the new filter when it lands
[08:18] <tkamppeter> pitti, one problem is also coordination with CUPS, together with it, a new CUPS package without the filters now maintained by cups-filters needs to get uploaded, too.
[08:18] <pitti> tkamppeter: i. e. create the packaging from a "make dist" from git
[08:19] <pitti> tkamppeter: I propose it gets uploaded to experimental first
[08:19] <pitti> tkamppeter: then it can Conflicts:/Replaces: cups (<< version_that_drops_filters)
[08:19] <pitti> tkamppeter: and cups can then Depends: cups-filters
[08:20] <pitti> tkamppeter: once it's through NEW, we can upload cups and cups-filters to unstable at the same time
[08:20] <pitti> and sync both into precise
[08:21] <pitti> tkamppeter: we can also get it into ubuntu earlier, no problem
[08:21] <pitti> we just need cups-filters packaged
[08:25] <bryce> pitti, confirmed no plans
[08:31] <didrocks> pitti: will you have time for a SRU round today? I'm afraid that unity will migrate into -updates (well, there are still some bugs not confirmed) where we should reset the counter with the new version in -proposed
[08:31] <pitti> didrocks: yep, can do
[08:32] <didrocks> pitti: thanks a bunch :)
[08:35] <pitti> didrocks: I was doing 10.04.4 review anyway, so doing now
[08:36] <didrocks> \o/
[08:37] <pitti> didrocks: bug 830949 not fixed in precise yet?
[08:37] <ubot2> Launchpad bug 830949 in xserver-xorg-video-intel "[Intel N10 Graphics] Need Compiz' "Copy to Texture" plugin so can display on multi-head layouts bigger than the max GL texture size" [Undecided,Invalid] https://launchpad.net/bugs/830949
[08:37] <pitti> should be, otherwise this can't go to -updates
[08:38] <didrocks> hum hum, this shouln't be in there
[08:38]  * didrocks checks
[08:38] <pitti> didrocks: same for the compiz upload
[08:38] <pitti> I accepted unity, as it's a regression in -proposed AFAIUI
[08:38] <didrocks> ah, you are looking the compiz update?
[08:38] <pitti> but compiz ought to get a precise upload first
[08:38] <pitti> didrocks: no, that was unity
[08:38] <didrocks> wait one sec
[08:38] <pitti> didrocks: http://launchpadlibrarian.net/90423564/unity_4.28.0-0ubuntu2_source.changes
[08:39] <didrocks> ok, reject :/
[08:39] <didrocks> wrong copy and paste
[08:39] <pitti> didrocks: compiz or unity?
[08:39] <didrocks> (the bug #)
[08:39] <didrocks> unity
[08:39] <pitti> didrocks: already accepted unity
[08:39] <pitti> didrocks: so let's just do the call for testing on the right one
[08:39] <didrocks> this is what happens when you get ping continuously :/
[08:39] <didrocks> sorry pitti
[08:39] <pitti> np
[08:39] <tkamppeter> pitti, can you upload the current snapshot of the CUPS BZR to Debian and Ubuntu? Then the package release after this one will get the cups-filters switchover.
[08:39] <pitti> which one is the actual bug?
[08:39] <didrocks> let me dig into my logs
[08:39] <pitti> tkamppeter: can do
[08:40] <didrocks> pitti: for compiz > yeah, I know, it's just that we planned to update compiz during the rally and so the moon should have aligned. However, there was this API break which postponed the precise upload
[08:41] <didrocks> pitti: bug #912682 is the right one
[08:41] <ubot2> Launchpad bug 912682 in unity/4.0 "Compiz add transparency to titlebar along with the panel" [High,In progress] https://launchpad.net/bugs/912682
[08:42] <didrocks> it's in trunk, will be released next week
[08:42] <pitti> tkamppeter: I want to look into http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654641 before upload, which is marked as RC
[08:42] <ubot2> Debian bug 654641 in libcups2 "libcups2: cups-1.4.4-7 package build failed on 'reverting patch manpage-translations'" [Serious,Open]
[08:42] <didrocks> pitti: sorry again for the mess :/
[08:42] <pitti> didrocks: no problem at all, *hug*
[08:43]  * didrocks hugs pitti
[08:47] <mhr3> no seb?
[08:47] <mhr3> hmmm
[08:49] <pitti> not yet
[08:49] <tkamppeter> seb128, I have uploaded Poppler now, where is the BZR to commit the changes?
[08:49] <pitti> tkamppeter: no bzr
[08:50] <pitti> it's in lp:ubuntu/poppler, or just upload
[08:50] <tkamppeter> pitti, I have done only a dput upload, but I remember that there was also a repo, and once one of my fixes got dropped because it was not in the repo.
[08:51] <pitti> tkamppeter: well, it doesn't have a Vcs-Bzr: header, so if someone complains, he will have to re-merge and add it
[08:51] <pitti> ah, https://code.launchpad.net/~ubuntu-desktop/poppler/ubuntu
[08:51] <pitti> tkamppeter: ^
[08:52] <pitti> tkamppeter: so you can commit it there
[08:53] <tkamppeter> pitti, I succeeded to download lp:ubuntu/poppler now, are there 2 independent repos? lp:ubuntu/poppler and https://code.launchpad.net/~ubuntu-desktop/poppler/ubuntu?
[08:55] <pitti> tkamppeter: you can ignore lp:ubuntu/poppler, it auto-updates from uploads
[08:55] <pitti> tkamppeter: ~ubuntu-desktop/poppler/ubuntu is the actual bzr branch which we are using
[08:55] <pitti> just someone dropped the Vcs-Bzr: tag from debian/control..
[08:56] <pitti> (this desperately needs to be added back, otherwise people will keep not committing first)
[09:06] <chrisccoulson> good morning everyone
[09:08] <pitti> hey chrisccoulson
[09:08] <chrisccoulson> hi pitti, how are you?
[09:08] <pitti> quite fine, thanks! hardly feel my jaw any more; how about you?
[09:09] <chrisccoulson> pitti - yeah, i'm good thanks
[09:09] <chrisccoulson> oh, you've had your tooth extracted now?
[09:09] <pitti> chrisccoulson: on Tuesday already
[09:09] <chrisccoulson> good to hear it's not too painful :)
[09:10] <pitti> chrisccoulson: we even talked about it, you told us about the weird anestheticum you got that made you actually enjoy it
[09:10] <pitti> wasn't that you?
[09:11] <chrisccoulson> pitti - yeah. i remember now, although i forgot which day you were having it done ;)
[09:18] <seb128> hey
[09:19] <pitti> hey seb128
[09:19] <seb128> hey pitti, how are you?
[09:19] <pitti> seb128: quite fine, thanks!
[09:19] <pitti> seb128: my crash from yesterday was indeed due to the PPA libc
[09:20] <seb128> \o/
[09:20] <seb128> pitti, do you know what upgrade or change triggered the issue for you yesterday?
[09:20] <pitti> seb128: no; I just downgraded libc6, and it was gone
[09:21] <pitti> I downgraded everything else except libc6, and I still got the crash
[09:21] <pitti> really a mystery to me
[09:21] <seb128> ok
[09:21] <seb128> well at least it was not a buggy update in precise
[09:22] <didrocks> good morning chrisccoulson
[09:22] <chrisccoulson> hi didrocks
[09:22] <chrisccoulson> hi seb128 too!
[09:22] <seb128> hey chrisccoulson
[09:23] <seb128> how are you?
[09:23] <chrisccoulson> yeah, good thanks. and you?
[09:23] <chrisccoulson> glad that firefox is building on powerpc now........until the next release, anyway!
[09:24]  * micahg hugs chrisccoulson
[09:29] <seb128> didrocks, pitti: dude, don't reopen closed bugs ;-)
[09:29] <seb128> the unity-greeter "en" keyboard issue is bug #915468
[09:29] <ubot2> Launchpad bug 915468 in lightdm "the unity-greeter keyboard's selection doesn't respect the user config" [High,Confirmed] https://launchpad.net/bugs/915468
[09:29] <seb128> no need to reopen a different bug
[09:30] <pitti> seb128: well, the title was quite matching
[09:30] <pitti> ok, then we can close the other one again
[09:30] <seb128> yeah, just did that
[09:30] <pitti> seb128: assigned to mterry and milestoned to a2
[09:31] <seb128> didrocks, pitti, I've discussed it with robert_ancell and mterry yesterday
[09:31]  * pitti in mumble and lagging on irc
[09:31] <seb128> robert_ancell said he would look at the lightdm side
[09:32] <didrocks> seb128: is there also a bug to track that in indicator-keyboard, there is only 3 french keyboard and not the "french (alternative)" which is the default ubuntu french one?
[09:32] <seb128> didrocks, no
[09:32] <seb128> but imho that design of listing all existing keymaps is ridiculous
[09:34] <didrocks> agreed, but if we stays on that, we need to ensure at least, we have the default french keyboard :)
[09:34]  * didrocks hates non oss keyboard
[09:34] <seb128> didrocks, I didn't even notice there was a difference :p
[09:34] <didrocks> seb128: you never use … !
[09:34] <seb128> no, I use ... ;-)
[09:34] <didrocks> bad bad bad ;-)
[09:34] <seb128> lol
[09:35] <didrocks> more seriously, we should align the proposal with what is set by default with ubiquity :)
[09:36] <seb128> dunno what a good UI would be, keyboard selectors always suck
[09:36] <seb128> but it should at least by default pick the user session layout
[09:37] <didrocks> yeah :)
[09:38] <seb128> didrocks, pitti: reassigned the lightdm part to robert_ancell and added an unity-greeter part for mterry, which is what we discussed here yesterday night
[09:39] <seb128> but I will try to have a look today to see if it's lightdm which is returning the wrong value of unity-greeter not using the lightdm api as it should
[09:40] <didrocks> seb128: can you look as well how the indicator select the keyboard display to show? (they are available in g-c-c)
[09:40] <seb128> didrocks, well do
[09:40] <seb128> but first I need to finish my fight with webkit
[09:40] <seb128> or aka. ld taking 3gb or ram and my disk ran out of space after 3 hours build yesterday
[09:40] <didrocks> fight? :)
[09:41] <didrocks> waow
[09:41]  * didrocks is making bug paperwork today and unity process writing…
[09:41] <seb128> indeed, I hate to close firefox and tb to be able to ld
[09:41] <seb128> hate -> had
[09:42] <tkamppeter> pitti, how do I bzr push to ~ubuntu-desktop/poppler/ubuntu?
[09:42] <tkamppeter> seb128: ^^
[09:42] <seb128> tkamppeter, bzr push lp:~ubuntu-desktop/poppler/ubuntu?
[09:44] <tkamppeter> seb128, did
[09:44] <tkamppeter> bzr launchpad-login till-kamppeter
[09:45] <seb128> tkamppeter, btw not sure I like that we ship a patch upstream said they disagree with
[09:45] <tkamppeter> bzr push --remember lp:~ubuntu-desktop/poppler/ubuntu
[09:45] <seb128> that should work
[09:45] <tkamppeter> and got
[09:45] <tkamppeter> bzr: ERROR: Cannot lock LockDir(chroot-89624528:///~ubuntu-desktop/poppler/ubuntu/.bzr/branch/lock): Transport operation not possible: readonly transport
[09:45] <seb128> you probably don't have the rights to push there
[09:45] <seb128> do a merge request
[10:11] <tkamppeter> seb128, I have upload rights to Poppler, can I get, to simplify the workflow in the future, also get push rights for this BZR?
[10:12] <seb128> tkamppeter, no, I think we discussed it before
[10:12] <seb128> tkamppeter, ubuntu-desktop membership gives full access to the desktop set
[10:13] <seb128> tkamppeter, we would need to move poppler out of the team vcs rather
[10:19] <tkamppeter> seb128, I went to the Launchpad page of this repo and do not find a link or buttonm to request a merge. Hopw do I proceed?
[10:20] <seb128> tkamppeter, did you file merge requests before? just push to lp:~tkamppeter/poppler/somename
[10:20] <seb128> then go that page and click on the submit merge request button
[10:21] <tkamppeter> seb128, I did not use this functionality before, because in all the other cases I had direct push access.
[10:22] <seb128> yeah, I understand that
[10:23] <tkamppeter> Poppler is the only team-owned package which is in my dput upload portfolio. I am in the Desktop Team, at least in terms of Canonical organization, but probably not memeber of the LP team due to an oversight or due to not having a full contract.
[10:24] <tkamppeter> seb128 ^^
[10:25] <tkamppeter> seb128: bzr push --remember lp:~tkamppeter/poppler/precise
[10:25] <tkamppeter> seb128: bzr: ERROR: Permission denied: "~tkamppeter/poppler/precise/": : Till Kamppeter cannot create branches owned by Till Kamppeter
[10:25] <seb128> urg
[10:25] <seb128> dunno about that one
[10:26] <seb128> tkamppeter, no, it's not an oversight, ubuntu-desktop has nothing to do with being working in the Canonical Desktop Team, it gives access to the desktop set for uploads
[10:26] <seb128> tkamppeter, it just happens that we have put the poppler packaging vcs under that team
[10:26] <tkamppeter> seb128, I will e-mail you the "bzr bundle" of my changed.
[10:26] <seb128> mterry, hey, waking up at the middle of the night? ;-)
[10:26] <micahg> tkamppeter: the ubuntu-desktop team is connected with upload rights for the ubuntu-desktop packageset in LP, not the Canonical Desktop team
[10:26] <seb128> tkamppeter, ok
[10:27] <mterry> seb128, yup  :)
[10:31] <chrisccoulson_> Ah, the imposter has gone
[10:34] <seb128> mterry, is LightDM.UserList something lightdm is building? is that supposed to be a full list of users with all their details set?
[10:34] <tkamppeter> seb128, you have mail.
[10:34] <seb128> tkamppeter, thanks
[10:35] <mterry> seb128, yeah
[10:36] <tkamppeter> seb128, I have also contacted upstream telling themn that 5-10 % performance loss is no problem when getting a more stable, reliable, less crashy, upstream-maintained library.
[11:34] <seb128> webkit-1.7.4$ du -ksh .
[11:34] <seb128> 15G	.
[11:34] <seb128> out of space build fail
[11:34] <seb128> chrisccoulson, I take firefox if you take webkit :p
[11:34] <chrisccoulson> lol
[11:35] <chrisccoulson> i think i'd prefer to keep firefox ;)
[11:35] <seb128> hehe
[11:35] <seb128> one the good side I'm almost there
[11:35] <seb128> it failed on the -dbg package dh_strip call
[11:37] <chrisccoulson> i even managed to do a bisect with firefox last night over 947 commits and it only took me around 30 minutes (for bug 918763)
[11:37] <ubot2> Launchpad bug 918763 in firefox "Firefox 12 fails to build on Lucid x86_64 (../../../dist/include/nsCOMPtr.h:316: internal compiler error: in tree_nrv, at tree-nrv.c:143)" [Critical,Triaged] https://launchpad.net/bugs/918763
[11:37] <chrisccoulson> i wonder what that would be like with webkit ;)
[11:37] <Sweetshark> seb128, chrisccoulson: I would have another package looking for additional maintainers, if you are interested ...
[11:37] <chrisccoulson> i'd probably still be building it now!
[11:38] <chrisccoulson> Sweetshark, lol ;)
[11:40] <mterry> seb128, did robert-ancell mention any progress on the keyboard thing?  I'll start looking at it
[11:40] <seb128> mterry, no, I've been looking a bit into it
[11:41] <seb128> mterry, so in unity-greeter.vala you do:
[11:41] <Sweetshark> pitti: I just uploaded a 3.5.0~beta2-2ubuntu4 to chinstrap with just the dep fixes
[11:41] <seb128>                 foreach (var user in users.users)
[11:41] <seb128>                     user_added_cb (user);
[11:41] <seb128> mterry, I've added a "                    stderr.printf("user layout: %s\n", user.layout);" there
[11:41] <seb128> mterry, in test mode the layout for my user is "fr"
[11:42] <seb128> mterry, (I hacked testmode to use the system list and not the builtin static one)
[11:42] <seb128> mterry, in real mode it's Null (in x-1-greeter.log)
[11:42] <pitti> Sweetshark: ah, thanks; note you need to close the bug yourself, as the LP syntax is wrong
[11:42] <seb128> mterry,
[11:42] <seb128> user name: seb128
[11:42] <seb128> user realname: seb128
[11:42] <seb128> user language: fr_FR.utf8
[11:42] <seb128> user layout: (null)
[11:42] <seb128>  
[11:42] <seb128> mterry, that's in real mode
[11:42] <mterry> seb128, is there a system layout?
[11:42] <seb128> mterry, so something is different between test mode and real mode which made the keymap not set
[11:42] <seb128> mterry, define system layout?
[11:42] <mterry> seb128, (i.e. do you know what lightdm_get_layout returns?)
[11:43] <seb128> mterry, let me try
[11:43] <mterry> seb128, that's the default layout if the user layout is null
[11:43] <pitti> Sweetshark: uploaded, thanks!
[11:43] <seb128> mterry, well the user layout shouldn't be null
[11:43] <mterry> LightDM.get_layout ()
[11:43] <mterry> seb128, yar, the fact that it's different between 'real' and 'testing' is certainly an issue
[11:44] <ricotz> hello everyone
[11:44] <ricotz> seb128, hi, you are playing with webkit?
[11:44] <mterry> seb128, OK, I thought user layout could be null
[11:44] <mterry> seb128, but I didn't base that on facts  :)
[11:44] <seb128> ricotz, updating to 1.7.4
[11:45] <ricotz> seb128, for precise or ppa?
[11:45] <seb128> mterry, there are 2 issues, one is that real mode fails to get the user layout for some reason (where test mode does work), the second one is that the default layout is wrong when that happens
[11:45] <seb128> ricotz, precise, why?
[11:45] <ricotz> seb128, did you enable webgl?
[11:45] <ricotz> seb128, ok, just asking
[11:45] <seb128> ricotz, webwhat?
[11:45] <seb128> ricotz, no
[11:45] <mterry> seb128, right
[11:46] <ricotz> seb128, ok
[11:46] <seb128> mterry, so get_layout() returns a LightDM.Layout, let me see how I can print that :p
[11:46] <seb128> lightdm_layout_get_name
[11:47] <mterry> seb128, ".name"
[11:48] <seb128> mterry,
[11:48] <seb128> user language: fr_FR.utf8
[11:48] <seb128> user layout: (null)
[11:48] <seb128> system layout: us
[11:48] <seb128> mterry, so yeah, that returns "us"
[11:48] <seb128> so I guess that part is a lightdm bug
[11:48] <mterry> seb128, and it's supposed to be "fr"?
[11:48] <seb128> mterry,
[11:48] <seb128> $ grep LAYOUT /etc/default/keyboard
[11:48] <seb128> XKBLAYOUT="fr"
[11:49] <seb128> mterry, which is basically what gdm or xorg would use if not told otherwise
[11:50] <seb128> mterry, btw that might be interesting:
[11:50] <seb128> :1-greeter.log:[+0,53s] WARNING: Getting layout failed: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: L'interface « com.canonical.dbusmenu » n'existe pas pour l'objet à l'emplacement /com/canonical/indicator/users/menu
[11:50] <mterry> hmm
[11:50] <seb128> it's french but you can guess the english versions, words are similar
[11:52] <pitti> I haven't followed the full conversation, but falling back to /etc/default/keyboard can't be the full story here
[11:52] <pitti> I have created a test user where control-center said "German", while my system keyboard is "US"
[11:52] <pitti> reading "us" from /e/d/keyboard wouldn't help there
[11:52] <seb128> pitti, several bugs
[11:52] <seb128> - getting the user layout is failing
[11:52] <seb128> - it's fallback wrongly to "us" rather than to the system default
[11:53] <seb128> fallbacking
[11:53] <pitti> Sweetshark: http://paste.ubuntu.com/810604/ :(
[11:53] <mterry> pitti, seb128: so this might be a good instance of the new policy of backing code out that would take more than an hour to fix?
[11:53] <pitti> seb128: *ack*
[11:53] <pitti> mterry: yeah, I agree, especially on a Friday afternoon
[11:54] <seb128> mterry, well, I don't see that as a major issue since you can select your layout with the indicator
[11:54] <seb128> but seems pitti and didrocks are of a different opinion
[11:54] <seb128> mterry, but maybe back out the commit which added the indicator (please don't backout the new version totally)
[11:55] <didrocks> I'm seeing people not being to log in because of that (and nobody notice the indicator), the workaround isn't obvious
[11:55] <mterry> seb128, sure...
[11:55] <didrocks> able to*
[11:55] <didrocks> then, not my decision ;)
[11:55] <seb128> mterry, your call
[11:55]  * mterry distro patches out the indicator bits
[11:55]  * didrocks sees all the pressure on mterry :)
[11:56] <pitti> mterry: disabling just the indicator is fine; I agree, no need to revert the whole thing
[11:56] <mterry> Probably should have backed this out yesterday when we first heard of it.
[11:57]  * seb128 slaps mterry
[11:57] <seb128> mterry, you first heard of it during the rally when I was sitting next to you and trying to get you or robert to look at it :p
[11:57] <mterry> seb128, oh yeah.  :)
[11:58] <mterry> seb128, sorry, I guess I didn't realize the severity
[11:58] <didrocks> mterry: you weren't hearing from the french man? :)
[11:58] <seb128> mterry, I see how you zap what I say though :p
[11:58] <didrocks> seb128: I hope you note for next 380 :p
[11:58] <seb128> didrocks, he probably though "it's a french issue, who cares" ;-)
[11:58] <didrocks> 360° even
[11:58] <didrocks> ;)
[11:58] <didrocks> totally!
[11:59]  * pitti pats the One True Keyboard Layout: pc105/us
[12:00] <seb128> pitti, it's not a bug right, it's user education? ;-)
[12:00] <didrocks> what a lack of taste!
[12:00] <pitti> seb128: yeah; who could ever type on azerty? :-)
[12:00]  * pitti hugs seb128 and didrocks -- Vive la France!
[12:00] <pitti> ("Viva"?)
[12:01] <seb128> vive
[12:01] <pitti> il est difficile
[12:01] <seb128> le français? oui ;-)
[12:01] <pitti> yay, I got it right :)
[12:01]  * seb128 hugs pitti
[12:01]  * didrocks hugs pitti
[12:06] <didrocks> mterry: also, if you are aware about this code, it seems that the keyboard menu doesn't list the variants as well (which is annoying as the default french ubuntu keyboard is XKBLAYOUT="fr" XKBVARIANT="oss"
[12:06] <seb128> didrocks, you should open a new bug about that
[12:06] <didrocks> of course, some people like seb128 doesn't use … so they don't care, but that's just showing bad practices!
[12:06] <seb128> seems a bug in lightdm_get_layouts()
[12:06] <seb128> i.e for robert_ancell
[12:06] <didrocks> seb128: yeah, finishing my paperwork and will open a bug, then looking at this if mterry has no direct idea :)
[12:07] <didrocks> ok, robert's side, so will look :)
[12:07] <seb128> he's using libxklavier in a basic way
[12:07] <mterry> seb128, so is this bug!  :)
[12:07] <seb128> mterry, well I think the "WARNING: Getting layout failed" is on unity-greeter
[12:08] <seb128> or it's in the lightdm session environement
[12:08] <mterry> seb128, no, it's likely just from liblightdm-gobject
[12:08] <seb128> bad robert_ancell!
[12:08]  * mterry guesses (as we only interact with getting/setting keyboard through that lib
[12:08] <seb128> it's a bit weird that there is a dbusmenu error there though
[12:09] <seb128> lightdm doesn't use libdbusmenu does it?
[12:09]  * mterry looks at the error again
[12:10] <mterry> seb128, that's possibly an error with the other indicators (the ones that actually are dbusmenu objects -- the keyboard one isn't).  Note it just says 'getting layout failed' -- may be talking about the dbusmenu layout call
[12:11] <mterry> seb128, I'm just saying that unity-greeter itself does no layout code.  All that logic is inside liblightdm.  But you're right that dbusmenu being a part of that interaction would be weird
[12:12] <seb128> mterry, yeah, dunno, out of the fact that the unity-greeter in test mode run into my session return the correct layout
[12:12] <seb128> mterry, so the liblightdm-gobject side seems fine
[12:12] <seb128> something fails for some reason in the greeter session though
[12:12] <seb128> hum, lunch ready, be back in a bit
[12:12] <mterry> seb128, I wonder if we're not running some xkb daemon or something that we should be
[12:13] <seb128> mterry, I will add some printfs on the liblightdm side after lunch
[12:13] <seb128> but food first!
[12:13] <seb128> bbiab
[12:14] <mterry> seb128, didrocks, pitti: OK, uploaded new unity-greeter without the keyboard indicator
[12:14] <didrocks> mterry: thanks a lot! you will make some people happy
[12:14] <mterry> sorry for any problems I caused!  /me writes a blog post to let people know
[12:17] <didrocks> mterry: no worry, just add a "if you are french, here is my photo to print it and play darts" :)
[12:17]  * didrocks hugs mterry
[12:18] <nessita> hello all!
[12:24] <chrisccoulson> wow, i didn't realize that armhf was so much faster at building firefox than armel
[12:24] <chrisccoulson> 9 hours for a full build compared to 14 hours so far for armel, and it hasn't even started running the tests yet
[12:29] <seb128> re
[12:29] <seb128> nessita, hey, how are you?
[12:29] <seb128> ok, getting ride of my ubuntu vm
[12:29] <nessita> seb128: fine!
[12:29] <nessita> you?
[12:30] <seb128> nessita, quite ok, hating webkit though
[12:30] <seb128> it made me delete my vms
[12:30] <nessita> ouch!
[12:30] <seb128> webkit-1.7.4$ du -ksh .
[12:30] <seb128> 17G	.
[12:30] <seb128> nessita, that's my build tree which failed on ENOSPACE again
[12:31] <nessita> :-(
[12:31] <nessita> seb128: can' t you use a canonistack instance, or something like that?
[12:31] <seb128> nessita, but I think I will win this time
[12:31] <seb128> that's ok, easier to do local builds
[12:31] <nessita> I need help :-): my keyboard layout is acting up today. When I did the precise fresh install I' m running, I chose " English (international with dead keys") layout, and worked just fine until this morning, where I lost the " internation with dead keys"  support. I tried re-choosing the layout, but it did not fix it, I also try logout and login, and nothing
[12:31] <seb128> nessita, how are you?
[12:32] <nessita>  seb128: good, but with a screwed up keyboard layout :-P
[12:32] <seb128> nessita, try the new unity-greeter mterry uploaded
[12:32] <seb128> nessita,
[12:32] <seb128> https://launchpad.net/ubuntu/precise/+source/unity-greeter/0.2.0-0ubuntu4
[12:32] <mterry> But you can log in fine...  might not be the unity-greeter problem
[12:32] <nessita> seb128: so is "ok"  to have lost the keyboard layout?
[12:33] <nessita> yes, I can login just fine
[12:33] <seb128> mterry, no, apparently lightdm apply the layout selected on the greeter to the session or something it seems
[12:33] <seb128> well that's what didrocks was complaining about
[12:33] <mterry> k
[12:34] <nessita> seb128: right, I tried to choose en + dead keys on the greeter and I couldn' t
[12:34] <seb128> right
[12:34] <seb128> didrocks said he would open a bug about that
[12:34] <nessita> nice
[12:37]  * nessita apt-get upgrades and sees the unity-greeter update
[12:37] <seb128> nessita, not enough, the newest one didn't build yet
[12:37] <didrocks> already?
[12:37] <didrocks> yeah, shouldn't be that one :)
[12:38] <seb128> nessita, well what arch do you use?
[12:38] <didrocks> hey nessita!
[12:38] <nessita> seb128: us.archive
[12:38] <nessita> hola didrocks!
[12:38] <seb128> nessita, no, i386 or amd64?
[12:38] <nessita> amd64
[12:39] <seb128> ok, not build yet there
[12:39] <seb128> see the url I gave you
[12:39] <seb128> nessita, the build should start in 1 min: https://launchpad.net/ubuntu/+source/unity-greeter/0.2.0-0ubuntu4/+build/3107652
[12:40] <nessita> seb128: ack, will re-update when is done. Thanks!
[12:40] <seb128> nessita, yw
[12:56] <mterry> nessita, build done, btw
[12:56] <nessita> yey!
[13:01] <tkamppeter> pitti, liblcms2 migration for CUPS (in new package cups-filters) is done upstream.
[13:05] <mterry> seb128, is your home directory world-readable?
[13:06] <pitti> tkamppeter: yay
[13:09] <seb128> re
[13:09] <seb128> hum
[13:10] <seb128> mterry, no, it's 700 user:user
[13:10] <pitti> why do we need the user's home directory?
[13:11] <seb128> pitti, to read the user keyboard layout config?
[13:11] <mterry> seb128, pitti: looks like the user's keyboard layout is in ~/.dmrc and not exposed via accountsservice.  Which is why seb128 was seeing a difference between test mode and real mode
[13:11] <pitti> you can't rely on the users home dir until after you type the password
[13:11] <pitti> it may be on NFS, ecryptfs, or what not
[13:11] <seb128> pitti, right, so we likely need to move that info in accountsservice
[13:11] <pitti> right
[13:11] <mterry> So that's why per-user keyboard layout wasn't working for everyone (a separate bug is the fact that fallback to system was always "us")
[13:11] <pitti> old gdm used /var/cache/gdm/<username>/dmrc
[13:12] <pitti> but if accountsservice caches it, so much the better
[13:12] <pitti> it doesn't right now, though
[13:13] <seb128> mterry, ok, I can confirm that copying my .dmrc to my test user which has its dir world readable "fixes" the issue
[13:13] <pitti> I'm actually quite surprised that Robert added a keyboard indicator again
[13:13] <seb128> i.e the user get a "fr" keymap when selected
[13:13] <pitti> I thought he was glad to get rid of all taht complexity
[13:13] <seb128> pitti, he didn't, mterry did ;-)
[13:13] <pitti> drwxr-xr-x 22 test test 4096 Jan 20 08:49 /home/test/
[13:13] <pitti> didn't work for taht one
[13:13] <seb128> pitti, do you have a keymap in .dmrc?
[13:14] <pitti> keyboard layout isn't saved in .dmrc
[13:14] <pitti> it's in gsettings
[13:14]  * mterry keeps getting blamed for this  :)
[13:14] <seb128> pitti, I've Layout=fr in my .dmrc
[13:14] <pitti> org.gnome.libgnomekbd.keyboard layouts
[13:14] <pitti> seb128: that's still from gdm 2
[13:14] <seb128> pitti, right, well that's what lightdm reads
[13:14] <seb128> no wonder it doesn't work ;-)
[13:14] <pitti> gdm 3 dropped it, so c-c doesn't put it there any more
[13:15] <pitti> org.gnome.libgnomekbd.keyboard layouts ['us', 'de\tnodeadkeys']
[13:15] <seb128> pitti, if only we had a clear spec for those things :-(
[13:15] <pitti> that's e. g. the value for me
[13:15] <seb128> pitti, that's GNOME specific though?
[13:15] <seb128> pitti, where lightdm tries to be desktop neutral
[13:15] <pitti> yes; there is no X.org standard for where to put them :(
[13:15] <pitti> nor fd.o
[13:15] <seb128> imho accountsservice seems the right place
[13:16] <pitti> I don't think KDE or XFCE use that either, thuogh
[13:16] <pitti> there is a reason why gdm 2 was so utterly complex :)
[13:16] <seb128> pitti, right, well we don't have any framework yet so we need to figure one
[13:16] <pitti> seb128: I like the accountsservice idea
[13:16] <seb128> me too ;-)
[13:17] <pitti> it's closest to something which all desktops _could_ use and which doesn't come with huge dependencies attached
[13:17] <pitti> it's just that it isn't being used much outside of gnome yet ..
[13:19] <mterry> seb128, pitti: OK, using bug 915468  to keep track of that (and percolating that through lightdm)
[13:19] <ubot2> Launchpad bug 915468 in unity-greeter "the unity-greeter keyboard's selection doesn't respect the user config" [High,Fix released] https://launchpad.net/bugs/915468
[13:19] <seb128> pitti, well, that's not an issue, we are already (ab)using it
[13:19]  * mterry now looks at system default layout
[13:19] <seb128> i.e we already store stuff like the language and user background there
[13:20] <pitti> mterry: system default layout is /etc/default/keyboard, but as you can change it in xorg.conf, I think it's best if you query the _XKB_RULES_NAMES property on the root window
[13:20] <pitti> and take the first layout/variant there
[13:20] <pitti> $ xprop -root _XKB_RULES_NAMES
[13:20] <pitti> _XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us,de", ",nodeadkeys", "terminate:ctrl_alt_bksp,grp:shifts_toggle"
[13:20] <mterry> pitti, there's not an xkl_* api for that?
[13:20] <pitti> mterry: if you already use libxklavier, it makes that quite easy to read, too
[13:22] <pitti> mterry: yes, xkl_config_rec_get_from_server, there you have the "model", "layouts", "variants"
[13:23] <mterry> pitti, you mean, via xkl_config_rec_get_from_root_window_property ?
[13:23] <pitti> looks right :)
[13:23] <mterry> pitti, or via XklConfigRegistry probs...
[13:24] <pitti> in GI I actually used rec = Xkl.ConfigRec()
[13:24] <pitti> rec.get_from_server(engine)
[13:24] <pitti> print rec.layouts
[13:24] <mterry> pitti, interesting...  I don't see how that maps to the C api
[13:25] <pitti> told you: xkl_config_rec_get_from_server() :)
[13:25] <mterry> pitti, http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk/view/head:/liblightdm-gobject/layout.c#L59
[13:25] <mterry> is the current code
[13:25] <pitti> I believe that's the right API
[13:25] <mterry> and we use the first return to be the default
[13:26] <mterry> pitti, I get that part.  But XklConfigRec doesn't seem to have a layouts property
[13:26] <pitti> that looks right
[13:26] <mterry> pitti, well, the first is apparently always "us" for seb and friends
[13:27] <pitti> seb128: what does this show for you: xprop -root _XKB_RULES_NAMES
[13:27] <seb128> pitti, guess that I should run that on the greeter right?
[13:28] <pitti> we are meant to have udev rules which read /etc/default/keyboard and slam them to the evdev devices, and X.org gets the default layouts from there
[13:28] <pitti> seb128: or a fresh user
[13:28] <mterry> seb128, maybe.  Do you know if the greeter returns different values for the system layout if you run it in testing or real mode?
[13:28] <pitti> seb128: at least anything NOT using the keyboard indicator :)
[13:28] <pitti> as that seems to override it
[13:29] <pitti> mterry: it isn't possible that you run this when the greeter already set a new default to the X server?
[13:30] <seb128> pitti, evdev pc105 fr oss
[13:30] <Sweetshark> pitti: drats, I think I changed the tarballs again by accident. Could you do me the favour of fixing the dsc and resigning it, if it is not too much of a hassle? I would love to get a 3.5.0rc1 ppa upload ready still for http://blog.documentfoundation.org/2012/01/17/tdf-announces-the-second-bug-hunting-session-to-put-first-release-candidate-of-libreoffice-3-5-on-the-test-bench/
[13:30] <seb128> in my test user session
[13:30] <mterry> pitti, not in my testing I don't believe
[13:30] <pitti> mterry: I don't understand that code
[13:30] <pitti> mterry: where does it actually _use_ xkl_config ?
[13:30] <mterry> pitti, in layout_cb (it calls foreach_layout)
[13:30] <pitti> mterry: AFAICS this returns all available layouts, I presume it uses that to fill the indicator menu for switching layouts?
[13:31] <mterry> pitti, and it saves the names of the layouts
[13:31] <mterry> pitti, yeah
[13:31] <pitti> oh, yay global variables
[13:31] <mterry> pitti, and the first in the list is assumed to be the default
[13:31] <pitti> yes, that's right
[13:31] <pitti> seb128: that looks right
[13:32] <pitti> Sweetshark: I'll try
[13:32] <pitti> mterry: I still don't see where you use xkl_config
[13:33] <pitti> mterry: that layout is for the registry iterator, and it only uses item ?
[13:33] <mterry> pitti, xkl_config_registry_foreach_layout
[13:33] <pitti> ooh!
[13:33] <pitti> that's where the problem is
[13:33] <pitti> mterry: xkl_config_registry_foreach_layout is NOT the list of configured layouts
[13:34] <pitti> it's the list of available layouts
[13:34] <pitti> mterry: xkl_config->layouts is the list of configured layouts
[13:34] <pitti> mterry: use the xkl_config_registry_foreach_layout to fill the available layouts for the indicator
[13:34] <pitti> xkl_config->layouts[0]/xkl_config->variants[0] is the default layout
[13:35] <pitti> it's best not to touch it at all unless the user actively selects something different
[13:35] <didrocks> ah, that would probably fix the "variant" issue :)
[13:35] <pitti> xkl_config_registry_foreach_layout always starts with "us"
[13:35] <mterry> pitti, OK, nice.  But http://developer.gnome.org/libxklavier/5.1/XklConfigRec.html never mentions the ->layouts field...  :-/
[13:36] <mterry> Guess I had to dig into .h files
[13:36] <mterry> didrocks, no, to fix that, I think we have to use xkl_config_registry_foreach_layout_variant
[13:36] <seb128> mterry, is there a design somewhere for that indicator?
[13:37] <mterry> pitti, what do you mean by touch it at all unless user actively selects something different?
[13:37] <didrocks> mterry: yeah, indeed
[13:37] <mterry> seb128, I don't think so?
[13:37] <seb128> mterry, listing hundred of keymaps doesn't seem well thought
[13:37] <didrocks> mterry: do you want me to assign the bug to you?
[13:37] <pitti> mterry: xkl_config_rec.h has the struct, FYI
[13:37] <pitti> mterry: I mean, users could set complicated options or variants you don't cover in the indicator
[13:37] <mterry> pitti, that'll learn me to rely on documentation :)
[13:38] <pitti> best not to break it until the user actively goes and changes it
[13:38] <seb128> pitti, mterry: ok, with the new version mterry uploaded without indicator the greeter XKB_RULES_NAMES is fr oss as well for me
[13:38] <seb128> so that bit seems fine
[13:38] <pitti> i. e. only export the GDM_KEYBOARD (or whatever it was, don't remember) if the user changed it
[13:38] <mterry> seb128, because we avoid touching anything in that version
[13:38] <seb128> mterry, right, I'm just saying that xorg set it right
[13:38] <seb128> mterry, so it's back to what pitti and you are discussing
[13:38] <mterry> pitti, well, we have to keep setting the keyboard to whatever each user has
[13:38] <seb128> it was just a piece of info ;-)
[13:39] <pitti> mterry: why?
[13:39] <pitti> mterry: oh, you mean for the password, yes
[13:39] <mterry> pitti, when a new user is selected in the carasoul
[13:39] <mterry> yeah
[13:39] <pitti> the session will set it up by itself
[13:39] <mterry> seb128, I asked robert about the design and he indicated there wasn't one
[13:40] <mterry> whole thing is apparently half baked
[13:40] <seb128> mterry, well I guess if we fix the "read user config" and the "get correct default" very few users will need to the use the long indicator list
[13:42] <pitti> frankly, I still think we shouldn't have an indicator at all
[13:42] <seb128> pitti, do you think we should read the user config?
[13:42] <pitti> if the user can type the password with his default layout, that addresses the main issue
[13:42] <seb128> well from accountsservice that's it
[13:43] <mterry> pitti, seb128: thanks for the pointers.   I'll talk to Rob to see who will code these bits up
[13:43] <seb128> pitti, having an indicator doesn't hurt, it tells you what layout is active and let you change it if needed
[13:43] <pitti> yes, we'd need that if we want to allow users to type their passwords on their layout instead of teh system default one
[13:43] <didrocks> I think what pitti is telling makes sense
[13:43] <mterry> pitti, well, that's going to be automatic
[13:43] <pitti> seb128: yes, but changing it involves writing it back to the user config, at which point it gets hairy
[13:43] <seb128> or not, it could just you overwrite it in a temporary way
[13:43] <pitti> I guess there's no harm in displaying the current layout, to clarify what you are typing
[13:44] <seb128> pitti, think "other" login for i.e nfs login
[13:44] <pitti> seb128: yeah; defining the "write back config" semantics there is pretty hairy
[13:44] <seb128> there are cases where we will not be able to get the value for the user
[13:44] <seb128> no need to "write back"
[13:44] <pitti> if we can, we should use it, otherwise just use the system default layout
[13:44] <seb128> we can just make the indicator define the current layout to type the password
[13:45] <pitti> seb128: but if you allow changing the layout in the greeter, but then not use it in the session, that feels like a bug, too
[13:45] <seb128> users usually have their session fine
[13:45] <seb128> pitti, no, think rather nfs
[13:45] <seb128> the layout is probably well configured in the session
[13:45] <pitti> sure
[13:45] <seb128> the greeter has just no access to the user config
[13:45] <pitti> sometimes, yes
[13:45] <seb128> so it can still be useful to manually select a keymap to be able to enter your password
[13:46] <seb128> only would it be for the login screen
[13:46] <pitti> hmm
[13:46] <seb128> imho the indicator doesn't hurt
[13:46] <pitti> well
[13:46] <seb128> it gives you feedback on what is the selected keymap which is good
[13:46] <pitti> it does if it can't read your config and selects the wrong layout
[13:46] <seb128> right we all agreed that's a bug and will be fixed
[13:46] <pitti> but I guess that's fixed with getting the correct system default
[13:47] <seb128> I think once we get the correct default and read the value for accountsservice for users we will be fine in 99% of the cases
[13:47] <seb128> having the indicator or not then doesn't matter much, though I like having a visual clue of the active keymap
[13:47] <seb128> the lock screen does display it as well
[13:50] <pitti> yes, we agree there -- reading and displaying the current layout sounds fine
[13:50] <pitti> it just gets more complicated when you allow the user to change it
[13:52] <seb128> right, well I think we don't need a lot
[13:52] <seb128> just make the indicator change the layout for the active greeter
[13:52] <seb128> doesn't bother about config or anything
[13:52] <seb128> same story as the language selection, users that need to fix their session layout can do it in g-c-c after login
[13:54] <desrt> good morning
[13:54]  * pitti tosses some chocolate to desrt
[13:54] <desrt> pitti: actually, i keep meaning to ask for cookies
[13:55] <desrt> now that you mention it :)
[13:56] <pitti> hmm, cookies all gone here :(
[13:56] <seb128> desrt, hum, cookies, that's something which is missing at european rallies!
[13:56] <seb128> desrt, hey btw ;-)
[13:56] <pitti> desrt: actually, we still have a fair number of christmas cookies left over indeed
[13:57] <desrt> pitti: there is a store in germany, rewe
[13:57] <desrt> and these sell these 'knusper-gebäck' cookies
[13:57] <pitti> I know it; I used to buy my stuff there in Dresden
[13:57] <desrt> (store brand)
[13:58] <desrt> http://www.richrath-express.de/suesswaren-gebaeck-snacks/rewe-knuspergebaeck-mit-korinthen.html
[13:58] <desrt> i had a rather intense affair with them when i was in bremen
[13:59] <desrt> seb128: looks like the thread caught a bit of traction, but most people are dancing around the issue
[13:59] <pitti> desrt: I used to have numerous of those: http://www.richrath-express.de/suesswaren-gebaeck-snacks/rewe-chocolade-cookies.html :)
[13:59] <seb128> desrt, yeah, I'm about to reply
[13:59] <desrt> those look just like plain chocolate chip cookies
[13:59] <pitti> they are
[13:59] <desrt> boring :p
[13:59] <desrt> you can get those anywhere :)
[14:00] <desrt> although they do look rather tasty...
[14:00] <desrt> i think i should ask benjamin to bring some of these to the gtk hackfest :)
[14:00] <pitti> desrt: not the stuff we make ourselves each year, though! https://www.piware.de/fotos/Adventsbacken-2003/2.html
[14:00] <desrt> pitti: naught ssl certificate!
[14:00] <desrt> *naughty
[14:01] <pitti> yeah, I know..
[14:01] <pitti> erm, https:// ?
[14:01] <desrt> crikey.
[14:01] <pitti> http:// is fully sufficient
[14:01] <desrt> that's pretty intense
[14:01] <desrt> my mother is a big christmas-time cookie maker but usually not so many different varieties
[14:02] <desrt> mostly sticking to the gingerbreads and shortbreads... maybe some peanutbrittle on the side
[14:02] <pitti> desrt: well, back then we used to be about 10 people, so we got lots of stuff and a nice variety
[14:05]  * didrocks is waiting for cookies, the tea is already ready :)
[14:06] <pitti> Sweetshark: ok, tried again after some manual .dsc/.changes surgery; let's ssee
[14:06] <seb128> desrt, ok, replied on the GNOME list
[14:07] <desrt> party
[14:07] <dobey> well at least it's not a godaddy cert
[14:07] <seb128> desrt, basically it would be great if GNOME could define the new interfaces it will rely on in the next cycle with protocol details a cycle in advances imho
[14:07] <desrt> seb128: hahahah
[14:07] <desrt> right
[14:08] <desrt> that would require that we have the ability to take decisions in public
[14:08] <seb128> desrt, to let integrator the time and the possibility to adapt their schedule to provide those
[14:08] <desrt> :)
[14:08] <seb128> desrt, well, how do you want integrators to do a decent job in integrating GNOME if you don't tell them in advance what GNOME will require to be working
[14:09] <desrt> seb128: no.  i agree.
[14:09] <desrt> i'm just saying that we're a bit dysfunctional with respect to the ability to do things like this at the moment
[14:09] <seb128> desrt, "oh, you need to track git commits and then revise track the protocols you need to implement, oh at any time of the cycle of course"
[14:09] <desrt> i'm wondering what the heck happened to the release team's processes for this, for example
[14:09] <seb128> revise->reverse
[14:09] <seb128> desrt, yeah
[14:10] <seb128> desrt, would really rock as well to have a document describings the apis the system should provide for GNOME to be fully working
[14:10] <seb128> like what kernel version you should have
[14:10] <seb128> what dbus services
[14:10] <seb128> etc
[14:10] <desrt> dbus?  i need dbus for gnome?
[14:10]  * desrt refuses
[14:10] <pitti> *cough* GNOME OS *cough*
[14:10] <seb128> ;-)
[14:10]  * chrisccoulson waits for the flamewar to begin
[14:11] <desrt> pitti: ya.  exactly, actually.
[14:11] <desrt> if anyone would actually define what that means, all the world's problems would be solved
[14:11] <pitti> but in GNOME's defense, they actually did broadcast the need for systemd APIs quite early
[14:11] <pitti> we have known that this was coming
[14:11] <seb128> pitti, not really
[14:11] <desrt> pitti: i'm not sure we ever did so in any official capacity
[14:11] <pitti> desrt: no, certainly not
[14:11] <desrt> we chatted that we might want to do it
[14:11] <seb128> there was some list discussions with disagreement
[14:11] <desrt> but nobody ever said "okay.  this is the plan"
[14:11] <seb128> no project consensus
[14:12] <pitti> desrt: it just reminded me of John's presentation at plumber's, that gnome os should be one official set of versions, dependencies, kernel, etc.
[14:12] <desrt> that's the continuing failure of the gnome project to have any sort of leadership taking hard (as in concrete) decisions
[14:12] <desrt> pitti: yes.  that's absolutely the right idea.
[14:12] <desrt> and we should be able to grow that as it suits us
[14:12] <pitti> for GNOME OS, anyway
[14:12] <desrt> but we should at least write it down somewhere ffs
[14:13] <pitti> it's certainly not what integrators want who treat GNOME as a platform, not as an OS
[14:13] <seb128> desrt, what is "fun", is if GNOME OS decide systemd is part of the system depends and Ubuntu is upstart based, does it mean GNOME would expect Ubuntu to not ship GNOME?
[14:13] <dobey> i can't help but LOL at "GNOME OS"
[14:13] <desrt> seb128: i raised that question from another direction in my mail
[14:13] <pitti> Sweetshark: ok, third time's the charm
[14:13] <desrt> "what about our own end-users who want to install the latest GNOME on their ubuntu boxes?"
[14:14] <dobey> if only for all the "GNOME OS" discussions in 2003
[14:14] <dobey> and then came Ubuntu, the gnome os
[14:14] <chrisccoulson> i can imagine that the suggestion will probably be "install fedora", won't it?
[14:14] <desrt> dobey: then you guys went to the dark side :p
[14:14] <seb128> desrt, I'm really pondering if rather than your gnome_me_harder we should just stop providing GNOME in Ubuntu and saying that Ubuntu doesn't match the requirements to ship GNOME
[14:14] <desrt> seb128: i'd be okay with that
[14:15] <seb128> we could stop bothering about breaking the upstream experience then and just deal with our packages
[14:15] <desrt> seb128: but i'd insist that you stay out of debian's namespace for our packages
[14:15] <dobey> desrt: or GNOME did ;)
[14:15] <seb128> desrt, lol
[14:15] <desrt> i'm serious
[14:15] <desrt> if you want to fork nautilus, do it properly
[14:15] <nessita> hey, does anyone know how to "convert" from pygtk to pygobject the function gtk.link_button_set_uri_hook (http://www.pygtk.org/docs/pygtk/class-gtklinkbutton.html#function-gtk--link-button-set-uri-hook)?
[14:15] <desrt> ditto the rest of them
[14:15] <seb128> desrt, you want your cake and eat it
[14:16] <desrt> ubunautilus
[14:16] <seb128> desrt, what's the point since in that case Ubuntu can't and will not ship GNOME so we don't hijack any namespace that would be useful to others
[14:16] <dobey> forking nautilus would be a waste
[14:16] <desrt> seb128: because someone else would
[14:17] <seb128> desrt, not likely if i.e our init system is incompatible
[14:17]  * kenvandine doesn't like the sound of this conversation :)
[14:17] <pitti> nessita: I think that disappeared from GTK #
[14:17] <desrt> seb128: that's not the case right now and you know it :p
[14:17] <pitti> nessita: whoops, "GTK 3"
[14:17] <seb128> desrt, well that's where we are heading to
[14:17] <seb128> kenvandine, hey
[14:17] <desrt> seb128: not really
[14:17] <nessita> pitti: ack, thanks, will workaround that somehow
[14:17] <kenvandine> hey seb128
[14:17] <seb128> kenvandine, come on, it's friday, it's trolling day ;-)
[14:17] <desrt> we're heading to various bits stop working properly on upstart, and they can be fixed
[14:17] <kenvandine> hehe
[14:18] <pitti> was just gonna say -- must be Friday afternoon :)
[14:18] <desrt> i'm not saying that you have any responsibility to fix them
[14:18] <desrt> but someone may want to do the work
[14:18] <desrt> maybe debian will
[14:18] <seb128> desrt, that would work if GNOME was being honest on their requirement, publishing them in advance and letting time to integrator to do their work
[14:18] <kenvandine> is this sparked by the ddl thread and systemd?
[14:18] <seb128> desrt, but let's see how that discussion goes
[14:18] <seb128> kenvandine, yes
[14:18] <desrt> kenvandine: a codevelopment, recently
[14:19] <desrt> seb started this last night
[14:19] <seb128> kenvandine, I was just pushing the logic further on the path for the sake of the discussion
[14:19] <kenvandine> seb128, makes sense... it is the general direction
[14:19] <desrt> (that's where the friday part comes in)
[14:19] <seb128> kenvandine, http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=27fa171efe4179c0a42ec79e0dc501077f042a08
[14:20] <seb128> kenvandine, that's what started the discussion basically
[14:20] <desrt> seb128: from a practical standpoint, there will never be a g_assert(systemd_is_running())
[14:20] <desrt> at most, you could imagine some mandatory library dependency in order to build a particular component
[14:20] <desrt> and systemd doesn't seem to roll that way, in general
[14:20] <kenvandine> seb128, saw that... which drives us to fork
[14:21] <seb128> desrt, right, but sneaking changes that made GNOME not work well on non systemd system the way it's currently done is not giving a fair chance to distributors to do their job well
[14:21] <desrt> seb128: no argument from me there
[14:21] <desrt> seb128: i'm just not buying into your slippery slope argument
[14:21] <seb128> it's a friday troll argument ;-)
[14:21] <seb128> not sure I'm buying into it either
[14:21] <desrt> oh.  in that case, i fully believe it :D
[14:22] <seb128> hehe
[14:22]  * desrt sends more mails to d-d-dl
[14:22] <desrt> er.  d-d-l
[14:23] <pitti> Sweetshark: hah, I convinced Soyuz to take it, accepted now
[14:26] <smspillaz> desrt: you can download the desktop devel ? (har har har)
[14:26] <nessita> pitti: would you know about former gtk.STATE_*? (I mean, how that translates to new pygobject stuff)
[14:27] <pitti> nessita: do you have an example STATE_* value?
[14:27] <nessita> yes
[14:27] <pitti> nessita: presumably Gtk.StateFlags.NORMAL
[14:27] <nessita> an_entry.modify_text(gtk.STATE_NORMAL, some_color)
[14:27]  * desrt downloads smspillaz's car
[14:27] <pitti> nessita: FYI, it's rather easy to look up C symbols in /usr/share/gir-1.0/Gtk-3.0.gir and see what the corresponding class/member is
[14:28] <desrt> smspillaz: btw, as of last night, our dreams of gsettings are really really really dead
[14:28] <desrt> maybe for a while...
[14:28] <nessita> pitti: awesome! that looks like it. I will check out that :-)
[14:28] <smspillaz> desrt: oh ?
[14:28] <smspillaz> desrt: you wouldn't want to download my car
[14:28] <smspillaz> desrt: its slow
[14:28] <smspillaz> and french
[14:28] <desrt> smspillaz: upstream change to gnome-settings-daemon to require systemd, more or less
[14:28]  * smspillaz runs from seb128 
[14:29] <seb128> ok, I wonder if mvo would hate me if I upload a webkit breaking s-c on friday afternoon
[14:29] <desrt> will require some extra work to get it going on ubuntu again
[14:29] <smspillaz> desrt: so I heard that ubuntu will be using KDE from now on
[14:29] <desrt> smspillaz: funny.  i heard compiz. :)
[14:29] <smspillaz> desrt: I realized that KDE had GNOME name envy yesterday
[14:29] <smspillaz> The GNUs Not Unix Network Object Model Environment vs
[14:30] <mvo> seb128: more than already you mean ;) ?
[14:30] <smspillaz> The Kool Desktop Environment Software Compilation Plasma Workspaces
[14:30] <mvo> seb128: in what way will it break?
[14:30] <seb128> mvo, ;-)
[14:30] <seb128> mvo, segfault on start
[14:30] <mvo> seb128: actually I wanted to upload a new apt too right before the weekend
[14:30] <desrt> i prefer to think of the G in gnome as standing for 'gtk'
[14:30] <desrt> it's a lot more fun that way
[14:30] <smspillaz> desrt: I was going to say that
[14:30]  * desrt gotta run
[14:31] <smspillaz> The GNUs Not Unix Image Manipulation Program Tool Kit Network Object Model Environment
[14:31] <smspillaz> YES
[14:31] <seb128> desrt, see you later ;-)
[14:31] <smspillaz> I vote that this is how we refer to GNOME from now on
[14:41] <seb128> typical bastienr reply... ;-)
[14:41] <seb128> "This particular change was mentioned nearly a year ago on this very same
[14:41] <seb128> list. It's not my fault Ubuntu (in this particular case) didn't take the
[14:41] <seb128> hint to start packaging the relevant D-Bus services, or rewriting them
[14:41] <seb128> to fit their use."
[14:44] <seb128> mvo, http://pastebin.ubuntu.com/810740/
[14:44] <seb128> mvo, s-c segfault
[14:47] <nessita> pitti: if I method that I used to use on gdk (window_foreign_new) is not in the /usr/share/gir-1.0/Gdk-3.0.gir, it means is not available?
[14:48] <pitti> nessita: yes, I'm afraid so
[14:49] <pitti> nessita: at this point it touches the raw X libs, which are poorly introspectable
[14:49] <nessita> pitti: would you know how can I make a gtk window transient for another from which I have the window xid?
[14:49] <nessita> (using gi, of course)
[14:49] <pitti> nessita: no, that doesn't work through GI
[14:49] <dobey> nessita: even things that you see in the gir may not be available.
[14:49] <pitti> nessita: we have a few cases like that, we had to disable that functinality
[14:50] <nessita> ok, disabling it as well in SSO then
[14:50] <nessita> pitti, dobey: thanks!
[14:50] <pitti> nessita: sometimes the .gir has a flag "introspectable=0" which means it's not available
[14:50] <nessita> ack
[14:50] <mvo> seb128: woah, I have not the slightest idea about this one
[14:50] <pitti> nessita: oh, hang on
[14:50]  * nessita hangs
[14:50] <pitti> nessita: foreign_new_for_display is the Gdk 3.0 API
[14:50] <pitti> nessita: that's in /usr/share/gir-1.0/GdkX11-3.0.gir
[14:50] <seb128> mvo, yeah, me neither, I guess I will just put webkit in the desktop ppa for today
[14:51] <nessita> pitti: let's see... will let you know
[14:52] <nessita> pitti: and that should be imported as "from gi.repository import GdkX11"?
[14:53] <nessita> yes! I tried before and did not work, I may have a typo
[14:53] <pitti> nessita: yes
[14:54] <pitti> nessita: still, take that with a grain of salt; X11 itself isn't introspectable much, so you might find a lot of low-level things not working
[14:54] <nessita> right
[14:57] <Sweetshark> pitti: thanks!
[14:58] <desrt> you know it's a good thread when you can start reading the mails in realtime
[15:01] <chrisccoulson> i think i've read enough of that thread now ;)
[15:01] <pitti> frankly it seems a little wasted to me -- we just need to add the interfaces to ubuntu-system-service, and be done with it?
[15:01] <pitti> Bastien won't do that for us
[15:02] <didrocks> phew, all paperwork finished \o/
[15:02] <pitti> didrocks: ... forever? :)
[15:02] <didrocks> pitti: ever *ever*
[15:02] <didrocks> :)
[15:02] <pitti> I want that, too!
[15:02] <didrocks> hum no, didn't claim my expenses for the rally :p
[15:02] <didrocks> but that's nothing to do
[15:03] <didrocks> pitti: if you want to reread the release process, as you found it a little bit heavy: https://wiki.ubuntu.com/Unity/ReleaseProcess
[15:03] <didrocks> (no hurry though)
[15:03] <pitti> ah, can do
[15:03] <pitti> didrocks: speaking of paperwork, I'm currently prep'ing the release meeting
[15:03] <pitti> need to drive today
[15:03] <didrocks> good luck :)
[15:04] <smspillaz> didrocks: seb128 : dpkg-source: info: local changes detected, the modified files are: compiz/.bzr-builddeb/default.conf
[15:04] <smspillaz> dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/compiz_0.9.6+bzr20120120-1-0ubuntu1~ppa1.diff.ESQcGB
[15:05] <smspillaz> any way I can make dpkg ignor ethat ?
[15:05] <smspillaz> or debuild rather ?
[15:05] <didrocks> smspillaz: just for testing?
[15:05] <smspillaz> as in when building packages
[15:05] <didrocks> smspillaz: remove debian/source
[15:05] <smspillaz> every time I do debuild -S I have to move .bzr-builddeb/default.conf out of the way
[15:06] <didrocks> smspillaz: yeah, remove that directory
[15:06] <desrt> pitti: are you volunteering? :)
[15:06] <smspillaz> ok. will that break if I upload a ppa ?
[15:06] <didrocks> source 3 is quite annoying for local changes
[15:06] <didrocks> smspillaz: no no, should be fine, do we have distro patches?
[15:07]  * desrt gets off streetcar, back in a few mins
[15:07] <smspillaz> didrocks: don't think so
[15:07] <didrocks> smspillaz: if we have some, in this case, after removing it, please replace in debian/rules dh $@ by dh $@ --with quilt
[15:07] <smspillaz> ok
[15:09] <Kaleo> what's the plan for the music lens in 12.04?
[15:10] <didrocks> I think dobey is the one carrying the item :)
[15:10] <dobey> eh?
[15:11] <didrocks> dobey: I think that we discussed that on the session, isn't it?
[15:11] <didrocks> that if we drop banshee, it needs:
[15:11] <didrocks> - a store for rhythmbox
[15:11] <didrocks> - a scope for the lens
[15:12] <dobey> davidcalle said he would make the lens work with rb
[15:12] <didrocks> ok, let's wait for him them :)
[15:13] <seb128> pitti, <pitti> frankly it seems a little wasted to me -- we just need to add the interfaces to ubuntu-system-service, and be done with it?
[15:13] <seb128> pitti, the issue is not that specific interface
[15:13] <didrocks> dobey: and the store for rhythmbox is in good hands ?
[15:14] <pitti> desrt: it's a Q matter anyway at this point?
[15:14] <seb128> pitti, it's that GNOME should have a clear platform definition, i.e a list of the interfaces GNOME needs to work properly, and publish that list somewhere official a cycle in advance
[15:14] <pitti> desrt: frankly, I'd rather volunteer to introduce systemd in Q :)
[15:14] <dobey> didrocks: yes
[15:14] <seb128> pitti, or we will need to keep running into those issues
[15:14] <pitti> but yes, it can't be too hard; I can take implementing that in Q
[15:14] <pitti> seb128: yes, I don't disagree
[15:15] <pitti> but we both know that this thread won't convince Bastien to revert it
[15:15] <seb128> pitti, no, I don't aim at that
[15:15] <seb128> pitti, I aim at GNOME taking a stance that they will publish their platform requirements
[15:15] <seb128> pitti, and do it one cycle in advance if possible
[15:15] <seb128> not one month before feature freeze
[15:15] <pitti> and we ourselves also didn't do any official statement about systemd in the ubuntu future either
[15:15] <pitti> yes, that would certainly help
[15:16] <seb128> pitti, that's orthogonal, it's not only about Ubuntu
[15:16] <seb128> pitti, Debian will have the same issue, they wanted 3.4 in wheezy
[15:16] <seb128> but they have neither ubuntu-system-services nor systemd by default
[15:18] <davmor2> hey guys is it me or is the nautilus bread crumb trail ugly in P
[15:19] <seb128> davmor2, https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/917830
[15:19] <ubot2> Launchpad bug 917830 in light-themes "Breadcrumbs using light background color unless focused or hovered over with cursor" [Undecided,Confirmed]
[15:19] <dobey> davmor2: looks like there's maybe a theme issue, but i'd say it's ugly in any version :)
[15:19] <seb128> talk to Cimi ;-)
[15:20] <davmor2> seb128: I figured it would be known if it was more than just mine, thanks
[15:20] <dobey> GtkPathBar is just not a great widget
[15:25] <pitti> didrocks: https://wiki.ubuntu.com/Unity/ReleaseProcess sounds nice
[15:26] <pitti> didrocks: oh, don't get me wrong -- I wasn't saying that I find the process bloated in any way; just that one full release week every two weeks might unnecessarily slow down upstream development?
[15:27] <didrocks> pitti: well, it's a freeze period, they can still continue to develop and ack branches
[15:27] <didrocks> it's just not entering trunk
[15:27] <davidcalle> dobey, didrocks : branch coming next week.
[15:28] <didrocks> davidcalle: awesome \o/
[15:28] <didrocks> pitti: but yeah, maybe we can't maintain a 2 weeks cadence with that
[15:29] <didrocks> let's see how it goes, at least, we have a block period of 24 hours of test needed
[15:29] <didrocks> then the first part and the loopback part depends on the quality of trunk
[15:29] <dobey> didrocks: for major releases, such an exhaustive process might make sense. but for point releases every two weeks, it does seem a bit much
[15:29] <didrocks> so, can be half a day or 2 days…
[15:29] <didrocks> dobey: well, with the distro criterias, we need to have such a process right now
[15:30] <didrocks> (of course, for a one commit post-release fix, this isn't expected to go through this process)
[15:31] <dobey> i mean if you have releases every 2 weeks, you don't need that much. maybe for every 2 months, sure. but some things should be a constant (testing), and some things should be shorter (freezes)
[15:32] <seb128> desrt, interesting question related to this dbus services discussions
[15:32] <desrt> seb128: i encourage you to ask it on-list, then :)
[15:32] <dobey> for instance, with u1, we do releases every 2 weeks (aligned with the ubuntu schedule), with like 1-2 days freeze, and constant testing with automated tests, and having nightlies PPA
[15:32] <seb128> desrt, if we want to reimplement some systemd services, does it mean we need to hijack the systemd namespace?
[15:32] <seb128> desrt, like use systemd namespacing in ubuntu-system-services?
[15:33] <desrt> seb128: i assume so
[15:33] <seb128> desrt, does it also mean u-s-s and systemd conflicts?
[15:33] <pitti> I thought that was the idea
[15:33] <desrt> seb128: and i think lennart has suggested that, indeed, you're expected to do that
[15:33] <seb128> desrt, which starts being interesting when they have overlapping but different services setsx
[15:33] <pitti> well, it wouldn't collide
[15:33] <pitti> if systemd was already running it wouldn't d-bus activate u-s-s
[15:33] <seb128> desrt, i.e it meant you can't install systemd and ubuntu-system-service, which means if you want to use systemd you have to break ubuntu specific features
[15:33] <pitti> of course we need to split u-s-s into two daemons
[15:34] <pitti> but maybe most of what u-s-s is doing is already covered by systemd APIs
[15:34] <dobey> didrocks: testing and freezes are good, but putting too much emphasis on them, means you never get any code :)
[15:34] <seb128> pitti, it wouldn't collide, wouldn't have they to ship the same .service on disk?
[15:34] <seb128> pitti, i.e same filename in the same dir?
[15:35] <desrt> seb128: dbus service filenames are ignored
[15:35] <desrt> seb128: it's the content that is important
[15:35] <desrt> seb128: and i don't imagine that systemd ships service files... it's just there from the start
[15:35] <desrt> no need for activation
[15:35] <pitti> yes
[15:35] <didrocks> dobey: oh I totally agree, the past didn't show that having that was enough though, well, we'll see :)
[15:35] <pitti> d-bus activating pid 1 sounds interesting, though!
[15:36] <seb128> pitti, well systemd != the services around systemd
[15:36] <desrt> seb128: actually, it is
[15:36] <pitti> seb128: I think you can have alternative names -- I've seen .service files being prefixed with gnome_ and kde_; I don't know the details unfortunately
[15:36] <pitti> but still, their names seem to be arbitrary
[15:37] <pitti> e. g. indicator-application.service activates com.canonical.indicator.application
[15:37] <pitti> so the file name doesn't need to match the API name, as desrt says
[15:37] <dobey> didrocks: it's like money. there's never enough. if we could predict everything perfectly, then it wouldn't matter anyway. :)
[15:37] <pitti> we coudl just call it ubuntu_com.systemd.whatever
[15:37] <desrt> it's similar to gsettings schema files
[15:37] <desrt> the name is totally unimportant, but it's generally good practice to keep it related to the content to avoid clashes
[15:38] <seb128> desrt, pitti: what happen if 2 .service list the same name?
[15:38] <desrt> seb128: in this case nothing
[15:38] <desrt> seb128: because the service would already be running, so activation would not happen
[15:38] <seb128> desrt, well 2 dbus activated services
[15:38] <pitti> seb128: I don't know; but I figure systemd would run already
[15:38] <seb128> if none is running
[15:38] <desrt> seb128: i dunno.  pick one at random? :)
[15:38] <pitti> presumably :)
[15:39] <pitti> whichever comes first when it scans the directory?
[15:39] <seb128> pitti, I don't think they activate the helper on boot
[15:39] <didrocks> and not in a reliable way to make it more fun :)
[15:39] <seb128> no need to add boot time for that
[15:39] <desrt> consult XDG_CURRENT_DESKTOP variable?
[15:39] <seb128> when you can activate them on demand
[15:40] <seb128> well anyway it's theoritical questions for now, I was more concerned about stealing systemd namespaces on the bus
[15:40] <seb128> but if lennart says it's the way to do it that's fine I guess ;-)
[15:40] <desrt> seb128: i wouldn't be concerned about that
[15:40] <desrt> don't quote me.  i'm not 100% he said that
[15:40] <desrt> but i think he did
[15:41] <seb128> ok
[15:42] <pitti> yes, he told me as well; not in that level of detail, but in general "write your own daemon which implements teh necessary part of the API"
[15:42] <pitti> it's a bit like aptdaemon exposing a PackageKit D-BUS API
[15:58] <rickspencer3> didrocks, I just updated to the latest unity on my netbook
[15:58] <rickspencer3> noticably faster
[15:58] <didrocks> rickspencer3: nice! :)
[15:58] <rickspencer3> didrocks, what did they change?
[15:58] <rickspencer3> I thought there was no compiz update yet
[15:59] <didrocks> rickspencer3: nothing changed, it's just a rebuild with the latest glew1.6
[15:59] <didrocks> we stayed before on a previous version, because nux was failing with it
[15:59] <didrocks> seems upstream glew fixed it
[15:59] <rickspencer3> nice
[15:59] <didrocks> (it's for intel only)
[15:59] <rickspencer3> I only have intel ;)
[15:59] <rickspencer3> \o/
[15:59] <didrocks> heh ;)
[16:00] <jbicha> seb128: what do you think about evince 3.3? seeing as we're already shipping poppler 0.18?
[16:01] <seb128> jbicha, did they announce anywhere that there will be no poppler 0.20 and that evince will not depends on that?
[16:10] <jbicha> seb128: poppler 0.20 looks like it will not be out for a while, but I'll try to find out for sure
[16:12] <seb128> jbicha, thanks
[16:12] <seb128> jbicha, btw I uploaded webkit 1.7.4 to the ubuntu-desktop ppa and pushed to the vcs
[16:13] <seb128> jbicha, not uploaded to the archive because s-c segfault on start with it there, http://pastebin.ubuntu.com/810740/
[16:18] <jbicha> seb128: has it been tested with ubiquity?
[16:18] <seb128> jbicha, no, but I just upload to the ppa for a reason ;-)
[16:18] <seb128> jbicha, I tested shotwell, s-c, gwibber
[16:18] <seb128> s-c segfault on start so it's a no go for today in any case
[16:54] <desrt> pitti: https://mail.gnome.org/archives/desktop-devel-list/2012-January/msg00066.html
[16:54] <pitti> desrt: yup, just saw that
[16:54] <desrt> viable?
[16:54] <pitti> I don't see why not
[16:56] <pitti> not sure if it actually is any easier than just slamming the stuff into ubuntu-system-service, though
[16:56] <pitti> but either way, it's writing a bunch of text files through a d-bus interface, it's not rocket science
[16:56] <pitti> anyway, meeting is over, and so is my week
[16:56] <pitti> happy weekend everyone!
[16:57] <seb128> pitti, have a nice w.e
[16:57] <seb128> desrt, I don't really like that approch
[16:57] <didrocks> enjoy your week-end pitti!
[16:58] <seb128> desrt, it means we get an half baked systemd source package, see how he disabled the journal
[16:58] <seb128> desrt, which usually leads to lennart blogging a rant about how ubuntu is making a bad job at packaging his softwares ;-)
[16:59] <desrt> pitti: i wouldn't mind a reply to the list with your thoughts
[16:59] <desrt> since if anyone, you're the one that will have to do this
[16:59] <seb128> desrt, the discussion is also drifting
[16:59] <desrt> it does seem a bit gross, though...
[16:59] <seb128> desrt, i.e nobody complained about how Ubuntu doesn't has the service, we can deal with our distro thanks
[17:00] <desrt> seb128: from general bitchiness into solving the specific problem?
[17:01] <seb128> desrt, well I don't see "how Ubuntu deal with providing services GNOME need" as a problem, it's just integration work we have to deal with
[17:01] <seb128> desrt, the problem is how and when new depends are announced
[17:01] <desrt> right.  that's the general bitchiness part
[17:02] <seb128> desrt, and maybe how it's decided that dropping support for part of the world is ok
[17:02] <desrt> which is indeed, what i really wanted to talk about
[17:10] <bryce> pitti, joncruz is going to look into moving inkscape to lcms2 in the coming weeks, given our interest
[17:19] <jml> qt applications seem to use a bold font for things like, say, button text
[17:19] <jml> this looks like a bug
[17:19] <jml> (or is it just that Qt app authors are tasteless?)
[17:21] <dobey> cp: cannot stat `./usr/share/dbus-1': No such file or directory
[17:21] <dobey> dh_install: cp -a ./usr/share/dbus-1 debian/rhythmbox-data//usr/share/ returned exit code 1
[17:21] <dobey> what the heck
[17:22] <dobey> ricotz, seb128: ^^ any idea why i'd get that?
[17:22] <dobey> jml: screenshot?
[17:22] <seb128> dobey, build log?
[17:23] <dobey> seb128: https://launchpadlibrarian.net/90516912/buildlog_ubuntu-precise-i386.rhythmbox_2.95%2Br7848-17~precise1_FAILEDTOBUILD.txt.gz
[17:24] <seb128> dobey, where is your source?
[17:25] <seb128> what ppa is that?
[17:25] <dobey> the u1 nightlies ppa
[17:26] <dobey> https://code.launchpad.net/~ubuntuone-control-tower/rhythmbox/packaging-dailies is the packaging
[17:26] <jml> dobey: http://people.canonical.com/~jml/bold-qt-creator.png ; http://people.canonical.com/~jml/bold-qjack.png ; http://people.canonical.com/~jml/bold-calibre.png
[17:26] <dobey> but my rhythmbox-data.install is the same as in lp:ubuntu/rhythmbox :-/
[17:27] <dobey> jml: they aren't bold for me
[17:27] <seb128> dobey, from a glance I would say that you need to bump your compat to 8
[17:27] <jml> dobey: so there's a bug that's not universal. hooray for progress.
[17:27] <dobey> seb128: ah ok.
[17:28] <seb128> dobey, or add debian/tmp/ on each .install lines
[17:28] <seb128> dobey, they made that optional in > 6
[17:28] <seb128> dobey, in compat = 5 you need the lines to have debian/tmp/...
[17:28] <dobey> ok, dh 8 it is then
[17:28] <dobey> well i was using 7
[17:28] <seb128> that's probably enough
[17:29] <seb128> I'm not sure now in which version it changed, it's 7 or 8
[17:29] <dobey> but i can make it 8.
[17:29] <seb128> but after 5 for sure
[17:29] <dobey> must be 8 :)
[17:30] <dobey> oh, but for some reason the compat file was 5. so i guess i was using 5. doh
[17:33] <dobey> thanks seb128
[17:33] <seb128> dobey, yw
[17:39] <micahg> man debhelper should show major changes between compat versions
[17:40] <dobey> it should make it more visible that the "compat" file and what you Build-Depends on for debhelper, don't match up
[17:42] <micahg> dobey: well, there's a paragraph in other notes that says it should, but it's obviously wrong since we don't have a debhelper 9 yet
[17:57] <GunnarHj> seb128: Do you know when lightdm-gtk-greeter (and lightdm-qt-greeter) 1.1.1 will make it into Precise? Is it a Robert thing to fix?
[17:57] <seb128> GunnarHj, no, is there any useful change in those version?
[17:58] <micahg> GunnarHj: lightdm-gtk-greeter will come in through Debian once Bug #916477  is addressed
[17:58] <ubot2> Launchpad bug 916477 in lightdm "gio-2.0 missing from liblightdm-gobject-1.pc" [Medium,Incomplete] https://launchpad.net/bugs/916477
[17:58]  * micahg thought the QT greeter was dropped
[17:59] <micahg> oh, not it exists
[17:59] <GunnarHj> seb128: I'm asking because they were broken out from lightdm, so now they aren't in the repository at all.
[17:59] <micahg> GunnarHj: the binaries are still there
[17:59] <GunnarHj> micahg: Looking at that bug...
[18:00] <GunnarHj> micahg: Sure, but not that easy to build locally, right?
[18:00] <seb128> GunnarHj, agateau is working on packaging the standalone gtk greeter
[18:00] <micahg> GunnarHj: right
[18:01] <GunnarHj> seb128, micahg: Great, then I know that something is happening. :)
[18:01] <seb128> GunnarHj, bug #918604
[18:01] <ubot2> Launchpad bug 918604 in ubuntu "[needs-packaging] lightdm-gtk-greeter" [High,Triaged] https://launchpad.net/bugs/918604
[18:02] <GunnarHj> seb128: Excellent, thanks!
[18:03] <seb128> he got blocked on https://code.launchpad.net/~agateau/lightdm-gtk-greeter/fix-missing-greeter-ui/+merge/89239 though
[18:10] <GunnarHj> seb128: Hmm... Considering Lubuntu and Xubuntu it's somewhat urgent, right?
[18:10] <seb128> GunnarHj, why? the current binaries are still in the archive and working
[18:11] <micahg> nah, not until beta 1 or so when we go removing binaries
[18:12] <didrocks> ok, time for dinner here. Have a good week-end everyone!
[18:14] <GunnarHj> seb128, micahg: There are issues (bug 918401) and further development is blocked or at least more difficult.
[18:14] <ubot2> Launchpad bug 918401 in lubuntu-meta "Unity-greeter installed by default on Lubuntu, crashing on start" [Undecided,Confirmed] https://launchpad.net/bugs/918401
[18:15] <seb128> GunnarHj, well it's being working, it's an issue for lubuntu or others they can step up and help maintaining the greeter they use ;-)
[18:15] <seb128> working -> worked
[18:15] <micahg> does not affect xubuntu
[18:15] <seb128> robert_ancell sent an email to ubuntu-devel saying that people who care about those greeter should step up to maintain them
[18:16] <GunnarHj> seb128: Ok, that's true, of course...
[18:18] <seb128> GunnarHj, but don't worry the gtk greeter should be uploaded some time next week
[18:18] <GunnarHj> seb128: Yes, I saw it. I for one would like to help, but I don't think I'm experienced enough to be a maintainer candidate.
[18:20] <GunnarHj> seb128: Anyway, next week sounds good to me.
[18:21] <seb128> ;-)
[18:31] <kenvandine> seb128, do we have a plan for libgee, 0.6 or 0.7?
[18:32] <seb128> kenvandine, I don't know enough about libgee to say but I would lean toward 0.6
[18:32]  * kenvandine is happy staying on 0.6 
[18:32] <seb128> kenvandine, seems even GNOME is unsure what version they will ship this cycle, they might ship 0.6
[18:33] <seb128> so if we don't have a strong reason to go for the new one I would stay on what we know is working
[18:33] <kenvandine> yeah, that is why i asked
[18:38] <desrt> gee/vala is a mess right now
[18:40] <seb128> desrt, yeah, and vuntz is trying to push us to use vala 0.15 ;-)
[18:41] <desrt> seb128: it looks like 0.15 is the right choice, actually
[18:41] <desrt> the good news is that it doesn't strictly matter
[18:41] <desrt> since the .c goes in the tarball
[18:42] <seb128> right
[18:42] <kenvandine> i am not to worried about the vala version
[18:42] <kenvandine> but bumping gee worries me
[18:43] <seb128> kenvandine, I will force it to 0.6 serie on version so nobody get ideas ;-)
[18:43] <kenvandine> excellent :)
[18:43] <kenvandine> it might not be painful, but we just don't know
[18:43] <kenvandine> and 0.6 has been solid
[18:43] <seb128> kenvandine, well by default on a lts cycle avoid wasting work where you don't need to
[18:44] <seb128> if we are happy with 0.6 let's stick to that
[18:44] <kenvandine> awesome
[18:44]  * kenvandine finds something else to worry about :)
[18:44] <seb128> kenvandine, if you get bored webkit is to worry about :p
[18:44]  * kenvandine just discovered that Dee is unusable in javascript
[18:44] <seb128> the 1.7 version makes s-c segfault on start
[18:44]  * kenvandine won't  be bored anytime soon :)
[18:44] <kenvandine> ugh
[19:42] <desrt> RAOF: we're getting the new input side of xserver, right?
[19:50] <seb128> Sweetshark, “libreoffice-l10n” 1:3.4.5-0ubuntu1 is still buggy in regard of calc formulas translations
[19:51] <bryce> desrt, yes
[19:51] <bryce> desrt, xserver 1.11 with the input stack from 1.12
[19:51] <bryce> desrt, it was a pretty clean port
[19:57] <desrt> sweet
[19:58] <desrt> it's already in precise, i guess?
[19:58]  * desrt notices XITouchEmulatingPointer missing from the headers
[20:12] <Sweetshark> seb128: /me is officially on vacation now.
[20:13] <seb128> Sweetshark, enjoy
[20:13] <seb128> Sweetshark, sorry to spoil your holidays start
[20:13] <seb128> Sweetshark, I've been trying to diff the ppa and proposed build log without real success
[20:14] <Sweetshark> seb128: but this time, I am absolutely sure the two build are identical on the source side, so something on the buildds is broken ...
[20:15] <Sweetshark> seb128: anyway, I gotta go to sleep now -- waking up at 3 am to start to drive to the french alps for skiing.
[20:16] <seb128> Sweetshark, enjoy your week off!
[20:18] <kenvandine> seb128, have you seen anything like bug 887850 ?
[20:18] <ubot2> Launchpad bug 887850 in chromium-browser "Assert failures in cairo-surface.c:1287: cairo_surface_set_device_offset: Assertion `status == CAIRO_STATUS_SUCCESS' failed, after upgrading to Oneiric with unity-2d" [Undecided,Confirmed] https://launchpad.net/bugs/887850
[20:19] <seb128> kenvandine, no
[20:19] <kenvandine> it appears to also break gwibber-accounts when run in unity-2d for people that can't run 3d
[20:19] <kenvandine> and pidgin too
[20:19] <seb128> weird
[20:20] <kenvandine> yeah...
[20:20] <kenvandine> i can't reproduce it in unity-2d, but i am talking to someone who can
[20:20] <kenvandine> he is using nvidia and unity-2d, always gets the fallback
[20:21] <kenvandine> seems hardware dependent
[20:21] <kenvandine> all the more reason to ditch gtk2/webkit in gwibber-accounts
[20:21] <kenvandine> :)
[20:24] <dobey> that makes no sense, unless something seriously broke in new updates
[20:26] <seb128> kenvandine, getting a valgrind log could be useful