[05:22]  * zyga-x240 is tired, very bad night
[06:19] <mborzecki> morning
[06:28] <dot-tobias> morning
[07:00] <pstolowski> morning
[07:00] <mvo> pstolowski: good morning! just fyi, I'm about to push some support thing around the import PR
[07:00] <zyga-x240> good morning guys
[07:00] <mvo> pstolowski: so probably best to not also work on it right now or we risk conflicts
[07:00] <mvo> good morning zyga-x240
[07:01] <mborzecki> mvo: hey
[07:01] <mvo> hey mborzecki ! good morning to you as well :)
[07:01] <mvo> how are you all?
[07:02] <pstolowski> mvo: hey, ack. i'll get back to it in the afternoon then, i'll focus on tests for cleanup on interrupted import
[07:02]  * zyga-x240 is pretty sleepy, lucy gave us a beating at night
[07:03] <mvo> pstolowski: we should probably have a quick chat, we discussed with samuele last night, there is this problem that the current import approach is racy, we don't need many changes but a little bit, give me 5min and I can push a sketch of what we discussed
[07:03] <pstolowski> mvo: ok
[07:04] <mvo> pstolowski: there is 9461,9462 and 9467 (all relatively small) in the meantime if you feel like it :)
[07:08] <pstolowski> sure
[07:09] <mvo> pstolowski: I wrote the idea down in https://github.com/snapcore/snapd/pull/9036#discussion_r499816703 now - hope it makes sense(?)
[07:14] <pstolowski> mvo: interesting points there. should we also delay our own restarts, or not start import if restart is pending?
[07:15] <mborzecki> mvo: i think that the comments i made in 9461 can be addressed in #9467
[07:15] <mborzecki> and perhaps have the former closed actually
[07:16] <mvo> mborzecki: sure, probably too granular all of this, sorry for that :/
[07:16] <dot-tobias> ijohnson xnox I'm trying to build the 20-armhf (or 20-arm64) pi-gadget snap, fails both on a Focal amd64 machine as well as remote-build with arm* --build-on flag. Anything I'm missing for the 20 build, since README instructions seem to be for uc18?
[07:16] <mvo> mborzecki, pstolowski thanks for the reviews!
[07:17] <zyga-x240> mvo: I commented on that idea
[07:17] <zyga-x240> just drive by comment
[07:17] <mborzecki> mvo: pstolowski: fwiw, can we actually detect the real snapshot size when reading the body? what if someone appends just some random content at the end after the legitimate zip data is finished?
[07:21] <mvo> mborzecki: we have the content-length and the limited reader now, that should help or am I misunderstanding?
[07:25] <mborzecki> mvo: hm maybe i'm complicating this a bit, what if i have a 1k snapshot, send content-length: 1G, and send the fill the rest with garbage?
[07:29] <pstolowski> mborzecki: i believe you need to be root to import. we do check if zip is valid, plus we will have disk space check there
[07:30] <pstolowski> or am i misunderstanding the concern here?
[07:30] <mvo> mborzecki: it will error when reading the tar content but yeah, in general we can not protect much about bad actors here. the content-length is mostly to ensure we can do size checks and that we protect against accidents
[07:31] <mborzecki> mvo: otoh as pstolowski mentioned, you need to be root, so there's easier ways to break stuff
[07:32] <zyga-x240> brb
[07:39] <mvo> mborzecki: yeah
[07:51] <mvo> pstolowski, pedronis how does https://github.com/snapcore/snapd/compare/master...mvo5:snapshot-import-3?expand=1 look ? this should make the import race-free (at least on the filesystem level)
[07:51] <mvo> pstolowski, pedronis also (to me but I'm biased) slightly easier to read(?)
[07:52] <mvo> (tests need updating still but integration works)
[07:52] <pstolowski> mvo: the url seems broken, wants me to open a PR
[07:53] <mvo> pstolowski: sorry! is this one better? https://github.com/snapcore/snapd/compare/master...mvo5:snapshot-import-3
[07:54] <mvo> https://github.com/snapcore/snapd/compare/master...mvo5:snapshot-import-3
[07:54] <pedronis> mvo: did you see zyga comment, not that I understand it
[07:56] <mvo> pedronis: I did, not sure how this helps against reboots, but once he is back I will ask him
[07:56] <pedronis> yes, that's the same question I have, also not clear what we would lock
[07:57] <mvo> pedronis: yeah, we could lock the $setid_importing file but not sure about the gain
[07:59] <pedronis> anyway checking for hashes will add more questions as well
[08:01] <mvo> pedronis: right, which ones to be exact? if we have hashes in export.json we can validate them after line 582. or am I missing something?
[08:02] <pedronis> mvo: we'll need to do some locking and put some data in importing to avoid importing the same thing twice if asked in quick succession
[08:02] <pstolowski> mvo: not sure, it shows all the changes against master i think
[08:03] <mvo> pedronis: oh, interessting. yes!
[08:03] <pedronis> anyway we are not there yet
[08:03] <mvo> pstolowski: oh, right, let me try to compare against just the old pr if that helps?
[08:04] <pstolowski> mvo: nah, i think i'll just look at entire thing again
[08:04] <mvo> pstolowski: might actually be easier
[08:26] <pstolowski> mvo: i think i'll hold off from touching import PR for now, it's moving too much
[08:28] <mborzecki> 2020-10-06 08:03:25 Cannot allocate google:centos-8-64: cannot allocate new Google server google:centos-8-64 hmm (oct060800-322222): timeout waiting for google:centos-8-64 (oct060800-322222) to provision
[08:37] <mvo> pstolowski: sorry for that, it should calm down very soon I think
[08:37] <mborzecki> zyga-x240: https://developers.redhat.com/blog/2020/09/24/new-c-features-in-gcc-10/?sc_cid=7013a00000260vRAAQ
[08:39] <pstolowski> mvo: no worries
[08:39] <pstolowski> mvo: i've fun with services now and that issue from the forum ;)
[08:40] <zyga-x240> mborzecki: nothing really interesting
[08:40] <zyga-x240> mborzecki: C++ is a sprawling mess
[08:40] <mvo> pstolowski: ha! great.
[08:40]  * zyga-x240 keeps hacking 
[08:41] <zyga-x240> there was a bit of worry as city-wide alarm sirens were on for like 10 minutes
[08:41] <zyga-x240> fortunately it's just a test
[08:41] <zyga-x240> but man, a bit nervous for a moment
[08:41] <zyga-x240> *those are LOUD*
[08:41] <dot-tobias> Is cloud-init still unsupported/buggy when building a core20 image, or does ubuntu-image need an update after https://github.com/CanonicalLtd/ubuntu-image/pull/186? I have some additional setup for my images in a cloud.conf that can't be reliably replicated through gadget or other supported mechanisms.
[08:41] <zyga-x240> bombing run alarm test
[08:42] <mvo> 9462 is an easy win
[08:42] <mvo> very small
[08:43] <mborzecki> mvo: pedronis: https://github.com/snapcore/pc-amd64-gadget/pull/50
[08:44] <zyga-x240> +1
[08:45] <pedronis> dot-tobias: depending what kind of model grade you are building, you'll have to put the cloud-init config in the gadget itself
[08:50] <dot-tobias> pedronis: Thanks, re-read https://core.docs.ubuntu.com/en/reference/gadget at Setup files. Don't remember why I didn't go that route initially, but it's been > 1 year so why not try again. Could you please elaborate what you mean by “model grade”? 😊
[08:52] <pedronis> dot-tobias: https://core.docs.ubuntu.com/en/releases/uc20
[08:52] <pedronis> under Model definition
[08:54] <dot-tobias> pedronis: Thank you very much! Overlooked this page, I knew there was a new way to specify the channel for required snaps now …
[12:17] <dot-tobias> ijohnson: Re https://bugs.launchpad.net/snapd/+bug/1898622 – can you give me a hint where/which logs to check to see if this happens in my case as well? I have a local uc20 gadget snap (i.e. model grade set to “dangerous” + passing local snap via --snaps) and the image boots on a Pi 4, but only with a blinking cursor like the thread opener in https://forum.snapcraft.io/t/ubuntu-core-20-hangs-with-added-snap/20342.
[12:21] <ijohnson> hi dot-tobias
[12:22] <ijohnson> I see you had a couple questions earlier, did you get your cloud-init question answered firstly?
[12:22] <ijohnson> and secondly, re building the 20 pi-gadget, what architecture are you trying to build for and what's the host system where you are trying to build the gadget?
[12:24] <dot-tobias> hi ijohnson, sorry for brevity without proper thanks and please 😊 First:
[12:25] <ijohnson> haha no worries
[12:25] <dot-tobias> Re cloud-init: Kind of, I placed it in the gadget but can't test if it works because I first need to have it boot properly 😄 Like https://forum.snapcraft.io/t/how-to-preconfigure-custom-image/4154/15?u=tobias describes, at some point way back, cloud.conf in the gadget wasn't applied – at least in my testing. Feeding it to ubuntu-image worked.
[12:26] <ijohnson> dot-tobias: for uc20 specifically the inverse is now true, feeding to ubuntu-image no longer works, but putting it in your gadget should work, we have tests for this, but in all honesty I haven't tested it for a couple weeks now so maybe something has broken again on this front
[12:27] <dot-tobias> Second, the pi20-gadget: I'm trying to build for armhf, I applied your patch from https://github.com/snapcore/pi-gadget/pull/43 and it builds just fine on an amd64 host. Then I build the image with ubuntu-image and flash to an SD. The Pi 4 seems to boot, but only to a blinking cursor on the screen.
[12:29] <dot-tobias> ijohnson: Will let you know if cloud.conf inside gadget snaps works for me as soon as I have the system booting properly 😄
[12:31] <ijohnson> dot-tobias: ok, great happy to hear that patch works, I need to go back and address the comments on that pr before it can be merged but still good to know it works :-)
[12:31] <dot-tobias> ijohnson: Unfortunately, I have to hurry to pick up my daughter at kindergarden. May I DM you on the snapcraft forum, because my IRC bouncer isn't as reliable as I would like it to be?
[12:31] <ijohnson> dot-tobias: yes of course
[12:31] <ijohnson> I'll wait to hear from you there then
[12:31] <dot-tobias> s/at/from/i 😄 Great, thanks in advance ijohnson!
[13:04] <mborzecki> ijohnson: standup or are you at the roadmap review?
[13:04] <ijohnson> mborzecki: I'm watching the roadmap
[13:04]  * zyga-x240 is on roadmap review
[14:30] <ijohnson> cachio: have you seen the journal-state test fail like this: https://pastebin.ubuntu.com/p/HgxDDBNXgd/
[14:30] <ijohnson> ?
[14:31] <ijohnson> the code looks rather odd `test 0 -eq 1` will never be true no matter how many iterations are run ...
[14:31] <cachio> ijohnson, no, weird
[14:31] <cachio> let me check if I can reproduce it
[14:32] <cachio> ijohnson, just happening in ubuntu 20.10?
[14:32] <ijohnson> cachio: yes that's where I just saw it fail
[14:32] <ijohnson> cachio: also did you see my update in the su doc about uc20-recovery ?
[14:33] <ijohnson> I can reproduce it now like 80+% of the time with your qemu cmdline but 0% with my qemu cmdline
[14:33] <cachio> yes
[14:33] <ijohnson> it's very odd and confusing and frustrating
[14:33] <cachio> could be associated to "no secure boot"
[14:33] <cachio> ?
[14:34] <ijohnson> I don't think so because I changed my cmdline to boot without secure boot and still couldn't reproduce it
[14:44] <cachio> ijohnson, I could reproduce the error on jounal-state test
[14:45] <ijohnson> cachio: interesting, what's the issue?
[14:47] <cachio> ijohnson, don't know yet
[14:47] <cachio> just failed
[14:47] <ijohnson> well good that you can reproduce it, that's always better than not being able to reproduce it :-)
[14:49] <cachio> ijohnson, well, seems to be that I used incorrectly the retry
[14:50] <cachio> ijohnson, I'll fix it and create a PR
[14:58] <ijohnson> nice thanks
[15:04]  * zyga goes for PT
[15:33]  * cachio lunch
[15:51] <ijohnson> cachio: I just saw the journal-state test fail again this time on uc20: https://pastebin.ubuntu.com/p/xKPMcypjDq/ is it the same thing ?
[16:11] <mvo> pedronis: 9469 is the snapshot work as discussed last night, still some gaps in the tests but should be without races
[17:38] <ijohnson> cachio: I think I finally figured out the uc20-recovery problem with your qemu command line args, or at least some kind of explanation
[17:39] <ijohnson> cachio: your command line has this: `-net nic,model=virtio -net user,hostfwd=tcp::8022-:22` while mine has `-netdev user,id=mynet0,hostfwd=tcp::8026-:22 -device virtio-net-pci,netdev=mynet0`
[17:39] <ijohnson> I don't know precisely what the difference in behavior is, but if I use your qemu command line net args the test fails, but with mine it passes
[18:03] <cachio> ijohnson, nice
[18:03] <cachio> I'll update my docs to start using yours
[18:04] <cachio> thanks for the research
[18:20] <zyga> back from pT
[18:26] <ijohnson> hey zyga
[18:26] <zyga> hey!
[18:26] <ijohnson> I gave a +1 to your notifications pr last night, it looks good!
[18:27] <zyga> ijohnson thank you, I will iterate to add some tests and then ask macieck for a re-review
[18:27] <zyga> I think he and mvo asked for tests on IRC
[18:27] <ijohnson> I started and am about halfway through the biggest file on your udev pr too
[18:27] <zyga> ijohnson woot!
[18:27] <zyga> it's a bit tedious
[18:27] <zyga> but I tried to structure the boring parts to be readable
[18:27] <ijohnson> it is a bit tedious and takes some close eyes for sure
[18:27] <zyga> thank you so much! that's my oldest really useful PR that has yet to land
[18:27] <zyga> (well, others are older but this is ready IMO)
[18:28] <zyga> I'm working on spread tests for inhibition locks now, just got back and noticed the test failed, but it worked interactively in spread -debug shell
[18:28] <zyga> must be missing something simple :)
[18:28] <ijohnson> simple missing things are the best missing things imho
[18:35] <zyga> I got tea and am digging into things :)
[18:43] <zyga-x240> weird
[18:43] <zyga-x240> my other PC disconnected
[18:43] <zyga-x240> hmm
[18:44] <zyga-x240> back
[18:44] <zyga-x240> :)
[19:01] <zyga-x240> hmm, nothing looking out of the ordinary, trying -debug
[19:14] <zyga-x240> DOH
[19:14] <zyga-x240> ijohnson: + snap install --classic SNAP_NAME
[19:14] <zyga-x240> what could be wrong ;D
[19:14] <ijohnson> haha
[19:14] <ijohnson> SNAP_NAME
[19:14] <ijohnson> classic
[19:14] <zyga-x240> not enough $
[19:14] <zyga-x240> ;D
[19:14] <ijohnson> haha good one
[19:15] <zyga-x240> I was trying to come up with a way to get some measurements done while a compound operation like "snap refresh" runs
[19:15] <zyga-x240> and I ended up using inotify in tests
[19:15] <zyga-x240> I think that's a first for us
[19:16] <ijohnson> yeah all I see is a comment from Maciej about arch linux in prepare.sh about d-bus needing to inotify on some path
[19:16] <zyga-x240> I will break out a few helpers
[19:17] <zyga-x240> yeah, that's related to the fact that dbus uses inotify to detect .service files
[19:17] <zyga-x240> but this only works if the relevant directory exists at the time dbus itself starts
[19:17] <zyga-x240> so we created it so that it works on first install IIRC
[19:17] <zyga-x240> inotify is a pretty poor API
[19:17] <ijohnson> yep that's exactly what the comment says :-)
[19:17] <ijohnson> good memory!
[19:18] <zyga-x240> haha, this time
[19:18] <zyga-x240> I forget many many things now
[19:19] <zyga-x240> ijohnson: did you see the nvidia ai video conferencing thing?
[19:19] <ijohnson> zyga-x240: no I don't think so
[19:20] <zyga-x240> https://www.youtube.com/watch?v=NqmMnjJ6GEg
[19:20] <zyga-x240> pretty interesting IMO, would love to see this in practice
[19:22] <ijohnson> yeah that's really cool
[19:24] <ijohnson> I wonder how well it works with a non-static background though
[19:24] <zyga-x240> I suspect it needs more keyframes with real image
[19:24] <ijohnson> yeah
[19:25] <zyga-x240> but it's an interesting evolution of "motion vectors" and other classic video tricks
[19:25] <zyga-x240> cannot wait for voice equivalent
[19:25] <zyga-x240> bi-directional audio to text to audio codec
[19:25] <zyga-x240> with emotions :)
[19:26] <zyga-x240> maybe irc and mumble could merge
[19:26] <ijohnson> ah that's interesting, but I imagine very difficult to get right but without lots of data on individual users which is a bit of a privacy concern
[19:27] <ijohnson> like imagine if this service can impersonate the voice of someone you know / trust
[19:27] <ijohnson> with arbitrary text
[19:27] <zyga-x240> yeah
[19:27] <zyga-x240> I think in the age of deep fakes we are really there already
[19:27] <zyga-x240> this just makes it mass market
[19:28] <ijohnson> true I guess I just haven't seen that for audio yet
[19:28] <zyga-x240> (or so the AI overlord told me to type ;-)
[19:28] <ijohnson> deepfake video is definitely a thing which I guess implies that audio is already there and maybe it just wasn't scary enough to make headlines the way video did
[19:28] <zyga-x240> ijohnson: there's a bunch of "obama speaks anything" videos on YT, given that he's got lots of public domain recordings available
[19:29] <zyga-x240> no need to do trump variant though, he really speaks anything just like that ;-)
[19:29]  * zyga-x240 refrains from more political joes
[19:29] <zyga-x240> *jokes
[19:30] <ijohnson> look you just made one!
[19:30] <ijohnson> while trying to refrain from making them
[19:30]  * ijohnson goes away and tries to debug pi things
[19:30] <zyga-x240> haha
[19:58] <zyga-x240> so the test was useful
[19:59] <zyga-x240> I broke something in snapstate, checking
[19:59] <zyga-x240> I mean, in my branch
[19:59] <zyga-x240> it's just refactoring to make it fit the model
[20:18] <zyga-x240> DOh
[20:18] <zyga-x240> nothing is broken
[20:18] <zyga-x240> I patched the test in the wrong spot
[20:18]  * zyga-x240 adjusts
[20:20] <ijohnson> zyga-x240: could you +1 9378? I addressed your feedback and you said your review was a +0.9 :-)
[20:20] <zyga-x240> looking
[20:20] <ijohnson> cachio: also could you take a look again at #9378 ?
[20:20] <ijohnson> would be great to land this finally
[20:21] <zyga-x240> done, thanks for changing @HOLD...
[20:21] <ijohnson> thank you!
[20:22] <zyga-x240> cachio: btw, I realized that my comment about prepare/restore on nested helpers may have been confusing
[20:22] <zyga-x240> I didn't imply that we should not have prepare/restore
[20:23] <zyga-x240> but that they are unclear in the context of explicit resource management performed by other commands
[20:23] <zyga-x240> I'm sure all those functions do something useful
[20:23] <cachio> ijohnson, sure
[20:23] <zyga-x240> I was trying to understand their function and see if any of that functionality should shift from one command to another
[20:23] <cachio> zyga-x240, ah, ok
[20:24] <cachio> zyga-x240, I'll go back to that PR once I finish the current one
[20:24] <zyga-x240> ok
[20:26] <cachio> zyga-x240, you are talking about the nested one, right?
[20:26] <zyga-x240> yes
[20:27] <zyga-x240> cachio: btw, did you know about $'foo' in bash?
[20:27] <cachio> bo
[20:27] <cachio> no
[20:27] <cachio> zyga-x240, what?
[20:27] <zyga-x240> I found out today
[20:27] <zyga-x240> echo $'hello\n $world'
[20:28] <ijohnson> what does that do
[20:28] <zyga-x240> handles specific \ sequences
[20:28] <zyga-x240> acts as ' ' otherwise
[20:28] <zyga-x240> I also found
[20:28]  * ijohnson is ready to run for the hills at mention of more bashisms
[20:28] <zyga-x240> ${foo@Q}
[20:28] <zyga-x240> which is genuinely very useful
[20:28] <zyga-x240> it expands foo as variable and quotes correctly for bash to read again
[20:28] <zyga-x240> the @xxx syntax has a few more things it can do
[20:29] <zyga-x240> but this one is most practical for our stuff
[20:29] <zyga-x240> as it would let us quote things and pass to nested bash easily
[20:29] <zyga-x240> anyway
[20:29] <ijohnson> oooh that is really cool
[20:29] <zyga-x240> just more ladmines
[20:29] <zyga-x240> in the no-mans bash land
[20:29] <zyga-x240> just those pop candy
[20:29] <zyga-x240> not your leg off
[20:30] <cachio> zyga-x240, cool
[20:30] <cachio> zyga-x240, how did you discover that?
[20:30] <cachio> reading docs?
[20:31] <zyga-x240> cachio: by reading twitter and reading bash to correct an almost-useful reference
[20:31] <zyga-x240> and finding more
[20:31] <zyga-x240> "marry has a little lamb"
[20:31] <zyga-x240> !:q
[20:31] <zyga-x240> run that in a bash
[20:31] <zyga-x240> it's another quoting mechanism
[20:32] <zyga-x240> but only for interactive job
[20:32] <zyga-x240> ${foo@Q} is generic
[20:33] <cachio> zyga-x240, nice
[20:33] <cachio> learning bash in twitter hehehe
[20:34] <cachio> it is cool
[20:35]  * zyga-x240 should get green pass now
[20:37]  * zyga-x240 goes to brush his teeth
[20:37] <zyga-x240> cachio: I wrote a small add-on to tests.cleanup
[20:37] <zyga-x240> tests.cleanup pop
[20:37] <zyga-x240> it's useful when you do something
[20:37] <zyga-x240> install cleanup via defer
[20:38] <zyga-x240> want to clean up on failure (which runs in restore)
[20:38] <cachio> zyga-x240, awesome
[20:38] <zyga-x240> but also want to clean up early on the happy code path
[20:38] <zyga-x240> so that you don't have to repeat the "undo" logic in any way
[20:38] <zyga-x240> anyway, I'll clean that up (add tests) and propose tomorrow
[20:39] <zyga-x240> today I'm just going to see this inhibition lock test pass on 18.04 and 20.04 and call it a day
[20:54] <zyga-x240> OUCH
[20:54] <zyga-x240> I was cleaning the kitchen
[20:55] <zyga-x240> and we routinely cut milk boxes in half to clean them (those are recycled and get collected twice a month)
[20:55] <zyga-x240> and cut right through my thumb nail and good part of thumb
[20:55] <zyga-x240> so...
[20:55]  * zyga-x240 EODs
[20:55] <zyga-x240> but I got x3 pass
[20:55] <zyga-x240> so some good in the ene
[20:55] <zyga-x240> *end
[20:56]  * zyga-x240 pushed handlers changes, more tomorrow
[20:57] <zyga-x240> need to find some bandage
[20:57] <zyga-x240> good that I don't use my right thumb for typing that often
[20:57] <zyga-x240> my left thumb is space bar
[20:57] <zyga-x240> right.... dunno
[20:57] <zyga-x240> maybe sometimes space