[04:14] <pitti> Good morning
[05:23] <larsu> morning!
[07:03] <pitti> hey larsu
[07:05] <larsu> hi pitti! Wie war dein Wochenende?
[07:06] <didrocks> hey larsu!
[07:06] <pitti> larsu: quite nice, thanks! I did some gardening, had a nice biking round, and (less nice) spent my Sunday evening with plumbing (congested pipes in the kitchen)
[07:06] <pitti> larsu: und Deins?
[07:06] <larsu> bonjour didrocks!!
[07:07] <didrocks> pitti: congested pipes, doesn't sound fun :/
[07:08] <larsu> pitti: uh oh, hope the kitchen is usable again ;) My girlfriend's mom was in town. Had some nice walks in Berlin's parks, some (slight) sightseeing and some theatre
[08:00] <seb128> good morning desktopers!
[08:00] <darkxst> hey seb128
[08:01] <mvo> hey seb128
[08:03] <darkxst> seb128, would you be open to backporting 3.12 power plugin/panel for u-s-d/u-c-c?
[08:04] <darkxst> (for upower transition)
[08:04] <Laney> morning
[08:04] <seb128> hey darkxst mvo Laney
[08:04] <seb128> darkxst, did you get that upower transition approved by the r-t?
[08:04] <larsu> hi $PEOPLE_SEB128_JUST_MENTIONED
[08:04] <Laney> good weekends?
[08:05] <seb128> somebody on #debian-gnome mentioned some days ago that trunk had another ABI change
[08:05] <seb128> we don't want to have to do 2 transitions if that's the case
[08:05] <seb128> we should wait for the ABI to stabilize
[08:05] <seb128> the Debian guys were mentioning maybe reverting the GNOME changes to use the old upower for the coming Debian stable
[08:05] <darkxst> seb128, since when do need r-t approval this early in the cycle?
[08:06] <seb128> that sort of transition impact on all flavors
[08:06] <ochosi> morning everyone! i'm sorry if this isn't the right channel, but i'm a bit lost with this. i found a (few) bugs in xdg-screensaver - any idea who i could talk to?
[08:06] <darkxst> seb128, g-s-d is a complete mess, they did major refactoring of the power plugin, which is all mixed up with the api changes
[08:06] <seb128> including touch
[08:07] <seb128> ochosi, we don't have anyone looking at xdg-utils bugs afaik, I'm happy to sponsor patches though
[08:07] <ochosi> seb128: ok, thanks, that's good to know!
[08:10] <didrocks> hey Laney, darkxst, ochosi
[08:10] <darkxst> hey didrocks
[08:10] <didrocks> and mvo :)
[08:10] <mvo> hey didrocks!
[08:11] <ochosi> seb128: first of all, it carries a useless patch that only duplicates things. that one should simply be dropped from my pov: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/xdg-utils/trusty/view/head:/debian/patches/xserver-blanking.diff
[08:11] <darkxst> seb128, the api changes are by themselves not that bad, g-s-d is a mess due to the included re-factoring
[08:12] <darkxst> most other components only have fairly simple patches
[08:12] <seb128> darkxst, looking at Debian that transition doesn't seem to be that easy
[08:12] <seb128> but anyway, it seems you guys are doing good job on it, I see you listed components, patches, etc
[08:12] <seb128> so it should be fine
[08:13] <seb128> but it impacts on several flavors, so it would be worth communicating about it on ubuntu-devel@
[08:13] <Laney> did you check the d-bus api?
[08:14] <darkxst> Laney, as best I can while codesearch is broken
[08:14] <Laney> mmm
[08:17] <pitti> hey Laney
[08:17] <pitti> bonjour seb128 !
[08:17] <Laney> hey pitti
[08:17] <Laney> I'd have merged a system-settings branch for you btw ;-)
[08:17] <seb128> pitti, salut! ça va bien ?
[08:17] <Laney> hwo's it going?
[08:17] <pitti> seb128: félicitations pour le match de football gagné hier :)
[08:17] <pitti> seb128: oui, merci
[08:17] <pitti> Laney: heh, I grabbed another guinea pig for the time being :)
[08:26] <darkxst> Laney, database still seems to be incomplete
[08:27] <Laney> I never fixed it :(
[08:27] <darkxst> obviously!
[08:27] <seb128> pitti, merci ! bonne chance pour le match ce soir
[08:30]  * darkxst wonders what is going on in debian land if they thing gjs transition is harder than upower!
[08:31] <Laney> speaking of transitions
[08:31]  * Laney has prepared evo 3.12
[08:31] <Laney> (H)
[08:38] <Laney> darkxst: sorry, I'll look at it soon hopefully
[08:38] <Laney> the code is written in go which I don't know so it's not a very appealing task
[08:51] <seb128> Laney, saw bug #1330033 ?
[08:51] <Laney> nein
[08:53] <ochosi> seb128: i hope you're ok with me setting you as a reviewer for my xdg-utils MR
[08:54] <Laney> looks new in 2.41
[08:56] <seb128> ochosi, that's fine yes, seems like you targeted the wrong Vcs though (lp:xdg-utils)
[08:56] <seb128> ochosi, is that change upstream btw?
[08:56] <pitti> seb128: merci :)
[08:57] <ochosi> seb128: it's not yet, but i will propose it there too. thing is, this is already affecting us in trusty, so it'd be nice to get it into ubuntu asap (and we're already carrying a - partly useless - delta with upstream)
[08:57] <ochosi> seb128: thing is, xdg-utils isn't even *that actively* maintained upstream...
[08:58] <seb128> ochosi, yeah, it's fine to not have changes in upstream vcs first, but we like to have a bug report reference at least, so we ensure it's reported there/might get included later
[08:58] <seb128> ochosi, if we don't do that, things often don't get upstreamed later and we create a delta and extra work for us
[08:59] <ochosi> seb128: ok, will look into doing that right now, shall i add a link in a comment to the MR?
[08:59] <seb128> ochosi, that would be nice, thanks
[08:59] <seb128> or ideally add it to the patch header, but I can do that for you when I upload
[09:04] <seb128> pitti, one problem with the "upload and commit to trunk" is that your might create issues for things already built and being tested in a silo
[09:05] <pitti> seb128: ah, right
[09:05] <seb128> like they are going to hit the issue that the revision is missing when they try to publish
[09:05] <pitti> meh, not having trunk is really maddening
[09:05] <pitti> seb128: ok, I'll just continue with dialer-app then and let the project maintainers do that update themselves
[09:06] <pitti> it wasn't for lack of trying on my side, at least :)
[09:06] <Laney> they'll just have to merge and rebuild
[09:06] <Laney> but yes :/
[09:06] <seb128> pitti, you can easily check is a component is a silo using the CI bot with "where <source>"
[09:06] <seb128> is in a silo*
[09:07] <seb128> pitti, btw should we start include those changes or should we wait?
[09:07] <seb128> like for settings we can get that in the next landing
[09:07] <pitti> seb128: it's fine to include them, as long as you don't mind having translations dropped for a few days
[09:07] <seb128> k
[09:24] <pitti> seb128: btw, I uploaded a fixed usb-creator for bug 1294877 (the thing you poked me about last week); but it's still not working well, I also sometimes get a failure about "failed to install boot loader"
[09:24] <pitti> usb-creator is in a rather sorry state :/
[09:25] <seb128> pitti, yeah, xnox needs to look at it
[09:25] <seb128> pitti, thanks for looking at it!
[09:27] <ochosi> seb128: done. added as a comment as i wasn't sure how/where to do that with the patch header
[09:27] <ochosi> seb128: i'll be looking at what you do with it though and try to learn from it
[09:28] <seb128> ochosi, ok, I just usually add some comment lines on top of the .patch
[09:28] <seb128> like
[09:28] <seb128> # Description: support xfce better
[09:28] <ochosi> ah
[09:28] <seb128> # Upstream: <url<
[09:28] <ochosi> right
[09:33] <ochosi> there's also that patch that could be dropped, i presume you need a MR for that too?
[09:33] <ochosi> s/could/should/
[09:34] <seb128> ochosi, which one? no need, I can have a look
[09:34] <ochosi> this one: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/xdg-utils/utopic/view/head:/debian/patches/xserver-blanking.diff
[09:34] <ochosi> it just duplicates code
[09:35] <ochosi> this is the bugreport for it: https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/1330386
[09:35] <seb128> you mean it was included upstream and not dropped from our patch serie?
[09:35] <ochosi> that'
[09:35] <ochosi> s the only explanation i could find
[09:35] <seb128> ok, thanks
[09:35] <ochosi> otherwise it makes no sense
[09:35] <seb128> let me look
[09:36] <ochosi> (fwiw, i've also removed that patch locally and tested things without it. as it's all bash-scripts it's fairly easy to test)
[09:37] <seb128> ochosi, yeah, http://cgit.freedesktop.org/xdg/xdg-utils/commit/scripts/xdg-screensaver.in?id=c9551d250722081cbf7d6611f417bc597765e5c9
[09:38] <ochosi> righty
[09:38] <ochosi> there you go
[09:38] <ochosi> sry, i guess i could've dug that up myself when doing the bugreport...
[09:38] <seb128> no worry
[09:38] <seb128> thanks for pointing it out ;-)
[09:38] <ochosi> np ;)
[09:39] <pitti> seb128: bug 1296275> argh, I'm a moron
[09:39] <seb128> pitti, did you include the wrong change?
[09:39] <pitti> ACTION="add"
[09:39] <pitti> that wanted to be ==
[09:39] <pitti> and actually, it's redundant
[09:39] <ochosi> seb128: one more question though, if i introduce a new feature to xdg-screensaver (i.e. restoring the correct value of xset), could we handle this the same way? (MR assigned to you, upstream bugreport+patch)
[09:40] <ochosi> (actually could be configured bugfix)
[09:40] <seb128> ochosi, yes
[09:40] <ochosi> s/configured/considered/
[09:40] <ochosi> weird mistype...
[09:40] <ochosi> seb128: ok thanks a bunch! i guess we need to file for SRU to get this into trusty?
[09:41] <seb128> ochosi, yes, you can use the existing bugs, you just need impact/test case/regression potential info on those
[09:42] <ochosi> seb128: ok, will look into that later today or whenever the changes have been pushed. thanks again!
[09:42] <seb128> ochosi, yw!
[11:02] <Sweet5hark> ricotz: FWIW https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-staging-main has 4.2.5~rc2 -- I havent smoketested it to install clean though ...
[11:12] <Sweet5hark> ricotz: looking good, copied
[11:16] <seb128> grrr
[11:16] <seb128> why is the ubuntu desktop next iso still stopping on the lightdm screen asking for an username
[11:17] <seb128> the lightdm log states it's try to log user "(null)"!
[11:17]  * seb128 debugs
[11:18] <Laney> :(
[11:18] <ogra_> probably uses "phablet" anywhere hardcoded ?
[11:20] <seb128> ogra_, no, we are using unity-greeter like desktop
[11:24] <ogra_> seb128, well, that wouldnt help if the session wrapper has the homedir/user hardcoded
[11:25] <seb128> ogra_, well, the log has user "(null)" that seems wrong in any case
[11:25] <darkxst> seb128, can you guys fork gnome-desktop ;)
[11:25] <seb128> darkxst, no
[11:25] <ogra_> true
[11:26] <darkxst> seb128, yes, its much easier than the alternatives!
[11:26] <seb128> darkxst, did Laney said, earlier in the cycle, that he was wanting to help you land this one?
[11:26] <darkxst> seb128, no laney hasn't mentioned that to me
[11:27] <seb128> lying
[11:27] <darkxst> whos lying?
[11:27] <seb128> you
[11:27] <seb128> darkxst, http://irclogs.ubuntu.com/2014/04/28/%23ubuntu-desktop.html#t11:23
[11:27] <seb128> you were part of that discussion
[11:27] <seb128> that was a reply to you
[11:28] <seb128> it's good that we have logs ;-)
[11:29] <darkxst> seb128, yes, even bet that you can just dig them up that quick ;)
[11:29] <darkxst> ^better
[11:29] <seb128> lol
[11:29] <seb128> well, I just had to grep for gnome-desktop mentions in that channel and grep for Laney on the results
[11:30] <darkxst> but still, I think it probably easier to fork it, libunity-desktop
[11:30] <darkxst> only for u-s-d and u-c-c
[11:31] <darkxst> everything else likes the apps, that shouldn;t even be using it... can continue on using the real library
[11:31] <seb128> what happens then e.g eog or cheese or nautilus or ...
[11:31] <seb128> +to
[11:32] <darkxst> seb128, they will be linked to one or the other
[11:32] <darkxst> doesnt matter too much which
[11:32] <seb128> well, those libraries are going to have common symbols?
[11:33] <seb128> is that likely to create conflicts?
[11:33] <darkxst> seb128, only if someone trys to link against both, (which is a really bad idea anyway)
[11:34] <seb128> right, seems there is no libs in the rdepends list
[11:34] <seb128> Laney, do you have an opinion on that?
[11:35] <darkxst> I think mostly the apps are using the thumbnailers, which upstream agreed could probably be moved into gtk, however I havent had time to chase that one up
[11:35] <Laney> what's the problem with doing the normal update?
[11:35] <darkxst> its also likely that some apps, nautilus maybe, are using deprecated modules
[11:36] <darkxst> Laney, all XRANR stuff was moved into mutter
[11:36] <darkxst> in fact anything X related was moved out
[11:37] <darkxst> I did rip out the code from mutter and make a standalone daemon, last cycle and that would still work
[11:37] <darkxst> but... things are just going to keep diverging
[11:43] <Laney> what uses the X stuff on our side?
[11:43] <Laney> I think splitting it out is okay
[11:43] <darkxst> Laney, the X stuff is pretty limited to u-s-d/u-c-c
[11:44] <darkxst> the apps just use stuff, that was never really intended to be in gnome-desktop
[11:44] <darkxst> but is there
[11:44] <Laney> would be happy to try the split first
[11:44] <Laney> if it's removed then it won't be changing
[11:45] <seb128> like copy that code in u-s-d/u-c-c?
[11:45] <Laney> darkxst already made a daemon for it
[11:45] <Laney> not sure what source it lives in
[11:45] <seb128> new source
[11:45] <Laney> seems okay
[11:45] <Laney> or a binary in one of those
[11:45] <Laney> doesn't matter to me
[11:45] <seb128> well, it's new code/js
[11:45]  * darkxst ripped the code from mutter and put in a daemon
[11:45] <seb128> I'm not even sure we want gjs on our iso
[11:46] <Laney> not a fork of the old stuff?
[11:46] <darkxst> seb128, no gjs involved
[11:46] <seb128> darkxst, oh, that part is only C?
[11:46] <darkxst> seb128, yes
[11:46] <seb128> Laney, no, a fork of the new gnome-shell code
[11:46] <seb128> with talking over dbus
[11:46]  * Laney nod
[11:46] <seb128> it has potential for bugs
[11:46] <seb128> but I guess we can try it out
[11:47] <seb128> and if doesn't work, look at doing a plan B by copying some old gnome-desktop code
[11:47] <darkxst> https://github.com/darkxst/displayconfig
[11:48] <darkxst> seb128, its all dbus
[11:48] <darkxst> and nothing to do with gnome-shell
[11:48] <darkxst> its all in mutter
[11:48] <Laney> okay so what I said last time still stands, ping me when you have stuff for sponsoring
[11:48] <seb128> those are the same thing to me
[11:48] <seb128> but noted ;-)
[11:49] <darkxst> seb128, for one there is no JS/gjs in mutter!
[11:49] <seb128> ls
[11:49] <seb128> ups
[11:50] <darkxst> but my concern, is this will continue to block us every cycle....
[11:50] <darkxst> I mean I can just go an rebase everything on 3.12 which it probably not to bad, but who knows what will happen in 3.14 and beyond
[11:51] <davmor2> seb128: No File or Directory ups located
[11:51] <Laney> if it becomes too horrible then forking will still be an option
[11:53] <seb128> davmor2, lol
[11:53] <seb128> well, it doesn't seem like we need to block, we can use that standalone service
[11:54] <seb128> or copy the old functions in u-s-d
[11:55] <Laney> yep
[11:55] <darkxst> there are probably a dozen patches each for u-s-d and u-c-c
[11:56] <seb128> hum, how much code are we talking about there? like how many functions are being dropped from gnome-desktop in the update?
[11:57] <seb128> I think my preferred solution would be to copy those functions/rename then if needed in u-s-d/u-c-c
[11:57] <seb128> it's a safer option than stacking changes and adding a new dbus service
[11:58] <darkxst> u-s-d/u-c-c patches just change from using gnome-desktop to dbus
[11:58] <darkxst> the code that moved was *all* the display config code
[11:58] <seb128> well, it might still be easy to copy ;-)
[11:58] <seb128> like just copy a bunch of .c/.h files in u-s-d source
[11:59] <darkxst> seb128, I doubt it would be that easy!
[11:59] <seb128> :-(
[11:59] <seb128> so back to square 1
[12:00] <darkxst> right, make libunity-desktop
[12:00] <darkxst> but only used by u-s-d/u-c-c
[12:00] <darkxst> I think that is the easiest option, avoiding the dbus daemon
[12:01] <Laney> but it only needs the X functions
[12:02] <darkxst> I suppose you could split out the X stuff into a new library
[12:02] <darkxst> but for example only 90% of xrandr plugin was moved into mutter (atleast for 3.10)
[12:04] <darkxst> or another option would be to rebase the u-s-d/u-c-c code off 3.12 for certain plugins/modules?
[12:04] <darkxst> but you would still need the daemon
[12:05] <seb128> we don't want the new display UI
[12:05] <darkxst> seb128, yes I have heard mpt doesnt like the egglistboxes
[12:06] <mpt> What’s an egglistbox?
[12:06] <seb128> well, it's also that our display panel is quite different from the upstream one
[12:06] <seb128> we have controls for the high dpi stuff there, and for the launcher and screen barrier
[12:07] <seb128> mpt, those sort of panels, http://afaikblog.files.wordpress.com/2013/01/privacy.png
[12:07] <darkxst> seb128, that is a forked panel? anyway updating won't affect that
[12:07] <seb128> darkxst, it's the "display" one with a stack of patches
[12:07] <mpt> oh, ha, yes
[12:08] <darkxst> seb128, nope its a forked panel
[12:08] <seb128> ?
[12:08] <darkxst> seb128, its called "Appearance" or something
[12:08] <seb128> well, a stack of patches can be called a fork, if that's what are you discussing
[12:08] <seb128> no, that's the background panel
[12:08] <seb128> display is the xrandr one
[12:08] <seb128> background/appearance is the wallpaper
[12:09] <darkxst> hmm so maybe its just a stack of XDG_CURRENT_DESKTOP patches then, but I don't think so?
[12:09] <seb128> it is
[12:10] <seb128> http://i.stack.imgur.com/TULXr.png
[12:10] <mpt> The Launcher options could/should be moved to “Appearance” [sic] > “Behavior” if that would make syncing easier
[12:10] <seb128> well, that image is an earlier version, so the UI is not really nice, we did some tweaks since
[12:10] <darkxst> seb128, oh that looks ancient!
[12:10] <seb128> darkxst, that's what we current have...
[12:11] <seb128> (well, expect we fixed the alignments issues and some glitches)
[12:11] <seb128> except*
[12:13] <darkxst> seb128, https://www.dropbox.com/s/6r6jzssyjdnqd5y/Screenshot%20from%202014-06-16%2022%3A12%3A00.png
[12:14] <darkxst> and I know you will dislike that :)
[12:15] <seb128> darkxst, indeed, but that's not even the point, it's just that the UI is so different that we can't really "rebase our code on 3.12"
[12:15] <seb128> well, assuming we don't want the new UI and we don't want it
[12:16] <darkxst> right, so fork gnome-desktop into libunity-desktop
[12:16] <seb128> hum, I'm pondering doing a summary email to the desktop list, listing options
[12:16] <seb128> well, we have 3 options
[12:16] <seb128> 1- create a new package with the old lib codebase, to use in u-s-d/u-c-c
[12:17] <seb128> 2- copy the files/functions we need in those sources
[12:17] <seb128> 3- try the new dbus service and patch u-s-d/u-c-c to use it
[12:17] <seb128> the option-3 is the most likely to create work for us
[12:18] <seb128> 1 and 2 are basically no runtime change, we just need to see if the copy is easy or to decide to keep a full copy of the source only for that
[12:18] <darkxst> seb128, option 3 is mostly done, but will need rebasing, and probably create some amount of bugs
[12:18] <seb128> right, it's the same amount of bugs which is the issue
[12:18] <darkxst> I'm not convinced to 2 would be that easy...
[12:18] <seb128> why? it's basically a variant of 1
[12:18] <seb128> either those functions are mostly standalone or not
[12:19] <seb128> if they are not, it's going to be an issue for 1 as well
[12:19] <darkxst> seb128, have you look at the code? it involves lots of minor api changes in gnome-desktop
[12:19] <seb128> ?
[12:19] <darkxst> seb128, so x-code got moved into mutter
[12:20] <darkxst> gnome-desktop has adjustment to re-direct to mutter dbus
[12:20] <seb128> we would copy gnome-desktop-xrandr.c/h (inventing a filename for example) from gnome-desktop 3.8 to u-s-d and include the local .h/build with that .c as part of u-s-d and have that code in u-s-d
[12:20] <seb128> so it's like we would static build g-d 3.8 in u-s-d
[12:21] <seb128> rather than having a shared lib
[12:21] <seb128> why wouldn't that work?
[12:21] <seb128> that code should call xrandr and be fine
[12:21] <seb128> no?
[12:21] <darkxst> seb128, oh, you mean copy my daemon code into u-s-d?
[12:21] <seb128> no
[12:21] <darkxst> or you want to try and disect the mess of changes that led to that?
[12:22] <seb128> copy gnome-desktop 3.8's code in there, so rather than using a shared libunity, have those functions be part of u-s-d
[12:22] <seb128> they would be built in xrandr.so
[12:22] <seb128> rather than being in a lib that is loaded at runtime
[12:23] <seb128> it's basically the "create a fork for gnome-desktop 3.8", just not making it a share library
[12:23] <seb128> shared
[12:29] <darkxst> seb128, its really not as simple as just copying a bit of code
[12:30] <darkxst> so there are really two options
[12:30] <seb128> why not?
[12:30] <darkxst> 1- fork gnome-desktop
[12:31] <darkxst> 2- keep gnome-desktop but create a  dummy dbus interface that works with the current gnome-desktop
[12:32] <darkxst> seb128, because they changed the api
[12:32] <seb128> well, that's not relevant
[12:32] <seb128> u-s-d uses the old 3.8 api, so if we copy those function in the u-s-d xrand plugin we could stop using libgnome-desktop there
[12:32] <seb128> just use the local copied code
[12:32] <seb128> no?
[12:33] <darkxst> well sure, if you copy the entire 3.8 gnome-desktop api
[12:33] <darkxst> in which case you have basically forked it anyway
[12:34] <darkxst> and it probably doesnt matter too much where it lives
[12:34] <seb128> well, gnome-desktop has stuff like keyboard layout handling, why would we need to copy those?
[12:34] <seb128> that and forked is fine, the issue is "shipping the fork as a shared library"
[12:34] <seb128> which means we might get people starting using that library, since it's shared and available on the install
[12:34] <darkxst> well it only needs to be shared between u-s-d and u-c-c
[12:35] <seb128> I'm going to have a look at how much code that is to copy around, to see if the option is a valid one
[12:35] <seb128> but yeah, otherwise the rename and ship the old version would work
[12:36] <darkxst> seb128, so basically its 90% of xrandr plugin, but also other things like (mainly) idle monitor
[12:38] <ricotz> Sweet5hark, great! thanks
[12:40] <darkxst> seb128, and believe me when I say that number of bug fixes you guys are missing out on just over a UI is pretty insane
[12:43] <seb128> darkxst, it's always "I can't believe you guys are using so buggy software", yet users are still happy to run 10 year old windows versions or whatever
[12:43] <seb128> we get almost no complain about the current xrandr case
[12:43] <seb128> works perfectly for what I have to do
[12:43] <seb128> so I'm sure the new code fix a ton of issues, but none I care about for my personal use...
[12:44] <seb128> (we don't get lot of bug reports either on that topic)
[12:45] <darkxst> oh seb128, yes I know you only start caring when in ranks highly on e.u.c ;)
[12:45] <seb128> not true
[12:46] <seb128> when it's popular in launchpad or when it's coming back from e.g oem teams as well
[12:46] <seb128> or when it's pointed in reviews or user forums
[12:46] <seb128> xrandr is in none of those categories though
[12:47] <darkxst> seb128, most users don't even know what xrandr is
[12:47] <darkxst> and I was talking more in general over the whole g-s-d
[12:47] <darkxst> not just xrandr bugs
[12:47] <seb128> yeah, we want to update things like wacom
[12:48] <darkxst> power?
[12:48] <seb128> g-s-d is more like candidate for updates
[12:48] <seb128> the issue is g-c-c and the new UIs
[12:48] <seb128> yeah, power could be one
[12:49] <tjaalton> Laney: filed bug 1330468, does it look ok and was this enough?
[12:51] <darkxst> seb128, but yeh, upstream basically consider gnome-desktop/g-s-d/g-c-c a set, no guarantee of api stability there
[12:51] <darkxst> maybe even an exclusive set
[12:52] <seb128> yeah, it makes trickier our job dealing with u-s-d/u-c-c
[12:52] <seb128> but that's our issue, not yours
[12:53] <darkxst> seb128, well it becomes ours as well... once we are blocked waiting...
[12:54] <darkxst> I would like to land the upower transition once its ready, and then move straight onto gnome-desktop 3.12
[13:00] <Laney> tjaalton: I think so, we'll see when didrocks and co look at it though ;-)
[13:01] <tjaalton> yeah
[13:01] <Laney> thanks for filing
[13:01] <didrocks> I'll have a look before EOW, is that fine?
[13:03] <Laney> no huge rush right now, thanks
[13:03] <darkxst> anyway night all, I should probably sleep now ;)
[13:04] <didrocks> see you darkxst
[14:20] <seb128> Laney, in fact current desktop-next does work/autologin, the issue I had earlier were likely because Mir doesn't run in VMs yet (I knew the session wouldn't work but I though I would see it trying to log in at least/having logs in the userdir)
[14:20] <seb128> works on real hardware
[14:21] <Laney> oh really!
[14:21] <Laney> I found a USB stick on the back of a shelf
[14:21] <Laney> so I'll see if it works on my hardware
[14:22] <Laney> don't know if we have mir/nvidia
[14:22] <ogra_> nouveau should work afaik
[14:38] <seb128> pitti, ^ btw
[14:38] <seb128> pitti, ubuntu-desktop-next works now (on real hardware, not on VMs)
[14:38] <pitti> seb128: yay! re-downloading :)
[14:38] <seb128> pitti, ;-)
[14:39] <ogra_> screw VMs ... they are for clouds !
[14:39] <pitti> seb128: I want them to run in an otto container :)
[14:40] <pitti> (actually half-serious, if we want to test them automatically)
[14:40] <pitti> didrocks, jibel: is otto still running in production, OOI?
[14:40] <seb128> pitti, having automated testing would be great
[14:40] <Laney> seb128: will you test the installer?
[14:40] <seb128> Laney, yes, about to do that
[14:40] <Laney> ooh, looks like cyphermox fixed the modemmanager stuff
[14:40] <Laney> maybe we can turn recommends back on then
[14:41] <cyphermox> Laney: yeah, I did, sorry
[14:41] <seb128> Laney, do you think we should seed the desktop wallpapers on that iso?
[14:41] <seb128> Laney, is that a recommends? ;-)
[14:41] <Laney> for the greeter?
[14:41] <Laney> :( :( :(
[14:41] <seb128> yes, greeter being one
[14:41] <Laney> ): ): ):
[14:41] <seb128> I was also looking for images to browse in gallery
[14:41] <Laney> if you want
[14:42] <seb128> let's maybe try to turn recommends on
[14:42] <ogra_> uuh
[14:42] <seb128> then have a review of what is there and shouldn't be/what is missing, and update the seeds
[14:44] <seb128> ogra_, ?
[14:44] <ogra_> seb128, just make sure ot only do it in the desktop seed ... and i guess your image will grow twice as big :)
[14:46] <seb128> ogra_, yeah, only desktop, and let's see, it shouldn't (desktop is not twice the touch image)
[14:46] <ogra_> no, but touch includes a lot non-yet-desktop packages that have recommends
[14:46] <seb128> well, we can do a build with them and see where we are
[14:47] <ogra_> yeah, sure
[14:47] <Laney> if they aren't wanted then they shouldn't be recommends
[14:47] <Laney> if they are then we want them
[14:47] <seb128> that image is not a production one anyway, it's made to see where we stand and deal with those issues
[14:47] <ogra_> well, i could say the same abouut touch :)
[14:47] <seb128> right, touch should use recommends
[14:47] <Laney> yes you could
[14:47] <seb128> but let's not discuss that today :p
[14:47] <ogra_> but cleaning up the recommends there will cause a big delta in the end
[14:47] <seb128> it's not going to lead anywhere useful
[14:48] <Laney> ubuntu-artwork is explicitly seeded in desktop
[14:48] <ogra_> well, i would like us to get away from the no-recommends setting at some point
[14:48] <Laney> i think we'd need to add that to touch/destkop too
[14:48] <ogra_> even on touch
[14:48] <ogra_> but i expect that to take a full cycle to clean up all the bits and pieces ... surely nothing to do this round
[14:49] <Laney> man look at my cool diagram in bzr log ubuntu-touch.utopic r193
[14:50] <Laney> seb128: okay, added ubuntu-artwork
[14:50] <seb128> Laney, thanks
[15:04] <seb128> Laney, install works fine and gives a working session
[15:05] <Laney> erm
[15:05] <Laney> wow
[15:05] <seb128> ;-)
[15:05] <Laney> we totally could have demoed this :P
[15:06] <Laney> if that fix got in when it was first propsoed
[15:06] <ogra_> i think xnox ran it all the time in mla
[15:06] <ogra_> *malta
[15:06] <pitti> w00t
[15:06] <pitti> great work, guys!
[15:07] <seb128> yeah
[15:07] <seb128> pitti, thanks ;-)
[15:07] <seb128> ogra_, we were running the unity8 session as well, we even demoed it installing clicks and running gedit...
[15:07] <seb128> ogra_, we are speaking about the live image there
[15:07] <ogra_> ah
[15:11] <didrocks> pitti: sorry, was on a call. I'm not 100% sure, but I heared still the CI team talking about the otto machines for Touch recently (like a month or so ago). fginther would know more I guess
[15:20] <seb128> pitti, do you need NEW review for those touch langpack sources?
[15:20] <pitti> seb128: sorry, no, will accept them wholesale
[15:20] <seb128> pitti, k; thanks ;-)
[15:25] <seb128> bregma, do you know if indicator-network not being available under unity8-desktop session is an known issue?
[15:26] <bregma> seb128, I am not aware of any such issue
[15:26] <seb128> bregma, is it listed for you?
[15:26] <seb128> it's not here and the settings wifi panel is empty
[15:27] <Laney> seb128: is it running?
[15:27] <Laney> upstart-wise
[15:28] <bregma> let me update my test systems
[15:30] <seb128> Laney, I guess I need to dbus environment from the session?
[15:30] <Laney> yeah
[15:30] <Laney> or UPSTART_SESSION or whatever it is
[15:30] <seb128> status indicator-network states "unknown job"
[15:30] <seb128> the process it's not running
[15:30] <Laney> get the environ from unity8 or something
[15:31] <seb128> but .cache/upstart/indicator-network.log has an entry "stop/pre-start, process nnnn"
[15:31] <Laney> yes
[15:31] <Laney> I think it's the pre-start script stopping the job
[15:32] <Laney> see /usr/share/upstart/sessions/indicator-network.conf
[15:32] <Laney> probably needs to list unity8-x11 and unity8-mir there
[15:32] <seb128> it's "stop/waiting"
[15:32] <Laney> hack the script then 'start indicator-network' and see if it works
[15:34]  * Laney checks e-d-s one last time
[15:36] <seb128> Laney, bregma: right, the job needs tweaking to start on unity8 sessions out of touch
[15:36]  * Laney nods
[15:37] <bregma> seb128, thinking back, I noticed it gone in Malta, so it's been broken for a while
[15:37] <Laney> this was added before trusty to prevent double indicators
[15:37] <bregma> I think it happened after the tweak to make two indicators not show up in the 14.04 unity 7 desktop
[15:37] <seb128> bregma, well, I guess since before trusty when we "fixed" it to not start in !touch so we wouldn't get it under unity7 sessions
[15:37] <seb128> lol
[15:38] <bregma> the fix worked
[15:43] <seb128> bregma, do you want to mp that?
[15:43] <bregma> seb128, yes please
[15:44] <Laney> haha
[15:45] <pitti> ok, c'est l'heure de football, à demain !
[15:46] <didrocks> pitti: I think I need to socially answer "enjoy" even if I don't know how you can enjoy that :)
[15:46] <pitti> didrocks: yes, it's indeed a social exercise -- we'll go to the beer garden :)
[15:47] <pitti> (we don't have a TV)
[15:47] <didrocks> pitti: I can do with the beer part, less with the football one though ;)
[15:47] <pitti> didrocks: if France loses its next game, it's due to you! :-P
[15:48] <didrocks> pitti: at least, they will stop talking abou
[15:48] <didrocks> about a stupid game :)
[15:48] <didrocks> (here)
[15:48] <didrocks> oh, it's not Friday yet? Ok I'll keep some for that day :p
[15:49] <seb128> pitti, bon chance pour le match!
[16:15] <Laney> go go gadget e-d-s
[16:21] <seb128> have a nice evening everyone!
[16:51] <chrisccoulson> qengho, are you back this week?
[19:39] <ari-tczew> hello
[19:40] <ari-tczew> can someone update a branch of sane-backends? I've proposed a merge for https://code.launchpad.net/~ari-tczew/sane-backends/ubuntu/+merge/220881
[23:23] <robert_ancell> tea time!