[00:17] PR snapcraft#912 opened: Add a gradle demo and test [00:20] PR snapcraft#652 closed: Demo/gradle [00:41] PR snapcraft#911 closed: Remove the outdated all snaps image set up for snaps tests === chihchun is now known as chihchun_afk [02:08] PR snapcraft#871 closed: Remove XXX comment from stage-packages [02:08] PR snapcraft#913 opened: help: update stage-packages and build-packages [02:29] PR snapcraft#914 opened: meta: icon is now dedeprecated [02:38] PR snapcraft#761 opened: Remove dangling symlink from JDK plugin [03:11] hello everyone, I just installed Ubuntu Snappy in Raspberry Pi3, However, I cannot build any packet such as apache2, sql, can someone help me please ??, I'm new in snappy [07:38] good morning [07:43] hey hey [07:47] bonjello [09:11] Bug #1620560 changed: Revert command doesn't reset the right apparmor profile

[09:56] tvoss: I think I understand it now [09:56] tvoss: testing a simple fix [09:58] is there a difference in what happens between [09:58] sudo snap install --devmode --force-dangerous mysnap.snap [09:58] and [09:58] sudo snap try path/to/mysnap/prime --devmode [09:58] ? [09:59] yes [09:59] tsdgeos: the difference is as follows: [09:59] tsdgeos: snap install copies the snap (across the connection) and installs it just as any other snap from the store (dangerous option means that some assertion are ignored) [09:59] tsdgeos: try on the other hand copies nothing and uses the directory indicated directly, ther'es a bind mount from that directory to /snap/$SNAP_NAME/$SNAP_REVISION [10:00] tsdgeos: you cannot remove that directory (rename it, break meta/snap.yaml) without some consequences [10:00] tsdgeos: the content is also live, you can change it and observe effects immediately [10:00] because i'm seeing what i think is a runtime difference, [10:00] do you think that's possible? [10:00] tsdgeos: at runtime, perhaps still, the directory might be writable [10:00] tsdgeos: I think we didn't fix that yet [10:00] tsdgeos: what do you observe? [10:01] matteo`: ping [10:01] Chipaca: pong [10:01] zyga: i think i'm seeing some dbus calls succeed in the install case and not in the try case [10:01] matteo`: what happened to docs/interfaces.md in your #2193 ? [10:01] tsdgeos: dbus is interesting, it is usually not affected by anything, can you show me the apparmor denial (journalctl | grep DENIED) please [10:02] Chipaca: isn't that moved to the wiki now? [10:02] ah! [10:02] :-) [10:02] zyga: and how is that kept in sync with the code? [10:02] ironically editing the wiki with git is nice :) [10:02] Chipaca: manually but the process is lighter [10:02] Chipaca: we should just poke people to edit it [10:02] zyga: so should there be a PR for the wiki for every PR that needs to update docs? [10:03] zyga: the thing is there's no denials, but i see code going further in one case than in the other, i think i'm wasting your time, let me do some more debugging, sorry for the noise [10:03] tsdgeos: no denials but things not working usually means seccomp [10:04] tsdgeos: but I have no context other than what you said just there [10:04] tsdgeos: do you have an encrypted home directory, or home directory in some non standard location [10:04] Chipaca: I found this? https://github.com/snapcore/snapd/blob/master/docs/MOVED.md [10:04] tsdgeos: I'm happy to help, bugs like this always show insight into what the real system is doing [10:04] matteo`: yep! sorry, i forgot about that move (see my conversation with zyga) [10:05] matteo`: but you're still on the hook for having the docs for this be in place once your branches land [10:05] matteo`: the up side is that you just hit the edit button and type away :) [10:05] matteo`: you can use git if you prefer [10:06] zyga: I wanted to edit the wiki only after the PR merge [10:06] otherwise I'll have documentation for a non existing feature [10:06] matteo`: that's fine, it's a wiki :D === matteo` is now known as matteo [10:07] matteo: just edit (you can say "PENDING merge" or something) [10:07] ok [10:07] matteo: it'd be nice to indicate "since snapd 1.2.3" actually [10:07] matteo: so you can just use the future version there [10:07] ok [10:08] matteo: rawusb is going to land in a few more minutes, unless i386 hates you [10:08] Chipaca: raw usb interface? [10:08] usb-raw [10:08] yes, direct usb access, eg. for sane [10:08] Chipaca: woot, I could use that for my test farm to drive some tools I have [10:09] (now if only 14.04 wasn't so mysteriously failing on the upgrade test) [10:09] zyga: woot at matteo; i'm just pushing it [10:09] thank you matteo :) [10:09] btw I have an example snap that uses it [10:09] it contains lsusb [10:09] zyga: and it might get renamed; jdstrand did ask niemeyer about the name, but that was 21 days ago [10:10] in snapd time that's past the statute of limitations1 [10:10] matteo: perfect, I was thinking about a libusb based flash tool for STM devices [10:10] Chipaca: that's like eternity ;0 [10:10] https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/examples/tree/usb-utils/snapcraft.yaml [10:10] precisely [10:10] do you have an STM MCU? Like STM324F? [10:11] zyga: this thing about me being able to push branches at PRs to unbreak them is terrible [10:11] matteo: yes, a few actually [10:11] matteo: I briefly worked on the lm4tools that can flash them [10:11] nice, I have some too [10:11] Chipaca: terrible or terrific? [10:11] did you flash them with gdb and openocd? [10:11] matteo: no, just lm4tools, it was way easier and I think, at the time, the only supported way [10:16] Chipaca: I alphabetizet everything in all.go and all_test.go, but you put NewAvahiObserveInterface after NewCupsControlInterface [10:16] how much time the autopkgtest need to run? [10:17] matteo: I don't think I did that? [10:17] NewAlsaInterface(), [10:17] NewAvahiObserveInterface(), [10:17] + NewBluetoothControlInterface(), [10:17] + NewCameraInterface(), [10:17] + NewCupsControlInterface(), [10:17] NewDcdbasControlInterface(), [10:18] in all_test [10:18] https://github.com/snapcore/snapd/pull/2193/commits/1b9586330a2bbdf7e3534fe3d511a86fa8871da3 [10:18] PR snapd#2193: add usb-raw iterface [10:18] matteo: gah [10:18] maybe you did indirectly, while merging [10:18] matteo: I noticed and fixed it in all.go, but missed it in all_tests.go [10:19] when merging, yes [10:19] matteo: I'll wait for all green, then fix this and wait for just spread green and land [10:19] matteo: unless you'd rather do it yourself [10:20] actually, this is strange [10:20] in all_tests locally i have it ordered [10:20] ah, no, wrong branch [10:20] * Chipaca is tracking too many right now [10:22] zyga: done the wiki [10:22] Chipaca: I'm for the "wait just for spread and merge" thing [10:24] zyga: you looked at 2249 before, could you +1 it if appropriate? [10:25] Hi I am thinking of making a snap of a java program I have written where would it be available I read something about a snappy strore but I can not find a trace of that? [10:28] Chipaca: checking [10:29] gerry_: the snap store doesn't have a web interface accessible from a non-snap system [10:29] gerry_: (you could install snapweb) [10:29] gerry_: the snap store is what `snap find foo` talks to [10:30] mvo: https://travis-ci.org/snapcore/snapd/jobs/176656727 [10:30] mvo: :-D [10:30] mvo: but also :-/ [10:33] ok so I am using ubunutu it has a new menu item called software as well as the ubuntu software center would it become available in that? [10:34] gerry_: yeah, "sofware" (not ubuntu software center) displays snaps and deb packages [10:35] ok thank you for your help one more question at the moment I have a jar with all dependencies (one library) contained in it would this be the best way to make a snappy package with the jar ? [10:41] gerry_: I'm not particularly familiar with java based snap, but you sohuld give a look at the jdk snapcraft plugin IMHO [10:41] ok thank you very much for your help [10:43] yw! keep us posted :) [10:47] tvoss: found one more issue, fixed it, trying [10:47] tvoss: we didn't enable the mount unit [10:48] tvoss: I switched the snapd-mount.sevice to a real snap.mount unit [10:48] tvoss: fingers crossed, it also mkdirs the /snap directory for free ;) [11:01] tvoss: ha, I think I begin to have something [11:01] tvoss: Nov 17 11:59:20 autopkgtest mount[20017]: mount: according to mtab /var/lib/snapd/snaps/core_394.snap is already mounted on /snap/core/394 as loop [11:01] tvoss: that's a lie, mtab is garbage [11:01] tvoss: I'll patch the test setup to rm /etc/mtab and use a symlink to see if that changes [11:10] zyga, +1, I'll another version of snapd into the ppa [11:10] zyga: did you push your most recent changes? [11:41] tvoss: no, none of them improve the state yet [11:42] zyga: ack, I'll push a new snapd package nevertheless [11:56] * zyga -> break [11:57] ogra_: Could you give me an update on where we are with https://bugs.launchpad.net/snappy/+bug/1639878? [11:57] Bug #1639878: pc-kernel.snap missing drivers necessary for Hyper-v [11:59] PR snapcraft#891 closed: repo: apt-mark new build-packages as automatically installed [12:05] tvoss: trying one more thing now [12:05] tvoss: I think systemd and /etc/mtab being a real file don't work [12:05] zyga: uploaded to ppa, waiting for accept/reject message [12:06] zyga: aha [12:06] tvoss: the rshared on / hides the issue somehow but not sure how [12:06] tvoss: the message I got was that systemd didn't do something it usually does (mount something) because it was apparently mounted (in the stale mtab file) [12:06] tvoss: it's all a bit shoot-in-the-dark though :/ [12:06] zyga: okay, let me find some help [12:12] tvoss: nope, didn't help - still digging [12:12] qemu:ubuntu-14.04-64 .../tests/upgrade/basic# systemctl status snap-core.mount [12:12] Loaded: error (Reason: No such file or directory) [12:19] zyga: I'm grabbing lunch, let's jump on a hangout with pitti right after that [12:23] tvoss: ok [12:26] tvoss: ah, silly me, the escaping causes my queries to systemd to give confusing messages === hikiko is now known as hikiko|ln [12:28] tvoss: let's talk here so that pitti can be in the loop [12:28] v+1 [12:29] tvoss: testing that new util-linux from ppa:pitti/systemd-semaphore [12:29] ack [12:32] okay, grabbing a quick bite [12:34] tvoss: no change [12:47] Chipaca: haha, thank you! [12:49] tvoss: thinking about what I'm seeing [12:49] tvoss: across restart we just lose all the .mount units [12:49] tvoss: is there anything that would keep them mounted? [12:50] zyga: across restart? [12:50] zyga: so that's snapd restart, correct? [12:50] tvoss: across snapd update [12:50] tvoss: that updates the package and runs some of the scripts [12:50] tvoss: (presumably the postrm / prerm ones [12:50] tvoss: I don't see anything starting mount units there [12:51] zyga: so snapd.postrm purge removes everything [12:51] hmmm, let me take a look at the actual test case [12:51] tvoss: I see a clear failure [12:51] the mount units are all stopped [12:52] hmm, but we don't purge, do we? [12:52] tvoss: is there an easy way to see the list of maintainer scripts / arguments across dpkg/apt transaction? [12:53] mvo: ^^ perhaps you know [12:53] zyga: /var/lib/dpkg/info has got all the scripts of all currently installed versions [12:54] zyga: I'm not sure I understand the question? do you want to see how they are called and in what order? [12:54] mvo: yes [12:54] mvo: something like that [12:55] mvo: when a package update occurs, what gets called and with what arguments [12:55] mvo: I understand some of the old scripts are called, then some of the new scripts are called [12:55] mvo: but details elude me [12:57] zyga: https://wiki.debian.org/MaintainerScripts has a flow diagram [12:57] zyga: the interessting one is "upgrading" [12:58] thanks [12:58] tvoss: I pushed my local patches, have a look [12:58] tvoss: some of those should be removed later (HACK) [12:58] looking [12:58] mvo: I see, it is quite "interesting" [13:00] tvoss: standup time for me [13:00] zyga: ack [13:01] zyga: probably makes sense if I join, too [13:01] do you have a link handy? [13:01] tvoss: sent [13:02] zyga: thx === JanC_ is now known as JanC [13:16] pitti: http://pastebin.ubuntu.com/23490458/ <- is this indicating the thing is mounted or not? === hikiko|ln is now known as hikiko === jhodapp_ is now known as jhodapp [13:23] Anybody on the snappy team seen this issue? Generally this resulted from me building my own snapd/snap and running that but now I want to use the system one installed via apt: http://pastebin.ubuntu.com/23490401/ [13:26] jhodapp from what I read mvo mentioning; your db got migrated so you cannot go back [13:27] sergiusens, is there a way I can start over? I don't care what's installed [13:27] jhodapp: yeah, sorry for that, please use the version of snapd in xenial-proposed that should be fine and compatible [13:27] jhodapp: starting over is also possible with "apt purge snapd" but its not really needed [13:27] jhodapp you misunderstand, I only said mvo mentioned, not that I can help you further than that ;-) [13:27] mvo, I tried apt purge snapd but that didn't seem to do it [13:28] sergiusens, heh :) [13:28] jhodapp: oh? what is leftover? did it fail? [13:28] mvo, let me try it again and get you the output [13:28] thank you [13:28] jhodapp: fwiw, we use purge in our tests to clean stuff up, so it should work in general, but maybe you hit some corner case (or we have another bug) [13:29] tvoss: that didn't change anything (not touching snap.mount in prerm) [13:29] mvo, here's the whole session: http://pastebin.ubuntu.com/23490516/ [13:29] interestingly [13:29] this is the journal for the core snap's mount unit [13:29] qemu:ubuntu-14.04-64 .../tests/upgrade/basic# journalctl -u snap-core-394.mount [13:29] -- Logs begin at Thu 2016-11-17 14:23:33 CET, end at Thu 2016-11-17 14:28:51 CET. -- [13:30] Nov 17 14:28:35 autopkgtest mount[19811]: mount: warning: /snap/core/394 seems to be mounted read-only. [13:30] that's it!, it's not unmounted here [13:30] I tried creating a sample snap using the tutorial on snapcraft.io (gnu-hello). On installing the snap created, it tried to connect to network ? [13:30] ah, unmount doesn't generate any logs, bummer [13:31] totally unrelated: I think I will snap up icq [13:31] is that still a thing? reminds me of windows 2000 and "I have a modem" days [13:32] tvoss: I patched the mount unit to be read only, inclined to add something to them to just see when it is being mounted/unmonted [13:32] unmounted* [13:33] pitti: anything I can add to a .mount unit to make it verbose? [13:34] zyga: it's actually open-source, and available for linux [13:35] zyga: distributed as a tar.xz containing a single executable [13:35] zyga: code is here: https://github.com/mailru/icqdesktop [13:35] tvoss: wow, is that the same "flower-logo" icq from two decades ago? [13:36] zyga: precisely that ;) [13:36] zyga: come on, install it, I wanna check if there is still the "uh-oh" sound :) [13:36] lol :) [13:36] mvo, any thoughts? [13:36] let's fix stuff to run on 14.04 first [13:36] then we can use icq as a trophy [13:37] jhodapp: yes [13:37] jhodapp: but sorry, was distracted by a meeting [13:37] zyga: sure [13:37] tvoss: I think I will follow niemeyer's advice and build a small test case to experiment and repdocude the behavior [13:37] mvo, np [13:37] jhodapp: could you please do a "ls -al ~/.snap" and pastebin that? [13:37] sure [13:37] tvoss: I still don't get what stops those units and why this happens on 14.04 but not on 16.04 [13:37] zyga: okay, I will instrument the maintainer scripts to be verbose and tell us what is actually called [13:37] tvoss: thanks [13:38] mvo, ls: cannot access '/home/jhodapp/.snap': No such file or directory [13:38] * mvo scratches head [13:39] lol [13:40] jhodapp: is there anything unusal about the system? coudl I get the output of "id ; env" please? [13:40] jhodapp: congratulations, welcome to the snappy team, you have just passed the secret test [13:40] ;) [13:40] zyga: no, inactive/dead says "not mounted" [13:40] jhodapp: welcome on board! [13:40] pitti: thanks! [13:40] zyga, hahaha [13:40] pitti: is there a way to see when systemd stops/starts mount units? (or just one for experiment) [13:41] zyga: verbose> a mount unit is just a wrapper around bin/mount, so you'll see its output in the journal; mount itself isn't very chatty, but you should certainly be able to see the effects of it? [13:41] jhodapp: the code tries to do a lookup of the current user but for some reason this fails here and I wonder how that could happen [13:41] pitti: I'm looking for "this is where that unit was stopped and something got unmounted" [13:41] zyga: sure, it's all in the journal; journalctl -f is useful [13:41] Starting Mount unit for core [13:41] Stopping Mount unit for core [13:41] mvo, http://pastebin.ubuntu.com/23490552/ [13:41] Chipaca: I see you talking about docs and git, etc. where is that branch? I need to add some stuff [13:42] pitti: hmm, is the 14.04 systemd doing that, I cannot see it [13:43] doesn't seem to be in https://github.com/snapcore [13:43] jdstrand: snapd wiki is a git repo, it's a github thing [13:43] oh I see the link now [13:43] * zyga tries and gets a quick coffee [13:44] funny, I just edited the wiki manually the other day [13:45] Chipaca: nm [13:46] * tvoss has test running with verbose maintainer scripts [13:46] jdstrand: sorry, was in a hangout [13:46] jdstrand: and then fixing a bug wrt resource consumption [13:47] (IOW getting lunch) [13:47] tvoss: first one that cracks this and fixes it gets a beer :) [13:47] no worries at all :) [13:47] zyga: ;) [13:49] jhodapp: I traced through the source and it looks like you get an EPERM in getpwuid_r() which is super strange. anything unusal about this system you are using? inside some container or anything else that might give a clue? [13:49] jhodapp: an strace -f -s1024 snap list would be nice as well, but I suspect the sudo you need for this will alter the behavior [13:49] mvo, nope, it's just my laptop running 16.04 [13:50] mvo, that requires sudo? [13:51] jhodapp: no [13:51] jhodapp: no, sorry [13:51] (too much stuff going on at the same time) === ben_r_ is now known as ben_r [13:51] mvo, http://pastebin.ubuntu.com/23490606/ [13:51] mvo, no prob [13:52] jhodapp: aha, there you go: "[pid 4186] open("/etc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)", what is "ls -al /etc/passwd"? [13:52] jhodapp: on your system? [13:53] mvo, -rw-r--r-- 1 root root 2954 Jul 7 09:17 /etc/passwd [13:53] jdstrand: any chance your are over ssh [13:53] er [13:53] jhodapp: ^ [13:53] jhodapp: and ssh is confining all the sessions with apparmor like jdstrand does [13:53] jhodapp: hmm, that looks fine, do you see something in "dmesg|grep DENIED" [13:54] zyga, nope, I'm at the keyboard...no ssh [13:54] jhodapp: its interessting, if I set it to 600 I get exactly the same error as you get [13:54] jhodapp: any evil maids with hypervisor malware in sight? [13:55] mvo, journalctl -f output for snap list: http://pastebin.ubuntu.com/23490617/ [13:55] pitti: since I don't get any of the stopping/starting messages on 14.04 does that mean I just don't have some journal glue to see this? [13:55] zyga, lol, I have kvm and virtualbox installed on this system, but neither are running [13:55] jhodapp: so we know now why it happens :) "Nov 17 08:54:51 smith audit[4327]: AVC apparmor="DENIED" operation="open" profile="/usr/bin/snap" name="/etc/passwd" pid=4327 comm="snap" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0" [13:56] jhodapp: waaat [13:56] profile="/usr/bin/snap" [13:56] that's not something we confine [13:56] zyga: exactly [13:56] jhodapp: can you look at /etc/apparmor.d/ and grep for /usr/bin/snap [13:56] jdstrand: ^ ? [13:56] yeah, one sec [13:57] jhodapp: sudo grep -r /usr/bin/snap /etc/apparmor.d [13:57] you have that evil maid somewhere [13:57] securing your snaps [13:57] I feel so protected [13:57] or the opposite, someone trying to make the system more secure :) [13:57] lol [13:57] mvo, http://pastebin.ubuntu.com/23490626/ [13:58] jdstrand: dpkg -S /etc/apparmor.d/cache/usr.bin.snap [13:58] er [13:58] sorry jdstrand, I hate irssi's tab completion [13:58] jhodapp: dpkg -S /etc/apparmor.d/cache/usr.bin.snap [13:59] maybe a missing conflicts with some other package [13:59] jhodapp, zyga: probably without the /cache/ ? [13:59] or missing maintainer script that removes that file when the package is removed [13:59] zyga, dpkg-query: no path found matching pattern /etc/apparmor.d/cache/usr.bin.snap [13:59] oh, I totally didn't see the cache part [13:59] hmmm [13:59] yep [14:00] jhodapp: which release are you on? [14:00] http://packages.ubuntu.com/search?searchon=contents&keywords=usr.bin.snap&mode=exactfilename&suite=yakkety&arch=any <- no hits [14:00] jhodapp: can you please pastebin that file [14:00] jhodapp: dpkg -S /etc/apparmor.d/usr.bin.snap please [14:01] zyga: I can't find anything in apt-file on xenial or yakkety [14:01] same here [14:01] curious [14:01] mvo, dpkg-query: no path found matching pattern /etc/apparmor.d/usr.bin.snap [14:01] :( [14:01] zyga, pastebin which file? [14:01] jhodapp: could you please pastebin /etc/apparmor.d/usr.bin.snap ? [14:01] yep [14:02] jhodapp: this is a really interessting issue you found! [14:02] since when is /usr/bin/snap confined? [14:02] lol, I didn't do anything fancy [14:02] jdstrand: it's not, something else is at play here and assumes the same name, perhaps one of the packages that conflict with snapd [14:02] jdstrand: this is what we are trying to figure out :) [14:03] mvo, http://pastebin.ubuntu.com/23490647/ [14:03] # Last Modified: Mon Oct 24 13:21:22 2016 [14:03] jdstrand, zyga -^ [14:03] what did you do on oct 24? [14:03] super strange [14:03] also the content is… very bare [14:03] did you write that file? who's the owner [14:04] I guess its root:root ;) [14:04] /etc/apparmor.d/cache/usr.bin.snap isn't going to be shipped by anything [14:04] /etc/apparmor.d/usr.bin.snap would be the thing that was shipped [14:04] jdstrand: apt-file knows about neither [14:04] mvo, -rw------- 1 root root 141 Oct 24 13:22 /etc/apparmor.d/usr.bin.snap [14:04] so weird [14:05] 600 is not typical [14:05] jhodapp: do you have anything in /var/log/apt/history.log* around that time? [14:05] what are the contents of /etc/apparmor.d/usr.bin.snap? [14:05] jhodapp: anything that got installed on that date/around this time? [14:05] jhodapp: anyway, fire your maid, remove that file, unload the profile with apparmor_parser -R usr.bin.snap # AFAIR [14:05] jdstrand: http://pastebin.ubuntu.com/23490647/ [14:05] * jhodapp checks [14:05] that looks like a test profile [14:06] not as in something we ship, but as in, what one might start with to see what it needed [14:07] pitti: any advice on journal / systemd on 14.04 [14:08] mvo, I installed apparmor-utils [14:08] jdstrand: could apparmor-utils have created profiles somehow? is there a command to auto-generate such profiles? [14:09] mvo, also dh-apparmor got pulled in from that [14:09] mvo: no, it wouldn't have done any magic like that [14:09] it too [14:10] did you run aa-genprof? [14:10] tvoss: I don't see any starting/stopping messages in syslog/journal on 14.04 [14:10] jdstrand, nope [14:10] tvoss: do you know how I can get that wired so that we have diagnostics? [14:11]