[02:46] <jbicha> attente: gtk3 can't build on s390x because content-hub isn't built there
[03:50] <attente> jbicha: is there a way around that? i'm not sure what content-hub depends on that prevents it from building on s390x
[03:54] <duflu> I assume that means GTK3 still works on non-Unity shells without a content-hub...?
[06:02] <hikiko> hi
[06:06] <duflu> hi hi hikiko
[06:09] <hikiko> hi duflu :-)
[08:20] <flexiondotorg> Morning duflu hikiko
[08:21] <duflu> Morning flexiondotorg
[08:21] <hikiko> morning all
[08:30] <desrt> hello!
[08:30] <desrt> happy thursday hikiko, seb128, flexiondotorg, duflu !
[08:31] <flexiondotorg> Morning desrt and seb128
[08:31] <duflu> Hey desrt
[08:31] <hikiko> I read happy birthday
[08:31] <desrt> hikiko: oh.  it is?  happy birthday!!
[08:31] <hikiko> no hahaha
[08:31] <desrt> (sorry.  i read "it's my birthday")
[08:31] <flexiondotorg> Trevinho you'll be please to hear your remmina snap works great of Debian 9 too :-)
[08:31] <desrt> =)
[08:31] <hikiko> :p
[08:32] <hikiko> is it?
[08:32] <desrt> is it your birthday?
[08:32] <desrt> well, i mean, obviously... yes...
[08:42] <hikiko> no my birthday is in august desrt :
[08:42] <hikiko> :)
[08:57] <Trevinho> desrt: Yeah, great!
[08:58] <Trevinho> flexiondotorg: that was for you... ^ :-)
[08:58] <Trevinho> But even the BD misunderstanding is nice 😂
[08:59] <flexiondotorg> :-)
[09:01] <flexiondotorg> Trevinho I think libpulse0 needs adding to the remmina snap.
[09:01] <Laney> ahoy
[09:01] <flexiondotorg> Laney o/
[09:04] <willcooke> morning all
[09:05] <willcooke> slightly change of plan, meeting got push back a bit - so will be leaving in an hour or so
[09:05] <willcooke> (for London)
[09:06] <Trevinho> flexiondotorg: oh...let me check that
[09:08] <davmor2> Morning all
[09:09] <willcooke> hi davmor2
[09:10] <seb128> hey desrt flexiondotorg hikiko Trevinho Laney davmor2
[09:10] <desrt> ...the ever-growing chain
[09:11] <hikiko> hi *
[09:11] <desrt> omg its like willcooke Laney Trevinho all here!
[09:11] <willcooke> \o\ /o/
[09:11] <desrt> hai guyz!!
[09:11] <hikiko> the hour of the hi-light :p
[09:12] <flexiondotorg> Morning seb128 davmor2 willcooke
[09:12] <seb128> Trevinho, well done on driving that reminna snap work!
[09:14] <Laney> omgzzzz
[09:16] <seb128> Laney, ?
[09:31] <Laney> just excited to be virtually with you guys
[09:38] <seb128> Laney, :-)
[09:43] <davmor2> Laney: you just realised it is Thursday really didn't you
[09:47] <seb128> not quite friday yet
[09:48] <davmor2> seb128: yeah so imagine how excited he'll be then :)
[09:49] <seb128> davmor2, "not" you mean? no Ubuntu for some days is not something a true opensource beliver like him is enjoying!
[09:50] <Laney> YEAHHHHHHHHHHHHHHH
[09:50] <Laney> FIXING BUGS!
[09:50] <seb128> see :-)
[09:51] <didrocks> (and creating more)
[09:51] <didrocks> (hey guys! ;))
[09:52] <seb128> hey didrocks :-)
[09:54] <Laney> hey didrocks
[09:54] <Laney> how are you?
[09:54] <didrocks> Laney: I'm good (and tired) but good, thanks! :)
[09:54] <didrocks> yourself?
[09:55] <Laney> feeling fineeeeeeeeeee
[09:55] <Laney> we had a pizza night last night
[09:55] <Laney> so also feeling fat
[09:55] <didrocks> time for climbing today!
[09:55] <didrocks> to eliminate this :p
[09:55] <Laney> correct
[10:07] <Trevinho> seb128: thanks... Snap was easy, CI integration took longer unfortunately, but... It was nice to learn
[10:08] <Trevinho> seb128: as for the gnome-runtime, I've given a look... But I've to check it further...
[10:10] <seb128> Trevinho, k, let me know if you have any comment and how it works for you
[10:15] <willcooke> Off to the train station.  bbl
[10:16] <Trevinho> flexiondotorg: so.... freerdp has libpulse-dev dep, so libpulse seems to be takena utomatically, isn't it?
[10:17] <flexiondotorg> Doesn't look like. Start remmina interactive, you'll see it complains libpulse0 is missing.
[10:17] <flexiondotorg> Add stage-packages:
[10:17] <flexiondotorg> And put:
[10:17] <flexiondotorg>  - libpulse0
[10:17] <flexiondotorg> In there.
[10:17] <Trevinho> unsquashfs -l remmina_1.2.0-rcgit.17_amd64.snap |grep pulse gives me things... mhmhm
[11:24] <Trevinho> flexiondotorg: same is for fresh installed things here..
[11:24] <Trevinho> marco@ubuntu-vmware:~:0$ find /snap/remmina|grep pulse
[11:24] <Trevinho> /snap/remmina/65/usr/lib/freerdp2/libaudin-client-pulse.so
[11:24] <Trevinho> /snap/remmina/65/usr/lib/freerdp2/librdpsnd-client-pulse.so
[11:24] <Trevinho> /snap/remmina/65/usr/lib/freerdp2/libtsmf-client-pulse-audio.so
[11:24] <Trevinho> /snap/remmina/65/usr/lib/x86_64-linux-gnu/libpulse-mainloop-glib.so.0
[11:24] <Trevinho> /snap/remmina/65/usr/lib/x86_64-linux-gnu/libpulse.so.0
[11:24] <Trevinho> /snap/remmina/65/usr/lib/x86_64-linux-gnu/pulseaudio
[11:24] <Trevinho> /snap/remmina/65/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-8.0.so
[11:25] <flexiondotorg> http://paste.ubuntu.com/23960176/
[11:25] <flexiondotorg> Where is your yaml?
[11:26] <flexiondotorg> I had a similar issue with pulse.
[11:26] <flexiondotorg> I also had to stage libpulse-mainloop-glib0 to overcome it.
[11:28] <Trevinho> Ahhhhhhhhhh
[11:28] <Trevinho> flexiondotorg: it's not about that then
[11:29] <Trevinho> in the past LD_LIBRARY_PATH was including $SNAP/usr/lib/x86_64-linux-gnu/pulseaudio/ too
[11:29] <Trevinho> when adding pulseaudio
[11:29] <Trevinho> it semes it's not the case anymore?
[11:30] <Trevinho> flexiondotorg: I think it's a job for desktop-launcher then
[11:30] <Trevinho> flexiondotorg: I mean, this was done in /snap/remmina/current/command-remmina.wrapper ...
[11:30] <Trevinho> not sure when it changed
[11:31] <flexiondotorg> https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports#L36
[11:31] <flexiondotorg> Seems to still be there.
[11:36] <Trevinho> Mh, so I don't see why it should give that
[11:37] <Trevinho> flexiondotorg: I don't have that issue though here
[11:40] <Trevinho> oh, in the edge there's not the spice plugin... mhmh
[11:41] <flexiondotorg> Not sure where RUNTIME is being set when not using the GNOME318 platform snap.
[11:41] <flexiondotorg> I'll take a proper look later.
[11:43] <GunnarHj> Hi seb128, any progress with the language packs, or shall we postpone it yet another week?
[11:44] <Trevinho> flexiondotorg: it's something weird though...
[11:44] <Trevinho> if you go into the --shell mode
[11:44] <Trevinho> and
[11:44] <Trevinho> env LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$SNAP/lib:$SNAP/usr/lib:$SNAP/lib/x86_64-linux-gnu:$SNAP/usr/lib/x86_64-linux-gnu" $SNAP/bin/desktop-launch ldd /snap/remmina/current/usr/lib/remmina/plugins/remmina-plugin-spice.so | grep not
[11:45] <Trevinho> you see that it's not loaded...
[11:45] <Trevinho> which... is weird
[12:04] <Trevinho> flexiondotorg: as you can see in
[12:04] <Trevinho> env LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$SNAP/lib:$SNAP/usr/lib:$SNAP/lib/x86_64-linux-gnu:$SNAP/usr/lib/x86_64-linux-gnu" $SNAP/bin/desktop-launch env|grep LD_LIBRARY_PATH | sed 's/:/\n/g'
[12:04] <Trevinho> pulseaudio subpath isn't there
[12:05] <Trevinho> ah... easy :o
[12:05] <Trevinho> grep pulse $SNAP/bin/desktop-launch
[12:05] <Trevinho> ##export LD_LIBRARY_PATH=$SNAP/usr/lib/$ARCH/pulseaudio:$LD_LIBRARY_PATH
[12:05] <Trevinho> who commented that...
[12:14] <didrocks> I was waited for a PR for ages to reenable it, after not seeing any move on it from the contributor, I did fix it this morning
[12:15] <didrocks> Trevinho: I'm still sad that pulseaudio (libunity as well apparently) can't find its private lib directory based on LD_LIBRARY_PATH and use either ld loader or a hardcoded one
[12:15] <scip> Hi all, I’m basically facing this issue http://askubuntu.com/questions/17381/unity-doesnt-load-no-launcher-no-dash-appears but the fixes aren’t working for me and ccsm isn’t persisting settings when I close it
[12:15] <ogra_> by whom were you waited ? :)
[12:15] <scip> I’m willing to reinstall some things if it helps, but was wondering if anyone had guidance? This happened after running “apt-get upgrade”. I have an nvidia card
[12:16] <didrocks> ogra_: https://github.com/ubuntu/snapcraft-desktop-helpers/pull/25
[12:16] <didrocks> ogra_: see the incorrect fix, only Qt-based
[12:16]  * ogra_ was just joking about the typo :)
[12:20] <didrocks> Trevinho: I'm surprised that even with that not exported, most of the apps I tried were using pulseaudio with success
[12:20] <didrocks> so, I really think there is something we don't understand well
[12:21] <ogra_> didrocks, note that there is a massive difference between pulse in xenial and newer ...
[12:21] <ogra_> afaik there are some not fully compatible changes between pulse 8 and 9
[12:21] <ogra_> so it might behave different on a zeyst install than it does on xenial
[12:22] <ogra_> **zesty
[12:22] <ogra_> (since your snap will have the xenial libpulse0 but the desktop you run on has the newer pulse running)
[12:27] <didrocks> ogra_: could be, but the issue here is in finding the lib it seems
[12:35] <seb128> GunnarHj, sorry it's a bit more work that I though, need to create new keys and get them rolled out on infra, I'm still aiming at getting that done this week but it probably means testing is better done next week
[12:38] <flexiondotorg> didrocks I noticed that pulseaudio work when the snap was built with just 'snapcraft'.
[12:38] <flexiondotorg> But if built with 'snapcraft cleanbuild', pulse didn't work.
[12:38] <flexiondotorg> Thanks for the fix this morning :-)
[12:39] <GunnarHj> seb128: Ok. Have been thinking... (happens once in a while) Considering that translations are not enabled yet for zesty, doesn't that mean that we will miss newly translated strings identical with strings in xenial? And if that's the case, should we possible wait with this xenial update until after the 17.04 release?
[12:43] <willcooke> Laney, thanks for that fix on #1630156  - could it be SRU'd to X?
[12:43] <Laney> if it's reviewed and if it reproduces there
[12:43] <Laney> seb128 said he couldn't make it happen there, but I only tried on zesty
[12:44] <seb128> I'm following the steps in the description
[12:44] <willcooke> I've got a fresh X here, I will test now.
[12:44] <willcooke> I guess SRU -> T as well if we can
[12:44] <seb128> but I do "set a password" the user gets removing from the group
[12:44] <seb128> removed
[12:44] <seb128> dunno what I'm doing wrong/differently
[12:46] <Laney> there is a path where it goes through AS for that
[12:46] <Laney> maybe you manage to hit that one
[12:47] <seb128> in which case does it goes through AS and not?
[12:47] <seb128> we need to know for the testcasae
[12:48] <didrocks> flexiondotorg: yw! That's interesting, I wonder though how exporting would help this, but we'll see
[12:48] <Laney> ...
[12:48] <Laney> I'm just trying to guess
[12:48] <Laney> I'll update the bug to be SRU compliant ...
[13:01] <Laney> done
[13:04] <willcooke> Laney, seb128 - just tested on a fresh 16.04 and I can recreate the bug
[13:04] <willcooke> laaaaaaaaaag
[13:04] <Laney> phat
[13:05] <Laney> i think upstream gnome has removed that option fyi
[13:05] <seb128> willcooke, Laney, looks like my user is behaving differently, wonder if that's ecryptfs or some special config since that box is upgraded through since trusty or something
[13:06] <seb128> I get it with a test user now...
[13:06] <Laney> weird
[13:06] <Laney> put a g_debug in the place that the MP touches and see if you get the passwd_... path or the other one
[13:06] <seb128> yeah, going to do that in a bit
[13:07] <Laney> winning
[13:07] <Trevinho> didrocks: mhmh, yeah I noticed you just fixed that :-)
[13:07] <Trevinho> didrocks: not sure what's going on... In theory they should use rpath in that case
[13:07] <didrocks> Trevinho: not really fixed to me until we understand
[13:07] <didrocks> which we don't
[13:08] <Trevinho> didrocks: well... workarounded :-)
[13:08] <didrocks> yep :)
[13:08] <didrocks> but I don't like it, everytime we do that it's going to strike us back 1000x
[13:12] <Laney> didrocks the hackmaster
[13:17] <didrocks> funny snapcraft bug btw: bug #1663233
[13:20] <Laney> omg
[13:20] <Laney> just accidentally looked under my space bar
[13:20] <Laney> gruesome
[14:27] <attente> jbicha: hey, is it possible to use a depends for libgtk-3-dev like libcontent-hub-glib-dev [!s390x]
[14:35] <jbicha> attente: yes but that would mean s390x no longer supports mir and based on the discussion on #ubuntu-devel almost 3 hr ago, I don't think they would rather fix ubuntu-app-launch to build on s390x instead
[14:36] <jbicha> *I think they would rather
[14:37] <xnox> jbicha, ideally we want ubuntu-app-launch not depend on src:upstart in zesty, correct. (and thus it will build on s390x)
[14:37] <xnox> jbicha, it is also true that I do not believe mir is there on s390x.
[14:37] <attente> jbicha, xnox: is that the only reason content-hub isn't built for s390x?
[14:37] <xnox> jbicha, but we do need src:gtk-3 on s390x, because a lot of things build-depend on gtk-3 whilst building useful commandline packages too.
[14:38] <xnox> attente, correct - the reason content-hub is not build on s390x is due to src:ubuntu-app-launch hard build-dep on src:upstart in zesty.
[14:38] <xnox> which should not be required anymore, as ubuntu-app-launch can support systemd these days.
[14:46] <attente> so is there something i can do to help other than wait for u-a-l s390x support?
[14:49] <xnox> attente, you can look into u-a-l code and change CMakeLists to be conditional on src:upstart, rather than hard.
[14:50] <xnox> attente, e.g. remove upstart runtime and build-time dependencies, and make sure that it still builds and runs.
[14:50] <xnox> you may need to skip parts of the code with ifdef and some tests.
[14:50] <xnox> if you do this. tedg_ & infinity will be really really happy =)
[14:51] <Trevinho> seb128: it's not clear to me how to import the desktop launcher for desktop...
[14:51] <Trevinho> i see that a gnome part is defined, but not added to the wiki... am I wrong?
[15:01] <seb128> Trevinho, good point, I didn't check since it was merged but we didn't get much feedback yet so maybe it would be good to get before adding it to the official list?
[15:01] <seb128> Trevinho, something like that should work http://paste.ubuntu.com/23960946/
[15:01] <Trevinho> I've added the thing, let me see if it works
[15:01] <Trevinho> not that one though
[15:01] <seb128> Trevinho, you just don't get the automagic remote part but defining the part yourself should be the same
[15:01] <seb128> which one?
[15:01] <Trevinho> seb128: however, the parte should be renamed in desktop-gnome to be coherent with others
[15:02] <Trevinho> and documentation
[15:02] <seb128> renamed to what?
[15:02] <Trevinho> seb128: the part in desktop helpers
[15:02] <Trevinho> seb128: I've added it now... it's there
[15:02] <Trevinho> https://parts.snapcraft.io/v1/parts.yaml
[15:03] <seb128> Trevinho, you added before testing if it works? ;-)
[15:03] <Trevinho> seb128: it's not breaking anything in case
[15:03] <Trevinho> seb128: but change is https://wiki.ubuntu.com/snapcraft/parts?action=diff&rev2=87&rev1=86
[15:03] <tjaalton> Trevinho: hi, are you interested in a compiz/libunityshell crasher when using mesa with libglvnd?-)
[15:03] <Trevinho> tjaalton: not much right now 😂
[15:03] <tjaalton> hehe
[15:03] <Trevinho> tjaalton: but... Well, sure I am
[15:03] <seb128> Trevinho, I'm not sure why you want to rename, you don't like desktop-gnome?
[15:04] <Trevinho> seb128: it's called gnome right now
[15:04] <Trevinho> not desktop-gnome
[15:04] <tjaalton> Trevinho: I'll file a bug, it's not that urgent
[15:04] <seb128> Trevinho, where?
[15:04] <Trevinho> seb128: in desktop helpers
[15:04] <Trevinho> seb128: https://github.com/ubuntu/snapcraft-desktop-helpers/pull/46 this fixes that
[15:04] <Trevinho> didrocks: ^ ?
[15:05] <seb128> Trevinho, why do we need it twice?
[15:05] <didrocks> Trevinho: isn't there already one?
[15:05] <didrocks> https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/snapcraft.yaml#L85
[15:06] <Trevinho> didrocks, seb128: there's no desktop-gnome in there.. There's just gnome
[15:06] <seb128> Trevinho, which you don't like?
[15:06] <Trevinho> 'gnome' only...
[15:06] <Trevinho> the docs says use
[15:06] <seb128> there is also a 'gtk3' in there
[15:06] <Trevinho> desktop-<platform>
[15:06] <Trevinho> which isn't true for that
[15:06] <Trevinho> also gtk3 isn't exported either as remote part
[15:07] <didrocks> gtk3 is internal for snapcraft to work
[15:07] <Trevinho> so right now if you do snapcraft search you only find "gnome" because I've just added it to the wiki
[15:07] <Trevinho> butt......
[15:07] <didrocks> it's desktop-gtk3
[15:07] <didrocks> if you want to have all libs
[15:07] <didrocks> and "gnome"
[15:07] <didrocks> if you want to use the runtime
[15:07] <didrocks> correct?
[15:08] <Trevinho> ok, ok... so imho we should instead have in public "desktop-gnome", in wiki, but no "gnome" in the uaml
[15:08] <Trevinho> yaml*
[15:08] <didrocks> ah
[15:08] <didrocks> this
[15:08] <didrocks> yeah, I tend to agree
[15:08] <seb128> I don't understand why there is a gtk3 and desktop-gtk3
[15:08] <seb128> in fact I overlooked that when I added the gnome one
[15:08] <didrocks> seb128: you should thank snapcraft :p
[15:08] <seb128> I started from the top and didn't notice the desktop-gtk3 at the bottom
[15:08] <didrocks> it's the whole desktop/part_name
[15:08] <didrocks> transition
[15:08] <seb128> I though that those were subparts
[15:09] <didrocks> when they removed afterwards the / in part
[15:09] <seb128> the / -> -
[15:09] <Trevinho> in theory we shoud use "after:" for the renaming... it should works now
[15:09] <seb128> right?
[15:09] <didrocks> yes
[15:09] <didrocks> they needed both or the importer was segfaulting
[15:09] <didrocks> (nice)
[15:09] <seb128> but yeah, I've no strong opinion on "gnome" or "desktop-gnome"
[15:09] <didrocks> hum
[15:10] <didrocks> isn't that case confusing that desktop-gtk3 is "all libs embeeded"
[15:10] <didrocks> and desktop-gnome use the gnome platform?
[15:10] <didrocks> Trevinho: I would rather just transition, that's why I gave so much time for it
[15:11] <didrocks> (or those renaming magic should have been internal to snapcraft, not having to patch all parts)
[15:11] <didrocks> copying the same logic 3 times :(
[15:11] <didrocks> desktop-gtk3 vs desktop-gnome, not confusing to you? If so, I'm happy to merge
[15:11] <Trevinho> didrocks: I think that having
[15:11] <Trevinho> partname oldname:
[15:11] <Trevinho>  after: [goodone]
[15:11] <Trevinho> should work
[15:11] <Trevinho> or... maybe it was something I wanted to do and I didn't finish? :o
[15:12] <didrocks> Trevinho: well, it's going to be removed, so knowing the fragility of the parser, I wouldn't give it a shot :)
[15:12] <seb128> should be easy to try
[15:12] <Trevinho> didrocks: maybe desktop-gnome-runtime?
[15:12] <didrocks> yeah, that's more clear to me
[15:12] <didrocks> dekstop-gnome-runtime
[15:12] <didrocks> seb128: wdyt?
[15:12] <Trevinho> or desktop-gnomeruntime
[15:12] <Trevinho> no bettr with dash..
[15:12]  * didrocks likes the - version more
[15:12] <seb128> with the "-"
[15:12] <Trevinho> versioning has to be included there?
[15:12] <didrocks> \o/
[15:12] <seb128> but it's slightly inconsistent
[15:12] <didrocks> no
[15:12] <seb128> which is annoying
[15:13] <didrocks> always pull latest
[15:13] <didrocks> with Qt?
[15:13] <seb128> yes
[15:13] <didrocks> desktop-ubuntu-app-platform:
[15:13] <didrocks> yeah
[15:13] <didrocks> platform vs runtime
[15:13] <seb128> :-/
[15:13] <didrocks> well, you didn't all agree on the dir name to mount on already :p
[15:14] <seb128> which might be good
[15:14] <seb128> if one day it's possible to mount several contents
[15:14] <seb128> they don't conflict
[15:14] <didrocks> yeah, if I already get an answer to my email one day :)
[15:15] <Trevinho> so... just give me the preferred remote part name and I'm updating the branch :-)
[15:15] <Trevinho> I'm fine with both ways... but platform can be more consistent with qt imho
[15:15] <didrocks> shouldn't we at least all use "platform"?
[15:15] <didrocks> yeah
[15:15] <didrocks> I would go with desktop-gnome-platform for the part name
[15:15] <didrocks> seb128: agreed? ^
[15:16] <Trevinho> desktop-ubuntu-desktop-app-platform
[15:16] <Trevinho> or ubuntu-classic ?
[15:16] <Trevinho> or ...
[15:16] <seb128> didrocks, I though you were the one that recommended using "runtime" before holidays when we discussed that
[15:16]  * seb128 forgot the details
[15:16] <seb128> Trevinho, that's too long
[15:16] <seb128> imho
[15:16] <Trevinho> agreedo, but we also have desktop-ubuntu-app-platform
[15:16] <Trevinho> for touch apps
[15:16] <seb128> which is too long :p
[15:16] <Trevinho> sure... but consistency...
[15:16] <didrocks> seb128: I thought that was the other way around, but yeah, I was twisted in my brain due to circumstances :)
[15:17] <didrocks> desktop-gnome-platform sounds good to app
[15:17] <didrocks> me*
[15:17] <seb128> wfm
[15:17] <seb128> I don't like the longer variants
[15:17] <Trevinho> Ok, me neither... it was just to make easier to understand
[15:18] <seb128> gnome-platform is easy enough imho
[15:18] <didrocks> without desktop- ?
[15:18] <didrocks> or you meant desktop-gnome-platform?
[15:18] <seb128> desktop-gnome-platform
[15:18] <didrocks> ok :)
[15:18] <didrocks> yeah, let's go with that
[15:18] <seb128> sorry
[15:18] <seb128> +1
[15:19] <didrocks> should we change all runtime by platform?
[15:19] <didrocks> content: gnome318-runtime -> content: gnome318-platform?
[15:19] <seb128> what do you mean "all"?
[15:19] <didrocks> and so on?
[15:19] <didrocks> (meaning, it needs a new platform snap upload)
[15:19] <didrocks> Trevinho: there is the help on top that needs to be updated :)
[15:19] <seb128> it's also going to break existing snaps that use it?
[15:20] <didrocks> are there any?
[15:20] <didrocks> uploaded to the store?
[15:20] <seb128> no idea
[15:20] <seb128> how do one query the store asking for that?
[15:20] <didrocks> philosophical questions I see :)
[15:20] <seb128> :-)
[15:20] <didrocks> we can be backward compatible
[15:20] <didrocks> having 2 slots
[15:21] <didrocks> one being gnome318-runtime and the other gnome318-platform
[15:21] <didrocks> with the same definition, and just different content name
[15:21] <didrocks> I'm happy to do it if you want
[15:21] <didrocks> (as I really think the naming was my mistake)
[15:21] <seb128> if you want please do
[15:21] <seb128> otherwise I can have a look tomorrow
[15:22] <didrocks> do you have the source handy?
[15:22] <seb128> I'm in middle of other things and we have a friend coming tonight for diner
[15:22] <didrocks> and you upload to a snap ppa?
[15:22] <didrocks> well, we can tackle this tomorrow
[15:22] <seb128> no ppa
[15:22] <didrocks> oh, so not all-arch?
[15:22] <seb128> ?
[15:22] <didrocks> you don't have non amd64 snaps?
[15:22] <seb128> I do
[15:22] <didrocks> or did you build them yourself and upload to the store?
[15:22] <seb128> it's built from a vcs on launchpad
[15:22] <didrocks> ok
[15:23] <didrocks> that's what I meant by "snap ppa"
[15:23] <seb128> i386/amd64/armhf
[15:23] <didrocks> ok :)
[15:23] <seb128> ah
[15:23] <didrocks> let's do the platform one tomorrow morning
[15:23] <didrocks> Trevinho: mind preparing the PR?
[15:23] <seb128> good friday thing
[15:23] <didrocks> Trevinho: change the help, replace all runtime by platform
[15:23] <didrocks> yeah :)
[15:23] <didrocks> Trevinho: also, on top of help, you have "gnome is similar to…", replace the naming as well (and runtime name usage)
[15:24] <Trevinho> didrocks: sure, it was already in the works :-)
[15:26] <didrocks> \o/
[15:44] <b4n> andyrock: any news on the a11y shortcus wrt. grabs?  anything I can do?
[15:45] <b4n> hey btw :)
[15:54] <andyrock> not much to be honest, I've been busy with other things
[15:54] <andyrock> another thing is that my solution required to open a new x11 Display
[15:54] <andyrock> and this can cause deadlocks
[15:55] <andyrock> and using the existing Display Connection does not work
[16:11] <andyrock> qengho: hey
[16:11] <andyrock> you here?
[16:11] <qengho> andyrock: hi
[16:11] <andyrock> hey I'm trying to build cr from source
[16:12] <andyrock> x11 + ozone
[16:12] <qengho> Cool.
[16:12] <andyrock> it builds but it fails to render properly
[16:12] <andyrock> i'm using Y
[16:12] <andyrock> with this parameters
[16:12] <andyrock> https://www.irccloud.com/pastebin/doHrlfLf/
[16:12] <andyrock> and running like that
[16:13] <andyrock>  ./out/DefaultY/chrome --ozone-platform=x11 --mash --window-manager=simple_wm
[16:13] <andyrock> it starts but it fails to render
[16:14] <andyrock> qengho: ^^^
[16:15] <Trevinho> didrocks: it should be all https://github.com/ubuntu/snapcraft-desktop-helpers/pull/46
[16:15] <Trevinho> or maybe I missed something... :o
[16:15] <qengho> andyrock: What happens with no parameters? --ozone.... ?
[16:16] <didrocks> Trevinho: still some changes needed
[16:16] <didrocks> Trevinho: see my comments
[16:16]  * didrocks needs to go for some errands
[16:16] <didrocks> Trevinho: if you don't get to it, I can either finish it myself, anyway, won't merge before updating the platform snap
[16:16] <b4n> andyrock: oh :(
[16:17] <Trevinho> didrocks: ok, also the wiki part should be separated or not?
[16:17] <b4n> (sorry missd your answer before)
[16:17] <didrocks> Trevinho: I don't think it should
[16:18]  * didrocks already late, see you tomorrow guys!
[16:18] <andyrock> qengho: other errors
[16:18] <Trevinho> didrocks: I'm not sure I see your comment in ...
[16:19] <qengho> andyrock: I don't have any insight into enabling ozone specifically to use its X11 pathway. There is probably some reason it isn't the default renderer.
[16:20] <qengho> andyrock: I can build and debug with you, if you like.
[16:21] <andyrock> i'm using vanilla cr
[16:21] <andyrock> maybe I should use https://code.launchpad.net/~chromium-team/chromium-browser/yakkety-working
[16:21] <andyrock> or something like that?
[16:22] <andyrock> qengho: ^^^
[16:22] <qengho> andyrock: right. I'll replace all (or most) GN configuration with the one you pasted. Might take 30-45 minutes to build. ...
[16:22] <andyrock> cool thanks
[16:23] <GunnarHj> jbicha: I was about to give bug #1662031 a try, but Ubuntu GNOME zesty seems to be severely broken at the moment. (Can't open g-c-c or the power menu.) What's up?
[16:27] <qengho> andyrock: Wait, are you asking because you expected the plain vanilla tree to work, or because you enabled something new but not exotic and it isn't working.
[16:28] <andyrock> because I expect the plain vanilla tree to work
[16:28] <andyrock> :D
[16:28] <qengho> andyrock: and it didn't?
[16:28] <andyrock> nope
[16:28] <qengho> Ah! I thought I was debugging some ozone for you.
[16:28] <GunnarHj> seb128: Did you see this question:
[16:28] <GunnarHj> https://irclogs.ubuntu.com/2017/02/09/%23ubuntu-desktop.html#t12:39
[16:29] <GunnarHj> ?
[16:29] <andyrock> qengho: i'm following this
[16:29] <andyrock> https://chromium.googlesource.com/chromium/src/+/lkgr/docs/linux_build_instructions.md
[16:29] <andyrock> should this work?
[16:30] <qengho> andyrock: v56 is a work in progress. Strip off the top changelog so the version is v55 and it plain chromium will work.
[16:30] <andyrock> I'll try that
[16:30] <qengho> andyrock: Every version has its headaches. :\
[16:31] <qengho> andyrock: I hope nobody told you chromium was easy. :P
[16:31] <andyrock> I can see from the size that's not easy
[16:31] <andyrock> also it changes fast
[16:31] <andyrock> which one is the git tag?
[16:32] <qengho> pardon?
[16:32] <andyrock> 55.0.2883.99
[16:32] <andyrock> for v55
[16:32] <andyrock> qengho: i guess they use tags for versioning
[16:33] <qengho> andyrock: They release tarballs every time they mark a version stable and I consume those directly, with no mutation.
[16:38] <jbicha> GunnarHj: it works here, uh can you try to run gnome-control-center from a terminal?
[16:43] <seb128> GunnarHj, oh, yeah but I didn't understand it and then got sidetracked by another ping sorry
[16:44] <seb128> GunnarHj, zesty opening shouldn't matter, translations are shared between serie when the strings are identic, when the serie was open doesn't matter I think
[16:47] <GunnarHj> seb128: My thought is that fresh upstream translations coming with zesty packages won't make it to xenial until zesty has opened. Maybe I'm missing something.
[16:47] <jbicha> GunnarHj: things work here, uh can you try to run gnome-control-center from a terminal?
[16:47] <seb128> that's true
[16:47] <seb128> GunnarHj, not sure many strings are untranslated in xenial and translated in zesty though
[16:48] <GunnarHj> seb128: Me neither. But it would be one reason for waiting with the xenial update a few weeks. Maybe there are reasons against too.
[16:51] <GunnarHj> jbicha: Tried that too, and the system froze.
[16:51] <GunnarHj> jbicha: (I'm not on Ubuntu GNOME atm.)
[16:51] <seb128> GunnarHj, I think we can do an upload, the zesty opening/import is going to take some time so that's for next round
[16:52] <GunnarHj> seb128: Ok, then the goal is to start the testing next week, right?
[16:53] <jbicha> GunnarHj: were you on bare hardware or virtualization?
[16:53] <GunnarHj> jbicha: Bare hardware, fully updated.
[16:53] <seb128> GunnarHj, yes
[16:57] <jbicha> hmm, the xfont stuff did land today
[16:59] <GunnarHj> seb128: Ack. Updated the schedule:
[16:59] <GunnarHj> https://wiki.ubuntu.com/Translations/XenialXerus/ReleaseSchedule
[16:59] <seb128> GunnarHj, thanks
[17:00] <GunnarHj> jbicha: I can't help much, probably, just wanted you to know.
[17:01] <jbicha> thanks
[17:15] <Trevinho> seb128: soo... who should create the  gnome-runtime folder now?
[17:16] <Trevinho> seb128: as If i try to use a remote part it's not generated...
[17:16] <Trevinho> thus no errror because it's not mounted
[17:18] <seb128> Trevinho, didrocks and I are going to update the runtime snap tomorrow
[17:18] <seb128> but he called it a day
[17:19] <seb128> (which I'm about to do as well, we have a friend over for dinner)
[17:20] <seb128> Trevinho, oh, without the rename you mean? the consumer snap needs to create the dir
[17:20] <seb128> the content sharing bind mount needs the target to exist
[17:20] <Trevinho> seb128: can't we rely on the remote part doing it?
[17:20] <seb128> no, your snap is a ro filesystem
[17:20] <seb128> oh, at build time
[17:20] <Trevinho> I mean the remote part creates that not in runtime...
[17:21] <seb128> yeah, I did that in my workaround part in decembre
[17:21] <seb128> let's discuss it with Didier tomorrow
[17:23] <Trevinho> ok
[17:23] <Trevinho> as right now it fails to warn about the missing thing
[17:30] <Trevinho> seb128: connecting doesn't always work, but... the remmina snap works in general... and it's just 11mb now
[17:47] <willcooke> right, to the train station.  night all
[18:25] <Trevinho> seb128: would you mind to merge https://code.launchpad.net/~3v1n0/+junk/snap-gnome-udt@split-parts+indicators-support with yours?
[18:25] <Trevinho> err DT one (which... I still i'm not part of :-/)