[01:09] kyrofa: sergiusens: is there anything that sets $TMPDIR when a snap is run? [01:09] mhall119, yeah, each app gets its own [01:10] kyrofa: what might such a value look like? [01:10] I ask because in pantheon-mail sqlite is trying to create temp files in /var/tmp/ and failing [01:12] mhall119, /tmp/snap.foo_bar_baz [01:12] mhall119, but it shows up to the snap as /tmp [01:12] mhall119, now that you mention it, I'm not sure anything is explicitly setting the TMPDIR var [01:12] We just make /tmp work correctly [01:13] So if sqlite defaults to /var/tmp is TMPDIR isn't set, that may be it [01:14] it does [01:14] according to https://www.sqlite.org/tempfiles.html#tempstore [01:14] can I do something like: TMPDIR=/tmp /snap/bin/pantheon-mail [01:14] or will the envvars be stripped out when the snap is run? [01:20] mhall119, you can do that, but it'll need to be in a wrapper somewhere [01:20] mhall119, soon that'll get easier, you'll be able to specify environments in the yaml, but not just yet [01:20] do you think it's worth putting in common gtk/qt desktop launcher parts? [01:20] (sorry for the delay, packing up my office for a cross-country move) [01:21] mhall119, if this problem is encountered enough, sure [01:21] presumably it will be encountered anywhere sqlite3 is used [01:21] Indeed [01:22] I just wonder if it'll cause problems for others [01:22] e.g. /var/tmp is different than /tmp, it's not cleared each boot [01:23] So some users might want TMPDIR to be, say, in $SNAP_DATA/tp [01:23] $SNAP_DATA/tmp rather [01:23] how about setting SQLITE_TMPDIR? I don't think sqlite expects them to persist between boots [01:24] SQLITE_TMPDIR seems a little specific to go in a generic part, but that's just me [01:24] Such an approach won't scale [01:25] well, you said there was an easier method on the way :) [01:25] Indeed [01:25] In the next snapd release, actually [01:25] Just waiting for it to get through SRU [01:25] Though snapcraft needs to support it too... not sure if sergiusens has done that yet or not [01:28] But to get up and running, a simple wrapper script is pretty easy [01:29] yup, and I've just verified that it fixes all my apparmor warnings [01:30] Very good [01:30] it isn't copying my sqlite database forward for new install revisions of the snap though :( [01:30] mhall119, and the DB is in $SNAP_DATA? [01:31] it's /home/mhall/snap/pantheon-mail/x2/.local/share/pantheon-mail/ [01:31] Ah interesting! A hidden dir [01:32] does /home/mhall/snap/pantheon-mail/x2/ map to an envvar? [01:32] Out of curiosity, can you force it to _not_ be hidden? [01:32] because it looks like something might be trying for $HOME/.local/share/ [01:32] Indeed, that's $SNAP_USER_DATA, but snapd also sets $HOME to that [01:32] You got it [01:33] and $SNAP_USER_DATA isn't copied? Or it this not being copied because it's a dotfile? [01:33] 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:34] Can you verify? Even if you just renamed the dir and installed a new rev [01:34] I'll give it a try and see, but might wait until tomorrow [01:35] Yeah it's a bit late for you === 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 [06:44] hiya [06:47] hey dholbach [06:47] salut didrocks [06:47] does anyone know what to respond to http://askubuntu.com/questions/795139/ntp-synchronisation-in-ubuntu-core-10? === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:49] ara: o/ [07:53] zyga_, hey! [07:53] morning all [07:54] PR snapd#1501 opened: client: existing JSON fixtures uses tabs for indentation === ant_ is now known as Guest59427 [08:48] has anyone looked at the snapd autopkgtest failures in yakkety? [09:15] mwhudson: hey [09:15] mwhudson: I did but didn't find anything, in fact I cannot reproduce them [09:15] mwhudson: I used a yakkety vm, got the package from proposed and ran kvm based autopkgtest [09:16] zyga: where is this damn session [09:16] zyga_: hm, i tried the same and the failed just a few seconds ago in fact [09:16] let's see if the failures looked similar [09:16] mwhudson: how did you run the test? [09:16] adt-run --unbuilt-tree . --- qemu ~/adt-yakkety-amd64-cloud.img [09:16] from a git tree checked out to the release tag [09:16] I ran something different [09:17] give me a sec [09:17] ~/adt-yakkety-amd64-cloud.img is what adt-buildvm-ubuntu-cloud -r yakkety spat out [09:17] (or whatever that command is called :-) [09:17] I haven't used adt in a while, just booting yakkety to paste the command I ran [09:18] heh [09:19] hmm i think i see fewer failures than on autopkgtest.u.c [09:19] "yay" [09:19] let me find my irc session [09:19] fg === zyga_ is now known as zyga [09:19] woot [09:20] mwhudson: autopkgtest-buildvm-ubuntu-cloud -v -a amd64 -r yakket [09:20] y [09:21] oh well, that's not significantly different [09:21] autopkgtest snapd_2.0.10+16.10.dsc -- qemu [09:21] * zyga tries again [09:22] oh no, i did get the same errors [09:22] as https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/s/snapd/20160707_052336@/log.gz [09:22] i got less output spam though, whatever that means [09:24] sigh failures in teardown [09:24] always a good smell [09:25] messages like "Unit snap-basic\x2dbinaries-x1.mount not found." make my have unicode paranoia [09:25] bug 1571721 [09:26] Bug #1571721: Removing when an app is running results in a half removal [09:30] trying again [09:32] mwhudson: most interestingly, tests don't fail if you just run them [09:32] mwhudson: I mean from the tree [09:32] zyga: and they don't fail on xenial, right? [09:32] mwhudson: yep [09:32] mwhudson: one thing I didn't test, fully proposed update [09:33] mwhudson: I only ran this with yakkety + snapd from proposed [09:33] what's significantly different in yakkety? systemd, kernel i guess [09:33] ahhh hm [09:33] mwhudson: yep, just note that arch has the same version and it is all good there :/ [09:33] so ... hmm? [09:33] i think this is the key failure: [09:33] error: cannot perform the following tasks: [09:33] - 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] A dependency job for snap-basic\x2dservice-x1.mount failed. See 'journalctl -xe' for details. [09:33] hmm [09:34] i *think* all the rest is fallout from that [09:34] but i hardly know what is going on :) [09:34] what is the dependency job? [09:34] the fact that systemd says the unit changed on disk is not new in 230 [09:34] perhaps the dependency will tell us more [09:34] i should run it again in that mode that lets me ssh in afterwards [09:35] how do you do that? [09:35] --shell-fail [09:35] I'll replicate here and see what we get [09:35] thanks [09:43] running zyga@yakkety:~$ autopkgtest --shell-fail snapd_2.0.10+16.10.dsc --- qemu ~/autopkgtest-yakkety-amd64.img [09:44] zyga: i'm not completely sure what's happening now but i have this feeling my run is going to pass [09:45] do you know how regression tests are ran? is it with everything from proposed or just the one package? [09:45] and if it is the former, how can we replicate that? [09:45] i don't [09:45] and by editing the sources.list in the image, i assume [09:46] well, I can just upgrade to proposed and run tests locally [09:47] bah it failed but the --shell-fail magic did too somehow [09:47] my run is still in progress [09:48] zyga: mwhudson: it tries to limit -proposed packages to just the trigger and its dependencies [09:48] sometimes that doesn't work (stuff is uninstallable), then it falls back to enabling all of -proposed [09:48] zyga: i pasted your question in #ubuntu-quality btw [09:48] mwhudson: thanks! [09:49] hmm [09:49] well, we can try the full proposed one I guess [09:49] my tests are still ongoing [09:51] PR snapd#1459 closed: daemon,overlord/auth,store: update macaroon authentication to use the new endpoints [09:52] zyga: apparently a known intermittent thing, i'm running again [09:53] mwhudson: my run is still in progress, no failure yet [09:54] mwhudson: I really wonder if there's a difference between how we run tests [09:54] zyga: aaah the build failed this time! [09:55] FAIL: policy_test.go:103: policySuite.TestIterOpBadTargetdir [09:55] mwhudson: what's the rest of the error? [09:56] mwhudson: and can you reproduce that with the .dsc? [09:57] hmmmmm [09:57] mwhudson: I see it run ./get-deps [09:57] zyga: http://paste.ubuntu.com/18692046/ [09:57] mwhudson: I don't think that should ever be done in autopkgtests [09:58] isn't the whole idea to run tests from packaged bits [09:58] + ./get-deps.sh [09:58] Obtaining dependencies [09:58] reading... [09:58] hmmm [09:58] mwhudson: what is $HOME like? [09:59] don't know [09:59] so far it still hasn't failed for me [09:59] probably just /home/ubuntu === hikiko is now known as hikiko|ln [10:01] still not failed [10:01] (my computer is slower :-) [10:02] ah, it failed now! [10:02] same way [10:02] error: cannot perform the following tasks: [10:02] - 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] ) [10:02] hooray [10:02] i think [10:02] ok package build worked this time [10:03] hmm, the failshell instructions don't work for me [10:03] ok [10:03] let's try to fail this on native yakkety without adt so that tinkering is easier [10:06] eh, we should really replace the one dependency that needs bzr [10:06] pulling all of python2 [10:07] :) [10:09] 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] to use the packaged version of the dependencies [10:10] yep [10:10] grrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr [10:13] ? [10:17] the --shell-fail failed again [10:20] i guess i should figure out how adt-virt-qemu runs the vm and do it by hand [10:20] but maybe not today [10:31] PR snapd#1502 opened: Add an interface for tpm 1.2 [10:38] 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? === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [11:19] Do i need to set anything special in my snapcraft.yml, if my snap requires network access? [11:20] netphreak: yes [11:20] anywhere i can see an example of that? [11:21] $ snap interfaces # list of plugs [11:21] netphreak: https://github.com/snapcore/snapd/blob/master/docs/interfaces.md [11:21] In the app definition, "plug: [ network ]" [11:23] thx [11:31] 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:32] PR snapcraft#635 opened: Fix parts cache handling [11:34] PR snapd#1503 opened: Set the snap price when listing available snaps === hikiko|ln is now known as hikiko [12:22] PR snapd#1504 opened: debian: chmod created config files to 0644 [12:25] PR snapd#1505 opened: store: introduce a search grammar (baby step #1) [12:40] kyrofa hey, is this only failing due to ros and friends? https://github.com/snapcore/snapcraft/pull/633 [12:40] PR snapcraft#633: qmake plugin: Stop doing out-of-source builds [12:52] kyrofa: zyga: is there a solution to the "clicking a URL in a snap doesn't open it in the browser" bug? [12:57] PR snapd#1506 opened: store/auth: add helper for the macaroon refresh endpoint [12:58] mhall119 there's a bug and attente was working on that [12:58] 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 [13:00] sergiusens, bug #1597417 [13:00] Bug #1597417: Doesn't use "update-desktop-database" which is needed for mime handlers [13:00] sergiusens: how can we re-use the url-dispatcher that does this on the phone? [13:00] you can maybe confirm it [13:00] PR snapd#1507 opened: cmd: add buy command [13:02] 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] unsure if it works out of the box though [13:03] that's also something that needs to be backported to xenial [13:05] PR snapcraft#635 closed: Fix parts cache handling [13:09] seb128 thanks [13:13] seb128: and that works based on the MimeType field in the .desktop files? [13:13] Bug #1597417 opened: Doesn't use "update-desktop-database" which is needed for mime handlers [13:16] seb128: besides backporting snapd-xdg-open, the fake xdg-open script needs to be inserted into the os snap [13:16] mhall119, urls are special cases of mimetypes so I guess in some ways [13:16] attente, that was done in yakkety? [13:18] sergiusens, I just merged with master, so I'll let you know [13:18] seb128: i don't recall, i thought mvo took care of that part though [13:18] k [13:18] mvo, ^ do you know what's the status there? ;-) [13:18] attente, thanks [13:25] attente: its in the os snap already (maybe not yet in stable? definitely in edge) [13:26] seb128: -^ [13:26] mvo: ok, thanks. so i guess the only thing missing is backporting to x [13:26] mvo, do we have an os snap installed on classic? [13:26] yo, just updated y'day and i'm seeing an error on snap list [13:26] known? [13:26] seb128: yeah, we do [13:26] error is "error: cannot list snaps: cannot unmarshal: json: cannot unmarshal string into Go value of type int" [13:27] seb128: yes [13:27] attente: people get it from the os snap, we don't need to backport it (unless I miss something) [13:27] mvo: I don't find it r122: /snap/ubuntu-core/current$ sudo find . -name 'xdg-open' [13:27] mvo: backporting snapd-xdg-open to xenial for the other half of that interaction [13:27] 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] didrocks, mvo, how do I see what it's in my os snap? snap list only includes ubuntu-core [13:27] seb128: this is the os snap [13:27] seb128: 122 is stable, right? [13:28] mvo: and also pulling it as a depends [13:28] mvo, 122 of what? [13:28] 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:29] 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] sergiusens, nope, example tests are still busted [13:29] mvo, ubuntu-core is the os snap? [13:29] seb128: yes, correct [13:29] or are they different things [13:29] ah ok [13:29] seb128: sorry for the confusion [13:29] no worry [13:34] PR snapd#1508 opened: cmd/snap,cmd/snap-exec: support running hooks via snap-exec [13:37] Chipaca: hey, for some reason, snapd still doesn't be returning an icon uri despite the snaps dpm uploaded being series 16 [13:39] Chipaca, https://launchpad.net/bugs/1588266 [13:39] Bug #1588266: Almost no info about Krita snap in Ubuntu Software

