[06:31] morning [07:26] mborzecki: hi! [08:04] morning [08:29] PR snapd#11323 opened: i/builtin: allow modem-manager interface to access some files in sysfs [08:36] pstolowski: hey [08:38] zyga-fyke: if you use vscode, could you give a +1 on pr 11245 ? [08:38] PR #11245: vscode: added integrated support for MS VSCODE [08:39] mvo, good morning, looking [08:45] mvo, look at my review please [08:46] zyga-fyke: \o/ you rock thanks so much [08:46] zyga-fyke: sorry for bugging you with this but we only have very few people with vscode experience it seems :) [08:48] mvo, you should try it for a week [08:48] it's transformative, much better than go in vim sadly [08:51] zyga-fyke: I really should! I'm using emacs since forever and I think I really should try something new [08:51] mvo, if you want I would love to have a call and just show you how I use it [09:54] waveform, o/ [10:13] mvo, mborzecki hey, good morning! would it be possible to merge https://github.com/snapcore/snapd/pull/11306 ? it looks like the spread test that is failing is not related to the PR [10:13] PR #11306: many: add transactional flag to snapd API [10:15] abeato: hey, i've restarted the spread jobs in the morning hoping most will be succesful, which they are, so merged just now [10:15] PR snapd#11306 closed: many: add transactional flag to snapd API [10:15] mborzecki, thank you! === dob1_ is now known as dob1 [10:24] abeato: \o/ thanks, nice to see this landed [10:24] zyga-fyke: sorry, meetings! would love to see that indeed, we just need to find a time :) [10:25] mvo, third and hopefully last PR still needed though :) === alan_g_ is now known as alan_g [10:27] abeato: \o/ [10:27] abeato: yeah, I know still nice to see that the prereqs are landing [10:27] sure! [11:20] PR snapd#11298 closed: tests: skip bind mount in snapd-snap test when the core snap in not repacked [11:20] PR snapd#11307 closed: tests: skip snap-userd-reexec test when reexec is not enabled [12:18] zyga-fyke, hello! [12:18] Hello [12:18] waveform hey :) [12:18] zyga-fyke, sorry - your ping landed right at the start of a meeting and it slipped my mind after :) [12:18] waveform just a FYI, there's something wrong with pi3 armv7 images [12:18] zyga-fyke, I am looking for you too? [12:18] core20 images I mean [12:18] arsenique hey [12:19] waveform I didn't get anything while debugging, the data looks fine, I must be missing something [12:19] waveform uboot doesn't load any scirpts and just hangs there [12:19] arsenique how can I help? [12:20] zyga-mbp, hmm - core20 armhf? Okay, I'll take a look in a mo [12:20] waveform yes, I've used the imager to burn if that makes any difference [12:20] waveform core20 aarch64 works fine [12:20] Sorry, I don't want to interrupt your current discussion. I just wanted to ask you to look @ my comments in the PR you are reviewing: https://github.com/snapcore/snapd/pull/11245 [12:20] PR #11245: vscode: added integrated support for MS VSCODE [12:21] arsenique sure, I'll look [12:21] Thank you. [12:21] zyga-mbp, shouldn't do -- in fact there's no separation of the images in 20 onwards (the pi3, pi4, etc. are all just symlinks to the arch-specific image) [12:21] zyga-mbp, but I assume in this case you're testing the armhf package on a 3B (or 3B+ or 3A+?) [12:21] waveform yes, 3B+ [12:21] zyga-mbp, okay -- I'll try and replicate here [12:22] waveform thanks, I'm happy to re-test if you have some ideas [12:22] arsenique I don't see any new comments after my mini review today, should I look back at older comments? [12:24] zyga-mdp I am sorry didn't mean to cause you looking at it right now. But, yes I've added replies to your comments [12:24] arsenique did you send? I don't see any new things [12:24] arsenique perhaps github is waiting for "submit review" [12:26] zyga-mdb strange I see them [12:27] zyga-mdb look i reissued request for review - perhaps this will change it. sorry for the confusion. [12:28] I think you still need to send your comments though [12:28] I don't see any new comments [12:45] PR snapd#11324 opened: tests: enable snap-userd-reexec on ubuntu and debian [12:48] zyga-mbp, I've managed to boot the core20 armhf image on a 3B+ here; currently going through the "Press enter to configure" "oh no, please wait for update/reboot" dance -- did yours hang before this or after all updates were complete? [12:48] it didn't even reach linu [12:48] can you tell me how you've programmed the card? [12:48] perhaps raspi-imager messes something up [12:49] zyga-mbp, just my usual "dd" but I've never noticed a difference between that and rpi-imager [12:49] I'll retry with rpi-imager in a bit and see if that affects it [12:49] can you pass the URL of the image you've used? [12:49] I'll try that [12:49] maybe some meta-data is stale and points to a broken image? [12:49] sure: http://cdimage.ubuntu.com/ubuntu-core/20/stable/current/ubuntu-core-20-armhf+raspi.img.xz -- but I've checked and that's the same URL as we're currently serving in the rpi-imager json [12:50] (so it *should* be the same image as you've got -- I'll double check the SHA256 though [12:50] (as I'm using a cached copy) [12:50] yup, same SHA256 as is currently being served [12:50] thanks, I'll re-program with dd and confirm [12:50] I really wonder what's wrong with the one I have [12:50] do you know if there's a way to check if the uboot.src file is not corrupted somehow (crc?) [12:51] the uboot.scr has a built-in CRC (erm... first 4 bytes I *think* if memory serves) so it should notice most (simple) corruption itself [12:51] right, in my experiments that was corrupted [12:52]

