=== Ringtailed_Fox is now known as RingtailedFox
[00:53] <mup> PR snapcraft#3226 closed: extensions: kde-neon: use gtk3 platform theme on gtk-based DE's <bug> <Created by galgalesh> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3226>
[02:05] <mup> PR snapd#9067 opened: cmd/snap-bootstrap/initramfs-mounts: add doSystemdMount + unit tests <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9067>
=== benfrancis5 is now known as benfrancis
[04:46] <mborzecki> morning
[06:23] <zyga> hello
[06:23] <zyga> I tried to dput the .3 release again at 4AM but it was rejected, - the orig tarball is not removed from te ppa yet
[06:24] <zyga> I wonder if we could ask someone from launchpad for help
[06:24] <zyga> I can upload the signed release somewhere so that after the turmoil ends someone else can dput it
[06:24] <zyga> mborzecki: ^
[06:25] <mborzecki> zyga: hey, what do i need to dput it?
[06:25] <zyga> I've sent a copy to maciek
[06:25] <zyga> you need dput
[06:25] <zyga> the magic line is
[06:26] <zyga> dput ppa:snappy-dev/image snapd_2.45.3_source.changes
[06:26] <zyga> brb, let me get a shower
[06:26] <zyga> I'm leaving at 11:30
[06:35] <zyga> I can try to dput now
[06:35] <zyga> and maybe you can ask in #launchpad
[06:36] <zyga> if they can somehow speed up the removal / garbage collection of the 2.45.3 release leftovers
[06:36] <zyga> I will dput now
[06:36] <zyga> dput always works if the release is valid
[06:36] <zyga> but an email sent later
[06:36] <mup> PR snapd#9068 opened: tests/main/selinux-clean: workaround SELinux denials triggered by linger setup on Centos8 <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9068>
[06:36] <zyga> tells you if you were successful or not
[06:36] <zyga> I fear the email goes to me
[06:36] <zyga> as I signed the release
[06:37] <zyga> I just got another rejected message
[06:37] <zyga> ok, afk again, I will try to manage the shower now
[06:37] <mborzecki> via email?
[06:37] <zyga> and double check my bag
[06:37] <zyga> yes
[06:53] <Saviq> mborzecki: hey (late reply) - no, Multipass does not plug removable media, what's the use case?
[06:54] <mborzecki> Saviq: hey, a scenario when you build a snap using snapcraft & mutipass, and your source tree is somewhere under /media, that would not work currently, would it?
[06:55] <Saviq> mborzecki: it should, we're re-confining the mount process
[06:58] <Saviq> mborzecki: ah hmm, but the `multipass` app will barf on trying to mount b/c of ENOPERM
[06:58] <mborzecki> Saviq: that's what i was suspecting, but i'm trying to mount something locally now
[07:12] <Saviq> mborzecki: https://github.com/canonical/multipass/issues/1598 btw
[07:13] <mborzecki> Saviq: btw. can you try to mount something, unmount and mount the same path again? does it work for you?
[07:20] <mborzecki> Saviq: https://paste.ubuntu.com/p/vYptW9MPPB/ pretty sure it worked once, i could see content under ~/Home in the vm
[07:54] <Saviq> mborzecki: worked just fine
[07:55] <Saviq> nothing in your log suggests it didn't…
[08:15] <mborzecki> Saviq: hmm for some reason ~/Home was empty, i can try a look into that later
[08:21] <mup> PR snapd#9069 opened: tests/main/selinux-clean: workaround SELinux denials triggered by linger setup on Centos8 (2.45) <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9069>
[08:43] <mborzecki> the tumbleweed images are broken apparently
[08:44] <mborzecki> 2020-07-27T21:56:14.0598453Z 2020-07-27 21:56:14 Server google:opensuse-tumbleweed-64 (jul272153-296516) is taking a while to boot...
[08:44] <mborzecki> 2020-07-27T21:57:13.1611691Z 2020-07-27 21:57:13 Cannot allocate google:opensuse-tumbleweed-64: cannot allocate new Google server google:opensuse-tumbleweed-64 (jul272153-296356): cannot find ready marker in console output for google:opensuse-tumbleweed-64 (jul272153-296356)
[10:45] <ijohnson> mborzecki: I approved https://github.com/snapcore/snapd/pull/9019, but it seems it needs a merge from master to pick up some fixes
[10:45] <mup> PR #9019: tests/nested/minimal/minimal-smoke: run core smoke tests in a VM meeting minimal requirements <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9019>
[10:45] <mborzecki> ijohnson: thanks, let me update it now
[10:48] <pedronis> ijohnson: hi, I reviewed #9063
[10:48] <mup> PR #9063: cmd/snap/debug: add "snap debug seeding" command for preseeding debugging (4/N) <Preseeding 🍞> <Run nested> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9063>
[10:48] <ijohnson> hi pedronis thanks, let me take a look
[10:59] <pedronis> ijohnson: also #9067
[10:59] <mup> PR #9067: cmd/snap-bootstrap/initramfs-mounts: add doSystemdMount + unit tests <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9067>
[11:24] <pedronis> ijohnson: I answered to some of mborzecki comments to #9063 with my input
[11:24] <mup> PR #9063: cmd/snap/debug: add "snap debug seeding" command for preseeding debugging (4/N) <Preseeding 🍞> <Run nested> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9063>
[11:25] <ijohnson> thanks pedronis makes sense
[11:31] <ijohnson> pedronis: I wonder if we should have the api for debug seeding use *time.Time in the response, that would make the JSON not include things like `0001-01-01T00:00:00Z` for some cases, it would slightly complicate the logic to test for nil, but maybe that would be good
[11:32] <pedronis> ijohnson: I thought of that, and is a bit cleaner, otoh it's a debug api, but if you want to do that, it's ok with me
[11:32] <ijohnson> I was just looking at the case for classic system that was not preseeded, and the time result is very confusing actually, 2562047h47m16.855s is actually like 292 years so I'm a bit confused how we got that result
[11:33] <ijohnson> I would have expected in that case an output like `seeding-time: -` because we don't actually have in the state.json how long seeding took
[11:33] <pedronis> we have seed-time
[11:33] <pedronis> but not seed-start-time
[11:34] <pedronis> there might be a few more cases where the client code needs to ignore values
[11:34] <ijohnson> sorry when I said `seeding-time: -` I meant `seeding-completion: -`
[11:35] <ijohnson> so what would you expect `seed-completion` to show in that case where we don't have a seed-start-time ?
[11:35] <pedronis> ijohnson: yes, my point is, we have had seed-time since long time
[11:35] <ijohnson> I mean at the end of the day this is a debug command
[11:35] <ijohnson> if it shows weird things on unsupported scenarios it's probably ok
[11:36] <pedronis> yes, otherwise I would say either ? or -
[11:36] <pedronis> or we need to think if we can guess a start-seed-time but it gets weird
[11:36] <ijohnson> I will timebox it, if I can fix it in 10 minutes I will fix it, otherwise classic / non-preseeded systems will just be buggy with this command
[11:37] <pedronis> why classic?
[11:37] <pedronis> you just mean older systems without all the values, no?
[11:38] <ijohnson> yeah sorry that's what I mean
[11:38] <pedronis> ah ok
[11:38] <ijohnson> I just said classic cause I can test this case easily on my classic system
[11:38] <ijohnson> BTW when was SeedTime added ?
[11:38] <ijohnson> err
[11:38] <ijohnson> seed-time
[11:38] <pedronis> I would need to check
[11:39] <ijohnson> was that a long long time ago sufficient that I can probably assume it will always be there ?
[11:40] <pedronis> ijohnson: I think it was added when we added the 2h delay for classic
[11:40] <pedronis> but it will take me a bit to confirm because the code has been moved around
[11:40] <pedronis> so blame doesn't give an immediate result
[11:41] <ijohnson> that's ok, I will assume it's always there and if it's not I think the code will just do "-" anyways I think
[11:45] <pedronis> ijohnson: Mar 2018
[11:45] <pedronis> so bionic times
[11:45] <ijohnson> mmm seems old enough to me to say that it will always be there
[11:45] <ijohnson> for a debug command at least
[11:45] <pedronis> yes
[12:01] <mborzecki> ijohnson: https://github.com/snapcore/snapd/pull/9064 spread jobs are close to finishing, we should restart it once more to make sure that caching of snapd snap job works
[12:01] <mup> PR #9064: .github/workflows: move snap building to test.yaml as separate cached job <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9064>
[12:02] <mborzecki> ijohnson: and btw the artifact is available already
[12:03] <ijohnson> mmm nice
[12:03] <ijohnson> so probably it shows up after the first run, and if you restart it, it doesn't discard that one from the UI
[12:04] <mborzecki> pedronis: https://github.com/snapcore/snapd/pull/9066 i think this one can be merged now, the failure on arch is unrelated (actually got 408 from the store)
[12:04] <mup> PR #9066: o/ifacestate: fix bug in snapsWithSecurityProfiles <Bug> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9066>
[12:08] <ijohnson> ok, made all the local changes, seems it took a bit longer than 10 minutes but meh
[12:34] <mup> PR snapcraft#3232 opened: build providers: install apt-transport-https <bug> <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3232>
[12:54] <mborzecki> cachio: hey, tumbleweed images seem to be broken, were they updated recently?
[12:54] <ijohnson> pedronis: #9067 is updated with your feedback addressed
[12:54] <mup> PR #9067: cmd/snap-bootstrap/initramfs-mounts: add doSystemdMount + unit tests <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9067>
[12:55] <cachio> mborzecki, hey, yes, yesterday
[12:55] <cachio> do you have a link to see the error?
[12:55] <mborzecki> cachio: 2020-07-28 11:10:01 Cannot allocate google:opensuse-tumbleweed-64: cannot allocate new Google server google:opensuse-tumbleweed-64 (jul280906-365867): cannot find ready marker in console output for google:opensuse-tumbleweed-64 (jul280906-365867)
[12:55] <mborzecki> this is all i get
[12:55] <mborzecki> cachio: looks like they are not booting at all?
[12:56] <cachio> yes
[12:56] <cachio> I can revert the image
[12:56] <ijohnson> mborzecki: did you restart spread on #9064 ? if so then the caching didn't work
[12:56] <mup> PR #9064: .github/workflows: move snap building to test.yaml as separate cached job <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9064>
[12:57] <mborzecki> ijohnson: no, i haven't
[12:57] <cachio> mborzecki, let me take a look first
[12:57] <ijohnson> mborzecki: ah ok
[12:57] <ijohnson> mborzecki: I will re-run spread after the current round of runs finishes
[12:57] <ijohnson> to ensure that the caching works
[12:57] <mborzecki> ijohnson: ok
[12:57] <mborzecki> hope the queue is not stuck again
[12:58] <ijohnson> mborzecki: no all the jobs are in progress, I just saw you approved, and wasn't clear if you approved because you saw the cacching work after restarting it or not
[12:58] <pedronis> mborzecki: thx, merged, I will prepare a backport a bit later
[13:01] <cachio> mborzecki, I see 2020-07-28T13:00:33.756313+00:00 localhost systemd-vconsole-setup[3050]: syntax error, unexpected ERROR
[13:01] <cachio> 2020-07-28T13:00:33.758590+00:00 localhost systemd-vconsole-setup[3049]: /usr/bin/loadkeys failed with exit status 1.
[13:01] <mborzecki> cachio: that's on the console with updated image?
[13:02] <cachio> mborzecki, yes
[13:03] <mup> PR snapd#9066 closed: o/ifacestate: fix bug in snapsWithSecurityProfiles <Bug> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9066>
[13:13] <Gargoyle> Hi.
[13:13] <Gargoyle> Why won't you fix your mailserver?
[13:31] <mborzecki> quick errand to pick up the pi4
[14:07] <mborzecki> re
[14:28] <mborzecki> geee restarted the spread job in #9006 since the build status was showing like half of jobs queued
[14:28] <mup> PR #9006: bootloader: compose command line with mode and extra arguments <Squash-merge> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9006>
[14:30] <mborzecki> now after restart, most of them are complete, and it's not the first time, as if there's some issue reporting job status
[15:01] <mborzecki> cachio: fwiw the tumbleweed spread jobs are running again, have you reverted the image?
[15:10] <cachio> mborzecki, yes
[15:11] <mborzecki> cachio: cool, thank you!
[15:11] <cachio> I am creating a new image to test
[15:11] <cachio> mborzecki, yaw
[16:19] <cachio> ijohnson, cmatsuoka hey
[16:19] <cachio> I see hte new logs https://paste.ubuntu.com/p/F5HvDdvvnW/
[16:19] <cachio> and the reboots are related to this error ide_atapi_cmd_error
[16:19] <cachio> look at line 1578
[16:20] <cachio> also I see this: vmport: unknown command 56
[16:23] <ijohnson> cachio: ah that's really interesting I bet that's related
[16:32]  * ijohnson afk for break
[16:36]  * cachio lunch
[17:01]  * ijohnson considers getting a specific boot for kicking github actions more
[17:29] <mup> PR snapd#9070 opened: o/ifacestate: fix bug in snapsWithSecurityProfiles (2.45) <Created by pedronis> <https://github.com/snapcore/snapd/pull/9070>
[17:30] <cmatsuoka> cachio: ah interesting
[17:31] <pedronis> mborzecki: ijohnson: backport ^
[17:34] <pedronis> ijohnson: mmh, #9070 is running a differen set of tests?
[17:34] <mup> PR #9070: o/ifacestate: fix bug in snapsWithSecurityProfiles (2.45) <Created by pedronis> <https://github.com/snapcore/snapd/pull/9070>
[17:34] <ijohnson> pedronis: hmm ?
[17:34]  * ijohnson looks
[17:34] <ijohnson> woah what
[17:35] <pedronis> maybe I'm just confused, and some haven't been added yet?
[17:35] <pedronis> we haven't pushed changes to actions to 2.45
[17:36] <pedronis> also Maciej's previous PR today had all the tests
[17:36] <ijohnson> I'd say let's just wait to see what happens
[17:37] <pedronis> this looks fine: https://github.com/snapcore/snapd/pull/9069
[17:37] <mup> PR #9069: tests/main/selinux-clean: workaround SELinux denials triggered by linger setup on Centos8 (2.45) <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9069>
[17:39] <cachio> cmatsuoka, I am running now with more specific traces
[17:39] <cachio> to see if I can find something else
[17:40] <cmatsuoka> cachio: nice, I'm checking that unknown command to see what that could be
[17:46] <ijohnson> pedronis: ah ok, so after the unit test runs passed, I see all the spread ones show up now too
[17:46] <pedronis> ok, just me confused
[17:46] <pedronis> good
[17:46] <ijohnson> pedronis: so I think the UI is just slow to show them all
[17:47] <ijohnson> pedronis: it might have something to do with those checks not being required for the release branch
[17:47] <ijohnson> I dunno though
[17:59] <mup> PR snapd#8677 closed: cmd/snap, daemon: detect and bail purge on multi-snap <Simple 😃> <Test Robustness> <Created by chipaca> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8677>
[18:08] <pedronis> ijohnson: can you look at #9068, I made a comment but not sure it makes sense or not
[18:08] <mup> PR #9068: tests/main/selinux-clean: workaround SELinux denials triggered by linger setup on Centos8 <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9068>
[18:08] <ijohnson> sure I can look but I'm no SELinux expert
[18:10] <ijohnson> thanks for the reviews pedronis
[18:20] <cachio> cmatsuoka, I reproduced this as well
[18:20] <cachio> https://paste.ubuntu.com/p/FcBqbvC4jj/
=== pedronis_ is now known as pedronis
[18:30] <mup> PR snapcraft#3222 closed: fix typo <bug> <Created by snshn> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3222>
[18:30] <mup> PR snapcraft#3223 closed: sentry: don't report tool missing errors <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3223>
[18:31] <ijohnson> cachio: can you resolve the conflicts in https://github.com/snapcore/snapd/pull/8558?
[18:31] <mup> PR #8558: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558>
[18:32] <cmatsuoka> cachio: I think the log is not in the last paste
[18:32] <cmatsuoka> it's one level of indirection away
[18:32] <cachio> ijohnson, I think I'll close that one and open this in small ones
[18:33] <ijohnson> cachio: ack sounds goof
[18:33] <ijohnson> *good
[18:35] <mup> PR snapcraft#3171 closed: snap: debug enabled by default <do-not-merge> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3171>
[18:37] <cmatsuoka> cachio: could you try with -machine q35,vmport=off
[18:39] <cmatsuoka> cachio: the unknown vmport command should be only a debug message, it doesn't seem that the crash is related to it but that property disables vmport
[18:43] <cachio> surew
[18:43] <cachio> cmatsuoka, running
[18:51] <cmatsuoka> cachio: my expectation is that it will still crash, but you won't see the vmport message in logs
[18:54] <mup> PR snapd#9069 closed: tests/main/selinux-clean: workaround SELinux denials triggered by linger setup on Centos8 (2.45) <Simple 😃> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9069>
[18:56] <cmatsuoka> cachio: these are the known vmware i/o port commands, they go from 0 to 43: https://sites.google.com/site/chitchatvmback/backdoor
[18:57] <cachio> checking
[19:00] <mup> PR snapcraft#3147 closed: Use `pylxd` instead of `lxc exec` <Created by abitrolly> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3147>
[19:00] <mup> PR snapcraft#3156 closed: log: trace HTTP connections with developer debug <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3156>
[19:15] <mup> PR snapcraft#2890 closed: extensions: add opengl extension to support classic and strict <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2890>
[19:16] <cachio> cmatsuoka, well, with the vmport=off the command error is not shown anymore
[19:20] <mup> PR snapcraft#2413 closed: kernel plugin: introduce a _get_kernel_version() helper <Created by piso77> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2413>
[19:22] <cachio> cmatsuoka, do you have all the parameters for -machine?
[19:39] <mup> PR snapd#9070 closed: o/ifacestate: fix bug in snapsWithSecurityProfiles (2.45) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9070>
[20:03] <cmatsuoka> cachio: I used the qemu-system(1) man page to see the parameter list
[20:04] <cachio> cmatsuoka, I am testing some specific parameters for intel machjnes
[20:05] <cmatsuoka> cachio: did you get any new logs when the vm crashes?
[20:06] <cachio> cmatsuoka, yes, but all is similar
[20:06] <cmatsuoka> ah ok
[20:15] <mup> PR snapd#9071 opened: release: 2.45.3.1 <Created by pedronis> <https://github.com/snapcore/snapd/pull/9071>
[20:15] <mup> PR snapd#9072 opened: packaging: add placeholder changelog for 2.45.3.1 <Created by pedronis> <https://github.com/snapcore/snapd/pull/9072>
[20:15] <pedronis> ijohnson: I re-prepared the release ^
[22:05] <mup> PR snapd#8499 closed: Adding comment on system instability caused by a privileged cp <Created by TZubiri> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8499>