[13:43] PR snapd#1504 closed: debian: chmod created config files to 0644 [13:49] kyrofa which ones? [13:51] PR snapd#1509 opened: interface: add new interfaces.all.SecurityBackends [13:51] sergiusens, http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/1216/console, image creation failure seems like [13:52] fgimenez, any idea on that one? ^^ [13:52] kyrofa, looking [13:54] sergiusens, I think my last successful run was a few days ago at this point :P [13:59] hi there, I get an error message when I try running any snap: [13:59] $ snap run vlc [13:59] execv failed: No such file or directory [13:59] 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] Thanks fgimenez [14:00] $ snap run hello [14:00] 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] execv failed: No such file or directory [14:00] slightly better error with hello I guess.. [14:00] gQuigs, that's not typically how one runs apps [14:00] gQuigs, run stuff out of /snap/bin [14:00] (which should be in your PATH) [14:02] kyrofa: hmm.. then it's not obvious how to run some... [14:02] kyrofa: for example, run hello and it says not installed [14:02] and what if I have both vlc snap and vlc deb installed? how to pick? [14:03] gQuigs, is hello installed? [14:04] $ /snap/bin/hello [14:04] Hello, world! [14:04] $ hello [14:04] The program 'hello' can be found in the following packages: [14:04] gQuigs, is /snap/bin in your PATH? [14:05] kyrofa, should be fixed now [14:05] Thanks fgimenez, re-running now [14:05] kyrofa: nope, it's not.. swear it was.. hmm [14:06] gQuigs, hmm indeed [14:08] with path set, hello works [14:09] but snap run still doesn't.. should that work? [14:09] How can i see what version of snapcraft and snap i installed? [14:09] jdstrand: Heya [14:09] jdstrand: Do you need any state currently in Spread-B? [14:09] netphreak: does --version not work for you? [14:10] 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:11] 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] Bug #1597417: Doesn't use "update-desktop-database" which is needed for mime handlers [14:12] it's important to make desktop applications useful [14:12] 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] kyrofa: so for VLC the deb takes precedent (based on how I did path). Should snap run work is that deprecated? [14:13] 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:14] gQuigs, it's an implementation detail [14:14] 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:15] gQuigs, so for a consistent experience, use /snap/bin/ [14:15] How do i upgrade to the latest snapd 2.0.10? I'm on apt-get [14:15] seb128 I have the same problem when clicking on telegram.me links ;-) [14:16] seb128: what needs to happen? does snapd needs to just run update-desktop-database after new desktop files got created? [14:16] kyrofa: so I should eventually work ? [14:17] gQuigs, yes, but again, you should never need to use it directly [14:17] niemeyer: no-- I can -discard now if that makes things easier for you [14:17] jdstrand: Ah, yes please, thanks! [14:17] mvo, yes [14:17] niemeyer: but when can I start up a new one with -keep? [14:17] jdstrand: Feel free to pick another one when you need [14:18] jdstrand: Immediately [14:18] kyrofa: thanks! [14:18] jdstrand: Hopefully I'll be faster and nuke the machine before you grab it again :) [14:18] jdstrand: There are other machines available on the new DC already [14:18] niemeyer: discarded [14:18] mvo, the mimetype handlers look into indexes and that dir doesn't have one so its entries are not registered [14:18] mvo, just doing the update command makes it work [14:19] jdstrand: Thanks, removed.. will re-allocate new ones with the same names on the new DC [14:19] 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] jdstrand: Wooo, that's great to hear! Thanks! [14:19] really nice. I was writing spread tests in just a few minutes [14:20] granted, I was using an existing project with spread.yaml, but still. good stuff :) [14:21] 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] Bug #1580740: [SRU] Cannot open a browser link from a snap that provides a link [14:21] niemeyer: oh and -debug is fantastic [14:21] attente, that SRU bug should do the trick [14:22] 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] totally [14:23] seb128: thanks! [14:24] attente, yw! [14:25] 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] seb128: could you please sponsor it for xenial? or should i subscribe ubuntu-sponsors? [14:26] niemeyer: fyi, I have Spread-E now [14:26] 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] jdstrand: Ack [14:27] jdstrand: That is, $ spread linode: [14:27] jdstrand: Then it'll run only things in Linode [14:27] 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] eg, if I just call 'spread' [14:28] 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] I see. ok, thanks [14:28] jdstrand: That's the main distinction between aborted and failed, btw.. aborted means "didn't even try" [14:29] ah, yes. that makes sense [14:29] 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:30] I'm not actively working on that-- just was curious [14:38]