**** BEGIN LOGGING AT Fri May 24 03:00:35 2019 May 24 07:14:40 olerem: could you please take a look at https://github.com/openwrt/openwrt/pull/2078#discussion_r286962341 it's ag71xx/ar8xxx related forward porting of ar71xx device to ath79, where I'm not sure if this approach (looks like stright 1:1 copy of ar71xx workaround into ath79) would be later accepted by the upstream May 24 07:56:14 lynxis: ping May 24 09:01:28 ynezz: hi. yes. you are right. this codehas nothing to do with ag71xx May 24 09:03:59 the phy driver should be registred by devicetree and if this device need some kind of reset or workaround, then it should be cleared with phy devs May 24 09:04:22 phy id is not only way to probe this driver May 24 09:09:26 hmm, has anyone got cpu temperature measurement working on apu2 ? May 24 09:26:59 olerem: thanks! May 24 09:59:47 ldir: coretemp should work May 24 10:03:38 ldir: x86/64 has CONFIG_SENSORS_K10TEMP=y builtin, so "sensors" should work ootb: https://pastebin.com/YzJJ8p12 May 24 10:42:07 Hey would like some opinions, i'm currently adding the requested UCI support for the new net/cifsd package, what are your opinions on section nameing, since we will reuse most of the samba stuff? Should i keep the old "samba" and "sambashare" section names or replace those with cifsd equivalents "cifsd" + "smbshare"/"share"? May 24 10:42:59 I mainly ask since you cant copy&paste samba.config in the later case, so you have to "know" the names, which might be hard without a proper wiki yet? May 24 10:43:01 maybe just "globals"/"settings" and "share" May 24 10:43:26 yeah was thinking the same, yet this will break config compatibility May 24 10:43:43 maybe we should also change it for samba3/4 to just those names? May 24 10:43:56 that would probably make sense May 24 10:44:01 but i guess this will break a lot of configs, so i dont like it May 24 10:44:45 so i would have to add backwards compatibility in the init scripts.... May 24 10:44:46 hmm, yeah. Maybe just have the script accept both the old and new names May 24 10:45:10 or a firstboot script to fixup the old config to the new format May 24 10:45:20 assuming it easily maps May 24 10:45:44 mhh dont like firstboot scripts, i have seen so many users copy there /etc/configs from backups May 24 10:46:25 i think i can live with compatibility checks, so just loop over multiple section names May 24 10:46:26 andy2244: handle both section names, emit a deprecation warning for the old ones May 24 10:47:13 if the actual handling of the section options is moved into procedures, you could just invoke the procedure for different names/types without much code duplication May 24 10:47:17 ok that makes sense yes May 24 10:47:29 andy2244: I have started on poking at that problem, need to cleanup and submit (basically split firstboot into real firstboot stuff (mtd etc fixups) and config update/fixes; don't delete the latter, and run them everytime when using sysupgrade to restore configs) May 24 10:47:36 yes it already does for_each May 24 10:49:15 btw what does this do exactly? Seen this in samba3 init May 24 10:49:15 CONFIG_APPEND=1 UCI_CONFIG_DIR=/var/run/config config_load samba May 24 10:49:51 it loads /var/run/config/samba in addition to the already loaded /etc/config/samba May 24 10:50:15 this was added iirc to allow for auto-configuring samba shares from other packages May 24 10:50:20 mhh is this hotplug script related? May 24 10:50:30 without modifying the user-owned /etc/config/samba May 24 10:50:50 yeah, iirc there's some block-hotplug-auto-samba-share package somewhere May 24 10:51:20 ah oki so have to check this stuff, when i add hotplug to my packages May 24 11:34:59 ynezz: that dialout error is probably due to an outdated base-files or a config backup restore of /etc/groups not containing dialout May 24 11:35:17 (referring to #1773) May 24 11:38:01 we really need to come up with a way to fix that imo May 24 11:54:34 jow: yeah, could be, do you see any problem with the https://github.com/ynezz/openwrt-procd/commit/d0c29ae49f325cf76bd21954630948792d9a8708 ? May 24 13:37:31 what are downsides of compiling kernel with -O3 instead of -O2? May 24 13:39:25 possibly opening pandora box full of compiler surprises? :) May 24 13:51:53 is there a standard way for a regular package to enable certain kernel configuration options ? May 24 13:52:12 I am packaging some user-space library that needs specific kernel features enabled (which can't be built as a module) May 24 14:00:08 kos_tom: yes, you don't. Packages should not influence kernel configuration outside of depending on kmods (as far as select-depends with "+" go) May 24 14:01:33 if it's a kernel option defined in config/Config-kernel.in, you can use a @-dependency (which means the package is hidden until the kernel option is enabled) May 24 14:08:36 KanjiMonster: and how an option in config/Config-kernel.in "ensures" the corresponding option in the kernel configuration is enabled ? May 24 14:09:19 KanjiMonster: basically, I'm packaging the set of software components that are needed to enable SELinux on OpenWRT, and SELinux obviously cannot work without the kernel part of it May 24 14:09:58 kos_tom: the any option starting with KERNEL_ will be translated as an option (sans the KERNEL_) in the kernel config May 24 14:11:24 KanjiMonster: hm, ok. The thing is that CONFIG_SECURITY_SELINUX in the kernel has plenty of dependencies May 24 14:11:50 so having just CONFIG_KERNEL_SECURITY_SELINUX=y set CONFIG_SECURITY_SELINUX=y in the kernel config is not going to be sufficient May 24 14:13:03 why not? May 24 14:15:13 also you might notice that the config KERNEL_* options (partially) mirror the depedencies of the in-kernel options May 24 14:15:34 because when FOO=y, with FOO depends on BAR, but BAR is not enabled, then FOO is going to be disabled as well May 24 14:16:48 that means that both FOO and BAR need to be present in config/Config-kernel.in, with appropriate depends/selects May 24 14:17:15 Shouldn't it be set so that selecting FOO also "forces" BAR? May 24 14:17:36 exactly because depency May 24 14:19:43 that's what the depends and selects are for May 24 14:28:57 KanjiMonster: ok. In my case it's going to be quite a few kernel options that need to be replicate in config/Config-kernel.in :/ May 24 14:30:27 kos_tom: nothing new, look at the cgroups, lxc or namespaces stuff May 24 15:05:24 after enabling SELinux and related options in "make kernel_menuconfig", I get http://code.bulix.org/5ibc83-743009?raw when building the kernel May 24 15:05:37 isn't OpenWRT doing an olddefconfig automatically ? May 24 15:13:18 ynezz: ok, I googled and I see there are various opinions on -O3 May 24 15:13:38 ynezz: accoring to some old resources it may cause problems May 24 15:14:07 new opinions state that it should be safe - but may produce bigger/slower code May 24 15:56:32 ynezz: the patch looks fine May 24 15:56:50 rmilecki: yeah, should, but it probably all depends how well is this being tested, as the {build,test}bots are probably using the defaults May 24 19:20:33 why on earth is selecting 'lm-sensors' making perl build (and fail on macos) ? May 24 19:22:45 Because it is a dependency for lm-sensors-detect. Change +perl* to +PACKAGE_lm-sensors-detect:perl* and it won't build. May 24 19:23:20 I have no clue about the failure, though. May 24 19:25:22 must be macOS May 24 19:27:48 I think openwrt needs to admit defeat about saying it builds on macos - increasingly packages are failing. May 24 19:28:29 I would warn against monocultures May 24 19:29:37 it should be easy to fix, "just" add some otherOS based build bot May 24 19:29:37 It's a good idea to add that condition nonetheless. I'll open a PR to change it. May 24 19:33:19 I think maybe more needs the conditional stuff +perlbase-essential +perlbase-fcntl +perlbase-file +perlbase-xsloader May 24 19:33:25 but I don't know May 24 19:34:20 Yes, that's what I meant by the *. I should have writtten sed 's/+perl/+PACKAGE_lm-sensors-detect:perl/g' May 24 19:42:23 ldir: thanks for volunteering to do regular build testing and fixing issues on macos ;P May 24 19:46:55 I would be very happy to dedicate a mac mini that is currently sat doing very little May 24 19:48:08 it's not exactly super cpu mega build bot. May 24 19:48:10 how much free space does it have? IIRC a full build was something about half a terabyte (probably more nowadays) May 24 19:49:11 Has 1TB drive which is mostly empty - and I could always add an external drive. May 24 19:55:00 nice :) May 24 19:56:57 I assume the resulting IB/SDK only runs on macos? We recently had a powerpc buildbot producing such binaries, which weren't quite well received, especially as they replaced the x86 ones. We need to fix this first May 24 19:58:41 good point May 24 20:03:25 * EqUaTe also has a mac mini that does next to nothing, so could also run builds, but doesn't have the time to debug things tbh May 24 20:08:56 1TB disk 8GB ram sat doing **** all. Very happy for it to be sat there churning cpu. No idea how to set it up or probably debugging the problems it hits but the offer is there. May 24 20:31:54 cotequeiroz: I can confirm your idea for fixing works - builds on macos and runs on my apu :-) May 24 20:35:19 cotequeiroz: What I really meant to say was "thank you" May 24 20:40:54 You're welcome. I've opened the PR: https://github.com/openwrt/packages/pull/9064. Now jow needs to agree. May 25 00:48:07 ynezz: pong **** ENDING LOGGING AT Sat May 25 02:59:58 2019