[00:22] <bcurtiswx> robert_ancell out today?
[00:22] <bcurtiswx> or is he not Australia and/or is australia not awake yet?
[02:19] <mfisch> robert_ancell: afternoon
[02:19] <robert_ancell> mfisch, hello
[02:20] <mfisch> robert_ancell: I was looking into a bug, #1069218, which should be a simple fix, but as far as I see the code that reads that config file is never loaded
[02:20] <mfisch> load_passwd_file() is the function that I dont see getting called
[02:21] <robert_ancell> mfisch, correct, this file is only used if AccountsService is not available
[02:22] <mfisch> so that config file isn't useful when a-s is running
[02:22] <robert_ancell> mfisch, yes
[02:25] <mfisch> doesn't look like a-s gives us shell or UID
[02:25] <mfisch> Background, Icon, Real Name, Home Dir, Username
[05:47] <pitti> Bonjour
[06:15] <didrocks> good morning
[06:55] <smspillaz> duflu: yo, don't merge the branches directly unless you feel like dealing with merge headaches
[06:55] <smspillaz> (as noted in the description ;-) )
[06:55] <duflu> smspillaz: I didn't...
[06:55] <duflu> ?
[06:55] <smspillaz> duflu: you changed the branch status to "approved" :)
[06:56] <duflu> smspillaz: Oh yes OK
[06:56] <smspillaz> np, just changed it back
[06:56] <duflu> smspillaz: So how to land it all (and backport)?
[06:56] <smspillaz> duflu: once we get these through we can drop the proposals and merge the one with the conflicts resolved etc
[06:56] <duflu> Yep fine
[06:56] <smspillaz> duflu: I wouldn't backport this fix
[06:56] <duflu> smspillaz: Has to be. It's critical to 0.9.8
[06:57] <smspillaz> duflu: well, you can if you want to ... but I'll warn upfront that it will be invasive
[06:57] <duflu> At least in the bug traffic I see :/
[06:57] <duflu> smspillaz: Yeah that's fine. I'd give it some time in raring first
[06:57] <smspillaz> kk
[06:58] <smspillaz> duflu: I'm trying to keep test coverage at 100% as I go along though, so hopefully it won't be too bad
[06:58] <duflu> smspillaz: So.. holidays huh?
[06:58] <smspillaz> duflu: My TV is broken and all my friends went back home
[06:59] <duflu> smspillaz: Fair enough. When is Uni back? late Feb?
[06:59] <smspillaz> yep :(
[06:59] <duflu> Hah. Any normal person would be happy.
[06:59] <smspillaz> hurrah for boredom!
[07:00] <smspillaz> I will get myself a new TV soonish, although #clickfail made that slightly more difficult
[07:01] <duflu> smspillaz: I recommend graysonline for a bargain
[07:02] <duflu> Hmm, sometimes. Not so much right now.
[07:03] <smspillaz> maybe. I have some friends at JB who can get me some good discounts
[07:04] <duflu> smspillaz: Or Sony PlayTV --> USB --> Ubuntu
[07:05] <smspillaz> well, when I say TV, I mean "display"
[07:06] <duflu> smspillaz: But a regular TV won't give you HD TV in wobbly/cube ;)
[07:07] <smspillaz> it will let me play zelda though
[07:07] <smspillaz> or something
[07:07] <smspillaz> I should get myself one of those though, I've been looking for a TV tuner that "just works"
[07:37] <duflu> smspillaz: Last week I had problems with CCSM changes not being sent to compiz till I restarted. Can't reproduce it now but possibly related to what you're doing?
[07:37] <duflu> (using a gsettings profile)
[07:39] <smspillaz> *shrug*
[07:39] <duflu> Suspected as much
[07:39] <smspillaz> duflu: there are so many points of failure that I don't really know what the relevant problem would be
[07:40] <duflu> smspillaz: Points of failure you found in the recent work?
[07:40] <duflu> Or that you assume are hiding?
[07:40] <smspillaz> duflu: are hiding
[07:41] <smspillaz> sometimes it can get into a weird state where compiz stops receiving settings updates
[07:42] <smspillaz> it doesn't bother me too much though, I really just mentally downgrade the importance of all bugs to do with changing settings that aren't exposed in g-c-c
[07:42] <smspillaz> also that "sometimes my focus follows mouse doesn't work" bug really should not be critical
[07:42] <smspillaz> critical means "blocks the entire distribution"
[07:52] <duflu> smspillaz: I know the importance of many if not most bugs needs re-evaluation
[07:53] <smspillaz> duflu++
[07:53] <smspillaz> duflu: and in other news, I finally have the unity gesture tests working without recompiling 8 fixes every.damn.build \o/
[07:53] <smspillaz> *8 files
[07:54] <smspillaz> (even if nothing changed)
[07:54] <duflu> smspillaz: Gestures? I've had multi-touch devices of some sort for a few years but gestures has not worked on any since 11.04 (when I sold my Macbook Air)
[07:55] <duflu> I suspect they're turned off for lots of multi-touch systems when they should not be
[07:57] <smspillaz> duflu: it only works on macbooks
[07:57] <smspillaz> iirc
[07:57] <smspillaz> and the XT2
[07:57] <smspillaz> duflu: get a magic trackpad if you want to try it
[07:57] <duflu> smspillaz: Hah. Yes, forgot to mention I saw it work on an XT2
[07:58] <smspillaz> duflu: in any case, yay, no recompiling
[07:58] <duflu> smspillaz: Got one in the cupboard. So I could finish contributing multi-touch fixes after I sold the Macbook
[07:58] <duflu> Yay. \o/
[07:59] <smspillaz> speaking of macbooks the rMBPs sure are pretty
[07:59] <smspillaz> except the price tag
[07:59] <duflu> smspillaz: I don't want to know. Already spent too much money lately
[08:00] <smspillaz> duflu: tell me about it - I put all my money in term deposits after I left canonical
[08:00] <smspillaz> that reminds me, I need to fix my super too
[08:00]  * smspillaz is worth approximately 300$ right now, and is hoping that will last until he finds another income stream
[08:22] <didrocks> bonjour jibel :) FYI, I've now push a fix to deploy_stack so that the right bzr branch is automatically the target of lp:<foo> when using lp-propose. Will be easier than doing that everytime by hand :)
[08:23] <didrocks> (especially as the indicator branchs have some names like: ~indicator-applet-developers/indicator-messages/trunk.13.04)
[08:27] <jibel> Salut didrocks
[08:27] <didrocks> ça va? :)
[08:29] <jibel> didrocks, ça va et toi?
[08:30] <didrocks> ça va bien :)
[09:03] <Laney> hiya
[09:05] <seb128> hey Laney, hey desktopers
[09:05] <Laney> hey
[09:05] <Laney> good weekend?
[09:05] <didrocks> salut Laney, bonjour seb128!
[09:06] <seb128> lut didrocks
[09:06] <didrocks> still busy, but good weekend :)
[09:06] <didrocks> and you?
[09:06] <seb128> did you guys have a good w.e?
[09:06] <seb128> w.e was good here ;-)
[09:08] <chrisccoulson> good morning everyone
[09:08] <didrocks> hey chrisccoulson
[09:09] <Laney> girlfriend's family were up to stay
[09:09] <Laney> so not relaxing ;-) but was good
[09:10] <chrisccoulson> hi didrocks, how are you?
[09:10] <didrocks> chrisccoulson: tired, but fine, yourself? ;)
[09:10] <chrisccoulson> didrocks, yeah, pretty much the same. had quite a busy weekend
[09:15] <xclaesse> Hello, is it possible to tell Dash's thunderbird icon to count only inbox emails and not all ML folders?
[09:19] <pitti> bonjour seb128, comment vas-tu?
[09:21] <seb128> pitti, salut, ca va ? t'as passé un bon W.E ?
[09:21] <seb128> hey chrisccoulson, how are you?
[09:21] <pitti> seb128: en effet! nous avons acheter un nouveau vélo pour ma femme
[09:21] <seb128> xclaesse, hey, ask chrisccoulson, I think there is an option inbox only
[09:21] <chrisccoulson> seb128, yeah, good thanks
[09:21] <seb128> pitti, l'ancien était cassé ? ou un meilleur modèle ?
[09:21] <chrisccoulson> how are you?
[09:21] <seb128> chrisccoulson, I'm good thank you
[09:21] <pitti> seb128: we took advantage of the marvellous weather to do a little bike tour, and some gardening
[09:22] <xclaesse> chrisccoulson, Hello, is it possible to tell Dash's thunderbird icon to count only inbox emails and not all ML folders?
[09:22] <seb128> nice
[09:22] <seb128> weather was great here as well
[09:22] <chrisccoulson> xclaesse, yeah, there's a radio button in the general pane of the preferences dialog
[09:22] <pitti> seb128: oui, every other week something else broke; it had > 16.000 km already (some 10 years), so EOL well deserved
[09:23] <seb128> waouh, that's quite some distance for a bike ;-)
[09:23] <Laney> speaking of weather, this is my parents' village at the weekend: https://fbcdn-sphotos-a-a.akamaihd.net/hphotos-ak-ash4/481717_10151255237798050_606163743_n.jpg
[09:23] <Laney> that's normally a road ...
[09:24] <xclaesse> chrisccoulson, there is no "general" pane in gnome-control-center here
[09:24] <chrisccoulson> Laney, oh, i hope their house didn't get flooded :/
[09:24] <chrisccoulson> xclaesse, in the thunderbird preferences
[09:24] <xclaesse> ah
[09:24] <Laney> chrisccoulson: nah, it's up the village a bit from the brook thankfully
[09:24] <xclaesse> chrisccoulson, good got it. Thanks :)
[09:25] <Laney> during the last big ones (2000?), it did come right up our road though
[09:26] <Laney> and i managed to get interviewed for bbc news 24 :P
[09:42] <didrocks> RAOF: hey, how are you?
[09:49] <didrocks1> grrr, system lockup
[11:22] <seb128> didrocks, https://bugs.launchpad.net/ubuntu/+source/cups-pk-helper/+bug/808829 ... was there anything blocking it?
[11:22] <ubot2> Launchpad bug 808829 in cups-pk-helper (Ubuntu) "[MIR] cups-pk-helper" [Undecided,Confirmed]
[11:23] <seb128> didrocks, you +1ed in comment #2 but then set to incomplete ... was that an ack or not?
[11:23] <didrocks> seb128: there is the "Bug #807261 seems quite important to fix though.
[11:23] <didrocks> "
[11:23] <ubot2> Launchpad bug 807261 in system-config-printer (Ubuntu Oneiric) "cups-pk-helper makes system-config-printer asking for a password when adding a new printer" [High,Fix released] https://launchpad.net/bugs/807261
[11:23] <seb128> the bug pointed was fixed
[11:23] <didrocks> then, discussing on IRC, pitti told it's not that important in the time
[11:23] <seb128> didrocks, that got fixed
[11:23] <didrocks> but it was still °1
[11:23] <didrocks> +1
[11:23] <seb128> didrocks, ok, so I can make g-c-c recommends it?
[11:23] <didrocks> so if it's important again, we can promote it
[11:23] <didrocks> seb128: sure, ping me once done, i'll promote it
[11:23] <seb128> didrocks, yeah, I enabled the upstream print dialog in g-c-c
[11:24] <seb128> didrocks, thanks
[11:24] <didrocks> yw ;)
[11:30]  * Laney plays a song over DAAP using a gst 1.0 rhythmbox
[11:30] <Laney> GY!BE - appropriately apocalyptic
[11:34]  * didrocks wonders why xvfb-run is looping when there is a failure
[12:29] <davmor2> In Raring now there seems to be no way to tell if there are updates.  In Quantal you clicked on about computer and the box appear on the overview page at the bottom telling you if there were updates but that isn't there in Raring is this a bug or a feature that will appear later?
[12:42] <cyphermox> good morning!
[12:49] <seb128> davmor2, seems like the code in GNOME 3.6 handles pkgkit 0.8 only and we don't have that version (yet)
[12:49] <seb128> cyphermox, hey, how are you?
[12:50] <davmor2> seb128: cool thanks for the update :)
[12:55] <cyphermox> seb128: good you?
[12:56] <seb128> good thanks
[13:00] <pitti> seb128: pk 0.8.4 is in Debian experimental; we might be able to just sync it? (didn't check new universe dependencies)
[13:04] <seb128> pitti, could be, I didn't look at it yet
[13:10] <didrocks1> urgh, seems I timeouted
[13:10] <didrocks1> hey cyphermox, how was the week-end?
[13:16] <cyphermox> didrocks1: it was ok...
[13:36] <xnox> which pieces of the following software can paint the desktop background picture all on their own: gnome-settings-daemon metacity nautilus compiz gnome-shell(mutter?!) your-option-here ?
[13:39] <seb128> xnox, gnome-settings-daemon and nautilus for sure, likely compiz through some plugin, iirc upstream GNOME is talking from moving the g-s-d code to gnome-shell
[13:39] <xnox> seb128: thanks a lot.
[13:40] <seb128> xnox, g-s-d has code to check and do nothing if nautilus is handling the desktop iirc
[13:40] <seb128> xnox, why? .. yw!
[13:40] <xnox> seb128: me and ogra_ just pondered about moving the installer to optionally use g-s-d for wallpaper painting, instead of ubiquity-background-image "mini-app"
[13:41] <xnox> but if that is going away, maybe not =)
[13:41] <seb128> xnox, you already have g-s-d running right?
[13:41] <xnox> seb128: yeap.
[13:41] <seb128> xnox, https://bugzilla.gnome.org/show_bug.cgi?id=686549
[13:41]  * xnox wonders if we double paint the background.
[13:41] <ubot2> Gnome bug 686549 in background "background: remove code that deals with nautilus drawing the desktop" [Normal,Unconfirmed]
[13:41] <seb128> xnox, we being unity or ubiquity?
[13:42] <xnox> seb128: ubiquity-only mode (ubiquity-dm). Currently it's X + metacity + custom background-painting app
[13:43] <seb128> ok
[13:43] <xnox> seb128: I am adding support for: X + compiz (which has a --bg-image option ;-) )
[13:43] <seb128> great ;-)
[14:11] <mspencer> mpt: png re. Contributor Console
[14:12] <mpt> mspencer, png? An icon?
[14:13] <mspencer> mpt: No, I was pinging you. I have several questions about Contributor Console
[14:13] <mpt> mspencer, ah. I never respond to pings. I do respond to questions. :-)
[14:15] <mspencer> mpt: I've pushed some code to the launchpad project. Should the wiki page be updated now that work is in progress on it?
[14:16] <mspencer> mpt: I see that you added a link but it still says that it doesn't exist yet.
[14:16] <mpt> mspencer, done :-)
[14:17] <mspencer> mpt: Great, thanks!
[14:18] <mspencer> mpt: What component do you have for the panel switcher? Is it something like what Software Center uses?
[14:18] <mpt> mspencer, yes. Polly is probably a simpler example.
[14:18] <mpt> Or Kazam.
[14:19] <mspencer> mpt: Okay, I'll take a look at those.
[14:19] <mspencer> mpt: You mentioned working on as much as I could do and having others work on the rest. How do I get others to help on it?
[14:20] <mspencer> mpt: I would like someone else to make an icon for it and probably to work on the Updates panel.
[14:20] <mpt> mspencer, promote it. Talk about it on Twitter, on your Web site if you have one, on relevnt mailing lists.
[14:20] <mpt> relevant, even
[14:21] <mspencer> mpt: Any of the Ubuntu mailing lists?
[14:22] <xnox> ubuntu-devel-discuss is a good one.
[14:22] <mspencer> xnox: thanks!
[14:23] <mspencer> mpt: Since you wrote the specification, are you in charge of all changes to it?
[14:25] <mpt> mspencer, no, anyone can make changes. With things I design, what usually happens is that I maintain the design parts of the specification while engineers add descriptions of how the system is structured etc. See <https://wiki.ubuntu.com/ErrorTracker> for example -- I didn't write any of the "How you can help" section.
[14:26] <mspencer> mpt: So what about new features, for example the bugs to report idea that you suggested?
[14:27] <xnox> how do i check if compiz is running with llvmpipe?
[14:27] <didrocks1> xnox: open the dash, if no transparence -> llvmpipe
[14:27] <xnox> didrocks1: I am not running dash =) i'm running X and ubiquity.
[14:28] <xnox> didrocks1: any other way?
[14:28] <didrocks1> xnox: can you spawn a terminal from compiz?
[14:28]  * xnox wants to make sure I'm starting compiz correctly by hand.
[14:28] <xnox> didrocks1: yes =)
[14:29] <didrocks1> xnox: /usr/lib/nux/unity_support_test -p
[14:29] <didrocks1> look at the vendor string
[14:29] <didrocks1> it will tell you if llvmpipe :)
[14:29] <xnox> cool, thanks.
[14:30] <mpt> mspencer, usually what happens is that a bug report requesting the feature is assigned to me. I update the spec to describe how it would be presented, and I link to the update from the bug report. See bug 449337 for example.
[14:30] <ubot2> Launchpad bug 449337 in software-center (Ubuntu) "does not support --addon-cd (regression from g-a-i)" [Medium,Triaged] https://launchpad.net/bugs/449337
[14:31] <xnox> didrocks: hmm... not getting any window decorators.
[14:31] <didrocks> xnox: do you have gtk-window-decorator running?
[14:31] <xnox> didrocks: nope =)
[14:31] <didrocks> the decor plugin is enabled?
[14:32] <xnox> didrocks: where can I check how the unity session is constructed?
[14:32] <didrocks> it's a little bit vague as a question :)
[14:32] <didrocks> do you know how the plugin system work? how do you start compiz?
[14:32] <mpt> mspencer, then I unassign it to show that anyone can implement it.
[14:33] <mspencer> mpt: Okay, thanks. Are there any tags to show that it is a feature request?
[14:33] <mpt> mspencer, no.
[14:34] <mpt> From "bug" to "missing feature" is a continuum. There's seldom a definite boundary.
[14:34] <xnox> didrocks: I start compiz like so `compiz --sm-disable --fast-filter --bg-image /path/to/background`
[14:34] <didrocks> so you have no plugin enabled
[14:34] <xnox> didrocks: looking at ubuntu session under gnome-session, it looks like I should start gnome-settings-daemon before starting compiz.
[14:34] <mspencer> mpt: If I get stuck on how to implement something, where is the best place to ask for help?
[14:35] <didrocks> xnox: hum, why does it matter?
[14:35] <xnox> didrocks: ok, how do I enable plugins
[14:35] <xnox> ah I need to specify them =)
[14:36] <didrocks> xnox: you need to either create a profile, either list all of them in the right order on the command line
[14:36] <mpt> mspencer, <http://developer.ubuntu.com/community/> has links to reference materials, Ask Ubuntu, and the #ubuntu-app-devel IRC channel.
[14:36] <xnox> didrocks: where is the default compiz profile then?
[14:36]  * xnox wants to take that as a base and trim the fat =)
[14:36] <xnox> (well strip it to the bone to be precise)
[14:37] <didrocks> xnox: look at /usr/share/glib-2.0/schemas/10_compiz-gnome.gschema.override
[14:37] <didrocks> "active-plugins"
[14:37] <xnox> didrocks: thanks.
[14:38] <mspencer> mpt: Thanks for all your help and thanks for showing me the project!
[14:38] <mpt> mspencer, thanks for getting involved. :-)
[14:38] <didrocks> yw
[14:43] <desrt> morning, peeps
[14:44] <stgraber> hey there, apparently everyime I decrease brightness on my machine, gnome-settings-dameon blows up, is that a known issue? (just noticed, haven't spent too much time debugging yet)
[14:44] <stgraber> (gnome-settings-daemon:26737): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GsdMediaKeysManager'
[14:44] <stgraber> Segmentation fault (core dumped)
[14:45] <mspencer> mpt: One more thing - you don't have a place for the in-progress spinner. Where do you want me to put it? Should I just use my own ideas for now?
[14:45] <mpt> mspencer, sure
[14:46] <mspencer> mpt: okay, that's what I'll do.
[14:46] <seb128> stgraber, known issue
[14:47] <stgraber> seb128: cool, won't spend any longer debugging it, will just stick gnome-settings-daemon in a while loop for now :)
[14:47] <seb128> lol
[14:47] <seb128> stgraber, or change the value from the system settings panel
[14:48] <stgraber> well, I happen to change brightness level pretty often, so having to open the window everytime is rather annoying, I prefer having g-s-d crashing but at least the brightness level set quickly so I can read my screen :)
[14:49] <seb128> hehe, well in any case I'm looking at it next, I hope it's not going to be hard and that we will have a fix in the next hour or so
[14:53] <pitti> desrt: hey Ryan, how are you?
[14:53] <desrt> awful
[14:53] <pitti> :( how's that?
[14:53] <stgraber> seb128: cool, thanks!
[14:53] <desrt> no coffe yet
[14:53] <pitti> hah
[14:53] <desrt> can't even type properly
[14:53] <pitti> desrt: so I guess it's a bad time still to ask you about dconf
[14:53] <desrt> nah
[14:53] <desrt> go ahead :p
[14:54] <pitti> desrt: context: I'm writing tests for g-settings-daemon; for that I run a private bus, and g-session and g-s-d on that
[14:54] <desrt> oh.  this sounds very interesting.
[14:54] <pitti> desrt: for the tests I temporarily need to change settings like idle-delay or sleep-inactive-ac-timeout
[14:55] <desrt> do you want to run these tests inside of a normal user account?
[14:55] <pitti> desrt: right now I remember which ones I changed and set them back to original values in tearDown(), but that's not very elegant
[14:55] <desrt> ie: in the account of someone who has their own dconf settings...
[14:55] <pitti> desrt: yes, so that they can be integrated into "make check" and don't need particular privs
[14:55] <desrt> pitti: so this problem is actually pretty boring
[14:55] <pitti> desrt: hadess suggested it might be possible to set $XDG_SOMETHING etc. to use a different dconf db?
[14:55] <desrt> you have two ways to slay it
[14:56] <desrt> first is indeed to set the XDG CONFIG HOME directory
[14:56] <desrt> that's probably the best
[14:56] <xnox> didrocks: with decor plugin I get window decoration but then my fake ubiquity-panel is left-alignment and "just right width" instead of full-screen width and right aligned.
[14:56] <pitti> right, as I need to fiddle with those anyway to create a temporary gnome-session session type
[14:56] <desrt> that will make (a) the process look to a different dir for the database
[14:57] <desrt> and (b) the service activated by the private bus will write there
[14:57]  * xnox will fiddle with it more.
[14:57] <pitti> desrt: it will also have the added benefit of not using the user's settings, but the schema ones, right?
[14:57] <desrt> pitti: at first
[14:57] <didrocks> xnox: seems you need to be nicer with decorators :)
[14:57] <desrt> pitti: of course, as you change settings, they will change
[14:57] <pitti> desrt: yes of course, that's what I want
[14:57] <desrt> pitti: there is a slightly strange complication here that perhaps you should pay attention to, though
[14:58] <desrt> pitti: although you will be using the same dconf database file, you will be sharing a different shm signalling mechanism (the file in the xdg runtime dir)
[14:58] <xnox> didrocks: i'll try gtk-window-decorator or see what's wrong with our minimalistic gnome-panet implementation in gtk.
[14:58] <didrocks> xnox: sounds good
[14:58] <desrt> pitti: in theory that's currently OK -- the shm mechanism currently only signals when the database needs to be reopened
[14:58] <pitti> desrt: you mean same dconf db file for all processes within the test, i.e. the scope in which I define the XDG dir?
[14:58] <desrt> so the result will be a bunch of programs have to spuriously reopen the dconf database (the real one, outside of the tests) even though nothing changed
[14:59] <xnox> didrocks: so far looking good.
[14:59] <pitti> desrt: ah, I see what you mean
[14:59] <desrt> pitti: i also don't like it because some day i may put another things in that file....
[14:59] <pitti> desrt: that at least sounds a lot better than me actually changing stuff in the user DB
[14:59] <desrt> pitti: so i'd recommend also changing the xdg runtime dir...
[15:00] <desrt> but note: that dir _must_ be on a native filesystem (read: not nfs/ecryptfs)
[15:00] <pitti> desrt: that sounds like a good safety precaution anyway
[15:00] <desrt> so perhaps you want to make a subdirectory in the runtime dir and point it at your subdir
[15:00] <pitti> desrt: mkdtemp ought to be okay, I guess
[15:00] <desrt> rather than making something inside of your tests...
[15:00] <desrt> pitti: mkdtemp is for the birds
[15:00] <desrt> pitti: the purpose of the runtime dir is to avoid having to pick secure tmp names
[15:00] <pitti> /tmp certainly ought to be a local dir?
[15:00] <desrt> pitti: maybe?
[15:01] <pitti> desrt: well, processes will use $XDG_RUNTIME_DIR, won't they?
[15:01] <pitti> if they hardcode /run/user/<username>/, I couldn't change it anyway
[15:01] <desrt> yes.  several o fthem.
[15:01] <desrt> nobody hardcodes that value.
[15:01] <desrt> they use g_get_user_runtime_dir()
[15:01] <pitti> *nod*
[15:02] <desrt> i think it's worth your while to create a temporary runtime dir
[15:02] <desrt> since various things use this
[15:02] <desrt> dconf, gvfs, keyring...
[15:02] <pitti> desrt: OOI, what does the "two zeros" file /run/user/martin/dconf/user do?
[15:03] <desrt> it's the convention to just name things there plainly (like 'dconf') since there is no concerns about security
[15:03] <desrt> but i guess you may have a situation where two instances of tests are being run at the same time.... so maybe use a PID?
[15:03] <desrt> pitti: that's the signal file
[15:03] <pitti> desrt: what's wrong with mkdtemp()? it's convenient to use, I don't need to think about it, and it will work
[15:03] <desrt> pitti: the second zero is meaningless.  it's created by seeking to position 1 and writing a zero
[15:04] <pitti> desrt: ok, thanks for the advice!
[15:04] <desrt> which is only done to force the first byte to exist with a default value of zero without risking overwriting it in a race if it's already there
[15:04] <desrt> the first byte is '1' to indicate "you need to reopen things now"
[15:04] <desrt> you will never ever see a '1' in that file, though
[15:04] <desrt> since by definition it means you are looking at a state copy of it
[15:05] <desrt> (ie: the service opens the file, unlinks it, then writes the '1'.... only so people who have it held open from before will see the '1')
[15:09] <didrocks> hey mterry! How was thanksgiving?
[15:09] <mterry> didrocks, hello!  Good!  Lots of pie
[15:09] <didrocks> and chicken? :)
[15:10] <desrt> didrocks: you're a month and a half late :)
[15:10] <didrocks> desrt: what what? :)
[15:10] <didrocks> for Canada I guess? ;)
[15:10] <didrocks> http://en.wikipedia.org/wiki/Thanksgiving seems to confirm
[15:11] <desrt> didrocks: one of my worst experiences in childhood was watching the pauly shore movie 'son in law'
[15:11] <desrt> for various reasons...
[15:12] <desrt> but one that sticks out the most is the fact that the movie features a halloween party, followed by a trip home for thanksgiving
[15:12]  * desrt looks back and shudders
[15:12] <didrocks> desrt's childhood, haunting him :)
[15:13] <pitti> desrt: if I want to restore all settings to the defaults in my tearDown(), do I need to track which ones I changed, or could I just wipe the 'user' file?
[15:13] <desrt> this movie was my exposure to the fact that things south of the border just aren't right...
[15:14] <desrt> pitti: the service will write files to the xdg user config and runtime dirs
[15:14] <desrt> pitti: if you kill the service and nuke those two temp dirs, then everything is gone
[15:15] <pitti> desrt: ah, I was afraid of that (not that easy to find out the pid of the service, is it?)
[15:15] <pitti> desrt: ah, probably easier to just call g_settings_reset on the whole power plugin schema
[15:15] <pitti> that sounds like a two-liner
[15:15] <desrt> pitti: ...
[15:15] <desrt> pitti: i'd assume that you planned to cleanup the tmpdirs you created?
[15:16] <desrt> pitti: just throw the entire test session into a cgroup and kill it when you're done
[15:16] <pitti> desrt: sure, I do; but if I do it for every test, I would be forced to kill the daemon
[15:16] <desrt> ahh
[15:16] <desrt> i see
[15:16] <desrt> you want to keep the fake session around for many tests
[15:16] <pitti> whereas, if I just reset all settings, it should work
[15:16] <desrt> pitti: the fastest/easiest thing for you is 'dconf reset -f /'
[15:16] <pitti> desrt: yes, that's a lot less overhead
[15:17] <pitti> desrt: oh, nice
[15:17] <desrt> pitti: or the equivalent, via the DConfClient API
[15:20] <mvo> glatzor: I would be keen to move "add_repo_add_key_and_install_app()" into aptdaemon itself to have it available for e.g. unity - would you accept a patch? or maybe via a plugin?
[15:25] <attente> is lp bzr down?
[15:27] <larsu> attente, haha came here to ask this...
[15:27] <tsdgeos> seems it is
[15:27] <tsdgeos> happening for lots of people
[15:29] <dobey> attente: #launchpad is the launchpad help channel
[15:29] <czajkowski> ello.....
[15:29] <seb128> ssh_exchange_identification: Connection closed by remote host
[15:29] <seb128> yeah, it's not behaving for me either
[15:29] <mvo> glatzor: i.e. I think what I want is a super-transaction so that I only need to send a single transaction-id to unity and that keeps track of the entire add/reload/install dance
[15:29] <seb128> czajkowski, hey
[15:29] <czajkowski> seb128: what's up
[15:30] <seb128> czajkowski, is code.launchpad.net known to be having issues?
[15:30] <seb128> larsu, attente: getting "ssh_exchange_identification: Connection closed by remote host" as well?
[15:31] <czajkowski> seb128: first I've heard
[15:31] <czajkowski> let me go and see
[15:31] <attente> yep, same thing
[15:31] <larsu> seb128, yes
[15:31] <glatzor> mvo, evening. sounds like a crazy name for a method :)
[15:31] <czajkowski> seb128: what are you seeing as it's loading fine for me
[15:31] <seb128> czajkowski, I get "ssh_exchange_identification: Connection closed by remote host" when trying to pull or push
[15:31] <seb128> czajkowski, bzr branch lp:unityThe
[15:31] <czajkowski> hmmm
[15:32] <glatzor> mvo, the problem is the resolving of the app name (package mapping)
[15:32] <mvo> glatzor: oh? maybe I'm missing something, but I know the expected pkgname in advance :)
[15:33] <tsdgeos> czajkowski: the web works fine, not the bzr repos
[15:33] <glatzor> mvo, currently unity only uses packagekit to talk to aptdaemon
[15:33] <tsdgeos> czajkowski: actually works fine again here :D
[15:33] <mvo> glatzor: aha, well, the install progress branch that I'm working on right now is using the native aptdaemon to track progress
[15:33]  * mvo can also not push his unity branch
[15:34] <glatzor> mvo, time to push a buy method to PackageKit?
[15:34] <seb128> back working here
[15:34] <mvo> glatzor: \o/
[15:34] <larsu> seb128, attentesame for me :)
[15:34] <didrocks> confirmed here
[15:34] <seb128> glatzor, mvo: speaking about pkgkit, should we sync 0.8 from debian experimental?
[15:34] <mvo> works here too now
[15:34] <glatzor> seb128, evening
[15:35] <glatzor> seb128, how are you
[15:35] <seb128> glatzor, hey, I'm good thanks, how are you?
[15:35] <attente> yep, works :)
[15:35] <czajkowski> minor wobbly thrown, all seems ok
[15:35] <glatzor> seb128, pk08 won't work with aptdaemon yet
[15:35] <czajkowski> shout again if any issues preferably in #launchpad :) b
[15:35] <seb128> glatzor, ok
[15:35] <seb128> czajkowski, will do, thanks
[15:35] <glatzor> seb128, I got a new job and it kept me quite busy.
[15:36] <seb128> glatzor, oh, congrats I guess ;-)
[15:36] <glatzor> seb128, what are your plans regarding gnome? do you need pk 0.8 at all?
[15:37] <seb128> glatzor, GNOME -> stay on 3.6, I don't need it no, I was mostly curious since some people suggested we should update before and I've no clue what the new version brings and breaks
[15:37] <glatzor> seb128, I started on a pk08 branch for aptdaemon some time ago. I will try to work on it this week.
[15:37] <glatzor> seb128, only API breaks :)
[15:37] <seb128> glatzor, so should be easy enough to adapt to it?
[15:38] <glatzor> seb128, the parallel transactions are not supported by either yum nor by aptcc.
[15:39] <glatzor> seb128, There are some pitfalls. There have been a lot of Dbus changes: bitwise transaction flags and integer based enums (before string based ones have been used)But the gobject client of packagekit hasn't changed much. If you use PkTask all should be fine.
[15:40] <seb128> glatzor, ok, you know better than me about the topic so your call wether we update or not
[15:40] <glatzor> seb128, the systemd integration is also not a killing feature for ubuntu - I guess :)
[15:40] <seb128> glatzor, we for sure don't have a need to update at the moment
[15:40] <seb128> indeed not ;-)
[15:40] <desrt> holy fuck
[15:40] <desrt> http://www.cbc.ca/news/canada/toronto/story/2012/11/25/toronto-ford-conflict-case-decision-release.html
[15:40] <desrt> it finally happened!
[15:41] <desrt> attente: ^^^
[15:41] <glatzor> mvo, what kind of parameters should the new method support?
[15:41] <Tm_T> tssk
[15:41] <attente> desrt: now he can follow his dream of coaching high school football :)
[15:45] <seb128> stgraber, g-s-d fix uploaded
[15:45] <glatzor> seb128, I am not sure how easy it is to port GNOME 3.6 to PackageKit 0.8. So we could be forced to keep the old one.
[15:46] <desrt> attente: srsly.
[15:46] <seb128> glatzor, well the reason I asked is because gnome-control-center 3.6 uses the pkgkit 0.8 api and I think it's the reason the "updates" button is not showing on raring
[15:46] <mvo> glatzor: it needs quite a bit of parameters :/ deb_line for the new repo, signing_key for the new repo, the application (pkgname). the software-center code has also license_key, license_key_path, oauth_token, but that should not be needed, thats fine to have that in two sepearte calls I think
[15:47] <seb128> glatzor, I'm not sure what other components are doing
[15:47] <jbicha> seb128: I don't think that updates button is very useful
[15:47] <seb128> jbicha, hey, thanks for the g-c-c bug cleaning and package work ;-)
[15:48] <seb128> jbicha, indeed not, it just made me wonder what version we should follow this cycle
[15:49] <glatzor> seb128, I will investigate this.
[15:49] <seb128> glatzor, thanks ... in any case not a high priority so please don't stress yourself over it ;-)
[15:50] <jbicha> glatzor: gpk 3.6 at least supports pk 0.8 also
[15:50] <glatzor> mvo, why do you need that transaction at all? for having a better progress bar in unity?
[15:51] <mvo> glatzor: yes
[15:52] <mvo> glatzor: I could do without surely :) but it would be nice to add the icon right at the start
[15:52] <glatzor> mvo, and how does unity trigger the buy process? from the dash?
[15:52] <mvo> glatzor: that is the eventual goal, yes
[15:52] <pitti> dput pygobject_3.7.2-0ubuntu1_source.changes
[15:53] <pitti> OMGponies
[15:53] <stgraber> seb128: yay! thanks
[15:53] <glatzor> mvo, so unity calls s-c and s-c calls unity?
[15:53] <seb128> pitti, you managed to get that working without the new glib?
[15:53] <desrt> seb128: the dependency relationship goes the other way, remember?
[15:53] <pitti> seb128: yes, I kept that in mind at the upstream side
[15:54] <pitti> seb128: I would like to get a newer g-i and glib, though
[15:54] <seb128> desrt, I though that was a locked batched update
[15:54] <pitti> I'm holding back patches
[15:54] <desrt> seb128: he has to upload the new pygobject _before_ the new glib :)
[15:54] <desrt> seb128: nah...
[15:54] <pitti> desrt: (I don't)
[15:54] <mvo> glatzor: unity calls aptdaemon, s-c will not be involved
[15:54] <pitti> g-i and glib are in lockstep
[15:54] <desrt> seb128: i used the term too strongly
[15:54] <desrt> pitti: not for any reasons that i know of
[15:54] <pitti> seb128: and I keep an eye on backporting fixes to the stable g-i branch
[15:54] <seb128> pitti, ok, I mixed g-i and pygobject
[15:55] <desrt> pitti: glib and g-i just have the normal dependency relationship
[15:55] <glatzor> mvo, so the buy code is moved to unity? right
[15:55] <mvo> glatzor: there will probably be a helper for now to trigger the add/reload/install dance, but it would be nice to move this helper into a more "official" place :)
[15:55] <mvo> glatzor: yeah
[15:55] <glatzor> mvo, s-c is dying?
[15:55] <mvo> glatzor: all code will move into it
[15:55] <mvo> glatzor: most likely, yes
[15:55]  * glatzor hugs mvo 
[15:56]  * mvo hugs glatzor
[15:56]  * desrt hugs rob ford
[15:56] <glatzor> mvo, but still secret? :)
[15:56] <mvo> glatzor: *cough* no
[15:58] <glatzor> mvo, do you know gdbus-codegen?
[15:58] <mvo> glatzor: no, sorry
[15:58] <mvo> glatzor: never used it
[16:00] <glatzor> mvo, quite handy. I used it last year (when starting on a glib based aptdaemon client library - which stalled)
[16:02] <glatzor> mvo, a problem could be the enum resolving (e.g. status and especially error codes) in unity
[16:02] <mvo> glatzor: meh, right. right now I'm using strings
[16:02] <mvo> glatzor: so thats easy
[16:03] <glatzor> mvo, if unit uses the PackageKit library it would be limited to the PackageKit error types (there is some basic mapping). And if you use the aptdaemon dbus api you have to extract the strings from aptdaemon.enums
[16:04] <glatzor> mvo, do you plan to move the code into a separate library?
[16:05] <mvo> glatzor: I moved it out into a seperate python helper so far
[16:05] <mvo> glatzor: but that still leaves the problem of the aggregation of the transaction progress
[16:07] <glatzor> mvo, the python helper could also provide a high level progress on a very small dbus interface
[16:08] <glatzor> mvo, this way you could reuse the s-c code
[16:09] <mvo> glatzor: hm, then unity would have to listen to two different dbus APIs for progress on normal installs or purchases or this small dbus interface would be used for both cases, I guess the later is ok
[16:11] <mitya57> Xubuntu users won't be able to purchase apps?
[16:11] <glatzor> mvo, the 4th dbus interface to install packages :) juhu
[16:14] <pitti> desrt: I'm getting GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not be saved or shared with other applications.
[16:14] <mvo> glatzor: exactly :(
[16:15] <pitti> desrt: I just noticed I don't have libdconf-dev installed; could it be that my jhbuild glib was not built with a dconf backend then?
[16:15] <pitti> desrt: or is that something else?
[16:17] <pitti> desrt: hm, I don't see any reference to "dconf" in glib's build system
[16:17] <seb128> pitti, it's a backend, those are not hardcoded at the glib level
[16:17] <desrt> pitti: there's another package for the backend
[16:17] <pitti> oh
[16:18] <desrt> dconf-gsettings-backend - simple configuration storage system - GSettings back-end
[16:18] <pitti> right, so that has a jhbuild module?
[16:18] <desrt> no
[16:18] <desrt> that's just 'dconf'
[16:18] <pitti> ah, so I need dconf in jhbuild
[16:19] <desrt> ohhh
[16:19] <desrt> yes
[16:19] <desrt> the reason is because glib looks for its modules at a hardcoded path relative to its own install prefix
[16:19] <pitti> there doesn't seem to be a dependency on this, so I didn't notice
[16:19] <pitti> desrt: thanks, building
[16:20] <desrt> pitti: it's tricky...
[16:20] <pitti> configure: error: Vala 0.17.0 not found.
[16:20] <pitti> *sigh*
[16:20] <desrt> because dconf has a forward dependency on glib
[16:21] <desrt> but glib depends back again on dconf (through dependency inversion)
[16:21] <seb128> pitti, remind me that I wanted to set 0.18 as default valac
[16:21] <desrt> same as the story for glib-networking and gvfs...
[16:21] <pitti> right, so I probably need a VALAC or so
[16:23] <pitti> desrt: how do you build dconf in jhbuild? mangling /usr/bin/valac manually?
[16:23] <desrt> pitti: jhbuild's dconf module has a dependency on vala....
[16:23] <desrt> if you just type 'jhbuild build dconf' it ought to work
[16:24] <pitti> oh, it's enough to just uninstall vala 0.16
[16:24] <desrt> even that should not be required
[16:24] <desrt> the valac installed by jhbuild should end up with the name 'valac' and it should be in the PATH before the distro one
[16:25] <pitti> right, but I'd like to avoid having to build vala itself
[16:25] <seb128> pitti, or just update-alternative --config valac
[16:25] <desrt> pitti: why?
[16:25] <desrt> pitti: embrace the chaos of jhbuild :)
[16:41] <pitti> bonsoir mes amis
[16:41] <didrocks> bonne soirée pitti
[16:43] <seb128> pitti, bye
[17:01] <mterry> didrocks, seb128: cwayne from QA has a metapackage in NEW that I sponsored: ubuntu-testing-tools.  Could I beg a NEW review from one of you?
[17:01] <mterry> (it's for nexus7 testing)
[17:03] <didrocks> mterry: sure, will do it tomorrow morning if seb128 doesn't beat me to it :)
[17:03] <seb128> didrocks, mterry: looking, if it's a dummy package it's likely trivial
[17:05] <seb128> didrocks, mterry: NEWed
[17:05] <didrocks> sweet :)
[17:06] <mterry> seb128, thanks!
[17:06] <seb128> mterry, yw ;-)
[17:14]  * didrocks counts 14 projects now deployed for daily landing into ubuntu (maybe 15 soon)
[17:25] <kenvandine>  didrocks, yay!
[17:26] <didrocks> :)
[17:30] <seb128> hey kenvandine, had a good thanksgiving?
[17:31] <kenvandine> yup
[17:31] <kenvandine> seb128, have a good weekend?
[18:11] <mterry> tedg, do you know why some packages use run-xvfb.sh instead of xvfb-run?
[18:12] <tedg> mterry, Well, I wrote run-xfvb.sh...
[18:12] <tedg> mterry, I wasn't aware of an xvfb-run, but if I was to guess, I'd say because it doesn't fallback to the local display if there is on.
[18:12] <tedg> one
[18:13] <mterry> tedg, yeah I don't think it does.  That's a feature you wanted?
[18:14] <tedg> mterry, Yeah, so I can see the tests when running them on a local branch.
[18:15] <tedg> mterry, But, run-xvfb.sh could call the other easily enough.
[18:16] <mterry> tedg, sure
[18:16] <mterry> It could be a simple if ! $DISPLAY; then xvfb-run
[18:17] <tedg> Yup.  Really if you're going to put time in there I'd rather go to the dummy X driver.
[18:17] <tedg> That's what xorg-gtest uses.
[18:17] <tedg> It seems to be a better solution than xvfb overall.
[18:18] <mterry> tedg, I'm not familiar with it
[18:26] <tedg> mterry, It's cnd's magic gtest harness for doing Xorg testing.  But the way it works is sets up a normal xorg server with a special driver.
[19:05] <seb128> grrr, powerpc or how to "freeze" the archive easily
[19:05] <seb128> (having only 2 builders running for it on raring and one picked libreoffice ... say bye to anything moving to raring before tomorrow)
[19:20] <zzecool> Hello is anyone here using Gnome 3 ppa ?
[19:22] <zzecool> I just update my ubuntu 12.10 with gnome 3 ppa and lost global menu only in gnome applications ( appmenu-gtk fail to load the gtk module even thought it is installed )
[19:23] <zzecool> any help is appreciated
[19:50] <zzecool> anyone ?
[19:50] <zzecool> ;/
[19:59] <attente> zzecool, maybe try checking the LD_LIBRARY_PATH to see if it points to where the gtk module is located?
[20:00] <zzecool> attente: can you please advice me on this ?
[20:00] <zzecool> how do i check this
[20:00] <zzecool> ?
[20:00] <attente> echo $LD_LIBRARY_PATH
[20:00] <zzecool> sec
[20:00] <zzecool> nothing on output]
[20:01] <zzecool> attente: the result is nothing empty space
[20:01] <attente> so i guess try to set the environment variable to wherever the gtk module is located
[20:02] <attente> let me see if i can find where it is on my machine
[20:02] <zzecool> ohh thank you
[20:06] <attente> zzecool: can you try:
[20:06] <attente> LD_LIBRARY_PATH=/usr/lib/gtk-3.0/3.0.0/menuproxies/ gedit
[20:07] <seb128> attente, are you sure those are ld loaded?
[20:08] <seb128> attente, e.g not dlopen-ed?
[20:08] <zzecool> yes just a sec
[20:08] <zzecool> attente: same problem
[20:08] <zzecool> no global menu
[20:08] <seb128> jbicha, is gnome3 ppa known to break appmenu integration?
[20:09] <attente> seb128: nope, wasn't sure
[20:09] <zzecool> seb128:  i spoke to the webupd8.com Guy and he said that it is working for him just fine
[20:10] <zzecool> maybe im an exception
[20:10] <zzecool> indicator-appmenu  appmenu-gtk appmenu-gkt3 appmenu-qt is install
[20:10] <zzecool> as an info
[20:10] <seb128> zzecool, echo $UBUNTU_MENUPROXY ?
[20:10] <zzecool> sec
[20:11] <zzecool> libappmenu.so
[20:11] <zzecool> seb128: libappmenu.so
[20:11] <seb128> zzecool, dpkg -l | grep libgtk-3-0
[20:12] <zzecool> libgtk-3-0:amd64       3.6.2-0ubuntu1~ubuntu12.10.1     amd64    GTK+ graphical user interface library
[20:13] <zzecool> seb128:  btw thanks for the support  , i hope we will find the culprit
[20:15] <seb128> zzecool, well, it could be that gtk version, where did you get it?
[20:15] <zzecool> sec
[20:15] <zzecool> let me chekc
[20:16] <zzecool> from the gnome 3 ppa
[20:16] <seb128> yeah, just found it there as well
[20:16] <zzecool> yeap
[20:17] <zzecool> if you read my first post i said that the problem appeared after i did and upgrade using this ppa
[20:17] <seb128> zzecool, strace eog 2>&1 | grep appmenu
[20:17] <seb128> can you copy that on pastebin.ubuntu.com or similar?
[20:17] <dupondje> any big changes in Optimus support yet since 12.10 ?
[20:17] <jbicha> seb128: we needed a newer gtk so that gnome-themes-standard wouldn't break everything
[20:17] <seb128> dupondje, what's Optimus?
[20:17] <zzecool> seb yes just a sec
[20:17] <dupondje> seb128: Hybrid graphic card stuff for Nvidia
[20:17] <seb128> jbicha, why would g-t-s break everything?
[20:18] <seb128> dupondje, try asking on #ubuntu-x
[20:18] <jbicha> seb128: https://bugzilla.gnome.org/show_bug.cgi?id=689027
[20:18] <ubot2> Gnome bug 689027 in general "Adwaita 3.6.2 GTK theme with GTK 3.6.0 makes everything segfault" [Critical,Resolved: fixed]
[20:18] <seb128> jbicha, don't update the theme? ;-)
[20:19] <seb128> jbicha, well anyway, it's a ppa so your call ... did that break appmenu for other users?
[20:19] <jbicha> seb128: well by the time I figured that out it was too late :(
[20:19] <zzecool> seb128: http://pastebin.com/UyKQYVwA
[20:20] <jbicha> the first I heard of the appmenu problem was zzecool's on webupd8.org earlier today
[20:20] <zzecool> jbicha: im happy that you read it :P
[20:20] <seb128> zzecool, dpkg -L appmenu-gtk3 | grep .so
[20:21] <zzecool> seb128: /usr/lib/gtk-3.0/3.0.0/menuproxies/libappmenu.so
[20:21] <seb128> zzecool, dpkg -l | grep appmenu-gtk3
[20:21] <zzecool> appmenu-gtk3                                                12.10.2-0ubuntu1                          amd64        Export GTK menus over DBus
[20:21] <zzecool> oups sry
[20:22] <seb128> yeah, ok
[20:22] <seb128> jbicha broke it :p
[20:22] <zzecool> ?
[20:22] <zzecool> seb128: we found the problem ?
[20:22] <seb128> zzecool, wget https://launchpad.net/ubuntu/+source/appmenu-gtk/12.10.2-0ubuntu3/+build/3988904/+files/appmenu-gtk3_12.10.2-0ubuntu3_amd64.deb and dpkg -i that
[20:22] <seb128> zzecool, yes, that version of appmenu is not multiarched and the raring gtk dropped fallback for non multiarch dirs
[20:22] <seb128> jbicha, ^
[20:23] <jbicha> seb128: any ideas what else could be broken by the multiarch fun?
[20:23] <zzecool> that why i didnt found the 32bit version in the var/cache/apt/archives when searching ?
[20:23] <seb128> jbicha, unico, adwaita, appmenu
[20:23] <seb128> zzecool, could be
[20:23] <zzecool> ahhh nice
[20:24] <zzecool> seb128: Thank you very much
[20:24] <jbicha> hmm, unico didn't seem broken...
[20:24] <zzecool> :)
[20:24] <seb128> jbicha, you should probably revert that fallback drop in the quantal version
[20:24] <seb128> zzecool, yw!
[20:24] <zzecool> make sure to update the ppa for others as well :)
[20:24] <seb128> jbicha, well, it is for pretty sure: https://launchpad.net/ubuntu/+source/gtk3-engines-unico/1.0.2+r139-0ubuntu3
[20:25] <seb128> jbicha, it was broken it in raring when gtk got uploaded so I doubt it will work in quantal
[20:25] <zzecool> i will log out log in and tell you the results
[20:25] <zzecool> :)
[20:27] <zzecool> seb128: thank you very much it worked :)
[20:27] <seb128> zzecool, glad it worked, thanks for pointing the issue
[20:27] <zzecool> np
[20:27] <seb128> next is to get jbicha to fix the ppa for everybody else ;-)
[20:27] <zzecool> seb128: i wasnt able to post a bug to the ppa
[20:27] <jbicha> seb128: ah, debian/patches/061_multiarch_module_fallback.patch wasn't mentioned in the changelog
[20:27] <zzecool> and i also sent a main with all the details to the ppa admin
[20:28] <zzecool> mail*
[20:28] <jbicha> zzecool: you'll actually want to downgrade to quantal's appmenu-gtk when this is fixed
[20:28] <seb128> jbicha, yeah, it did bite us by surprise in raring as well...
[20:28] <zzecool> appmenu-gtk is form quantal not form the gnome 3 ppa
[20:28] <zzecool> form*
[20:28] <zzecool> from**
[20:28] <seb128> jbicha, Laney did some cleanups in the patches during the UDS session without updating the changelog
[20:29] <mterry> seb128, were you going to promote gnome-control-center-unity, or shall I file a MIR?
[20:29] <GunnarHj> charles: ping?
[20:29] <seb128> jbicha, then I went some weeks later to do a simple update and got bitten by it after upload
[20:31] <seb128> mterry, no need of MIR, that was waiting on something to recommends it and we forgot to run the command then, doing it
[20:31] <mterry> seb128, cool, thanks!
[20:31] <zzecool> jbicha: any estimate about the fix so i will not get surprised ?
[20:32] <seb128> mterry, yw!
[20:32] <seb128> (done)
[20:34] <jbicha> zzecool: I'm pushing now, it will take about an hour to build & publish
[20:35] <seb128> jbicha, thanks for fixing ;-)
[20:35] <jbicha> or 2 hours depending on how busy the builders are
[20:35] <zzecool> jbicha: i hope i will not have any problem to downgrade :)
[20:35] <seb128> jbicha, sorry about the changelog/lack of warning issue
[20:36] <jbicha> I remembered the breakage earlier in raring but I didn't read the diff carefully
[20:37] <zzecool> jbicha: one last question , is there any easy way to downgrade - ppapurge gnome 3 ppa ? because yesterday with the gnome theme bug  i had to remove allmost my whole system and reinstall with ubuntu-desktop package
[20:37] <jbicha> yes, you can install the ppapurge package and use that
[20:37] <zzecool> i got all the crazy segfaults and i though im doomed so i proceed
[20:37] <jbicha> *ppa-purge
[20:38] <zzecool> jbicha: i have it but its doesnt working with this ppa because there is a dependency  with libgtk-3 i think
[20:39] <zzecool> let me check now and tell you
[20:41] <zzecool> jbicha: here you are i was right it is libgtk-3 http://pastebin.com/p5v9gi4Z
[20:44] <zzecool> i know that ppa-purge use aptitude  that it doesnt support multiarch  but im not sure that this is the prob here right ?
[20:45] <jbicha> I don't know; you can file a bug against ppa-purge
[20:47] <zzecool> ok thank you
[20:47] <zzecool> :)
[20:47] <zzecool> jbicha: goodnight and thanks