**** BEGIN LOGGING AT Sun Dec 20 02:59:57 2020
**** BEGIN LOGGING AT Sun Dec 20 08:38:20 2020
Dec 20 09:44:42 <RP> kanavin_home: looks like we have intermittent reproducibility issues in grub, u-boot-tools and man :/
Dec 20 09:45:12 <RP> had hoped I'd fixed the grub one but obviously not entirely :(
Dec 20 09:48:11 <kanavin_home> RP: the easy way out is to add them to the exception list :-/
Dec 20 09:49:14 <kanavin_home> RP: the problem with that is things that break reproducibility intermittently would get merged, then fail to reproduce much later, and the list would just keep growing
Dec 20 09:49:19 <RP> kanavin_home: the u-boot-tools one looks like somehow LOCALVERSION is set on one builder
Dec 20 09:49:47 <RP> kanavin_home: the grub one looks like file linking commands changing order as far as I can tell
Dec 20 09:50:25 <RP> kanavin_home: its also possible hash equivalence is "infecting" things :( I'm noticing a growing problem with that :(
Dec 20 09:50:38 <RP> kanavin_home: I know what you mean about not wanting the list to grow
Dec 20 11:23:48 <RP> kanavin_home: somehow the build of u-boot-tools on debian9-ty-2 has the version with "-dirty" on the end, even though when I run the command that should generate that, it doesn't any more :/
Dec 20 11:25:19 * RP pauses that worker until he can look properly
Dec 20 12:14:23 <RP> kanavin_home: you'll love the "fix" for u-boot
Dec 20 12:55:10 <kanavin_home> RP: yikes. I never looked at u-boot, as it never showed up in my tests.
Dec 20 14:49:58 <RP> kanavin_home: found the second grub issue too (I hope)
Dec 20 22:55:45 <tlwoerner> jonesv[m]: there is no such thing as a default bootloader. typically someone (or some company) will put in the effort to port one bootloader to a given board/SoC, and that becomes the bootloader for that board
Dec 20 22:56:11 <tlwoerner> in theory any bootloader could boot any board… if someone ports it
Dec 20 22:56:29 <tlwoerner> but in practice there is generally one bootloader for a given board
Dec 20 22:57:32 <tlwoerner> jonesv[m]: *in general* grub is used for x86 boards and u-boot for everything else
Dec 20 22:58:12 <tlwoerner> jonesv[m]: every board is special, but with the raspberry pi, it is even more special (special-er?)
Dec 20 22:59:02 <tlwoerner> jonesv[m]: when the rpi comes out of reset, it is the GPU that gets run first
Dec 20 22:59:29 <tlwoerner> it is then the job of the GPU to start up the CPU(s), then load the next stage of the boot
Dec 20 23:00:25 <tlwoerner> on the raspberry pi the GPU can boot linux directly (GPU → linux), or it can optionally chain-load u-boot (GPU → u-boot → linux)
Dec 20 23:01:42 <tlwoerner> jonesv[m]: i don't know much about fastboot, that's an android thing. it is used on boards like the dragonboard to load your image into the onboard eMMC via the OTG port
Dec 20 23:02:21 <tlwoerner> but that's because fastboot is supported in the SoC's firmware
Dec 20 23:03:02 <tlwoerner> in the yocto world we rely on the BSP layer for the board to know which bootloader to use and to build and set it up properly
**** ENDING LOGGING AT Mon Dec 21 02:59:56 2020