[00:04] elopio I've updated 629 [00:12] elopio 629 is the interesting one to be tested against the staging store [01:28] 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] niemeyer: ogra_: ? [01:38] MichaelTunnell: Yes to both [01:42] 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] or I can send you the test user password. [01:43] niemeyer: nice thanks for clarification [02:28] Bug #1598984 opened: snap list reports no snaps installed when invalid name passed [02:45] 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] PR snapcraft#629 changed: Proper message when registering an already registered snap [03:41] 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] Bug #1572399: [upload] Catch name registration issue and explain how [05:26] hey hey === chihchun_afk is now known as chihchun [07:07] PR snapd#1485 opened: snap: add `snap run --debug-shell` [07:09] o/ [07:16] PR snapd#1394 changed: debian: add snapd.postrm that purges [07:51] PR snapd#1486 opened: interfaces: add wireless-control [08:41] PR snapd#1481 changed: overlord: make patch1_test more robust [08:43] PR snapd#1487 opened: tests: set yaml indentation to 4 spaces === chihchun is now known as chihchun_afk === seb128_ is now known as seb128 [09:43] PR snapd#1462 closed: snapstate: cleanup downloaded temp snap files [09:55] PR snapd#1487 closed: tests: set yaml indentation to 4 spaces [10:47] zyga, mvo: hey, i was looking at the snap-confine package in the yakkety queue [10:47] where did the tarball come from? it doesn't seem to match the release on https://github.com/snapcore/snap-confine/releases [10:47] (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] 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] also also i'm going to bed [10:50] (package for debian in http://anonscm.debian.org/cgit/collab-maint/snap-confine.git/log/?h=debian fwiw) [10:51] mwhudson: hey [10:52] mwhudson: I'm not sure, I didn't' do the yakkety release, please definitely use the make dist one [10:53] zyga: the snap-confine-1.0.34.tar.gz is a make dist one? [10:53] (it looks like it to me) [10:53] mwhudson: yes [10:53] zyga: on https://github.com/snapcore/snap-confine/releases [10:53] mwhudson: libexecdir should stay as /usr/lib/snapd [10:53] mwhudson: (for various interesting reasons) [10:53] didrocks, btw - did that issues detecting gtk3 vs gtk2 on 64bit get fixed? [10:53] mwhudson: if you want I can make those changes and send you patches [10:55] zyga: i took that change [10:56] http://anonscm.debian.org/cgit/collab-maint/snap-confine.git/tree/debian/rules?h=debian#n22 [10:56] zyga: but thanks for confirming :-) [10:57] mwhudson: in .34 the config option changed to --disable-seccomp and --disable-apparmor [10:57] mwhudson: nice, thank you [10:57] zyga: ah ok, please send a patch for that :) [10:57] mwhudson: gladly [10:58] hi [10:58] gouchi: hey [10:58] it still built with --disable-confinement though, unless i goofed my build testing [10:58] I was wondering if those device will be part of opengl interface ? [10:58] http://www.hastebin.com/ixuyuduxaz.vhdl [10:58] mwhudson: that's odd, it definitely should not [10:58] mwhudson: cloning to test now [10:58] cool [10:59] * mwhudson really really going to bed now [10:59] ttyl [10:59] gouchi: let me check [10:59] mwhudson: bye! === hikiko is now known as hikiko|ln [11:01] PR snapd#1478 closed: many: Add device authentication skeleton [11:01] PR snapd#1488 opened: store: switch search to new snap-specific endpoint [11:03] gouchi: /dev/dri/dri0 is not in the opengl interface [11:04] 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] zyga: using intel gpu I tried to run retroarch in drm/kms with egl [11:05] zyga: https://github.com/libretro/RetroArch/wiki/KMS-mode [11:06] zyga: As I couldn't make it work with x11 interface, I tried with opengl interface [11:06] gouchi: this looks closer to the mir interface [11:07] 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] zyga: I will try thank you [11:07] gouchi: then the application using the new interface [11:08] 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] gouchi: in thise sense, you could use the new interface slot to grant that application to run with direct gpu access [11:09] zyga: this one https://github.com/snapcore/snapd/pull/1299 ? [11:09] PR snapd#1299: create mir interface [11:09] yes === chihchun_afk is now known as chihchun [11:28] PR snapd#1485 closed: snap: add `snap run --shell` [11:57] willcooke: yeah, it's fixed now [11:57] didrocks, thanks! [11:58] willcooke: just rebuild your snap if you didn't since Friday :) [11:58] running it now === hikiko|ln is now known as hikiko [11:59] willcooke: ensure you snapcraft update (I don't know how much it caches) [11:59] run* [11:59] ack [12:06] PR snapd#1473 closed: tests, integration-tests: port refresh all test to spread [12:16] zyga: better http://www.hastebin.com/dubevesula.coffee but I got fatal error [12:17] gouchi_: is that with mir or with a new interface? [12:18] zyga: mir interface [12:18] zyga: plugs: [network, network-bind, mir, opengl, home] [12:18] gouchi_: try slots: [mir] [12:18] gouchi_: mir slot let mir "be mir" and talk to GPUs and such [12:19] didrocks, yay! works. thank you!! [12:19] gouchi_: though you will probably need bleeding edge code from that branch [12:19] gouchi_: do you know how to rebuild snapd? [12:19] zyga: I followed https://github.com/snapcore/snapd/blob/master/README.md and build it [12:20] gouchi_: you can use github.com/zyga/devtools to use the new version easily [12:20] gouchi_: look at the refresh-bits script there [12:20] gouchi_: I wrote that for working on interfaces [12:21] zyga: I will try thank you very much [12:22] gouchi_: refresh-bits snap snapd setup run-snapd restore [12:22] gouchi_: (read the code to see what happens) [12:22] gouchi_: it also has useful --help [12:26] zyga: same error with slots: [mir] [12:29] willcooke: excellent! yw ;) [12:41] PR snapd#1458 closed: many: add `snap enable/disable` commands [12:41] PR snapd#1489 opened: snap: ensure unknown arguments to `snap run` are ignored [13:06] 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] operation="open" profile="snap.screenly-client.logger" name="/run/log/journal/a82c9efe141649b3983327aa20a8ed23/system@5b2dfcfdd13348ce82cbcf01123e4caa-000000000000064e-000536e30cc89344.journal" [13:07] 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] sborovkov, whare snapd version do you use? [13:14] seb128: snapcraft should be from last week I think. I did build the image before that I think though [13:15] sborovkov, snapd, not snapcraft [13:15] the snappy system service [13:15] not the build tools [13:15] Understood, how do I make it ouput the version? [13:16] on ubuntu "dpkg -l | grep snapd" [13:16] apt list snapd [13:16] :) [13:17] (so much nicer IMNSHO) [13:17] good to know [13:17] wait, I am on RPI [13:17] no dpkg [13:18] k [13:18] well anyway the journal interface got some fixes in 2.0.10 which is less than a week old [13:18] make sure you have this version [13:18] Understood [13:18] unsure about your RPI image [13:18] maybe mvo can help [13:18] My image is more recent, so might be that. [13:18] (snapd really needs a -v argument) [13:19] sergiusens: what's the easiest way for me to try your snapcraft pkg-config lookup patches when doing a cleanbuild? [13:26] 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] 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] 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] hem hem ;) [13:33] lalala ;-) [13:33] heh [13:34] 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] seb128, well, i see it in the gdk loaders dir [13:34] and i regenerate the loader cache on app startup [13:34] is it that one doing the decoding? [13:34] despite using the gtk theme engine in qt, it's qt itself doing the svg decoding [13:34] for instance [13:35] well, it is a java awt app [13:35] unsure if awt can decode svg [13:35] try shipping a corresponding .png image [13:35] well those work on normal desktop I guess [13:35] in the same directory than one icon it's using [13:36] that would be a known problem otherwise? [13:36] and see if it can open it [13:36] yeah, what about without devmode? [13:36] i only run without devmode ;) [13:37] and if you run your app directly? [13:37] like without the u-c-l wrapper? [13:38] if i run it as java -jar $path_to_jar i get icons [13:38] so thereis still some env var missing or so [13:38] did you try with the gtk launcher? [13:39] to see if it's something that you might miss [13:39] way to much overhead [13:39] well, try it at lest [13:39] least* === jdstrand_ is now known as jdstrand [13:39] but i'll tyr to grab bits from there [13:39] and you know, you can override some stage-packages [13:39] at least, try it and see [13:39] that will give you some hints [13:39] you are then welcome bringing a smaller one and contribute :) [13:39] rather than duplicating [13:40] * ogra_ is looking for the most minimal setup here [13:40] this is what I did with the new desktop launchers [13:40] the minimal required things for gtk/qt apps [13:40] but it seems it's been a couple of days you are stuck on this without even trying another one [13:41] just to ensure that the issue is larger than just missing dependencies [13:43] intellij IDEA is using java awt [13:43] and have working theme here [13:43] (since I switched it to my gtk launcher) [13:49] 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] (while /bin/sh is always guaranteed to be there) [13:50] ogra_: yeah, patch welcome, otherwise, it's on my list, but for later :) [13:50] yeah [13:50] 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] jdstrand: https://bugzilla.suse.com/show_bug.cgi?id=986050#c1 [13:51] jdstrand: and https://bugzilla.suse.com/show_bug.cgi?id=986050#c2 [13:51] ogra_, didrocks doesn't like to be limited by dash [13:51] heh [13:52] I'm used to dash, did a big part of porting years ago of our scripts to dash :) [13:52] but here, I just wanted something which works quickly :p [13:53] 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] ogra_: better to do just use dash, it's not user visible anyway [13:55] i was joking ;) [14:15] 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] oSoMoN, try didrocks' launcher instead [14:17] ogra_, is that the desktop/qt5 one? [14:17] yep [14:17] cool, will try that one [14:20] kyrofa mind quickly fixing https://github.com/snapcore/snapcraft/pull/622 ? [14:20] PR snapcraft#622: Hard-link local sources instead of symlinking them [14:20] sergiusens, yeah I'm working on it as we speak [14:20] kyrofa oh, nice :-) [14:21] PR snapcraft#630 closed: Report a nice error when registering too fast [14:23] sergiusens, super annoying... can't get it to happen locally :P [14:33] using x11, opengl, unity interfaces shouldn't make XOpenIM to failed ? [14:33] elopio, are you around? [14:35] ftp://www.x.org/pub/X11R7.7/doc/man/man3/XOpenIM.3.xhtml [14:36] sergiusens, look at this trace: http://pastebin.ubuntu.com/18546556/ [14:36] sergiusens, makedirs(..., exist_ok=True) -> "bam, that already exists!" -> death [14:37] 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] kyrofa sure, give me a sec [14:38] 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] Oh... wait... [14:39] sergiusens, nevermind, I'm stupid [14:40] sergiusens, that was way too hard [14:40] kyrofa what was it [14:40] ? [14:40] * didrocks is interested, I looked at the os code, and I see 2 protections against what you saw :) [14:41] kyrofa: hello [14:41] how can I help you? [14:42] 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] elopio, nevermind, sorry! [14:42] I will be glad if somebody can test my snap package to see if I am doing something wrong [14:42] here is the source : https://framadrop.org/r/vEimxEXgr2#SHwKK3R8qJ12soOacXboC+PbzNPvb/xPoijFaq7+e5s= [14:43] kyrofa: ahah, that explains! :) [14:44] didrocks, super confusing :P [14:44] 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] gouchi_: I can look but not tonight, I have plenty of things to finish [14:45] kyrofa heh, that's what you get for mocking ;-) [14:45] sergiusens, nothing is mocked! [14:45] 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] zyga: thank you no problem I can't find why it stops [14:46] kyrofa preparing the testbed/fixture would require you to make it absolute again though, right? [14:48] sergiusens, nah, it just copies the entire snap directory that contains the symlink already made [14:51] kyrofa: indeed :) [14:51] Man, I really want chromium on snappy [14:54] you can ... but only in devmode [14:58] 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] jdstrand: sure thing, I'll put it in the pipeline! [15:01] gouchi_, ogra_ was having the same XOpenIM issue, unsure if he solved it [15:01] well, i dont remember anymore [15:01] :) [15:01] roadmr: thanks! [15:02] (i remember i had it ...) [15:02] ah, no, i didnt .... that was when i tried to package servo [15:08] ogra_: I checked snappy playpen packages and only mpv is using XOpenIM [15:08] ogra_: but I doubt it using x11 code as mpv snap package is using only opengl interface [15:10] gouchi, does it work in devmode? [15:11] zyga, how do you test snap-confine, since it conflicts with u-c-l? [15:14] seb128: nope [15:14] 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] kyrofa: you install ubuntu-core-launcher too :) [15:16] kyrofa: snap-confine has two binary packages [15:16] kyrofa: one of them is snap-confine, the other is ubuntu-core-laucher [15:16] zyga, argh, missed that [15:16] Thanks :) [15:16] gouchi, I can try having a look if you want [15:16] seb128: I will be glad to, thank you very much [15:16] yw [15:22] elopio the current interface we have for pushing files makes me sad [15:25] zyga: I'm sure you'll know how to get an all-snap image for rpi2 :) [15:26] 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] zyga: thanks! hehe no problem, I'll walk to the future (also known as : waiting) X-) [15:27] roadmr: I think ogra_ might know more [15:27] roadmr: note that slangasek works on ubuntu-image so he might also know some useful thigns I dont [15:28] cool! yay, fwiw I'm happy to assemble my own image if pointed to tools/docs [15:28] well, the current images ... even if you buuild them newly .... are months outdated [15:28] i doubt any recent snaps would even work [15:28] ogra_: oh bummer, and there's no way to build one with recent components I reckon? [15:29] 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] haha :) [15:29] roadmr, the recent components are not in the store, ubuntu-core is ages old [15:29] ogra_: so for all real purposes I'm better off just using xenial with snapd? [15:29] we would need to update it first, but there are some blockers [15:30] yeah [15:30] just use a classic install [15:30] ok... I can do that, no problem :) [15:32] thanks ogra_ :) [15:47] sergiusens: do you mean, the store clients? [15:51] elopio _upload.py specifically [15:52] sergiusens: I agree. It doesn't match the others, and passing the client as an argument is a little spaghetti [15:52] sadly, I ended up with no good refactoring in mind for it. Do you have one? [15:52] elopio I think I am going to spend the rest of the week on a little refactor [15:52] \o/ [15:55] 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] that's on possibility [15:56] one other is that the other themes use svg files [15:56] which you don't have proper support for loading [15:56] yeah [15:56] i do [15:56] did you get the same behavior with the desktop launcher? [15:56] i have all pixbuf loaders and the loader cache is updated [15:56] is your snap available somewhere so I can have a look? [15:57] right [15:57] but java maybe doesn't use gdkpixbuf [15:57] like we tried with a qt app and were missing libqsvg or something [15:57] seb128, it works if i launch th jar directly [15:57] from outside the snap? [15:57] yes [15:57] right [15:57] just using the java on my desktop i get proper icons [15:58] anyway, is your snapcraft.yaml public? [15:58] so I can have a look [15:58] not the current version.. but it has only: [15:58] stage-packages: [15:58] - libglib2.0-0 [15:58] - hicolor-icon-theme [15:58] - openjdk-8-jdk [15:58] (i dont want *any* integration with the host here .... the app should ship and run everything standalone [15:58] ) [16:01] seb128, https://github.com/ogra1/jtiledownloader ... thats the one not usin any themeing [16:01] ogra_, k === chihchun is now known as chihchun_afk [16:02] 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] would easily rule out a class of issues [16:03] 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] also the XDG_DATA_HOME setting the launcher uses breaks awt/swing [16:04] niemeyer: here is why I've been asked so many random questions lately, https://youtu.be/0ApRUndiXKU [16:04] the app cant start [16:08] sergiusens: hi, have you thought any more about the python3 PR? are you still nervous about test coverage? [16:25] sergiusens, I think snapcraft#622 should be good now [16:25] PR snapcraft#622: Hard-link local sources instead of symlinking them [16:33] when creating a snap of webbrowser-app (which contains oxide), I’m seeing this: [16:33] Removing suid/guid from /build/webbrowser-app/snap/parts/webbrowser-app/install/usr/lib/x86_64-linux-gnu/oxide-qt/chrome-sandbox [16:33] this prevents oxide from functioning correctly [16:33] how can I prevent snapcraft from tempering with the suid/guid of the chrome sandbox? [16:34] joc_ I think it is ok [16:34] elopio mind taking a look at the python --root pr? [16:35] sergiusens: I'm out for swimming lessons. I'll do that on the way back. [16:36] elopio thanks [16:37] oSoMoN suid and guid would be blocked by apparmor and the review tools [16:37] jdstrand any alternatives there ^? [16:38] sergiusens, why remove the suid and guid then, if apparmor would block them anyway? [16:38] oSoMoN it was the nice thing to do before --devmode ever existed [16:38] sergiusens, ah ok, it predated --devmode, that makes sense [16:39] oSoMoN by a year almost [16:39] sergiusens, shouldn’t it be deprecated now? sounds like --devmode is much better suited [16:40] oSoMoN we still need to be able to auto remove the suidness somehow for people with confinement strict [16:40] oSoMoN I suppose we can tie this up to the `confinement` flag; mind logging a bug? [16:40] sergiusens, doing right away, against which project? [16:43] oSoMoN snapcraft [16:44] sergiusens, against the project itself, or against the source package? it seems there are existing bug reports targetting both [16:44] oSoMoN project, we always ask people to log against the project in the release ANN :-) [16:44] ok [16:48] sergiusens, https://bugs.launchpad.net/snapcraft/+bug/1599234 [16:48] Bug #1599234: should not remove suid/guid from binaries when confinement is devmode [16:49] * zyga -> supper, then more suse hacking [16:49] sergiusens: when's the next planned Snapcraft release? [17:00] Bug #1586581 changed: CAP_SYS_ADMIN interface for unconfined snaps [17:12] tsimonq2 today [17:12] MichaelTunnell: Nice! [17:13] sergiusens: oh ok [17:13] tsimonq2 why? [17:15] sergiusens: it really would have been great to land my latest PR before 2.12 but it's no big deal :) [17:15]