**** BEGIN LOGGING AT Tue Sep 17 03:01:14 2019 Sep 17 04:21:08 xback: 4.19.73 just needs rm target/linux/generic/pending-4.19/840-media-i2c-tda1997x-select-V4L2_FWNODE.patch (merged in stable) for me on ipq806x, ath79 and lantiq, other than that it compiles fine there (run tested on ipq806x) Sep 17 05:23:54 Hauke: this one is for openwrt-19.07 https://github.com/pkgadd/openwrt/commits/hostapd-19.07-bugfix-1 only build tested on ath79, I won't actually file it as pull request until I got a chance to runtime test it (in the evening); I have successfully runtime tested 065-0001-AP-Silently-ignore-management-frame-from-unexpected-.patch on master+hostapd 2.9/ ipq806x though, including Sep 17 05:24:00 https://git.kernel.org/linus/3e493173b7841259a08c5c8e5cbe90adb349da7e (ath10k-ct) Sep 17 05:35:22 what's the thinking around read-only u-boot-env partitions? i notice in looking at dts files, that read-only is dominant, but some seem to be writable (at least, not specifically marked read-only). Sep 17 05:39:18 also there are a minority (26 vs 287) of dts that use the label uboot-env instead of u-boot-env. Sep 17 05:41:27 read-only seems safer, less likely to brick yourself, people who need to write are probably capable of turning off read-only, etc Sep 17 05:41:36 russell--: I got the impression it is a 'special case' yu want to writo to / update the u-boot from running yssetm... normally that is left well-alone and considered a recovery-environment ..? Sep 17 05:56:26 here's a list of what i found in my zeroth approximation search for writable u-boot-env partitions in dts files: http://paste.debian.net/1101176/ Sep 17 06:05:26 russell--: your assumption is correct - it's writeable in case you need to modify something for installation Sep 17 06:30:53 blocktrron: i've just been working on a no-serial method for installing on Meraki MR24 using tftp, which requires writable u-boot-env's, which is why it got my attention Sep 17 06:33:46 more details https://patchwork.ozlabs.org/patch/1097475/ Sep 17 06:33:49 ^ russell-- Sep 17 06:38:51 i wish i was more motivated, but after spending half-a-week setting up my flashing environment, i finished flashing the 16 new devices i had in an hour saving myself 4 hours of tedium, and now i don't need it anymore. :( Sep 17 06:39:30 i am motivated to understand the image creation makefile hackery more though. Sep 17 06:43:13 if anyone has favorite methods of understanding what is happening inside make, i'd love to hear them. Sep 17 06:45:43 make V=1 is just too verbose for me Sep 17 06:47:14 GNU Make Manual under pillow works for me Sep 17 07:01:41 has anyone played with remake, btw? Sep 17 07:03:13 https://elinux.org/Debugging_Makefiles#remake Sep 17 07:09:27 ynezz can you give me an advise on how to copy locally installed feeds to the created binary? Sep 17 07:23:16 I can't parse your question Sep 17 07:40:55 ynezz: I'm making some progress regarding reproducibility, like got the kernel issue fixed (thanks again), now I need to get distfeeds.conf copied the right way **** BEGIN LOGGING AT Tue Sep 17 08:07:17 2019 Sep 17 08:40:58 http://5.9.6.233/SNAPSHOT/x86/64/openwrt-x86-64-generic-rootfs.tar.gz.html#tmpaqglgpp--content---.-etc-opkg-distfeeds.conf Sep 17 08:41:01 please see this Sep 17 08:41:19 ynezz: -^ Sep 17 09:00:11 different configs? Sep 17 09:01:25 grep FEED.*=y$ .config Sep 17 10:00:16 ynezz: thanks, fixed, new build is running Sep 17 10:00:58 ynezz: btw should we continue the evaluation for now here? https://gitlab.com/openwrtorg/openwrt/issues Sep 17 10:07:02 aparcar[m]: I propose removing the "Feature Request" label, as feature requests will likely never be actually implemented, so just add noise to the issue tracker Sep 17 10:07:58 sounds wise Sep 17 10:08:25 pkgadd: Thanks. currently making the bumps :-) Sep 17 10:15:02 aparcar[m]: ynezz: if someone with a live.de/hotmail.com address ask for evaluation gitlab account, please tell them to switch the mail provider. i'm now writing my 5th mail towards hotmail. no fun at all. no delivery possible with hotmail.de/live.com/ whatever. Sep 17 10:23:14 lynxis: seems like aparcar[m] has already fixed it by moving the testing to the gitlab.com Sep 17 10:23:18 :) Sep 17 10:23:47 aparcar[m]: sure, why not, this way its more public Sep 17 10:28:37 KanjiMonster: I remember at least one such feature request implemented by jow- recently Sep 17 10:29:19 lynxis: did you go through their whitelisting department? Sep 17 10:29:29 had to whitelist our mail infra as well there Sep 17 10:37:53 lynxis: I'd count abolute paths on the same level as user name or machine name - potentially not under control from the user, so should not be contained in build artifacts (relative paths are probably fine) Sep 17 11:07:53 jow: not yet. still in their queue Sep 17 11:08:44 ynezz: good. then it's fixed for me. but it stills annoy me, that I can not even answer people who wrote me a mail Sep 17 17:10:36 Hauke: could it be that 5ghz ap scanning broke with the recent mac80211 bump? Sep 17 17:10:53 Hauke: I am now getting: # iw dev wlan1 scan Sep 17 17:10:54 command failed: Resource busy (-16) Sep 17 17:11:17 after an update to todays snapshot Sep 17 17:14:59 creating further vif interfaces fails as well Sep 17 17:43:25 jow: I'm seeing that for at least a year (following master closely) on QCA9984 and AR9380, it works if you down the AP interface first Sep 17 17:43:43 talking only about the scanning, not creating further vifs Sep 17 17:55:58 jow: I haven't tryed this, but let me check **** ENDING LOGGING AT Wed Sep 18 02:59:57 2019