| mhall119 | kyrofa: sergiusens: is there anything that sets $TMPDIR when a snap is run? | 01:09 |
|---|---|---|
| kyrofa | mhall119, yeah, each app gets its own | 01:09 |
| mhall119 | kyrofa: what might such a value look like? | 01:10 |
| mhall119 | I ask because in pantheon-mail sqlite is trying to create temp files in /var/tmp/ and failing | 01:10 |
| kyrofa | mhall119, /tmp/snap.foo_bar_baz | 01:12 |
| kyrofa | mhall119, but it shows up to the snap as /tmp | 01:12 |
| kyrofa | mhall119, now that you mention it, I'm not sure anything is explicitly setting the TMPDIR var | 01:12 |
| kyrofa | We just make /tmp work correctly | 01:12 |
| kyrofa | So if sqlite defaults to /var/tmp is TMPDIR isn't set, that may be it | 01:13 |
| mhall119 | it does | 01:14 |
| mhall119 | according to https://www.sqlite.org/tempfiles.html#tempstore | 01:14 |
| mhall119 | can I do something like: TMPDIR=/tmp /snap/bin/pantheon-mail | 01:14 |
| mhall119 | or will the envvars be stripped out when the snap is run? | 01:14 |
| kyrofa | mhall119, you can do that, but it'll need to be in a wrapper somewhere | 01:20 |
| kyrofa | mhall119, soon that'll get easier, you'll be able to specify environments in the yaml, but not just yet | 01:20 |
| mhall119 | do you think it's worth putting in common gtk/qt desktop launcher parts? | 01:20 |
| kyrofa | (sorry for the delay, packing up my office for a cross-country move) | 01:20 |
| kyrofa | mhall119, if this problem is encountered enough, sure | 01:21 |
| mhall119 | presumably it will be encountered anywhere sqlite3 is used | 01:21 |
| kyrofa | Indeed | 01:21 |
| kyrofa | I just wonder if it'll cause problems for others | 01:22 |
| kyrofa | e.g. /var/tmp is different than /tmp, it's not cleared each boot | 01:22 |
| kyrofa | So some users might want TMPDIR to be, say, in $SNAP_DATA/tp | 01:23 |
| kyrofa | $SNAP_DATA/tmp rather | 01:23 |
| mhall119 | how about setting SQLITE_TMPDIR? I don't think sqlite expects them to persist between boots | 01:23 |
| kyrofa | SQLITE_TMPDIR seems a little specific to go in a generic part, but that's just me | 01:24 |
| kyrofa | Such an approach won't scale | 01:24 |
| mhall119 | well, you said there was an easier method on the way :) | 01:25 |
| kyrofa | Indeed | 01:25 |
| kyrofa | In the next snapd release, actually | 01:25 |
| kyrofa | Just waiting for it to get through SRU | 01:25 |
| kyrofa | Though snapcraft needs to support it too... not sure if sergiusens has done that yet or not | 01:25 |
| kyrofa | But to get up and running, a simple wrapper script is pretty easy | 01:28 |
| mhall119 | yup, and I've just verified that it fixes all my apparmor warnings | 01:29 |
| kyrofa | Very good | 01:30 |
| mhall119 | it isn't copying my sqlite database forward for new install revisions of the snap though :( | 01:30 |
| kyrofa | mhall119, and the DB is in $SNAP_DATA? | 01:30 |
| mhall119 | it's /home/mhall/snap/pantheon-mail/x2/.local/share/pantheon-mail/ | 01:31 |
| kyrofa | Ah interesting! A hidden dir | 01:31 |
| mhall119 | does /home/mhall/snap/pantheon-mail/x2/ map to an envvar? | 01:32 |
| kyrofa | Out of curiosity, can you force it to _not_ be hidden? | 01:32 |
| mhall119 | because it looks like something might be trying for $HOME/.local/share/ | 01:32 |
| kyrofa | Indeed, that's $SNAP_USER_DATA, but snapd also sets $HOME to that | 01:32 |
| kyrofa | You got it | 01:32 |
| mhall119 | and $SNAP_USER_DATA isn't copied? Or it this not being copied because it's a dotfile? | 01:33 |
| kyrofa | It is copied. The fact that the DB isn't makes me wonder if it's the dotfile, which would be a bug I'd say | 01:33 |
| kyrofa | Can you verify? Even if you just renamed the dir and installed a new rev | 01:34 |
| mhall119 | I'll give it a try and see, but might wait until tomorrow | 01:34 |
| kyrofa | Yeah it's a bit late for you | 01:35 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| dholbach | hiya | 06:44 |
| didrocks | hey dholbach | 06:47 |
| dholbach | salut didrocks | 06:47 |
| dholbach | does anyone know what to respond to http://askubuntu.com/questions/795139/ntp-synchronisation-in-ubuntu-core-10? | 06:47 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| zyga_ | ara: o/ | 07:49 |
| ara | zyga_, hey! | 07:53 |
| popey | morning all | 07:53 |
| mup | PR snapd#1501 opened: client: existing JSON fixtures uses tabs for indentation <Created by stevenwilkin> <https://github.com/snapcore/snapd/pull/1501> | 07:54 |
| === ant_ is now known as Guest59427 | ||
| mwhudson | has anyone looked at the snapd autopkgtest failures in yakkety? | 08:48 |
| zyga_ | mwhudson: hey | 09:15 |
| zyga_ | mwhudson: I did but didn't find anything, in fact I cannot reproduce them | 09:15 |
| zyga_ | mwhudson: I used a yakkety vm, got the package from proposed and ran kvm based autopkgtest | 09:15 |
| zyga_ | zyga: where is this damn session | 09:16 |
| mwhudson | zyga_: hm, i tried the same and the failed just a few seconds ago in fact | 09:16 |
| mwhudson | let's see if the failures looked similar | 09:16 |
| zyga_ | mwhudson: how did you run the test? | 09:16 |
| mwhudson | adt-run --unbuilt-tree . --- qemu ~/adt-yakkety-amd64-cloud.img | 09:16 |
| mwhudson | from a git tree checked out to the release tag | 09:16 |
| zyga_ | I ran something different | 09:16 |
| zyga_ | give me a sec | 09:17 |
| mwhudson | ~/adt-yakkety-amd64-cloud.img is what adt-buildvm-ubuntu-cloud -r yakkety spat out | 09:17 |
| mwhudson | (or whatever that command is called :-) | 09:17 |
| zyga_ | I haven't used adt in a while, just booting yakkety to paste the command I ran | 09:17 |
| mwhudson | heh | 09:18 |
| mwhudson | hmm i think i see fewer failures than on autopkgtest.u.c | 09:19 |
| mwhudson | "yay" | 09:19 |
| zyga | let me find my irc session | 09:19 |
| zyga_ | fg | 09:19 |
| === zyga_ is now known as zyga | ||
| zyga | woot | 09:19 |
| zyga | mwhudson: autopkgtest-buildvm-ubuntu-cloud -v -a amd64 -r yakket | 09:20 |
| zyga | y | 09:20 |
| mwhudson | oh well, that's not significantly different | 09:21 |
| zyga | autopkgtest snapd_2.0.10+16.10.dsc -- qemu | 09:21 |
| * zyga tries again | 09:21 | |
| mwhudson | oh no, i did get the same errors | 09:22 |
| mwhudson | as https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/s/snapd/20160707_052336@/log.gz | 09:22 |
| mwhudson | i got less output spam though, whatever that means | 09:22 |
| mwhudson | sigh failures in teardown | 09:24 |
| mwhudson | always a good smell | 09:24 |
| mwhudson | messages like "Unit snap-basic\x2dbinaries-x1.mount not found." make my have unicode paranoia | 09:25 |
| mwhudson | bug 1571721 | 09:25 |
| mup | Bug #1571721: Removing when an app is running results in a half removal <verification-done> <Snappy:Fix Committed> <snapd (Ubuntu):Fix Committed> <snapd (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1571721> | 09:26 |
| zyga | trying again | 09:30 |
| zyga | mwhudson: most interestingly, tests don't fail if you just run them | 09:32 |
| zyga | mwhudson: I mean from the tree | 09:32 |
| mwhudson | zyga: and they don't fail on xenial, right? | 09:32 |
| zyga | mwhudson: yep | 09:32 |
| zyga | mwhudson: one thing I didn't test, fully proposed update | 09:32 |
| zyga | mwhudson: I only ran this with yakkety + snapd from proposed | 09:33 |
| mwhudson | what's significantly different in yakkety? systemd, kernel i guess | 09:33 |
| mwhudson | ahhh hm | 09:33 |
| zyga | mwhudson: yep, just note that arch has the same version and it is all good there :/ | 09:33 |
| zyga | so ... hmm? | 09:33 |
| mwhudson | i think this is the key failure: | 09:33 |
| mwhudson | error: cannot perform the following tasks: | 09:33 |
| mwhudson | - Mount snap "basic-service" ([start snap-basic\x2dservice-x1.mount] failed with exit status 1: Warning: snap-basic\x2dservice-x1.mount changed on disk. Run 'systemctl daemon-reload' to reload units. | 09:33 |
| mwhudson | A dependency job for snap-basic\x2dservice-x1.mount failed. See 'journalctl -xe' for details. | 09:33 |
| zyga | hmm | 09:33 |
| mwhudson | i *think* all the rest is fallout from that | 09:34 |
| mwhudson | but i hardly know what is going on :) | 09:34 |
| zyga | what is the dependency job? | 09:34 |
| zyga | the fact that systemd says the unit changed on disk is not new in 230 | 09:34 |
| zyga | perhaps the dependency will tell us more | 09:34 |
| mwhudson | i should run it again in that mode that lets me ssh in afterwards | 09:34 |
| zyga | how do you do that? | 09:35 |
| mwhudson | --shell-fail | 09:35 |
| zyga | I'll replicate here and see what we get | 09:35 |
| zyga | thanks | 09:35 |
| zyga | running zyga@yakkety:~$ autopkgtest --shell-fail snapd_2.0.10+16.10.dsc --- qemu ~/autopkgtest-yakkety-amd64.img | 09:43 |
| mwhudson | zyga: i'm not completely sure what's happening now but i have this feeling my run is going to pass | 09:44 |
| zyga | do you know how regression tests are ran? is it with everything from proposed or just the one package? | 09:45 |
| zyga | and if it is the former, how can we replicate that? | 09:45 |
| mwhudson | i don't | 09:45 |
| mwhudson | and by editing the sources.list in the image, i assume | 09:45 |
| zyga | well, I can just upgrade to proposed and run tests locally | 09:46 |
| mwhudson | bah it failed but the --shell-fail magic did too somehow | 09:47 |
| zyga | my run is still in progress | 09:47 |
| mwhudson | zyga: <pitti> mwhudson: it tries to limit -proposed packages to just the trigger and its dependencies | 09:48 |
| mwhudson | <pitti> sometimes that doesn't work (stuff is uninstallable), then it falls back to enabling all of -proposed | 09:48 |
| mwhudson | zyga: i pasted your question in #ubuntu-quality btw | 09:48 |
| zyga | mwhudson: thanks! | 09:48 |
| zyga | hmm | 09:49 |
| zyga | well, we can try the full proposed one I guess | 09:49 |
| zyga | my tests are still ongoing | 09:49 |
| mup | PR snapd#1459 closed: daemon,overlord/auth,store: update macaroon authentication to use the new endpoints <Created by matiasb> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1459> | 09:51 |
| mwhudson | zyga: apparently a known intermittent thing, i'm running again | 09:52 |
| zyga | mwhudson: my run is still in progress, no failure yet | 09:53 |
| zyga | mwhudson: I really wonder if there's a difference between how we run tests | 09:54 |
| mwhudson | zyga: aaah the build failed this time! | 09:54 |
| mwhudson | FAIL: policy_test.go:103: policySuite.TestIterOpBadTargetdir | 09:55 |
| zyga | mwhudson: what's the rest of the error? | 09:55 |
| zyga | mwhudson: and can you reproduce that with the .dsc? | 09:56 |
| zyga | hmmmmm | 09:57 |
| zyga | mwhudson: I see it run ./get-deps | 09:57 |
| mwhudson | zyga: http://paste.ubuntu.com/18692046/ | 09:57 |
| zyga | mwhudson: I don't think that should ever be done in autopkgtests | 09:57 |
| zyga | isn't the whole idea to run tests from packaged bits | 09:58 |
| zyga | + ./get-deps.sh | 09:58 |
| zyga | Obtaining dependencies | 09:58 |
| zyga | reading... | 09:58 |
| mwhudson | hmmm | 09:58 |
| zyga | mwhudson: what is $HOME like? | 09:58 |
| mwhudson | don't know | 09:59 |
| zyga | so far it still hasn't failed for me | 09:59 |
| mwhudson | probably just /home/ubuntu | 09:59 |
| === hikiko is now known as hikiko|ln | ||
| zyga | still not failed | 10:01 |
| zyga | (my computer is slower :-) | 10:01 |
| zyga | ah, it failed now! | 10:02 |
| zyga | same way | 10:02 |
| zyga | error: cannot perform the following tasks: | 10:02 |
| zyga | - Mount snap "basic-binaries" ([start snap-basic\x2dbinaries-x1.mount] failed with exit status 5: Failed to start snap-basic\x2dbinaries-x1.mount: Unit snap-basic\x2dbinaries-x1.mount not found. | 10:02 |
| zyga | ) | 10:02 |
| mwhudson | hooray | 10:02 |
| mwhudson | i think | 10:02 |
| mwhudson | ok package build worked this time | 10:02 |
| zyga | hmm, the failshell instructions don't work for me | 10:03 |
| zyga | ok | 10:03 |
| zyga | let's try to fail this on native yakkety without adt so that tinkering is easier | 10:03 |
| zyga | eh, we should really replace the one dependency that needs bzr | 10:06 |
| zyga | pulling all of python2 | 10:06 |
| mwhudson | :) | 10:07 |
| mwhudson | zyga: yeah i think the get-deps.sh invocation would be better as cp -r /usr/share/gocode/src $tmp or something like that | 10:09 |
| mwhudson | to use the packaged version of the dependencies | 10:09 |
| zyga | yep | 10:10 |
| mwhudson | grrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr | 10:10 |
| zyga | ? | 10:13 |
| mwhudson | the --shell-fail failed again | 10:17 |
| mwhudson | i guess i should figure out how adt-virt-qemu runs the vm and do it by hand | 10:20 |
| mwhudson | but maybe not today | 10:20 |
| mup | PR snapd#1502 opened: Add an interface for tpm 1.2 <Created by jessesung> <https://github.com/snapcore/snapd/pull/1502> | 10:31 |
| dholbach | attente, do you know what to reply to http://askubuntu.com/questions/780670/i-cant-install-snap-packages-with-ubuntu-software-but-ok-with-terminal? | 10:38 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| netphreak | Do i need to set anything special in my snapcraft.yml, if my snap requires network access? | 11:19 |
| qengho | netphreak: yes | 11:20 |
| netphreak | anywhere i can see an example of that? | 11:20 |
| qengho | $ snap interfaces # list of plugs | 11:21 |
| gouchi | netphreak: https://github.com/snapcore/snapd/blob/master/docs/interfaces.md | 11:21 |
| qengho | In the app definition, "plug: [ network ]" | 11:21 |
| netphreak | thx | 11:23 |
| qengho | Hrm, I have a snap installed. I "snap install ./develomentsnap". I want to remove the devel version and return to the previous. How can I do that? | 11:31 |
| mup | PR snapcraft#635 opened: Fix parts cache handling <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/635> | 11:32 |
| mup | PR snapd#1503 opened: Set the snap price when listing available snaps <Created by stevenwilkin> <https://github.com/snapcore/snapd/pull/1503> | 11:34 |
| === hikiko|ln is now known as hikiko | ||
| mup | PR snapd#1504 opened: debian: chmod created config files to 0644 <Created by zyga> <https://github.com/snapcore/snapd/pull/1504> | 12:22 |
| mup | PR snapd#1505 opened: store: introduce a search grammar (baby step #1) <Created by chipaca> <https://github.com/snapcore/snapd/pull/1505> | 12:25 |
| sergiusens | kyrofa hey, is this only failing due to ros and friends? https://github.com/snapcore/snapcraft/pull/633 | 12:40 |
| mup | PR snapcraft#633: qmake plugin: Stop doing out-of-source builds <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/633> | 12:40 |
| mhall119 | kyrofa: zyga: is there a solution to the "clicking a URL in a snap doesn't open it in the browser" bug? | 12:52 |
| mup | PR snapd#1506 opened: store/auth: add helper for the macaroon refresh endpoint <Created by matiasb> <https://github.com/snapcore/snapd/pull/1506> | 12:57 |
| sergiusens | mhall119 there's a bug and attente was working on that | 12:58 |
| sergiusens | mhall119 I also raised the inverse, going from host to snap doesn't work as the mime handler doesn't seem to get registered. Hm, let me log a bug for that | 12:58 |
| seb128 | sergiusens, bug #1597417 | 13:00 |
| mup | Bug #1597417: Doesn't use "update-desktop-database" which is needed for mime handlers <snap-desktop-issue> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1597417> | 13:00 |
| mhall119 | sergiusens: how can we re-use the url-dispatcher that does this on the phone? | 13:00 |
| seb128 | you can maybe confirm it | 13:00 |
| mup | PR snapd#1507 opened: cmd: add buy command <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1507> | 13:00 |
| seb128 | mhall119, I don't think we need url dispatcher there, we have snapd-xdg-open in yakkety which is supposed to do that | 13:02 |
| seb128 | unsure if it works out of the box though | 13:02 |
| seb128 | that's also something that needs to be backported to xenial | 13:03 |
| mup | PR snapcraft#635 closed: Fix parts cache handling <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/635> | 13:05 |
| sergiusens | seb128 thanks | 13:09 |
| mhall119 | seb128: and that works based on the MimeType field in the .desktop files? | 13:13 |
| mup | Bug #1597417 opened: Doesn't use "update-desktop-database" which is needed for mime handlers <snap-desktop-issue> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1597417> | 13:13 |
| attente | seb128: besides backporting snapd-xdg-open, the fake xdg-open script needs to be inserted into the os snap | 13:16 |
| seb128 | mhall119, urls are special cases of mimetypes so I guess in some ways | 13:16 |
| seb128 | attente, that was done in yakkety? | 13:16 |
| kyrofa | sergiusens, I just merged with master, so I'll let you know | 13:18 |
| attente | seb128: i don't recall, i thought mvo took care of that part though | 13:18 |
| seb128 | k | 13:18 |
| seb128 | mvo, ^ do you know what's the status there? ;-) | 13:18 |
| seb128 | attente, thanks | 13:18 |
| mvo | attente: its in the os snap already (maybe not yet in stable? definitely in edge) | 13:25 |
| mvo | seb128: -^ | 13:26 |
| attente | mvo: ok, thanks. so i guess the only thing missing is backporting to x | 13:26 |
| seb128 | mvo, do we have an os snap installed on classic? | 13:26 |
| kgunn | yo, just updated y'day and i'm seeing an error on snap list | 13:26 |
| kgunn | known? | 13:26 |
| didrocks | seb128: yeah, we do | 13:26 |
| kgunn | error is "error: cannot list snaps: cannot unmarshal: json: cannot unmarshal string into Go value of type int" | 13:26 |
| mvo | seb128: yes | 13:27 |
| mvo | attente: people get it from the os snap, we don't need to backport it (unless I miss something) | 13:27 |
| didrocks | mvo: I don't find it r122: /snap/ubuntu-core/current$ sudo find . -name 'xdg-open' | 13:27 |
| attente | mvo: backporting snapd-xdg-open to xenial for the other half of that interaction | 13:27 |
| mvo | attente: if its not in stable yet (can check in a bit) it will be soon, we will get a new stable in the next few days | 13:27 |
| seb128 | didrocks, mvo, how do I see what it's in my os snap? snap list only includes ubuntu-core | 13:27 |
| didrocks | seb128: this is the os snap | 13:27 |
| mvo | seb128: 122 is stable, right? | 13:27 |
| attente | mvo: and also pulling it as a depends | 13:28 |
| seb128 | mvo, 122 of what? | 13:28 |
| seb128 | mvo, sorry i'm not familiar with your new world ;-) my knowledge goes as far as the snapd version installed my xenial and snap list/install and the ubuntu-core snaps | 13:28 |
| mvo | seb128: I will double check, I think r122 of ubuntu-core is the stable version that has n been updated in a while | 13:29 |
| kyrofa | sergiusens, nope, example tests are still busted | 13:29 |
| seb128 | mvo, ubuntu-core is the os snap? | 13:29 |
| mvo | seb128: yes, correct | 13:29 |
| seb128 | or are they different things | 13:29 |
| seb128 | ah ok | 13:29 |
| mvo | seb128: sorry for the confusion | 13:29 |
| seb128 | no worry | 13:29 |
| mup | PR snapd#1508 opened: cmd/snap,cmd/snap-exec: support running hooks via snap-exec <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1508> | 13:34 |
| attente | Chipaca: hey, for some reason, snapd still doesn't be returning an icon uri despite the snaps dpm uploaded being series 16 | 13:37 |
| dpm | Chipaca, https://launchpad.net/bugs/1588266 | 13:39 |
| mup | Bug #1588266: Almost no info about Krita snap in Ubuntu Software <amd64> <apport-bug> <xenial> <gnome-software (Ubuntu):Confirmed for attente> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1588266> | 13:39 |
| mup | PR snapd#1504 closed: debian: chmod created config files to 0644 <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/1504> | 13:43 |
| sergiusens | kyrofa which ones? | 13:49 |
| mup | PR snapd#1509 opened: interface: add new interfaces.all.SecurityBackends <Created by mvo5> <https://github.com/snapcore/snapd/pull/1509> | 13:51 |
| kyrofa | sergiusens, http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/1216/console, image creation failure seems like | 13:51 |
| kyrofa | fgimenez, any idea on that one? ^^ | 13:52 |
| fgimenez | kyrofa, looking | 13:52 |
| kyrofa | sergiusens, I think my last successful run was a few days ago at this point :P | 13:54 |
| gQuigs | hi there, I get an error message when I try running any snap: | 13:59 |
| gQuigs | $ snap run vlc | 13:59 |
| gQuigs | execv failed: No such file or directory | 13:59 |
| fgimenez | kyrofa, seems like a quota problem, there are two danglling instances, i'll try to identify and delete them, will ping you when done | 13:59 |
| kyrofa | Thanks fgimenez | 13:59 |
| gQuigs | $ snap run hello | 14:00 |
| gQuigs | 2016/07/07 09:59:44.531420 cmd_run.go:175: WARNING: cannot create user data directory: cannot create "/home/bryan/snap/hello/common": mkdir /home/bryan/snap/hello/common: permission denied | 14:00 |
| gQuigs | execv failed: No such file or directory | 14:00 |
| gQuigs | slightly better error with hello I guess.. | 14:00 |
| kyrofa | gQuigs, that's not typically how one runs apps | 14:00 |
| kyrofa | gQuigs, run stuff out of /snap/bin | 14:00 |
| kyrofa | (which should be in your PATH) | 14:00 |
| gQuigs | kyrofa: hmm.. then it's not obvious how to run some... | 14:02 |
| gQuigs | kyrofa: for example, run hello and it says not installed | 14:02 |
| gQuigs | and what if I have both vlc snap and vlc deb installed? how to pick? | 14:02 |
| kyrofa | gQuigs, is hello installed? | 14:03 |
| gQuigs | $ /snap/bin/hello | 14:04 |
| gQuigs | Hello, world! | 14:04 |
| gQuigs | $ hello | 14:04 |
| gQuigs | The program 'hello' can be found in the following packages: | 14:04 |
| kyrofa | gQuigs, is /snap/bin in your PATH? | 14:04 |
| fgimenez | kyrofa, should be fixed now | 14:05 |
| kyrofa | Thanks fgimenez, re-running now | 14:05 |
| gQuigs | kyrofa: nope, it's not.. swear it was.. hmm | 14:05 |
| kyrofa | gQuigs, hmm indeed | 14:06 |
| gQuigs | with path set, hello works | 14:08 |
| gQuigs | but snap run still doesn't.. should that work? | 14:09 |
| netphreak | How can i see what version of snapcraft and snap i installed? | 14:09 |
| niemeyer | jdstrand: Heya | 14:09 |
| niemeyer | jdstrand: Do you need any state currently in Spread-B? | 14:09 |
| gQuigs | netphreak: does --version not work for you? | 14:09 |
| niemeyer | jdstrand: We're having some connectivity issues between the freemont DC and Google services, so I'm moving it out to a different DC | 14:10 |
| seb128 | mvo, sergiusens, what would the way to get the attention of the snappy team on bug #1597417? it's probably an easy one but I don't know if it needs team discussion on possible security impact or something | 14:11 |
| mup | Bug #1597417: Doesn't use "update-desktop-database" which is needed for mime handlers <snap-desktop-issue> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1597417> | 14:11 |
| seb128 | it's important to make desktop applications useful | 14:12 |
| seb128 | like I've evince in a snap but it's not very useful if you can't get it to be used when clicking on a pdf in nautilus | 14:12 |
| gQuigs | kyrofa: so for VLC the deb takes precedent (based on how I did path). Should snap run work is that deprecated? | 14:12 |
| kyrofa | gQuigs, snap run will be how snaps are run behind the scenes, but you should never have to run it. You should be running things out of /snap/bin | 14:13 |
| kyrofa | gQuigs, it's an implementation detail | 14:14 |
| kyrofa | gQuigs, and I'm not sure that it actually works in the version of snapd released currently-- it's finished in the one being released now | 14:14 |
| kyrofa | gQuigs, so for a consistent experience, use /snap/bin/ | 14:15 |
| netphreak | How do i upgrade to the latest snapd 2.0.10? I'm on apt-get | 14:15 |
| sergiusens | seb128 I have the same problem when clicking on telegram.me links ;-) | 14:15 |
| mvo | seb128: what needs to happen? does snapd needs to just run update-desktop-database after new desktop files got created? | 14:16 |
| gQuigs | kyrofa: so I should eventually work ? | 14:16 |
| kyrofa | gQuigs, yes, but again, you should never need to use it directly | 14:17 |
| jdstrand | niemeyer: no-- I can -discard now if that makes things easier for you | 14:17 |
| niemeyer | jdstrand: Ah, yes please, thanks! | 14:17 |
| seb128 | mvo, yes | 14:17 |
| jdstrand | niemeyer: but when can I start up a new one with -keep? | 14:17 |
| niemeyer | jdstrand: Feel free to pick another one when you need | 14:17 |
| niemeyer | jdstrand: Immediately | 14:18 |
| gQuigs | kyrofa: thanks! | 14:18 |
| niemeyer | jdstrand: Hopefully I'll be faster and nuke the machine before you grab it again :) | 14:18 |
| niemeyer | jdstrand: There are other machines available on the new DC already | 14:18 |
| jdstrand | niemeyer: discarded | 14:18 |
| seb128 | mvo, the mimetype handlers look into indexes and that dir doesn't have one so its entries are not registered | 14:18 |
| seb128 | mvo, just doing the update command makes it work | 14:18 |
| niemeyer | jdstrand: Thanks, removed.. will re-allocate new ones with the same names on the new DC | 14:19 |
| jdstrand | niemeyer: I'm not sure you saw, but between README.md and a really nice cli, spread is literally the easiest testing infrastructure I've ever used | 14:19 |
| niemeyer | jdstrand: Wooo, that's great to hear! Thanks! | 14:19 |
| jdstrand | really nice. I was writing spread tests in just a few minutes | 14:19 |
| jdstrand | granted, I was using an existing project with spread.yaml, but still. good stuff :) | 14:20 |
| attente | seb128: mvo: how should we backport snapd-xdg-open to xenial? should i reuse this sru? https://bugs.launchpad.net/snappy/+bug/1580740 or file a new one against the package? | 14:21 |
| mup | Bug #1580740: [SRU] Cannot open a browser link from a snap that provides a link <snap-desktop-issue> <Snappy:Triaged> <https://launchpad.net/bugs/1580740> | 14:21 |
| jdstrand | niemeyer: oh and -debug is fantastic | 14:21 |
| seb128 | attente, that SRU bug should do the trick | 14:21 |
| niemeyer | jdstrand: Yeah, I was very pleased with that one as well. So convenient to be able to jump in at the exact breakage | 14:22 |
| jdstrand | totally | 14:22 |
| attente | seb128: thanks! | 14:23 |
| seb128 | attente, yw! | 14:24 |
| jdstrand | niemeyer: at some point I want to try it with lxd. oh, that reminds me-- I guess it is possible to have two different backends and then spread -list would just prefix them accordingly? what happens if say a project has linode and lxd, and you have lxd and I don't? | 14:25 |
| attente | seb128: could you please sponsor it for xenial? or should i subscribe ubuntu-sponsors? | 14:25 |
| jdstrand | niemeyer: fyi, I have Spread-E now | 14:26 |
| niemeyer | jdstrand: Right.. it'll try to run all backends by default, but you can easily tell what to run at the CLI.. e.g. linode: | 14:26 |
| niemeyer | jdstrand: Ack | 14:26 |
| niemeyer | jdstrand: That is, $ spread <options> linode: | 14:27 |
| niemeyer | jdstrand: Then it'll run only things in Linode | 14:27 |
| jdstrand | niemeyer: if a project has both linode and lxd, but I don't have lxd, do that cause a usability issue for me or will spread just skip those? | 14:27 |
| jdstrand | eg, if I just call 'spread' | 14:27 |
| niemeyer | jdstrand: It'll try to run lxd, error out because it can't, mark the specific jobs that should run under lxd as aborted, but otherwise continue with all the rest | 14:28 |
| jdstrand | I see. ok, thanks | 14:28 |
| niemeyer | jdstrand: That's the main distinction between aborted and failed, btw.. aborted means "didn't even try" | 14:28 |
| jdstrand | ah, yes. that makes sense | 14:29 |
| jdstrand | I was trying to wrap my head around how useful it would be to add lxd backends to things and how that might affect people | 14:29 |
| jdstrand | I'm not actively working on that-- just was curious | 14:30 |
| mvo | seb128: thanks, that sounds pretty straightforward | 14:38 |
| niemeyer | jdstrand: I have a background idea that I haven't quite designed yet, but which might fit with what you describe | 14:38 |
| niemeyer | jdstrand: I'd like a way to mark certain tests as "manual".. | 14:38 |
| niemeyer | jdstrand: IOW, should only fire when explicitly requested | 14:39 |
| jdstrand | right | 14:39 |
| niemeyer | jdstrand: Need to find a way to blend that into the default job matching behavior in a non-awkward way | 14:39 |
| jdstrand | yeah, that would definitely work for this use case so long as it could be applied to backends as well as tests and suites | 14:40 |
| jdstrand | which in saying that, I see what you mean be it needing some design :) | 14:41 |
| niemeyer | jdstrand: Yeah, it'd need to work in a similar way to everything else.. cascading through the matrix | 14:41 |
| jdstrand | cool | 14:41 |
| niemeyer | Might be just a test in a suite, or a suite, or whole backend | 14:41 |
| jdstrand | anyway, I'm not using lxd just yet here for that, but I was excited to see it as a backend | 14:42 |
| niemeyer | I want to support kvm soon as well. There was some difficulties in finding the ip the machine fired with, but ogra_ gave some ideas. | 14:43 |
| seb128 | mvo, thanks | 14:43 |
| mup | PR snapd#1431 closed: cmd,interfaces,snap: implement hook whitelist <Reviewed> <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1431> | 14:53 |
| seb128 | attente, sorry, day is a bit crazy and i'm off tomorrow ... please subscribe sponsors and maybe see if mvo wants to sponsor the SRU, I think he did the yakkety upload? otherwise I have a look on monday | 14:58 |
| mup | PR snapd#1510 opened: integration-tests: remove login tests <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1510> | 15:01 |
| mvo | attente, seb128: sure I can sponsor, just ping me | 15:02 |
| seb128 | mvo, great, thanks! | 15:02 |
| zyga | jdstrand: I wrote a spread test for the apparmor profile | 15:05 |
| zyga | jdstrand: just testing it and I'll add it to the pull request | 15:05 |
| zyga | jdstrand: you said you want to have another thing in .36? | 15:05 |
| zyga | jdstrand: can you be more specific please? | 15:05 |
| jdstrand | zyga: I want only that in .36 | 15:09 |
| jdstrand | I mean, other things can be there, but we need to make sure we don't lose confinement for the next ubuntu upload | 15:09 |
| zyga | jdstrand: .35 was released, .36 is today | 15:10 |
| jdstrand | zyga: right. what I mean is that .35 is where I noticed the profile attachment bug you are working on. afaic, we need to only fix that bug for .36. then .36 can go to ubuntu | 15:12 |
| attente | mvo: thanks! is there anything you need from me for the sru? | 15:12 |
| zyga | ah, ok | 15:12 |
| zyga | so there's nothing else you want to fix? | 15:12 |
| zyga | what about the nodev thing that was also mentioned by SUSE folks? | 15:13 |
| jdstrand | zyga: I do have something I was working on but it doesn't have to be for .36 | 15:16 |
| zyga | ok | 15:16 |
| zyga | sounds good then | 15:16 |
| jdstrand | zyga: for the nodev, that was actually a question for /tmp being user-owned, but that got me thinking snap-confine probably should think about nodev and nosuid for some of those mounts, but that is a hardening measure since the things being mounted are not user-controlled, correct? Does this have the content interface changes? If so, those mounts should absolutely by nodev and nosuid | 15:18 |
| jdstrand | zyga: ok, phew, I see in sc_setup_mount_profiles that MS_NODEV and MS_NOSUID are used | 15:21 |
| ogra_ | hmm | 15:23 |
| ogra_ | sergiusens, wouldnt it make sense if the make plugin would install a compiler by default (and put the cc and gcc links in place automatically) ? | 15:24 |
| zyga | yes, the user mounts are safe | 15:25 |
| zyga | those that are controlled by the user | 15:25 |
| zyga | but remember that all you need to do is to ship a snap with /dev/sda node | 15:25 |
| * ogra_ notes that he has to put ([ -e /usr/bin/cc ] || ln -s /usr/bin/gcc-5 /usr/bin/cc) and ([ -e /usr/bin/gcc ] || ln -s /usr/bin/gcc-5 /usr/bin/gcc) into his makefiles ... | 15:25 | |
| zyga | and you're good :-( | 15:25 |
| ogra_ | and i have to put gcc-5 into build-files | 15:25 |
| ogra_ | err build-packages | 15:25 |
| sergiusens | ogra_ not make, but autotools and cmake yes | 15:34 |
| ogra_ | why not make ? | 15:34 |
| jdstrand | niemeyer: I have a potentially dumb question re environment and spread. I'm try to do: | 15:34 |
| sergiusens | ogra_ there are a bunch of examples where people use make as they would use the copy plugin | 15:34 |
| jdstrand | environment: | 15:34 |
| jdstrand | CORESNAP: $(mount | grep ubuntu-core | tail -1 | cut -f 1 -d ' ') | 15:35 |
| jdstrand | execute: | | 15:35 |
| jdstrand | ... | 15:35 |
| ogra_ | sergiusens, yeah, i have done that too ... but still, gcc is broken if you depend on it | 15:35 |
| jdstrand | echo "CORESNAP=$CORESNAP" | 15:35 |
| jdstrand | ... | 15:35 |
| sergiusens | ogra_ as a build-packages? | 15:35 |
| ogra_ | sergiusens, the needed symlinks are alternatives ... | 15:35 |
| ogra_ | yeah | 15:35 |
| jdstrand | niemeyer: but $CORESNAP is empty | 15:35 |
| jdstrand | niemeyer: the is in task.yaml | 15:35 |
| ogra_ | sanpcraft doesnt run postinsts ... so the symlinks are missing | 15:35 |
| sergiusens | ogra_ build-packages do run postinsts | 15:36 |
| sergiusens | what are you talking about? | 15:36 |
| ogra_ | well, not here | 15:36 |
| sergiusens | there are a bunch of tests for this | 15:36 |
| jdstrand | niemeyer: if I do under execute: echo "CORESNAP=$(mount | grep ubuntu-core | tail -1 | cut -f 1 -d ' ')" I see what I want | 15:36 |
| sergiusens | ogra_ use build-packages, not stage-packages | 15:36 |
| ogra_ | i tried to make all my packages "cleanbuild" safe today | 15:36 |
| ogra_ | and all of them are missing these links | 15:36 |
| jdstrand | niemeyer: I can sprinkle that command around and am not blocked, but it seems like environment should be able to handle this | 15:36 |
| ogra_ | sergiusens, https://github.com/ogra1/nethack/blob/master/snapcraft.yaml ... | 15:37 |
| ogra_ | sergiusens, same for https://github.com/ogra1/upnp-server/blob/master/snapcraft.yaml | 15:38 |
| ogra_ | (and a few others i havent public yet) | 15:38 |
| sergiusens | ogra_ ah you are explicitly installing gcc-5, that won't create the gcc link you want | 15:38 |
| ogra_ | if i use gcc-5 in build-packages there are definitely no alternative links set | 15:38 |
| ogra_ | it does if i install gcc-5 on a normal desktop | 15:39 |
| sergiusens | ogra_ because you have gcc installed as well | 15:39 |
| ogra_ | hmm, let me try to move to plain "gcc" | 15:39 |
| ogra_ | mvo, in case you do manual image builds. please note the new EXTRA_PPAS entry in crontab | 15:40 |
| ogra_ | ( i changed that yesterday ,,, forgot to tell you about it) | 15:41 |
| ogra_ | sergiusens, bah, and indeed you are right :P | 15:46 |
| * ogra_ goes and fixes all branches again ... mental note: ask first next time before writing a workaround | 15:47 | |
| sergiusens | ogra_ iirc gcc has the alternative stuff and didrocks told me we install it by default on desktop now too | 15:47 |
| ogra_ | we always did | 15:47 |
| ogra_ | it is a requirement of dkms | 15:47 |
| ogra_ | (and before it was a req. for nvidia drivers and the like ... when they still got compiled at install time) | 15:48 |
| ogra_ | but tthat doesnt help with cleanbuild :) | 15:48 |
| mup | PR snapcraft#622 closed: Hard-link local sources instead of symlinking them <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/622> | 15:54 |
| === chihchun is now known as chihchun_afk | ||
| kyrofa | Yay! | 16:01 |
| mup | Bug #1599919 opened: SnapOpSuite unit tests interfere with the user's $HOME/.snap directory <Snappy:New> <https://launchpad.net/bugs/1599919> | 16:03 |
| niemeyer | jdstrand: One particularity of environment is that $() executions run locally rather than remotely.. I might move that behavior out into a separate field as it's probably unexpected | 16:10 |
| niemeyer | jdstrand: Right now that's how we can provide secrets and local info in general to the tests | 16:11 |
| jdstrand | I see | 16:11 |
| jdstrand | ok, well, like I said, I'm not blocked | 16:11 |
| jdstrand | thanks for the explanation | 16:12 |
| niemeyer | np | 16:12 |
| mup | PR snapcraft#636 opened: parser - Handle malformed wiki entries <Created by josepht> <https://github.com/snapcore/snapcraft/pull/636> | 16:30 |
| mvo | ogra_: thanks for the heads up | 16:32 |
| mup | PR snapd#1511 opened: overlord: actually run hooks <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1511> | 16:32 |
| mvo | attente: if you could prepare it so that I just need to dput the sru that would rock of course, if not just let me know | 16:33 |
| attente | mvo: sure | 16:38 |
| attente | mvo: i literally just changed the release to xenial and the date in the changelog: https://launchpad.net/~attente/+archive/ubuntu/snapd-xdg-open/+packages | 16:50 |
| attente | (from the yakkety one) | 16:50 |
| === JanC is now known as Guest55200 | ||
| === JanC_ is now known as JanC | ||
| === olli_ is now known as olli | ||
| zyga | mvo, attente: can we please do an upstream release of snapd-xdg-open | 17:07 |
| zyga | we really want it everywhere, not just ubuntu | 17:07 |
| zyga | if you want I can look at this | 17:09 |
| mup | PR snapd#1512 opened: overlord: initial work on renaming core snap <Created by zyga> <https://github.com/snapcore/snapd/pull/1512> | 17:15 |
| sergiusens | kyrofa this is good to go https://github.com/snapcore/snapcraft/pull/632 | 17:15 |
| mup | PR snapcraft#632: WIP Refactor/push <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/632> | 17:15 |
| attente | zyga: sure, but i don't have push access to that repo. i think mvo does however? | 17:16 |
| kyrofa | sergiusens, looks like it needs to be merged with master | 17:22 |
| sergiusens | kyrofa really, again? | 17:23 |
| sergiusens | kyrofa there you go | 17:23 |
| kyrofa | sergiusens, thank you! Also consider changing the title | 17:24 |
| sergiusens | kyrofa so pushy, I was going to change it while merging :-P | 17:24 |
| sergiusens | kyrofa there you go | 17:25 |
| kyrofa | sergiusens, I know you. You'll forget, and then our history will be hilarious | 17:25 |
| zyga | jdstrand: I've updated snap-confine#73 | 17:26 |
| mup | PR snap-confine#73: Update apparmor profile for snap-confine <Created by zyga> <https://github.com/snapcore/snap-confine/pull/73> | 17:26 |
| zyga | jdstrand: I didn't rename policy file because I think this simply belongs in downstream packaging and it is more and more evident | 17:27 |
| tsimonq2 | what sort of unit test coverage should I seek for my PR? ( snapcraft#619 ) | 17:27 |
| 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:27 |
| tsimonq2 | integrated in the Tar and Zip classes or in it's own class? | 17:28 |
| tsimonq2 | kyrofa: ^ | 17:28 |
| kyrofa | tsimonq2, taking a look now | 17:29 |
| jdstrand | zyga: re rename> well, it depends-- where does make install put it? if the default is to /usr/lib/snapd/snap-confine then the name should reflect that | 17:29 |
| tsimonq2 | thanks kyrofa | 17:29 |
| jdstrand | zyga: alternatively, skip all that and just rename to 'snap-confine' | 17:29 |
| jdstrand | zyga: the only thing apparmor cares about is what's inside | 17:30 |
| zyga | jdstrand: I'd simply put it in src/apparmor-profile.in | 17:30 |
| zyga | jdstrand: and have the makefile generate the real one | 17:30 |
| jdstrand | that works too, but then update the debian/ packaging | 17:31 |
| zyga | jdstrand: downstream packaging will be doing the rename | 17:31 |
| zyga | jdstrand: yep, I will have to do it for debian and ubuntu then | 17:31 |
| zyga | jdstrand: just a reminder, I will try to remove debian entirely from the tree so that we can do real tests against real packaging in debian/ubuntu | 17:31 |
| zyga | jdstrand: right now debian/ is not used anywhere for real | 17:32 |
| kyrofa | tsimonq2, actually I think your units look pretty good. I'd check the coverage, though (do you know how to do that?) | 17:34 |
| kyrofa | tsimonq2, however, while you have an integration test snap, you don't have an integration test. Are you working on that? | 17:34 |
| kyrofa | Because that will be important | 17:35 |
| tsimonq2 | kyrofa: so do you think my integration tests need to be added to the tar and zip tests or it's own test? | 17:35 |
| kyrofa | tsimonq2, oh I see what you're asking | 17:35 |
| kyrofa | tsimonq2, I say add them to tar and zip | 17:37 |
| tsimonq2 | kyrofa: okay, so it's in the snap, I need to add to the python? | 17:37 |
| kyrofa | tsimonq2, so add some more to the simple-zip snap, then add checks to the integration tests that use simple-tar and simple-zip | 17:37 |
| kyrofa | tsimonq2, exactly | 17:37 |
| kyrofa | tsimonq2, I'm not sure it's worth adding new archives though-- just take the checksums for the archives already in the snaps | 17:38 |
| tsimonq2 | kyrofa: alright | 17:38 |
| tsimonq2 | kyrofa: all of them? which ones would you suggest? | 17:39 |
| kyrofa | tsimonq2, oh, scratch that. Forgot there were multiple. Go ahead and add a new one :) | 17:39 |
| tsimonq2 | alright :() | 17:39 |
| tsimonq2 | *:) | 17:39 |
| kyrofa | tsimonq2, do you know how to check the coverage? | 17:40 |
| tsimonq2 | kyrofa: yeah there's a report | 17:40 |
| tsimonq2 | kyrofa: that's talking about unit tests right? | 17:41 |
| tsimonq2 | kyrofa: or is that integration? | 17:41 |
| kyrofa | tsimonq2, yup, units, you got it | 17:41 |
| tsimonq2 | kyrofa: if it's unit, do I add my tests to the Tar and Zip classes or do I make my own class? | 17:41 |
| kyrofa | tsimonq2, wait... now I'm not sure what we're talking about | 17:41 |
| tsimonq2 | kyrofa: in snapcraft/tests/test_sources.py (or whatever the name of the file is) | 17:42 |
| kyrofa | tsimonq2, the unit tests you have so far look good (though I've not given them a complete review). The integration tests will be good for actually verifying checksums | 17:42 |
| tsimonq2 | kyrofa: there's class TestTar(tests.TestCase): and class TestZip(tests.TestCase): | 17:42 |
| kyrofa | But the integration tests go in integration_tests, not snapcraft/tests (those are units). Am I answering your question? :P | 17:43 |
| tsimonq2 | kyrofa: no | 17:43 |
| tsimonq2 | so here's what I'm asking | 17:43 |
| kyrofa | Heh, sorry | 17:43 |
| tsimonq2 | I added unit tests for incompatibility, right? | 17:43 |
| tsimonq2 | what about for testing that it works? | 17:43 |
| tsimonq2 | or that it successfully checks the checksum? | 17:44 |
| sergiusens | kyrofa might be good to go, but I don't want to update branch again ;-) https://github.com/snapcore/snapcraft/pull/633 | 17:44 |
| mup | PR snapcraft#633: qmake plugin: Stop doing out-of-source builds <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/633> | 17:44 |
| kyrofa | Well, in order to test that it works, you need to make something to take a checksum OF | 17:44 |
| kyrofa | That is an integration test | 17:44 |
| kyrofa | sergiusens, you're so mean :P | 17:44 |
| tsimonq2 | kyrofa: so then what's the difference between integration and unit? | 17:44 |
| mup | PR snapcraft#633 closed: qmake plugin: Stop doing out-of-source builds <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/633> | 17:45 |
| kyrofa | sergiusens, oh ha! I see what you're saying now ;) | 17:45 |
| sergiusens | tsimonq2 kyrofa difference between unit and integration changes depending on who you ask | 17:46 |
| sergiusens | tsimonq2 kyrofa we've settled for integration meaning talking to external servers and using real code to run snapcraft agains using the real snapcraft command | 17:47 |
| sergiusens | and for unit, we use some other module | 17:47 |
| sergiusens | to call as under test | 17:47 |
| kyrofa | tsimonq2, you have the right idea-- you should definitely verify the checksums work correctly. However, in this case the data you need to setup to test the checksums work correctly is beyond what a unit test should do. In order to test this at the unit level you could do some mocking though | 17:47 |
| sergiusens | and we consider it totatlly fine to generate artifacts on disk these days | 17:48 |
| tsimonq2 | kyrofa: so do I need a unit test or not for the coverage? | 17:48 |
| kyrofa | tsimonq2, indeed, integration doesn't count toward coverage | 17:48 |
| zyga | jdstrand: arch now ships snap-confine 1.0.35 | 17:48 |
| sergiusens | kyrofa I personally don't see this as a problem with open('file', 'w') as f:\n f.write('something that will produce a known checksum') | 17:48 |
| zyga | arch is FAST :) | 17:49 |
| sergiusens | kyrofa aside from an integration test | 17:49 |
| sergiusens | zyga how fast? | 17:49 |
| zyga | sergiusens: I mean, fast to update | 17:49 |
| jdstrand | neat | 17:49 |
| kyrofa | sergiusens, it needs to be a tar or zip source though | 17:49 |
| zyga | sergiusens: that's not me updating the package | 17:49 |
| zyga | sergiusens: that's arch maintainer | 17:49 |
| kyrofa | sergiusens, but yeah, you're right, not a big deal | 17:49 |
| zyga | sergiusens: it was released a day ago | 17:49 |
| sergiusens | kyrofa you could use the tar or zip modules for that, with tar.open... | 17:49 |
| zyga | on another note, I just got most spread tests to work on debian sid | 17:49 |
| kyrofa | tsimonq2, sergiusens's idea is probably better than mocking | 17:50 |
| kyrofa | tsimonq2, use that to make sure your code is covered, and then use the integration tests to cover end-to-end | 17:50 |
| tsimonq2 | kyrofa: so wait, when he said, "kyrofa I personally don't see this as a problem with open('file', 'w') as f:\n f.write('something that will produce a known checksum')" ? | 17:52 |
| kyrofa | tsimonq2, hold on, my son is asking me to tuck him in for his nap, be right back | 17:52 |
| tsimonq2 | alright kyrofa :) | 17:52 |
| mcphail | Can someone point me to details of how to get launchpad to build ARM snaps? | 17:53 |
| kyrofa | mcphail, https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way | 17:54 |
| mcphail | kyrofa: thanks! | 17:54 |
| kyrofa | sergiusens, how would you like him to determine the checksum in a known manner that still tests his code? | 17:55 |
| sergiusens | kyrofa I don't follow | 17:55 |
| tsimonq2 | sergiusens: I need unit test coverage, how would I go about doing that for snapcraft#619 ? | 17:56 |
| mup | PR snapcraft#619: Add source-checksum option for tar and zip sources (bug 1585913) <Created by tsimonq2> <Conflict> <https://github.com/snapcore/snapcraft/pull/619> | 17:56 |
| kyrofa | sergiusens, he has code that grabs the checksum of the archive. If he generates the archive on the fly he can't know the checksum until it's been generated. How should he get it while still being able to test the checksum-grabbing code? | 17:56 |
| sergiusens | tsimonq2 by creating known files on the fly as part of the test fixture setup and passing those to your source (Zip, Tar) calls | 17:57 |
| kyrofa | sergiusens, i.e. saying "use my code to get checksum" -> "test that my code that gets checksum matches that checksum" isn't really a valid test | 17:57 |
| kyrofa | sergiusens, unless you're saying there's a way to create tars and zips in a completely deterministic manner across archs? | 17:59 |
| kyrofa | (not sure what metadata gets packed in there) | 18:00 |
| kyrofa | zyga, good for arch, they're ahead of ubuntu! | 18:00 |
| kyrofa | zyga, how is that SRU coming? :P | 18:01 |
| zyga | kyrofa: I don't know | 18:03 |
| zyga | kyrofa: I'm not doing the SRU work really :/ | 18:03 |
| zyga | kyrofa: I'm working on .36 for more SRU :P | 18:03 |
| mvo | attente: hm, what was the sru tracking bug again? I think that should also be in the changelog :) I can add it | 18:04 |
| kyrofa | zyga, hahaha | 18:04 |
| mvo | attente: aha, found it | 18:05 |
| mcphail | Can someone check my snapcraft.yaml at http://bazaar.launchpad.net/~njmcphail/+junk/ag-mcphail/view/head:/snapcraft.yaml ? It isn't building on launchpad as per https://launchpadlibrarian.net/271553088/buildlog_snap_ubuntu_xenial_arm64_ag-mcphail_BUILDING.txt.gz due to grumbles about the "confinement" line, but builds OK on my machine | 18:05 |
| kyrofa | mcphail, huh... looks like their snapcraft might be out of date... ? | 18:05 |
| mcphail | kyrofa: hmm. Should I poke someone about that? | 18:06 |
| mvo | zyga: for xnapd-xdg-open - you just need a git tag? or more? | 18:06 |
| kyrofa | mcphail, hop in #launchpad. I just asked | 18:06 |
| zyga | mvo: what's the buildystem there? I don't recall | 18:07 |
| zyga | mvo: ideally a make dist tarball and a release on github | 18:07 |
| zyga | (or launchpad) | 18:07 |
| zyga | mvo: and some simple packaging instructions | 18:07 |
| mvo | zyga: autotools | 18:07 |
| zyga | mvo: is that something that goes into the snap in any way or is it just the host distro | 18:08 |
| mvo | zyga: ok, can do in a bit | 18:08 |
| zyga | mvo: thanks | 18:08 |
| zyga | (I guess arch will be first again :) | 18:08 |
| mvo | zyga: we need it alongside snapd | 18:08 |
| zyga | understood | 18:08 |
| zyga | jdstrand: FYI, https://github.com/snapcore/snap-confine/pull/74 | 18:09 |
| mup | PR snap-confine#74: Debian spread tests <Created by zyga> <https://github.com/snapcore/snap-confine/pull/74> | 18:09 |
| zyga | jdstrand: sid support in spread | 18:09 |
| jdstrand | nice! | 18:13 |
| kyrofa | mcphail, to be fair I didn't document that very well in the post, so I'm adding a blurb now | 18:17 |
| zyga | jdstrand: I'd like to know what to do about the apparmor issue, we have the fact that .34 and .35 shipped without confinement, I'd like to get a resolution you agree on quickly so that .36 can be released that fixes the bigger issue, perhaps without adding a smaller one | 18:19 |
| jdstrand | zyga: I think I've been pretty clear :) | 18:27 |
| jdstrand | zyga: you can release 1.0.36 if you want without the fix, but we can't release that to Ubuntu because it regresses an important security feature | 18:28 |
| mcphail | kyrofa: getting different build errors now, but making progress. Thanks! | 18:31 |
| kyrofa | mcphail, good deal! Let me know if you need any help | 18:31 |
| mcphail | kyrofa: when building on lp, I assume installing libpcre3-dev doesn't automatically install libpcre3 as well? | 18:32 |
| zyga | jdstrand: but ubuntu 16.10 will get .35 through debian so isn't the cat out of the bag already? | 18:33 |
| kyrofa | mcphail, I assume it does, isn't it a dependency? | 18:33 |
| zyga | jdstrand: let me re-read your comments, I'm not sure what the next step is there | 18:33 |
| kyrofa | (I've not actually looked at the cache) | 18:33 |
| jdstrand | zyga: 16.10 is the dev release. 16.04 is stable. we can't regress this security feature in 16.04 | 18:34 |
| jdstrand | we shouldn't in 16.10, but if we do we just fix it | 18:35 |
| mcphail | kyrofa: if you look at https://launchpadlibrarian.net/271556609/buildlog_snap_ubuntu_xenial_i386_ag-mcphail_BUILDING.txt.gz , for some reason libpcre3 shows up in the "Skipping blacklisted from manifest packages:"... | 18:35 |
| kyrofa | mcphail, ah, must be already installed then | 18:36 |
| jdstrand | zyga (cc tyhicks): the next step is to give examples of mount profiles that snapd currently implements | 18:36 |
| zyga | jdstrand: only the content interface uses them | 18:36 |
| attente | mvo: ah, sorry, thanks for catching that | 18:36 |
| zyga | jdstrand: and the read/write paths are decided by plug/slot attributes | 18:36 |
| jdstrand | zyga (cc tyhicks): and then understand precisely what mount rules are needed | 18:36 |
| zyga | jdstrand: any value is allowed right now | 18:36 |
| zyga | jdstrand: that fact implies that any mount rules might be allowed | 18:37 |
| jdstrand | zyga: yes, but the source mount point is inside a snap, not /** | 18:37 |
| jdstrand | zyga: and the target mount point is inside a snap, not /** | 18:37 |
| zyga | jdstrand: one useful use case is /var/lib/snapd/hostfs/usr/share/fonts | 18:37 |
| zyga | jdstrand: as for the target directory, let me check | 18:37 |
| arges | Hi, I'm playing with the snappy client code. Does it make sense that 'Find' returns a Status of 'available' for each snap even if it is installed on the machine? Do I need to do a separate call to 'List' to determine if a package is actually installed? | 18:37 |
| mcphail | kyrofa: perhaps I need to add pkg-config as a build dependency? I'd assumed that would be default? | 18:37 |
| jdstrand | zyga: but the fonts directory is an implicit slot, not the content interface | 18:38 |
| tyhicks | zyga: sorry to distract from the discussion but does the snap itself define the plug/slot attributes? | 18:38 |
| zyga | jdstrand: it would be a slot on the core snap (it doesn't exist yet) | 18:38 |
| zyga | tyhicks: yes | 18:38 |
| zyga | small clarification, currently both source and destination are rooted at $SNAP | 18:38 |
| jdstrand | zyga: right, so we add a rules for /usr/share/fonts like we do for /etc/alternatives | 18:38 |
| kyrofa | mcphail, indeed, try adding that | 18:38 |
| zyga | so I guess we can constrain those profiles to /snap/*/** | 18:39 |
| jdstrand | zyga: and then a different glob rule for content | 18:39 |
| jdstrand | yes! :) | 18:39 |
| kyrofa | mcphail, it's not a default-- not everything needs it | 18:39 |
| zyga | I missed those two lines, I just read the content interface | 18:39 |
| mcphail | kyrofa: ok, thanks | 18:39 |
| kyrofa | mcphail, not even gcc/g++ is a default | 18:39 |
| mcphail | kyrofa: so we need to add build-essential? | 18:40 |
| kyrofa | mcphail, you can, but that's a bit of a shotgun | 18:40 |
| jdstrand | unfortunately, /snap/bin is in there and shouldn't be mounted, so we'll need several rules to express /snap/*/**. | 18:40 |
| tyhicks | zyga: when reviewing the bind mount PR, I thought we were in full control of the source and destination paths | 18:40 |
| jdstrand | tyhicks: we are | 18:40 |
| kyrofa | mcphail, the only things plugins will add implicitly are the tools required to run them (e.g. the make plugin will install make, autotools will install autotools, etc.) | 18:41 |
| kyrofa | mcphail, everything else you have absolute control over | 18:41 |
| jdstrand | tyhicks: for content it is relative to the providing snap's and consuming snap's directories | 18:41 |
| zyga | yes | 18:41 |
| jdstrand | which is why I kept saying let's constrain this to what we actually allow | 18:41 |
| mcphail | kyrofa: OK, that's interesting. Is there any way to get a "naked" build environment on a local machine to simulate this? Presumably run it in lxc? | 18:41 |
| tyhicks | do we have protections against "../" components in the path? | 18:42 |
| zyga | that's a bit unfortunate for font sharing though, there's no way to describe that | 18:42 |
| kyrofa | mcphail, indeed, cleanbuild | 18:42 |
| jdstrand | zyga: font sharing? | 18:42 |
| zyga | tyhicks: we ensure that filepath.Clean(path) == path | 18:42 |
| jdstrand | zyga: regardless, we can have a separate rule for the fonts dir, just like we do for all the others | 18:42 |
| mcphail | kyrofa: nice. Thanks | 18:42 |
| zyga | that is, no ../ bits are present | 18:42 |
| zyga | jdstrand: (this is actually inside snapd that we'd have to allow this) | 18:43 |
| zyga | jdstrand: to make the source *not* relative to the core snap | 18:43 |
| zyga | but I think we are good actually | 18:43 |
| jdstrand | zyga: I'm confused about what you are talking about there | 18:43 |
| zyga | not for fonts but for this | 18:43 |
| zyga | jdstrand: sorry, I'm just observing that content sharing interfae cannot be used to share fonts from the host today | 18:43 |
| zyga | but that's not a problem at hand, sorry for adding this to the mix | 18:44 |
| jdstrand | ok | 18:44 |
| jdstrand | well, in the future we can add whatever mount rule is needed for fonts too | 18:44 |
| jdstrand | so, I think some sort of /snap/*/** mount rule with a comment that it is to enable the content interface is fine | 18:45 |
| mcphail | kyrofa: actually, looks as if gcc is in the base launchpad build instance already | 18:45 |
| zyga | jdstrand, tyhicks: https://github.com/snapcore/snap-confine/pull/73/commits/24bbd4338d24e97330ccd20e3cb01cb714b5f08c | 18:48 |
| mup | PR snap-confine#73: Update apparmor profile for snap-confine <Created by zyga> <https://github.com/snapcore/snap-confine/pull/73> | 18:48 |
| jdstrand | importantly, you are going to have to do the crappy /snap/[^b]*/**, /snap/b[^i]*/**, /snap/bi[^n]*/**, /snap/bin?*/**, /snap/b/**, /snap/bi/** shenanigans | 18:48 |
| jdstrand | zyga: see ^. let me add a comment | 18:48 |
| zyga | ohhh | 18:49 |
| zyga | hmmm | 18:49 |
| zyga | is that really needed? | 18:49 |
| zyga | I see why but what's the attack there? | 18:49 |
| jdstrand | yes | 18:49 |
| zyga | you cannot run any of those things | 18:49 |
| jdstrand | you don't want to mount /snpa/bin | 18:49 |
| zyga | and the mount is happening after unshare | 18:49 |
| zyga | why not? | 18:49 |
| zyga | will any other process see that mount? | 18:50 |
| jdstrand | because like you say it is pointless and we are being fanatical to guard against attacks | 18:50 |
| zyga | ah | 18:50 |
| zyga | that's a good answer | 18:50 |
| jdstrand | give me a minute | 18:50 |
| jdstrand | we are being as defensive as possible | 18:50 |
| zyga | I mean, if there's any way this is exploitable already I'd like to know (this is why I ask those questions), I undestand general "to be more safe" answers | 18:50 |
| jdstrand | I can't think of an attack otoh | 18:51 |
| zyga | ok, let me do the exclusive rules then | 18:51 |
| jdstrand | zyga: hold on | 18:51 |
| zyga | btw, would a deny rule be easier and would work too? | 18:51 |
| zyga | ok | 18:51 |
| jdstrand | no deny rules | 18:51 |
| jdstrand | I mean we can | 18:52 |
| jdstrand | well | 18:52 |
| jdstrand | actually in this case that would be good | 18:52 |
| jdstrand | audit deny mount /snap/bin/**, | 18:52 |
| zyga | is the single argument form matching both source and destination? | 18:53 |
| jdstrand | that is a good question | 18:53 |
| jdstrand | mount rule syntax is annoying | 18:53 |
| jdstrand | how about: audit deny mount /snap/bin/** -> /**, | 18:54 |
| zyga | yep | 18:54 |
| jdstrand | that is clear | 18:54 |
| zyga | jdstrand: wait, isn't that reverse | 18:54 |
| zyga | jdstrand: source -> destination | 18:54 |
| zyga | we don't want to let people bind mount over that | 18:54 |
| zyga | or bind mount that somewhere? | 18:54 |
| zyga | actually, probably both | 18:55 |
| zyga | jdstrand: like this? http://paste.ubuntu.com/18724566/ | 18:55 |
| zyga | (not tested) | 18:55 |
| mup | PR snapd#1510 closed: integration-tests: remove login tests <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1510> | 18:56 |
| zyga | I'll add a few spread tests for this but I need to go now | 18:56 |
| jdstrand | yes | 18:56 |
| jdstrand | I like that | 18:56 |
| jdstrand | I just read the man page and the single argument form is the source mount, but this is very clear | 18:56 |
| mup | PR snapd#1509 closed: interface: add new interfaces.all.SecurityBackends <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1509> | 18:57 |
| jdstrand | fyi, without those rules there would be an info leak on the installed snaps | 18:57 |
| sergiusens | kyrofa mind looking at https://github.com/snapcore/snapcraft/pull/627 | 18:57 |
| mup | PR snapcraft#627: Added new maven-targets option to maven plugin <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/627> | 18:57 |
| sergiusens | ? | 18:58 |
| jdstrand | we don't protect against that perfectly today, but there are longer term work items that will address that | 18:58 |
| zyga | jdstrand: good point about the info leak! | 19:00 |
| zyga | jdstrand: I'll make the spread tests happen | 19:00 |
| zyga | jdstrand: but now -> time to take a walk, it's 21:00 already | 19:00 |
| jdstrand | zyga: where'd the time go?! | 19:02 |
| jdstrand | zyga: thank you for working on this :) | 19:02 |
| tsimonq2 | kyrofa: so what am I doing for the integration tests again? | 19:13 |
| mup | PR snapcraft#637 opened: Do not clean before running the snaps tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/637> | 19:18 |
| kyrofa | tsimonq2, you're adding stuff to integration_tests/test_tar_plugin.py and integration_tests/test_zip_source.py | 19:22 |
| tsimonq2 | kyrofa: oh okay | 19:22 |
| sergiusens | slangasek hey, how's that umbrella bug for SRUing supposed to be created? | 19:25 |
| tsimonq2 | kyrofa: so what exactly should I test for, should I ensure that it can check the checksum (if so, I don't know if I can do that), should I check the checksum in the test, I mean, what am I trying to do here? | 19:25 |
| slangasek | sergiusens: file bug against the package; include pointer to the wiki page describing the exception; document what testing has been done; include this bug in the changelog of the upload | 19:26 |
| tsimonq2 | slangasek: would https://pad.lv/1599125 , https://pad.lv/1567524 , and https://pad.lv/1590807 be able to be linked to 2.14 please? | 19:26 |
| tsimonq2 | whoops sergiusens ^ | 19:27 |
| tsimonq2 | sergiusens: or do you think they shouldn't? thoughts? | 19:27 |
| sergiusens | tsimonq2 I can link them once a PR is up, seems like a lot for a weeks work though | 19:28 |
| tsimonq2 | thanks sergiusens for clarifying | 19:28 |
| kyrofa | tsimonq2, well, you added some good stuff to simple-tar. An archive along with several known checksums. Make sure the test runs them all, and make sure you do similar things for zip | 19:29 |
| tsimonq2 | kyrofa: but doesn't it already all run because it's in the snapcraft.yaml? | 19:29 |
| kyrofa | tsimonq2, it might, I haven't looked. You may not need to change the tar test at all. But you're missing the zip test snap, right? | 19:30 |
| * tsimonq2 does that | 19:30 | |
| elopio | slangasek: ping. Can you please reply here please? https://bugs.launchpad.net/snapcraft/+bug/1596068/comments/4 | 19:33 |
| mup | Bug #1596068: The unittests in autopkgtest are run twice <verification-done> <Snapcraft:Fix Released by elopio> <https://launchpad.net/bugs/1596068> | 19:33 |
| slangasek | elopio: so the argument is that the unit tests only test the snapd code, and would not pick up a regression caused by a dependency? | 19:40 |
| elopio | slangasek: they would catch regressions on dependencies, we don't fake everything. But those regressions should be caught too by the integration tests. | 19:41 |
| slangasek | ok | 19:42 |
| elopio | and on the integration tests we don't fake any of the dependencies. | 19:42 |
| slangasek | elopio: in that case I'm comfortable with your position; I just want to make sure we continue to have strong archive-level CI for this package, which it sounds like you're covering | 19:43 |
| sergiusens | slangasek so about the SRU bug now :-) | 19:44 |
| elopio | slangasek: great, thanks. | 19:44 |
| sergiusens | slangasek can I create a bug with a xenial/yakkety task title "New upstream version X.X.X" with a link to our milestone with all the fixed bugs and features in the summary? | 19:44 |
| sergiusens | and maybe a link to the wiki with the exception | 19:44 |
| elopio | ah, that's the umbrella you were talking about. | 19:45 |
| sergiusens | elopio yes | 19:45 |
| slangasek | sergiusens: yes | 19:46 |
| sergiusens | slangasek works for me, thanks! | 19:50 |
| elopio | sergiusens: please call it the same as mvo is doing for snappy. It's like [SRU] New stable micro release X.X.X | 19:51 |
| mup | PR snapcraft#632 closed: Refactor and update the logic that deals with the snap-push store endpoint <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/632> | 19:51 |
| tsimonq2 | sergiusens: when you have a minute, how do I do that unit test coverage? how do I test checksumming in the unit test? :) | 19:51 |
| sergiusens | tsimonq2 run ./runtests.sh unit && python3-coverage html | 19:52 |
| sergiusens | tsimonq2 apt install python3-coverage if not there | 19:52 |
| tsimonq2 | sergiusens: I know how to test, how do I code the unit tests? basically, the clarifying question kyrofa asked | 19:52 |
| tsimonq2 | (for my PR) | 19:52 |
| sergiusens | tsimonq2 either create some zips or tars on the fly which you would know what they compute to or mock some things out. Final judgement should come from our QA master elopio though ;-) | 19:54 |
| sergiusens | ohh, I need to leave! | 19:55 |
| tsimonq2 | elopio? do you agree? we're talking about how to do the coverage for snapcraft#619 | 19:55 |
| mup | PR snapcraft#619: Add source-checksum option for tar and zip sources (bug 1585913) <Created by tsimonq2> <Conflict> <https://github.com/snapcore/snapcraft/pull/619> | 19:55 |
| elopio | tsimonq2: yes, I agree. Ideally, check the sum in a real file, not mocking. | 19:57 |
| tsimonq2 | thanks elopio :) | 19:58 |
| elopio | thanks to you. | 19:58 |
| zyga | time to hack | 19:58 |
| zyga | jdstrand: does this look like the right approach? http://paste.ubuntu.com/18729680/ | 20:07 |
| mup | PR snapd#1490 closed: overlord: implement &Retry{After: duration} support for handlers <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1490> | 20:07 |
| zyga | jdstrand: I wonder how to do that to see the deny in syslog somehow | 20:07 |
| jdstrand | zyga: deny in syslog is difficult. you can dmesg|tail -1|grep 'DEN...' but it has the potential to be racy | 20:10 |
| jdstrand | zyga: but yeah, that looks like a fine test | 20:10 |
| zyga | jdstrand: I'll try to include some sort of audit trail there | 20:11 |
| zyga | jdstrand: I could fork a journalctl -f and kill it later | 20:11 |
| zyga | jdstrand: thanks, I'm reading your test | 20:12 |
| zyga | jdstrand: one personal preference, quote arguments to echo | 20:12 |
| DT01 | anyone around that can help with snapcraft 1.x - trying to get lsusb to work on snappy | 20:12 |
| jdstrand | zyga: you can probably make that pretty good by adding 10 entries with logger that don't match and then tail -10 | 20:12 |
| DT01 | I have a snapcraft file ready if someone could take a look | 20:12 |
| jdstrand | zyga: I normally like that myself, but wasn't sure how well that played with yaml | 20:13 |
| zyga | DT01: hey, on 1.0 and 15.04 that could be tricky, not sure if possible | 20:13 |
| jdstrand | zyga: that test was pretty annoying to write btw :P | 20:13 |
| zyga | jdstrand: I think it works because the whole part there is "free form text" - or so it seems | 20:13 |
| DT01 | zyga: it builds and installs but when it runs it says that it cannot find libusb-1.0.so.0. Even though it is in the stage\build section | 20:15 |
| zyga | DT01: after that you'd be hit by confinement | 20:15 |
| zyga | jdstrand: can each test have restore and setup? I think it would be nicer for readability if we start to move long setup code to per-test prepare section | 20:16 |
| DT01 | zyga: so I need to run in unconfined mode? | 20:16 |
| DT01 | btw this is for a personal system not to be published | 20:16 |
| zyga | DT01: yes and I don't remember how much of that existed in 15.04 | 20:16 |
| jdstrand | zyga: idk | 20:17 |
| DT01 | hmmm, I will take a quick stab at that | 20:17 |
| jdstrand | zyga: I was treating each dir as per-test and therefore the setup is per-test, but maybe there are other ways of doing it | 20:17 |
| zyga | jdstrand: what do you mean by remote environment variables? | 20:18 |
| zyga | jdstrand: AFAIR spread supports them | 20:18 |
| jdstrand | zyga: I found out the 'environment' runs the $(...) code locally and injects it to the remote end | 20:18 |
| jdstrand | zyga: see backscroll in this channel. I wanted to do environement: OSNAP=$(ls ...), but that ls is run on my laptop, not on the remote end | 20:19 |
| zyga | jdstrand: there's also [] | 20:19 |
| zyga | jdstrand: [SOMETHING] | 20:19 |
| * zyga looks at spread docs | 20:19 | |
| jdstrand | zyga: I tried that, but it didn't work | 20:20 |
| jdstrand | zyga: I talked to Gustavo and he said that environment is currently there to support SPREAD_LINODE_KEY and not what I was doing | 20:20 |
| zyga | jdstrand: I think I see what this does, it runs locally | 20:21 |
| zyga | jdstrand: and sends the interpolated value already | 20:21 |
| jdstrand | yes | 20:22 |
| jdstrand | based on what he said and I observed | 20:22 |
| zyga | jdstrand: FYI I just checked that you can have a prepare/restore per task | 20:24 |
| zyga | "owner died" geez | 20:29 |
| mwhudson | zyga: https://launchpad.net/ubuntu/+source/snap-confine has 1.0.35 now \o/ | 20:29 |
| mup | PR snapcraft#627 closed: Added new maven-targets option to maven plugin <Created by ZenHarbinger> <Closed by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/627> | 20:30 |
| tsimonq2 | elopio: with my PR, to check the checksum, do I use hashlib or the function defined in snapcraft/internal/sources.py and if it's the latter, how would I go about calling it? | 20:35 |
| mup | PR snapcraft#638 opened: Re-create feature/maven-targets branch for snapcraft <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/638> | 20:39 |
| zyga | mwhudson: that's good, making .36 today :) | 20:44 |
| mwhudson | zyga: no rest for the wicked! | 20:44 |
| zyga | mwhudson: not in this world | 20:44 |
| mwhudson | hopefully i won't screw up the gbp interactions so many times today | 20:44 |
| zyga | mwhudson: I didn't manage to fix yakkety snapd tests | 20:44 |
| zyga | mwhudson: no idea why that fails, I did a chmod on the two environment files that debian/tests scripts create | 20:45 |
| zyga | mwhudson: but no difference | 20:45 |
| mwhudson | zyga: i have a vm which i'm going to run the tests in by hand | 20:45 |
| mwhudson | zyga: but my qemu-fu is pretty weak | 20:46 |
| zyga | mwhudson: I have a vm with yakkety but I don't know how to run those tests without any abstractions in the way | 20:46 |
| zyga | mwhudson: but I'm almost sure this is the testbed, not snapd that is at fault | 20:46 |
| mwhudson | zyga: i guess staring at the diff between 2.0.2 and 2.0.3 might also be interesting | 20:47 |
| zyga | mwhudson: I dind't think of that | 20:47 |
| zyga | mwhudson: but it could be substantial :/ | 20:47 |
| zyga | mwhudson: maybe the diff between debian/tests is smaller | 20:48 |
| mwhudson | 15k lines, haha | 20:48 |
| mwhudson | zyga: i wonder if it just adds the test that fails or something... | 20:48 |
| zyga | mwhudson: you mean debian/tests or snapd in general? | 20:51 |
| mwhudson | snapd in general | 20:52 |
| mwhudson | but i'm just guessing here | 20:52 |
| mwhudson | debian/tests/integrationtests looks fairly different to what's in 2.0.10 | 20:52 |
| zyga | mwhudson: can we patch it somehow to run just the failing test | 20:55 |
| zyga | mwhudson: to make iteration faster | 20:55 |
| zyga | mwhudson: in general it takes ~30 minutes for me to run it to failure | 20:55 |
| mwhudson | must be possible somehow yeah | 20:55 |
| zyga | jdstrand: my spread tests are improving | 20:56 |
| zyga | jdstrand: I should be able to see the exact failure soon | 20:56 |
| jdstrand | cool :) | 20:56 |
| zyga | jdstrand: I've uploaded snapd-hacker-toolbelt 0.2 that adds $SNAP/mnt as a mount point for testing | 20:56 |
| mwhudson | zyga: feels like this "resume test after reboot" stuff must be related | 20:57 |
| zyga | mwhudson: hmmm | 20:58 |
| zyga | mwhudson: maybe snappy updates itself | 20:58 |
| tsimonq2 | *raises big red flag* elopio, sergiusens: I didn't touch snapcraft/storeapi/__init__.py , did a local merge that involved that file, and my static tests are failing with the following error: snapcraft/storeapi/__init__.py:405:15: F821 undefined name 'e' and I just confirmed that in my clean master branch I'm getting the same eorrr | 20:58 |
| tsimonq2 | *error | 20:58 |
| zyga | mwhudson: and something something reexec happens | 20:58 |
| tsimonq2 | elopio, sergiusens: so this is on master and the static tests are failing | 20:58 |
| zyga | tsimonq2: git diff? :) | 20:58 |
| tsimonq2 | zyga: I checked that | 20:58 |
| tsimonq2 | zyga: all clean | 20:58 |
| zyga | tsimonq2: git log -p on that file? | 20:59 |
| * tsimonq2 checks it out in /tmp and confirms again | 20:59 | |
| mwhudson | zyga: heh heh when we worked on pypy there were internal jokes about "stuff occuring" whenever we didn't know what was going on | 20:59 |
| zyga | mwhudson: the local quantum fluctuation added 'e' there | 20:59 |
| tsimonq2 | elopio, sergiusens: also confirmed in a clean checkout | 21:00 |
| zyga | tsimonq2: locally installed package with a typo? | 21:00 |
| tsimonq2 | zyga: huh? | 21:00 |
| tsimonq2 | zyga: clone master locally, git pull origin master, then ./runtests static throws a failure | 21:01 |
| zyga | tsimonq2: do you have the same python package installed locally? | 21:01 |
| jdstrand | zyga: I'll need to play with snapd-hacker-toolbelt sometime | 21:02 |
| zyga | tsimonq2: I had plenty of cases where my /usr/lib/python3/site-packages/ would have something | 21:02 |
| zyga | jdstrand: it's just busybox :> | 21:02 |
| zyga | jdstrand: I will publish that somewhere | 21:02 |
| tsimonq2 | zyga: I don't know what you are saying | 21:02 |
| zyga | jdstrand: should this say anything? I don't see any denial dmesg | grep DENIED | 21:02 |
| tsimonq2 | weird | 21:03 |
| tsimonq2 | really weird | 21:03 |
| tsimonq2 | it passes on Travis... | 21:03 |
| zyga | tsimonq2: what is the code, snapcraft? | 21:03 |
| tsimonq2 | zyga: yeah | 21:03 |
| zyga | tsimonq2: is python3-snapcraft installed? | 21:03 |
| tsimonq2 | zyga: E: Unable to locate package python3-snapcraft | 21:03 |
| zyga | hmmm | 21:03 |
| zyga | how about snapcraft itself | 21:03 |
| tsimonq2 | yep installed | 21:04 |
| tsimonq2 | 2.12 | 21:04 |
| zyga | tsimonq2: just sanity,remove it and try again | 21:04 |
| tsimonq2 | zyga: snapcraft is uninstalled and it still | 21:05 |
| tsimonq2 | *still fails | 21:05 |
| jdstrand | if you are using 'audit deny' and it tries to mount, it should, yes. you might want to: sysctl -w kernel.printk_ratelimit=0 | 21:05 |
| zyga | tsimonq2: hmmmm | 21:06 |
| zyga | ah, thanks | 21:06 |
| zyga | jdstrand: how to undo that | 21:06 |
| zyga | what's the default? | 21:06 |
| zyga | jdstrand: audit deny or deny audit? | 21:09 |
| jdstrand | zyga: to undo, grab 'sysctl kernel.printk_ratelimit' then feed back in later: sysctl -w kernel.printk_ratelimit=$prev | 21:10 |
| zyga | jdstrand: it deoesn't work | 21:10 |
| zyga | jdstrand: digging deeper | 21:11 |
| zyga | spread is fantastic | 21:12 |
| zyga | I don't like only one thing about it | 21:12 |
| zyga | I prefer --options | 21:12 |
| zyga | but everything else is just amazingly useful | 21:12 |
| jdstrand | the default is to deny and log. when you add a rule it allows it with no logging. to deny it without logging, specify only deny. to explicitly deny and log, use audit deny. I always use audit first. I never thought it mattered but looking at apparmor.d, audit might need to be first | 21:12 |
| zyga | ha | 21:13 |
| zyga | trying that | 21:13 |
| zyga | because the thing does "work" (busybox true fails) | 21:13 |
| zyga | nice | 21:13 |
| jdstrand | zyga: it is possible that kern messages aren't going to syslog | 21:13 |
| jdstrand | zyga: they should if it is Ubuntu, but perhaps the syslogger is setup different | 21:14 |
| zyga | jdstrand: this is 16.04 so ... they should | 21:14 |
| jdstrand | zyga: I saw denials with 'dmesg'-- do you see anything there? | 21:15 |
| niemeyer | Anyone seen this before: findfs: unable to resolve 'LABEL=writable' | 21:15 |
| zyga | niemeyer: looks like the partition doesn't have the filesystem label | 21:16 |
| zyga | niemeyer: then we don't boot far | 21:16 |
| zyga | niemeyer: I saw it while fiddling with images | 21:16 |
| zyga | niemeyer: are you trying to get an all-snap image into linode? | 21:16 |
| niemeyer | zyga: The label is properly set | 21:16 |
| niemeyer | Yeah | 21:16 |
| zyga | jdstrand: successs :) | 21:16 |
| zyga | cannot mount /snap/bin at /snap/snapd-hacker-toolbelt/current/mnt with options bind,ro. errmsg: Permission denied | 21:16 |
| zyga | woot | 21:16 |
| zyga | niemeyer: hmm | 21:16 |
| zyga | jdstrand: a few more tweaks and I'll use this test as a base | 21:17 |
| zyga | jdstrand: I'm using SNAP_CONFINE_DEBUG | 21:17 |
| zyga | jdstrand: then it just puts errors on stderr and I can check that easily | 21:17 |
| zyga | [ 4389.271507] audit: type=1400 audit(1467926268.960:29): apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine" name="/snap/snapd-hacker-toolbelt/2/mnt/" pid=4382 comm="ubuntu-core-lau" srcname="/snap/bin/" flags="rw, bind" | 21:18 |
| zyga | jdstrand: so the order DOES matter | 21:18 |
| zyga | jdstrand: we can grep for "deny audit" vs "audit deny" perhaps | 21:19 |
| elopio | tsimonq2: are you on xenial or yakkety? | 21:19 |
| tsimonq2 | elopio: yakkety | 21:20 |
| jdstrand | zyga: snapd and snap-confine don't otherwise use 'deny audit' (just checked) | 21:20 |
| elopio | tsimonq2: yes, it happens only with yakkety's flake8. Please report a bug. | 21:21 |
| tsimonq2 | elopio: alright thanks | 21:21 |
| tsimonq2 | elopio: I think I'm almost done too! | 21:21 |
| zyga | jdstrand: thanks! | 21:22 |
| niemeyer | Someone else reported the same thing in April, with no feedback: https://lists.ubuntu.com/archives/snappy-devel/2016-April/001729.html | 21:22 |
| zyga | hohoho | 21:23 |
| zyga | niemeyer: fedora 25 can find snaps in the store :> | 21:23 |
| zyga | niemeyer: in gnome-software | 21:23 |
| zyga | so so cute :> | 21:23 |
| niemeyer | Sweet :) | 21:23 |
| zyga | just watched this on G+ | 21:24 |
| zyga | :D | 21:24 |
| zyga | that's fantastic to see | 21:24 |
| zyga | I suspect this will land in Arch soon :) | 21:25 |
| zyga | I'm just going to watch that again | 21:26 |
| zyga | to let it sink in : | 21:26 |
| zyga | :> | 21:26 |
| zyga | niemeyer: btw, did I say how much I love spread? | 21:26 |
| niemeyer | zyga: :D | 21:27 |
| zyga | niemeyer: I talked about exactly having something like spread at the sprint to fgimenez and elopio and you made it :-) | 21:27 |
| tsimonq2 | elopio: another thing while you are around. https://github.com/snapcore/snapcraft/pull/619/files#diff-3ce6f0422479e72d9db0860efb0e7b42R132 should cuase the test to fail, I did that intentionally for debugging perposes. It doesn't. https://github.com/snapcore/snapcraft/pull/619/files#diff-e6205a80af76b4faec1d9241dc3b3b7cR177 is what should cause it to fail but it isn't | 21:28 |
| 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> | 21:28 |
| tsimonq2 | elopio: I can't figure out what the problem is | 21:28 |
| tsimonq2 | elopio: otherwise, my PR is ready for a full review | 21:29 |
| zyga | jdstrand: look at this test please: https://github.com/snapcore/snap-confine/pull/73/commits/9b09f3a2e574bb7782b5be5beaefa4e6cc74ddd6 | 21:31 |
| mup | PR snap-confine#73: Update apparmor profile for snap-confine <Created by zyga> <https://github.com/snapcore/snap-confine/pull/73> | 21:31 |
| === devil is now known as Guest36675 | ||
| tsimonq2 | elopio: /o\ scratch that, still thinks I have no unit test coverage... ahh | 21:34 |
| elopio | tsimonq2: run it locally. | 21:35 |
| elopio | sergiusens: latest test of master and staging fails because the snap we are uploading needs a manual review. | 21:35 |
| elopio | https://travis-ci.org/snapcore/snapcraft/jobs/143148743 | 21:35 |
| tsimonq2 | elopio: I did | 21:36 |
| elopio | tsimonq2: and it fails locally? | 21:36 |
| tsimonq2 | elopio: the problem is, because the test doesn't fail, it isn't verbose | 21:36 |
| tsimonq2 | elopio: it's supposed to fail but it doesn't | 21:36 |
| tsimonq2 | elopio: (unit tests) | 21:36 |
| elopio | tsimonq2: have you used pdb? | 21:37 |
| tsimonq2 | elopio: never heard of it | 21:37 |
| === Guest36675 is now known as devil_ | ||
| elopio | tsimonq2: add this line before https://github.com/snapcore/snapcraft/pull/619/files#diff-e6205a80af76b4faec1d9241dc3b3b7cR177 : import pdb; pdb.set_trace() | 21:38 |
| 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> | 21:38 |
| elopio | that's a debugger. Enter n to jump to the next line. You can print a variable with p var_name. | 21:38 |
| tsimonq2 | wow that's awesome! :D | 21:39 |
| zyga | heh :) | 21:39 |
| elopio | https://docs.python.org/3/library/pdb.html | 21:39 |
| zyga | you should try gdb some day | 21:39 |
| elopio | tsimonq2: read that ^. | 21:39 |
| zyga | like pdb but also down to the metal | 21:39 |
| tsimonq2 | elopio: how do I run coveralls locally? | 21:40 |
| elopio | tsimonq2: install python3-coverage. Coveralls is just a way to display the report, not something you run locally. | 21:41 |
| tsimonq2 | elopio: oh I see | 21:42 |
| * tsimonq2 remembers now :D | 21:42 | |
| mwhudson | zyga: I hacked it to only run the failing test, it passes of course | 21:43 |
| zyga | mwhudson: since it failed on some service still running I suspect it's bleeding the previous ttest that is causing the next one now | 21:44 |
| mwhudson | zyga: certainly plausible | 21:44 |
| tsimonq2 | elopio: so when I run the unit tests, am I supposed to get a debugger? because I'm not | 21:52 |
| zyga | I forked the test to cover both cases | 21:52 |
| zyga | I'll also have to patch the earlier tests that now fail because mount profiles got more constrained | 21:53 |
| tsimonq2 | elopio: and the coverage statement tells me that all three of my if/elif statements never returned to true | 21:53 |
| zyga | but we're looking good :) | 21:53 |
| elopio | tsimonq2: then put the breakpoint earlier, you are not hitting that statement. | 21:54 |
| tsimonq2 | alright elopio | 21:54 |
| mwhudson | zyga: ah --shell-fail finally worked for me | 21:54 |
| zyga | mwhudson: did you change anything? | 21:54 |
| mwhudson | zyga: when i log in, systemctl status snap-basic\\x2dbinaries-100001.mount is bad | 21:55 |
| zyga | mwhudson: for me it printed commands, none of which worked | 21:55 |
| mwhudson | Jul 08 09:49:37 autopkgtest mount[2148]: mount: special device /var/lib/snapd/snaps/basic-binaries_100001.snap does not exist | 21:55 |
| zyga | mwhudson: explore, why is it bad | 21:55 |
| zyga | oh | 21:55 |
| zyga | is that snap gone? | 21:55 |
| mwhudson | zyga: oh hm, no the ssh command worked for me | 21:55 |
| mwhudson | zyga: no, its there | 21:55 |
| mwhudson | zyga: and in fact i can run sudo systemctl start snap-basic\\x2dbinaries-100001.mount and it starts | 21:55 |
| mwhudson | zyga: could be a race? /me guesses wildly | 21:56 |
| zyga | hmmmm :< | 21:56 |
| zyga | I doubt it, we put the unit in place after we've looked at the squashfs file | 21:56 |
| zyga | mwhudson: anything in snapd log? | 21:59 |
| mwhudson | zyga: journalctl -u snapd? | 21:59 |
| mwhudson | or something else? | 21:59 |
| zyga | that should be it | 21:59 |
| zyga | Day changed to 08 lip 2016 | 22:00 |
| zyga | geee, thanks irssi | 22:00 |
| zyga | I wonder if any other irc client says that | 22:00 |
| mwhudson | quassel does | 22:00 |
| mwhudson | zyga: some stuff, yeah http://paste.ubuntu.com/18738038/ | 22:01 |
| zyga | hmmm | 22:01 |
| zyga | one thing is very wrong | 22:01 |
| zyga | Jul 08 09:49:38 autopkgtest /usr/lib/snapd/snapd[2060]: taskrunner.go:234: DEBUG: Running task 33 on Do: Mount snap "basic-service" | 22:01 |
| zyga | Jul 08 09:51:08 autopkgtest /usr/lib/snapd/snapd[2060]: task.go:250: DEBUG: 2016-07-08T09:51:08+12:00 ERROR [start snap-basic\x2dservice-100001.mount] failed with exit status 1: Warning: snap-basic\x2dservice-100001.mount changed on disk. Run 'systemctl daemon-reload' to reload units. | 22:02 |
| zyga | A dependency job for snap-basic\x2dservice-100001.mount failed. See 'journalctl -xe' for details. | 22:02 |
| zyga | Jul 08 09:51:08 autopkgtest /usr/lib/snapd/snapd[2060]: taskrunner.go:234: DEBUG: Running task 32 on Undo: Prepare snap "/tmp/snapd-sideload-pkg-316559037" | 22:02 |
| zyga | (sorry for pasting like that) | 22:02 |
| zyga | ah, no sorry | 22:02 |
| zyga | I though it's ignoring the error and carrying on but it is in fact undoing the thing | 22:02 |
| zyga | mwhudson: can you reproduce this if you run this in a loop? | 22:02 |
| zyga | I mean the whole testbed | 22:03 |
| zyga | and if so, how fast can you run it? | 22:03 |
| mwhudson | zyga: it seems pretty reproducible yeah | 22:04 |
| mwhudson | and it takes, uh, 10mins to run? | 22:04 |
| zyga | mwhudson: I was wondering if we can patch snapd to run deeper syslog dump when that fails | 22:04 |
| mwhudson | zyga: can certainly try that | 22:04 |
| zyga | mwhudson: or can you see that manually after logging in? | 22:04 |
| mwhudson | zyga: i don't know, am happy to try things :) | 22:04 |
| zyga | mwhudson: I have no idea why this might fail, I'm just trying to see beyond: | 22:05 |
| zyga | Jul 08 09:51:08 autopkgtest /usr/lib/snapd/snapd[2060]: task.go:250: DEBUG: 2016-07-08T09:51:08+12:00 ERROR [start snap-basic\x2dservice-100001.mount] failed with exit status 1: Warning: snap-basic\x2dservice-100001.mount changed on disk. Run 'systemctl daemon-reload' to reload units. | 22:05 |
| zyga | A dependency job for snap-basic\x2dservice-100001.mount failed. See 'journalctl -xe' for details. | 22:05 |
| mwhudson | zyga: oh hm, maybe http://paste.ubuntu.com/18738572/ ? | 22:08 |
| mwhudson | zyga: btw did you see https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1599799 ? | 22:08 |
| mup | Bug #1599799: snapd > 2.0.2 fails on yakkety <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1599799> | 22:08 |
| mwhudson | that latest paste does look a little more informative | 22:08 |
| zyga | mwhudson: I saw it, I've added a comment to it | 22:09 |
| zyga | mwhudson: Jul 08 09:51:08 autopkgtest systemd[1]: dev-loop2.device: Job dev-loop2.device/start timed out. | 22:09 |
| zyga | Jul 08 09:51:08 autopkgtest systemd[1]: Timed out waiting for device /dev/loop2. | 22:09 |
| zyga | this looks wrong :/ | 22:09 |
| mwhudson | oh yes, so you ddid | 22:09 |
| zyga | https://bbs.archlinux.org/viewtopic.php?id=196083 suggest this is when the source doesn't exist but I find that hard to believe | 22:11 |
| mwhudson | does seem unlikely | 22:12 |
| * zyga iterates on mount tests | 22:22 | |
| zyga | ro test done, rw test almost done | 22:47 |
| zyga | I changed the testing approach but the test is still valid | 22:47 |
| zyga | jdstrand: around? | 22:48 |
| zyga | jdstrand: I realized that there's no reason for allowing rw mounts | 22:48 |
| zyga | jdstrand: since we constrain to $SNAP anyway | 22:48 |
| zyga | jdstrand: ... they are always read only now | 22:48 |
| thomi | sergiusens: I'm once again hitting the issue where #! lines in python scripts point to my stage directory, rather than to the bundled python within the snap. I've tried making 'command' both reative within the snap, and just the command name, with no l uck | 22:53 |
| thomi | sergiusens: at what point is the #! line supposed to get rewritten? | 22:53 |
| zyga | jdstrand: I've updated https://github.com/snapcore/snap-confine/pull/73 | 23:08 |
| mup | PR snap-confine#73: Update apparmor profile for snap-confine <Created by zyga> <https://github.com/snapcore/snap-confine/pull/73> | 23:08 |
| zyga | jdstrand: if you feel that is sufficient now please merge it | 23:08 |
| * zyga EODs | 23:20 | |
| chasinglogic | Hey does anyone know if there will be 16.04 images of snappy available? I noticed that there weren't any for 15.10 | 23:24 |
| zyga | chasinglogic: there will be, we're working on the fine details | 23:25 |
| zyga | chasinglogic: when is more complicated but I'm already EOD and tired today | 23:26 |
| chasinglogic | zyga: if I grab the 15.04 image will I be able to upgrade | 23:26 |
| zyga | chasinglogic: no | 23:26 |
| chasinglogic | zyga: cool thanks for the info! | 23:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!