**** BEGIN LOGGING AT Mon Feb 22 02:59:57 2021
Feb 22 03:06:01 <Grommish> Not OpenWrt related, but has anyoine setup a local BitWarden server to handle passwords?
Feb 22 03:06:39 <Grommish> I've got an old Barracuda SpamAssassin box that I am repurposing
Feb 22 03:13:51 <lipnitsk> I have a KCONFIG vs DEPENDS question if anybody is online... Struggling to define an optional kernel module dependency. It works during target/linux/compile and during package/kernel/linux/compile but fails at package/install. The idea is that if a CONFIG option is defined then a dependency is needed, but if not then it is not needed. So I think adding +OPTION:kmod-xxx to the DEPENDS. The problem is that all modules
Feb 22 03:13:51 <lipnitsk> are built together, so OPTION is selected during the build, but OPTION is only set to 'm', not 'y', so kmod-xxx.ipk is not built for rootfs... Any way to fix this?
Feb 22 03:16:41 <lipnitsk> any way to force OPTION to 'y' if it was 'm', but not depend on it if it was 'n' or absent?
Feb 22 03:48:26 <Namidairo> Grommish: bitwarden_rs works well just remember to setup db backups
Feb 22 03:49:37 <Grommish> I was looking at the docker image
Feb 22 03:58:46 <Grommish> Ironically, I don't want to mess with rustlang outside of the build system
Feb 22 04:49:01 <lipnitsk> another way of putting my problem is: does OpenWrt build system support not enforcing module dependencies that are guarded by IS_REACHABLE in the kernel code, thereby making the dependency optional?
Feb 22 05:12:42 <owrt-snap-builds> build #305 of mpc85xx/p1010 is complete: Failure [failed images]  Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp1010/builds/305  blamelist: Moritz Warning <moritzwarning@web.de>, Georgi Valkov <gvalkov@abv.bg>, David Bauer <mail@david-bauer.net>, Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
Feb 22 05:17:38 <Grommish> lipnitsk: You should ping jow on that, and see if he answers (in addition to the rest).
Feb 22 05:18:10 <Grommish> but it'll at least show up on his end, if he knows and can answer
Feb 22 05:34:21 <lipnitsk> jow: ping
Feb 22 05:34:44 <lipnitsk> Grommish: thanks for the suggestion!
Feb 22 06:06:57 <Grommish> If anyone wants to toss in an opinion..  https://forum.openwrt.org/t/openwrt-servicing-public-dns-queries/89332
Feb 22 06:55:26 <lipnitsk> zx2c4: I just pushed the best fix I could come up with - I was able to build a couple different configurations successfully with it. Hopefully that settles the issue for now, unless somebody has a better idea in mind.
Feb 22 06:58:06 <lipnitsk> zx2c4: by successfully, I mean that it got past the package/install error related to kmod-crypto-kpp. The build still failed because the resulting image was too big for some target, but that looked completely unrelated to any of the crypto changes.
Feb 22 07:14:03 <lipnitsk> jow: any ideas on how to better handle this? https://github.com/openwrt/openwrt/pull/3885/commits/d3f005f4383924f0b5b0e45e80a4b93812d0c06d
Feb 22 07:36:04 <RaspberryJam> I run openwrt on a wireless access point. I need to get a poe managed switch, I see that openwrt has preliminary support for some of these switches with a realtek chipset.
Feb 22 07:36:04 <RaspberryJam> There's a trendnet switch that has the specs I want but there is no official confirmation openwrt works on it, I made a forum post about it.
Feb 22 07:36:05 <RaspberryJam> https://forum.openwrt.org/t/trendnet-tpe-1620ws-both-hardware-revisions-supported/89268
Feb 22 07:36:05 <RaspberryJam> If I order one of those switches what would be the most effective way to help openwrt run on it? Would I just post pictures of the board, try to flash it with a dev rom, and report what happens?
Feb 22 07:39:52 <ynezz> if you're not willing to tackle this yourself, then just buy one which has already support
Feb 22 07:59:22 <guidosarducci> ynezz: ping
Feb 22 08:01:40 <guidosarducci> blocktrron: ping
Feb 22 08:09:13 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_omap.html has been updated. (0% images and 98.2% packages reproducible in our current test framework.)
Feb 22 08:11:05 <guidosarducci> BTW 21.02 SNAPSHOT IB was working 2 days ago, but current one fails with many errors like:  "Packages for mtd found, but incompatible with the architectures configured". Known issue?
Feb 22 08:18:11 <plntyk> think so -its related to abi changes
Feb 22 08:18:16 <plntyk> i have it too
Feb 22 08:19:18 <plntyk> guidosarducci, look at some fixes in felix tree - think those are not submitted/backported yet
Feb 22 08:19:24 <guidosarducci> plntyk: only other thing I can think is if package builds aren't complete even though the IB is available...
Feb 22 08:19:40 <plntyk> build: reorder more BuildPackages lines to deal with ABI_VERSION
Feb 22 08:21:04 <guidosarducci> plntyk: all that stuff worries me... I saw a complete NOP change to a package I maintain, so really wondering changes are based on.
Feb 22 08:21:21 <guidosarducci> plntyk: will look at his tree too, thanks
Feb 22 08:21:50 <guidosarducci> plntyk: ^ "wondering what changes are based on"
Feb 22 08:22:10 <plntyk> guidosarducci, there are some other changes in the build system on the way - some to make compile / recompile times shorter
Feb 22 08:22:31 <plntyk> and the abi change was probably done to make security updates "easier"
Feb 22 08:22:44 <plntyk> and/or "fix" buildbot stuff when releasing
Feb 22 08:23:51 <plntyk> some packages / upstream "behavior" is "stupid" too - like mpd
Feb 22 08:24:24 <guidosarducci> plntyk: should I even ask "what changes?" It begs the question of what's been slowing things down. But TBH I find things pretty quick once ccache is enabled, downloads are cached.
Feb 22 08:24:54 <plntyk> "embedded" player that changed to C++17 - while some platforms have problems with "modern" languages / compiler support
Feb 22 08:25:56 <plntyk> doing stuff faster sometimes exposes more bugs like parallel build flags becoming necessary
Feb 22 08:26:43 <plntyk> felix has some change that should decrease buildtime on autoconfig stuff
Feb 22 08:28:11 <guidosarducci> plntyk: right, the parallel builds can be flakey if pushed I've seen too
Feb 22 08:29:02 <rsalvaterra> 'morning
Feb 22 08:29:08 <plntyk> good morning
Feb 22 08:34:33 <guidosarducci> ldir: ping
Feb 22 08:39:52 <rsalvaterra> I'm… seeing a git send-email borderline crazy behaviour: git send-email -7 works, -9 works, -8 doesn't work, gives me a "No patch files specified!". Any ideas?
Feb 22 08:54:03 <plntyk> look at patch series with "file" tool - maybe it points out something
Feb 22 08:55:45 <rsalvaterra> Oh, wow…! Making -8 the last argument seems to have worked. Composing…
Feb 22 09:02:59 <rsalvaterra> Yeah, it work. Perl shenanigans, for sure…
Feb 22 09:03:02 <rsalvaterra> *worked
Feb 22 10:31:24 <eliasmagn> Hy guys why to use uci_get insteat of uci get in init scripts?
Feb 22 10:46:27 <plntyk> eliasmagn, dunno - https://dev.archive.openwrt.org/ticket/7312 coding decision
Feb 22 10:46:45 <plntyk> from ~2010
Feb 22 10:49:59 <eliasmagn> plntyk, thanks for the hint
Feb 22 11:39:27 <owrt-snap-builds> build #863 of sunxi/cortexa53 is complete: Failure [failed tools]  Build details are at http://buildbot.openwrt.org/master/images/builders/sunxi%2Fcortexa53/builds/863  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, Georgi Valkov <gvalkov@abv.bg>, David Bauer <mail@david-bauer.net>, Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
Feb 22 11:41:07 <zx2c4> lipnitsk: i have a better idea...
Feb 22 11:41:14 <zx2c4> Ill remove that dependency upstream
Feb 22 11:45:45 <zx2c4> Oh never idea it's kind of already there
Feb 22 11:45:52 <zx2c4> it's just conditional, blah
Feb 22 11:54:39 <zx2c4> lipnitsk: what about this...
Feb 22 11:54:41 <zx2c4>   DEPENDS_m:=kmod-crypto-kpp
Feb 22 11:54:41 <zx2c4>   DEPENDS_y:=$(DEPENDS_m)
Feb 22 11:54:41 <zx2c4>   DEPENDS:=$(DEPENDS_$(CONFIG_CRYPTO_KPP))
Feb 22 12:33:09 <zx2c4> lipnitsk: okay the issue is having dependencies in the arch-specific things
Feb 22 12:33:15 <zx2c4> because you evaluate the equivalance wit ha global if
Feb 22 12:33:22 <zx2c4> im fixing it -- ill forcepush
Feb 22 12:36:22 <zx2c4> though that might get messy. perhaps we just want to unconditionally depend on CONFIG_KPP
Feb 22 13:03:33 <ynezz> is there anyone who has flashed openwrt to omnia from the stock u-boot?
Feb 22 13:04:29 <ynezz> my device is running U-Boot 2019.07 (Oct 05 2020 - 23:50:39 +0000), Build: jenkins-turris-os-packages-dragons-omnia-1753
Feb 22 13:05:15 <ynezz> but it seems like I'm not able to write anything to emmc, any 'mmc write' command fails in u-boot, have I missed something like some hidden read-only knob or such "feature" ?
Feb 22 13:06:37 <ynezz> my idea is something like 'dhcp ${kernel_addr_r} openwrt-mvebu-cortexa9-cznic_turris-omnia-sysupgrade.img; mmc dev 0 0; run set_blkcnt; mmc write ${kernel_addr_r} 0 ${blkcnt}'
Feb 22 13:17:18 <plntyk> ynezz, "protect" command seems available on u-boot turris fork
Feb 22 13:17:27 <plntyk> *might*
Feb 22 13:17:30 <plntyk> https://gitlab.nic.cz/turris/u-boot-turris/-/blob/turris/README
Feb 22 13:57:28 <rsalvaterra> ynezz: I too would like to update the u-boot on my Omnia, but we're lacking a definitive guide… :/
Feb 22 13:58:00 <rsalvaterra> What's your hardware revision?
Feb 22 13:58:52 <rsalvaterra> (I have a CZ11NIC13.)
Feb 22 14:02:48 <ynezz> what definitive guide do you need? :)
Feb 22 14:04:19 <rsalvaterra> Something fat-finger-proof. :P
Feb 22 14:04:29 <rsalvaterra> I wouldn't like to brick my baby. :P
Feb 22 14:04:42 <ynezz> you can't
Feb 22 14:04:57 <rsalvaterra> Oh, well… I'll wait, then. :)
Feb 22 14:05:25 <zx2c4> lipnitsk: alright, fixed, pushed
Feb 22 14:08:22 <tmn505> rsalvaterra: I tihink all armada 32 bit cpus support kwboot (uploading through uart) so You should be safe.
Feb 22 14:08:48 <ynezz> yeah
Feb 22 14:08:50 <rsalvaterra> tmn505: Safe, but slow… ;)
Feb 22 14:09:17 <tmn505> then You write it to spi and slowness disapears
Feb 22 14:09:32 <rsalvaterra> I didn't know that, though, good stuff. :)
Feb 22 14:11:46 <rsalvaterra> tmn505: Looks like someone's testing my patches already. :) https://forum.openwrt.org/t/no-nonsense-linksys-wrt-builds/80522/214
Feb 22 14:12:01 <blogic> xback: ping
Feb 22 14:12:10 <tmn505> I'm just now starting the compilation
Feb 22 14:12:14 <blogic> xback: did you have any luck with the rb9xx ?
Feb 22 14:12:23 * rsalvaterra prays…
Feb 22 14:17:58 <ynezz> rsalvaterra: http://sprunge.us/tVvGdo
Feb 22 14:19:22 <ynezz> so upstream perhaps needs some vendor magic
Feb 22 14:19:52 <rsalvaterra> ynezz: That DRAM training failure doesn't sound very desirable… :P
Feb 22 14:20:22 <ynezz> I guess it's some mvebu feature :p
Feb 22 14:21:22 <rsalvaterra> It's a shame it's not ECC… :(
Feb 22 14:24:58 <stintel> yay, negative pcr test, flight booked
Feb 22 14:25:27 <ynezz> rsalvaterra: actually if booted after power cycle
Feb 22 14:25:32 <ynezz> s/if/it/
Feb 22 14:26:07 <rsalvaterra> ynezz: No errors, this time?
Feb 22 14:26:35 <ynezz> no, just emmc doesn't work :p
Feb 22 14:28:03 <rsalvaterra> In other news, is it just me, or is the 5.10 kernel really big, compared to 5.4…?
Feb 22 14:28:45 <ynezz> this one even boots, cool U-Boot 2021.04-rc1-00199-gf08e6d70c7f4 (Feb 22 2021 - 15:22:42 +0100)
Feb 22 14:31:55 <ynezz> but still emmc bummer, MMC write: dev # 0, block # 0, count 21993 ... mmc write failed
Feb 22 14:34:53 <lipnitsk> zx2c4: looks better than my hack. I tried playing with custom kconfig, but didn't try the imply. I'll test it out with a couple of build combinations
Feb 22 14:36:01 <lipnitsk> zx2c4: thanks for marking the lobs HIDDEN too, I considered doing that, but didn't for whatever reason
Feb 22 14:36:11 <lipnitsk> libs*
Feb 22 14:41:12 <Borromini> stintel: belgium?
Feb 22 14:41:29 <Borromini> adrianschmutzler: re-ping
Feb 22 14:42:01 <Borromini> adrianschmutzler: can you merge the DIR-860L fix into master & 21.02 pretty please https://patchwork.ozlabs.org/project/openwrt/patch/20210218131057.426197-1-foss@volatilesystems.org/
Feb 22 14:44:58 <ynezz> I quite don't get it why the default DTS has write protect on eMMC device, adding `disable-wp` allows me to finally flash omnia over uboot
Feb 22 14:45:54 <ynezz> rsalvaterra: so 2021.04 with this http://sprunge.us/GwYzpq works fine
Feb 22 14:57:24 <rsalvaterra> ynezz: Hm… weird. Maybe there's a good reason? kab-el?
Feb 22 15:01:55 <ynezz> let's find out https://lists.denx.de/pipermail/u-boot/2021-February/441964.html
Feb 22 15:02:31 <rsalvaterra> Nothing like a patch to stir things up, heh? :)
Feb 22 15:03:57 <rsalvaterra> Ouch. I need to refresh/rebase my generic patches to 5.10… :/
Feb 22 15:08:14 <guidosarducci> rsalvaterra: 5.10 big vs 5.4 in what sense? sources or binary?
Feb 22 15:09:23 <owrt-snap-builds> build #731 of lantiq/xway is complete: Failure [failed tools]  Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxway/builds/731  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, David Bauer <mail@david-bauer.net>, Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
Feb 22 15:11:50 <owrt-snap-builds> build #738 of ramips/mt76x8 is complete: Failure [failed kmods]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt76x8/builds/738  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>, David Bauer <mail@david-bauer.net>, Aleksander Jan Bajkowski <A.Bajkowski@stud.elka.pw.edu.pl>
Feb 22 15:12:08 <rsalvaterra> guidosarducci: Binary, of course. But I haven't tested an equivalent configuration (I usually don't build modules, my kernels are as monolithic as possible).
Feb 22 15:17:10 <guidosarducci> rsalvaterra: I thought you meant sources... I've been doing some surveys of our kernel sizes going way back (and a little forward), and was surprised to find the ath79 lzma'ed 5.10 kernel only ~30KB larger than 5.4.
Feb 22 15:17:25 <rsalvaterra> Heh… who cares about source code size? ;)
Feb 22 15:18:08 <owrt-2102-builds> build #9 of bcm63xx/generic is complete: Failure [failed gitcheckout]  Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/bcm63xx%2Fgeneric/builds/9  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>
Feb 22 15:18:10 <rsalvaterra> Linux sources get bigger because of drivers, basically. More drivers, more code.
Feb 22 15:18:50 <owrt-2102-builds> build #9 of layerscape/armv7 is complete: Failure [failed toolchain]  Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/layerscape%2Farmv7/builds/9  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>
Feb 22 15:19:04 <guidosarducci> rsalvaterra: usually our kernels grow by ~200KB/year last few years, which impacts future partitions, etc.
Feb 22 15:19:46 <rsalvaterra> guidosarducci: That's probably also related to compiler version bumps.
Feb 22 15:20:05 <rsalvaterra> For example, gcc 10 inlines much more aggressively.
Feb 22 15:20:39 <guidosarducci> rsalvaterra: yeah, but more functionality gets packed into the "monolithic" part too, even not turning on new stuff.
Feb 22 15:21:18 <guidosarducci> rsalvaterra: hmmm, I'd be really surprised if it was down to compilers, given how much tuning towards small sizes takes place.
Feb 22 15:22:19 <guidosarducci> rsalvaterra: and all my experiments used the default compiler.. too scared to use gcc 10 full time yet.
Feb 22 15:24:15 <rsalvaterra> I've been using gcc 10 for months, already… ath79 (24/74Kc), mipsel (mt7621), mvebu (cortexa9) and x86-64 compile and run perfectly.
Feb 22 15:27:01 <guidosarducci> rsalvaterra: and you're seeing big binary size increases? My usage has been testing with musl 1.2.x occasionally, so maybe more fragile than your usage.
Feb 22 15:28:32 <rsalvaterra> Oh, I haven't touched musl yet… I'll wait for mangix. :P
Feb 22 15:29:28 <owrt-snap-builds> build #734 of bcm53xx/generic is complete: Failure [failed gitcheckout]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm53xx%2Fgeneric/builds/734  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>
Feb 22 15:31:55 <owrt-snap-builds> build #767 of omap/generic is complete: Failure [failed gitcheckout]  Build details are at http://buildbot.openwrt.org/master/images/builders/omap%2Fgeneric/builds/767  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>
Feb 22 15:38:55 <owrt-2102-builds> build #9 of ipq40xx/mikrotik is complete: Failure [failed gitcheckout]  Build details are at http://buildbot.openwrt.org/openwrt-21.02/images/builders/ipq40xx%2Fmikrotik/builds/9  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>
Feb 22 15:43:29 <noltari> I'm loving all this sudden attention from the buildbots :P
Feb 22 15:52:55 <zx2c4> lipnitsk: things seem to more or less work for you?
Feb 22 15:57:16 <lipnitsk> zx2c4: testing now. I think they will though, because 'imply' seems to do the trick in upgrading CONFIG_PACKAGE_kmod-crypto-kpp from 'm' to 'y'
Feb 22 15:57:57 <lipnitsk> more general question though - since openwrt probably will never build these modules into the kernel, won't IS_REACHABLE always return false?
Feb 22 15:58:08 <lipnitsk> then we are really wasting space by adding kpp at all
Feb 22 16:01:08 <lipnitsk> maybe some OpenWrt build system changes are needed to support excluding certain optional dependencies, though not sure how prevalent this case really is.
Feb 22 16:04:53 <lipnitsk> zx2c4: I think there is wrinkle with your change - when I deselect CONFIG_PACKAGE_kmod-crypto-ecdh there are no more strong dependencies on CONFIG_PACKAGE_kmod-crypto-kpp, but it still gets set to 'y'. So the 'weak' thing doesn't appear to be working for me.
Feb 22 16:06:38 <lipnitsk> zx2c4: in fact, even making a brand new .config, and only enabling luci-app-wireguard will bring in KPP, sadly.
Feb 22 16:07:20 <zx2c4> lipnitsk: but, you can explicitly go in and uncheck KPP
Feb 22 16:07:42 <zx2c4> imply is annoying. it allows you to opt-out, but it opts you in by default
Feb 22 16:07:50 <zx2c4> but it's the closest we get to the weakdep that we need
Feb 22 16:08:58 <lipnitsk> zx2c4: you are right. I think my hack was probably a little more automatic, but more kludgy too :)
Feb 22 16:09:44 <lipnitsk> zx2c4: I was able to manually uncheck kpp (I guess you un-HIDDEN it?)
Feb 22 16:11:29 <lipnitsk> zx2c4: still it seems that IS_REACHABLE branches in curve25519 will never run on OpenWrt, unless I'm misunderstanding something
Feb 22 16:15:04 <kab-el> ynezz: I replied to your patch. It seems that U-Boot shouldn't be denying writes if disable-wp is not present, when there is no wp control mechanism (at least according to Linux mmc-controller device-tree binding documentation)
Feb 22 16:15:51 <ynezz> kab-el: thanks for the review, without this I'm not able to write anything to emmc
Feb 22 16:16:18 <ynezz> stock/vendor 2019.07 or latest 2021.04
Feb 22 16:16:30 <ynezz> any 'mmc write' call fails
Feb 22 16:17:19 <kab-el> ynezz: the correct solution here is to fix U-Boot's mmc code, to start behaving according to documentation
Feb 22 16:19:02 <ynezz> maybe it's just armada sdhci pins?
Feb 22 16:52:54 <grift> yes the file is mislabeled
Feb 22 16:52:59 <grift> wrong chn
Feb 22 17:00:57 <rsalvaterra> tmn505: ping
Feb 22 17:02:41 <rsalvaterra> tmn505: It's the first time I'm adding a reviewed-by tag, ever. Do I add it for each and every patch, or just the cover letter?
Feb 22 17:09:27 <tmn505> for each patch
Feb 22 17:09:55 <tmn505> the same with other tags
Feb 22 17:20:54 <rsalvaterra> Thanks, will do.
Feb 22 17:44:23 <rsalvaterra> tmn505: Sent. Some email threading weirdness with patch #1, I don't know what happened… :/
Feb 22 18:17:55 <tmn505> rsalvaterra: LGTM. The patches in patchwork ocasionally are clasified outside of the series but I don't know specifics, happened to me few times.
Feb 22 18:40:39 >KGB-2< https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (98.2% images and 98.4% packages reproducible in our current test framework.)
Feb 22 19:31:18 <rsalvaterra> tmn505: Yeah, it happened to me too on other occasions. Anyway, thanks for your patience! :)
Feb 22 20:21:17 <rmilecki> noltari: do you need "mtd fixtrx firmware"?
Feb 22 20:21:23 <rmilecki> does that target use trx at all?
Feb 22 20:44:04 <noltari> rmilecki: yes, it’s needed on some devices
Feb 22 20:44:13 <rmilecki> o
Feb 22 20:44:15 <rmilecki> ok
Feb 22 21:27:00 <lipnitsk> blocktrron: I see you made some small fixes - let me know if you want me to squash your kernel module .mk fixes into my kmod commit
Feb 22 21:30:14 <shibboleth> can "master" build a "generic" ath79 mikrotik image (like the ones for ar71xx/19.07) or will support for each model/device have to be added separately?
Feb 22 21:30:59 <shibboleth> like, for 1907 you'll find a couple of "generics", like nor/nand, small/large, ac/non-ac
Feb 22 21:38:32 <stintel> Borromini: Dubai!
Feb 22 21:39:59 <Borromini> stintel: to get vaccinated? :P
Feb 22 21:40:29 <Borromini> enjoy though!
Feb 22 21:40:30 <stintel> to get vitamin sea and sun
Feb 22 21:40:45 <stintel> don't need a vaccin, covid is a hoax
Feb 22 21:40:46 * stintel hides
Feb 22 21:41:36 <rsalvaterra> Oh, I survived an hoax! :P
Feb 22 21:41:41 <rsalvaterra> *a hoax
Feb 22 21:54:37 <Borromini> 💩
Feb 22 21:55:36 <blocktrron> lipnitsk: ill let you know
Feb 22 22:26:43 <mangix> jesus gettext is so slow to compile
Feb 22 22:27:10 <mangix> gotta love the garbage build system is has
Feb 22 23:53:28 <aparcar[m]> mangix: aren't there better alternatives?
Feb 23 00:13:34 <lipnitsk> does parallel not work with it for whatever reason?
Feb 23 01:11:20 <blocktrron> lipnitsk: successfully built mpc85xx-* as well as ath79-generic on 5.4 as well as 5.10 with the changes in my staging tree.
Feb 23 01:11:48 <blocktrron> I'll add some proper commit descriptions / squash them to your patches and apply them tomorrow evening
Feb 23 01:12:07 <lipnitsk> Great, thank you!
Feb 23 01:14:26 <blocktrron> :)
Feb 23 02:19:47 <philipp64> mangix: can I DM you?
Feb 23 02:20:42 <philipp64> lipnitsk: if you can fix the parallel build for a lot of these projects and upstream the fixes, then everyone wins...
Feb 23 02:22:59 <lipnitsk> philipp64: yeah, maybe I'll peek at it (haven't looked at all yet). Chances are it's some hornet's nest otherwise maybe it wouldn't have been a problem in the first place..
Feb 23 02:23:31 <philipp64> my recollection is that automake generates parallel-safe builds...
Feb 23 02:23:32 <lipnitsk> what do you mean by a lot of these projects?
Feb 23 02:23:46 <philipp64> but... not everyone uses autotools.
Feb 23 02:23:55 <lipnitsk> which ones are misbehaving to your understanding?
Feb 23 02:24:10 <lipnitsk> it's not just gettext?
Feb 23 02:28:09 <philipp64> libtool, uci, libxml2, mdnsresponder... freeswitch... there are a few.
Feb 23 02:28:33 <philipp64> might be more. just did a search but it wasn't exhaustive.
Feb 23 02:45:34 <lipnitsk> philipp64: what did you search for? PKG_BUILD_PARALLEL:=0 ?
Feb 23 02:45:51 <philipp64> yes
Feb 23 02:47:03 <lipnitsk> yeah, probably set to 0 for good reason ;) funnily enough gettext-full does have it set to 1
**** ENDING LOGGING AT Tue Feb 23 03:00:05 2021