**** BEGIN LOGGING AT Mon Jan 18 02:59:57 2021 Jan 18 03:42:17 OutBackDingo: you could try the github mirrors Jan 18 03:50:19 aparcar[m]: dont work for feeds, have to edit it all for 19.07-2 Jan 18 04:14:34 OutBackDingo: well it's just a different branch isn't it? Jan 18 04:16:25 aparcar[m]: nope different git revs altogether Jan 18 04:17:00 ❯ cat feeds.conf.default Jan 18 04:17:00 src-git packages https://git.openwrt.org/feed/packages.git^99efce0cd27adfcc53384fba93f37e5ee2e517de Jan 18 04:17:00 src-git luci https://git.openwrt.org/project/luci.git^13dd17fca148965d38f0d4e578b19679a7c4daa2 Jan 18 04:17:00 src-git routing https://git.openwrt.org/feed/routing.git^efa6e5445adda9c6545f551808829ec927cbade8 Jan 18 04:17:00 src-git telephony https://git.openwrt.org/feed/telephony.git^6f95d6ab3f359ee2ce81c20522700937424d1591 Jan 18 04:19:38 Well github is a mirror so it has the very same refs Jan 18 06:11:03 aparcar[m]: mmmm not from what gitlab shows compared to openwrt Jan 18 06:13:08 I've been working on porting OpenWrt to the Actiontec MI424WR Rev. I (Avanta-based) and I think I'm pretty close. The kernel can't mount the rootfs. I'm assuming the file "root.squashfs" in the build directory is the rootfs. How do I tell the kernel to look there during the boot process? Jan 18 06:16:02 I'm a total novice, and I'm assuming I'm just missing something obvious. All I've done to get this far is tftp over a uImage that I built and run bootm. Jan 18 06:50:07 bkallus, afaik arm architectures have either: a bootenv entry with root= on internal flash, a bootscript (.scr) which overwrrites the previous entry - when booted from usb/external storage, or the kernel has an internal root= cmdline that is executed anyway and ignores the uboot option set before (on other arches like ath79 iirc this is done) Jan 18 06:51:09 so the path is likely incorrect - since "vendor" firmware and openwrt probably use different drivers meaning paths of rootfs change Jan 18 06:51:36 rootfs should be dumped/written via mtd / or other mechanics to a rootfs partition Jan 18 07:24:11 mangix why is ugps not in packages git? Jan 18 07:37:45 aparcar[m]: depdencency issue with busybox-selinux annoying? Jan 18 07:38:02 what exactly is annoying about it? Jan 18 07:47:42 aparcar[m]: perhaps ugps could be considered a core package due to PKG_SOURCE_URL=$(PROJECT_GIT)/project/ugps.git which means developed and maintained in the main tree ? But then we should probably move cgio-io from packages to main tree as well :) Jan 18 07:50:15 ynezz: I'd say because a packet is "created" within the OpenWrt project doesn't mean it has to be part of openwrt.git Jan 18 07:50:41 what do you think about perf, iperf, iperf3 and ethtool? Jan 18 07:50:57 in case of cgi-io it should, it's network exposed service and installed by default in release builds Jan 18 07:51:46 so we're doing review of patches on the mailing list, but do package bumps in packages feed Jan 18 07:54:21 cgi-io itself isnt network exposed afaik? Jan 18 07:54:51 atleast my security policy dont not associate networking rules with it Jan 18 07:56:21 i guess you mean indirectly via uhttpd or another webserver Jan 18 07:56:37 but then a lot if 'exposed' to the network Jan 18 07:56:49 grift: I think cgi-io has a direct call to upload files Jan 18 07:57:17 i see, i guess i overlooked that Jan 18 07:57:29 ynezz: you're right, which kind of means LuCI should be part of openwrt.git 😉 Let's move cgi-io over to openwrt.git and move the dev utils to packages Jan 18 07:59:23 i still needs to address upgrading firmware via luci ( and i guess that is what does the uploading) Jan 18 07:59:46 for that i would like to be able to tell sysupgrade to not reboot automatically directly Jan 18 08:00:15 ie put it in the back group and add a sleep call or something, or just dont automatically reboot at all Jan 18 08:00:21 grift: the busybox-selinux issue is that if I select the general selinux option, the build fails because the build system is confused by busybox vs busybox-selinux. I'm assuming it's an openwrt issue but still Jan 18 08:00:58 grift: https://github.com/openwrt/luci/search?q=cgi-io Jan 18 08:01:05 i cant produce that aparcar[m] Jan 18 08:01:18 grift: I'll investigate Jan 18 08:01:21 aparcar[m]: works for me Jan 18 08:01:56 grift: I'm currently working on some buildbot upgrades which hopefully allow to build a selinux release in parallel. Jan 18 08:01:59 aparcar[m]: well at least mkresin/dedeckeh would like to have dev/debugging/network troubleshooting packages in the main tree Jan 18 08:02:38 ynezz: do you know why? Jan 18 08:03:29 ynezz: yes i know i addressed most of the access: https://git.defensec.nl/?p=selinux-policy.git;a=blob;f=src/cgiscript/cgiio.cil;h=41bbd2a2bc9009d828b5d47547bbcb29abed35a8;hb=HEAD Jan 18 08:03:45 except luci-peeraddr i suppose not sure when that is triggered Jan 18 08:04:00 aparcar[m]: they don't use feeds during development and creating package symlink from feed repo to the main tree is too much hassle :) Jan 18 08:04:23 aparcar[m]: https://lists.infradead.org/pipermail/openwrt-devel/2019-August/024126.html Jan 18 08:04:42 aparcar[m]: nice Jan 18 08:05:20 ynezz: thanks, you always do you ML homework Jan 18 08:05:32 grift: time will tell Jan 18 08:06:06 afaik just ticking SELinux should be enough Jan 18 08:06:24 certainly should be enough to build, i do that all the time Jan 18 08:06:27 ynezz: I like the idea to offload the maintenance of these tools and also speed up phase1 Jan 18 08:06:37 aparcar[m]: FYI I don't use feeds either, but still use packages from there sometime https://lists.infradead.org/pipermail/openwrt-devel/2019-August/024177.html Jan 18 08:07:03 aparcar[m]: AFAIK those packages are build in phase2 anyway Jan 18 08:07:13 phase1 only builds those for images Jan 18 08:08:51 ynezz: I think you're right! Jan 18 08:09:13 I'll just send patches and put them in cc Jan 18 08:09:55 if they did not change their mins after your response (which never got a response?) I'll see where the discussion goes to Jan 18 08:12:32 aparcar[m]: btw you can't build perf with SDK, so it makes no sense to move it to packages.git Jan 18 08:12:46 but iperf correct? Jan 18 08:13:32 if I need it I `opkg install` it anyway Jan 18 08:13:57 but I might have different workflow Jan 18 08:13:57 agree Jan 18 08:15:23 grift: I wish there was something like uselinux (microselinux) which could be enabled and shipped by default by !SMALL_FLASH targets Jan 18 08:16:03 uh grift do you know if someone works on busybox selinux api updates? afaik it's legacy right? Jan 18 08:16:49 grift: hoping your effort goes well, I did read your mail. Jan 18 08:17:02 nbd: are you okay with moving perf(3) over? Jan 18 08:17:14 you can't do that :p Jan 18 08:17:16 at least it says you're the maintainer Jan 18 08:17:41 oh iperf Jan 18 08:17:47 sry Jan 18 08:19:02 ynezz: did you have a look at the AUTORELEASE patch? Jan 18 08:27:47 grift: I assume, that selinux is quite resource heavy and thus usable only on a few big targets like aarch64/x86_64, so it might get traction when/if those targets become store shelf standard due to wifi6/11ax demand, but then people will disable it to get 20% performance boost :p Jan 18 08:28:31 like they're disabling spectre mitigations and such :p Jan 18 08:29:09 ynezz define resource hungry Jan 18 08:30:02 theres no 20% performance degradating Jan 18 08:30:26 more like 2% maybe Jan 18 08:31:29 but it would be nice if someone with perf experience would have a closer look Jan 18 08:32:30 While I don't know anything about selinux toll, in general things are always need to put into scopes... for random consumer router and especially purely AP, gain for any of migitations or "security stuff" is diminishing... but if the thing is also made to serve DNS and generally more thing than just routing, especially to internet, then it can be beneficial to use such things, but deployers of those might already know Jan 18 08:32:30 better Jan 18 08:33:09 i dont see it like that Jan 18 08:33:47 selinux enhances continuity of operations , and that *ca* be beneficial equally to all Jan 18 08:33:49 yeah, I think a baseline security level is always a good place to start. Jan 18 08:34:04 security shouldn't be opt-in. Jan 18 08:34:38 it was linus' idea to create LSM Jan 18 08:35:10 and that essentially made it so that people could use an excuse and say: well mac isnt enabled by default so must not be important Jan 18 08:35:31 but linus' just wanted people to be able to choose between implementations Jan 18 08:36:34 Like said, I didn't specifically target selinux there.. And yes I also agree that at least per default things should be safe (whatever that entails), and generally I'd say openwrt build defaults relating are just nice (of those that are implemented) Jan 18 08:38:22 i really have a hard time understanding why people , especially industry workers, can't see the problem with traditional access control Jan 18 08:39:01 same with ip6 vs ip4 Jan 18 08:39:28 this industry should be advocating and working actively to prefer ip6 over ip4 Jan 18 08:39:50 The fact that form of ipv6 natting "needed" to made into existence tells alot, kinda ;P Jan 18 08:41:09 i was looking into the busybox built settings the other day to disable the ntpd app, and there was an option ticked prefer ip4 for dns name resolving Jan 18 08:41:26 things like that should just prefer ip6 instead Jan 18 08:49:12 grift: probably stems from the fact that ip6 is anything but reliable is many places still... Jan 18 08:53:30 grift, not all isp`s have ipv6 implemented yet Jan 18 08:53:51 its a preference option Jan 18 08:54:15 ie if theres ip6 then prefer that, if not the obviously it does not apply Jan 18 08:54:36 grift, correct, but builds are catered for everyone ;) Jan 18 08:56:41 ok then lest turn the tables Jan 18 08:56:52 what if i only have an ip6 stack and not ip4? Jan 18 08:59:29 if there's no ip4 stack enabled in the system the prefer probably doesn't apply anyway since getaddrinfo() and friends won't consider ip4 Jan 18 08:59:40 when it comes to selinux this is why i admire red hats leadership in this industry Jan 18 09:00:19 they actively take the industry in a direction Jan 18 09:00:23 Issue where such option stems is likely that suprisingly many places/ISP/networks/things allures systems to thign there is ipv6 connectivity (to outside world, not just stack existing) and then much everything failing, being sluggish, etc Jan 18 09:00:48 *nod* Jan 18 09:03:06 if thats true and if it just apply to getaddrinfo() then the sluggishness will currently probably be the issue for the people using ip6 only with this setting Jan 18 09:03:49 becaise it will try ip4 first, determines theres no connectivity, then try ip6 (or whatever) Jan 18 09:04:09 no. If there's no ip4 stack, getaddrinfo() doesn't "try" ip4 Jan 18 09:04:18 anyways, its not my field of expertise i just found it ironic Jan 18 09:04:41 yes but openwrt build with ip4 stack? Jan 18 09:04:46 you said it yourself: Jan 18 09:05:08 09:54 < nitroshift> grift, correct, but builds are catered for everyone ;) Jan 18 09:06:27 last words. i might be wrong but the way i see if ip4 is favored over ip6 Jan 18 09:06:40 it should be the other way around Jan 18 09:06:45 if both are available yes Jan 18 09:08:00 as I mentioned before, it's (unfortunately) still not rare that when both stacks are present, ip6 is less reliable. Not to mention the case where ip6 is a tunnel into ip4, in which case the performance penalty is very high. Jan 18 09:08:35 Usually default state is not to favour anything but the answer that is got first (aka does not matter is it v4 or v6), obviously where both stacks are enabled and in use Jan 18 09:12:58 but asides from that compare (in some way's) the ip4->ip6 transition to the dac->mac transition Jan 18 09:13:25 thats why modernisation is happening so slowly Jan 18 09:59:02 it happens slowly, because people don't care enough Jan 18 09:59:39 this stuff needs to be made mandatory from goverment, otherwise it's optional and nobody cares Jan 18 10:00:38 for many of us, the gains are extremelt hard to quantify, and the costs are real and measurable. (applies to both v6 and selinux) Jan 18 10:01:47 I mean, IIRC we've ipv6 mandatory since 2016 for new goverment services, but for example they've just launched new reservation system for covid-19 vaccination and it's ipv4 only Jan 18 10:02:10 isn't it like climate change were you postpone the problem due to missing direct impact and next thing you know 30 mio routers are part of a botnet causing aws downtimes? Jan 18 10:02:50 so I keep saying, I don't care about ipv6 that mich and just wait for ipv7 :p Jan 18 10:02:56 s/mich/much/ Jan 18 10:03:58 Security notice - Site break-in on 16-Jan-2021 Jan 18 10:03:58 Around 0400 GMT on 16 Jan 2021, an administrator account on the OpenWrt forum (https://forum.openwrt.org) was breached. It is not known how the account was accessed: the account had a good password, but did not have two-factor authentication enabled. Jan 18 10:03:59 The intruder was able to download a copy of the user list that contains email addresses, handles, and other statistical information about the users of the forum. Although we do not believe the intruder could download the database, from an abundance of caution, we are following the advice of the Discourse community and have reset all passwords on the Forum, and flushed any API keys. Jan 18 10:04:29 Tapper: are you Ted? Jan 18 10:05:06 no mate. Jan 18 10:05:17 From the forums. Jan 18 10:05:31 I see, Hi Jan 18 10:05:32 That is what pops up befor you logno Jan 18 10:05:42 login now Jan 18 10:13:19 Do we know who's account was breached? Privately if need be Jan 18 10:13:49 not mine, I don't have admin access and use U2F :) Jan 18 10:15:01 I haven't been told it was mine but then I don't have admin either AFAIK Jan 18 10:16:40 * Borromini didn't even know discourse supported 2FA Jan 18 10:17:02 stintel: what hardware? Jan 18 10:17:17 U2F i mean Jan 18 10:17:22 Solo Jan 18 10:17:25 open! Jan 18 10:17:51 https://solokeys.com/ Jan 18 10:18:04 https://github.com/solokeys/solo-hw Jan 18 10:18:18 https://github.com/solokeys/solo Jan 18 10:20:11 thanks. you got both usb-c and usb-a? Jan 18 10:20:14 yes Jan 18 10:20:43 :) Jan 18 10:21:03 only downside of the solo vs yubikey is that solo does not support ed25519 ssh keys yet Jan 18 10:21:06 been looking at them before. do you use nfc? Jan 18 10:21:24 but google titan and probably yubikey also can be cloned apparently Jan 18 10:21:31 I do Jan 18 10:21:54 I also use those keys for sudo Jan 18 10:21:59 neat Jan 18 10:22:08 you got a somu or just the big ones? Jan 18 10:22:12 safer than NOPASSWD but more convenient than typing a password Jan 18 10:22:23 2 somu, 1 usb-c + nfc, 1 usb-a + nfc Jan 18 10:22:30 :) Jan 18 10:22:43 i just upped my sudo timeout to 1h :P Jan 18 10:22:48 not the smartest thing either i reckon :P Jan 18 10:23:09 well if your browser gets pwnd it could be instant root Jan 18 10:23:16 that's why I opted for this approach Jan 18 10:24:57 :) Jan 18 10:25:05 * Borromini looks for a shop *not* in the UK Jan 18 10:25:15 they ship from .de Jan 18 10:25:25 yeah looks like it Jan 18 10:25:44 https://solokeys.de/ Jan 18 10:25:45 no ed25519... like anyone uses anything else unless absolutely needed to 😜 maybe the v2 addresses that issue Jan 18 10:26:11 is there a v2 on the way olmari ? Jan 18 10:26:51 Site says there is, when I don't know, nor I directly know does it support 25519 Jan 18 10:30:30 unless https://solokeys.com/v2 is already old info and current things are v2 Jan 18 10:31:37 https://solokeys.com/blogs/news/a-new-year-a-new-launch-solo-v2 Jan 18 10:32:27 ty Jan 18 10:32:52 mm.. I'm still trying to dig what it actually does support, or that even could be made to Jan 18 10:33:43 * Borromini subscribed Jan 18 10:34:04 ldir: he was having beer with just you and me the last day in Hamburg, is that enough? :) Jan 18 10:34:29 https://github.com/solokeys/solo/issues/443 Jan 18 10:39:54 ynezz Jan 18 10:39:54 ldir: What I would not do to go out with good people and have a beer or to. Jan 18 10:40:09 two* Jan 18 10:41:16 Bring on this vaccine! Jan 18 10:41:34 stintel: Thanks, dropped noise there for importance of ed25519 ;P Jan 18 10:41:48 :) Jan 18 10:41:58 be it any use for anyone there.. not that noise here will help either :D Jan 18 10:53:51 ynezz: I think I remember... the beer worked is all I'm saying. I seem to remember a walk to the train station to check routes to airports. Jan 18 11:29:45 apparently I bought a bootlooping ER-X. what did I get myself into? Jan 18 11:31:34 might be dead flash Jan 18 11:31:47 get serial and check what is going on Jan 18 11:32:01 you can try tftp recovery though Jan 18 11:32:43 dead flash sounds no good. isn't it using NAND? Jan 18 11:33:07 they have some weird flash issue. needs serial and reflash and you should be good to go again Jan 18 11:33:23 some update caused this, can't remember what Jan 18 11:33:56 tons of those dead er-x turned up cheap on ebay for easy repair Jan 18 11:34:26 ...wow you just made my day Jan 18 11:40:04 mangix: you got it to play with? Jan 18 11:40:10 er-x is mt7621 no Jan 18 11:40:58 * stintel reads 24V PoE, closes browser tab Jan 18 11:41:18 Borromini: lemmi explained Jan 18 11:41:48 i have no mt7621 device right now anyway Jan 18 11:42:50 mangix: he explained what they suffer from, but not what your intentions were :) Jan 18 11:42:54 stintel: hehe Jan 18 11:44:50 play with for now. I only bought it for the low price. Jan 18 11:45:45 :) Jan 18 11:46:39 that would be the second device I have with SFP, which I can't even use Jan 18 11:46:52 :P Jan 18 11:47:09 i have my first PoE client devices on the way Jan 18 11:47:36 looking at it again, it's pretty barebone Jan 18 11:47:37 mangix: but that means you have the er-x-sfp. basically the same part, but just to be accurate Jan 18 11:47:54 someone on the forums told me his GS1900-8HP seems unstable with PoE, at least his aruba AP fed by it seems to reboot after an hour Jan 18 11:48:15 no sd card, usb, wifi, etc... Jan 18 11:48:50 Borromini: I need 2 hands to count mine :P Jan 18 11:48:55 yeah it's just a tiny wired router Jan 18 11:48:56 and the sfp port only works on master, doesn't work with 19.x.y Jan 18 11:49:07 stintel: lol Jan 18 11:49:09 oh of course Jan 18 11:49:27 * Borromini had PoE and SFP mixed up again Jan 18 11:49:30 i would not even conaider running 19.07 Jan 18 11:49:56 too many reports of crashing ethernet driber Jan 18 11:50:01 *driver Jan 18 11:50:29 and it's passive 24V PoE, so triple check if the other device supports that or if it is going to be cooked by it Jan 18 11:50:59 i have tons of these things working, and never experienced that crashing driver problem. Jan 18 11:51:22 I think it's hardware dependent Jan 18 11:51:44 that is, broken mt7621 re isions Jan 18 11:52:05 apparently it has something to do with pause-frames. but almost nothing uses that in my setups, so i might just have avoided this problem that way Jan 18 11:52:24 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 95.2% packages reproducible in our current test framework.) Jan 18 11:53:07 anyway, does PoE need to be enabled? Jan 18 11:53:39 it's per default disabled Jan 18 11:53:55 that's what I thought Jan 18 11:54:28 can't have that with passive poe Jan 18 11:57:24 indeed.. "active" or any standard 802.3xx compliant PoE device will not give power until/unless device specifically asks for it Jan 18 11:58:05 "passive" in otherhand is slang word for "ef the standards, just put whatever voltage to be present on wires always" Jan 18 12:00:02 ubiquiti poe? :P Jan 18 12:00:32 olmari: what could go wrong Jan 18 12:01:10 remindsmeof early type c power adapters Jan 18 12:02:12 mangix: see https://bugs.openwrt.org/index.php?do=details&task_id=2713 and https://bugs.openwrt.org/index.php?do=details&task_id=3206 Jan 18 12:02:59 For the interested, active poe first measures is there certain resistance between certain wires, indicating there is PoE capable device present on other end, then it gives some small power so device can get power up neccesary parts to actually communicate what kind of power it really needs :) Jan 18 12:05:20 nnot quite like type c :) Jan 18 14:15:59 build #194 of at91/sama5 is complete: Failure [failed pkgbuild] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/at91%2Fsama5/builds/194 blamelist: Rosen Penev , Hauke Mehrtens Jan 18 14:23:12 dorf_: also seems there was a BasicAuth option added to tinyproxy but /etc/init.d/tinyproxy does not support it Jan 18 14:25:43 its pretty neat service though, i have it proxy http transparently for my guest network, unfortunately https transparent proxying does not work, then i have it set to filter by default and just a whitelisted some domains Jan 18 14:41:06 grift: yeah, it's not bad is it? if you can make it more openwrt friendly, I'm sure it would be much appreciated :) Jan 18 14:41:35 polipo and privoxy should probably be retired. Jan 18 14:45:27 maybe squid as well Jan 18 14:49:02 yeah, squid could also be retired. that's super-bloat central. Jan 18 14:50:36 yes but squid has some unique caching functionality albeit useless on routers probably Jan 18 14:58:41 true, squid does do caching, but that's more the domain of an x86 server. Jan 18 14:58:49 (as is squid) Jan 18 14:59:05 I forgot tinyproxy already has a luci front end. Jan 18 15:09:08 nice Jan 18 15:52:52 grift: one thing that's less than optimal with tinyproxy is the divergent-from-upstream conf file. Jan 18 15:58:20 I'm having a hard time configuring an upstream proxy to forward all requests, when it should be trivial. :| Jan 18 16:04:03 the luci app has an issue with entering '.' in the target host field, despite the help text underneath, and it should support * for all hosts or, failing that, an empty field should parse as "all hosts and domains". Jan 18 16:04:45 there's also no method in the ui to select the proxy type, which is not so hot. Jan 18 16:05:49 i havent tried that functionality yet Jan 18 16:06:19 neither luci integration not proxy chains Jan 18 16:22:39 it has potential at least :) Jan 18 17:12:51 jow: did u see my PR regarding owipcalc? https://github.com/openwrt/openwrt/pull/3793 Jan 18 19:33:28 49,999 commits :) Jan 18 19:34:28 aparcar: will there be a ceremony for the 50000th commit? :-) Jan 18 19:34:49 svanheule: i hope Jan 18 19:42:35 mangix: ping Jan 18 19:45:55 nbd: ping Jan 18 19:47:48 aparcar[m]: pong Jan 18 19:48:50 nbd: I think the issue I'm seeing in MT7615 is basically this one. https://github.com/openwrt/mt76/issues/410 Jan 18 19:50:25 nbd: Actually, it's all broadcast not getting through. Jan 18 20:01:30 mangix: your autoconf patch is broken Jan 18 20:02:10 unfortunate Jan 18 20:10:08 mangix: very, mind sending a patch? Jan 18 20:34:48 mangix: sorry you may got some spam from me Jan 18 20:43:51 the at91 taregt is not compoling in 19.07 any more becasue someone deleted the git tags OpenWrt points to in the reposetory and we do not have a mirror hash. Jan 18 20:46:12 luckyly we haev it already on our mirrors and when using the same commit hash from a random fork on github I also get the same tar.gz Jan 18 20:47:14 what repo? Jan 18 20:47:25 I thought mchp wsa doing a fair job of looking after this stuff? Jan 18 20:48:56 someone removed some tags from these repos: https://github.com/linux4sam/u-boot-at91 Jan 18 20:49:10 https://github.com/linux4sam/at91bootstrap Jan 18 20:49:30 I have a fix, so OpenWrt will work again, I will also send a mail to the poeple from microchip Jan 18 21:19:06 Hello! Who know latest driver for Ralink rt2800 and rt2x00 with full speed WiFi? Jan 18 21:19:32 you'll be limitied by usb2 anyway Jan 18 21:21:10 shibboleth: You about my question? Jan 18 21:21:22 yeah Jan 18 21:21:37 shibboleth: Big thank for you! Jan 18 21:25:16 Hauke: what a boring 50k commit ;) Jan 18 21:36:32 it looks like the github repos for u-boot-at91 and at91bootstrap are ok, just github didn't want to talk to us and there seams to be some problems when doing "make package/at91bootstrap/download V=99" Jan 18 21:36:53 but havbing a mirror hash is good as we do not haev to clone this repo all the time Jan 18 23:27:30 Hauke: i think it was some python problem Jan 18 23:28:54 yeah https://downloads.openwrt.org/releases/faillogs-19.07/arm_arm926ej-s/base/uboot-at91/at91sam9m10g45ek_nandflash/compile.txt Jan 18 23:29:32 it went away with a version update Jan 18 23:34:40 hauke fixed this http://buildbot.openwrt.org/openwrt-19.07/images/builders/at91%2Fsama5/builds/194 Jan 18 23:35:01 Download from https://github.com/linux4sam/at91bootstrap.git failed Jan 18 23:36:41 separate issue then Jan 19 01:03:21 I'm working on a build of openwrt for the actiontec mi424wr rev i, and I got something booting. However, when I add DEVICE_PACKAGES := kmod-ath9k to my device's config in the kirkwood image makefile, it tells me that certain packages are "incompatible with the architectures configured" Jan 19 01:03:34 where do I go from here? Jan 19 01:07:47 aparcar[m]: sent new autoconf patch Jan 19 01:38:11 aclocal.m4:6: error: Exactly version 2.69 of Autoconf is required but you have 2.70 Jan 19 01:38:15 what the hell Jan 19 01:39:46 heh Jan 19 01:39:57 that's a glibc error Jan 19 01:39:57 mangix: keep me posted Jan 19 01:40:28 going to try a musl build now Jan 19 01:44:10 I think it's because the glibc is subtly broken Jan 19 01:44:30 I remember an issue on CentOS 7 where it doesn't compile due to old make version Jan 19 01:44:43 it's supposed to use tools/make but uses OS make Jan 19 01:46:05 musl compiled Jan 19 02:26:30 aparcar[m]: meh ignore it. a bunch of packages fail Jan 19 02:26:45 someone else can deal with it **** ENDING LOGGING AT Tue Jan 19 03:00:19 2021