**** BEGIN LOGGING AT Wed Nov 25 02:59:57 2020
Nov 25 03:00:57 <mangix> should be
Nov 25 03:01:34 <mangix> I don't think anything in base fails with full NLS.
Nov 25 04:28:20 <aparcar[m]> mangix: strange but my staging tree doesn't produce any images o.O
Nov 25 04:28:26 <aparcar[m]> https://github.com/aparcar/openwrt/actions/runs/382236332
Nov 25 04:28:35 <aparcar[m]> No files were found with the provided path: bin/targets/ath79/generic/openwrt-ath79-*. No artifacts will be uploaded.
Nov 25 04:29:29 <mangix> aparcar[m]: exfat is a kernel module, not really a package
Nov 25 04:30:12 <mangix> yeah, I see it as kmod-fs-exfat_5.4.79+5.10.1-1_x86_64.ipk
Nov 25 04:41:57 <aparcar[m]> curious what stopped the images...
Nov 25 05:24:25 <ynezz> aparcar[m]: I've noticed your previous openvpn question, FYI I've already started the "Review and cleanup of base packages" discussion, can't point you to the archive link, here is excerpt from my local archive http://sprunge.us/3sWpKc
Nov 25 05:26:58 <aparcar[m]> excellent thank you
Nov 25 05:43:28 <aparcar[m]> mangix: images were built, problem was just a config option in the ci :)
Nov 25 05:43:38 <aparcar[m]> I'll runtime your bump and push it
Nov 25 05:55:41 <mangix> ynezz: some of those have been transfered
Nov 25 05:56:23 <aparcar[m]> mangix: to test exfat, howdo I create a device via /dev/null?
Nov 25 05:57:03 <mangix> What I meant was doing something like dd if=/dev/null of=test.img
Nov 25 05:57:09 <mangix> easier to just use truncate
Nov 25 05:57:28 <mangix> erm, actually /dev/zero
Nov 25 05:57:38 <mangix> not /dev/null
Nov 25 05:57:52 <aparcar[m]> :)
Nov 25 05:57:56 * mangix loves to confuse the two
Nov 25 05:58:09 <mangix> in C++ they're identical
Nov 25 06:03:30 <aparcar[m]> mangix: so can we move out openvpn?
Nov 25 06:05:15 <mangix> i think so
Nov 25 06:05:44 <mangix> i want to say magnus had an issue with that
Nov 25 06:05:46 <mangix> need to check
Nov 25 06:07:39 <mangix> hhmm seems I remember wrong
Nov 25 07:34:29 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 98.2% packages reproducible in our current test framework.)
Nov 25 08:12:21 <aparcar[m]> nbd: do you mind?
Nov 25 08:22:22 <aparcar[m]> zorun: I updated opkg with your patches, please close your patches on patchwork (I lack that power still)
Nov 25 08:25:23 <aparcar[m]> mangix: will you create a patch for packages.git for the package you removed from openwrt.git?
Nov 25 08:31:28 <mangix> already did
Nov 25 08:32:00 <mangix> i've placed it as draft until someone merges
Nov 25 08:33:49 <aparcar[m]> Some packages in base don't have an explicit maintainer so I would have taken care of it, but in this case nbd is in charge :)
Nov 25 08:33:59 <aparcar[m]> I'll not burn my fingers on the first day...
Nov 25 08:38:59 <damex> is there a support for APQ8053 ?
Nov 25 08:39:18 <damex> looking at UniFi Cloud Key Gen2
Nov 25 08:40:23 <damex> it seems like upstream does support it but openwrt have no target
Nov 25 08:42:40 <aparcar[m]> mangix: so what additional target should I CI test?
Nov 25 09:06:53 <stintel> damex: looks like an interesting device, don't recall upstream support though. iirc it was snapdragon based?
Nov 25 09:08:02 <damex> stintel: yeah,  i think it not actually upstream as linux upstream but android one :(
Nov 25 09:08:29 <damex> https://android.googlesource.com/kernel/msm.git/+/android-7.1.0_r0.3/arch/arm/boot/dts/qcom/apq8053.dtsi here it is :(
Nov 25 09:09:53 <stintel> damex: so I guessed probably also android style bootloader and didn't bother to look further
Nov 25 09:10:17 <damex> uh, okay :(
Nov 25 09:10:39 <stintel> also looked at dream machine pro. annapurna labs cpu. no upstream support either
Nov 25 09:10:46 <stintel> like they're doing it on purpose
Nov 25 09:10:52 <damex> annapurna labs have some upstream support
Nov 25 09:11:00 <damex> i remember there were something
Nov 25 09:12:05 <damex> https://github.com/torvalds/linux/tree/master/arch/arm64/boot/dts/amazon there it is ;p
Nov 25 09:12:50 <damex> there is also some for 32bit variant ;p
Nov 25 09:12:52 <stintel> damex: I should look into details again but iirc it was a different soc
Nov 25 09:13:22 <damex> stintel: yeah,  they use different soc on their servers and on consumer devices
Nov 25 09:13:36 <damex> but platform itself is 'kinda supported' :)
Nov 25 09:15:51 <aparcar[m]> mangix: tested your exfat patch and it worked fine, mounting etc, merged
Nov 25 09:17:51 <stintel> damex: I'll force myself not to buy anything new to try play with openwrt on until I get one of the other devices I got for that working
Nov 25 09:18:05 <mangix> aparcar[m]: nothing really to test
Nov 25 09:18:50 <damex> stintel: haha,  at this point i am trying to not get any network device that have no support for openwrt. burned by ubiquiti and their broadcom switches ;(
Nov 25 09:18:54 <rsalvaterra> Good morning/evening/night! :)
Nov 25 09:19:20 <aparcar[m]> rsalvaterra: 🦈
Nov 25 09:19:44 <rsalvaterra> Shark? :P
Nov 25 09:20:09 <stintel> damex: well I have 2 WatchGuard Firebox M300. I would really like to get them working, would be nice for a HA setup, but just the DTS alone is insane
Nov 25 09:20:21 <rsalvaterra> I have an indecent proposal…
Nov 25 09:21:00 <stintel> damex: decompiling oem DTB -> 1797 lines
Nov 25 09:21:13 <aparcar[m]> rsalvaterra: elaborate
Nov 25 09:21:30 <rsalvaterra> … how about we enable airtime policy on hostapd for the -basic variants too? It's only a 4 kiB binary difference, and it's extremely useful for multiple BSS scenarios (most people nowadays have at least a private and guest network).
Nov 25 09:21:58 <aparcar[m]> rsalvaterra: ping dangole
Nov 25 09:22:19 <damex> stintel: could be worse.  1/3 of that is what it took to bring dts for cn71xx and actual cn7130 device :)
Nov 25 09:22:43 <rsalvaterra> aparcar[m]: Yeah, I will, no worries. :)
Nov 25 09:26:37 <aparcar[m]> rsalvaterra: also shark in german is *hai* == hi
Nov 25 09:26:58 <rsalvaterra> aparcar[m]: Oh…! TIL.
Nov 25 09:27:21 <rsalvaterra> My German is basically non-existent. :P
Nov 25 09:29:26 <mangix> aparcar[m]: how about this one http://patchwork.ozlabs.org/project/openwrt/patch/20200901214554.85687-1-rosenp@gmail.com/ :)
Nov 25 09:29:54 <mangix> a user in the packages feed wanted it fixed
Nov 25 09:30:22 <rsalvaterra> mangix: I'd say "fix the package"… :/
Nov 25 09:30:34 <aparcar[m]> If I fixed the typo defenitions does it requires a SoB?
Nov 25 09:30:52 <mangix> rsalvaterra: huh?
Nov 25 09:31:36 <rsalvaterra> mangix: Sorry, misread. It's not disabling -fno-common. I'm gonna make some coffee.
Nov 25 09:32:34 <mangix> Yeah it's a direct fix
Nov 25 09:33:05 <aparcar[m]> is iftop still alive?
Nov 25 09:33:06 <mangix> I only force fcommon if it's way too annoying to fix
Nov 25 09:33:25 <mangix> ¯\_(ツ)_/¯
Nov 25 09:33:38 <rsalvaterra> What's the current recommended alternative to iftop?
Nov 25 09:34:18 <aparcar[m]> I use bmon but that's not really the same tbh
Nov 25 09:34:44 <aparcar[m]> mangix: I'd actually say to kick iftop out of openwrt.git
Nov 25 09:35:17 <rsalvaterra> Hm… bmon has lots of dependencies.
Nov 25 09:35:22 <aparcar[m]> but that's a question for jow
Nov 25 09:39:03 <mangix> aparcar[m]: how about this one? http://patchwork.ozlabs.org/project/openwrt/patch/20201029071216.383594-1-rosenp@gmail.com/
Nov 25 09:39:04 <aparcar[m]> I can't locally compile gcc10 in time
Nov 25 09:39:11 <aparcar[m]> will postpone it until tomorrow
Nov 25 09:39:30 <mangix> I got the issue when upgrading to Fedora 32
Nov 25 09:41:43 <aparcar[m]> done
Nov 25 09:43:45 <karlp> mangix: is that based on something new? I built master yesterday on fc32, been on fc32 for a while now?
Nov 25 09:44:51 <karlp> are you getting python3.9 from some backport or something?
Nov 25 09:44:51 <mangix> nope. I updated to f32 the second day it was out and hit the issue
Nov 25 09:44:57 <karlp> I've only got 3.8
Nov 25 09:45:01 <karlp> do you mean 33?
Nov 25 09:45:14 <mangix> whoops
Nov 25 09:45:17 <mangix> i do mean 33
Nov 25 09:45:22 <karlp> ok :) no problem :)
Nov 25 09:45:57 <karlp> that python 3.5+ check is funny anyway, is there really no better way than trying to run explicit minor versions?
Nov 25 09:46:18 <mangix> I think it's the most portable
Nov 25 09:46:29 <mangix> but yes it's not ideal.
Nov 25 09:47:07 <karlp> as long as all distros provide the "pythonY.N" binary,
Nov 25 09:47:37 <karlp> I naiively would have tried just running python3 -V and grep with a regexp for not 1234 or something
Nov 25 09:48:12 <karlp> I wonder how far python3 dot versions will go.
Nov 25 09:49:09 <mangix> I have a feeling a long time. The python 2-3 transition was painful
Nov 25 09:51:44 <aparcar[m]> mangix: do you have an APU board?
Nov 25 09:52:02 <mangix> I do not. Turris Omnia is the closest thing I havew
Nov 25 09:52:26 <aparcar[m]> k nevermind thanks :)
Nov 25 09:52:48 <rsalvaterra> aparcar[m]: I have one, but it's in production, at the office. Can't do much testing on it.
Nov 25 09:53:38 <aparcar[m]> rsalvaterra: https://github.com/openwrt/openwrt/pull/3135
Nov 25 09:54:28 <rsalvaterra> aparcar[m]: It's an APU2C4, not APU1, unfortunately. :)
Nov 25 09:55:25 <rsalvaterra> LEDs is actually something I could test, since it doesn't interfere with networking.
Nov 25 09:56:27 <mangix> that PR looks fine
Nov 25 09:57:49 <mangix> aparcar[m]: this one
Nov 25 09:57:54 <mangix> 's easy http://patchwork.ozlabs.org/project/openwrt/patch/20201013223518.10592-1-rosenp@gmail.com/
Nov 25 09:59:27 <Tapper> https://t.co/FBcxhTGhew - A new WebAIM survey is open for anyone that implements accessibility. This is a follow-up to previous surveys. Please take a few minutes to complete the survey to provide valuable data and insight into the web accessibility field and practices.
Nov 25 10:00:07 <aparcar[m]> mangix: btw WARNING: Makefile 'package/feeds/packages/whois/Makefile' has a build dependency on 'perl/host', which does not exist
Nov 25 10:00:37 <Tapper> That is off topic I know, but It can be helpfull for blind people. Thanks and sorry for the noise.
Nov 25 10:02:03 <aparcar[m]> Tapper: appreciate thanks
Nov 25 10:02:32 <aparcar[m]> mangix: I can't reproduce the error message, how to?
Nov 25 10:02:54 <mangix> make package/argp-standalone/compile V=s
Nov 25 10:02:57 <mangix> should be there
Nov 25 10:05:01 <aparcar[m]> nope not here...
Nov 25 10:12:17 <aparcar[m]> mangix: how do I set the buildroot to use clang?
Nov 25 10:12:42 <mangix> don't
Nov 25 10:12:47 <mangix> tools won't compile
Nov 25 10:13:02 <aparcar[m]> so why is it then supported?
Nov 25 10:13:05 <aparcar[m]> or semi supported
Nov 25 10:13:20 <karlp> or, why submit patches for compiling with clang you mean? :)
Nov 25 10:13:43 <mangix> karlp: because I have CC and CXX set to clang and clang++ locally :)
Nov 25 10:14:22 <karlp> that's your problem :)
Nov 25 10:14:22 <mangix> it just so happens that cmake.mk does not set HOSTCC and HOSTCXX for host builds
Nov 25 10:14:31 <karlp> (I don't see that clang fix submitted upstream either)
Nov 25 10:14:51 <mangix> both of those are ignored by cmake.mk basically
Nov 25 10:15:04 <mangix> there's nothing to fix upstream honestly
Nov 25 10:15:18 <karlp> doesn't sound like anything to fix here then either?
Nov 25 10:15:37 <mangix> well, there's a weird local math patch
Nov 25 10:15:38 <aparcar[m]> http://patchwork.ozlabs.org/project/openwrt/patch/20201124094917.410344-1-rosenp@gmail.com/
Nov 25 10:15:41 <mangix> no idea why it's here
Nov 25 10:15:59 <karlp> well, maybe a better commit message might be more palatable then :)
Nov 25 10:16:12 <karlp> because at the moment it's " fix clang, here's some compiler spew"
Nov 25 10:16:33 <mangix> the compiler spew is pretty clear. you can't redefine builtin functions
Nov 25 10:16:46 <mangix> *redeclare :)
Nov 25 10:17:09 <karlp> personally, I don't feel unaccompanied compiler spew is ever an appropriate commit message.
Nov 25 10:17:38 <mangix> again, I have no idea why that patch is even there. probably a fix to some old glibc version
Nov 25 10:18:28 <aparcar[m]> I agree with karlp
Nov 25 10:19:12 <mangix> note that clang is aliased to gcc on at least macos. maybe even the BSDs
Nov 25 10:19:16 <aparcar[m]> anyway I'm off, more merging tomorrow
Nov 25 10:21:01 <rsalvaterra> mangix: On macOS gcc is aliased to clang…? O_o
Nov 25 10:21:09 * rsalvaterra tests…
Nov 25 10:21:27 <rsalvaterra> Sweet baby Jesus…
Nov 25 10:22:21 <rsalvaterra> As if I didn't have enough reasons to hate macOS ($dayjob requirements)…
Nov 25 10:23:00 <mangix> LOL
Nov 25 10:23:15 <mangix> macos cannot use GCC because of licensing reasons
Nov 25 10:23:24 <rsalvaterra> Sure, I know… but aliasing?
Nov 25 10:23:39 <nitroshift> rsalvaterra, i feel you, got a macbook as a gift, gave it away 2 days later
Nov 25 10:23:42 <mangix> well, do note that clang is compatible with GCC 4
Nov 25 10:23:42 <rsalvaterra> brew install gcc, I guess…
Nov 25 10:23:58 <mangix> in a way it makes sense
Nov 25 10:26:05 <rsalvaterra> nitroshift: This is a 2012 Mac Mini, with the top i7 CPU, it's quite agile… but the OS *feels* slow, when compared to my beloved Debian Sid.
Nov 25 10:32:11 <nitroshift> mine was an i7 too, still in love with my i7 acer nitro running kali linux
Nov 25 10:36:00 <rsalvaterra> nitroshift: Yeah, but Linux is much faster, especially for these kinds of workloads (building and git workflow). :)
Nov 25 10:36:23 <nitroshift> rsalvaterra, exactly! ;)
Nov 25 10:37:20 <rsalvaterra> It was already the fastest, at the time RCU path name lookup was introduced. After that, it just blows everything out of the water.
Nov 25 10:42:12 <mangix> huh. fedora uses chrony. wonder if I can use timedated
Nov 25 10:43:00 <nitroshift> nbd, ping
Nov 25 10:43:12 <rsalvaterra> mangix: I use systemd-timesyncd… :P
Nov 25 10:47:21 <ynezz> is it already possible to compile complete OpenWrt with clang?
Nov 25 10:47:44 <mangix> nope
Nov 25 10:48:00 <ynezz> so why to bother?
Nov 25 10:48:00 <mangix> tools/m4 fails to compile
Nov 25 10:48:05 <ynezz> kernel likely as well
Nov 25 10:48:18 <mangix> it's not that
Nov 25 10:48:31 <mangix> I have CC and CXX set to clang and clang++ for other reasons
Nov 25 10:48:45 <mangix> cmake.mk does not respect HOSTCC and HOSTCXX
Nov 25 10:48:49 <ynezz> but GCC is mandatory, clang is not supported
Nov 25 10:49:00 <ynezz> look at readme at minimal requirements
Nov 25 10:49:01 <mangix> sure, but it's using it
Nov 25 10:49:23 <ynezz> those clang changes doesn't make much sense, maybe you should rather detect that clang aka gcc in prereq and error out?
Nov 25 10:49:38 <mangix> or fix cmake.mk
Nov 25 10:49:53 <mangix> what makes less sense is that math patch
Nov 25 10:50:01 <ynezz> are we going to support visual c++ if they make it gcc in wsl3? :p
Nov 25 10:50:32 <mangix> that's...not going to happen
Nov 25 10:50:47 <mangix> MSVC is a completely different beast
Nov 25 10:51:18 <ynezz> it was rather meant as a joke
Nov 25 10:51:29 <Namidairo> all I wanted from them was the ability to mount ext4 but that's only in preview builds for now
Nov 25 10:52:21 <ynezz> either we can build complete tree with that compiler and decide that we want to support it, update readme to reflect that or simply ignore the compiler
Nov 25 10:52:32 <ynezz> simple as that for me
Nov 25 10:53:07 <adrianschmutzler> Hi, what's neheb's name here on IRC?
Nov 25 10:53:25 <mangix> pretty sure it's possible. macOS uses clang symlinked to gcc and it builds there
Nov 25 10:53:27 <rsalvaterra> Well, I hope one day, in the far, far future, we'll be able to compile with clang (or any other standards-compliant compiler). That would be healthy for the project as a whole. :)
Nov 25 10:53:33 <mangix> the m4 issue is some linker problem
Nov 25 10:53:44 <mangix> adrianschmutzler: hi
Nov 25 10:53:57 <adrianschmutzler> ah, you are that ... :-)
Nov 25 10:54:27 <adrianschmutzler> just saw the libusb-compat removal patch, do you plan to synchronize removal and addition, or can I just merge it?
Nov 25 10:54:43 <mangix> Go ahead
Nov 25 10:54:59 <mangix> actually...if I merge on packages first it won't conflict
Nov 25 10:55:40 <adrianschmutzler> technically, nbd is maintainer, but I doubt he will be too interested in moving that package?
Nov 25 10:55:59 <mangix> I'm sure he's busy with more important stuff
Nov 25 10:56:08 <adrianschmutzler> that's what I meant ;-)
Nov 25 10:57:23 <mangix> anyway, merged to packages
Nov 25 10:58:25 <adrianschmutzler> thanks. I've picked it into my local tree, so it will go to master in the next two hours
Nov 25 10:59:26 <mangix> great
Nov 25 11:02:38 <ynezz> nice, thanks!
Nov 25 11:25:00 <zorun> aparcar[m]: thanks! will do
Nov 25 11:26:57 <zorun> aparcar[m]: can you also have a look at the other patches?
Nov 25 11:26:59 <zorun> https://patchwork.ozlabs.org/project/openwrt/patch/20200824144600.441391-1-baptiste@bitsofnetworks.org/
Nov 25 11:27:04 <zorun> https://patchwork.ozlabs.org/project/openwrt/patch/20200913124256.893496-1-baptiste@bitsofnetworks.org/
Nov 25 11:27:11 <zorun> these are small issues
Nov 25 11:29:42 <adrianschmutzler> just got aware of the musl 1.2.1 PR again
Nov 25 11:30:23 <adrianschmutzler> since we probably won't branch anywhere really soon, can somebody give an estimate how long it would take to clean up if we added that one now?
Nov 25 11:32:38 <stintel> it breaks libvirt and upstream refuses to accept the patches to fix it. not sure if many people use libvirt on openwrt, but it could be a problem
Nov 25 11:34:43 <Namidairo> would probably be limited to some of the beefier x86 targets using it?
Nov 25 11:35:22 <adrianschmutzler> and as I understand it, it wouldn't be different after the branch?
Nov 25 11:35:56 <adrianschmutzler> so we just don't have to deal with it _now_?
Nov 25 11:37:49 <adrianschmutzler> Just saw that the PR is from May ...
Nov 25 11:38:00 <karlp> probably about when 1.2 came out?
Nov 25 11:39:51 <adrianschmutzler> I just don't have that much experience how big the risk for stability would be if we added it now ...
Nov 25 11:41:32 <stintel> I'd say we skip it and try getting 20.* out asap, we're back to old OpenWrt release schedules atm so we're breaking our own "rules"
Nov 25 11:41:53 <zorun> let's ask the question the other way around: what advantage would it bring to update to 1.2 now?
Nov 25 11:41:55 <stintel> but at the same time I'm of not much help these days and probably won't be any time soon
Nov 25 11:42:10 <zorun> if there is no clear advantage, it's not worth the risk (even if the risk is small)
Nov 25 11:42:39 <adrianschmutzler> stintel: well, this is about building an opinion, so you are a help with that
Nov 25 11:42:54 <karlp> swiutching to 1.2 now seems like a really bad idea
Nov 25 11:43:33 <stintel> one question to ask is: will 1.1 still receive any updates?
Nov 25 11:43:56 <stintel> as in (security) bugfixes
Nov 25 11:46:04 <karlp> it's declared eol, but 1.2 only came out in feb, and I guarantee lots of people are sitll on 1.1 and it will get fixes
Nov 25 11:51:58 <Tapper> karlp The thing is how close are we to branching? If we are branching soon then we should hold off on the update, but if it's going to be a long time untill branching then update it.
Nov 25 11:53:06 <Tapper> To be clear I would like openwrt 20.xx insted of a update to
Nov 25 11:53:19 <Tapper> 1.2
Nov 25 11:55:17 <Borromini> Tapper: any extra major change just pushes branching further forward.
Nov 25 11:55:36 <adrianschmutzler> and that discussion was mainly my point
Nov 25 11:55:54 <Tapper> What do we get from updating to 1.2?
Nov 25 11:55:57 <adrianschmutzler> nobody does seem to address the remaining DSA usability issues soon
Nov 25 11:56:00 <Borromini> like stintel says, it's looking like old openwrt release schedules again, and that's one of the things people did not want (and one of the reaons we had the lede plit)
Nov 25 11:56:17 <Borromini> *split
Nov 25 11:56:20 * Tapper nods
Nov 25 12:04:11 <Tapper> there is some Security Advisories for it, but I don't know if any of them are bad for openwrt
Nov 25 12:04:17 <Tapper> https://musl.libc.org/releases.html
Nov 25 12:08:00 <Namidairo> well you've already backported that last one and it'd be a DoS at best unless you had some other issue disclosing memory contents?
Nov 25 12:26:16 <mangix> stintel: got a link to that failure?
Nov 25 12:27:29 <stintel> what failure ?
Nov 25 12:27:39 <mangix> libvirt
Nov 25 12:27:55 <stintel> https://gitlab.com/libvirt/libvirt/-/issues/52#note_377144096
Nov 25 12:29:05 <mangix> adrianschmutzler: i don't care much for the actual bump as much as I do the other patches in that PR. The PR mixes musl and GCC10 fixes.
Nov 25 12:30:26 <adrianschmutzler> I can help you much with package changes, but obviously nobody will merge those if they are _only_ in that PR
Nov 25 12:30:49 <mangix> stintel: maybe alpine has a patch. they've bewn using musl 1.2 since it came out
Nov 25 12:30:52 <adrianschmutzler> but you seem to have sent several GCC10 fixes separately IIRC
Nov 25 12:31:04 <stintel> mangix: patches are sent to libvirt upstream, they don't care
Nov 25 12:31:14 <stintel> everything is in that issue
Nov 25 12:31:26 <stintel> redhat are asshats
Nov 25 12:32:16 <adrianschmutzler> stintel: be careful, there are many submissions at our platforms where people could say the same ... :-(
Nov 25 12:32:44 <Borromini> :P
Nov 25 12:33:18 <mangix> adrianschmutzler: all tb
Nov 25 12:33:34 <mangix> tbe patches in that PR are on patchwork
Nov 25 12:34:35 <mangix> eh maybe except 1 or 2
Nov 25 12:53:16 <Strykar> do ddns-scripts respect "ddns.global.upd_privateip='1'"?
Nov 25 12:59:33 <barhom_> I've come across now several times that the dnsmasq config looses its "dhcp-range=set:lan,192.168...." until I run a restart of dnsmasq. Has anyoen come across this before and know what's going on?
Nov 25 12:59:39 <barhom_> Before I spend hours trying to reproduce it
Nov 25 13:00:11 <AdrianFL> Hi guys, I'm working on debugging something on Ubus and I'm planning to add ulog support (from libubox) to it, in a similar way as procd has a debug mode. I think this would be good to have upstream if you think its worth it. Do you have any coding standards I should follow for this?
Nov 25 13:00:40 <jow> barhom: maybe the init script detects another active dhcp server in the segment
Nov 25 13:00:47 <jow> barhom: see if setting option force 1 cures it
Nov 25 13:00:59 <owrt-1907-builds> build #209 of ath79/nand is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ath79%2Fnand/builds/209
Nov 25 13:03:05 <barhom_> jow, interesting. How does the init script try to detect this even? It sends a dhcp request to see if there is a dhcp server somewhere?
Nov 25 13:04:46 <PaulFertser> barhom_: yes
Nov 25 13:06:56 <barhom_> PaulFertser, thanks. For my use case, I do strongly believe force should be default to 1. But I guess there are other better use cases then
Nov 25 13:07:48 <jow> the intention about not forcing is to avoid disrupting existing lans when plugging in an openwrt device for configuration
Nov 25 13:08:00 <PaulFertser> barhom_: is running more than one DHCPv4 server on a single line segment a good idea ever?
Nov 25 13:08:14 <PaulFertser> s/line/ethernet/
Nov 25 13:09:10 <barhom_> PaulFertser, definentely not. But I am certain in my lab testing I've seen several instances on where the dhcpserver fails to start. And I do not have another dhcp server in my lan
Nov 25 13:09:49 <PaulFertser> barhom_: then the startup failure is likely explained by other reasons
Nov 25 13:11:11 <PaulFertser> udhcpc -n -q -s /bin/true -t 1 -i "$ifname" >&- && rv=1 || rv=0
Nov 25 13:11:38 <PaulFertser> And in that case you'd find "found already running DHCP-server..." in your log
Nov 25 13:13:04 <barhom_> I'm curious now to what is causiung my error. Ill give it a go at reproducing before I go with "force 1"
Nov 25 13:25:49 <raiz> Hi, I did not find support for the VRV7006AW22-A-GR arcandyan modem / router. Do you have any firmware or no support ?!
Nov 25 13:28:15 <PaulFertser> raiz: if there's nothing on the wiki, nothing on the forum and nothing in the source code, well...
Nov 25 13:39:08 <rsalvaterra> adrianschmutzler: Thanks, I didn't know you preferred them split. :)
Nov 25 13:39:48 <adrianschmutzler> I only split them because for one target you actually move and for the other it's redundant
Nov 25 13:39:58 <adrianschmutzler> so, it's two different things anyway
Nov 25 13:40:08 <adrianschmutzler> otherwise I'd probably not have bothered
Nov 25 13:40:22 <rsalvaterra> Ah, I see. It put them all in the same bag, true.
Nov 25 13:41:21 <adrianschmutzler> though that's more a pedantic move than actually necessary
Nov 25 13:53:48 <owrt-1907-builds> build #223 of ar71xx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ar71xx%2Fgeneric/builds/223
Nov 25 14:12:38 <ynezz> AdrianFL: follow the already estabilished coding style in that particular project
Nov 25 14:12:55 <ynezz> AdrianFL: and https://openwrt.org/submitting-patches
Nov 25 15:01:07 <owrt-1907-builds> build #195 of ar71xx/tiny is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ar71xx%2Ftiny/builds/195
Nov 25 16:08:29 <adrianschmutzler> rsalvaterra: just stumbled across your old sstrip patch:
Nov 25 16:08:33 <adrianschmutzler> https://patchwork.ozlabs.org/project/openwrt/patch/20201118091210.9864-1-rsalvaterra@gmail.com/
Nov 25 16:08:46 <rsalvaterra> adrianschmutzler: Hope you didn't fall. :)
Nov 25 16:08:48 <adrianschmutzler> IMO this is about two completely separate things and should be split
Nov 25 16:08:58 <adrianschmutzler> though both are tiny ...
Nov 25 16:10:13 <rsalvaterra> adrianschmutzler: Ah, you mean de rewording should be a patch and the default -z should be another, right?
Nov 25 16:11:01 <adrianschmutzler> yes
Nov 25 16:12:45 <rsalvaterra> adrianschmutzler: Actually, I'm thinking if it wouldn't be better just to resend everything as a series of three patches…
Nov 25 16:13:01 <adrianschmutzler> and if you touch in anyway, please change prefix into tools/sstrip
Nov 25 16:13:13 <adrianschmutzler> 3rd is version bump?
Nov 25 16:13:47 <rsalvaterra> First, version bump. Second, build patch, Third, default -z.
Nov 25 16:15:22 <adrianschmutzler> err, if you create that file in the version bump, why not give it a proper description right there?
Nov 25 16:15:35 <adrianschmutzler> and send a v2 with two patches, version bump and -z?
Nov 25 16:18:27 <rsalvaterra> Oh, shouldn't I also increment PKG_RELEASE?
Nov 25 16:18:34 <rsalvaterra> (Just noticed it.)
Nov 25 16:20:35 <adrianschmutzler> well, for the _version_ bump you would actually reset RELEASE to one, but it's already there. And for the -z, I'd say that's an external change and can be ignored ...
Nov 25 16:21:26 <rsalvaterra> I need to read when and when not to change PKG_RELEASE, I still don't get the exact criteria. Is it documented somewhere?
Nov 25 16:23:21 <rsalvaterra> Just to make sure we're in the same page: I'll squash the reword into the version update patch and send a the default -z as a second patch, in a series.
Nov 25 16:24:04 <adrianschmutzler> yes. since I'm under the impression that you create the patch that you reword later in the version-bump patch
Nov 25 16:24:25 <adrianschmutzler> so, make it right on the first patch instead of introducing a second ...
Nov 25 16:24:50 <rsalvaterra> Yeah, it was basically it. :)
Nov 25 16:25:06 <adrianschmutzler> Unless the -z is also a consequence of the version bump.
Nov 25 16:25:14 <adrianschmutzler> then you can squash all of them together
Nov 25 16:25:57 <adrianschmutzler> or rather "necessity" instead of "consequence"
Nov 25 16:26:08 <rsalvaterra> It is, in the sense the -z is an argument that didn't exist. Adding it by default maintains the behaviour of the previous sstrip we had in our tree (remove trailing zeros).
Nov 25 16:26:52 <adrianschmutzler> then squash it all together and expand the description in the remaining patch
Nov 25 16:27:22 <adrianschmutzler> though I'm not sure whether PKG_NAME should be changed, but that's for somebody else to decide
Nov 25 16:27:49 <rsalvaterra> Yeah, I had thought about PKG_NAME too, but I wasn't sure what to do about it, so I let it be.
Nov 25 16:28:27 <adrianschmutzler> aparcar[m]: you commented initially on that patch. any opinion?
Nov 25 16:28:31 <adrianschmutzler> https://patchwork.ozlabs.org/project/openwrt/patch/20201111235337.1450434-1-rsalvaterra@gmail.com/
Nov 25 16:28:42 <adrianschmutzler> keep or change PKG_NAME?
Nov 25 16:29:40 <adrianschmutzler> I'd also be happy if Paul could then evaluate and merge the result, since he tested the initial version and requested the changes ...
Nov 25 16:30:14 <rsalvaterra> adrianschmutzler: It's still early, aparcar[m] is probably asleep.
Nov 25 16:30:30 <adrianschmutzler> I've marked the old patches with "Changes Requested".
Nov 25 16:30:34 <adrianschmutzler> You are probably right.
Nov 25 16:30:50 <adrianschmutzler> Maybe just send the new patch and add him to receivers
Nov 25 16:31:05 <adrianschmutzler> You could add the question about the PKG_NAME to the commit message after the ---
Nov 25 16:31:12 <rsalvaterra> Yeah, I'll send to the mailing list and copy both of you.
Nov 25 16:31:45 <rsalvaterra> Thanks for the review! v2 coming up shortly. :)
Nov 25 16:32:06 <adrianschmutzler> Well, it wasn't really a review ...
Nov 25 16:34:18 <rr123> l=require('lsqlite3'); error loading module 'lsqlite3' from file './lsqlite3.so':Error relocating ./lsqlite3.so: sqlite3_enable_load_extension: symbol not found
Nov 25 16:37:20 <rr123> not sure about the different between luasql-sqlite3 vs lua-sqlite3 but the latter is the 'official' one from lua.org, however I can not load it, other so module under /usr/lib/lua ars loaded without problems
Nov 25 16:37:35 <rr123> s/different/difference/
Nov 25 16:49:04 <rsalvaterra> adrianschmutzler: Patch sent.
Nov 25 16:58:44 <adrianschmutzler> BTW don't feel discouraged by the little feedback on your patches, I think you touch the right spots, but there is just not many people able to review that stuff
Nov 25 17:00:43 <rsalvaterra> adrianschmutzler: Let me put it this way: I'm used to upstream kernel feedback. ;)
Nov 25 17:01:32 <rsalvaterra> Case in point: https://marc.info/?l=linux-block&m=160603868901675&w=4
Nov 25 17:03:11 <rsalvaterra> I'm happy to return to the drawing board as many times as needed. That's the price of quality.
Nov 25 17:52:10 <owrt-1907-builds> build #196 of ar71xx/nand is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ar71xx%2Fnand/builds/196
Nov 25 18:42:49 <aparcar[m]> rsalvaterra: please send another version of the sstrip patch
Nov 25 19:22:38 <philipp64> stintel: ping
Nov 25 19:26:36 <nick[m]> Do I have to make special things if I want to use _GNU_SOURCE and the fnctions like reallocarray
Nov 25 19:26:38 <nick[m]> ?
Nov 25 19:27:33 <nick[m]> ahhh, Openwrt has some stripped down glibc oder?
Nov 25 19:44:20 <nick[m]> no it is called musl, sry ^^ but is there a standard workaround for reallocarray?
Nov 25 19:52:40 <rsalvaterra> aparcar[m]: Will do, sorry for the delay (back from a 7 km walk).
Nov 25 20:02:01 <rsalvaterra> aparcar[m]: Patch sent.-
Nov 25 20:09:12 <rsalvaterra> Now I need to see if dangole allows me to bloat hostapd-basic by 4 kiB. :P
Nov 25 20:14:10 <aparcar[m]> rsalvaterra: https://github.com/aparcar/openwrt/actions/runs/383931457 if it builds fine I'll merge it later
Nov 25 20:14:36 <rsalvaterra> Great! Thanks!
Nov 25 20:16:44 <aparcar[m]> mangix: is your openssl fix upstream/
Nov 25 20:16:45 <aparcar[m]> ?
Nov 25 20:16:57 <svanheule[m]> Thanks for merging my uImage patches, adrianschmutzler! =)
Nov 25 20:53:04 <aparcar[m]> rsalvaterra: https://github.com/aparcar/openwrt/runs/1455564472 patch is broken
Nov 25 20:54:01 <rsalvaterra> Eek!
Nov 25 20:54:10 <rsalvaterra> Let me see here…
Nov 25 20:56:04 <rsalvaterra> Can't find the patch…? Hmm…
Nov 25 20:56:30 <aparcar[m]> I'm assuming the build dir is wrong
Nov 25 20:56:40 <aparcar[m]> because package name != elfkickers
Nov 25 20:57:49 <rsalvaterra> Aw, crap. Alright, let me fix this…
Nov 25 20:59:21 <aparcar[m]> rsalvaterra: could you work on ustream-ssl ;)?
Nov 25 20:59:31 <rsalvaterra> Yeah, it's extracting to another dir.
Nov 25 20:59:51 <rsalvaterra> Hmm… ustream-ssl? Is that a thing now? :P
Nov 25 21:00:04 <aparcar[m]> yes
Nov 25 21:00:07 <aparcar[m]> a broken thing
Nov 25 21:00:17 <aparcar[m]> *broken under specific circumstances
Nov 25 21:00:34 <rsalvaterra> It's a 7 years old thing, I see.
Nov 25 21:03:30 <aparcar[m]> rsalvaterra: We need it to work with wolfssl
Nov 25 21:04:04 <rsalvaterra> Hmm… doesn't wolfSSL provide a OpenSSL compatibility header?
Nov 25 21:04:26 <aparcar[m]> currently it doesn't validate certificates
Nov 25 21:04:30 <aparcar[m]> which is... bad
Nov 25 21:04:48 <rsalvaterra> Yeah, validating certificates is kinda the whole point.
Nov 25 21:09:12 <aparcar[m]> zorun: https://patchwork.ozlabs.org/project/openwrt/patch/20200824144600.441391-1-baptiste@bitsofnetworks.org/ merged
Nov 25 21:10:04 <rsalvaterra> aparcar[m]: Isn't ustream-ssl used by the libustream-*? Or is it the other way around?
Nov 25 21:11:32 <aparcar[m]> rsalvaterra: it's used by uclient-fetch and uhttpd, that's all I know
Nov 25 21:16:34 <rsalvaterra> aparcar[m]: Ok, I think I fixed sstrip, but I don't like it.
Nov 25 21:16:55 <rsalvaterra> HOST_BUILD_DIR:=$(BUILD_DIR_HOST)/ELFkickers-$(PKG_VERSION)
Nov 25 21:17:18 <rsalvaterra> Oh, and HOST_BUILD_DIR and BUILD_DIR_HOST? Really? :P
Nov 25 21:18:39 <karlp> whatever, the variables are there to be used,
Nov 25 21:19:46 <rsalvaterra> Yeah, of course, but the naming…!
Nov 25 21:22:55 <mangix> aparcar[m]: no. the bug is a cross compilation one. I CC'ed cotequeiroz for comments but he seems to be AWOL.
Nov 25 21:23:22 <aparcar[m]> rsalvaterra: my favorite is BUILD_KEY=$(TOPDIR)/key-build
Nov 25 21:23:29 <rsalvaterra> aparcar[m]: Compile-testing to make sure I don't screw up again…
Nov 25 21:23:43 <aparcar[m]> rsalvaterra: ideally you always do that ;)
Nov 25 21:25:06 <rsalvaterra> aparcar[m]: Riiiiight… :P
Nov 25 21:25:40 <rsalvaterra> git log
Nov 25 21:25:47 <rsalvaterra> Oops! Wrong terminal.
Nov 25 21:29:05 <rsalvaterra> aparcar[m]: Sent. (Come to think of it, I think that's why I changed the PKG_NAME initially.)
Nov 25 21:29:32 <aparcar[m]> :)
Nov 25 21:31:45 <aparcar[m]> zorun: looking at https://patchwork.ozlabs.org/project/openwrt/patch/20200913124256.893496-1-baptiste@bitsofnetworks.org/ I wonder if opkg should lose all md5 support
Nov 25 21:32:11 <mangix> why not
Nov 25 21:33:41 <mangix> that bug seems really bad
Nov 25 21:33:43 <aparcar[m]> mangix: response to opkg?
Nov 25 21:33:51 <aparcar[m]> rsalvaterra: https://github.com/aparcar/openwrt/actions/runs/384041162
Nov 25 21:33:52 <mangix> yeah
Nov 25 21:34:22 <rsalvaterra> Green. I like green. Green is good.
Nov 25 21:34:45 <aparcar[m]> rsalvaterra: yellow. The gods did not decide yet
Nov 25 21:35:11 <aparcar[m]> dangole: good evening
Nov 25 21:35:16 <rsalvaterra> I'm colourblind, sorry. :P
Nov 25 21:35:46 <aparcar[m]> itt: remove md5 support of opkg based on https://patchwork.ozlabs.org/project/openwrt/patch/20200913124256.893496-1-baptiste@bitsofnetworks.org/
Nov 25 21:35:48 <rsalvaterra> (It's actually true, but not red-green, fortunately.)
Nov 25 21:35:58 <aparcar[m]> rsalvaterra: CI ready
Nov 25 21:36:30 <rsalvaterra> Hey, dangole!
Nov 25 21:36:59 <rsalvaterra> So, do you let me bloat hostapd by 4 kiB? ;)
Nov 25 21:37:11 <rsalvaterra> *hostapd-basic-*
Nov 25 21:37:49 <aparcar[m]> mangix: up for a little opkg patching?
Nov 25 21:38:40 <mangix> meh don't really carefor it.
Nov 25 21:38:45 <dangole> rsalvaterra: yes, let
Nov 25 21:39:15 <rsalvaterra> Great! Airtime policy support is really a must-have, these days.
Nov 25 21:39:31 <mangix> aparcar[m]: request ti merge https://github.com/openwrt/openwrt/pull/3316
Nov 25 21:39:47 <mangix> it's been tested already
Nov 25 21:39:50 <dangole> rsalvaterra: imho we should switch that on for the -mesh variants as well
Nov 25 21:41:08 <rsalvaterra> dangole: Really? In that case, I'll update my patch. Let's see…
Nov 25 21:41:43 <aparcar[m]> mangix: +9 −29,539 w00t
Nov 25 21:42:40 <aparcar[m]> mangix: will have a look
Nov 25 21:43:29 <dangole> rsalvaterra: make sure to enable it for both, wpa_supplicant and hostapd for the -mesh variant.
Nov 25 21:44:59 <rsalvaterra> You mean wpa_supplicant and wpad, right?
Nov 25 21:45:14 <rsalvaterra> There's no hostapd-mesh, from what I can tell.
Nov 25 21:57:12 <aparcar[m]> jow: do you mind I compile and run test this? https://github.com/openwrt/openwrt/pull/3316 you're the maintainer
Nov 25 21:59:08 <aparcar[m]> mangix: wondering if the [..] stuff should be above the SoB line
Nov 25 21:59:24 <jow> aparcar[m]: feel free
Nov 25 22:07:07 <rsalvaterra> dangole: Speaking of airtime policy, I've been playing with it today. I defined a per-BSS limited configuration, but I somehow see all stations with an airtime weight of 256, when I do a iw dev station dump. Is this expected?
Nov 25 22:11:03 <eduardas> hello, I am quite confused about SPI-NOR flash IC command sets... It seems to me that chips from different manufacturers like Microchip, Macronix and Gigadevice are compatible (like gd25q16c and SST25VF016B), but that particular command set is not really part of any JEDEC standard
Nov 25 22:11:52 <eduardas> I would be very grateful if anyone could elaborate on this topic... is this a de-facto standard or is there a spec for this?
Nov 25 22:13:44 <mangix> aparcar[m]: probably.
Nov 25 22:28:19 <aparcar[m]> mangix: please fix that
Nov 25 22:32:53 <mangix> the PR is not mine
Nov 25 22:33:04 <mangix> you can manually do it
Nov 25 22:33:56 <adrianschmutzler> Those commit message could need some polishing anyway
Nov 25 22:34:07 <rsalvaterra> Is it my impression, or is the hostapd release cycle *really* slow? I mean, the latest version is 2.9 and it was tagged early August last year… :/
Nov 25 22:35:14 <adrianschmutzler> but it's up to aparcar whether he prefers fixing himself or pushing the author to do so
Nov 25 22:35:44 <adrianschmutzler> depending on the author, one or the other might be the better choice ;-)
Nov 25 22:38:28 <pkgadd> rsalvaterra: there is no real release cycle for hostapd
Nov 25 22:40:59 <pkgadd> it's basically just trunk/ master, it only gets bumped when Jouni notices that a long time has passed and that there really ought to be one soon; to be fair, he does a great job at maintaining security fixes for old(er) releases though
Nov 25 22:41:15 <dangole> rsalvaterra: i meant the hostapd contained in wpad-mesh-*, and yes, there is no hostapd-mesh
Nov 25 22:44:31 <rsalvaterra> pkgadd: Ah, I see our makefile points to a specific commit, that explains it.
Nov 25 22:46:14 <rsalvaterra> dangole: Wait. The mesh variants are -full + mesh stuff. So they already have airtime policy enabled.
Nov 25 22:50:57 <stintel> any reports of broken swconfig ? my DAP-2695-A1 doesn't configure its VLANs anymore after sysupgrade
Nov 25 22:53:30 <rsalvaterra> stintel: I had an issue one or two weeks ago, it was caused by a netifd change, but nbd fixed it really quickly.
Nov 25 22:54:04 <pkgadd> stintel: seems to work with a slightly complex VLAN setup on my nbg6817 (ipq8065) on r15021-b0ecae504b (1.5 days old)
Nov 25 22:55:29 <stintel> https://bpa.st/AVAA = broken
Nov 25 22:55:39 <stintel> on DAP-2695-A1. similar works fine on EAP-245v3
Nov 25 22:55:51 <stintel> great. how does one debug this?
Nov 25 22:57:33 <rsalvaterra> stintel: That's similar to my Archer C6, on which I had the issue. Basically, the WAN VLAN wasn't configured at all, in my case.
Nov 25 22:57:46 <stintel> wait. would it be caused by uci again, due to /etc/config/snmpd and /etc/config/snmpd-opkg conflicting somehow
Nov 25 22:57:54 <stintel> I vaguely recall having this on another device
Nov 25 22:59:48 <stintel> apparently not
Nov 25 23:01:17 <stintel> apparently something was in my /etc/config/network that broke it
Nov 25 23:01:33 <stintel> config device 'wl24-guest'
Nov 25 23:01:34 <stintel>         option isolate '1'
Nov 25 23:02:32 <aparcar[m]> mangix are you up for a commit message fix-up and I do the testing and merge?
Nov 25 23:02:42 <stintel> a bit annoying that this completely breaks stuff instead of ignoring it
Nov 25 23:09:14 <mangix> well, do note I never made that commit. I just made the changes. I assumed Pepe would merge those into his commit.
Nov 25 23:10:47 <mangix> Hmm don't see the issue with the commit, except for the last point being commented badly.
Nov 25 23:11:04 <mangix> Maybe Removed TARGET_CLAFGS, it is not longer necessary.
Nov 25 23:11:13 <mangix> whoops
Nov 25 23:13:27 <mangix> Removed TARGET_CFLAGS. fPIC is default. gnu99 is as well. Defining USE_DOS increases the size by adding extra outdated conversions that are unused.
Nov 25 23:13:32 <adrianschmutzler> mangix: there is a signed-off-by from you in the second commit
Nov 25 23:13:43 <adrianschmutzler> if you didn't authorize that, you should tell him
Nov 25 23:14:06 <mangix> well, I don't really mind.
Nov 25 23:19:30 <stintel> blocktrron: can you document the wifi options you added recently on the wiki?
Nov 25 23:22:49 <mangix> there's actually a different issue with libiconv-full that I haven't figured out
Nov 25 23:23:14 <mangix> when building with BUILD_NLS, the host package becomes totally broken
Nov 25 23:31:48 <Tapper> Hi am I write in thinking that dnsmasq does DHCP?
Nov 25 23:32:13 <mangix> I would hope so
Nov 25 23:32:28 <Tapper> If so why do we have dnsmasq odhcpd and odhcpdv6
Nov 25 23:32:41 <mangix> because NIH
Nov 25 23:32:50 <Tapper> NIH?
Nov 25 23:32:58 <mangix> not invented here
Nov 25 23:33:11 <pkgadd> dnsmasq-full could do IPv6 as well, but it's not too good with dynamic prefixes (that's where odhcpd is better).
Nov 25 23:34:43 <Tapper> I don't know a thing about ip v6. why do we need odhcpd and odhcpv6 then if dnsmasq can handle ipv4 dhcp?
Nov 25 23:35:41 <Tapper> can't dnsmasq do ipv4 and odhcpv6 do ipv6?
Nov 25 23:35:48 <stintel> yes
Nov 25 23:36:58 <Tapper> so would dropping odhcp save space
Nov 25 23:37:36 <mangix> yes
Nov 25 23:37:39 <Tapper> It sounds to me like we have 3 packages that can do the same thing.
Nov 25 23:37:42 <stintel> seeing a load of `Thu Nov 26 01:36:55 2020 daemon.notice netifd: radio5 (3230): sh: out of range`
Nov 25 23:37:50 <stintel> how can one figure out what is causing this ?
Nov 25 23:38:50 <Tapper> mangix I am not just talking about me I am on about openwrt as a project.
Nov 25 23:38:53 <mangix> Tapper: eh no. odhcpdv6 is just a package variant with disabled ipv4
Nov 25 23:39:30 <Tapper> In a stock build of openwrt you have dnsmasq odhcp and odhcpv6
Nov 25 23:39:44 <mangix> I've actually replaced dnsmasq with odhcpcd before. works well. but no DNS.
Nov 25 23:40:16 <Tapper> lol I have to say I need me some DNS!
Nov 25 23:40:21 <mangix> Tapper: one is a client the other is a server
Nov 25 23:41:13 <Tapper> I am confused.
Nov 25 23:42:16 <mangix> odhcp6c is a client used for WAN. odhcpd is a server for the local network
Nov 25 23:42:25 <Tapper> I did a build of openwrt with out odhcp and odhcpv6. I switched dnsmasq to dnsmasq-full and it all worked
Nov 25 23:42:44 <mangix> right. But NIH.
Nov 25 23:42:53 <Tapper> all devices on my net work got dns and dhcp ip-v4 and ip-v6
Nov 25 23:46:32 <mangix> stintel: does lldpd even compile?
Nov 25 23:47:25 <stintel> root@ap0:~# opkg list_installed |grep lld
Nov 25 23:47:25 <stintel> lldpd - 1.0.7-1
Nov 25 23:47:32 <stintel> you know, I test stuff
Nov 25 23:47:59 <mangix> I do as well. The previous version doesn't even compile: https://downloads.openwrt.org/snapshots/faillogs/aarch64_cortex-a53/base/lldpd/compile.txt
Nov 25 23:48:15 <stintel> first I hear of it
Nov 25 23:48:27 <mangix> You using glibc?
Nov 25 23:48:33 <stintel> root@gpsrpi4:~# opkg list_installed | grep lldp
Nov 25 23:48:34 <stintel> lldpd - 1.0.5-2
Nov 25 23:48:39 <stintel> this is on rpi4/aarch64
Nov 25 23:48:45 <stintel> no, I do not
Nov 25 23:48:50 <mangix> strange
Nov 25 23:48:53 <stintel> glibc is corner case, I will never test that
Nov 25 23:49:20 <mangix> what OS do you compile on?
Nov 25 23:49:28 <stintel> linux
Nov 25 23:49:38 <mangix> sorry, which distro?
Nov 25 23:49:41 <stintel> gentoo
Nov 25 23:50:15 <mangix> No idea there. lldpd doesn't compile on Debian or Fedora derivatives
Nov 25 23:50:41 <mangix> problem started with GCC8 I believe
Nov 25 23:54:07 <mangix> Interesting. nbd has 100% of OpenWrt's commits
Nov 25 23:55:37 <mangix> n Debian or Fedora derivatives
Nov 25 23:55:37 <mangix> 15:50 < mangix> problem started with GCC8 I believe
Nov 25 23:55:47 <mangix> uhhh
Nov 25 23:55:55 <mangix> https://gist.github.com/neheb/e18242d47f39e8cd6c24dbe904837f21
Nov 26 00:00:22 <stintel> so it's cc80cf53c50 causing all those sh out of range erros
Nov 26 00:09:17 <mangix> aparcar[m]: sent replacement patch for the libjson-c fix.
Nov 26 00:21:20 <owrt-snap-builds> build #529 of ramips/mt7621 is complete: Failure [failed images]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt7621/builds/529  blamelist: Rosen Penev <rosenp@gmail.com>, Rui Salvaterra <rsalvaterra@gmail.com>, Stijn Tintel <stijn@linux-ipv6.be>, Ataberk ?zen <ataberkozen123@gmail.com>, Paul Spooren
Nov 26 00:21:20 <owrt-snap-builds> <mail@aparcar.org>, Adrian Schmutzler <freifunk@adrianschmutzler.de>, Lukas Tribus <lukas@ltri.eu>, Michael Pratt <mcpratt@pm.me>, Filip Moc <lede@moc6.cz>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Sander Vanheule <sander@svanheule.net>, Karel Ko?? <karel.koci@nic.cz>, Tomasz Maciej Nowak <tmn505@gmail.com>
Nov 26 00:32:56 <aparcar[m]> mangix: and commit message?
Nov 26 00:35:44 <mangix> https://patchwork.ozlabs.org/project/openwrt/patch/20201126000857.130391-1-rosenp@gmail.com/
Nov 26 00:46:42 <mangix> posted libiconv bump on patchwork with a reworded message.
Nov 26 00:49:14 <aparcar[m]> ack
**** ENDING LOGGING AT Thu Nov 26 02:59:57 2020