| seyeongkim | hello, is there a way to install older revision of core? | 03:53 |
|---|---|---|
| mup | PR snapcraft#1861 opened: extractors: also support appdata.xml appstream files <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1861> | 05:40 |
| mborzecki | morning | 05:58 |
| zyga-ubuntu | o/ | 06:47 |
| * zyga-ubuntu is tad sleepy | 06:47 | |
| zyga-ubuntu | hacking till 2AM | 06:47 |
| zyga-ubuntu | I'll go back to bed | 06:48 |
| mborzecki | zyga-ubuntu: hey | 06:50 |
| mborzecki | mvo: morning | 07:21 |
| mup | PR snapd#4458 closed: overlord/snapstate: no refresh just for hints if there was a recent regular full refresh <Reviewed> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4458> | 07:21 |
| mvo | hey mborzecki - good monring | 07:23 |
| mup | PR snapd#4456 closed: snap: rename `snap advise-command` to `snap advise-snap --command` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4456> | 07:23 |
| mup | PR snapd#4463 opened: client, daemon: update user's email when logging in with new account <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4463> | 07:53 |
| kalikiana | good morning | 07:53 |
| mborzecki | kalikiana: morning | 07:54 |
| mup | PR snapd#4394 closed: snap: give the snap.Container interface a Walk method <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4394> | 08:14 |
| zyga-ubuntu | hey | 08:32 |
| zyga-ubuntu | back now, I think I owe everyone some reviews | 08:32 |
| zyga-ubuntu | I took 4452 and went wild on unit tests | 08:35 |
| zyga-ubuntu | found an obscure bug with symlinks (and fixed it) | 08:35 |
| zyga-ubuntu | but grew the branch to a big extreme sizes | 08:36 |
| zyga-ubuntu | I will probably double back and propse all the unit test changes separately, though not sure if that will help | 08:36 |
| zyga-ubuntu | I'll get a coffee and start chopping | 08:38 |
| zyga-ubuntu | all right | 08:46 |
| === __chip__ is now known as Chipaca | ||
| mup | PR snapd#4464 opened: overlord/snapstate: add validateContainer, that uses snap.Container's <Created by chipaca> <https://github.com/snapcore/snapd/pull/4464> | 09:05 |
| Chipaca | mvo: thank you for merging #4394! As a recompense, here's 4464 ^-^ | 09:05 |
| mup | PR #4394: snap: give the snap.Container interface a Walk method <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4394> | 09:05 |
| Chipaca | oh dear, commit message murder | 09:06 |
| * Chipaca tidies | 09:06 | |
| * kalikiana coffee | 09:07 | |
| mvo | Chipaca: thanks for the code update. it was very nice | 09:07 |
| pedronis | Chipaca: hi, did you see my comment last night? we install jq with --devmode in other tests, do you have a preference for not doing that everywhere? | 09:09 |
| Chipaca | pedronis: it seems tidier to me to not use devmode for that -- we disrecommend devmode for good reasons, but if at the first problem _we_ switch to devmode, … :-) | 09:10 |
| pedronis | Chipaca: well, not these days people publish as classic instead | 09:11 |
| Chipaca | pedronis: same argument there though | 09:12 |
| Chipaca | pedronis: but just to be clear, it's merely a sense of tidiness, nothing more | 09:12 |
| pedronis | I found our tests not very tidy in general, but maybe it's just me | 09:13 |
| Chipaca | pedronis: that's fair | 09:14 |
| pedronis | I mean, I feel when writing spread tests that my tidniness setting is medium | 09:15 |
| zyga-ubuntu | pedronis: hehe, how does that materialize? | 09:16 |
| Chipaca | zyga-ubuntu: I'm assuming if it were higher than that there'd be infinite PRs from samuele trying to beat our spread suite into submission | 09:18 |
| pedronis | Chipaca: either way, switching away from --devmode for jq would be a PR, as I said it's done in a couple of places, starting with prepare.sh | 09:21 |
| Chipaca | pedronis: no worries | 09:21 |
| pedronis | Chipaca: if we do that it become tempting to introduce some kind of jq_modify_state helper (but maybe we already have too many obscure helpers we don't remember about) | 09:28 |
| mvo | Chipaca: you have a review | 09:33 |
| mvo | Chipaca: nice job btw | 09:33 |
| mvo | a second review for 4454 would be nice, should be trivial | 09:34 |
| mup | PR snapd#4454 closed: snap: fix gadget.yaml parsing for multi volume gadgets <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4454> | 09:38 |
| mvo | pedronis: I think https://github.com/snapcore/snapd/pull/4356 is ready for a re-review | 09:39 |
| mup | PR #4356: many: add new `snap refresh --amend <snap>` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/4356> | 09:39 |
| pedronis | I'll look at it today | 09:40 |
| mvo | ta | 09:41 |
| * Chipaca -> bbiab (physio) | 09:43 | |
| kalikiana | woot, --ammend wouldn't have been my choice of name, but nice to see this | 09:44 |
| mvo | kalikiana: not too late for suggestions :) | 09:44 |
| mvo | kalikiana: in the PR please, they will need sign off from gustavo | 09:44 |
| kalikiana | Aye, will comment there | 09:49 |
| mvo | popey: hey, we 1742247> what version of snapd did you use to make this workaround work? | 09:57 |
| mvo | popey: fwiw, the message got improved to be ambiguous, it now says "snap foo is no longer tracking %s" | 09:57 |
| mvo | (in master) | 09:57 |
| popey | mvo: I'm on core from candidate | 10:01 |
| mvo | popey: ta, let me try to reproduce with that | 10:01 |
| mvo | mborzecki: https://travis-ci.org/snapcore/snapd/builds/327128264#L1541 is probably something you want to look at | 10:03 |
| mvo | mborzecki: (context is 4463) | 10:03 |
| mborzecki | mvo: thanks, looking now | 10:03 |
| mvo | also 4461 is tiny and needs a second review | 10:04 |
| zyga-ubuntu | hmm, github is not responding here | 10:06 |
| kalikiana | popey: ping wrt bug 1741752 | 10:07 |
| mup | Bug #1741752: yaml.constructor.ConstructorError: could not determine a constructor for the tag '!ExtractedMetadata' <Snapcraft:New> <https://launchpad.net/bugs/1741752> | 10:07 |
| popey | kalikiana: hello | 10:07 |
| kalikiana | popey: Hey. How are you this morning? | 10:07 |
| popey | Super, how are you? :) | 10:08 |
| kalikiana | Very well. There's a little bit of sun today so that"s rare and awesome :-D | 10:08 |
| zyga-ubuntu | https://status.github.com/messages | 10:09 |
| zyga-ubuntu | it's down | 10:09 |
| kalikiana | popey: I'd just like to clarify what you wrote in the bug if possible. In the description you said `usually if I re-run or clean, it goes away` but later replied `definitely didn't do lxc delete, and don't believe I did snapcraft clean` | 10:10 |
| popey | that's right | 10:10 |
| popey | what I do is run snapcraft, the thing needs rebuilding so I re-run snapcraft. Then the error appears | 10:11 |
| kalikiana | popey: Maybe the expected behavior isn't very clear. When you do `snapcraft clean`with persistent containers enabled, that equates to deleting the container if you don't pass more arguments. | 10:11 |
| popey | Yes. That's what I expect. But as I said, I didn't clean. But I _have_ to clean to get past this error | 10:12 |
| kalikiana | eg. `snapcraft clean mypart` would *not* delete it | 10:12 |
| kalikiana | popey: You mean if you do `snapcraft clean` the error goes away? | 10:13 |
| popey | Yes | 10:13 |
| kalikiana | popey: Okay, now that makes sense. I was a bit lost in your wording, sorry :-D | 10:13 |
| popey | Ah sorry. Will try harder with my words next time :) | 10:14 |
| kalikiana | popey: So, as I said in the comment, re-using an existing container wouldn't pull in a new snapcraft if the revision changed or it's a local build. Can you tell me what might have expected? Maybe we should print a message like `Btw your snapcraft is on a different channel, you may wanna refresh the container` | 10:16 |
| popey | Wait, what? | 10:16 |
| popey | I don't want to pull in a new snapcraft revision | 10:16 |
| popey | I just wanted the software to rebuild, that's all | 10:17 |
| popey | and I got smacked in the face with python backtrace and an error at the bottom. I am not trying to update anything, *just* rebuild like a normal developer would as they iterate over a build | 10:17 |
| kalikiana | popey: Example, you have snapcraft from beta, build stuff in a container, do `snap refresh snapcraft --channel=edge`, and now your new snapcraft has different expectations | 10:18 |
| kalikiana | I think that's what happened, simplified | 10:18 |
| popey | I didnt do that | 10:18 |
| popey | i just ran snapcraft and then ran snapcraft again | 10:18 |
| popey | you're saying snapd refreshed in the minute or two between running snapcraft and running it again? | 10:19 |
| mup | PR snapd#4457 closed: spread: trying to re-enable tests on Fedora <Reviewed> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4457> | 10:20 |
| kalikiana | popey: So you were using edge the whole time? | 10:21 |
| kalikiana | Please bear with me, I'm just trying to get the exact situation | 10:21 |
| popey | yes | 10:22 |
| kalikiana | popey: So then it must've been snapd refreshing out of sync on your host vs. container | 10:22 |
| kalikiana | Which is possible since we don't force that | 10:22 |
| popey | kalikiana: tell you what, lets park that bug, and I will try and re-produce it. | 10:24 |
| popey | And get a better "steps to reproduce" okay? | 10:24 |
| popey | because it's all a bit muddy now :) | 10:24 |
| popey | (unless you fully understand it now and know what to fix) :D | 10:26 |
| mup | PR snapd#4461 closed: snap: fix missing error check when multiple snaps are refreshed <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4461> | 10:27 |
| zyga-ubuntu | mvo: 1st of the easy branches: https://github.com/snapcore/snapd/pull/4465/files | 10:27 |
| mup | PR #4465: cmd/snap-update-ns: new test features <Created by zyga> <https://github.com/snapcore/snapd/pull/4465> | 10:27 |
| mup | PR snapd#4465 opened: cmd/snap-update-ns: new test features <Created by zyga> <https://github.com/snapcore/snapd/pull/4465> | 10:28 |
| sparkiegeek | mvo: anything I can do to help #1735344 along? | 10:30 |
| mup | Bug #1735344: [SRU] 2.30 <snapd (Ubuntu):Confirmed> <snapd (Ubuntu Trusty):Confirmed> <snapd (Ubuntu Xenial):Confirmed> <snapd (Ubuntu Zesty):Confirmed> <snapd (Ubuntu Artful):Confirmed> <https://launchpad.net/bugs/1735344> | 10:30 |
| mvo | niemeyer: hey, for late, do the strings in 4441 look good to you ? this pr is mostly a tiny string change | 10:30 |
| mvo | sparkiegeek: a good question, it is still in unapproved. I assume apw is just super busy with spectre/meltdown and all this madness | 10:31 |
| * sparkiegeek nods | 10:32 | |
| apw | i am cirtaonly that, plus it won't build even if i accept it | 10:32 |
| mvo | apw: aha, indeed, that is the other issue :) | 10:32 |
| * mvo hugs apw for tireless work to protect us again | 10:32 | |
| sparkiegeek | mvo: just to confirm, to get 2.30 in the meantime, I should use ppa:snappy-dev/edge ? | 10:33 |
| * sparkiegeek joins mvo in hugging apw | 10:33 | |
| sparkiegeek | on systems that don't have core installed and need ... configuration | 10:34 |
| kalikiana | popey: Yeah, I think I know what's going on now. Incompatible `snap/.snapcraft/state`. I'll figure something out with elopio | 10:34 |
| mvo | sparkiegeek: the stable core got updated so you should have it via re-exec. if you prefer the deb you can add "apt-add-repository ppa:snappy-dev/image" | 10:34 |
| mvo | sparkiegeek: its there for xenial,zesty,artful | 10:34 |
| kalikiana | popey: Thanks for clarifying the missing pieces of the puzzle! | 10:34 |
| mvo | sparkiegeek: and I think trusty but I doubt you care about that | 10:34 |
| mup | PR snapd#4436 closed: snap: do not leak internal errors on install/refresh etc <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4436> | 10:36 |
| popey | kalikiana: awesome | 10:36 |
| mvo | niemeyer: if you have a bit of time (hard I know) double checking the strings in 4382 and 4441 would be great. just to make sure everything is consistent | 10:36 |
| zyga-ubuntu | mvo: 2nd and tiny trivial PR: https://github.com/snapcore/snapd/pull/4466 | 10:38 |
| mup | PR #4466: interfaces/mount: test OptsToCommonFlags, filter out x-snapd. options <Created by zyga> <https://github.com/snapcore/snapd/pull/4466> | 10:38 |
| mup | PR snapd#4466 opened: interfaces/mount: test OptsToCommonFlags, filter out x-snapd. options <Created by zyga> <https://github.com/snapcore/snapd/pull/4466> | 10:39 |
| zyga-ubuntu | mvo: 3rd trival PR: https://github.com/snapcore/snapd/pull/4467 | 10:39 |
| mup | PR #4467: cmd/snap-update-ns: untangle upcoming cyclic initialization <Created by zyga> <https://github.com/snapcore/snapd/pull/4467> | 10:39 |
| mup | PR snapd#4334 closed: tests: ensure snap-confine apparmor profile is parsable <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4334> | 10:40 |
| mup | PR snapd#4467 opened: cmd/snap-update-ns: untangle upcoming cyclic initialization <Created by zyga> <https://github.com/snapcore/snapd/pull/4467> | 10:40 |
| zyga-ubuntu | mvo: 4th: ^ | 10:40 |
| mup | PR snapd#4468 opened: cmd/snap-update-ns: we don't want to bind mount symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4468> | 10:41 |
| mvo | zyga-ubuntu: ta | 10:41 |
| zyga-ubuntu | now the main dish, this will take a little longer to prepare | 10:41 |
| mup | PR snapd#4452 closed: cmd/snap-update-ns: enable writable mimic, allow content sharing to $SNAP <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4452> | 11:05 |
| zyga-ubuntu | mvo: I have the rest but I need this batch to land, I'll switch to review to help others now | 11:05 |
| zyga-ubuntu | mvo: if you can review 4465, 4466, 4467 and 4468 it will help me a lot, they are all small | 11:06 |
| mvo | zyga-ubuntu: ok | 11:12 |
| niemeyer | mvo: Thanks, will look at that next | 11:12 |
| zyga-ubuntu | hey niemeyer, good morning :) | 11:13 |
| mvo | niemeyer: thanks! really just a quick ack/nack on the strings | 11:13 |
| mvo | niemeyer: and good morning :) | 11:13 |
| niemeyer | Moin! | 11:13 |
| pstolowski | morning! | 11:23 |
| * Son_Goku rises from the dead | 11:24 | |
| zyga-ubuntu | Son_Goku: hey | 11:27 |
| * zyga-ubuntu hands Son_Goku a coffee | 11:27 | |
| zyga-ubuntu | mborzecki: you have a review on 4449 | 11:27 |
| * Son_Goku stares at the coffee | 11:27 | |
| mborzecki | zyga-ubuntu: thanks | 11:30 |
| niemeyer | mvo: What's the background for #4441? | 11:31 |
| mup | PR #4441: snap: add usage hints in `snap download` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4441> | 11:31 |
| mvo | niemeyer: a bugreport | 11:33 |
| mvo | niemeyer: it should be referenced in the PR - its fine if this is a won't-fix of course | 11:34 |
| niemeyer | mvo: I'm asking because it felt curious to just throw the --help in this case, when this is the normal workflow for download and the vast majority of cases people using download won't be interested in these pages | 11:35 |
| niemeyer | mvo: What was the report? People lacking ack? | 11:35 |
| mvo | niemeyer: yeah, people did not know apparently that "snap ack" exists/can be used to import the assertion | 11:35 |
| niemeyer | mvo: Okay, maybe we can be more direct then and give the command names | 11:36 |
| niemeyer | command lines | 11:36 |
| niemeyer | mvo: I'll suggest something for your consideration there | 11:36 |
| mvo | niemeyer: +1 | 11:37 |
| mvo | niemeyer: thank you! | 11:37 |
| mvo | zyga-ubuntu: re 4449> what I am missing here is why the tests test for *both* messages - the "use debug build" and in the same test also with debug enabled it tests for the real message. or am I reading it incorrectly? | 11:38 |
| zyga-ubuntu | mvo: not sure, I think it's not relevant to the issue that mborzecki wanted to fix (building with debug actually getting a debug binary) | 11:39 |
| zyga-ubuntu | mvo: in the debug binary those will be visible | 11:39 |
| zyga-ubuntu | mvo: I think the 2nd part is not strictly needed | 11:39 |
| mvo | zyga-ubuntu: right, but still, why are the tests expecting two lines now, one with "hidden" and then "the real thing"? | 11:40 |
| zyga-ubuntu | mvo: I don't know :) | 11:40 |
| mborzecki | zyga-ubuntu: mvo: there are 2 parts, one is getting a debug binary, the other is incorrect error message from a failed [u]mount when SNAP_CONFINE_DEBUG is enabled | 11:40 |
| niemeyer | mvo: np, please have a look to see what you think | 11:41 |
| mborzecki | basically when you have a non-debug build and run with SNAP_CONFINE_DEBUG you'll see `cannot perform operation: (disabled) use debug build to see details` | 11:41 |
| zyga-ubuntu | mborzecki: that's the desired behavior | 11:42 |
| mborzecki | zyga-ubuntu: ok, but then but if you turn SNAP_CONFINE_DEBUG off you'll see `cannot perform operation: mount -t blah blah` | 11:42 |
| mvo | mborzecki: lol, really? | 11:42 |
| mborzecki | yes, that's what the PR is fixing | 11:42 |
| zyga-ubuntu | mborzecki: hmmm :) | 11:43 |
| mvo | mborzecki: ok, then I just don't understand the test in https://github.com/snapcore/snapd/pull/4449/files#diff-70758630224dcb7ba3963d1fa05bb69aR234 - it seems to check for both message on stderr, no? | 11:43 |
| mup | PR #4449: cmd/libsnap-confine-private, cmd/snap-confine: fix logging of failed [u]mount when run with SNAP_CONFINE_DEBUG=1 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4449> | 11:43 |
| zyga-ubuntu | mborzecki: that's probably confusing, are you sure we render the messages in non-debug builds? | 11:43 |
| zyga-ubuntu | mborzecki: I've seen the disabled message countless times | 11:43 |
| zyga-ubuntu | mborzecki: some messages are hardcoded and not formatted on the fly | 11:43 |
| mborzecki | zyga-ubuntu: take a look here: https://forum.snapcraft.io/t/on-arch-snaps-show-broken-after-switch-from-snapd-to-snapd-git/3427, specifically the first message and then the debug log | 11:44 |
| mborzecki | popey got: | 11:44 |
| mborzecki | [alan@manjarovm ~]$ snap run brave | 11:44 |
| mborzecki | cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_gwR9tX//dev: No such file or directory | 11:44 |
| mborzecki | and then when running with SNAP_CONFINE_DEBUG: | 11:44 |
| zyga-ubuntu | mborzecki: that particular one may be hardcoded | 11:44 |
| zyga-ubuntu | mborzecki: they look the same but come from different places | 11:45 |
| mborzecki | cannot perform operation: (disabled) use debug build to see details: No such file or directory | 11:45 |
| zyga-ubuntu | mborzecki: DEBUG: performing operation: (disabled) use debug build to see details | 11:45 |
| zyga-ubuntu | mborzecki: that's the disabled one | 11:45 |
| zyga-ubuntu | mborzecki: I still don't see what's wrong there | 11:45 |
| mborzecki | zyga-ubuntu: no SNAP_CONFINE_DEBUG, `cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_gwR9tX//dev: No such file or directory` | 11:46 |
| mborzecki | zyga-ubuntu: with SNAP_CONFINE_DEBUG `cannot perform operation: (disabled) use debug build to see details: No such file or directory` | 11:46 |
| mborzecki | same binary | 11:46 |
| zyga-ubuntu | mborzecki: devil is in the details :) but I see how this is confusing (for me too) | 11:46 |
| zyga-ubuntu | mborzecki: it depends on who prints what | 11:46 |
| zyga-ubuntu | mborzecki: anyway, I'll look again, thank you for explaining that | 11:46 |
| mborzecki | zyga-ubuntu: we're hitting this path: https://github.com/snapcore/snapd/blob/master/cmd/libsnap-confine-private/mount-opt.c#L266 then this check https://github.com/snapcore/snapd/blob/master/cmd/libsnap-confine-private/mount-opt.c#L280 neve succeeds so you end up printing the `(disabled) ..` message whem mount/umount fails | 11:48 |
| zyga-ubuntu | ohh | 11:49 |
| zyga-ubuntu | that's wrong | 11:49 |
| zyga-ubuntu | it should not be there | 11:49 |
| zyga-ubuntu | that whole thing should go away | 11:49 |
| zyga-ubuntu | ah | 11:49 |
| zyga-ubuntu | no | 11:49 |
| zyga-ubuntu | sorry | 11:49 |
| zyga-ubuntu | :D | 11:49 |
| zyga-ubuntu | I just read the comment above it | 11:50 |
| zyga-ubuntu | sorry, my mind is rusty about this | 11:50 |
| === ogra_ is now known as ogra | ||
| mborzecki | Chipaca: i'm playing with gometalinter and vet tool just raised this: 'advisor/backend.go:178::error: literal copies lock value from *db: github.com/boltdb/bolt.DB contains sync.Pool contains sync.noCopy (vet)' | 11:52 |
| mup | PR snapcraft#1831 closed: cli: add expiration option to export-login <enhancement> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1831> | 12:00 |
| mup | PR snapcraft#1849 closed: tests: add snap not found tests <codein> <Created by daniellimws> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1849> | 12:00 |
| * Chipakeitor looks takes careful aim at Chipaca | 12:00 | |
| zyga-ubuntu | mborzecki: nice find! | 12:00 |
| === Chipakeitor is now known as Chipaca | ||
| Chipaca | mborzecki: i'm not sure i understand | 12:01 |
| niemeyer | mvo: On the second one, a typo and a suggestion | 12:04 |
| mvo | niemeyer: \o/ thank you | 12:04 |
| mborzecki | Chipaca: looking into it now, might be false positive | 12:04 |
| * zyga-ubuntu goes to cook something, ttyl | 12:05 | |
| niemeyer | mvo: Thank you! | 12:05 |
| Chipaca | mborzecki: I don't mind making boltFinder embed a *bolt.DB instead of a bolt.DB if it makes the liter happy | 12:05 |
| Chipaca | linter* | 12:05 |
| mborzecki | Chipaca: i guess the tool cannot detect if the pool was used and raises a warning | 12:06 |
| Chipaca | mborzecki: and it's fair; there's no guarantee the DB didn't start a maintenance goroutine | 12:07 |
| mborzecki | then i think it's fair to embed *botl.DB rather than a copy | 12:07 |
| * Chipaca nods | 12:08 | |
| Chipaca | thanks, metalinter! <plastic grin> <cut to commercial> | 12:08 |
| * Chipaca -> dentit | 12:25 | |
| mup | PR snapd#4469 opened: tests: add hard-coded fully expired macaroons to run related tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4469> | 12:42 |
| Chipaca | i might be a few minutes late to the standup | 12:58 |
| * Chipaca returning from dentistist | 12:58 | |
| mborzecki | gometalinter running from run-checks --static https://paste.ubuntu.com/26359996/ | 12:59 |
| mup | PR snapd#4470 opened: overlord/snapstate: fix gofmt -s -l <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4470> | 13:07 |
| mup | PR snapcraft#1860 closed: setup: simplify bin/snapcraft and correct tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1860> | 13:36 |
| mvo | kyrofa, sergiusens what happend to https://github.com/snapcore/snapcraft/pull/1420/files ? I tried to build a snap using that with snapcraft 2.34 and I got an error that "adapter" is unknown. is my snapcraft too old? | 13:40 |
| mup | PR snapcraft#1420: add new "no-wrapper" property to apps <enhancement> <Created by mvo5> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1420> | 13:40 |
| zyga-ubuntu | Chipakeitor: can you look at 4465-4468 quickly, I'd like to land them to propse the intersting changes that will take longer to review | 13:47 |
| === Chipakeitor is now known as Chipaca | ||
| * Chipaca looks | 13:47 | |
| mup | PR snapd#4463 closed: client, daemon: update user's email when logging in with new account <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4463> | 13:53 |
| Chipaca | zyga-ubuntu: neat-o | 13:55 |
| * kalikiana going to have lunch, back in a bit | 14:00 | |
| * pstolowski lunch | 14:01 | |
| mup | PR snapd#4467 closed: cmd/snap-update-ns: untangle upcoming cyclic initialization <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4467> | 14:01 |
| mup | PR snapd#4466 closed: interfaces/mount: test OptsToCommonFlags, filter out x-snapd. options <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4466> | 14:02 |
| mup | PR snapd#4468 closed: cmd/snap-update-ns: we don't want to bind mount symlinks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4468> | 14:02 |
| jamesh | zyga-ubuntu: hi. Yesterday you mentioned having a chat about user-mounts some time tomorrow with niemeyer. Should we set a time? | 14:14 |
| zyga-ubuntu | jamesh: hey, yes the plan is to do it tomorrow, you mentioned someting about your morning being preferred | 14:15 |
| zyga-ubuntu | let's look at the calendar now | 14:15 |
| jamesh | zyga-ubuntu: I thought my evening might be easier | 14:15 |
| zyga-ubuntu | ah I must have rembembered wrong then, sorry | 14:16 |
| jamesh | I think the biggest time difference is between WA and Brazil | 14:16 |
| mborzecki | off to pick up the kids | 14:18 |
| zyga-ubuntu | I wish google calendar could show the local time for each participant | 14:18 |
| zyga-ubuntu | jamesh: when it's 10AM here (CET+1) what is it for you? | 14:19 |
| Chipaca | zyga-ubuntu: i thought you were on CET | 14:19 |
| zyga-ubuntu | Chipaca: I never remember if its' CET or +1 | 14:20 |
| zyga-ubuntu | Chipaca: DST and that | 14:20 |
| Chipaca | zyga-ubuntu: your DST is in march | 14:20 |
| Chipaca | starts in march, i mean | 14:21 |
| jamesh | zyga-ubuntu: WA is UTC+8, so 10AM in UTC+1 would be 5 PM | 14:21 |
| zyga-ubuntu | jamesh: that's reasonable for you I think | 14:21 |
| zyga-ubuntu | Chipaca: ah, I remembered UTC+1=CET, now it makes sense | 14:22 |
| zyga-ubuntu | jamesh: ok I think 10AM it is | 14:22 |
| jamesh | zyga-ubuntu: sounds great. | 14:23 |
| zyga-ubuntu | hmm, the new calendar has arrived | 14:23 |
| zyga-ubuntu | no idea how to add a hangout link | 14:24 |
| jamesh | zyga-ubuntu: maybe move it forward a day? | 14:24 |
| Chipaca | HAH! a bunch of spread tests failed because the snaps don't pass validation | 14:25 |
| * sergiusens ran out to run some errands | 14:25 | |
| zyga-ubuntu | doh :D | 14:25 |
| jamesh | zyga-ubuntu: you've got it scheduled for 5 hours ago | 14:25 |
| zyga-ubuntu | sorry, the UI is totally confusing at first sight, I saw vertical stripes which I assumed were days, it's updated now | 14:26 |
| zyga-ubuntu | (it were people, not days) | 14:26 |
| sergiusens | mvo is your PR tagged with a greater number? | 14:26 |
| mvo | sergiusens: it says "milestone: 2.35" | 14:27 |
| zyga-ubuntu | jamesh: realistically I think we'll see a lot of mount features ladning next week | 14:28 |
| zyga-ubuntu | jamesh: I'm close to enabling layouts, the new content interface will likely land this week | 14:28 |
| mvo | sergiusens: hrm, but apparently I only have 2.34 - sorry, let me figure out where I can get 2.35 | 14:28 |
| zyga-ubuntu | jamesh: your work is also looking very good | 14:28 |
| zyga-ubuntu | jamesh: we can look at enabling themes soon, though I don't really know if my I know what your plans for that are | 14:29 |
| jamesh | zyga-ubuntu: If there is time, I'd also like to discuss how we could support the dbus app container socket feature | 14:30 |
| zyga-ubuntu | I'm not familiar with that, can you share a link so that I can prepare | 14:30 |
| jamesh | zyga-ubuntu: https://forum.snapcraft.io/t/interacting-with-dbus-daemons-app-container-feature/3245 has a summary I prepared, plus links to the upstream bugs | 14:31 |
| zyga-ubuntu | thank you, I'll read that today | 14:31 |
| jamesh | zyga-ubuntu: I've been talking with upstream to try and make sure the feature takes a form we can use, but properly supporting it will require some changes to the way we construct the mount namespaces | 14:33 |
| jamesh | since we'd want to inject a new unix socket | 14:34 |
| zyga-ubuntu | jamesh: do you have a specific plan (I haven't read everything yet) | 14:34 |
| zyga-ubuntu | jamesh: where would it be injected? into the per-user mount ns? | 14:34 |
| jamesh | zyga-ubuntu: no specific plan yet. From that thread, I had some ideas that were shot down. | 14:35 |
| zyga-ubuntu | ok | 14:35 |
| jamesh | zyga-ubuntu: for the session bus, we probably need to have "snap run" ask some user process to set up the socket in $XDG_RUNTIME_DIR/snap.$pkgname/dbus | 14:36 |
| jamesh | zyga-ubuntu: It's less obvious what to do about the system bus | 14:36 |
| zyga-ubuntu | jamesh: do you see this as something apps can use transparently or will this be a transition that can break existing snaps? | 14:37 |
| jamesh | zyga-ubuntu: apps connect to whatever $DBUS_SESSION_BUS_ADDRESS tells them to connect to. | 14:38 |
| zyga-ubuntu | right but I presume the point of this exercise is to put something new at the other end | 14:38 |
| jamesh | zyga-ubuntu: this would mainly offer a way for unconfined trusted helpers to identify confined apps in a confinement system independent way | 14:38 |
| zyga-ubuntu | some proxy probably | 14:38 |
| jamesh | zyga-ubuntu: so e.g. rather than xdg-desktop-portal having code to separately identify when it is talking to a snap or a flatpak, it would check for an app container ID | 14:39 |
| jamesh | zyga-ubuntu: the dbus feature also offers a new message filtering ACL system, but we can continue to rely on the existing AppArmor mediation | 14:41 |
| zyga-ubuntu | jamesh: how does the container ID thing work? | 14:42 |
| jamesh | zyga-ubuntu: some process creates a new listening unix domain socket, and passes it to dbus-daemon along with some metadata (containment system, application identifier, etc). dbus-daemon will then listen on that socket in addition to its main one, and any connections accepted on the new socket will be tagged with that info | 14:43 |
| zyga-ubuntu | ah | 14:44 |
| zyga-ubuntu | cool | 14:44 |
| zyga-ubuntu | essentially a trusted way to introduce a new socket to dbus | 14:44 |
| zyga-ubuntu | is that shipping today? | 14:44 |
| zyga-ubuntu | (anywhere) | 14:44 |
| zyga-ubuntu | if we roll this out how hard will it be to push it to 14.04 | 14:45 |
| jamesh | the initial work is in dbus master. I don't think it's in bionic yet | 14:46 |
| jamesh | and some things are in flux | 14:47 |
| zyga-ubuntu | jamesh: do you see this as a feature we only enable on some releases/distros? | 14:47 |
| zyga-ubuntu | jamesh: and can we easily identify if dbusd has it? | 14:47 |
| jamesh | zyga-ubuntu: ideally I'd use it everywhere. But it will need some kinks worked out | 14:48 |
| zyga-ubuntu | jamesh: but we cannot ship it to, say, fedora 26 | 14:49 |
| jamesh | zyga-ubuntu: the feature is controlled via method calls on the bus daemon: if those method calls are missing, then the feature isn't available. | 14:49 |
| zyga-ubuntu | jamesh: I see, that is enough to identify I guess | 14:49 |
| jamesh | zyga-ubuntu: this isn't just a feature for snapd though. It sounds like this is something flatpak wants too, which might help with getting the patches out | 14:50 |
| zyga-ubuntu | jamesh: indeed, especially since otherise, my understanding is that dbus filtering in selinux and flatpak in general is not very rich | 14:51 |
| jamesh | zyga-ubuntu: I'd like to have some plans about how we'll handle it early, rather than waiting and have it solidify in a form that works for flatpak but is unusable to us | 14:51 |
| zyga-ubuntu | (not at all available in flatpak) | 14:52 |
| jamesh | zyga-ubuntu: flatpak currently uses a dbus proxy to do its filtering, so this feature lets them get rid of that | 14:52 |
| zyga-ubuntu | ah, I see | 14:53 |
| zyga-ubuntu | is the new ACL language something you see us adopt in snapd? another securty backend (perhaps part of the existing dbus backend) | 14:53 |
| jamesh | zyga-ubuntu: I believe we can mostly ignore the filtering side by installing a wide open ACL and continue to rely on the LSM hooks | 14:53 |
| zyga-ubuntu | is there any advantage for us to use it as compared to apparmor | 14:53 |
| zyga-ubuntu | jamesh: it could boost our cross distro support | 14:53 |
| zyga-ubuntu | jamesh: I wonder if the language is similar enough to let us generate appropriate things automatically | 14:54 |
| zyga-ubuntu | either ACLs for dbus-daemon or apparmor profiles | 14:54 |
| jamesh | zyga-ubuntu: there are things that dbus's filtering could help us with. For instance, dbus won't let a process see bus names its ACL doesn't allow | 14:54 |
| jamesh | so there could be room for us to include some filtering there. | 14:55 |
| elopio | sergiusens: that ant test takes here 3 minutes. | 14:56 |
| popey | sergiusens: how can I "unrelease" a snap using snapcraft? | 14:57 |
| popey | I need to pull a specific revision from the store. Not all, just one. | 14:58 |
| jamesh | zyga-ubuntu: the upstream info about the ACL language is here: https://bugs.freedesktop.org/show_bug.cgi?id=101902 -- I've made some comments there about what I think I'd need (mainly a way to replace the base ACL after the container was created) | 14:58 |
| jamesh | zyga-ubuntu: anyway. It's late here, so I'll talk to you tomorrow. | 14:59 |
| zyga-ubuntu | jamesh: certainly, thank you for keeping me int the loop! very interesting things | 14:59 |
| kalikiana | re | 15:06 |
| sergiusens | popey I think that would be accomplished by a release of the previous revision | 15:12 |
| popey | sergiusens: nope, I don't want it released | 15:12 |
| popey | I want to *un* release it, not revert it | 15:12 |
| sergiusens | We don't have API semantics for unrelease | 15:12 |
| sergiusens | close the channel? | 15:12 |
| popey | nope | 15:12 |
| popey | I want to unrelease one arch | 15:12 |
| popey | one revision | 15:13 |
| popey | not the entire application/channel | 15:13 |
| popey | I'll file a bug if we don't have a way to do it. | 15:13 |
| sergiusens | popey I don't think you can and I am not aware of an API that would allow us to do so | 15:13 |
| popey | ok, ta :) | 15:13 |
| sergiusens | noise][ ideas ^ | 15:13 |
| noise][ | yeah, i don't think we currently cover that use case | 15:15 |
| popey | https://bugs.launchpad.net/snapstore/+bug/1742464 here you go then :) | 15:16 |
| mup | Bug #1742464: Not obvious how to 'un-release' a revision <Snapcraft:New> <Snap Store:New> <https://launchpad.net/bugs/1742464> | 15:16 |
| noise][ | thx popey | 15:16 |
| popey | noise][: is there some way a store person can ninja this? | 15:17 |
| mup | PR snapd#4470 closed: overlord/snapstate: fix gofmt -s -l <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4470> | 15:21 |
| sergiusens | elopio hey, about those tests, try with my branch as it does a lot more crawling on files | 15:22 |
| elopio | sergiusens: ack. | 15:23 |
| noise][ | popey: ping in #snapstore, probably can work something out | 15:34 |
| popey | ok | 15:36 |
| mup | PR snapd#4465 closed: cmd/snap-update-ns: new test features <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4465> | 15:39 |
| zyga-ubuntu | Chipaca: FYI https://github.com/snapcore/snapd/pull/4464/files#r160714920 | 15:45 |
| mup | PR #4464: overlord/snapstate: do a minimal sanity check on containers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4464> | 15:45 |
| zyga-ubuntu | mvo: https://github.com/snapcore/snapd/pull/4471 | 15:45 |
| mup | PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471> | 15:45 |
| mup | PR snapd#4471 opened: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471> | 15:46 |
| zyga-ubuntu | mvo: that's the essence of the PR we spoke about in the morning | 15:46 |
| zyga-ubuntu | mvo: everything else are just extra tests added on top | 15:46 |
| Chipaca | hmmm | 15:47 |
| Chipaca | zyga-ubuntu: cannot snap-exec: cannot exec "/snap/snap-hooks/x1/true": exec format error | 15:47 |
| Chipaca | zyga-ubuntu: i suspect there's a trivial case not accounted for somewhere :-) | 15:47 |
| Chipaca | zyga-ubuntu: the trivial /bin/true is an empty file with the executable bit set | 15:48 |
| Chipaca | zyga-ubuntu: looks like we don't support that :-) | 15:48 |
| zyga-ubuntu | Chipaca: that's odd, it should be done by the kernel | 15:48 |
| zyga-ubuntu | the kernel should invoke /bin/sh | 15:48 |
| zyga-ubuntu | anyway | 15:48 |
| flexiondotorg | apol: Welcome! | 15:49 |
| zyga-ubuntu | Chipaca: can you please look at 4471, just some sanity review on the structure of changePerform | 15:49 |
| apol | o/ | 15:49 |
| Chipaca | zyga-ubuntu: in a mo' | 15:49 |
| zyga-ubuntu | Chipaca: I tried hard to make that sane but then ran into a but that caused some extra logic in unexpected places | 15:49 |
| zyga-ubuntu | Chipaca: sure, thank you! | 15:49 |
| Chipaca | hmmmmmm | 15:53 |
| zyga-ubuntu | mm? | 15:53 |
| Chipaca | zyga-ubuntu: is the way snap-exec interprets commands intentional? documented? | 15:54 |
| zyga-ubuntu | Chipaca: haha, no | 15:54 |
| zyga-ubuntu | Chipaca: probably just an evolutionary result of hacking | 15:54 |
| Chipaca | zyga-ubuntu: in particular the way it interpolates variables (i think?) and splits on spaces | 15:54 |
| Chipaca | (it might not be the one doing the interpolation) | 15:54 |
| zyga-ubuntu | "we require more bugfixes" with the starcraft 2 voice | 15:54 |
| Chipaca | yes it is snap-exec doing the whole thing | 15:56 |
| mup | PR snapd#4472 opened: cmd/snap-confine: allow snap-update-ns to poke writable holes in $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4472> | 15:56 |
| pstolowski | niemeyer, dang, re plug/slot.DynamicAttrs(), I can get rid of it in policy, and that eliminates one use case, but I've two more uses cases that are slightly problematic (but i've an idea); do you have a moment to discuss before I dive into changing it? | 15:57 |
| Chipaca | zyga-ubuntu: https://github.com/snapcore/snapd/blob/master/cmd/snap-exec/main.go#L178 :-) | 15:59 |
| niemeyer | pstolowski: Sure | 15:59 |
| zyga-ubuntu | Chipaca: not sure what to think about it | 16:00 |
| Chipaca | zyga-ubuntu: 's fine | 16:00 |
| Chipaca | zyga-ubuntu: i just need to handle it in the validator as well :-) | 16:00 |
| pstolowski | niemeyer, standup ho? | 16:02 |
| niemeyer | pstolowski: On my way | 16:03 |
| mup | PR snapd#4473 opened: snap: add `snap run --strace` to be able to strace snap apps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4473> | 16:06 |
| mvo | zyga-ubuntu: thanks sorry was distracted mostly by spectre and a bit by the recent pr | 16:06 |
| zyga-ubuntu | mvo: sure, no worries :) anything new about spectre? | 16:07 |
| mvo | zyga-ubuntu: we have an updated kernel snap | 16:08 |
| mvo | zyga-ubuntu: for meltdown, I asked slangasek to build a new image for release.u.c - but there is more work to do | 16:08 |
| zyga-ubuntu | mvo: the image is for everything? AFAIK the pi is not affected | 16:10 |
| mvo | zyga-ubuntu: thats up to steve, we need an update to at least i386/amd64 | 16:10 |
| zyga-ubuntu | and then the clouds reboot | 16:11 |
| roadmr | hey folks is jdstran-d on vacation maybe? | 16:22 |
| kalikiana | kyrofa: Arg, just noticed I hadn't finished my commit for snapcraft#1857 ... pushed it now. Please let me know if you like the revised way of testing. Or if it needs more discussion | 16:26 |
| mup | PR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857> | 16:26 |
| mvo | roadmr: yeah, he is on vac | 16:26 |
| roadmr | mvo: ok, thanks :) | 16:26 |
| Chipaca | zyga-ubuntu: which was the pr you wanted me to shake a stick at? | 16:28 |
| Chipaca | roadmr: and there are photos to prove it | 16:30 |
| brunosfer | Hi guys, I'm trying to make a go application to further embed in a snap. However I do need to know in Go how can I get the list from the snaps installed without throwing a command such as "snap list" and then parse the info. | 16:35 |
| Chipaca | brunosfer: you want a snap that can list snaps? | 16:36 |
| nacc | brunosfer: or are you trying to depend on other snaps? | 16:36 |
| zyga-ubuntu | re, sorry was paying taxes | 16:42 |
| zyga-ubuntu | Chipaca: the one that makes changePerform do magic... | 16:42 |
| brunosfer | I wanted to reuse the code that exists in the cmd_lists.go to retrieve the list of snaps | 16:42 |
| zyga-ubuntu | https://github.com/snapcore/snapd/pull/4471 | 16:42 |
| mup | PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471> | 16:42 |
| zyga-ubuntu | brunosfer: I don't know if you can access that from a snap | 16:43 |
| brunosfer | but since that code is private, I will use the cmd line and parse the output with awk and so on... | 16:43 |
| zyga-ubuntu | brunosfer: you cannot run "snap" from your snap | 16:43 |
| zyga-ubuntu | brunosfer: or it won't do what you would normally be allowed to do | 16:43 |
| brunosfer | zyga-ubuntu: yeah, I just got that now after reaind the source code... | 16:44 |
| zyga-ubuntu | roadmr: hey, yes, he's off all week AFAIK | 16:44 |
| Chipaca | brunosfer: sorry to intrude, but why do you want to list the snaps installed? | 16:44 |
| zyga-ubuntu | Chipaca: actually reading my own diff I see some of the comments are stale | 16:46 |
| zyga-ubuntu | Chipaca: and could use some facelift | 16:46 |
| brunosfer | Chipaca: because I want to check if they need updates with no internet available. | 16:47 |
| Chipaca | brunosfer: there are (privileged) interfaces that let you query the snapd api directly | 16:48 |
| zyga-ubuntu | brunosfer: are you writing some management software? typically snapd does that | 16:48 |
| brunosfer | Chipaca: what are the interfaces? | 16:48 |
| Chipaca | brunosfer: so if your snap has snapd-control, you can talk to snapd and ask it (if your lcient is go, you could use the code in client/) | 16:48 |
| Chipaca | brunosfer: snapd-control is the name of the interface that gives your snap that permission | 16:49 |
| Chipaca | brunosfer: if you want to see what's available, one tool i found very useful is the 'http' snap | 16:49 |
| brunosfer | Chipaca: Thank you very much, I will give a look to that. | 16:49 |
| Chipaca | brunosfer: the http snap has snapd-control, so it can talk to snapd, and | 16:49 |
| brunosfer | Chipaca: I already used the HTTP Flag, but that's for REST requests to the API | 16:49 |
| Chipaca | brunosfer: http snapd:////v2/snaps | 16:50 |
| Chipaca | brunosfer: lists all the snaps installed | 16:50 |
| brunosfer | Chipaca: Awesome. I will check that out | 16:50 |
| zyga-ubuntu | good luck :) | 16:50 |
| brunosfer | Chipaca: Thanks! | 16:50 |
| Chipaca | brunosfer: i don't know what "HTTP Flag" is, but good luck :-) | 16:50 |
| brunosfer | zyga-ubuntu: Thanks! | 16:50 |
| zyga-ubuntu | Chipaca: the PR goes in tandem with this one https://github.com/snapcore/snapd/pull/4472 | 16:57 |
| mup | PR #4472: cmd/snap-confine: allow snap-update-ns to poke writable holes in $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4472> | 16:57 |
| zyga-ubuntu | it's a tiny tiny diff that shows you what's new | 16:57 |
| brunosfer | Chipaca: I was talking about this "sudo SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=3 /usr/lib/snapd/snapd" | 16:58 |
| Chipaca | ah :) yes | 16:58 |
| Chipaca | zyga-ubuntu: given your comments about the comments, should i wait before looking at 4471? | 17:00 |
| zyga-ubuntu | Chipaca: no, they are not that wrong | 17:01 |
| zyga-ubuntu | just a bit weirdly worded | 17:01 |
| zyga-ubuntu | Chipaca: and I'm on a clock | 17:01 |
| zyga-ubuntu | Chipaca: this cannot be proposed yet but a spread test for this is here; https://github.com/zyga/snapd/commit/617739eee69faf483dee8cad3ae241a1c5b08b57 | 17:02 |
| * kalikiana calling it a day | 17:14 | |
| brunosfer | Chipaca: Do you know how can I query directly the API locally? | 17:22 |
| Chipaca | brunosfer: it depends exactly what you mean by 'directly' and 'locally' :-) | 17:23 |
| Chipaca | brunosfer: from inside the snap? | 17:23 |
| Chipaca | brunosfer: or do you mean from a script? | 17:23 |
| zyga-ubuntu | brunosfer: talk to the same socket, if you have the right interface it can be done from the snap | 17:24 |
| zyga-ubuntu | brunosfer: if not you need to be unconfined (outside) | 17:24 |
| zyga-ubuntu | brunosfer: but should be enough to let you code | 17:24 |
| brunosfer | right now I'm doing it in golang but the idea is to make a snap out of it, so I would need to make my yaml file with those previledges, but I'm also quite noob in Go as well as in the Snaps =P | 17:26 |
| === JanC is now known as Guest37549 | ||
| === JanC_ is now known as JanC | ||
| zyga-ubuntu | brunosfer: you cannot grant the permission yourself, the interface that you'd have to request is sensitive, it would have to be a decision agreed upon in the forum and reviewed by the security team | 17:27 |
| brunosfer | Chipaca: And what do you mean by priviledged? --devmode? | 17:27 |
| zyga-ubuntu | brunosfer: some interfaces can be accessed instantly as they are considered safe | 17:28 |
| zyga-ubuntu | brunosfer: but with this interface you can equally remove and install snaps | 17:28 |
| Chipaca | brunosfer: i'm sorry if i'm not fully following what you need | 17:29 |
| Chipaca | brunosfer: curl -s --unix-socket /run/snapd.socket http://localhost/v2/snaps | 17:30 |
| Chipaca | brunosfer: ^ is that what you're asking? | 17:30 |
| pedronis | mvo: test lxd seems to have failed here: https://travis-ci.org/snapcore/snapd/builds/327212657?utm_source=github_status&utm_medium=notification | 17:31 |
| brunosfer | Chipaca: That's exactly what I was looking for! Perfect answer! Thank you so much for the command line. It works perfectly. | 17:38 |
| brunosfer | Chipaca: But for me to perform that command line do I need to have a special permission? Using it from my snap? | 17:38 |
| Chipaca | brunosfer: yes, the snap needs snapd-control to accss the socket | 17:39 |
| brunosfer | Chipaca: That's perfect. You helped me a lot ;) | 17:40 |
| mvo | pedronis: hm, you restarted by now I guess? was it just a slow download? that happens sometimes unfortunately | 17:46 |
| popey | flexiondotorg: https://bugs.launchpad.net/snapcraft/+bug/1742504 | 17:56 |
| mup | Bug #1742504: magic.mgc, 1: Warning: offset `' invalid <Snapcraft:New> <https://launchpad.net/bugs/1742504> | 17:56 |
| popey | kyrofa: ^ New and interesting ways to break snapcraft | 17:57 |
| kyrofa | Oh how fun! | 17:57 |
| kyrofa | Oh dang | 17:57 |
| kyrofa | popey, and that didn't happen in 2.35? | 17:58 |
| popey | nope | 17:58 |
| popey | flexiondotorg: just hit the same | 17:58 |
| popey | he's in an i386 vm, I'm on an i386 VPS | 17:58 |
| kyrofa | popey, you didn't read the changelog? Snapcraft does abstract art now. It's a feature | 17:58 |
| popey | lulz | 17:58 |
| popey | Nice try! | 17:58 |
| flexiondotorg | I'm running snapcraft from the beta channel on a i386 VM. | 17:58 |
| flexiondotorg | Same issue. | 17:58 |
| kyrofa | i386, huh? | 17:59 |
| kyrofa | Have either of you tried on amd64? | 17:59 |
| flexiondotorg | Doesn't happend of metal amd64. | 17:59 |
| popey | lemme switch my amd64 laptop to beta to reproduce | 18:00 |
| popey | oooh | 18:01 |
| popey | got it to do it and not screw fonts up | 18:01 |
| popey | so i have a readable stacktrace now | 18:02 |
| popey | kyrofa: there you go, comment #2 | 18:03 |
| kyrofa | popey, any chance the snap you're building is public so I can poke at what's happening there? | 18:05 |
| popey | I'll attach the yaml | 18:05 |
| popey | kyrofa: attached, and had the same issue on armhf and not amd64 | 18:07 |
| popey | You're wecome! :D | 18:07 |
| kyrofa | Thank you! We'll have a look | 18:07 |
| Chipaca | santa cachucha, so many special cases | 18:10 |
| flexiondotorg | Looks like elf patching is not working on 32-bit binaries. | 18:10 |
| popey | Looks like we need more test cases on more architectures! :D | 18:13 |
| ogra | or just drop support for some :P | 18:15 |
| flexiondotorg | Yeah, armhf ;-) | 18:15 |
| ogra | booo | 18:16 |
| Chipaca | let's drop armel and nubus-ppc | 18:17 |
| kyrofa | popey, flexiondotorg we have test cases on other arches, but they're adt | 18:19 |
| lundmar | so, the build.snapcraft.io is currently down? | 18:20 |
| * zyga-ubuntu looks at slashdot story | 18:20 | |
| zyga-ubuntu | https://news.slashdot.org/story/18/01/10/1634215/meltdown-and-spectre-patches-bricking-ubuntu-1604-computers | 18:20 |
| mup | PR snapcraft#1810 closed: [WIP] i18n support <Created by m4sk1n> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1810> | 18:22 |
| lundmar | man, for some work loads the performance degradation of spectre/meltdown fix is quite a blow. | 18:22 |
| cwayne | zyga-ubuntu: that's fixed with -109 which is already out | 18:25 |
| zyga-ubuntu | yeah, I read that | 18:25 |
| zyga-ubuntu | just was caught by the headline | 18:25 |
| roadmr | zyga-ubuntu: "bricking" should not be used to mean "left unbootable and needing recovery and/or factory reset". Bricking means "it became a useless brick and had to be thrown into trash" | 18:25 |
| zyga-ubuntu | lundmar: can you elaborate please? I'm curious | 18:25 |
| roadmr | also hi :) | 18:26 |
| zyga-ubuntu | roadmr: yeah, it's just clickbait journalism | 18:26 |
| sergiusens | kyrofa popey if it is magic that is breaking I think I can fix that | 18:26 |
| roadmr | zyga-ubuntu: well I've seen "bricking" used to mean a recoverable situation very frequently. I think people are just confused and/or have never actually had a bricked device | 18:26 |
| lundmar | zyga-ubuntu: some workloads seem to degrade by as much as ~30% | 18:26 |
| kyrofa | sergiusens, yeah, seems so | 18:26 |
| roadmr | zyga-ubuntu: but anyway I'm just whining :) | 18:26 |
| zyga-ubuntu | roadmr: hey, that's my spare time activity ;) | 18:27 |
| sergiusens | kyrofa might as well get rid of magic completely, that python module is a mess | 18:27 |
| kyrofa | sergiusens, can we? It's always so hard to find documentation for it as well | 18:27 |
| sergiusens | I wish we could also get rid of python-apt, that would also be a blessing :-) | 18:27 |
| sergiusens | kyrofa yes, I will replace it with readelf, then it is also one call | 18:27 |
| lundmar | zyga-ubuntu: you might find this interesting: https://www.phoronix.com/scan.php?page=news_item&px=KPTI-Retpoline-Combined-Ubuntu | 18:28 |
| lundmar | anyone know what is going on with build.snapcraft.io - it seems to be down but https://status.snapcraft.io is all green? | 18:29 |
| kyrofa | lundmar, yeah, the build farm is down pending mitigation for meltdown/specre | 18:30 |
| kyrofa | noise][, were you going to put something about that on status.snapcraft.io? | 18:30 |
| lundmar | the status page should show red then :) | 18:30 |
| kyrofa | No argument from me. I sent an email about this last week | 18:31 |
| noise][ | sorry, we added a notice in the Incident History on status.snapcraft.io and it was pinned to the top for a time but has now drifted down | 18:32 |
| lundmar | it's been down for a while? I only just noticed. | 18:32 |
| kyrofa | lundmar, about a week now | 18:33 |
| lundmar | ok | 18:33 |
| lundmar | hopefully it will be up again soon | 18:33 |
| kyrofa | lundmar, https://twitter.com/launchpadstatus/status/948688233029881856 | 18:33 |
| kyrofa | My hope as well | 18:33 |
| kyrofa | Mitigations started rolling last night, so I expect it to come back up any time | 18:33 |
| lundmar | great | 18:34 |
| noise][ | yes, hopefully all back over the next 2 days | 18:34 |
| lundmar | this whole spectre thing is quite a big deal - amazing such a simple mechanism has gone unnoticed until now. | 18:34 |
| kyrofa | noise][, I kinda feel like something should be big and red, there | 18:34 |
| kyrofa | build.snapcraft.io is a pretty decent thing that we should consider tracking there | 18:35 |
| noise][ | for various reasons we don't have access to check the status of the actual build farm in that status dashboard | 18:35 |
| noise][ | just that the store side and build.snapcraft.io website are up | 18:35 |
| kyrofa | Even just something that could be toggled by hand, seeing that we know the build farm is down would be handy | 18:36 |
| noise][ | well that was the incident notice, which i will re-pin now | 18:36 |
| kyrofa | noise][, I doubt people will scroll down that far once they see everything is green | 18:37 |
| kyrofa | Just sayin | 18:37 |
| lundmar | I almst missed the pinned incident pop up notice. | 18:37 |
| lundmar | almost* | 18:37 |
| zyga-ubuntu | I'm a bit exhausted, time to sleep | 18:51 |
| zyga-ubuntu | I'll wake up earlier tomorrow | 18:52 |
| mup | PR snapcraft#1862 opened: zip: support extracting non-unix zip files <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1862> | 19:04 |
| kyrofa | sergiusens, that's for you ^^ | 19:04 |
| sergiusens | actually for ogra ^ ;-) | 19:06 |
| kyrofa | Ha! | 19:06 |
| ogra | well, i'm also just proxying | 19:07 |
| sergiusens | ogra if you want to give the snap a spin, go to the travis build and search for the transfer.sh file upload ;-) | 19:07 |
| ogra | it is for that mythical "customer" guy :) | 19:07 |
| kyrofa | Yeah, like to keep those happy and non-mythical | 19:10 |
| sergiusens | kyrofa btw, was snapcraft#1639 supposed to be approved? | 19:14 |
| mup | PR snapcraft#1639: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639> | 19:14 |
| kyrofa | sergiusens, I'm re-reviewing now. elopio and I didn't like the tests, but kalikiana's fix for that seemed to introduce weird test problems | 19:15 |
| kyrofa | sergiusens, so the tests have been reverted | 19:15 |
| kyrofa | I'm kinda meh on the tests. I'd rather see real integration test snaps like we do for the other pieces of the grammar | 19:16 |
| kyrofa | But in the interest of time they may be okay | 19:17 |
| sergiusens | kyrofa if they are not good, then they are not good. | 19:32 |
| sergiusens | kyrofa what about snapcraft#1857 ? | 19:33 |
| mup | PR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857> | 19:33 |
| kyrofa | sergiusens, it's next on my queue | 19:33 |
| kyrofa | Had some testing questions there on the last pass | 19:34 |
| kyrofa | elopio, what are your thoughts on snapcraft#1639? Do you like that better than putting more snaps in tests/integration/snaps ? | 19:36 |
| mup | PR snapcraft#1639: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639> | 19:36 |
| popey | sergiusens: yay! | 20:00 |
| kyrofa | sergiusens, while I'll pass snapcraft#1639 assuming elopio is okay with it, snapcraft#1857's tests aren't right yet | 20:29 |
| mup | PR snapcraft#1639: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639> | 20:29 |
| mup | PR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857> | 20:29 |
| kyrofa | Should be an easy change though, hopefully | 20:29 |
| sergiusens | kyrofa so now only snapcraft#1853 is left? | 20:56 |
| mup | PR snapcraft#1853: extractors: support appstream icon and desktop <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1853> | 20:56 |
| kyrofa | Yep | 20:58 |
| elopio | kyrofa: yes, I think we have too many snaps in tests/integration/snaps | 20:59 |
| kyrofa | sergiusens, although we should consider snapcraft#1861 as well | 20:59 |
| mup | PR snapcraft#1861: extractors: also support appdata.xml appstream files <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1861> | 20:59 |
| elopio | I'm ok with the tests. Not super happy, but I think we can later make a better filter of the ones that require to be in snaps. And get all the others to consistently use the fixture | 21:00 |
| kyrofa | elopio, sounds good | 21:01 |
| sergiusens | elopio kyrofa fwiw I am seriously considering removing the buffering and let tests print everything they need to | 21:41 |
| kyrofa | sergiusens, we kinda tried that already, things slow waaay down | 21:42 |
| sergiusens | kyrofa not for unit, for integration | 21:42 |
| sergiusens | I don't like the current travis hack I had to do | 21:42 |
| kyrofa | sergiusens, yeah, that's what I'm talking about. Let me find the PR... | 21:42 |
| sergiusens | oh, bummer :-/ | 21:43 |
| sergiusens | ok, for the past to months every other week we've had to stop and deal with something new with travis; let's consider some alternatives | 21:43 |
| kyrofa | sergiusens, oh wait, nevermind-- things might slow down a little, but we closed it because it ended up not being necessary for what we were doing. You might like it: https://github.com/snapcore/snapcraft/pull/1591 | 21:44 |
| mup | PR snapcraft#1591: snapd integration tests: print stdout/stderr <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1591> | 21:44 |
| kyrofa | sergiusens, that's just a subset of the integration tests, but you get the idea | 21:44 |
| kyrofa | I wonder how hard it would be to port to circle CI. They seem to innovate faster, and have longer runtimes | 21:46 |
| kyrofa | Oh wait, no-- you only get one instance. Nevermind | 21:46 |
| kyrofa | That'll slow things down | 21:46 |
| sergiusens | kyrofa so, instead of printing to stdout/stderr we opted to just skip the test? :-/ | 21:47 |
| sergiusens | kyrofa we are at a point where if we do not print we need to skip all the tests | 21:47 |
| kyrofa | Hahahaha | 21:47 |
| kyrofa | It wasn't an "instead" so much as a "well, that didn't actually help us solve the problem" | 21:48 |
| kyrofa | We thought the issue was that travis was timing out before we could print, but once we fixed that the test still took waaay to long to be in the suite | 21:48 |
| kyrofa | But I agree that printing would be useful as long as we didn't suffer too much of a slowdown | 21:49 |
| mup | PR snapcraft#1639 closed: grammar: to statement <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1639> | 21:53 |
| mup | PR snapcraft#1861 closed: extractors: also support appdata.xml appstream files <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1861> | 21:56 |
| sergiusens | elopio you now have conflicts | 22:04 |
| sergiusens | kyrofa we should print a `.` for every line of progress or something like that | 22:05 |
| sergiusens | kyrofa I still think we need to migrate away from travis, the free tier isn't cutting it | 22:05 |
| kyrofa | sergiusens, then I only see two options: non-free tier, or self-hosting | 22:06 |
| kyrofa | (which is also non-free) | 22:06 |
| sergiusens | kyrofa yeah we will probably go back to adt | 22:06 |
| kyrofa | elopio, one more comment on snapcraft#1853, but I suspect it's good | 22:16 |
| mup | PR snapcraft#1853: extractors: support appstream icon and desktop <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1853> | 22:16 |
| elopio | kyrofa! | 22:20 |
| elopio | sorry | 22:20 |
| elopio | kyrofa: so are you OK with every get to return Union[str, List[str]]? | 22:21 |
| elopio | It's easy to change, just want to double check I got your comment | 22:22 |
| kyrofa | elopio, seems better than Any | 22:26 |
| kyrofa | elopio, note that mypy will barf if you end up handing it off to something that expects a str though, so you can cast if you know for sure it is (and need it to be) | 22:26 |
| popey | kyrofa: for some reason I picked up from a thread on the forum that $SNAP_ARCH_TRIPLET was a thing I could use in environment: | 22:44 |
| popey | kyrofa: seems not :( | 22:44 |
| popey | Any plan to add it, so we don't have to add if elif elif elif else fi nonsense? | 22:44 |
| kyrofa | popey, SNAPCRAFT_ARCH_TRIPLET, and only in 2.36 and later | 22:44 |
| popey | oh! | 22:44 |
| popey | in environment? | 22:45 |
| popey | e.g. if I have an environment setup for a command, will snapcraft fill it in at build time? | 22:45 |
| kyrofa | popey, I'm not 100% sure what you're asking, but it's like SNAPCRAFT_PART_INSTALL if you've used that | 22:46 |
| kyrofa | It is an environment variable | 22:46 |
| popey | but it's an environment varibale at snapcraft runtime, not snap runtime | 22:46 |
| popey | so for example if i have a command that needs a path set to a lib directory, setting environment: PATH: "$SNAP/usr/lib/$SNAPCRAFT_ARCH_TRIPLET/foo" gonna work? | 22:47 |
| kyrofa | popey, ahh, right, I see where you're coming from now | 22:49 |
| kyrofa | popey, no, that won't work | 22:49 |
| popey | :( | 22:50 |
| popey | I end up needing 3 yamls, one per arch | 22:50 |
| kyrofa | popey, I really wish snapd would add that, but I added a remote part for it if you want to use that instead | 22:50 |
| popey | yeah, i found that :) | 22:50 |
| kyrofa | THAT will give you SNAP_ARCH_TRIPLET | 22:50 |
| kyrofa | popey, and it literally just does the elif elif elif vi nonsense for you :P | 22:51 |
| kyrofa | Huh. I type that command too much | 22:52 |
| popey | :D | 22:52 |
| kyrofa | So yeah, you can use SNAPCRAFT_ARCH_TRIPLET at snap build time, but at runtime all snapd gives you is SNAP_ARCH, so you either need to write the elif stuff or use that remote part | 22:53 |
| popey | This feels like it needs a bug | 22:53 |
| popey | having a bunch of shell script attached to a hundred snaps makes no sense | 22:54 |
| kyrofa | I could have sworn we had one against snapd at some point, but I suspect it was lost between snappy/snapd/etc. | 22:54 |
| kyrofa | I agree | 22:54 |
| * popey files | 22:54 | |
| kyrofa | popey, sorry I got your hopes up. I pictured your childish joy at learning this was possible only to have crushed it | 22:56 |
| popey | hahah | 22:56 |
| kyrofa | er, childlike is probably what I wanted there | 22:56 |
| popey | https://bugs.launchpad.net/snapd/+bug/1742565 | 22:58 |
| mup | Bug #1742565: snapd should provide SNAP_ARCH_TRIPLET <snapd:New> <https://launchpad.net/bugs/1742565> | 22:58 |
| popey | kyrofa: snapcraft really craps the bed if you switch from beta to stable | 23:20 |
| popey | i.e. from 2.38 back to 2.35 | 23:20 |
| kyrofa | popey, because of the state tracking? | 23:20 |
| kyrofa | Yeah, that was written well before snaps were a possibility. We should start accounting for that | 23:21 |
| popey | https://paste.ubuntu.com/26363030/ | 23:21 |
| kyrofa | Handle it well, say 'hey yo, I don't recognize this state stuff at all. Clean, man." | 23:21 |
| popey | i have no idea what to do at this point ^ | 23:22 |
| kyrofa | popey, wait, that's different | 23:22 |
| kyrofa | popey, are you on i386 again? | 23:22 |
| popey | yes, same on armhf | 23:22 |
| kyrofa | stable channel? | 23:22 |
| popey | yes | 23:22 |
| popey | i reverted back from beta to stable to rebuild something and avoid the magic bug from earlier | 23:23 |
| kyrofa | popey, https://bugs.launchpad.net/snapcraft/+bug/1733922 | 23:23 |
| mup | Bug #1733922: “snapcraft init” crashes on 32-bit Ubuntu <Snapcraft:Fix Released by kyrofa> <https://launchpad.net/bugs/1733922> | 23:23 |
| kyrofa | popey, the fix is in 2.36, I'm afraid | 23:23 |
| popey | uhm | 23:23 |
| kyrofa | That never made it to stable | 23:24 |
| popey | so 2.35 is broken, 2.36 is fixed (but never released) and 2.38 (released) is broken. | 23:24 |
| popey | Which version should I use? :) | 23:24 |
| kyrofa | popey, hold on, let me give you 2.36 | 23:24 |
| popey | i wonder if I can refresh --revision? | 23:25 |
| kyrofa | popey, you're not a collaborator. But you don't need to be, I'll make a hotfix channel for ya | 23:25 |
| popey | oh, i dont think you need to be a collaborator to --revision ninja | 23:25 |
| popey | I did this earlier with another snap ;) | 23:25 |
| kyrofa | Hmm, okay. I thought that was the idea, anyway | 23:26 |
| kyrofa | popey, you're on armhf? Try rev 878 | 23:26 |
| kyrofa | popey, let me know if it doesn't work and I'll create a hotfix | 23:27 |
| popey | it wont let me | 23:27 |
| kyrofa | Oh good, I'm not insane | 23:27 |
| popey | i think the deb works | 23:27 |
| popey | (I used the deb earlier successfully, but only moved to snap to test some of these environment variables) | 23:27 |
| kyrofa | Indeed, the deb should work for that bug anyway | 23:28 |
| popey | ok, lemme test that | 23:28 |
| kyrofa | popey, feel free to use the edge/2-36 channel as well, if you like | 23:33 |
| popey | thanks | 23:33 |
| popey | they're all building now | 23:33 |
| kyrofa | popey, edge/2-37 is open as well, if you find you need it | 23:35 |
| popey | you're a star | 23:35 |
| kyrofa | Remember they only live for a month, but easy to re-create if necessary | 23:35 |
| popey | I'm sure all the bugs will be fixed in a month, so won't need it ;) | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!