[06:31] <mborzecki> morning
[07:26] <mardy> mborzecki: hi!
[08:04] <pstolowski> morning
[08:29] <mup> PR snapd#11323 opened: i/builtin: allow modem-manager interface to access some files in sysfs <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/11323>
[08:36] <mborzecki> pstolowski: hey
[08:38] <mvo> zyga-fyke: if you use vscode, could you give a +1 on pr 11245 ?
[08:38] <mup> PR #11245: vscode: added integrated support for MS VSCODE <Created by are-scenic> <https://github.com/snapcore/snapd/pull/11245>
[08:39] <zyga-fyke> mvo, good morning, looking
[08:45] <zyga-fyke> mvo, look at my review please
[08:46] <mvo> zyga-fyke: \o/ you rock thanks so much
[08:46] <mvo> zyga-fyke: sorry for bugging you with this but we only have very few people with vscode experience it seems :)
[08:48] <zyga-fyke> mvo, you should try it for a week
[08:48] <zyga-fyke> it's transformative, much better than go in vim sadly
[08:51] <mvo> zyga-fyke: I really should! I'm using emacs since forever and I think I really should try something new
[08:51] <zyga-fyke> mvo, if you want I would love to have a call and just show you how I use it
[09:54] <zyga-fyke> waveform, o/
[10:13] <abeato> 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] <mup> PR #11306: many: add transactional flag to snapd API <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/11306>
[10:15] <mborzecki> 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] <mup> PR snapd#11306 closed: many: add transactional flag to snapd API <Created by alfonsosanchezbeato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/11306>
[10:15] <abeato> mborzecki, thank you!
[10:24] <mvo> abeato: \o/ thanks, nice to see this landed
[10:24] <mvo> zyga-fyke: sorry, meetings! would love to see that indeed, we just need to find a time :)
[10:25] <abeato> mvo, third and hopefully last PR still needed though :)
[10:27] <mvo> abeato: \o/
[10:27] <mvo> abeato: yeah, I know still nice to see that the prereqs are landing
[10:27] <abeato> sure!
[11:20] <mup> PR snapd#11298 closed: tests: skip bind mount in snapd-snap test when the core snap in not repacked <Squash-merge> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/11298>
[11:20] <mup> PR snapd#11307 closed: tests: skip snap-userd-reexec test when reexec is not enabled <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/11307>
[12:18] <waveform> zyga-fyke, hello!
[12:18] <arsenique> Hello
[12:18] <zyga-mbp> waveform hey :)
[12:18] <waveform> zyga-fyke, sorry - your ping landed right at the start of a meeting and it slipped my mind after :)
[12:18] <zyga-mbp> waveform just a FYI, there's something wrong with pi3 armv7 images 
[12:18] <arsenique> zyga-fyke, I am looking for you too?
[12:18] <zyga-mbp> core20 images I mean
[12:18] <zyga-mbp> arsenique hey
[12:19] <zyga-mbp> waveform I didn't get anything while debugging, the data looks fine, I must be missing something
[12:19] <zyga-mbp> waveform uboot doesn't load any scirpts and just hangs there
[12:19] <zyga-mbp> arsenique how can I help?
[12:20] <waveform> zyga-mbp, hmm - core20 armhf? Okay, I'll take a look in a mo
[12:20] <zyga-mbp> waveform yes, I've used the imager to burn if that makes any difference
[12:20] <zyga-mbp> waveform core20 aarch64 works fine
[12:20] <arsenique> 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] <mup> PR #11245: vscode: added integrated support for MS VSCODE <Created by are-scenic> <https://github.com/snapcore/snapd/pull/11245>
[12:21] <zyga-mbp> arsenique sure, I'll look
[12:21] <arsenique> Thank you.
[12:21] <waveform> 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] <waveform> zyga-mbp, but I assume in this case you're testing the armhf package on a 3B (or 3B+ or 3A+?)
[12:21] <zyga-mbp> waveform yes, 3B+
[12:21] <waveform> zyga-mbp, okay -- I'll try and replicate here
[12:22] <zyga-mbp> waveform thanks, I'm happy to re-test if you have some ideas
[12:22] <zyga-mbp> arsenique I don't see any new comments after my mini review today, should I look back at older comments?
[12:24] <arsenique> 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] <zyga-mbp> arsenique did you send? I don't see any new things
[12:24] <zyga-mbp> arsenique perhaps github is waiting for "submit review"
[12:26] <arsenique> zyga-mdb strange I see them
[12:27] <arsenique> zyga-mdb look i reissued request for review - perhaps this will change it. sorry for the confusion.
[12:28] <zyga-mbp> I think you still need to send your comments though
[12:28] <zyga-mbp> I don't see any new comments
[12:45] <mup> PR snapd#11324 opened: tests: enable snap-userd-reexec on ubuntu and debian <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/11324>
[12:48] <waveform> 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] <zyga-mbp> it didn't even reach linu
[12:48] <zyga-mbp> can you tell me how you've programmed the card?
[12:48] <zyga-mbp> perhaps raspi-imager messes something up
[12:49] <waveform> zyga-mbp, just my usual "dd" but I've never noticed a difference between that and rpi-imager
[12:49] <waveform> I'll retry with rpi-imager in a bit and see if that affects it
[12:49] <zyga-mbp> can you pass the URL of the image you've used?
[12:49] <zyga-mbp> I'll try that
[12:49] <zyga-mbp> maybe some meta-data is stale and points to a broken image?
[12:49] <waveform> 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] <waveform> (so it *should* be the same image as you've got -- I'll double check the SHA256 though
[12:50] <waveform> (as I'm using a cached copy)
[12:50] <waveform> yup, same SHA256 as is currently being served
[12:50] <zyga-mbp> thanks, I'll re-program with dd and confirm
[12:50] <zyga-mbp> I really wonder what's wrong with the one I have
[12:50] <zyga-mbp> do you know if there's a way to check if the uboot.src file is not corrupted somehow (crc?)
[12:51] <waveform> 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] <zyga-mbp> right, in my experiments that was corrupted 
 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] <waveform> 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] <zyga-mbp> ah
