**** BEGIN LOGGING AT Tue Oct 08 02:59:57 2019 Oct 08 04:41:37 aparcar[m]: sup Oct 08 06:43:41 albert: I never heard about it so far Oct 08 06:50:44 ynezz: thanks for the response regarding fwtool. Are you looking into that? If not I could give it a try. Also, can we move fwtool oot? Oct 08 07:26:23 Mornin' all Oct 08 07:43:42 aparcar[m]: nope, I'm not looking into that, sorry Oct 08 07:43:59 xback: morning :) Oct 08 07:44:09 dobro utro :) Oct 08 07:46:34 hm, you can't type in cyrillic yet? :p Oct 08 07:46:57 I could if I had a cyrillic keyboard Oct 08 07:47:08 oh, nice Oct 08 07:47:22 I was looking at a new roccat keyboard but they didn't respond if they have a "Bulgarian qwerty" variant Oct 08 07:47:40 and putting stickers .. I don't think so :P Oct 08 07:48:13 it would actually help since it would be easier for me to practice like that Oct 08 07:49:42 hm, what about all these cygwin changes? Oct 08 07:49:57 receiving a 1090MHz bandpass filter and antenna today, curious for the results. I barely get anything in dump1090 in Sofia while with the same equipment at my parents' place in Belgium I get over 2000 aircrafts per day Oct 08 07:50:50 I've thought, that cygwin is not supported build host/platform Oct 08 07:51:40 ordered yesterday around noon, coming from Cambridge UK and it's already out for delivery in Sofia since 20m Oct 08 07:51:53 what a time to be alive :) Oct 08 07:52:37 * ynezz *cough* brexit *cough* Oct 08 07:52:59 haha yeah, well it's not there yet so might as well make use of it ;) Oct 08 07:53:49 and it makes me wonder if it makes sense to start supporting cygwin as there seems to be WSL (never tried it myself, but a lot of people using it succesfully) Oct 08 07:54:18 I don't think it's work the effort, since there is WSL now Oct 08 07:54:23 ^ mangix Oct 08 07:56:34 and https://gitlab.com/openwrtorg/openwrt/blob/master/README#L11 says "Cygwin is unsupported because of the lack of a case sensitive file system." Oct 08 08:09:43 I'm biased and I'm also in the (dis)United Kingdom soon to be annexed from the EU so feel free to completely ignore... I'd prefer to see MacOS support less of a poor relation. WSL *is* Linux...we're already there. And stintel, don't get your hopes up, if it come from the UK it won't work. :-) Oct 08 08:10:17 * ldir goes back to lurk mode Oct 08 08:11:37 ynezz: ack Oct 08 08:13:57 ynezz: you got mail Oct 08 08:14:36 ldir: :D Oct 08 08:15:41 ldir: what's broken on macOS this week? Oct 08 08:16:06 aparcar[m]: yeah, patches welcome :) Oct 08 08:16:49 ynezz: not sure if I can pull that off... Oct 08 08:19:57 ynezz: could you help me with a little bit of elf .rodata hassle? I'm trying to figure out what tool puts in the build path but can't find anything Oct 08 08:20:37 which package? Oct 08 08:21:44 kmod-gpio Oct 08 08:22:24 it's basically in all firmware images and therefore makes them all unreproducable if buildpath != /build/foobar/ which is basically never the case except for special rebuild environments Oct 08 08:22:58 and this is with gcc8 and that remap patches? Oct 08 08:24:50 ynezz: the kernel uses the "old" fmacro thing (https://github.com/torvalds/linux/blob/master/Makefile#L892) whhich appears to be used for kmod compilation. I tried (not in depth) to patch that as a "hack" kernel patch however no change. thats why I wanted first to verify the issue is actually a gcc thing and not introduced by the linker or whatever Oct 08 08:39:38 ynezz: can you tell if all this stuff is just debugging information? https://paste2.org/EyeV3HZ0 Oct 08 08:40:01 line 45 starts the build path Oct 08 08:43:42 ynezz: It would be nice to resolve: https://pastebin.com/hYUU2mbw Oct 08 08:45:10 I don't dare do the update to Cataiina..... yet. Oct 08 08:46:53 ldir: `git grep libtirpc` doesn't return anything here Oct 08 08:47:06 its from the feeds iirc Oct 08 08:47:18 so different project :) Oct 08 08:48:30 ha, yes, ok, point taken. Oct 08 08:51:20 jow: did you create issues for the fwtool bugs or should I? Oct 08 08:51:32 ldir: probably gcc-9 related? Oct 08 09:04:39 aparcar[m]: as explained before, you can't tell from the static strings where they come from, you would need to actually dissasemble the module to find out where is that string used Oct 08 09:05:26 is that kind of stuff... really hard? I've never did so before but sounds fun Oct 08 09:06:41 it's easier http://paste.ubuntu.com/p/2MYWgD84pw/ Oct 08 09:07:16 it's simply dragged in by one of this macros Oct 08 09:08:33 -.- sweet Oct 08 09:08:46 so it's __FILE__ which should be handled by the gcc remap stuff Oct 08 09:08:50 ynezz: aren't the buildbots set to disable all debug info? Oct 08 09:09:37 FILE is already handled via -fmarco (which is already used). Seems like these are debugging variables staying in the kmod Oct 08 09:09:37 this is unrelated Oct 08 09:10:13 provide pastebin of following: `make package/gpio-button-hotplug/{clean,compile} V=sc -j1 JOBS=1` Oct 08 09:13:42 nbd: I've been testing your financial algo in mac80211 rate control in the field on dozens of devices interconnected. works really well. I notice less short interruptions on movement Oct 08 09:16:03 aparcar[m]: not yet Oct 08 09:18:10 ynezz: I applied your patch and the buildpath is gone! https://paste.ubuntu.com/p/4hzgJjpFbn/ Oct 08 09:18:25 sweet this makes a big difference Oct 08 09:20:39 I don't see any remap args in your pastebin Oct 08 09:21:05 ah it's file-prefix-map Oct 08 09:23:53 so as you can see, the kernel build is not using -ffile-prefix-map but it's internal -fmacro-prefix-map=./= and that's why it fails Oct 08 09:24:48 mips-openwrt-linux-musl-gcc ... -fmacro-prefix-map=./= Oct 08 09:31:13 aparcar[m]: http://paste.ubuntu.com/p/Cmv4cvrrD2/ Oct 08 09:36:05 xback: nice! Oct 08 09:36:14 ynezz: I don't understand the second patch? Is it more than a cleanup? The kernel doesn't use ffile-prefix-map yet, it still uses fmacro (see here https://github.com/torvalds/linux/blob/master/Makefile#L892). Oct 08 09:37:46 aparcar[m]: just a wild guess, copied it over from wireguard as this module was causing issues previously as well Oct 08 09:38:58 ynezz: and it still does, it also contains the buildpath (however it is not included in mostly all images Oct 08 09:39:37 another fun thing is seen here where openwrt feeds have different commit hash length attached, for whatever reason https://aparcar.gitlab.io/-/rebuild/-/jobs/314425271/artifacts/output/SNAPSHOT/ath79/generic/feeds.buildinfo.html Oct 08 09:40:31 ynezz: since using "#fake key" the fwtool issues is "fixed" btw https://aparcar.gitlab.io/-/rebuild/-/jobs/314425271/artifacts/output/SNAPSHOT/ath79/generic/index.html Oct 08 09:40:39 kinda cheating Oct 08 09:42:50 maybe you could try to pass that file-prefix-map via KCFLAGS to kernel? Oct 08 09:49:43 ldir: if you find some time, could you test this on macOS please https://patchwork.ozlabs.org/patch/1170499/ ? Oct 08 09:50:07 I would like to push it soon, once I build/run test it myself Oct 08 09:51:09 ynezz: where would I define KCFLAGS so it applies to all modules (and those to come) Oct 08 09:54:04 aparcar[m]: perhaps in KERNEL_MAKE_FLAGS in include/kernel.mk Oct 08 10:09:35 bingo Oct 08 10:12:08 ynezz: so it works but now we have ffile-prefix-map and fmacro-prefix-map in the opts, which is not problem as the latter just removes ./ as $(srctree) is set to "." - I'll create a PR Oct 08 10:19:56 ynezz: pulled in that patch from your staging tree, done a dirclean, updated to latest xcode from apple, set toolchain to use gcc8 (not gcc9) - busy turning macbook into red hot metal... Oct 08 10:22:15 eyes mac os software update window suspiciously - macOS Catalina 10.15 -- 8.09 GB - think I'll wait.. that really does have 'pain' written all over it. Oct 08 11:01:06 ynezz: I send a commit including the KCFLAGS, thank you very much! Oct 08 11:03:48 aparcar[m]: this v3 is quite weird, I would simply prefer to go with v2 + new patch which fixes the KCFLAGS Oct 08 11:04:28 and ldir + myself are already building with v2 Oct 08 11:05:02 ynezz: fair enough, ill send a single patch tomorrow Oct 08 11:05:44 good, so I've marked v3 as rejected Oct 08 11:07:43 ynezz: ack Oct 08 11:28:57 I just experienced a very strange error. When trying to build ubus, Make was complaining about a circular dependency and was dropping the rule. I've debugged it and eventually determined that in staginig_dir/target/pkginfo/ there was a libubus.version which created the circular dependency. Does anyone know how could this happen? And shouldn't running make package/ubus/{clean,prepare} (specfically clean) delete that file? Oct 08 13:04:39 ynezz: built on macos, for x86 & ath79. running ath79 - can't test the x86 just yet but don't anticipate any problem. Oct 08 13:05:22 \o/ Oct 08 13:05:25 ldir: that was fast, thanks, so can I add your tested-by? Oct 08 13:06:09 aparcar[m]: the abbreviated commit hash length is decided by git Oct 08 13:06:25 aparcar[m]: and the defualt min length differs with git versions Oct 08 13:06:45 aparcar[m]: its probably easiest to find the place emitting the abbreviated hash and change it to print a full hash instead Oct 08 13:07:17 or stick to safe 12 as default everywhere Oct 08 13:07:48 ldir: I've just built from scratch for ath79, imx6, mt7620 and will run-test later Oct 08 13:09:28 I've always used the latest toolchains as soon as they get committed so I was using gcc8 'ages' ago...and now using gcc9... 'cos it's there. Oct 08 13:45:26 make -j 4 Oct 08 13:55:54 make: *** No targets specified and no makefile found. Stop. Oct 08 13:57:55 yayaya Oct 08 14:02:16 * ldir goes to stackoverflow and copies some vulnerabilities Oct 08 14:02:25 lol Oct 08 16:57:10 Here's the sort of challenge that jow likes - a quick/dirty way of working out if a passed IP address is ipv4 or ipv6.. in ash Oct 08 16:57:57 thinking about it, it could be as simple/dirty as seeing if dots are in the passed string or not. Oct 08 17:43:56 ldir: no, dots may appear in an IPv6 Oct 08 17:44:06 fe80::1.2.3.4 is valid Oct 08 17:44:43 check for ":" instead (but I'm pretty sure there is already something somewhere in the openwrt codebase that already provides this functionality) Oct 08 17:48:15 ah thanks for that 'gotcha', checking for : first is best. Oct 08 17:53:58 I'm looking at some code https://pastebin.com/w3tr7ejT - it basically constantly reads each line from 'logfile -f' into a variable Oct 08 17:55:13 it filters those lines through sed, but via a 'herefile'. Oct 08 17:55:32 annnd I think I just worked out the answer to my question. Oct 08 18:49:44 ynezz: yey 100% https://rebuild.aparcar.org/SNAPSHOT/ath79/generic/ Oct 08 18:51:27 ldir: should I add a gcc10 option to the toolchain then? Oct 08 18:52:17 gcc-10 is boring, clang-10 pls Oct 08 18:52:24 jow: thanks you I'd send a PR to the buildbots.git Oct 08 18:53:22 100%, congrats :) Oct 08 18:57:37 ynezz: with a bit of cheating... Oct 08 18:58:01 ynezz: readong about clang on their website it seems so much nicer... Oct 08 18:58:06 *reading Oct 08 19:06:00 ynezz: regarding the iremap map patch, should it still use that function or should it rather always just go with --file-prefix-map? Oct 08 19:07:18 yes, it should work on gcc-7 as well Oct 08 19:08:50 bump to gcc-8 is probably going to introduce some regressions, so it should still be possible to switch back to gcc-7 for testing etc. Oct 08 19:10:37 okay than I just cherry-pick that single line and create a new commit Oct 08 19:11:10 gcc-7: error: unrecognized command line option β€˜--file-prefix-map=./=meh’; did you mean β€˜--debug-prefix-map=’? Oct 08 19:12:34 gcc7 know --fmacro-prefix-map which is applied by the kernels makefile Oct 08 19:12:45 I never touched --debug-prefix-map Oct 08 19:14:08 well, in other words, just stick to --file-prefix-map for gcc >= 8 Oct 08 19:14:30 and the previous prefix-foo for older versions Oct 08 19:15:49 file do Oct 08 19:16:24 ynezz: it's ffile, so twice an f just so you know :) Oct 08 19:20:37 aparcar[m]: BTW if I understand the openwrt/docker .gitlab-ci.yml correctly, currently the main destination for the final images is just Docker hub, right? Oct 08 19:21:30 wouldn't it make more sense to push them also to gitlab registry as it might be faster during testing on the gitlab itself? Oct 08 19:22:15 s/more sense/sense/ :) Oct 08 19:34:04 sure will add an extra push there Oct 08 19:34:26 ideally we could catch the "openwrt" instead of "openwrtorg" username :P Oct 08 19:36:57 there is no registry size limit? Oct 08 19:38:40 jesus, and again two screens of "error: recursive dependency detected!" :\ Oct 08 19:39:19 ynezz: afaik no. problem is a bit that gitlabs ci only allows contains matching the project name. so I'd have to use tags for sdk, rootfs and ib Oct 08 19:39:47 I'll look if thats possible to change. if not the name would be like reg.gitlab.com/openwrtorg/docker:sdk-master Oct 08 19:40:47 MY-R: good, not just me then Oct 08 19:41:10 :< Oct 08 19:43:27 aparcar[m]: yeah, that tagging makes me crazy Oct 08 19:43:51 so I'd be okay with it but it's no real fun, that's why I used the external docker in the first place Oct 08 19:45:33 anyway, in the build step, you're pushing the image to that registry as it could be used in the test step Oct 08 19:46:11 or that is some different registry used during CI testing? Oct 08 19:50:29 ldir: I would've used case "$val" in *:*) echo "probably ipv6";; *) echo "probably ipv4";; esac Oct 08 19:50:47 ynezz: within the test scripts it's using the gitlab reg to see if the contains works, if they work the deployment is on hub.dockre Oct 08 19:52:17 aparcar[m]: it would be nice if you could split the gcc patch into multiple patches Oct 08 19:52:17 aparcar[m]: indeed, but they'll stay on gitlab reg as well, didn't they? you would need to delete them explicitly, right? Oct 08 19:52:52 Hauke: where to draw the lines? Oct 08 19:54:09 ynezz: only x86/64 is tested to see if the docker-create scripts are working, all other targets are then blindly deployed (as blindly as they are uploaded to downloads.openwrt) Oct 08 19:55:19 aparcar[m]: I would do it based on topic Oct 08 19:55:30 like the fixes for gcc8 into a seperate patch Oct 08 19:55:42 the change of the default gcc into a seperate patch Oct 08 19:57:06 jow: that's pretty much exactly what I came up with in the end :-) Oct 08 19:57:18 Hauke: if you're talking about v3, I've already rejected that and plan to push v2 which was already build/run tested Oct 08 19:58:51 Hauke: but if you would like to take it over, you're of course more then welcome :) Oct 08 19:59:06 Hauke: well if possible I'd don't do the extra work commit splitting Oct 08 20:00:23 Hauke: https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=commit;h=8f8fb3c0b9ea91704f25eac2dabb51fdd7237385 Oct 08 20:01:01 but yeah, it's not in yet, so some tweaks are still possible Oct 08 20:02:22 looking at it again, splitting that commit, wouldn't it break bisectability? Oct 08 20:03:04 I mean, having separate commit for openssl change might produce unbuildable tree Oct 08 20:07:44 ok, so probably those remap changes should go into one separate commit Oct 08 20:08:14 version bump into another one Oct 08 20:09:40 it would be nice to have a liitle bit more description, you do not have to compete with Felix commit comments ;-) Oct 08 20:10:13 does openssl still compile with gcc7? Oct 08 20:10:30 ynezz: thanks for taking this over Oct 08 20:10:45 I think it is a good timing for such an upgrade now Oct 08 20:11:24 The openssl patch can come before the gcc8 switch. It's just filtering out options. Nothing will happen if those options are not there. Oct 08 20:13:42 aparcar[m]: don't worry about it, I'll split it into separate patches tomorrow and retest Oct 08 20:13:51 MY-R, ldir: the circular dependencies are being caused by db424ede2f079f2bf73634d30ec3c59a8a782118 icu: Deactivate uClibc Oct 08 20:14:12 that's a packages feed commit, btw. Oct 08 20:15:00 ynezz: thank oyu Oct 08 20:17:13 cotequeiroz, bad bad commit! :P Oct 08 20:19:10 The explanation for it is that, with icu now depending on !UCLIBC, anything selecting it (do it recursively) will have to also depend on !UCLIBC. You can imagine the mess. Oct 08 20:21:00 * ynezz runs in circles Oct 08 20:21:26 cotequeiroz, yes, mess: http://sprunge.us/jgWuGA Oct 08 20:22:11 I'll have that commit reverted in a bit. Oct 08 20:24:00 mangix: OK to revert? Oct 08 21:52:08 thank you cotequeiroz! Oct 08 22:19:32 cotequeiroz: of course Oct 08 22:21:01 uClibc-ng can stay broken. Oct 08 22:26:39 anyone using it except arc? Oct 08 22:28:04 nope. see my latest patch on the mailing list Oct 08 22:28:54 the original condition was made when musl support was still hit or miss. now it supports everything. Oct 08 22:29:26 hehe Oct 08 22:30:15 in other news, umdns is still broken with GCC9. AGH Oct 08 22:33:10 good, so synopsys can fix it then... Oct 09 00:27:30 ahh wonderful. RPi0W wifi broken in master Oct 09 00:40:23 bah, device path changed. aren't we supposed to create some migration mechanism if this happens? especially on wifi-only devices? Oct 09 00:42:16 it has happened a couple of times on other hardware already. yes, best to be avoided, but sometimes hard to come up with robust migration scripts Oct 09 00:46:01 and moving from swconfig to the dsa framework will be such a breaking change in the future as well (e.g. qca8k for ipq806x, same for ipq40xx and mvebu all have dsa drivers that are close to ready, with the biggest hurdle being to come up with automated migration support (which I'd argue isn't really possible for anything but the most default switch configurations)) Oct 09 01:14:36 karlp: nah. nobody will. The proper solution would be to get ARC support in musl and kick uClibc-ng to the curb. **** ENDING LOGGING AT Wed Oct 09 03:01:40 2019