[00:04] <sergiusens> elopio I've updated 629
[00:12] <sergiusens> elopio 629 is the interesting one to be tested against the staging store
[01:28] <MichaelTunnell> if a non-official snap is added to the snapstore and an official team wants to take it over is it possible to transfer ownership to become official and if so can the suffix be removed from the snap name?
[01:30] <MichaelTunnell> niemeyer: ogra_: ?
[01:38] <niemeyer> MichaelTunnell: Yes to both
[01:42] <elopio> sergiusens: you can register your own user on staging, and pass the TEST_USER_NAME and TEST_USER_PASSWORD. Just make sure to accept the agreement first.
[01:42] <elopio> or I can send you the test user password.
[01:43] <MichaelTunnell> niemeyer: nice thanks for clarification
[02:28] <mup> Bug #1598984 opened: snap list reports no snaps installed when invalid name passed <Snappy:New> <https://launchpad.net/bugs/1598984>
[02:45] <TheMuso> Is the latest version of snapd going into yakkety any time soon? I know we are targetting snaps for xenial right now, but it would be nice to be able to work with and test snaps in yakkety as well.
[03:07] <mup> PR snapcraft#629 changed: Proper message when registering an already registered snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/629>
[03:41] <sergiusens> elopio about lp: #1572399 ... I talked to cprov and he asked me to create a bug, mind just linking this to the store tracker?
[03:41] <mup> Bug #1572399: [upload] Catch name registration issue and explain how <Snapcraft:In Progress by tsimonq2> <https://launchpad.net/bugs/1572399>
[05:26] <dholbach> hey hey
[07:07] <mup> PR snapd#1485 opened: snap: add `snap run --debug-shell` <Created by mvo5> <https://github.com/snapcore/snapd/pull/1485>
[07:09] <niemeyer> o/
[07:16] <mup> PR snapd#1394 changed: debian: add snapd.postrm that purges <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1394>
[07:51] <mup> PR snapd#1486 opened: interfaces: add wireless-control <Created by lpotter> <https://github.com/snapcore/snapd/pull/1486>
[08:41] <mup> PR snapd#1481 changed: overlord: make patch1_test more robust <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1481>
[08:43] <mup> PR snapd#1487 opened: tests: set yaml indentation to 4 spaces <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1487>
[09:43] <mup> PR snapd#1462 closed: snapstate: cleanup downloaded temp snap files <Reviewed> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1462>
[09:55] <mup> PR snapd#1487 closed: tests: set yaml indentation to 4 spaces <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1487>
[10:47] <mwhudson> zyga, mvo: hey, i was looking at the snap-confine package in the yakkety queue
[10:47] <mwhudson> where did the tarball come from? it doesn't seem to match the release on https://github.com/snapcore/snap-confine/releases
[10:47] <mwhudson> (i think maybe the one in the upload queue is a straight git export and the one on github is the output of some 'make dist' type thing?)
[10:48] <mwhudson> also i'm probably going to upload it to debian as 1.0.34-1 tomorrow so maybe you should use a version that won't be overwritten by that? (or maybe being overwritten is fine?)
[10:48] <mwhudson> also also i'm going to bed
[10:50] <mwhudson> (package for debian in http://anonscm.debian.org/cgit/collab-maint/snap-confine.git/log/?h=debian fwiw)
[10:51] <zyga> mwhudson: hey
[10:52] <zyga> mwhudson: I'm not sure, I didn't' do the yakkety release, please definitely use the make dist one
[10:53] <mwhudson> zyga: the snap-confine-1.0.34.tar.gz is a make dist one?
[10:53] <mwhudson> (it looks like it to me)
[10:53] <zyga> mwhudson: yes
[10:53] <mwhudson> zyga: on https://github.com/snapcore/snap-confine/releases
[10:53] <zyga> mwhudson: libexecdir should stay as /usr/lib/snapd
[10:53] <zyga> mwhudson: (for various interesting reasons)
[10:53] <willcooke> didrocks, btw - did that issues detecting gtk3 vs gtk2 on 64bit get fixed?
[10:53] <zyga> mwhudson: if you want I can make those changes and send you patches
[10:55] <mwhudson> zyga: i took that change
[10:56] <mwhudson> http://anonscm.debian.org/cgit/collab-maint/snap-confine.git/tree/debian/rules?h=debian#n22
[10:56] <mwhudson> zyga: but thanks for confirming :-)
[10:57] <zyga> mwhudson: in .34 the config option changed to --disable-seccomp and --disable-apparmor
[10:57] <zyga> mwhudson: nice, thank you
[10:57] <mwhudson> zyga: ah ok, please send a patch for that :)
[10:57] <zyga> mwhudson: gladly
[10:58] <gouchi> hi
[10:58] <zyga> gouchi: hey
[10:58] <mwhudson> it still built with --disable-confinement though, unless i goofed my build testing
[10:58] <gouchi> I was wondering if those device will be part of opengl interface ?
[10:58] <gouchi> http://www.hastebin.com/ixuyuduxaz.vhdl
[10:58] <zyga> mwhudson: that's odd, it definitely should not
[10:58] <zyga> mwhudson: cloning to test now
[10:58] <mwhudson> cool
[10:59]  * mwhudson really really going to bed now
[10:59] <mwhudson> ttyl
[10:59] <zyga> gouchi: let me check
[10:59] <zyga> mwhudson: bye!
[11:01] <mup> PR snapd#1478 closed: many: Add device authentication skeleton <Created by wgrant> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1478>
[11:01] <mup> PR snapd#1488 opened: store: switch search to new snap-specific endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/1488>
[11:03] <zyga> gouchi: /dev/dri/dri0 is not in the opengl interface
[11:04] <zyga> gouchi: can you tell me more about the application you are trying to run as well as the GPU and driver you are using
[11:05] <gouchi> zyga: using intel gpu I tried to run retroarch in drm/kms with egl
[11:05] <gouchi> zyga: https://github.com/libretro/RetroArch/wiki/KMS-mode
[11:06] <gouchi> zyga: As I couldn't make it work with x11 interface, I tried with opengl interface
[11:06] <zyga> gouchi: this looks closer to the mir interface
[11:07] <zyga> gouchi: and it seems it would require a new interface to work, can you please look at snapd pull requests on github.com/snapcore/snapd, look at the mir interface there and use it as a starting point
[11:07] <gouchi> zyga: I will try thank you
[11:07] <zyga> gouchi: then the application using the new interface
[11:08] <zyga> gouchi: note that application can  gain permissins just by having a slot of a given type, it doesn't have to be connected
[11:08] <zyga> gouchi: in thise sense, you could use the new interface slot to grant that application to run with direct gpu access
[11:09] <gouchi> zyga: this one https://github.com/snapcore/snapd/pull/1299 ?
[11:09] <mup> PR snapd#1299: create mir interface <Reviewed> <Created by kgunnfront> <https://github.com/snapcore/snapd/pull/1299>
[11:09] <zyga> yes
[11:28] <mup> PR snapd#1485 closed: snap: add `snap run --shell` <Reviewed> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1485>
[11:57] <didrocks> willcooke: yeah, it's fixed now
[11:57] <willcooke> didrocks, thanks!
[11:58] <didrocks> willcooke: just rebuild your snap if you didn't since Friday :)
[11:58] <willcooke> running it now
[11:59] <didrocks> willcooke: ensure you snapcraft update (I don't know how much it caches)
[11:59] <didrocks> run*
[11:59] <willcooke> ack
[12:06] <mup> PR snapd#1473 closed: tests, integration-tests: port refresh all test to spread <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1473>
[12:16] <gouchi_> zyga: better http://www.hastebin.com/dubevesula.coffee but I got fatal error
[12:17] <zyga> gouchi_: is that with mir or with a new interface?
[12:18] <gouchi_> zyga: mir interface
[12:18] <gouchi_> zyga:   plugs: [network, network-bind, mir, opengl, home]
[12:18] <zyga> gouchi_: try slots: [mir]
[12:18] <zyga> gouchi_: mir slot let mir "be mir" and talk to GPUs and such
[12:19] <willcooke> didrocks, yay! works.  thank you!!
[12:19] <zyga> gouchi_: though you will probably need bleeding edge code from that branch
[12:19] <zyga> gouchi_: do you know how to rebuild snapd?
[12:19] <gouchi_> zyga: I followed https://github.com/snapcore/snapd/blob/master/README.md and build it
[12:20] <zyga> gouchi_: you can use github.com/zyga/devtools to use the new version easily
[12:20] <zyga> gouchi_: look at the refresh-bits script there
[12:20] <zyga> gouchi_: I wrote that for working on interfaces
[12:21] <gouchi_> zyga: I will try thank you very much
[12:22] <zyga> gouchi_: refresh-bits snap snapd setup run-snapd restore
[12:22] <zyga> gouchi_: (read the code to see what happens)
[12:22] <zyga> gouchi_: it also has useful --help
[12:26] <gouchi_> zyga: same error with  slots: [mir]
[12:29] <didrocks> willcooke: excellent! yw ;)
[12:41] <mup> PR snapd#1458 closed: many: add `snap enable/disable` commands <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1458>
[12:41] <mup> PR snapd#1489 opened: snap: ensure unknown arguments to `snap run` are ignored <Created by mvo5> <https://github.com/snapcore/snapd/pull/1489>
[13:06] <sborovkov> Hi. What is log-observe interface doing? I am using python's systemd API to get journal contents and poll for it's changes but I still get some APPARMOR warnings
[13:06] <sborovkov> operation="open" profile="snap.screenly-client.logger" name="/run/log/journal/a82c9efe141649b3983327aa20a8ed23/system@5b2dfcfdd13348ce82cbcf01123e4caa-000000000000064e-000536e30cc89344.journal"
[13:07] <sborovkov> And this one: operation="open" profile="snap.screenly-client.logger" name="/run/log/journal/a82c9efe141649b3983327aa20a8ed23/system.journal" pid=1368 comm="python3" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[13:14] <seb128> sborovkov, whare snapd version do you use?
[13:14] <sborovkov> seb128: snapcraft should be from last week I think. I did build the image before that I think though
[13:15] <seb128> sborovkov, snapd, not snapcraft
[13:15] <seb128> the snappy system service
[13:15] <seb128> not the build tools
[13:15] <sborovkov> Understood, how do I make it ouput the version?
[13:16] <seb128> on ubuntu "dpkg -l | grep snapd"
[13:16] <mvo> apt list snapd
[13:16] <mvo> :)
[13:17] <mvo> (so much nicer IMNSHO)
[13:17] <josepht> good to know
[13:17] <sborovkov> wait, I am on RPI
[13:17] <sborovkov> no dpkg
[13:18] <seb128> k
[13:18] <seb128> well anyway the journal interface got some fixes in 2.0.10 which is less than a week old
[13:18] <seb128> make sure you have this version
[13:18] <sborovkov> Understood
[13:18] <seb128> unsure about your RPI image
[13:18] <seb128> maybe mvo can help
[13:18] <sborovkov> My image is more recent, so might be that.
[13:18] <seb128> (snapd really needs a -v argument)
[13:19] <mhall119> sergiusens: what's the easiest way for me to try your snapcraft pkg-config lookup patches when doing a cleanbuild?
[13:26] <ogra_> grmpf .. packaging a java GUI app i can get everything to work fine with the default GTK theme (win95 style) ... but as soon as i ship light-themes and set a theme no icons are found :(
[13:28] <jdstrand_> sborovkov: re log-observe and systemd journal> there is a fix in 2.0.10 for that (https://launchpad.net/ubuntu/+source/snapd/2.0.10). If you are using Ubuntu, 2.0.10 hasn't landed yet in 16.04, but is on its way
[13:32] <seb128> ogra_, unsure what toolkit they use but you might lack a svg loader
[13:33]  * didrocks wonders why seb128 is talking about svg loader :p
[13:33] <didrocks> hem hem ;)
[13:33] <seb128> lalala ;-)
[13:33] <didrocks> heh
[13:34] <didrocks> ogra_: yeah, ensure that you have this svg loader, icons are in svg and we experienced that some theme engine won't even look at them until they have a svg loader/decoder
[13:34] <ogra_> seb128, well, i see it in the gdk loaders dir
[13:34] <ogra_> and i regenerate the loader cache on app startup
[13:34] <didrocks> is it that one doing the decoding?
[13:34] <didrocks> despite using the gtk theme engine in qt, it's qt itself doing the svg decoding
[13:34] <didrocks> for instance
[13:35] <ogra_> well, it is a java awt app
[13:35] <didrocks> unsure if awt can decode svg
[13:35] <didrocks> try shipping a corresponding .png image
[13:35] <seb128> well those work on normal desktop I guess
[13:35] <didrocks> in the same directory than one icon it's using
[13:36] <seb128> that would be a known problem otherwise?
[13:36] <didrocks> and see if it can open it
[13:36] <didrocks> yeah, what about without devmode?
[13:36] <ogra_> i only run without devmode ;)
[13:37] <didrocks> and if you run your app directly?
[13:37] <didrocks> like without the u-c-l wrapper?
[13:38] <ogra_> if i run it as java -jar $path_to_jar i get icons
[13:38] <ogra_> so thereis still some env var missing or so
[13:38] <didrocks> did you try with the gtk launcher?
[13:39] <didrocks> to see if it's something that you might miss
[13:39] <ogra_> way to much overhead
[13:39] <didrocks> well, try it at lest
[13:39] <didrocks> least*
[13:39] <ogra_> but i'll tyr to grab bits from there
[13:39] <didrocks> and you know, you can override some stage-packages
[13:39] <didrocks> at least, try it and see
[13:39] <didrocks> that will give you some hints
[13:39] <didrocks> you are then welcome bringing a smaller one and contribute :)
[13:39] <didrocks> rather than duplicating
[13:40]  * ogra_ is looking for the most minimal setup here 
[13:40] <didrocks> this is what I did with the new desktop launchers
[13:40] <didrocks> the minimal required things for gtk/qt apps
[13:40] <didrocks> but it seems it's been a couple of days you are stuck on this without even trying another one
[13:41] <didrocks> just to ensure that the issue is larger than just missing dependencies
[13:43] <didrocks> intellij IDEA is using java awt
[13:43] <didrocks> and have working theme here
[13:43] <didrocks> (since I switched it to my gtk launcher)
[13:49] <ogra_> didrocks, btw, it would be good if you stopped using a bash shebang in these launchers ... on actual snappy images we might not have bash access
[13:49] <ogra_> (while /bin/sh is always guaranteed to be there)
[13:50] <didrocks> ogra_: yeah, patch welcome, otherwise, it's on my list, but for later :)
[13:50] <ogra_> yeah
[13:50] <didrocks> ogra_: I think it would be better to be compiled anyway, so rewriting in go or such (but then, there is the issue for uncompiled snaps like python and so…)
[13:51] <zyga> jdstrand: https://bugzilla.suse.com/show_bug.cgi?id=986050#c1
[13:51] <zyga> jdstrand: and https://bugzilla.suse.com/show_bug.cgi?id=986050#c2
[13:51] <kyrofa> ogra_, didrocks doesn't like to be limited by dash
[13:51] <ogra_> heh
[13:52] <didrocks> I'm used to dash, did a big part of porting years ago of our scripts to dash :)
[13:52] <didrocks> but here, I just wanted something which works quickly :p
[13:53] <ogra_> you could just put bash into stage packages by default ... whats another 5MB if your hello-world already needs 100MB of deps :P
[13:55] <didrocks> ogra_: better to do just use dash, it's not user visible anyway
[13:55] <ogra_> i was joking ;)
[14:15] <oSoMoN> dpm, hey, I’m experimenting with snapcraft and webbrowser-app, and https://github.com/dplanella/qt5conf/blob/master/qt5-launch#L45 appears to be preventing the app from starting, making XDG_DATA_HOME a non-writable location sounds wrong
[14:16] <ogra_> oSoMoN, try didrocks' launcher instead
[14:17] <oSoMoN> ogra_, is that the desktop/qt5 one?
[14:17] <ogra_> yep
[14:17] <oSoMoN> cool, will try that one
[14:20] <sergiusens> kyrofa mind quickly fixing https://github.com/snapcore/snapcraft/pull/622 ?
[14:20] <mup> PR snapcraft#622: Hard-link local sources instead of symlinking them <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/622>
[14:20] <kyrofa> sergiusens, yeah I'm working on it as we speak
[14:20] <sergiusens> kyrofa oh, nice :-)
[14:21] <mup> PR snapcraft#630 closed: Report a nice error when registering too fast <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/630>
[14:23] <kyrofa> sergiusens, super annoying... can't get it to happen locally :P
[14:33] <gouchi_> using x11, opengl, unity interfaces shouldn't make XOpenIM to failed ?
[14:33] <kyrofa> elopio, are you around?
[14:35] <gouchi_> ftp://www.x.org/pub/X11R7.7/doc/man/man3/XOpenIM.3.xhtml
[14:36] <kyrofa> sergiusens, look at this trace: http://pastebin.ubuntu.com/18546556/
[14:36] <kyrofa> sergiusens, makedirs(..., exist_ok=True) -> "bam, that already exists!" -> death
[14:37] <kyrofa> sergiusens, this test isn't failing locally and I can't duplicate that behavior. Do you see anything I'm missing? Ensure failure is here: https://travis-ci.org/snapcore/snapcraft/jobs/142467621
[14:37] <sergiusens> kyrofa sure, give me a sec
[14:38] <kyrofa> It's a symlink, not a dir, but that still works fine locally. I even tried messing with the permissions in case that threw it off, but it works locally anyway. Do we know which python3 version is on the job machines?
[14:39] <kyrofa> Oh... wait...
[14:39] <kyrofa> sergiusens, nevermind, I'm stupid
[14:40] <kyrofa> sergiusens, that was way too hard
[14:40] <sergiusens> kyrofa what was it
[14:40] <sergiusens> ?
[14:40]  * didrocks is interested, I looked at the os code, and I see 2 protections against what you saw :)
[14:41] <elopio> kyrofa: hello
[14:41] <elopio> how can I help you?
[14:42] <kyrofa> sergiusens, didrocks it's a test artifact. The integration test runs on a partially build snap, to test that the change works on an old tree. But the parts/foo/src symlink is absolute, not relative, so it's a broken one in jenkins (doh!)
[14:42] <kyrofa> elopio, nevermind, sorry!
[14:42] <gouchi_> I will be glad if somebody can test my snap package to see if I am doing something wrong
[14:42] <gouchi_> here is the source : https://framadrop.org/r/vEimxEXgr2#SHwKK3R8qJ12soOacXboC+PbzNPvb/xPoijFaq7+e5s=
[14:43] <didrocks> kyrofa: ahah, that explains! :)
[14:44] <kyrofa> didrocks, super confusing :P
[14:44] <gouchi_> for now it failed here https://github.com/libretro/RetroArch/blob/master/gfx/common/x11_common.c#L338 using x11, opengl, unity7 interface
[14:44] <zyga> gouchi_: I can look but not tonight, I have plenty of things to finish
[14:45] <sergiusens> kyrofa heh, that's what you get for mocking ;-)
[14:45] <kyrofa> sergiusens, nothing is mocked!
[14:45] <kyrofa> sergiusens, it's just a bit of an odd test is all. I made the mistake of committing exactly what snapcraft gave me (an absolute symlink) without thinking about it
[14:45] <gouchi_> zyga: thank you no problem I can't find why it stops
[14:46] <sergiusens> kyrofa preparing the testbed/fixture would require you to make it absolute again though, right?
[14:48] <kyrofa> sergiusens, nah, it just copies the entire snap directory that contains the symlink already made
[14:51] <didrocks> kyrofa: indeed :)
[14:51] <bpeak> Man, I really want chromium on snappy
[14:54] <ogra_> you can ... but only in devmode
[14:58] <jdstrand> roadmr: hey, at some time whenever it is convenient, can you pull r692. this is for puritine click and not urgent (next roll out is fine)
[14:59] <roadmr> jdstrand: sure thing, I'll put it in the pipeline!
[15:01] <seb128> gouchi_,  ogra_ was having the same XOpenIM issue, unsure if he solved it
[15:01] <ogra_> well, i dont remember anymore
[15:01] <ogra_> :)
[15:01] <jdstrand> roadmr: thanks!
[15:02] <ogra_> (i remember i had it ...)
[15:02] <ogra_> ah, no, i didnt .... that was when i tried to package servo
[15:08] <gouchi> ogra_: I checked snappy playpen packages and only mpv is using XOpenIM
[15:08] <gouchi> ogra_: but I doubt it using x11 code as mpv snap package is using only opengl interface
[15:10] <seb128> gouchi, does it work in devmode?
[15:11] <kyrofa> zyga, how do you test snap-confine, since it conflicts with u-c-l?
[15:14] <gouchi> seb128: nope
[15:14] <roadmr> hey folks, what's a good/recommended way to get or build a snappy-only image for a rpi2? i.e. not xenial-with-snapd but an "all-snap" image?
[15:15] <zyga> kyrofa: you install ubuntu-core-launcher too :)
[15:16] <zyga> kyrofa: snap-confine has two binary packages
[15:16] <zyga> kyrofa: one of them is snap-confine, the other is ubuntu-core-laucher
[15:16] <kyrofa> zyga, argh, missed that
[15:16] <kyrofa> Thanks :)
[15:16] <seb128> gouchi, I can try having a look if you want
[15:16] <gouchi> seb128: I will be glad to, thank you very much
[15:16] <seb128> yw
[15:22] <sergiusens> elopio the current interface we have for pushing files makes me sad
[15:25] <roadmr> zyga: I'm sure you'll know how to get an all-snap image for rpi2 :)
[15:26] <zyga> roadmr: yes, get a delorean and come back later ;) in all honesty I didn't work with all snap images for a while, I bet you can still get an image somewhere but I wasn't in the loop around that lately
[15:27] <roadmr> zyga: thanks! hehe no problem, I'll walk to the future (also known as : waiting) X-)
[15:27] <zyga> roadmr: I think ogra_ might know more
[15:27] <zyga> roadmr: note that slangasek works on ubuntu-image so he might also know some useful thigns I dont
[15:28] <roadmr> cool! yay, fwiw I'm happy to assemble my own image if pointed to tools/docs
[15:28] <ogra_> well, the current images ... even if you buuild them newly .... are months outdated
[15:28] <ogra_> i doubt any recent snaps would even work
[15:28] <roadmr> ogra_: oh bummer, and there's no way to build one with recent components I reckon?
[15:29] <ogra_> afaik mvo has a hacked u-d-f that might get you something working that would persist for a few days until you need to break it again
[15:29] <roadmr> haha :)
[15:29] <ogra_> roadmr, the recent components are not in the store, ubuntu-core is ages old
[15:29] <roadmr> ogra_: so for all real purposes I'm better off just using xenial with snapd?
[15:29] <ogra_> we would need to update it first, but there are some blockers
[15:30] <ogra_> yeah
[15:30] <ogra_> just use a classic install
[15:30] <roadmr> ok... I can do that, no problem :)
[15:32] <roadmr> thanks ogra_ :)
[15:47] <elopio> sergiusens: do you mean, the store clients?
[15:51] <sergiusens> elopio _upload.py specifically
[15:52] <elopio> sergiusens: I agree. It doesn't match the others, and passing the client as an argument is a little spaghetti
[15:52] <elopio> sadly, I ended up with no good refactoring in mind for it. Do you have one?
[15:52] <sergiusens> elopio I think I am going to spend the rest of the week on a little refactor
[15:52] <elopio> \o/
[15:55] <ogra_> seb128, didrocks, soo ... it seems icons are only broken if i put any icon themes beyond hicolor into stage-packages (i had light-themes in there when it broke) ... ii guess snapcraft omitting all maintainer scripts breaks the icon stuff somehow
[15:56] <seb128> that's on possibility
[15:56] <seb128> one other is that the other themes use svg files
[15:56] <seb128> which you don't have proper support for loading
[15:56] <didrocks> yeah
[15:56] <ogra_> i do
[15:56] <didrocks> did you get the same behavior with the desktop launcher?
[15:56] <ogra_> i have all pixbuf loaders and the loader cache is updated
[15:56] <seb128> is your snap available somewhere so I can have a look?
[15:57] <seb128> right
[15:57] <seb128> but java maybe doesn't use gdkpixbuf
[15:57] <seb128> like we tried with a qt app and were missing libqsvg or something
[15:57] <ogra_> seb128, it works if i launch th jar directly
[15:57] <seb128> from outside the snap?
[15:57] <ogra_> yes
[15:57] <seb128> right
[15:57] <ogra_> just using the java  on my desktop i get proper icons
[15:58] <seb128> anyway, is your snapcraft.yaml public?
[15:58] <seb128> so I can have a look
[15:58] <ogra_> not the current version.. but it has only:
[15:58] <ogra_>     stage-packages:
[15:58] <ogra_>       - libglib2.0-0
[15:58] <ogra_>       - hicolor-icon-theme
[15:58] <ogra_>       - openjdk-8-jdk
[15:58] <ogra_> (i dont want *any* integration with the host here .... the app should ship and run everything standalone
[15:58] <ogra_> )
[16:01] <ogra_> seb128, https://github.com/ogra1/jtiledownloader ... thats the one not usin any themeing
[16:01] <seb128> ogra_, k
[16:02] <seb128> ogra_, you should try the desktop/gtk3 part launcher, it's a big hammer but if it works it would tell you there is some magic from the wrapper you can borrow
[16:03] <seb128> would easily rule out a class of issues
[16:03] <ogra_> i borrowed most of it already ... but i'm now pretty sure it is the postinst files breaking the stock icons since as soon as i drop the ubuntu themes and all theme hackery it all works just fine
[16:04] <ogra_> also the XDG_DATA_HOME setting the launcher uses breaks awt/swing
[16:04] <MichaelTunnell> niemeyer: here is why I've been asked so many random questions lately, https://youtu.be/0ApRUndiXKU
[16:04] <ogra_> the app cant start
[16:08] <joc_> sergiusens: hi, have you thought any more about the python3 PR? are you still nervous about test coverage?
[16:25] <kyrofa> sergiusens, I think snapcraft#622 should be good now
[16:25] <mup> PR snapcraft#622: Hard-link local sources instead of symlinking them <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/622>
[16:33] <oSoMoN> when creating a snap of webbrowser-app (which contains oxide), I’m seeing this:
[16:33] <oSoMoN> Removing suid/guid from /build/webbrowser-app/snap/parts/webbrowser-app/install/usr/lib/x86_64-linux-gnu/oxide-qt/chrome-sandbox
[16:33] <oSoMoN> this prevents oxide from functioning correctly
[16:33] <oSoMoN> how can I prevent snapcraft from tempering with the suid/guid of the chrome sandbox?
[16:34] <sergiusens> joc_ I think it is ok
[16:34] <sergiusens> elopio mind taking a look at the python --root pr?
[16:35] <elopio> sergiusens: I'm out for swimming lessons. I'll do that on the way back.
[16:36] <sergiusens> elopio thanks
[16:37] <sergiusens> oSoMoN suid and guid would be blocked by apparmor and the review tools
[16:37] <sergiusens> jdstrand any alternatives there ^?
[16:38] <oSoMoN> sergiusens, why remove the suid and guid then, if apparmor would block them anyway?
[16:38] <sergiusens> oSoMoN it was the nice thing to do before --devmode ever existed
[16:38] <oSoMoN> sergiusens, ah ok, it predated --devmode, that makes sense
[16:39] <sergiusens> oSoMoN by a year almost
[16:39] <oSoMoN> sergiusens, shouldn’t it be deprecated now? sounds like --devmode is much better suited
[16:40] <sergiusens> oSoMoN we still need to be able to auto remove the suidness somehow for people with confinement strict
[16:40] <sergiusens> oSoMoN I suppose we can tie this up to the `confinement` flag; mind logging a bug?
[16:40] <oSoMoN> sergiusens, doing right away, against which project?
[16:43] <sergiusens> oSoMoN snapcraft
[16:44] <oSoMoN> sergiusens, against the project itself, or against the source package? it seems there are existing bug reports targetting both
[16:44] <sergiusens> oSoMoN project, we always ask people to log against the project in the release ANN :-)
[16:44] <oSoMoN> ok
[16:48] <oSoMoN> sergiusens, https://bugs.launchpad.net/snapcraft/+bug/1599234
[16:48] <mup> Bug #1599234: should not remove suid/guid from binaries when confinement is devmode <Snapcraft:New> <https://launchpad.net/bugs/1599234>
[16:49]  * zyga -> supper, then more suse hacking
[16:49] <tsimonq2> sergiusens: when's the next planned Snapcraft release?
[17:00] <mup> Bug #1586581 changed: CAP_SYS_ADMIN interface for unconfined snaps <snapd-interface> <Snappy:Invalid> <https://launchpad.net/bugs/1586581>
[17:12] <sergiusens> tsimonq2 today
[17:12] <niemeyer> MichaelTunnell: Nice!
[17:13] <tsimonq2> sergiusens: oh ok
[17:13] <sergiusens> tsimonq2 why?
[17:15] <tsimonq2> sergiusens: it really would have been great to land my latest PR before 2.12 but it's no big deal :)
[17:15] <sergiusens> tsimonq2 2.12 has been out for a while though ;-)
[17:15] <sergiusens> we are releasing 2.13 ;-)
[17:15] <tsimonq2> wait
[17:15] <tsimonq2> lol
[17:16] <tsimonq2> I meant 2.13
[17:17] <tsimonq2> sergiusens: is it already released?
[17:18] <tsimonq2> sergiusens: I mean technically, are the git tags set and everything?
[17:19] <tsimonq2> sergiusens: if not, any chance you have a minute to help me finish my PR?
[17:24] <tsimonq2> PR #619
[17:25] <tsimonq2> snapcraft#619
[17:25] <mup> PR snapcraft#619: Add source-checksum option for tar and zip sources (bug 1585913) <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/619>
[17:25] <tsimonq2> there we are
[17:26] <jdstrand> oSoMoN, sergiusens: I commented in the bug
[17:27] <sergiusens> tsimonq2 I am in the process of reviewing the last PRs right now though
[17:28] <sergiusens> tsimonq2 take your time to finish it, nothing wrong with going into the next release ;-)
[17:28] <sergiusens> jdstrand thanks
[17:29] <tsimonq2> alright sergiusens, the only things left are some annoying test failures, test failures that could be easily solved today
[17:29] <sergiusens> tsimonq2 test failures are the hardest part of the problem; just look at kyrofa, he spent all morning looking into why his PR failed
[17:30] <oSoMoN> jdstrand, I’ve seen that, thanks!
[17:30] <kyrofa> tsimonq2, indeed, look at me
[17:30]  * kyrofa gives his best blue steel look
[17:30] <tsimonq2> \o/ kyrofa
[17:32] <tsimonq2> sergiusens: how close are you from making 2.13 final? basically, how much time do I have left to fix things if I really want my PR landed in 2.13? :)
[17:34] <kyrofa> tsimonq2, don't stress about that. If it gets in, it gets in. We try to do weekly releases
[17:35] <tsimonq2> kyrofa: alright :)
[17:37] <pachulo> sergiusens: one question, when do you plan to update the telegram-snap in the store? I've tried to create the snap with telegram-desktop 0.9.56 and it worked ok
[17:38] <kyrofa> tsimonq2, just focus on quality. Make sure those tests look good
[17:38] <sergiusens> pachulo I should just do it I guess, I wanted to fix some input method problems first though
[17:40] <tsimonq2> kyrofa: I'm working hard :)
[17:41] <tsimonq2> kyrofa: I'm not in a rush, I won't do it halfway, like I said, it would just be *nice* for source-checksum to land in 2.13, so I'm going to work towards that goal :)
[17:42] <kyrofa> tsimonq2, excellent
[17:42] <pachulo> sergiusens: i noticed problems when trying to write letters with accents, but thought it was a problem with the application, not the snap versio of it: https://github.com/telegramdesktop/tdesktop/issues/1360
[17:45] <sergiusens> oh, look at that, niemeyer too ^
[17:46] <sergiusens> pachulo thanks, I will see if this is indeed the problem I see
[17:46] <niemeyer> I don't have the problem out of a snap, FWIW
[17:46] <niemeyer> sergiusens: Also, those particular accents work.. probably something else
[17:49] <sergiusens> niemeyer yeah, most likely missing something input method related.
[18:12] <mup> PR snapcraft#614 closed: python3: use --root instead of --target <Created by jocave> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/614>
[18:20] <pachulo> maybe is a silly question, but after checking the documentation could not find an answer: Was trying to create a MAME snap using the "make" plugin, but as it seems that there is no "install" target in the MAME Makefile it fails to build because the snapcraft make plugin tries to install it; how should I proceed?
[18:21] <jrwren> pachulo: thanks for re-asking. I'm watching to see the answer.
[18:26] <kyrofa> sergiusens, snapcraft's python2 plugin can't seem to install this from pip: https://pypi.python.org/pypi/pymacaroons-pynacl/ . Is it because wheels are disabled? Think the --root PR will fix that?
[18:30] <kyrofa> sergiusens, oh... that was only python3
[18:41] <sergiusens> kyrofa it won't
[18:41] <sergiusens> kyrofa global-options disable wheeling
[18:41] <kyrofa> sergiusens, hmm... how might one get around this, then?
[18:44] <kyrofa> pachulo, do you know off the top of your head what needs to be placed into the snap after the part is made?
[18:45] <kyrofa> pachulo, i.e. can you safely separate the compiled binaries from the sources?
[18:45] <kyrofa> pachulo, that's typically what an install rule does-- the upstream project knows what it needs to run and where things need to go
[18:46] <kyrofa> pachulo, if your upstream project didn't supply that, then you'll need to create a local plugin that simply calls "make" and then copies stuff in explicitly rather than relying on an install rule
[18:46] <sergiusens> kyrofa elopio sup
[18:46] <kyrofa> sergiusens, on my way
[18:58] <pachulo> kyrofa: not really, but I was planning on looking at the files installed by the repostory package to see what I need to copy
[18:58] <mup> Bug #1598304 changed: systemd services created by snappy breaks etckeeper <etckeeper:New> <Snappy:Invalid> <https://launchpad.net/bugs/1598304>
[18:58] <pachulo> kyrofa: I will try the local plugin approach, thanks for your suggestion!
[18:59] <kyrofa> pachulo, sure!
[19:02] <tsimonq2> *sigh* I have been racking my brain on this for too long, it's time to seek help, I've tweaked a lot of different things to no avail...
[19:02] <tsimonq2> (in snapcraft#619 )
[19:02] <mup> PR snapcraft#619: Add source-checksum option for tar and zip sources (bug 1585913) <Created by tsimonq2> <https://github.com/snapcore/snapcraft/pull/619>
[19:02] <tsimonq2> I'll push my changes now, but I'm getting thrown this error in the unit tests:
[19:02] <tsimonq2> TypeError: __init__() missing 1 required positional argument: 'source_checksum'
[19:05] <tsimonq2> if anybody is around to give me a hand and just point me in the right direction, that would be awesome, I know kyrofa was helping me the other day so I don't know if he wishes to help again :)
[19:06] <kyrofa> Sure tsimonq2, give me a minute
[19:17] <tsimonq2> thanks kyrofa :)
[19:37] <kyrofa> Alright tsimonq2 I'm taking a look at the branch now
[19:39] <mup> PR snapcraft#631 opened: Fix the store integration tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/631>
[19:40] <tsimonq2> cool thanks kyrofa
[19:44] <netphreak> hi, guys!
[19:44] <kyrofa> tsimonq2, alrighty
[19:44] <kyrofa> tsimonq2, take a look at the Base class
[19:44] <kyrofa> tsimonq2, specifically its __init__
[19:45] <kyrofa> tsimonq2, do you know which parameters are required, and which are optional?
[19:45] <kyrofa> Hey netphreak :)
[19:45] <netphreak> Just uploaded my first snap to the store in the Edge channel, and get the following error from automated review: "package contains external symlinks: usr/lib/jvm/java-8-openjdk-armhf/jre/lib/security/cacerts lint-snap-v2_external_symlinks"
[19:45]  * tsimonq2 pops open the source
[19:45] <netphreak> The snap uses the java/jdk plugin.
[19:45] <tsimonq2> kyrofa: in snapcraft/internal/sources.py ?
[19:45] <kyrofa> tsimonq2, indeed
[19:46] <tsimonq2> kyrofa: alright
[19:46] <kyrofa> netphreak, can you pastebin the output of ls -l prime/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/security/
[19:46] <tsimonq2> kyrofa: what's required is source
[19:47] <tsimonq2> the rest are optional depending on what you are trying to do
[19:47] <netphreak> : No such file or directory
[19:47] <kyrofa> tsimonq2, how can you tell? What about source_dir?
[19:48] <kyrofa> netphreak, I made the assumption you still had the built tree there. Do you still have your prime directory lying around?
[19:48] <tsimonq2> kyrofa: I just guessed from what I know about snapcraft.yaml files, there's not much in the Base class that would tell me a lot about that
[19:48] <tsimonq2> except that source_dir kind of stands out
[19:48] <kyrofa> tsimonq2, sure there is. Note that source and source_dir aren't immediately followed by =
[19:49] <tsimonq2> (in the init)
[19:49] <tsimonq2> well yes
[19:49] <kyrofa> tsimonq2, the other parameters all have default values
[19:49] <kyrofa> tsimonq2, which means they aren't required
[19:49] <tsimonq2> kyrofa: well source-checksum isn't required either
[19:49] <kyrofa> tsimonq2, indeed. And it shouldn't
[19:49] <kyrofa> tsimonq2, check out Zip's __init__ or Tar's __init__
[19:50] <netphreak> i still have the snap build lying around.. but can't see no prime dir
[19:50] <tsimonq2> kyrofa: oh, so it seems to be required?
[19:50] <kyrofa> netphreak, ah, your snapcraft is a little old then, but no matter: run `ls -l snap/usr/lib/jvm/java-8-openjdk-armhf/jre/lib/security/`
[19:50] <netphreak> ahh.. sorry.. I do have a prime dir.. moment.
[19:50] <kyrofa> tsimonq2, indeed
[19:50] <kyrofa> tsimonq2, but the tests don't pass it in
[19:50] <kyrofa> tsimonq2, so you get an error saying a param is missing
[19:51] <tsimonq2> ahhh
[19:51] <kyrofa> tsimonq2, so: is it required or not? If so, the tests need to be updated. If not, the __init__s need to be updated
[19:51] <tsimonq2> let me fix and do a test build locally
[19:51] <tsimonq2> kyrofa: it's optional, I'll update
[19:51] <kyrofa> tsimonq2, very good
[19:51] <netphreak> http://paste.ubuntu.com/18577482/
[19:52] <kyrofa> netphreak, yikes, yeah. Hmm... it's too bad I'm so unfamiliar with java, I'm not sure what's causing that
[19:52] <tsimonq2> kyrofa: I leanred something new today, I've never worked with *that* complex of Python :)
[19:53] <kyrofa> tsimonq2, the day is a waste without learning something new!
[19:53] <netphreak> Well, i guess everyone using this plugin will have the same problem as i have run into..
[19:53] <kyrofa> netphreak, does /etc/ssl/certs/java/cacerts actually exist?
[19:53] <tsimonq2> kyrofa: yep! :D
[19:54] <tsimonq2> kyrofa: http://paste.ubuntu.com/18577713/ - I'll start looking around for something obvious
[19:54] <tsimonq2> oh hm
[19:55] <kyrofa> tsimonq2, self.source_checksum
[19:55] <netphreak> nope.. seems the folder "/etc/ssl/certs/java/" is empty
[19:55] <kyrofa> tsimonq2, you might consider running ./runtests.sh static
[19:55] <tsimonq2> kyrofa: aha, that's right, because it's not called in the constructor
[19:56] <kyrofa> netphreak, default-jdk might include that
[19:57] <netphreak> Hmm.. I think the plugin includes a default java in the final snap...
[19:58] <netphreak> why this references a file that does not exist is a bit weird..
[19:59] <kyrofa> netphreak, because it's pulled in by openjdk-8-jre-headless
[19:59] <kyrofa> netphreak, which apparently contains an absolute symlink
[20:00] <tsimonq2> kyrofa: I think it would be good to ensure integration test coverage with source-checksum, right?
[20:00] <kyrofa> But these are stage-packages, so they don't go where they think they're going
[20:00] <kyrofa> tsimonq2, agreed
[20:00] <tsimonq2> kyrofa: the unit tests all passed (\o/) so I'll make sure integration tests pass, I'll whip that up, then I should be done
[20:01] <kyrofa> tsimonq2, nice job :)
[20:01] <tsimonq2> kyrofa: \o/ thanks :)
[20:02] <tsimonq2> kyrofa: and thank you so much for your help
[20:02] <kyrofa> tsimonq2, of course
[20:12] <tsimonq2> kyrofa: build is failing? huh? https://github.com/snapcore/snapcraft
[20:13] <kyrofa> tsimonq2, I don't see it failing...
[20:16] <kyrofa> elopio, wait... was this actually successful then? http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/1083/console
[20:16] <tsimonq2> http://storage2.static.itmages.com/i/16/0705/h_1467749818_7705696_1b78d50c7a.png
[20:16] <tsimonq2> kyrofa: that ^
[20:18] <mup> PR snapd#1490 opened: overlord: implement &Retry{After: duration} support for handlers <Created by pedronis> <https://github.com/snapcore/snapd/pull/1490>
[20:18] <netphreak> kyrofa: I just created the following bugreport: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1599281
[20:18] <mup> Bug #1599281: Snap upload automated review error <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1599281>
[20:19] <kyrofa> tsimonq2, ah, looks like test ran into a timing issue
[20:19] <kyrofa> tsimonq2, I requested a new run
[20:19] <tsimonq2> kyrofa: oh alright, I just thought that I should mention it
[20:19] <kyrofa> netphreak, very good, thank you!
[20:20] <tsimonq2> kyrofa: \o/ yes! finally! build passed!
[20:24] <elopio> kyrofa: http://paste.ubuntu.com/18579746/ did you touch something on the parser?
[20:24] <kyrofa> elopio, no
[20:25] <kyrofa> elopio, that's totally external to the snapcraft lifecycle, right?
[20:26] <elopio> kyrofa: yes. Maybe a timeout there, but not related to your change, so the execution is ok.
[20:26] <kyrofa> elopio, alright. I guess I need to update the branch anyway, so running again! Stop landing stuff, sheesh
[20:36] <tsimonq2> kyrofa: you think md5, sha256, and sha512 are good enough to support for checksumming or is there another format that people use that comes to mind?
[20:37] <kyrofa> tsimonq2, did you see sabdfl's comment on bug #1585913 ?
[20:37] <mup> Bug #1585913: Snapcraft should allow the user to verify downloaded files with a checksum <Snapcraft:In Progress by tsimonq2> <https://launchpad.net/bugs/1585913>
[20:38] <tsimonq2> kyrofa: no, I didn't catch that
[20:39] <tsimonq2> kyrofa: hmm, so is he saying to only support SHA3-384?
[20:39] <kyrofa> tsimonq2, honestly I'm not sure. Most often I see md5
[20:39] <kyrofa> tsimonq2, we probably want to support a range of things there
[20:40] <tsimonq2> kyrofa: yeah, which is why I'm asking
[20:40] <kyrofa> tsimonq2, so make sure 384 is supported
[20:40] <kyrofa> But I'd include the others as well
[20:40] <tsimonq2> kyrofa: alright
[20:40] <kyrofa> tsimonq2, make sure you have tests for each
[20:40] <tsimonq2> kyrofa: yeah currently, if my code works, we have md5, sha256, and sha512
[20:40] <tsimonq2> yep
[20:40] <kyrofa> tsimonq2, excellent
[20:41] <tsimonq2> kyrofa: I'm running my integration tests for those now, so I'm not entirely sure if it even works yet, lol
[20:42] <tsimonq2> kyrofa: would you suggest I respond to Mark in the bug report asking for clarification?
[20:43] <kyrofa> tsimonq2, sure, he won't bite.
[20:43] <tsimonq2> great :)
[20:50] <ogra_> tsimonq2, dont wear a tasty tempura crust though ...
[20:50] <tsimonq2> ogra_: huh?
[20:51] <ogra_> then he might bite ;)
[20:52] <tsimonq2> oh hahahaha
[21:00] <Croepha> so when I use stage-packages, is it actually downloading each time I run it? it looks like it is, is there a way to tell it to cache the downloads?
[21:08] <kyrofa> Croepha, they're pulled along with everything else in the pull step. Once the pull step has completed just don't run it again unless you need to add something to it
[21:09] <kyrofa> Croepha, for example, you can clean only back to the build step (snapcraft clean -s build) which will leave pull alone
[21:09] <kyrofa> Dangit ogra_ I'm hungry
[21:09] <Croepha> kyrofa: ok, got it, thanks :)
[21:13] <sergiusens> elopio so far https://github.com/snapcore/snapcraft/compare/master...sergiusens:refactor/push
[21:13] <sergiusens> still ways to go
[21:13] <sergiusens> i will bbl
[21:19] <tsimonq2> bug 1585913
[21:19] <mup> Bug #1585913: Snapcraft should allow the user to verify downloaded files with a checksum <Snapcraft:In Progress by tsimonq2> <https://launchpad.net/bugs/1585913>
[21:20] <tsimonq2> kyrofa: whoever is hacking on that bot should know that https://pad.lv/1585913 = https://launchpad.net/bugs/1585913
[21:23] <robert_ancell> ev, who's in charge of lp:rnrserver now?
[21:28] <thomi> sergiusens: did the way we load & run snapcraft plugins change between 2.11 and 2.12? I'm sure I used to be able to set a breakpoint in my plugin and have it work in 2.11. In 2.12 they seem to be ignored somehow?
[21:30] <tsimonq2> kyrofa: what does snapcraft/internal/sources.py:141:1: C901 'FileBase.check_checksum' is too complex (10) mean and how do I fix it?
[21:31] <tsimonq2> kyrofa: I'm assuming it means I have to dumb down my code?
[21:33] <thomi> tsimonq2: I believe it's the cyclomatic complexity check built into flake8  - https://en.wikipedia.org/wiki/Cyclomatic_complexity might help
[21:34] <thomi> tsimonq2: it's not really about 'dumbing down' your code, but rather limiting the complexity of any one function.
[21:34] <tsimonq2> thomi: I see
[21:34] <tsimonq2> there's a way I can make it simpler
[21:34] <tsimonq2> so I'll do that :)
[21:36] <Kamilion> yeah, if you're seeing that; you need to reorganize slightly; Ran into that while I was working on Customizer.
[21:37] <Kamilion> good to see you on changelogs though, tsimonq2. :)
[21:37] <tsimonq2> hey it's Kamilion! \o/
[21:37] <Kamilion> funnily enough, while I was doing work on checksumming files too.
[21:37] <tsimonq2> Kamilion: how'd you find me? lol
[21:37] <tsimonq2> hah yeah
[21:37] <Kamilion> w'dya mean? I've been here.
[21:38] <tsimonq2> Kamilion: I haven't seen you in ages :)
[21:38] <Kamilion> no longer in a release crunch
[21:38] <tsimonq2> oh?
[21:38] <Kamilion> well, 16.04's out now XD
[21:38] <tsimonq2> XD
[21:38] <Kamilion> i don't have to do another LTS job till 2018
[21:39] <Kamilion> and most of my papercuts were fixed between 15.04 and 16.04 WRT xen, openvswitch, and ceph.
[21:39] <Kamilion> Still can't get snapd to work from a livecd though
[21:39] <tsimonq2> Kamilion: so you here to submit code to Snapcraft, snap some things, support, what? just curious :)
[21:39] <tsimonq2> oh :(
[21:40] <Kamilion> as you know, I build appliance images
[21:40] <Kamilion> so everything was already running from the iso squashfs
[21:40] <tsimonq2> yeah
[21:41] <Kamilion> not sure if it's just unhappy about the rootfs being squash too or something else casper is tweaking when it boots the system.
[21:42] <Kamilion> that reminds me, i should say hi to walter when I get a chance
[21:42] <tsimonq2> Kamilion: *shrug* I don't know anything about that sort of thing :)
[21:42] <tsimonq2> I thought he's online?
[21:42] <Kamilion> probably is; I'm just in like 180 channels
[21:43] <tsimonq2> oh lol
[21:43] <Kamilion> and busy with several other projects as well
[21:43] <Kamilion> but i saw you talking when I was scrolling through the list and thought I'd say hi
[21:44] <tsimonq2> well I hope things are going well :)
[21:47] <Kamilion> if they weren't, I wouldn't be around ;)
[21:47] <tsimonq2> ;)
[21:51] <mwhudson> slangasek: hey, just pushed a patch from zyga to http://anonscm.debian.org/cgit/collab-maint/snap-confine.git/log/?h=debian
[21:51] <mwhudson> slangasek: otherwise i think that package is ready to go, what do you think?
[22:22] <ev> robert_ancell: OLS owns rnr as a team - what’s up?
[22:23] <robert_ancell> ev, was wondering if there's a plan regarding snap reviews. I thought that that would use the click API, but looking into it I'm not sure that's the case
[22:23] <robert_ancell> but 1574586 for reference
[22:23] <robert_ancell> bug 1574586
[22:23] <mup> Bug #1574586: Not able to rate/review snaps <Snappy:New> <gnome-software (Ubuntu):Triaged> <https://launchpad.net/bugs/1574586>
[22:24] <ev> robert_ancell: I don’t recall snap reviews coming up in vancouver or santa cruz. Has this found its way onto the roadmap?
[22:24] <robert_ancell> ev, no, I don't think it's on the roadmap either so was wondering if there's been any decisions either way.
[22:24] <robert_ancell> or if it should 'just work' with the click API.
[22:26] <ev> I don’t think it’d just work, but we can do a back of the envelope calculation if you need one
[22:28] <robert_ancell> ev, that would be handy, thanks
[22:30] <ev> sure thing