=== WhatsGoingOn is now known as iMadper
[05:08] <mborzecki> morning
[05:47] <zyga> Hi
[05:47] <zyga> mborzecki: voting is over
[05:48] <mborzecki> zyga: yeah, it is
[05:48] <zyga> Could be better, could be worse
[05:48] <mborzecki> zyga: though, we have domestic round in october right? :)
[05:48] <zyga> Too bad 70% of young people did not vote
[05:49] <mborzecki> zyga: tbh, wasn't much to choose from
[05:49] <zyga> Yes, that will be critical
[05:49] <mborzecki> zyga: same faces each time
[05:49] <zyga> Eh
[05:49] <zyga> Yes, that is true
[05:50] <zyga> One more kid to send to school, ttyl
[05:52] <mborzecki> zyga: at least konfederacja is outside, don't think they need more lunatics in brussels
[06:13] <zyga> I’m happy to see wiosna, it means we are not all crazy yet
[06:26] <zyga> back in the office now
[06:26] <zyga> ok, time to set everything else aside
[06:26] <zyga> and look at initramfs
[06:26] <zyga> mborzecki: ping me for reviews
[06:26] <zyga> mborzecki: if you ever want a puzzle to solve https://github.com/snapcore/snapd/pull/6891 is critical for .1
[06:26] <mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
[06:26] <zyga> and has exactly one apparmor denial in one test on one system!!!
[06:26] <zyga> and I'm out of ideas why
[06:36] <mborzecki> zyga: on 14.04?
[06:39] <zyga> correct
[06:40] <zyga> on 14.04 only
[06:40] <zyga> 4.4 kernel
[06:40] <mvo> hey mborzecki and zyga - good morning!
[06:40] <zyga> and, to my looks, the denial is bogus because we have that rule
[06:40] <zyga> mvo: good morning!
[06:40] <zyga> mborzecki: I didn't look, at the time, about environmental differences, like /tmp tmpfs vs ext4
[06:40] <zyga> mborzecki: I know that a bare "mount," rule fixes it
[06:40] <zyga> and the denial was on flags
[06:40] <zyga> perhaps there's a bug on 14.04 parser
[06:41] <zyga> the bad thing is that apparmor blob format is opaque, I wrote some tools to disassemble it a while ago but I didn't manage to crack the essential part
[06:41] <mborzecki> mvo: hey
[06:41] <zyga> the encoding of the state engine transition tables
[06:41] <zyga> those are highly compressed and optimized
[06:41] <zyga> and I just didn't understand the kernel code that walks over them
[06:41] <zyga> there's no documentation that helps that I could find
[06:41] <zyga> mvo: hey
[06:41] <zyga> mvo: some bad news
[06:42] <zyga> mvo: the fix for the bug is blocked
[06:42] <zyga> I'm happy to HO to discuss this quickly
[06:42] <mborzecki> zyga: have you reached out to jdstrand_ or jjohansen maybe?
[06:42] <zyga> mborzecki: jj no, jdstrand yes
[06:42] <mborzecki> maybe it's like a known issue or sth :)
[06:42] <zyga> we talked about this on friday, no effect
[06:42] <zyga> nope
[06:42] <mvo> zyga: hm, ok - is there a tl;dr summary?
[06:44] <zyga> mvo: a single test fails, only on 14.04, it makes no sense: https://github.com/snapcore/snapd/pull/6891#issuecomment-495643768
[06:44] <mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
[06:44] <zyga> mvo: we get a single apparmor denial for a rule we definitely hold
[06:44] <zyga> mvo: requires jumps to kernel to debug
[06:46] <mvo> zyga: given that 14.04 is EOL I'm not sure we should block things. how bad is the denial?
[06:46] <zyga> mvo: snap-confine doesn't work
[06:46] <zyga> all snaps fail
[06:46] <zyga> it's not great
[06:46] <mvo> zyga: :(
[06:46] <zyga> see
[06:46] <mvo> zyga: it does not work *at all* ?
[06:46] <zyga> yes, it stops early on a mount permission and dies
[06:47] <zyga> mvo: I added "mount," rule and that fixes it
[06:47] <mup> PR snapd#6915 opened: spread: enable Fedora 30 (2.39) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6915>
[06:47] <zyga> but as soon as I try to express the arguments used by the call it is failing again
[06:48] <zyga> mvo: perhaps I missed something, it was late on friday
[06:48] <zyga> mvo: fresh pair of eyes (or even one) appreciated
[06:48] <mvo> zyga: what PR is it?
[06:48] <zyga> the one linked above, 6891
[06:49] <zyga> mvo: AFAIR we fail on line https://github.com/snapcore/snapd/pull/6891/files#diff-af477950316a096b57d91c74478bc4d2R252 which is handled by this rule https://github.com/snapcore/snapd/pull/6891/files#diff-798ce6f0668878eda67847b4ab492745R150
[06:49] <mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
[06:49] <zyga> but again, perhaps I missed something
[06:50] <zyga> but suspicious that it is only 14.04
[06:50] <zyga> other systems pass this test
[06:50] <mvo> zyga: looking
[06:50] <zyga> thank you!
[06:51] <zyga> mvo: note: failed flags match error says that apparmor found the rule for the mount path, but not for the flags
[06:51] <mup> PR snapd#6914 closed: tests: change strace parameters on snap-run test to avoid the test gets stuck <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6914>
[06:51] <zyga> that's very suspect IMO
[06:51] <zyga> flags are "rw, rshared" in the denial
[06:52] <zyga> anyway, back to initramfs
[06:52] <zyga> please ping me if you find anything
[06:56] <zyga> we should also look at "settle is not converging" bug
[06:56] <zyga> it is 100% reproducible in packaging builds
[06:56] <mup> PR snapd#6916 opened: cmd/snap-confine, tests: tweak comments, reenable symlink check in RHBZ 1584461 regression <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6916>
[06:56] <zyga> something fishy
[06:57] <mup> PR snapd#6895 closed: cmd/snap-confine, data/selinux: cherry pick Fedora 30 fixes to 2.39 <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6895>
[06:57] <mvo> mborzecki: do you have the comments in 6874 on your radar? the post-merge ones from jamie?
[06:59] <mborzecki> mvo: yup, opened #6916
[06:59] <mup> PR #6916: cmd/snap-confine, tests: tweak comments, reenable symlink check in RHBZ 1584461 regression <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6916>
[06:59] <mvo> mborzecki: \o/ thank you
[06:59] <zyga> it's even reviewed already :')
[07:00] <zyga> gnome shell bug where background doesn't render drives me crazy
[07:00] <zyga> quality of the linux desktop has never been thix mised
[07:00] <zyga> *mixed
[07:00] <mvo> woah
[07:00]  * mvo hugs zyga for already reviewing it
[07:00] <zyga> on one hand side it's really the golden age where hardware works great and there's lots of polish
[07:01] <zyga> on the other hand we're building a desktop shell in javascript and running it ends with stream of crap javascript errors
[07:01] <zyga> and this is cross dirstro: suse, ubuntu - all broken
=== pstolowski|Afk is now known as pstolowski
[07:01] <pstolowski> morning!
[07:01] <zyga> I'm afraid to update fedora (
[07:01] <zyga> hey pawel, good morning, welcome to our new right-wing world
[07:03] <zyga> huh, suse update resulted in EFI mok enroll?
[07:03] <zyga> (with an opensuse key)
[07:03] <mborzecki> pstolowski: hey
[07:03] <mborzecki> zyga: background doesn't render?
[07:03] <zyga> yep
[07:04] <mborzecki> zyga: how so?
[07:04] <zyga> https://www.irccloud.com/pastebin/Sjl5oiPM/
[07:04] <zyga> like this
[07:04] <zyga> if you google for the "tweener" and some other messages it's a pretty widespread problem
[07:05] <zyga> doesn't *for whatever reason* happen on wayland
[07:05] <zyga> happens 100% on X11 on all my up-to-date distros
[07:05] <zyga> must be the new shell
[07:05] <zyga> 18.04 is ok
[07:05] <zyga> the key is May 27 09:04:22 fyke gnome-shell[3767]: Object Meta.Background (0x5584c4024190), has been already deallocated — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
[07:05] <zyga> nothing like working on bright white background in the morning
[07:06] <zyga> oh, suse update just fixed it
[07:07] <mborzecki> zyga: hm, that's been fixed afaik
[07:07] <zyga> right
[07:07] <zyga> QA
[07:08] <mborzecki> zyga: i think you also need to have some specific extensions to trigger that
[07:08] <zyga> 100% vanilla
[07:08] <zyga> but anyway, even if that is true
[07:08] <zyga> do you recall something this silly in any old desktops?
[07:08] <zyga> I mean, ever?
[07:09] <mborzecki> hmmm, let me think, gnome panel going crazy was rather common
[07:09] <mborzecki> kde crashed a lot too
[07:09] <zyga> so now we traded crashes to javascript errors on mouse motion
[07:09] <mup> PR snapd#6835 closed: snapstate: allow removal of non-model kernels <Remodel :train:> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6835>
[07:09] <zyga> guess that's just inevitabale ;)
[07:09] <mborzecki> zyga: it's called progress :P
[07:09] <mborzecki> zyga: at least it's not an electron app
[07:10] <mvo> yet!
[07:10] <mborzecki> Download snap "snapd-hacker-toolbelt" (26) from channel "stable" (received an unexpected http response code (408) when trying to download https://api.snapcraft.io/api/v1/snaps/download/FMONi3pH7TfSv15FusziadAGCjQ6t4EG_26.snap)
[07:11] <mvo> hm, do we retry on 408? it seems we should
[07:25] <pedronis> mvo: hi, I made a comment after it was merged on #6835
[07:25] <mup> PR #6835: snapstate: allow removal of non-model kernels <Remodel :train:> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6835>
[07:26] <mvo> pedronis: thank you! I will do a followup with your comments and refactor this code a bit
[07:30] <mvo> zyga: there is some funny stuff happening in the VM with the fix for 6891 - the test failed on 14.04, I ran it manually and it failed. I ran it again and now its not failing anymore
[07:30] <zyga> !??!
[07:30] <zyga> whaat
[07:30] <mvo> zyga: yeah, quite puzzling
[07:30] <zyga> can you discard and re-run
[07:30] <zyga> does it fail?
[07:30] <mvo> zyga: I'm looking at the profiles not etc
[07:30] <zyga> I mean, it seems to fail on just construction
[07:30] <mvo> zyga: sure, one sec
[07:30] <zyga> so discarding and running that hello command should be enough
[07:30] <mborzecki> got to go to school to pick up my son, he's not feeling too well, back in a bit
[07:31] <mvo> zyga: just looking at the timestamp of the apparmor profile to double check nothing has changed
[07:31] <zyga> mvo: remember about reexec, are you editing the right profile?
[07:31] <zyga> mborzecki: o/
[07:32] <mvo> zyga: I did not edit anything so far and tried "SNAP_REXEC=0|1" without any difference this is why I'm puzzled :)
[07:33] <mvo> zyga: aha, now its consistently failing again, but I need to set "SNAP_REEXEC=1 ..."
[07:33] <zyga> indeed, that's a good find though
[07:33] <zyga> we repackage, right?
[07:34] <zyga> so reexec vs not should not matter
[07:34] <mvo> zyga: let me compare the profiles
[07:36] <mvo> zyga: hm, so /var/lib/snapd/apparmor/snap-confine.snapd.x1 seems to miss bits, i.e. the rshared bits that got added
[07:37] <mvo> zyga: it looks like the profile is outdated
[07:37] <zyga> hmmmmm
[07:37] <zyga> that's weird
[07:37] <zyga> repackaging is broken?
[07:37] <mvo> zyga: which of course raises the question - why on 14.04 only?
[07:37] <zyga> exactly!
[07:38] <mvo> zyga: oh, maybe because we have some strange if 14.04 in the prepare code :(
[07:38] <mvo> zyga: let me look
[07:38] <zyga> some tabs-vs-spaces in prepare-restore.sh
[07:40] <zyga> mvo: I don't see any smoking guns, looking at delta in packaging/
[07:41] <mvo> zyga: let me poke at this, I have an idea
[07:41] <zyga> mvo: there's a difference wrt .real vs non profile
[07:41] <zyga> maybe what we are hitting is a bug in snapd + packaging
[07:42] <zyga> 14.04 doesn't have the .real suffix
[07:42] <zyga> mvo: we should drop the .real suffix in 19.10
[07:42] <zyga> mvo: I'll keep you to it, thank you for looking and for the insight
[07:43] <zyga> I'll resume initramfs poking
[07:43] <mvo> zyga: thank you!
[07:43]  * zyga hugs mvo! :)
[07:43] <mvo> zyga: yeah, let me poke for 5min and hopefully I get an idea
[07:43] <mvo> zyga: no sense in duplicating the effort
[08:00] <mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
[08:00] <mup> PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
[08:00] <mup> PR pc-amd64-gadget#14 closed: gadget.yaml: add system-recovery partition <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/14>
[08:01] <mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
[08:01] <mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
[08:01] <mup> PR pc-amd64-gadget#14 opened: gadget.yaml: add system-recovery partition <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/14>
[08:02] <mborzecki> re
[08:27] <mup> PR snapd#6917 opened: Add endpoint for snap download in the daemon <Created by glower> <https://github.com/snapcore/snapd/pull/6917>
[08:30] <mborzecki> zyga: i think i can split #6890
[08:30] <mup> PR #6890: gadget: mounted filesystem writer & updater <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6890>
[08:49] <zyga> mborzecki: in a call
[08:58] <zyga> re
[08:58] <zyga> mborzecki: that's neat, thank you, I will be looking at gadget reviews all week; please let me know which one to start with
[08:59] <zyga> * as long as it's not the 2K one
[08:59] <mborzecki> zyga: haha :)
[09:01] <mvo> zyga: I am running a final test now on 6891 now, if its green I push a 2 line fix in the test setup to it (if you don't mind)
[09:01] <zyga> mvo: how could I mind :D
[09:01] <zyga> mvo: thank you so much
[09:14] <mvo> zyga: worked locally, pushed now
[09:15] <zyga> \o/
[09:15] <zyga> thank you!
[09:18] <zyga> brb, need to run an errand at school, 30min
[09:23]  * pstolowski needs to run an errand, bb in ~1h
[09:45] <zyga> back now
[09:49] <mup> PR snapd#6918 opened: snaptest: add helper for mocking snap with contents <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6918>
[09:49] <mborzecki> a really simple one ^^
[10:08] <zyga> mborzecki: don't we have something like that already?
[10:08] <zyga> mborzecki: +1 on the patch but perhaps look at the tree, I'm pretty sure we have ad-hoc implementations
[10:08] <zyga> that could be reduced
[10:08] <mborzecki> zyga: afaik no, we have something that packs a *.snap, but that's not what i'm looking for
[10:09] <zyga> I mean there are bits that drop files on disk, along with a meta/snap.yaml
[10:09] <zyga> then parse the yaml and return that
[10:09] <zyga> we have way too many helpers like that
[10:09] <zyga> it'd be great if all such helpers *had to* use snaptest
[10:11] <pedronis> we did a pass of reducing that afaik, that's were the helper are coming in the first place, might still be some
[10:11] <mborzecki> zyga: to be precise, i don't see anything similar in snaptest, there's bits in random tests that do ioutil.WriteFile
[10:11] <pedronis> *where
[10:11] <zyga> yeah
[10:11] <zyga> that's what I mean
[10:12] <mborzecki> zyga: tbh, this is pulled from #6750 which.. introduces such helper locally :)
[10:12] <mup> PR #6750: overlord/devicestate: update-gadget task handler with stubbed gadget callbacks <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6750>
[10:14] <pedronis> zyga: mborzecki: I don't think it should be a blocker either way, the test grew organically, also if all it's inolved is a couple WriteFile, it's unclear if the helper are a big win or not
[10:14] <zyga> +1
[10:24] <zyga> mvo: https://github.com/snapcore/snapd/pull/6891 is green!
[10:24] <mup> PR #6891: many: make per-snap mount namespace MS_SHARED <Created by zyga> <https://github.com/snapcore/snapd/pull/6891>
[10:26] <mvo> zyga: yay! once its in we need to make sure we have a 2.39 PR too
[10:26] <mvo> zyga: but we can discuss in the standup
[10:26] <mvo> zyga: maybe we add this in .40 only
[10:27] <zyga> mvo: yeah, let's review it first!
[10:27] <mborzecki> pedronis: about https://github.com/snapcore/snapd/pull/6750/files/34e6a2ba202c127efa934e72d2cd6f57d429a8d1#r281945201 you're thinking some operation log for later auditing?
[10:27] <mup> PR #6750: overlord/devicestate: update-gadget task handler with stubbed gadget callbacks <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6750>
[10:52] <zyga> brr
[10:52] <zyga> brb :)
[10:58] <pstolowski> re
[11:09] <mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/6918/
[11:09] <mup> PR #6918: snaptest: add helper for mocking snap with contents <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6918>
[11:09] <pstolowski> k
[11:09] <mborzecki> pstolowski: thanks!
[11:20] <pedronis> mborzecki: yes, and also to help debugging
[11:28] <mup> PR snapd#6918 closed: snaptest: add helper for mocking snap with contents <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6918>
=== ricab is now known as ricab|lunch
[11:50] <mborzecki> no space left on device keeps breaking the builds from time to time: https://paste.ubuntu.com/p/TjtdxMmKzB/
[12:10] <pstolowski> mvo: https://github.com/snapcore/snapd/pull/6899 needs de-conflicting
[12:10] <mup> PR #6899: image: make prepare-image recovery-system aware <Created by mvo5> <https://github.com/snapcore/snapd/pull/6899>
[12:12] <pstolowski> pedronis: also, remodelling PRs have conflicts
[12:13] <pstolowski> zyga: hey, what's the status of https://github.com/snapcore/snapd/pull/6347 ?
[12:13] <mup> PR #6347: many: allow snap-update-ns to write user mount profile <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6347>
[12:15] <pedronis> mvo: pstolowski: I applied some of the feedback to #6838
[12:15] <mup> PR #6838: overlord/devicestate: introduce remodel kinds and contexts <Remodel :train:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/6838>
[12:18] <pstolowski> thanks, i'll finish this review
[12:19] <zyga> pstolowski: hey, a little bit on hold this week, I mergef fmaster into them on Friday but I need a moment to iterate towards something reviewable
[12:21] <pstolowski> zyga: k
[12:46] <pstolowski> pedronis: 2 small questions to the PR
[12:50] <mup> PR snapd#6916 closed: cmd/snap-confine, tests: tweak comments, reenable symlink check in RHBZ 1584461 regression <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6916>
=== ricab|lunch is now known as ricab
[13:35] <pstolowski> mvo: what was the 19.10 low-hanging fruit you mentioned in the standup?
[13:37] <roadmr> 🍎  🍌  🍇
[13:41] <pedronis> pstolowski: --explain but it needs some design, so I don't think it's that low hanging
[13:42]  * zyga goes for lunch
[13:47] <pstolowski> pedronis: i see
[13:52] <pedronis> pstolowski: what is the status of the slot-snap-type changes? and of fixing the content bug in a more general way?
[14:04] <pstolowski> pedronis: still needs work, i need to return to that branch. as mentioned before some i found a few interfaces problematic
[14:04] <pedronis> pstolowski: I probably need to understand the problem to help
[14:06] <pstolowski> pedronis: i'll check that branch and summarize then issue(s), then get back to you
[14:19]  * zyga finished lunch, thinking about either taking a short break and walk or getting coffeee
[14:19] <zyga> after that, grub.cfg hacking :)
[14:19] <zyga> and some more fun in initramfs
[14:25]  * cachio afk
[14:32] <pedronis> pstolowski: thx
[15:02] <mvo> sil2100: do you think you can look at https://github.com/snapcore/pc-amd64-gadget/pull/14 ? note that it will only be in the new "20" branch (which is only used for experimental UC20 images) so very low risk
[15:02] <mup> PR pc-amd64-gadget#14: gadget.yaml: add system-recovery partition <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/14>
[15:07] <sil2100> mvo: hey! Sure thing - I'll have a quick fix for core18 PR'ed soon, can I poke you for a review of that one in return? ;)
[15:08] <mvo> sil2100: sure
[15:14] <mup> PR core18#130 opened: gpg (dirmngr actually) panics when there's no random/urandom <Created by sil2100> <https://github.com/snapcore/core18/pull/130>
[15:17] <sil2100> mvo: ^ that's the PR I was talking about, just pushed the latest version. Let me look at your PR now o/
[15:17] <sil2100> (I'll have to look why it suddenly stopped working though, out of curiosity)
[15:20] <mvo> sil2100: yeah, I would love to figure out why it stops working, maybe a snapcraft change?
[15:25] <mvo> sil2100: so you have a link to the failure without the pr 130?
[15:25] <mup> PR #130: Basic kernel/os handling <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/130>
[15:26] <sil2100> mvo: you can reproduce it locally even, so I just checked and the reason is that now in our ubuntu-base tarballs our /dev directory is empty
[15:26] <sil2100> mvo: previously we had all the /dev/random and /dev/urandom shipped in the tarball
[15:26] <sil2100> Need to check if that's intentional that they're gone
[15:27] <sil2100> mvo: (as for failures, you can see them on LP as well: https://launchpad.net/~ubuntu-core-service/+snap/core18)
[15:27] <sil2100> But as said, it's just that the base tarball stopped shipping those - investigating why now
[15:33] <mvo> sil2100: aha, nice. thanks for digging into the root cause
[15:39] <sil2100> mvo: ok, I guess this is due to livecd-rootfs 2.525.23 ;/ Apparently this change was made for docker, will have to ask mwhudson a bit about this one then
[15:39] <sil2100> "Backport two minimizations for the docker images: remove apt lists that are removed downstream anyway, and remove device nodes from the image. (LP: #1828118)"
[15:39] <mup> Bug #1828118: docker tarballs contain /dev/null <verification-done> <verification-done-bionic> <verification-done-cosmic> <verification-done-disco> <livecd-rootfs (Ubuntu):Fix Released> <livecd-rootfs (Ubuntu Bionic):Fix Released> <livecd-rootfs (Ubuntu Cosmic):Fix Released> <livecd-rootfs (Ubuntu
[15:39] <mup> Disco):Fix Released> <https://launchpad.net/bugs/1828118>
[15:41] <sil2100> mvo: I guess this might be an architectual question what we should actually expect having in the ubuntu-base tarball
[15:42] <sil2100> Maybe I should add some conditionals checking for the existance of these files and only then create/delete them
[15:42] <sil2100> Actually, wonder what happening in the end snap
[15:56]  * cachio lunch
[16:02] <sil2100> Ok, images with the snap work - but still, let me bring that up with Steve
[16:06] <mvo> sil2100: ta
[16:07] <mvo> sil2100: yeah, the change itself looks fine but I'm a bit worried it might have unintended side-effects
=== pstolowski is now known as pstolowski|afk
[16:37] <mup> PR core18#130 closed: gpg (dirmngr actually) panics when there's no random/urandom <Created by sil2100> <Merged by sil2100> <https://github.com/snapcore/core18/pull/130>
[17:08]  * zyga was going through some core20 ideas during the walk
[17:08] <zyga> now shower and more work :)
[19:31]  * cachio afk
[19:44] <mup> PR snapd#6915 closed: spread: enable Fedora 30 (2.39) <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6915>
[20:00] <mup> PR snapd#6838 closed: overlord/devicestate: introduce remodel kinds and contexts <Remodel :train:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6838>
[21:07] <mup> PR snapd#6919 opened: cmd/okay: Remove err message when warning file not exist <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/6919>
[21:10] <mwhudson> wait, ubuntu-base:minimized builds are used for core18??