[04:14] Good morning [05:23] morning! [07:03] hey larsu [07:05] hi pitti! Wie war dein Wochenende? [07:06] hey larsu! [07:06] 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] larsu: und Deins? [07:06] bonjour didrocks!! [07:07] pitti: congested pipes, doesn't sound fun :/ [07:08] 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] good morning desktopers! [08:00] hey seb128 [08:01] hey seb128 [08:03] seb128, would you be open to backporting 3.12 power plugin/panel for u-s-d/u-c-c? [08:04] (for upower transition) [08:04] morning [08:04] hey darkxst mvo Laney [08:04] darkxst, did you get that upower transition approved by the r-t? [08:04] hi $PEOPLE_SEB128_JUST_MENTIONED [08:04] good weekends? [08:05] somebody on #debian-gnome mentioned some days ago that trunk had another ABI change [08:05] we don't want to have to do 2 transitions if that's the case [08:05] we should wait for the ABI to stabilize [08:05] the Debian guys were mentioning maybe reverting the GNOME changes to use the old upower for the coming Debian stable [08:05] seb128, since when do need r-t approval this early in the cycle? [08:06] that sort of transition impact on all flavors [08:06] 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] 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] including touch [08:07] ochosi, we don't have anyone looking at xdg-utils bugs afaik, I'm happy to sponsor patches though [08:07] seb128: ok, thanks, that's good to know! [08:10] hey Laney, darkxst, ochosi [08:10] hey didrocks [08:10] and mvo :) [08:10] hey didrocks! [08:11] 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] seb128, the api changes are by themselves not that bad, g-s-d is a mess due to the included re-factoring [08:12] most other components only have fairly simple patches [08:12] darkxst, looking at Debian that transition doesn't seem to be that easy [08:12] but anyway, it seems you guys are doing good job on it, I see you listed components, patches, etc [08:12] so it should be fine [08:13] but it impacts on several flavors, so it would be worth communicating about it on ubuntu-devel@ [08:13] did you check the d-bus api? [08:14] Laney, as best I can while codesearch is broken [08:14] mmm [08:17] hey Laney [08:17] bonjour seb128 ! [08:17] hey pitti [08:17] I'd have merged a system-settings branch for you btw ;-) [08:17] pitti, salut! ça va bien ? [08:17] hwo's it going? [08:17] seb128: félicitations pour le match de football gagné hier :) [08:17] seb128: oui, merci [08:17] Laney: heh, I grabbed another guinea pig for the time being :) [08:26] Laney, database still seems to be incomplete [08:27] I never fixed it :( [08:27] obviously! [08:27] 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] speaking of transitions [08:31] * Laney has prepared evo 3.12 [08:31] (H) [08:38] darkxst: sorry, I'll look at it soon hopefully [08:38] the code is written in go which I don't know so it's not a very appealing task [08:51] Laney, saw bug #1330033 ? [08:51] bug 1330033 in glib2.0 (Ubuntu) "invalid token @CARBON_LIBS@ in glib-2.0.pc" [Undecided,New] https://launchpad.net/bugs/1330033 [08:51] nein [08:53] seb128: i hope you're ok with me setting you as a reviewer for my xdg-utils MR [08:54] looks new in 2.41 [08:56] ochosi, that's fine yes, seems like you targeted the wrong Vcs though (lp:xdg-utils) [08:56] ochosi, is that change upstream btw? [08:56] seb128: merci :) [08:57] 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] seb128: thing is, xdg-utils isn't even *that actively* maintained upstream... [08:58] 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] 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] seb128: ok, will look into doing that right now, shall i add a link in a comment to the MR? [08:59] ochosi, that would be nice, thanks [08:59] or ideally add it to the patch header, but I can do that for you when I upload [09:04] 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] seb128: ah, right [09:05] like they are going to hit the issue that the revision is missing when they try to publish [09:05] meh, not having trunk is really maddening [09:05] seb128: ok, I'll just continue with dialer-app then and let the project maintainers do that update themselves [09:06] it wasn't for lack of trying on my side, at least :) [09:06] they'll just have to merge and rebuild [09:06] but yes :/ [09:06] pitti, you can easily check is a component is a silo using the CI bot with "where " [09:06] is in a silo* [09:07] pitti, btw should we start include those changes or should we wait? [09:07] like for settings we can get that in the next landing [09:07] seb128: it's fine to include them, as long as you don't mind having translations dropped for a few days [09:07] k [09:24] 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] bug 1294877 in OEM Priority Project "usb-creator fails to wipe usb device when the device has ext4 partition" [Undecided,Triaged] https://launchpad.net/bugs/1294877 [09:24] usb-creator is in a rather sorry state :/ [09:25] pitti, yeah, xnox needs to look at it [09:25] pitti, thanks for looking at it! [09:27] seb128: done. added as a comment as i wasn't sure how/where to do that with the patch header [09:27] seb128: i'll be looking at what you do with it though and try to learn from it [09:28] ochosi, ok, I just usually add some comment lines on top of the .patch [09:28] like [09:28] # Description: support xfce better [09:28] ah [09:28] # Upstream: right [09:33] there's also that patch that could be dropped, i presume you need a MR for that too? [09:33] s/could/should/ [09:34] ochosi, which one? no need, I can have a look [09:34] this one: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/xdg-utils/utopic/view/head:/debian/patches/xserver-blanking.diff [09:34] it just duplicates code [09:35] this is the bugreport for it: https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/1330386 [09:35] Ubuntu bug 1330386 in xdg-utils (Ubuntu) "The xserver-blanking patch in Ubuntu duplicates code" [Undecided,New] [09:35] you mean it was included upstream and not dropped from our patch serie? [09:35] that' [09:35] s the only explanation i could find [09:35] ok, thanks [09:35] otherwise it makes no sense [09:35] let me look [09:36] (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] ochosi, yeah, http://cgit.freedesktop.org/xdg/xdg-utils/commit/scripts/xdg-screensaver.in?id=c9551d250722081cbf7d6611f417bc597765e5c9 [09:38] righty [09:38] there you go [09:38] sry, i guess i could've dug that up myself when doing the bugreport... [09:38] no worry [09:38] thanks for pointing it out ;-) [09:38] np ;) [09:39] seb128: bug 1296275> argh, I'm a moron [09:39] bug 1296275 in gvfs (Ubuntu Utopic) "PTP Cameras not working on 14.04, works flawlessly on 12.04" [Low,Triaged] https://launchpad.net/bugs/1296275 [09:39] pitti, did you include the wrong change? [09:39] ACTION="add" [09:39] that wanted to be == [09:39] and actually, it's redundant [09:39] 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] (actually could be configured bugfix) [09:40] ochosi, yes [09:40] s/configured/considered/ [09:40] weird mistype... [09:40] seb128: ok thanks a bunch! i guess we need to file for SRU to get this into trusty? [09:41] ochosi, yes, you can use the existing bugs, you just need impact/test case/regression potential info on those [09:42] seb128: ok, will look into that later today or whenever the changes have been pushed. thanks again! [09:42] ochosi, yw! [11:02] ricotz: FWIW https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-staging-main has 4.2.5~rc2 -- I havent smoketested it to install clean though ... === MacSlow is now known as MacSlow|lunch [11:12] ricotz: looking good, copied [11:16] grrr [11:16] why is the ubuntu desktop next iso still stopping on the lightdm screen asking for an username [11:17] the lightdm log states it's try to log user "(null)"! [11:17] * seb128 debugs [11:18] :( [11:18] probably uses "phablet" anywhere hardcoded ? [11:20] ogra_, no, we are using unity-greeter like desktop [11:24] seb128, well, that wouldnt help if the session wrapper has the homedir/user hardcoded [11:25] ogra_, well, the log has user "(null)" that seems wrong in any case [11:25] seb128, can you guys fork gnome-desktop ;) [11:25] darkxst, no [11:25] true [11:26] seb128, yes, its much easier than the alternatives! [11:26] darkxst, did Laney said, earlier in the cycle, that he was wanting to help you land this one? [11:26] seb128, no laney hasn't mentioned that to me [11:27] lying [11:27] whos lying? [11:27] you [11:27] darkxst, http://irclogs.ubuntu.com/2014/04/28/%23ubuntu-desktop.html#t11:23 [11:27] you were part of that discussion [11:27] that was a reply to you [11:28] it's good that we have logs ;-) [11:29] seb128, yes, even bet that you can just dig them up that quick ;) [11:29] ^better [11:29] lol [11:29] well, I just had to grep for gnome-desktop mentions in that channel and grep for Laney on the results [11:30] but still, I think it probably easier to fork it, libunity-desktop [11:30] only for u-s-d and u-c-c [11:31] everything else likes the apps, that shouldn;t even be using it... can continue on using the real library [11:31] what happens then e.g eog or cheese or nautilus or ... [11:31] +to [11:32] seb128, they will be linked to one or the other [11:32] doesnt matter too much which [11:32] well, those libraries are going to have common symbols? [11:33] is that likely to create conflicts? [11:33] seb128, only if someone trys to link against both, (which is a really bad idea anyway) [11:34] right, seems there is no libs in the rdepends list [11:34] Laney, do you have an opinion on that? [11:35] 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] what's the problem with doing the normal update? [11:35] its also likely that some apps, nautilus maybe, are using deprecated modules [11:36] Laney, all XRANR stuff was moved into mutter [11:36] in fact anything X related was moved out [11:37] I did rip out the code from mutter and make a standalone daemon, last cycle and that would still work [11:37] but... things are just going to keep diverging [11:43] what uses the X stuff on our side? [11:43] I think splitting it out is okay [11:43] Laney, the X stuff is pretty limited to u-s-d/u-c-c [11:44] the apps just use stuff, that was never really intended to be in gnome-desktop [11:44] but is there [11:44] would be happy to try the split first [11:44] if it's removed then it won't be changing [11:45] like copy that code in u-s-d/u-c-c? [11:45] darkxst already made a daemon for it [11:45] not sure what source it lives in [11:45] new source [11:45] seems okay [11:45] or a binary in one of those [11:45] doesn't matter to me [11:45] well, it's new code/js [11:45] * darkxst ripped the code from mutter and put in a daemon [11:45] I'm not even sure we want gjs on our iso [11:46] not a fork of the old stuff? [11:46] seb128, no gjs involved [11:46] darkxst, oh, that part is only C? [11:46] seb128, yes [11:46] Laney, no, a fork of the new gnome-shell code [11:46] with talking over dbus [11:46] * Laney nod [11:46] it has potential for bugs [11:46] but I guess we can try it out [11:47] and if doesn't work, look at doing a plan B by copying some old gnome-desktop code [11:47] https://github.com/darkxst/displayconfig [11:48] seb128, its all dbus [11:48] and nothing to do with gnome-shell [11:48] its all in mutter [11:48] okay so what I said last time still stands, ping me when you have stuff for sponsoring [11:48] those are the same thing to me [11:48] but noted ;-) [11:49] seb128, for one there is no JS/gjs in mutter! [11:49] ls [11:49] ups [11:50] but my concern, is this will continue to block us every cycle.... [11:50] 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] seb128: No File or Directory ups located [11:51] if it becomes too horrible then forking will still be an option [11:53] davmor2, lol [11:53] well, it doesn't seem like we need to block, we can use that standalone service [11:54] or copy the old functions in u-s-d [11:55] yep [11:55] there are probably a dozen patches each for u-s-d and u-c-c [11:56] hum, how much code are we talking about there? like how many functions are being dropped from gnome-desktop in the update? [11:57] I think my preferred solution would be to copy those functions/rename then if needed in u-s-d/u-c-c [11:57] it's a safer option than stacking changes and adding a new dbus service [11:58] u-s-d/u-c-c patches just change from using gnome-desktop to dbus [11:58] the code that moved was *all* the display config code [11:58] well, it might still be easy to copy ;-) [11:58] like just copy a bunch of .c/.h files in u-s-d source [11:59] seb128, I doubt it would be that easy! [11:59] :-( [11:59] so back to square 1 === alan_g is now known as alan_g|lunch [12:00] right, make libunity-desktop [12:00] but only used by u-s-d/u-c-c [12:00] I think that is the easiest option, avoiding the dbus daemon [12:01] but it only needs the X functions [12:02] I suppose you could split out the X stuff into a new library [12:02] but for example only 90% of xrandr plugin was moved into mutter (atleast for 3.10) [12:04] or another option would be to rebase the u-s-d/u-c-c code off 3.12 for certain plugins/modules? [12:04] but you would still need the daemon [12:05] we don't want the new display UI [12:05] seb128, yes I have heard mpt doesnt like the egglistboxes [12:06] What’s an egglistbox? [12:06] well, it's also that our display panel is quite different from the upstream one [12:06] we have controls for the high dpi stuff there, and for the launcher and screen barrier [12:07] mpt, those sort of panels, http://afaikblog.files.wordpress.com/2013/01/privacy.png [12:07] seb128, that is a forked panel? anyway updating won't affect that [12:07] darkxst, it's the "display" one with a stack of patches [12:07] oh, ha, yes [12:08] seb128, nope its a forked panel [12:08] ? [12:08] seb128, its called "Appearance" or something [12:08] well, a stack of patches can be called a fork, if that's what are you discussing [12:08] no, that's the background panel [12:08] display is the xrandr one [12:08] background/appearance is the wallpaper [12:09] hmm so maybe its just a stack of XDG_CURRENT_DESKTOP patches then, but I don't think so? [12:09] it is [12:10] http://i.stack.imgur.com/TULXr.png [12:10] The Launcher options could/should be moved to “Appearance” [sic] > “Behavior” if that would make syncing easier [12:10] well, that image is an earlier version, so the UI is not really nice, we did some tweaks since [12:10] seb128, oh that looks ancient! [12:10] darkxst, that's what we current have... [12:11] (well, expect we fixed the alignments issues and some glitches) [12:11] except* [12:13] seb128, https://www.dropbox.com/s/6r6jzssyjdnqd5y/Screenshot%20from%202014-06-16%2022%3A12%3A00.png [12:14] and I know you will dislike that :) [12:15] 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] well, assuming we don't want the new UI and we don't want it [12:16] right, so fork gnome-desktop into libunity-desktop [12:16] hum, I'm pondering doing a summary email to the desktop list, listing options [12:16] well, we have 3 options [12:16] 1- create a new package with the old lib codebase, to use in u-s-d/u-c-c [12:17] 2- copy the files/functions we need in those sources [12:17] 3- try the new dbus service and patch u-s-d/u-c-c to use it [12:17] the option-3 is the most likely to create work for us [12:18] 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] seb128, option 3 is mostly done, but will need rebasing, and probably create some amount of bugs [12:18] right, it's the same amount of bugs which is the issue [12:18] I'm not convinced to 2 would be that easy... [12:18] why? it's basically a variant of 1 [12:18] either those functions are mostly standalone or not [12:19] if they are not, it's going to be an issue for 1 as well [12:19] seb128, have you look at the code? it involves lots of minor api changes in gnome-desktop [12:19] ? [12:19] seb128, so x-code got moved into mutter [12:20] gnome-desktop has adjustment to re-direct to mutter dbus [12:20] 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] so it's like we would static build g-d 3.8 in u-s-d [12:21] rather than having a shared lib [12:21] why wouldn't that work? [12:21] that code should call xrandr and be fine [12:21] no? [12:21] seb128, oh, you mean copy my daemon code into u-s-d? [12:21] no [12:21] or you want to try and disect the mess of changes that led to that? [12:22] 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] they would be built in xrandr.so [12:22] rather than being in a lib that is loaded at runtime [12:23] it's basically the "create a fork for gnome-desktop 3.8", just not making it a share library [12:23] shared [12:29] seb128, its really not as simple as just copying a bit of code [12:30] so there are really two options [12:30] why not? [12:30] 1- fork gnome-desktop [12:31] 2- keep gnome-desktop but create a dummy dbus interface that works with the current gnome-desktop [12:32] seb128, because they changed the api [12:32] well, that's not relevant [12:32] 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] just use the local copied code [12:32] no? [12:33] well sure, if you copy the entire 3.8 gnome-desktop api [12:33] in which case you have basically forked it anyway [12:34] and it probably doesnt matter too much where it lives [12:34] well, gnome-desktop has stuff like keyboard layout handling, why would we need to copy those? [12:34] that and forked is fine, the issue is "shipping the fork as a shared library" [12:34] which means we might get people starting using that library, since it's shared and available on the install [12:34] well it only needs to be shared between u-s-d and u-c-c [12:35] 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] but yeah, otherwise the rename and ship the old version would work [12:36] seb128, so basically its 90% of xrandr plugin, but also other things like (mainly) idle monitor [12:38] Sweet5hark, great! thanks [12:40] 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] 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] we get almost no complain about the current xrandr case [12:43] works perfectly for what I have to do [12:43] so I'm sure the new code fix a ton of issues, but none I care about for my personal use... [12:44] (we don't get lot of bug reports either on that topic) === MacSlow|lunch is now known as MacSlow [12:45] oh seb128, yes I know you only start caring when in ranks highly on e.u.c ;) [12:45] not true [12:46] when it's popular in launchpad or when it's coming back from e.g oem teams as well [12:46] or when it's pointed in reviews or user forums [12:46] xrandr is in none of those categories though [12:47] seb128, most users don't even know what xrandr is [12:47] and I was talking more in general over the whole g-s-d [12:47] not just xrandr bugs [12:47] yeah, we want to update things like wacom [12:48] power? [12:48] g-s-d is more like candidate for updates [12:48] the issue is g-c-c and the new UIs [12:48] yeah, power could be one [12:49] Laney: filed bug 1330468, does it look ok and was this enough? [12:49] bug 1330468 in libinput (Ubuntu) "MIR: libinput" [Undecided,New] https://launchpad.net/bugs/1330468 [12:51] seb128, but yeh, upstream basically consider gnome-desktop/g-s-d/g-c-c a set, no guarantee of api stability there [12:51] maybe even an exclusive set [12:52] yeah, it makes trickier our job dealing with u-s-d/u-c-c [12:52] but that's our issue, not yours === davmor2__ is now known as davmor2 [12:53] seb128, well it becomes ours as well... once we are blocked waiting... [12:54] I would like to land the upower transition once its ready, and then move straight onto gnome-desktop 3.12 [13:00] tjaalton: I think so, we'll see when didrocks and co look at it though ;-) [13:01] yeah [13:01] thanks for filing [13:01] I'll have a look before EOW, is that fine? [13:03] no huge rush right now, thanks [13:03] anyway night all, I should probably sleep now ;) === alan_g|lunch is now known as alan_g [13:04] see you darkxst === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [14:20] 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] works on real hardware [14:21] oh really! [14:21] I found a USB stick on the back of a shelf [14:21] so I'll see if it works on my hardware [14:22] don't know if we have mir/nvidia [14:22] nouveau should work afaik === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g [14:38] pitti, ^ btw [14:38] pitti, ubuntu-desktop-next works now (on real hardware, not on VMs) [14:38] seb128: yay! re-downloading :) [14:38] pitti, ;-) [14:39] screw VMs ... they are for clouds ! [14:39] seb128: I want them to run in an otto container :) [14:40] (actually half-serious, if we want to test them automatically) [14:40] didrocks, jibel: is otto still running in production, OOI? [14:40] pitti, having automated testing would be great [14:40] seb128: will you test the installer? [14:40] Laney, yes, about to do that [14:40] ooh, looks like cyphermox fixed the modemmanager stuff [14:40] maybe we can turn recommends back on then [14:41] Laney: yeah, I did, sorry [14:41] Laney, do you think we should seed the desktop wallpapers on that iso? [14:41] Laney, is that a recommends? ;-) [14:41] for the greeter? [14:41] :( :( :( [14:41] yes, greeter being one [14:41] ): ): ): [14:41] I was also looking for images to browse in gallery [14:41] if you want [14:42] let's maybe try to turn recommends on [14:42] uuh [14:42] then have a review of what is there and shouldn't be/what is missing, and update the seeds [14:44] ogra_, ? [14:44] seb128, just make sure ot only do it in the desktop seed ... and i guess your image will grow twice as big :) [14:46] ogra_, yeah, only desktop, and let's see, it shouldn't (desktop is not twice the touch image) [14:46] no, but touch includes a lot non-yet-desktop packages that have recommends [14:46]