[12:54] <zyga-mbp> in that case something else might be fishy in the image I happen to have flashed 
[12:54] <zyga-mbp> but I'll avoid debugging that and re-check with dd first
[12:55] <waveform> do you happen to have anything plugged into the Pi on the GPIO pins?
[12:55] <zyga-mbp> just the serial 
[12:55] <zyga-mbp> power power (skipped), tx/rx/ground
[12:55] <zyga-mbp> nothing else
[12:55] <waveform> 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] <zyga-mbp> thank you, if it works I'll re-check my setup
[12:56] <zyga-mbp> 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] <waveform> 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] <zyga-mbp> no, absolutely nothing
[13:08] <zyga-mbp> I will re-check, maybe my usb-serial is faulty?
[13:08] <zyga-mbp> the weird thing is that I had no input
[13:08] <zyga-mbp> maybe ... tx/gnd swapped?
[13:08] <zyga-mbp> that would be bad (but I often flash those late at night)
[13:18] <mborzecki> oh meh, udev during snap install kils pipewire and my sound is gone now 
[14:01] <mup> PR snapd#11325 opened: overlord: skip manager tests on riscv for now <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/11325>
[14:36] <mup> PR snapd#11326 opened: o/snapstate: implement transactional flag <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/11326>
[15:41] <ijohnson[m]> is this a known problem? https://pastebin.ubuntu.com/p/PgrwtjPwHh/
[15:59] <mvo> I have not seen that before
[16:13] <ijohnson[m]> hmm
[17:17] <mup> PR snapd#11327 opened: snap-confine: allow numbers in hook security tag <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/11327>
[18:34] <miguelpires> 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] <ijohnson[m]> miguelpires: no I didn't have time to look into it 
[19:18] <mup> PR snapd#11328 opened: tests: remove CentOS 8 (EOL) <Simple 😃> <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/11328>