**** BEGIN LOGGING AT Mon Oct 05 02:59:57 2020
Oct 05 04:24:41 <mangix> aparcar[m]: if you're interested in building SDKs, https://github.com/openwrt/packages/issues/13554
Oct 05 05:23:52 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (0% images and 100.0% packages reproducible in our current test framework.)
Oct 05 08:57:23 <Borromini> svanheule[m]: someone's taking care of the Aircube :D https://github.com/openwrt/openwrt/pull/3482
Oct 05 11:29:20 <svanheule[m]> Borromini: Now all you need to do is find some money to buy one :P
Oct 05 11:34:33 <Borromini> i'm not sure if i will with only 64 MB of RAM :(
Oct 05 11:35:25 <ynezz> Hauke: clang-7, seriously? :)
Oct 05 11:36:42 <svanheule[m]> Borromini: 64MB might be on the low side to be future proof...
Oct 05 11:36:42 <ynezz> Hauke: CI was using clang-9, I've switched it to clang-10 yesterday so I'm trying to use the same version as on CI, don't wasting time to make it all version compatible
Oct 05 11:37:20 <Borromini> svanheule[m]: yeah.
Oct 05 12:27:24 <nick[m]2> why canI just see the circleci output without logging in into circleci? Is this a special feature or just some option somewhere?
Oct 05 13:01:25 <jow> ynezz: just looked at your uci patch series
Oct 05 13:01:59 <jow> ynezz: I think the fix 6/6 could be more elegant, allocating a 4KB stackspace buffer just for formattinga tempfile name does not seem dieal
Oct 05 13:02:08 <jow> *ideal
Oct 05 13:07:29 <jow> nevermind, it already is pushed :/
Oct 05 13:14:51 <olmari> Oh well, there can always be next one ;P
Oct 05 13:17:10 <olmari> BTW, I noticed defining /root/.ssh/ in sysupgrade keep files, files in the folder kept permission, but .ssh folder itself did not..
Oct 05 13:17:34 <olmari> After flash ai mean
Oct 05 13:31:08 <ynezz> jow: what do you suggest instead? I've used the same value which was found in some header file
Oct 05 13:32:11 <ynezz> jow: I'm usually using 256, but then being pesked, that it's too small :)
Oct 05 13:32:43 <ynezz> jow: feel free to correct that, I'm waiting for Hauke's fixes and then bump the uci package in the repo
Oct 05 13:36:49 <jow> ynezz: I probably would have attempted to free() in the error paths
Oct 05 13:37:05 <jow> ynezz: but the nested setjmp() / longjmp() logic is hard to follow
Oct 05 13:37:11 <ynezz> is that even possible?
Oct 05 13:37:29 <jow> could be that it is is not due to longjmp()
Oct 05 13:37:54 <jow> possible alternatives would be: 1) alloca()
Oct 05 13:38:17 <jow> 2) store the tempfile in a field of the uci state, and free it when freeing the cursor
Oct 05 13:39:09 <ynezz> ah, alloca!
Oct 05 13:39:59 <ynezz> speaking of memory, uci_getln would need some love as well, I've seen it allocating 130kB with 43B uci file
Oct 05 13:40:58 <ynezz> as it's always using double of previous allocated value
Oct 05 13:41:11 <jow> ynezz: http://sprunge.us/i9uKHw
Oct 05 13:41:53 <jow> I probably forgot some free(filename), which needs to be removed as well
Oct 05 13:42:09 <ynezz> gotta go now, later or never, sorry :)
Oct 05 13:42:42 <jow> http://sprunge.us/MbP8OW
Oct 05 13:42:54 <jow> bye
Oct 05 14:01:54 <barhom_> I'm fighting a little bit with running multiple dnsmasq. I'm trying to achieve an additional DNSMASQ running DNS forwarded (only) on port 54 (instead of 53) with no DHCP server running. Both are on the LAN zone.
Oct 05 14:04:24 <barhom_> https://0bin.net/paste/c-HlRll3#OO6nToLduB-7aGkUZhWALxqdR50mVWPFPVQFd/obePX < example
Oct 05 14:10:02 <olmari> barhom_: what are you actually wanting to achieve? (so we'll be sure second dnsmasq is even needed)
Oct 05 14:10:47 <barhom_> olmari, I'd like to keep the standard DHCP server being offered together with the standard dns forwarder running on port 53. This already works.
Oct 05 14:10:56 <barhom_> On top of that, Id like another dns forwarded on port 54
Oct 05 14:11:17 <jow> barhom_: you need to name your "config dnsmasq" sections, then add "option instance name" to all DHCP related sections
Oct 05 14:11:17 <barhom_> That other dns forwarder will use a specific list of servers (not read from /etc/resolv)
Oct 05 14:11:54 <jow> barhom_: so e.g. "config dnsmasq instance1; ...; config dnsmasq instance2; ...; config dhcp; option instance instance1; ...
Oct 05 14:12:14 <barhom_> jow, makes a lot of sense. I'll try that now.
Oct 05 14:14:42 <barhom_> jow, perfect it works! Thanks
Oct 05 14:26:01 <pmelange_> hey everyone, I have been having problems with the bug described here (https://bugs.openwrt.org/index.php?do=details&task_id=3354) and after bisecting came to the conclusion that commit 7081b1704e978414cf8e9ea10bf77be9787aa338 is to blame.  Could maybe someone with more experience take a look at this?
Oct 05 15:47:33 <PaulFertser> pmelange_: if it's caused by a memory corruption that commit might be totally unrelated.
Oct 05 15:51:58 <pmelange_> But I built the snapshot with the associated patch removed and had no problem.  I have been looking around for a case where the return value of napi_complete is checked, and I haven't found any.
Oct 05 16:11:14 <pmelange_> https://elixir.free-electrons.com/linux/v5.4.69/C/ident/napi_complete
Oct 05 16:44:36 <grift> made quite a bit of progress on luci today, learned quite a bit about its inner workings so far
Oct 05 18:09:32 <grift> dangole: just CONFIG_UBIFS_FS_SECURITY=y does not seem to be  enough to enable labeling for ubifs and it seems that CONFIG_UBIFS_FS_XATTR=y has to be set as well
Oct 05 18:24:56 <Hauke> dangole: is there a reason we do not set CONFIG_UBIFS_FS_XATTR=y, but we set CONFIG_JFFS2_FS_XATTR=y ?
Oct 05 18:25:30 <Hauke> overlayfs would like to use some of these attributes, but I think we do not use these overlayfs features anyway.
Oct 05 18:26:05 <Hauke> ynezz: I applied your patch in the wrong way, with the changes from master it work
Oct 05 18:28:58 <grift> we require CONFIG_UBIFS_FS_XATTR=y for selinux labeling support atleast, without it ubifs cannot be mounted when selinux is on with a policy that enabled labeling support, and openwrt will fall back to ramoveraly
Oct 05 18:29:36 <damex> hi, does octeon target actually support device tree? i have edgerouter 4 and plan to make it run openwrt. seems like octeon ethernet driver is dropped from upstream due to code quality though.
Oct 05 19:16:07 <dangole> Hauke, grift: I guess enabling CONFIG_UBIFS_FS_XATTR was simply forgotten, I'll add it now (and remove it from target/linux/*/config as it seems to have slipped in from kernel defconfig into some targets)
Oct 05 19:19:23 <dangole> Hauke, grift: ok, it's more of a mess than I thought. *_FS_XATTR as well as *_FS_SECURITY are quite arbitrarily enabled or disabled on a bunch of targets...
Oct 05 19:21:48 <grift> dangole: i had to enable it manually on ipq4XX/generic
Oct 05 19:22:45 <grift> s/ipq4XX/ipq40XX/
Oct 05 19:22:48 <dangole> grift: total of 46 mentions of *_FS_SECURITY and 52 mentions of *_FS_XATTR in target/linux/* ... not exactly clean at all
Oct 05 19:28:18 <dangole> hm, as random as arch/*/configs/*_defconfig in the kernel, also there those features are enabled/disabled/unmentioned randomly
Oct 05 19:28:48 <dangole> and I guess in many cases this is where OpenWrt target/linux/*/config came from
Oct 05 19:29:54 <dangole> so, I guess what we should do is: enable all of *_FS_XATTR in target/linux/generic and enable *_FS_SECURITY only on SELinux-enabled systems.
Oct 05 19:30:41 <jow> dangole: if the storage size footprint is not too large I'd also say that we should unconditionally enable xattr
Oct 05 19:30:43 <dangole> or have them all disabled by default and only enable on SELinux-enabled builds, but Hauke mentioned that overlayfs uses xattr (afaik for whiteouts)
Oct 05 19:30:53 <grift> cant you just enable CONFIG_UBIFS_FS_XATTR on selinux enabled systems? seems least itusive to me?
Oct 05 19:30:54 <jow> afair we require it anyway actually for whiteouts and stuff
Oct 05 19:32:47 <dangole> as JFFS2_FS_XATTR seems to be enabled already even on SMALL_FLASH targets, I doubt that SQUASHFS_FS_XATTR would add more than a few hundred bytes. all other filesystems are built as module anyway and hence it won't hurt much.
Oct 05 19:33:04 <dangole> (on targets with limited amount of NOR flash, ie. using SQUASHFS+JFFS2)
Oct 05 19:33:58 <jow> is squashfs xattr even making sense? Is mksquashfs supporting it?
Oct 05 19:36:27 <jow> apparently it does, nvm
Oct 05 19:42:19 <grift> i wish someone would look into modernizing the selinux code in busybox (if i were competent enough i would do it but i am not)
Oct 05 19:42:36 <grift> it caries a lot of legacy with a lot of drawbacks
Oct 05 19:43:26 <grift> sooner or later some of the deprecated code used in busybox is likely to be removed from upstream
Oct 05 20:02:50 <dangole> jow: we could enable SQUASHFS_FS_XATTR only on SELinux-enabled-builds where we will need it for SQUASHFS_FS_SECURITY. i also don't see any other good use for SQUASHFS_FS_SECURITY
Oct 05 20:37:36 <Hauke> DonkeyHotei: jow: what are whiteouts in overlayfs?
Oct 05 20:38:06 <Hauke> DonkeyHotei: wanted to ask dangole
Oct 05 20:39:12 <Hauke> found it https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt
Oct 05 20:39:40 <Hauke> as we have JFFS2_FS_XATTR already enabled, I would enable all *_FS_XATTR by default
Oct 05 20:39:57 <Hauke> this should not need much extra space
Oct 05 21:11:21 <jow> Hauke: yeah, thinking the same
Oct 05 21:12:31 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)
Oct 05 21:24:23 <Hauke> jow: I would like to reproduce this problem: https://bugs.openwrt.org/index.php?do=details&task_id=3284
Oct 05 21:38:55 <zorun> Hauke: hi, are you trying to reproduce it on 18.06?
Oct 05 21:50:04 <aparcar[m]> zorun: I think you misunderstood my imagebuilder signature commit message. The local folder packages/ is user modifiable and therefore can't be "pre signed" on buildbots
Oct 05 21:51:27 <aparcar[m]> Hauke: if we enable fs_xattr for all, do you mind I enable it for tools/tar as well?
Oct 05 21:52:34 <zorun> aparcar[m]: it only contains kernel modules, that doesn't sound like something the imagebuilder user would change
Oct 05 21:53:07 <aparcar[m]> zorun: but I can insert my own packages
Oct 05 21:53:14 <aparcar[m]> e.g. if I'm a freifunk distributor
Oct 05 21:53:34 <aparcar[m]> sure I could also add a remote feed to repositories.conf
Oct 05 21:53:49 <aparcar[m]> I'm just pointing out that this is currently a "feature"
Oct 05 21:53:53 <zorun> hmm, true
Oct 05 21:54:13 <zorun> but your solution is basically "sign something then verify it"
Oct 05 21:54:19 <zorun> it seems pointless
Oct 05 21:54:28 <aparcar[m]> Ideally we fix opkg so that it finally uses the kmod feeds and make the packages folder obsolete
Oct 05 21:55:01 <Hauke> zorun: yes I try to do trigegr this on 19.07 and 18.06
Oct 05 21:55:11 <Hauke> I am not so familiar with the firewall configuration
Oct 05 21:55:37 <aparcar[m]> you can't tell opkg (withouth by plan B patches) to trust these, bot not those feeds. So either patch opkg or sign and verify
Oct 05 22:02:13 <aparcar[m]> Hauke: how do I add a new kernel option to generic? just adding it there and then remove it on all other targets where it's already defined?
Oct 05 22:02:43 <zorun> aparcar[m]: what about disabling signature check for local (file) repo? I don't remember why it was ruled out
Oct 05 22:03:24 <zorun> aparcar[m]: can you make a summary of all the possible approaches and their pro/con? it would be clearer than patches that don't contain the background
Oct 05 22:03:33 <zorun> like a wiki page or a simple email
Oct 05 22:04:39 <zorun> Hauke: ok, I half-reproduced it on 18.06: the first ubus call produces the same result as in the bug report, but the second one doesn't add any rule
Oct 05 22:06:55 <Hauke> aparcar[m]: yes for the generic kernel config you have to do it manually
Oct 05 22:07:15 <aparcar[m]> Hauke: to whatever is in generic is inherited to all others?
Oct 05 22:07:47 <Hauke> aparcar[m]: you can fix the ordering of the file like this:
Oct 05 22:07:50 <Hauke> ./scripts/kconfig.pl '+' target/linux/generic/config-4.19 /dev/null > target/linux/generic/config-4.19-new
Oct 05 22:08:00 <Hauke> aparcar[m]: yes it is inherited
Oct 05 22:08:07 <aparcar[m]> great thank you
Oct 05 22:08:11 <aparcar[m]> zorun: I'll write something up
Oct 05 22:08:51 <Hauke> zorun: for me the first one did not produce a postrouting iptables rule
Oct 05 22:09:43 <zorun> aparcar[m]: thanks
Oct 05 22:17:07 <aparcar[m]> Hauke: maybe I'm not actually qualified to do this kernel stuff. CONFIG_F2FS_FS=y is not enabled per default, so setting CONFIG_F2FS_FS_XATTR=y in generic would enabled it everywhere and likely increase things, no?
Oct 05 22:18:15 <Hauke> aparcar[m]: no it would not enable it everywhere, it only enables options which are selectable
Oct 05 22:18:34 <Hauke> CONFIG_F2FS_FS_XATTR=y will only be set if something else set CONFIG_F2FS_FS=y
Oct 05 22:18:59 <Hauke> if a kmod package sets CONFIG_F2FS_FS=m also CONFIG_F2FS_FS_XATTR=y will be set
Oct 05 22:19:14 <aparcar[m]> amazing
Oct 05 22:19:15 <aparcar[m]> thanks
Oct 05 22:19:37 <Hauke> it just concatinates the configuration files and then runs oldconfig
Oct 05 22:20:29 <Hauke> zorun: I will look into this tomorrow
Oct 05 22:20:45 <Hauke> ynezz: if you are fine with my patches feel free to apply them to master
Oct 05 22:24:14 <zorun> Hauke: thanks, I'm trying to find a simpler example but I have a hard time understanding where this data is parsed
Oct 05 22:26:13 <zorun> ok, it's processed by fw3_ubus_rules_add()
Oct 05 22:37:10 <zorun> I'm giving up for now
Oct 06 00:22:30 <philipp64|work> How is the SHA created for a kernel package build?  I rebuilt and it changed and I’m not sure why.
Oct 06 00:23:55 <philipp64|work> Would changing the .config change the hash?
Oct 06 00:25:46 <philipp64|work> I wanted to build a couple of additional modules, but now when I go to install them it’s telling me I need to reinstall everything kernel related. sigh.
Oct 06 01:01:09 <aparcar[m]> philipp64|work: look for kernel magic
Oct 06 02:27:09 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_ar71xx.html has been updated. (99.1% images and 100.0% packages reproducible in our current test framework.)
**** ENDING LOGGING AT Tue Oct 06 02:59:56 2020