[01:10] <TheMuso> attente: Hrm ok, but it may be because the yakkety system is relatively fresh, i.e last week.
[01:10] <TheMuso> attente: i.e that other system worked fine.
[05:00] <hikiko> hello
[06:44] <vigo> morning!
[06:44] <vigo> somone to lend a hand with yakkety?
[06:46] <RAOF> What's up?
[06:48] <vigo> I'm trying to install daily build of yakkety but it is crashing every time I try
[06:48] <vigo> toshiba portege with SSD hd
[06:48] <vigo> you happen to know if the installation is buggy or crashy=
[06:49] <vigo> I've got even the bug report
[06:49] <vigo> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1611010
[06:51] <vigo> I'm doing the installation through a USB bootable stick
[06:53] <RAOF> Looks like the installer *is* buggy :)
[06:53] <vigo> I'm trying now with xenial iso to confirm =)
[06:56] <vigo> You're right RAOF =) on xenial works perfect
[06:57] <vigo> you buggy installer thanks!
[07:17] <tsdgeos> is anyone else not having a proper scrollbar in firefox in yakkety?
[07:17] <tsdgeos> the scrollbar space is there, but not the handle/knob
[07:20] <desrt> word up, d-tops
[07:34] <RAOF> The bird, I believe, is the word.
[07:47] <seb128> good morning desktopers
[07:47] <seb128> hey desrt RAOF
[07:48] <Trevinho> good morning
[07:48] <seb128> tsdgeos, could be a gtk 3.20 fallout, what firefox version do you have? yakkety has 46 but proposed has 48 and it might be worth trying that one
[07:48] <seb128> hey Trevinho!
[07:48] <Trevinho> hi seb128, how are you?
[07:48] <desrt> hey seb
[07:48] <seb128> Trevinho, I'm good thanks! you?
[07:48] <tsdgeos> seb128: 47
[07:48] <seb128> try 48 just in case
[07:48] <Trevinho> allright, another sunny day... This summer is as it as to be :-)
[07:48] <tsdgeos> seb128: yeah the internet seems to agre with you it's because of gtk 3.20
[07:49] <tsdgeos> i've installed some extension that gives me blue colored scrollbars for the moment
[07:49] <tsdgeos> it's something
[07:49] <seb128> can you try 48?
[07:50] <seb128> I've a yakkety vm, let me boot that
[08:03] <Trevinho> Wow... This last yakkety landing is taking soooo long... :-/
[08:03] <Laney> sup
[08:03] <flexiondotorg> Morning.
[08:04] <flexiondotorg> I have a spare hour or so today. Laney, I'll be uploading artwork later.
[08:04] <willcooke> morning all
[08:04] <seb128> hey Laney
[08:04] <seb128> & flexiondotorg
[08:04] <seb128> & willcooke
[08:05] <seb128> how is u.k today?
[08:05] <willcooke> sunny!
[08:05] <flexiondotorg> Yep, that ^
[08:07] <seb128> lie!
[08:07] <Laney> it suuuuuuuuure is
[08:07] <seb128> what's going on?!
[08:08] <seb128> can you please send us our european sun back
[08:08] <seb128> kthxbye
[08:09] <Sweet5hark1> meh
[08:09] <Sweet5hark1> meh meh
[08:10] <Sweet5hark1> that naive patch for theming doesnt work against 3.20. in fact everything is different in 3.20.
[08:13] <seb128> welcome to GTK fun world, you got a free ticket to play another round!
[08:21] <desrt> *cough*
[08:22] <desrt> The following NEW packages will be installed: ... gcc-6 ...
[08:23] <desrt> cool
[08:29] <ochosi> Sweet5hark1: heh, yeah, what seb128 said ;) if you need help and link me to the code i can take a look later today probably
[08:29] <seb128> hey ochosi, how are you?
[08:30] <ochosi> good good :) you?
[08:31] <Sweet5hark1> ochosi: thanks, I think I first need to recompile an unpatched version against 3.20 to see if/how stuff is broken there at all.
[08:31] <ochosi> Sweet5hark1: hm, not sure that's true, but go ahead :]
[08:36] <seb128> I'm good thanks
[08:38] <ochosi> how's the whole gtk3.20 transition going for y?
[08:38] <seb128> it's in
[08:38] <ochosi> nice
[08:38] <ochosi> congrats
[08:39] <Laney> firefox needs a rebuild and to get out of proposed
[08:39] <Laney> been stuck there for a while
[08:40] <Sweet5hark1> ochosi: well, https://cgit.freedesktop.org/libreoffice/core/commit/?id=03c33a2521421415c4fcbbe1491dc92a1943269b looks like stuff is quite different for 3.20 vs. 3.19
[08:42] <seb128> chrisccoulson, hey, ^ do you plan to look at the firefox build on ppc/s390x or do you need help with that?
[08:42] <seb128> Laney, I've a feeling it's not going to be easy to find somebody wanting to fix the firefox build on ppc
[08:43] <chrisccoulson> I don't plan to do anything with ppc
[08:43] <Laney> so what then?
[08:45] <seb128> well, chrisccoulson's position iirc is that we should stop to claim we support firefox on those archs and stop building in there
[08:45] <seb128> but infinity disagrees with that iirc and said he would be happy to help fixing build issues so we keep having it available on those archs
[08:45] <chrisccoulson> Yeah, we should stop pretending that firefox is supported on powerpc
[08:46] <seb128> infinity, xnox hey, do you think you would have any cycles to help sorting out firefox on powerpc/s390x? if not we are suggesting removing it from those archs
[08:46] <seb128> chrisccoulson, what about s390x?
[08:47] <Laney> I get the position, but it requires some execution to become reality
[08:47] <seb128> you mean?
[08:47] <seb128> well, I just pinged them
[08:47] <seb128> let's give them some time to reply
[08:48] <seb128> if they don't/don't have slots we just stop building on those arch/delete
[08:48] <seb128> but it wouldn't be nice to just do it now before they reply?
[08:49] <seb128> I'm personally +1 to stop building it on powerpc, there are probably like 10 users for it and it's not worth the work it put on us to keep it working
[08:50] <ochosi> Sweet5hark1: right, but while for the theming side of things the changes might seem invasive, it's not *that* bad
[08:51] <Laney> I mainly mean that it has reverse dependencies
[08:51] <Laney> Hopefully most of those are OR-ed to any web browser
[08:53] <seb128> seems they do
[08:53] <seb128> but yeah if we decide to go this way it needs some work
[08:53] <seb128> but I don't think too much
[09:01] <Laney> I'll use chromium for a bit :-)
[09:02] <chrisccoulson> does anyone still use firefox? ;)
[09:03] <seb128> o/
[09:03] <Laney> I did until 2 minutes ago
[09:04] <seb128> I don't like the new look of the awesome bar in firefox 48 :-/
[09:04] <seb128> it's way harder to read/parse for me
[09:04] <seb128> let's see if I get used to it
[09:05] <seb128> desrt, oh, reminding you to look at that glib gerexp test issue from friday
[09:05] <desrt> oh ya.  yay.
[09:05]  * desrt loves gregex
[09:06] <desrt> link me?
[09:06] <seb128> desrt, also do you know if having xdg-open as a fallback for urls handling in glib when there are no registered handler was ever discussed?
[09:06] <seb128> didrocks, ^
[09:06] <desrt> what is your usecase here?
[09:06] <desrt> i think it doesn't make sense, since xdg-open is really only supposed to be doing what glib would be doing anyway
[09:06] <seb128> desrt, ERROR:/build/glib2.0-4NbKb8/glib2.0-2.49.2/./glib/tests/regex.c:82:test_new: assertion failed (g_regex_get_compile_flags (regex) == data->real_compile_opts): (0x00000000 == 0x00000001)
[09:06] <desrt> but i guess this is in the case that xdg-open has been replaced by our helper?
[09:06] <seb128> https://bugzilla.gnome.org/show_bug.cgi?id=767240
[09:07] <seb128> desrt, yeah, it's in the snappy case, we have a fake "xdg-open" that sends a dbus call to the real env which has a service handling the url
[09:07] <desrt> i think we should consider a different approach here, in fact
[09:07] <seb128> but for the "click on url" to work in gtk apps we need to have the mimetypes defined in the env
[09:07] <desrt> why not ship upstream xdg-open inside of the snap
[09:07] <desrt> and then create a .desktop file for our forwarding service
[09:07] <seb128> and?
[09:07] <desrt> and set it up as the default http and https handler (and whatever else)
[09:08] <desrt> then xdg-open will do its normal job, and then so will glib
[09:08] <seb128> how would that help?
[09:08] <desrt> it would make upstream xdg-open work, and it would eliminate the need for weird non-op fallbacks in glib
[09:08] <seb128> the issue there is that the in-snap .desktop needs to list all known handlers
[09:08] <desrt> no.  it only needs to know about the forwarding service
[09:08] <seb128> like x-scheme-handler/skype
[09:09] <desrt> oh.
[09:09] <desrt> i thought this was only for http and https
[09:09] <seb128> http/https works
[09:09] <desrt> on account of security concerns...
[09:09] <seb128> but it forces us to create a mimeapps.list
[09:09] <seb128> right
[09:09] <desrt> mimeapps.list is a trivial text file
[09:09] <seb128> right
[09:09] <seb128> but it needs to be edited to add mimetypes on our end then
[09:10] <seb128> like if skype claims x-scheme-handler in their snapd
[09:10] <seb128> we need to edit our os snap to list the mimetype
[09:10] <seb128> so xdg-open knows it's a type it can handle
[09:10] <desrt> i thought we discussed handling of arbitrary schemes and decided that it represents a security hole
[09:10] <seb128> well some people did
[09:10] <seb128> but I was not in this discussion
[09:10] <seb128> and now I'm hitting the issue than for e.g yelp to work be need to add help:
[09:11] <seb128> and then next somebody is going to say than clicking on an hangout:url in telegram doesn't work
[09:11] <seb128> so we add hangout
[09:11] <seb128> etc
[09:11] <desrt> telegram works by url
[09:11] <desrt> which seems to be the future here, in fact
[09:11] <seb128> you mean?
[09:11] <desrt> like telegram.me/desrt
[09:12] <seb128> well, if I send on a text saying "join me on hangout:seb-and-desrt"
[09:12] <desrt> ie: matching http url prefixes
[09:12] <seb128> what happens to the hangout:<...> part?
[09:12] <desrt> but does hangouts actually work that way?  hangouts are by http URL too
[09:12] <seb128> dunno
[09:13] <seb128> but
[09:13] <seb128> /usr/share/applications/mimeinfo.cache:x-scheme-handler/skype=skype.desktop;
[09:13] <desrt> ya... skype is dumb and old
[09:13] <seb128> so it means skype supports "skype:<id>"
[09:13] <desrt> i bet it has a more modern approach as well
[09:13] <seb128> /usr/share/applications/mimeinfo.cache:x-scheme-handler/steam=steam.desktop;
[09:13] <seb128> /usr/share/applications/mimeinfo.cache:x-scheme-handler/spice=remote-viewer.desktop;
[09:13] <seb128> /usr/share/applications/mimeinfo.cache:x-scheme-handler/vnc=vinagre.desktop;
[09:13] <seb128> I meant there is a stack of those
[09:14] <seb128> or "you should install appstream:evolution"
[09:14] <desrt> ...and it's probably not generally safe to allow confined apps to arbitrarily open them
[09:14] <seb128> they don't open
[09:14] <seb128> they send a dbus call to the system with the url
[09:14] <desrt> ...and then?
[09:14] <seb128> and the helper decide if it's safe to open or not
[09:14] <desrt> right.  exactly.
[09:14] <desrt> and afaik, the helper currently decides "http and https?  yes.  else?  no."
[09:15] <desrt> and mailto: also iirc
[09:15] <seb128> right
[09:15] <seb128> I wanted to restart that discussion with the snappy team because I was not part of the previous one and don't understand the rational
[09:15] <desrt> ie: we want only very specific handlers here.... as a matter of security policy... opening it to arbitrary handlers being dispatched from confined apps is a bad idea
[09:15] <seb128> what's the security risk of saying to the system "open that skype url with the handle you have for it"?
[09:15] <desrt> talk to attente when he wakes us...
[09:15] <desrt> opening skype can join you to a conversation, for example
[09:16] <seb128> k, I was planning to
[09:16] <desrt> that's much more active than simply viewing a webpage in a browser (which is an entire program designed to security-isolate you from the URLs you visit)
[09:16] <desrt> in any case...... i guess it might make sense to provide some sort of override mechanism in glib for this kind of thing, but it probably won't work as well as you think it will
[09:17] <seb128> is the issue there than we currently don't have a prompt to make you pick the app you want to use?
[09:17] <seb128> because e.g android do that
[09:17] <seb128> click on files or url trigger the system to ask you with what you want to open
[09:17] <seb128> and that list includes random app
[09:17] <seb128> I'm sure you can open skype from messanger on android
[09:17] <desrt> the issue is that applications, as we know them, are generally designed to assume that the thing passing them a (e.g.) skype: url are operating at a similar trust level
[09:18] <abeato> Laney, hey, I still need a review for the plugins-bad MP :)
[09:18] <desrt> on android it's different.. their URL dispatching mechanism has different trust-assumptions baked in to it
[09:18] <desrt> and it's not just about some "are you good with this?  [x]don't bother me again" prompt
[09:18] <Laney> abeato: I know, it's open right now
[09:18] <seb128> I guess I don't see what security issue it could be to see "yes I want to open that url in <software>" if it's a decision I explicitly ack/deny
[09:19] <Laney> abeato: I had to fix libhybris yesterday to make gst-bad even build
[09:19] <Laney> which was step zero in reviewing it
[09:19] <Laney> :/
[09:19] <desrt> because (a) if there is a security dialog every time, that's really really poor design
[09:19] <abeato> Laney, oh, I see
[09:19] <desrt> and (b) if there is not a security dialog every time, it's potentially dangerous
[09:19] <seb128> (a) is what android does right?
[09:19] <desrt> and (c) allowing the user to select "don't show me this anymore" is not really providing them with enough information to make an informed choice
[09:19] <Laney> abeato: so ya, doing this in a minute - now need to make MPs for those fixes
[09:20] <abeato> Laney, cool, thanks
[09:20] <desrt> no.  first of all, android only asks if there is a question of what to do.
[09:20] <desrt> if there is only one possible app to handle an action, it just does it
[09:20] <desrt> ie: the android dialog is not about security at all.  it is about selecting an app, in the purest sense.
[09:20] <seb128> k
[09:21] <desrt> and i repeat, the most important aspect here: android apps have been designed such that dispatched URLs are assumed to come from potentially untrusted sources
[09:21] <desrt> apps as we have them on our systems are not.  they assume that the thing that is feeding them the command line arguments is operating at the same level of trust
[09:21] <seb128> which was never true though
[09:21] <seb128> like you could call "program url:I-typed" for ever
[09:22] <desrt> yes.  of course.  the key being "i-typed"
[09:22] <desrt> ie: the user doing it themselves
[09:22] <seb128> so programs have to deal with potentially receiving random input aimed at made them bug
[09:22] <seb128> or the webpage you visit
[09:22] <desrt> and the argument there is, "if the user can type this commandline, then of course they could also just type rm -rf /... so no security concern..."
[09:22] <desrt> web browsers are VERY cautious about opening 3rd-party handlers
[09:23] <desrt> i just did a telegram request, for example, and am getting a rather large lecture about it from chrome
[09:23] <seb128> well if you click on appstream: url it's going to call gnome-software
[09:23] <desrt> "If you did not initiate this request, it may represent an attempted attack on your system.  Unless you took an explicit action to initiate this request, you should press «Do Nothing»"
[09:23] <seb128> interesting
[09:24] <desrt> (and imho, this is bad UI)
[09:24] <seb128> I think it's enough discussion for telling me it's not a simple matter of waving the whitelist thing then
[09:24] <seb128> hope they agree to add a few other selected handlers though
[09:24] <desrt> but the point stands: nobody thinks it's a good idea to let untrusted things open arbitrary url schemes with arbitrary handlers
[09:24] <desrt> meh.
[09:24] <seb128> I want "help:" in there so GNOME documentation works
[09:24] <desrt> to be honest, you have a point
[09:25] <desrt> it may make sense to allow this to be expanded in the future
[09:25] <desrt> and at some point we will probably want to add some mechanism to glib to allow for opening url handlers working with arbitrary URLs (and have them rejected on the system side)
[09:25] <seb128> well I guess it's fine for selected ones where we set a default handler
[09:26] <seb128> like help ;-)
[09:26] <desrt> that's a real feature to discuss... but (a) we can't "just do it", and (b) it won't look like fork()/exec() xdg-open
[09:26] <seb128> right
[09:26] <seb128> well my "fallback on xdg-open" was because xdg-open is that wrapper than do a dbus call for it
[09:26] <desrt> ya... of course
[09:26] <seb128> but it doesn't get to that point in there is no .desktop installed to claim the mimetype
[09:26] <desrt> but that only makes sense if xdg-open is not ... *ahem* xdg-open
[09:26] <seb128> so I need to create a fake mimeapps.list which has
[09:27] <seb128> x-scheme-handler/http=xdg-open.desktop
[09:27] <seb128> x-scheme-handler/https=xdg-open.desktop
[09:27] <seb128> x-scheme-handler/mailto=xdg-open.desktop
[09:27] <seb128> and it's a bit annoying
[09:27] <seb128> well, even if it was the real xdg-open
[09:27] <seb128> to get to the point it's being called you need it to have a .desktop which claims the mimetypes
[09:28] <desrt> i wonder if we could do x-scheme-handler/* somehow
[09:28] <desrt> like, we have mimetype inheritance
[09:28] <seb128> that would be nice
[09:28] <desrt> we could make a x-scheme-handler/fallback that is the parent type of all the other scheme handlers
[09:29] <seb128> qt apparently just fallback to calling xdg-open (from what didrocks said) so was wondering if that would make sense for gio
[09:29] <desrt> to be discussed with the mime maintainers, perhaps
[09:29] <seb128> right
[09:29] <seb128> desrt, thanks for the discussion!
[09:29] <desrt> i seriously doubt we will ever do this
[09:29] <seb128> k, fair enough
[09:29] <desrt> glib is trying hard to reduce the amount of fork()/exec() it does
[09:29] <seb128> do you know how flatpak handles urls?
[09:29] <desrt> i think it doesn't :)
[09:29] <desrt> at least not last i heard of it
[09:30] <seb128> k, so eventually we all need to figure out something
[09:30] <desrt> ya.  and i will insist on it being the same thing for everyone :)
[09:30] <seb128> +1
[09:31] <seb128> thanks desrt
[09:31] <seb128> desrt, going back to the other topic, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/g/glib2.0/20160806_091504@/log.gz
[09:31] <seb128> desrt, the error matches what is in https://bugzilla.gnome.org/show_bug.cgi?id=767240
[09:31] <seb128> which I think meant 8.39
[09:32] <desrt> i'm starting to wonder about the value of testing GRegex
[09:32] <seb128> that's the pcre3 8.38->8.39 that triggers the test regression
[09:32] <desrt> i think pretty much 100% of people are using it only for non-obscure features
[09:32] <desrt> and the testcase is brutally heavy on testing every weird edge case
[09:32] <andyrock> Morning
[09:33] <seb128> well it's important to not regress/change behaviour, even on edge cases no?
[09:33] <seb128> hey andyrock, having nice holidays? ;-)
[09:34] <desrt> seb128: not if nobody cares :p
[09:34] <desrt> at some point you start testing the implementation more than the interface
[09:35] <desrt> okay.  in this case, it seems quite bad, indeed, though.
[09:35] <desrt> since the documentation specifically mentions these features...
[09:35] <desrt> wtf...
[09:37] <desrt> interesting to notice that the last several cases of this have been addressed by fixing the tests :p
[09:41] <seb128> :-)
[09:50] <tsdgeos> seb128: yes firefox 48 from proposed fixes the scrollbar problem (and other issues i had with checkboxes and stuff)
[10:25] <xnox> seb128, infinity, chrisccoulson - possibly related https://bugzilla.mozilla.org/show_bug.cgi?id=1271748 based on pattern matching. The fact that it affects big-endian only is suspicious.
[10:25] <xnox> does anyone at all run nightly builds and/or any way to bisect as to when this has started to happen?
[10:26] <chrisccoulson> xnox, that issue was caused by us not bundling the ICU data file. That's fixed now
[10:26] <xnox> chrisccoulson, ack, thanks.
[10:29] <xnox> chrisccoulson, is our packaging of firefox at all bisectable, or am I better off building / running bisect against upstream tree? to spot when s390x stopped building between firefox 46 & 48?
[10:29] <chrisccoulson> xnox, you'd need to do it against upstream
[10:30] <xnox> ack
[10:36] <desrt> seb128: you'll never guess what i'm going to do to fix this bug :D
[10:36] <desrt> pcre broke behaviour upstream, intentionally...
[10:36] <xnox> chrisccoulson, ... and it needs gazzilion disk space right?
[10:36] <desrt> and i sort of agree that it doesn't really matter
[10:37] <chrisccoulson> xnox, I can't remember - I don't recall the last time that I did a firefox build locally :)
[10:37] <chrisccoulson> I don't think it's that bad
[10:37] <chrisccoulson> compared to what I usually work on
[10:41] <ricotz> chrisccoulson, xnox, better adding s390x support to the firefox-next ppa ;)
[10:41] <chrisccoulson> Does anyone use firefox on s390x?
[10:42] <ricotz> I guess not, so simply blacklisting the ppc and s390x seems the best way
[10:45] <xnox> ricotz, there is community port to lubuntu for powerpc, i'm pretty sure it's like the only browser working there.
[10:45] <xnox> no, nobody uses graphical things on s390x.
[10:45] <xnox> .... or at least they should not.
[10:45] <xnox> but failure of _all_ big endian architectures we have, indicates an endianess bug =)
[10:47] <ricotz> xnox, ok
[10:51] <desrt> seb128: patch in the bug to test, if you like
[10:51] <xnox> ricotz, is firefox-next canonical-only ppa?
[10:52] <ricotz> xnox, no
[10:52] <xnox> no powerpc/s390x for that, for now, then =(
[11:01] <chrisccoulson> xnox, see the comment here - https://hg.mozilla.org/mozilla-central/file/tip/build/autoconf/icu.m4#l81
[11:02] <Sweet5hark1> hmmm, apt-get build-dep libreoffice finished with exactly 0 bytes of disc space in a VM. it claims to be successful.
[11:02] <chrisccoulson> should save you time bisecting ;)
[11:02] <Sweet5hark1> <- living on the edge
[11:02] <xnox> chrisccoulson, ah
[11:02] <xnox> chrisccoulson, so... how is that generate? and why a system one is not used?
[11:03]  * xnox ponders how to generate it.
[11:10] <chrisccoulson> xnox, we don't use system libraries in firefox
[11:12] <xnox> i think their update script does build both little and big endian, and then just ignores the bigendian one =(
[11:28] <xnox> chrisccoulson, re-running icu_sources_data.py after patching it to keep bigendian icudata.
[11:31] <xnox> then i'll need to patch build machineray to use that. and hopefully everything will be good.
[11:32] <Laney> seb128: it's raining now
[11:32] <Laney> you'll be happy to know
[11:34] <Laney> xnox: thanks for looking!
[12:03] <seb128> Laney, sorry about that, sun is back there...
[12:04] <seb128> desrt, thanks, going to try that in a bit
[12:05] <desrt> pretty sure it should work fine.... it basically just comments out the problem :p
[12:05] <seb128> feels like cheating!
[12:10] <desrt> the problem is well-understood, and the change was intentional by upstream
[12:10] <desrt> it just so happens that our tests are more pedantic than theirs are
[12:17] <infinity> xnox: Nobody attaches graphical heads on s390x, it seems to be a very common use case to run x clients on s390x though.
[12:18] <infinity> chrisccoulson: You use some system libraries...
[12:19] <infinity> chrisccoulson: System libicu might be a good candidate.
[12:19] <infinity> Though, this should be fixed upstream regardless.
[12:28] <jibel> I cannot start gnome terminal in yakkety and I've this crash bug 1611358, is it known?
[12:37] <Laney> jibel: No, but if you go into dconf-editor and browse to /org/gnome/terminal/legacy/profiles: and look at background-transparency-percent, what are the values?
[12:38] <Laney> I can make it happen if I put a value > 100 in there
[12:39] <jibel> Laney, -89
[12:40] <Laney> Probably fix that to like 10
[12:40] <Laney> no idea how that would happen
[12:41] <jibel> Laney, it works with 10
[12:41] <jibel> and breaks with any value <0
[12:42] <Laney> ok
[12:42] <Laney> I can put some sanity checking in there, but I wonder how that happens
[12:43] <jibel> there are already 3 reports in errors.u.c
[12:43] <Laney> I see that
[12:50] <Laney> jibel: ok, I uploaded something to make it not crash
[12:50] <Laney> thx for reporting
[12:50] <jibel> Laney, thx for fixing
[13:09] <xnox> chrisccoulson, i hate icu
[13:09] <xnox> so the build that firefox does doesn't support byteswapping in the icupkg tool.
[13:09] <xnox> argh
[13:14] <attente> seb128: hey, just following up on the discussion you had with desrt. is the xdg-open whitelist ok? or did you want to do something else?
[13:25] <seb128> attente, I was wondering how much it was discussed to restrict, like where do we draw the line on what is ok and not
[13:26] <seb128> attente, I'm unsure to see what security issue it is but d_esrt convinced me some people think it's desirable to keep it restricted, which is fair enough
[13:26] <seb128> attente, oh and hey btw ;-)
[13:29] <attente> hey to you too :)
[13:30] <attente> yeah, i guess we were trying to play it safe
[13:30] <attente> there wasn't that much discussion, but niemeyer wanted it restricted too iirc
[13:31] <attente> maybe there's some way we can make updating the whitelist less painful though?
[13:33] <attente> is having a dialog asking the user to open a url really that bad design though? it sounds ok to me tbh...
[13:33] <seb128> do you have any clever idea there?
[13:33] <seb128> I don't know
[13:33] <seb128> but do you know who should take the decision if it's ok to add more url types to the whitelist?
[13:34] <seb128> is that gustavo?
[13:35]  * didrocks missed that discussion, got some Internet outage for 10 minutes
[13:35] <attente> yeah, gustavo, but it might be good to ask #security too
[13:35] <didrocks> (or less, but time to go to the cave, see nothing happened, coming back…)
[13:37] <seb128> k
[13:37] <jbicha> desrt: ricotz: any idea on how to fix the gjs autopkgtest? it's blocking gnome-shell 3.20 from yakkety https://bugzilla.gnome.org/769447
[13:37] <seb128> didrocks, you didn't miss much but I copied it in /msg for you
[13:38] <didrocks> thanks seb128!
[13:39] <desrt> jbicha: gjs is not my strong suit, sorry
[13:40] <seb128> yw!
[13:41] <seb128> oh, Laney didn't like my gedit patch ;-)
[13:41] <attente> desrt: hey, don't want to sound sense, but what exactly is the problem with a dialog asking the user what they want to do with the url?
[13:44] <jbicha> desrt: yeah, it's annoying that the tests work fine on my computer… :(
[13:47] <seb128> jbicha, did you try with the lxc thing?
[13:49] <jbicha> I used autopkgtest-buildvm-ubuntu-cloud and autopkgtest -- qemu
[13:51] <jbicha> let's try autopkgtest-build-lxc
[14:17] <desrt> attente: because, if the system is working properly, the user already expressed their intent
[14:18] <desrt> if i select "Help" from the menu, i don't want to see a dialog asking "Are you sure you want to see the help?"
[14:18] <desrt> "Are you sure you want to allow ______?" dialogs are awful.  we need to avoid them as far as it is possible to do so.
[14:19] <desrt> as discussed during the gtk hackfest, the best way to do this is to make the receiving app do something "safe", in response to the incoming request, and that's the nature of what we're debating here
[14:19] <desrt> for opening help, the safe thing is opening help
[14:20] <desrt> for joining a video chat or capturing an image, though, a better example would be to open a "adjust your hair" screen or so, giving the user a chance to either proceed or cancel, before anything actually happens
[14:23] <seb128> desrt, that regex patch fixes the test with .39 (and they still work with .38)
[14:25] <desrt> cool!
[14:26] <desrt> attente: we have to perform an interesting trick... we have to assume that the apps that the user are using are malicious, without revealing to the user that we think this...
[14:27] <qengho> If the next step is obvious and costless and not sensitive to time, just do it and make it easy for the user to back out when they decide.
[14:27] <desrt> from the user's point of view, everything should flow just as well as it did before... if they start being asked "are you sure that this thing that you did is what you really want to do?" then they are going to start feeling that the experience isn't as smooth as it was before
[14:28] <desrt> so we need to find ways to turn "are you sure you want to do that thing you told me to do?" type questions into "...and in what way do you want me to do that for you?" type questions
[14:28] <desrt> (always being careful to put a convenient "no.  i don't want this at all!" button there)
[14:30] <attente> isn't there some assumption that snaps are confined because they could potentially be dangerous?
[14:32] <desrt> from our point of view, of course we have to think about that
[14:32] <desrt> but the user shouldn't have to
[14:33] <desrt> when i click on a link in telegram i don't want to think about the interaction as a potentially dangerous exchange between two mutually-untrusting agents
[14:33] <desrt> i just want the link to open...
[14:34] <desrt> ditto for when i tell meetup that i want to select a new profile picture from my photo album
[14:34] <desrt> "this app might be attacking me" is the farthest thing from my mind at that point, because i just told it, please _take_ this picture
[14:36] <attente> yeah, i see what you mean
[14:45] <jbicha> Laney: could you upload gnome-desktop3 3.20 to yakkety? it was in the gtk320 ppa
[14:46] <seb128> soname change right?
[14:46] <seb128> I was looking at the git yesterday and think there is one?
[14:46] <seb128> in which case we should probably stay away from it until the current transitions are sorted out
[14:47] <Laney> looks like seb128 is on it
[14:47] <Laney> thanks!
[14:47] <Laney> i don't remember if it is or not
[14:47] <seb128> yw!
[14:47] <seb128> I'm going to have a look at e-d-s and some of the others
[14:48] <Laney> looks not actually
[14:49] <seb128> weird
[14:49] <seb128> https://git.gnome.org/browse/gnome-desktop/commit/?h=gnome-3-20&id=0a74cc9a0f1c154d3e776fab4896c76c30a103a7 suggests it should
[14:50] <seb128> or the commit message is confusing
[14:50] <jbicha> hmm
[14:50] <seb128> I guess the soname is 13-1=12
[14:50] <seb128> but I wonder then if it's an abi change and if they screwed the soname change
[14:50] <seb128> https://git.gnome.org/browse/gnome-desktop/commit/?h=gnome-3-20&id=3721282fc6377fa42158ca8a1b2022f6f252b44e
[14:50] <seb128> I guess not
[14:51] <seb128> just added a function so commit message is confusing
[14:53] <Laney> it's the first one minus the last one
[14:53] <Laney> there's some rules about when you increment each one
[14:53] <seb128> right, thanks for confirming
[14:54] <seb128> yeah, most GNOME configure.ac have a snippet that explain it
[14:54] <seb128> like update when something is added
[14:54] <seb128> set back to 0 when...
[14:54] <seb128> etc
[14:54] <seb128> I just didn't read it for sometime and it doesn't stick well to my memory ;-)
[14:54] <Laney> so just copy it out of the ppa if you want
[14:54] <seb128> but I guess he meant to just bump the minor version for an api addition there
[14:58] <Laney> https://autotools.io/libtool/version.html
[14:59] <Laney>  If the interface has changed, then current must be incremented, and revision reset to `0'. This is the first revision of a new interface.
[14:59] <Laney> If the new interface is a superset of the previous interface (that is, if the previous interface has not been broken by the changes in this new release), then age must be incremented. This release is backwards compatible with the previous release.
[15:02] <jbicha> but he did both, 12:0:0 to 13:0:1, anyway, as packaged in Debian, it's still libgnome-desktop-3-12 currently
[15:02] <Laney> that's what that says
[15:02] <Laney> it's current:revision:age
[15:04] <seb128> soname is current-age
[15:04] <Laney> haha
[15:04] <Laney> HAHAHAH
[15:05] <Laney> whoever invented this has a sense of humour
[15:08] <Laney> I'll just end this all and copy the package :-)
[15:08] <Laney> DONE
[15:10] <seb128> thanks
[15:10] <seb128> (sorry in a meeting)
[15:11] <jbicha> Laney: hey, did you see the discussion in #gnome-hackers? do we need gobject-introspection 1.49 to match glib 2.49?
[15:11] <jbicha> or if we don't need glib 2.49, does it make sense to revert to 2.48?
[15:11] <Laney> what is the problem?
[15:13] <jbicha> the autopkgtest for gjs fails, keeping gnome-shell in -proposed https://bugzilla.gnome.org/769447
[15:14] <jbicha> hadess suggested that test was from g-i
[15:18] <Laney> ok, let me look
[15:28]  * willcooke will attempt to be in 2 meetings at the same time....
[15:29] <davmor2> willcooke: 2 pc's 2 mics and a lot of mute unmuteing
[15:31] <seb128> hey :-)
[15:32] <willcooke> #startmeeting Desktop Team Weekly Meeting 2016-08-09
[15:32] <meetingology> Meeting started Tue Aug  9 15:32:06 2016 UTC.  The chair is willcooke. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:32] <meetingology> Available commands: action commands idea info link nick
[15:33] <willcooke> Roll call: andyrock, attente, desrt,  dgadomski, fjkong, happyaron (out), hikiko, laney, qengho, seb128, sweet5hark, themuso (out), tkamppeter, trevinho, robert_ancell (out)
[15:33] <willcooke> think that's correct
[15:33] <seb128> hey!
[15:33] <Trevinho> o/
[15:33] <desrt> greetings
[15:33] <hikiko> hey
[15:33] <hikiko> oops have no bullets
[15:33]  * hikiko prepares them now
[15:34] <willcooke> let's begin
[15:34] <willcooke> #topic andyrock
[15:35] <andyrock> Hey
[15:36] <andyrock> Can i do this later?
[15:36] <andyrock> I've some problems with the connection
[15:36] <willcooke> andyrock, sure
[15:36] <willcooke> #topic attente
[15:37] <willcooke> ohhhh
[15:37] <willcooke> maybe I do too
[15:37] <willcooke> there we go
[15:37] <Laney> that was the bot lagging
[15:37] <attente> lag?
[15:37] <attente> last week, i just finished the apparmor dconf work and emailed the apparmor mailing list. hope there's still time for it to get reviewed and merged this cycle...
[15:37] <attente> continuing work on the gtk-mir backend, did a bit of investigation into getting gnome-software working under u8
[15:37] <attente> (eof)
[15:37] <willcooke> thanks attente
[15:38] <willcooke> nicely done
[15:38] <willcooke> #topic desrt
[15:38] <desrt> - adding support to gvdb for path matches (like /org/gnome/foo/) to efficiently allow marking a range of keys for a particular purpose (such as...)
[15:38] <desrt> - in addition to allowing locks, it is now possible to specify "unlocks" -- a range of keys to which the user is allowed to write, excluding all others not in the list
[15:39] <desrt> - this is all obviously aimed at using the existing dconf file format as the basis for IPC between the system and containerised apps
[15:39] <desrt> - bugs
[15:39] <desrt> eof
[15:39] <willcooke> thanks desrt
[15:39] <willcooke> #topic dgadomski
[15:40] <dgadomski> hey
[15:40] <dgadomski> * trying to make samba to produce some static libs - bug #1584485
[15:40] <dgadomski> * after replacing gtk-launch with desktop-launch darktable snap works
[15:40] <dgadomski> * working on RawTherapee snap - will require patching it to change user settings path
[15:40] <dgadomski> eof
[15:40] <willcooke> cool! thanks dgadomski
[15:40] <willcooke> #topic FJKong
[15:40] <FJKong> hey
[15:40] <FJKong> * sogou IM: building and tesing new release of sogoulib.
[15:40] <FJKong> * bug tracing: candidate words disappear after typing too much.
[15:41] <FJKong> * localization work for phone scope
[15:41] <FJKong> eof
[15:41] <willcooke> thanks FJKong
[15:41] <willcooke> #topic happyaron
[15:41] <willcooke> 1. opencc transition
[15:41] <willcooke> 2. librime update, fix gcc-6 failure, get rid of kyotocabinet dependency
[15:41] <willcooke> 3. introducing fcitx-kkc
[15:41] <willcooke> 4. dropping features from libpyzy, preparing for deprecation
[15:41] <willcooke> 5. new sogoupinyin engine library merge
[15:41] <willcooke> #topic hikiko
[15:41] <hikiko> hi
[15:42] <hikiko> working on removing blend and have faster moving windows
[15:42] <hikiko> - compiz side changes:
[15:42] <hikiko> fixed grid, resize, move plugins to not use blend in low gfx
[15:42] <hikiko> - unity side changes:
[15:42] <hikiko> fixed unity to have the appropriate options and settings, added support for outline and rectangle modes
[15:42] <hikiko> - problems: discovered a bug in window rendering which is seen in outline only mode - working to fix it and on alternative solutions in case I don't find it on time
[15:42] <hikiko> eof
[15:42] <willcooke> thanks hikiko
[15:42] <willcooke> #topic Laney
[15:42] <Laney> oh
[15:42] <Laney> • A lot of fixes, updates and followup fixes for 3.20
[15:42] <Laney> • Unblocked 3.20, which went in - slightly bumpy (firefox is still broken), but not too bad considering
[15:42] <Laney> • Help with various transitions which are stuck in proposed, still ongoing
[15:42] <Laney> • Help with some landings and random stuff related to those, e.g. fixing google-mock in Ubuntu and Debian for Trevinho
[15:43] <Laney> • Review and uploading of a gst-plugins-bad fix for touch guys, including fixing libhybris which broke its build
[15:43] <Laney> • Some signond debugging, since it started popping up a random authentication window
[15:43] <Laney> • Debug ssh agent not being poked into the session properly - it's usually because unity7 is not systemd yet
[15:43] <Laney> • Now looking at gjs for j_bicha, then will help M_irv with his migration, then review some more GTK branches, then look at c_yphermox's ubiquity thing, then hopefully I get to go onto appstream
[15:43] <Laney> • Will be off on Friday
[15:43] <Laney> 🚳
[15:43] <willcooke> thanks Laney :)
[15:43] <willcooke> hope you have a nice day off
[15:43] <Laney> we're going to be in bridlington
[15:43] <Laney> kayaking on the sea
[15:43] <willcooke> oh, sorry to hear that
[15:43] <willcooke> #bants
[15:44] <Laney> eeeeeyyyy lad
[15:44] <jbicha> thanks for pushing GTK 3.20 through
[15:44] <Laney> they have good fish and chips
[15:44] <Laney> and a fudge shop
[15:44] <willcooke> :)
[15:44] <Laney> (which almost makes up for the inhabitants)
[15:44] <willcooke> harsh
[15:44] <Laney> (jokes if you're from there, don't beat me up)
[15:44] <Laney> (JOKES)
[15:44] <willcooke> :)))
[15:44] <willcooke> #topic qengho
[15:44] <qengho> Hi hi!
[15:44] <qengho> * Back in US Eastern time. The best timezone.
[15:44] <qengho> * Finished testing, gave previous Cr security update to #security.
[15:44] <qengho> * New Chromium upstream release. Fixing a crasher in Y and then merging down to P—X.
[15:44] <qengho> * Trying other linking options for libatomic shlibdeps failure in P for the gcc-mozilla toolchain. Still mysterious.
[15:44] <qengho> * Talking to Google about Ubuntu's API keys and some resource limits on geolocation.
[15:44] <qengho> EOF
[15:45] <willcooke> thanks qengho
[15:45] <willcooke> #topic seb128
[15:45] <seb128> • snappy
[15:45] <seb128> ∘ submitted snapd and livecd-rootfs patches for bits missing/bugs in the snappy/xdg-open integration
[15:45] <seb128> ∘ debugged/fixed a bug in snapd with the update-desktop-database registration
[15:45] <seb128> ∘ several discussion about url handlers&security impact (trying to add more handlers for e.g help urls)
[15:45] <seb128> • some archive admin work (NEW reviews, deleted some binaries for transitions)
[15:45] <seb128> • sponsoring (n-m SRU for Aron)
[15:45] <seb128> • tested a glib test fix from desrt
[15:45] <seb128> • debugged gvfsd-smb eating cpu issues and backported a samba fix that should help with those
[15:45] <seb128> • samba was ftbfsing in yakkety, had to fix that on the way (was due to a buggy ldb merge)
[15:45] <seb128> • debugged/fixed vino/upnp eating cpu
[15:45] <seb128> • backported an eog upstream fix for reloading files on disk changes (+SRU)
[15:45] <seb128> • some bugs triaging/upstreamed a few ones
[15:45] <seb128> • installed yakkety in a vm from a daily and played a bit with it, tested new gtk, looks good, great work Laney (&team)!

[15:45] <willcooke> thanks seb128 :)
[15:45] <qengho> EOG?
[15:45] <qengho> Still around?
[15:46] <seb128> sure!
[15:46] <seb128> don't tell me you open images in chromium ;-)
[15:46] <qengho> I don't use chromium!
[15:46] <seb128> lol
[15:47] <Laney> qengho just opens things in a hex editor
[15:47] <willcooke> #topic Sweet5hark1
[15:47] <qengho> Only XPMs
[15:47] <Laney> pfft, entry level
[15:47] <Sweet5hark1> - libreoffice 5.2.0 upstream release
[15:47] <Sweet5hark1> - libreoffice 5.2.0 snap release
[15:47] <Sweet5hark1> - libreoffice 5.2 testbuild on arm
[15:47] <Sweet5hark1> - CVE-2016-1513: tldr: AOO published an advisory about an issue, claiming LibreOiffice isnt affected, while in fact old versions were. they also denied sharing the PoC code, so we had to ask the researchers directly.
[15:47] <Sweet5hark1> -- As a bonus they have only published a source patch and still publish vulnerable binaries. we are good since thursday, which was the ad-hoc disclosure date added for LibreOffice after the fact
[15:47] <Sweet5hark1> - libreoffice/gtk3 and theming foo. first played with LibreOffice master against gtk 3.19, but then found both the LibreOffice 5.2 branch and the 3.20 stuff to be quite different ...
[15:47] <Sweet5hark1> - so did a local build of libreoffice 5.2 against 3.20 on a yakkety VM ... which failed because linking libmerged OOMed
[15:47] <Sweet5hark1> - some upstream triage, review and bugfixing
[15:47] <Sweet5hark1> EOF
[15:47] <willcooke> thanks Sweet5hark1
[15:47] <Sweet5hark1> (oh also: AOO apparently was informed 6 months ago)
[15:47] <willcooke> #topic TheMuso
[15:48] <willcooke> * Attempted to reproduce issues in bug #1574324 with no success, requested some info from those who experience it.
[15:48] <willcooke> * In working on the above, I did find that my own bluetooth headset can't be used with the A2DP profile in xenial, but works in yakkety. Think the issue is in bluez, going to spend some time trying to track down the needed patches and see about pushing the fix in an SRU.
[15:48] <willcooke> * Merged and uploaded alsa-utils 1.1.2 to yakkety.
[15:48] <willcooke> #topic tkamppeter
[15:48] <tkamppeter> - Ghostscript: Investigating tray selection bug in PCL-XL driver.
[15:48] <tkamppeter> - cups-filters: More modifications for snappification.
[15:48] <tkamppeter> - Google Summer of Code 2016: Guide students through their projects
[15:48] <tkamppeter> - Bugs
[15:48] <willcooke> thanks tkamppeter
[15:48] <willcooke> #topic Trevinho
[15:49] <Trevinho> · Fixed maximize button for partially maximized windows
[15:49] <Trevinho> · Fixed some unity8 branches
[15:49] <Trevinho> · Adapted CSS selectors in force-quit dialog windows for gtk 3.20
[15:49] <Trevinho> · Fixed google-mock causing test crashes in yakkety with gcc-6
[15:49] <Trevinho> · Fixed a libframe crash
[15:49] <Trevinho>  /eof
[15:49] <willcooke> thanks Trevinho
[15:49] <willcooke> #topic aob
[15:50] <willcooke> No update from Robert, but he's full time on libsnapd
[15:50] <willcooke> I'm going to London again tomorrow
[15:50] <willcooke> so FJKong will reschedule our 1:1
[15:50] <willcooke> and hikiko, I think we're in sync already
[15:50] <seb128> just a note that feature freeze is coming
[15:50] <FJKong> willcooke: no p
[15:51] <willcooke> Anyone got anything else for the meeting?
[15:51] <seb128> and things are going to get a bit crazy
[15:51] <hikiko> yes willcooke, thanks!
[15:51] <seb128> we might need to MIR a stack of packages for getting u8 session in the iso
[15:51] <seb128> would be nice to dispatch some of the workload
[15:52] <willcooke> +1
[15:52] <seb128> so please keep some cycles in your planning for that
[15:53] <seb128> though I don't think there is much we can descope
[15:53] <seb128> like we landed transitions&updates in proposed/yakkety
[15:53] <seb128> so we need to sort the whole out now
[15:53] <seb128> anyway was just a pre-ff warning
[15:53] <seb128> thanks ;-)
[15:54] <willcooke> thanks seb128
[15:54] <willcooke> so lets wrap, thanks all
[15:54] <willcooke> #endmeeting
[15:54] <meetingology> Meeting ended Tue Aug  9 15:54:26 2016 UTC.
[15:54] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2016/ubuntu-desktop.2016-08-09-15.32.moin.txt
[15:54] <andyrock> and me? :O
[15:54] <seb128> andyrock, I though you were on holidays? ;-)
[15:55] <seb128> or was that a Trevinho's joke?
[15:55] <andyrock> just not at my place
[15:55] <andyrock> :D
[15:55] <andyrock> you know part-time thing
[15:55] <seb128> yeah, was just joking
[15:55] <Sweet5hark1> seb128: as for ff, can we dump in libreoffice as is  then so we dont need a ffe. will see about the theming -- im sure its solvable, but the longer we postpone LO, the more likely it is that something else will break it in interesting ways again.
[15:55] <seb128> andyrock, I guess post your update
[15:56] <seb128> Sweet5hark1, yeah, check with Laney though, we don't want to end up with having to fix libreoffice build to unblock some of the current transitions
[15:57] <Sweet5hark1> seb128, Laney: I build libreoffice against -proposed on ~all arches last Friday, so that should be reasonably well.
[15:58] <seb128> good
[15:58] <seb128> let's land it this week then
[16:00] <seb128> andyrock, your weekly update!? ;-)
[16:13] <Trevinho> seb128: about that unity8 autopkg tests making unity not being moved to release pocket... Can we do something?
[16:13] <seb128> Trevinho, try to see if Saviq can help
[16:13] <seb128> those buggy test are annoying :-/
[16:13] <Trevinho> i've been told they've been fixed upstream, things were in a silo
[16:13] <Trevinho> which... Mirv told me it was about to be released
[16:14] <Laney> do it
[16:16] <xnox> chrisccoulson, https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+build/10588750 https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+build/10588752
[16:16]  * xnox crosses fingers
[16:19] <seb128> Laney, thanks
[16:20] <seb128> Trevinho, if the test is known to be flaky can you ask them to just force land anyway?
[16:20] <Trevinho> seb128: "them", who? :)
[16:20] <seb128> trainguards
[16:21] <sil2100> What's up?
[16:21] <Trevinho> seb128: ah, well... on that side is published
[16:21] <seb128> well is it not published?
[16:21] <seb128> where
[16:21] <Trevinho> seb128: it's in proposed, not in release because of that
[16:21] <seb128> oh
[16:21] <seb128> then from a SRU perspective it landed
[16:22] <seb128> they don't require you to have migration done
[16:22] <seb128> they just don't want to not be forgotten
[16:22] <Trevinho> ok
[16:22] <Saviq> seb128, Trevinho, where can I help?
[16:22] <seb128> Saviq, can you make the unity8 tests unflacky? -;)
[16:22] <seb128> ;-)
[16:22] <seb128> -c
[16:22] <Saviq> I can try and make them unflaky :P
[16:23] <seb128> thanks!
[16:23] <seb128> would make Trevinho happy
[16:23] <tedg> Trevinho: I think you need to be a core-dev to kick stuff on proposed: http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#unity
[16:23] <seb128> you want happy italians, they provide you with good beer and pizza then
[16:23] <Saviq> need to start collecting stats on what're the most offending ones
[16:23] <Trevinho> :)
[16:24] <Trevinho> I can be happy anyway... Actually we should probably just make an unity-schema file which we both depends on, instead of having shared schemas in our codebase
[16:24] <tedg> Though, it seems the unity8 tests on armhf aren't flaky, they're Always Failed :-)
[16:24] <Trevinho> so... no more this autopkg tests
[16:25] <seb128> right
[16:27] <Trevinho> or, maybe just moving them to gsettings-ubuntu-schemas ?
[16:27] <Trevinho> Saviq, seb128: what you think ?
[16:28] <seb128> I wouldn't add a new source for those
[16:28] <seb128> seems most work that it's worth
[16:28] <Trevinho> gsettings-ubuntu-schemas is already there
[16:35] <seb128> Trevinho, right, I was saying I wouldn't add a new unity-schema
[16:36] <Trevinho> seb128: yeah, I do agree...
[16:37] <seb128> bah, gnome-software doesn't list vlc in my yakkety vm :/
[16:38]  * seb128 goes to a command line
[16:39] <seb128> it's listed by appstream-cli
[16:40] <seb128> but I never remember what that means :-/
[16:54] <Laney> http://appstream.ubuntu.com/yakkety/universe/issues/vlc.html <- it's not available on yakkety
[17:00] <Laney> got to go to the allotment
[17:00] <Laney> laters
[17:01] <seb128> have fun Laney!
[17:46] <willcooke> night all
[21:31] <ochosi> jbicha: in case you can help with the gresource stuff (breaks assets in greybird) that'd be great. if not that's ok too, i'll read up on it
[21:32] <jbicha> hmm? is there a bug? did you install the gresource files?
[21:34] <ochosi> yeah i did. seems like checks and radios don't show up anymore (the assets aren't loaded/found)
[21:35] <jbicha> ok I saw that bug, is there a common app that you found that could reproduce that bug?
[21:35] <ochosi> sure, any app practically :)
[21:35] <ochosi> try system-config-printer