there's an error message earlier: Loading Environment from FAT... *** Warning - bad CRC, using default environment -- from https://pastebin.ubuntu.com/p/knzG5gqwHZ/ [12:54] oh, hang on -- I might be thinking of the .env, not the .scr. Yes, the .env has a front-end CRC, the .scr has a larger header but there is a CRC in it *somewhere*. That said, core20 doesn't ship a uboot.env as I recall (but does ship a .scr), in which case you *should* see that error because it also gets printed when there's no environment [12:54] ah [12:54] in that case something else might be fishy in the image I happen to have flashed [12:54] but I'll avoid debugging that and re-check with dd first [12:55] do you happen to have anything plugged into the Pi on the GPIO pins? [12:55] just the serial [12:55] power power (skipped), tx/rx/ground [12:55] nothing else [12:55] okay, so nothing should be erroneously sending a key to serial to interrupt u-boot ... hmmm. I'm reflashing with rpi-imager now -- I'll see if I can replicate with that [12:56] thank you, if it works I'll re-check my setup [12:56] I've programmed a few boards/images lately so I was not expecting anything weird here but perhaps I've missed something [13:06] * zyga-mbp needs to move to some cloud irc, sigh [13:07] zyga-mbp, it appears the rpi-imager flashed version also boots happily (eventually :) to the configuration screen. I'd hazard a guess that you've got *something* attached (over USB perhaps?) that's interrupting u-boot and dropping to the u-boot prompt? Must be acting like a keyboard in that case though [13:08] no, absolutely nothing [13:08] I will re-check, maybe my usb-serial is faulty? [13:08] the weird thing is that I had no input [13:08] maybe ... tx/gnd swapped? [13:08] that would be bad (but I often flash those late at night) [13:18] oh meh, udev during snap install kils pipewire and my sound is gone now [14:01] PR snapd#11325 opened: overlord: skip manager tests on riscv for now [14:36] PR snapd#11326 opened: o/snapstate: implement transactional flag [15:41] is this a known problem? https://pastebin.ubuntu.com/p/PgrwtjPwHh/ [15:59] I have not seen that before [16:13] hmm [17:17] PR snapd#11327 opened: snap-confine: allow numbers in hook security tag [18:34] ijohnson[m]: hi, did you figure out what's going with Centos 8? I had the same issue and messed around with the repo config but couldn't fix it. Maybe we can remove Centos8 from the spread tests since it's EOL [18:50] miguelpires: no I didn't have time to look into it [19:18] PR snapd#11328 opened: tests: remove CentOS 8 (EOL)