[03:13] <robert_ancell> ximion, what code does the icon lookup for appdata? I'm wondering if it doesn't handle Icon=name.extension in .desktop files (see bug 1560550)
[03:13] <robert_ancell> Note that skype seems to make the same mistake (of explicitly putting in an extension)
[03:14] <robert_ancell> The spec suggests this is not valid (https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html)
[03:14] <robert_ancell> But it seems everthing is currenly handling it
[03:32] <ximion> robert_ancell: the generator cheats in that case
[03:32] <ximion> and removes the extension
[03:32] <robert_ancell> ximion, so is that bug invalid?
[03:33] <ximion> this only works with .png though, and is a hack - I was even thinking about removing it, to make people obey the spec ^^
[03:33]  * ximion won't do that though, maybe later after a long priod of warning about it
[03:35] <ximion> hmm... this looks like a generator bug
[03:35] <ximion> or maybe not
[03:36] <sarnold> in my experience things get harder to remove the longer they've been around :)
[03:36] <robert_ancell> ximion, oh, the icon is in -data and the .desktop is in the main package
[03:36] <robert_ancell> That's still an issue right?
[03:37] <ximion> robert_ancell: that shouldn't be a problem
[03:37] <ximion> but the icon being a symlink in 256x256 to a 48x48px icon in /usr/share/pixmaps is a problem
[03:37] <ximion> that should definitely be fixed, and I bet the problem will be solved then
[03:38] <robert_ancell> aha
[03:39] <ximion> robert_ancell: the generator tells explicitly what the problem is :D
[03:39] <ximion> http://appstream.ubuntu.com/xenial/universe/issues/supertux.html
[03:40] <ximion> => The symbolic link points to a file which is in a different package - we don't follow those links
[03:41] <robert_ancell> ximion, but it would work if there wasn't a link?
[03:41] <ximion> robert_ancell: yes - I suggest removing the bad link from the supertux package, and symlinking the file in the -data package at the same location
[03:42] <robert_ancell> ximion, thanks
[03:42] <ximion> that will work, and will have no drawbacks
[03:42] <ximion> yw
[03:42] <ximion> I wonder why the symlink was in the other package in the first place...
[03:43] <ximion> oh, btw: adding a smaller icon size would be nice for DEs which currently downscale a 256x256 icon ^^
[03:43] <ximion> (but that's optional)
[03:45] <robert_ancell> ximion, can't solve all of upstreams issues :)
[03:46] <hexahive> Hello ppl :) I need an advice... I'm getting an error "[*] Access file: 'access.conf' was not found." , while trying to start fwknop-server ... I've checked that the file exists in /etc/fwknop, also tried to chmod it to 777 and chgroup it to my username instead of root, but none of those usual things help... Any ideas ?
[03:46] <ximion> robert_ancell: when the new metadata generator is deployed at Debian, I will submit a patch to the Distro Tracker / PTS to display that information there
[03:47] <ximion> that should help to raise awareness that there are issues ^^
[03:47] <ximion> (people need to explicitly go to appstream.d.o or appstream.u.o to find that information)
[03:47] <sarnold> hexahive: hint: stick around for more than a minute after asking a question...
[03:49] <sarnold> hexahive: http://sources.debian.net/src/fwknop/2.6.0-2.2/server/access.c/#L1018
[03:49] <hexahive> sarnold: thanks for advice, i've accidentaly exited ubuntu-server after asking ;)
[03:49] <sarnold> hexahive: note that it tries to use the same pathname in stat() that it prints to the error log -- since it is just 'access.conf' that probably means it is looking in the current working directory for the file. Is the current working directory set to /etc when you run it?
[03:51] <hexahive> ah, no... so your advice is to try starting it by first cd-ing to /etc or /etc/fwknop ? btw i run it with sudo service fwknop-server start
[03:52] <sarnold> hexahive: or give a full pathname in the configuration file
[03:53] <sarnold> giving the full pathname means you won't need to care about current working directory
[03:55] <hexahive> sarnold: thanks, will try right away
[05:11] <hikiko> Hi
[07:55] <willcooke> morning all
[07:59] <Trevinho> Morning!
[07:59] <Trevinho> Hi willcooke
[07:59] <willcooke> How's it going Trevinho ?
[07:59] <willcooke> Good weekend>?
[08:01] <Trevinho> willcooke: yeah a longer one. And a good one, although weather didn't help much.
[08:01] <Trevinho> You?
[08:01] <willcooke> same
[08:01] <willcooke> :)
[08:06] <happyaron> morning willcooke
[08:06] <willcooke> hey happyaron
[08:07] <Sweet5hark> moin
[08:07] <willcooke> morning Sweet5hark
[08:24] <xnox> willcooke, jibel - i thought the conclusion was that www.ubuntu.com will only list amd64 for 16.04 for desktop download images, but we will release i386 iso as usual.
[08:25] <willcooke> xnox, I think I've missed some of the back-story but yeah, that makes sense I think.  Seb will probably be cross, but I think it's logical to but the 32 bit image in the same place as the "alternates"
[08:26] <willcooke> I have a meeting with the web team at lunchtime so I can check in with them then
[08:27] <willcooke> Trevinho, are you aware of this one:  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1532226
[08:28] <willcooke> Trevinho, assigning to you to start with, please reassign as neeeded
[08:39] <xnox> willcooke, physical meeting, or virtual?
[08:40] <willcooke> xnox, they'll be in Bluefin I'll be on via a HO
[08:40] <xnox> willcooke, when i used to be on the installer team, i'd go to bluefin to brush over all download pages to make sure they are aligned with what release team is planning to release. Not two cycles were the same yet =)
[08:40] <willcooke> :)
[08:40] <xnox> willcooke, imho it should just be an orange download button, without any drop-downs for desktop download page, same as it is for server/cloud
[08:41] <xnox> and since this is an LTS release, just the LTS download section.
[08:42] <willcooke> xnox, I agree.  Will keep you posted
[08:42] <xnox> =)
[08:59] <didrocks> willcooke: FYI, Make supports 35 frameworks as of now (4 more than my annual review comment last month ;))
[09:00] <didrocks> (replied to thibaut)
[09:00] <didrocks> and hey!
[09:00] <willcooke> thanks didrocks
[09:00] <didrocks> yw
[09:49] <Trevinho> willcooke: ok looking at that bug, thanks.
[09:50] <willcooke> thanks Trevinho - I haven't seen it yet, but I guess plenty of people have now
[09:50] <willcooke> maybe davmor2_HOLS did too
[09:50] <willcooke> hence it being in the iso tracker
[11:00] <andyrock> hey
[11:05] <willcooke> hi andyrock
[11:05] <andyrock> willcooke: any news about the crash?
[11:06] <willcooke> andyrock, yes! See: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1555237
[12:06] <ricotz> Trevinho, hi, if a BamfApplication emits window-added providing the BamfWindow as argument I would assume that bamf_application_get_windows and bamf_application_get_xids lists that window already
[12:07] <ricotz> Trevinho, It seems logical I am pretty sure it was so in the past and therefore a regression?
[12:12] <Trevinho> ricotz: mhmh. So it should happen. At lunch now. Looking at it soon.
[12:17] <ricotz> Trevinho, thanks
[12:50] <desrt> word up
[12:51] <willcooke> morning desrt
[12:58] <Trevinho> ricotz: soooooo... I don't get that here, but it looks like it something that could happen because of a race. The thing is that bamf_application_get_windows returns the cached-windows that is actually populated on child-added signal, not on window-adedd. Thus if that window-added signal arrives before than child-added, then the result might be broken
[12:59] <Trevinho> ricotz: however, while I see that possible for bamf_application_get_windows, it looks weird for bamf_application_get_xids , since this uses a list of xids that we populate on window-added signal
[13:00] <Trevinho> ricotz: http://pastebin.ubuntu.com/15551495/
[13:00] <Trevinho> ricotz: so the list is populated, then we emit the signal. And  cached_xids is returned if available when calling get_xids
[13:03] <Trevinho> ricotz: I think this might fix things for you though
[13:03] <Trevinho> http://pastebin.ubuntu.com/15551521/
[13:10] <Trevinho> In my opinion deprecating the window-added signal at daemon level would be just better, however... And just rely on the child-added one. Then generating the window-added/removed signals only at lib level
[13:13]  * desrt raises her eyebrow
[13:18] <ricotz> Trevinho, using child-added with get_xids seems to work
[13:19] <ricotz> it still seems something changed here
[13:19] <Trevinho> ricotz: not really recently. Probably 1.5 cycles ago?
[13:20] <Trevinho> ricotz: as I added some caching, and get_xids is not calling dbus methods everytime now
[13:20] <ricotz> I am a bit puzzled that I would have missed the for so long
[13:20] <ricotz> maybe some dbus/glib changes triggered some ordering change?
[13:21] <Trevinho> I don't think... Signals seems to be emitted properly in order. We didn't change that.
[13:21] <ricotz> I see
[13:21] <Trevinho> but as I said, the fact that we depend on a cached list of xids now, might be the thing
[13:21] <Trevinho> also, this shouldn't show up on first child addition
[13:21] <ricotz> ok
[13:32] <ricotz> Trevinho, alright, please make those signals behave the same as you suggested
[15:22] <Trevinho> ricotz: want to check https://code.launchpad.net/~3v1n0/bamf/windows-signal-merge/+merge/290325 ?
[15:26] <Trevinho> ricotz: can you also open a bug related to that?
[15:30] <willcooke> meeting time
[15:30] <willcooke> #startmeeting Desktop Team Meeting - 2016-03-29
[15:30] <meetingology> Meeting started Tue Mar 29 15:30:19 2016 UTC.  The chair is willcooke. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:30] <meetingology> Available commands: action commands idea info link nick
[15:30] <andyrock> \o
[15:30] <Trevinho> o/
[15:30] <willcooke> Roll call:  andyrock, attente, desrt,  dgadomski (hols), fjkong, happyaron (out), hikiko(out), laney(hols), qengho, seb128(hols), sweet5hark, themuso (out), tkamppeter, trevinho, robert_ancell (out)
[15:30] <qengho> Yay!
[15:30] <desrt> hihi
[15:30] <FJKong> 0.0
[15:31] <Sweet5hark> heya
[15:31] <qengho> Hello, my lovelies.
[15:31] <attente> o/
[15:31] <willcooke> Lets roll...
[15:31] <willcooke> #topic andyrock
[15:32] <andyrock> hey all
[15:32] <andyrock> i worked on the upgrade crash and took some days off
[15:32] <andyrock> now i'm working to update a branch afters Trevinho's review
[15:33] <willcooke> thanks andyrock
[15:34] <willcooke> Do you know if anything has changed on the upgrade bug today?
[15:34] <andyrock> nope
[15:34] <andyrock> but it's definitely not unity
[15:34] <andyrock> neither compiz
[15:35] <willcooke> oki, I'll speak to c__yphermox and see if he knows where we go next.  Thanks for digging in to it
[15:35] <willcooke> #topic attente
[15:36] <attente> shorter week due to long weekend, fixed some gnome-software bugs, looks like most of the low-hanging fruit is gone at this point though (eof)
[15:36] <willcooke> thanks attente
[15:36] <willcooke> could you hook up with Robert later on and see what's the next best one to work on?
[15:36] <attente> sure
[15:36] <willcooke> cheers! :)
[15:37] <willcooke> #topic desrt
[15:37] <desrt> short week here as well
[15:37] <desrt> did reviews
[15:37] <desrt> also 3.20 gnome releases
[15:37] <desrt> also did a bit of tech-support this week in terms of helping with the snappification of gnome-tech-using software
[15:37] <desrt> eof.
[15:37] <willcooke> thanks desrt
[15:38] <willcooke> #topic FJKong
[15:38] <FJKong> 1 just working on new feature request about sogou IM
[15:38] <FJKong> 2 testing decompression of skin file using libapng
[15:38] <FJKong> 3 collecting new bug report from community user
[15:38] <FJKong> eof
[15:38] <willcooke> thanks FJKong
[15:38] <willcooke> #topic happyaron
[15:38] <willcooke> 1. Sponsor uploads for Ubuntu Kylin
[15:38] <willcooke> 2. Sprint with NUDT during Wed - Sat, for sogoupinyin and localization stuff
[15:38] <willcooke> 3. Package new wallpapers
[15:38] <willcooke> 4. Bugs.
[15:38] <willcooke> #topic hikiko
[15:38] <willcooke> * bug #1555237: after some debug on X and some suspicious postinst
[15:38] <willcooke> scripts that could be related to the issue, we found out that xserver
[15:38] <willcooke> receives the SIGKILL by systemd and dies and it's not compiz or any
[15:38] <willcooke> other desktop application that crashes it - slangasek is working on it now.
[15:38] <willcooke> * ezoom (today): fixed another issue with the translation parts of the
[15:39] <willcooke> compiz zoom matrix, fixed some problems related to the transformations
[15:39] <willcooke> order, working on the scaling bugs I have on nux/unity side...
[15:39] <willcooke> EOF
[15:39] <willcooke> #topic qengho
[15:39] <qengho> * New Chromium release, 49.0.2623.108. Less than a week after previous. Tested. Gave to #security
[15:39] <qengho> * Some progress on Snappy package crash of Chromium in dynamic linker. Still weird. In progress.
[15:39] <qengho> * Other snappy/snapcraft work. Thinking about cross-compilation features.
[15:39] <qengho> EOF
[15:39] <willcooke> thanks qengho
[15:39] <willcooke> #topic Sweet5hark
[15:40] <Sweet5hark> - two days holidays
[15:40] <Sweet5hark> - some tweaking of snap
[15:40] <Sweet5hark> - some QA/bug triage/admin
[15:40] <Sweet5hark> - some bug/regression fixing and code review
[15:40] <Sweet5hark> EOF
[15:40] <willcooke> thanks Sweet5hark
[15:40] <willcooke> #topic TheMuso
[15:40] <willcooke> * Finally got all the pieces landed for accessibility profiles, and all working except for one small bug I overlooked which is addressed with a quick upload.
[15:40] <willcooke> * More upgrade testing, still freezing, not sure whats going on, testing in a VM, may switch to testing on real hardware since I have some spare.
[15:40] <willcooke> * Installer testing mostly for accessibility profile stuff, no showstoppers.
[15:40] <willcooke> #topic tkamppeter
[15:42] <willcooke> hmm
[15:42] <willcooke> #topic Trevinho
[15:42] <Trevinho> · Improving theming support for overlays
[15:42] <Trevinho> · Decorate launcher/panel when in spread mode
[15:42] <Trevinho> · Fixed and Landed gtk/theme branches for getting toolbar-mode headerbars when maximized
[15:42] <Trevinho> · Reviews
[15:42] <Trevinho> EOF
[15:42] <willcooke> thanks Trevinho
[15:42] <willcooke> #topic robert_ancell
[15:42] <willcooke> - GNOME Software work
[15:42] <willcooke> - LightDM 1.18.0 stable release
[15:42] <willcooke> - Sponsoring uploads
[15:42] <willcooke> #topic willcooke
[15:42] <willcooke> Beta 2 out!!!!
[15:43] <willcooke> Thanks to everyone for all your help getting it out
[15:43] <willcooke> we had some snags along the way and it was pretty late in the day when it was released, but we got there
[15:43] <willcooke> #topic any other business
[15:43] <willcooke> Anyone got anything they want to talk about?
[15:44] <willcooke> going once
[15:44] <Trevinho> Mh, not really... I think the we're quite on track...
[15:44] <Trevinho> Ah, there's that bug of menus not showing up...
[15:44] <willcooke> let's end the meeting and talk about that...
[15:45] <willcooke> thanks all
[15:45] <Trevinho> Which seems something like a race, maybe attente knowledge on unity-gtk-module might help at some point
[15:45] <willcooke> #endmeeting
[15:45] <meetingology> Meeting ended Tue Mar 29 15:45:03 2016 UTC.
[15:45] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2016/ubuntu-desktop.2016-03-29-15.30.moin.txt
[15:45] <attente> Trevinho: which bug?
[15:46] <Trevinho> attente: Bug 1532226
[15:46] <attente> Trevinho: also.. i'm not sure what happened, but when i tried to run gtk apps recently in jhbuild, theming seems kind of broken
[15:46] <Trevinho> attente: using upstream gtk?
[15:47] <attente> Trevinho: yeah, but even if i check out an older version (like three months ago, i still see it, so i'm not sure what's happening)
[15:48] <Trevinho> attente: and by broken you mean?
[15:48] <attente> i'll take a screenshot
[15:50] <tkamppeter> hi
[15:50] <tkamppeter> sorry for being late.
[15:50] <tkamppeter> willcooke, I will send my stuff by mail in some minutes.
[15:53] <attente> Trevinho: https://imgur.com/wVYEPwI
[15:53] <attente> for the usual apps, everything looks ok
[15:54] <attente> it's just when running through jhbuild, the decorations look bad
[15:54] <Trevinho> attente: are you using the gtk unity patch?
[15:54] <Trevinho> I mean have you applied that to jhbuild?
[15:54] <attente> no, this is unpatched gtk
[15:54] <Trevinho> mh, it's weird though... Since nothing should change at theme level in this case
[15:55] <attente> but for whatever reason when i check out gtk from 3 months ago, it still has this problem, so i have no real clue what changed
[15:55] <Trevinho> since we apply new rules to a class of headerbars only that is only exported if that patch is there
[15:55] <attente> yeah... it's really weird
[15:55] <Trevinho> attente: that was caused by the last theme update?
[15:56] <attente> Trevinho: really hard to tell, i did a dist-upgrade concurrently with a gtk+ checkout
[15:56] <Trevinho> mh
[15:56] <Trevinho> can you try old ubuntut hemes?
[15:59] <Trevinho> attente: ^
[15:59] <attente> Trevinho: sure
[15:59] <attente> Trevinho: i'm not sure that's a unity-gtk-module bug if this is happening: https://launchpadlibrarian.net/245092360/Screenshot%20from%202016-03-02%2017-08-23.png
[16:00] <Trevinho> attente: it could be, what else could provide such menus?
[16:01] <Trevinho> attente: if you can give me gdbus call --session --dest com.canonical.Unity.Panel.Service.Desktop --object-path /com/canonical/Unity/Panel/Service --method com.canonical.Unity.Panel.Service.SyncOne 'libappmenu.so'
[16:01] <Trevinho> wnckprop --list
[16:01] <attente> Trevinho: well in that situation, maybe u-p-s isn't getting any signal from bamf that the focused application changed?
[16:02] <Trevinho> attente: as per the fact that calculator app name is there, would say no.
[16:02] <attente> Trevinho: i didn't replicate the problem yet, that's just a screenshot from the bug report you linked
[16:02] <Trevinho> attente: also we now exports all the menus around
[16:02] <Trevinho> Ah.
[16:52] <ricotz> Trevinho, https://paste.debian.net/plain/422523 ?
[16:53] <Trevinho> ricotz: mh, no.. I'd keep the window-{added,removed} at lib level. I'd just bind them to the child ones
[16:53] <Trevinho> as in theory a bamf app could be a container of other views (not that this is the case anymore, but it used to be with webapps)
[16:54] <ricotz> Trevinho, I see
[16:54] <ricotz> still is there a reason for the chain-up?
[16:55] <Trevinho> not much right now, but I'd prefer to keep that API
[16:56] <Trevinho> ricotz: ah you mean on the daemon?
[16:56] <ricotz> Trevinho, yes, then second part of the diff
[16:57] <Trevinho> ricotz: yeah, that is fine
[16:57] <ricotz> ok, sorry, g2g
[16:59] <Trevinho> me too... Pushing your changes later
[18:12] <cyphermox> Trevinho: hey
[18:13] <cyphermox> are you looking into udisks2 for the upgrade from trusty?
[18:14] <willcooke> andyrock could get involved here too ^
[18:14] <Trevinho> cyphermox: I wasn't working on that... andyrock did
[18:15] <andyrock> cyphermox: are we 100% sure it's udisks2?
[18:15] <ogra_> looks like simply someone restarts dbus (which tears down the world with it)
[18:16] <andyrock> ogra_: can we monitor who/what does that?
[18:16] <cyphermox> andyrock: I'm not 100% sure of anything, I was just looking at the upgrade bug again, looking to see if there's something for me to do there.
[18:17] <ogra_> andyrock, i dont think so
[18:17] <cyphermox> dbus restarting is unfortunate but a reality when you need to update things like glibc too, etc.
[18:17] <ogra_> but i'd expect some evil postinst or some such somewhere
[18:17] <ogra_> cyphermox, well, but that kills lightdm
[18:17] <cyphermox> are you sure that's what kills lightdm?
[18:17] <cyphermox> ie. X crashes anyway, that's not dbus-related.
[18:18] <cyphermox> or if it doesn't crash, it stops in any case
[18:18] <ogra_> cyphermox, stop dbus on your system and you will see lightdm stop
[18:18] <cyphermox> it definitely needs more looking into, that's for sure
[18:18] <cyphermox> ogra_: doesn't mean that's the issue
[18:18] <ogra_> not, it could just be fallout
[18:19] <ogra_> but there is indication tht dbus gets restarted somewhere in the bug
[18:19] <ogra_> which will cause lightdm to die
[18:20] <cyphermox> too many people looking at this bug makes it full of useless garbage and red herrings
[18:20] <ogra_> weather that is because dbus crashed due to something or because some evil postinst force-restarts it, that i dont know
[18:21] <andyrock> i looked into it until we thought that unity/compiz was making x crashing
[18:26] <cyphermox> heh
[18:28] <andyrock> i can keep working but we need more info on why dbus crashes
[18:28] <andyrock> i can try to gdb it if it's possible
[18:40] <ogra_> are you sure it even crashes ?
[19:02] <willcooke> right, off now until EOW. Email me if you need anything
[21:48] <attente> robert_ancell: hi, are there any specific gs bugs you would like me to look at? i think a lot of the crashes might go away by taking 7fabe936f527ad53f0f51408da64bad80a126dc1 and 0ea65a85eb9fd2e71295f694aa4fb30aae773956
[21:48] <robert_ancell> attente, nothing specific really, just what looks the highest priority
[21:49] <robert_ancell> attente, did you want to make a release so you're comfortable with the process?
[21:50] <attente> robert_ancell: sure, i can give it a try
[21:51] <attente> robert_ancell: i can just take diffs of each branch against the gnome-3-20 and use those for the debian patches?
[21:51] <robert_ancell> attente, yes, but you might find some conflicts if you don't make your own rebased branch with them all
[21:52] <robert_ancell> And rebasing will make it easier to generate the patches
[21:53] <robert_ancell> attente, you should also generate a snapshot from gnome-3-20 because it has some fwupd patches that we need
[21:53] <attente> ok
[22:01] <robert_ancell> (or you can pull in each individual patch)