[06:00] <mborzecki> morning
[06:44] <mwhudson> (answer: snapd in the core snap is newer than snapd in bioinic today)
[07:08] <zyga-ubuntu> good morning
[07:09] <zyga-ubuntu> mwhudson: can you give me the denial please
[07:09] <zyga-ubuntu> mwhudson: grep for DENIED in dmesg
[07:09] <mborzecki> zyga-ubuntu: mornings
[07:09] <mwhudson> zyga-ubuntu: i think it's the more or less known thing about apparmor and overlayfs not being friends
[07:10] <zyga-ubuntu> mwhudson: ah, so it's still the version witohut overrlay support?
[07:10] <zyga-ubuntu> mwhudson: can you pastebin /var/lib/snapd/system-key
[07:10] <mwhudson> zyga-ubuntu: i'm going to wait for 2.32 until i get bothersome about it
[07:10] <mwhudson> zyga-ubuntu: don't have a vm up know
[07:10] <zyga-ubuntu> that's ok
[07:10] <zyga-ubuntu> I thought that patch was out already
[07:11] <mwhudson> zyga-ubuntu: i think xenial is on 2.23.1 or something
[07:12] <mwhudson> hm that's what xenial-proposed has anyway
[07:12] <mwhudson> so does the stable core snap have snapd from xenial-proposed in it?
[07:12] <mwhudson> that seems surprising
[07:12]  * zyga-ubuntu doesn't know
[07:12] <zyga-ubuntu> I was a little detached yesterday
[07:30] <mup> PR snapd#4844 opened: overlord/snapstate: allow core defaults configuration via 'system' key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4844>
[07:36] <pstolowski> mornings
[07:37] <mborzecki> pstolowski: hey
[07:38] <mborzecki> pstolowski: can you take a look at #4826?
[07:38] <mup> PR #4826: wrappers: services which are socket or timer activated should not be started during boot <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4826>
[07:53] <pstolowski> mborzecki: yep
[07:59] <kalikiana> moin moin
[08:15] <mborzecki> pstolowski: thanks for the review
[08:16] <pstolowski> np
[08:18] <mup> PR snapd#4826 closed: wrappers: services which are socket or timer activated should not be started during boot <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4826>
[08:37] <mup> PR snapd#4845 opened: snap, store: store version numbers in the commands database <Created by mvo5> <https://github.com/snapcore/snapd/pull/4845>
[08:38] <mvo> mborzecki: could you please create a 2.32 version of 4826 (if there isn't one already)?
[08:39] <mborzecki> mvo: coming up
[08:39] <mvo> ta
[08:49] <mup> PR snapd#4846 opened: [2.32] wrappers: services which are socket or timer activated should not be started during boot <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4846>
[08:50] <mborzecki> mvo: ^^
[08:53] <mvo> mborzecki: ta
[08:53] <Chipaca> *yawn*
[08:53] <Chipaca> just five more minutes
[08:58] <pedronis> hello
[08:59] <Chipaca> pedronis: hi
[08:59] <pedronis> Chipaca: hi,  I need to update a PR after let me know when you want to chat about puritan
[09:00] <Chipaca> pedronis: knee-deep in the hash cache mash atm
[09:00] <pedronis> Chipaca: I saw you discussing that,    did you notice that some of those helpers are used when there's no state
[09:01] <pedronis> StateCache need to be optional
[09:01] <Chipaca> pedronis: yes I did
[09:01] <pedronis> I mean snapasserts exist to hold stuff at the intersection of  snap files and assertions (but not needing state)
[09:02] <pedronis> or at least not requiring state
[09:02]  * Chipaca nods
[09:04] <pedronis> Chipaca: are you looking  also into the download case? I though the idea was to fix firstboot first
[09:04] <pedronis> store has its own ways to keep state at distance
[09:04] <Chipaca> pedronis: firstboot first, but with my eye on download to make the followup easy (or trivial)
[09:05] <pedronis> easier sounds fair, trivial unlikely
[09:05] <Chipaca> it's all a bit messy though
[09:05] <Chipaca> pedronis: did you see the thing about the extra extra hashing during download delta?
[09:05] <pedronis> yes, I was aware of that
[09:05] <pedronis> we also check the hash of the delta itself
[09:06] <Chipaca> i guess i'd forgotten :-)
[09:06] <Chipaca> that's fine
[09:06] <pedronis> seems a bit orthogonal
[09:06] <pedronis> except that we should have picked a different hash for those
[09:06] <Chipaca> anyhoo, that's  what i'm in
[09:06] <pedronis> no sense being super expensive
[09:06] <pedronis> given that we need to recheck the whole thing anyhow
[09:06] <pedronis> but it's as it is
[09:07] <Chipaca> pedronis: we can fix that though :-)
[09:07] <pedronis> yes, it's fixable
[09:07] <Chipaca> not today
[09:07] <Chipaca> also, store is a mess, and daemon is a mess
[09:07] <Chipaca> ¯\_(ツ)_/¯
[09:07] <pedronis> store was worse
[09:07] <Chipaca> oh, totally
[09:07] <Chipaca> baby steps
[09:07] <pedronis> it's improving (slowly)
[09:08] <pedronis> daemon, no, I don't think we rearchitected much of it yet
[09:08] <pedronis> let me know if I can help, also happy to review
[09:09]  * pedronis back to his high prio stuff
[09:09] <mup> PR snapd#4847 opened: osutil: add symlinkat(2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4847>
[09:20] <pedronis> grumble, the PR that had a consistently failing spread test now passed once I added a some debug stanza :/ I'm quite sure there is something fragile after the change but who knows now
[09:23] <Chipaca> pedronis: i'm feeling rather dumb here, but I can't figure out where the second hashing in firstboot is happening
[09:24] <Chipaca> pedronis: derive side info does one, but the second one...?
[09:24] <mborzecki> it'd be so nice if i didn't have to fire up a vm with fedora/suse just to check what `rpm -E %configure` expands to
[09:24] <pedronis> Chipaca: verify-snap
[09:24] <Chipaca> pedronis: that's not run for firstboot
[09:24] <pedronis> ?
[09:24] <Chipaca> pedronis: firstboot does InstallPath
[09:24] <Chipaca> pedronis: which means the snap is local, so gets no validate-snap task
[09:25] <pedronis> really
[09:25] <pedronis> I'm confused
[09:25] <Chipaca> that's how i read it, but see: dumb
[09:25] <pedronis> I thought we always did that
[09:25] <pedronis> if we don't there is nothing to fix
[09:25] <pedronis> but might be problematic for other reasons
[09:25]  * Chipaca takes the rest of the day off
[09:25] <Chipaca> :-)
[09:26] <pedronis> that's a recent chnage
[09:27] <Chipaca> pedronis: 2016
[09:27] <pedronis> nothing to do afaict
[09:28] <pedronis> now I'll discover it's by me
[09:28] <mup> PR snapd#4846 closed: [2.32] wrappers: services which are socket or timer activated should not be started during boot <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4846>
[09:29] <Chipaca> pedronis: you'd only discover that if you went looking
[09:30] <Chipaca> pedronis: I say don't
[09:30] <pedronis> it's by me
[09:30] <pedronis> so we never did double hashing
[09:30] <Chipaca> so the symlink fix should make all the difference we can make
[09:31] <pedronis> I mean at firstboot
[09:31]  * Chipaca too
[09:32] <pedronis> mmh
[09:32] <pedronis> yes, avoiding the copy is as good as it gets
[09:33] <pedronis> unless we go back to the cheating script
[09:33] <pedronis> same also for core btw
[09:33] <Chipaca> pedronis: well, core links
[09:33] <Chipaca> pedronis: the symlink only happens if the link fails
[09:33] <pedronis> yea, there's not win to be had on core
[09:33] <Chipaca> ah. yeah.
[09:34] <Chipaca> but
[09:34] <Chipaca> i do feel that if we had a central place to do hashing this would've not taken so long to figure out
[09:34] <Chipaca> but, not work for today
[09:35] <pedronis> not sure how we can achieve that
[09:35] <pedronis> unless you mean one codeline, not conceptually
[09:35] <Chipaca> magic ヽ(｀Д´)⊃━☆ﾟ. * ･ ｡ﾟ,
[09:36] <Chipaca> wishful thinking mostly
[09:36] <pedronis> we would need unify DeriveSideInfo and doValidateSnap, seems worthwhile but not sure how to attack that
[09:37] <pedronis> it's probably possible, bit of a code pretzel though
[09:37]  * Chipaca nods
[09:37] <Chipaca> meanwhile I'll do the cheap thing and skip the extra hash in download after successful applyDelta
[09:37] <Chipaca> then that'll stop bugging me
[09:39] <Chipaca> pedronis: can we talk about puritan in ~2h
[09:40] <pedronis> yes
[09:46] <zyga-ubuntu> mborzecki: can you please look at 4847 again
[09:46] <zyga-ubuntu> I added one more syscall
[09:56] <mvo> mborzecki: go vet is fully happy now again on 1.10, right?
[09:57] <mborzecki> mvo: yes, it's passing
[09:57] <mborzecki> mvo: cachio's bionic PR failed in InstallDate() unit test, probably outdated mksquashfs with the bug that you fixed
[10:00] <ackk> sergiusens, mvo I see that https://github.com/snapcore/snapcraft/commit/10509d590658f1c417b91d66a356700483997d75 has landed now, is there any plan to rename base-18 to core18 soon?
[10:08] <mvo> mborzecki: yeah, the issue here is that squashfs has not transitioned to bionic yet iirc the autopkgtest for lxd failed
[10:08] <mvo> ackk: yes, we want to rename it soon, right now a snapcraft issue prevents us from building, this will get fixed this week, then we will do the rename (once we can build again)
[10:09] <ackk> mvo, ah, cool, thanks
[10:10] <pedronis> pstolowski: hi, I think I still owe you a bunch of reviews, I will try to have a reviews day tomorrow
[10:12] <pstolowski> pedronis: hi! no worries, and thanks in advance! I think you can focus on #4358 for now and ignore the rest
[10:12] <mup> PR #4358: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358>
[10:12] <pstolowski> as they are stacked on top of 4358
[10:15] <mup> PR snapd#4848 opened: many: cherry-pick relevent `go vet` 1.10 fixes to 2.32 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4848>
[10:18] <Chipaca> mvo: you'll also want to cherry pick 19a1dc929b89bf8dd5d6ad22bb36942b5a2508c4
[10:19] <mup> PR snapcraft#1994 closed: docker: add the architecture <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1994>
[10:19] <Chipaca> mvo: for bubonic i mean
[10:19] <Chipaca> bah, for bubonic to pass
[10:19] <Chipaca> bionic*
[10:20] <mvo> Chipaca: thank you
[10:20] <Chipaca> there's a go 1.10's behaviour change that breaks our tests (explained in that commit)
[10:20] <mborzecki> Chipaca: bubonic ;)
[10:21] <mvo> Chipaca: its not in master yet, is it?
[10:21] <Chipaca> mvo: no
[10:21] <mborzecki> hope it's not about the plague
[10:21] <mvo> Chipaca, mborzecki lol
[10:21] <Chipaca> mvo: it's pushed to #4835
[10:21] <mup> PR #4835: tests: add bionic system to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4835>
[10:22] <Chipaca> but that fails to be green because the google archive mirror doesn't have the new bionic squashfstools
[10:22] <mvo> Chipaca: we need to enable bionic-proposed there
[10:22] <mvo> Chipaca: but I can cherry-pick into my 2.32 pr
[10:22]  * Chipaca nods
[10:22] <Chipaca> this is why i mention it :-)
[10:22] <mvo> ta
[10:24] <mborzecki> Chipaca: can you take a look at #4841?
[10:24] <mup> PR #4841: snap/pack, cmd/snap: add `snap pack --check-skeleton` <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4841>
[10:25] <mvo> hey stgraber ! the autopkgtests for squashfs-tools fail in the lxd testing right now (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#squashfs-tools), is there a know issue with autopkgtest and lxd? the failures do not look related to the squashfs change
[10:25] <Chipaca> mborzecki: I can do 4831, and 4861, but not 4841 sorry
[10:26]  * Chipaca lies
[10:27] <mborzecki> at least 4861 gives the nice tatooine-ish 404 :P
[10:28] <mup> PR snapcraft#1996 closed: tests: add SNAPCRAFT_KEEP_DATA to debug <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1996>
[10:28] <cachio> mvo, the problem of enabling bionic-proposed is that I need to doit suring the prepare, is it ok?
[10:29] <pedronis> #4829 and #4849 also needs reviews
[10:29] <mup> PR #4829: store: Sections and WriteCatalogs need to strictly send device auth only if the device has a custom store <Created by pedronis> <https://github.com/snapcore/snapd/pull/4829>
[10:29] <mup> PR #4849: many: propagate contexts enough to be able to mark store operations done from the Ensure loop <Created by pedronis> <https://github.com/snapcore/snapd/pull/4849>
[10:29] <mup> PR snapd#4849 opened: many: propagate contexts enough to be able to mark store operations done from the Ensure loop <Created by pedronis> <https://github.com/snapcore/snapd/pull/4849>
[10:30] <cachio> mvo, it will be temporal until is it enabled by default
[10:32] <mvo> cachio: yeah, I think thats ok
[10:34] <Chipaca> mvo: how would you feel about sliding 4834 into .32?
[10:34] <Chipaca> #4834
[10:34] <mup> PR #4834: snap/squashfs: when installing from seed, try symlink before cp <Created by chipaca> <https://github.com/snapcore/snapd/pull/4834>
[10:35] <mup> PR snapd#4834 closed: snap/squashfs: when installing from seed, try symlink before cp <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4834>
[10:36] <mvo> Chipaca: let me look
[10:36] <ondra> zyga-ubuntu ping
[10:36] <mvo> Chipaca: absolutely
[10:36] <Chipaca> mvo: cd7a41b921446bff4ad02ceacf1811c1a6319cc7 fwiw
[10:36] <mvo> Chipaca: I cherry-pick
[10:37] <zyga-ubuntu> Hey ondra
[10:37] <ondra> zyga-ubuntu hey, I have asked this before, but when using layouts, what was the process to read original file?
[10:38] <mvo> Chipaca: ta
[10:41] <zyga-ubuntu> ondra: you can attempt to use hostfs
[10:43] <ondra> zyga-ubuntu any how to do that?
[10:48] <pedronis> Chipaca: having early lunch, we can chat in ~40 ?
[10:49] <Chipaca> pedronis: sure
[10:50] <zyga-ubuntu> ondra: re, sorry, I was afk
[10:50] <zyga-ubuntu> ondra: so, you can look at the file in /var/lib/snapd/hostfs/$F
[10:50] <zyga-ubuntu> ondra: but you will need an interface for t hat
[10:50] <mup> PR snapd#4850 opened: many: fix shellcheck warnings in bionic <Created by mvo5> <https://github.com/snapcore/snapd/pull/4850>
[10:51] <ondra> zyga-ubuntu which interface is that?
[10:51] <zyga-ubuntu> none exists now
[10:51] <Chipaca> mvo: the spellcheck check is also broken in xenial, fwiw, we just don't run it
[10:51] <zyga-ubuntu> it would depend on $F for sure
[10:51] <ondra> zyga-ubuntu :)
[10:51] <zyga-ubuntu> as otherwise it would let  you read any file
[10:51] <ondra> zyga-ubuntu right
[10:52] <mvo> Chipaca: spellcheck or shellcheck? I don't mind so much about the spellcheck, we might as well disable it and only run it via a nightly job
[10:52] <Chipaca> shellcheck
[10:52] <Chipaca> ah
[10:52] <Chipaca> sorry
[10:52] <Chipaca> :-)
[10:52] <mvo> oh, ok
[10:52] <zyga-ubuntu> sheepcheck
[10:52]  * Chipaca shellchecks his spellchecker
[10:52] <mvo> shellshock
[10:52] <ondra> zyga-ubuntu wouldn't be easier to allow hook to run before bind mount, and then we can rely on existing permissions?
[10:52] <Chipaca> ah wait, yes, shellcheck, we're talking of the same thing
[10:52] <zyga-ubuntu> ondra: no, it's not easy in any way
[10:53] <ondra> zyga-ubuntu right
[10:53] <zyga-ubuntu> ondra: and it would still need an interface
[10:53] <Chipaca> mvo: shellcheck does not run as part of tests; it's not installed on the images
[10:53] <zyga-ubuntu> ondra: as this way you could read abritrary files
[10:53] <zyga-ubuntu> ondra: our current design assumes that applications cannot observe pre-layout filesystem at any stage
[10:53] <zyga-ubuntu> so no partial state is expsed
[10:53] <ondra> zyga-ubuntu ok, so hostfs it is then
[10:53] <zyga-ubuntu> as our apparmor profile assumes the layout is in place
[10:53] <zyga-ubuntu> and grants permissions to the places affected by the layout
[10:53] <ondra> zyga-ubuntu ah, OK that makes sense
[10:54] <mborzecki> zyga-ubuntu: regarding #4571 we could move configure.ac/autogen.sh to the top of snapd tree
[10:54] <mup> PR #4571: data, cmd, packaging: use autotools to generate artifacts under data <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4571>
[10:54] <zyga-ubuntu> ondra: my advice is to open a thread to request an interface for reading hostfs file (specific file) so that we can grant this
[10:54] <zyga-ubuntu> mvo: what do you think about mborzecki's proposal?
[10:54] <zyga-ubuntu> I'm okay but we had a discussion with that and this is how we ended up with "autotools is hidden in cmd/"
[10:55] <ondra> zyga-ubuntu OK will do
[11:00] <cachio> zyga-ubuntu, that should be fixed? https://travis-ci.org/snapcore/snapd/builds/353519499#L5247
[11:00] <cachio> zyga-ubuntu, or it is still in progress
[11:00] <zyga-ubuntu> cachio: no, not yet. I'm working on that now
[11:01] <cachio> zyga-ubuntu, ah, ok, thanks
[11:04] <mvo> zyga-ubuntu: I think to think but to me autotools is just something I dislike whereever it lifes
[11:04] <mvo> zyga-ubuntu: I mean "I need to think"
[11:04] <zyga-ubuntu> mvo: any ideas as to what to do then?
[11:04] <zyga-ubuntu> should we move away from autotools
[11:04] <zyga-ubuntu> or just use it consistently
[11:06] <mvo> zyga-ubuntu: sorry, I know my comment was not helpful. but yeah, either consistently or switch but switching must be worth it, mesons seems to be popular but I'm not sure its sufficiently better
[11:07] <mvo> (to justify the cost)
[11:08] <mborzecki> mvo: xenial version of meson is outdated, and afaik it's not available in trusty at all
[11:11] <ondra> zyga-ubuntu mvo any idea what could be causing "run hook "post-refresh": execv failed: No such file or directory"
[11:11] <zyga-ubuntu> hmmm,
[11:12] <zyga-ubuntu> ondra: what does the hook look like?
[11:12] <ondra> zyga-ubuntu https://pastebin.ubuntu.com/p/w22S3q9Y2D/
[11:12] <ondra> zyga-ubuntu :)
[11:13] <ondra> zyga-ubuntu I trimmed it down, as I can't figure out what is the problem
[11:13] <zyga-ubuntu> so you refresh a snap and the hook fails to run?
[11:13] <zyga-ubuntu> is it reproducible?
[11:14] <ondra> zyga-ubuntu I have install hook which runs just fine I did sym link as I usually do and it failed to run
[11:14] <ondra> zyga-ubuntu install works
[11:14] <zyga-ubuntu> symlink?
[11:14] <ondra> zyga-ubuntu happening all the time
[11:14] <ondra> zyga-ubuntu that was before
[11:14] <zyga-ubuntu> pstolowski: ^ wanna look?
[11:14] <ondra> zyga-ubuntu so I replaced sym link with file, and still same
[11:16] <pstolowski> ondra: can you share that snap?
[11:16] <ondra> pstolowski yeah preparing to share it
[11:22] <ondra> pstolowski zyga-ubuntu damn, I did clean build and now it works, and I did same before
[11:22] <zyga-ubuntu> do you have the old snap?
[11:22] <ondra> so can't reproduce it now
[11:22] <zyga-ubuntu> maybe look inside
[11:23] <ondra> zyga-ubuntu so I was using snap try
[11:23] <ondra> zyga-ubuntu and without rebuild I was modifying prime/meta/hook
[11:25] <mup> PR snapd#4848 closed: many: cherry-pick relevent `go vet` 1.10 fixes to 2.32 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4848>
[11:30] <pedronis> Chipaca: I'm back
[11:31] <Chipaca> pedronis: wb :)
[11:31] <Chipaca> pedronis: so, if I understand your point of view, using puritan for everything stringish isn't a sustainable practice
[11:31] <ondra> zyga-ubuntu pstolowski http://people.canonical.com/~okubik/git_2.7.4_amd64.snap
[11:32] <ondra> zyga-ubuntu so I'm using snap try, so unsquash it first
[11:32] <pedronis> Chipaca: indeed
[11:32] <pstolowski> ondra: could this be a missing -x on the hook script?
[11:32] <ondra> zyga-ubuntu pstolowski so now I have different problem, it will install, but if I try to run I get execv failed: No such file or directory
[11:32] <Chipaca> pedronis: OTOH my point of view is that unless we do something for every stringish thinig, we're going to eventually miss one we shouldn't
[11:33] <ondra> zyga-ubuntu pstolowski do $ snap try <>; it will run, call $ snap try <> on same directory and it will break
[11:33] <Chipaca> pedronis: would you be happier with using a lot more types, for example?
[11:33] <pedronis> Chipaca: no in general
[11:34] <pedronis> Chipaca: we need  tooling and a way to mark things
[11:34] <pedronis> Chipaca: I find needing a special type for snap-id very suspect
[11:34] <pedronis> it feels very cargo cultish
[11:34] <Chipaca> pedronis: when you say tooling, do you mean a static checker, or do you mean a json decoder replacement?
[11:34] <pedronis> whatever works
[11:34] <pstolowski> ondra: what core are you running with?
[11:35] <pedronis> Chipaca: atm we are just making a bit of code uglier without clear path forward
[11:35] <ondra> pstolowski 16-2.31.2+git610.7a79b84 (4243)
[11:36] <Chipaca> pedronis: what would you do?
[11:36] <pedronis> Chipaca: also whatevedr is problematic with the store is likely problematic with snap.yaml
[11:36] <pedronis> as well
[11:36] <pedronis> Chipaca: I don't know, I'm not even sure I agree with your premise
[11:36] <pedronis> that we really need to worry about everything
[11:37] <pedronis> but if we do need to worry about everything the current approach alone doesn't cut it
[11:38] <Chipaca> pedronis: because of the lack of a static checker?
[11:38] <pstolowski> ondra: ok, same core here. I un-suqashed it, did snap try twice, it worked. can you do 'snap changes' to find changes correspondin to your snap-try commands, and then 'snap change <ID of the change>' for both to see more info about the failure?
[11:38] <pedronis> Chipaca: it seems we need to mark all structs with json or yaml tags as either risky or not and then decide what to do with each
[11:39] <mborzecki> zyga-ubuntu: mvo: tried having just cmd/configure.ac and doing AC_CONFIG_FILES([../data/Makefile ..]) but that doesn't work, the resulting makefiles do some silly thing and try to cd one level above snapd checkout
[11:39] <pedronis> though sometimes we use map[string]interface{} directly, maybe not on input
[11:39] <pedronis> not sure
[11:40] <zyga-ubuntu> mborzecki: thank you for confirming that
[11:41] <mborzecki> zyga-ubuntu: mvo: just moving configure.ac and autogen.sh to the top level dir (plus adjusting paths) is enough, it will clutter the directory once you autoreconf but at least both cmd and data are built using autohell
[11:41] <zyga-ubuntu> mborzecki: yeah,
[11:41] <zyga-ubuntu> you have my +1 but convince gustavo as he was opposing it before
[11:42] <Chipaca> pedronis: that's a mountain of work, but it does seem the logical conclusion
[11:42] <mborzecki> zyga-ubuntu: we could easily say with the hack that's right now in the PR :P works too, and does not clutter the directory
[11:42] <pedronis> Chipaca: well, the non logical solution is say we need to care about everything but then leaving it up to reviewers
[11:43] <mborzecki> Chipaca: could we do a silly hack with reflection and field tags perhaps?
[11:44] <ondra> pstolowski https://paste.ubuntu.com/p/7J8yPTrmBG/
[11:44]  * cachio afk
[11:45] <mborzecki> Chipaca: then have an unmarshaller that wraps json and goes to inspect all the strings to clean them up, unless there's a tag that says to leave the string as it is
[11:45] <mborzecki> pedronis: ^^
[11:45] <pedronis> there are probably a few possible approaches
[11:46] <pedronis> there are also concerns about runtime speed
[11:46] <pedronis> also personally don't think we should write a full new json decoder
[11:48] <mborzecki> agreed, i'm not propsing to write a json decoder, just sanitize the structs when they come out of the decoder somehow, in a separate call perhaps
[11:48] <ondra> pstolowski here you have whole test https://paste.ubuntu.com/p/2q7PH8cqk4/
[11:48] <ondra> pstolowski from snap remove
[11:49] <pedronis> Chipaca: now we also need to understand what everything means,  I suppose you mean that for example store generated error messages are also a concern?
[11:49] <ondra> pstolowski exactly same error I was getting before about configure hook
[11:49] <pedronis> Chipaca: I mean is our attacker a user of the store, or the store?
[11:49] <ondra> pstolowski need to run for lunch, but will be available later
[11:50] <pedronis> (there are blurry lines there but it still make a difference where to spend our energy)
[11:50] <Chipaca> pedronis: if it's the store itself i think things fall apart
[11:51] <Chipaca> pedronis: but, the problem is bugs
[11:51] <pedronis> I understand
[11:51] <pedronis> but there are all sorts of bugs
[11:51] <Chipaca> pedronis: I mean, #1750527 is the bug
[11:51] <mup> Bug #1750527: dashboard does not validate text fields <review-tools:Triaged by jdstrand> <Snapcraft:New> <snapd:In Progress by chipaca> <Snap Store:Fix Released by matiasb> <https://launchpad.net/bugs/1750527>
[11:52] <Chipaca> pedronis: even with that change, it's not clear to me everything textish from the store is validated
[11:52] <pedronis> Chipaca: I'm not arguing for doing nothing, but I'm also not happy to do something cargo cultish and unbounded
[11:53] <Chipaca> pedronis: I understand, but if the alternative to cargo culting something is having to make a decision about every single field, cargo culting starts to look good
[11:53] <pedronis> Chipaca: you are saying we should use the store data without knowing what it is / what it is about
[11:54] <Chipaca> pedronis: "is this something that can be edited by third parties, and is it going to be shown to the user" seemed to be the question
[11:54] <Chipaca> the first half we can probably answer easily
[11:55] <pedronis> Chipaca: and snap-id is dubious?
[11:55] <pedronis> anyway  at this point as I said even if we continue to use string for some things
[11:55] <pedronis> as I said we need to worry about all the json and all the yaml
[11:55] <Chipaca> I don't think snap-id is dubious, no
[11:55] <pedronis> but you made a puritan.SimpleString
[11:56] <Chipaca> but if you make everything not be a string, you can write a really silly static checker
[11:56] <Chipaca> the alternative is tagging, which isn't hard (but I hadn't thought of it in this context)
[11:56] <pedronis> I'm skeptical of that
[11:57] <pedronis> (the silly part)
[11:58] <Chipaca> pedronis: it'd be only a little more work than the check in daemon for commands
[11:58] <pedronis> ?
[11:58] <pedronis> we define local types sometimes to parse json
[11:59] <Chipaca> ok
[11:59] <Chipaca> pedronis: so what do we do
[12:00] <pedronis> it seems like we need to introduce safejson and safeyaml,   and not use json and yaml, as thin wrappers and go from there
[12:01] <pedronis> with a silly check that we don't use the other diretly in non-tests
[12:01] <Chipaca> pedronis: what are safejson and safeyaml?
[12:01] <pedronis> Chipaca: packages with a subset of what is offered by json and yaml
[12:02] <pedronis> we can probably then make them have different behavior at test time vs runtime
[12:02] <pedronis> and at test time they could check the rules that we make for target types
[12:05] <pedronis> Chipaca: it seems the only approach to make sure we cover all the ground  (I'm a bit worried about the messiness of dealing with our various uses of json statically)
[12:05] <pedronis> though yaml is probably worse, all of it comes from the user
[12:05] <pedronis> by definition
[12:06] <pedronis> if we don't trust snapcraft
[12:06] <pedronis> otoh we have validation there
[12:06] <pedronis> Chipaca: are you saying that we should do validation for snap.yaml but not trust any string from the store?
[12:07] <pedronis> it seems asymmetric, but maybe there's a good reason
[12:07] <Chipaca> pedronis: aborting a 'snap find' because one of the results had a bogus entry seemed a poor choice
[12:07] <Chipaca> pedronis: aborting a 'snap install' because of the same seems fine
[12:08] <pedronis> yea, but validation doesn't check all the fields at the moment
[12:08] <pedronis> does it?
[12:08] <Chipaca> it does not
[12:08] <pedronis> we might print a non-validated field
[12:08] <pedronis> (for reasons)
[12:08] <Chipaca> yes
[12:08] <Chipaca> but it'd be fairly straightforward to fix that
[12:08] <pedronis> Chipaca: I fear you opened a can of worms
[12:09] <Chipaca> pedronis: it was already open :-) i might've kicked it a little
[12:10] <pedronis> Chipaca: anyway  you mighe decide to go validation only for snap.yaml (but we have also other yaml files, like gadget yaml)
[12:10] <pedronis> but we still need a scalable solution for all the json from the store
[12:11] <Chipaca> pedronis: (just to keep things interesting, what should it do if the snap yaml ini the json fromo the store is invalid? :) )
[12:12] <pedronis> are we not validating it?
[12:12] <Chipaca> pedronis: the one in details? probably not
[12:12] <pedronis> anyway it's a corner case that shows cargo culting with naive types is not great
[12:12] <pedronis> false security effect
[12:13] <pedronis> anyway I think we validate it
[12:13] <pedronis> and if it's invalid we ignore it
[12:13] <pedronis> or maybe not
[12:13] <pedronis> let me check
[12:14] <pstolowski> ondra, ah wait, the execv error comes from running the app, it's not hooks
[12:15] <pedronis> Chipaca: no, it's not validated atm
[12:15] <pedronis> just parsed
[12:15] <pedronis> we ignore it on "parse" errors but not validation (that we don't do)
[12:16] <pstolowski> ondra: but ok, i can reproduce what you pasted, investigating
[12:18] <pedronis> Chipaca: so what I would do is have a way to enforce needing to tag all json fields as either  "user" or something else, all user fields need one of the special dedicated types
[12:19] <pedronis> (for values of all)
[12:21] <pedronis> Chipaca: still would need  a plan about how to make sure we validate all snap.yaml fields
[12:22] <Chipaca> pedronis: would something like puritan still be useful in this context?
[12:22] <pedronis> Chipaca: yes,   as I said we would String and Paragrah
[12:22] <pedronis> for some of the user fields
[12:22] <Chipaca> pedronis: and in particular, if I just used puritan for the known-problematic fields today would that be a reasonable zeroth step
[12:23] <pedronis> Chipaca: yes,  starting with just a few fields  would an accetable first step
[12:23] <pedronis> we probably don't need or shouldn't need SimpleString though
[12:23] <pedronis> for that step
[12:23] <pedronis> unless I'm confused
[12:23] <Chipaca> ok, I'll prune puritan back to just those, and nuke everthing but paragraph and string
[12:23] <Chipaca> (they can easily be brought back -- i'll leave the flags in the underlying code)
[12:24] <pedronis> Chipaca: I'm also not sure puritan will not offende somebody as a name
[12:24]  * Chipaca grins
[12:24] <Chipaca> it's a silly name, but I don't think there are puritans left
[12:24] <Chipaca> i might be wrong though
[12:28] <Chipaca> pedronis: i could call it 'safejson', and then also use it to house the tag checker
[12:28] <pedronis> seems reasonable (to me)
[12:28] <Chipaca> although this is a particular brand of safe (but then, safe always is)
[12:29] <Chipaca> safe-against-global-thermonuclear-war
[12:29] <Chipaca> termite-safe vs thermite-safe, etc
[12:29] <Chipaca> (also, does termite-safe mean termites can eat it, or won't eat it?)
[12:30]  * Chipaca needs lunch
[12:30] <pedronis> mvo: Chipaca: do we have a fix now with test layout and /etc?  do I just need ot merge master
[12:30] <Chipaca> pedronis: AFAIK the layout test is still a flake
[12:30] <pedronis> fun not :/
[12:31] <pstolowski> ondra: I installed your snap normally, then uninstalled, then snap try works. something is fishy here...
[12:31] <Chipaca> pstolowski: what's going on?
[12:32] <pedronis> Chipaca: contact(_url) is intersteting btw, it seems we need a type that validates urls or blanks them
[12:32] <Chipaca> ungh
[12:33] <Chipaca> pedronis: have you seen the data in contact
[12:33] <pedronis> it's random?
[12:33] <pedronis> I thought it was supposed to be a http: or mailto: url
[12:33] <mborzecki> hm there's a govalidator package that can do some of this magic
[12:34] <mborzecki> you basically set validate tags in struct fields and then call ValidateStruct()
[12:34] <mborzecki> Chipaca: pedronis: https://godoc.org/github.com/asaskevich/govalidator
[12:34] <pedronis> interesting but seems not what we want (speedwise)
[12:34] <mborzecki> we've used it in mender for some of the APIs
[12:35] <pedronis> if I understood Chipaca's worries
[12:35] <pedronis> we need more of a metavalidator than a validator
[12:35] <mborzecki> speedwise is subjective, my guess would be the i/o part of working with store will be longer than the validation :)
[12:36] <pedronis> that's not what I gathered from John at the sprint
[12:36] <pedronis> he was worried about double decoding utf8 basically
[12:36] <mborzecki> the github page has some nice examples https://github.com/asaskevich/govalidator
[12:36] <pedronis> anyway our current problem is not so much validation (we have the code), is make sure all the fields
[12:36] <pedronis> are setup properly for it
[12:37] <mborzecki> pedronis: yes, that's what i recall to, but looks like we're moving towards verifying the contents/structure of respective fields
[12:37] <Chipaca> pedronis: mborzecki: well... i wasn't worried about the double utf8 decode, per se
[12:37] <Chipaca> pedronis: mborzecki: but i needed to do most of the work anyway
[12:37] <pedronis> it might be underasting for snap.yaml
[12:38] <Chipaca> that's why it ended up doing it directly
[12:38] <pedronis> heh
[12:38] <pedronis> I meant "interesting"
[12:38] <pedronis> otoh unless is perfect not sure we want one more dep
[12:39] <pedronis> mborzecki: for  store json we have more of cleaning up problem, than a validation one
[12:39] <pedronis> if I understand
[12:39] <zyga-ubuntu> mvo: I have the first and harder half of the layouts fix
[12:39] <zyga-ubuntu> shall I push it to 4847 so that it can be squashed
[12:39] <zyga-ubuntu> or would you like to see separate commits
[12:39] <Chipaca> pedronis: mborzecki: we can also decide to drop invalid json on the floor
[12:39] <zyga-ubuntu> I haven't pushed the fix there yet, just the prerequisite helpers
[12:39] <Chipaca> pedronis: mborzecki i'd be fine with taht if we can do it at the snap level
[12:40] <Chipaca> that is, in a search result, drop individual results
[12:40] <Chipaca> but then... a typo in a description would stop a snap refresh
[12:40] <Chipaca> not sure we want that
[12:40] <Chipaca> (granted you'd really need to work hard to get a typo now the store is fixed)
[12:41] <pedronis> Chipaca: doesn't that apply to snap.yaml too though?
[12:41] <pedronis> if the description  comes from the snap.yaml then we clean from the store, but fail when we install anyway?
[12:41] <Chipaca> pedronis: indeed. and even more vocally.
[12:42]  * Chipaca turns up the 'everything is terrible' dial another notch, and goes to get some tea
[12:42] <zyga-ubuntu> Chipaca: hey, sorry for being late with that patch; could you look at 4847, this adds the symlinkat and realinkat functions
[12:42] <zyga-ubuntu> and some testing helpers
[12:42] <zyga-ubuntu> it's used in upcoming fix
[12:43] <Chipaca> zyga-ubuntu: realinkat?
[12:43] <pedronis> zyga-ubuntu: it's "cannot update snap namespace: cannot create writable mimic over "/etc": no such file or directory" fixed or are you working on that still?
[12:43] <Chipaca> but yes, after tea is brewed
[12:43]  * pedronis has lost track
[12:43] <zyga-ubuntu> I meant to say readlinkat
[12:43] <zyga-ubuntu> Thank you!
[12:44] <Chipaca> pedronis: that's the fix he's talking about
[12:44] <Chipaca> right now :-)
[12:46] <pstolowski> ondra: ah, ignore my earlier comment, second snap try breaks it
[12:47] <zyga-ubuntu> pedronis: that's what I fixed just now, it will be a PR in a moment
[12:47] <zyga-ubuntu> pedronis: just trying to coordinate that with mvo for release (one PR, many PRs, squash or not, etc)
[12:48] <mup> PR snapd#4836 closed: tests: force profile re-generation via system-key <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4836>
[12:48] <pedronis> zyga-ubuntu: that's fine, just trying to understand whether I needed to re-run the tests or merge master first
[12:49] <zyga-ubuntu> re run now
[12:51] <mup> PR snapd#4838 closed: snapstate: put layout feature behind feature flag <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4838>
[12:51] <mup> PR snapd#4851 opened: cmd/snap-update-ns: fix creation of layout symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4851>
[12:51] <zyga-ubuntu> mvo: I've opened https://github.com/snapcore/snapd/pull/4851 to get a feel of the fix in the wild
[12:51] <mup> PR #4851: cmd/snap-update-ns: fix creation of layout symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4851>
[12:52] <zyga-ubuntu> after standup I need to go to the doctor again but the 2nd fix for layouts is easier so I will push the PR after returning
[12:56] <pstolowski> zyga-ubuntu: can you remind me/brief me on how do I inspect namespaces of a snap?
[12:56] <mup> PR snapd#4809 closed: cmd/snap: tweak and polish help strings <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4809>
[12:56] <zyga-ubuntu> pstolowski: use nsenter
[12:56] <zyga-ubuntu> nsenter -m/run/snapd/ns/foo.mnt
[13:01] <mup> PR snapd#4852 opened: snapstate: put layout feature behind feature flag <Created by mvo5> <https://github.com/snapcore/snapd/pull/4852>
[13:02] <pstolowski> niemeyer: having network issues, will join in a few moments
[13:27] <soee_> hey are there any plans to fix the ugly looking snap apps their icons in launchers etc?
[13:28] <zyga-ubuntu> pstolowski: can you please pastebin the meta/snap.yaml
[13:28] <zyga-ubuntu> pstolowski: I have a suspicion I know what's going on
[13:28] <pstolowski> zyga-ubuntu: https://pastebin.ubuntu.com/p/8tCdGtRTcp/
[13:29] <zyga-ubuntu> pstolowski: aha, that's curious
[13:29] <zyga-ubuntu> that's not what I assumed
[13:29] <zyga-ubuntu> can you paste the URL of the snap pelase
[13:29] <zyga-ubuntu> *please
[13:29] <zyga-ubuntu> I'll pull and explore
[13:30] <pstolowski> zyga-ubuntu: http://people.canonical.com/~okubik/git_2.7.4_amd64.snap
[13:30] <pstolowski> zyga-ubuntu: unsquash and snap try twice
[13:31] <zyga-ubuntu> thanks
[13:41] <pstolowski> zyga-ubuntu: ty! let me know what's the outcome
[13:42] <zyga-ubuntu> I will only check after my doctor appointment though
[13:45] <pstolowski> sure
[13:56] <mborzecki> Chipaca: are you fixing snap info output?
[13:56] <Chipaca> mborzecki: yes
[13:57] <mborzecki> Chipaca: idk why, but even `fmt.Fprint(w, formatDescr(both.Description, termWidth))` tries to expand %
[13:57] <Chipaca> mborzecki: it's not formatDescr
[13:57] <Chipaca> mborzecki: it's strutil.WordWrap
[13:57] <Chipaca> mborzecki: which is the same one munging the indents
[13:57] <Chipaca> mborzecki: so guess who's throwing it away
[13:58] <Chipaca> <- this guy
[13:58] <Chipaca> :-)
[13:59] <mborzecki> Chipaca:
[14:00] <ondra> pstolowski hey
[14:00] <mborzecki> Chipaca: https://paste.ubuntu.com/p/qXH3Bk4Zkt/ pff poor man's fix, but if it's WordWrap breaking it then strutil is probably better place to fix it
[14:00] <ondra> pstolowski back now, I saw you can reproduce it now
[14:00] <ondra> pstolowski anything else I can assist with?
[14:02] <pstolowski> ondra: yeah, I got to the point where I can point my finger at what breaks and handed it over to zyga as it's his domain, he will look at it
[14:02] <zyga-ubuntu> I'm going to see a doc now, I'll check it out after that ondra
[14:02] <zyga-ubuntu> definitely feels like my type of problem
[14:04] <ondra> zyga-ubuntu yeah no time pressure from me, it's not blocking me personally, just found it as very interesting problem, so happy to help if there need
[14:04] <zyga-ubuntu> I know what to look at, I'll let you know when I understand the problem
[14:06] <Chipaca> mborzecki: yeah, by the time formatDescr gets it it's already happened
[14:07] <mborzecki> Chipaca: http://paste.ubuntu.com/p/F3y8NcpYQZ/
[14:07] <ondra> zyga-ubuntu thanks bunch :)
[14:07] <Chipaca> mborzecki: pretty much yes, but as I said on the list, the indent munging needs to die
[14:08] <mborzecki> Chipaca: death by 1000 tabs
[14:08] <Chipaca> :-)
[14:09] <pedronis> niemeyer: #4825 is the PR that needs a 2nd look
[14:09] <mup> PR #4825: overlord/snapstate:  implement policy of holding refreshes for 2h since seeding on classic <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4825>
[14:10] <zyga-ubuntu> ondra: I know what the problem is, something for me to fix in do-undo logic for mounts
[14:10] <zyga-ubuntu> thanks for bringing this to my attention, I will focus on it ASAP
[14:11] <ondra> zyga-ubuntu happy to help :)
[14:20] <mborzecki> off to pick up the kids
[14:28] <mup> PR snapd#4825 closed: overlord/snapstate:  hold refreshes for 2h after seeding on classic <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4825>
[14:47] <MincePies> Question: After installing spotify snap in Elementary OS - How Do I Start It ?
[14:53] <kyrofa> MincePies, if they don't pick up the desktop file, check in /snap/bin
[14:53] <kyrofa> There should be an executable in there you can run
[14:54] <Chipaca> MincePies: if you just installed snapd, you might need to log out before it has the paths set up right, but you should be able to do 'snap run spotify' (or /snap/bin/spotify if elementary ships it as /snap)
[14:54] <Chipaca> brb, rebooting
[15:41] <mup> PR snapd#4853 opened: overlord/snapstate: hold refreshes for 2h after seeding on classic <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4853>
[15:41] <pedronis> mvo: ^  I made the backport for that bit
[15:41] <jjohansen> zyga-ubuntu: I'm building test kernels, is there one you would like in particular
[15:51] <cachio> niemeyer, hey
[15:52] <cachio> remember the spread issue that I told you during the standup?
[15:52] <niemeyer> cachio: Hey, sure
[15:52] <cachio> niemeyer, well, the real problem was different
[15:52] <niemeyer> cachio: Not surprised ;)
[15:53] <cachio> debian is killing the networking before the ssh sessions
[15:53] <cachio> it is a known issue
[15:53] <niemeyer> cachio: What does that mean in more detail?
[15:55] <cachio> when we reboot
[15:56] <cachio> systemd is stopping the network services
[15:56] <cachio> in this debian
[15:56] <cachio> it is stopping first the network connection and then the ssh sessions
[15:57] <niemeyer> How's that an issue?
[15:58] <cachio> in that case spread is not getting that the session is closed
[15:58] <cachio> so then when it tries to connect to detect the machine is rebooted
[15:58] <cachio> it is to late
[15:58] <cachio> the machine is up again
[15:59] <cachio> bebian is taking between 7 and 8 seconds to start
[15:59] <cachio> ubuntu is taking + than 12
[15:59] <niemeyer> Ah, I see.. the connection is silently dropped
[15:59] <cachio> yes
[16:00] <niemeyer> Okay, that makes more sense
[16:00] <cachio> I created a service to force to stop the ssh sessions before the network
[16:00] <cachio> when we reboot
[16:00] <cachio> and the problem is gone
[16:00] <niemeyer> I'd prefer to workaround it in a way that makes spread more resilient
[16:00] <niemeyer> Hmm
[16:01] <cachio> otherwise I could add a keepalive in spread when we reboot
[16:01] <cachio> to detect if the ssh session is gone
[16:01] <niemeyer> cachio: Won't work.. too short a time
[16:02] <niemeyer> cachio: I suggest the following: let's drop all the waits, and make spread look at the actual uptime
[16:02] <cachio> niemeyer, ok
[16:02] <niemeyer> cachio: Instead of waiting for the disconnection, it disconnects by itself automatically when asking for the reboot
[16:02] <niemeyer> cachio: And then immediately tries to reconnect and check the uptime
[16:03] <niemeyer> cachio: Repeat until timeout
[16:03] <cachio> niemeyer, ok, makes sense
[16:03] <cachio> I'll try that
[16:03] <niemeyer> cachio: WE need to make this logic resilient as we'll often see errors mid-routine
[16:04] <cachio> which errors?
[16:04] <cachio> you mean the failed attempts?
[16:05] <cachio> niemeyer,
[16:05] <cachio> I'll try that and push it
[16:05] <cachio> after lunch :)
[16:06] <cachio> niemeyer, thanks
[16:07] <niemeyer> cachio: np, thanks for figuring it out
[16:12] <niemeyer> cachio: I suggest using this to figure the latest boot time:
[16:12] <niemeyer> date -u --iso-8601=seconds -d "`cut -f1 -d. /proc/uptime` seconds ago"
[16:12] <niemeyer> cachio: There are backticks in that message, which hopefully your IRC client did not interpret
[16:13] <niemeyer> cachio: Ah, even better:
[16:13] <niemeyer>  date -u --iso-8601=seconds -d "$(cut -f1 -d' ' /proc/uptime) seconds ago"
[16:15] <niemeyer> cachio: Then, we need to tolerate a delta of up to, say, 3 seconds, since there will be a difference between the time we read the uptime from the time date makes the syscall to pick up the time
[16:15] <Chipaca> niemeyer: cachio: or, you know, 'uptime -s'
[16:15] <Chipaca> :)
[16:17] <Chipaca> i'm going to go offline for a while, will bbl
[16:17] <niemeyer> Chipaca: Does it use utmp or proc?
[16:17]  * niemeyer checks
[16:17] <niemeyer> (we want proc)
[16:17] <Chipaca> should still be able to push the fix for snap info tonight
[16:19] <niemeyer> Apparently proc, so that's nicer indeed, thanks!
[16:19] <Chipaca> niemeyer: proc; utmp for who's logged in
[16:19]  * Chipaca vanishes in a cloud of []rune
[16:20] <niemeyer> Except cut and date come from coreutils, and uptime comes from procps
[16:20] <niemeyer> Probably good enough
[16:25] <MincePies> well that worked - only just! https://paste.ubuntu.com/p/Dj5nxS7t8g/
[16:26] <MincePies> Where can I find a list of snaps to test ?
[16:37] <cachio> niemeyer, ok, so I'll use 'uptime -s'
[16:37] <niemeyer> cachio: Sounds good, thanks
[16:40] <MincePies> Where can I find a list of snaps to test ?
[16:40] <MincePies> I have a 1 teraByte SSD
[16:44] <pedronis> I'm getting again  Job for snapd.service canceled.  on 14.04
[16:45] <pedronis> did we find what was it about?
[16:45] <cachio> pedronis, do you have a log?
[16:45] <cachio> to see where is it failing
[16:46] <pedronis> cachio:  https://travis-ci.org/snapcore/snapd/builds/353848109?utm_source=github_status&utm_medium=notification  3 prepares on 14.04 are failing with that
[16:46] <cachio> pedronis, it was giving that error when we tried to stop it and it was not in running state
[16:48] <cachio> pedronis, it is failig in another place now
[16:49] <cachio> pedronis, a solution is to encapsulate the stop into a function and there check before the status and then stop the service
[16:50] <pedronis> it's failing like this on a couple of my branches
[16:50] <pedronis> that have very different changes
[16:52] <cachio> pedronis, so, perhaps it is something new
[16:52] <pedronis> master is also red
[16:52] <pedronis> trying to see which way
[16:53] <cachio> same error on master
[16:53] <cachio> something changed
[16:53] <pedronis> yes
[16:53] <cachio> pedronis, I'll take a look
[16:53] <cachio> right now
[16:54] <cachio> thanks for the headsup
[17:01] <mup> PR snapd#4854 opened: devicestate: introduce DeviceManager.Registered returning a channel closed when the device is known to be registered <Created by pedronis> <https://github.com/snapcore/snapd/pull/4854>
[17:01] <zyga-ubuntu> re
[17:01]  * zyga-ubuntu needs more examinations 
[17:08] <zyga-ubuntu> aww, pushed go fmt fixes
[17:16] <MincePies> question, Where can I find a list of snaps for testing, please ?
[17:26] <mcphail> https://snapcraft.io/store ?
[17:27] <mcphail> https://uappexplorer.com/snaps
[17:29] <MincePies> mcphail: how do I get this to go? https://uappexplorer.com/snap/ubuntu/software-boutique
[17:31] <mcphail> MincePies: I've never used that snap. I think it is fairly specific for Ubuntu Mate. flexiondotorg may be able to clarify for you
[17:32] <MincePies> Who is he ?
[17:32] <zyga-ubuntu> MincePies: he's affiliated with Ubuntu Mate
[17:32] <mcphail> He's the creator of that snap
[17:32] <MincePies> Lets see if he shows-up, then (?)
[17:33] <mcphail> Generally, if you have a snap installed, "snap info name_of_snap" will tell you which commands can be run
[17:36] <MincePies> Brilliant & Its my first snap install! https://imgur.com/CHByC6U
[17:39] <ogra_>  oh zyga-ubuntu ....
[17:39] <ogra_> zyga-ubuntu, will you take pictures of the crowd with pitchforks in fromt of your house ?
[17:39] <ogra_> "Because flatpak is not the future ..."
[17:40] <zyga-ubuntu> ogra_: in poland? they will be lost at the train station
[17:40] <ogra_> lol
[17:40] <zyga-ubuntu> "track 6 at platform 4 in sector 8"
[17:40] <zyga-ubuntu> all said in gibberish polish with poor speakers
[17:40] <zyga-ubuntu> and once they come here they will become infected
[17:41] <zyga-ubuntu> and then half of them will oppose the other half
[17:41] <zyga-ubuntu> and they will discuss a substitute topic instead
[17:41] <zyga-ubuntu> wanna do a code review?
[18:09] <MincePies> zyga-ubuntu: > wanna do a code review? Answer: Yeah.
[18:09] <zyga-ubuntu> MincePies: hey
[18:10] <zyga-ubuntu> I have two related PRs
[18:10] <zyga-ubuntu> https://github.com/snapcore/snapd/pull/4847
[18:10] <mup> PR #4847: osutil,testutil: add symlinkat(2) and readlinkat(2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4847>
[18:10] <zyga-ubuntu> and https://github.com/snapcore/snapd/pull/4851
[18:10] <mup> PR #4851: cmd/snap-update-ns: fix creation of layout symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4851>
[18:11] <zyga-ubuntu> I will happily take feedback
[18:12] <MincePies> zyga-ubuntu: I don't Like this: https://paste.ubuntu.com/p/H944SV4kc3/
[18:12] <zyga-ubuntu> can you be more specific?
[18:13] <MincePies> Will it work on debian ?
[18:13] <zyga-ubuntu> yes, why would you worry about that?
[18:13] <zyga-ubuntu> this is an unit test for a testing helper
[18:13] <zyga-ubuntu> it will work on any system
[18:14] <MincePies> zyga-ubuntu:  > it will work on any system | That's abit 'headed' there.
[18:14] <zyga-ubuntu> ?
[18:14] <MincePies> Have you tried Rosa ?
[18:14] <zyga-ubuntu> it will work on windows and macos and plan9
[18:15] <zyga-ubuntu> because it's totally unrelated to the system
[18:15] <zyga-ubuntu> because it's a mocking helper for testing other parts of the code
[18:15] <MincePies> What is a mocking helper, then, when its at home?
[18:15] <zyga-ubuntu> sorry, I'm looking for people who can review my code
[18:16] <MincePies> he doesn't know.
[18:16] <zyga-ubuntu> internet is a funny place
[18:25] <zyga-ubuntu> jjohansen: hey, do you have a patch I could pull and try out?
[18:37] <mup> PR snapd#4839 closed: errtracker: respect the /etc/whoopsie configuration <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4839>
[18:37] <mup> PR snapd#4853 closed: overlord/snapstate: hold refreshes for 2h after seeding on classic (2.32) <Critical> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4853>
[18:39] <mup> PR snapd#4285 closed: tests, spread: add Arch Linux to CI systems <Created by bboozzoo> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/4285>
[19:17] <mup> PR snapd#4855 opened: Translate polkit strings <Created by gunnarhj> <https://github.com/snapcore/snapd/pull/4855>
[19:49] <mup> PR snapd#4852 closed: snapstate: put layout feature behind feature flag (2.32) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4852>
[19:56] <oSoMoN> sergiusens, is https://forum.snapcraft.io/t/custom-environment-variables-for-parts/1639/9 being planned / worked on yet?
[19:57] <oSoMoN> (I might be able to take a stab at it if not)
[20:04] <zyga-ubuntu> hmmm
[20:04] <zyga-ubuntu> I'm getting consistent failures
[20:04]  * zyga-ubuntu wonders what changed
[20:06] <zyga-ubuntu> + systemctl stop snapd.service snapd.socket
[20:06] <zyga-ubuntu> Job for snapd.service canceled.
[20:06] <cachio> zyga-ubuntu, I have fixed that
[20:06] <zyga-ubuntu> mvo: if you are around, do you have any idea what may have changed?
[20:06] <zyga-ubuntu> oh
[20:06] <zyga-ubuntu> cachio: shall I pull master?
[20:07]  * zyga-ubuntu hugs cachio :-)
[20:07] <cachio> no yet
[20:07] <zyga-ubuntu> what do I need?
[20:07] <cachio> I was testing that
[20:07] <cachio> I'll push in 5 minutes
[20:07] <zyga-ubuntu> excellent, thank you
[20:07] <zyga-ubuntu> I will send kids to bed in the meantime
[20:08] <sergiusens> oSoMoN: no, not on the roadmap; we could plan for it in Berlin.
[20:09] <mvo> zyga-ubuntu: hey
[20:09] <mvo> zyga-ubuntu: I am around, what is the question
[20:11] <oSoMoN> sergiusens, please do :) I won't be in Berlin but I'll be tracking it
[20:13] <mup> PR snapd#4856 opened: release: 2.32~pre2 changelogs <Created by mvo5> <https://github.com/snapcore/snapd/pull/4856>
[20:17] <sergiusens> oSoMoN: if you want to implement I would not be against that either ;-)
[20:17] <mwhudson> zyga-ubuntu: morning
[20:18] <mwhudson> zyga-ubuntu: "We can check that we are on an overlayfs, look at the upperdir and check if it is a tmpfs." <- does this mean parsing /proc/mounts or something else?
[20:18] <mwhudson> if so, does snapd already have code for this?
[20:19] <cachio> zyga-ubuntu, #4857
[20:19] <mup> PR #4857: tests: adding checks before stop snapd service to avoid job canceled on ubuntu 14.04 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4857>
[20:19] <mup> PR snapd#4857 opened: tests: adding checks before stop snapd service to avoid job canceled on ubuntu 14.04 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4857>
[20:19] <cachio> is not a super elegant solution but should work
[20:20] <cachio> We already used that in the past to fix the same problem in the reset
[20:20] <mwhudson> mmm osutil/mountinfo.go looks like a good start ;)
[20:20] <mup> PR snapd#4855 closed: data: translate polkit strings (2.32) <Created by gunnarhj> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4855>
[20:24] <zyga-ubuntu> re
[20:24] <zyga-ubuntu> hey good morning
[20:24] <zyga-ubuntu> mwhudson: we have code for this already
[20:24] <zyga-ubuntu> mwhudson: please look at ... (one sec)
[20:25] <zyga-ubuntu> https://github.com/snapcore/snapd/blob/master/osutil/overlay.go#L44
[20:25] <zyga-ubuntu> I believe this can be modified to return both upper and lower dir
[20:25] <zyga-ubuntu> and then we can inspect the upper dir path to find the fstype
[20:26] <mwhudson> oh heh that code looks installer relevant
[20:26] <zyga-ubuntu> it is referenced from ..
[20:27] <zyga-ubuntu> https://github.com/snapcore/snapd/blob/master/interfaces/apparmor/backend.go#L114 and https://github.com/snapcore/snapd/blob/master/interfaces/apparmor/backend.go#L441
[20:27] <zyga-ubuntu> which means it ends up in both snap-confine and per-snap profiles
[20:27] <zyga-ubuntu> er
[20:27] <oSoMoN> sergiusens, I haven't looked into implementation details yet, but it looks like it shouldn't be too much work
[20:27] <zyga-ubuntu> per app snap profiles
[20:27] <mwhudson> yeah that makes sense
[20:27] <zyga-ubuntu> we could use it as a starting point
[20:27] <zyga-ubuntu> I think rather than doing elaborate mountinfo analysis just find upperdir and then fstatfs it
[20:28] <mwhudson> i guess we should change code around here: https://github.com/snapcore/snapd/blob/master/overlord/snapstate/autorefresh.go#L134
[20:28] <mwhudson> (which seems very fresh, hi pedronis)
[20:36] <zyga-ubuntu> mwhudson: not sure, ask pedronis via the forum
[20:36] <mwhudson> zyga-ubuntu: ack
[20:49] <mvo> cachio: we might have a new 2.32~pre for amd64/i386 soon in beta
[20:49] <mvo> cachio: arm seems to be a bit slow to build though
[20:49] <cachio> mvo, perfect
[20:49] <cachio> tomorrow afternoon I'll be off
[20:49] <mvo> cachio: no worries
[20:49] <cachio> mvo, but I can make the tests run
[20:49] <mvo> cachio: getting it into beta and bionic is the key here, all else is bonus :)
[20:50] <cachio> so should not be a problem
[20:50] <mvo> cachio: thank you! that is great
[20:52] <cachio> np
[20:53] <zyga-ubuntu> cachio: so, what can I do to unblock PRs?
[20:54] <cachio> zyga-ubuntu, we need to merge #4857  first
[20:54] <mup> PR #4857: tests: adding checks before stopping snapd service to avoid job canceled on ubuntu 14.04 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4857>
[20:54] <cachio> it is the first part of the solution
[20:54] <zyga-ubuntu> ok, reading
[20:54] <zyga-ubuntu> what's next?
[20:55] <cachio> then I'll apply that to the other tests and scripts
[20:55] <cachio> zyga-ubuntu, I just applied that for those tests that were failing
[20:55] <cachio> basically it fails in tests with script which are stopping snapd in the first line
[20:56] <cachio> in the prepare
[20:56] <cachio> it happens because in the prepare-each the last line is starting the snapd.service and socket
[20:56] <cachio> and for some reason now the start is taking more time than before
[20:57] <zyga-ubuntu> cachio: can we use systemctl is-active?
[20:57] <cachio> well, the problem is that the status "activating" makes the mess
[20:57] <cachio> is-active returns true
[20:58] <cachio> but it is not fully ready
[20:58] <cachio> it is just happening in 14.04
[20:58] <cachio> perhaps we could try to make a change in systemd to prevent that
[20:59] <cachio> and/or see why the systemd service is taking more time to be active (running)
[20:59] <zyga-ubuntu> hmm
[20:59] <zyga-ubuntu> I mean
[20:59] <zyga-ubuntu> it prints "active"
[20:59] <zyga-ubuntu> I mainly ask because it looks cleaer than doing status and grepping
[21:00] <zyga-ubuntu> *cleaner
[21:01] <cachio> zyga-ubuntu, is-active is not enough
[21:02] <cachio> zyga-ubuntu, that's the problem
[21:03] <cachio> zyga-ubuntu, perhaps I am not getting you well, please add a comment in the PR
[21:03] <zyga-ubuntu> nah, that's ok
[21:03] <cachio> this solution is temporal
[21:03] <zyga-ubuntu> I'm fine with good is better than perfect if it ships
[21:03] <cachio> I think we need to figure out why it is happening now, and not before
[21:04] <cachio> but I did that to unblock all the other PRs
[21:06] <cachio> zyga-ubuntu, let's see if all the tests pass
[21:06] <cachio> zyga-ubuntu, I just tested completion
[21:06] <cachio> with repeat 50
[21:07] <oSoMoN> I'm not finding any documentation on build-snaps. how does snapcraft expose the contents of the build-snaps once they are installed?
[21:09] <mvo> cachio: i386 is in beta now
[21:10] <mvo> cachio: looks like you need to shepherd amd64/arm* into beta, it takes a long time today :/
[21:12] <mvo> cachio: or will do the rest in my morning, need to sleep now. cu
[21:12] <oSoMoN> sergiusens, ^
[21:16] <cachio> zyga-ubuntu, well, no errors for 14.04
[21:16] <cachio> still missing to finish one test
[21:16] <zyga-ubuntu> ok
[21:21] <cachio> zyga-ubuntu, in green
[22:12] <Chipaca> niemeyer: ping
[22:12] <niemeyer> Chipaca: pong but on a call
[22:13] <Chipaca> niemeyer: ah, give me a shout when you get off, i'll prepare some examples meanwhile
[22:22] <zyga-ubuntu> Chipaca: wow, you're working late
[22:23] <zyga-ubuntu> cnk
[22:23] <zyga-ubuntu> cachio: is it merged?
[22:23] <Chipaca> zyga-ubuntu: i don't work tomorrow, and i want to fix this snap info description thing
[22:23] <cachio> zyga-ubuntu, let me check
[22:24] <zyga-ubuntu> Chipaca: I understand the feeling
[22:24] <zyga-ubuntu> plus
[22:24] <zyga-ubuntu> I had coffee
[22:24] <zyga-ubuntu> that wasn't a smart thing
[22:24] <cachio> zyga-ubuntu, no reviews yet
[22:24] <zyga-ubuntu> but it was leftover after some cake we made
[22:24] <zyga-ubuntu> and now I'm here and looking at a bug
[22:27] <cachio> Chipaca, zyga-ubuntu #4857
[22:27] <mup> PR #4857: tests: adding checks before stopping snapd service to avoid job canceled on ubuntu 14.04 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4857>
[22:27] <cachio> please take a look before merging it
[22:36] <Chipaca> zyga-ubuntu: oooh, i have cake too
[22:36] <Chipaca> but … it's downstairs
[22:39] <zyga-ubuntu> Chipaca: let's review 4857
[22:39] <zyga-ubuntu> it shoud fix master
[22:39] <Chipaca> i'm looking at it
[22:39] <Chipaca> and scritching my head
[22:39] <Chipaca> is systemd really this broken
[22:39] <zyga-ubuntu> why
[22:39] <zyga-ubuntu> heh
[22:40] <zyga-ubuntu> that's a good question
[22:40] <zyga-ubuntu> I'm inclined to slap a TODO on it and merge it because it's green
[22:40] <zyga-ubuntu> and red sucks
[22:40] <zyga-ubuntu> actually
[22:40] <zyga-ubuntu> maybe we are just silly
[22:40] <zyga-ubuntu> maybe the "cancelled" error just means
[22:40] <zyga-ubuntu> yeah, it's off
[22:40] <Chipaca> zyga-ubuntu: ?
[22:40] <zyga-ubuntu> but returns an error
[22:41] <Chipaca> ah, no
[22:41] <Chipaca> zyga-ubuntu: cancelled means 'i couldn't queue that job you asked me to do'
[22:41] <zyga-ubuntu> ah
[22:41] <zyga-ubuntu> hmmm
[22:41] <Chipaca> where 'that job' is stopping the thing
[22:41] <zyga-ubuntu> did we report it upstream?
[22:41] <Chipaca> zyga-ubuntu: AIUI it's fixed in a new enough systemd
[22:42] <zyga-ubuntu> but not in 18.04
[22:42] <Chipaca> also if we describe what we're doing to systemd in trusty i suspect pottering will weep
[22:42] <Chipaca> zyga-ubuntu: isn't this 14.04 fix?
[22:42] <zyga-ubuntu> but this was affecting 16.04 and others
[22:42] <zyga-ubuntu> hmm
[22:42] <zyga-ubuntu> one sec
[22:42] <cachio> it is affecting just 14.04
[22:42] <Chipaca> if we can catch it on a new enough  one, yes please let's report it
[22:43] <Chipaca> i thought it was always trusty
[22:43] <zyga-ubuntu> ah
[22:43] <zyga-ubuntu> yes, just 14.04
[22:43] <zyga-ubuntu> so...
[22:43] <zyga-ubuntu> meh but yes
[22:43] <zyga-ubuntu> I wonder why now it became so apparent
[22:43] <zyga-ubuntu> did something change
[22:43] <zyga-ubuntu> or is it just google cloud being "better"
[22:44] <Chipaca> races are racy
[22:44] <zyga-ubuntu> I have a feeling we are "winning" more often now
[22:44] <Chipaca> niemeyer: depending on how busy your call is, if you want, take a look at http://people.canonical.com/~john/wrappers.txt
[22:45] <Chipaca> niemeyer: bottom line the current formatDescr is very buggy, so  i rewrote it, but before pushing i thought i'd compare it with formatDescr and with go/doc's ToText
[22:45] <Chipaca> niemeyer: in my book, i win
[22:46] <Chipaca> niemeyer: but i thought i'd check with you
[22:46]  * zyga-ubuntu -> Zzz
[22:47] <niemeyer> Chipaca: Which one is yours? Top?
[22:47] <Chipaca> niemeyer: the one labeled 'wordwrap'
[22:47] <Chipaca> yes, top
[22:47] <mup> PR snapd#4857 closed: tests: adding checks before stopping snapd service to avoid job canceled on ubuntu 14.04 <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4857>
[22:47] <niemeyer> Chipaca: A bit strange on acestreamplayer
[22:48] <Chipaca> niemeyer: that's the 'respecting existing \n' thing
[22:49] <niemeyer> Chipaca: Even worse on autopilot-qt
[22:49] <niemeyer> Chipaca: I wonder if we should fold
[22:49] <niemeyer> Chipaca: and respect empty lines instead
[22:49] <Chipaca> niemeyer: knowing when to fold is hard
[22:49] <niemeyer> Chipaca: Empty lines?
[22:49] <Chipaca> niemeyer: look at firefox for an example of folding
[22:49] <zyga-ubuntu> just buy 100 nvidia GPUs and have them AI the problem away
[22:50] <Chipaca> zyga-ubuntu: Zzz
[22:50] <niemeyer> Chipaca: I see..
[22:50] <Chipaca> zyga-ubuntu: (in reading this i saw there's a gpu-enabled terminal, and i wondered why a terminal would use the gpu for the terminal and not for ai)
[22:50] <niemeyer> Chipaca: Empty lines and non letters at start, maybe..
[22:50] <niemeyer> Chipaca: I think it's going into a good direction.. and the exercise you're doing is great
[22:51] <niemeyer> Chipaca: Thanks for that!
[22:51] <niemeyer> Chipaca: Let's see if we can do some conservative folding, starting on the cases we're pretty sure is fine.. that might be better than to figure when *not* to fold
[22:51] <Chipaca> niemeyer: if knowing when to fold were easy there wouldn't be a Common Mark :-)
[22:52] <niemeyer> Anyway
[22:52] <Chipaca> but, sure
[22:52] <niemeyer> I need to run
[22:52] <Chipaca> niemeyer: aw
[22:52] <Chipaca> you're no fun any more :-)
[22:52] <Chipaca> niemeyer: I'll push this, as it's an improvement over formatDescr, and we can loop back next week
[22:52] <Chipaca> i'm not here tomorrow :-)
[22:52] <niemeyer> Thank you!
[22:52] <niemeyer> Me neither
[22:52] <niemeyer> :)
[22:52] <niemeyer> Or maybe not anyway ;)
[22:52] <zyga-ubuntu> haha
[22:52] <niemeyer> ... nothing to see here ... o/
[22:52] <zyga-ubuntu> so "see you all tomorrow"
[22:53] <zyga-ubuntu> this team is so predictibly terrible at not working
[22:53]  * zyga-ubuntu goes to sleep
[22:57] <Chipaca> niemeyer: btw in that .txt the "has \n\n" and "has \r" is to help figure out folding heuristics, if they exist
[22:57] <cachio> zyga-ubuntu, good night
[22:57] <Chipaca> the "has \t" is because i refuse to care if it looks bad because somebody put tabs in there
[23:17] <mwhudson> how long should booting ubuntu core on a dragonboard take?
[23:18] <mwhudson> i haven't booted this one in a long time so it's possible the hardware has died
[23:18] <mwhudson> but it's hanging at "failed to load macaddress file, using random one instead"
[23:20] <mwhudson> or it's possible i hadn't inserted the sd card fully
[23:27] <zyga-ubuntu> mwhudson: hmm, it should boot pretty quickly
[23:27] <zyga-ubuntu> mwhudson: I had to reflash my SD card after loooong inactivty, not sure why
[23:27] <zyga-ubuntu> maybe that other card just failed
[23:27] <mwhudson> zyga-ubuntu: nah i just hadn't pushed the card i was booting off in fully :)
[23:28] <zyga-ubuntu> ah :)
[23:28]  * zyga-ubuntu cannot sleep after that coffee
[23:29] <mwhudson> ok now time to try to remember how to make an ubuntu core image
[23:29] <zyga-ubuntu> ctrl-r ubuntu-image ;-)
[23:29] <zyga-ubuntu> you need a model assertion
[23:29] <zyga-ubuntu> the rest is easy-ish
[23:29] <mwhudson> yes exactly :)
[23:31] <mwhudson> uh i also need to download an arm64 core snap
[23:32] <mup> PR snapd#4858 opened: strutil, cmd/snap: drop strutil.WordWrap, first pass at replacement <Created by chipaca> <https://github.com/snapcore/snapd/pull/4858>
[23:32] <Chipaca> zyga-ubuntu: ^ special rune-wrangling pr for curing insomnia
[23:33] <mwhudson> uhh my board rebooted and snapd paniced with "sync: unlock of unlocked mutex"
[23:33] <zyga-ubuntu> uh
[23:33] <zyga-ubuntu> not fun
[23:33] <zyga-ubuntu> what did it do before
[23:33] <zyga-ubuntu> I recall we had some issues when error cases would panic
[23:33] <zyga-ubuntu> s/cases/paths/
[23:33] <zyga-ubuntu> but not deliberatly, more by accident really
[23:34] <mwhudson> https://www.dropbox.com/s/y2svocouxp7o1h2/IMG_20180316_123326990.jpg?dl=0
[23:35] <mwhudson> hm not extremely readable
[23:35] <zyga-ubuntu> no, not much
[23:35] <zyga-ubuntu> can you focus on the screen and send another one
[23:35] <zyga-ubuntu> oh
[23:36] <zyga-ubuntu> invalid memory address or nil pointer dereference
[23:36] <zyga-ubuntu> looks like pedronis-land
[23:36] <zyga-ubuntu> I don't know that code much
[23:36] <zyga-ubuntu> but please drop this in the forum
[23:36] <zyga-ubuntu> looks like something to fix for the release
[23:40] <mwhudson> https://forum.snapcraft.io/t/panic-on-dragonboard/4490
[23:41] <zyga-ubuntu> Chipaca: replied
[23:41] <zyga-ubuntu> Thank you mwhudson
[23:41] <zyga-ubuntu> you can drop the image into the forum
[23:41] <zyga-ubuntu> it is more long-lived than a dropbox URL
[23:41] <zyga-ubuntu> just drag the image over to the edit field
[23:41] <zyga-ubuntu> and wow
[23:41] <zyga-ubuntu> you have a big office :D
[23:42] <mwhudson> haha i can't work at home any more
[23:42] <zyga-ubuntu> why not?
[23:42] <zyga-ubuntu> Chipaca: https://travis-ci.org/snapcore/snapd/builds/354083470?utm_source=github_status&utm_medium=notification
[23:43] <zyga-ubuntu> this build is done but still "running" on travis
[23:43] <zyga-ubuntu> it will fail on timeout any moment now
[23:44] <zyga-ubuntu> ok
[23:45] <zyga-ubuntu> I will now exercise "can I keep my eyes closed" game
[23:49] <Chipaca> ok, i'm out of here
[23:49] <Chipaca> see you all when i see you all