**** BEGIN LOGGING AT Wed Nov 11 03:02:41 2020
Nov 11 04:16:19 <FirstTime_NoTime> Hello, getting my patch ready for submission is nearly more labour intensive than creating the patch for a new raimps device. Can anyone have a quick look at my patch set? https://pastebin.com/11QMYR8e
Nov 11 08:59:15 <rsalvaterra> aparcar[m]: ping
Nov 11 08:59:22 <aparcar[m]> ping
Nov 11 09:00:00 <rsalvaterra> I think we thought the same thing, so it's better to ask you beforehand… ;)
Nov 11 09:00:31 <rsalvaterra> I've seen your bug report on ELFKickers. Have you tried to update sstrip to the current version?
Nov 11 09:09:24 <aparcar[m]> no haven't touched it since
Nov 11 09:09:49 <rsalvaterra> Alright, thanks for letting me know. I'm going to take it for a spin.
Nov 11 09:10:14 <rsalvaterra> If it works, maybe we can patch it locally to sync the version numbers?
Nov 11 09:23:45 <aparcar[m]> rsalvaterra: would be cool
Nov 11 09:23:56 <aparcar[m]> you could also ping upstream again, not sure if they still maintain it
Nov 11 09:25:57 <rsalvaterra> Yeah, that's what worries me about sstrip… yet, the version is our tree is even older, 3.1a is from last year, and there have been commits this year…
Nov 11 09:26:16 <rsalvaterra> Probably not dead, but in maintenance mode.
Nov 11 09:29:08 <aparcar[m]> I'm happy to test a update if you have the time
Nov 11 09:30:22 <rsalvaterra> I'm taking the opportunity to learn how to create a new package, so it's not going to be terribly fast. :)
Nov 11 09:32:13 <aparcar[m]> if you don't try to package a Rust tool like Grommish it should be fairly easy :)
Nov 11 09:34:33 <rsalvaterra> Yeah, that must have been "fun", but he's got Suricata 6 working!
Nov 11 11:59:39 <rsalvaterra1> aparcar[m]: Almost there, surprisingly. I needed to hack the original makefile not to try to compile elftoc, since it fails miserably with musl's elf.h.
Nov 11 11:59:59 <rsalvaterra1> But we don't need that, anyway. We just want sstrip.
Nov 11 13:19:53 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
Nov 11 14:03:52 <rsalvaterra> dangole: Go doesn't like MIPS16, heh?
Nov 11 14:04:45 <dangole> rsalvaterra: not always, apparently. in some rare cases it works... but MIPS toolchain is generally massively borked, I wouldn't even blame Go for that
Nov 11 14:05:49 <rsalvaterra> I haven't bumped into any issues with GCC 10.2… I'm even building wolfSSL and OpenSSL with MIPS16, here.
Nov 11 14:06:29 <dangole> rsalvaterra: i've tried gcc-10 just for fun a week ago on MIPS64 (be) and it failed to even start init (kernel looked fine though)
Nov 11 14:06:50 <rsalvaterra> dangole: Are you using mklibs?
Nov 11 14:07:47 <dangole> rsalvaterra: no, i didn't strip things at all for that (as i was expecting to run into problems and wanted to be ready to attack them with gdb)
Nov 11 14:08:24 <rsalvaterra> I see… I don't have any MIPS64 machines for testing, unfortunately… :)
Nov 11 14:09:45 <rsalvaterra> I ordered a Redmi AC2100 on AliExpress, though. I want to play a bit with MediaTek stuff.
Nov 11 14:46:26 <dangole> rsalvaterra: i also only tested on qemu, no "real" MIPS64 hardware around. i've deployed ERLite a couple of times and it generally works well, but it's all used in production in other people's places, so i can't exactly test-run stuff on that...
Nov 11 15:12:01 <damex> if you're in europe - i have heard that edgerouter 8 and edgerouter 8 pro might come very close to 20~30 bucks shipped or something like that
Nov 11 15:12:27 <damex> used ofcourse ;p
Nov 11 15:34:08 <rsalvaterra> damex: Where??
Nov 11 15:34:33 <damex> rsalvaterra: ebay :)
Nov 11 15:38:10 <rsalvaterra> damex: From a cursory search, that's blatantly false. Unfortunately. :P
Nov 11 15:38:34 <damex> rsalvaterra: i have heard that from lemmi so he might help you with that ;)
Nov 11 15:40:01 <rsalvaterra> One thing that worries me (in the long term) about the Redmi AC2100 is the fixed 4 MiB kernel partition…
Nov 11 15:41:39 <Grommish> aparcar[m]: hehe I could just leave it so it adds 2 hour to a clean build.  That seems like such a waste though since it really isn't needed hehe
Nov 11 15:42:15 <Grommish> Now I'm at a point I can actually work on Suricata though..  which is a whole new interesting thing
Nov 11 15:42:26 <Grommish> Hyperscan by Intel is next :)
Nov 11 17:16:01 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 99.7% packages reproducible in our current test framework.)
Nov 11 17:17:37 <adrianschmutzler> would somebody please trigger buildbot for layerscape/armv8_64b on 18.06?
Nov 11 17:17:52 <adrianschmutzler> I've just pushed a possible fix
Nov 11 17:23:50 <Hauke> adrianschmutzler: I can just build it manually
Nov 11 17:25:04 <adrianschmutzler> Hauke: I tried to build it locally myself, but I had a different error than before about missing Python.h for uboot-layerscape ...
Nov 11 17:25:42 <adrianschmutzler> I was hoping this would go away with different environment; but maybe that's also the case when you build it
Nov 11 17:26:56 <adrianschmutzler> I just hope it's a missing dependency somewhere, as I don't really want to invest more time into this
Nov 11 17:28:01 <adrianschmutzler> (I've never built 18.06 on this machine before)
Nov 11 17:32:12 <Hauke> adrianschmutzler: I started a build now on my could server
Nov 11 17:32:56 <zorun> adrianschmutzler: thanks for looking at this, I think the buildbots will pick it up eventually (there aren't that many builders for 18.06)
Nov 11 17:34:02 <Hauke> adrianschmutzler: I think it takes ~24 hours till all 18.06 images are build again
Nov 11 17:34:54 <adrianschmutzler> I just looked at the history of individual builders and there appear to be huge gaps between the builds ...
Nov 11 17:35:04 <adrianschmutzler> so I assumed this is somehow triggered manually
Nov 11 17:35:22 <adrianschmutzler> particularly since those gaps are unevenly distributed
Nov 11 17:35:32 <aparcar[m]> zorun: could you please test https://github.com/aparcar/openwrt/commit/8b7ebd99c3ea9a750ebe5f094bafd2e24923baa3 for imagebuilder signature checking
Nov 11 17:36:22 <zorun> adrianschmutzler: see http://buildbot.openwrt.org/openwrt-18.06/images/grid : there are only 3 builders for many targets
Nov 11 17:36:42 <adrianschmutzler> Hauke: thanks; so lets see whether we are lucky
Nov 11 17:38:51 <adrianschmutzler> Just looked into the downloads, the last release including armv8_64b was 18.06.4
Nov 11 17:38:57 <adrianschmutzler> Jul 1 2019
Nov 11 17:39:34 <zorun> aparcar[m]: I haven't delved back into this, but from a cursory look it's still not clear to me
Nov 11 17:40:36 <zorun> aparcar[m]: the goal of this commit is to add signature verification when the imagebuilder downloads packages (which is good), but it's not clear why you are also adding new key infrastructure etc, it seems unrelated
Nov 11 17:41:10 <aparcar[m]> signature verification requires keys
Nov 11 17:41:13 <zorun> aparcar[m]: and I still don't understand this last sentence: "adding the advantage that sysupgrades can validate the ImageBuilders local key"
Nov 11 17:41:18 <aparcar[m]> and where else would you store them?
Nov 11 17:42:26 <aparcar[m]> imagebuilder has to be shipped with valid keys, as the download of the openwrt-keyring package would be a chicken/egg problem
Nov 11 17:42:27 <zorun> aparcar[m]: can you send an email with a summary of the problem / possible solutions / their advantages & shortcomings?
Nov 11 17:43:04 <zorun> I mean, you are adding keys that end up in the images, right?
Nov 11 17:43:06 <aparcar[m]> I think I wrote one a while back, I'll forward it to you
Nov 11 17:43:15 <zorun> ah, thanks
Nov 11 17:43:16 <aparcar[m]> no they don't add up in the images
Nov 11 17:43:23 <aparcar[m]> they are just used for the imagebuilders opkg
Nov 11 17:43:43 <aparcar[m]> optionally you can add a locally generated one. just the same as it's done in the openwrt buildroot
Nov 11 17:44:20 <aparcar[m]> created images can be signed, which means a signature is attached to the very end. a running device can verify that signature before installing the image
Nov 11 17:44:36 <aparcar[m]> if the imagebuilder has its own key, it can build images and sign them
Nov 11 17:45:28 <zorun> we really have image signature in sysupgrade?
Nov 11 17:47:41 <aparcar[m]> yes it
Nov 11 17:47:50 <aparcar[m]> 's just not really activated yet https://github.com/openwrt/openwrt/pull/1992
Nov 11 17:48:18 <zorun> aparcar[m]: ok, it looks good then, but you should clarify which part happens on the build host and which part happens on the device
Nov 11 17:48:47 <aparcar[m]> okay I'll modify that
Nov 11 17:48:48 <zorun> I thought the second-to-last paragraph was talking about the device opkg, but now that I read it again with your comments it's probably about the imagebuilder opkg
Nov 11 17:48:57 <zorun> it needs clarification
Nov 11 17:49:45 <zorun> and you should document this new feature (the part about add local keys to the imagebuilder and optionally pushing them to the device images)
Nov 11 17:50:23 <zorun> in the wiki or in the imagebuilder help
Nov 11 17:50:52 <zorun> also, clarify where this ADD_LOCAL_KEY option can be changed: when generating the imagebuilder, or when running the imagebuilder?
Nov 11 17:51:45 <Grommish> I need python3-yaml on the host, but it doesn't have a host install. (i already have python3/host)  Does anyone know of a way to have the fake buildroot also use python3-yaml?
Nov 11 17:57:37 <aparcar[m]> zorun: mind helping me with those phrasings?
Nov 11 18:16:00 <zorun> aparcar[m]: sorry, it's your code, and I don't have lots of time
Nov 11 18:16:30 <zorun> adrianschmutzler: fyi, I had started a build and building the kernel seems to work. however it fails when building mac80211 because of some broadcom stuff: http://paste.debian.net/hidden/b1c17bb4/
Nov 11 18:16:58 <zorun> if this target hasn't been built for more than one year, it's probably a rabbit hole...
Nov 11 18:23:21 <adrianschmutzler> probably some mac80211 bump that didn't fail earlier since the target failed anyway?
Nov 11 18:23:50 <adrianschmutzler> err
Nov 11 18:23:57 <adrianschmutzler> warning: overriding recipe for target '/home/bjonglez/openwrt-18.06/dl/broadcom-wl-5.100.138.tar.bz2'
Nov 11 18:24:04 <adrianschmutzler> warning: ignoring old recipe for target '/home/bjonglez/openwrt-18.06/dl/broadcom-wl-5.100.138.tar.bz2'
Nov 11 18:24:28 <adrianschmutzler> looks like you should do make clean and/or rm -rf dl
Nov 11 19:55:53 <Hauke> adrianschmutzler: openwrt-18.06 build on layerscape/armv8_64b failed for me in brcmfmac
Nov 11 20:00:12 <adrianschmutzler> Hauke: okay, that's at least a different problem now
Nov 11 20:01:05 <adrianschmutzler> not sure whether it's worth to invest further time, though
Nov 11 20:16:12 <f00b4r0> hmm, Luci tells me uptime is "24h 45m 45s" on current master
Nov 11 20:16:18 <f00b4r0> which looks a bit odd
Nov 11 20:19:58 <Grommish> Anyone know how to properly use DownloadMethod/Default (or /git)?
Nov 11 20:27:07 <Hauke> adrianschmutzler: now it compiles for me
Nov 11 20:44:30 <rsalvaterra> It's becoming painfully clear that hacking on the toolchain on a slow machine is a terrible idea.
Nov 11 20:44:47 <rsalvaterra> I mean the hacking part is fine…
Nov 11 20:44:53 <rsalvaterra> … testing, however…
Nov 11 20:46:17 <Borromini> :P
Nov 11 20:48:32 <rsalvaterra> Borromini: Yeah, takes about 4 hours to rebuild the world, here.
Nov 11 20:50:24 <rsalvaterra> And then comes the question… "Which system shall I brick?" (Because nothing works the first time, obviously.)
Nov 11 20:58:17 <Borromini> ;)
Nov 11 21:46:25 <adrianschmutzler> Hauke: nice, so the python.h problem was really local after all
Nov 11 21:50:32 <Hauke> adrianschmutzler: yes probably
Nov 11 21:50:39 <Hauke> lets see if it builds now in build bot
Nov 11 23:59:00 <rsalvaterra> aparcar[m]: ping
Nov 12 00:20:32 <aparcar[m]> rsalvaterra: mobile pong
Nov 12 02:37:17 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_ar71xx.html has been updated. (99.1% images and 100.0% packages reproducible in our current test framework.)
**** ENDING LOGGING AT Thu Nov 12 02:59:56 2020