00:57 <apteryx> that indeed works well

01:59 <Forty-Bot> sjg1: say you have something like A -> B -> C -> D -> E (each a different branch) and you need to do a v2 of A

01:59 <Forty-Bot> do you know if there's a way to rebase everything automatically?

04:32 <marex> Forty-Bot: what if you have rebase conflict ?

04:32 <marex> Forty-Bot: I usually try and do octopus merge instead

04:32 <Forty-Bot> fix it and rebase --continue

04:33 <Forty-Bot> if you have a conflict when rebasing you will have one when octopus merging too

04:34 <marex> Forty-Bot: yeah, that kinda becomes non-automatic then

13:22 <apteryx> sjg1: I think I'll take a pause from producing patman patches, let them sink in, and then I may have one last think I'd like to adjust (configurability of the checkpatch script), but I need to think about it. Thanks for your time reviewing these!

15:56 <bryanb> morning Tartarus1: regarding https://lore.kernel.org/u-boot/20221219180829.10077-1-b-kapoor@ti.com

15:56 <bryanb> there are a lot of changes comming up with the next sysfw release and I wanted to try to package it all together in one series

15:58 <bryanb> this patch look good so far but there will be some more updates... didn't know how you would prefer we send this to you

16:18 <sjg1> apteryx: OK sounds good, thanks. Good to see the improvements

16:28 <jkorsnes[m]> as objects with static storage duration are initialized to 0 in c, would this hold true for the global data (gd) object as well? asking since it seems this object is treated specially. did one quick test, and it does seem to be the case.

16:51 <apteryx> is there a way to disable sending the cover letter with patman? (other than removing the Cover-letter: text from the commit?)

18:38 <marex> hm ... dang ... setting two serial consoles leads to boom

18:38 <marex> u-boot=> setenv stdout serial@30860000,serial@30880000

18:38 <marex> u-boot=> "Error" handler, esr 0xbf000002

18:40 <marex> hmmm, as if the UART clock were off

18:45 <marex> yep, clock

18:45 <marex> seems like imx8m does not manage uart clock via DM, hmmmm

19:13 <apteryx> I'm trying to build a 'u-boot-sandbox' package, and so far I'm getting link errors like: https://paste.debian.net/1264770/

19:13 <apteryx> image-host.c:(.text+0x1ea): undefined reference to `image_get_checksum_algo'

19:13 <apteryx> where do these come from?

19:23 <apteryx> u-boot itself, it seems. hm.

19:24 <apteryx> also; warning: 'image_get_spezialized_img' defined but not used [-Wunused-function] -> is this a typo? "spezialized"

19:26 <apteryx> ah, seems I need SDL

19:26 <apteryx> I'm used to configure scripts aborting on missing deps ^^'

19:57 <apteryx> hm, adding sdl2 or building with NO_SDL=1 doesn't change the earlier error

20:23 <sjg1> apteryx: re cover letter, I just type 'n' when asked whether to send the email

20:23 <apteryx> OK :-) thanks

20:23 <sjg1> apteryx: for building, see this: https://u-boot.readthedocs.io/en/latest/build/gcc.html#dependencies

20:26 <apteryx> I think I have all these

20:27 <apteryx> currently attempting to build with: bc@1.07.1 bison@3.7.6 dtc@1.6.1 flex@2.6.4 gnutls@3.7.2 lz4@1.9.3 ncurses-with-tinfo@6.2.20210619 openssl@1.1.1l perl@5.34.0 python-coverage@5.2.1 python-pycryptodomex@3.15.0 python-pytest@6.2.5 python@3.9.9 sdl2@2.24.0 swig@4.0.2 util-linux@2.37.2 (plus core stuff such as GCC, coreutils, grep, etc.)

20:28 <apteryx> u-boot-tools is built already on my system but with CONFIG_FIT_SIGNATURE, CONFIG_UT_LIB_ASN1 and CONFIG_TOOLS_LIBCRYPTO set to 'n' because of (past?) licensing incompatibilities between u-boot and openssl

20:28 <apteryx> I guess that could be a workaround if I don't figure it out

22:11 <sjg1> apteryx: Can you try a revert of: d948c8988c2 sandbox: Rework how SDL is enabled / disabled

22:12 <sjg1> apteryx: But it is more likely silently dropping a Kconfig option

22:12 <sjg1> apteryx: Like IMAGE_SIGN_INFO

22:22 <apteryx> that commit came after v2022.10, right?

22:22 <apteryx> I'm working on a package made from that last release

22:28 <apteryx> "make" "HOSTCC=gcc" "KBUILD_VERBOSE=1" sandbox_defconfig gives me the following .config: https://paste.centos.org/view/e38605af

22:29 <apteryx> which has CONFIG_IMAGE_SIGN_INFO=y

22:29 <apteryx> ah!

22:30 <apteryx> there's some old cruft in the make-u-boot-package that edits .config to disable CONFIG_TOOLS_LIBCRYPTO

22:30 <apteryx> (guix side)

22:30 <sjg1> apteryx: Yes just saw CONFIG_TOOLS_LIBCRYPTO - that will be it

22:33 <apteryx> I think this is a remnant from the times openssl had its own, GPL-incompatible license

22:33 <apteryx> now it's Apache 2.0, which is compatible, so we can combine both without issues

22:39 <apteryx> ah... Apache 2.0 is still not compatible with GPL v2, only with GPL v3

22:39 <apteryx> source: https://www.gnu.org/licenses/license-list.html#apache2

22:39 <apteryx> so incompatible license issues still exist when combining u-boot and openssl

22:40 <apteryx> it is possible to build the sandbox without openssl?

22:40 <apteryx> a NO_OPENSSL make flag could be handy for distributions

22:42 <apteryx> alternatively, would supporting another implementation difficult? e.g., gnutls

22:42 <vagrantc> in the past folks have been amenable in theory to using another implementation that doesn't have any ambiguity about license compatibility

22:42 <apteryx> vagrantc: :-)

22:42 <vagrantc> but ... the work has yet to materialize

22:43 <vagrantc> apteryx: maybe we can trick, er, encourage you? :)

22:43 <apteryx> is u-boot gpl2+ ?

22:43 <vagrantc> parts of it, but parts are gpl2-only

22:44 <apteryx> that's unfortunate

22:45 <vagrantc> relicensing those bits would probably be very hard ... maybe the code that is gpl2 only does not sufficiently interact to consider it a violation? *shrug*

22:46 <vagrantc> the other issue is even if the code doesn't currently violate, because of the presence of gpl2 code, having openssl available would make it hard to prove that new code doesn't incorporate it in new ways co-mingling incompatible licenses

22:47 <cambrian_invader> aiui the gpl2+ is so you could e.g. reuse a driver in a gpl3 project

22:47 <cambrian_invader> but anything gpl2 only makes the combined work gpl2

22:47 <vagrantc> u-boot as a project gets around the issue as it is only triggered on binary distribution, and u-boot only releases source code

22:47 <vagrantc> cambrian_invader: yeah, that is the conservative position i've held until "proven" otherwise

22:48 <vagrantc> debian quietly changed it's stance on the issue a couple years ago ... which was one of the major hold-outs