**** BEGIN LOGGING AT Wed Dec 30 02:59:57 2020 Dec 30 03:00:19 aparcar[m]: opinion on usbutils Dec 30 03:02:47 mangix: removing it? Dec 30 03:04:29 yes Dec 30 03:04:52 I have a version bump to 013, but it requires libudev-zero from the packages feed Dec 30 03:17:20 mangix: do you already have a removal patch? Dec 30 03:27:18 wishing you a better year.. https://www.youtube.com/watch?v=fn3KWM1kuAw Dec 30 03:27:29 aparcar[m]: I mean, I can prepare one. I'm asking mostly if it should be done. Dec 30 03:29:02 philipp64: ping Dec 30 03:32:40 mangix: i think it's reasonable based on my current knowledge Dec 30 03:35:20 sent Dec 30 03:37:16 aparcar[m]: also, can you look into https://patchwork.ozlabs.org/project/openwrt/patch/20201230000540.49166-1-rosenp@gmail.com/ ? Package is unmaintained currently. Dec 30 03:44:30 mangix: pong Dec 30 03:47:54 anyone recall a package that just downloads the binary from upstream and packages it for openwrt? Dec 30 04:03:56 Strykar: that sounds problematic, since paths/directories might be laid out differently, but they’re frequently compiled into the binaries… Dec 30 04:08:29 philipp64: so no hope of getting the speedtest.net binary accepted? https://www.speedtest.net/apps/cli Dec 30 04:08:44 mangix: doesn't it miss a mirror hash? Dec 30 04:13:35 mangix: also, do you want to become maintainer of that package? I'm not sure what's the process for "non core developers" and being a maintainer but I'd rather have a name there Dec 30 04:48:55 philipp64: what do you think about removing perl-device-usb? Dec 30 05:42:37 aparcar[m]: I don't want to maintain that package. I don't use it. It's also a dev package Dec 30 05:43:09 ffainelli seems to be gone now Dec 30 08:58:03 mangix: you mean [florian] Dec 30 09:27:31 Could someone please guide on https://bugs.openwrt.org/index.php?do=details&task_id=3539 - what can I do? Dec 30 10:19:40 reiffert: have you tried using the snapshot config stub to build and seeing if that fails in the same way as a snapshot binary? Dec 30 10:56:03 mangix: glibc SDK fix seems to have improved the situation Dec 30 10:56:08 mangix: https://downloads.openwrt.org/snapshots/faillogs/arc_archs/ Dec 30 10:56:29 only a handful of broken packages remaining (compared to before, that is) Dec 30 11:09:49 mangix: ffainelli is still in IRC as [florian] Dec 30 11:10:09 jow: thanks for fixing the SDK for glibc, it looks good Dec 30 12:20:31 russell--: I have not done that as I'm convinced it would lead into the same results. same config = same results Dec 30 12:42:16 reiffert: in theory, there is no difference between theory and practice Dec 30 13:30:24 any clues as to why I'm getting this error https://pastebin.com/fprJz5ub ? Dec 30 13:34:47 jow: hrrm it seems the libc variant makes a lot of difference to getaddrinfo() priorities/intelligence, which may be nobbling busybox ntpd seemingly Dec 30 13:35:15 enyc: yes, for some reason glibc decided to turn its stub resolver into a kitchensink Dec 30 13:35:49 ldir: my first hunch would be a dangling symlink Dec 30 13:36:17 jow: I think suitably tested patch to busybox is a sensible pragmatic approach, but without being openwrt-dev-centric [as somebody learning my way back into compsci and so-on myself] I don't know how best to get it attended to, I'd like to test variants/builds which is something I am well placed to do. Dec 30 13:36:45 Borromini: aha! spotted your comment above -- I then found https://github.com/libuv/libuv/issues/2225 .... Dec 30 13:37:35 also... having fixed ntp and so-on, my lantiq isn't crashing again yet.... will see if it does! Dec 30 13:38:01 If it does, do I want serial-console logging and as much syslog over network logging as I can , to help-out attempting to see the cause? Dec 30 13:56:36 jow: appears to be caused by https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=f17c30098356778f212f73b8ea0c2e238907b580 Dec 30 13:59:33 which looks sensible & correct. So maybe there's something really odd in my config. Dec 30 14:00:59 ldir: not sure the change is correct Dec 30 14:01:58 I bow to your knowledge :-) Dec 30 14:02:01 ldir: `:=` assignments are expended when defined while `=` ones are when used Dec 30 14:04:28 ldir: but anyhow, maybe it is correct after all. I wonder why the chmod fails in your case, since the packaging should happen under fakeroot Dec 30 14:04:38 but maybe that broke again on OS X Dec 30 14:05:04 chmod can't change a file that doesn't exist Dec 30 14:05:35 the root cause is not permitted Dec 30 14:05:42 in line 5 Dec 30 14:06:59 I think the no such file or directory error is due to the fact that we add /etc/syslog.conf as conffile but do not package it, that should be nonfatal tough Dec 30 14:08:23 ldir: I'd say fakeroot is broken Dec 30 14:08:41 otherwise chown root:root would be allowed Dec 30 14:08:51 did you recently upgrade OS X ? Dec 30 14:09:54 yes I've gone up to big sur, but I've done a whole load of other changes too. I was able to get builds through until the commit I pointed at. Dec 30 14:10:02 I see Dec 30 14:11:21 apprently that change un-broke the logic for setting PKG_FILE_MODES which now triggers chown/chmod of /bin/busybox Dec 30 14:14:04 note that busybox is the only package in core using PKG_FILE_MODES Dec 30 14:14:14 What can I look at to assist further? Dec 30 14:14:30 you mentioned 'fakeroot' - no idea what that is Dec 30 14:14:35 and only a handful from the feeds use it, so maybe your package selection simply contains no package performing fakeroot assisted chown/chmod Dec 30 14:15:04 essentialyl it is a preload mechanism, it preloads a library before invoking the shell / a command Dec 30 14:16:16 that library intercepts any filesystem related system calls and for some operations pretends that they worked while not doing actual changes on the underlying fs Dec 30 14:16:45 this is useful to chown/chmod files before tar'ing them while lacking the permissions to actually chown root in the underlying fs Dec 30 14:17:03 anyhow, to start debugging I'd probably edit /Volumes/CaseSense/wrt/staging_dir/host/bin/fakeroot Dec 30 14:17:09 jow: hi, I'm looking at adding persistent connections to opkg; is it acceptable to add a dependency on libuclient? Dec 30 14:17:10 drop some "set -x" near the top Dec 30 14:17:28 currently, opkg simply calls "wget" (which is uclient-fetch on openwrt) Dec 30 14:17:37 make package/busybox/{clean,compile} V=sc Dec 30 14:17:47 see what fakeroot is(n't) doing Dec 30 14:18:28 the main possible issue I see is on the host, I'm not 100% sure libuclient is usable here Dec 30 14:18:37 e.g. for the imagebuilder Dec 30 14:18:47 I'll give it a try :-) Dec 30 14:23:37 https://pastebin.com/DVvkxC6d Dec 30 14:28:20 zorun: did you think about the possibility of simply passing all urls at once to the download util? Dec 30 14:28:49 zorun: at least with curl that causes connection reuse, uclient could be likely extended Dec 30 14:30:31 ldir: /Volumes/CaseSense/wrt/staging_dir/host/lib/libfakeroot.dylib exists? Dec 30 14:32:07 it's a symlink to libfakeroot-0.dylib which exists. Dec 30 14:32:14 jow: Something completely different: any idea why CONFIG_STRIP_KERNEL_EXPORTS breaks x86(-64, at least) kernel builds? It seems to erroneously purge symbols which are required by modules, but then again it doesn't break mvebu, ramips or ath79 kernels, which is weird. Dec 30 14:32:48 rsalvaterra: up until now I didn't even know that it is broken, so... no idea Dec 30 14:33:33 maybe upstream gained some obscure feature that now requires introspection during kernel build Dec 30 14:33:50 but that pure unenducated guess, maybe you could share a log of the breakage Dec 30 14:34:19 jow: Welcome to the party, then. :P I'm also building OpenWrt for an APU2C4 for the first time. Dec 30 14:35:03 jow: No breakage during build, only at runtime. But I can cook an image to show you. Dec 30 14:35:10 jow: I thought about it, yes, but using a proper library seems cleaner Dec 30 14:35:37 during runtime? so it fails to load modules? Dec 30 14:35:49 or grub failing to boot the kernel? Dec 30 14:36:55 but thanks for the suggestion, it might be easier to extend uclient-fetch indeed Dec 30 14:37:34 jow: Modules fail to load and there's a dump of the missing symbols in dmesg. Dec 30 14:37:39 zorun: apart from that I am not sure if I want to trust libuclient Dec 30 14:38:28 jow: For example, the module I have on the APU is WireGuard. Everything works fine apart from it. Dec 30 14:38:33 jow: you mean API-wise? Dec 30 14:38:35 *the only module Dec 30 14:38:38 zorun: I know that its proxy and redirect handling is broken at least, and I wouldn't surprised by yet unkown bugs in http body parsing Dec 30 14:38:48 ah Dec 30 14:39:10 well, we do use uclient-fetch in opkg already Dec 30 14:39:16 true Dec 30 14:39:59 but you're right, it would tie opkg much more tightly to uclient Dec 30 14:40:18 maybe in the future we could use the "real" wget on target Dec 30 14:40:32 ldir: next try would be STAGING_DIR=/Volumes/CaseSense/wrt/staging_dir/target-x86_64_musl /Volumes/CaseSense/wrt/staging_dir/host/bin/fakeroot bash Dec 30 14:40:53 ldir: within that shell session, try something like touch /tmp/foo; chown root:root /tmp/foo Dec 30 14:41:08 see if that is working Dec 30 14:41:26 (/tmp/foo should appear on your system but not really belong to root, even if the chown succeeds) Dec 30 14:41:43 within the running bash session it should appear as belonging to root, though Dec 30 14:42:13 rsalvaterra: whats dmesg say? Dec 30 14:43:09 rsalvaterra: did you enable the wireguard kmod and recompile after you initially enabled the export stripping? Dec 30 14:43:37 like mklibs, the export stripping needs to know all kmods that are going to be used, maybe it failed to accout for wireguard Dec 30 14:43:46 zx2c4: It's not a WireGuard specific problem, I think basically every module is affected. Let me build an image do show you guys. :) Dec 30 14:43:46 maybe its broken for out-of-tree kmods in general Dec 30 14:44:14 nvm, wireguard is not out of tree anymore I guess Dec 30 14:44:25 I don't think it's just OOT modules, that's the problem. Dec 30 14:44:49 jow: WireGuard is still OOT on Linux 5.4. Dec 30 14:45:16 my guess would be that something changed with a major kernel bump Dec 30 14:45:30 and the exports stripping now fails to assemble the required symbol list Dec 30 14:45:38 try to drill down into that area Dec 30 14:46:52 see also 2ef0acc5fcda557fa5aaad35d27cb8cf75be96d2 Dec 30 14:47:06 maybe the same happened again Dec 30 14:47:56 Alright, I'll try to dig deeper, thanks for the hints. Dec 30 14:48:28 didn't upstream recently change stuff around GPL symbol exporting etc? Dec 30 14:49:12 anyhow, I'd focus on `$(TARGET_CROSS)nm -n $(LINUX_DIR)/vmlinux.o | grep ' [rR] __ksymtab' | sed -e 's,........ [rR] __ksymtab_,,' > $(KERNEL_BUILD_DIR)/kernel_symtab.txt` Dec 30 14:49:20 see if that yields proper results Dec 30 14:49:43 (also *sigh* at grep | sed) Dec 30 14:49:50 jow: I think this is an old issue (by "old" I mean at least one year old). I remember trying to compile OpenWrt 19.07 and having similar issues on the APU. Dec 30 14:59:48 jow: as you've probably guessed by the delay, fakeroot doesn't work. I even installed the homebrew version and that has the same problem. Hmmmm. Dec 30 15:03:05 ahh, I have an idea.... Dec 30 15:10:29 jow: I'd replace that grep | sed with a single awk, most likely… :P Dec 30 16:33:22 rmilecki: I have a Buffalo WSR-2533DHP2 (mt7622) which uses NAND flash and a TRX image header, U-Boot expects a TRX header. I would like to put the rootfs and the overlay FS into UBI, how to do this best? Dec 30 16:33:48 I think the Buffalo device using brcm53xx is doing this Dec 30 16:33:55 rmilecki: depends on what Buffalo wants in the TRX Dec 30 16:34:23 rmilecki: standard Broadcom boards expect kernel in the TRX partition Dec 30 16:34:31 rmilecki: so you can't have kernel in the UBI Dec 30 16:34:34 rmilecki: it is loading the kernel with "append-ubi | trx-nand | < some other headers>" Dec 30 16:34:59 that's why we have: Dec 30 16:35:02 1. TRX part #0: kernel Dec 30 16:35:04 2. TRX part #1: UBI Dec 30 16:35:13 yes I would like to have this Dec 30 16:35:24 so kernel on raw flash and rootfs + overlay in ubi Dec 30 16:35:32 so just build UBI image with whatver you want (normally squashfs + ubifs) Dec 30 16:35:42 and then use (o)trx to build final TRX binary Dec 30 16:35:56 trx -f kernel.bin -f rootfs.ubi Dec 30 16:36:33 https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/bcm53xx/image/Makefile;h=00141118a166654c01b0984896d14ab3bf9183ea;hb=HEAD#l68 Dec 30 16:37:16 I am using this and it looks good, but the kernel does not find the rootfs: https://pastebin.com/uT1MFSz4 Dec 30 16:37:43 it still expects there a squashfs, but it find the ubi magic Dec 30 16:38:04 mtdsplit: no squashfs found in "rootfs", but: 0x23494255 Dec 30 16:38:13 0x23494255 == UBI magic Dec 30 16:39:34 Hauke: what is "trx-fw" parser? Dec 30 16:39:49 parser should create "ubi" names MTD partition Dec 30 16:39:55 so OpenWrt's kernel can auto mount it Dec 30 16:40:44 trx-fw: target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_trx.c Dec 30 16:40:45 you may try using existing parser Dec 30 16:40:48 see arch/arm/boot/dts/bcm47094-phicomm-k3.dts Dec 30 16:41:12 oh, we have such a thing? Dec 30 16:41:14 ok will try brcm,trx Dec 30 16:41:18 I think i left it for some old targets Dec 30 16:41:24 try upsream mtd parser Dec 30 16:43:10 rmilecki: thanks, I haven't noticed this is already upstream **** ENDING LOGGING AT Wed Dec 30 16:54:07 2020 **** BEGIN LOGGING AT Wed Dec 30 16:56:20 2020 Dec 30 16:58:10 rmilecki: thanks, one step further, now it complains about: "ubi0 error: validate_ec_hdr: bad VID header offset 2048, expected 512" is this related to 500-UBI-Detect-EOF-mark-and-erase-all-remaining-blocks.patch ? Dec 30 16:58:49 yes, it may be some previous UBI data that wasn't ereased Dec 30 16:58:59 I think OPenWrt also supports some deadc0de mark Dec 30 16:59:07 ok Dec 30 16:59:11 I added 500-UBI-Detect-EOF-mark-and-erase-all-remaining-blocks.patch cause I didn't know about generic solution Dec 30 16:59:43 494-mtd-ubi-add-EOF-marker-support.patch Dec 30 16:59:45 I will try that patch now Dec 30 16:59:57 it's EOF actually (not deadc0de) Dec 30 17:08:13 hmm, the issue with calling wget to bulk-download all packages is that they will all pile up in /tmp/ Dec 30 17:08:22 that might take too much memory Dec 30 17:08:39 while currently only one package at a time will be stored in /tmp/ Dec 30 17:09:01 also, opkg is architectured around processing one package at a time Dec 30 17:13:22 LOL! Dec 30 17:13:31 jow: I think I found the bug. Dec 30 17:13:50 Somebody forget 64 bit kernel addresses are, well… 64 bits wide. Dec 30 17:14:16 *forgot Dec 30 17:16:58 Dang, this is a *long lived* bug. 2014, right? Dec 30 17:17:46 damn, libcurl is no longer in core repo Dec 30 17:27:15 Let's see how rusty my awk-fu is… Dec 30 17:28:48 … but first, my daily 8,5 km walk. Be back later. **** ENDING LOGGING AT Wed Dec 30 17:45:48 2020 **** BEGIN LOGGING AT Wed Dec 30 17:48:53 2020 Dec 30 18:33:25 mangix: I’m okay with deprecated perl-device-usb. Is it not used by anyone/any other packages? Dec 30 18:54:36 rmilecki: now the flash is working, had to add the fixtrx in addition to prevent the u-boot from restoring the abckup Dec 30 18:54:40 *backup Dec 30 18:54:46 thanks for your help Dec 30 19:00:06 zorun: so we go the lib path rather than the batch path? Dec 30 19:05:26 is it possible to make prereq-build dependend on specific config options? As in, rerun checks if a speciic option is enabled Dec 30 20:05:32 jow: Patch sent. :) Dec 30 20:22:39 Hauke: np, you're welcome Dec 30 22:00:36 jow: oh lovely. just umdns is broken in base apparently. I also happen to have patches months old that fiz this... Dec 30 23:02:54 aparcar[m]: please look into https://patchwork.ozlabs.org/project/openwrt/patch/20201015061027.7614-1-rosenp@gmail.com/ Dec 31 00:17:03 Hey. Just wanted to say you are all awesome! You save privcy and with code. I got an fritzbox 7530 and im using it when you have added support for adsl and dsl.. Then i will try openwrt! Thanks! https://forum.openwrt.org/t/support-of-fritzbox-7530/25485/39 Please keep it up! Almost finished =) Just DSL and stuff left.. Please try if you can.. Dec 31 00:17:03 Thanks for all your great work. Dec 31 00:18:20 Save us with privacy.. The fritz has backdoors i read online.. So openwrt is clean and i want it.. in the future. I bought this just for openwrt, but missed to read the dsl bit.. unsupported Dec 31 00:19:09 Guess i'll ceck back in the future.. Open wrt looks awesome though! I will wait and see.. and use a backdoored router in the meanwhile i guess. ;) Dec 31 00:19:23 check back Dec 31 02:24:22 j **** ENDING LOGGING AT Thu Dec 31 02:59:57 2020