[01:24] PR snapd#8774 closed: tests: disable test of nfs v3 with udp proto on debian-sid <⚠ Critical> === KindTwo is now known as KindOne [05:21] morning [06:36] hmm https://forum.snapcraft.io/t/linux-mint-20-will-forbid-snapd-from-installing-and-snaps-growing-external-adoption-problem/17913 [06:37] and https://blog.linuxmint.com/?p=3906 [06:50] errand, back in 30 or so [07:01] morning [07:07] o/ [07:36] re [07:36] zyga: pstolowski: hey [07:37] o/ [07:37] mvo wrote he's going to start later today [07:37] yeah, I noticed [07:37] zyga: seen the bad press? :) [07:48] mborzecki: it's not bad press [07:48] (when a competitor makes a press release, it's not press, it's just a statement) [07:49] I wish them good luck on maintaining chromium as a deb [07:49] zyga: from what i understand they won't maintain a deb [07:49] zyga: but rather complain about snaps each time one tries to install chromium? [07:50] heh [07:50] interesting [07:50] i guess a blog post is less work than packaging chromium [07:52] the blog post clearly states commercial inteterests [07:52] "it becomes a threat" [07:56] pstolowski: unit tests failing on #8567 [07:56] PR #8567: o/devicestate: core20 early config from gadget defaults [07:57] pedronis: ah, thanks, weird, go test ./... didn't run those [08:59] in the context of https://forum.snapcraft.io/t/snapd-cannot-run-daemon-cannot-read-state-unexpected-eof/17908/2 should we keep a backup of state.json? [09:00] last known good state is likely better than scrubbing all of it [09:02] we'd need to carefully select which scenarios restoring from backup could be useful [09:05] yes, would be good to avoid a single point of failure like this [09:06] PR snapd#8776 opened: bootloader: rename test helpers to reflect we are mocking EFI boot locations [09:06] i think we scrapped any plans to migrate from json to a db? [09:06] trivial PR ^^ [09:07] pstolowski: i don't see it in trello, so probably longer term goal? [09:08] pedronis: do you remember whether we dropped json -> db? [09:09] I don't thinkd dropped it the right way to put it, we don't have any immediate plan, for sure not this cycle [09:09] it's also not clear we have a db choice [09:36] diddledan: hi, pushed a little fix for the openttd snap https://github.com/diddlesnaps/openttd/pull/2 [09:36] PR diddlesnaps/openttd#2: snap/gui: fix desktop file Exec [10:00] drat [10:00] my thinkpad keeps shutting down all of a sudden [10:00] stuff like that always happens when you look at new thinkpads [10:01] zyga: anything in journal? [10:01] 4 times today [10:01] or dmesg? maybe a hardware problem? [10:01] mborzecki: it doesn't even reset, it just goes "off" [10:02] https://www.irccloud.com/pastebin/sHPeZkTd/ [10:02] but that's not even the last thing [10:02] just stood out of the oridinary [10:15] hmmm [10:15] I'm seeing more and more failures from restarting journald [10:15] https://www.irccloud.com/pastebin/W6kTcLLE/ [10:16] PR snapd#8776 closed: bootloader: rename test helpers to reflect we are mocking EFI boot locations [10:16] morning folks [10:17] ijohnson: hey, thanks for merging the PR [10:17] hey mborzecki [10:23] ijohnson: good morning! [10:23] hey zyga [10:23] how are you doing this morning [10:23] heh, I was about to tell mvo about my health [10:23] better, not well, painkillers work reliably now [10:24] well that's good you're feeling better than yesterday [10:24] I really need to see a doctor but I want to stay clear of any hospital for the next few weeks, at least [10:24] it's so annoying, my left leg is heavily impacted by this [10:24] I mostly work from bed, apart from standups and other calls [10:24] I had re-lapses of this a few times but none that would be this long [10:25] sorry to hear that, I know others who are in a similar situation, not wanting to go to any hospitals right now and it's quite unfortunate :-( [10:25] zyga: ok, thank you! [10:26] I think our government is not really doing a good job with this, and prefers to pretend the situation is good by not testing [10:26] heh sounds familiar [10:26] if it would deteriorate more I would definitely go despite the risk [10:26] last time that saved me from a wheelchair :| [10:28] zyga: do you work seated? [10:28] mborzecki: now? [10:28] mborzecki: no, I'm on the floor [10:29] zyga: i mean in general, i recall you bought a standing desk [10:29] yes, I use it [10:30] I'm pretty strongly considering buying a standing desk or at least retro fitting my current desk to work standing [10:30] i remember when i started working from home full time i had some backpain, but then with the standing desk it's no longer an issue [10:31] PR snapd#8777 opened: Enable riscv64 builds in the edge PPA [10:31] mborzecki: but now standing up is not great either, I keep getting those phantom pains in my left leg [10:31] that only go away when I'm curled up or at least not standing straight [10:31] i work seated maybe 1-1.5h a day, partially caused by my super uncomfortable chair [10:32] it was much worse before but I wonder if I will need some real help later on [10:32] oh, my main chair broke :| [10:32] we bought it looong time ago, when I met my wife [10:32] so it's ~15-18 years old now [10:33] zyga: yeah, better check it, sciatica is no joke if untreated [10:33] we've ordered parts but the company making them has some issues [10:33] mborzecki: I know [10:36] mborzecki: spent half a year in bed crawling to the bathroom [10:36] mborzecki: fun days [10:43] mborzecki: how do you work for the reminder of the day? [10:45] zyga: i'm available now, i need to go pick up some stuff right after the standup and be back for a bit ~5pm [10:45] mborzecki: no no, I mean [10:45] you said that you work seted for a fraction of the day [10:45] ah, though you wanted to discuss something on HO ;) [10:45] do you use a standing desk otherwise? [10:46] (please forgive my terrible english phrases) [10:47] zyga: yeah standing, sprints are probably the only time when i work seated (hence enjoying walking around later in the day) [10:47] I see :) [10:47] yeah, standing desk is really worth it :) [10:49] I like biking so much because the position on a bike is really close to curled up "neutral" for me, so I can just go and go and go without any pain [10:50] mborzecki: btw, I'm still using fish, I grew to like it more than zsh [10:55] zyga: haha, maybe you can fix that problem then ;) [11:00] zyga: the biking thing probably depends on the bike type/frame geometry, i can totally see how most people would find a road bike uncomfortable [11:01] PR snapd#8778 opened: tests: modernize and use snapd.tool [11:01] mborzecki: not being a biking expert I'm not sure how to call my bike :) [11:03] zyga: not an expert either, i just enjoy riding bikes :P [11:04] I think it's a mountain bike [11:05] though now with all the bike lanes that grow like grass after rain, I think a city bike would be good too [11:08] mborzecki: could you look at https://github.com/snapcore/snapd/pull/8733 [11:08] PR #8733: tests: port document-portal-activation to session-tool [11:08] I addressed your comments there [11:15] PR snapcraft#3153 opened: review-tools: add --allow-classic flag for local review [11:59] more journal failures [11:59] I will look after the branch I'm working on is odne [11:59] *done [12:16] PR snapd#8733 closed: tests: port document-portal-activation to session-tool [12:16] PR snapd#8779 opened: osutil: Enable riscv64 build [12:31] mvo, hey [12:33] mvo, any idea why test-snapd-rsync-core20 is not published for arm64? [12:41] cachio: wasn't that the one I built locally for you and sent to you ? [12:43] ijohnson, yes, but then mvo fixed that and published for all the archs [12:43] but arm64 is missing [12:44] ah ok [12:44] don't know if mvo forgot to upload or there is a problem [12:44] not sure [12:46] PR snapd#8780 opened: tests: core20 early defaults spread test [12:56] PR snapd#8781 opened: tests: modernize tests.session and port everything using it [12:59] cachio: let me check, maybe something failed somewhere [13:01] mvo, thanks [13:01] PR snapd#8770 closed: snap/naming: add ParseSecurityTag and friends [13:41] this is ready now https://github.com/snapcore/snapd/pull/8778 [13:41] PR #8778: tests: modernize and use snapd.tool [13:47] PR snapd#8779 closed: osutil: enable riscv64 build [14:00] cachio: pstolowski: thoughts on https://github.com/snapcore/snapd/pull/8780/files#r433896786 ? [14:00] PR #8780: tests: core20 early defaults spread test [14:05] ijohnson, thanks [14:10] * cachio afk [14:12] degville: when you have a chance could you review the wording in my message here for `snap remove --help`? [14:12] https://github.com/snapcore/snapd/pull/8782 [14:12] PR #8782: cmd/snap/remove: mention snap restore/automatic snapshots [14:12] PR snapd#8782 opened: cmd/snap/remove: mention snap restore/automatic snapshots [14:17] ijohnson: yes, of course. Looking now. [14:17] thank you! === King_InuYasha is now known as Conan_Kudo === Conan_Kudo is now known as King_InuYasha [14:39] pedronis: could you please look at https://github.com/snapcore/snapd/pull/8778 [14:39] PR #8778: tests: modernize and use snapd.tool [14:39] just to make sure the snapd.tool exec thing is what you expected [14:42] gosh I still just can't believe how cool it is that when I restart a spread run all the successful runs are cached [14:42] yeah :D [14:42] move from travis was worth it [14:48] zyga, it looks like the crash in openttd is because pulseaudio isn't being used on the pi default desktop? [14:49] diddledan: I installed ubuntu-desktop (note: this was not raspbian) [14:49] oh [14:49] hmm [14:49] diddledan: I also installed the deb and that did work [14:49] no idea then [14:49] though there was no sound as my speaker was connected over usb and probably not default [14:49] it looks to be crashing immediately after trying to access pulse on my raspberry pi os install [14:49] s/pulse/alsa/ [14:50] zyga: what's the current way to format our c code? clang-format? [14:50] mvo: we use a hybrid approach to avoid flag days, make fmt will use both clang format and indent depending on the file name [14:51] mvo: I strongly prefer clang format but I don not want to enforce it as the format also shifts from time to time and it's just not worth it [14:51] zyga: that's fine, it's for a new file [14:51] mvo: ideally new files should be clang, existing files should be using whatever was used [14:56] ijohnson: thanks, replied [14:57] pstolowski: https://bugs.launchpad.net/bugs/1881350 is interesting [14:57] Bug #1881350: snap seeding fails with libc6-lse [14:58] does anyone know what libc6-lse is? [14:58] zyga: indeed [14:59] zyga: not existing in the archive? [14:59] .. at least I can't find it [15:00] diddledan: the report mentions 20.10 [15:00] oh. must be new then [15:00] lse is a new arm64 feature AFAIK [15:01] "Large System Extensions" [15:01] see also https://launchpad.net/ubuntu/+source/glibc/2.31-0ubuntu9 [15:01] heh [15:01] also https://en.wikichip.org/wiki/arm/armv8.1 [15:01] pstolowski: new custom weird stuff :) [15:02] aah [15:06] https://github.com/snapcore/snapd/pull/8781 is ready for review [15:06] PR #8781: tests: modernize tests.session and port everything using it [15:07] PR snapd#8784 opened: snap: add new `snap run --gdbserver` option [15:12] PR snapd#8640 closed: wrappers: pass 'disable' flag to StopServices wrapper (2/N) [15:16] https://github.com/snapcore/snapd/pull/8778 needs a 2nd review though perhaps I can merge it as-is as it's really boring and should not linger [15:16] PR #8778: tests: modernize and use snapd.tool [15:26] mvo: did you get gdbserver working for a regular user then? [15:27] if it works it'd be a great improvement [15:29] then i can polish some of the manual solib-search-path/sysroot tweaks and turn those into a script you could load from gdb [15:29] mborzecki: ohhh, that would be nice [15:30] mborzecki: well, gdbserver runs as root as it needs to attach via ptrace :( [15:30] mborzecki: but the app runs as user, the gdb that attaches is run as user [15:31] mvo: i'll play with the branch a bit [15:32] zyga: see last comments https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1881350 [15:32] Bug #1881350: snap seeding fails with libc6-lse [15:33] looking [15:33] ooohh [15:33] interesting :) [15:33] onse sec [15:33] *one sec [15:33] mborzecki: cool, keep me updated [15:33] btw, are there more complete logs in that bug report? [15:33] mvo: btw. we need gdbserver in core20 [15:34] mborzecki: it will use the gdbserver from the outside [15:34] mborzecki: to avoid the ptrace problem inside the confinement [15:34] ah cool [15:34] pstolowski: snap-confine has this permission [15:34] /{,usr/}lib{,32,64,x32}/{,@{multiarch}/}libpthread{,-[0-9]*}.so* mr, [15:48] pstolowski: I commented on the bug but it looks like something is more seriously broken [15:48] I suspect we need a different apparmor permission for the different binary [15:48] and it just manifests itself as that pthread thing [15:48] the fix is likely a one liner in the apparmor profile [15:50] I will EOD soon [15:50] need to go for a bike ride or I will go insane [15:54] zyga: i see. thanks [16:03] pstolowski: thank you! [16:07] PR snapd#8769 closed: dbusutil: move all D-Bus helpers and D-Bus test helpers [16:10] * cachio lunch [16:13] cachio: +1 for your 20.10 PR [16:21] one last PR today: https://github.com/snapcore/snapd/pull/8785 [16:21] PR #8785: sandbox/cgroup: move FreezerCgroupDir from dirs.go [16:21] breaking parts of the big sandbox/cgroup patch from the backend branch [16:21] it's super small and straightforward [16:22] PR snapd#8785 opened: sandbox/cgroup: move FreezerCgroupDir from dirs.go [16:30] * zyga EODs with a warm encouragement to merge https://github.com/snapcore/snapd/pull/8781 and avoid further suffering during the transition [16:30] PR #8781: tests: modernize tests.session and port everything using it [16:38] Psi-Jack, tx [16:39] Huh? [16:41] Psi-Jack, is that a "huh? I didn't do nuffin. you can't prove I did it. wasn't me." [16:42] PR snapd#8786 opened: arch: add riscv64 [16:47] cachio: test-snapd-rsync-core20 should be available for arm64 now [16:47] mvo, yes I saw that [16:47] thanks [16:47] yw [16:49] mvo, I created #8787 [16:49] PR #8787: tests: install test-snapd-rsync snap from edge channel [16:50] cachio: ta [16:50] which is needed for uc20 === mbriza is now known as mbriza2 [16:50] More like a "huh? Why are you telling me to transmit randomly?" [16:52] PR snapd#8787 opened: tests: install test-snapd-rsync snap from edge channel [16:52] * Psi-Jack glares to cachio. [16:55] :), sorry about thatpstolowski -> Psi-Jack [16:55] pstolowski left and I didn't noticed [16:56] Hehe. It's all cool. :) [16:58] ijohnson, zyga? could yo please take a quick look to #8787 ? [16:58] PR #8787: tests: install test-snapd-rsync snap from edge channel [16:58] yes [16:58] I need it for rpi4 validation on uc20 [16:58] it is super simple [16:58] cachio: I don't understand the "idea is to use edge" [16:58] is edge different from stable here? [16:58] it is the same [16:59] but we are publishing just on edge for the new snaps [16:59] I see [16:59] I'll remove them from stable [16:59] ok [16:59] the test snapd should be just published on edge [16:59] when possible [17:00] cachio: reviewed [17:00] zyga, ijohnson thanks!! [17:02] cachio: yaw [17:06] PR snapcraft#3153 closed: review-tools: add --allow-classic flag for local review [17:17] * zyga EODs for real this time [17:18] PR snapd#8788 opened: cmd/snap-confine: add support for libc6-lse [17:20] cachio: where is MATCH defined in our tests? [17:22] cachio: ah, just found it [17:27] cmatsuoka, there are 2 MATCH [17:27] 1 in testslib/bin [17:28] another defined inside spread [17:28] also we have NOMATCH [17:28] defined inside spread [17:28] cachio: yes, I now see that in spread.yaml we overwrite the dummy definition [17:31] mvo: if you have time yet today, could you sudo git merge https://github.com/snapcore/snapd/pull/8782 ? it is stuck waiting for travis, I could close and re-open if you wanted instead but seems wasteful [17:31] PR #8782: cmd/snap/remove: mention snap restore/automatic snapshots [17:54] * cachio -> cofee [18:20] ijohnson: sure === facundo__ is now known as facubatista [18:23] PR snapd#8782 closed: cmd/snap/remove: mention snap restore/automatic snapshots [18:28] PR snapd#8764 closed: tests: add ubuntu 20.10 to spread tests [18:33] PR snapd#8781 closed: tests: modernize tests.session and port everything using it [18:58] PR snapd#8789 opened: interfaces/docker: use implicitOnClassic: true <⛔ Blocked> === KindTwo is now known as KindOne [19:16] PR snapcraft#3150 closed: cli: error/warn when using sudo === KindTwo is now known as KindOne [19:46] PR snapcraft#3151 closed: cli: disable --target-arch support on core20 [20:13] PR snapd#8787 closed: tests: install test-snapd-rsync snap from edge channel [20:27] ijohnson, hey [20:27] hi cachio [20:27] about the comment you left in the review [20:28] on stolowski's PR? [20:28] I dont get the first part [20:28] yes [20:28] yes sorry I was confused [20:28] I read the wrong section in the spread.yaml [20:28] ah, ok [20:29] because in the past I created some images in gce with nested vms precreated and running [20:29] I dont know if you were suggesting something like this [20:29] no sorry for the confusion [20:29] ijohnson, np [20:30] ijohnson, I have a question [20:30] sure [20:30] in pi4 I see this error https://paste.ubuntu.com/p/rsGWsBWJ2r/ [20:30] preparing the main suite [20:31] any idea? [20:31] huhu [20:31] huh [20:31] no I don't let me look in the prepare for that suite [20:31] perhaps it's checking for a particular dtb [20:32] dindt found nothing about dtb in prepare [20:32] first time I see that issue [20:32] cachio: do you have more logs ? [20:33] yes it is very odd indeed I've never seen it either [20:34] cachio: is it maybe from get_boot_path ? [20:34] ijohnson, this is the full log https://paste.ubuntu.com/p/RP3wNqJvvC/ [20:34] it is the rpi with 8gb [20:36] ijohnson, running now with the 4gb version [20:36] ijohnson, using this image http://cdimage.ubuntu.com/ubuntu-core/20/dangerous-beta/current/ubuntu-core-20-arm64+raspi.img.xz [20:36] cachio: I'm inclined to think it's failing with the get_boot_path but for some reason it clips the output [20:38] cachio: I see similar end of output when I run that same command on my uc pi, i.e. `ls -alR /boot` shows similar output of [20:38] /boot/uboot/pi-kernel_162.snap/dtbs/overlays: [20:38] total 385 [20:38] drwxr-xr-x 2 root root 15360 May 29 07:11 . [20:38] drwxr-xr-x 4 root root 512 May 29 07:10 .. [20:38] -rwxr-xr-x 1 root root 569 May 27 13:45 act-led.dtbo [20:41] ijohnson, in restore I see this boot_path='Cannot determine boot path [20:41] cachio: right that makes sense that would cause the prepare error you see [20:41] let me look at the logs more [20:42] not sure what the issue is yet [20:43] cachio: I don't see that `Cannot determine boot path` message in the full log you sent, where do you see that? [20:43] ijohnson, hehe, I read the previous error log [20:43] 1 sec [20:44] ijohnson, https://paste.ubuntu.com/p/KCdkWyt4ND/ [20:44] cachio: do you have a shell to this system ? [20:44] ijohnson, no [20:45] cachio: but you are using the released image? [20:45] yes [20:45] err rather the images published on cdimage [20:45] ok [20:45] the one from beta [20:45] http://cdimage.ubuntu.com/ubuntu-core/20/dangerous-beta/current/ubuntu-core-20-arm64+raspi.img.xz [20:45] let me download it and try to flash it, it will take me a while though [20:46] well [20:46] I know [20:46] total 5 [20:46] drwxr-xr-x 3 root root 512 Jun 2 20:16 . [20:46] drwxr-xr-x 6 root root 70 May 27 15:05 .. [20:46] -rwxr-xr-x 1 root root 4096 Jun 2 20:16 boot.sel [20:46] drwxr-xr-x 3 root root 512 May 15 21:06 pi-kernel_155.snap [20:46] this is what we have [20:46] hmmmm [20:46] if [ -f /boot/uboot/uboot.env ] || [ -f /boot/uboot/uboot.sel ]; then [20:47] and we check that [20:47] cachio: is this shell maybe being run in install mode ? [20:47] boot.sel vs uboot.sel [20:47] ahhhh I see [20:47] cachio: yes it should be boot.sel [20:48] I'll create a quick pr for that [20:48] sure, let me know and I can approve it [20:49] ijohnson, thanks [20:49] ijohnson, I don't know why it is not failing in pi3 [20:50] ijohnson, any idea if in pi3 we have uboot.sel? [20:50] or boot.sel? [20:51] I can't get any pi3 on the lab [20:59] cachio could be a typo in the gadget maybe? [20:59] Let me look [21:01] cachio no it should not be uboot.sel on pi3 [21:01] ok, thnanks [21:04] ijohnson, https://github.com/snapcore/snapd/pull/8790 [21:04] PR #8790: tests: update the file used to detect the boot path on uc20 [21:08] PR snapd#8790 opened: tests: update the file used to detect the boot path on uc20 [21:13] * cachio afk [21:44] PR snapd#8791 opened: snap/prepare_image: Add support for append/remove [21:49] PR snapd#8792 opened: interfaces: miscellanious policy update xlv [21:54] PR snapd#8793 opened: interfaces: miscellanious policy update xlv - 2.45 [23:19] PR snapd#8794 opened: boot/bootstate16.go: clean snap_try_* vars when not in Trying status too [23:49] PR snapd#8795 opened: cmd/snap-bootstrap/initramfs-mounts: also copy systemd clock + netplan files