**** BEGIN LOGGING AT Sun Dec 06 02:59:56 2020
Dec 06 03:00:56 <ByteEnable> I will grep it out and see .
Dec 06 03:05:11 <ByteEnable> obj-$(CONFIG_ARMADA_370_CLK)    += armada-370.o
Dec 06 03:05:11 <ByteEnable> obj-$(CONFIG_ARMADA_375_CLK)    += armada-375.o
Dec 06 03:05:12 <ByteEnable> obj-$(CONFIG_ARMADA_38X_CLK)    += armada-38x.o
Dec 06 03:05:12 <ByteEnable> obj-$(CONFIG_ARMADA_39X_CLK)    += armada-39x.o
Dec 06 03:05:22 <ByteEnable> So it does generate extra code.
Dec 06 03:06:05 <ByteEnable> Maybe just a few bytes but there some extra maybe.
Dec 06 03:08:34 <ByteEnable> It looks like the 385 is leveraging the 370 for some CPU architecture stuff like IRQs.
Dec 06 03:09:08 <ByteEnable> Well that's good.  No worries then.
Dec 06 03:10:24 <mangix> some of the drivers are shared yes
Dec 06 03:17:05 <ByteEnable> Yeah.  Looks like the combination is also generating the weakest code too.   Because the 385 has crypto engine and neon.
Dec 06 03:21:37 <ByteEnable> It's using NEON when it builds raid but raid is XOR intensive.
Dec 06 03:23:29 <mangix> ByteEnable: mvebu has a XOR driver
Dec 06 03:24:47 <mangix> hmm I think it's only used for mdadm though
Dec 06 03:31:33 <ByteEnable> Look at my captured build.log (make V=sc), only RAID is using NEON.  Everywhere else its -mfpu=vfp which is an alias vfp2.
Dec 06 03:31:53 <mangix> hmmmmmmmmmmm where the hell is this XOR driver used?
Dec 06 03:33:29 <mangix> ok I see references in md/raid5.[ch]
Dec 06 03:33:53 <mangix> so btrfs doesn't use it. wonder why.
Dec 06 03:46:11 <mangix> ByteEnable: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/Makefile?h=next-20201204#n103
Dec 06 04:05:28 <mangix> finally figured it out. btrfs does not support hardware XOR
Dec 06 04:05:29 <mangix> ugh
Dec 06 04:12:25 <ByteEnable> CONFIG_KERNEL_MODE_NEON is not set in Master.
Dec 06 04:15:31 <mangix> armada 370 does not support NEON
Dec 06 04:17:48 <ByteEnable> 385 does though.
Dec 06 04:18:19 <ByteEnable> wrt32x wrt3200acm
Dec 06 04:19:49 <ByteEnable> turris omnia
Dec 06 04:20:23 <ByteEnable> https://deviwiki.com/w/index.php?search=armada+385&title=Special%3ASearch&go=Go
Dec 06 04:22:22 <dorf> don't forget the wrt1900acs :)
Dec 06 04:22:57 <ByteEnable> Yeah looks like about 7 routers.
Dec 06 04:39:55 <ByteEnable> Lots of verbage on using NEON in kernel mode.    Only crypto and raid use NEON in kernel mode.
Dec 06 04:40:16 <ByteEnable> Documentation/arm/kernel_mode_neon.rst
Dec 06 04:41:38 <ByteEnable> Also there in an option to select vfp3 but only vfp is ever used in the kernel as well.
Dec 06 04:43:47 <ByteEnable> Looking upstream at 5.9.  It's the same.  Only make use of vfp.  No vfp3.
Dec 06 05:03:54 <mangix> ByteEnable: this has had contention. the reason for not adding an extra target is to lessen buildbot load.
Dec 06 05:04:09 <ByteEnable> Oh yeah of course.
Dec 06 05:04:45 <mangix> There's nobody that has shown NEON to have a good enough advantage
Dec 06 05:10:23 <ByteEnable> Yeah it looks like in kernel mode no one is really using it or vfp3.  Maybe openSSL or encrypted network traffic.
Dec 06 05:10:55 <ByteEnable> IPv6 has encryption built into the spec.
Dec 06 05:12:06 <mangix> I think kernel NEON is already enabled for some stuff
Dec 06 05:12:16 <mangix> probably gets en/disabled at runtime
Dec 06 05:12:43 <ByteEnable> You would think Arm would be all over this but maybe there is really no real world performance gains.
Dec 06 05:13:05 <mangix> NEON's just for crypto and multimedia stuff
Dec 06 05:13:24 <ByteEnable> Yeah Arm's version of SIMD.
Dec 06 05:13:25 <mangix> that's all SIMD's useful for
Dec 06 05:16:04 <ByteEnable> Arm is gunning for x86 so they have some big fish to fry right now.
Dec 06 05:16:15 <ByteEnable> Apple switched.
Dec 06 05:18:02 <ByteEnable> That's one thing about Apple.  They are not shy to move platforms.
Dec 06 05:18:52 <ByteEnable> Not an Apple fanboy.  I use Android.
Dec 06 05:20:14 <mangix> Apple switched to ARM for a different reason than most.
Dec 06 05:21:11 <mangix> they want control of the entire supply chain
Dec 06 05:23:33 <ByteEnable> Probably.
Dec 06 05:23:53 <ByteEnable> Hey I found a good faq on vfp:  https://wiki.debian.org/ArmHardFloatPort/VfpComparison
Dec 06 05:24:12 <ByteEnable> Bottom line:  NEON requires hand tuning to get any real gain.
Dec 06 05:26:16 <ByteEnable> Or buy the $6000 compiler from Arm.
Dec 06 05:26:33 <mangix> yeah
Dec 06 05:26:42 <mangix> wireguard neon code for example is hand tuned
Dec 06 06:25:59 <owrt-1907-builds> build #208 of zynq/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/zynq%2Fgeneric/builds/208
Dec 06 06:57:17 <mangix> finally found out why ccache was failing with some packages
Dec 06 06:57:19 <mangix> libcxx
Dec 06 07:21:29 <owrt-1907-builds> build #210 of bcm53xx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/bcm53xx%2Fgeneric/builds/210
Dec 06 07:21:44 <aparcar[m]> mangix: ping
Dec 06 07:23:41 <owrt-1907-builds> build #206 of brcm2708/bcm2710 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm2708%2Fbcm2710/builds/206
Dec 06 07:24:54 <aparcar[m]> jow: https://github.com/openwrt/luci/pull/4637/files#diff-adf712ab47ca2e5c052d0ad45de5737b2be6860525cd51ec8f424c7e3a43b78aR886 is there a nice way to split those ultra long lines?
Dec 06 07:40:07 <mangix> aparcar[m]: pong
Dec 06 07:40:19 <aparcar[m]> is the lzo thing merged?
Dec 06 07:55:35 <aparcar[m]> mangix:
Dec 06 07:55:43 <aparcar[m]> can you please tell me how to test this? https://github.com/openwrt/openwrt/pull/1491
Dec 06 08:13:58 <mangix> x32 huh
Dec 06 08:14:31 <mangix> that requires a special host system
Dec 06 08:15:09 <aparcar[m]> ok I'll postpone it
Dec 06 08:15:29 <mangix> yeah that's not for a 32-bit VM as he mentioned
Dec 06 08:15:51 <mangix> it's a 64-bit host system where the environment is all 32-bit
Dec 06 08:15:56 <mangix> it's a weird environment
Dec 06 08:16:48 <mangix> https://en.wikipedia.org/wiki/X32_ABI
Dec 06 08:16:54 <aparcar[m]> ugh
Dec 06 08:16:57 <mangix> if you read on the bottom, almost everyone hates it
Dec 06 08:20:59 <aparcar[m]> about your lzo patch, what about package/utils/mtd-utils/Makefile ?
Dec 06 08:21:10 <aparcar[m]> it requires lzo but then is compiled --without-lzo
Dec 06 08:22:19 <mangix> oh. build_depends....
Dec 06 08:22:27 <mangix> that makes no sense
Dec 06 08:23:49 <owrt-1907-builds> build #240 of mpc85xx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mpc85xx%2Fgeneric/builds/240
Dec 06 08:23:51 <aparcar[m]> please install ripgrep and check those cases before proposing a removal :)
Dec 06 08:26:58 <mangix> all of those build depends are probably bogus
Dec 06 08:27:04 <mangix> I'll clean the package up
Dec 06 08:27:10 <aparcar[m]> thank you
Dec 06 08:28:13 <mangix> OK util-linux is needed because of libuuid
Dec 06 08:28:16 <mangix> great
Dec 06 08:28:35 <mangix> wait a minute...
Dec 06 08:29:35 <owrt-1907-builds> build #197 of apm821xx/nand is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/apm821xx%2Fnand/builds/197
Dec 06 08:30:44 <mangix> I see. all the binaries are linked statically.
Dec 06 08:36:11 <mangix> enjoy
Dec 06 08:36:17 <aparcar[m]> why is qemu 0.14.1 shipped within openwrt while upstream is... 5.1?
Dec 06 08:36:39 <mangix> I believe the version in tools/ is only used to create an x86 image
Dec 06 08:36:48 <mangix> that is, only one binary is used
Dec 06 08:37:03 <aparcar[m]> yea but seem to buildfail on this exotic x32 env
Dec 06 08:38:17 <mangix> oh I see
Dec 06 08:38:25 <mangix> I guess it's time to update.
Dec 06 08:38:59 <mangix> I think stintel can be a guinea pig
Dec 06 08:39:04 <aparcar[m]> mangix: that's the spirit
Dec 06 08:40:06 <mangix> let's see
Dec 06 08:40:09 <aparcar[m]> mangix: your commit message is a bit to casual
Dec 06 08:40:11 <mangix> what's the latest version
Dec 06 08:40:26 <aparcar[m]> 5.1.0 but we have 5.0.0 in packages.git, which I copy patsed
Dec 06 08:42:01 <owrt-1907-builds> build #238 of layerscape/armv8_64b is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/layerscape%2Farmv8_64b/builds/238
Dec 06 08:43:09 <mangix> 5.2.0 is at rc4
Dec 06 08:43:10 <mangix> joy
Dec 06 08:43:45 <aparcar[m]> don't get gready
Dec 06 08:44:59 <mangix> ah found out why it's not updated
Dec 06 08:45:02 <mangix> ERROR: glib-2.48 gthread-2.0 is required to compile QEMU
Dec 06 08:45:19 <aparcar[m]> meaning?
Dec 06 08:45:30 <mangix> those are huge dependencies
Dec 06 08:46:50 <aparcar[m]> we only ever use qemu to convert stuff right? can't it be stipped down?
Dec 06 08:47:04 <mangix> I'm sure it can
Dec 06 08:47:34 <aparcar[m]> isn't it cleaner to have qemu with qemu-img only in version 5.1.0?
Dec 06 08:50:01 <mangix> looks like QEMU must be configured
Dec 06 08:50:34 <aparcar[m]> mangix: maybe it's the wrong focus, there are likely other fishes to fry
Dec 06 08:58:28 <mangix> yeha
Dec 06 08:58:44 <mangix> maybe there's a way to remove tools/qemu and replace it with something else
Dec 06 09:00:30 <mangix> git grep qemu-image
Dec 06 09:02:22 <aparcar[m]> I'd just remove the whole thing and require users to convert it themselfs
Dec 06 09:02:49 <mangix> meh I don't care enough for it. I don't use x86 QEMU images
Dec 06 09:03:02 <aparcar[m]> neither...
Dec 06 09:03:41 <mangix> most important issue is this: https://github.com/openwrt/packages/issues/14144
Dec 06 09:07:27 <aparcar[m]> I'll ping him, I estimate he's back in 2h
Dec 06 09:07:43 <mangix> who?
Dec 06 09:07:51 <aparcar[m]> dango
Dec 06 09:08:05 <mangix> he already reported the issue
Dec 06 09:08:37 <aparcar[m]> oh I thoughts gingerneut did
Dec 06 09:08:50 <mangix> https://github.com/transmission/transmission/issues/1537
Dec 06 09:09:10 <aparcar[m]> 🍿
Dec 06 09:09:35 <mangix> this code looks implemented and abandoned
Dec 06 09:09:36 <mangix> ugh
Dec 06 09:09:50 <mangix> last touched 2016
Dec 06 09:10:19 <aparcar[m]> mangix: I upated opkg.git, can you please give it a test run?
Dec 06 09:17:35 <mangix> hmm?
Dec 06 09:18:17 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 97.5% packages reproducible in our current test framework.)
Dec 06 09:20:12 <mangix> which packages are not reproducible?
Dec 06 09:21:16 <mangix> ah, i have to search for unreproducible
Dec 06 09:23:08 <owrt-1907-builds> build #240 of ramips/rt3883 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Frt3883/builds/240
Dec 06 09:28:18 <aparcar[m]> mangix: https://git.openwrt.org/?p=project/opkg-lede.git
Dec 06 09:29:20 <mangix> it looks like you're removing code
Dec 06 09:29:22 <owrt-1907-builds> build #239 of ar71xx/mikrotik is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ar71xx%2Fmikrotik/builds/239
Dec 06 09:37:00 <aparcar[m]> mangix: excellent observation :)
Dec 06 09:37:52 <mangix> what is there to test then?
Dec 06 09:37:58 <aparcar[m]> fair
Dec 06 09:38:04 <aparcar[m]> i need to go
Dec 06 09:44:01 <owrt-1907-builds> build #243 of mvebu/cortexa72 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa72/builds/243
Dec 06 10:24:03 <owrt-1907-builds> build #243 of armvirt/32 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/armvirt%2F32/builds/243
Dec 06 11:30:24 <owrt-1907-builds> build #237 of mvebu/cortexa53 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mvebu%2Fcortexa53/builds/237
Dec 06 12:27:41 <owrt-1907-builds> build #226 of ath25/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ath25%2Fgeneric/builds/226
Dec 06 13:21:50 <owrt-1907-builds> build #180 of ath79/tiny is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ath79%2Ftiny/builds/180
Dec 06 13:27:44 <Tapper> Hi people. From the forums.
Dec 06 13:27:45 <Tapper> I am trying to port OpenWrt to the Wink Hub v1, which is an i.MX28-based board with a whole bunch of IoT radios attached via serial ports. The standard flash has updater_kernel and updater-root partitions intended for recovery and update purposes, which appears to be ideal for messing around with OpenWrt, but still keep the ability to boot back to a working OS.
Dec 06 13:27:52 <Tapper> https://forum.openwrt.org/t/porting-openwrt-to-winkhub-v1/56966
Dec 06 14:18:49 <Hauke> nbd: Could you please have a look at the changes to 300-mac80211-optimize-skb-resizing.patch in the mac80211 update: https://patchwork.ozlabs.org/project/openwrt/patch/20201201221950.32548-3-hauke@hauke-m.de/
Dec 06 14:18:54 <Hauke> I am not sure if this is correct
Dec 06 14:19:09 <Hauke> I think you fixed the problem Johannes found in a different way already
Dec 06 14:19:32 <Hauke> It would be ncie if you could send this patch upstream again
Dec 06 14:36:18 <owrt-1907-builds> build #200 of x86/legacy is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/x86%2Flegacy/builds/200
Dec 06 14:43:16 <owrt-1907-builds> build #203 of mxs/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mxs%2Fgeneric/builds/203
Dec 06 15:25:16 <russell--> KanjiMonster: did you see this? https://github.com/openwrt/openwrt/pull/3616
Dec 06 15:25:41 * russell-- goes Zzzz for several hours
Dec 06 15:40:40 <owrt-1907-builds> build #202 of brcm2708/bcm2708 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm2708%2Fbcm2708/builds/202
Dec 06 15:41:03 <owrt-1907-builds> build #193 of brcm2708/bcm2709 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm2708%2Fbcm2709/builds/193
Dec 06 15:47:31 <owrt-1907-builds> build #201 of lantiq/xrx200 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Fxrx200/builds/201
Dec 06 16:45:52 <owrt-1907-builds> build #185 of samsung/s5pv210 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/samsung%2Fs5pv210/builds/185
Dec 06 17:47:34 <owrt-1907-builds> build #181 of mpc85xx/p2020 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/mpc85xx%2Fp2020/builds/181
Dec 06 18:58:22 <aparcar[m]> rsalvaterra: I merged your kmod-lib-zstd patch
Dec 06 18:58:47 <rsalvaterra> aparcar[m]: I just noticed it, thanks! :)
Dec 06 19:00:13 <rsalvaterra> Still trying to upstream my zram patch to allow disabling lzo, but I hit a snag with the ppc44x defconfig, which broke for some unfathomable reason.
Dec 06 19:11:21 <aparcar[m]> good luck
Dec 06 19:14:15 <rsalvaterra> Heh… I'll try to reproduce it on my dog-slow iBook G4, eventually, when boredom hits hard.
Dec 06 19:14:41 <aparcar[m]> rsalvaterra: what is the impact of https://patchwork.ozlabs.org/project/openwrt/patch/20201110225920.1030302-1-rsalvaterra@gmail.com/ ?
Dec 06 19:15:29 <aparcar[m]> also please close https://patchwork.ozlabs.org/project/openwrt/patch/20201027094231.2633-1-rsalvaterra@gmail.com/
Dec 06 19:15:33 <rsalvaterra> aparcar[m]: Functional? Zero. In terms of performance? Marginal, at best. Haven't measured.
Dec 06 19:17:01 <aparcar[m]> okay than I don't bother ;P
Dec 06 19:17:44 <rsalvaterra> aparcar[m]: Probably more placebo than anything… but it's Gentoo-compliant. :P
Dec 06 19:18:11 <ByteEnable> 19.7.04:  Installing libpthread results in no actual library installed.  Is there another step?
Dec 06 19:29:44 <aparcar[m]> rsalvaterra: please test https://github.com/aparcar/openwrt/commit/fa8d57f4e1f8c0c800bfa201b9ce669ea323e4f5
Dec 06 19:36:11 <rsalvaterra> Hm… I don't use opkg in my builds… :/
Dec 06 19:38:24 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html
Dec 06 19:38:56 <aparcar[m]> fair
Dec 06 19:41:20 <rsalvaterra> I'm a bit weird, for sure… :P
Dec 06 19:41:42 <aparcar[m]> no worries
Dec 06 19:57:30 <blocktrron> aparcar[m]: would've been nice if a decision on the 802.11b disable PR could have waited after the weekend
Dec 06 19:58:50 <blocktrron> In the end, WiFi interoperability specifically states that these rates are mandatory
Dec 06 19:59:53 <ByteEnable> musl libc faq says libpthread.a should exist but the package libpthread has nothing lib is empty.
Dec 06 20:01:37 <blocktrron> I know this is only the standpoint of the alliance, however I greatly dislike the idea we ship the default configuration in a state where even modern stuff has trouble performing network discovery.
Dec 06 20:06:48 <ByteEnable> librt is empty as well.  If I make musl on the host I get librt.a and libpthread.a .
Dec 06 20:07:48 <owrt-1907-builds> build #190 of ramips/mt7620 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Fmt7620/builds/190
Dec 06 20:08:02 <jow> ByteEnable: it makes no sense to install static .a libraries on openwrt
Dec 06 20:08:05 <jow> why would you want that?
Dec 06 20:08:34 <ByteEnable> That is how is musl redirects apps to use its thread library.
Dec 06 20:08:45 <jow> no it doesn't
Dec 06 20:09:05 <ByteEnable> Why even include empty librt and libpthread as packages in openwrt.
Dec 06 20:09:32 <jow> because we also support compilation with glibc or uclibc, there librt and libpthread are separate
Dec 06 20:10:20 <ByteEnable> From the musl faq:  Why not just omit libm.a, libpthread.a, etc. entirely? POSIX says -lm, -lpthread, etc. are valid options to the compiler and conforming applications must use these options when they need the corresponding functionality, and the easiest way to comply with that requirement (and avoid breaking applications) is with empty .a files by those names.
Dec 06 20:10:31 <jow> correct
Dec 06 20:10:36 <jow> but we do not *compile* on target
Dec 06 20:10:49 <jow> hence no need to ship *.a libraries just to satisfy compile time flags
Dec 06 20:10:55 <ByteEnable> But why offer empty packages in openwrt?
Dec 06 20:11:10 <ByteEnable> Your defending brokenness.
Dec 06 20:11:13 <jow> so that packages can have the same DEPENDS:= regardless of whether they're built with glibc or musl systems
Dec 06 20:11:47 <ByteEnable> So you package empty ipk's for naught.
Dec 06 20:13:01 <ByteEnable> I can gcc on target to compile apps.
Dec 06 20:13:08 <ByteEnable> *I can install
Dec 06 20:13:09 <jow> right
Dec 06 20:13:19 <jow> but it's not officially supported
Dec 06 20:13:50 <jow> and lib* ipk archives would not be the proper ones to ship *.a libraries since nothing uses it at runtime (they're only used for linking apps)
Dec 06 20:14:03 <jow> lib*-dev packages would be the appropriate place, but OpenWrt does not support these
Dec 06 20:14:04 <ByteEnable> There is a package named gcc which says its supported no?
Dec 06 20:14:15 <jow> gcc is a feed package, maintained by the community
Dec 06 20:14:30 <jow> openwrt does not support on-target ocmpilation, there's no base-supported toolchain on target
Dec 06 20:14:42 <owrt-1907-builds> build #202 of layerscape/armv7 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/layerscape%2Farmv7/builds/202
Dec 06 20:14:53 <ByteEnable> Okay.  So then why package empty ipks?
Dec 06 20:15:34 <jow> so that packages that require librt or libpthread functionality which are built for systems using uclibc or glibc instead of musl can use the same DEPENDS:=
Dec 06 20:16:22 <jow> openwrt used to ship with uclibc by default, so librt and libpthread are actual libs there
Dec 06 20:16:28 <jow> a few targets still use uclibc
Dec 06 20:16:38 <ByteEnable> But musl is the default support for openwrt right?
Dec 06 20:16:49 <jow> for most, but not all targets
Dec 06 20:16:55 <jow> some targets still use uclibc
Dec 06 20:16:55 <ByteEnable> To get glibc you must do your compile right?
Dec 06 20:17:12 <owrt-1907-builds> build #183 of ramips/mt7621 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ramips%2Fmt7621/builds/183
Dec 06 20:18:04 <jow> yes, to get glibc you need to compile yourself
Dec 06 20:18:20 <ByteEnable> You are not making any sense.  If openwrt default shipping build is with muscl and you don't include the .a files then why package empty ipks?
Dec 06 20:20:53 <jow> because we want people to be able to compile with glibc without having to touch package Makegiles to manually add +libpthread to the respective DEPENDS:= lines of their Makefiles
Dec 06 20:21:24 <ByteEnable> The IPK in the package repo has nothing to do with when someone builds glibc.
Dec 06 20:21:59 <jow> it has if you build with glibc and host your own package repos
Dec 06 20:22:14 <jow> also opkg is used during firmware compilation, so dependency resolution has to work there as well to produce proper images
Dec 06 20:22:18 <ByteEnable> If I go to software in luci and search for libpthread there is a package.  You install the package.  But the package is actually empty.
Dec 06 20:22:43 <jow> yes, for officla builds it is empty
Dec 06 20:23:28 <ByteEnable> So why package empty ipk's ?
Dec 06 20:23:44 <urjaman> you're just running around in these silly circles and i've kinda had it lol
Dec 06 20:24:12 <ByteEnable> Me too.
Dec 06 20:24:20 <urjaman> you were answered
Dec 06 20:24:34 <ByteEnable> Doesn't make sense for the end user.
Dec 06 20:24:42 <ByteEnable> You expect to get the .a files.
Dec 06 20:24:42 <jow> it's not an end user question
Dec 06 20:24:45 <jow> no
Dec 06 20:25:05 <jow> I would expect *.a files from *-dev packages (a concept which does not exist on openwrt)
Dec 06 20:25:07 <urjaman> it exists to satisfy dependencies, those dependencies exist to support other valid configurations, end of story
Dec 06 20:25:33 <ByteEnable> Only at build time on the host right?
Dec 06 20:26:02 <jow> no at run time on the target
Dec 06 20:26:18 <urjaman> if you build a repo of glibc or uclibc-based ipks they will be needed runtime too (and contain .so files as i get it? like one would expect)
Dec 06 20:27:26 <jow> there would be multiple ways to chage that nowadays, we could move librt.so and libpthread.so into libc.ipk for glibc and ditch extra packages
Dec 06 20:27:36 <jow> or we could introduce conditional depends
Dec 06 20:28:03 <jow> but it is additional work for no gain
Dec 06 20:29:25 <jow> if your actual question is "how do I compile stuff on an musl target where some build system insists on linking with "-lpthread" or "-lrt" eventhough the corresponding apis are part of the default libc.so already, then use this: https://forum.openwrt.org/t/usr-bin-ld-cannot-find-lpthread/18404/3
Dec 06 20:30:19 <jow> but again, on-target compilation is not really supported. Not in the sense you would expect it from a Debian or CentOS or any other ordinary Linux distro
Dec 06 20:30:56 <jow> yes, there is a gcc package, but it is neither polished, nor tested, nor are all auxiliary utilities packaged that are typically needed to compile complex software pacakges
Dec 06 20:31:04 <jow> or header-files or development packages
Dec 06 20:31:58 <jow> and the empty librt and libpthread packages are placeholders for libc implementations where these libs are separate shared objects
Dec 06 20:32:39 <jow> motivation is that compiled packages always have the same dependency specs if they use rt or thread symbols, regardless of whether the crt happens to contain these symbols in the core or in extra shared objects
Dec 06 20:50:22 <owrt-1907-builds> build #200 of lantiq/falcon is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Ffalcon/builds/200
Dec 06 20:55:18 <ldir-> happy happy happy happy
Dec 06 21:10:17 <aparcar[m]> ldir-: happy?
Dec 06 21:10:21 <owrt-1907-builds> build #199 of sunxi/cortexa7 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/sunxi%2Fcortexa7/builds/199
Dec 06 21:11:32 <aparcar[m]> blocktrron: okay I'll give it more time next time
Dec 06 21:22:03 <ldir-> trying to counteract the preceding hour's 'fun'
Dec 06 21:22:57 <aparcar[m]> ldir-: elaborate
Dec 06 21:25:08 <aparcar[m]> jow: plans to publish ucode?
Dec 06 22:11:29 <jow> aparcar[m]: once it meets my quality expectations
Dec 06 22:11:37 <jow> still finding bugs
Dec 06 22:12:22 <aparcar[m]> is it worth to add a RC to openwrt.git so people start tinkering with it?
Dec 06 22:28:46 <Borromini> jow: i am running into what seems to be a firewall bug with PPPoE like documented here: https://forum.openwrt.org/t/iptables-uses-wrong-interface-on-boot/74757
Dec 06 22:30:05 <Borromini> from the moment i switched my modem to passthrough and had OpenWrt handle the PPPoE connection DNS somehow works but lan to wan traffic does not (e.g. can resolve websites but not ping or visit them)
Dec 06 22:30:29 <Borromini> wondering if there's extra stuff i can try to find out what goes wrong where. a firewall reload fixes things.
Dec 06 22:47:20 <jow> aparcar[m]: I think I'll merge it next week alomng with firewall4, so people can play with it
Dec 06 22:47:48 <jow> Borromini: that forum post sounds weird
Dec 06 22:48:11 <jow> Borromini: why should the firewall use `wan` (I assume a DSA port) instead of `pppoe-wan` if the connection is PPPoE
Dec 06 22:49:36 <jow> Borromini: anyhow, please start with providing the contents of /var/run/fw3.state in broken and working state
Dec 06 22:49:47 <jow> Borromini: along with the output of "ifstatus wan"
Dec 06 22:50:09 <Borromini> jow: ok. i'll reproduce and get back to you. is that ok?
Dec 06 22:50:21 <Borromini> it's mt7621, so dsa yes.
Dec 06 22:50:32 <jow> sure. I assume the regression got introduced with DSA
Dec 06 22:50:54 <jow> I vaguely remember that we have some "interpret value as logical network, then netdev" logic somewhere
Dec 06 22:51:13 <Borromini> ok :)
Dec 06 22:51:21 <jow> since with DSA "wan" is both a logical network and a Linux network device, things might get confused on early boot when PPPoE is not yet up
Dec 06 22:52:18 <jow> could you also try renaming your wan in /etc/config/network to something like "wan2" or "internet" (don't forgot to adjust option/list network wan in /e/c/firewall too)
Dec 06 22:52:28 <jow> and see if the issue still occurs then
Dec 06 22:52:49 <Borromini> will do.
Dec 06 22:53:32 <jow> actually I think its clear
Dec 06 22:53:59 <jow> on boot, when pppoe is not yet up, ifstatus wan will likely report no l3_device and (DSA) "wan" as (l2_)device
Dec 06 22:54:07 <jow> so fw3 will use that
Dec 06 22:54:31 <jow> however, when PPPoE eventually comes up, it should trigger /etc/hotplug.d/iface/20-firewall which should then restart fw3
Dec 06 22:54:46 <jow> I suggest to add some debugging to /etc/hotplug.d/iface/20-firewall as well
Dec 06 22:54:51 <jow> maybe we have a race there
Dec 06 22:56:14 <Borromini> ok. debugging as in removing the -q and /dev/null redirect?
Dec 06 22:56:45 <jow> yeah, and adding something like `env | logger -t hotplug-vars` to dump the event env vars to logread
Dec 06 22:57:08 <jow> to see what DEVICE, ACTION etc. are set to, ideally before the if condition filtering things out
Dec 06 22:58:06 <Borromini> https://paste.debian.net/1175869/ < like this then, with env at the very top?
Dec 06 22:58:52 <jow> yes.
Dec 06 22:59:07 <jow> My hunch is that `fw3 network "$INTERFACE"` fails
Dec 06 22:59:39 <Borromini> ok, will do and let you know :). thanks a lot for the tips already.
Dec 06 22:59:42 <jow> if this is the case, you should see *no* `Reloading firewall due to ifup of wan (pppoe-wan)` in logread
Dec 06 23:01:10 <Borromini> alright. i've logged all this and will get back to you.
Dec 06 23:01:12 <Borromini> goodnight!
Dec 06 23:01:15 <jow> good night
Dec 07 02:35:46 <mangix> aparcar[m]: if you could look into https://patchwork.ozlabs.org/project/openwrt/patch/20201205092105.15305-1-rosenp@gmail.com/ :)
Dec 07 02:36:16 <mangix> not mentioned in the commit message is that ccache is broken with it, as I later found out.
**** ENDING LOGGING AT Mon Dec 07 02:59:57 2020