[00:56] <mup> Bug #1747794 opened: cannot resolve host name  with avahi interface  <Snappy:New> <https://launchpad.net/bugs/1747794>
[04:18] <mup> Bug #1702095 changed: snap enable removes complain for daemons <Snappy:Expired> <https://launchpad.net/bugs/1702095>
[06:18] <mborzecki> morning
[06:29] <zyga> good morning
[06:33] <mborzecki> zyga: hey
[06:42] <zyga> -6 outside now
[06:42] <zyga> so pretty
[06:49] <zyga> coffee and back to spread
[06:49] <zyga> I wrote a new feature and a test together
[06:49] <zyga> need to split those out
[07:11] <mborzecki> hm tried to reproduce this https://forum.snapcraft.io/t/oneshot-daemon-freezes-install-on-start-snap-foo-unset-services/3894 but no luck, nothing 'hangs'
[07:18] <zyga> looking at that I wonder if the original deamon did something "fancy" that made it hang
[07:18] <zyga> like get stuck on a syscall or whatever
[07:21] <mborzecki> the next thing that happens after starting the services is running configuration hooks
[07:22] <mborzecki> wonder if he had any
[07:25] <mborzecki> oh
[07:25] <mborzecki> shit
[07:25] <zyga> oh?
[07:25] <zyga> did you find something nasty?
[07:25] <mborzecki> yeah, so whena  snap is installed we run all the services
[07:25] <mborzecki> this one is 'oneshot'
[07:27] <zyga> so?
[07:27] <zyga> it should run and stop
[07:28] <mborzecki> hahaha
[07:28] <mborzecki> but it does not
[07:29] <zyga> is this a regression in 2.31?
[07:29] <zyga> (do we need rc4) or 2.31.1
[07:29] <mborzecki> it's named usb_mount, suggesting that's it will mount a usb device, if there's none then it will apparently wait
[07:29] <zyga> oh
[07:29] <zyga> so oneshot services block until they exit?
[07:29] <mborzecki> so i made a simple service that loops infinitely, and it hangs 'Start snap "daemon-oneshot" (unset) services'
[07:29] <mborzecki> yeah
[07:29] <zyga> oh, wow
[07:29] <zyga> that's not great
[07:30] <mborzecki> we also probably shoulnd't start them when installing a snap
[07:30] <zyga> actually, what should happen for oneshot services isn't clear to me
[07:30] <zyga> who should start them?
[07:30] <zyga> the snap itself?
[07:32] <mborzecki> the way i used oneshot is either as a dependency before other service (eg. generate ssh keys) or as a response to something that happens (path conditions, or a template unit)
[08:06] <mborzecki> --no-block may be a reasonable workaround, but this doesn't change the fact that the service should not wait indefinitely
[08:08] <pstolowski> heyas!
[08:09] <mborzecki> pstolowski: morning
[08:09] <kalikiana> moin moin
[08:10] <mborzecki> everyone joining :) morning mvo & kalikiana
[08:10] <mvo> good morning mborzecki
[08:10] <mvo> hey kalikiana
[08:21] <zyga> hey guys
[08:21] <zyga> mborzecki is the service bug a regression?
[08:21] <zyga> if so I bet mvo will want to know
[08:21] <mvo> zyga: I do want to know
[08:22] <mborzecki> mvo: https://forum.snapcraft.io/t/oneshot-daemon-freezes-install-on-start-snap-foo-unset-services/3894
[08:22] <mborzecki> zyga: not a regression, technically it was there before
[08:25] <mvo> mborzecki: nice find
[08:26] <mborzecki> mvo: what happens is that if a oneshot service hangs/loops/does not termine, snapd will be stuck in start-snap-services task
[08:26] <mborzecki> s/termine/terminate/
[08:26] <mvo> mborzecki: yeah, I was just readoing it
[08:27] <mvo> mborzecki: thats really unfortunate, I wonder if --no-block in systemctl might help
[08:28] <mborzecki> i'm looking at some options, like not starting oneshot tasks, adding --no-block (complicates systemd interface internally), adding TimeoutSec= in *.service (the timeout is fairly arbitrary and probably incorrect in some edge cases)
[08:28] <mvo> mborzecki: thanks for looking into this
[08:29] <mborzecki> mvo: frankly i'm leaning towards not starting oneshot services at all
[08:29] <mup> PR snapd#4621 closed: tests: skip alsa interface test when the system does not have any audio devices <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4621>
[08:30] <mup> PR snapd#4618 closed: tests: new snaps to test installs nightly <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4618>
[08:38]  * zyga iterates on layouts and testing 
[08:38] <zyga> next up: refreshes that change layouts :)
[08:38] <zyga> *that* will be interesting
[08:41] <zyga> jamesh, hey, good morning
[08:55] <zyga> did you guys watch the falcon heavy launch yesterday?
[08:58] <mvo> zyga: yeah, quite spectacular.
[08:59] <zyga> I watched it by accident (I got a tip from kissiel) and wow, it was crazy, like watching a sci-fi movie
[08:59] <zyga> *live*
[08:59] <kissiel> :)
[08:59]  * zyga found some bugs in layout validation
[08:59] <zyga> time to fix that
[08:59] <zyga> (too conservative)
[08:59] <zyga> nothing to worry about
[09:00] <zyga> mvo remember before we had spread?
[09:00] <zyga> it was like driving blind
[09:00] <mvo> zyga: I don't, my therapist helped me with that
[09:00]  * mvo pats the emacs therapist
[09:00] <zyga> haha, good one
[09:01] <mvo> zyga: but indeed, totally agree
[09:01] <zyga> -5C outside, brrr
[09:01] <zyga> let's rethink that validator
[09:23] <mup> PR snapd#4623 opened: wrappers: do not start oneshot services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4623>
[09:23] <mborzecki> there's probably a spread test that will fail as a result of ^^
[09:29]  * kalikiana coffeeeeee
[09:30]  * zyga notices a movie crew outside his house
[09:30] <zyga> kalikiana khaaaaaaan
[09:31] <zyga> there's a fake police car, fake news crew and fake people doing an interview
[09:31] <zyga> they use this site for some sitcom or other local TV thing once in a while
[09:31] <zyga> I wonder if I was in the shot, helping my daughter go to school
[09:31] <zyga> they didn't stop filming, maybe just a dry run
[09:32] <mvo> zyga: they are shooting a new sitcom - the big O theory - guess who the starts will be ?
[09:32] <zyga> haha :)
[09:33]  * mvo stops being silly and makes more tea
[09:33] <zyga> is it also freezing for you mvo?
[09:38] <Chipaca> zyga: a little bit of snow fell this morning, ~5am
[09:38] <Chipaca> zyga: it's just sitting on the glass patio table, pondering life
[09:38] <zyga> melting away
[09:38] <zyga> like all of us
[09:38] <zyga> ;-)
[09:38] <Chipaca> no, actually
[09:38]  * zyga is in a good mood today
[09:39] <Chipaca> zyga: your comment on my MatchCounter PR, could you expand it?
[09:39] <zyga> yeah, let me pull the diff tab
[09:39] <zyga> w.partial is empty
[09:39] <zyga> oh
[09:39] <zyga> man
[09:39] <zyga> I should not comment late at night
[09:39] <zyga> nothing :)
[09:40] <zyga> I got rid of it
[09:40] <zyga> I somehow read that bytes.IndexByte() was called on w.partial
[09:40] <Chipaca> ueh ueh ueh, or something
[09:40] <mvo> zyga: its around 0 here
[09:41] <mvo> Chipaca: I guess you want to rebase my PR on top of this ;)?
[09:43] <Chipaca> zyga: https://i.imgur.com/Wcj6Swd.png
[09:43] <Chipaca> zyga: censorship!
[09:43] <Chipaca> :-)
[09:43] <zyga> oh?
[09:43] <zyga> I didn't delete your comment, I just deleted mine
[09:43] <zyga> I guess it killed your comment that wasn't loaded in my tab
[09:44] <Chipaca> mvo: more like: if you think it'll improve things, I can push a commit to your PR that uses this
[09:44] <mvo> Chipaca: its more general than mine, so +1 for this
[09:44] <Chipaca> mvo: ok, i'll push a commit to yours as soon as this lands
[09:44] <mvo> ta
[09:45] <mvo> that was a subtle clue that I should review it, right?
[09:45] <Chipaca> today I'm going into london, so a lot of time on public transport with little/bad connectivity, and I'm going to miss the standup
[09:45] <Chipaca> mvo: not at all
[09:45] <Chipaca> mvo: I mean, I wasn't subtle
[09:45] <Chipaca> :-D
[09:45] <mvo> lol
[09:46]  * mvo hugs Chipaca 
[09:46] <mborzecki> Chipaca: i have mixed feelings about 4632 too, idk, maybe it'd be best to leave the code as it is now, this guys code is probably wrong
[09:47] <Chipaca> mborzecki: FWIW i think we _should_ expose startup timeout, and conditionals, and have some extra magic for oneshots where we don't hang but still handle it, but it's a lot of work for something that, in this case, is probably dev error
[09:47] <Chipaca> I mean: why would a mount process hang
[09:47] <mborzecki> Chipaca: otoh, it's not really possible to interrupt this, ^C has no effect
[09:48] <Chipaca> mborzecki: in that abort doesn't abort?
[09:48] <mborzecki> Chipaca: yeah, i have a snap with an app that loops inside and i cannot abort the installation
[09:48] <Chipaca> mborzecki: we probably want to make systemctl use the brand new osutil.RunWithContext :-)
[09:48] <Chipaca> and bubble context into systemd
[09:49] <Chipaca> OTOH it might be better to make start use --no-block and then poll, like we do with stop
[09:49] <kalikiana> zyga: what are fake people? robots? ;-)
[09:49] <Chipaca> (i mean, without it, systemctl is doing the polling)
[09:49] <zyga> kalikiana just actors ;)
[09:49] <Chipaca> kalikiana: kardashains
[09:49] <kalikiana> lol
[09:50] <mborzecki> Chipaca: hmm right, let me take another look at the code
[09:50] <mborzecki> s/kardashians/osbournes/
[09:50] <Chipaca> mborzecki: OTO²H context + (no-block + poll) is probably the real winner
[09:51] <Chipaca> mborzecki: OTO³H probably a lot of work
[09:51] <mborzecki> yeah, sounds backlog worthy
[09:51] <Chipaca> mborzecki: OTO⁴H I'm running out of superscripts
[09:51]  * sparkiegeek wonders how many hands Chipaca has
[09:52] <Chipaca> mborzecki: OTO⁽ⁿ⁺¹⁾H, you'll never know
[09:52] <mborzecki> Chipaca: RunWithContext was merged right?
[09:52] <Chipaca> mborzecki: yes
[09:53] <Chipaca> mborzecki: but killing systemctl might not dtrt wrt systemd, which is why i said it might be better to do the more detailed work
[09:53] <Chipaca> but you could use it as a base, or phase 1, or sth
[09:53]  * Chipaca gives up, and starts getting ready to leave
[09:53] <mborzecki> probably better than stalling
[09:54] <Chipaca> mborzecki: first, see if killing systemctl stops the eternal oneshot
[09:54] <mborzecki> 'eternal oneshot'
[09:54] <Chipaca> if so then robert is your mother's brother
[09:54] <Chipaca> or something
[09:55] <mborzecki> Chipaca: right, it did, the unit was stopped
[09:56] <Chipaca> perfect then :-)
[09:56] <zyga> trivial PR for someone, pretty please
[09:57] <zyga> 4624
[09:57] <mup> PR snapd#4624 opened: snap: apply some golint suggestions <Created by zyga> <https://github.com/snapcore/snapd/pull/4624>
[09:58] <Chipaca> mmm, golint fixes
[09:58] <Chipaca> zyga: ValidAppName returns true if if given string is a valid application name.
[09:59] <Chipaca> zyga: and if if not?
[09:59] <zyga> well, it returns false ;)
[09:59] <Chipaca> zyga: I mean, too many ifs
[09:59] <zyga> oh
[09:59] <zyga> I see now
[09:59] <zyga> thanks
[10:00] <Chipaca> this isn't me getting into the "oh it should be whether" thing
[10:00] <Chipaca> which I have learned is pedantic :-)
[10:00] <zyga> another good point
[10:00] <zyga> I never write that word
[10:00] <zyga> because I'm always afraid I will say weather
[10:00] <zyga> or actually, write weather
[10:00] <zyga> if if you see what I mean
[10:00] <Chipaca> zyga: maybe it's just a tsundere comment
[10:01] <zyga> a what comment?
[10:01] <mup> PR snapd#4625 opened: daemon: remove redundant UserOK markings from api commands <Created by mvo5> <https://github.com/snapcore/snapd/pull/4625>
[10:01] <mvo> Chipaca: ^- is what we talked about last night
[10:01] <Chipaca> zyga: maybe you don't want to know
[10:01] <Chipaca> mvo: ack
[10:01]  * Chipaca looks
[10:01] <mvo> Chipaca: I hope this makes things for my future self easier to grok
[10:03] <Chipaca> mvo: when the mythical "no more features, just fixes and cleanup" year arrives, I grab "rewrite daemon"
[10:03] <Chipaca> anyhow, I need to run
[10:03] <zyga> o/
[10:04] <Chipaca> telegram is your best bet to reach me (or whatsapp fwiw)
[10:04] <zyga> mvo "what the canAccess() policy." ... what?
[10:04] <mvo> Chipaca: see you
[10:05] <mvo> zyga: not sure I follow, did I write something in an unclear way?
[10:06] <zyga> I think it ends abruptly
[10:06] <zyga> "what the canAccess() policy means." maybe?
[10:07] <pedronis> unless it was meant to be "polices"  (the verb)
[10:08] <mup> PR snapd#4626 opened:  daemon: improve ucrednet code for the snap.socket <Created by mvo5> <https://github.com/snapcore/snapd/pull/4626>
[10:08] <pedronis> ah, just the "what" is too much
[10:10] <pstolowski> mvo, hey, #4579 can land, right? it got +1 from security in the old PR?
[10:10] <mup> PR #4579:  many: add interfaces.SystemKey() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/4579>
[10:13] <mvo> pstolowski: I think so, but zyga asked for a tweak (which I can do in a followup if this helps you)
[10:13] <zyga> mvo can be in a follow-up yeah
[10:13] <zyga> mvo especially since there's a new function to extract out of that logic
[10:14] <mvo> pstolowski, zyga I work on the followup and then work on the other two (smaller) ones
[10:14] <pstolowski> mvo, no, it doesn't change much for me (need other PRs as well), it's just 1 less to look after ;)
[10:14] <mup> PR snapd#4579 closed:  many: add interfaces.SystemKey() helper <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4579>
[10:15] <sparkiegeek> FYI: the snappy store is in a maintenance window until 11:00 UTC (see https://forum.snapcraft.io/t/snap-store-maintenance-dashboard-february-7-10-00-11-00-utc/3866 )
[10:15] <zyga> oh, thanks for the heads up sparkiegeek
[10:18] <mvo> zyga: hm, the release/apparmor.go code is doing the inverse of what I need, so I guess I just move my code there? or am I missing something?
[10:18] <zyga> yes
[10:18] <zyga> just move it there and perhaps reuse your code in the computation of what was already there, if feasible
[10:19] <zyga> hmm, store is doing 503
[10:19] <zyga> is that expected sparkiegeek
[10:21] <sparkiegeek> zyga: yes, but it should be coming back up now
[10:36] <mup> PR snapd#4627 opened: release, interfaces: add new release.AppArmorFeatures helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/4627>
[10:37] <mborzecki> pstolowski: left you a comment about truncation, feel free to ignore it, i think it would complicate the internals a bit too much
[10:40] <zyga> mvo 4627 is almost good
[10:40] <pstolowski> mborzecki, thx, will check
[10:45] <mup> PR snapd#4623 closed: wrappers: do not start oneshot services <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4623>
[10:46] <zyga> whee
[10:46] <zyga> spread now passes
[10:47] <zyga> ok, let's upstream the changes and work on hardening so that jdstrand doesn't turn grey on release day
[10:52] <sparkiegeek> store maintenance is now over, please report any issues on the forum thread: https://forum.snapcraft.io/t/snap-store-maintenance-dashboard-february-7-10-00-11-00-utc/3866
[11:26] <mup> PR snapd#4613 closed: release: snapd 2.31 <Blocked> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4613>
[11:26] <zyga> woot :)
[11:26] <cachio_> mvo, hey, we are ready to go to candidate
[11:27] <zyga> so no more RCs? :)
[11:27] <cachio_> no
[11:27] <mvo> cachio_: yes
[11:28] <mvo> cachio_: actually, give me ~20min to check the autopkgtest results on bionic
[11:28] <cachio_> mvo, sure
[11:28] <mvo> cachio_: if these are bad we *migth* need a .1
[11:29] <mborzecki> uhhn the changes allwoing cancelling of systemctl start are ugly
[11:30] <mvo> cachio_: looks like we do have some issues in autopkgtest due to the different environment. oh well.
[11:30] <cachio_> mvo, which is the link?
[11:31] <cachio_> mvo, could I take a look?
[11:31] <mvo> cachio_: http://autopkgtest.ubuntu.com/browse.cgi/packages/s/snapd and follow the bionic links
[11:31] <mvo> cachio_: one strange one is unit test for TestDoREquestSerialErrorsOnNoHost
[11:31] <mvo> cachio_: but it looks like a random assortion
[11:35] <cachio_> mvo, I see that a failure in the interfaces-timeserver-control is breaking the whole suite
[11:35] <cachio_> for amd64
[11:36] <mvo> cachio_: yeah, I have not looked into the details yet but it seems there are some failures we need to look at :/
[11:36] <mvo> cachio_: slightly annoying that its so hard to test autopkgtest for real
[11:38] <mup> PR snapd#4628 opened: spread: add missing ubuntu-18.04-arm64 to available autopkgtest machines <Created by mvo5> <https://github.com/snapcore/snapd/pull/4628>
[11:39] <mvo> cachio_: some is rather trivial like -^
[11:39] <cachio_> mvo, yes, I'll work on that
[11:40] <mvo> cachio_: thanks
[11:40] <mvo> zyga: looks like we need an s390x build for snapd-hacker-toolbelt
[11:40] <mvo> cachio_: and one for test-snapd-kernel-module-consumer for s390x
[11:40] <mvo> cachio_: but I guess we should focus on amd64/i386 first
[11:41] <cachio_> mvo, yes, agree
[11:41] <xnox> mvo, isn't it nice, that s390x is no longer a restricted arch and one can just tick the tickbox for it ;-)
[11:41] <zyga> mvo aha
[11:41] <zyga> mvo in a moment, I'm busy for 15 minutes
[11:41] <cachio_> mvo, not sure if we are able to create a bionic image in linode
[11:42] <mvo> xnox: it is!
[11:42] <cachio_> as it is not stable
[11:42] <mvo> cachio_: I don't think this will help us much
[11:42] <mvo> cachio_: my feeling is that the images are not the problem
[11:42] <mvo> cachio_: its that the autopkgtest env is more restricted
[11:42] <cachio_> mvo, ah, ok
[11:42] <mvo> cachio_: for whatever reason
[11:43] <mvo> cachio_: it really should not be, we run in a full VM and added hints that we mess the host up but e.g. timezone setting is denied
[11:43] <pstolowski> mvo, thanks for 4627!
[11:43] <cachio_> mvo, how do you do to trigger the tests?
[11:43] <mvo> cachio_: or maybe it is actually bionic, might be easiest to just run against qemu to see if something in e.g. systemd failed
[11:43] <mvo> cachio_: s/failed/changed/
[11:44] <mvo> cachio_: thats the sad part - to trigger the tests I need to upload the package to the real archive
[11:44] <mvo> cachio_: this is my grief with adt - there is no easy way to test against e.g. a ppa
[11:45] <cachio_> mvo, ok, I'll start runnig in qemu and then if we have a 100% we can go forward
[11:45] <mvo> cachio_: great, I keen to know if e.g. the timezone failure is related to bionic or adt
[11:48] <cachio_> mvo, so, should I promote to candidate?
[11:49] <cachio_> mvo, I can do it after the standup
[11:51] <cachio_> mvo, I have a doc appointment now, I'll be bac for the standup
[11:52]  * cachio_ afk
[11:58] <zyga> mvo sorry I'm back now
[11:58] <zyga> I just sold my x250
[11:58] <zyga> so, about that build for s390x
[12:02] <zyga> mvo, I wonder how we can build one, will snapcraft.io do it?
[12:03] <mvo> zyga: launchpad can do it, if you have snap building enabled on it
[12:03] <mvo> zyga: then you can just click on s390x as an arch
[12:03] <mvo> pstolowski: the next one (re-generate on system-key change) will arrive as soon as 4627 is green
[12:04] <pstolowski> mvo, great!
[12:04] <zyga> mvo, let me look, I honestly don't remember how I built it
[12:04] <mvo> pstolowski: then i think its just #3471 and its done
[12:04] <mup> PR #3471: snap: make `snap run` look at the system-key for security profiles <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3471>
[12:04] <mvo> pstolowski: not sure if you need this piece for your work though
[12:04] <pstolowski> cool
[12:04] <zyga> ah, it's on launchpad allright
[12:04] <zyga> mvo: shall I just rebuild for all arches?
[12:05] <mvo> zyga: +1
[12:05] <pstolowski> mvo, ah, if this is only about snap-run then no
[12:05] <zyga> mvo, man, I can even build for powerpc :)
[12:05] <zyga> would that work?
[12:05] <zyga> or is it just fake?
[12:06] <mvo> zyga: I think it will work
[12:07] <mvo> zyga: we could even build a core for powerpc now if that is fully enabled
[12:07] <zyga> https://launchpad.net/~zyga/+snap/snapd-hacker-toolbelt
[12:07] <zyga> builds are pending
[12:11] <zyga> that will be an interesting refresh :)
[12:12] <zyga> I should adopt one of the new features in snapcraft and generate version dynamically
[12:13]  * pstolowski lunch
[12:14] <zyga> mvo all done
[12:14] <zyga> wow,
[12:17] <mup> PR snapd#4624 closed: snap: apply some golint suggestions <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4624>
[12:20]  * zyga re-reads 4622
[13:00] <mup> PR snapd#4627 closed: release, interfaces: add new release.AppArmorFeatures helper <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4627>
[13:04] <mup> PR snapd#4629 opened: ifacestate: only rewrite security profiles if the system-key changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/4629>
[13:12] <mup> PR snapd#4630 opened: snap: sort layout elements before validating <Created by zyga> <https://github.com/snapcore/snapd/pull/4630>
[13:25] <zyga> + systemctl stop snapd.service snapd.socket
[13:25] <zyga> Job for snapd.socket canceled.
[13:25] <zyga> I wonder what this was, is this something that we fixed in another context before?
[13:25] <zyga> ^ cachio_  (perhaps you remember)
[13:30] <zyga> mvo ^ trivial  4630
[13:30] <mvo> zyga: ta!
[13:31] <zyga> I have one more on top, also trivial but separate issue
[13:32] <zyga> jdstrand 4631 is super trivial but for you
[13:33] <mup> PR snapd#4631 opened: cmd/snap-confine: allow mounting anywhere, effectively <Created by zyga> <https://github.com/snapcore/snapd/pull/4631>
[13:33] <zyga> jdstrand this is a side effect of a fully working spread test, which is coming up in two branches from now
[13:34] <zyga> once the test lands I will start pushing hardening for snap-update-ns, knowing that I didn't break anything
[13:53] <mup> PR snapd#4626 closed:  daemon: improve ucrednet code for the snap.socket <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4626>
[13:56] <diddledan> what's a "gated snap"?
[13:57] <zyga> diddledan snaps can use gating to ensure QA constraints
[13:57]  * diddledan read the snapcraft --help and found `snapcraft gated` and `snapcraft validate`
[13:57] <zyga> you can use it to ensure that refreshes will happen only after you sign that off as not breaking your snap
[13:57] <diddledan> so what's "gating"?
[13:58] <zyga> so. you can, for example, have a super important snap that you want to support 24/7
[13:58] <zyga> gating is the whole process
[13:58] <zyga> and you control your snap so that part is easy
[13:58] <zyga> but the core snap can introduce bugs so you want to have a way to validate them
[13:59] <zyga> if you have validation control on the core snap you can say that the core snap will refresh only if you say that your snap works with a given revision of the core snap
[13:59] <zyga> (core can by any other snap but it's typically core)
[13:59] <zyga> obviously this only applies if your snap is installed
[13:59] <zyga> it's a way to check that you can conform to your contractual agreements most likely
[13:59] <zyga> where you can check each new core revision and "ack" it
[13:59] <zyga> (for the purpose of your snap)
[13:59] <zyga> does that make sense?
[13:59] <diddledan> no
[14:00] <diddledan> clear as mud :-p
[14:00] <zyga> can you be more specific?
[14:00] <diddledan> I'm just thick
[14:00] <zyga> I can give you an example if that helps
[14:01] <diddledan> "Get the list of snaps and revisions gating a snap." means nothing to me
[14:01] <zyga> gets the list of snaps and revisions that _block the snap from refreshing_
[14:01] <diddledan> can we change the verbiage then?
[14:02] <zyga> change what, sorry?
[14:02] <diddledan> "gating" is a term which requires intimate knowledge of what it means to "gate"
[14:02] <zyga> yes, we use many words that require one specific knowledge
[14:02] <diddledan> "block", "blocks" and "blocking" are much more appropriate words if that's what is happening
[14:02] <zyga> but I think that's unavoidable and not a problem as long as they are clearly explained somewhere accessible
[14:03] <zyga> it's not just blocking, it's more subtle
[14:03] <diddledan> ... which they're not (explained somewhere accessible)
[14:03] <zyga> the users can override that
[14:03] <zyga> diddledan please raised this with kalikiana as I think this is a snapcraft documentation
[14:04] <mup> PR snapd#4632 opened: Fixing denial for when using avahi-observe slot <Created by kubiko> <https://github.com/snapcore/snapd/pull/4632>
[14:06]  * zyga -> lunch
[14:09] <kalikiana> diddledan: It's not really explained there, that's true. Would you mind filing a bug for it?
[14:20] <zyga> jdstrand thank you, I replied to your question if you want to look at why I needed this
[14:21] <mup> PR snapd#4631 closed: cmd/snap-confine: allow mounting anywhere, effectively <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4631>
[14:35]  * kalikiana hopping on a tram towards coffee shop for lunch, back in ~60min max
[14:41] <mup> PR snapd#4628 closed: spread: add missing ubuntu-18.04-arm64 to available autopkgtest machines <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4628>
[14:42] <mup> PR snapd#4633 opened:  snap: introduce timer service data types and validation  <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4633>
[14:47] <zyga> mborzecki can you please look at 4630, it's tiny and it's just adding sorting + tests
[14:47] <mborzecki> looking
[14:47] <zyga> cool, thanks
[14:48]  * zyga looks at other PRs
[14:48] <pedronis> mvo: cachio_:  here are the failures for linode:ubuntu-16.04-64:tests/main/... with SPREAD_REMOTE_STORE=staging , I think most of them are missing snaps/old snap revisions,   not sure about the core transition; canonical-livepatch and lxd we could skip though I think, the other it would be good to fix:  https://pastebin.ubuntu.com/26534904/
[14:49] <zyga> mborzecki you have a conflict on 4633
[14:50] <zyga> and it looks like what I did, sorry
[14:50] <mvo> pedronis: I think core-transition, lxd, livepatch we should skip yes
[14:50] <jdstrand> zyga: /me nods
[14:50] <zyga> mvo do you think we could disable tests for core transition?
[14:50] <mvo> zyga: probably
[14:50] <zyga> jdstrand thanks for acking the dbus fix
[14:51] <zyga> mvo if you do 2.31.1 I would suggest cherry-picking 4632
[14:51] <mvo> zyga: we do a .1
[14:51] <zyga> I'll mark it
[14:52] <mvo> zyga: ta
[14:52] <mborzecki> zyga: ok if i rebase?
[14:52] <zyga> mborzecki quickly :)
[14:53] <mborzecki> haha ok
[14:54] <cachio__> pedronis, ok, I'll take a look
[14:55] <mborzecki> zyga: pushed
[14:59] <mup> PR snapd#4605 closed: snap: detect unsquashfs write failures <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4605>
[15:00] <zyga> oh, kids home
[15:00] <zyga> brb
[15:02] <mvo> zyga: you reviewed 4491 earlier but did not do a +1 - did you forgot or was the review not complete?
[15:04] <zyga> checking
[15:06] <zyga> mvo I need to re-read that
[15:10] <mup> PR snapd#4634 opened: tests: check if snapd.socket is active before stoping it <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4634>
[15:16] <andyrock> mvo: I'm trying to allow store login in the installer. One possible solution would be to:
[15:16] <andyrock> 1) stop/disable snapd.service/snapd.socket (the one running in the live session)
[15:16] <andyrock> 2) manually start snapd inside the /target chroot
[15:16] <andyrock> 3) a client can now talk with the chrooted snapd through /run/snapd.socket
[15:16] <andyrock> Do you think that (1) and/or (2) could create any side effect?
[15:18] <zyga> andyrock: do you expect to be able to run snaps in the end?
[15:19] <zyga> andyrock I didn't check what would happen with chroot
[15:19] <zyga> probably it'd be okay
[15:19] <zyga> snapd has some logic to reassociate itself with the mount namespace of pid 1
[15:20] <zyga> but since this is the same namespace, just different chroot, it should not trigger
[15:20] <andyrock> zyga: that's not necessary
[15:20] <andyrock> for livepatch we can actually enable it at first run without problems
[15:20] <andyrock> I just need to login into the store
[15:20] <andyrock> so that the state.json has the valid entries
[15:22] <andyrock> I need (1) otherwise the live-session-snapd will activate
[15:25] <mvo> andyrock: I don't see any immediate problem, give it a go
[15:27] <andyrock> thanks
[15:34] <zyga> mvo do you want me to cherry-pick 4632?
[15:35] <mup> PR snapd#4632 closed: Fixing denial for when using avahi-observe slot <Created by kubiko> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4632>
[15:39] <mvo> zyga: sure go for it
[15:43] <zyga> pushed
[15:47] <kalikiana> re
[15:49] <Chipaca> mvo: mborzecki: did either of you mean to +1 #4622 and didn't?
[15:49] <mup> PR #4622: strutil: introducing MatchCounter <Created by chipaca> <https://github.com/snapcore/snapd/pull/4622>
[15:50] <Chipaca> or -1 or sth :-)
[15:50] <zyga> Chipaca +1 from me
[15:50] <zyga> though I didn't comment
[15:50] <zyga> let me
[15:50] <zyga> I read it a few times but I was in some wrong zone I guess
[15:50] <Chipaca> it's fiddly :-)
[15:51] <Chipaca> rather like round.Robin
[15:51] <Chipaca> :-)
[15:54] <zyga> hmmm
[15:54] <zyga> Chipaca so
[15:54] <zyga> do you need a flush?
[15:54] <zyga> on diff line 62 there
[15:54] <zyga> what guarantees that w.partial will be eventually inspected
[15:55] <Chipaca> zyga: it only matches full lines
[15:55] <Chipaca> zyga: either you wrote a full line, and got counted, or you didn't and it's in partial
[15:55] <Chipaca> \n is a flush, in that sense
[15:55] <zyga> mhm
[15:55] <Chipaca> to make it generic and not line-oriented a flush or something would be needed
[15:56] <zyga> okay
[15:56] <zyga> I think it's fine, YAGNI untill we need to do that
[15:56] <zyga> hmm
[15:56] <zyga> actually
[15:56] <zyga> you could use it without being line oriented
[15:56] <zyga> though I don't need that either
[15:56] <zyga> just wonder if it would be equally genreric
[15:56] <zyga> *generic
[15:57] <Chipaca> zyga: it very much uses the \n as the flusher
[15:57] <zyga> I'll let others comment
[15:57] <zyga> yeah
[15:57] <Chipaca> so yes you can use it, but it'd be unpredictable
[15:57] <zyga> regexpes are hard :)
[15:57] <Chipaca> and that :-)
[15:57] <zyga> it could compute the derivative of the re based on the partial input
[15:57] <zyga> and reset the re when it is empty
[15:57] <zyga> not needed
[15:57] <zyga> ;)
[15:59] <Chipaca> zyga: OTOH, instead of w.Flush() do w.Write([]byte{'\n'}) :-)
[16:00] <Chipaca> zyga: a more general thing would have two regexps (or deduce one from the other but that's Hard), one for matching, one for deciding whether to keep a chunk
[16:01] <Chipaca> eh
[16:01] <zyga> I think you can just use one RE and feed it incrementally (computing the derivative)
[16:01] <zyga> though I haven't seen any stdlib implementation that does that
[16:01] <zyga> essentially streaming
[16:02] <Chipaca> it'd require the regexp be front-anchored though, i think
[16:02] <Chipaca> i mean, the regexp for the sqlite failures is literally `.*[Ff]ailed.*`
[16:03] <zyga> mmmm
[16:03] <Chipaca> (it could be made to be `.*\b[Ff]ailed\b.*` for more nitpickiness)
[16:03] <zyga> I don't think it would, why would it?
[16:03] <zyga> derivative is a generic operation
[16:04] <Chipaca> zyga: because as soon as it starts with .*, you can't decide ahead of time
[16:04] <Chipaca> the answer always is 'yes this might match'
[16:05] <zyga> the derivative of ".*" over any character is ".*"
[16:06] <Chipaca> (aside: I'd love to understand why it's called the derivative)
[16:06] <zyga> but ".*foo.*" over "f" is "oo.*|.*foo.*" (probably)
[16:06] <zyga> dunno, you can ask the inventor
[16:06] <zyga> he's still alive
[16:07] <Chipaca> 82 and at princeton, huh
[16:07]  * zyga reads that page again
[16:07] <zyga> https://en.wikipedia.org/wiki/Brzozowski_derivative
[16:07] <Chipaca> zyga: but, er, i'm not sure how the derivative would let you decide whether to discard it early
[16:09] <zyga> I think the re will effectively remember what you threw at it
[16:12] <Chipaca> ahhh
[16:12] <Chipaca> I'd misunderstood :-)
[16:12]  * Chipaca reading pdf
[16:13] <Chipaca> Suppose we are given an RE r and a string u and we want to determine if u ∈ L[[r]]. We have u ∈ L[[r]] if, and only if, ε ∈ L[[∂u r]], which is true exactly when ε = ν(∂u r). Combining this fact with the definition of ∂u leads to an algorithm for testing if u ∈ L[[r]].
[16:13]  * Chipaca puts pdf down
[16:18] <zyga> Chipaca always read the conclusion first
[16:18] <zyga> then the abstract
[16:18] <zyga> then the rest
[16:19] <zyga> Chipaca I have a problem, wondering if I solved it right
[16:19] <zyga> https://github.com/zyga/snapd/commit/2784dc9bed05c9afb06ecbcec43328b61563c125
[16:20] <Chipaca> zyga: am I looking at the problem, or the solution? :-)
[16:21] <zyga> the solution
[16:22] <Chipaca> zyga: ok tell me about the problem
[16:23] <Chipaca> zyga: or is that what's in the commit message?
[16:23] <zyga> yeah, that
[16:23] <zyga> feels hackish
[16:24] <zyga> maybe correct but hackish
[16:24] <Chipaca> zyga: at what point are these paths getting cleaned?
[16:25] <zyga> they are not cleaned, they are verified to be clean
[16:25] <zyga> it's on line 468 in the diff context (left hand side)
[16:25] <zyga> isAbsAndClean
[16:26] <Chipaca> zyga: right, so, filepath.Clean drops trailing /s (except for root)
[16:27] <Chipaca> that is, filepath.Clean("/foo/") is "/foo"
[16:27] <zyga> yes, right
[16:27] <zyga> we require that (and check for it)
[16:27] <Chipaca> ok
[16:27] <zyga> and then for directories we slam that "/" at the end
[16:27] <zyga> and where "for directories" I mean for tmpfs mounts and for non-file bind mounts
[16:27] <Chipaca> zyga: then why the check for trailing /s in effectivePath?
[16:28] <zyga> ah, good question
[16:28] <zyga> in case $SNAP expands to /snap/core/123/
[16:28] <zyga> vs 123
[16:28] <zyga> I just didn't want to be fragile there
[16:30] <Chipaca> ok
[16:30] <Chipaca> zyga: i wasn't concerned about being defensive, i was concerned about a muddled "clean filepath" barrier
[16:31] <Chipaca> OTOH I suspect whatever expands $SNAP should be cleaning it as well
[16:31] <zyga> mmm
[16:31] <zyga> I'm not cleaning there
[16:31] <zyga> yeah
[16:31] <zyga> separate patch, let's see it
[16:32] <zyga> done now
[16:32] <Chipaca> zyga: isn't this blocking a file /foo/bar if /foo/bartholomew is in the blacklist?
[16:33] <zyga> aha, indeed
[16:33] <zyga> hmm hmm :)
[16:33] <zyga> first, let's add a test so that I know it's broken
[16:34] <Chipaca> zyga: ExpandSnapVariables does clean its returns fwiw (maybe it should document this)
[16:35] <zyga> it does?
[16:35] <zyga> I tweaked it to do it now
[16:35] <zyga> or are you saying that os.Expand cleans
[16:35] <Chipaca> zyga: I'm saying it returns things that are the result of filepath.Join
[16:35] <zyga> as for the /foobarthomesomething, we could check for prefix if the blacklist item ends with /
[16:35] <Chipaca> zyga: and filepath.Join is documented as cleaning its result
[16:35] <zyga> and check for equaility otherwise
[16:35] <zyga> aah
[16:36] <Chipaca> zyga: would it be hard to keep files and dirs separate?
[16:36] <zyga> not sure I know how
[16:36] <zyga> can you be more specific?
[16:37] <Chipaca> zyga: have two blacklists, and have effectivePath return whether it's one or the other as a bool?
[16:37] <zyga> hmm
[16:37] <zyga> but I'd have to check the directory blacklist for files as well
[16:37] <zyga> if /foo is a tmpfs mount then I must reject /foo/bar
[16:38] <zyga> even if /foo/bar is a file bind mount
[16:38] <Chipaca> zyga: hmm
[16:39] <Chipaca> zyga: another option is for effectivePath to return interfacy things, and use separate concrete classes for one and t'other
[16:39] <Chipaca> i'm not sure i'm communicating sense
[16:39] <zyga> such as IsBlacklisted() os something
[16:39] <zyga> yeah, that would work
[16:39] <zyga> I mean, I'd still check the same thing but it might be less magic
[16:39] <Chipaca> zyga: it'd keep the / fiddliness isolated
[16:40] <Chipaca> zyga: the blacklist check would be 'for interfacyThing in blacklist: interfacyThing.frobbles(otherInterfacyThing)
[16:40] <Chipaca> or sth
[16:40] <zyga>   yeah
[16:41] <zyga> thank you for spotting the bug :)
[16:41] <Chipaca> heh, np
[16:43] <zyga> https://github.com/snapcore/snapd/pull/4633 needs a 2nd review
[16:43] <mup> PR #4633:  snap: introduce  timer service data types and validation  <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4633>
[16:43] <mup> PR snapd#4622 closed: strutil: introducing MatchCounter <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4622>
[16:43] <Chipaca> zyga: tea, and i'll look at it
[16:43] <zyga> ha
[16:43] <zyga> I found my old tea
[16:43] <zyga> from yesterday evening
[16:43] <zyga> it has rum in it :)
[16:43] <Chipaca> sadly i have no rum (and it's a little early)
[16:44] <Chipaca> best i can do is port
[16:44] <Chipaca> but that doesn't sound like it'd work
[16:44] <ikey> see also https://www.youtube.com/watch?v=JImcvtJzIK8
[16:45] <zyga> hehe, someone is triggered on rum :D
[16:46] <zyga> so
[16:46] <zyga> the travis log page officially sucks
[16:46] <zyga> it's horrible
[16:46] <zyga> it's so slow an iframe would be a godsend
[16:46] <zyga> and it's forcibly loaded when all I want to do is to hit "retry"
[17:10] <zyga> Chipaca I wrote the dumb version and I'll rebase and work on the smarter version next
[17:16] <Chipaca> mvo: you around?
[17:20] <mvo> Chipaca: ish - what can I do?
[17:20] <Saviq> niemeyer: hey, a lot of our builds started failing over the past couple of days, it's usually a single run that times out on travis because the task seems stuck at updating apt (https://travis-ci.org/MirServer/mir/builds/338519402) - I tried enabling debugging from spread, but travis didn't like the amount of logging (https://travis-ci.org/MirServer/mir/builds/338550499)
[17:20] <Chipaca> mvo: i'm tweaking the error output of unsquashfsStderrWriter, thought I'd check with you first
[17:20] <Saviq> niemeyer: any idea how to proceed?
[17:20] <Chipaca> Saviq: disable ipv6?
[17:20] <Chipaca> at a guess
[17:21]  * Saviq raises brow
[17:21] <Chipaca> Saviq: we had a lot of hangs in linode during apt update with ipv6 enabled
[17:21] <Chipaca> Saviq: seems to be a problem with talking with whatever the mirror was? cachio__ might know more
[17:22] <Saviq> interesting!
[17:31] <zyga> jhodapp hey
[17:32] <jhodapp> zyga, hey there
[17:33] <mvo> Chipaca: sure, tweaking sound sgood
[17:34] <Chipaca> mvo: any rationale for it being 10 failures long, for example? it seems to result in a rather long message :-)
[17:34] <zyga> man, travis doesn't love me
[17:36] <mvo> Chipaca: no good reason, 4 is probably equally fine
[17:36] <Chipaca> mvo: perfect :-D
[17:37] <mvo> Chipaca: or 3
[17:37] <mvo> Chipaca: I just think too little is not ideal as we really have no idea
[17:37] <Chipaca> mvo: are they always in groups of 3?
[17:37] <Chipaca> mvo: otherwise, 4 seems better
[17:37] <mvo> Chipaca: I need to look, I suspect not
[17:38] <mvo> Chipaca: gtg, but will read backlog
[17:38] <Chipaca> mvo: ok, if you could at some point, it can be part of your review of this ;-)
[17:38]  * Chipaca hugs mvo 
[17:38] <mvo> Chipaca: sure
[17:38]  * mvo hugs Chipaca and vanishes
[17:40] <niemeyer> Saviq: That timeout on apt is usually associated with IPv6
[17:40] <niemeyer> Saviq: Disable IPv6 on the prepare script before trying to use apt and it should work
[17:41] <Chipaca> Saviq: https://github.com/snapcore/snapd/blob/master/spread.yaml#L294
[17:44] <Saviq> yeah, /me just stole that
[17:44] <Saviq> erm
[17:44] <Saviq> borrowed, you know
[17:44] <Saviq> I'll give it back
[17:50] <Chipaca> mvo: https://github.com/mvo5/snappy/pull/17 is the thing (i also pushed a merge of master to your pr directly, to make this one's diff easier on you)
[17:50] <mup> PR mvo5/snappy#17: snap/squashfs: change unsquashfsStderrWriter to use MatchCounter <Created by chipaca> <https://github.com/mvo5/snappy/pull/17>
[18:09] <mup> PR snapd#4630 closed: snap: sort layout elements before validating <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4630>
[18:10] <mup> PR snapd#4635 opened: snap: add support for `snap run --gdb` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4635>
[18:11] <zyga> oh, cool stuff mvo
[18:12] <ikey> oo
[18:15] <zyga> mvo quick review out
[18:15] <mvo> zyga: cool, thanks
[18:16] <zyga> Chipaca 4636 is what we talked about sans the interface indirection
[18:16] <mvo> zyga: good feedback, thank you. will address those, the message also needs tweaking I think. it was mostly a flash of inspiration that I wanted to check if it would work (i.e. use gdb from outside and the shim to break at the right point)
[18:16] <mup> PR snapd#4636 opened: snap: understand directories in layout blacklist <Created by zyga> <https://github.com/snapcore/snapd/pull/4636>
[18:18] <cachio> Saviq, sorry for the delay, which images are you using?
[18:19] <cachio> sabdfl, we have ipv6 disabled in linode images to avoid timeouts/connection issues
[18:19] <zyga> mvo I looked at your earlier PR but I'm at a stage where thinking requires a 7AM freshness
[18:19] <mvo> zyga: haha, no worries
[18:19] <mvo> zyga: I think I could probably untangle them but there will be conflicts
[18:19] <zyga> no, that's fine
[18:19] <mvo> zyga: so that stacking was easier
[18:19] <mvo> zyga: ta!
[18:20] <zyga> I just need to look at it carefully as it changes a few things in an area that is tricky
[18:20] <mvo> cachio: do we need 4634 for .31 ?
[18:21] <mvo> cachio: if we do, please shoot me a quick mail with the commit id and I will cherry-pick
[18:21] <cachio> mvo, no, it is just for an error that we see in linode
[18:21] <mvo> cachio: ok
[18:21] <mup> PR snapd#4634 closed: tests: check if snapd.socket is active before stoping it <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4634>
[18:22] <zyga> woot, I'm one PR away for spread test for layouts
[18:23] <cachio> niemeyer, do you have any idea about what could be causing this error on linode? https://paste.ubuntu.com/26537045/
[18:27] <Chipaca> cachio: probably https://twitter.com/gniemeyer/status/961273050707693569
[18:27] <cachio> Chipaca, nice
[18:28] <cachio> tx
[18:34]  * zyga -> afk
[19:23] <cachio> niemeyer, I still can't run tests on linode, is it the same issue that we faced previously?
[19:23] <niemeyer> cachio: I'll soon be with you
[19:23] <cachio> sure
[19:30] <sparkiegeek> hmm, potential ux regression in 2.31? https://bugs.launchpad.net/snapd/+bug/1747992
[19:30] <mup> Bug #1747992: Refreshing to a newly created channel but immediately stopped tracking <snapd:New> <https://launchpad.net/bugs/1747992>
[20:23] <niemeyer> sparkiegeek: Huh.. weird
[20:23] <niemeyer> sparkiegeek: Yeah, definitely worth looking into
[20:54] <niemeyer> cachio: Still there?
[20:59] <cachio> niemeyer,
[20:59] <niemeyer> cachio: So yeah, these errors look like Linode breaking down
[20:59] <cachio> niemeyer, https://paste.ubuntu.com/26537730/
[21:00] <cachio> these kind of errors I see
[21:00] <niemeyer> cachio: In general Spread can automatically recover from them, though, and the fact we have several workers per systems means no big deal
[21:00] <cachio> niemeyer, it is related to the quota limits?
[21:00] <cachio> niemeyer, it is trying to connect to the vm and nothing
[21:01] <cachio> it tries until it breaks
[21:01] <cachio> it fails
[21:01] <niemeyer> cachio: It's not quota.. it's corruption
[21:01] <niemeyer> cachio: They have severe bugs in their API services.. apparently races
[21:01] <cachio> niemeyer, I checked debian-9 and we have ipv6 enabled there
[21:02] <cachio> I could not check in trusty
[21:02] <niemeyer> cachio: Let me see which machine is creating problems.. just a sec
[21:02] <cachio> niemeyer, sure
[21:03] <niemeyer> cachio: There are machines with an empty plan ID
[21:04] <niemeyer> cachio: Which gives you an idea of how nice it is
[21:04] <cachio> niemeyer, ouch
[21:07] <cachio> niemeyer, are you killing these ones?
[21:08] <jdstrand> davidcalle (cc sergiusens): fyi, https://docs.snapcraft.io/deprecation-notices/dn5 uses the wrong header 'DN2'. It should be 'DN5'
[21:09] <niemeyer> cachio: I've run a full pass of garbage collection
[21:09] <niemeyer> cachio: Please give a shot
[21:11] <cachio> niemeyer, it is still having same issue
[21:11] <niemeyer> Okay, hold on
[21:11] <cachio> niemeyer, well, now got 1 serve
[21:11] <cachio> r
[21:12] <niemeyer> cachio: What does that mean?
[21:12] <cachio> niemeyer, it is workfing now
[21:12] <niemeyer> cachio: Phew, cool
[21:13] <cachio> niemeyer, thanks
[21:20] <niemeyer> cachio: np, let me know if you have more bad cases blocking you
[21:20] <niemeyer> cachio: I'll need to speed up our move over, likely to Google Compute
[22:09] <zyga> now to get some rest and fight tomorrow
[22:35] <slanigan> Hi everyone, I'm struggling to build an Ubuntu Core image as per the steps on the introduction page: https://docs.ubuntu.com/core/en/guides/build-device/image-building
[22:35] <slanigan> I keep getting COMMAND FAILED: sudo cp -dR --preserve=mode,timestamps,ownership /tmp/tmpuv44url8/root/* /tmp/tmp7yr_gzqx/root-mount  cp: error writing '/tmp/tmp7yr_gzqx/root-mount/system-data/var/lib/snapd/snaps/core_3884.snap': No space left on device cp: error writing '/tmp/tmp7yr_gzqx/root-mount/system-data/var/lib/snapd/snaps/pi2-kernel_22.snap': No space left on device cp: cannot create directory '/tmp/tmp7yr_gzqx/root-mount/s
[22:35] <slanigan> When I try to do the "ubuntu-image" command
[22:36] <kyrofa> slanigan, any chance you're out of HD space?
[22:37] <slanigan> df -h reports this:
[22:37] <slanigan>     Filesystem Size Used Avail Use% Mounted on     udev 7.8G 0 7.8G 0% /dev     tmpfs 1.6G 9.7M 1.6G 1% /run     /dev/sda1 432G 259G 157G 63% /     tmpfs 7.8G 130M 7.7G 2% /dev/shm     tmpfs 5.0M 4.0K 5.0M 1% /run/lock     tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup     ...     /dev/loop8 3.9M 52K 3.3M 2% /tmp/tmpvn70tzdq/root-mount <<<<<<<<
[22:38] <slanigan> That's a shortened list, but the /dev/loop8 entry is while ubuntu-image is trying to do its thing