**** BEGIN LOGGING AT Thu Feb 20 02:59:57 2020
Feb 20 07:55:00 <ynezz> anyone working on that pppd fix already?
Feb 20 08:04:25 <russell--> how soon do we expect 5.4 to hit master?
Feb 20 08:06:02 <ynezz> apparently a busy month for everybody :)
Feb 20 08:06:34 <ynezz> anyway, you can have the latest 5.4 stuff from xback's staging tree
Feb 20 08:06:51 <ynezz> so this is likely what is going to be pushed
Feb 20 08:15:08 <ynezz> stintel: BTW have you tested pppd with ALSR enabled?
Feb 20 08:27:13 <stintel> ynezz: I don't use ppp
Feb 20 08:29:01 <ynezz> ok, so it must have been someone else then, I barely remember some discussion about pppd and ASLR here
Feb 20 08:29:18 <ynezz> but already paged out the content :)
Feb 20 08:30:54 <ynezz> seems like some projects get the info sooner https://lists.debian.org/debian-lts-announce/2020/02/msg00005.html
Feb 20 08:31:20 <stintel> ynezz: well it is enabled in some of my builds, but it didn't compile with CONFIG_PKG_ASLR_PIE_ALL=y
Feb 20 08:31:35 <ynezz> ah, that was it
Feb 20 08:32:36 <stintel> and I asked here if it was OK to push PKG_ASLR_PIE:=0 to its makefile but that was nacked
Feb 20 08:35:48 <ynezz> ok, I'll at that ASLR build breakage then
Feb 20 08:35:55 <ynezz> s/at/look at/
Feb 20 09:09:59 <nitroshift> blogic, morning, sent the mvebu config-5.4 just now
Feb 20 09:54:48 <ynezz> stintel: PKG_ASLR_PIE_REGULAR:=1 in ppp builds fine here on imx6/master
Feb 20 09:59:30 <stintel> ynezz: don't recall on what target this was
Feb 20 10:03:50 <jow> ynezz: are there any other mitigations? like refusing certain auth methods?
Feb 20 10:35:52 <ynezz> jow: dunno
Feb 20 10:37:01 <ynezz> "significant impact due to the possiblity
Feb 20 10:37:02 <ynezz> of remote code execution prior to authentication"
Feb 20 10:37:33 <ynezz> rm -fr /sbin/ppp* ? :p
Feb 20 10:59:17 <ynezz> jow: BTW in that Debian SA it's "This issue is also mitigated by
Feb 20 10:59:18 <ynezz> Debian's hardening build flags."
Feb 20 11:06:08 <ynezz> `char rhostname[256];` stack allocated, so perhaps they meant `-fstack-protector-strong` ?
Feb 20 11:15:44 <aleksander_m> if two init.d services are scheduled to run at the same step (same START), which one goes first? based on the name of the file? or are they scheduled literally at the same time?
Feb 20 11:16:50 <karlp> 99% sure it's alphabetical file name,  the sSTART= just sets up the symlinks in rc.d
Feb 20 11:22:15 <aleksander_m> and, is it common to schedule services before the boot (START=10) one? I have one service that updates registers in the hardware, e.g. to repurpose several pins from JTAG to plain GPIOs. I'd like that to be run before any other gpio configuration that openwrt may do (e.g. config gpio_switch setups in /etc/config/system)
Feb 20 11:22:38 <aleksander_m> is it wise to setup that service as START=9?
Feb 20 11:23:25 <aleksander_m> START=09 I mean
Feb 20 11:24:23 <ynezz> jow: we're probably "safe" as Debian is, seems like -D_FORTIFY_SOURCE=1 mitigates the issue
Feb 20 11:24:42 <ynezz> jow: so it's "just" DoS *** buffer overflow detected ***: ./trivial terminated
Feb 20 11:25:05 <ynezz> jow: this was with -D_FORTIFY_SOURCE=1 -fno-stack-protector
Feb 20 11:26:14 <ynezz> jow: so perhaps the SA should be reworded
Feb 20 11:28:02 <ynezz> default PKG_FORTIFY_SOURCE_1
Feb 20 11:55:22 <russell--> we are missing ath79 support for the ar7240 version of the ubnt_bullet-m
Feb 20 12:07:20 <jow> aleksander_m: common not but perfectly acceptable. Be sure to zero-pad the number (START=09)
Feb 20 12:07:51 <jow> /e/i/boot is at START=10 for exactly that reason, that its possible the schedule other things before
Feb 20 12:08:38 <ynezz> (puting aside, that this GPIO fiddling belongs to DTS)
Feb 20 12:21:03 * blogic opens his 2 new m920s machines
Feb 20 12:21:13 <blogic> muhahah
Feb 20 12:21:25 <blogic> some serious cpu power on my desk now
Feb 20 12:21:46 <blogic> and amazingly, 2 minutes after ups dropped them of, dhl rang the doorbell with the 10gb mellanox cards
Feb 20 12:21:49 <blogic> :-D
Feb 20 12:22:01 <blogic> now I am just waiting for the ax200 cards to arrive
Feb 20 12:22:29 <blogic> and amazingly the machines came with m2 ssd and 2,5"ssd
Feb 20 12:22:49 <blogic> lets hope linux comes up without too much hassle
Feb 20 12:25:19 <stintel> hah I have just confirmed my order for a 10gig PoE switch and AX AP with 10gig PoE-PD uplink
Feb 20 12:28:57 <ynezz> monsters
Feb 20 12:29:53 <stintel> so I might decide to order 2 of those macchiatobin's soon, too
Feb 20 12:30:26 <stintel> I should be good for a few years then :P
Feb 20 12:34:38 <pkgadd> ax200 is a bit picky, but overall it's working quite well
Feb 20 13:50:35 <mamarley> blogic: I don't have an 802.11ax WAP, but I can confirm that the Intel AX200 card is working well for me with Linux.  You will need to be using a fairly recent kernel though.  I'm not sure when support was added, but it was sometime in 5.x.
Feb 20 14:02:51 <pkgadd> v5.1, but the firmware blob and the used PCIe are more picky
Feb 20 14:17:47 <guifipedro[m]> hey! compiling openwrt 19.07.1 for architecture octeon says "Package rssileds is missing dependencies for the following libraries: libnl-tiny.so"
Feb 20 14:18:09 <guifipedro[m]> `CONFIG_TARGET_octeon=y`
Feb 20 14:18:16 <adrianschmutzler> make clean?
Feb 20 14:18:38 <guifipedro[m]> aha, good point, let's try a compilation from scratch
Feb 20 14:18:52 <guifipedro[m]> (thanks!)
Feb 20 15:09:24 <guifipedro[m]> adrianschmutzler: did clean compilation from scratch (including git clone), same error
Feb 20 15:10:27 <karlp> do you have both libnl and libnl-tiny eabled or anything?
Feb 20 15:10:33 <karlp> it might be a wonky | depends
Feb 20 15:25:08 <guifipedro[m]> I'm in a debian 10 stable
Feb 20 15:25:25 <guifipedro[m]> uops, it's not installed
Feb 20 15:25:30 <karlp> no, not in your host,
Feb 20 15:25:33 <guifipedro[m]> libnl-3-dev ?
Feb 20 15:25:42 <karlp> not on the host, in the openwrt packages.
Feb 20 15:26:12 <guifipedro[m]> let me show you:
Feb 20 15:26:38 <guifipedro[m]> this is available packages and installed_packages to .config: http://paste.debian.net/1131257/
Feb 20 15:28:35 <karlp> that's something completely private and not the openwrt buildroot tooling...
Feb 20 15:28:58 <karlp> in make menuconfig, what's actually been done?
Feb 20 15:29:02 <guifipedro[m]> no, it's not private, it's here: gitlab.com/guifi-exo/temba
Feb 20 15:29:06 <karlp> what's ./scripts/diffconfig show
Feb 20 15:29:16 <karlp> we're not supporting some third party builder software....
Feb 20 15:29:28 <guifipedro[m]> https://gitlab.com/guifi-exo/temba/-/blob/master/imagebuilder.sh#L49-67
Feb 20 15:29:44 <guifipedro[m]> no worries, I maintain it, and it's an easy tool
Feb 20 15:30:00 <karlp> easy for you.
Feb 20 15:30:59 <guifipedro[m]> I mean, it does few things, I write directly the .config (to have it in a noninteractive way)
Feb 20 15:31:37 <guifipedro[m]> we can focus on openwrt itself
Feb 20 15:32:04 <guifipedro[m]> you want the .config that produces this compilation problem?
Feb 20 15:32:08 <karlp> like I said, so do you have both libnl and libnl-tiny or anythign like that?
Feb 20 15:32:36 <karlp> but things like diffconfig and menuconfig to see what you _actually_ have, in addition to what you asked for and set explicitly is what you want to look at.
Feb 20 15:32:43 <karlp> is rssileds still maintained?
Feb 20 15:32:50 <karlp> isn't that largely superseded these days anyway?
Feb 20 15:33:01 <guifipedro[m]> I installed it because I needed in the past
Feb 20 15:33:06 <guifipedro[m]> 18.x
Feb 20 15:33:13 <guifipedro[m]> so maybe is no longer needed?
Feb 20 15:33:44 <adrianschmutzler> karlp: It is still used
Feb 20 15:33:48 <guifipedro[m]> (nice tool the `scripts/diffconfig.sh` !! thanks)
Feb 20 15:34:03 <adrianschmutzler> one commit in 2019, next in in 2017 for the package, though ...
Feb 20 15:34:25 <karlp> where is the package?
Feb 20 15:34:33 <adrianschmutzler> https://github.com/openwrt/openwrt/commits/master/package/network/utils/rssileds/Makefile
Feb 20 15:34:41 <guifipedro[m]> diffconfig: http://paste.debian.net/1131258/
Feb 20 15:34:41 <karlp> oh, it's in core?
Feb 20 15:34:58 <adrianschmutzler> it's added via DEVICE_PACKAGES
Feb 20 15:35:11 <adrianschmutzler> e.g. most of the ath79 ubnt XM/XW devices have it
Feb 20 15:35:11 <guifipedro[m]> karlp: as you see in my bash arrays http://paste.debian.net/1131257/ rssileds was required by tplink_cpe510-v3
Feb 20 15:35:19 <karlp> well, it has a target-ld flags with -lnl-tiny explicitly,
Feb 20 15:35:36 <karlp> so it looks like it's been broken for... as long as it's been since we added deps tracking?
Feb 20 15:35:49 <adrianschmutzler> I built master for cpe210-v2 with rssileds yesterday, so that's supposed to work
Feb 20 15:35:49 <karlp> so odd that it hasn't been reported elsewhere before?
Feb 20 15:35:53 <guifipedro[m]> I don't know why, maybe because I directly write the .config, I don't get all the dependencies, so I add them manually.
Feb 20 15:36:08 <karlp> are you calling "make defconfig" after you make your .config stub?
Feb 20 15:36:22 <karlp> that's the only supported way of expanding a stub file afair
Feb 20 15:36:43 <guifipedro[m]> yes: https://gitlab.com/guifi-exo/temba/-/blob/master/imagebuilder.sh#L170
Feb 20 15:38:00 <adrianschmutzler> but weren't you refering to octeon before, how's that related to the cpe510-v3?
Feb 20 15:38:26 <adrianschmutzler> Do you add rssileds by hand?
Feb 20 15:38:37 <karlp> adrianschmutzler: is libnl-tiny always built in? there's no DEPENDS in the package definition, so it shouldn't be working for you either
Feb 20 15:38:54 <karlp> (nor libuci nor libubox....
Feb 20 15:39:14 <adrianschmutzler> karlp: I suppose something else pulls it, otherwise the buildbot would fail as well
Feb 20 15:39:36 <karlp> that's not how the dependency tracking is meant to be working afaik, you're meant be _required_ to explicitly list them.
Feb 20 15:39:44 <karlp> that was the whole point.
Feb 20 15:39:58 <guifipedro[m]> so, one day I compiled cpe510-v3 and needed rssileds (it is also needed by alix), so I install it always. then other day another one and so on. so today I'm trying for the first time 19.x, and with a new arch (octeon) for edgerouter lite
Feb 20 15:40:40 <guifipedro[m]> I think I had this issue before when trying 19.x, but It was RC, so I said, let's try when it's stable, now this is 19.x.1
Feb 20 15:40:55 <adrianschmutzler> guifipedro: well, that would at least explain your problem with octeon. You are not supposed to always add rssileds, it should be pulled by DEVICES_PACKAGES
Feb 20 15:41:13 <karlp> it shouldn't _break_ if you choose it yourself though, nothing should
Feb 20 15:41:20 <adrianschmutzler> you have to have ROOTFS_PER_TARGET enabled though (or how it's called)
Feb 20 15:41:30 <adrianschmutzler> karlp: yes, of course
Feb 20 15:41:39 <guifipedro[m]> I did not know that adding extra package from openwrt can break compilations
Feb 20 15:41:43 <karlp> it shouldn't
Feb 20 15:42:15 <adrianschmutzler> well, it's easy to check, I'll give it a try
Feb 20 15:42:35 <guifipedro[m]> ok, I will comment rssileds and try again my compilation
Feb 20 15:43:14 <adrianschmutzler> karlp: rssileds has depend on libiwinfo, and libiwinfo has +PACKAGE_kmod-cfg80211:libnl-tiny
Feb 20 15:43:36 <guifipedro[m]> so I learn things from imagebuilder and openwrt compilation and I work on my script to make it work. of course, I do best effort. sorry :)
Feb 20 15:45:08 <guifipedro[m]> adrianschmutzler:  what ROOTFS_PER_TARGET? http://paste.debian.net/1131263/
Feb 20 15:45:27 <adrianschmutzler> TARGET_PER_DEVICE_ROOTFS
Feb 20 15:45:53 <guifipedro[m]> adrianschmutzler: yes, in general looks like the dependencies are from their devices, but sometimes that does not work. maybe it's because the dependencies are not correctly set (?) I don't know
Feb 20 15:45:56 <adrianschmutzler> if you don't have that, all target-specific packages are ignored IIRC
Feb 20 15:46:12 <guifipedro[m]> wo!
Feb 20 15:46:28 <adrianschmutzler> dependencies from devices only work if you have TARGET_PER_DEVICE_ROOTFS set
Feb 20 15:46:53 <guifipedro[m]> but look at that, it does not appear as "non set" hmmmm
Feb 20 15:46:54 <guifipedro[m]> really interesting
Feb 20 15:46:57 <guifipedro[m]> then maybe I can quit that strange options, right?
Feb 20 15:46:57 <guifipedro[m]> TARGET_PER_DEVICE_ROOTFS=y ?
Feb 20 15:47:05 <adrianschmutzler> because otherwise you are not building "per device", so it does not make sense to include device packages
Feb 20 15:47:30 <guifipedro[m]> googling TARGET_PER_DEVICE_ROOTFS looks like it's not very documented, right?
Feb 20 15:48:01 <adrianschmutzler> did you try on octeon or octeon-tx?
Feb 20 15:48:08 <guifipedro[m]> octeon
Feb 20 15:48:29 <guifipedro[m]> first, I used the openwrt compiled image opteon, and it works, then I'm compiling myself
Feb 20 15:48:54 <guifipedro[m]> so what I really want is image builder, but that forces me to do silly compilations, that's why I do: https://gitlab.com/guifi-exo/temba/-/blob/master/imagebuilder.sh#L108-113
Feb 20 15:49:04 <guifipedro[m]> but sometimes, I can do https://gitlab.com/guifi-exo/temba/-/blob/master/imagebuilder.sh#L133-136
Feb 20 15:49:10 <adrianschmutzler> I do not have any experience with image builder
Feb 20 15:49:38 <adrianschmutzler> but for normal build it is always a good idea to start from the setup the buildbots use for snapshots
Feb 20 15:49:58 <guifipedro[m]> imagebuilder basically is enabling it this way https://gitlab.com/guifi-exo/temba/-/blob/master/imagebuilder.sh#L162-164
Feb 20 15:50:15 <guifipedro[m]> (to compile entirely localhost)
Feb 20 15:50:24 <adrianschmutzler> and you should care about diffconfig and stuff, as that's what you actually need to create/verify a valid config for standard build
Feb 20 15:50:36 <guifipedro[m]> I don't get what is "buildbots use for snapshots"
Feb 20 15:51:05 <adrianschmutzler> https://downloads.openwrt.org/snapshots/targets/octeon/generic/
Feb 20 15:51:21 <adrianschmutzler> the config.buildinfo will contain the setup used for compiling these images
Feb 20 15:51:24 <karlp> imagebuilder _should_ work, and if people can't be using image builder, we need to fix it.
Feb 20 15:51:42 <karlp> (the buildbots were using the image builder to ensure this worked at someoitn right?)
Feb 20 15:51:46 <adrianschmutzler> and config.buildinfo in your build directory will tell you what _you_ used
Feb 20 15:52:09 <adrianschmutzler> the build bots are just compiling as you would do with "make menuconfig"
Feb 20 15:52:25 <adrianschmutzler> (... to create the config)
Feb 20 15:52:51 <karlp> adrianschmutzler: given that rssileds seems to have a _direct_ dependency on libnl-tiny (from it's TARGET_LD_FALGS) I would expect that it should be required to have the dependency itself not inherited from libiwinfo
Feb 20 15:52:51 <guifipedro[m]> what diffs diffconfig? diff between my .config and...?
Feb 20 15:52:57 <adrianschmutzler> technically, you can just copy the config.buildinfo, rename it to .config, run make and might get images
Feb 20 15:53:00 <karlp> the target default.
Feb 20 15:53:20 <adrianschmutzler> https://openwrt.org/docs/guide-developer/build-system/use-buildsystem
Feb 20 15:53:23 <guifipedro[m]> aha
Feb 20 15:53:30 <adrianschmutzler> that link is what you need
Feb 20 15:54:43 <guifipedro[m]> thanks
Feb 20 15:59:23 <guifipedro[m]> next time, I will uncomment all this rare dependencies I add before asking for help :)
Feb 20 15:59:26 <guifipedro[m]> by the way `.config:35:warning: unexpected data: TARGET_PER_DEVICE_ROOTFS=y`
Feb 20 15:59:50 <adrianschmutzler> need "CONFIG_" prefix?
Feb 20 16:00:06 <adrianschmutzler> just have a look at the config.buildinfo, you can just copy it from there
Feb 20 16:00:07 <guifipedro[m]> ups :)
Feb 20 16:00:19 <adrianschmutzler> which is btw the default config
Feb 20 16:00:38 <adrianschmutzler> err, no, it isn't
Feb 20 16:01:10 <adrianschmutzler> it's default if you choose buildbot settings, which you don't want, as it will build all packages
Feb 20 16:01:26 <guifipedro[m]> yea, I don't want to build all packages :)
Feb 20 16:02:42 <guifipedro[m]> all targets*
Feb 20 16:03:48 <adrianschmutzler> well, if you look at the config.buildinfo, you will see that only one target is selected.
Feb 20 16:04:16 <adrianschmutzler> and I do not think you can build more than one target with a single config?
Feb 20 16:05:12 <guifipedro[m]> well, with one build of a ar71xx I can build similar devices, yea
Feb 20 16:05:46 <adrianschmutzler> target!=device
Feb 20 16:06:12 <guifipedro[m]> I'm not finding config.buildinfo
Feb 20 16:06:38 <guifipedro[m]> I think it was compile all targets in make menuconfig, right?
Feb 20 16:07:49 <guifipedro[m]> config.buildinfo es generated after my compilation succeeded?
Feb 20 16:20:33 <jow> if netlink calls that used to work in the past return -7 (NLE_INVAL) now, is that related to the new netlink nested attribute policy stuff in the kernel?
Feb 20 16:32:58 <guifipedro[m]> yeah, compilation succesful quitting that strange packages
Feb 20 16:33:10 <guifipedro[m]> great support! thanks
Feb 20 16:50:26 <guifipedro[m]> hey, in octeon compilation, results are directories? or is because something went bad? linux-octeon  root-octeon
Feb 20 16:51:00 <adrianschmutzler> if you want to see the results, again just have a look at what the buildbot does for the snapshots
Feb 20 16:52:32 <guifipedro[m]> adrianschmutzler: this is a URL? can you link it?
Feb 20 17:02:22 <adrianschmutzler> just what I linked above
Feb 20 17:02:37 <adrianschmutzler> https://downloads.openwrt.org/snapshots/targets/octeon/generic/
Feb 20 17:05:15 <adrianschmutzler> karlp: indeed, if you manually select rssileds on octeon, it will fail with the error reported above
Feb 20 17:10:56 <adrianschmutzler> if will build with manually selecting cfg80211 as well
Feb 20 17:11:34 <karlp> fail you mean?
Feb 20 17:11:45 <adrianschmutzler> standard -> working
Feb 20 17:11:51 <adrianschmutzler> standard + rssileds -> fail
Feb 20 17:12:01 <adrianschmutzler> standard + rssileds + cfg80211 -> working
Feb 20 17:12:24 <adrianschmutzler> all on octeon
Feb 20 17:15:14 <adrianschmutzler> ah, and on ath79 if I select to build rootfs per device then kmod-cfg80211 gets marked as "M"
Feb 20 17:17:07 <adrianschmutzler> most probably because ath79 has swconfig in DEFAULT_PACKAGES, and that will have libnl-tiny selected ...
Feb 20 17:17:57 <adrianschmutzler> So, if somebody cares for that corner case, one should either limit rssileds to certain targets or sort out the dependencies ...
Feb 20 17:18:53 <adrianschmutzler> grep tells that rssileds is used on ar71xx/ath79/ramips only ...
Feb 20 17:28:19 <karlp> I sitll think that if it's directly depending on libnl-tiny, it shoudl be listed expclitily.
Feb 20 17:28:57 <adrianschmutzler> karlp: That's what I'm just trying to build, just added +libnl-tiny and build "octeon + rssileds"
Feb 20 17:29:25 <karlp> in other news, is anyone having problems with umdns?  in 1907 I get no nearby hosts, and /etc/init.d/umdns restart I get "command failed: invalid argument" which is from the ubus set_config call failing, but I don't know why.
Feb 20 17:33:21 <karlp> looks like I have two points on the 1907 branch wher eit stops working, so I guess tomorrow is bisection day :)
Feb 20 17:33:58 <adrianschmutzler> can't help you there
Feb 20 17:34:51 <adrianschmutzler> do you want a suggested-by on my libnl-tiny one-liner patch? :-)
Feb 20 17:35:28 <guifipedro[m]> adrianschmutzler: thanks for your research; and sorry, yes, found it. working under pressure makes everything more difficult
Feb 20 17:35:31 <karlp> not in the least.
Feb 20 17:35:37 <karlp> but thanks for offering I guess :)
Feb 20 17:36:38 <adrianschmutzler> that's what I thought :-)
Feb 20 17:38:32 <karlp> (it shoudl really have depends for _all_ of it's direct deps IMO, so everything listed in it's target ld_flags...)
Feb 20 17:39:06 <karlp> building without libuci and libubus being selected would be challenging, sure, but... well, they're direct dependencies!
Feb 20 17:39:33 <adrianschmutzler> TARGET_LDFLAGS += -liwinfo -luci -lubox -lnl-tiny
Feb 20 17:39:41 <adrianschmutzler> so you would say:
Feb 20 17:40:01 <adrianschmutzler> DEPENDS:=+libiwinfo +libnl-tiny +libubox +libuci
Feb 20 17:40:03 <adrianschmutzler> ?
Feb 20 18:20:49 <jow> karlp: yes, the umdns failure seems to be related to an libubox issue
Feb 20 18:20:56 <jow> karlp: there's an open ticket about it iirc
Feb 20 18:24:41 <jow> karlp: https://bugs.openwrt.org/index.php?do=details&task_id=2833
Feb 20 20:18:33 <karlp> ok, neat, that saves me some work tomorrow :) I only found one very niche mdns bug outstanding :)
Feb 20 20:45:22 <karlp> is there anything that patch needs? it's a regression in 1907.
Feb 20 20:53:20 <jow> meh... just spent an hour debugging FS#2841... only to figure out that the config is wrong to begin with
Feb 20 20:53:30 <jow> (and that netifd's error handling sucks)
Feb 20 20:53:49 <jow> I mean can't it at least print a line to stderr if a netlink call fails?
Feb 20 20:55:38 <mamarley> No, that would make figuring out the problem too easy.
Feb 20 20:59:13 <jow> at least I learned howto turn the netlink messages shown by strace into neat structured dumps
**** ENDING LOGGING AT Fri Feb 21 02:59:57 2020