seyeongkimhello, is there a way to install older revision of core?03:53
mupPR snapcraft#1861 opened: extractors: also support appdata.xml appstream files <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1861>05:40
* zyga-ubuntu is tad sleepy06:47
zyga-ubuntuhacking till 2AM06:47
zyga-ubuntuI'll go back to bed06:48
mborzeckizyga-ubuntu: hey06:50
mborzeckimvo: morning07:21
mupPR 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
mvohey mborzecki - good monring07:23
mupPR 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
mupPR 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
kalikianagood morning07:53
mborzeckikalikiana: morning07:54
mupPR 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-ubuntuback now, I think I owe everyone some reviews08:32
zyga-ubuntuI took 4452 and went wild on unit tests08:35
zyga-ubuntufound an obscure bug with symlinks (and fixed it)08:35
zyga-ubuntubut grew the branch to a big extreme sizes08:36
zyga-ubuntuI will probably double back and propse all the unit test changes separately, though not sure if that will help08:36
zyga-ubuntuI'll get a coffee and start chopping08:38
zyga-ubuntuall right08:46
=== __chip__ is now known as Chipaca
mupPR snapd#4464 opened: overlord/snapstate: add validateContainer, that uses snap.Container's <Created by chipaca> <https://github.com/snapcore/snapd/pull/4464>09:05
Chipacamvo: thank you for merging #4394! As a recompense, here's 4464 ^-^09:05
mupPR #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
Chipacaoh dear, commit message murder09:06
* Chipaca tidies09:06
* kalikiana coffee09:07
mvoChipaca: thanks for the code update. it was very nice09:07
pedronisChipaca: 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
Chipacapedronis: 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
pedronisChipaca: well, not these days people publish as classic instead09:11
Chipacapedronis: same argument there though09:12
Chipacapedronis: but just to be clear, it's merely a sense of tidiness, nothing more09:12
pedronisI found our tests not very tidy in general, but maybe it's just me09:13
Chipacapedronis: that's fair09:14
pedronisI mean, I feel when writing spread tests that my tidniness setting is medium09:15
zyga-ubuntupedronis: hehe, how does that materialize?09:16
Chipacazyga-ubuntu: I'm assuming if it were higher than that there'd be infinite PRs from samuele trying to beat our spread suite into submission09:18
pedronisChipaca: 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.sh09:21
Chipacapedronis: no worries09:21
pedronisChipaca: 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
mvoChipaca: you have a review09:33
mvoChipaca: nice job btw09:33
mvoa second review for 4454 would be nice, should be trivial09:34
mupPR 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
mvopedronis: I think https://github.com/snapcore/snapd/pull/4356 is ready for a re-review09:39
mupPR #4356: many: add new `snap refresh --amend <snap>` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/4356>09:39
pedronisI'll look at it today09:40
* Chipaca -> bbiab (physio)09:43
kalikianawoot, --ammend wouldn't have been my choice of name, but nice to see this09:44
mvokalikiana: not too late for suggestions :)09:44
mvokalikiana: in the PR please, they will need sign off from gustavo09:44
kalikianaAye, will comment there09:49
mvopopey: hey, we 1742247> what version of snapd did you use to make this workaround work?09:57
mvopopey: 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
popeymvo: I'm on core from candidate10:01
mvopopey: ta, let me try to reproduce with that10:01
mvomborzecki: https://travis-ci.org/snapcore/snapd/builds/327128264#L1541 is probably something you want to look at10:03
mvomborzecki: (context is 4463)10:03
mborzeckimvo: thanks, looking now10:03
mvoalso 4461 is tiny and needs a second review10:04
zyga-ubuntuhmm, github is not responding here10:06
kalikianapopey: ping wrt bug 174175210:07
mupBug #1741752: yaml.constructor.ConstructorError: could not determine a constructor for the tag '!ExtractedMetadata' <Snapcraft:New> <https://launchpad.net/bugs/1741752>10:07
popeykalikiana: hello10:07
kalikianapopey: Hey. How are you this morning?10:07
popeySuper, how are you? :)10:08
kalikianaVery well. There's a little bit of sun today so that"s rare and awesome :-D10:08
zyga-ubuntuit's down10:09
kalikianapopey: 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
popeythat's right10:10
popeywhat I do is run snapcraft, the thing needs rebuilding so I re-run snapcraft. Then the error appears10:11
kalikianapopey: 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
popeyYes. That's what I expect. But as I said, I didn't clean. But I _have_ to clean to get past this error10:12
kalikianaeg. `snapcraft clean mypart` would *not* delete it10:12
kalikianapopey: You mean if you do `snapcraft clean` the error goes away?10:13
kalikianapopey: Okay, now that makes sense. I was a bit lost in your wording, sorry :-D10:13
popeyAh sorry. Will try harder with my words next time :)10:14
kalikianapopey: 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
popeyWait, what?10:16
popeyI don't want to pull in a new snapcraft revision10:16
popeyI just wanted the software to rebuild, that's all10:17
popeyand 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 build10:17
kalikianapopey: Example, you have snapcraft from beta, build stuff in a container, do `snap refresh snapcraft --channel=edge`, and now your new snapcraft has different expectations10:18
kalikianaI think that's what happened, simplified10:18
popeyI didnt do that10:18
popeyi just ran snapcraft and then ran snapcraft again10:18
popeyyou're saying snapd refreshed in the minute or two between running snapcraft and running it again?10:19
mupPR 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
kalikianapopey: So you were using edge the whole time?10:21
kalikianaPlease bear with me, I'm just trying to get the exact situation10:21
kalikianapopey: So then it must've been snapd refreshing out of sync on your host vs. container10:22
kalikianaWhich is possible since we don't force that10:22
popeykalikiana: tell you what, lets park that bug, and I will try and re-produce it.10:24
popeyAnd get a better "steps to reproduce" okay?10:24
popeybecause it's all a bit muddy now :)10:24
popey(unless you fully understand it now and know what to fix) :D10:26
mupPR 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-ubuntumvo: 1st of the easy branches: https://github.com/snapcore/snapd/pull/4465/files10:27
mupPR #4465: cmd/snap-update-ns: new test features <Created by zyga> <https://github.com/snapcore/snapd/pull/4465>10:27
mupPR snapd#4465 opened: cmd/snap-update-ns: new test features <Created by zyga> <https://github.com/snapcore/snapd/pull/4465>10:28
sparkiegeekmvo: anything I can do to help #1735344 along?10:30
mupBug #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
mvoniemeyer: hey, for late, do the strings in 4441 look good to you ? this pr is mostly a tiny string change10:30
mvosparkiegeek: a good question, it is still in unapproved. I assume apw is just super busy with spectre/meltdown and all this madness10:31
* sparkiegeek nods10:32
apwi am cirtaonly that, plus it won't build even if i accept it10:32
mvoapw: aha, indeed, that is the other issue :)10:32
* mvo hugs apw for tireless work to protect us again10:32
sparkiegeekmvo: just to confirm, to get 2.30 in the meantime, I should use  ppa:snappy-dev/edge ?10:33
* sparkiegeek joins mvo in hugging apw10:33
sparkiegeekon systems that don't have core installed and need ... configuration10:34
kalikianapopey: Yeah, I think I know what's going on now. Incompatible `snap/.snapcraft/state`. I'll figure something out with elopio10:34
mvosparkiegeek: 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
mvosparkiegeek: its there for xenial,zesty,artful10:34
kalikianapopey: Thanks for clarifying the missing pieces of the puzzle!10:34
mvosparkiegeek: and I think trusty but I doubt you care about that10:34
mupPR 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
popeykalikiana: awesome10:36
mvoniemeyer: 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 consistent10:36
zyga-ubuntumvo: 2nd and tiny trivial PR: https://github.com/snapcore/snapd/pull/446610:38
mupPR #4466: interfaces/mount: test OptsToCommonFlags, filter out x-snapd. options <Created by zyga> <https://github.com/snapcore/snapd/pull/4466>10:38
mupPR 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-ubuntumvo: 3rd trival PR: https://github.com/snapcore/snapd/pull/446710:39
mupPR #4467: cmd/snap-update-ns: untangle upcoming cyclic initialization <Created by zyga> <https://github.com/snapcore/snapd/pull/4467>10:39
mupPR 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
mupPR snapd#4467 opened: cmd/snap-update-ns: untangle upcoming cyclic initialization <Created by zyga> <https://github.com/snapcore/snapd/pull/4467>10:40
zyga-ubuntumvo: 4th: ^10:40
mupPR 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
mvozyga-ubuntu: ta10:41
zyga-ubuntunow the main dish, this will take a little longer to prepare10:41
mupPR 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-ubuntumvo: I have the rest but I need this batch to land, I'll switch to review to help others now11:05
zyga-ubuntumvo: if you can review 4465, 4466, 4467 and 4468 it will help me a lot, they are all small11:06
mvozyga-ubuntu: ok11:12
niemeyermvo: Thanks, will look at that next11:12
zyga-ubuntuhey niemeyer, good morning :)11:13
mvoniemeyer: thanks! really just a quick ack/nack on the strings11:13
mvoniemeyer: and good morning :)11:13
* Son_Goku rises from the dead11:24
zyga-ubuntuSon_Goku: hey11:27
* zyga-ubuntu hands Son_Goku a coffee11:27
zyga-ubuntumborzecki: you have a review on 444911:27
* Son_Goku stares at the coffee11:27
mborzeckizyga-ubuntu: thanks11:30
niemeyermvo: What's the background for #4441?11:31
mupPR #4441: snap: add usage hints in `snap download` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4441>11:31
mvoniemeyer: a bugreport11:33
mvoniemeyer: it should be referenced in the PR - its fine if this is a won't-fix of course11:34
niemeyermvo: 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 pages11:35
niemeyermvo: What was the report? People lacking ack?11:35
mvoniemeyer: yeah, people did not know apparently that "snap ack" exists/can be used to import the assertion11:35
niemeyermvo: Okay, maybe we can be more direct then and give the command names11:36
niemeyercommand lines11:36
niemeyermvo: I'll suggest something for your consideration there11:36
mvoniemeyer: +111:37
mvoniemeyer: thank you!11:37
mvozyga-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-ubuntumvo: 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-ubuntumvo: in the debug binary those will be visible11:39
zyga-ubuntumvo: I think the 2nd part is not strictly needed11:39
mvozyga-ubuntu: right, but still, why are the tests expecting two lines now, one with "hidden" and then "the real thing"?11:40
zyga-ubuntumvo: I don't know :)11:40
mborzeckizyga-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 enabled11:40
niemeyermvo: np, please have a look to see what you think11:41
mborzeckibasically 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-ubuntumborzecki: that's the desired behavior11:42
mborzeckizyga-ubuntu: ok, but then but if you turn SNAP_CONFINE_DEBUG off you'll see `cannot perform operation: mount -t blah blah`11:42
mvomborzecki: lol, really?11:42
mborzeckiyes, that's what the PR is fixing11:42
zyga-ubuntumborzecki: hmmm :)11:43
mvomborzecki: 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
mupPR #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-ubuntumborzecki: that's probably confusing, are you sure we render the messages in non-debug builds?11:43
zyga-ubuntumborzecki: I've seen the disabled message countless times11:43
zyga-ubuntumborzecki: some messages are hardcoded and not formatted on the fly11:43
mborzeckizyga-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 log11:44
mborzeckipopey got:11:44
mborzecki[alan@manjarovm ~]$ snap run brave11:44
mborzeckicannot perform operation: mount --rbind /dev /tmp/snap.rootfs_gwR9tX//dev: No such file or directory11:44
mborzeckiand then when running with SNAP_CONFINE_DEBUG:11:44
zyga-ubuntumborzecki: that particular one may be hardcoded11:44
zyga-ubuntumborzecki: they look the same but come from different places11:45
mborzeckicannot perform operation: (disabled) use debug build to see details: No such file or directory11:45
zyga-ubuntumborzecki: DEBUG: performing operation: (disabled) use debug build to see details11:45
zyga-ubuntumborzecki: that's the disabled one11:45
zyga-ubuntumborzecki: I still don't see what's wrong there11:45
mborzeckizyga-ubuntu: no SNAP_CONFINE_DEBUG, `cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_gwR9tX//dev: No such file or directory`11:46
mborzeckizyga-ubuntu: with SNAP_CONFINE_DEBUG `cannot perform operation: (disabled) use debug build to see details: No such file or directory`11:46
mborzeckisame binary11:46
zyga-ubuntumborzecki: devil is in the details :) but I see how this is confusing (for me too)11:46
zyga-ubuntumborzecki: it depends on who prints what11:46
zyga-ubuntumborzecki: anyway, I'll look again, thank you for explaining that11:46
mborzeckizyga-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 fails11:48
zyga-ubuntuthat's wrong11:49
zyga-ubuntuit should not be there11:49
zyga-ubuntuthat whole thing should go away11:49
zyga-ubuntu :D11:49
zyga-ubuntuI just read the comment above it11:50
zyga-ubuntusorry, my mind is rusty about this11:50
=== ogra_ is now known as ogra
mborzeckiChipaca: 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
mupPR 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
mupPR 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 Chipaca12:00
zyga-ubuntumborzecki: nice find!12:00
=== Chipakeitor is now known as Chipaca
Chipacamborzecki: i'm not sure i understand12:01
niemeyermvo: On the second one, a typo and a suggestion12:04
mvoniemeyer: \o/ thank you12:04
mborzeckiChipaca: looking into it now, might be false positive12:04
* zyga-ubuntu goes to cook something, ttyl12:05
niemeyermvo: Thank you!12:05
Chipacamborzecki: I don't mind making boltFinder embed a *bolt.DB instead of a bolt.DB if it makes the liter happy12:05
mborzeckiChipaca: i guess the tool cannot detect if the pool was used and raises a warning12:06
Chipacamborzecki: and it's fair; there's no guarantee the DB didn't start a maintenance goroutine12:07
mborzeckithen i think it's fair to embed *botl.DB rather than a copy12:07
* Chipaca nods12:08
Chipacathanks, metalinter! <plastic grin> <cut to commercial>12:08
* Chipaca -> dentit12:25
mupPR 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
Chipacai might be a few minutes late to the standup12:58
* Chipaca returning from dentistist12:58
mborzeckigometalinter running from run-checks --static https://paste.ubuntu.com/26359996/12:59
mupPR snapd#4470 opened: overlord/snapstate: fix gofmt -s -l <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4470>13:07
mupPR 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
mvokyrofa, 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
mupPR 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-ubuntuChipakeitor: can you look at 4465-4468 quickly, I'd like to land them to propse the intersting changes that will take longer to review13:47
=== Chipakeitor is now known as Chipaca
* Chipaca looks13:47
mupPR 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
Chipacazyga-ubuntu: neat-o13:55
* kalikiana going to have lunch, back in a bit14:00
* pstolowski lunch14:01
mupPR 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
mupPR 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
mupPR 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
jameshzyga-ubuntu: hi.  Yesterday you mentioned having a chat about user-mounts some time tomorrow  with niemeyer.  Should we set a time?14:14
zyga-ubuntujamesh: hey, yes the plan is to do it tomorrow, you mentioned someting about your morning being preferred14:15
zyga-ubuntulet's look at the calendar now14:15
jameshzyga-ubuntu: I thought my evening might be easier14:15
zyga-ubuntuah I must have rembembered wrong then, sorry14:16
jameshI think the biggest time difference is between WA and Brazil14:16
mborzeckioff to pick up the kids14:18
zyga-ubuntuI wish google calendar could show the local time for each participant14:18
zyga-ubuntujamesh: when it's 10AM here (CET+1) what is it for you?14:19
Chipacazyga-ubuntu: i thought you were on CET14:19
zyga-ubuntuChipaca: I never remember if its' CET or +114:20
zyga-ubuntuChipaca: DST and that14:20
Chipacazyga-ubuntu: your DST is in march14:20
Chipacastarts in march, i mean14:21
jameshzyga-ubuntu: WA is UTC+8, so 10AM in UTC+1 would be 5 PM14:21
zyga-ubuntujamesh: that's reasonable for you I think14:21
zyga-ubuntuChipaca: ah, I remembered UTC+1=CET, now it makes sense14:22
zyga-ubuntujamesh: ok I think 10AM it is14:22
jameshzyga-ubuntu: sounds great.14:23
zyga-ubuntuhmm, the new calendar has arrived14:23
zyga-ubuntuno idea how to add a hangout link14:24
jameshzyga-ubuntu: maybe move it forward a day?14:24
ChipacaHAH! a bunch of spread tests failed because the snaps don't pass validation14:25
* sergiusens ran out to run some errands14:25
zyga-ubuntudoh :D14:25
jameshzyga-ubuntu: you've got it scheduled for 5 hours ago14:25
zyga-ubuntusorry, the UI is totally confusing at first sight, I saw vertical stripes which I assumed were days, it's updated now14:26
zyga-ubuntu(it were people, not days)14:26
sergiusensmvo is your PR tagged with a greater number?14:26
mvosergiusens: it says "milestone: 2.35"14:27
zyga-ubuntujamesh: realistically I think we'll see a lot of mount features ladning next week14:28
zyga-ubuntujamesh: I'm close to enabling layouts, the new content interface will likely land this week14:28
mvosergiusens: hrm, but apparently I only have 2.34 - sorry, let me figure out where I can get 2.3514:28
zyga-ubuntujamesh: your work is also looking very good14:28
zyga-ubuntujamesh: we can look at enabling themes soon, though I don't really know if my I know what your plans for that are14:29
jameshzyga-ubuntu: If there is time, I'd also like to discuss how we could support the dbus app container socket feature14:30
zyga-ubuntuI'm not familiar with that, can you share a link so that I can prepare14:30
jameshzyga-ubuntu: https://forum.snapcraft.io/t/interacting-with-dbus-daemons-app-container-feature/3245 has a summary I prepared, plus links to the upstream bugs14:31
zyga-ubuntuthank you, I'll read that today14:31
jameshzyga-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 namespaces14:33
jameshsince we'd want to inject a new unix socket14:34
zyga-ubuntujamesh: do you have a specific plan (I haven't read everything yet)14:34
zyga-ubuntujamesh: where would it be injected? into the per-user mount ns?14:34
jameshzyga-ubuntu: no specific plan yet.  From that thread, I had some ideas that were shot down.14:35
jameshzyga-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/dbus14:36
jameshzyga-ubuntu: It's less obvious what to do about the system bus14:36
zyga-ubuntujamesh: do you see this as something apps can use transparently or will this be a transition that can break existing snaps?14:37
jameshzyga-ubuntu: apps connect to whatever $DBUS_SESSION_BUS_ADDRESS tells them to connect to.14:38
zyga-ubunturight but I presume the point of this exercise is to put something new at the other end14:38
jameshzyga-ubuntu: this would mainly offer a way for unconfined trusted helpers to identify confined apps in a confinement system independent way14:38
zyga-ubuntusome proxy probably14:38
jameshzyga-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 ID14:39
jameshzyga-ubuntu: the dbus feature also offers a new message filtering ACL system, but we can continue to rely on the existing AppArmor mediation14:41
zyga-ubuntujamesh: how does the container ID thing work?14:42
jameshzyga-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 info14:43
zyga-ubuntuessentially a trusted way to introduce a new socket to dbus14:44
zyga-ubuntuis that shipping today?14:44
zyga-ubuntuif we roll this out how hard will it be to push it to 14.0414:45
jameshthe initial work is in dbus master.  I don't think it's in bionic yet14:46
jameshand some things are in flux14:47
zyga-ubuntujamesh: do you see this as a feature we only enable on some releases/distros?14:47
zyga-ubuntujamesh: and can we easily identify if dbusd has it?14:47
jameshzyga-ubuntu: ideally I'd use it everywhere.  But it will need some kinks worked out14:48
zyga-ubuntujamesh: but we cannot ship it to, say, fedora 2614:49
jameshzyga-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-ubuntujamesh: I see, that is enough to identify I guess14:49
jameshzyga-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 out14:50
zyga-ubuntujamesh: indeed, especially since otherise, my understanding is that dbus filtering in selinux and flatpak in general is not very rich14:51
jameshzyga-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 us14:51
zyga-ubuntu(not at all available in flatpak)14:52
jameshzyga-ubuntu: flatpak currently uses a dbus proxy to do its filtering, so this feature lets them get rid of that14:52
zyga-ubuntuah, I see14:53
zyga-ubuntuis the new ACL language something you see us adopt in snapd? another securty backend (perhaps part of the existing dbus backend)14:53
jameshzyga-ubuntu: I believe we can mostly ignore the filtering side by installing a wide open ACL and continue to rely on the LSM hooks14:53
zyga-ubuntuis there any advantage for us to use it as compared to apparmor14:53
zyga-ubuntujamesh: it could boost our cross distro support14:53
zyga-ubuntujamesh: I wonder if the language is similar enough to let us generate appropriate things automatically14:54
zyga-ubuntueither ACLs for dbus-daemon or apparmor profiles14:54
jameshzyga-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 allow14:54
jameshso there could be room for us to include some filtering there.14:55
elopiosergiusens: that ant test takes here 3 minutes.14:56
popeysergiusens: how can I "unrelease" a snap using snapcraft?14:57
popeyI need to pull a specific revision from the store. Not all, just one.14:58
jameshzyga-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
jameshzyga-ubuntu: anyway. It's late here, so I'll talk to you tomorrow.14:59
zyga-ubuntujamesh: certainly, thank you for keeping me int the loop! very interesting things14:59
sergiusenspopey I think that would be accomplished by a  release of the previous revision15:12
popeysergiusens: nope, I don't want it released15:12
popeyI want to *un* release it, not revert it15:12
sergiusensWe don't have API semantics for unrelease15:12
sergiusensclose the channel?15:12
popeyI want to unrelease one arch15:12
popeyone revision15:13
popeynot the entire application/channel15:13
popeyI'll file a bug if we don't have a way to do it.15:13
sergiusenspopey I don't think you can and I am not aware of an API that would allow us to do so15:13
popeyok, ta :)15:13
sergiusensnoise][ ideas ^15:13
noise][yeah, i don't think we currently cover that use case15:15
popeyhttps://bugs.launchpad.net/snapstore/+bug/1742464  here you go then :)15:16
mupBug #1742464: Not obvious how to 'un-release' a revision <Snapcraft:New> <Snap Store:New> <https://launchpad.net/bugs/1742464>15:16
noise][thx popey15:16
popeynoise][: is there some way a store person can ninja this?15:17
mupPR snapd#4470 closed: overlord/snapstate: fix gofmt -s -l <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4470>15:21
sergiusenselopio hey, about those tests, try with my branch as it does a lot more crawling on files15:22
elopiosergiusens: ack.15:23
noise][popey: ping in #snapstore, probably can work something out15:34
mupPR 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-ubuntuChipaca: FYI https://github.com/snapcore/snapd/pull/4464/files#r16071492015:45
mupPR #4464: overlord/snapstate: do a minimal sanity check on containers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4464>15:45
zyga-ubuntumvo: https://github.com/snapcore/snapd/pull/447115:45
mupPR #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
mupPR 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-ubuntumvo: that's the essence of the PR we spoke about in the morning15:46
zyga-ubuntumvo: everything else are just extra tests added on top15:46
Chipacazyga-ubuntu: cannot snap-exec: cannot exec "/snap/snap-hooks/x1/true": exec format error15:47
Chipacazyga-ubuntu: i suspect there's a trivial case not accounted for somewhere :-)15:47
Chipacazyga-ubuntu: the trivial /bin/true is an empty file with the executable bit set15:48
Chipacazyga-ubuntu: looks like we don't support that :-)15:48
zyga-ubuntuChipaca: that's odd, it should be done by the kernel15:48
zyga-ubuntuthe kernel should invoke /bin/sh15:48
flexiondotorgapol: Welcome!15:49
zyga-ubuntuChipaca: can you please look at 4471, just some sanity review on the structure of changePerform15:49
Chipacazyga-ubuntu: in a mo'15:49
zyga-ubuntuChipaca: I tried hard to make that sane but then ran into a but that caused some extra logic in unexpected places15:49
zyga-ubuntuChipaca: sure, thank you!15:49
Chipacazyga-ubuntu: is the way snap-exec interprets commands intentional? documented?15:54
zyga-ubuntuChipaca: haha, no15:54
zyga-ubuntuChipaca: probably just an evolutionary result of hacking15:54
Chipacazyga-ubuntu: in particular the way it interpolates variables (i think?) and splits on spaces15:54
Chipaca(it might not be the one doing the interpolation)15:54
zyga-ubuntu"we require more bugfixes" with the starcraft 2 voice15:54
Chipacayes it is snap-exec doing the whole thing15:56
mupPR 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
pstolowskiniemeyer, 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
Chipacazyga-ubuntu: https://github.com/snapcore/snapd/blob/master/cmd/snap-exec/main.go#L178 :-)15:59
niemeyerpstolowski: Sure15:59
zyga-ubuntuChipaca: not sure what to think about it16:00
Chipacazyga-ubuntu: 's fine16:00
Chipacazyga-ubuntu: i just need to handle it in the validator as well :-)16:00
pstolowskiniemeyer, standup ho?16:02
niemeyerpstolowski: On my way16:03
mupPR 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
mvozyga-ubuntu: thanks sorry was distracted mostly by spectre and a bit by the recent pr16:06
zyga-ubuntumvo: sure, no worries :) anything new about spectre?16:07
mvozyga-ubuntu: we have an updated kernel snap16:08
mvozyga-ubuntu: for meltdown, I asked slangasek to build a new image for release.u.c - but there is more work to do16:08
zyga-ubuntumvo: the image is for everything? AFAIK the pi is not affected16:10
mvozyga-ubuntu: thats up to steve, we need an update to at least i386/amd6416:10
zyga-ubuntuand then the clouds reboot16:11
roadmrhey folks is jdstran-d on vacation maybe?16:22
kalikianakyrofa: 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 discussion16:26
mupPR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857>16:26
mvoroadmr: yeah, he is on vac16:26
roadmrmvo: ok, thanks :)16:26
Chipacazyga-ubuntu: which was the pr you wanted me to shake a stick at?16:28
Chipacaroadmr: and there are photos to prove it16:30
brunosferHi 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
Chipacabrunosfer: you want a snap that can list snaps?16:36
naccbrunosfer: or are you trying to depend on other snaps?16:36
zyga-ubunture, sorry was paying taxes16:42
zyga-ubuntuChipaca: the one that makes changePerform do magic...16:42
brunosferI wanted to reuse the code that exists in the cmd_lists.go to retrieve the list of snaps16:42
mupPR #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-ubuntubrunosfer: I don't know if you can access that from a snap16:43
brunosferbut since that code is private, I will use the cmd line and parse the output with awk and so on...16:43
zyga-ubuntubrunosfer: you cannot run "snap" from your snap16:43
zyga-ubuntubrunosfer: or it won't do what you would normally be allowed to do16:43
brunosferzyga-ubuntu: yeah, I just got that now after reaind the source code...16:44
zyga-ubunturoadmr: hey, yes, he's off all week AFAIK16:44
Chipacabrunosfer: sorry to intrude, but why do you want to list the snaps installed?16:44
zyga-ubuntuChipaca: actually reading my own diff I see some of the comments are stale16:46
zyga-ubuntuChipaca: and could use some facelift16:46
brunosferChipaca: because I want to check if they need updates with no internet available.16:47
Chipacabrunosfer: there are (privileged) interfaces that let you query the snapd api directly16:48
zyga-ubuntubrunosfer: are you writing some management software? typically snapd does that16:48
brunosferChipaca: what are the interfaces?16:48
Chipacabrunosfer: 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
Chipacabrunosfer: snapd-control is the name of the interface that gives your snap that permission16:49
Chipacabrunosfer: if you want to see what's available, one tool i found very useful is the 'http' snap16:49
brunosferChipaca: Thank you very much, I will give a look to that.16:49
Chipacabrunosfer: the http snap has snapd-control, so it can talk to snapd, and16:49
brunosferChipaca: I already used the HTTP Flag, but that's for REST requests to the API16:49
Chipacabrunosfer: http snapd:////v2/snaps16:50
Chipacabrunosfer: lists all the snaps installed16:50
brunosferChipaca: Awesome. I will check that out16:50
zyga-ubuntugood luck :)16:50
brunosferChipaca: Thanks!16:50
Chipacabrunosfer: i don't know what "HTTP Flag" is, but good luck :-)16:50
brunosferzyga-ubuntu: Thanks!16:50
zyga-ubuntuChipaca: the PR goes in tandem with this one https://github.com/snapcore/snapd/pull/447216:57
mupPR #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-ubuntuit's a tiny tiny diff that shows you what's new16:57
brunosferChipaca: I was talking about this "sudo SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=3 /usr/lib/snapd/snapd"16:58
Chipacaah :) yes16:58
Chipacazyga-ubuntu: given your comments about the comments, should i wait before looking at 4471?17:00
zyga-ubuntuChipaca: no, they are not that wrong17:01
zyga-ubuntujust a bit weirdly worded17:01
zyga-ubuntuChipaca: and I'm on a clock17:01
zyga-ubuntuChipaca: this cannot be proposed yet but a spread test for this is here; https://github.com/zyga/snapd/commit/617739eee69faf483dee8cad3ae241a1c5b08b5717:02
* kalikiana calling it a day17:14
brunosferChipaca: Do you know how can I query directly the API locally?17:22
Chipacabrunosfer: it depends exactly what you mean by 'directly' and 'locally' :-)17:23
Chipacabrunosfer: from inside the snap?17:23
Chipacabrunosfer: or do you mean from a script?17:23
zyga-ubuntubrunosfer: talk to the same socket, if you have the right interface it can be done from the snap17:24
zyga-ubuntubrunosfer: if not you need to be unconfined (outside)17:24
zyga-ubuntubrunosfer: but should be enough to let you code17:24
brunosferright 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 =P17:26
=== JanC is now known as Guest37549
=== JanC_ is now known as JanC
zyga-ubuntubrunosfer: 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 team17:27
brunosferChipaca: And what do you mean by priviledged? --devmode?17:27
zyga-ubuntubrunosfer: some interfaces can be accessed instantly as they are considered safe17:28
zyga-ubuntubrunosfer: but with this interface you can equally remove and install snaps17:28
Chipacabrunosfer: i'm sorry if i'm not fully following what you need17:29
Chipacabrunosfer: curl -s --unix-socket /run/snapd.socket http://localhost/v2/snaps17:30
Chipacabrunosfer: ^ is that what you're asking?17:30
pedronismvo: test lxd seems to have failed here:  https://travis-ci.org/snapcore/snapd/builds/327212657?utm_source=github_status&utm_medium=notification17:31
brunosferChipaca: That's exactly what I was looking for! Perfect answer! Thank you so much for the command line. It works perfectly.17:38
brunosferChipaca: But for me to perform that command line do I need to have a special permission? Using it from my snap?17:38
Chipacabrunosfer: yes, the snap needs snapd-control to accss the socket17:39
brunosferChipaca: That's perfect. You helped me a lot ;)17:40
mvopedronis: hm, you restarted by now I guess? was it just a slow download? that happens sometimes unfortunately17:46
popeyflexiondotorg: https://bugs.launchpad.net/snapcraft/+bug/174250417:56
mupBug #1742504: magic.mgc, 1: Warning: offset `' invalid <Snapcraft:New> <https://launchpad.net/bugs/1742504>17:56
popeykyrofa: ^ New and interesting ways to break snapcraft17:57
kyrofaOh how fun!17:57
kyrofaOh dang17:57
kyrofapopey, and that didn't happen in 2.35?17:58
popeyflexiondotorg: just hit the same17:58
popeyhe's in an i386 vm, I'm on an i386 VPS17:58
kyrofapopey, you didn't read the changelog? Snapcraft does abstract art now. It's a feature17:58
popeyNice try!17:58
flexiondotorgI'm running snapcraft from the beta channel on a i386 VM.17:58
flexiondotorgSame issue.17:58
kyrofai386, huh?17:59
kyrofaHave either of you tried on amd64?17:59
flexiondotorgDoesn't happend of metal amd64.17:59
popeylemme switch my amd64 laptop to beta to reproduce18:00
popeygot it to do it and not screw fonts up18:01
popeyso i have a readable stacktrace now18:02
popeykyrofa: there you go, comment #218:03
kyrofapopey, any chance the snap you're building is public so I can poke at what's happening there?18:05
popeyI'll attach the yaml18:05
popeykyrofa: attached, and had the same issue on armhf and not amd6418:07
popeyYou're wecome! :D18:07
kyrofaThank you! We'll have a look18:07
Chipacasanta cachucha, so many special cases18:10
flexiondotorgLooks like elf patching is not working on 32-bit binaries.18:10
popeyLooks like we need more test cases on more architectures! :D18:13
ograor just drop support for some :P18:15
flexiondotorgYeah, armhf ;-)18:15
Chipacalet's drop armel and nubus-ppc18:17
kyrofapopey, flexiondotorg we have test cases on other arches, but they're adt18:19
lundmarso, the build.snapcraft.io is currently down?18:20
* zyga-ubuntu looks at slashdot story18:20
mupPR snapcraft#1810 closed: [WIP] i18n support <Created by m4sk1n> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1810>18:22
lundmarman, for some work loads the performance degradation of spectre/meltdown fix is quite a blow.18:22
cwaynezyga-ubuntu: that's fixed with -109 which is already out18:25
zyga-ubuntuyeah, I read that18:25
zyga-ubuntujust was caught by the headline18:25
roadmrzyga-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-ubuntulundmar: can you elaborate please? I'm curious18:25
roadmralso hi :)18:26
zyga-ubunturoadmr: yeah, it's just clickbait journalism18:26
sergiusenskyrofa popey if it is magic that is breaking I think I can fix that18:26
roadmrzyga-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 device18:26
lundmarzyga-ubuntu: some workloads seem to degrade by as much as ~30%18:26
kyrofasergiusens, yeah, seems so18:26
roadmrzyga-ubuntu: but anyway I'm just whining :)18:26
zyga-ubunturoadmr: hey, that's my spare time activity ;)18:27
sergiusenskyrofa might as well get rid of magic completely, that python module is a mess18:27
kyrofasergiusens, can we? It's always so hard to find documentation for it as well18:27
sergiusensI wish we could also get rid of python-apt, that would also be a blessing :-)18:27
sergiusenskyrofa yes, I will replace it with readelf, then it is also one call18:27
lundmarzyga-ubuntu: you might find this interesting: https://www.phoronix.com/scan.php?page=news_item&px=KPTI-Retpoline-Combined-Ubuntu18:28
lundmaranyone know what is going on with build.snapcraft.io - it seems to be down but https://status.snapcraft.io is all green?18:29
kyrofalundmar, yeah, the build farm is down pending mitigation for meltdown/specre18:30
kyrofanoise][, were you going to put something about that on status.snapcraft.io?18:30
lundmarthe status page should show red then :)18:30
kyrofaNo argument from me. I sent an email about this last week18: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 down18:32
lundmarit's been down for a while? I only just noticed.18:32
kyrofalundmar, about a week now18:33
lundmarhopefully it will be up again soon18:33
kyrofalundmar, https://twitter.com/launchpadstatus/status/94868823302988185618:33
kyrofaMy hope as well18:33
kyrofaMitigations started rolling last night, so I expect it to come back up any time18:33
noise][yes, hopefully all back over the next 2 days18:34
lundmarthis whole spectre thing is quite a big deal - amazing such a simple mechanism has gone unnoticed until now.18:34
kyrofanoise][, I kinda feel like something should be big and red, there18:34
kyrofabuild.snapcraft.io is a pretty decent thing that we should consider tracking there18:35
noise][for various reasons we don't have access to check the status of the actual build farm in that status dashboard18:35
noise][just that the store side and build.snapcraft.io website are up18:35
kyrofaEven just something that could be toggled by hand, seeing that we know the build farm is down would be handy18:36
noise][well that was the incident notice, which i will re-pin now18:36
kyrofanoise][, I doubt people will scroll down that far once they see everything is green18:37
kyrofaJust sayin18:37
lundmarI almst missed the pinned incident pop up notice.18:37
zyga-ubuntuI'm a bit exhausted, time to sleep18:51
zyga-ubuntuI'll wake up earlier tomorrow18:52
mupPR snapcraft#1862 opened: zip: support extracting non-unix zip files <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1862>19:04
kyrofasergiusens, that's for you ^^19:04
sergiusensactually for ogra ^ ;-)19:06
ograwell, i'm also just proxying19:07
sergiusensogra if you want to give the snap a spin, go to the travis build and search for the transfer.sh file upload ;-)19:07
ograit is for that mythical "customer" guy :)19:07
kyrofaYeah, like to keep those happy and non-mythical19:10
sergiusenskyrofa btw, was snapcraft#1639 supposed to be approved?19:14
mupPR snapcraft#1639: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639>19:14
kyrofasergiusens, I'm re-reviewing now. elopio and I didn't like the tests, but kalikiana's fix for that seemed to introduce weird test problems19:15
kyrofasergiusens, so the tests have been reverted19:15
kyrofaI'm kinda meh on the tests. I'd rather see real integration test snaps like we do for the other pieces of the grammar19:16
kyrofaBut in the interest of time they may be okay19:17
sergiusenskyrofa if they are not good, then they are not good.19:32
sergiusenskyrofa what about snapcraft#1857 ?19:33
mupPR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857>19:33
kyrofasergiusens, it's next on my queue19:33
kyrofaHad some testing questions there on the last pass19:34
kyrofaelopio, what are your thoughts on snapcraft#1639? Do you like that better than putting more snaps in tests/integration/snaps ?19:36
mupPR snapcraft#1639: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639>19:36
popeysergiusens: yay!20:00
kyrofasergiusens, while I'll pass snapcraft#1639 assuming elopio is okay with it, snapcraft#1857's tests aren't right yet20:29
mupPR snapcraft#1639: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639>20:29
mupPR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857>20:29
kyrofaShould be an easy change though, hopefully20:29
sergiusenskyrofa so now only snapcraft#1853 is left?20:56
mupPR snapcraft#1853: extractors: support appstream icon and desktop <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1853>20:56
elopiokyrofa: yes, I think we have too many snaps in tests/integration/snaps20:59
kyrofasergiusens, although we should consider snapcraft#1861 as well20:59
mupPR snapcraft#1861: extractors: also support appdata.xml appstream files <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1861>20:59
elopioI'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 fixture21:00
kyrofaelopio, sounds good21:01
sergiusenselopio kyrofa fwiw I am seriously considering removing the buffering and let tests print everything they need to21:41
kyrofasergiusens, we kinda tried that already, things slow waaay down21:42
sergiusenskyrofa not for unit, for integration21:42
sergiusensI don't like the current travis hack I had to do21:42
kyrofasergiusens, yeah, that's what I'm talking about. Let me find the PR...21:42
sergiusensoh, bummer :-/21:43
sergiusensok, for the past to months every other week we've had to stop and deal with something new with travis; let's consider some alternatives21:43
kyrofasergiusens, 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/159121:44
mupPR snapcraft#1591: snapd integration tests: print stdout/stderr <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1591>21:44
kyrofasergiusens, that's just a subset of the integration tests, but you get the idea21:44
kyrofaI wonder how hard it would be to port to circle CI. They seem to innovate faster, and have longer runtimes21:46
kyrofaOh wait, no-- you only get one instance. Nevermind21:46
kyrofaThat'll slow things down21:46
sergiusenskyrofa so, instead of printing to stdout/stderr we opted to just skip the test? :-/21:47
sergiusenskyrofa we are at a point where if we do not print we need to skip all the tests21:47
kyrofaIt wasn't an "instead" so much as a "well, that didn't actually help us solve the problem"21:48
kyrofaWe 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 suite21:48
kyrofaBut I agree that printing would be useful as long as we didn't suffer too much of a slowdown21:49
mupPR snapcraft#1639 closed: grammar: to statement <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1639>21:53
mupPR 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
sergiusenselopio you now have conflicts22:04
sergiusenskyrofa we should print a `.` for every line of progress or something like that22:05
sergiusenskyrofa I still think we need to migrate away from travis, the free tier isn't cutting it22:05
kyrofasergiusens, then I only see two options: non-free tier, or self-hosting22:06
kyrofa(which is also non-free)22:06
sergiusenskyrofa yeah we will probably go back to adt22:06
kyrofaelopio, one more comment on snapcraft#1853, but I suspect it's good22:16
mupPR snapcraft#1853: extractors: support appstream icon and desktop <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1853>22:16
elopiokyrofa: so are you OK with every get to return Union[str, List[str]]?22:21
elopioIt's easy to change, just want to double check I got your comment22:22
kyrofaelopio, seems better than Any22:26
kyrofaelopio, 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
popeykyrofa: 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
popeykyrofa: seems not :(22:44
popeyAny plan to add it, so we don't have to add if elif elif elif else fi nonsense?22:44
kyrofapopey, SNAPCRAFT_ARCH_TRIPLET, and only in 2.36 and later22:44
popeyin environment?22:45
popeye.g. if I have an environment setup for a command, will snapcraft fill it in at build time?22:45
kyrofapopey, I'm not 100% sure what you're asking, but it's like SNAPCRAFT_PART_INSTALL if you've used that22:46
kyrofaIt is an environment variable22:46
popeybut it's an environment varibale at snapcraft runtime, not snap runtime22:46
popeyso 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
kyrofapopey, ahh, right, I see where you're coming from now22:49
kyrofapopey, no, that won't work22:49
popeyI end up needing 3 yamls, one per arch22:50
kyrofapopey, I really wish snapd would add that, but I added a remote part for it if you want to use that instead22:50
popeyyeah, i found that :)22:50
kyrofaTHAT will give you SNAP_ARCH_TRIPLET22:50
kyrofapopey, and it literally just does the elif elif elif vi nonsense for you :P22:51
kyrofaHuh. I type that command too much22:52
kyrofaSo 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 part22:53
popeyThis feels like it needs a bug22:53
popeyhaving a bunch of shell script attached to a hundred snaps makes no sense22:54
kyrofaI could have sworn we had one against snapd at some point, but I suspect it was lost between snappy/snapd/etc.22:54
kyrofaI agree22:54
* popey files22:54
kyrofapopey, sorry I got your hopes up. I pictured your childish joy at learning this was possible only to have crushed it22:56
kyrofaer, childlike is probably what I wanted there22:56
mupBug #1742565: snapd should provide SNAP_ARCH_TRIPLET <snapd:New> <https://launchpad.net/bugs/1742565>22:58
popeykyrofa: snapcraft really craps the bed if you switch from beta to stable23:20
popeyi.e. from 2.38 back to 2.3523:20
kyrofapopey, because of the state tracking?23:20
kyrofaYeah, that was written well before snaps were a possibility. We should start accounting for that23:21
kyrofaHandle it well, say 'hey yo, I don't recognize this state stuff at all. Clean, man."23:21
popeyi have no idea what to do at this point ^23:22
kyrofapopey, wait, that's different23:22
kyrofapopey, are you on i386 again?23:22
popeyyes, same on armhf23:22
kyrofastable channel?23:22
popeyi reverted back from beta to stable to rebuild something and avoid the magic bug from earlier23:23
kyrofapopey, https://bugs.launchpad.net/snapcraft/+bug/173392223:23
mupBug #1733922: “snapcraft init” crashes on 32-bit Ubuntu <Snapcraft:Fix Released by kyrofa> <https://launchpad.net/bugs/1733922>23:23
kyrofapopey, the fix is in 2.36, I'm afraid23:23
kyrofaThat never made it to stable23:24
popeyso 2.35 is broken, 2.36 is fixed (but never released) and 2.38 (released) is broken.23:24
popeyWhich version should I use? :)23:24
kyrofapopey, hold on, let me give you 2.3623:24
popeyi wonder if I can refresh --revision?23:25
kyrofapopey, you're not a collaborator. But you don't need to be, I'll make a hotfix channel for ya23:25
popeyoh, i dont think you need to be a collaborator to --revision ninja23:25
popeyI did this earlier with another snap ;)23:25
kyrofaHmm, okay. I thought that was the idea, anyway23:26
kyrofapopey, you're on armhf? Try rev 87823:26
kyrofapopey, let me know if it doesn't work and I'll create a hotfix23:27
popeyit wont let me23:27
kyrofaOh good, I'm not insane23:27
popeyi think the deb works23:27
popey(I used the deb earlier successfully, but only moved to snap to test some of these environment variables)23:27
kyrofaIndeed, the deb should work for that bug anyway23:28
popeyok, lemme test that23:28
kyrofapopey, feel free to use the edge/2-36 channel as well, if you like23:33
popeythey're all building now23:33
kyrofapopey, edge/2-37 is open as well, if you find you need it23:35
popeyyou're a star23:35
kyrofaRemember they only live for a month, but easy to re-create if necessary23:35
popeyI'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!