**** BEGIN LOGGING AT Mon Sep 16 03:00:52 2019 Sep 16 03:07:50 is patchwork supposed to be down? Sep 16 04:52:04 hello Sep 16 05:26:37 rmilecki: hey Sep 16 05:51:33 I'm trying to rebuild the snapshots but the kernel versions are always different, even tho I'm using the same openwrt.git commit. What am I missing here? http://5.9.6.233/SNAPSHOT/ath79/generic/openwrt-ath79-generic-adtran_bsap1800-v2-squashfs-rootfs.bin.html Sep 16 05:55:32 It's a diffoscope view, showing the file differences Sep 16 05:59:41 lynxis: I guess you know the problem (and solution) Sep 16 07:29:23 that hash is $(LINUX_DIR)/.vermagic Sep 16 07:30:17 include/kernel-defaults.mk: grep '=[ym]' $(LINUX_DIR)/.config.set | LC_ALL=C sort | mkhash md5 > $(LINUX_DIR)/.vermagic Sep 16 07:30:51 so probably you've different kernel configs during the two consecutive builds? Sep 16 07:37:51 Hey guys - I'm holding my hands on a Easybox 904 LTE. From briefly skipping over 300 billion forum posts it sounds as if additional work is needed. Is anyone willing to lead the way and have me follow and test with my 904? Sep 16 07:38:46 aparcar[m]: and you're probably comparing release build Vs snapshot build `src/​gz·​openwrt_luci·​http:​/​/​downloads.​openwrt.​org/​snapshots/​packages/​mips_24kc/​luci` Sep 16 08:01:12 ynezz: good advise I'll look into it! Sep 16 08:02:19 ynezz: I wonder why it doesn't copy the whole feeds file Sep 16 08:40:46 reiffert: if you follow the forked repo, it will mostly work (WLAN is... difficult, easy to break, not reliable) - but it's very hard to get it into a mergeable state given the technical pecularities of that particular hardware Sep 16 09:07:32 is there any u2f support for UI ? Sep 16 10:01:16 What should happen if I want to add the device-specific configuration for PC Engines APU4 on OpenWRT updatream? Is that even possible? Sep 16 10:01:51 Even if it's a standard x86 board, it requires some specific kernel options to be configured, as well as additional modules Sep 16 10:11:08 skrzyp: generic x86 hw Sep 16 10:12:58 skrzyp: what specific kernel options are you talking about that are not already enabled or available as module ? Sep 16 10:15:58 Would be great to have profile for APU boards, but think its not possible since guy who sends basic pathes for apu 5 years ago tried to convince devs.... Sep 16 10:16:25 *to upstream Sep 16 10:16:59 stintel EDAC? Sep 16 10:17:17 CRYPTO_AES_NI_INTEL Sep 16 10:17:29 AES_NI_INTEL is there Sep 16 10:17:44 target/linux/x86/64/config-4.19:CONFIG_CRYPTO_AES_NI_INTEL=y Sep 16 10:17:59 I enabled that in 2017 Sep 16 10:18:05 Its not APU specific, but LXC ? :) Sep 16 10:20:08 EDAC could be nice, feel free to send a patch that enables it for x86/64. I would be inclined to ACK it Sep 16 10:20:30 but maybe check rasdaemon kernel requirements and enable all those in one go Sep 16 10:21:57 looks like infradead.org is having some troubles Sep 16 10:22:36 https://pagure.io/rasdaemon Sep 16 10:23:01 and while at it, submit rasdaemon as a new package to the packages feed ;) Sep 16 10:25:28 muhaha: maybe not a greatest example, but out of my head the support for /dev/mem by default would be nice. APU has an ability to have its Coreboot flashed directly from running systems, and they provide updates quite often, really improving performance and stability Sep 16 10:26:08 muhaha: but I'll probide some more comprehensive options (not modules) when I get a moment to read my .clnfig Sep 16 10:26:11 config* Sep 16 10:27:51 skrzyp: KERNEL_DEVMEM Sep 16 10:28:05 stintel: yes, I know Sep 16 10:28:13 but it's disabled by default in x86 builds :) Sep 16 10:28:51 and probably not so usable for any x86 board beyond APU Sep 16 10:29:13 however, when I think about this now… many people who run OpenWRT on x86 might already have a coreboot there as well Sep 16 10:29:16 I already gave up support for APU, I am using generic x86 image.. I have not time for it.. Sep 16 10:29:23 the problem with x86 is that there are so many different possibilities, adding profiles for one device would pave the way for everybody wanting to add a profile for their specific device Sep 16 10:29:34 right Sep 16 10:29:41 this is going to be a major maintenance burden, I believe for this reason we rejected it in the past Sep 16 10:30:18 but I think it's rasonable as APU is not a PC-AT compatible device, just a board using x86 chip Sep 16 10:30:55 Nextime I will end up with Omnia, I am BFU and I want to have updated system rather that customized build, which is obsolete, beacuse of I dont want to compile new version.... Sep 16 10:31:34 Its a same that pcengines is not supporting/contributing to wrt Sep 16 10:32:03 pcengines is just a single guy doing all that work :) Sep 16 10:32:53 and there's another guy from Polish company 3mdeb being outsourced to work on APU firmware Sep 16 10:33:50 I did not know that, thats superb ! :) one man show... Sep 16 10:34:02 still almost perfect boards for routers Sep 16 10:34:20 they might contribute to OpenWRT IMO, but from industry point of view the OWRT project isn't so stable now after all these OWRT→LEDE→OWRT transformations nad dramas Sep 16 10:34:24 I'm considering an upgrade :) Sep 16 10:35:22 Is there any alternative to APU? :) Sep 16 10:35:33 Which is supported Sep 16 10:35:34 there were some ryzen-based embedded boards with 10Gbe Sep 16 10:35:41 and I read somewhere ("[citatio needed]") about not-so-great attitude of upstream devs to customized images, while PC Engines would probably want to build them on their own and put on their page with all the fancy branding and so on Sep 16 10:36:09 Exactly, branding like turris omnia... Sep 16 10:37:06 ryzen based = a lot of modules disabled in upstream kernel Sep 16 10:37:47 Omnia didn't only put their logo on it, which would be fine IMO in relation like "OpenWRT-APU, powered by OpenWRT Project". They did some serious stuff on every layer, even the LuCI is replaced by some custom Web UI Sep 16 10:38:23 Well.. AFAIK contributing to base openwrt should be always desired (sideways relating that coredevs need to ack that not every things are always perfect patches), then "irrelevant" customising should be OEM own thing, they can do as much as they like, on own repo / branch etc... those 2 things when done right will never conflict Sep 16 10:38:25 you guys from wrt, you should make some flagship (supported) devices... Freenas comes to my mind Sep 16 10:38:52 They offers 3rdparty hw branded and ready to use Sep 16 10:38:56 stintel: but is it only for development purposes and sold "as-is", or rather comes with available cases, addons and support? For me, PCEngines is so unique just because you can order almost complete set of components from them, including things like wireless cards and usb-serial adaptors Sep 16 10:39:53 looks like that sapphire board with 2x10Gbe is not on their website anymore :( Sep 16 10:40:11 muhaha: but they let someone else make it from customized off-the-shelf board. Now as you brought that topic up, I think such "partnership" with PCE might be not so bad approarch Sep 16 10:42:19 for anyone which doesn't know the topic closer, I think visiting the website itself is enough to show the "mr. pcengines" attitude. Well, he even lists the exact dimmensions of every component, provides board schematics and his Coreboot fork is open Sep 16 10:43:00 but I don't want to sound like the salesman anymore, as I'm not related in any way except being an owner of single apu4c4 Sep 16 10:48:05 Crafted image for APUs, LXC support ( containers are moderne these days ), HW tiers, HA/clustering support, API for automation ( ansible/terraform ), sticker and You are ready to hit enterprise :D Sep 16 10:51:42 I would actually be more interested in a way to easily build x86 images optimized for march=foo, something that is not too intrusive so that it can go upstream, but not used on the buildbots Sep 16 10:51:59 I've had some ideas about that but I don't remember them :( Sep 16 10:53:54 the problem if you enable it in CONFIG_EXTRA_OPTIMIZATION or CONFIG_TARGET_OPTIMIZATION, the directory name in {build,staging}_dir is generic, and if you build for different devices, you could end up with a broken image once you build for the other device because not everything gets rebuilt Sep 16 12:26:16 aparcar[m]: the question is, do you see build path as part of reproducible builds or not. right now I would like to fix other parts before looking further into build path dependencies. e.g. add the results of openwrt into the reproducible builds database Sep 16 13:48:47 pkgadd: I don't need the wifi stuff. What do you mean by hard to merge and technical pecularities .. you seem to come with sort of a history and easybox 904? Sep 16 13:49:18 good morning Sep 16 13:50:09 pkgadd: you mean that one right? https://forum.openwrt.org/t/support-for-easybox-904-lte/14478 Sep 16 14:58:30 dedeckeh: hi, just going through the pending requests on bugs.o.o, there are two bugs FS#1457 and FS#1971 related to odhcpd with unhappy users which would like to re-open the issues :) Do you've an idea what to do with those requests? Accept/Deny? Sep 16 16:25:59 ynezz:FS#1457 van be accepted and put into fixed state, fixed with one of thr latest commits. For FS#1971 I provided a way how it can be configured in line with rfc4193, this request can be denied Sep 16 16:54:09 jow: ping Sep 16 16:54:48 mangix: pong Sep 16 17:30:59 jow: https://downloads.openwrt.org/snapshots/faillogs/arc_arc700/packages/ know why libfolly and liburcu show up? Sep 16 17:31:40 These packages cannot be selected under ARC as liburcu has an explicit @!arc dependency. libfolly depends on boost-context, which is not available on arc Sep 16 17:34:54 mangix: good question. maybe no @arc symbol in the SDK? Sep 16 17:35:15 maybe it needs @TARGET_arc instead or similar Sep 16 17:39:02 in make menuconfig i definitely cannot select it Sep 16 17:39:08 dependencies as well Sep 16 17:39:33 make package/libfolly/compile or make package/liburcu/compile works however Sep 16 17:47:48 did you check the SDK? Sep 16 18:04:39 no Sep 16 19:32:44 mangix: did you get my messages about nut not building after libgd cmake changes? Sep 16 19:38:12 reiffert: how much time do you have...? the Easybox 904/ Arcadyan VGV952CJW33-E-IR is ...difficult on many layers, some that are very hard to get working at all, some that 'just' need serious cleaning up (but which is hindered by the more fundamental issues). Sep 16 19:39:52 reiffert: the biggest issue is it requiring a custom bad block table (BBT marker) implementation, which needs a new strategy (talk to the mtd/ NAND upstream maintainers) to deal with in a generic kernel (https://github.com/Quallenauge/Easybox-904-XDSL/commit/92c65667d0ad10ff95504840bf0b8bc833d67b93 works, but would break all other lantiq devcies) Sep 16 19:41:17 reiffert: then the RTL8366RB switch needs changes, those are basically mergeable - but need (a little) work to actually get merged. Sep 16 19:42:02 reiffert: getting the display to work is also quite difficult (finding a solution withouzt /dev/mem) Sep 16 19:42:23 reiffert: and wlan is a particular domain of pain Sep 16 19:44:56 reiffert: that's just a very abbreviated executive summary, nothing (aside from finding an upstream(!) solution for the BBT markers on NAND) impossible - but a huge amount of work to get merge ready Sep 16 19:55:46 reiffert: the bulk of pending tasks is 'just' busy-work, cleaning up the patches - but there are some pretty fundamental issues (BBT and WLAN the biggest ones, but getting the display to work in a generic way isn't easy either; although I'd consider that to be 'optional' for initial merging). the device needs just a huge amount of custom work compared to more common lantiq devices Sep 16 20:04:01 lynxis: could you please give me a quick advise on how the r-b.o database works? what files are stored? Sep 16 20:13:02 aparcar[m]: you should ask that question in #reproducible-builds it's all in the python scripts. Sep 16 20:14:54 lynxis: will do Sep 16 21:25:18 Hauke: are you aware of https://w1.fi/security/2019-7/ ? I'd provide a pull request, but wonder if that should target hostapd v2.8 or v2.9 at this point? Sep 16 21:29:52 pkgadd: no I am not aware of them Sep 16 21:30:13 could you do it on top of 2.7 which is used in 19.07 first Sep 16 21:30:17 first Sep 16 21:30:35 o.k. Sep 16 21:31:09 I'm currently working on master and your hostapd v2.9 update, but I'll look into 19.07 afterwards Sep 16 21:32:49 pkgadd: I am wondering if this is related: https://git.kernel.org/linus/3e493173b7841259a08c5c8e5cbe90adb349da7e Sep 16 21:33:48 it's probably at least loosely related **** ENDING LOGGING AT Tue Sep 17 03:01:14 2019