**** BEGIN LOGGING AT Sat Mar 27 02:59:58 2021 Mar 27 04:44:35 guidosarducci: just about the buildbot stuff, i'll handle it Mar 27 04:46:25 aparcar[m]: ok, thanks, my head was starting to spin there for a while! Mar 27 05:13:13 VFIO Non-Privileged userspace driver framework (VFIO) [N/m/y/?] (NEW) Mar 27 05:14:19 ^^^ just started being prompted for this bulding malta/be. Anyone else? I don't recall seeing kernel config changes for this recently... Mar 27 05:22:09 Anyone know what spawns these type of messages? Packages for xxxxxxx found, but incompatible with the architectures configured Mar 27 05:36:02 Grommish: IIRC that might be related to the large build-system churn we've gone through recently Mar 27 05:48:29 guidosarducci: It isn't a repo package, but I rebase yesterday Mar 27 05:48:34 and it worked then.. hmm Mar 27 05:48:53 I dunn what triggers that message though, so I was asking Mar 27 05:49:14 I'm going to clear out building_dir, staging_dir tmp/ and .ccache and see what happens Mar 27 05:57:01 guidosarducci: Was there something intro'd to the packages that needs to be changed/added to them with the overhaul? Mar 27 05:59:34 Grommish: honestly can't remember, must have suppressed the painful memories :) Mar 27 06:00:59 guidosarducci: I can imagine :) Well. I was do for complete removal of the build structure anyway Mar 27 07:36:07 guidosarducci: Well.. That didn't work.. What in the world Mar 27 08:21:49 guidosarducci: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/drivers/vfio/Kconfig?id=v5.10.26&id2=v5.10.25 - I missed that one. Mar 27 08:23:53 ldir: good catch, kind of a big dependency reversal... Mar 27 08:38:45 I'm not quite sure how to deal with it. The 'obvious' solution is # CONFIG_VFIO is not set in malta/config-5.10 but Mar 27 08:39:20 I suspect the issue is spread wider than that. Mar 27 08:45:25 ah, and it didn't bite me on X86 'cos it's set there. Mar 27 08:52:03 guidosarducci: I have a commit stood by - can you confirm that adding # CONFIG_VFIO is not set to the config does actually solve the problem for you? Mar 27 08:53:52 ldir: just finishing a build first, link to your commit? Mar 27 08:55:44 https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=aee57b67c9a42aa03e987a45c5a8dd7167ebf18e Mar 27 08:58:34 ldir: not sure this is arch-specific. Maybe the generic config is better? Needs some checking of targets though... want me to try for just malta anyway? Mar 27 08:59:02 yes please Mar 27 09:05:42 ldir: building without prompt on malta/be... Mar 27 09:05:49 yay Mar 27 09:06:31 ldir: maybe wait a bit to check buildbot logs, see if the prompt appears for other archs (even though BBs just "press return") Mar 27 09:07:11 https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=3426fd0d964bf931e29b47a0f57641909e7f3615 Mar 27 09:08:32 ldir: way ahead of me :) Mar 27 09:08:54 guidosarducci: your iproute2 pr for 21.02, is there anything specific one needs to do to test it? Mar 27 09:09:08 most of my stuff is on DSA and that relies on iproute2 by default no? Mar 27 09:11:48 Borromini: I changed it to draft for now after so reported an NLS build problem. What's special about DSA and iproute2? Haven't used it yet myself... Mar 27 09:12:55 guidosarducci: nothing special, i understood DSA relies on standard linux networking tools (so iproute) to set up interfaces, instead of swconfig Mar 27 09:16:21 Borromini: I guess the "bridge" utility? Again, not sure. If you're not using NLS you can use that 21.02 PR fine. Won't see much difference unless you use BPF, plus all the small utilities no longed have a useless libelf dependency. And using tc-tiny will save you some space too. Mar 27 09:19:45 yeah, i noticed the split, thanks. i'm not using bpf Mar 27 09:19:58 nor nls. nls seems a bit weird on embedded, but hey. Mar 27 11:44:34 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_ar71xx.html has been updated. (99.1% images and 98.3% packages reproducible in our current test framework.) Mar 27 14:12:31 i modified dnsmasq's files/etc/dnsmasq.init, dnsmasq has PKG_RELEASE:=$(AUTORELEASE) in the Makefile so I did not bump it, now make {clean,compile} will never update /etc/init.d/dnsmasq in root-ath79, why is that Mar 27 14:17:19 also make package/network/services/dnsmasq/install fails Mar 27 14:17:24 "no install" Mar 27 14:17:30 but it's in the Makefile Mar 27 15:08:24 also looks like multiple instance dnsmasq does not work, unless I disable ubus additional instances Mar 27 15:54:28 rr123: IIRC 'install' is a legacy thing, it's all handled by compile Mar 27 15:56:17 also the autorelease is a new thing to me. I think it's bases the release on the number of commits since the last bump or some such Mar 27 16:06:41 if you want the 'base image' as found in root-ath79 to be updated I think 'make package/install' will do what you're after Mar 27 16:24:07 Good Afternoon All. Can someone please advise if drivers contained in an OEM image source code are any good? Unfortunately I have no expertise. There is a lot in it and I think it looks promising. Thank you. Mar 27 16:28:30 Radu-Mamy: usually vendors drivers are awful, unmaintainable mess. Mar 27 16:29:59 Thanks. But if the drivers are working in original image and they are provided in source code, they must be good I guess Mar 27 16:31:13 I just think we might be sitting on some gold dust and it's not explored Mar 27 16:32:30 Radu-Mamy: if people are watching eurovision it must be good Mar 27 16:34:05 I guess so. But without even looking we won't know for sure. If its acceptable it can be corrected if it's source code... Mar 27 16:34:22 Of course the devs are looking at those. Mar 27 16:42:49 Who is the the best person to contact? Mar 27 16:57:06 Radu-Mamy: about what exactly? Mar 27 16:57:44 About validating if drivers are any good? Mar 27 16:58:02 Assume they're not, what next? Mar 27 16:58:45 I don't know, could they be fixed? Mar 27 16:59:42 Radu-Mamy: what device do you have in mind anyway? Stop talking riddles please. Mar 27 17:00:07 Vodafone Wi-Fi Hub Vox30 https://openwrt.org/toh/vodafone/vodafone_power_station Mar 27 17:00:25 The OEM source code is added to the page Mar 27 17:01:05 It's god ADSL, wireless, pretty much everything Mar 27 17:01:21 Just don't know what to do with it Mar 27 17:02:09 OEM is custom built of Openwrt Mar 27 17:03:28 Radu-Mamy: it would be a massive effort to get that supported, and probably only partially anyway. Mar 27 17:04:07 Happy to help, but don't know how Mar 27 17:04:26 Then it's likely you can't really help :( Mar 27 17:04:44 If Vodafone provided everything, could the drivers be recompiled? Mar 27 17:05:03 Drivers inside might be useful for other boards Mar 27 17:06:36 It contains a lot more by the looks of it Mar 27 17:08:32 since its broadcom i doubt that sourcecode drivers are available - or stuff for pots Mar 27 17:08:49 Please download it Mar 27 17:09:06 You might be surprised what you'll find Mar 27 17:09:45 I think it's very legit Mar 27 17:21:04 hm... i like software archaeology "GPL code has been tested in Fedora 12 (32bits)" Mar 27 17:22:48 Yes, seen that too Mar 27 17:23:21 What about the drivers? Mar 27 17:24:24 The kernel that ships with the box is 4.1 so not that old Mar 27 17:25:27 The box is fast and very capable Mar 27 17:25:57 I own one and I ordered another one for testing Mar 27 17:26:37 Being Arm could be used for a lot of things if openwrt gets ported to it Mar 27 17:28:28 i didnt do a diff of the kernel - some folders only contain the header files and not the C files with the implementation Mar 27 17:29:32 So I guess that is a bad thing... Mar 27 17:29:51 😕 Mar 27 17:30:26 ldir: thanks for the compile-include-install thing, for autorelease a new dnsmasq ipkg is built based on commit numbers, i.e. dnsmasq-full_2.84-2_mips_24kc.ipk, however, neither make ../dnsmasq/{clean,compile}, nor make package/install will update root-ath79's content, though the ipkg does contain my own changes, very strange Mar 27 17:31:17 so at the moment there is no way I can get my own dnsmasq changes to the firmware image and the board other than manually copying over Mar 27 17:44:38 fn'plntyk, what are your thoughts? Anything useful / worth salvaging? Mar 27 17:48:16 is https://git.openwrt.org/?p=project/procd.git truly the upstream procd repo? Mar 27 17:48:23 There's no CI/CD whatsoever as far as I can tell Mar 27 17:48:24 :| Mar 27 17:50:54 Build [#13](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/70/builds/13) of `x86/legacy` completed successfully. Mar 27 17:56:53 Thermi: yes, it is Mar 27 17:56:57 EWWWW Mar 27 17:57:11 Radu-Mamy, i dont see how that is "custom built of openwrt" in that gpl drop Mar 27 17:57:32 jow: So I need to set up my own stuff to build it if I want to test if my changes work? Mar 27 17:57:42 Thermi: yes Mar 27 17:57:46 :(((((( Mar 27 17:58:07 in general we expect people to actually compile and run test their changes before submitting a PR to core components :) Mar 27 17:58:08 there are some vendors like cz.nic (Turris Omnia) or other that really use openwrt "forks" Mar 27 17:58:33 Well evidently Mar 27 17:58:35 you can use the SDK to recompile just the procd package if you do not want to build the entire buildroot Mar 27 17:58:43 That what it's saying on the page Mar 27 17:59:00 Yes, so I need to clone upstream make my changes, and then somehow deal with the sdk to get the source into the build process Mar 27 17:59:01 :/ Mar 27 17:59:06 Oh well. Mar 27 17:59:46 yes. you can achieve that by setting CONFIG_SRC_TREE_OVERRIDE in menuconfig Mar 27 17:59:46 Check the bootlog, will this give you any hints? Mar 27 18:00:27 ty, that might help me Mar 27 18:00:35 Is it even feasible to set up CI/CD for procd? Mar 27 18:01:06 And is there a specific reason procd upstream is just on git.openwrt.org? Mar 27 18:01:17 it is doable and ynezz already developed some tests, but you cannot rely on CI/CD to actually do the work for you Mar 27 18:01:37 eventually you do need to compile your changes yourself and see if they work Mar 27 18:02:00 Yeah, I want to avoid the "it works on my box!" Mar 27 18:02:58 must be some bug to me, dnsmasq.ipk autorelease contains the correct info, root-ath79 contains old dnsmasq content after make ..dnsmasq/clean-compile and after make package/install, opkg list_installed showed the correct dnsmasq new version however it's content is stale(as shown in root-ath79), a force-reinstall can get the new dnsmasq.ipkg correct installed, so, after I modified dnsmasq and Mar 27 18:03:04 git-commited and rebuilt it into ipkg etc, it never went to root-ath79? Mar 27 18:03:26 s/it's/its Mar 27 18:06:08 fn'plntyk, "Linux version 4.1.38 (repowrt-builder@0e3f98211bf6) (gcc version 5.3.0 (OpenWrt GCC 5.3.0 unknown) )" Mar 27 18:06:27 Maybe it's just GCC Mar 27 18:08:29 well - there is procd - but the build structure is very different from what i can see Mar 27 18:10:29 I'll be driving for a bit, feel free to msg me privately. Thanks Mar 27 19:34:14 Auto-merging target/linux/bcm4908/patches-5.4/701-net-dsa-bcm_sf2-keep-GPHY-enabled-on-the-BCM4908.patch keep getting this suddenly on 21.02 Mar 27 21:10:05 Hauke: can you please check https://pastebin.com/qBMKZvWE and https://pastebin.com/ivvaCiqZ ? there's some user reporting that fixed-links are not working with the mainline GSWIP driver and these patches are an attempt to fix this Mar 27 21:43:17 xdarklight: looks good Mar 27 21:43:28 is gswip_phylink_mac_link_up() called after gswip_port_enable() Mar 27 21:44:41 from the HW side it looks good Mar 27 21:45:05 when you post them to the mailing list someone with more knowlage about DSA should have a look at them Mar 27 21:46:13 xdarklight: I am not sure if we configure everything when the autopoling is deactivated Mar 27 21:46:23 it could be that some MAC settings are not done manually Mar 27 22:36:36 Hauke: yes, mac_link_up is called after port_enable Mar 27 22:37:44 Hauke: auto polling is currently always enabled (for any port that uses a PHY). so I am not sure which MAC settings could be an issue here? Mar 27 22:37:52 Hauke: also thanks for looking at the patches :-) Mar 28 00:41:57 Build [#7](https://buildbot.openwrt.org/openwrt-19.07/images/#builders/29/builds/7) of `oxnas/ox820` completed successfully. **** ENDING LOGGING AT Sun Mar 28 02:59:56 2021