**** BEGIN LOGGING AT Thu Sep 10 07:36:15 2020
Sep 10 08:09:34 <jow> zorun: done
Sep 10 08:20:10 <rsalvaterra> Hey, guys! I'm trying to understand the kind of partition parsing we have on the TL-WDR3600, in order to disable what I don't need from the kernel. In the device tree we have u-boot, firmware and art. I'm 90 % confident I only need the OpenFirmware (device tree) and squashfs partition parsers, but I just want to make sure, lest I have to TFTP my way out of it. :)
Sep 10 08:22:36 <rsalvaterra> Oh, and I need the TP-Link partition parser too, of course.
Sep 10 08:40:55 <PaulFertser> rsalvaterra: I'm not sure you need any partition table parsers at all (except for the device tree one) but you need MTD splitters. One to split firmware into uimage (does this tplink use plain uimage or uimage with tplink header prepended?) and rootfs, and then another to split squashfs rootfs into rootfs and rootfs_data.
Sep 10 08:43:26 <rsalvaterra> From my dmesg… https://paste.debian.net/1163266/
Sep 10 08:44:29 <PaulFertser> rsalvaterra: ok, so it's not plain uimage splitter, that's essential.
Sep 10 08:45:01 <rsalvaterra> Yeah, I know I need the TP-Link parser. :)
Sep 10 08:45:42 <rsalvaterra> So, OpenFirmware and TP-Link parsers and squashfs splitter should be enough.
Sep 10 08:47:27 <jow> mangix: ping
Sep 10 08:47:40 <andy2244> hiho, i'm still looking for a reviewer for this small PR, if anyone is interested? https://github.com/openwrt/openwrt/pull/3148
Sep 10 08:48:30 <dwmw2_gone> andy2244: can't it be a module?
Sep 10 08:49:12 <PaulFertser> rsalvaterra: not parser, CONFIG_MTD_SPLIT_TPLINK_FW
Sep 10 08:49:38 <PaulFertser> rsalvaterra: and CONFIG_MTD_SPLIT_SQUASHFS_ROOT
Sep 10 08:49:49 <rsalvaterra> dwmw2_gone: I believe io_uring is too core to be a module.
Sep 10 08:50:03 <rsalvaterra> The thing is… are there any users already?
Sep 10 08:50:12 <rsalvaterra> PaulFertser: Got it, thanks! :)
Sep 10 08:50:35 <dwmw2_gone> rsalvaterra: and yet it can be a config option?
Sep 10 08:51:19 <rsalvaterra> I'm still waiting for libevent (which I need for Tor) to implement io_uring support. :P
Sep 10 08:51:21 <andy2244> i guess my samba module would be the first, we just have liburing for a months, which most use but we also need this kernel opion
Sep 10 08:51:58 <rsalvaterra> dwmw2_gone: It's not tristate, I guess. :)
Sep 10 08:52:13 <Borromini> if anyone can help me track down what is making my Config-kernel.in addition not show up in menuconfig i'd be most happy to :) https://forum.openwrt.org/t/kernel-symbol-in-openwrt-buildroot-enabled-but-not-showing/73809
Sep 10 08:53:27 <dwmw2_gone> doesn't look hard to make it a module
Sep 10 08:54:18 <rsalvaterra> dwmw2_gone: You should ask Jens Axboe about it, it's his baby…
Sep 10 08:54:46 <dwmw2_gone> it's all in fs/io_uring.c
Sep 10 08:55:11 <dwmw2_gone> the only thing outside there is in fs.h where it nops out the io_uring_get_socket() function if it isn't enabled.
Sep 10 08:56:22 <jow> rmilecki: v4 or rc is almost golden, only minor nitpick is that it likely mis-handles commented-out START= and STOP= declarations
Sep 10 08:56:37 <jow> rmilecki: but that is something you could fix in a subsequent commit. Feel free to add my Acked-by:
Sep 10 08:56:42 <rmilecki> jow: that was a quick review ;)
Sep 10 08:56:43 <dwmw2_gone> should be easy enough to make the io_uring_get_socket() function dtrt in the modular case, loading the module if it's needed
Sep 10 08:56:48 <rmilecki> thanks!
Sep 10 08:57:39 <rsalvaterra> andy2244: For what it's worth, in my opinion, default y (even if !SMALL_FLASH) is a no-no.
Sep 10 08:58:08 <rsalvaterra> Make it default n and have the packaged that need it select it.
Sep 10 08:58:21 <rsalvaterra> *packages
Sep 10 08:58:41 <jow> no conditional compilation for kernel symbols, this is discouraged
Sep 10 08:59:07 <rsalvaterra> jow: Really? Ah, right… opkg.
Sep 10 08:59:22 <rsalvaterra> Well, that's a bummer. :)
Sep 10 08:59:40 <jow> I have no issues with adding stuff like uring to x86, mvebu and other capable targets
Sep 10 08:59:54 <jow> on ath25 or ar71xx one likely wouldn't run samba4 anyway
Sep 10 09:00:19 <andy2244> mhh so i need to convince upstream to make it a module, before we merge it?
Sep 10 09:00:40 <rsalvaterra> andy2244: That would be a better option, yes.
Sep 10 09:05:07 <andy2244> ok will try, not a big priority atm. My samba tests with io_uring module where mixed atm, but this may change with samba 4.13. Thanks for the quick info
**** BEGIN LOGGING AT Thu Sep 10 09:23:04 2020
**** BEGIN LOGGING AT Thu Sep 10 09:49:35 2020
Sep 10 10:14:20 <jow> is the file mode stuff in packages still broken?
Sep 10 10:15:23 <jow> I just installed http://downloads.openwrt.org/snapshots/packages/x86_64/base/libjson-c5_0.14-2_x86_64.ipk and have
Sep 10 10:15:26 <jow> root@jj:~# ls -nl /usr/lib/libjson-c.so.5.0.0
Sep 10 10:15:35 <jow> -rw-r--r--    1 101      102          65606 Sep  9 07:54 /usr/lib/libjson-c.so.5.0.0
Sep 10 10:15:38 <jow> the file is owned by uid 101, gid 102 instead of 0, 0
Sep 10 10:19:55 <jow> same for a random other package: https://downloads.openwrt.org/snapshots/packages/x86_64/base/libroxml3.0.2_3.0.2-1_x86_64.ipk
Sep 10 10:20:05 <jow> this is very bad
Sep 10 10:21:33 <jow> other package, built today: https://downloads.openwrt.org/snapshots/packages/arm_cortex-a7/base/netifd_2020-09-08-d7b614a8-1_arm_cortex-a7.ipk
Sep 10 10:23:17 <jow> contents seem to belong to 101, 102 which happens to be the buildbot user
Sep 10 10:23:43 <jow> if I would need to guess, my guess would be that nobody bothered to test the SDK
Sep 10 10:25:37 <blogic> oh dear
Sep 10 10:26:32 <jow> maybe it was me with the IPC change yesterday, need to investigate
Sep 10 10:32:10 <rsalvaterra> I'm wondering… is the QCA8337 just a rebranded AR8337, or are the completely different switches?
Sep 10 10:32:13 <jow> yep, reproduced with the SDK
Sep 10 10:32:22 <jow> all package contents belong to me when building with the SDK
Sep 10 10:32:34 <jow> seriously, who comiits such crap?
Sep 10 10:34:15 <jow> and since when do I need to build libselinux to produce a base-file package? Is that crap enabled by defualt now?
Sep 10 10:34:45 <jow> libprce... wth
Sep 10 10:36:55 <jow> make[2]: *** [Makefile:217: /tmp/openwrt-sdk-x86-generic_gcc-8.4.0_musl.Linux-x86_64/build_dir/target-i386_pentium4_musl/linux-x86_generic/base-files/.configured_75c7549342abdfffcc35571e1cb1a0e6_8e081b74cf069e1e6800a5bbcbb282f0] Segmentation fault
Sep 10 10:37:00 <jow> *clap* *clap*
Sep 10 10:59:49 <WiredLife> Does anyone knows where i can see the changelog of the build for xiaomi/redmi ac2100?
Sep 10 11:00:00 <jow> staging_dir/host/bin/fakeroot also uses hardcoded paths
Sep 10 11:00:12 <jow> it can't work
Sep 10 11:02:18 <karlp> but.... you're missing the big picture, now, in theory, we can have multi user openwrt!
Sep 10 11:05:45 <jow> sems the actual culprit is the PKG_FILE_MODES to scripts/ipkg-build
Sep 10 11:05:55 <mangix> jow: pong
Sep 10 11:06:25 <jow> it removed the --owner=0 --group=0 uid squashing and replaced it with -m
Sep 10 11:06:38 <jow> that applies only the specifically mentioned files though
Sep 10 11:06:54 <jow> all other files keep their ownership and permissions from the host system
Sep 10 11:07:12 <jow> an chown -R root:root $pkgdir or similar is needed
Sep 10 11:07:14 <pavlix> I'm really happy OpenWRT is switching to 5.4! But the at91 patches seem to modify files that don't exist in v5.4.63. Looks suspicious.
Sep 10 11:07:43 <jow> seems like a classic case of a missing negative test. It was only tested that the file mode stuff works for the files covered by it, not the entire rest
Sep 10 11:08:51 <jow> mangix: I was wondering if it makes sense to handle libcxx and libcxxabi in the same Makefile (same source package) to avoid circular depends
Sep 10 11:09:04 <jow> mangix: given that these two libs seem to be deeply entangled anyway
Sep 10 11:11:00 <mangix> they're teo different projects
Sep 10 11:11:11 <mangix> *two
Sep 10 11:11:25 <mangix> with different tarballs
Sep 10 11:12:23 <mangix> the proper way to build them is from the LLVM monorepo but that includes a lot of other stuff.
Sep 10 11:13:47 <jow> mangix: it is not a problem to fetch multiple tarballs from one makefile
Sep 10 11:14:10 <jow> mangix: so if you want to keep them separate, either package could simply fetch the sources of the other again and extract them locally
Sep 10 11:15:54 <mangix> in that case, one Makefile woild make sense. Nothing else uses libcxxabi.
Sep 10 11:16:30 <jow> you could take a look at the mac80211 package to see how to fetch multiple sources
Sep 10 11:19:24 <mangix> Anyway, hauke was requesting a fix for it. Didn't know stuff in the SDK was in a different directory.
Sep 10 11:21:26 <pavlix> I suspect the patches-5.4 might not even be applied for at91 target... How do I force linux tarball to unpack and get patched to check that? I can make package/NAME/{clean,prepare} but that doesn't seem to work for the kernel...
Sep 10 11:22:52 <Borromini> pavlix: i think it's make package/kernel/...
Sep 10 11:22:52 <pavlix> I see now. target/linux/{clean,prepare}
Sep 10 11:23:19 * Borromini shuts up
Sep 10 11:23:26 <Borromini> yeah >_>
Sep 10 11:24:14 <pavlix> I see now. There are loads of generic patches in OpenWRT and the at91 specific patches are used on top of those.
Sep 10 11:29:35 <pavlix> It looks like linux-at91 port is a bit messy. Some at91 files are created by the generic patches and then modified by the specific patches.
Sep 10 11:30:59 <Borromini> i think that's the case for all targets, since generic ones are meant to apply to all supported targets, not just the one you are looking at e.g.
Sep 10 11:31:02 <Borromini> hence the split
Sep 10 11:31:46 <pavlix> Borromini: Actually the generic patch here adds a DTB file for an at91 target and the specific one updates it.
Sep 10 11:32:16 <pavlix> I also suspect the DTB file is already in upstream, just under a different name.
Sep 10 11:34:25 <pavlix> Actually it doesn't seem to come from generic patches but rather from files. But that means it's probably then patched for 5.4 specifically.
Sep 10 11:34:30 <pavlix> Interesting.
Sep 10 11:34:43 <pavlix> Speaking about: target/linux/at91/files/arch/arm/boot/dts/wb45n.dts
Sep 10 11:35:26 <pavlix> I'll just drop all the specific patches for my builds as they are unrelated. I'm used to symlinking the patch-x.y directory to my own patchest out of the OpenWRT tree.
Sep 10 11:35:37 <pavlix> (Open for a better way, though.)
Sep 10 11:36:56 <pavlix> It is interesting to see that the 5.4.63 has build issues (on new systems) that the 4.19.141 already got rid of.
Sep 10 11:40:33 <pavlix> Oh, it's not the kernel, it's the kernel files copied to u-boot again.
Sep 10 11:53:10 <jow> okay, so it turns out that wrapped executables in the SDK lose their fakeroot context because we're preloading too
Sep 10 11:53:45 <zorun> jow: thanks!
Sep 10 12:28:57 <jow> rmilecki: will you also work on coverting luci to rpcd/rc ?
Sep 10 12:29:11 <rmilecki> jow: i may at some point, sure
Sep 10 12:30:11 <rmilecki> jow: reviewing my another patch could encourage me ;) https://patchwork.ozlabs.org/project/openwrt/patch/20200618132518.26000-1-zajec5@gmail.com/ [PATCH luci] luci-mod-system: use ubus method for reboot
Sep 10 12:30:41 <jow> rmilecki: oh yes, feel free to push
Sep 10 12:30:52 <rmilecki> perfect
Sep 10 12:31:56 <jow> (and check if the 'require fs'; can be dropped after the change)
Sep 10 12:32:59 <jow> just took a look myself, it can be removed, no other user in that particular .js file
Sep 10 12:34:47 <rmilecki> thanks
**** BEGIN LOGGING AT Thu Sep 10 12:44:10 2020
Sep 10 12:51:27 <jow> any OS X user here who can run a quick runtime test?
Sep 10 13:10:27 <rsalvaterra> WTF…?! https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=ccb4b96b8a4990178512c7a785f998a5e6f74cc3
Sep 10 13:11:02 <rsalvaterra> Ok, I understand the point, but why on Earth should comgt-ncm depend on wwan? It should be the other way around, no?
Sep 10 13:11:54 <rsalvaterra> If a user knows which protocol to use, why should he have to pull an auto-detection dependency?
Sep 10 13:12:37 <rsalvaterra> Imma fixin' this in my tree…
**** BEGIN LOGGING AT Thu Sep 10 13:34:54 2020
Sep 10 13:54:41 <rsalvaterra> And shouldn't the wwan package show up inside the WWAN submenu…?
Sep 10 14:10:20 <karlp> those submenus are a menace IMO.  too many layers and too many overlaps with "shodul I like for this in _that_ menyu, or _that_ menu, or in the root?"
Sep 10 14:10:49 <jow> I agree
Sep 10 14:11:03 <jow> simple alphabetical order would be more than sufficient
Sep 10 14:11:19 <jow> after all you need to know in advance what to look for anyway
Sep 10 14:11:36 <rsalvaterra> Well, submenus are a tool… and like every tool, they should be used wisely. :P
Sep 10 14:11:49 <karlp> It makes sense for a couple of the individual packages that have like 50 options/subpackages, but the vaguely "networking term here"  submenus are hard to use.
Sep 10 14:12:18 <karlp> jow: I don't _always_ know what i'm looking for, sometimes I'm browsing to see what might be interesting or useful :)
Sep 10 14:12:38 <karlp> but even then I just scroll the descriptions and titles, better than in and out of menus all the time :)
Sep 10 14:17:16 <rsalvaterra> And about comgt-ncm, why should it depend on usb-serial and wwan? According to the documentation, usb-serial is optional.
Sep 10 14:26:21 <karlp> because we dont' have optional deps in owrt...
Sep 10 14:26:35 <karlp> we have a few packages attempt it, but it's hit and miss,
Sep 10 14:26:50 <karlp> and build variants are awkward for installing things.
Sep 10 14:26:57 <karlp> so often you just include what's likely to be wanted anyway
**** BEGIN LOGGING AT Thu Sep 10 14:28:50 2020
Sep 10 14:50:14 <rsalvaterra> Oh, well…
Sep 10 14:50:34 <rsalvaterra> I just did this on the comgt makefile…
Sep 10 14:50:37 <rsalvaterra> -  DEPENDS:=+comgt +wwan +kmod-usb-serial-option +kmod-usb-net-huawei-cdc-ncm
Sep 10 14:50:37 <rsalvaterra> +  DEPENDS:=+comgt +kmod-usb-net-huawei-cdc-ncm
Sep 10 14:51:06 <rsalvaterra> … and my connection is working perfectly without the extra stuff.
Sep 10 14:51:59 <karlp> yes, yours.
Sep 10 14:52:13 <Borromini> :P
Sep 10 14:52:37 <karlp> and you're lucky that it didn't detect the option driver being available, compile it in as detected, and then give you a package build error about undeclared dependencies...
Sep 10 14:53:02 <rsalvaterra> What NCM device requires the serial interface to connect?
Sep 10 14:53:04 <karlp> so _you_ might get a smaller package that way. but it won't necessarily work for everyone.
Sep 10 14:53:14 * karlp shrugs, I'm speaking int he abstract of why these optional deps get set like that.
Sep 10 14:54:45 <rsalvaterra> karlp: I understand, nobody's got the time to test every single combination. :)
Sep 10 14:58:26 <karlp> it's not even testing, it's also that there's no way of a user opkg installing it, and _maybe- they got the right thing?
Sep 10 14:58:41 <karlp> like in your case it's neithre required, nor resulted in a compile time change
Sep 10 14:58:48 <karlp> but some optional deps are optional things that get compiled in.
Sep 10 14:58:55 <karlp> you can't just opkg install the optional dep
Sep 10 14:59:14 <karlp> that sort of thing baloons out to build variants and that soup of complications.
Sep 10 14:59:28 <karlp> so.... los of the time, the optional, small dep gets listed just as a direct dep, and everyone's happy.
Sep 10 14:59:37 <karlp> knob tweakers can always knob tweak.
Sep 10 17:15:35 <Hauke> zorun: thanks for taking care of the release announcements
Sep 10 18:01:16 <blogic> https://sfconservancy.org/news/2020/sep/10/openwrt-joins/
Sep 10 18:02:18 <rsalvaterra> blogic: woohoo!
Sep 10 18:04:55 <rsalvaterra> Speaking of which, I believe most (if not all) ISPs here in Portugal are violating the GPL.
Sep 10 18:24:38 <Borromini> blogic: neat!
Sep 10 18:26:11 <f00b4r0> blogic: nice!
Sep 10 18:37:19 <aparcar[m]> how do I correctly add a line to config-5.4? Just adding it randomly and then some make kernel_menuconfig?
Sep 10 18:37:27 <aparcar[m]> I'm talking about the sorting
Sep 10 18:38:00 <aparcar[m]> blogic: wow
Sep 10 18:38:29 <Borromini> aparcar[m]: isn't sorting alphabetical?
Sep 10 18:38:35 <stintel> aparcar[m]: I usually manually put it in the right place
Sep 10 18:38:50 <stintel> but I believe there is scripts/kconfig.pl
Sep 10 18:38:56 <Borromini> aparcar[m]: from a quick stroll through config-5.4 it really looks alphabetical
Sep 10 18:39:11 <aparcar[m]> Borromini: the vim sort function doesn't handle #
Sep 10 18:39:18 <aparcar[m]> but I'll just add it manually
Sep 10 18:39:49 <Borromini> aparcar[m]: fair point.
Sep 10 18:40:01 <aparcar[m]> maybe there is a cleaner approach but I want rootfs of multiple targets, x86 and armvirt does so already.
Sep 10 18:40:06 * Borromini isn't skilled enough to use the vim sort function and just uses the vim search function
Sep 10 18:40:10 <aparcar[m]> I'd just add TARGET_ROOTFS_TARGZ but maybe there is a better way?
Sep 10 18:40:12 <adrianschmutzler> it's alphabetical, and if you put it in the wrong place "make kernel_oldconfig" will sort it anyway
Sep 10 18:40:26 <aparcar[m]> adrianschmutzler: that's what I needed to know
Sep 10 18:40:39 <adrianschmutzler> (which you should run afterwards anyway, in case additional stuff gets selected)
Sep 10 18:41:10 <aparcar[m]> I want to support more docker rootfs tags
Sep 10 18:41:11 <aparcar[m]> https://hub.docker.com/r/openwrtorg/rootfs/tags
Sep 10 18:41:18 <adrianschmutzler> unless for generic config-xx, there it isn't sorted automatically
Sep 10 18:41:22 <blogic> adrianschmutzler: that rtl838x PR
Sep 10 18:41:23 <aparcar[m]> so not only x86, armvirt/{32,64}
Sep 10 18:41:39 <blogic> adrianschmutzler: do you have any issues with the PR beyond your comments ?
Sep 10 18:41:52 <blogic> adrianschmutzler: otherwise I would help clean up tomorrow and merge it
Sep 10 18:42:00 <blogic> i'd like it in the tree pre release
Sep 10 18:42:02 <stintel> oooh exciting :)
Sep 10 18:42:14 <blogic> I started to cleanup the kernel part so we can send it upstream
Sep 10 18:42:37 <blogic> but having it in the release pre cleanup would be great
Sep 10 18:42:38 <adrianschmutzler> blogic: I have no other problems with it, but actually I don't really understand most of the other stuff properly, as I'm limited to the high-level stuff
Sep 10 18:42:49 <blogic> fine
Sep 10 18:42:56 <blogic> I'll just handle it then with the guys
Sep 10 18:42:58 <adrianschmutzler> so, if it looks sane to you go ahead
Sep 10 18:43:03 <blogic> we have a dedicated irc channel
Sep 10 18:43:26 <Borromini> blogic: neat!
Sep 10 18:43:55 <Borromini> i might be in the market for some extra switches and maybe i could finally deliberately buy some realtek stuff for a change :P
Sep 10 18:44:27 <adrianschmutzler> maybe the author is even here as birger_ ?
Sep 10 18:45:16 <Borromini> adrianschmutzler: yes same full name on a whois
Sep 10 18:45:54 <adrianschmutzler> Borromini: thanks, wasn't aware of whois
Sep 10 18:46:35 <Borromini> yw
Sep 10 18:46:52 <Borromini> i have no idea how polite it is to /whois someone on irc though :D
Sep 10 18:47:03 <stintel> Borromini: as long as you don't tell them they don't know ;)
Sep 10 18:47:27 <adrianschmutzler> was that public? because I just clicked whois on my client ...
Sep 10 18:47:43 <stintel> no
Sep 10 18:48:20 <stintel> normally a user cannot see if you whois them
Sep 10 18:49:30 <stintel> although I remember being on a network where as an oper you do get notified if someone whois'es you
Sep 10 18:50:26 <Borromini> adrianschmutzler: no it's not public
Sep 10 18:50:38 <Borromini> stintel: i thought people were notified if someone whois'ed them
Sep 10 18:50:41 <Borromini> yeah ^^
Sep 10 18:50:46 <Borromini> but maybe not on freenode
Sep 10 18:52:22 <adrianschmutzler> blogic: I'd be happy if my remarks would be addressed before merging, though
Sep 10 18:53:59 <Borromini> blogic: are SFC gonna show the new logo? :P
Sep 10 18:54:15 <Borromini> i thought there was one to replace that variant as well
Sep 10 18:54:24 <adrianschmutzler> btw: birger actually has already contributed to openwrt trunk in contrast to what the PR says, just the github account is new
Sep 10 18:55:58 <aparcar[m]> adrianschmutzler: running kernel_* removes the CONFIG_TARGET_ROOTFS_TARGZ=y option. Should I just add and sort it manually?
Sep 10 18:56:35 <adrianschmutzler> I'd rather ask myself why it's removed
Sep 10 18:57:11 <adrianschmutzler> Either some prerequisite is missing or it's selected elsewhere anyway
Sep 10 18:57:53 <adrianschmutzler> E.g. if you add CONFIG_ATA_LEDS=y but don't have CONFIG_ATA=y in the config, the former will get deleted again during kernel_oldconfig
Sep 10 18:58:19 <stintel> aparcar[m]: scripts/kconfig.pl can be used for alphabetical sorting iirc
Sep 10 18:58:57 <stintel> but yes it's probably better to do what adrianschmutzler said
Sep 10 18:58:58 <adrianschmutzler> stintel: that's I think what Hauke uses for the generic config, because there automatic sorting does not happen
Sep 10 18:59:15 <Borromini> does make kernel_menuconfig have a verbose switch?
Sep 10 18:59:31 <adrianschmutzler> he typically pastes the command in commit message, so one just has to look for recent updates there
Sep 10 18:59:34 <Borromini> you see it doing a lot of stuff but it doesn't spit out any errors (happen to be fighting with it myself)
Sep 10 19:01:07 <aparcar[m]> I mean TARGET_ROOTFS_TARGZ is a OpenWrt specific function and therefore not really known to the kernel, or am I misunderstanding something? Maybe I have to set the option somewhere else instead?
Sep 10 19:03:57 <adrianschmutzler> To me this looks like an OpenWrt config symbol, and not a kernel config symbol
Sep 10 19:04:48 <adrianschmutzler> so it doesn't belong into kernel config files at all
Sep 10 19:05:45 <aparcar[m]> adrianschmutzler: good, where would I set it then? Do I have to set it as default for all targets at once?
Sep 10 19:06:11 <adrianschmutzler> that depends on what you want to do with it
Sep 10 19:07:16 <aparcar[m]> I want CI runtime tests for packages.git, meaning to have more rootfs OpenWrt docker containers than just x86 and armvirt. However I don't mean to test all targets and therefore only need a few more rootfs.tar.gz files
Sep 10 19:07:17 <adrianschmutzler> typically you would just use the logic in Config-images.in for that
Sep 10 19:07:52 <Borromini> aparcar[m]: make menuconfig
Sep 10 19:07:52 <aparcar[m]> but that changes it for all at once right? Or should I do some defaul y if TARGET_ath79?
Sep 10 19:07:56 <adrianschmutzler> well, then just set it in the .config file you use
Sep 10 19:08:24 <adrianschmutzler> you can tune it in Config-images.in
Sep 10 19:08:27 <aparcar[m]> I want the buildbots to create those rootfs
Sep 10 19:08:28 <Borromini> aparcar[m]: you can filter for target_ath79 afaik
Sep 10 19:08:37 <adrianschmutzler> for the .config, you can only build one target at a time anyway
Sep 10 19:08:57 <adrianschmutzler> just look at what's already in Config-images.in for the other symbols
Sep 10 19:09:01 <adrianschmutzler> I have to leave now
Sep 10 19:09:40 <Borromini> ttyl
Sep 10 19:09:42 <aparcar[m]> bye & thanks
Sep 10 19:15:14 <aparcar[m]> okay it's a FEATURE flag in target/linux/ath79/generic/target.mk
Sep 10 19:16:27 <adrianschmutzler> aparcar: FEATURE will only help you to enable it unconditionally though
Sep 10 19:17:03 <aparcar[m]> adrianschmutzler: I want to enable it for ath79/generic at all times
Sep 10 19:17:31 <adrianschmutzler> then either use FEATURE or default y if target_ath79 in Config-images.in
Sep 10 19:17:56 <aparcar[m]> I think Config-images becomes messy
Sep 10 19:18:16 <adrianschmutzler> no idea what best practice is for this case
Sep 10 19:18:19 <aparcar[m]> Ideally it'll run 10 architectures
Sep 10 19:19:02 <aparcar[m]> is 19.07.4 a RELEASE or a VERSION?
Sep 10 19:19:19 <aparcar[m]> or a RELEASE with VERSION 19.07.4
Sep 10 19:19:21 <adrianschmutzler> but then adding it to config-images might provide more overview than having to grep for it through targets
Sep 10 19:19:27 <aparcar[m]> just thinking of a variable name
Sep 10 19:34:40 <rmilecki> blogic: what PR you're discussing with Adrian?
Sep 10 19:38:48 <svanheule[m]> rmilecki: should be this one https://github.com/openwrt/openwrt/pull/3376
Sep 10 19:38:55 <rmilecki> thx
Sep 10 19:44:36 <aparcar[m]> ynezz: ping
Sep 10 19:44:58 <aparcar[m]> to generate 19.07.4 docker containers we need https://github.com/openwrt/docker/pull/64
Sep 10 20:17:05 <Hauke> where and how can we put this onto our website: https://sfconservancy.org/news/2020/sep/10/openwrt-joins/ ?
Sep 10 20:27:47 <zorun> nice!
Sep 10 20:28:32 <zorun> if it's something important, maybe on the frontpage, before "Current stable series"?
Sep 10 20:28:44 <zorun> with one or two paragraphs, and "read more" link to the article
Sep 10 20:29:54 <zorun> does this mean that openwrt is no longer represented by SPI?
Sep 10 20:30:08 <Hauke> yes we switched from the SPI to the SFC
Sep 10 20:30:30 <Hauke> we worked on this for over a year ;-)
Sep 10 20:33:11 <zorun> ok!
Sep 10 20:33:28 <zorun> openwrt would need to be removed there then: https://www.spi-inc.org/projects/openwrt/
Sep 10 20:36:37 <Hauke> zorun: yes we talks with SPI before
Sep 10 20:36:47 <Hauke> this should happen soon
Sep 10 20:42:13 <svanheule[m]> anybody else seeing "hostapd: nl80211: NL80211_ATTR_STA_VLAN (addr=11:22:33:44:55:66 ifname=wlan1 vlan_id=0) failed: -2 (No such file or directory)" on recent master builds? (ath10k-ct, wave-1 hw)
**** BEGIN LOGGING AT Thu Sep 10 23:29:35 2020
**** BEGIN LOGGING AT Fri Sep 11 02:54:30 2020
**** ENDING LOGGING AT Fri Sep 11 02:59:57 2020