**** BEGIN LOGGING AT Mon Sep 23 02:59:57 2019 Sep 23 04:11:24 Hello openwrt-devel, could anyone commit https://patchwork.ozlabs.org/patch/1157844/ ? it's a really simple cherry-pick for 19.07 Sep 23 05:43:29 champtar: done Sep 23 05:49:20 ynezz: thanks! Sep 23 08:26:39 ynezz: do you know how to not store build path in kernel modules? https://rebuild.aparcar.org/SNAPSHOT/x86/64/packages/kmod-wireguard_4.19.74+0.0.20190702-1_x86_64.ipk.html Sep 23 08:49:09 no from top of my head, I would need to look into that Sep 23 08:53:51 ynezz: I can do that as well, I'm just not familiar with .ko files at all... Sep 23 09:06:23 this is probably because of ASSERT_RTNL macro Sep 23 09:07:05 used in wireguard, which is using __FILE__ macro https://elixir.bootlin.com/linux/v4.19.75/source/include/linux/rtnetlink.h#L104 Sep 23 09:11:49 take a look at package/libs/openssl/patches/120-strip-cflags-from-binary.patch Sep 23 09:12:02 namely the -fmacro-prefix-map=$(1)=$(2) gcc option Sep 23 09:15:08 oh, it's already documented https://reproducible-builds.org/docs/build-path/ Sep 23 09:15:38 hm, this is gcc8+ option Sep 23 09:18:17 I think, that workaround is to build in the same directory structure both builds Sep 23 09:19:13 (it was probably also mentioned as one of the current RB drawbacks by h01ger during the Hamburg meeting) Sep 23 09:21:46 what about TARGET_CFLAGS += -D'ASSERT_RTNL()=do{}while(0)' ? Sep 23 09:22:52 asserts are good, I would just remove the __FILE__ part (or just directory/path from that file macro) Sep 23 09:26:09 okay, TARGET_CFLAGS += -U__FILE__ then, I guess Sep 23 09:28:45 nice solution :) Sep 23 09:32:51 well, it might work for wireguard as the assert is used only in one place for now Sep 23 09:33:19 but by removing the file name completely you wont know where the assert has happened, you would just get line number Sep 23 09:50:48 ynezz: it will produce an oops trace, so it should be possible to infer the affected function Sep 23 09:51:36 there's also various clever CPP hacks to have something like a __FILENAME__ macro without path, e.g. https://stackoverflow.com/a/41367919 Sep 23 09:59:31 right in kernel it produces the stack trace Sep 23 10:57:06 aparcar[m]: BTW I'm trying to dogfood GitLab, trying to use it instead of GitHub, so reading the GitLab docs (occasionally), and it makes me wonder if the move to gitlab.com with openwrtorg was a good step as if I understand it correctly this is GitLab EE (Enterprise Edition) instance and the features of GitLab CE (Community Edition) are different, I mean, if we use GitLab EE now for the evaluation, Sep 23 10:57:12 we might use features which would be missing in the CE Sep 23 11:43:06 why is 1806 getting brcmfmac backports? Sep 23 11:45:10 hrm, I guess it's still the last release Sep 23 11:53:57 ynezz: https://about.gitlab.com/2018/06/05/gitlab-ultimate-and-gold-free-for-education-and-open-source/ Sep 23 11:55:45 we would be at the mercy of gitlab though, and if they one day decided to end the program, we would have an issue Sep 23 11:57:41 At many sense I personally likegitlab better, but indeed nothing is without an drawback and/or risk of some sort :) Sep 23 12:03:20 somehow i compiled tiny image and it came out the same as generic in package contents Sep 23 12:03:42 *in list of packages Sep 23 12:03:55 like it has luci and everything Sep 23 12:04:42 i used http://downloads.openwrt.org/releases/18.06.4/targets/ar71xx/tiny/config.seed , then make defconfig Sep 23 12:12:01 the tiny images have luci Sep 23 12:12:22 they disable kernel features, have differnet squashfs block size, disable usb support etc. Sep 23 12:14:16 I've just run a "make package/blah/{clean,compile} V=s" with logs turned on in menuconfig, and the logs/package/feeds/pacakges/blah has clean.txt and compile.txt, but they're not even close to containing the full logs. is this something that changed recently? Sep 23 12:14:26 build #336 of x86/generic is complete: Failure [failed kmods] Build details are at http://release-builds.lede-project.org/17.01/images/builders/x86%2Fgeneric/builds/336 blamelist: Eneas U de Queiroz , Hauke Mehrtens Sep 23 12:15:15 then i have strange issue where i can't get opkg to work with 8MiB of ram free after opkg update Sep 23 12:20:54 ooh .. there a fix for floppy drives in the new kernel .. making the bumps currently to fix this asap ;-) Sep 23 12:21:34 xback: what was broken ? Sep 23 12:22:00 swiftgeek: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.19.75&id=c3817ffb10369fac0979f0c4367159c412ccc3d8 Sep 23 12:22:47 sadly can't comprehend that :D Sep 23 12:23:02 how long was it broken? Sep 23 12:23:30 Fixes: version 1.0 Sep 23 12:23:33 2017-06-27 Sep 23 12:23:35 hah Sep 23 12:23:37 nice. Sep 23 12:25:13 Tue Jun 27 15:47:56 2017 Sep 23 12:25:46 I'll probably only push it tomorrow after testing ... so sorry to all people using floppy drivers in their routers .. :-( Sep 23 12:27:24 http://dpaste.com/30BXKJH Sep 23 12:35:14 found some workaround on chinese forum to comment out feeds that are not needed in /etc/opkg/distfeeds.conf Sep 23 12:36:25 but it does seem sketchy that 9M is not enough for such simple operation Sep 23 12:44:42 it sounds like a job for zcat and awk :D Sep 23 13:04:35 swiftgeek: try to run time -v opkg-update. In my WRT3200ACM: with all feeds: Maximum resident set size (kbytes): 37040; without packages: 19328 Sep 23 13:08:04 > Maximum resident set size (kbytes): 30992 Sep 23 13:08:27 (with all feeds) Sep 23 13:09:30 without opkg update > Maximum resident set size (kbytes): 3584 Sep 23 13:10:36 It's using a lot of memory, but I think it's been like this for a while. Packages feed just grew a lot lately. Sep 23 13:10:48 well Sep 23 13:11:25 with just base/core > Maximum resident set size (kbytes): 7584 Sep 23 13:13:43 if I use zcat then memory used is the same regardless of feed :D Sep 23 13:14:58 and with file format like that i think it's a bug if memory usage grows with feed size Sep 23 13:15:32 but didn't know time -v could do that, thanks for the tip cotequeiroz :D Sep 23 13:45:30 has anyone already solved/automated this package feeds requirement? Maintainer: me / @\ (find it by checking history of the package Makefile) Sep 23 15:44:02 ynezz: further status() fixes are required http://dpaste.com//3BEZC8T Sep 23 15:48:18 and EXTRA_HELP from e.g. package/network/config/ltq-vdsl-app/files/dsl_control is overwritten Sep 23 15:53:02 ^^^ more evidence that the final user/package provided init scripts should be able to provide their own status() overriding the system default, not the other way around... Sep 23 15:53:25 and i guess "status" from EXTRA_HELP could be dropped? there're a few hits (main repo, packages, routing) Sep 23 16:00:57 I've found a pretty nasty/breaking bug in the QMI LTE modem support. It affects 18.06 and 19.07. Sep 23 16:00:57 In the sequence of the scripts it brings up the device before it figures out the date mode, 802.3 vs. raw-ip, and since the device is already up and since the default is 802.3 it fails for any raw-ip modem. Sep 23 16:01:11 *data Sep 23 16:04:39 I'd like to fix it but am pretty new to owrt; I think it is an issue with /lib/netifd/proto/qmi.sh but maybe it's an issue with what calls it. Sep 23 16:04:40 What's the best way to get up to speed on this? Mailing list to the last few guys that changed it? Sep 23 16:10:47 so did it ever work? 1806 has been around a while now Sep 23 16:46:11 Quazil: yes, mailing list would be a good start Sep 23 16:48:00 Hey guys I just attempted to flash a D-Link DWR 921 C3 with the latest openwrt release factory.bin however the device was dead after that. Sep 23 16:48:38 recovering the stock image using the JBOOT bootloader was working good. any ideas of what could have gone wrong? Sep 23 17:01:33 I'll take that back. 192.168.1.1 is working just fine - just no switch LED blinking. Sep 23 17:03:39 a process "mount_root done" is eating up 100% CPU.. hm. Sep 23 17:06:13 jow: can you look at https://github.com/openwrt/packages/pull/10046 ? No idea why rpath needs to be set to HOSTPKG Sep 23 17:26:27 reiffert: mount_root done is waiting for the kernel to format the jjfs2 overlayfs iirc, could take a while if the flash is large or very slow Sep 23 17:31:56 jow: you are correct - thank you! It is working now! Sep 23 17:39:59 build #349 of x86/64 is complete: Failure [failed kmods] Build details are at http://release-builds.lede-project.org/17.01/images/builders/x86%2F64/builds/349 blamelist: Eneas U de Queiroz , Hauke Mehrtens Sep 23 17:41:28 mangix: You asked jow, but I _think_ I can answer that. It happens because you're [building/linking to] a hostpkg shared library. If you don't set rpath, it will look for the libraries in the host standard dirs (/usr/lib). Sep 23 17:45:03 manginx: One way to fix this is to only build hostpkg static libs, as it was done before the switch to cmake. Sep 23 17:45:13 *mangix: Sep 23 17:50:37 cotequeiroz: sure but this problem came up in the conversion to CMake Sep 23 17:52:01 I had to turn on -DBUILD_SHARED_LIBS=ON to get it to work properly Sep 23 17:52:20 or do you mean libboost was statically linked? Sep 23 17:54:46 I have to try this to be sure, but protobuf/hostpkg is built with `-DBUILD_SHARED_LIBS=ON`. So anything linking to it will use the shared library and require the rpath. Sep 23 17:56:12 right. without -DBUILD_SHARED_LIBS=ON, I was getting libboost_* not found Sep 23 17:58:54 speaking of boost, it's broken on a few targets. time for patch i guess. Sep 23 18:44:25 mangix: have you tried adding `link=static` to the .`/b2` line under `Host/Compile` in boost. It will only build & install static libs for hostpkg. Sep 23 19:14:52 I have not. Sep 23 20:14:52 mangix: I was out for a while, and was disconnected. I'm looking at the protobuf{,-c} host build errors now. At least here, protobuf is copying stuff to lib64, but pkg-config looks for them in lib. Sep 23 20:16:31 I can force the use of 'lib' with `CMAKE_HOST_OPTIONS += -DCMAKE_INSTALL_LIBDIR=lib` in `protobuf/Makefile`. Sep 23 20:17:55 Then protobuf-c linking fails because of library order--`-lprotobuf` has to come after `-lprotoc`. This can be circumvented by adding `HOST_CONFIGURE_VARS += LIBS=-lprotobuf` to protobuf-c/Makefile Sep 23 20:22:49 These may not be the ideal solutions. We may want to create a lib64 -> lib symlink in hostpkg, just as I see in host, and frankly, the rpath solution starts to not look so bad if we are to encounter more linking trouble. Sep 23 20:39:15 * mangix looks Sep 23 20:41:29 It's installing to hostpkg/lib here Sep 23 20:41:58 nevertheless, I should probably add that line if it's causing trouble elsewhere. Sep 23 20:51:18 ...just found out the protobuf commit is useless Sep 23 20:51:28 ola compiles just fine without it Sep 23 22:26:24 ugh that was annoying. apparently commit 1 was actually needed for a different reason. **** ENDING LOGGING AT Tue Sep 24 02:59:59 2019