[00:03] <mup> PR snapcraft#1527 closed: repo: Use os-release(5) to detect supported Linux distributions <Created by Conan-Kudo> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1527>
[02:15] <mup> PR snapcraft#1518 closed: project: introduce build-snaps <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1518>
[06:00] <mup> PR snapd#3847 opened: tests: run the tests/unit/go everywhere <Created by mvo5> <https://github.com/snapcore/snapd/pull/3847>
[06:12] <zyga-ubuntu> mvo: hey
[06:12] <zyga-ubuntu> mvo: no luck with static go + c
[06:12] <zyga-ubuntu> mvo: I'll iterate shortly, just need to send kids to school
[06:13] <mvo> hey zyga-ubuntu
[06:13] <mvo> zyga-ubuntu: ok, good luck
[06:17] <mvo> fwiw, I enabled an arful-i386 autopkgtest (outcome of the 2.27 cycle retrospect)
[06:18] <mup> PR snapd#3839 closed: docs: use abolute path in PULL_REQUEST_TEMPLATE.md <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3839>
[07:07] <zyga-ubuntu> mvo: thanks, I had a question at the last stand-up, what happened to our ppc adt tests?
[07:08] <pstolowski> morning
[07:10] <zyga-ubuntu> hey pstolowski
[07:10] <zyga-ubuntu> rainy day, eh?
[07:10] <pstolowski> uhm
[07:20] <mvo> zyga-ubuntu: we only have a ppc64, not powerpc itself
[07:20] <mvo> zyga-ubuntu: is that what you mean?
[07:24] <zyga-ubuntu> aha, I see
[07:25] <zyga-ubuntu> mvo: I recall you ran into an issue that only affected a weird arch during the last cycle
[07:25] <zyga-ubuntu> and I was wondering if we missed or ignored the adt data
[07:25] <zyga-ubuntu> or if we simply didn't have any data
[07:25] <zyga-ubuntu> pstolowski: hey, I looked at your huge branch
[07:26] <zyga-ubuntu> pstolowski: that was a painful patch to write, I presume
[07:26] <pstolowski> zyga-ubuntu, a little bit, yes ;)
[07:26] <pstolowski> zyga-ubuntu, and it breaks every now and then when something new lands ;)
[07:27] <mvo> zyga-ubuntu: hm, I need to look into the PRs/error logs, I don't remember that one off-ahdn
[07:35] <zyga-ubuntu> mvo: can you please look at the general design of https://github.com/snapcore/snapd/pull/3810 since you requested those changes
[07:35] <mup> PR #3810: interfaces/hooks: PlugData and SlotData wrappers <Created by stolowski> <https://github.com/snapcore/snapd/pull/3810>
[07:36] <zyga-ubuntu> mvo: I will then work with pawel on reviweing that branch and landing it
[07:36] <pstolowski> zyga-ubuntu, and it breaks every now and then when something new lands ;)
[07:36] <pstolowski> ups, wrong window ;)
[07:37] <pstolowski> zyga-ubuntu, thanks for looking at this
[07:37] <mvo> zyga-ubuntu: yeah, in a short while, just lookiing into 2.28 breakage on artful/i386,s390x
[07:37] <mvo> zyga-ubuntu: fwiw s/requested/suggested/
[07:46] <zyga-ubuntu> mvo: sure, no rush and indeed :)
[07:48]  * zyga-ubuntu managed to link statically now
[07:48] <zyga-ubuntu> whee :)
[07:52] <zyga-ubuntu> mvo: are you looking into "./get-deps.sh: 10: ./get-deps.sh: go: not found" ?
[07:56] <mvo> zyga-ubuntu: yes, that too
[08:12] <pedronis> mvo:  will not running the unit tests everywhere increase our test run time too much ?
[08:19] <mvo> pedronis: that might be a problem yes, i can try to figure out other ways to run them but right now there is a gap in our testing, e.g. unit tests failed on trusty but we don't test for this anywhere
[08:33] <mup> PR snapd#3848 opened: snap-seccomp: check for negative syscalls in runBpf() and skip those tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3848>
[08:34] <mvo> meh, stuff like: "/tmp/go-build037063724/github.com/snapcore/snapd/cmd/snap-seccomp/_test/snap-seccomp.test: error while loading shared libraries: R_PPC64_ADDR16_HA re13f596af8 for symbol `' out of range
[08:34] <mvo> exit status 127" (in the zesty/ppc64el build) make me weep hard
[08:34] <pedronis> pstolowski: is #3810 so big because of the changes in snap/ ?
[08:34] <mup> PR #3810: interfaces/hooks: PlugData and SlotData wrappers <Created by stolowski> <https://github.com/snapcore/snapd/pull/3810>
[08:36] <pedronis> were they strictly necessary?
[08:38] <zyga-ubuntu> mvo: hmmm, symbol "empty string"
[08:38] <pstolowski> pedronis, yes, it's because the change in snap/; the change is trivial but affected lots of tests
[08:39] <pedronis> pstolowski: is it needed though?
[08:39] <pedronis> it doesn't make much sense on its own
[08:39] <pstolowski> pedronis, not strictly neccessary, but mvo suggested a nice change to avoid code repetition in the new API
[08:39] <pedronis> yes, but that's internal
[08:39] <pedronis> PlugSlotData vs plugSlotData
[08:39] <pedronis> a world of difference
[08:39] <pedronis> yes, you noticed by needing to change so much
[08:41] <pedronis> pstolowski: I don't think mvo suggestion extended to snap, it was about the new stuff
[08:47] <mup> PR snapd#3849 opened: tests: fix unit tests on Ubuntu 14.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3849>
[08:48] <mvo> pedronis: when I looked into this iirc I had to exend it to snap/ but I only looked briefly its probalby worth exploring options here
[08:49] <pstolowski> pedronis, it did, I merged mvo's branch with these refactoring changes, I fixed all the tests
[08:49] <pstolowski> pedronis, perhaps I accepted it too quick, not denying that, if this can be avoided then I'm ok to revert/redo this
[08:50] <pedronis> pstolowski: well I data *snap.PlugSlotData
[08:50] <pedronis> will probably confuse us
[08:50] <pedronis> because it recreates the problems we are trying to get away from
[08:50] <pedronis> s/I data/I think data/
[08:51] <pedronis> we should really treat the Info stuff as immutable
[08:51] <mup> PR snapd#3848 closed: snap-seccomp: check for negative syscalls in runBpf() and skip those tests <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3848>
[08:52] <pedronis> pstolowski: to be clear I'm not against a shared plugSlotData in the new stuff, I'm not thrilled by snap.PlugSlotData and even less so by sharing it with plugSlotData by reference
[08:52] <mup> PR snapd#3849 closed: tests: fix unit tests on Ubuntu 14.04 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3849>
[08:52] <mup> PR snapd#3850 opened: tests: check for negative syscalls in runBpf() and skip those tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3850>
[08:53] <mup> PR snapd#3851 opened: tests: fix unit tests on Ubuntu 14.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3851>
[08:54] <pedronis> pstolowski: using mutated or not copies of *Info is our current confusion/problem
[08:54] <pedronis> this particular changes doesn't seem to address that
[08:56] <pedronis> pstolowski: I expect some changes coming from addressing that, but the massive rework seems to not help to me
[08:59] <mvo> pstolowski: sorry for having made your life more complicated
[09:00] <pedronis> pstolowski: I'm happy to have a HO if this is unclear
[09:00] <pedronis> mvo: did you suggest to change snap.PlugInfo ?  I saw your suggestion about the new stuff, not those
[09:01] <mvo> pedronis: when I played with code I did add a snap.PlugSnapData so that it could be embedded into the new stuff
[09:01] <mvo> pedronis: maybe that was wrong
[09:01] <pedronis> yes, it is
[09:01] <pstolowski> pedronis, thanks for the feedback, really appreciate it! i'm often missing the big picture when it comes to how the structures we have fit rogether
[09:01] <pedronis> I mean, it's not wrong
[09:01] <mvo> pedronis: I was mostly trying to the duplication
[09:01] <pedronis> but it tempts bad stuff
[09:01] <pstolowski> mvo, don't worry :)
[09:01] <pedronis> and it's a massive rework
[09:01] <pedronis> that muds things
[09:02] <mvo> pedronis: ok, do you see another way to avoid the duplication or is that just something we need to accept if we don't want to go down the other route?
[09:02]  * mvo hasn't looked into the branch since a couple of days so will have to refresh his memory
[09:03] <pstolowski> pedronis, i need to revisit this branch to refresh my brain, currently finishing some other PR; will let you know later if I need more clarification
[09:03] <pedronis> mvo: pstolowski: I think the main point is that NewPlug/SlotData need to really copy stuff out of Info
[09:03] <pedronis> and then we need to live with the consequences
[09:03] <pedronis> of that
[09:03] <pedronis> right now because we didn't have dynamic attrs
[09:04] <pedronis> we use *Info either fromt he repo or the snap
[09:04] <pedronis> in slightly mixed up ways
[09:04] <pedronis> we cannot afford that once we have dynamic attrs
[09:05] <zyga-ubuntu> hmm
[09:05] <pedronis> so we do need big changes, but more about how the repository store stuff
[09:07] <pedronis> zyga-ubuntu: the PlugInfo and SlotInfo in repo are sanitized, the ones from the snaps aren't, it seems we have no bugs yet, but super unclear if just chance
[09:08] <pedronis> anyway the use of the same type makes unclear why using the wrong one would be a problem
[09:09] <zyga-ubuntu> pedronis: indeed
[09:09] <pedronis> given that go has types we might as well use them to our advantage, especially now we are adding the complexity of dynamic attrs
[09:14] <pstolowski> pedronis, got you. that's a good point
[09:19] <pedronis> pstolowski: notice that we still need to think a bit about Plug vs PlugInfo vs PlugData
[09:20] <pedronis> pstolowski: as I said happy to chat a bit about options when you have time
[09:21] <Chipaca> o/
[09:24] <mup> PR snapd#3852 opened: hooks: commands for controlling own services from snapctl <Created by stolowski> <https://github.com/snapcore/snapd/pull/3852>
[09:26]  * zyga-ubuntu reboots
[09:27] <pedronis> Chipaca: hi
[09:29] <pstolowski> pedronis, ack, thanks
[09:30]  * zyga-ubuntu walks his son to school, brb
[09:39] <Jasem[m]> Hello, I think I found an issue with snap and AppArmor, I tried sending an email to the list
[09:39] <Jasem[m]> but it bounced back
[09:40] <mvo> mwhudson: hey, I ran into /tmp/go-build407282108/github.com/snapcore/snapd/cmd/snap-seccomp/_test/snap-seccomp.test: error while loading shared libraries: R_PPC64_ADDR16_HA re110ef6af8 for symbol `' out of range in zesty/ppc64el package building. that looks very much like bug 1711935 which you marked fix released but I see it. if it is PIE related I can try to disable PIE on ppc64el maybe?
[09:40] <Jasem[m]> anywhere else?
[09:40] <mup> Bug #1711935: failing to start on ppc64el: R_PPC64_ADDR16_HA 277ef287d88 for symbol `' out of range <containerd (Ubuntu):Fix Released by mwhudson> <https://launchpad.net/bugs/1711935>
[09:40] <Chipaca> Jasem[m]: the forum?
[09:40] <Jasem[m]> Chipaca: ok will try there
[09:41] <Chipaca> Jasem[m]: you're in the right place for the chitchat around snapd, for what it's worth
[09:42] <Jasem[m]> Chipaca: well, it's an odd problem. I made a snap package for KStars about a year ago, it includes INDI server. So I forgot about the package and today I found that my INDI server (not related to the one in the snap package) was crashing. Turns out it was permission issue, and it only when away to I removed the snap from the system.
[09:42] <Jasem[m]> Chipaca: so for some reason, the AppArmor stuff was being applied to things outside of the snap in the reuglar system
[09:43] <Chipaca> Jasem[m]: that sounds awfully like one of those "that's not how this works" memes
[09:43] <Chipaca> Jasem[m]: how does the client talk to the server?
[09:44] <Jasem[m]> Chipaca: you can image frustration of troubleshooting this.. 2 hours I wasn't going anywhere it was driving me insane. I think a recent update to snap or apprmor changed things. I forgot about the snap package installed last year as I was testing snap packaging.
[09:49] <Chipaca> Jasem[m]: yes, i can imagine!
[09:49] <Chipaca> Jasem[m]: did you see my question?
[09:49] <Jasem[m]> Chipaca: the server crashes after a few seconds without any client
[09:50] <zyga-ubuntu> Jasem[m]: hey
[09:50] <zyga-ubuntu> JamieBennett: can you please open a bug or a forum thread?
[09:50] <zyga-ubuntu> er
[09:50] <zyga-ubuntu> Jasem[m]: ^
[09:50] <JamieBennett> heh, I can ;-)
[09:51] <zyga-ubuntu> Jasem[m]: sorry, I meant you above :)
[09:51] <zyga-ubuntu> Jasem[m]: do you see any apparmor denials? dmesg | grep DENIED
[09:51] <Jasem[m]> zyga-ubuntu: I didn't check that, but problem went away after the kstars snap was removed.
[09:53] <Jasem[m]> Ok I don't see any DENIED related to indiserver.
[09:54] <pedronis> Chipaca: do you want to give a look  at #3780 again, it was rebased  , also #3727 needs a 2nd review
[09:54] <mup> PR #3780: many: configure store from state, reconfigure store at runtime <Created by sparkiegeek> <https://github.com/snapcore/snapd/pull/3780>
[09:54] <mup> PR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>
[09:55] <Chipaca> pedronis: also a deconflict
[09:55] <zyga-ubuntu> Jasem[m]: please try to reproduce the issue, collect any data such as journal logs and denials or messages from the service
[09:55] <zyga-ubuntu> Jasem[m]: and let's chat
[09:55] <Chipaca> pedronis: was looking at 3870 already
[09:55] <zyga-ubuntu> Jasem[m]: in the end lets please open a forum topic with all the facts you managed to collect
[09:56] <pedronis> mvo: #3727 needs a deconflict it seems
[09:56] <mup> PR #3727: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/3727>
[10:06] <Chipaca> pedronis: opinions on snapd#3845?
[10:06] <mup> PR #3845: osutil: AtomicWriter (an io.Writer), and io.Reader versions of AtomicWrite* <Created by chipaca> <https://github.com/snapcore/snapd/pull/3845>
[10:07] <Chipaca> it's got 1.66… reviews already fwiw
[10:12] <pedronis> I'll look in  a sec
[10:12] <mvo> Chipaca: I can have a look too
[10:13] <Chipaca> mvo: you already did, twice, and you're doing the release
[10:13] <mvo> pedronis: I will work on my branches next
[10:13] <mvo> pedronis: still fighting some annoying issues with our matrix of (arch,release)
[10:13] <mvo> Chipaca: good point
[10:16] <mvo> Chipaca: fwiw, looks very nice, thanks for improving the tests btw
[10:19] <zyga-ubuntu> mvo: btw, does that mean we do 2.27.6 with build fixes?
[10:26] <pedronis> Chipaca: looked at it, mostly comments on comments and names
[10:27]  * Chipaca looks
[10:31] <Chipaca> pedronis: Commit/Cancel? Commit/Abort?
[10:31] <Chipaca> mvo: WDYT?
[10:32] <Chipaca> mvo: (re pedronis' comment that Finalize is bad because Go uses it for something else, and we already use Commit for things that can't be re-committed -- and sql transactions usually can't commit twice)
[10:34] <pedronis> Chipaca: usually for files the thing you can do many times is "flush"
[10:34] <Chipaca> mhmm
[10:34] <Chipaca> which isn't this
[10:34] <Chipaca> that's called Sync in go, and you can do that on these
[10:34] <pedronis> what where you thinking about commit and many times?
[10:34] <pedronis> s/where/were/
[10:34] <Chipaca> pedronis: mvo said he'd expect to be able to call Commit piecewise
[10:35] <pedronis> I don't know why
[10:35] <pedronis> anyway either Cancel or Abort are fine by me
[10:35] <Chipaca> pedronis: I think it's the bread. Germans do crazy stuff with the bread.
[10:35] <pedronis> Chipaca: piecewise shouds like flush
[10:36] <pedronis> except here we commit to the name
[10:36] <pedronis> with the rename
[10:36]  * Chipaca awaits mvo's feedback
[10:38] <mvo> Chipaca, pedronis: maybe its because of vcs commit that I had a mental "commit, commit" model
[10:38] <mvo> the bread is another possiblity
[10:40] <mvo> Chipaca, pedronis: "submit()"? "finish()"? but I have no super strong objection against commit(), just felt a bit odd to not be able to repeat it
[10:40] <pedronis> we have already two Commit in the codebase
[10:41] <Chipaca> nobody liked Enfeoff()
[10:41] <pedronis> my brain admittedly happily keeps vcs commit and  transactional commit separate
[10:42] <mvo> ok, commit it is then
[10:42] <xnox> does core 16, all-snappy systems, use resolved in xenial?
[10:43] <ogra_> ogra@nanopi-air:~$ ps ax|grep resolv
[10:43] <ogra_>  1618 pts/0    S+     0:00 grep --color=auto resolv
[10:43] <ogra_> xnox, ^^ does that answer it ? :)
[10:44] <xnox> ogra_, no, but this would $ systemctl status systemd-resolved
[10:44] <ogra_> xnox, we do use networkd
[10:44] <Chipaca> pedronis: I've flip-flopped over having AtomicWriter being the real thing, and it being an interface. Advantage of the interface is that it's a lot easier to document. Advantage of the real thing is that e.g. you get Sync() for free (because I'd embed *os.File)
[10:44] <Chipaca> pedronis: do you have an opinion on that?
[10:44] <ogra_> ogra@nanopi-air:~$ systemctl status systemd-resolved
[10:44] <ogra_> ● systemd-resolved.service - Network Name Resolution
[10:44] <ogra_>    Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
[10:44] <xnox> ack, thanks
[10:47] <mup> PR snapd#3850 closed: tests: check for negative syscalls in runBpf() and skip those tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3850>
[10:49] <mup> PR snapd#3851 closed: tests: fix unit tests on Ubuntu 14.04 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3851>
[11:23] <pedronis> Chipaca: the interface is ok
[11:24] <pedronis> Chipaca: do you have a use case for doing more File stuff ?
[11:24] <Chipaca> pedronis: no
[11:25] <Chipaca> pedronis: pushed an iteration
[11:26] <Chipaca> pedronis: most notably i've rejiggered commit so the only thing that can fail once the file is in place is the final dir sync
[11:26] <Chipaca> pedronis: and i've chosen to silently ignore that error
[11:27] <Chipaca> (if power dies after a failed dir sync, you either have the old or the new thing -- atomicity is there)
[11:27] <Chipaca> and, reasons for a failing dir sync after everything else worked, are really hard to come up with without it involving filesystem failure
[11:28] <pedronis> Chipaca: wondering a bit about the flags, should we have a mutex?   are there patterns where Cancel for example could come from a different goroutine than Commit?
[11:29] <Chipaca> pedronis: one of the cancels will fail with one of the appropriate errors
[11:29] <Chipaca> or one of the cancel / commits
[11:29] <Chipaca> er
[11:29] <Chipaca> let me look at it just to be sure, but i _think_ all you get is a werider error than is user-friendly
[11:30] <Chipaca> (granted that the _expected_ outcome of calling cancel and commit in different goroutines is unknown)
[11:30] <Chipaca> gah
[11:31] <Chipaca> i've done that thing again where i think just because something is a boolean, concurrent accesses will only get booleans
[11:31] <Chipaca> pedronis: would it be fair to say, if you use these things from different goroutines, add a mutex?
[11:32] <pedronis> yea, it's fair
[11:32] <pedronis> maybe just a matter to write it somewhere
[11:33] <Chipaca> pedronis: OK. If that's the only issue with the code as it stands, I'll address it in the first PR that actually uses these :-)
[11:34] <Chipaca> BTW last night I found a place where we're doing something similar to the old "compile a constant regexp every time a function is called"
[11:35] <Chipaca> (that'll be addressed in the first PR that uses this as well)
[11:37] <pedronis> Chipaca: any particular reasons to stop returning the dir.Sync() error?
[11:37] <Chipaca> pedronis: there's nothing useful you can do with it
[11:38] <Chipaca> you can't cancel the commit
[11:38] <Chipaca> you can't re-commit
[11:38] <pedronis> you disk is bad and you go ahead
[11:38] <Chipaca> the filesystem is probably consistent, but fucked because otherwise why would it error
[11:39] <Chipaca> pedronis: stated like that, it sounds like maybe I shouldn't
[11:39] <pedronis> it's  a change
[11:39] <pedronis> if you are worried about Cancel
[11:39] <pedronis> you can save the error
[11:39] <pedronis> and return that instead of
[11:39] <Chipaca> pedronis: but if I do I feel compelled to make the wording around the interface a lot more convoluted than is probably needed
[11:40] <pedronis> just cannot canccle
[11:40] <Chipaca> I'm going to go make lunch and think about it
[11:41] <pedronis> ok, anyway not giving it a +1 yet
[11:41] <pedronis> do you need an explicit -1 ?
[11:52] <zyga-ubuntu> jdstrand: hello!
[11:53] <zyga-ubuntu> jdstrand: if you are around today, can you please have a look at https://github.com/snapcore/snapd/pull/3621 again, I have added a child profile and massaged things into compliance build-wise
[11:53] <mup> PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
[11:53] <zyga-ubuntu> jdstrand: as a small note, we now have snap-exec and snap-update-ns as statically linked executables
[11:53] <zyga-ubuntu> jdstrand: I kept the are-we-reexecing-function in the PR even though I don't need it yet because it may come in handy later
[12:09]  * zyga-ubuntu sighs 
[12:12] <Chipaca> pedronis: another attempt :-)
[12:19] <jdstrand> zyga-ubuntu: hey, I'll try to get to it. I need to figure out the cgroup issue and haven't been through my inbox yet, but it is very high on the list
[12:21] <pedronis> Chipaca: just reverted that bit of change?
[12:21] <Chipaca> pedronis: and added docs
[12:23] <jdstrand> Jasem[m]: I'll just reiterate what zyga-ubuntu said and ask for more information (eg any security denials in journactl at the time the application was crashing)-- the security confinement shouldn't leak out to other processes in the way you described, and if it did, there would be logs
[12:25] <jdstrand> Jasem[m]: depending on the architecture of how the client interacts with the server, or if you had a deb client and a snap client, or a deb server and a snap server installed at the same time, then there could be conflicts (not necessarily security sandbox related)
[12:25] <zyga-suse> jdstrand: thank you, I'm trying to sort out last packaging quirk there
[12:28] <pedronis> Chipaca: matt changed #3780, it looks reasonable/consistent now, don't know if you want to look again
[12:28] <mup> PR #3780: many: configure store from state, reconfigure store at runtime <Created by sparkiegeek> <https://github.com/snapcore/snapd/pull/3780>
[12:36] <Chipaca> pedronis: i'll take a look
[12:42] <pedronis> jdstrand: hi, this seems something for you:  https://forum.snapcraft.io/t/sandboxing-in-general/1984
[12:53] <jdstrand> pedronis: yep, just came online, I'll get to it in a bit
[12:53] <jdstrand> pedronis: thanks
[13:37] <ogra_> sborovkov, https://github.com/snapcore/pi2-gadget/pull/9 ;)
[13:37] <mup> PR pi2-gadget#9: add splash support <Created by ogra1> <https://github.com/snapcore/pi2-gadget/pull/9>
[13:42] <nsg> For fun last weekend, I wrote a little snap store/repo. I downloaded the signed hello-world snap from the official store and was able to install it from my store. The question is, would it be possible to trust my own sign key and selfsign my own snaps and install them from my local store? Or is there something hardcoded in snapd that would prevent that?
[13:48] <zyga-ubuntu> nsg: there is a chain of trust from the root key, yes
[13:48] <cachio> mvo, did you see the error in the base snaps test?
[13:48] <zyga-ubuntu> nsg: there's a forum thread about that today, I would suggest you catch up first
[13:48]  * zyga-ubuntu needs to pick up his son from school, brb
[13:51] <nsg> zyga-ubuntu: will do!
[13:51] <mvo> cachio: I saw it but have not looked deeper yet, I had some vague idea, let me look again
[13:51] <mvo> cachio: I spend my morning with seccomp and similar failures in the unittests on s390x and pppc64el :)
[13:51] <cachio> mvo, ahh, ok
[13:52] <xnox> mvo, btw, i am ponderring if the new libssecomp should be backported from artful to xenial, to support newer kernels etc.
[13:52] <xnox> and s390x
[13:52] <cachio> mvo, np, I am still researching the issues that I see in the results
[13:52] <mvo> cachio: the error looks a bit like something is wrong with the branch that ubuntu-core-16-arm-32 runs from, the snapbuild version looks outdated
[13:53] <cachio> mvo, after I finish beta for 2.28 I'll create a job to run the tests on core i386 and amd64
[13:55] <ogra_> jdstrand, regarding the opengl stuff, note that mir works fine with the fixed udev rule (but we perhaps still want to allow access to these platform paths for other apps that rely on them)
[13:58] <jdstrand> ogra_: yeah, read the thread. those other paths seem reasonable for the interface though
[13:58] <jdstrand> ogra_: thanks
[13:58] <ogra_> :)
[13:59] <cachio> mvo, I already reviewed that but it is using the release/2.28 in all the cases
[14:01] <cachio> mvo, and the version that is running in the devices is correct too
[14:04] <mvo> cachio: aha, thanks. strange, I have a look at the snapbuild code, wonder what is going on there
[14:06] <nsg> hm, I can't find any forum tread from the last day discussing snap selfsigning ... I'm missing something? Any pointers of what to search for? :)
[14:09] <mvo> cachio: a PR for you: https://github.com/snapcore/spread-cron/pull/41 :)
[14:09] <mup> PR spread-cron#41: trigger builds for zesty,artful,trusty as well as xenial <Created by mvo5> <https://github.com/snapcore/spread-cron/pull/41>
[14:09] <nsg> (I'm up2date on the "External repositories" thread, if that was the one you was talking about.)
[14:13] <cachio> mvo, looking
[14:30] <mup> PR snapd#3853 opened: corecfg: mock "systemctl" in all corecfg tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3853>
[14:32] <sborovkov> ogra_: saw the PR, does this one work on the first boot?
[14:36] <niemeyer> mvo: "add --last to snap abort and snap watch"
[14:36] <niemeyer> mvo: Slightly surprised to see this one in the notes
[14:36] <niemeyer> mvo: Is it just --last, or --last=foo?
[14:36]  * niemeyer checks
[14:36] <ogra_> sborovkov, on every boot (including the first) ... i added a pre-made snap to your bug for testing
[14:37] <mvo> niemeyer: its "snap --last={install,refresh,remove,try,...}
[14:37] <mvo> niemeyer: so yes, sorry for that, that should have at least an example
[14:37] <niemeyer> mvo: Ah, okay, no worries.. I'll put an example in
[14:37] <Son_Goku> zyga-ubuntu: please test the new snapd release for Fedora
[14:38] <Son_Goku> I'd like for it to make its way through rather quickly
[14:39] <sborovkov> ogra_: when you say pre-made snap, you mean gadget snap? Anyway I will pull it and try it out. Thanks a lot! Now there is much better user experience with this. We got a bunch of bugs filed when people ran the image for the first time and it was stuck on login page for a very long time, everone was writing to us that it's broken
[14:40] <mup> PR snapd#3853 closed: corecfg: mock "systemctl" in all corecfg tests <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3853>
[14:40] <ogra_> sborovkov, yes, a gadget snap with the PR included
[14:40] <ogra_> sborovkov, fro userspace you can additionally use the psplash snap to run as a service
[14:41] <ogra_> the system will switcxh over from one splash to the other
[14:42] <sborovkov> ok that's great. this PR is for pi2-gadget only though?
[14:46] <mup> PR snapd#3854 opened: corecfg: mock "systemctl" in all corecfg tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3854>
[14:47] <mvo> cachio: fwiw, I can reproduce the error, looking now
[14:47] <sborovkov> ogra_: and I see that while pi3-gadget is still getting new commits, it does not have your commit that allow to build uboot from source for instance? Are they kinda diverging now?
[14:48] <ogra_> sborovkov, pi2 and pi3 both have the build-from-source commit ... i dont have the splash PR ready for pi3 yet though
[14:49] <mvo> cachio: I think I know what is going on - we need an update to test-snapd-snapbuild
[14:50] <sborovkov> ogra_: ah, alright sorry. How different is pi3 gadget snap? If I tried to apply your changes from pi2 PR would it work? We only use pi3 :-(
[14:50] <mvo> cachio: I'm on it
[14:50] <cachio> mvo, nice
[14:50] <ogra_> sborovkov, oops, i should have started with pi3 then (i actually thought you do pi2 ... heh) ... i guess it should apply
[14:51] <cachio> mvo, I am going to push a fix for lxd tests
[14:51] <cachio> mvo, testing it now
[14:51] <mvo> cachio: sweet, thank you!
[14:51] <cachio> mvo, it is quite slow here
[14:51] <mvo> cachio: yeah, sorry for that :/
[14:51] <mvo> cachio: you raised concerns in the PR
[14:51] <cachio> mvo, np :)
[14:51] <mvo> cachio: happy to move it to the nightly suite or something, I just think we need it tested :)
[14:52] <mvo> niemeyer: good news, CE already did the automated test for 2.28~rc1
[14:52] <cachio> mvo, yes, the idea is to run the whole test suite inside a vm with ubuntu core
[14:52] <cachio> I have to see how to reuse the nested suite
[15:01] <zyga-ubuntu> Pharaoh_Atem: hello, gladly, I'll test it ASAP
[15:01] <zyga-ubuntu> nsg: not about self-signing but about federated / external repositories
[15:01] <zyga-ubuntu> nsg: that topic is related so please look for "external repositories"
[15:03] <mvo> cachio: the base test should work now on the external backends, I will rerun on my sysem
[15:03] <mvo> system
[15:03] <cachio> great
[15:04] <mup> PR snapd#3845 closed: osutil: AtomicWriter (an io.Writer), and io.Reader versions of AtomicWrite* <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3845>
[15:08] <nsg> zyga-ubuntu: "the store signs them with an archive key so they can be verified (assertions)" ... I have seen that code from the source but my go skills are not the best so it's a little hard to follow. I guess there must be a public or a key signature somewhere on my computer and/or inside the snapd binary to validate the signature? My question is, where is it and can it be replaced with my own?
[15:09] <niemeyer> mvo: \o/
[15:10] <nsg> hm, maybe it's better to ask that instead in the thread... I will do that later :)
[15:11] <niemeyer> mvo: I'm about half-way though the list, writing a section for each item
[15:12] <niemeyer> mvo: Will have lunch now and do the rest afterwards
[15:13] <zyga-ubuntu> nsg: its baked into snapd binary
[15:13] <zyga-ubuntu> nsg: you can replace it but then none of the existing snaps will validate
[15:16] <mvo> niemeyer: thanks a lot
[15:18] <nsg> I see, so I need to build my own snapd then. In this case it's a feature that no other snaps validate :) (need to re-sign the core snap of course). I will see if I take the time to do this (probably not) ... the alternatives are just "wget ... && snap install --dangerous ..." but that sounded so hacky and I liked to avoid it by making a store for my self.
[15:18] <ogra_> nsg, it *is* super hacky, dont do it :)
[15:19] <nsg> yeah, but the other alternatives are to not use snaps at all :\
[15:19] <nsg> need to have a local repo
[15:20] <zyga-suse> nsg: why do you need this?
[15:20] <zyga-suse> nsg: we understand that some people feel strong about it but most people don't need a local repo today
[15:20] <zyga-suse> nsg: you can create private snaps today
[15:21] <nsg> I like to use snaps at work for example, I must host them inside the network
[15:21] <nsg> For my personal things, private snaps are just fine
[15:22] <zyga-suse> I see
[15:22] <ogra_> mvo, btw, if you are interested ... https://github.com/snapcore/pi2-gadget/pull/9 is the first thing that exercises "split initrd" (see the uboot.env.in bit)
[15:22] <mup> PR pi2-gadget#9: add splash support <Created by ogra1> <https://github.com/snapcore/pi2-gadget/pull/9>
[15:22] <nsg> We did consider just to package debs and deploy them inside lxd containers but snaps was a much better solution for our usecase so I tried to work my self around the problem :)
[15:22] <zyga-suse> nsg: this is not available as a feature yet, it will come out of the commercial side of snapd, where people can just get a local store and point their devices there, that store could live on your land and also act as a mirror/filter for the public snap store
[15:22] <ogra_> i have another PR pending (that sits on top of this one) to actually load a modules.img
[15:23] <zyga-suse> nsg: for the moment you can just snap install --dangerous them
[15:23] <mvo> ogra_: thanks, I check it out later, I haven't managed to find time for it yet (but I did see it)
[15:23] <zyga-suse> nsg: that just skips the assertion check
[15:23] <ogra_> mvo, yeah, it is more FYI, i can get reviews from oothers
[15:23] <ogra_> works really well though
[15:23] <mvo> ogra_: nice to hear
[15:24] <ogra_> and i can easily do all the gadget bits ahead of time before the snapd changes happen
[15:24] <mvo> cachio_lunch: just tests tests/main/base-snap on external: and it seems to be happy now
[15:24] <jdstrand> tyhicks: hey, do you have a moment to talk about one of the next steps on seccomp deny/log rather than kill?
[15:24]  * zyga-ubuntu would love to listen
[15:27] <nsg> zyga-suse: if you can tell, what time frame do you think we talk about here? --dangerous can be a acceptable solution if there is a better solution over the horizon. But if we talk 2019+ it's probably better just to stick to deb:s.
[15:29] <mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[15:29] <mup> PR core#54 closed: Use io.snapcraft.Launcher instead of com.canonical.SafeLauncher <Created by mvo5> <https://github.com/snapcore/core/pull/54>
[15:29] <mup> PR core#55 closed: Create mount points for use in exposing host system fontconfig <Created by jhenstridge> <https://github.com/snapcore/core/pull/55>
[15:30] <mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
[15:30] <mup> PR core#54 opened: Use io.snapcraft.Launcher instead of com.canonical.SafeLauncher <Created by mvo5> <https://github.com/snapcore/core/pull/54>
[15:30] <mup> PR core#55 opened: Create mount points for use in exposing host system fontconfig <Created by jhenstridge> <https://github.com/snapcore/core/pull/55>
[15:31] <zyga-suse> nsg: gustavo recently posted the snapd roadmap: https://forum.snapcraft.io/t/the-snapd-roadmap
[15:31] <diddledan> trying to run snapcraft container builds: - Copy snap "core" data (cannot copy "/var/snap/core/2774" to "/var/snap/core/2774": failed to copy all: "cp: cannot stat '/var/snap/core/2774': No such file or directory" (1))
[15:31] <zyga-suse> nsg: having said that this is a store side feature, for that there's no roadmap that I know of
[15:32] <diddledan> that 2774 is a folder which is empty
[15:32] <zyga-suse> nsg: I suspect this is a ~2018 window as I hear about various commercial projects with similar needs
[15:32] <zyga-suse> nsg: so please stick to snaps and let's work together on making this as nice as possible for all the use cases
[15:33] <zyga-suse> diddledan: that's something Chipaca may know about
[15:33] <diddledan> full log: http://paste.ubuntu.com/25472718/
[15:33] <Chipaca> diddledan: known bug, i'm afraid
[15:33] <diddledan> ergh
[15:33] <Chipaca> diddledan: (fixed in the latest)
[15:34] <Chipaca> diddledan: not sure where snapcraft comes in to it though
[15:34] <zyga-suse> man, it feels good to be on a 100Mbit connection
[15:34] <Chipaca> diddledan: that is: the operation that failed fails because of a known, fixed, issue
[15:34] <Chipaca> diddledan: but it's an operation that doesn't happen "naturally"; what triggered this?
[15:35] <diddledan> the trigger was : SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft
[15:35] <ogra_> zyga-suse, do you hear the "WOOSH" when sending and receiving files ?
[15:35] <diddledan> using snapcraft, version 2.33+git53.69dceb8
[15:35] <zyga-suse> ogra_: I don't have to count the bits anymore
[15:35] <ogra_> :)
[15:35] <Chipaca> diddledan: what does "snap version" output?
[15:35] <diddledan> in the container or locally?
[15:36] <Chipaca> diddledan: both!
[15:36] <pstolowski> davidcalle, hey, i've just tested the little problem we discussed with artful. i still cannot get the expected snapcraft build output - see http://pastebin.ubuntu.com/25472726/
[15:36] <pstolowski> davidcalle, any chance you forgot to push simething to your repo?
[15:36] <nsg> zyga-suse: yup, I have read that post (a lot if great things in there!), 2018 sounds good. For my simple use case just an easy way to change the key would be fine to... no need of a new store (I can write something simple for that). I will try to convince my team :) Thanks for the info!
[15:36] <davidcalle> pstolowski: I've tried with a clone of this repo
[15:36] <diddledan> locally: http://paste.ubuntu.com/25472730/ container: https://paste.ubuntu.com/25472734/
[15:37] <zyga-suse> nsg: thanks, please stay around and share your experiences
[15:37] <Chipaca> diddledan: what are the containers?
[15:38] <diddledan> whatever snapcraft spins up
[15:38] <diddledan> lxd
[15:38] <davidcalle> pstolowski: looks like you are running snapcraft from the snap dir, should be from the root
[15:38] <mup> PR snapcraft#1313 closed: Meta: Version from deb <Created by piso77> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1313>
[15:38] <Chipaca> diddledan: ok, may i suggest you take all this info and open a forum topic? I suspect snapcraft is doing something screwy and triggering the bug, and while it'll go away in the next snapd release, maybe it shouldn't be doing that thing
[15:39] <pstolowski> davidcalle, oh my, that's it
[15:39] <davidcalle> pstolowski: aha :)
[15:39] <pstolowski> davidcalle, why doesn't it complain?
[15:39] <zyga-suse> ok, I think I know how to massage the %gobuild macro on opensuse into compliance
[15:40] <davidcalle> pstolowski: because snapcraft.yaml can be at the root as well, so it's a valid project dir in itself
[15:40]  * davidcalle note to self: add a readme!
[15:42] <Chipaca> 		err = osutil.AtomicWriteFile(dst, nil, 0644, 0)
[15:42] <Chipaca> WHAT
[15:42] <Chipaca> why
[15:43]  * Chipaca thinks
[15:43] <Chipaca> ah, ok
[15:43] <Chipaca> :-)
[15:43] <pstolowski> davidcalle, interesting
[15:44] <diddledan> Chipaca: https://forum.snapcraft.io/t/snapcraft-container-builds-triggering-a-bug-in-snapd/1990
[15:45] <pstolowski> davidcalle, anyway. just got it built on artful now with hooks as expected. it installed cleanly. it failed when I made it to fail explicitely (I broke its install hook for a test). since i'm uncessful in reproducing, I may need your state.json file
[15:47] <davidcalle> pstolowski: should I reproduce the issue and send it over to you?
[15:48] <pstolowski> davidcalle, nb, we also have a spread test (i.e. a test with real VM) with a test snap with install hook and it has been passing too. not sure what's going on, but perhaps you got yourself into a state which somehow breaks it
[15:49] <pstolowski> davidcalle, yes, that would be helpful. do you only see it on your box where you already accumulated a bit of history with snapd, or are you able to reproduce with a clean VM?
[15:50] <tyhicks> jdstrand, zyga-suse: hey - I just got out of a meeting and can chat about the seccomp changes now
[15:50] <zyga-suse> great
[15:51] <zyga-suse> tyhicks, jdstrand: I'll adapt to any environment
[15:51] <zyga-suse> personally I think we can do it on IRC here
[15:51] <jdstrand> mvo: https://github.com/snapcore/snapd/pull/3850#pullrequestreview-60647180
[15:51] <mup> PR #3850: tests: check for negative syscalls in runBpf() and skip those tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3850>
[15:51] <jdstrand> mvo: (and hi)
[15:51] <jdstrand> tyhicks: ok
[15:52] <mvo> jdstrand: hi, I have no idea why it regresses, I did not dig into it yet, there was a ton more but I can do so tomorrow
[15:52] <jdstrand> tyhicks: basically, my understanding is that the upstream kernel changes will be in 4.14 (the next stable kernel), there will be patches for libseccomp and seccomp-go
[15:53] <mvo> jdstrand: maybe its just libseccomp ?
[15:53] <jdstrand> mvo: maybe it is seccomp-go? I don't know how it interfaces with libseccomp
[15:54] <zyga-suse> jdstrand: I think the changes will be in seccomp-go and libseccomp (unless they already landed in libseccomp)
[15:54] <tyhicks> jdstrand: correct - the libseccomp PR is here: https://github.com/seccomp/libseccomp/pull/92
[15:54] <mup> PR seccomp/libseccomp#92: Expose improved kernel logging features through libseccomp <Created by tyhicks> <https://github.com/seccomp/libseccomp/pull/92>
[15:54] <mvo> jdstrand: I can dig into it tomorrow morning
[15:54] <tyhicks> jdstrand: once that gets an ack, I can work on the libseccomp-golang patches
[15:54] <jdstrand> mvo: zesty and artful have libseccomp 2.3.1. they also have kernel > 4.3. I didn't look at the glibc bits
[15:55] <jdstrand> mvo: thanks
[15:55] <tyhicks> the libseccomp-golang changes should be quick to code up
[15:56] <jdstrand> tyhicks: ok, so in terms of using this in snapd, it sounds like we could do some conditional logic in snapd to detect if the feature is available, and if it is, use EPERM, else kill
[15:56] <tyhicks> jdstrand: that's correct
[15:56] <jdstrand> tyhicks: which is where I think we last landed
[15:57] <tyhicks> jdstrand: libseccomp/libseccomp-golang will have ways for applications to test if the kernel supports the new seccomp LOG action and the new seccomp LOG filter flag
[15:57] <zyga-suse> jdstrand: right, I asked about that aspect but I don't recall an answer; how can we check for this feature at runtime?
[15:57] <tyhicks> zyga-suse: I responded to your question in the bug report an hour or so ago (I just returned from vacation today)
[15:57] <zyga-suse> aha, perfect, I'll catch up with email then
[15:57] <zyga-suse> thank you
[15:57] <jdstrand> tyhicks: seeing that setpriority issue, I wonder if perhaps we should unconditionally use EPERM and conditionally set up logging based on kernel. kernel snaps could have this kernel patch and just start benefiting, but everything acts the same in terms of the snap developer
[15:58] <tyhicks> jdstrand: yes, I think that's the way to do it
[15:58] <jdstrand> tyhicks: perhaps there is a config option to kill instead of EPERM for systems that prefer that behavior
[15:59] <tyhicks> jdstrand: IMO, I'd keep that config option in our back pocket in the case that someone asks for it
[15:59] <jdstrand> tyhicks: like, maybe it is part of snap config for the core snap or something
[15:59] <tyhicks> seems like added complexity that doesn't have any demand, atm
[16:00] <jdstrand> tyhicks: I worry about silent denials
[16:01] <tyhicks> jdstrand: good point
[16:02] <jdstrand> tyhicks: a way to do this would be the kernel sees if it can log with EPERM. if it cannot, it logs this with a link to the forum. the forum tells what patch is needed for the kernel, and how to set the old behavior (snap set core seccomp=kill) or something
[16:03] <jdstrand> tyhicks: this would get info to kernel developers and allow users to configure the system in a way that they could see the denials
[16:04] <tyhicks> jdstrand: yeah, that could work
[16:06] <jdstrand> tyhicks: so that would be a small change to snapd to read whatever the core 'snap set' would do. it could be that snapd could evaluate an env var SNAPD_SECCOMP=kill (or somthing), and the 'snap set core' simply updates snapd's systemd unit
[16:06] <tyhicks> jdstrand: do you know if there's a bug for EPERM-by-default? I could only find a bug for "complain mode" (LP: #1567597)
[16:06] <mup> Bug #1567597: implement 'complain mode' in seccomp for developer mode with snaps <Snappy:In Progress by tyhicks> <libseccomp (Ubuntu):Confirmed for tyhicks> <linux (Ubuntu):Fix Committed by tyhicks> <https://launchpad.net/bugs/1567597>
[16:07] <tyhicks> jdstrand: I think that's a pretty clean design
[16:07] <jdstrand> tyhicks: that is the only bug I know of
[16:07] <jdstrand> tyhicks: I would suggest creating a forum topic so that others from the snapd team can comment on the design
[16:08] <tyhicks> jdstrand: that's a good idea but I'm not sure I'll be able to do that today
[16:08] <jdstrand> tyhicks: doesn't have to be today :)
[16:08]  * tyhicks nods
[16:08] <jdstrand> tyhicks: anytime before you start implementing things :)
[16:09] <jdstrand> tyhicks: the setpriority topic just got me thinking, so wanted to bring it up snce it seems like next steps are coming soonish
[16:14] <om26er> Hi! whats the practice for not having hard-coded version number in snapcraft.yaml ?
[16:14] <nacc> om26er: in which sense? for your snap? or for dependencies?
[16:14] <tyhicks> jdstrand: glad you brought it up so that at least a few of us are on the same page
[16:15] <om26er> nacc: for my snap. In our project we have a central place where we append the version number. For our snap we still have to edit the snapcraft.yaml by hand.
[16:15] <jdstrand> tyhicks: I summarized the conversation in trello
[16:15] <jdstrand> tyhicks: np
[16:26] <om26er> nacc: maybe something similar to what the core snap does ?
[16:26] <nacc> om26er: i have no idea what it does/how, sorry
[16:28] <ogra_> om26er, https://github.com/ogra1/strongswan-snap/blob/master/snap/snapcraft.yaml see "version-script:"
[16:28] <ogra_> (you can freely use shell there)
[16:30] <Chipaca> pedronis: quuestion for you that involves newlines in repairs :-)
[16:30] <pedronis> Chipaca: yes?
[16:31] <Chipaca> pedronis: how bad is it if a repair thing ends in a newline?
[16:31] <Chipaca> pedronis: currently for example runnerSuite.TestNextNotFound checks that the repair ends in }
[16:31] <Chipaca> and not }\n
[16:32] <pedronis> where, what?
[16:32] <pedronis> that's json?
[16:32] <pedronis> is not a repair
[16:33] <pedronis> Chipaca: which line in the test?
[16:33] <Chipaca> 1179
[16:34] <Chipaca> yes, the json
[16:34] <Chipaca> pedronis: the problem is https://play.golang.org/p/i5tX-SBcTo
[16:34] <Chipaca> switching runner.go to use AtomicFile instead of AtomicWriteFile results in an extra newline
[16:35] <pedronis> and test files?
[16:35] <pedronis> fails?
[16:35] <Chipaca> yep
[16:35] <pedronis> something is weird there, though?
[16:35] <pedronis> extra newline, or a newline that is not there before?
[16:35] <Chipaca> pedronis: http://pastebin.ubuntu.com/25473162/
[16:36] <Chipaca> pedronis: depends which direction you're thinking in :-)
[16:36] <Chipaca> pedronis: json.NewEncoder(aw).Encode(thing) adds a newline after encoding the thing, whereas json.Marshal(thing) does not
[16:36] <pedronis> I'm not sure whether you are trolling me or what :)
[16:37] <ogra_> lool
[16:37] <ogra_> err
[16:37] <ogra_> lol
[16:37] <ogra_> (sorry lool )
[16:37] <Chipaca> pedronis: I know nothing about repairs, so i thought i'd ask rather than just fix the tests
[16:37] <pedronis> Chipaca: repair.json is  a repair status file,  as long as we can read it back we are happy
[16:37] <Chipaca> pedronis: if we hash that json, i'd be breaking stuff
[16:38] <pedronis> Chipaca: it's not a repair
[16:38] <Chipaca> ok
[16:38] <pedronis> it was actually called repair-state.json
[16:38] <pedronis> at some point
[16:38]  * Chipaca edits the tests with glee
[16:38] <Chipaca> pedronis: sorry for the trolling (even though i think it wasn't intentional)
[16:38] <pedronis> Chipaca: it's like /var/lib/snapd/state.json bu for repairs
[16:38] <Chipaca> ok
[16:38] <pedronis> for snap-repair
[16:39] <pedronis> Chipaca: the repairs are saved as  r#.repair with a different AtomicWriteFile
[16:40] <pedronis> and are assertions, those are pickier
[16:40] <pedronis> but for sure don't end in }
[16:42] <Chipaca> pedronis: ok :-D
[16:42] <Chipaca> pedronis: actually, if you don't mind, I'll change the tests to parse the json and DeepEqual them instead of comparing them with a string? unless there was a reason to do it this way
[16:43] <pedronis> it was expedient and seemed ok for the simple cases
[16:44] <Chipaca> pedronis: agreed it's often simpler; just that now i've broken them with an unrelated change, so ¯\_(ツ)_/¯
[16:44] <pedronis> we do something similar for some tests in overlord/overlord_test.go
[16:44] <pedronis> Chipaca: notice that there's a helper that also writes states, freshState
[16:45] <pstolowski> davidcalle, hey, can you check journalctl |grep -i "using default"
[16:45] <Chipaca> pedronis: noted
[16:45] <pstolowski> davidcalle, does it find anything?
[16:56]  * Chipaca gives up after nearly drowning in a sea of map[string]interfaces{}
[17:00] <om26er> ogra_: that did the trick, thanks.
[17:10] <om26er> ogra_: how do you include the git commit info on edge channel only ?
[17:10] <om26er> is there channel specific version script ?
[17:20]  * Chipaca writes commit messages for zyga-suse to be proud
[17:21] <mup> PR snapd#3855 opened: many: switch to use the new osutil.AtomicWriter where reasonable <Created by chipaca> <https://github.com/snapcore/snapd/pull/3855>
[17:23]  * zyga-suse hugs Chipaca :-)
[17:25] <zyga-suse> Chipaca: is the trim space coming from a new newline?
[17:25] <Chipaca> zyga-suse: yes
[17:25] <Chipaca> zyga-suse: because https://play.golang.org/p/i5tX-SBcTo
[17:26] <pedronis> Chipaca: I'm probably dense today, but none of the cases in that PR seems to involve large data? what's the win?
[17:26] <zyga-suse> aha
[17:26] <pedronis> except snap-repair
[17:26] <zyga-suse> pedronis: I think I requested that, it involves arbitrary sized data when command-not-found hints are involved
[17:26] <zyga-suse> or was it also for section names and snap names?
[17:26] <Chipaca> zyga-suse: yeah, but for a lot of these we know the size
[17:26] <pedronis> yes, but that's not for the cases in that branch
[17:27] <Chipaca> pedronis: mostly just exercising the new thing, so if you'd rather I didn't do it on most of these I won't mind
[17:27] <pedronis> Chipaca: another interesting case is state.json itself  but that's mediated through state.Backend.Checkpoint taking []byte atm
[17:27] <pedronis> Chipaca: given that's it's more code, I'm not super fond,  snap-repair though seems a valid one
[17:28] <Chipaca> pedronis: ack
[17:28] <pedronis> Chipaca: I'm a being insuffarable today? I might be
[17:29] <Chipaca> pedronis: not at all, it's a valid point
[17:29] <Chipaca> the new api feels cleaner to me, but by so little, i don't mind
[17:29] <Chipaca> as i say this was _mostly_ to exercise the api, see if it was sane
[17:30] <zyga-suse> Chipaca: the only thing I found surprising is that defer cancel is unconditional, but is "trumped" by commit
[17:30] <Chipaca> zyga-suse: i love that bit :-)
[17:30] <pedronis> Chipaca: as I said exploring this vs state.json could be interesting, probably would need to a standalone thing
[17:30] <Chipaca> pedronis: agreed
[17:30] <Chipaca> state.json does its own thing though, i think?
[17:30] <Chipaca> it uses CopyFile with the sync flag?
[17:31] <pedronis> no,
[17:31] <pedronis> but it's mediated through an interface
[17:31] <pedronis> Chipaca: see overlord/backend.go:36
[17:32] <pedronis> and  the code in overlord/state/state.go calling Checkpoint
[17:32] <Chipaca> ah
[17:32]  * zyga-suse is tired
[17:33] <Chipaca> pedronis: ok, i'm going to close the PR, and then prune it and reopen it
[17:33]  * Chipaca hugs zyga-suse 
[17:33] <Chipaca> zyga-suse: why are you still here
[17:33] <pedronis> thnak you
[17:33] <zyga-suse> I want to solve the build blocker for suse
[17:33] <zyga-suse> and dput snapd for sid
[17:34] <mup> PR snapd#3855 closed: many: switch to use the new osutil.AtomicWriter where reasonable <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3855>
[17:34] <zyga-suse> aww, don't close that
[17:34] <zyga-suse> I think it's a good change
[17:35] <Chipaca> zyga-suse: i'll bring it back, for variable-sized things at least
[17:36] <zyga-suse> ok
[17:37] <Chipaca> zyga-suse: i might play with commands first, as that's the other big user (and it doesn't exist in code yet)
[17:45] <diddledan> ogra_: I got a devmode ring working kinda. it doesn't work straight away, but instead requires you to execute two separate commands because it relies on a session dbus service which is handled by a separate executable, and even tho it's supposed to autostart it doesn't seem able to
[17:51] <mup> PR snapcraft#1298 closed: jhbuild plugin: new plugin <Created by diddledan> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1298>
[17:52] <diddledan> aha. strace to the rescue - it's trying to call dbus-launch which doesn't exist (needs a stage-package)
[18:18] <mup> PR snapd#3780 closed: many: configure store from state, reconfigure store at runtime <Created by sparkiegeek> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3780>
[18:29] <mup> PR snapd#3856 opened: overlord: introduce Mock which enables to use Overlord.Settle for settle in many more places <Created by pedronis> <https://github.com/snapcore/snapd/pull/3856>
[20:37] <niemeyer> Pharaoh_Atem: ping
[21:20] <Pharaoh_Atem> niemeyer: pong
[21:20] <Pharaoh_Atem> niemeyer: what's up?
[21:23] <Pharaoh_Atem> did you want something?
[21:47] <niemeyer> Pharaoh_Atem: Heya
[21:47] <niemeyer> Pharaoh_Atem: If/when you have a moment, I'd like to perform a quick test in the forum to aid in the bug report
[22:27] <King_InuYasha> niemeyer: sure
[22:28] <niemeyer> Okay, let me create a quick topic.. you'll probably get the notification again
[22:29] <niemeyer> King_InuYasha: Done.. "Testing, please ignore"
[22:30] <King_InuYasha> it'll take a minute before Discourse decides to send it
[22:30] <King_InuYasha> heavens knows why...
[22:39] <King_InuYasha> niemeyer: I didn't get any mail so far
[22:39] <King_InuYasha> ah, here it is
[22:39] <King_InuYasha> I just got it
[22:39] <niemeyer> King_InuYasha: Alright, so now I'm sending a reply to it
[22:40] <niemeyer> King_InuYasha: The question is whether you'll get that second one
[22:40] <niemeyer> King_InuYasha: "And this is the reply."
[22:40] <niemeyer> King_InuYasha: It should take about 5 minuts
[22:40] <niemeyer> minutes
[22:48] <niemeyer> King_InuYasha: Ah, and please don't visit the topic while the reply is there, otherwise the email is not sent no matter what.
[22:49] <niemeyer> King_InuYasha: If you did see the reply through the web, let me know and I'll send another one.
[22:49] <niemeyer> Son_Goku: ^
[22:50] <Son_Goku> niemeyer: yeah, I clicked it
[22:50] <Son_Goku> sorry
[22:50] <Son_Goku> ...
[22:50] <Son_Goku> but I got the reply anyway?
[22:51] <Son_Goku> it just takes ~10 minutes
[22:51] <Son_Goku> each email was sent 11 minutes after posting
[22:54] <niemeyer> Son_Goku: Ah, you did get the reply?
[22:54] <Son_Goku> yep
[22:54] <niemeyer> Son_Goku: Super, thanks
[22:54] <niemeyer> Son_Goku: Will include in the report
[22:55] <Son_Goku> np
[22:55] <niemeyer> Son_Goku: The mailing list mode apparently sends anyway, even if you visit the web UI then
[22:55] <Son_Goku> :D
[22:55] <niemeyer> Son_Goku: The normal notifications won't
[22:55] <Son_Goku> I would seriously hope so
[22:55] <Son_Goku> otherwise the ML mode is more broken than I thought
[22:56] <niemeyer> Yeah, makes sense, at least in that case
[23:18] <mup> PR snapcraft#1530 opened: tests: share the cache dir in the integration suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1530>
[23:52] <CodeMouse92__> I think I finally figured out my ongoing problem with snapping a kivy app...I need to pip install cython BEFORE pip installing kivy, which means the two need to be installed in separate steps...
[23:53] <CodeMouse92__> I assume this means I need to create a second part, but I'm not 100% sure. Insight?