[05:28] <pitti> tkamppeter_: "Only long keyids (v4, 160bit) are supported", ah, that indeed explains it
[05:28] <pitti> Good morning
[05:29] <larsu> pitti, good morning :)
[05:29] <pitti> larsu: oh right -- crazy times for you now :)
[05:29] <larsu> pitti, ya, at least I see you get up now!
[05:30] <attente> larsu_: ping
[05:31] <larsu_> attente: pong
[06:15] <BigWhale> Good Morning
[06:23] <didrocks> good morning
[06:38] <BigWhale> good morning didrocks :)
[06:39] <didrocks> hey BigWhale, how are you?
[06:39] <BigWhale> I'm up from 6am ... that's how I am :))
[06:40] <BigWhale> Right now contemplating what is the acceptable number of bugs for a 'stable' release. :)
[06:42] <didrocks> heh ;)
[06:46] <BigWhale> That's not funny! :P
[06:46] <BigWhale> :))
[06:49] <didrocks> it is, before coffee and you start to realize what this really means ;)
[06:53] <BigWhale> I don't drink coffe. :/
[06:54] <didrocks> tea works for caffein ;)
[07:34] <jibel> good morning
[07:34] <robru> hmmmmmmm... what is the Vala equivalent of python's unittest.assertRaises?
[07:39] <didrocks> hey jibel, morning/evening robru!
[07:40] <robru> hey didrocks !
[07:40] <jibel> bonjour didrocks
[07:44] <BigWhale> Which window manager is used in gnome-session-fallback?
[07:49] <didrocks> metacity
[07:50] <BigWhale> is there a way to turn on compositing in metacity?
[07:51] <BigWhale> or make a window transparent in non-compositing WM's?
[07:52] <mitya57> BigWhale: gsettings set org.gnome.metacity compositing-manager true
[07:52] <mitya57> btw there is also gnome-fallback-comits session
[07:52] <mitya57> *gnome-fallback-compiz
[07:53] <BigWhale> mitya57, thanks.
[07:54] <BigWhale> Why is it off anyway?
[07:54] <BigWhale> performance wise?
[07:55] <didrocks> BigWhale: doesn't work well if you don't have accelerated drivers
[07:55] <didrocks> still work, but can be slower and have artefacts
[09:04] <Laney> friiiiiday
[09:09] <didrocks> yeeeeep ;)
[09:10] <didrocks> qtdays!
[09:11] <Laney> O RLY
[09:24] <BigWhale> I abandoned Qt when KDE4 was released for the first time. :)
[09:45] <Riddell> didrocks: what what?
[09:45] <popey> mpt: got another potentially not helpful update-manager dialog today... http://popey.com/~alan/untrusted.png  "This requires installing packages from unauthenticated sources" (I know the reason, I have a PPA which I didn't add the key for)
[09:46] <chrisccoulson> good morning
[09:46] <didrocks> hey Riddell, sorry, was disconnected, didn't receive your first message :)
[09:46] <popey> mpt: if you run "apt-get upgrade" then the similar warning is presented as just that, a warning, with the option of pressing "yes" to allow it. update manager offers no option to ignore the warning.
[09:46] <didrocks> (sharing screen in hangout made xorg crashing)
[09:46] <Riddell> didrocks: I only got "qtdays" does this mean you have some plans for qt today?
[09:47] <didrocks> Riddell: the plan than Mirv talk to you about with Qt 5
[09:47] <didrocks> Riddell: so qtchooser + qt4 compatible with qt5 paths
[09:47] <didrocks> and we start to upload an initial version qt5, reviewing under way
[09:47] <Riddell> didrocks: I'm wanting to wait until KDE 4.10 is in before that gets uploaded
[09:47] <didrocks> (the version that was acked with debian as well)
[09:47] <Riddell> cos I suspect they'll clash somewhat
[09:48] <didrocks> Riddell: you mean, the qt5 part?
[09:48] <Riddell> didrocks: well qtchooser and qt4-x11 changes, but I think qt5 will depend on that
[09:48] <didrocks> Riddell: the qt4 with qtchooser it uploaded (qt4 in binary NEW I guess for the -default package) and qtchooser in source NEW
[09:49] <didrocks> is*
[09:49] <Riddell> didrocks: ah good old New queue :)
[09:49] <didrocks> heh :)
[09:49] <Riddell> didrocks: KDE SC 4.10 is all done except for smelly old powerpc being slow
[09:50] <didrocks> Riddell: ah ok, no new package? I doubt qt4-x11 will be built on powerpc before the kde pieces on powerpc are built?
[09:50] <Riddell> no new in 4.10
[09:51] <didrocks> ok, I thought that's what you meant once you wanted KDE 4.10 first ;) so we're all good
[09:51] <didrocks> Riddell: qt4-x11 won't be publish anyway before the new -default package is NEWed
[09:51] <didrocks> and I guess powerpc will finish before qt4-x11 powerpc starts even
[09:51] <didrocks> finished*
[09:51] <didrocks> let's keep qtchooser in source NEW as well until the powerpc builds ends
[09:52] <didrocks> Riddell: works for you?
[09:52] <Riddell> didrocks: qt4 seems to have started on powerpc, how did it skip the queue?!
[09:53] <didrocks> Riddell: hum, you're right, crap :/ is it a priority main/universe?
[09:53] <didrocks> Riddell: I didn't request anything FYI, no score bump
[09:53] <Riddell> didrocks: oh that's probably it
[09:53] <didrocks> Riddell: normally, headers are not impacted, it's just binaries that are moving
[09:53] <didrocks> Riddell: so, hopefully, you can still publish kde, even on powerpc if built against the new qt4-x11
[09:54] <Laney> you could have someone kill the build
[09:54] <Riddell> didrocks: since powerpc is not something we should care about I wonder if it's sensible to just tell the proposed migration to ignore the kde packages
[09:54] <mpt> popey, bug report please
[09:54] <didrocks> Riddell: I would +1 on that TBH, but I guess that the tool won't be able to copy powerpc after the fact and will rebuilt it
[09:55] <didrocks> or just do what Laney is proposing, killing the build
[09:55] <Riddell> the qt build?
[09:55] <didrocks> for powerpc
[09:55] <Riddell> ok I'll ask for that
[09:55] <Laney> why is it a problem?
[09:56] <Laney> surely any problem you'll hit at the next upload anyway
[09:56] <didrocks> Laney: it's not really, we are just moving some binaries and renaming them for being compatible with the incoming qt5
[09:56] <didrocks> so no header change
[09:56] <didrocks> Laney: but Riddell wants to publish KDE 4.10 first to have a separate change tests, I guess
[09:56] <popey> mpt: ok
[09:56] <didrocks> (understandbly, don't mix potential issues ;))
[10:02] <didrocks> Riddell: which package should I look at to tell "yeah, everything is built on powerpc"?
[10:02] <didrocks> everything == KDE 4.10
[10:03] <Riddell> didrocks: everything beginning with a k? :)
[10:03] <didrocks> Riddell: well, do you have a control tower for that? ;-)
[10:04] <Riddell> didrocks: what's one of those?
[10:04] <popey> mpt done, bug 1119247
[10:04] <ubot2> Launchpad bug 1119247 in update-manager (Ubuntu) ""This requires installing packages from unauthenticated sources" warning not useful" [Undecided,New] https://launchpad.net/bugs/1119247
[10:04] <didrocks> Riddell: I meant, do you have a one single page to check that powerpc on everything starting with a k ended?
[10:04]  * didrocks wonders why again he can't access to https://launchpad.net/builders
[10:04] <Riddell> didrocks: I'm watching http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[10:05] <Riddell> although haskall is getting in the way of making it quick to read
[10:05] <didrocks> Riddell: oh, good hint!
[10:05] <didrocks> Riddell: thanks, will look at that :)
[10:05] <didrocks> so many haskell* package, I blame Laney!
[10:06] <Laney> muhahah
[10:07] <didrocks> :p
[10:08] <czajkowski> didrocks: private receipe build going on so untul thats gone you wont be able to see it
[10:08] <didrocks> czajkowski: isn't it written normally just "private build" for those?
[10:09] <didrocks> I saw that sometimes, without details, just "private build"
[10:09] <czajkowski> didrocks: sometimes but wgrants says this is normal
[10:09] <Laney> that's private package builds
[10:09] <Laney> slightly different
[10:09] <didrocks> hum, interested in more details now ;)
[10:10] <czajkowski> didrocks: poke wgrant :)
[10:10] <Laney> there's probably a bug on it
[10:10] <Laney> https://bugs.launchpad.net/launchpad/+bug/760303
[10:10] <ubot2> Ubuntu bug 760303 in Launchpad itself "builders page inaccessible if a private recipe build is building" [High,Triaged]
[10:11] <didrocks> heh, will do thanks czajkowski, Laney ;)
[10:11] <czajkowski> really need to remove launchpad as a highlight
[10:12] <Laney> lies, your interventions are helpful
[10:15] <didrocks> indeed, they are :)
[10:24] <seb128> chrisccoulson, hey
[10:25] <chrisccoulson> hi seb128, how are you?
[10:25] <seb128> chrisccoulson, I'm good thanks, how are you?
[10:25] <seb128> happy friday ;-)
[10:25] <chrisccoulson> seb128, yeah, not too bad thanks
[10:25] <seb128> chrisccoulson, did you see my libdbusmenu ping yesterday afternoon?
[10:25] <chrisccoulson> bah, friday, i could do with an extra day in the week ;)
[10:26] <chrisccoulson> seb128, what sort of testcase are you after?
[10:26] <seb128> chrisccoulson, something that could do a SRU testcase :p
[10:26] <chrisccoulson> seb128, ah, i did wonder :)
[10:26] <seb128> I want to SRU the fixes, I'm just unsure that the SRU team will like "run firefox under valgrind"
[10:26] <chrisccoulson> seb128, yeah, i'll see if i can get a testcase that doesn't involve firefox
[10:27] <seb128> thanks!
[10:27] <chrisccoulson> you need a special build to run that under valgrind in any case
[10:27] <seb128> don't spend too much work on it anyway
[10:27] <seb128> if we don't have a testcase I will go the "just make sure nothing behave wrongly, watch $program memory usage"
[10:27] <seb128> way
[11:04] <Laney> gruh
[11:04] <Laney> didrocks: so this does introduce failures
[11:05] <Laney> the unversioned qmake seems to have gone/moved
[11:07]  * didrocks looks for the merge request
[11:07] <didrocks> Laney: do you have a link for the failure?
[11:07] <Laney> seems from the changelog that I have to BD on qt4-default now?
[11:07] <Laney> it was a local build
[11:08] <Laney> qmake [long list of options] fa
[11:08] <Laney> iled to to execute: No such file or directory
[11:08] <didrocks> Laney: ah right, you need qt4-default or qtchooser to chose one
[11:09] <didrocks> the -dev package dep on qt4-default IIRC
[11:09] <didrocks> let me check
[11:10] <Laney> so qt5 will start installing just `qmake' I guess? is that expected to work for most packages?
[11:12] <Laney> I think I'll pass --buildsystem=qmake_qt4
[11:14] <didrocks> sorry, was another chat :)
[11:15] <Laney> heh
[11:15] <didrocks> one sec, checking something
[11:15] <didrocks> indeed, this is an issue in a builder
[11:15] <didrocks> I think libqt4-dev should dep on libqt4-default
[11:16] <didrocks> or
[11:16] <didrocks> hum, not that easy :)
[11:16] <didrocks> because qt4-default and qt5-default conflicts
[11:16] <didrocks> qtchooser is the tool to tell "I'm using those dev tools"
[11:16] <Laney> alternatives?
[11:16] <didrocks> being make_qt4
[11:16] <didrocks> or qmake_qt5
[11:16] <didrocks> Laney: debian didn't want alternatives
[11:17] <Laney> hmm
[11:17] <didrocks> Laney: they prefered this tool, which is what upstream is supportive for
[11:17] <didrocks> maybe Mirv can give us an hint, he work with them more than I
[11:22] <Mirv> yes, upstream recommended and Debian wanted qtchooser, making it unnecessary to continuing patching the sources adding suffixes everywhere and handling alternatives
[11:23] <Laney> do you expect continued build failures due to this?
[11:23] <didrocks> Mirv: the question I guess is for a simple app, they will build-dep on libqt4-dev and not qt4-default
[11:23] <Mirv> it has the new requirement that everything that builds against Qt4 needs to build-dep on qt4-default
[11:24] <Laney> I think this ought to be communicated
[11:24] <didrocks> shouldn't rather we have libqt4-dev dep on qt4-default | qt-default
[11:24] <didrocks> and qt4-default provides: qt-default?
[11:24] <didrocks> (and something similar for qt5)
[11:25] <Mirv> that could be an option. I tried to initiate ideas with pkg-kde but didn't get the topic going.
[11:25] <didrocks> Laney: am I crazy or this proposal makes sense to you? ^
[11:25] <didrocks> (if so, I would propose we fix that right away)
[11:27] <Laney> I think so, but I don't know the area well enough to be aware of any gotchas
[11:27] <Mirv> I'm starting a parallel discussion at #debian-qt-kde (oftc)
[11:27] <didrocks> Mirv: if I have qt4-default installed
[11:27] <didrocks> and I run qtchooser
[11:27] <didrocks> I can set qt5 as default, right?
[11:27] <didrocks> which screwing up the packages?
[11:28] <didrocks> without*
[11:28] <Mirv> didrocks: yes, you can use any of the methods like export QT_SELECT=qt5
[11:28] <Mirv> but only one can be the real default without any parameters or env vars
[11:28] <didrocks> Mirv: ok, tell me how it goes on #debian-qt-kde, I think we should do those for qt4 before the week-end
[11:28] <Mirv> let's see if anyone is around
[11:28] <didrocks> thanks :)
[11:31] <Laney> unblocking glib; I don't see any new failures from it
[11:32] <Phryq> heya guys. Is this a room where Ubuntu desktop-users can ask for help?
[11:38] <mpt> Phryq, no, this channel is for Ubuntu developers. You can find IRC support and other forums at <http://www.ubuntu.com/support>.
[11:39] <mpt> And a channel list at <https://wiki.ubuntu.com/IRC/ChannelList>.
[11:42] <czajkowski> Phryq: if you're looking for irc support head to #ubuntu
[11:47] <GunnarHj> pitti: Hi Martin; thanks for sponsoring bug 1103547.
[11:47] <ubot2> Launchpad bug 1103547 in language-selector (Ubuntu) "drag and drop does not work language support not complete" [Low,In progress] https://launchpad.net/bugs/1103547
[11:48] <Mirv> didrocks: some talk now how most packages should be using qmake-qt4 which is still available..
[11:48] <Mirv> was there some package that already failed to build?
[11:48] <Laney> Mirv: that's not what debhelper calls
[11:48] <Laney> see /usr/share/perl5/Debian/Debhelper/Buildsystem/qmake.pm
[11:48] <pitti> hey GunnarHj, you're welcome! thanks for the fisx
[11:48] <GunnarHj> pitti: Just curious about why you use set() instead of 'the good old' []. Is it about efficiency?
[11:50] <pitti> GunnarHj: no, but because missing() was previously returning a set
[11:50] <Mirv> Laney: thanks, using that information
[11:50] <pitti> and the new function turned a set into a list
[11:50] <pitti> GunnarHj: ^ which broke API; my new test case complained about taht
[11:50] <Laney> Mirv: I don't know whether debhelper could in theory be improved to detect which qmake to call
[11:50] <GunnarHj> pitti: Aha, then I understand. Thanks for explaining.
[11:51] <Laney> you might want to use codesearch.debian.net to see how many packages explicitly call unversioned qmake too
[11:51] <Mirv> < pinotree> use qmake_qt4, not that
[11:51] <Laney> that's fine to say, but reality might be different
[11:51] <Laney> the fact is debhelper uses that by default so I expect packages do rely on it
[11:52] <pitti> hey Laney
[11:52] <pitti> Laney: I don't see any autopkgtest failures which are due to glib, did you?
[11:53] <Laney> pitti: no - I already unblocked it
[11:54] <pitti> yay
[11:55] <Laney> and: trying: glib2.0
[11:55] <Laney> accepted: glib2.0
[11:55] <Laney> \o/
[11:59] <Mirv> I'm also mentioning that rcc tool didn't have the suffix in Qt4
[12:00] <SuperMatt> I'm having a bit of a problem... I can't log in to my account on my PC
[12:00] <Mirv> which means any package using rcc would break without qt4-default
[12:00] <SuperMatt> it accepts my password, but then goes back to lightdm
[12:00] <SuperMatt> I'm running raring
[12:00] <seb128> SuperMatt, hey, try #ubuntu+1 for user support
[12:00] <SuperMatt> righto
[12:09] <Mirv> didrocks: discussion stopped for a moment, but since all in Qt5 is NEW qt5-default requirement would be fine (and we also use it already). I'm trying to get agreement first if qt4-default dependency in libqt4-dev is acceptable. for rcc and debhelper use it seems obvious to me.
[12:10] <Laney> Mirv: thanks for following it up
[12:10] <Laney> Riddell: ^ you might want to be aware of this discussion
[12:11] <Mirv> there is also the option of we just doing it for libqt4-dev, since if Debian decides not to follow that route and fixes all Qt4 apps not to require qt4-default, we can sync
[12:11] <Mirv> we're not seeing uploads in Debian any time soon probably anyway because of the upcoming release and NEW queue being deprioritized there
[12:12] <didrocks> Mirv: ok, thanks :)
[12:12] <didrocks> Mirv: so we won't change qt5-default
[12:12] <didrocks> just keep compatibility for qt4, right?
[12:12] <Mirv> didrocks: actually for the time being I don't see any downsides of we doing the libqt4-dev dep on qt4-default thing, since it's transparent to drop if everything actually works without?
[12:13] <didrocks> Mirv: right, want to do it?
[12:13] <Mirv> didrocks: sounds like that currently
[12:13] <didrocks> or I can
[12:13] <didrocks> actually
[12:13] <Mirv> didrocks: well, feel free, I still haven't had my lunch :(
[12:13] <didrocks> Mirv: sure, enjoy your lunch then :)
[12:13] <Mirv> the hangout that was supposed to be later started an hour ago
[12:13] <Mirv> I really try now :)
[12:13] <didrocks> urgh, good luck! :)
[12:14] <didrocks> Laney: thanks for spotting it! I'm sure there are still some cases in qtchooser that is still not covered, but at least, that shouldn't break the build of qt4 apps
[12:14] <Laney> hmm
[12:14] <didrocks> I'm adding as well a recommends from qt4-default on libqt4-dev
[12:14] <Laney> so then you won't be able to develop for qt4 without having it as default
[12:15] <didrocks> so that if the way in the future is to use qt5-default, people don't mix it
[12:15] <Laney> i.e. installing qt5-default will actually uninstall libqt4-dev
[12:15] <Laney> is that ok?
[12:15] <didrocks> ah, good point
[12:15] <didrocks> hum…
[12:16] <didrocks> Laney: ok, I didn't follow this story from the beginning, we can workaround with a recommends for now
[12:16] <Laney> buildds don't install those
[12:16] <didrocks> really? I never knew that
[12:16] <didrocks> hemf
[12:17] <Laney> Perhaps Depends: qt4-default | qt-default and qt5-default Provides: qt-default is the way to go
[12:17] <Mirv> so only the qt5-default providing qt-default as well would allow full conistallability
[12:17] <didrocks> Laney: that was my proposal
[12:17] <didrocks> 12:24:14      didrocks | shouldn't rather we have libqt4-dev dep on qt4-default | qt-default
[12:17] <Laney> yeah
[12:17] <didrocks> yeah, let's do that
[12:18] <Laney> but we were coming around to not changing qt5
[12:18] <didrocks> let's makes it provide qt-default
[12:18] <Laney> I can't currently think of a solution where that's possible though
[12:18] <Mirv> one person doesn't like that because qt5-default shouldn't be able to fulfill libqt4-dev dependency, but even though that's a cosmetic issue we don't yet even have the consensus of accepting qt4-default dependency in libqt4-dev, so that's only the next debate
[12:18] <Mirv> sorry, I go now, I shouldn't be here..
[12:19] <didrocks> Laney: yep, I think that the qtchooser thing was half-thought, I don't even know how if it handles well manually changing the default when one default package is installed
[12:19] <Laney> well, you can think of that dependency as saying that you get qt4 as default by default but if you know what you're doing you can override that
[12:19] <didrocks> should really have been an alternative, not sure why it was rejected
[12:19] <didrocks> anyway, let's avoid breaking for now :)
[12:20] <Laney> if Debian decides to reject it it wouldn't be too hard to fix up the packages
[12:20] <didrocks> yep :)
[12:23] <didrocks> ok, it's ready here, waiting for the powerpc build for k* to finish first
[12:24] <didrocks> Laney: mind having a look? lp:~kubuntu-packagers/kubuntu-packaging/qt/, rev 349
[12:25] <Laney> getting
[12:26] <Laney> looks right
[12:26] <didrocks> Laney: thanks ;)
[12:26] <didrocks> reuploading qt5 in NEW
[12:32] <Mirv> didrocks: it seems that for now, the Debian qt4 packaging will not be changed, ie. "see what breaks" and even that is only at some point when those start to be uploaded
[12:33] <Mirv> then if it needs to be added, the "qt4-default | qt-default" libqt4-dev dep is more likely than "qt4-default" (where qt5-default would force uninstallation of libqt4-dev) since only one opposes it
[12:34] <didrocks> Mirv: yeah, I've prepared that for qt4 (waiting for the k* to be built on powerpc) and uploaded the new qt5 with the provides
[12:35] <Mirv> sounds good
[13:27] <ogra_> ah, nice, amliit is in the archive ...
[13:27] <ogra_> *maliit
[13:28] <ogra_> but it doesnt buy us any ram :(
[13:29] <ogra_> Laney, is there any config file or so for it ?
[13:29] <ogra_> its pretty small
[13:30] <ogra_> seb128, did you set up a meeting agenda for today ? (i was pondering to send an announcement and link to it)
[13:31] <seb128> ogra_, no, do you have anything you would like to get on an agenda? should we start creating a wiki page for that?
[13:31] <seb128> ogra_, I can send the reminder if you want
[13:31] <ogra_> that would be fine, no, nothing for the agenda, you said you wanted one this week, so i thought i'd ask
[13:32] <seb128> yeah, and I though about it this morning and I've nothing to put on it :p
[13:33] <ogra_> heh, same here
[13:33] <seb128> ogra_, I can create a wiki page anyway so we have one and maybe we manage to put stuff on it next time
[13:33] <seb128> ogra_, should I send the reminder to ubuntu-devel@ then?
[13:33] <ogra_> so lets ignore the agenda (and a wiki for it) until we have something for it
[13:33] <ogra_> yeah, i'll post it to G+ then
[13:33] <seb128> thanks
[13:34] <ricotz> seb128, hi :)
[13:35] <seb128> ricotz, hey
[13:38] <ricotz> seb128, i am looking into a vala patch http://people.ubuntu.com/~ricotz/pkg/vala-0.18_0.18.1-0ubuntu4.debdiff which is needed with the next gobject-introspection release
[13:39] <seb128> pitti, ^ do you know about that? g-i is your domain ;-)
[13:39] <ricotz> seb128, weirdly i am running into build issues currently, will check this out first
[13:40] <ricotz> vapigen will fail/error-out on this new parameter otherwise
[13:42] <ricotz> seb128, ah, since the vala builds directly from the c source it isnt that easy to patch
[13:43] <seb128> ricotz, you probably want to include the diff to the .c as well
[13:43] <ricotz> seb128, yes, or depend on valac again
[13:43] <seb128> no, please no circular depends
[13:43] <ricotz> i know, it was annoying in the past
[13:45] <pitti> seb128: hey; reading (back from lunch)
[13:46] <pitti> ricotz, seb128: ah, that's from Colin Walters, so seems fine; thanks for the heads-up, I wasn't aware that .girs are going to get the self argument
[14:01] <ricotz> seb128, pitti, http://people.ubuntu.com/~ricotz/pkg/vala-0.18_0.18.1-0ubuntu4.debdiff
[14:02] <pitti> eek
[14:02] <pitti> ricotz: our vala package doesn't build-dep on vala to rebuild itself?
[14:02] <ricotz> pitti, no, not anymore
[14:03] <pitti> but *shrug*, it's ACN upstream, so will hopefully disappear soon
[14:04] <ricotz> pitti, yeah, hopefully
[14:04] <ricotz> although there isnt even a 0.19.x release yet
[14:07] <ricotz> i hope someone likes to sponsor it ;)
[14:08] <seb128> ricotz, it doesn't seem to be in the sponsoring queue?
[14:08] <seb128> not going to be sponsored if it's not in there...
[14:08] <pitti> ricotz: ah, sure, I'll upload it
[14:08] <ricotz> seb128, ah, i meant upload it
[14:09] <ricotz> pitti, thanks!
[14:09] <seb128> ricotz, not likely to happen either (vala 0.19) if somebody doesn't put an update up for sponsoring
[14:09] <seb128> ricotz, currently desktop team has other priorities than packaging unstable series
[14:09] <seb128> ogra_, https://lists.ubuntu.com/archives/ubuntu-devel/2013-February/036448.html
[14:09] <pitti> seb128: c'est d'accord, j'ai le telecharge
[14:10] <pitti> ..chargé
[14:10] <seb128> pitti, vala 0.19 ?
[14:10] <pitti> (^ je crois?)
[14:10] <pitti> seb128: no, ricotz's 0.18 patch
[14:10] <ricotz> seb128, yes, i was speaking of upstream, jbuergi seems busy
[14:10] <seb128> pitti, oh, ok
[14:10] <seb128> pitti, "télécharge" ;-)
[14:10] <SuperMatt> is canonical still tracking one version behind gnome?
[14:10] <pitti> seb128: "j'ai le téléchargé"?
[14:11] <seb128> SuperMatt, canonical->ubuntu and define "one version behind" and "still"
[14:11] <seb128> SuperMatt, since this cycle we decided to stay on stable GNOME series rather than track unstable ones
[14:11] <pitti> SuperMatt: yeah, blocked by not having logind and also we decided to stay at 3.6 feature-wise for this cycle
[14:11] <SuperMatt> gotcha
[14:11] <ricotz> seb128, just to clarify this patch is only present in vala master which hasnt seen a release this cycle yet
[14:12] <SuperMatt> so essentially no gnome 3.8 in raring
[14:12] <seb128> pitti, "je l'ai téléchargé" if it's done, "je le télécharge" if you are doing it
[14:12] <seb128> pitti, french is hard? ;-)
[14:12] <seb128> SuperMatt, right, and no gnome 3.10 next cycle
[14:12] <pitti> seb128: ah, the "le" goes before the "have" even, merci
[14:13] <seb128> pitti, de rien!
[14:13] <ricotz> seb128, was there a conclusion about gtk+ 3.7.x?
[14:13] <pitti> seb128: I was applying German word order
[14:13] <seb128> ricotz, it might happen if somebody file the MIR for harfbuzz and figure the graphite2 depends and work then on the updates
[14:14] <seb128> ricotz, not likely to happen without somebody out of canonical-desktop-team helping though
[14:14] <ricotz> seb128, the packages are in gnome3-staging
[14:14] <seb128> so up to you and the other gnome3 ppa guys to see if you prefer to maintain it in a ppa or try to get it in the archvie
[14:14] <seb128> ricotz, that doesn't solve the MIR issue :p
[14:15] <ricotz> yeah, just the harfbuzz mir then
[14:15] <seb128> and the graphite2 thing
[14:15] <ricotz> this dep can be dropped
[14:15] <seb128> and somebody to submit merge requests to review for those updates
[14:15] <seb128> I don't plan to go try to figure out what is happening in ppas
[14:15] <Laney> ogra_: config file? what for? Not that I'm aware of
[14:15] <ricotz> seb128, i see
[14:15] <seb128> pitti, yeah, I agree with you, german words order is weird, I always though so :p
[14:16]  * seb128 hugs pitti
[14:16]  * pitti tu donne une accolade aussi
[14:16] <pitti> "te"
[14:16] <pitti> argh!
[14:16] <seb128> shrug, it's another of those days were nothing is moving out of proposed thanks to powerpc
[14:16] <seb128> hate powerpc
[14:17] <pitti> FTBFS or slow?
[14:17] <seb128> 6 hours backlog
[14:17] <seb128> well it's getting better, but the source I was looking to has been uploaded 6 hours ago and is set to build in 15 min
[14:21] <Laney> the new buildd is pretty decent I've found
[14:34] <ogra_> Laney, well, to define that it is at a usable size
[14:35] <ogra_> Laney, in landsacep it only occupies about 1/3 of the screen widht ... in portrait it is so small that i cant really use it
[14:35] <ogra_> *landscape
[14:39] <xnox> seb128: mostly due to private jobs still building on powerpc....
[14:41] <Laney> ogra_: I'm sure things will improve wrt the tablet usecase over time
[14:41] <Laney> we'll be able to have the nemo keyboard once Qt5 exists
[14:41] <ogra_> Laney, sure, i was just wondering if we could replace onboard ...
[14:42] <Laney> not that I know if it's better or worse
[14:42] <Laney> I wouldn't recommend that just now
[14:42] <ogra_> but the RAM usage seems to be the same and the actual kbd isnt really usable that way yet
[14:42] <Laney> laney@bisquicks:~$ htop
[14:42] <Laney> No command 'htop' found, did you mean: Command 'hatop' from package 'hatop' (universe)
[14:42] <Laney> err
[14:42] <ogra_> its doesnt seem to buy us anything over onboard atm
[14:43] <ogra_> uh, what ?
[14:43] <Laney> I didn't suggest switching it just yet
[14:43] <Laney> we should wait and see what happens, but now it's in the archive so people can play with it
[14:46] <ogra_> yeah
[16:56] <GunnarHj> seb128: still there?
[16:56] <seb128> GunnarHj, hey, sort of
[16:57] <GunnarHj> seb128: Hi Sebastien! Do you have time to sponsor the latest MP at bug 1103547? It's a regression fix, and we may be spared a few bug reports if it makes it into the archive fast.
[16:57] <ubot2> Launchpad bug 1103547 in language-selector (Ubuntu) "drag and drop does not work language support not complete" [High,In progress] https://launchpad.net/bugs/1103547
[16:57] <seb128> GunnarHj, still there for 1.5 hours but with a backlog of work worth 3 hours :p
[16:57] <GunnarHj> seb128: sorry ...
[16:57] <seb128> GunnarHj, sure, that seems easy enough
[16:57] <GunnarHj> seb128: Great!
[16:57] <seb128> GunnarHj, no worry, usually end of week rush, nothing to stress about, some stuff will wait monday ;-)
[16:58] <GunnarHj> seb128: Sounds familiar, somehow... ;-)
[16:59] <seb128> :-)
[17:05] <jbicha> why doesn't /org/freedesktop/hostname1 work right?
[17:06] <seb128> you mean?
[17:07] <jbicha> 2 issues, 1 is that it looks like I have to run System Settings as root to be able to change the hostname in Details (so maybe that's GNOME)
[17:08] <jbicha> and apparently 'Computer' in the Nautilus 3.7.5 sidebar is supposed to be named as whatever the hostname is
[17:09] <seb128> jbicha, hostnamed is a systemd feature, do you run systemd?
[17:09] <seb128> ubuntu-system-service doesn't provide that interface I think
[17:09] <seb128> that's nothing new
[17:10] <jbicha> no u-s-s does, it looks like the culprit is http://git.gnome.org/browse/gnome-control-center/tree/panels/common/gnome-control-center.rules
[17:10] <seb128> "org.freedesktop.hostname1.set-hostname"
[17:10] <seb128> that method is provided by systemd
[17:11] <seb128> no?
[17:11] <seb128> http://www.freedesktop.org/wiki/Software/systemd/hostnamed
[17:11] <jbicha> http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart
[17:11] <seb128> well the reason why changing hostname doesn't work on Ubuntu is because we don't have hostnamed
[17:11] <seb128> dunno about the ppa
[17:12] <jbicha> those methods are listed in d-feet too
[17:12] <Laney> AA
[17:12] <Laney> AFAICS those methods are provided by uss
[17:13] <seb128> org.freedesktop.hostname1.set-hostname org.freedesktop.hostname1.set-static-hostname are indeed
[17:14] <seb128> so maybe a but in u-s-s
[17:14] <Laney> jbicha: that rules file would affect getting the hostname but not setting it?
[17:14] <Laney> err the other way around
[17:14] <Laney> so the gcc problem but not the nautilus one
[17:28] <jbicha> ok I filed bug 1119596 in case someone wants to look into that
[17:28] <ubot2> Launchpad bug 1119596 in nautilus (Ubuntu) "Nautilus sidebar 'Computer' doesn't set itself to hostname correctly" [Undecided,New] https://launchpad.net/bugs/1119596
[18:22] <GunnarHj> seb128: Remember the l-s MP before you leave? ;-)
[18:26] <seb128> GunnarHj, merged/uploaded
[18:28] <GunnarHj> seb128: Thanks. Have a nice weekend!
[18:28] <seb128> GunnarHj, thanks, you as well ;-)
[18:33] <seb128> jbicha, Laney: https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-service/+bug/1119596/comments/1
[18:33] <ubot2> Ubuntu bug 1119596 in ubuntu-system-service (Ubuntu) "Nautilus sidebar 'Computer' doesn't set itself to hostname correctly" [Undecided,New]
[18:33] <seb128> just fyi...
[18:35] <jbicha> seb128: thanks, that could be the problem with g-c-c too since it still didn't work after changing the group from "wheel" to "sudo"
[18:36] <seb128> jbicha, could be, I need to look at what g-c-c is trying to do
[18:36] <seb128> jbicha, we still plan to replace u-s-s by systemd helper (python -> C) this cycle so I think I will wait for that land to spend time on those issues
[18:37] <seb128> hopefully that should fix it
[18:37] <seb128> but I still need to check the comment about lack of files to start this prettyhostname and if systemd will work or if we need the file added
[18:38] <jbicha> ah I was wondering whether that would land this cycle, it would be nice to get autosuspend back on my computer
[18:43] <seb128> jbicha, systemd helpers != logind
[18:43] <seb128> we will get the tools to set date, time, hostname, etc
[18:44] <seb128> not sure about logind, it's based on the systemd cgroup use
[18:44] <seb128> slangasek is looking into getting that to work on Ubuntu but we are not sure it's doable
[18:44] <seb128> if not we will need to implement compatible interfaces another way
[18:44] <seb128> but that would probably not be this cycle...
[18:46] <jbicha> ok well, better date, time, and hostname would still be good
[18:54]  * didrocks waves good evening
[18:55] <ogra_> hmm, have we lost the startup applications UI in raring ?
[18:55] <ogra_> or did it just move to a new hidden place
[18:57] <Laney> gnome-sesion-properties (from gnome-session-bin) - still exists here
[18:58] <ogra_> yeah, but only through the dash
[18:58] <ogra_> there is no way to find it through g-c-c or any menu anymore
[18:58] <ogra_> but well, i found it ...
[21:12] <desrt> xnox: any word on those fixes to the installer image?
[23:24] <ozcanesen> hey overlayscollbars disabling transparency of object, example:  http://i.imgur.com/URBRRXt.png , is anybody can help me to solve this? i can't understand why?