mhall119kyrofa: sergiusens: is there anything that sets $TMPDIR when a snap is run?01:09
kyrofamhall119, yeah, each app gets its own01:09
mhall119kyrofa: what might such a value look like?01:10
mhall119I ask because in pantheon-mail sqlite is trying to create temp files in /var/tmp/ and failing01:10
kyrofamhall119, /tmp/snap.foo_bar_baz01:12
kyrofamhall119, but it shows up to the snap as /tmp01:12
kyrofamhall119, now that you mention it, I'm not sure anything is explicitly setting the TMPDIR var01:12
kyrofaWe just make /tmp work correctly01:12
kyrofaSo if sqlite defaults to /var/tmp is TMPDIR isn't set, that may be it01:13
mhall119it does01:14
mhall119according to https://www.sqlite.org/tempfiles.html#tempstore01:14
mhall119can I do something like: TMPDIR=/tmp /snap/bin/pantheon-mail01:14
mhall119or will the envvars be stripped out when the snap is run?01:14
kyrofamhall119, you can do that, but it'll need to be in a wrapper somewhere01:20
kyrofamhall119, soon that'll get easier, you'll be able to specify environments in the yaml, but not just yet01:20
mhall119do 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
kyrofamhall119, if this problem is encountered enough, sure01:21
mhall119presumably it will be encountered anywhere sqlite3 is used01:21
kyrofaI just wonder if it'll cause problems for others01:22
kyrofae.g. /var/tmp is different than /tmp, it's not cleared each boot01:22
kyrofaSo some users might want TMPDIR to be, say, in $SNAP_DATA/tp01:23
kyrofa$SNAP_DATA/tmp rather01:23
mhall119how about setting SQLITE_TMPDIR? I don't think sqlite expects them to persist  between boots01:23
kyrofaSQLITE_TMPDIR seems a little specific to go in a generic part, but that's just me01:24
kyrofaSuch an approach won't scale01:24
mhall119well, you said there was an easier method on the way :)01:25
kyrofaIn the next snapd release, actually01:25
kyrofaJust waiting for it to get through SRU01:25
kyrofaThough snapcraft needs to support it too... not sure if sergiusens has done that yet or not01:25
kyrofaBut to get up and running, a simple wrapper script is pretty easy01:28
mhall119yup, and I've just verified that it fixes all my apparmor warnings01:29
kyrofaVery good01:30
mhall119it isn't copying my sqlite database forward for new install revisions of the snap though :(01:30
kyrofamhall119, and the DB is in $SNAP_DATA?01:30
mhall119it's /home/mhall/snap/pantheon-mail/x2/.local/share/pantheon-mail/01:31
kyrofaAh interesting! A hidden dir01:31
mhall119does /home/mhall/snap/pantheon-mail/x2/ map to an envvar?01:32
kyrofaOut of curiosity, can you force it to _not_ be hidden?01:32
mhall119because it looks like something might be trying for $HOME/.local/share/01:32
kyrofaIndeed, that's $SNAP_USER_DATA, but snapd also sets $HOME to that01:32
kyrofaYou got it01:32
mhall119and $SNAP_USER_DATA isn't copied? Or it this not being copied because it's a dotfile?01:33
kyrofaIt is copied. The fact that the DB isn't makes me wonder if it's the dotfile, which would be a bug I'd say01:33
kyrofaCan you verify? Even if you just renamed the dir and installed a new rev01:34
mhall119I'll give it a try and see, but might wait until tomorrow01:34
kyrofaYeah it's a bit late for you01: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
didrockshey dholbach06:47
dholbachsalut didrocks06:47
dholbachdoes 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
arazyga_, hey!07:53
popeymorning all07:53
mupPR 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
mwhudsonhas anyone looked at the snapd autopkgtest failures in yakkety?08:48
zyga_mwhudson: hey09:15
zyga_mwhudson: I did but didn't find anything, in fact I cannot reproduce them09:15
zyga_mwhudson: I used a yakkety vm, got the package from proposed and ran kvm based autopkgtest09:15
zyga_zyga: where is this damn session09:16
mwhudsonzyga_: hm, i tried the same and the failed just a few seconds ago in fact09:16
mwhudsonlet's see if the failures looked similar09:16
zyga_mwhudson: how did you run the test?09:16
mwhudsonadt-run --unbuilt-tree . --- qemu ~/adt-yakkety-amd64-cloud.img09:16
mwhudsonfrom a git tree checked out to the release tag09:16
zyga_I ran something different09:16
zyga_give me a sec09:17
mwhudson ~/adt-yakkety-amd64-cloud.img  is what adt-buildvm-ubuntu-cloud -r yakkety spat out09: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 ran09:17
mwhudsonhmm i think i see fewer failures than on autopkgtest.u.c09:19
zygalet me find my irc session09:19
=== zyga_ is now known as zyga
zygamwhudson: autopkgtest-buildvm-ubuntu-cloud -v -a amd64 -r yakket09:20
mwhudsonoh well, that's not significantly different09:21
zygaautopkgtest snapd_2.0.10+16.10.dsc  -- qemu09:21
* zyga tries again09:21
mwhudsonoh no, i did get the same errors09:22
mwhudsonas https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/s/snapd/20160707_052336@/log.gz09:22
mwhudsoni got less output spam though, whatever that means09:22
mwhudsonsigh failures in teardown09:24
mwhudsonalways a good smell09:24
mwhudsonmessages like "Unit snap-basic\x2dbinaries-x1.mount not found." make my have unicode paranoia09:25
mwhudsonbug 157172109:25
mupBug #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
zygatrying again09:30
zygamwhudson: most interestingly, tests don't fail if you just run them09:32
zygamwhudson: I mean from the tree09:32
mwhudsonzyga: and they don't fail on xenial, right?09:32
zygamwhudson: yep09:32
zygamwhudson: one thing I didn't test, fully proposed update09:32
zygamwhudson: I only ran this with yakkety + snapd from proposed09:33
mwhudsonwhat's significantly different in yakkety? systemd, kernel i guess09:33
mwhudsonahhh hm09:33
zygamwhudson: yep, just note that arch has the same version and it is all good there :/09:33
zygaso ... hmm?09:33
mwhudsoni think this is the key failure:09:33
mwhudsonerror: 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
mwhudsonA dependency job for snap-basic\x2dservice-x1.mount failed. See 'journalctl -xe' for details.09:33
mwhudsoni *think* all the rest is fallout from that09:34
mwhudsonbut i hardly know what is going on :)09:34
zygawhat is the dependency job?09:34
zygathe fact that systemd says the unit changed on disk is not new in 23009:34
zygaperhaps the dependency will tell us more09:34
mwhudsoni should run it again in that mode that lets me ssh in afterwards09:34
zygahow do you do that?09:35
zygaI'll replicate here and see what we get09:35
zygarunning zyga@yakkety:~$ autopkgtest --shell-fail snapd_2.0.10+16.10.dsc  --- qemu ~/autopkgtest-yakkety-amd64.img09:43
mwhudsonzyga: i'm not completely sure what's happening now but i have this feeling my run is going to pass09:44
zygado you know how regression tests are ran? is it with everything from proposed or just the one package?09:45
zygaand if it is the former, how can we replicate that?09:45
mwhudsoni don't09:45
mwhudsonand by editing the sources.list in the image, i assume09:45
zygawell, I can just upgrade to proposed and run tests locally09:46
mwhudsonbah it failed but the --shell-fail magic did too somehow09:47
zygamy run is still in progress09:47
mwhudsonzyga: <pitti> mwhudson: it tries to limit -proposed packages to just the trigger and its dependencies09:48
mwhudson<pitti> sometimes that doesn't work (stuff is uninstallable), then it falls back to enabling all of -proposed09:48
mwhudsonzyga: i pasted your question in #ubuntu-quality btw09:48
zygamwhudson: thanks!09:48
zygawell, we can try the full proposed one I guess09:49
zygamy tests are still ongoing09:49
mupPR 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
mwhudsonzyga: apparently a known intermittent thing, i'm running again09:52
zygamwhudson: my run is still in progress, no failure yet09:53
zygamwhudson: I really wonder if there's a difference between how we run tests09:54
mwhudsonzyga: aaah the build failed this time!09:54
mwhudsonFAIL: policy_test.go:103: policySuite.TestIterOpBadTargetdir09:55
zygamwhudson: what's the rest of the error?09:55
zygamwhudson: and can you reproduce that with the .dsc?09:56
zygamwhudson: I see it run ./get-deps09:57
mwhudsonzyga: http://paste.ubuntu.com/18692046/09:57
zygamwhudson: I don't think that should ever be done in autopkgtests09:57
zygaisn't the whole idea to run tests from packaged bits09:58
zyga+ ./get-deps.sh09:58
zygaObtaining dependencies09:58
zygamwhudson: what is $HOME like?09:58
mwhudsondon't know09:59
zygaso far it still hasn't failed for me09:59
mwhudsonprobably just /home/ubuntu09:59
=== hikiko is now known as hikiko|ln
zygastill not failed10:01
zyga(my computer is slower :-)10:01
zygaah, it failed now!10:02
zygasame way10:02
zygaerror: 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
mwhudsoni think10:02
mwhudsonok package build worked this time10:02
zygahmm, the failshell instructions don't work for me10:03
zygalet's try to fail this on native yakkety without adt so that tinkering is easier10:03
zygaeh, we should really replace the one dependency that needs bzr10:06
zygapulling all of python210:06
mwhudsonzyga: yeah i think the get-deps.sh invocation would  be better as cp -r /usr/share/gocode/src $tmp or something like that10:09
mwhudsonto use the packaged version of the dependencies10:09
mwhudsonthe --shell-fail failed again10:17
mwhudsoni guess i should figure out how adt-virt-qemu runs the vm and do it by hand10:20
mwhudsonbut maybe not today10:20
mupPR snapd#1502 opened: Add an interface for tpm 1.2 <Created by jessesung> <https://github.com/snapcore/snapd/pull/1502>10:31
dholbachattente, 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
netphreakDo i need to set anything special in my snapcraft.yml, if my snap requires network access?11:19
qenghonetphreak: yes11:20
netphreakanywhere i can see an example of that?11:20
qengho$ snap interfaces   # list of plugs11:21
gouchinetphreak: https://github.com/snapcore/snapd/blob/master/docs/interfaces.md11:21
qenghoIn the app definition, "plug: [ network ]"11:21
qenghoHrm, 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
mupPR snapcraft#635 opened: Fix parts cache handling <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/635>11:32
mupPR 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
mupPR snapd#1504 opened: debian: chmod created config files to 0644 <Created by zyga> <https://github.com/snapcore/snapd/pull/1504>12:22
mupPR snapd#1505 opened: store: introduce a search grammar (baby step #1) <Created by chipaca> <https://github.com/snapcore/snapd/pull/1505>12:25
sergiusenskyrofa hey, is this only failing due to ros and friends? https://github.com/snapcore/snapcraft/pull/63312:40
mupPR snapcraft#633: qmake plugin: Stop doing out-of-source builds <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/633>12:40
mhall119kyrofa: zyga: is there a solution to the "clicking a URL in a snap doesn't open it in the browser" bug?12:52
mupPR snapd#1506 opened: store/auth: add helper for the macaroon refresh endpoint <Created by matiasb> <https://github.com/snapcore/snapd/pull/1506>12:57
sergiusensmhall119 there's a bug and attente was working on that12:58
sergiusensmhall119 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 that12:58
seb128sergiusens, bug #159741713:00
mupBug #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
mhall119sergiusens: how can we re-use the url-dispatcher that does this on the phone?13:00
seb128you can maybe confirm it13:00
mupPR snapd#1507 opened: cmd: add buy command <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1507>13:00
seb128mhall119, I don't think we need url dispatcher there, we have snapd-xdg-open in yakkety which is supposed to do that13:02
seb128unsure if it works out of the box though13:02
seb128that's also something that needs to be backported to xenial13:03
mupPR snapcraft#635 closed: Fix parts cache handling <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/635>13:05
sergiusensseb128 thanks13:09
mhall119seb128: and that works based on the MimeType field in the .desktop files?13:13
mupBug #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
attenteseb128: besides backporting snapd-xdg-open, the fake xdg-open script needs to be inserted into the os snap13:16
seb128mhall119, urls are special cases of mimetypes so I guess in some ways13:16
seb128attente, that was done in yakkety?13:16
kyrofasergiusens, I just merged with master, so I'll let you know13:18
attenteseb128: i don't recall, i thought mvo took care of that part though13:18
seb128mvo, ^ do you know what's the status there? ;-)13:18
seb128attente, thanks13:18
mvoattente: its in the os snap already (maybe not yet in stable? definitely in edge)13:25
mvoseb128: -^13:26
attentemvo: ok, thanks. so i guess the only thing missing is backporting to x13:26
seb128mvo, do we have an os snap installed on classic?13:26
kgunnyo, just updated y'day and i'm seeing an error on snap list13:26
didrocksseb128: yeah, we do13:26
kgunnerror is "error: cannot list snaps: cannot unmarshal: json: cannot unmarshal string into Go value of type int"13:26
mvoseb128: yes13:27
mvoattente: people get it from the os snap, we don't need to backport it (unless I miss something)13:27
didrocksmvo: I don't find it r122: /snap/ubuntu-core/current$ sudo find . -name 'xdg-open'13:27
attentemvo: backporting snapd-xdg-open to xenial for the other half of that interaction13:27
mvoattente: 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 days13:27
seb128didrocks, mvo, how do I see what it's in my os snap? snap list only includes ubuntu-core13:27
didrocksseb128: this is the os snap13:27
mvoseb128: 122 is stable, right?13:27
attentemvo: and also pulling it as a depends13:28
seb128mvo, 122 of what?13:28
seb128mvo, 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 snaps13:28
mvoseb128: I will double check, I think r122 of ubuntu-core is the stable version that has n been updated in a while13:29
kyrofasergiusens, nope, example tests are still busted13:29
seb128mvo, ubuntu-core is the os snap?13:29
mvoseb128: yes, correct13:29
seb128or are they different things13:29
seb128ah ok13:29
mvoseb128: sorry for the confusion13:29
seb128no worry13:29
mupPR 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
attenteChipaca: hey, for some reason, snapd still doesn't be returning an icon uri despite the snaps dpm uploaded being series 1613:37
dpmChipaca, https://launchpad.net/bugs/158826613:39
mupBug #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
mupPR 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
sergiusenskyrofa which ones?13:49
mupPR snapd#1509 opened: interface: add new interfaces.all.SecurityBackends <Created by mvo5> <https://github.com/snapcore/snapd/pull/1509>13:51
kyrofasergiusens,, image creation failure seems like13:51
kyrofafgimenez, any idea on that one? ^^13:52
fgimenezkyrofa, looking13:52
kyrofasergiusens, I think my last successful run was a few days ago at this point :P13:54
gQuigshi there, I get an error message when I try running any snap:13:59
gQuigs$ snap run vlc13:59
gQuigsexecv failed: No such file or directory13:59
fgimenezkyrofa, seems like a quota problem, there are two danglling instances, i'll try to identify and delete them, will ping you when done13:59
kyrofaThanks fgimenez13:59
gQuigs$ snap run hello14:00
gQuigs2016/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 denied14:00
gQuigsexecv failed: No such file or directory14:00
gQuigsslightly better error with hello I guess..14:00
kyrofagQuigs, that's not typically how one runs apps14:00
kyrofagQuigs, run stuff out of /snap/bin14:00
kyrofa(which should be in your PATH)14:00
gQuigskyrofa: hmm.. then it's not obvious how to run some...14:02
gQuigskyrofa: for example, run hello and it says not installed14:02
gQuigsand what if I have both vlc snap and vlc deb installed?  how to pick?14:02
kyrofagQuigs, is hello installed?14:03
gQuigs$ /snap/bin/hello14:04
gQuigsHello, world!14:04
gQuigs$ hello14:04
gQuigsThe program 'hello' can be found in the following packages:14:04
kyrofagQuigs, is /snap/bin in your PATH?14:04
fgimenezkyrofa, should be fixed now14:05
kyrofaThanks fgimenez, re-running now14:05
gQuigskyrofa: nope, it's not.. swear it was.. hmm14:05
kyrofagQuigs, hmm indeed14:06
gQuigswith path set, hello works14:08
gQuigsbut snap run still doesn't.. should that work?14:09
netphreakHow can i see what version of snapcraft and snap i installed?14:09
niemeyerjdstrand: Heya14:09
niemeyerjdstrand: Do you need any state currently in Spread-B?14:09
gQuigsnetphreak: does --version not work for you?14:09
niemeyerjdstrand: We're having some connectivity issues between the freemont DC and Google services, so I'm moving it out to a different DC14:10
seb128mvo, 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 something14:11
mupBug #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
seb128it's important to make desktop applications useful14:12
seb128like 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 nautilus14:12
gQuigskyrofa: so for VLC the deb takes precedent (based on how I did path).  Should snap run work is that deprecated?14:12
kyrofagQuigs, 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/bin14:13
kyrofagQuigs, it's an implementation detail14:14
kyrofagQuigs, and I'm not sure that it actually works in the version of snapd released currently-- it's finished in the one being released now14:14
kyrofagQuigs, so for a consistent experience, use /snap/bin/14:15
netphreakHow do i upgrade to the latest snapd 2.0.10? I'm on apt-get14:15
sergiusensseb128 I have the same problem when clicking on telegram.me links ;-)14:15
mvoseb128: what needs to happen? does snapd needs to just run update-desktop-database after new desktop files got created?14:16
gQuigskyrofa: so I should eventually work ?14:16
kyrofagQuigs, yes, but again, you should never need to use it directly14:17
jdstrandniemeyer: no-- I can -discard now if that makes things easier for you14:17
niemeyerjdstrand: Ah, yes please, thanks!14:17
seb128mvo, yes14:17
jdstrandniemeyer: but when can I start up a new one with -keep?14:17
niemeyerjdstrand: Feel free to pick another one when you need14:17
niemeyerjdstrand: Immediately14:18
gQuigskyrofa: thanks!14:18
niemeyerjdstrand: Hopefully I'll be faster and nuke the machine before you grab it again :)14:18
niemeyerjdstrand: There are other machines available on the new DC already14:18
jdstrandniemeyer: discarded14:18
seb128mvo, the mimetype handlers look into indexes and that dir doesn't have one so its entries are not registered14:18
seb128mvo, just doing the update command makes it work14:18
niemeyerjdstrand: Thanks, removed.. will re-allocate new ones with the same names on the new DC14:19
jdstrandniemeyer: 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 used14:19
niemeyerjdstrand: Wooo, that's great to hear! Thanks!14:19
jdstrandreally nice. I was writing spread tests in just a few minutes14:19
jdstrandgranted, I was using an existing project with spread.yaml, but still. good stuff :)14:20
attenteseb128: 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
mupBug #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
jdstrandniemeyer: oh and -debug is fantastic14:21
seb128attente, that SRU bug should do the trick14:21
niemeyerjdstrand: Yeah, I was very pleased with that one as well. So convenient to be able to jump in at the exact breakage14:22
attenteseb128: thanks!14:23
seb128attente, yw!14:24
jdstrandniemeyer: 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
attenteseb128: could you please sponsor it for xenial? or should i subscribe ubuntu-sponsors?14:25
jdstrandniemeyer: fyi, I have Spread-E now14:26
niemeyerjdstrand: 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
niemeyerjdstrand: Ack14:26
niemeyerjdstrand: That is, $ spread <options> linode:14:27
niemeyerjdstrand: Then it'll run only things in Linode14:27
jdstrandniemeyer: 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
jdstrandeg, if I just call 'spread'14:27
niemeyerjdstrand: 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 rest14:28
jdstrandI see. ok, thanks14:28
niemeyerjdstrand: That's the main distinction between aborted and failed, btw.. aborted means "didn't even try"14:28
jdstrandah, yes. that makes sense14:29
jdstrandI was trying to wrap my head around how useful it would be to add lxd backends to things and how that might affect people14:29
jdstrandI'm not actively working on that-- just was curious14:30
mvoseb128: thanks, that sounds pretty straightforward14:38
niemeyerjdstrand: I have a background idea that I haven't quite designed yet, but which might fit with what you describe14:38
niemeyerjdstrand: I'd like a way to mark certain tests as "manual"..14:38
niemeyerjdstrand: IOW, should only fire when explicitly requested14:39
niemeyerjdstrand: Need to find a way to blend that into the default job matching behavior in a non-awkward way14:39
jdstrandyeah, that would definitely work for this use case so long as it could be applied to backends as well as tests and suites14:40
jdstrandwhich in saying that, I see what you mean be it needing some design :)14:41
niemeyerjdstrand: Yeah, it'd need to work in a similar way to everything else.. cascading through the matrix14:41
niemeyerMight be just a test in a suite, or a suite, or whole backend14:41
jdstrandanyway, I'm not using lxd just yet here for that, but I was excited to see it as a backend14:42
niemeyerI 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
seb128mvo, thanks14:43
mupPR 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
seb128attente, 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 monday14:58
mupPR snapd#1510 opened: integration-tests: remove login tests <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1510>15:01
mvoattente, seb128: sure I can sponsor, just ping me15:02
seb128mvo, great, thanks!15:02
zygajdstrand: I wrote a spread test for the apparmor profile15:05
zygajdstrand: just testing it and I'll add it to the pull request15:05
zygajdstrand: you said you want to have another thing in .36?15:05
zygajdstrand: can you be more specific please?15:05
jdstrandzyga: I want only that in .3615:09
jdstrandI mean, other things can be there, but we need to make sure we don't lose confinement for the next ubuntu upload15:09
zygajdstrand: .35 was released, .36 is today15:10
jdstrandzyga: 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 ubuntu15:12
attentemvo: thanks! is there anything you need from me for the sru?15:12
zygaah, ok15:12
zygaso there's nothing else you want to fix?15:12
zygawhat about the nodev thing that was also mentioned by SUSE folks?15:13
jdstrandzyga: I do have something I was working on but it doesn't have to be for .3615:16
zygasounds good then15:16
jdstrandzyga: 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 nosuid15:18
jdstrandzyga: ok, phew, I see in sc_setup_mount_profiles that MS_NODEV and MS_NOSUID are used15:21
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
zygayes, the user mounts are safe15:25
zygathose that are controlled by the user15:25
zygabut remember that all you need to do is to ship a snap with /dev/sda node15: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
zygaand you're good :-(15:25
ogra_and i have to put gcc-5 into build-files15:25
ogra_err build-packages15:25
sergiusensogra_ not make, but autotools and cmake yes15:34
ogra_why not make ?15:34
jdstrandniemeyer: I have a potentially dumb question re environment and spread. I'm try to do:15:34
sergiusensogra_ there are a bunch of examples where people use make as they would use the copy plugin15:34
jdstrand    CORESNAP: $(mount | grep ubuntu-core | tail -1 | cut -f 1 -d ' ')15:35
jdstrandexecute: |15:35
jdstrand    ...15:35
ogra_sergiusens, yeah, i have done that too ... but still, gcc is broken if you depend on it15:35
jdstrand    echo "CORESNAP=$CORESNAP"15:35
jdstrand    ...15:35
sergiusensogra_ as a build-packages?15:35
ogra_sergiusens, the needed symlinks are alternatives ...15:35
jdstrandniemeyer: but $CORESNAP is empty15:35
jdstrandniemeyer: the is in task.yaml15:35
ogra_sanpcraft doesnt run postinsts ... so the symlinks are missing15:35
sergiusensogra_ build-packages do run postinsts15:36
sergiusenswhat are you talking about?15:36
ogra_well, not here15:36
sergiusensthere are a bunch of tests for this15:36
jdstrandniemeyer: if I do under execute: echo "CORESNAP=$(mount | grep ubuntu-core | tail -1 | cut -f 1 -d ' ')" I see what I want15:36
sergiusensogra_ use build-packages, not stage-packages15:36
ogra_i tried to make all my packages "cleanbuild" safe today15:36
ogra_and all of them are missing these links15:36
jdstrandniemeyer: I can sprinkle that command around and am not blocked, but it seems like environment should be able to handle this15: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.yaml15:38
ogra_(and a few others i havent public yet)15:38
sergiusensogra_ ah you are explicitly installing gcc-5, that won't create the gcc link you want15:38
ogra_if i use gcc-5 in build-packages there are definitely no alternative links set15:38
ogra_it does if i install gcc-5 on a normal desktop15:39
sergiusensogra_ because you have gcc installed as well15: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 crontab15:40
ogra_( i changed that yesterday ,,, forgot to tell you about it)15:41
ogra_sergiusens, bah, and indeed you are right :P15:46
* ogra_ goes and fixes all branches again ... mental note: ask first next time before writing a workaround15:47
sergiusensogra_ iirc gcc has the alternative stuff and didrocks told me we install it by default on desktop now too15:47
ogra_we always did15:47
ogra_it is a requirement of dkms15: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
mupPR 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
mupBug #1599919 opened: SnapOpSuite unit tests interfere with the user's $HOME/.snap directory <Snappy:New> <https://launchpad.net/bugs/1599919>16:03
niemeyerjdstrand: 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 unexpected16:10
niemeyerjdstrand: Right now that's how we can provide secrets and local info in general to the tests16:11
jdstrandI see16:11
jdstrandok, well, like I said, I'm not blocked16:11
jdstrandthanks for the explanation16:12
mupPR snapcraft#636 opened: parser - Handle malformed wiki entries <Created by josepht> <https://github.com/snapcore/snapcraft/pull/636>16:30
mvoogra_: thanks for the heads up16:32
mupPR snapd#1511 opened: overlord: actually run hooks <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1511>16:32
mvoattente: if you could prepare it so that I just need to dput the sru that would rock of course, if not just let me know16:33
attentemvo: sure16:38
attentemvo: i literally just changed the release to xenial and the date in the changelog: https://launchpad.net/~attente/+archive/ubuntu/snapd-xdg-open/+packages16: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
zygamvo, attente: can we please do an upstream release of snapd-xdg-open17:07
zygawe really want it everywhere, not just ubuntu17:07
zygaif you want I can look at this17:09
mupPR snapd#1512 opened: overlord: initial work on renaming core snap <Created by zyga> <https://github.com/snapcore/snapd/pull/1512>17:15
sergiusenskyrofa this is good to go https://github.com/snapcore/snapcraft/pull/63217:15
mupPR snapcraft#632: WIP Refactor/push <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/632>17:15
attentezyga: sure, but i don't have push access to that repo. i think mvo does however?17:16
kyrofasergiusens, looks like it needs to be merged with master17:22
sergiusenskyrofa really, again?17:23
sergiusenskyrofa there you go17:23
kyrofasergiusens, thank you! Also consider changing the title17:24
sergiusenskyrofa so pushy, I was going to change it while merging :-P17:24
sergiusenskyrofa there you go17:25
kyrofasergiusens, I know you. You'll forget, and then our history will be hilarious17:25
zygajdstrand: I've updated snap-confine#7317:26
mupPR snap-confine#73: Update apparmor profile for snap-confine <Created by zyga> <https://github.com/snapcore/snap-confine/pull/73>17:26
zygajdstrand: I didn't rename policy file because I think this simply belongs in downstream packaging and it is more and more evident17:27
tsimonq2what sort of unit test coverage should I seek for my PR? ( snapcraft#619 )17:27
mupPR 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
tsimonq2integrated in the Tar and Zip classes or in it's own class?17:28
tsimonq2kyrofa: ^17:28
kyrofatsimonq2, taking a look now17:29
jdstrandzyga: 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 that17:29
tsimonq2thanks kyrofa17:29
jdstrandzyga: alternatively, skip all that and just rename to 'snap-confine'17:29
jdstrandzyga: the only thing apparmor cares about is what's inside17:30
zygajdstrand: I'd simply put it in src/apparmor-profile.in17:30
zygajdstrand: and have the makefile generate the real one17:30
jdstrandthat works too, but then update the debian/ packaging17:31
zygajdstrand: downstream packaging will be doing the rename17:31
zygajdstrand: yep, I will have to do it for debian and ubuntu then17:31
zygajdstrand: 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/ubuntu17:31
zygajdstrand: right now debian/ is not used anywhere for real17:32
kyrofatsimonq2, actually I think your units look pretty good. I'd check the coverage, though (do you know how to do that?)17:34
kyrofatsimonq2, however, while you have an integration test snap, you don't have an integration test. Are you working on that?17:34
kyrofaBecause that will be important17:35
tsimonq2kyrofa: so do you think my integration tests need to be added to the tar and zip tests or it's own test?17:35
kyrofatsimonq2, oh I see what you're asking17:35
kyrofatsimonq2, I say add them to tar and zip17:37
tsimonq2kyrofa: okay, so it's in the snap, I need to add to the python?17:37
kyrofatsimonq2, so add some more to the simple-zip snap, then add checks to the integration tests that use simple-tar and simple-zip17:37
kyrofatsimonq2, exactly17:37
kyrofatsimonq2, I'm not sure it's worth adding new archives though-- just take the checksums for the archives already in the snaps17:38
tsimonq2kyrofa: alright17:38
tsimonq2kyrofa: all of them? which ones would you suggest?17:39
kyrofatsimonq2, oh, scratch that. Forgot there were multiple. Go ahead and add a new one :)17:39
tsimonq2alright :()17:39
kyrofatsimonq2, do you know how to check the coverage?17:40
tsimonq2kyrofa: yeah there's a report17:40
tsimonq2kyrofa: that's talking about unit tests right?17:41
tsimonq2kyrofa: or is that integration?17:41
kyrofatsimonq2, yup, units, you got it17:41
tsimonq2kyrofa: if it's unit, do I add my tests to the Tar and Zip classes or do I make my own class?17:41
kyrofatsimonq2, wait... now I'm not sure what we're talking about17:41
tsimonq2kyrofa: in snapcraft/tests/test_sources.py (or whatever the name of the file is)17:42
kyrofatsimonq2, 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 checksums17:42
tsimonq2kyrofa: there's class TestTar(tests.TestCase): and class TestZip(tests.TestCase):17:42
kyrofaBut the integration tests go in integration_tests, not snapcraft/tests (those are units). Am I answering your question? :P17:43
tsimonq2kyrofa: no17:43
tsimonq2so here's what I'm asking17:43
kyrofaHeh, sorry17:43
tsimonq2I added unit tests for incompatibility, right?17:43
tsimonq2what about for testing that it works?17:43
tsimonq2or that it successfully checks the checksum?17:44
sergiusenskyrofa might be good to go, but I don't want to update branch again ;-) https://github.com/snapcore/snapcraft/pull/63317:44
mupPR snapcraft#633: qmake plugin: Stop doing out-of-source builds <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/633>17:44
kyrofaWell, in order to test that it works, you need to make something to take a checksum OF17:44
kyrofaThat is an integration test17:44
kyrofasergiusens, you're so mean :P17:44
tsimonq2kyrofa: so then what's the difference between integration and unit?17:44
mupPR 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
kyrofasergiusens, oh ha! I see what you're saying now ;)17:45
sergiusenstsimonq2 kyrofa difference between unit and integration changes depending on who you ask17:46
sergiusenstsimonq2 kyrofa we've settled for integration meaning talking to external servers and using real code to run snapcraft agains using the real snapcraft command17:47
sergiusensand for unit, we use some other module17:47
sergiusensto call as under test17:47
kyrofatsimonq2, 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 though17:47
sergiusensand we consider it totatlly fine to generate artifacts on disk these days17:48
tsimonq2kyrofa: so do I need a unit test or not for the coverage?17:48
kyrofatsimonq2, indeed, integration doesn't count toward coverage17:48
zygajdstrand: arch now ships snap-confine 1.0.3517:48
sergiusenskyrofa 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
zygaarch is FAST :)17:49
sergiusenskyrofa aside from an integration test17:49
sergiusenszyga how fast?17:49
zygasergiusens: I mean, fast to update17:49
kyrofasergiusens, it needs to be a tar or zip source though17:49
zygasergiusens: that's not me updating the package17:49
zygasergiusens: that's arch maintainer17:49
kyrofasergiusens, but yeah, you're right, not a big deal17:49
zygasergiusens: it was released a day ago17:49
sergiusenskyrofa you could use the tar or zip modules for that, with tar.open...17:49
zygaon another note, I just got most spread tests to work on debian sid17:49
kyrofatsimonq2, sergiusens's idea is probably better than mocking17:50
kyrofatsimonq2, use that to make sure your code is covered, and then use the integration tests to cover end-to-end17:50
tsimonq2kyrofa: 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
kyrofatsimonq2, hold on, my son is asking me to tuck him in for his nap, be right back17:52
tsimonq2alright kyrofa :)17:52
mcphailCan someone point me to details of how to get launchpad to build ARM snaps?17:53
kyrofamcphail, https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way17:54
mcphailkyrofa: thanks!17:54
kyrofasergiusens, how would you like him to determine the checksum in a known manner that still tests his code?17:55
sergiusenskyrofa I don't follow17:55
tsimonq2sergiusens: I need unit test coverage, how would I go about doing that for snapcraft#619 ?17:56
mupPR 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
kyrofasergiusens, 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
sergiusenstsimonq2 by creating known files on the fly as part of the test fixture setup and passing those to your source (Zip, Tar) calls17:57
kyrofasergiusens, i.e. saying "use my code to get checksum" -> "test that my code that gets checksum matches that checksum" isn't really a valid test17:57
kyrofasergiusens, 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
kyrofazyga, good for arch, they're ahead of ubuntu!18:00
kyrofazyga, how is that SRU coming? :P18:01
zygakyrofa: I don't know18:03
zygakyrofa: I'm not doing the SRU work really :/18:03
zygakyrofa: I'm working on .36 for more SRU :P18:03
mvoattente: hm, what was the sru tracking bug again? I think that should also be in the changelog :) I can add it18:04
kyrofazyga, hahaha18:04
mvoattente: aha, found it18:05
mcphailCan 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 machine18:05
kyrofamcphail, huh... looks like their snapcraft might be out of date... ?18:05
mcphailkyrofa: hmm. Should I poke someone about that?18:06
mvozyga: for xnapd-xdg-open - you just need a git tag? or more?18:06
kyrofamcphail, hop in #launchpad. I just asked18:06
zygamvo: what's the buildystem there? I don't recall18:07
zygamvo: ideally a make dist tarball and a release on github18:07
zyga(or launchpad)18:07
zygamvo: and some simple packaging instructions18:07
mvozyga: autotools18:07
zygamvo: is that something that goes into the snap in any way or is it just the host distro18:08
mvozyga: ok, can do in a bit18:08
zygamvo: thanks18:08
zyga(I guess arch will be first again :)18:08
mvozyga: we need it alongside snapd18:08
zygajdstrand: FYI, https://github.com/snapcore/snap-confine/pull/7418:09
mupPR snap-confine#74: Debian spread tests <Created by zyga> <https://github.com/snapcore/snap-confine/pull/74>18:09
zygajdstrand: sid support in spread18:09
kyrofamcphail, to be fair I didn't document that very well in the post, so I'm adding a blurb now18:17
zygajdstrand: 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 one18:19
jdstrandzyga: I think I've been pretty clear :)18:27
jdstrandzyga: 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 feature18:28
mcphailkyrofa: getting different build errors now, but making progress. Thanks!18:31
kyrofamcphail, good deal! Let me know if you need any help18:31
mcphailkyrofa: when building on lp, I assume installing libpcre3-dev doesn't automatically install libpcre3 as well?18:32
zygajdstrand: but ubuntu 16.10 will get .35 through debian so isn't the cat out of the bag already?18:33
kyrofamcphail, I assume it does, isn't it a dependency?18:33
zygajdstrand: let me re-read your comments, I'm not sure what the next step is there18:33
kyrofa(I've not actually looked at the cache)18:33
jdstrandzyga: 16.10 is the dev release. 16.04 is stable. we can't regress this security feature in 16.0418:34
jdstrandwe shouldn't in 16.10, but if we do we just fix it18:35
mcphailkyrofa: 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
kyrofamcphail, ah, must be already installed then18:36
jdstrandzyga (cc tyhicks): the next step is to give examples of mount profiles that snapd currently implements18:36
zygajdstrand: only the content interface uses them18:36
attentemvo: ah, sorry, thanks for catching that18:36
zygajdstrand: and the read/write paths are decided by plug/slot attributes18:36
jdstrandzyga (cc tyhicks): and then understand precisely what mount rules are needed18:36
zygajdstrand: any value is allowed right now18:36
zygajdstrand: that fact implies that any mount rules might be allowed18:37
jdstrandzyga: yes, but the source mount point is inside a snap, not /**18:37
jdstrandzyga: and the target mount point is inside a snap, not /**18:37
zygajdstrand: one useful use case is /var/lib/snapd/hostfs/usr/share/fonts18:37
zygajdstrand: as for the target directory, let me check18:37
argesHi, 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
mcphailkyrofa: perhaps I need to add pkg-config as a build dependency? I'd assumed that would be default?18:37
jdstrandzyga: but the fonts directory is an implicit slot, not the content interface18:38
tyhickszyga: sorry to distract from the discussion but does the snap itself define the plug/slot attributes?18:38
zygajdstrand: it would be a slot on the core snap (it doesn't exist yet)18:38
zygatyhicks: yes18:38
zygasmall clarification, currently both source and destination are rooted at $SNAP18:38
jdstrandzyga: right, so we add a rules for /usr/share/fonts like we do for /etc/alternatives18:38
kyrofamcphail, indeed, try adding that18:38
zygaso I guess we can constrain those profiles to /snap/*/**18:39
jdstrandzyga: and then a different glob rule for content18:39
jdstrandyes! :)18:39
kyrofamcphail, it's not a default-- not everything needs it18:39
zygaI missed those two lines, I just read the content interface18:39
mcphailkyrofa: ok, thanks18:39
kyrofamcphail, not even gcc/g++ is a default18:39
mcphailkyrofa: so we need to add build-essential?18:40
kyrofamcphail, you can, but that's a bit of a shotgun18:40
jdstrandunfortunately, /snap/bin is in there and shouldn't be mounted, so we'll need several rules to express /snap/*/**.18:40
tyhickszyga: when reviewing the bind mount PR, I thought we were in full control of the source and destination paths18:40
jdstrandtyhicks: we are18:40
kyrofamcphail, 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
kyrofamcphail, everything else you have absolute control over18:41
jdstrandtyhicks: for content it is relative to the providing snap's and consuming snap's directories18:41
jdstrandwhich is why I kept saying let's constrain this to what we actually allow18:41
mcphailkyrofa: 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
tyhicksdo we have protections against "../" components in the path?18:42
zygathat's a bit unfortunate for font sharing though, there's no way to describe that18:42
kyrofamcphail, indeed, cleanbuild18:42
jdstrandzyga: font sharing?18:42
zygatyhicks: we ensure that filepath.Clean(path) == path18:42
jdstrandzyga: regardless, we can have a separate rule for the fonts dir, just like we do for all the others18:42
mcphailkyrofa: nice. Thanks18:42
zygathat is, no ../ bits are present18:42
zygajdstrand: (this is actually inside snapd that we'd have to allow this)18:43
zygajdstrand: to make the source *not* relative to the core snap18:43
zygabut I think we are good actually18:43
jdstrandzyga: I'm confused about what you are talking about there18:43
zyganot for fonts but for this18:43
zygajdstrand: sorry, I'm just observing that content sharing interfae cannot be used to share fonts from the host today18:43
zygabut that's not a problem at hand, sorry for adding this to the mix18:44
jdstrandwell, in the future we can add whatever mount rule is needed for fonts too18:44
jdstrandso, I think some sort of /snap/*/** mount rule with a comment that it is to enable the content interface is fine18:45
mcphailkyrofa: actually, looks as if gcc is in the base launchpad build instance already18:45
zygajdstrand, tyhicks: https://github.com/snapcore/snap-confine/pull/73/commits/24bbd4338d24e97330ccd20e3cb01cb714b5f08c18:48
mupPR snap-confine#73: Update apparmor profile for snap-confine <Created by zyga> <https://github.com/snapcore/snap-confine/pull/73>18:48
jdstrandimportantly, you are going to have to do the crappy /snap/[^b]*/**, /snap/b[^i]*/**, /snap/bi[^n]*/**, /snap/bin?*/**, /snap/b/**, /snap/bi/** shenanigans18:48
jdstrandzyga: see ^. let me add a comment18:48
zygais that really needed?18:49
zygaI see why but what's the attack there?18:49
zygayou cannot run any of those things18:49
jdstrandyou don't want to mount /snpa/bin18:49
zygaand the mount is happening after unshare18:49
zygawhy not?18:49
zygawill any other process see that mount?18:50
jdstrandbecause like you say it is pointless and we are being fanatical to guard against attacks18:50
zygathat's a good answer18:50
jdstrandgive me a minute18:50
jdstrandwe are being as defensive as possible18:50
zygaI 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" answers18:50
jdstrandI can't think of an attack otoh18:51
zygaok, let me do the exclusive rules then18:51
jdstrandzyga: hold on18:51
zygabtw, would a deny rule be easier and would work too?18:51
jdstrandno deny rules18:51
jdstrandI mean we can18:52
jdstrandactually in this case that would be good18:52
jdstrandaudit deny mount /snap/bin/**,18:52
zygais the single argument form matching both source and destination?18:53
jdstrandthat is a good question18:53
jdstrandmount rule syntax is annoying18:53
jdstrandhow about: audit deny mount /snap/bin/** -> /**,18:54
jdstrandthat is clear18:54
zygajdstrand: wait, isn't that reverse18:54
zygajdstrand: source -> destination18:54
zygawe don't want to let people bind mount over that18:54
zygaor bind mount that somewhere?18:54
zygaactually, probably both18:55
zygajdstrand: like this? http://paste.ubuntu.com/18724566/18:55
zyga(not tested)18:55
mupPR snapd#1510 closed: integration-tests: remove login tests <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1510>18:56
zygaI'll add a few spread tests for this but I need to go now18:56
jdstrandI like that18:56
jdstrandI just read the man page and the single argument form is the source mount, but this is very clear18:56
mupPR snapd#1509 closed: interface: add new interfaces.all.SecurityBackends <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1509>18:57
jdstrandfyi, without those rules there would be an info leak on the installed snaps18:57
sergiusenskyrofa mind looking at https://github.com/snapcore/snapcraft/pull/62718:57
mupPR snapcraft#627: Added new maven-targets option to maven plugin <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/627>18:57
jdstrandwe don't protect against that perfectly today, but there are longer term work items that will address that18:58
zygajdstrand: good point about the info leak!19:00
zygajdstrand: I'll make the spread tests happen19:00
zygajdstrand: but now -> time to take a walk, it's 21:00 already19:00
jdstrandzyga: where'd the time go?!19:02
jdstrandzyga: thank you for working on this :)19:02
tsimonq2kyrofa: so what am I doing for the integration tests again?19:13
mupPR snapcraft#637 opened: Do not clean before running the snaps tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/637>19:18
kyrofatsimonq2, you're adding stuff to integration_tests/test_tar_plugin.py and integration_tests/test_zip_source.py19:22
tsimonq2kyrofa: oh okay19:22
sergiusensslangasek hey, how's that umbrella bug for SRUing supposed to be created?19:25
tsimonq2kyrofa: 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
slangaseksergiusens: 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 upload19:26
tsimonq2slangasek: 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
tsimonq2whoops sergiusens ^19:27
tsimonq2sergiusens: or do you think they shouldn't? thoughts?19:27
sergiusenstsimonq2 I can link them once a PR is up, seems like a lot for a weeks work though19:28
tsimonq2thanks sergiusens for clarifying19:28
kyrofatsimonq2, 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 zip19:29
tsimonq2kyrofa: but doesn't it already all run because it's in the snapcraft.yaml?19:29
kyrofatsimonq2, 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 that19:30
elopioslangasek: ping. Can you please reply here please? https://bugs.launchpad.net/snapcraft/+bug/1596068/comments/419:33
mupBug #1596068: The unittests in autopkgtest are run twice <verification-done> <Snapcraft:Fix Released by elopio> <https://launchpad.net/bugs/1596068>19:33
slangasekelopio: 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
elopioslangasek: they would catch regressions on dependencies, we don't fake everything. But those regressions should be caught too by the integration tests.19:41
elopioand on the integration tests we don't fake any of the dependencies.19:42
slangasekelopio: 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 covering19:43
sergiusensslangasek so about the SRU bug now :-)19:44
elopioslangasek: great, thanks.19:44
sergiusensslangasek 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
sergiusensand maybe a link to the wiki with the exception19:44
elopioah, that's the umbrella you were talking about.19:45
sergiusenselopio yes19:45
slangaseksergiusens: yes19:46
sergiusensslangasek works for me, thanks!19:50
elopiosergiusens: please call it the same as mvo is doing for snappy. It's like [SRU] New stable micro release X.X.X19:51
mupPR 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
tsimonq2sergiusens: when you have a minute, how do I do that unit test coverage? how do I test checksumming in the unit test? :)19:51
sergiusenstsimonq2 run ./runtests.sh unit && python3-coverage html19:52
sergiusenstsimonq2 apt install python3-coverage if not there19:52
tsimonq2sergiusens: I know how to test, how do I code the unit tests? basically, the clarifying question kyrofa asked19:52
tsimonq2(for my PR)19:52
sergiusenstsimonq2 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
sergiusensohh, I need to leave!19:55
tsimonq2elopio? do you agree? we're talking about how to do the coverage for snapcraft#61919:55
mupPR 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
elopiotsimonq2: yes, I agree. Ideally, check the sum in a real file, not mocking.19:57
tsimonq2thanks elopio :)19:58
elopiothanks to you.19:58
zygatime to hack19:58
zygajdstrand: does this look like the right approach? http://paste.ubuntu.com/18729680/20:07
mupPR 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
zygajdstrand: I wonder how to do that to see the deny in syslog somehow20:07
jdstrandzyga: deny in syslog is difficult. you can dmesg|tail -1|grep 'DEN...' but it has the potential to be racy20:10
jdstrandzyga: but yeah, that looks like a fine test20:10
zygajdstrand: I'll try to include some sort of audit trail there20:11
zygajdstrand: I could fork a journalctl -f and kill it later20:11
zygajdstrand: thanks, I'm reading your test20:12
zygajdstrand: one personal preference, quote arguments to echo20:12
DT01anyone around that can help with snapcraft 1.x - trying to get lsusb to work on snappy20:12
jdstrandzyga: you can probably make that pretty good by adding 10 entries with logger that don't match and then tail -1020:12
DT01I have a snapcraft file ready if someone could take a look20:12
jdstrandzyga: I normally like that myself, but wasn't sure how well that played with yaml20:13
zygaDT01: hey, on 1.0 and 15.04 that could be tricky, not sure if possible20:13
jdstrandzyga: that test was pretty annoying to write btw :P20:13
zygajdstrand: I think it works because the whole part there is "free form text" - or so it seems20:13
DT01zyga: 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 section20:15
zygaDT01: after that you'd be hit by confinement20:15
zygajdstrand: 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 section20:16
DT01zyga: so I need to run in unconfined mode?20:16
DT01btw this is for a personal system not to be published20:16
zygaDT01: yes and I don't remember how much of that existed in 15.0420:16
jdstrandzyga: idk20:17
DT01hmmm, I will take a quick stab at that20:17
jdstrandzyga: I was treating each dir as per-test and therefore the setup is per-test, but maybe there are other ways of doing it20:17
zygajdstrand: what do you mean by remote environment variables?20:18
zygajdstrand: AFAIR spread supports them20:18
jdstrandzyga: I found out the 'environment' runs the $(...) code locally and injects it to the remote end20:18
jdstrandzyga: see backscroll in this channel. I wanted to do environement: OSNAP=$(ls ...), but that ls is run on my laptop, not on the remote end20:19
zygajdstrand: there's also []20:19
zygajdstrand: [SOMETHING]20:19
* zyga looks at spread docs20:19
jdstrandzyga: I tried that, but it didn't work20:20
jdstrandzyga: I talked to Gustavo and he said that environment is currently there to support SPREAD_LINODE_KEY and not what I was doing20:20
zygajdstrand: I think I see what this does, it runs locally20:21
zygajdstrand: and sends the interpolated value already20:21
jdstrandbased on what he said and I observed20:22
zygajdstrand: FYI I just checked that you can have a prepare/restore per task20:24
zyga"owner died" geez20:29
mwhudsonzyga: https://launchpad.net/ubuntu/+source/snap-confine has 1.0.35 now \o/20:29
mupPR 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
tsimonq2elopio: 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
mupPR snapcraft#638 opened: Re-create feature/maven-targets branch for snapcraft <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/638>20:39
zygamwhudson: that's good, making .36 today :)20:44
mwhudsonzyga: no rest for the wicked!20:44
zygamwhudson: not in this world20:44
mwhudsonhopefully i won't screw up the gbp interactions so many times today20:44
zygamwhudson: I didn't manage to fix yakkety snapd tests20:44
zygamwhudson: no idea why that fails, I did a chmod on the two environment files that debian/tests scripts create20:45
zygamwhudson: but no difference20:45
mwhudsonzyga: i have a vm which i'm going to run the tests in by hand20:45
mwhudsonzyga: but my qemu-fu is pretty weak20:46
zygamwhudson: I have a vm with yakkety but I don't know how to run those tests without any abstractions in the way20:46
zygamwhudson: but I'm almost sure this is the testbed, not snapd that is at fault20:46
mwhudsonzyga: i guess staring at the diff between 2.0.2 and 2.0.3 might also be interesting20:47
zygamwhudson: I dind't think of that20:47
zygamwhudson: but it could be substantial :/20:47
zygamwhudson: maybe the diff between debian/tests is smaller20:48
mwhudson15k lines, haha20:48
mwhudsonzyga: i wonder if it just adds the test that fails or something...20:48
zygamwhudson: you mean debian/tests or snapd in general?20:51
mwhudsonsnapd in general20:52
mwhudsonbut i'm just guessing here20:52
mwhudsondebian/tests/integrationtests looks fairly different to what's in 2.0.1020:52
zygamwhudson: can we patch it somehow to run just the failing test20:55
zygamwhudson: to make iteration faster20:55
zygamwhudson: in general it takes ~30 minutes for me to run it to failure20:55
mwhudsonmust be possible somehow yeah20:55
zygajdstrand: my spread tests are improving20:56
zygajdstrand: I should be able to see the exact failure soon20:56
jdstrandcool :)20:56
zygajdstrand: I've uploaded snapd-hacker-toolbelt 0.2 that adds $SNAP/mnt as a mount point for testing20:56
mwhudsonzyga: feels like this "resume test after reboot" stuff must be related20:57
zygamwhudson: hmmm20:58
zygamwhudson: maybe snappy updates itself20: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 eorrr20:58
zygamwhudson: and something something reexec happens20:58
tsimonq2elopio, sergiusens: so this is on master and the static tests are failing20:58
zygatsimonq2: git diff? :)20:58
tsimonq2zyga: I checked that20:58
tsimonq2zyga: all clean20:58
zygatsimonq2: git log -p on that file?20:59
* tsimonq2 checks it out in /tmp and confirms again20:59
mwhudsonzyga: heh heh when we worked on pypy there were internal jokes about "stuff occuring" whenever we didn't know what was going on20:59
zygamwhudson: the local quantum fluctuation added 'e' there20:59
tsimonq2elopio, sergiusens: also confirmed in a clean checkout21:00
zygatsimonq2: locally installed package with a typo?21:00
tsimonq2zyga: huh?21:00
tsimonq2zyga: clone master locally, git pull origin master, then ./runtests static throws a failure21:01
zygatsimonq2: do you have the same python package installed locally?21:01
jdstrandzyga: I'll need to play with snapd-hacker-toolbelt sometime21:02
zygatsimonq2: I had plenty of cases where my /usr/lib/python3/site-packages/ would have something21:02
zygajdstrand: it's just busybox :>21:02
zygajdstrand: I will publish that somewhere21:02
tsimonq2zyga: I don't know what you are saying21:02
zygajdstrand: should this say anything? I don't see any denial     dmesg | grep DENIED21:02
tsimonq2really weird21:03
tsimonq2it passes on Travis...21:03
zygatsimonq2: what is the code, snapcraft?21:03
tsimonq2zyga: yeah21:03
zygatsimonq2: is python3-snapcraft installed?21:03
tsimonq2zyga: E: Unable to locate package python3-snapcraft21:03
zygahow about snapcraft itself21:03
tsimonq2yep installed21:04
zygatsimonq2: just sanity,remove it and try again21:04
tsimonq2zyga: snapcraft is uninstalled and it still21:05
tsimonq2*still fails21:05
jdstrandif you are using 'audit deny' and it tries to mount, it should, yes. you might want to: sysctl -w kernel.printk_ratelimit=021:05
zygatsimonq2: hmmmm21:06
zygaah, thanks21:06
zygajdstrand: how to undo that21:06
zygawhat's the default?21:06
zygajdstrand: audit deny or deny audit?21:09
jdstrandzyga: to undo, grab 'sysctl kernel.printk_ratelimit' then feed back in later: sysctl -w kernel.printk_ratelimit=$prev21:10
zygajdstrand: it deoesn't work21:10
zygajdstrand: digging deeper21:11
zygaspread is fantastic21:12
zygaI don't like only one thing about it21:12
zygaI prefer --options21:12
zygabut everything else is just amazingly useful21:12
jdstrandthe 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 first21:12
zygatrying that21:13
zygabecause the thing does "work" (busybox true fails)21:13
jdstrandzyga: it is possible that kern messages aren't going to syslog21:13
jdstrandzyga: they should if it is Ubuntu, but perhaps the syslogger is setup different21:14
zygajdstrand: this is 16.04 so ... they should21:14
jdstrandzyga: I saw denials with 'dmesg'-- do you see anything there?21:15
niemeyerAnyone seen this before: findfs: unable to resolve 'LABEL=writable'21:15
zyganiemeyer: looks like the partition doesn't have the filesystem label21:16
zyganiemeyer: then we don't boot far21:16
zyganiemeyer: I saw it while fiddling with images21:16
zyganiemeyer: are you trying to get an all-snap image into linode?21:16
niemeyerzyga: The label is properly set21:16
zygajdstrand: successs :)21:16
zygacannot mount /snap/bin at /snap/snapd-hacker-toolbelt/current/mnt with options bind,ro. errmsg: Permission denied21:16
zyganiemeyer: hmm21:16
zygajdstrand: a few more tweaks and I'll use this test as a base21:17
zygajdstrand: I'm using SNAP_CONFINE_DEBUG21:17
zygajdstrand: then it just puts errors on stderr and I can check that easily21: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
zygajdstrand: so the order DOES matter21:18
zygajdstrand: we can grep for "deny audit" vs "audit deny" perhaps21:19
elopiotsimonq2: are you on xenial or yakkety?21:19
tsimonq2elopio: yakkety21:20
jdstrandzyga: snapd and snap-confine don't otherwise use 'deny audit' (just checked)21:20
elopiotsimonq2: yes, it happens only with yakkety's flake8. Please report a bug.21:21
tsimonq2elopio: alright thanks21:21
tsimonq2elopio: I think I'm almost done too!21:21
zygajdstrand: thanks!21:22
niemeyerSomeone else reported the same thing in April, with no feedback: https://lists.ubuntu.com/archives/snappy-devel/2016-April/001729.html21:22
zyganiemeyer: fedora 25 can find snaps in the store :>21:23
zyganiemeyer: in gnome-software21:23
zygaso so cute :>21:23
niemeyerSweet :)21:23
zygajust watched this on G+21:24
zygathat's fantastic to see21:24
zygaI suspect this will land in Arch soon :)21:25
zygaI'm just going to watch that again21:26
zygato let it sink in :21:26
zyganiemeyer: btw, did I say how much I love spread?21:26
niemeyerzyga: :D21:27
zyganiemeyer: I talked about exactly having something like spread at the sprint to fgimenez and elopio and you made it :-)21:27
tsimonq2elopio: 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't21:28
mupPR 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
tsimonq2elopio: I can't figure out what the problem is21:28
tsimonq2elopio: otherwise, my PR is ready for a full review21:29
zygajdstrand: look at this test please: https://github.com/snapcore/snap-confine/pull/73/commits/9b09f3a2e574bb7782b5be5beaefa4e6cc74ddd621:31
mupPR 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
tsimonq2elopio: /o\ scratch that, still thinks I have no unit test coverage... ahh21:34
elopiotsimonq2: run it locally.21:35
elopiosergiusens: latest test of master and staging fails because the snap we are uploading needs a manual review.21:35
tsimonq2elopio: I did21:36
elopiotsimonq2: and it fails locally?21:36
tsimonq2elopio: the problem is, because the test doesn't fail, it isn't verbose21:36
tsimonq2elopio: it's supposed to fail but it doesn't21:36
tsimonq2elopio: (unit tests)21:36
elopiotsimonq2: have you used pdb?21:37
tsimonq2elopio: never heard of it21:37
=== Guest36675 is now known as devil_
elopiotsimonq2: add this line before https://github.com/snapcore/snapcraft/pull/619/files#diff-e6205a80af76b4faec1d9241dc3b3b7cR177 : import pdb; pdb.set_trace()21:38
mupPR 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
elopiothat's a debugger. Enter n to jump to the next line. You can print a variable with p var_name.21:38
tsimonq2wow that's awesome! :D21:39
zygaheh :)21:39
zygayou should try gdb some day21:39
elopiotsimonq2: read that ^.21:39
zygalike pdb but also down to the metal21:39
tsimonq2elopio: how do I run coveralls locally?21:40
elopiotsimonq2: install python3-coverage. Coveralls is just a way to display the report, not something you run locally.21:41
tsimonq2elopio: oh I see21:42
* tsimonq2 remembers now :D21:42
mwhudsonzyga: I hacked it to only run the failing test, it passes of course21:43
zygamwhudson: since it failed on some service still running I suspect it's bleeding the previous ttest that is causing the next one now21:44
mwhudsonzyga: certainly plausible21:44
tsimonq2elopio: so when I run the unit tests, am I supposed to get a debugger? because I'm not21:52
zygaI forked the test to cover both cases21:52
zygaI'll also have to patch the earlier tests that now fail because mount profiles got more constrained21:53
tsimonq2elopio: and the coverage statement tells me that all three of my if/elif statements never returned to true21:53
zygabut we're looking good :)21:53
elopiotsimonq2: then put the breakpoint earlier, you are not hitting that statement.21:54
tsimonq2alright elopio21:54
mwhudsonzyga: ah --shell-fail finally worked for me21:54
zygamwhudson: did you change anything?21:54
mwhudsonzyga: when i log in, systemctl status snap-basic\\x2dbinaries-100001.mount is bad21:55
zygamwhudson: for me it printed commands, none of which worked21:55
mwhudsonJul 08 09:49:37 autopkgtest mount[2148]: mount: special device /var/lib/snapd/snaps/basic-binaries_100001.snap does not exist21:55
zygamwhudson: explore, why is it bad21:55
zygais that snap gone?21:55
mwhudsonzyga: oh hm, no the ssh command worked for me21:55
mwhudsonzyga: no, its there21:55
mwhudsonzyga: and in fact i can run sudo systemctl start snap-basic\\x2dbinaries-100001.mount and it starts21:55
mwhudsonzyga: could be a race? /me guesses wildly21:56
zygahmmmm :<21:56
zygaI doubt it, we put the unit in place after we've looked at the squashfs file21:56
zygamwhudson: anything in snapd log?21:59
mwhudsonzyga: journalctl -u snapd?21:59
mwhudsonor something else?21:59
zygathat should be it21:59
zygaDay changed to 08 lip 201622:00
zygageee, thanks irssi22:00
zygaI wonder if any other irc client says that22:00
mwhudsonquassel does22:00
mwhudsonzyga: some stuff, yeah http://paste.ubuntu.com/18738038/22:01
zygaone thing is very wrong22:01
zygaJul 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
zygaJul 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
zygaJul 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
zygaah, no sorry22:02
zygaI though it's ignoring the error and carrying on but it is in fact undoing the thing22:02
zygamwhudson: can you reproduce this if you run this in a loop?22:02
zygaI mean the whole testbed22:03
zygaand if so, how fast can you run it?22:03
mwhudsonzyga: it seems pretty reproducible yeah22:04
mwhudsonand it takes, uh, 10mins to run?22:04
zygamwhudson: I was wondering if we can patch snapd to run deeper syslog dump when that fails22:04
mwhudsonzyga: can certainly try that22:04
zygamwhudson: or can you see that manually after logging in?22:04
mwhudsonzyga: i don't know, am happy to try things :)22:04
zygamwhudson: I have no idea why this might fail, I'm just trying to see beyond:22:05
zygaJul 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
mwhudsonzyga: oh hm, maybe http://paste.ubuntu.com/18738572/ ?22:08
mwhudsonzyga: btw did you see https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1599799 ?22:08
mupBug #1599799: snapd > 2.0.2 fails on yakkety <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1599799>22:08
mwhudsonthat latest paste does look a little more informative22:08
zygamwhudson: I saw it, I've added a comment to it22:09
zygamwhudson: Jul 08 09:51:08 autopkgtest systemd[1]: dev-loop2.device: Job dev-loop2.device/start timed out.22:09
zygaJul 08 09:51:08 autopkgtest systemd[1]: Timed out waiting for device /dev/loop2.22:09
zygathis looks wrong :/22:09
mwhudsonoh yes, so you ddid22:09
zygahttps://bbs.archlinux.org/viewtopic.php?id=196083 suggest this is when the source doesn't exist but I find that hard to believe22:11
mwhudsondoes seem unlikely22:12
* zyga iterates on mount tests22:22
zygaro test done, rw test almost done22:47
zygaI changed the testing approach but the test is still valid22:47
zygajdstrand: around?22:48
zygajdstrand: I realized that there's no reason for allowing rw mounts22:48
zygajdstrand: since we constrain to $SNAP anyway22:48
zygajdstrand: ... they are always read only now22:48
thomisergiusens: 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 uck22:53
thomisergiusens: at what point is the #! line supposed to get rewritten?22:53
zygajdstrand: I've updated https://github.com/snapcore/snap-confine/pull/7323:08
mupPR snap-confine#73: Update apparmor profile for snap-confine <Created by zyga> <https://github.com/snapcore/snap-confine/pull/73>23:08
zygajdstrand: if you feel that is sufficient now please merge it23:08
* zyga EODs23:20
chasinglogicHey does anyone know if there will be 16.04 images of snappy available? I noticed that there weren't any for 15.1023:24
zygachasinglogic: there will be, we're working on the fine details23:25
zygachasinglogic: when is more complicated but I'm already EOD and tired today23:26
chasinglogiczyga: if I grab the 15.04 image will I be able to upgrade23:26
zygachasinglogic: no23:26
chasinglogiczyga: cool thanks for the info!23:26

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!