**** BEGIN LOGGING AT Fri Jan 10 02:59:58 2020 Jan 10 03:16:34 build #68 of oxnas/ox820 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/oxnas%2Fox820/builds/68 blamelist: Matthias Schiffer Jan 10 03:33:06 build #183 of ramips/mt7621 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt7621/builds/183 Jan 10 04:09:32 build #66 of pistachio/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/pistachio%2Fgeneric/builds/66 Jan 10 04:35:26 build #65 of mediatek/mt7623 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/mediatek%2Fmt7623/builds/65 Jan 10 05:23:16 Hey y'all do you guys know how to correctly set up 802.11r on mwlwifi? is it stable because last time I've tried it the network was extremely slow and barely usable, when both AP's were set back to being individual with same ssid things work fine Jan 10 08:22:51 Could someone please update https://downloads.openwrt.org/ for the new releases 19.07.0 and 18.06.6 Jan 10 08:23:04 wigyori: please update the topic of the IRC channels Jan 10 08:23:33 Hauke: already did the download server juggling Jan 10 08:24:16 and congratulations on 19.07.0 - great work! Jan 10 08:25:18 Hauke: our frontpage still listed lede 17.07 as old stable, I took the liberty and removed that Jan 10 08:25:27 jow: thanks Jan 10 08:25:35 I will just do the 18.06.6 stuff now Jan 10 08:25:49 I'll also decomission the old lede 17.07 builder now Jan 10 08:25:55 ok Jan 10 08:26:26 ynezz: can you send out the security advisories please Jan 10 08:26:44 seamless upgrade from 18.06.5? Jan 10 08:27:00 anyone migrated from 18.06.5 -> 19.07.0 seamlessly? Jan 10 08:27:05 me Jan 10 08:27:08 anything that i should watch out? Jan 10 08:27:18 mt7621a device Jan 10 08:27:31 The "Download a firmware image for your device" is not working for 19.07.0 and 18.06.6 Jan 10 08:27:36 I do not know how to fix it Jan 10 08:28:25 jow: can you also update the "Old Stable Release" link on https://downloads.openwrt.org/ please Jan 10 08:28:31 Hauke: ping @tmomas in the Forum. But iirc the guys are already working on it Jan 10 08:28:39 ok thanks Jan 10 08:29:03 downloads.openwrt.org should already be updated Jan 10 08:29:28 yes partly the "Old Stable Release" section is still pointing to 18.06.5 Jan 10 08:29:58 .6 is already out? missed that Jan 10 08:30:16 yes I tagged that together with 19.07.0 Jan 10 08:32:33 will take care of it after 18.06.5 is synced to the archive server Jan 10 08:37:14 some of the 18.06.6 builds failed, I just retriggered them Jan 10 08:37:21 but these are all unimportant targets Jan 10 08:50:38 Hauke: uhttpd/ubus/libubox/procd/ucert has fixes in master and 19.07 Jan 10 08:51:07 Hauke: but 18.06 has probably only uhttpd fix if I'm not mistaken Jan 10 08:52:51 oh yeap Jan 10 08:52:57 that was a seamless upgrade Jan 10 08:53:10 seems like you gusy readied the wifi thing migration ;) Jan 10 08:53:12 thanks Jan 10 08:56:38 Hauke: download page updated Jan 10 08:59:16 thinking of cancelling the hetzner machine doing the 17.01 builds Jan 10 08:59:24 and replace it with a newer ryzen box Jan 10 08:59:35 +1 :) Jan 10 09:00:03 i7-6700 / 64G RAM => Ryzen 5 3600 / 64G RAM Jan 10 09:00:11 for two euro more Jan 10 09:01:02 +1 Jan 10 09:01:06 the latter has only 2x 512G NVME though, but that should be more than enough for the modern docker builders Jan 10 09:01:56 okay, I'll do that later today Jan 10 09:25:26 is 18.06.6 mostly just for the openssl bump? Jan 10 09:25:48 the cve in e2fs on quotas seems pretty esoteric, and I can't see anything else? Jan 10 09:26:57 nvm, wasn't seeing hauke's mail earlier Jan 10 09:41:05 Hi congrats to all who worked on the 19.07 Jan 10 09:41:37 Hauke thanks i put it up on twitter now. Jan 10 09:58:11 karlp: I'd say it's mostly to keep them in sync, to get it done while everything is in place anyways Jan 10 10:16:03 karlp: having both in sync certainly makes keeping track of pending security issues easier, as any bigger issue that needs quick attention tends to affect all branches Jan 10 10:19:36 congrats for the 19.07.0 release to everybody! Jan 10 10:25:53 jow: i noticed rt3883 dir-645 build was disabled for 19.07 (https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=2607c02ed599b6118ba26e2f35e7c828c21d7275), however the device definitely has enough space to save the overlay given i'm running an imagebuilder-built 19.07.0 on it Jan 10 10:30:29 build #61 of octeon/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/octeon%2Fgeneric/builds/61 Jan 10 11:25:11 Hauke: yay, thank you for the release \o/ Jan 10 11:26:22 karlp: there are release notes here: https://openwrt.org/releases/18.06/notes-18.06.6 Jan 10 11:41:38 yeah, I'd just missed hauke's mail with it all links, thanks. Jan 10 12:04:18 build #61 of at91/sama5d3 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/at91%2Fsama5d3/builds/61 Jan 10 12:11:48 zorun: people complain about "full manual reinstall". This wording is very unclear. Jan 10 12:12:17 PaulFertser: yes, I saw that, I'm updating it Jan 10 12:12:53 zorun: thank you! It would be nice to see something directly applicable, like sysupgrade command options or specific tickboxes in LuCI. Jan 10 12:13:22 sysupgrade is not supported in all cases Jan 10 12:14:52 Something actionable would be nice to have. Not everyone is intimately familiar with the boot sequence of their devices and how OpenWrt fits in there. Jan 10 12:15:13 the fun this is, we neither :) Jan 10 12:18:49 a) flash factory image b) buy better router and continue with a) Jan 10 12:26:34 ah Jan 10 12:27:10 how is it supposed to work? try to sysupgrade -n, and if it fails, install with the bootloader? Jan 10 12:27:59 which means serial console access Jan 10 12:28:19 or TFTP recovery in good cases Jan 10 12:34:38 zorun: for switching from ar71xx to ath79 it's likely both -n and -F are needed. Jan 10 12:34:57 On my devices that's enough. Jan 10 12:36:01 zorun: it's also would be nice to mention what part of old configs are usually not applicable so that people with complex arrangements do not need to do it from scratch. Jan 10 12:36:58 zorun: so far the list is: "option path" in wireless config; all LEDs; probably some wired ethernet interfaces changed names too. Jan 10 13:46:15 PaulFertser: I have just created https://openwrt.org/docs/guide-user/installation/ar71xx.to.ath79 , feel free to fill relevant information there :) Jan 10 13:47:32 zorun: "Most ar71xx devices" we wished, heh Jan 10 13:48:12 zorun: can you at least add some luci screenshots? I do not have luci anywhere so can't do it easily. Jan 10 13:49:12 PaulFertser: sorry, I can't do it easily either, but imho such screenshots would be very nice in more generic pages Jan 10 13:49:21 such as https://openwrt.org/docs/guide-quick-start/sysupgrade.luci or https://openwrt.org/docs/guide-user/installation/generic.sysupgradehttps://openwrt.org/docs/guide-user/installation/generic.sysupgrade Jan 10 13:52:08 Maybe we should add a column in https://openwrt.org/docs/techref/targets/ar71xx-ath79 where we mark devices with incompatible network setup Jan 10 13:52:30 i.e. eth0/eth1 swap, one-eth-in-switch to two-eth-in-switch Jan 10 13:52:32 etc. Jan 10 13:53:00 as we do not have a migration script for those, "sysupgrade -n" would be mandatory for those Jan 10 13:53:02 The question is who would do that... Even I having just ported my own device can't tell for sure. Jan 10 13:53:56 if someone adds the column, I would put data for the devices I know about Jan 10 13:54:11 I'm just afraid to destroy that table Jan 10 13:54:35 I think this table is auto-generated? Jan 10 13:55:09 So stuff like the "Unsupported functions" are parsed from the commit message? Jan 10 13:55:17 hmm, unlikely Jan 10 13:55:24 let's ask thomas Jan 10 13:55:26 So, if it's been fixed in a later commit that wouldn't be updated? Jan 10 13:56:28 Clicked on Edit: It's auto-generated, but I do not understand the data-sources Jan 10 13:56:30 My proposal: recommend to _always_ make a config backup prior to any sysupgrading; in this specific case always use -n first and manually inspect the difference in network, wireless and system configs; check generic failsafe is working as expected; if deemed reasonable, amend the backup in accordance to the finding and try restoring configs from it. Jan 10 13:57:33 PaulFertser: good idea, can you add that procedure to the page? Jan 10 13:57:45 Maybe let me rephrase it: Certain devices, like those with swapped ethX, will definitely need "sysupgrade -n". Maybe we can just provide a manual list somewhere containing only those devices: Device where we know that sysupgrade without -n will break them Jan 10 13:57:51 zorun: I can, but I'd like more feedback first :) Jan 10 13:58:17 break -> "break" Jan 10 13:58:23 well, making a backup is definitly needed :) Jan 10 14:04:17 Probably the ath79 table is not fully auto-generated, my device is not there. Jan 10 14:04:37 adrianschmutzler: http://lists.infradead.org/pipermail/openwrt-devel/2020-January/021153.html Jan 10 14:04:53 PaulFertser: well, it depends on the data source ;) could be a tag on the device page Jan 10 14:25:33 build #233 of armvirt/32 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F32/builds/233 Jan 10 14:25:39 zorun: https://openwrt.org/docs/guide-user/installation/ar71xx.to.ath79#sysupgrade OK? Jan 10 14:28:35 PaulFertser: I feel like people are led into using -F too easily here. I'd prefer something like -F should not be required, and one should think twice before using it. It would even be good if people reported such cases, as we could set/fix the SUPPORTED_DEVICES then. Jan 10 14:30:53 PaulFertser: I would add a new section before this one with "do backups + test that failsafe works", because it's better to do that before trying to sysupgrade Jan 10 14:30:55 adrianschmutzler: I'm fine with you editing the text as you see fit. Jan 10 14:31:17 zorun: IMHO, trying generic failsafe before sysupgrading is useless Jan 10 14:31:17 okay, I'll try Jan 10 14:31:25 otherwise it looks good Jan 10 14:31:26 does it? Jan 10 14:31:49 you mean it could work differently on ar71xx and ath79? Jan 10 14:32:06 adrianschmutzler: please do not get me wrong, I just really do not have much experience flashing ar71xx to ath79, so I'm afraid to give advices too specific. Jan 10 14:32:33 zorun: of course. It might be completely broken on either. And after you flash ath79 it doesn't matter anyhow if it worked before or not :) Jan 10 14:34:46 zorun: my idea with testing generic failsafe is that: 1. It's always good to know whether it works on your board; 2. In case restoring amended configs from backup goes wrong, you know there's an easy way to tweak them. Jan 10 14:36:31 PaulFertser: ah, I see, I thought it was recover from a failed sysupgrade Jan 10 14:37:09 zorun: lol no, if it failed hard you have to resort to bootloader-specific means and that's it. And if it fails "light" you just have the old firmware running as before. Jan 10 14:39:12 I've updated the "-F" text. I will just add a section add the end for listing devices that can't be flashed without "-n" for sure, there it shouldn't interfere with anything else Jan 10 14:41:30 I can't refrain from mentioning that I do not like the word "bricking" applied to devices with functional bootloader (that one can interact with anyhow) and undamaged calibration data. Jan 10 14:42:56 well, if you flash an image for a 8 MB device over a 4MB device, it will be "bricked", won't it? Jan 10 14:43:08 And that's the kind of stuff you can do with "-F" Jan 10 14:43:16 build #232 of mediatek/mt7622 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7622/builds/232 Jan 10 14:43:37 I'm just not sure whether that's possible with the sysupgrade images or whether you would require a factory for that Jan 10 14:44:20 if you just flash tl-wr1043nd v3 over tl-wr1043nd v2 nothing exceptional will happen Jan 10 14:45:28 adrianschmutzler: hm, no, the "art" partition is read-only so the kernel won't allow one to damage it, so it won't be bricked (in my terminology, since both bootloader and "art" would be intact). Jan 10 14:47:12 because sysupgrade takes care of the read-only (assuming that it is set correctly)? Jan 10 14:48:17 "takes care of" -> "cares about" Jan 10 14:48:30 Technically speaking, on that target sysupgrades calls "mtd" utility, and that uses kernel interfaces to do the actual erasure and writing and so the kernel guards against changing the read-only partitions. Jan 10 14:48:53 okay, I'll rephrase it Jan 10 14:51:53 I have to admit some people consider any device that requires attaching a serial console to UART to be worthless. So it might be considered kind of bricking for those who are allergic to serial. Jan 10 14:57:41 I've just changed it to be more generic now. Jan 10 14:58:10 I'm not triggered anymore, thank you :) Jan 10 15:02:27 I wonder if that page should mention that there're no specific plans to port all the devices and so if nobody is working to port a specific board, one should either do it him/herself or get ready to see no support for it in the next release. Jan 10 15:02:46 ah, yes, if this is the case then it should be written there... Jan 10 15:03:20 I am not sure but I can't see how this can be not the case given the OpenWrt development model. Jan 10 15:03:32 that would be helpful indeed Jan 10 15:03:51 just replace "should" by "is encouraged to" Jan 10 15:04:02 or "is invited to" Jan 10 15:04:44 BTW: I count 113 SUPPORTED_DEVICES in ath79 compared to 197 TARGET_DEVICES Jan 10 15:04:52 I like SHOULD from RFC2119 ;) Jan 10 15:05:40 so, taking into account the devices only in ath79, that would mean that between 60 and 80 % of the devices have SUPPORTED_DEVICES set (though we do not know whether the string is correct) Jan 10 15:06:03 (and thus would work without -F) Jan 10 15:07:44 (both in master, though) Jan 10 15:09:36 85/148 in openwrt-19.07, that should be about the same. Jan 10 15:23:18 adrianschmutzler: just grepping through the target is enough to obtain these numbers? Jan 10 15:24:17 yes. Jan 10 15:24:42 nice Jan 10 15:24:55 that's why I can't say which are added without support in ar71xx and which have wrong string in supported devices Jan 10 15:25:11 'grep -rn "SUPPORTED_DEVICES" target/linux/ath79/image/ | wc -l' Jan 10 15:25:18 same for TARGET_DEVICES Jan 10 15:25:38 by doing the same thing with ar71xx we can say something more accuratethan "Most ar71xx devices should be supported" Jan 10 15:25:55 although some images are disabled (DEFAULT := n) Jan 10 15:26:41 well, I assume one could acquire relatively accurate number with 15-30 minutes of work Jan 10 15:26:42 what do you mean by wrong string? Jan 10 15:27:05 If SUPPORTED_DEVICES is set to a value which is not the correct boardname Jan 10 15:27:28 e.g. TL-WDR3600 has board_name tl-wdr4300 in ar71xx Jan 10 15:28:10 so SUPPORTED_DEVICES for WDR3600 needs to be "tl-wdr4300". If someone put "wdr3600" there, it would have been counted, but sysupgrade without -F would not work Jan 10 15:28:31 Those cases I cannot filter by grepping or even scripting Jan 10 15:28:36 ah, ok Jan 10 15:29:16 and that's BTW why I prefer feedback compared to people just using -F, as it's easy to correct this if you know about it Jan 10 15:29:36 but hard to find in the first place Jan 10 15:40:05 aiui, SUPPORRTED_DEVICES was only added by people who did the porting work, so shoujld be _very_ reliable. Jan 10 15:41:25 well, I have changed several already ... Jan 10 15:43:04 well then :) Jan 10 15:43:12 The WDR3600 was an actual example (though not fixed by me) ;-) Jan 10 15:45:55 at least in generic.mk, the wdr3600/3700/3800 seems to be only one that changed after the fact in any way that matters Jan 10 15:51:37 do dts files follow a specific format in OpenWrt vers the GPL I got from the manufacture? Jan 10 15:51:58 karlp: might be, I'm mostly dealing with tplink/ubnt Jan 10 15:55:47 Slimey: https://openwrt.org/docs/guide-developer/defining-firmware-partitions Jan 10 15:56:11 https://openwrt.org/submitting-patches#dts_checklist Jan 10 16:27:38 im trying to modify an existing target from red15w_rev1 to a new device Jan 10 16:33:32 Slimey: nothing particular, but sometimes a vendor kernel might hve put in vendor hacks or workarounds while upstream figured out the "perfect" binding for various solutions Jan 10 16:34:23 luckly the red15w_rev1 intramfs inage works just cant see mtd or wifi Jan 10 16:35:05 if someone has time, can they show me 'dmesg | grep iram' after booting up ath10k-ct on their wave-2 platform? Trying to see if the default config will have enough IRAM for a commit I'm about to make. Jan 10 16:35:41 Are there any specific plans for y2038 support in a future openwrt release ? We have recently completed the kernel support, with the last patches making it into v5.6, but easily backported into v5.4. musl 1.2 will have the corresponding user space changes, and as soon as you upgrade to that version I expect things to start requiring user space bugfixes Jan 10 16:42:54 arnd: AFAIK theres ongoing 5.4 effort at https://git.openwrt.org/?p=openwrt/staging/xback.git;a=summary Jan 10 16:44:06 yes, i'll continue working on 5.4 somewehere next week. Jan 10 16:44:10 and for y2038 fixes we've some time :) Jan 10 16:48:45 ynezz: I think there isn't a lot of time left: random vendors pick old openwrt releases to base their products on, then these get sold for many years and then users never update them. Adding this all up, you easily get to 15 years between a software release and the last hardware based in it dying Jan 10 16:49:39 You can choose to ignore it and only care about the latest release but someone is going to suffer in the end Jan 10 16:50:16 I still maintain 12.06 because of armv4t :) Jan 10 16:51:04 anyway, I think, that it shouldn't be an issue to include those fixes in 5.4 from day one if there's some branch with 5.4 backports Jan 10 16:53:35 Ok, cool. https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=y2038-endgame is my branch with the missing patches Jan 10 16:54:06 I'll keep updating that as patches get merged and regression fixes get applied on top Jan 10 16:54:44 ynezz: the musl conversation is going to be much more interesting than the kernel update, so that should be well planned Jan 10 16:57:25 arnd: its not just about musl, there's glibc/uclibc as well Jan 10 17:00:02 it's going to be fun Jan 10 17:00:07 ynezz: only musl has so far done the conversion to 64-bit time_t, so using the others means you still have the y2038 problem Jan 10 17:00:40 I expect glibc to allow choosing time_t in the release next summer Jan 10 17:01:08 For uclibc I suppose there are no plans at all yet Jan 10 17:02:28 so it's not that trivial as it seemed at first look Jan 10 17:02:37 musl-1.2 using time64 unconditionally means it's easier to get right, but also that you hit all bus as soon as you upgrade Jan 10 17:03:13 glib sounds like, what is it, disaster of choice or something? can't decide, so offers both, ends up confusing everybody Jan 10 17:06:51 Maybe musl-1.2 needs to be fourth option in openwrt for a while, alongside musl-1.1, uclibc and glibc Jan 10 17:08:58 karlp: glibc needs to support upgrading across releaaes and they don't want to change the default behavior in an incompatible way Jan 10 17:11:39 I would have preferred it to be a compile time option for building glibc itself, but they instead made it an option you have to pass to the compiler for each file that gets compiled against glibc Jan 10 17:12:05 I don't see a problem with making breaking shift to musl 1.2 Jan 10 17:12:28 incompatible libc runtime changes pretty much were the norm back in the uclibc days Jan 10 17:13:02 as for glibc and uclibc... people who use these for openwrt are pretty much on their own anyway Jan 10 17:17:49 jow: the problem with musl-1.2 is not that it's incompatible (it actually still supports running old binaries, just not building them), but that going to time64 introduces regressions in application that make assumptions about sizeof(time_t) Jan 10 17:19:19 arnd: the only way to spot these is forcing the transition Jan 10 17:19:33 back when we switched from uclibc to musl we also just switched Jan 10 17:19:48 Ok, fair enough Jan 10 17:20:02 it was a bumpy ride for a week or two but after the first few weeks the had fixed the majority of things Jan 10 17:20:11 the longtail is probably going to take a while to iron out Jan 10 17:20:33 but I expect the most important packages to settle within a few weeks (if there's even issues to begin with) Jan 10 17:21:15 I'm no toolchain/gcc expert but I wonder if it is feasible to introduce some kind of compiler warning when some sizeof(time_t) expression is encountered Jan 10 17:21:35 that would make it easier to spot and review potential issues Jan 10 17:22:08 but that idea is probably nonesense as `sizeof(int)` does not trigger warnings either Jan 10 17:22:35 so static code analysis is probably the way to go Jan 10 17:27:56 jow: the problem is not the expression itself, but things like python C library wrappers describing the equivalent of timespec in another language when it cannot see the libc header Jan 10 17:29:07 another common problem is assuming that kernel interfaces such as struct input_event are based on timeval, when they are actually fixed-size regardless of the libc implementation Jan 10 17:29:40 There is unfortunately no good way to check for these problems in general, they are all different. Jan 10 17:30:03 One thing I hope to get toolchain support for is programs doing Jan 10 17:31:10 sturct timeval tv; int now; gettimeofday(&tv); now = tv.tv_sec; Jan 10 17:31:50 which converts a time_t to a narrower type. This code won't break with the update to 64-bit time_t, but it will break in y2038, so it's harder to find through testing Jan 10 17:42:42 i've been trying to debug a problem i'm seeing on ar71xx/ubnt-bullet-m over the last month. i have a small batman-adv mesh network, and they are silently (the one i have a console on) rebooting somewhat randomly but at intervals ranging from 12 hours to a few days. is there something i can do to make the reboot less silent? Jan 10 18:01:32 so if my MTD layout is this Jan 10 18:01:32 Creating 15 MTD partitions on "spi32766.0": Jan 10 18:01:32 0x000000000000-0x000000040000 : "Bootloader" Jan 10 18:01:32 0x000000040000-0x000000080000 : "Bootloader environment" Jan 10 18:01:38 do i make the dts look like this? Jan 10 18:01:39 partition@0 { Jan 10 18:01:39 reg = <0x0 0x40000>; Jan 10 18:01:39 label = "u-boot"; Jan 10 18:01:39 read-only; Jan 10 18:01:39 }; Jan 10 18:01:39 partition@100000 { Jan 10 18:01:40 reg = <0x40000 0x80000>; Jan 10 18:01:40 label = "u-boot-env"; Jan 10 18:01:43 and so on Jan 10 18:05:32 Slimey: why @100000 for the env? It's usually marked r/o too. Jan 10 18:06:04 Slimey: the second argument in the reg should be the size, so 0x80000 is incorrect. Jan 10 18:07:17 i dunno where some of these values come from Jan 10 18:09:07 Slimey: I'm talking about the DTS you're writing. Jan 10 18:09:36 so am i Jan 10 18:11:26 But the values you write are coming from you by definition. Jan 10 18:12:38 is openwrt-devel@lists.openwrt.org still working, btw? I haven't received anything in quite some time (probably missed a memo) Jan 10 18:13:01 last email http://lists.infradead.org/pipermail/openwrt-devel/2020-January/021156.html Jan 10 18:14:16 Slimey: Jan 10 18:14:22 im getting them from Creating 15 MTD partitions on "spi32766.0": Jan 10 18:14:23 partition@0 { reg = <0x0 0x40000>; label = "u-boot"; read-only; }; partition@40000 { reg = <0x40000 0x40000>; label = "u-boot-env"; Jan 10 18:15:25 ynezz: Last I got was 2019-04-27 so I guess the list server decided to spare you my contributions ;) Jan 10 18:16:42 Slimey: https://www.kernel.org/doc/Documentation/devicetree/bindings/mtd/partition.txt Jan 10 18:18:15 okay Jan 10 18:28:13 karlp: 18.06.6 also contains the uhttpd fix Jan 10 18:28:25 but not the ubus/libubox/procd/ucert fixes Jan 10 18:29:09 jow: thanks for updating all the missing websites Jan 10 18:52:37 Hauke: I didn't spotted any issue so far, so I'm going to push my staging tree with yours (and mine) PIE/ASLR changes once the test build finishes https://gitlab.com/ynezz/openwrt/pipelines/108486335 if you're fine with that Jan 10 19:11:59 ynezz: ping Jan 10 19:16:37 does this look right? im not sure how to do the kernel and rootfs parts.. Jan 10 19:16:39 https://paste.ubuntu.com/p/DgpwVMgw23/ Jan 10 19:17:09 Borromini: pong Jan 10 19:19:29 ynezz: hi. i saw a hostapd patch in your staging branch yesterday, but it's gone now... is there something the matter with it? Jan 10 19:20:59 oh, it was just a quick rebase on the latest hostapd for FS#2679 (and probably similar) Jan 10 19:22:39 it would need much more rebasing and testing, especially the mesh patches Jan 10 19:30:55 ok :) Jan 10 19:30:56 ty Jan 10 20:22:18 Hi can some one who knows about wifi drivers pleas take a look at this: https://github.com/openwrt/openwrt/pull/2397 Jan 10 20:22:42 I think it would meen that I could use the 3rd radio in my wrt3200acm Jan 10 20:24:32 I am not sure that it would mien OpenWrt breaking any FCC rules. Jan 10 20:32:06 it does apparently, but FCC rules don't apply outside the US Jan 10 20:55:39 greearb_: iram http://paste.debian.net/1125520/ nbg6817/ ipq8065/ qca9984 (wifi has been switched off most of the router's uptime so far though) Jan 10 21:02:43 pkgadd, thanks, almost 23k of IRAM available, should be plenty as I only needed to consume around 8k Jan 10 21:31:45 ynezz: looks good Jan 10 21:32:00 on which target did you do the size mesurments? Jan 10 21:32:14 x86/64 Jan 10 21:32:26 should probably add that detail as well Jan 10 21:33:05 the size increase is probably bigger on MIPS Jan 10 21:33:19 or I did it wrong :) Jan 10 21:33:31 ynezz: should we remove the mesh patches from hostapd? Jan 10 21:33:56 Hauke: hm, why? Jan 10 21:34:09 I just didn't wanted to bother with them for that testing, thats all about it Jan 10 21:34:12 one of them introduces a memory leak Jan 10 21:34:20 but probably not so big Jan 10 21:34:27 and I am not sure if it work at all Jan 10 21:37:26 some memleak(s) were fixed upstream Jan 10 21:37:56 I don't know who uses it, but IIRC daniel added some patches on top of it, so perhaps he's using it Jan 10 21:38:54 some of them went into upstream with hostapd 2.8, but not everything Jan 10 21:39:15 the main author of hostapd requested some changes Jan 10 21:46:43 bummer Jan 10 21:47:53 that patchset is huge and PITA to rebase **** ENDING LOGGING AT Sat Jan 11 03:00:52 2020