[07:40] <cpaelzer> sil2100: I see you are on +1 duty today as well - are we syncing on work items here or in any other channel (+1 , -release, ...)?
[07:46] <sil2100> cpaelzer: I think there was some discussion to use -release for any coordination, if anything :)
[07:51] <cpaelzer> ok, thanks sil2100
[14:19] <xnox> @patchpilot in
[14:19] <udevbot> Error: "patchpilot" is not a valid command.
[14:19] <xnox> !patchpilot in
[14:19] <xnox> @pilot in
[14:19] <xnox> @pilot out
[14:20] <ogra> that was a short session
[14:20] <xnox> ogra:  hahhahhahhahahhahahaha
[14:53] <rbasak> bryce: FYI, https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/384974 is trivial and I'm going to "self-land" it once CI passes on the basis that it doesn't need a code review. If you object to this sort of thing in principle, please let me know.
[14:53] <bryce> rbasak, ok
[15:01] <cpaelzer> sil2100: I have updated the wiki with my ongoing items
[15:04] <sil2100> cpaelzer: excellent! I had a few meetings now, but now I'm looking at pycryptodome - will be promoting the unsatisfiable dependency to main
[15:05] <sil2100> cpaelzer: just hope us updating the wiki-page won't clash and we won't overwrite eachothers changes! This is this one thing I like in discourse more than the wiki
[15:07] <coreycb> RAOF: bdmurray: hi, the openstack ussuri SRUs should be ready to release to focal-updates.
[15:08] <cpaelzer> sil2100: yeah, I'm even pro-trello on this, but we can settle the "how and which tool" after we settled on which content shall be in mails vs some semi-static-page
[15:08] <cpaelzer> OTOH I understand some people find trello noisy (so many thing on the screen - and I agree in some cases
[15:08] <cpaelzer> we will see
[15:09] <cpaelzer> sil2100: updates on the wiki (as long as that is what we use) have to be edit, change, save asap - not click edit in the morning and try to save in the evening
[15:09] <cpaelzer> :-)
[15:14] <bdmurray> coreycb: ack
[15:16] <gpiccoli> Hi folks, do you know if Scott Remnant is here?
[15:16] <gpiccoli> I don't know his nick
[15:17] <sil2100> cpaelzer: exactly ;)
[15:26] <cpaelzer> sil2100: if it turns out that the wiki is too mcuh pain on update-conflicts or getting outdated we can then think about alternatives
[15:27] <gpiccoli> pitti, Hi Martin, I'm studying the eait-for-root code, I was looking to talk to original developers. I see Scott was the original devel, but you worked a lot on it, right?
[15:28] <gpiccoli> I'm trying to understand what is the exact problem it was meant to solve...it seems to me, it's potentially "innocuous" now
[15:51] <zyga> ogra: who's the best person to talk to about https://bugs.launchpad.net/ubuntu/focal/+source/linux-raspi/+bug/1876862 ?
[15:51] <ogra> zyga, RAOF
[15:51] <zyga> RAOF: I'm interested in raspberry pi as a desktop system
[15:51] <ogra> zyga, or well ... for the kernel side juergh
[15:52] <ogra> zyga, it is already fixed in the tree i think
[15:52] <zyga> in mainline?
[15:52] <zyga> does it need backports?
[15:52] <ogra> but i think the next kernel release is only scheduled for end of the month
[15:52] <zyga> I wonder if there's anything I can do to help
[15:52] <ogra> mainline ?
[15:52] <ogra> we'Re talkng about rpi !
[15:53] <ogra> in mainline it is probably ready in a few months ... who knows 😛
[15:53] <ogra> the tree at kernel.ubuntu.com has the moduke enabled ... but i doubt thats enough ... there are likely additional patches needed plus some dtb changes
[15:54] <ogra> and such patches usually only live in the raspberrypi.org kernels ... typically it takes a while til they make it into mainline
[15:55] <cjwatson> gpiccoli: Scott hasn't been around in Ubuntu for a long time
[15:55] <ogra> zyga, waveform should have the broader overview though, he's "pi-dude" 🙂
[15:55] <zyga> mmmm
[15:55] <cjwatson> gpiccoli: Probably best to assume he wouldn't remember anything about it even if you did contact him :)
[15:55] <gpiccoli> cjwatson, so I heard..but maybe he was here, in freenode
[15:55] <zyga> waveform: is there anything I can do to help with the effort of making ubuntu a great desktop OS for pi 8GB?
[15:56] <gpiccoli> But I agree hehe, maybe he doesn't remember anymore
[15:56] <cjwatson> gpiccoli: (also, if you do contact him, IME he'll be quite irritated if you call him Scott Remnant rather than Scott James Remnant)
[15:56] <gpiccoli> Oh, thanks for your hint, I wasn't aware of this!
[15:56] <ogra> zyga, also ... the desktop team is likley looking into arm64 images eventually (i heard it mentioned during the vienna sprint a few times)
[16:03] <juliank> but like proper arm64 uefi images, not rpi weirdness?
[16:04] <waveform> juliank, no no no - not uefi :)
[16:04] <waveform> (sorry, in meeting - will comment more in a bit)
[16:05] <ogra> juliank, ahah wishful thinking
[16:05] <juliank> ogra: Well I don't know, all I know about arm64 desktops is the WOS devices
[16:06] <ogra> as londg as the DSP/GPU is your bootloader i doubt you'll see UEFI
[16:06] <juliank> but sure it makes sense to pop out rpi4 ones too
[16:06] <ogra> you *can* chainload u-boot from the GPU loader ... and then chainload grub and have UEFI on a pi though
[16:06] <juliank> I meant that people were interested in playing with desktop on UEFI arm devices, and I thought we might want images for that
[16:06] <ogra> but thats a lot of chainloading
[16:06] <juliank> not that we'd want UEFI on rpi
[16:07] <juliank> Arguably, desktop on rpi is probably more useful than desktop on uefi arm64 devices
[16:08] <juliank> but it'd sure be nice to have that :)
[16:08] <ogra> desktop on an 8GB pi4 is surely as powerful as one of my older laptops
[16:08] <ogra> as long as you add a speedy USB 3.1 SSD
[16:09] <ogra> (you really dont want to use the SD card for more than bootloader stuff on such a system)
[16:09] <waveform> zyga, desktop on the pi is certainly of interest here - the biggest thing on my plate with regard to that is ditching uboot (which is what currently breaks ... so many things!)
[16:10] <zyga> waveform: I see, so that we don't use intermediate bootloader?
[16:10] <waveform> zyga, precisely - ideally we want to do the same as raspbian: gpu bootloader, kernel, optional initrd
[16:11] <waveform> zyga, unfortunately that is more complex than it sounds (in particular with regard to ubuntu core) and is at least partly dependent on the goodwill of the pi foundation adding certain things to their bootloader (unpacking arm64 kernels and more importantly some mechanism to handle fallback for A/B booting)
[16:13] <waveform> as it stands you can boot ubuntu armhf (*not* arm64) from an SSD without any SD card without much issue (the kernel cmdline and /etc/fstab were updated to use label-based partitions in eoan)
[16:14] <waveform> but I've still got a ton of other stuff to add - current priority is camera module support, and the pi4 EEPROM utilities after that
[16:15] <ogra> yeah
[16:15] <ogra> the images are fine as they are for the moment really
[16:16] <ogra> UEFI is a nice to have eventually but there is so much other pressing stuff forst
[16:16] <ogra> *first
[16:18] <zyga> waveform: do you think we could use somethnig like raspi-config tailored for ubuntu
[16:18] <zyga> even with the same name but different backend?
[16:18] <ogra> nah
[16:18] <zyga> I'm really personally interested and would love to help
[16:18] <ogra> we have something way cooler !!
[16:19] <zyga> ogra: why? I think it has tremendous usage muscle memory
[16:19] <ogra> made by waveform 🙂
[16:19] <waveform> actually I wouldn't call it "more awesome" as "slightly broken" at the mo after I discovered an undocumented "feature" in the pi bootloader ... but I'll come back to that
[16:19] <zyga> hehe
[16:19] <zyga> ok
[16:19] <zyga> waveform: my offer to help stands
[16:20] <waveform> zyga, many thanks - let me see if I can dig out the post I made for this and see if it answers your query sufficiently
[16:20] <waveform> zyga, here we go: https://waldorf.waveform.org.uk/2020/introducing-pibootctl.html
[16:20] <zyga> waveform: more than queries, I'd liek to help with coding if you have something simple
[16:21] <waveform> zyga, well - it's all open-source and the code's there for people to hack on but despite the code being relatively simple, the difficult bit is that you need to be *really* familiar with the fine details of the bootloader's configuration
[16:22] <zyga> mmm
[16:22] <waveform> zyga, by way of example (and this is what tripped me up last week); activating the camera module can be done with "start_x=1" in the config.txt (amongst a couple of other ways, but that's the common one)
[16:22] <waveform> zyga, the bootloader also permits inclusion of files via, for example, "include syscfg.txt" - as we use in ubuntu
[16:23] <zyga> yep
[16:23] <zyga> I am familiar with it to a small degree
[16:23] <waveform> zyga, but ... guess what ... start_x doesn't work in included files :)
[16:23] <ogra> fun
[16:23] <zyga> must be really reliable ;)
[16:24] <waveform> now, if you know a bit about the bootloader mechanisms this actually makes sense; start_x=1 implies start_file and fixup_file getting set to start_x.elf and fixup_x.dat respectively
[16:24] <waveform> that means it implies launching a *different* tertiary stage of the bootloader
[16:24] <waveform> so, the parsing of that bit of config.txt is *not* done by start.elf (unlike all the rest); it's being done by bootcode.bin (or the EEPROM on the pi4)
[16:24] <waveform> which almost certainly doesn't know about includes (or probably conditional sections though I haven't tested that yet)
[16:25] <zyga> waveform: any chance to work closely with the foundation to at least document that bit better
[16:25] <zyga> do you know why that part is not open source? is there some broadcom-likely-NDA or is there something deeper?
[16:26] <waveform> zyga, it's partly that it's broadcom owned code but there's more complex bits. For instance, start_x.elf includes the camera firmware. That's largely based on threadx (a closed source RTOS) and includes things like a hardware-accelerated H264 encoder (under patent)
[16:26] <zyga> that feels like firmware blob we could include if it was available as a blob
[16:26] <zyga> I'm faimilar with threadx
[16:27] <zyga> though I last used it really long time ago
[16:27] <waveform> zyga, in other words, don't hold your breath on that being opened - I'm sure they'd like to but there's a whole pile of closed-source fun tied up in that .elf
[16:27] <zyga> I think 90% of the benefit would be from being able to implement a better start.elf
[16:27] <zyga> that's just loading the big blobs
[16:27] <zyga> so that boot logic is less weird
[16:27] <zyga> and can do things that people are using the PI for more than before
[16:28] <ogra> well, you'D lose acceleration ... but you could surely revers engineer it
[16:28] <zyga> ogra: why?
[16:28] <ogra> not sure how useful a pi without graphics is though
[16:28] <zyga> ogra: I didn't mean not to use the blobs
[16:28] <waveform> anyway, at the moment I'm putting together a doc loosely titled "everything Dave knows about the pi bootloader but you were afraid to ask ... in case he started going on about it" - I'll stick it in as part of pibootctl's docs when it's done
[16:28] <zyga> just to load them with different helper that is open
[16:28] <ogra> because the GPU (well actually its a multi purpose DSP) is your bootloader
[16:28] <zyga> ogra: that's great
[16:28] <ogra> the boot process fires up the GPU first ... the GPU then starts the ARM
[16:29] <zyga> I can keep that part even if not open, I think you misinterpreted my comments above
[16:29] <ogra> this is wh you also dont really need a GPU driver ...
[16:29] <ogra> it is already in RAM when the ARM starts
[16:29] <zyga> my point was that a open source start.elf that contains blobs that are not open source (as today0 is better than what we have today
[16:30] <waveform> zyga, that would be a wonderful step forward (if only so I could figure out logic like the inclusion process without actually having to manually test all the possibilties - as I've done for pibootctl!)
[16:31] <waveform> anyway, I need to run off to another meeting - many thanks for the offer of help - do feel free to have a play with pibootctl and I'll see what I can add to the docs in the near future
[16:31] <zyga> o/
[16:31] <zyga> thanks for the time and info
[16:44] <AsciiWolf> kenvandine, hi, I have found another Ubuntu-related Snap Store issue... it seems that Snap Store/GNOME Software does not work properly with apps from PPAs: https://bugs.launchpad.net/snap-store/+bug/1881487
[16:46] <kenvandine> AsciiWolf: so both deb and snap.  Must be something else that has been fixed upstream since we last rebased
[16:50] <AsciiWolf> I did not try compiling upstream GS on Ubuntu, however I don't have this issue on Fedora with apps from various third-party repositories
[16:50] <AsciiWolf> only on Ubuntu with apps from PPAs that have AppStream metadata
[16:51] <kenvandine> does gnome-software on fedora use packagekit?
[16:51] <AsciiWolf> yep, it does
[16:51] <kenvandine> ok
[16:52] <AsciiWolf> btw. I am not sure if GS/PackageKit handles PPAs differently than regular (third-party) repositories
[17:36] <bdmurray> coreycb: Is comment #97 in bug 1877642 all the verification information?
[17:37] <coreycb> bdmurray: yes it is
[17:42] <bdmurray> coreycb: okay
[18:08] <bdmurray> coreycb: all the panko verifications don't seem to be done
[18:11] <coreycb> bdmurray: do you know which bug, is it 1848519 ?
[18:12] <bdmurray> coreycb: and 1859422
[18:37] <coreycb> bdmurray: I see, panko must have been stuck in focal-proposed at release time
[18:54] <coreycb> bdmurray: those bugs should be all set now