[00:42] GunnarHj, I'm not sure about other desktops, but when I looked into fixing the XDG_CURRENT_DESKTOP usage it seemed that very few (if any) of them make sense anyway. [00:42] So if we fix those first we'll be able to see what remains. [00:42] I think the answer is if it is being used by other desktops it still makes sense to show all the options === thumper-dogwalk is now known as thumper [00:55] robert_ancell: Of course, as long as we aren't sure that it won't be used by other desktops, it makes sense to keep the options. I suppose that it's a little late in the cycle to figure it out. I'll try this weekend to make an MP which fixes the tests so they handle cases like "GNOME-Flashback:Unity" properly. And also make sure that u-c-c does not override an existing XDG_CURRENT_DESKTOP value, but only sets "Unity" as a fallba [00:55] ck if XDG_CURRENT_DESKTOP is empty for some reason. [00:56] GunnarHj, I think it's been set because some of the panels have OnlyShowIn=Unity. Which seems to me like they should just be fixed to either have a list of desktops or u-c-c should show them regardless of what desktop it is in. [00:57] I'm fixing GTK+ at the moment [01:04] robert_ancell: If I understand it correctly, the panels will be shown in the case of OnlyShowIn=Unity as long as Unity is one of the elements in XDG_CURRENT_DESKTOP's colon separated list. So in the example I mentioned (GNOME-Flashback:Unity) the panels should be shown. (But I haven't tested yet.) In that case, it's the remaining XDG_CURRENT_DESKTOP tests within u-c-c which need to be modified (split on ":" etc.). === JoseeAntonioR is now known as jose [03:00] attente, ping? [03:01] attente, oh, now I get it. No problem. === tsimonq2alt is now known as tsimonq2- === tsimonq2- is now known as tsimonq2 [05:53] hi === tjaalton_ is now known as tjaalton === mfisch is now known as Guest38484 [06:46] good morning === Guest77642 is now known as fredp === fredp is now known as Guest77696 [08:19] good morning [08:47] GunnarHj, late reply to your XDG_CURRENT_DESKTOP comment, the desktop files are not an issue, yes OnlyShowIn=Unity works fine with GNOME-Flashback:Unity [08:51] seb128: bonjour ! comment ça va? [08:51] salut pitti, ça va bien et toi ? [08:52] seb128: je vais mieux, merci [08:52] super ! [08:52] seb128: gnome-desktop got removed in Debian; we still have one rdepends, banshee [08:52] how did Debian fix that? [08:53] https://tracker.debian.org/news/712556 [08:54] seb128: that's a newer upstream version, though [08:54] right, i was going to say [08:54] seb128: (doing process-removals today, and it's depressing..) [08:54] seb128: so, do we want to merge and follow along? or keep that old stuff? [08:54] (why? less to maintain is good no?) [08:55] seb128: well, once you can *actually* remove packages, yes :) but I'm running into countless cases of "one rdepends left in Ubuntu which hasn't been merged/updated in ages" [08:55] I did a few, but this is a ratsnest :) [08:56] I've no idea about banshee, I never really used it and didn't look at it for years [08:56] right, i. e. do we still actually want to keep it} [08:56] ? [08:56] if the new version is only in experimental there might be a reason [08:56] I assume we do [08:56] seb128: ah no, unstable has https://tracker.debian.org/news/712782 [08:57] having things in universe doesn't cost us much, we can as well keep it [08:57] which also dropped the deps [08:57] nice [08:57] well, it's still growing tech debt [08:57] let's just do that then [08:57] Version: 2.9.0+really2.6.2-3ubuntu1 [08:57] it's not like universe was close from not have all sort of old unmaintained things [08:57] so at some point we wanted to go back, but I don't have the details any more [08:57] having* [08:57] or had ever been [08:57] at some point we had ubuntuone integration and all that, perhaps that's all obsolete [08:58] yeah [08:58] Downgrade to 2.6.1 -- 2.9.x is unstable and 3.0 won't arrive in time for [08:58] release [08:58] (09 Feb 2014) [08:59] if somebody wants to update it/clean patches they can go for it [08:59] I suppose that's still true :) [08:59] well, that's the thing -- nobody does it [08:59] I wouldn't spend efforts on universe things [08:59] right [08:59] (and no, I've already touched too many KDE packges to pile up even more TIL) [08:59] like for some other 10k packages in universe [08:59] I would just ignore it [08:59] morning all [08:59] hey willcooke [08:59] TheMuso, be with you in 5 === maclin1 is now known as maclin [09:00] seb128: this all started with me cleaning up some wx2.8 stuff for removing gst 0.10; shouldn't have done this :) [09:00] willcooke: No worries. [09:00] * TheMuso waves to everybody else. :) [09:00] * pitti waves back to TheMuso [09:01] pitti, good man, trying to fight the universe ;-) [09:01] morning! [09:01] hey Laney [09:01] hey TheMuso [09:01] hey Laney [09:01] seb128: do I look green and really musculous yet? [09:02] Hey Laney seb128 willcooke [09:02] we need a sprint or UDS so I can tell you :p [09:02] hey [09:02] what's up? [09:03] http://vignette1.wikia.nocookie.net/vsbattles/images/8/88/AoU_Hulk_0004.png/revision/latest?cb=20150608160344 ← me running process-removals [09:04] pitti, going to clean up libgnome gnome-vfs etc from the archive next, right? ;-) [09:04] * seb128 hides [09:04] seb128: the cleaning isn't the problem :) [09:04] enjoying the wet weather for a change ;) [09:05] good time to do a pilot shift when you can't physically leave the house ;) [09:08] indeed! [09:08] checking for Mono 2.0 GAC for Mono.Cairo.dll... not found [09:08] configure: error: missing required Mono 2.0 assembly: Mono.Cairo.dll [09:08] ^ awesome, banshee is FTBFS [09:09] so at some point doko will haunt you anyway :) [09:09] pitti, how did you manage to get a vivid upload to xenial? [09:09] "xchat-indicator (0.3.11-0ubuntu7) vivid; urgency=medium" [09:09] " * Add hexchat-indicator." [09:09] that's confusing [09:09] wut? [09:09] on xenial-changes [09:10] ah sorry, part of cleaning up xchat, just noise [10:10] Trevinho, hikiko - Shadows vs CSD fixes.... [10:10] So hikiko is close to landing a fix for shadows in Compiz which will fix it for all apps not just Gtk [10:10] hikiko, you think it will be finished today? [10:11] and how much work is there still to do on E Zoom? [10:11] I hope so willcooke [10:11] on ezoom I am blocked at an issue [10:11] transformation stack [10:11] I use compiz transformations with nux but there's something that doesn't work [10:11] if I fix tha [10:11] that [10:12] then it's like 2 days work [10:12] the trick there is to pass the compiz ezoom transformation to all the nux components [10:12] but for some reason some of them misbehave [10:12] hikiko: as I said, if you can figure out that ezoom thing, it would be cool... As it helps in a11y. As for gtk apps I think we're all set now. Not the best fix, but it's good enough and we can then try to fix it better later (and in case SRU to xenial), but the one we've now to me is fine. [10:12] and I am looking for that "reason" :. [10:12] :/ [10:13] well, the thing is that the proper fix is almost done and will work with all transparent windows [10:13] if qt decides to have transparency [10:13] that will work too [10:13] your hack is cool but works only with gtk [10:14] so, depends on how much we want to support everything [10:14] or just gtk [10:14] yeah, but it's all we need for now... as transparent windows are in general something that should care about their shadows by design. [10:15] I've seen a branch on compiz side, which is only gtk related, but we can't do that without changing the whole compiz geo system (which is something we can't do now) [10:15] instead if you can extract alpha from windows and get its shape it would be cool, but still we can't apply that to all windows... Since we can't be sure that a window is already providing a shadow (and thus double-shadowing it). I think to cairo-dock for example [10:16] you mean that we don't need a general solution that supports all the windowxs? [10:16] what do you mean? [10:16] we have 1- rectangular windows (supported) [10:16] 2- shaped windows (supported) [10:17] 3- windows that are not shaped - not rectangular and have alpha (under construction) [10:17] how it comes and we double shadow them? [10:18] Yeah, 3 is fine, but as I said if you try apps like cair-dock, or many other alpha windows around, they already provide their own shadow. Since being alpha is a contract with compositor that says: "I'm caring about my own shadows". So, for gtk ones or anyone supporting us, we can say "Ok, I'm alpha, but I still want your shadows". we unfortunately can't [10:18] apply that to any window, without risking regressions [10:19] Anyway, if you can get 3 on is nice, but I think we can now delay that compared to ezoom. [10:19] 1 day? :p [10:19] If you have some code I can look at, I might help anwyay [10:19] ok [10:21] ok, hard dead line is midday UTC tomorrow. If it's not done, then work stops there and we move to E Zoom. How's that sound hikiko, Trevinho? [10:21] fine for me [10:21] k [10:25] the clock is ticking . . . . . . [10:25] ;) [10:25] good luck! [10:39] hikiko, https://code.launchpad.net/~albertsmuktupavels/compiz/add-gtk-frame-extents-to-net-supported/+merge/257303 [10:49] muktupavels: we can't have that without proper geometry rework... And it's too tricky to get it done with few lines unforunately [10:50] anyway.... [10:50] lol https://code.launchpad.net/~hikiko/compiz/compiz.black-dots-fix [10:50] * Trevinho drives back to Florence [10:50] ok he did it first I approve it in a sec [10:50] hikiko: no, please... [10:50] why not? [10:51] it doesn't seem to damage anything else? [10:51] hikiko: enabling that, changes the way gtk exposes their area. And it creates a bigger input area which breaks things for us [10:51] https://code.launchpad.net/~albertsmuktupavels/compiz/add-gtk-frame-extents-to-net-supported/+merge/257303/comments/680812 [10:51] Trevinho, I posted link because hikiko branch had same fix and it had some comments... [10:52] yeah, hikiko see the comments [10:52] sec [10:52] so without fixing the compiz geometry we can't land that. [10:53] and removing these borders from compiz geo seems to be harder than expected. I spent more than a week on that, but it's problematic [10:53] I know what you mean [10:53] that the pixmap [10:54] has some space for decorations around [10:54] well we can just clip the image to remove it isn't it? [10:57] hikiko: yeah, but I failed in doing that [10:59] anyway, for removing the black dotsit's not a problem patching gtk and using a rgba surface in unity, so, we can live without that change [10:59] * Trevinho has to go [10:59] Trevinho, hikiko: does not gtk+ add bigger input area only when window-frame has margin != 0 and/or box-shadow != none. If Ambiance does not add that css then should not be problem. [10:59] I was going to clip the pixmap on unity anyway because I need that for the shadows [10:59] +1 muktupavels [11:00] I think so, I'll test that === Guest77696 is now known as fredp === fredp is now known as Guest86230 === Guest86230 is now known as fredp === fredp is now known as Guest12079 [12:48] willcooke, did you get that ask from the ubuntu-docs team about desktop change notes for 16.04? [12:50] bregma, I didn't, but strangely enough I sent an email out about 10 mins ago to start gathering release notes [12:51] davmor2, cyphermox - do you know - are we supposed to inhibit the screensave during a dist-upgrade? [12:52] davmor2, I forgot to disable the screensaver, and not I'm stuck at the prompt again. Sigh. Start again. [12:52] *now [12:52] willcooke: there was mention of it I think in one of the logs [12:53] bregma, oh, maybe I misunderstood the question? [12:54] willcooke, sound like you're on it, just crossing the task off my list [12:55] bregma, oki cool. Very strange timing though, like I thought of it minutes before you mentioned it. Maybe be have a physic link? [12:55] what's that? Take a hammer from the shed? [12:56] willcooke: 2016-03-10 11:46:23,912 DEBUG Removing 'xscreensaver' (ubuntu-desktop PostUpgradeRemove rule) I'd say that was a pretty brutal way to ensure that the screensaver didn't kick in :) [12:57] nah, that wont stop it running though [12:58] there is a "nice" way to inhibit it [12:58] but perhaps we shouldnt have to === francisco is now known as Guest63468 === alan_g is now known as alan_g|lunch === hikiko is now known as hikiko|ln === alan_g|lunch is now known as alan_g [14:44] willcooke: screensaver or not should not make a difference in the upgrade, things shouldn't crash as a result of the upgrade. [14:44] cyphermox, oki [14:45] trying again with screensaver etc turned off [14:45] just to see if I can find the exact moment it dies [14:48] ah [14:49] I wonder if this is why we're not getting GUI prompts davmor2 [14:50] Something about debconf needs a screen at least 13 lines high, blah blah, falling back to readline [14:50] I'm running the install on a vbox [14:50] with a poor resolution [14:50] that might explain that issue anyway. === hikiko|ln is now known as hikiko [14:57] willcooke: readline should be "sufficient" and the prompts would then show in the attached terminal window [14:57] cyphermox, yeah, thats what happens [14:57] I mean, I see that the install on davmor's machine i stuck waiting for input for ssl, but I don't think that's the issue -- the no X is more of a problem [14:58] that said, I'm logged on SSH on dave's machine, and I'll try to debug compiz live maybe? [14:58] did we have a crash dump for it yet? [14:59] dont think so [15:07] okay [15:08] the point at which the upgrader UI crashes is about here... [15:08] Preparing to unpack .../xfonts-base_1%3a1.0.4+nmu1_all.deb ... [15:08] Unpacking xfonts-base (1:1.0.4+nmu1) over (1:1.0.3) ... [15:08] Preparing to unpack .../xfonts-scalable_1%3a1.0.3-1.1_all.deb ... [15:08] Unpacking xfonts-scalable (1:1.0.3-1.1) over (1:1.0.3-1) ... [15:08] Preparing to unpack .../xinit_1.3.4-3_amd64.deb ... [15:08] Unpacking xinit (1.3.4-3) over (1.3.2-1) ... [15:08] Preparing to unpack .../xinput_1.6.2-1_amd64.deb ... [15:09] and then the upgrade seems to stop here: [15:09] Setting up python-debtagshw (2.0.1ubuntu6) ... [15:09] Setting up ureadahead (0.100.0-19) ... [15:09] Setting up perl-modules-5.22 (5.22.1-8) ... [15:09] and it kicked me out of one of my SSH sessions [15:10] ok [15:11] that was using the graphical release-upgrader? [15:11] that was using "update-manager -d" [15:11] (ie. not do-release-upgrade -d in a terminal) [15:11] ok [15:11] I probably wouldn't make a difference, but just in case [15:11] so I had top running in another ssh session [15:12] and it kicked me out of that session at about 15:05:58 [15:12] I still have one ssh session open some hout [15:12] how [15:12] and in syslog [15:12] Mar 10 15:05:22 test14to16 ModemManager[28639]: Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:03.0': not supported by any plugin [15:12] Mar 10 15:05:57 test14to16 dbus[394]: [system] Reloaded configuration [15:12] Mar 10 15:06:00 test14to16 dbus[394]: message repeated 2 times: [ [system] Reloaded configuration] [15:12] Mar 10 15:06:00 test14to16 dbus[394]: [system] Activating service name='org.freedesktop.UDisks2' (using servicehelper) [15:12] Mar 10 15:06:00 test14to16 udisksd[29495]: udisks daemon version 2.1.7 starting [15:12] Mar 10 15:06:00 test14to16 dbus[394]: [system] Activating service name='org.freedesktop.PolicyKit1' (using servicehelper) [15:12] Mar 10 15:06:00 test14to16 polkitd[29500]: started daemon version 0.105 using authority implementation `local' version `0.105' [15:14] oh, and I had disabled the lock and the screensaver before running this upgrade [15:15] last thing in dpkg.log: [15:15] 2016-03-10 15:06:26 status installed libgtkmm-3.0-1v5:amd64 3.18.0-1 [15:18] ummmm [15:18] I wonder [15:18] apt.log: [15:18] MarkDelete python3.4 [ amd64 ] < 3.4.3-1ubuntu1~14.04.3 > ( python ) FU=0 [15:19] willcooke: gtkmm is not typically something that would break everything [15:19] I wonder if the installer has removed python from underneath the installer? [15:19] though a GLib / Gtk upgrade at the wrong time might cause crashes [15:20] willcooke: I thought all of X crashed? [15:20] oh, right yeah [15:20] yeah my X session is dead now [15:21] nothing in /var/crash [15:21] xorg log: [15:21] [ 6323.283] (EE) FBDEV(0): FBIOBLANK: Invalid argument [15:21] [ 6323.297] (EE) FBDEV(0): FBIOBLANK: Invalid argument [15:24] restarted lightdm [15:25] init: Error while reading from descriptor: Bad file descriptor [15:25] instead of a greeter [15:34] darkxst: Thanks for confirming about multidesktop XDG_CURRENT_DESKTOP values and .desktop files. [15:53] willcooke, cyphermox: I think it just hates us :'( [15:54] :(( [15:55] oh Laney looks like you might actually be able to detach the hdmi lead from the xps now without kernel panicking the system \o/ I don't want to try it again incase it was pure fluke :D === JoseeAntonioR is now known as jose === JanC_ is now known as JanC [16:48] davmor2: :-o [17:10] Laney: hey, is there some way to ask someone (aptdaemon/packagekit) over dbus to do an apt update? i tried org.debian.apt.RefreshCache but that didn't populate /var/lib/app-info/ [17:16] attente: I'm not sure, I would ask juliank in #ubuntu-devel - he's more likely to know [17:17] ok, thanks [17:17] maybe that function does it in some different way that doesn't run the Post-Update-Success hook [17:18] Laney: it's hard to tell what that function does at all. it seems to do nothing afaict [17:19] what does (e.g.) software-properties use? [17:31] Laney: ok, desrt just helped me out here. apparently i have to create a transaction and call GetUpdates on it [17:33] cool [17:33] sorry I don't know those APIs very well & I'm in the middle of my quest to kill juju [17:42] Laney: we kinda want to expand your original bug [17:42] and make it so that we do a refresh on startup any time we detect that the last time 'apt update' was run is more than 1 day ago (or never) [17:43] it turns out that the timestamp on /var/cache/apt is a pretty good place to start -- but it's a bit complicated if this directory was created during install and nobody actually ran 'apt update' yet [17:43] desrt: as long as you fix the bug then you can expand whatever you want [17:43] the rest is a matter for robert_ancell [17:43] it would also be ideal if we could plumb this through packagekit... [17:44] well, fixing it is easy enough now that we found the right set of APIs [17:44] sehr gut [17:44] but "first install and user didn't apt update yet" is not the only place where apps may be missing [17:44] could be nobody ran "apt update" in months and apps got added in the meantime [17:45] update-manager is updating for you [17:45] just not right after install :p [17:45] right [17:45] can we fix that? :D [17:46] not for the general 'sudo apt install gnome-software' case [17:46] i ate you [17:47] actually, i'm kinda hungry [17:47] I think that ximion said that g-s already does have this timed refresh thing [17:47] just not the always-do-it-if-empty case [17:47] ya... i think it stores the timestamp int he user session tho [17:47] we could do the same here....... just seems ugly to have 100 copies of timestamps stored per user for the same thing (which is really system-wide) [17:48] for apt it is... [17:48] like, even separate copies of it stored for the same user, even [17:48] true. [17:48] * desrt snaps her fingers [17:48] anyways! [17:48] ya. a bit of a sidetrack here [17:48] As long as updaters have it working [17:48] seems that the easiest thing to do now is to fix the bug as filed, using the dbus api [17:48] any extra coolness is cool too [17:49] Laney: that timed refresh doesn't happen though if you patch out the g-s daemon mode [17:49] it's cool to be cool! [17:49] kaj mojoseco mojosas [17:49] ximion: ok I didn't track what they did on the client side to be honest [17:49] Laney: AFAIr removed that feature ^^ [17:50] (but better check for that, don't take my word for it) [17:51] we disabled daemon mode except in the case where it's explicitly run with --gapplication-service [17:51] is it DBusActivatable? [17:51] yes [17:52] so then it's always run with --gapplication-service... [18:08] g'nigth all [18:08] night [18:12] me too, see you [18:15] night Laney & co [19:46] good night europeans [20:58] tkamppeter, I'm looking at the unity-settings-daemon code and the print notification plugin seems completely disabled. Does that make sense? I'm going to drop all the code for it if that's the case. [21:06] Mh, with recent changes I did, I'm about to think that all the apps we patched to get headerbar would just look better as native... 🙊 [21:06] starting from https://code.launchpad.net/~3v1n0/ubuntu-themes/toolbar-mode-headerbar-gradient/+merge/288701 (and related gtk patch) [21:07] Trevinho, yeah, they look nice now [21:07] robert_ancell: about that.... can you give a look at the gtk branch? 😃 [21:08] Trevinho, which branch? [21:08] robert_ancell: https://code.launchpad.net/+branch/~3v1n0/gtk/unity-maximized-headerbar-buttons-hide [21:09] Trevinho, you have an unused local variable "unity_environment" in the patch [21:09] I do use it... [21:09] Trevinho, you use priv->unity_environment [21:10] oh, duh [21:10] reading the patch wrong [21:10] :) [21:10] I thought that was at the top of the function [21:10] Reviewing patches really feels wrong [21:10] It's like we have a better system for all this... version control? [21:10] Actually I should probably change it so that it only hides the title if != from toplevel window title [21:10] ;) [21:11] Maybe somneone could set an headerbar title that is different... [21:12] Trevinho, yeah, I was thinking that might even be likely. Do HeaderBar apps even set the traditional title? [21:13] Also, the placement of the title is probably significant (i.e. being centered) [21:13] Or does Unity handle that [21:50] robert_ancell: placement shouldn't be a problem,... [21:51] robert_ancell: I've updated the patch to care about window title, though. [22:20] robert_ancell, I did not really have a look at the print notifications on the desktop. CUPS produces notifications on D-Bus which I have already made use of in cups-browsed (making use of some code snippets of larsu's printer-indicator). [22:21] robert_ancell, I think it is a good idea to have some kind of notifications, so that users can access their jobs and know which printers are currently free. [22:21] tkamppeter, I think g-s-d had some notification system that we disabled, so it's no longer required in u-s-d [22:23] robert_ancell, could be either the printer indicator showing a printer at the top right and having a menu to reach the print queues or like in mpt's printing design a printer in the launcher on the left, doing more or less the same thing. [22:24] robert_ancell, if both g-s-d and u-s-d are running, then only one needs to handle printing notification (to avoid duplicates), so if both contain the code, it can be dropped in one. [22:24] robert_ancell, and g-s-d is probably the better place as it is running in both Unity and GNOME desktops. [22:25] tkamppeter, u-s-d checks if it is running in Unity and disables the code. I just wanted to check you didn't expect u-s-d to provide this functionality [22:27] robert_ancell, I did not code anything of the print notification functionality for the desktop, we only should make sure not to duplicate functionality to ease maintaining the code and make sure that all users get notifications, both of GNOME and of Unity.