**** BEGIN LOGGING AT Mon Feb 15 02:59:58 2021
Feb 15 03:12:37 <aparcar[m]> mangix: what did dango do?
Feb 15 03:19:49 <aparcar[m]> nevermind found it
Feb 15 03:20:15 <aparcar[m]> lipnitsk: did you test your script somewhere?
Feb 15 03:25:05 <lipnitsk> locally
Feb 15 03:25:15 <lipnitsk> by forcing PKG on a dirty package
Feb 15 03:28:12 <lipnitsk> aparcar[m]: basically tested that a dirty PKG is marked as dirty, but once clean, the script doesn't error. There is a chance that make package/PKG/refresh does not work on some packages, though I did a pass and fixed all of them a week or two ago
Feb 15 03:28:53 <lipnitsk> I think one improvement might be to fail with a different message if make package/$PKG/refresh failed for whatever reason
Feb 15 03:29:39 <lipnitsk> or at least do a || exit $? after make
Feb 15 03:34:54 <lipnitsk> aparcar[m]: I've tested every branch of the script locally and it performs as intended. I also just added the || exit $? to the make command as an improvement
Feb 15 03:38:29 <mangix> aparcar[m]: I've removed dnsmasq before as an experiment. odhcpd works as a DHCP server. The issue is DNS
Feb 15 03:41:40 <rr123> still quite a few build errors related to ubus, "incompatible with the architectures configured" https://pastebin.ubuntu.com/p/ZgY2ssVhZ5/
Feb 15 03:42:15 <rr123> Cannot satisfy the following dependencies for base-files:libblobmsg-json20201212
Feb 15 03:43:11 <rr123> tplink,archer-a7-v5, master branch fresh checkout
Feb 15 03:43:57 <aparcar[m]> mangix: iI think you're pretty good at C, can't you just code something?
Feb 15 03:44:20 <mangix> DNS is something I don't dare touch
Feb 15 03:44:32 <aparcar[m]> lipnitsk: okay I'll run an actual test with the CI in a bit
Feb 15 03:44:34 <aparcar[m]> thanks for the PR
Feb 15 03:45:54 <lipnitsk> okay, no problem. hope it makes mangix's life easier
Feb 15 03:55:31 <lipnitsk> aparcar[m]: Looking at the entrypoint.sh script, should V=s be replaced with V=$V everywhere?
Feb 15 03:56:57 <mangix> now there's the question of that treewide PR. As I alluded to, some patches need to be manually edited as they're two in one.
Feb 15 03:57:09 <aparcar[m]> lipnitsk: sounds good
Feb 15 04:00:07 <mangix> hahaha manual git am of that patch doesn't apply. of course now.
Feb 15 04:00:09 <mangix> *not
Feb 15 04:03:14 <lipnitsk> aparcar[m]: okay, pushed V=s -> V="$V" to same PR
Feb 15 04:04:34 <mangix> lipnitsk: I don't like how it changed utils/open-vm-tools/patches/0008-Rename-poll.h-to-vm_poll.h.patch . I remember manually adjusting it. Having said that, I wonder if the patch is even needed.
Feb 15 04:04:40 <lipnitsk> mangix: Yeah I can re-run the check (some packages are probably out of date now). Well the automated refresh shouldn't really make things worse, right? That's what quilt already does when preparing the package for building (even the horribly broken one)
Feb 15 04:05:54 <mangix> it doesn't but the change in that patch is questionable
Feb 15 04:06:07 <mangix> utils/mc/patches/010-subshell.patch also looks strange
Feb 15 04:06:16 <lipnitsk> mangix: agreed - actually I ran into the same thing with a patch I'm hoping to get merged in. Basically, quilt doesn't handle "rename from/rename to" well
Feb 15 04:06:28 <owrt-snap-builds> build #714 of zynq/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/zynq%2Fgeneric/builds/714
Feb 15 04:07:13 <mangix> LOL the issue with utils/mc/patches/010-subshell.patch is actually quite hillarious. it's missing a -
Feb 15 04:07:30 <lipnitsk> oh.
Feb 15 04:08:33 <lipnitsk> that is funny. why didn't it just remove the old stuff
Feb 15 04:09:17 <lipnitsk> looks like maybe we need to patch quilt itself :)
Feb 15 04:11:06 <mangix> to be fair, the patch is illformer
Feb 15 04:11:10 <mangix> *illformed
Feb 15 04:11:23 <lipnitsk> yeah, really just need a - in the first line
Feb 15 04:11:40 <lipnitsk> but I don't like that quilt can't handle renames, or is that a feature, not a bug?
Feb 15 04:13:58 <mangix> unfortunately i have no idea. maybe there's some option. it is bad though. when refreshing a patch, if the original file was changed, a quilt refresh will not keep the source file changes AFAIK.
Feb 15 04:14:55 <mangix> net/rpcbind/patches/002-fix_stack_buffer_overflow.patch is interesting in that quilt removed the description. I think it needs to be manually edited to remove the ====
Feb 15 04:18:07 <mangix> lang/python/python-requests/patches/0001-idna-dependency-bump.patch also needs to be split in two
Feb 15 04:18:12 <lipnitsk> well that's one disadvantage of forcing this I think is that quilt does seem to remove descriptions.
Feb 15 04:18:16 <mangix> that's all problems i see so far
Feb 15 04:18:41 <mangix> not usually. for that file specifically it's getting tripped up on the =========
Feb 15 04:19:35 <lipnitsk> okay, so renames are really the only showstopper here?
Feb 15 04:20:41 <mangix> yeah. Maybe I can get rid of that rename patch in open-vm-tools
Feb 15 04:21:42 <lipnitsk> fortunately that's the only one, at least in packages feed
Feb 15 04:22:11 <lipnitsk> my proposed patch will go into openwrt repo, so I'm okay.. But it's strange that quilt can't handle it. Seems like a potential feature
Feb 15 04:25:08 <mangix> hmmmm
Feb 15 04:25:25 <mangix> i think one way to fix it is with --diff=utility
Feb 15 04:28:01 <lipnitsk> what does it use by default? diff? git diff is probably what we want, if we can make it accept two files without a repo
Feb 15 04:28:19 <lipnitsk> git diff [<options>] --no-index [--] <path> <path> might work
Feb 15 04:28:44 <mangix> I'll do some tests once my toolchain compiles
Feb 15 04:29:27 <lipnitsk> let me see if I can make open-vm-tools refresh happier with git diff
Feb 15 04:30:29 <mangix> maybe passing diff -s also works
Feb 15 04:30:32 <mangix> no idea yety
Feb 15 04:30:34 <mangix> *yet
Feb 15 04:32:53 <owrt-snap-builds> build #761 of apm821xx/nand is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/apm821xx%2Fnand/builds/761
Feb 15 04:34:21 <owrt-snap-builds> build #794 of ramips/rt3883 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt3883/builds/794
Feb 15 04:35:00 <owrt-snap-builds> build #786 of lantiq/xway_legacy is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxway_legacy/builds/786
Feb 15 04:41:58 <owrt-snap-builds> build #784 of archs38/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/archs38%2Fgeneric/builds/784
Feb 15 04:45:32 <owrt-snap-builds> build #721 of bcm53xx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm53xx%2Fgeneric/builds/721
Feb 15 05:14:30 <lipnitsk> mangix: dug up this patch, looks like it never got merged into quilt: https://lists.gnu.org/archive/html/quilt-dev/2015-06/msg00002.html
Feb 15 05:15:10 <lipnitsk> although I'm not sure if renames would just work with that. Unlikely. His test cases didn't feature any renames: https://lists.gnu.org/archive/html/quilt-dev/2015-06/msg00001.html
Feb 15 05:17:23 <lipnitsk> it does seem like quilt is hard-coded to use GNU diff
Feb 15 05:17:45 <mangix> well, good news is that the open-vm-tools patch is useless
Feb 15 05:17:54 <mangix> seems some other ones are too
Feb 15 05:18:00 <lipnitsk> https://git.savannah.nongnu.org/cgit/quilt.git/tree/quilt/scripts/patchfns.in#n744
Feb 15 05:18:50 <lipnitsk> yeah that is good news. But we may still need a way to allow exceptions with renames, if we are going to enforce this in CI
Feb 15 05:20:21 <lipnitsk> or maybe there is some other kludgy way to achieve that - like handle renames as some separate task, not with quilt, or not with patches?
Feb 15 05:25:47 <owrt-snap-builds> build #773 of mediatek/mt7623 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7623/builds/773
Feb 15 05:25:57 <owrt-snap-builds> build #783 of mvebu/cortexa72 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/mvebu%2Fcortexa72/builds/783
Feb 15 05:27:07 <owrt-snap-builds> build #769 of armvirt/32 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F32/builds/769
Feb 15 05:29:59 <owrt-snap-builds> build #766 of mediatek/mt7622 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7622/builds/766
Feb 15 05:47:24 <owrt-snap-builds> build #784 of layerscape/armv8_64b is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/784
Feb 15 05:57:09 <owrt-snap-builds> build #645 of layerscape/armv7 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv7/builds/645
Feb 15 06:01:53 <owrt-snap-builds> build #645 of mediatek/mt7629 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7629/builds/645
Feb 15 06:16:57 <owrt-snap-builds> build #532 of bcm63xx/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fgeneric/builds/532
Feb 15 06:25:54 <owrt-snap-builds> build #754 of x86/geode is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2Fgeode/builds/754
Feb 15 06:26:54 <owrt-snap-builds> build #761 of kirkwood/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/kirkwood%2Fgeneric/builds/761
Feb 15 06:27:43 <owrt-snap-builds> build #294 of mpc85xx/p1010 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp1010/builds/294
Feb 15 06:41:19 <owrt-snap-builds> build #540 of bcm47xx/legacy is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm47xx%2Flegacy/builds/540
Feb 15 06:43:45 <mangix> Grommish: Can you comment on this? https://github.com/neheb/openwrt/commit/1e81d2afde2becfa82bdf4fdc1fb404756ac5ca4
Feb 15 06:51:37 <mangix> wait a minute....
Feb 15 06:51:48 <mangix> o32 is specific to mips32 only
Feb 15 07:06:33 <owrt-snap-builds> build #774 of ramips/rt288x is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt288x/builds/774
Feb 15 07:14:11 <owrt-snap-builds> build #834 of ath25/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath25%2Fgeneric/builds/834
Feb 15 08:00:29 <owrt-snap-builds> build #644 of ath79/tiny is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Ftiny/builds/644
Feb 15 08:15:42 <owrt-snap-builds> build #683 of lantiq/xrx200 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxrx200/builds/683
Feb 15 09:21:03 <mangix> rsalvaterra: you using turrisos?
Feb 15 09:22:10 <rsalvaterra> mangix: I used before OpenWrt supported the Omnia, yes.
Feb 15 09:22:27 <owrt-snap-builds> build #450 of ath79/mikrotik is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fmikrotik/builds/450
Feb 15 09:22:29 <rsalvaterra> But I haven't used it in years.
Feb 15 09:33:57 <owrt-snap-builds> build #775 of lantiq/ase is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fase/builds/775
Feb 15 09:56:49 <aparcar[m]> nbd: you just reverted the revert of the ABI changes?
Feb 15 09:57:41 <nbd> yes, because the reason for the revert is resolved
Feb 15 09:57:51 <nbd> there was a bug in patchelf
Feb 15 09:57:54 <nbd> and i merged the fix
Feb 15 10:05:59 <zorun> Hauke: I just merged the fix I wanted to have in 19.07.7, so it's good to go from my side
Feb 15 10:06:04 <zorun> I'll prepare the release notes
Feb 15 10:10:16 <rmilecki> pkgadd: thanks for the info! I'm wondering if openwrt2020 luci theme could be fixed, handling <button>s with CSS should be simple enough not to require "btn" class
Feb 15 10:10:40 <rmilecki> master has stopped building for me
Feb 15 10:10:41 <rmilecki> Package libuci is missing dependencies for the following libraries:
Feb 15 10:10:43 <rmilecki> libubox.so
Feb 15 10:11:23 <rmilecki> define Package/libuci contains DEPENDS:=+libubox
Feb 15 10:12:21 <rmilecki> libubox & PKG_ABI_VERSION is smells fishy
Feb 15 10:12:37 <rmilecki> i already tried rm -fr bin/ tmp/
Feb 15 10:15:33 <rmilecki> fun! Package jsonfilter is missing dependencies for the following libraries:
Feb 15 10:15:35 <rmilecki> libubox.so
Feb 15 10:20:57 <rmilecki> it seems we need to manually clean all libubox dependencies, i'm giving up after make package/{uci,libubox,jsonfilter,usign,firewall,odhcp6c}/clean V=s
Feb 15 10:21:29 <rmilecki> rm -fR build_dir/target-*
Feb 15 10:24:42 <nbd> rmilecki: did you have libubox unpacked with quilt or git-src?
Feb 15 10:26:22 <nbd> or maybe one of the other packages?
Feb 15 10:32:18 <rmilecki> nbd: i didn't use QUILT=1 if that answers your question
Feb 15 10:32:28 <rmilecki> nbd: i just let "make" do unpackaging & compiling
Feb 15 10:33:12 <nbd> i just tested making a change to the libubox abi version and it rebuilt jsonfilter as well
Feb 15 10:33:19 <nbd> so not sure where your build error is coming from
Feb 15 10:34:20 <rmilecki> nbd: can it be because my "git pull" pulled both: revert & your commit?
Feb 15 10:36:29 <mangix> jow: any plans to update the buildbots to debian 10?
Feb 15 11:22:14 <rmilecki> DonkeyHotei: i'm going to reference problem you got 1,5 year ago, be aware ;)
Feb 15 11:23:09 <rmilecki> DonkeyHotei: you got ath79 device with two denx,uimage partitions
Feb 15 11:23:27 <rmilecki> only 1 of them should be used for finding kernel & rootfs
Feb 15 11:23:39 <rmilecki> i added support for very similar case in BCM4908
Feb 15 11:24:09 <rmilecki> you can check my commit ac7d45b5e783fdd4ca35fe53a0921d8972f3f53b ("kernel: backport "ofpart" mtd parser upstream quirks support")
Feb 15 11:24:47 <DonkeyHotei> i was hoping a more universal solution could be deployed, as the upstream mainline kernel was getting some work to support such
Feb 15 11:25:42 <rmilecki> f00b4r0: ynezz: you were also dealing with device with similar problem I believe, 922UAGS-5HPacD I think
Feb 15 11:26:24 <f00b4r0> rmilecki: I don't have the backlog, what's this about?
Feb 15 11:27:10 <rmilecki> f00b4r0: [2020-03-20] [09:07:10 CET] <ynezz>  rmilecki: f00b4r0 wants to fix Mikrotik devices in ath79 properly, as Mikrotik seems to use dynamic mtd partitions (on some models?), probably due to variable size of the bootloader, apparently some partitions have tags and can be identified programatically, do you've any idea how to approach that in upstreamable fashion?
Feb 15 11:27:51 <f00b4r0> rmilecki: you're aware that I've put code to do just that in the tree, right? :)
Feb 15 11:28:00 <rmilecki> f00b4r0: no
Feb 15 11:28:19 <rmilecki> f00b4r0: can you point me to that?
Feb 15 11:28:31 <f00b4r0> https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/files/drivers/mtd/parsers/routerbootpart.c;h=f9bba0f3ba15ecc3c033a046728236be3202f970;hb=HEAD
Feb 15 11:28:55 <f00b4r0> not a model of elegance, I'll admit readily. But it works.
Feb 15 11:30:13 <rmilecki> f00b4r0: thanks, i'll check that!
Feb 15 11:30:19 <f00b4r0> np, yw
Feb 15 11:30:56 <f00b4r0> it's basically an enhanced version of ofparts
Feb 15 11:31:04 <DonkeyHotei> rmilecki: your patch is moved to generic but is still specific to the bcm4908
Feb 15 11:31:17 <f00b4r0> I wish i could have avoided some code duplication, but couldn't find a way to do so.
Feb 15 11:31:35 <rmilecki> DonkeyHotei: i moved it to generic as it's upstream backport that other targets may want to use as well
Feb 15 11:31:41 <rmilecki> DonkeyHotei: bcm53xx will need that too
Feb 15 12:17:24 <DonkeyHotei> rmilecki: this is the mechanism "blessed" by upstream as i understand it: https://lore.kernel.org/patchwork/patch/1047244/
Feb 15 12:17:53 <DonkeyHotei> but last i checked, it was still being worked on
Feb 15 12:18:06 <DonkeyHotei> i've lost track of its progress
Feb 15 12:27:46 <DonkeyHotei> at the time, i wanted to talk to christian lamparter about it, but he didn't come back to irc, and i later forgot the details
Feb 15 12:30:23 <owrt-snap-builds> build #755 of omap/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/omap%2Fgeneric/builds/755
Feb 15 12:30:30 <DonkeyHotei> if the relevant patches got mainlined while i wasn't paying attention or might soon be, then all archs should be updated to use this
Feb 15 12:31:24 <owrt-snap-builds> build #787 of lantiq/xway_legacy is complete: Failure [failed kmods]  Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxway_legacy/builds/787  blamelist: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>, Rafa? Mi?ecki <rafal@milecki.pl>, Felix Fietkau <nbd@nbd.name>
Feb 15 12:31:44 <DonkeyHotei> it would eliminate ugly hacks on ppc and ipq40xx
Feb 15 12:32:04 <xback> blogic: hi.  Any luck with the NAND on the rb912?   just 2 know if you are still working on it or if I should look futher myself :-)
Feb 15 12:44:54 <russell--> xback: is this a case of kernel-too-bit-for-routerboot?
Feb 15 12:45:17 <russell--> big*
Feb 15 12:48:43 <blogic> xback: i got part done then got side tracked
Feb 15 12:48:55 <blogic> shall I mail you latest patch version that I have ?
Feb 15 12:51:44 <xback> blogic: yes. please do :-)
Feb 15 12:51:47 <xback> appreciated!
Feb 15 12:52:16 <xback> russell--: No, it's not.   this is about adding support for rb912 to ath79 in master
Feb 15 12:59:15 <blogic> xback: sent
Feb 15 12:59:23 <xback> tyvm
Feb 15 12:59:27 <blogic> basically the read and write functions are left to make work
Feb 15 12:59:43 <blogic> also still some commented out code in there where i bumped apis
Feb 15 13:00:03 * rmilecki starts wondering if he didn't break fixed-partitions
Feb 15 13:01:27 <rmilecki> i fuc* did
Feb 15 13:07:43 <xback> blogic: could it be you forgot to send a part?   you mention commenting out some code but it's not reflected in the patch you've sent me :-)
Feb 15 13:21:56 <Hauke> nbd: thank you for adding it again
Feb 15 13:23:42 <Hauke> rmilecki: the lantiq/xway_legacy build failed becasue of some mtd patch not applying, could you have a look please
Feb 15 13:24:11 <rmilecki> Hauke: i broke things totally, I'm working on it right now
Feb 15 13:24:22 <Hauke> rmilecki: thanks
Feb 15 13:32:14 <blogic> xback: yeah, sent it just now
Feb 15 13:35:51 <rmilecki> i'll get mtd fixed in ~30 minutes, hopefully less
Feb 15 13:35:59 <rmilecki> i'm also working with mtd guys at the same time on it
Feb 15 13:37:15 <Tapper> rmilecki is mtd broken on all targets? I just did a build from master is it ok to flash?
Feb 15 13:37:28 <rmilecki> Tapper: don't know your devices, better wait
Feb 15 13:38:27 <nick[m]1> ping aparcar please finally merge the luci-app-babeld stuff :D https://github.com/openwrt/luci/pull/4791
Feb 15 13:53:24 <owrt-snap-builds> build #662 of ath79/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fgeneric/builds/662
Feb 15 14:05:22 <rr123> target/linux/ath79/patches-5.4/404-mtd-cybertan-trx-parser.patch using plaintext: patching file drivers/mtd/parsers/Makefile Hunk #1 FAILED at 5.
Feb 15 14:07:46 <rmilecki> Hauke: Tapper: rr123: fix pushed
Feb 15 14:08:02 <rmilecki> sorry for that
Feb 15 14:08:13 <ynezz> nbd: there seems to be something funky going on with the build, running `for run in $(seq 1 3); do echo "building for $run time..."; echo "$(time make -j8 > /dev/null 2>&1)"; done` yields 23min for the 1st run, 30min for the 2nd run...
Feb 15 14:20:51 <nbd> ynezz: maybe you can do the test runs with BUILD_LOG=1 to see if we have spurious rebuilds in there somewhere
Feb 15 14:25:23 <hurricos> rmilecki: Do you recall fixups for flowrings in brcmfmac?
Feb 15 14:25:36 <rmilecki> hurricos: i don't
Feb 15 14:26:20 <hurricos> s/.*//; -- no problem, I will probably just flyspray the bug instead, the stack trace when brcmfmac crashes on ppc32 has much more information.
Feb 15 14:29:24 <rmilecki> hurricos: send me a link please
Feb 15 14:29:32 <Hauke> hurricos: did I break brcmfmac with the mac80211 update?
Feb 15 14:30:48 <hurricos> rmilecki: I will. Fairly sure nobody broke anything. This is nonstandard configuration that was never confirmed-working.
Feb 15 14:30:59 <blogic> Cloning into './feeds/packages'...
Feb 15 14:31:00 <blogic> fatal: unable to access 'https://git.openwrt.org/feed/packages.git/': GnuTLS recv error (-24): Decryption has failed.
Feb 15 14:31:03 <blogic> failed.
Feb 15 14:31:05 <blogic> ermmm
Feb 15 14:31:35 <blogic> ok, rerunning that and it works
Feb 15 14:32:28 <hurricos> bcm4366c as mPCIe card (eBay bcm43465) in Aerohive HiveAP 330. I have to rebuild with symbols
Feb 15 14:38:50 <rr123> Package wpad-wolfssl is missing dependencies for the following libraries:libubox.so.20201212
Feb 15 14:48:35 <rr123> Hauke: you reverted libubox but it's re-reverted back?
Feb 15 14:58:42 <Borromini> rr123: does a make clean/compile fix it?
Feb 15 14:59:04 <Borromini> on those single packages (wpad-wolfss, maybe also libubox)
Feb 15 15:14:26 <ynezz> nbd: I've removed tmp, then 1st was 17m17s, 2nd 2m23s, 3rd 2m22s so seems better now
Feb 15 15:14:58 <ynezz> but I was bisecting so maybe hit some corner case
Feb 15 15:35:30 <enyc> OoooOoo   21.02 goals now includes  "Add AX support.  "
Feb 15 15:35:47 <enyc> I guess that means, initial support, and only on a few targets
Feb 15 15:36:09 <enyc> aiui there is a very complex feature set in wifi-6 etc.
Feb 15 15:36:47 <rr123> Borromini: you're right, clean hostapd and libubox and the build completed
Feb 15 15:37:08 <Borromini> enyc: i think only Mediatek support (MT7915 probably)
Feb 15 15:37:22 <Borromini> rr123: good :)
Feb 15 15:46:10 <adrianschmutzler> apm821xx/sata und mvebu/cortexa53 still fail with:
Feb 15 15:46:13 <adrianschmutzler> pkg_hash_fetch_best_installation_candidate: Packages for fdisk found, but incompatible with the architectures configured
Feb 15 15:49:09 <Borromini> adrianschmutzler: hi! can i prod you to accept the following? :) https://patchwork.ozlabs.org/project/openwrt/patch/20210214100322.246853-1-sander@svanheule.net/
Feb 15 15:49:30 <Borromini> i've been testing the device for weeks now (mostly because of the 5 GHz wireless driver)
Feb 15 15:49:55 <adrianschmutzler> Borromini: I probably won't have time for reviewing a device support right now.
Feb 15 15:50:12 <Borromini> ok.
Feb 15 15:50:16 <adrianschmutzler> But I could be convinced into "backporting" something like this after 21.02 branch easily
Feb 15 15:50:40 <Borromini> ok, cool. would be nice if it could make it into 21.02 releases still :)
Feb 15 15:52:56 <nbd> adrianschmutzler: btw. i just now noticed that you removed the generic profiles from some targets
Feb 15 15:53:01 <nbd> let me explain why those profiles were there in the first place
Feb 15 15:53:37 <nbd> the point was to have a default selection that builds a common image that works on all devices supported by the target
Feb 15 15:53:49 <nbd> instead of selecting just one random device that the target supports
Feb 15 15:54:05 <nbd> (random == the first one from the alphabetically sorted list)
Feb 15 15:54:32 <adrianschmutzler> nbd: that's what I thought it does. But does this make sense on ath79?
Feb 15 15:54:59 <adrianschmutzler> because that's why I only removed it on specific targets where I thought it's moot ...
Feb 15 15:55:42 <enyc> Borromini: and that not to hold up the fork/release too much?
Feb 15 15:56:04 <adrianschmutzler> nbd: maybe it makes sense to have it for a mere target build test ...
Feb 15 15:58:02 <nbd> the default config is a trade-off
Feb 15 15:58:16 <nbd> it may not include some big drivers that are only needed for a few devices
Feb 15 15:58:24 <nbd> but it should produce something that boots fine on all devices
Feb 15 15:58:31 <adrianschmutzler> without dts?
Feb 15 15:58:52 <nbd> what do you mean?
Feb 15 15:59:01 <Borromini> enyc: from seeing what's on patchwork it looks like more about ax support in hostapd, so maybe not driver level. there's quite a bit of ax stuff in the mt76 driver already and that just got bumped yesterday in master as well
Feb 15 15:59:35 <nbd> i mean it still builds one image per device (with the per-device dts of course), but only one rootfs
Feb 15 16:00:21 <adrianschmutzler> does it? hmm ...
Feb 15 16:01:16 <adrianschmutzler> how is that different from multi-profile without rootfs_per_device?
Feb 15 16:01:50 <nbd> the main difference is that it doesn't build in all device specific packages
Feb 15 16:02:13 <nbd> for instance on ath79 it would not build in all the different ath10k firmwares
Feb 15 16:02:21 <nbd> because that would bloat up the default rootfs a lot
Feb 15 16:02:40 <adrianschmutzler> okay, I understand.
Feb 15 16:03:01 <adrianschmutzler> I'm still not sure whether we really need this, particularly since nobody cried so far.
Feb 15 16:03:25 <adrianschmutzler> But if you think it's valuable, feel free to revert my commits.
Feb 15 16:03:43 <nbd> ideally i'd like to replace it with something cleaner
Feb 15 16:03:48 <nbd> but i don't have a good solution yet
Feb 15 16:03:50 <adrianschmutzler> But be aware that there are targets where it never has been added in the first place.
Feb 15 16:04:01 <ynezz> nbd: so now i'ts 4m40s for 3 consecutive builds, git revert 8597da20acce b12288fa69b1 f421fefa8a34 c92165038217 2591c83b3406 a933c26852b8 f378d81da6d1 and it's around 30s
Feb 15 16:04:06 <adrianschmutzler> Or ramips, where five subtargets had it and one didn't
Feb 15 16:04:09 <rr123> my openwrt build sysupgrade.bin increase 200KB in the last two days, no config changes other than git-pull and rebuild
Feb 15 16:04:53 <ynezz> nbd: 4min difference seems like quite huge overhead for "just" that ABI changes
Feb 15 16:04:54 <rr123> some new packages made it from 8061740 to 8323884
Feb 15 16:04:57 <adrianschmutzler> I personally just removed it because I did not see an important point to have it, and nobody cried after I put it on the list.
Feb 15 16:05:24 <rr123> 260KB that is
Feb 15 16:05:29 <adrianschmutzler> So, I have no strong opinion or interest there
Feb 15 16:06:00 <Borromini> rr123: new extra required packages?
Feb 15 16:06:35 <nbd> ynezz: seems to me like there must be some spurious rebuild in there somewhere
Feb 15 16:06:43 <adrianschmutzler> And at some point, we have to discuss this whole DEVICE_PACKAGES subject anyway, since we have that other problem with initramfs
Feb 15 16:07:04 <nbd> ynezz: can you figure out what it keeps rebuilding in your test or where it spends most of the time?
Feb 15 16:10:10 <rr123> Borromini: just did a binwalk -e, and found the increased 260KB(after unsquash it's >1MB) is mainly from libubox
Feb 15 16:10:17 <nbd> ynezz: ah, i think i may have found it
Feb 15 16:10:57 <rr123> in fact under /lib, libblobmsg_json.so.20201212 libjson_script.so.20201212 libubox.so.20201212 are each 200KB+ now
Feb 15 16:11:10 <rr123> something is wrong with dynamic library soft links there
Feb 15 16:11:44 <rr123> let me reflash it to the board and see if that's true
Feb 15 16:11:57 <Borromini> rr123: that sounds fishy indeed
Feb 15 16:13:09 <nbd> ynezz: please test if this helps: https://termbin.com/9l98
Feb 15 16:14:23 <enyc> Borromini: hrrm, regression potential? etc hrrm
Feb 15 16:16:38 <Borromini> it's master eh? :P
Feb 15 16:17:25 <rr123> https://imgur.com/a/dkNEavE  yes libubox/libblogmsg/ etc definitely messed up with size after installation
Feb 15 16:18:28 <rr123> the naming style might be too much for long-standing practice buried in some scripts somewhere, never saw shared library named things like libubox.so.20201212...some scripts might not expect that style
Feb 15 16:19:05 <karlp> they better not care... :)
Feb 15 16:19:23 <karlp> and if they are, they "correctly" depended on teh ABI they intended :)
Feb 15 16:20:35 <nbd> i think it's another bug in patchelf
Feb 15 16:20:51 <nbd> it seems to mess up the ELF headers somehow
Feb 15 16:21:51 <Borromini> is the .so/.so.$ABI split intended?
Feb 15 16:22:19 <Borromini> oh nevermind, there's just one libubox.so.$ABI
Feb 15 16:23:27 <Borromini> rr123: that's beefy. Feb 13th master build here and libubox is 33351
Feb 15 16:23:30 <Borromini> that's x10
Feb 15 16:25:53 <rr123> libwolfssl.so.4.6.0.66253b90 increased 100K from libwolfssl.so.24.3.0, jshn increase from 16 to 144KB
Feb 15 16:29:26 <joaohcca> adrianschmutzler do you think you'll be able backport ath79 support from https://github.com/openwrt/openwrt/pull/3319 to 20.02 ?
Feb 15 16:30:38 <ynezz> nbd: 1st run 5:44, 2nd run 4:11, 3rd run 4:19
Feb 15 16:33:07 <ynezz> nbd: revert, 1st 0:41, 2nd 28s, 3rd 28s
Feb 15 16:42:28 <ynezz> nbd: http://sprunge.us/xctaRr
Feb 15 16:42:51 <ynezz> + is addition in log from the longer run
Feb 15 16:43:25 <ynezz> that's comparison of the 1st run with and without the ABI changes
Feb 15 16:44:27 <ynezz> that 1st run takes longer due to fresh config and defconfig
Feb 15 16:47:03 <nbd> i think i'll abandon the patchelf idea, it seems to be too fragile
Feb 15 16:47:36 <nbd> better to just patch packages to allow the build to specify soname
Feb 15 17:58:49 <nbd> ynezz: pushed some commits that remove the soname patching and instead build libubox and wolfssl with the updated soname
Feb 15 17:59:01 <nbd> please test if it's still slow for you
Feb 15 17:59:22 <nbd> rr123: this will also fix the size issues you were running into
Feb 15 18:11:24 <ynezz> ugh it seems like it's rebuilding kernel now
Feb 15 18:12:23 <ynezz> maybe due to rebase
Feb 15 18:22:19 <shibboleth> so, for 1907/ar71xx there are "generic" images on openwrt.org for mikrotik devices. when building master it seems to insist on generating device-specific images
Feb 15 18:22:21 <ynezz> nbd: magic! 1st 7:06, 2nd 0:21, 3rd 0:22
Feb 15 18:22:32 <ynezz> thanks!
Feb 15 18:22:37 <nbd> cool
Feb 15 18:22:40 <nbd> thanks for testing
Feb 15 18:22:50 <shibboleth> is there a way to generate "generic" images like the ones for 1907?
Feb 15 18:40:05 <Grommish> Oo.. So, what's broken with libubox?  I saw someone mention something on it earlier but I just hit the wall with it
Feb 15 18:42:06 <Grommish> Package libuci is missing dependencies for the following libraries: libubox.so
Feb 15 18:43:36 <Borromini> Grommish: still broken with latest master?
Feb 15 18:44:01 <Grommish> I just rebased a few hours ago, so.. yes
Feb 15 18:44:22 <Grommish> It's there though in the file.. ./target-mips64_octeonplus_64_musl/root-octeon/lib/libuci.so
Feb 15 18:44:30 <Borromini> well last push is 45' ago
Feb 15 18:44:34 <Grommish> and ./target-mips64_octeonplus_64_musl/uci-2020-10-06-52bbc99f/libuci.so
Feb 15 18:44:42 <Grommish> Gotcha.. I was building.. I'll rebase
Feb 15 18:44:48 <Borromini> with the ABI stuff involved
Feb 15 18:46:02 <Grommish> Rebased .. I'll clean and build.. Thanks Borromini :)
Feb 15 18:46:15 <Borromini> well i'm doing one myself, just hoping it's fixed ;)
Feb 15 18:46:29 <Grommish> Someone found another reason for rust-lang, so it's getting some interest finally hehe
Feb 15 18:47:13 <Borromini> =)
Feb 15 18:47:34 <Borromini> i'm also getting uci build failuers now
Feb 15 18:47:38 <Borromini> * failures
Feb 15 18:48:26 <Grommish> Do me a favor while you're digging thru you source?
Feb 15 18:48:41 <Grommish> and run: ls ./staging_dir/toolchain-*_gcc-*/bin/*-gcc and DM me with it?
Feb 15 18:54:37 <Grommish> Well, at least I'll have time to look at stuff.. they are calling for upto 40cm of snow over the next 3 or 4 days
Feb 15 18:54:58 <Grommish> I'm not going anywhere. time to turtle up
Feb 15 18:56:38 <Borromini> US?
Feb 15 18:57:52 <Grommish> Yeah.. Ohio
Feb 15 18:58:03 <Borromini> :)
Feb 15 18:58:44 <Grommish> Not as bad as Texas because we see snow more often but it'll not be fun
Feb 15 18:59:00 <Grommish> Those poor folks just don't have the infrastructure for that kinda weather
Feb 15 18:59:43 <Borromini> ok
Feb 15 19:14:29 <Grommish> Borromini: I just finished building out with ndb last push
Feb 15 19:14:54 <Grommish> My HEAD is at 542eab31a6 and it worked after I cleaned
Feb 15 19:17:10 <jmv> Hi, any reason uhttpd / luci-ssl is not starting on snapshot? The first error in logread is that it can not find libubox.so, even though opkg install libubox says it is up to date. Thanks.
Feb 15 19:17:45 <shibboleth> sorry for repeating myself, but: so, for 1907/ar71xx there are "generic" images on openwrt.org for mikrotik devices. when building master it seems to insist on generating device-specific images
Feb 15 19:21:14 <Grommish> jmv: Luci isn't installed by default on Snapshots
Feb 15 19:21:36 <Grommish> jmv: but there was a libubox/libuci issue that was just pushed an hour ago
Feb 15 19:22:14 <Grommish> jmv: So maybe just wait a cycle if you aren't building locally.. I just built out from that error and it was corrected with commit 542eab31a6
Feb 15 19:24:07 <Borromini> Grommish: it works here too, but full (util-linux) dmesg doesn't want to cooperate here
Feb 15 19:24:18 <Grommish> Or rather, it BUILDS.. I've not flashed
Feb 15 19:26:00 <Borromini> me neither :P
Feb 15 19:26:23 <Borromini> mangix: cbedb5de75440b336072ee32bf97a81fac529a6a is breaking dmesg build for me on mt7621
Feb 15 19:43:31 <Borromini> mangix: error i'm seeing is "pkg_hash_fetch_best_installation_candidate: Packages for dmesg found, but incompatible with the architectures configured"
Feb 15 19:44:01 <rr123> updated master and now everything seems fine to me
Feb 15 19:46:15 <philipp64> What's Rosen's handle?  For that matter, where is the real name to handle mapping for this channel?
Feb 15 19:46:40 <Borromini> philipp64: mangix
Feb 15 19:46:54 <philipp64> right. thanks
Feb 15 19:47:04 <Borromini> philipp64: util-linux problem?
Feb 15 19:47:09 <philipp64> mangix: wither art thou?
Feb 15 19:47:14 <philipp64> um, no. why?
Feb 15 19:47:30 <Borromini> i'm seeing one and his commit seems to blame :P
Feb 15 19:54:38 <philipp64> link?
Feb 15 19:56:11 <Grommish> Rosen? Neheb
Feb 15 19:56:14 <Grommish> I believe
Feb 15 19:57:04 <jmv> Also, on x64 master on virtualbox: opkg install rpcd-mod-rrdns (normally for luci-ssl) gives "command not found". Don't know which command would be missing.
Feb 15 19:57:16 <Grommish> but I could be wrong.. I'm not up on everyones name heh
Feb 15 19:57:40 <EqUaTe> jmv: normally I'd say that would be opkg
Feb 15 19:58:17 <EqUaTe> though if opkg is a script of some sort (having not looked closely at it in a very very long time), then it could be something it is calling that is an external binary (or even the script processor - eg perl)
Feb 15 19:58:30 <jmv> It says: configuring rpcd-mod-rrdns. Command filed: Not found.
Feb 15 19:58:31 <Borromini> philipp64: cbedb5de75440b336072ee32bf97a81fac529a6a is a util-linux one, but once i revert that and build, even a make package/dmesg/{clean,compile} without the revert works again
Feb 15 19:59:13 <jmv> "command failed: Not found"
Feb 15 19:59:51 <EqUaTe> something in the postinst script for rpcd-mod-rrdns then, presuming that that package name is accurate
Feb 15 19:59:59 <philipp64> jmv: I see that too sometimes for other packages... haven't dug into what causes it.  I see it when I do a "stop" on an init script that isn't running, for instance...
Feb 15 20:01:41 <jmv> Same for opkg install rpcd-mod-luci.
Feb 15 20:01:55 <ynezz> nbd: just pulled again your latest changes and it's back to 4min28sec
Feb 15 20:04:23 <philipp64> Borromini: hmm.... if you build both ways and then diff the resultant directories in build_dir/target-xyzzy/... etc. what shows up as diffs between the two builds?
Feb 15 20:06:13 <Grommish> The build system doesn't use ccache by default, correct?
Feb 15 20:07:59 <Borromini> philipp64: how would one do that?
Feb 15 20:10:44 <Borromini> besides building different targets
Feb 15 20:14:02 <nbd> ynezz: just found another old bug that was causing spurious rebuilds
Feb 15 20:15:22 <Borromini> mangix: for what it's worth: https://paste.debian.net/1185622/
Feb 15 20:27:45 <Hauke> did someone look into the problem with opkg and fdisk on some targets?
Feb 15 20:28:21 <Hauke> some builds are failing because of some strange error "Packages for fdisk found, but incompatible with the architectures configured"
Feb 15 20:28:42 <Hauke> I can reproduce it now and will have a look
Feb 15 20:28:43 <Borromini> Hauke: i am seeing something similar with dmesg here
Feb 15 20:28:53 <Borromini> Hauke: https://paste.debian.net/1185622/
Feb 15 20:29:35 <Hauke> Borromini: thanks for the info
Feb 15 20:29:39 <Borromini> mangix: sorry for the noise the revert helping seems to have been a one-off
Feb 15 20:29:47 <Hauke> most of the fails in build bot are caused by this: http://buildbot.openwrt.org/master/images/waterfall
Feb 15 20:30:22 <Borromini> Hauke: doing a make package/util-linux/{clean,compile} helps for the package itself but not for the full build
Feb 15 20:31:03 <rr123> incompatible with the architectures -- looks familiar, with the newest master along with a fresh build might get that cleaned?
Feb 15 20:32:36 <Grommish> Borromini: That is a different package than the busybox dmesg?
Feb 15 20:32:40 <Borromini> rr123: i've done a make clean already, no dice
Feb 15 20:32:51 <Borromini> Grommish: yes it's a 'full' dmesg, part of util-linux
Feb 15 20:34:01 * rr123 does not use util-linux dmesg, try to enable and build now
Feb 15 20:34:05 <Grommish> Ok.. I'll try that package when/if this build finishes
Feb 15 20:34:36 <Grommish> to see if its target dependent
Feb 15 20:35:16 <Borromini> ok
Feb 15 20:36:37 <rr123> 23767 Feb 15 14:35 packages/mips_24kc/base/dmesg_2.36.1-2_mips_24kc.ipk  built fine for me
Feb 15 20:37:21 <Borromini> rr123: my package architecture is mipsel_24kc, and it has built fine for ages
Feb 15 20:37:36 <Borromini> i'm not seeing any weirdness about architectures in the util-linux Makefile either
Feb 15 20:38:11 <owrt-snap-builds> build #97 of realtek/generic is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/realtek%2Fgeneric/builds/97
Feb 15 20:50:25 <Borromini> rr123: the package gets built just fine, it's just the final image stage that seems to throw that error
Feb 15 20:52:17 <rr123> that just reminds me the libubox thing since yesterday, some endian weirdness
Feb 15 20:55:57 <Borromini> i've done a make clean and manually removed the toolchains as well from staging_dir, so it's squeaky clean. it really seems an image stage level error at this point (no idea if your libubo error was as well)
Feb 15 20:56:48 <Hauke> Borromini: I am bisecing the problem
Feb 15 20:57:38 <Borromini> Hauke: ok
Feb 15 20:57:56 <Borromini> just wanted to make sure i was still sane after my own local breakage :)
Feb 15 21:02:38 <philipp64> Borromini: I'd build a problematic target, like "dmesg", both with and without the problematic commit... after each build, save the build directory out as "cp -a build_dir/target-xyzzy/dmesg-n.n.n/ build_dir/target-xyzzy/dmesg-n.n.n-patched/" (or whatever, and again for "unpatched")... then when you have both builds, do "diff -urN build_dir/target-xyzzy/dmesg-n.n.n-{unpatched,patched}/ipkg-arch/" and share a pastebin of that...
Feb 15 21:03:03 <lipnitsk> are there plans on using CI to compile patches/PRs for openwrt similar to feeds/packages? Should make trunk more stable
Feb 15 21:03:27 <Borromini> philipp64: ok, but i was wrong. reverting the last util-linux commit didn't help any.
Feb 15 21:03:32 <philipp64> Hauke: we were just talking about "Packages for fdisk found, but incompatible with the architectures configured"... I've been seeing that for a while now... maybe 5 weeks?
Feb 15 21:04:31 <philipp64> well, not for fdisk, but for other packages.
Feb 15 21:04:49 <philipp64> Odd that our CI/CD didn't detect that.
Feb 15 21:05:33 <philipp64> Maybe we should add a step of pre-installing the prior build of the package, and then re-installing (upgrading) via the pipeline result, and making sure that happened?
Feb 15 21:06:04 <karlp> lipnitsk: that would require all submissions to be proposed as patches/PRs first...
Feb 15 21:06:04 <philipp64> Who owns the CI/CD, anyway?  Charpentier used to be very involved in that but that was a couple of years ago.
Feb 15 21:06:49 <philipp64> karlp: that wouldn't be a bad thing.
Feb 15 21:07:02 <lipnitsk> karlp: uhm, that's most of the changes already, isn't it? Pushing straight to master is a bit of a cowboy approach :)
Feb 15 21:07:51 <lipnitsk> if CI was reasonably responsive then forcing PRs wouldn't be a bad idea.
Feb 15 21:08:34 <philipp64> Hauke: here's another example: https://github.com/openwrt/packages/issues/14735
Feb 15 21:09:17 <karlp> philipp64: never said it was :)
Feb 15 21:09:32 <philipp64> lipnitsk: I think a lot still gets reviewed via mailing out patches, and then individual sandboxes get themselves rebased into master...
Feb 15 21:10:36 <philipp64> though as I remember, patchwork has the option to run a backend on any submitted patches... so we could hook up to CI/CD there, too.
Feb 15 21:11:45 <lipnitsk> AFAIK packages uses github actions so could tap into those resources too (especially if they are 'free'). But yeah, staging trees and patchwork would need to be addressed somehow
Feb 15 21:12:23 <rmilecki> this ain't a good day for OpenWrt deps :|
Feb 15 21:12:29 <rmilecki>  * pkg_hash_fetch_best_installation_candidate: Packages for ubus found, but incompatible with the architectures configured
Feb 15 21:12:30 <rmilecki>  * satisfy_dependencies_for: Cannot satisfy the following dependencies for base-files:
Feb 15 21:12:31 <rmilecki>  *      libubus20191227
Feb 15 21:12:57 <lipnitsk> maybe enable CI for staging trees also, especially if it 'just works' with github. That would force staging trees to migrate to github, but then staging tree merges can just become PRs...
Feb 15 21:13:21 <lipnitsk> not that we want to totally rely on github, but why not use it while it fits the bill
Feb 15 21:14:37 <lipnitsk> I'm sure this is something folks like aparcar[m] have considered - I'm new to the game here, so just trying to make sense of it
Feb 15 21:14:51 <Borromini> rmilecki: Hauke is looking into it :)
Feb 15 21:14:52 <philipp64> aparcar[m]: you've got fingerprints on "opkg" (as does dangowrt)... could the last commit of "opkg" (Christmas eve) have broken anything?
Feb 15 21:15:03 <Hauke> this is the last change to opkg, but it looks fine to me: https://git.openwrt.org/?p=project/opkg-lede.git;a=commitdiff;h=9bbc7eae91edc3dbb020e2a50d51d9a3fbbf31ca
Feb 15 21:15:14 <Hauke> this was merged on 24. Dec
Feb 15 21:15:32 <Hauke> build bot saw it the first time yesterday
Feb 15 21:15:49 <aparcar[m]> Why the delay?
Feb 15 21:16:13 <nbd> typically that msg appears when a dependency can't be resolved, i think
Feb 15 21:16:27 <rmilecki> Borromini: Hauke: i fixed above problem by rm -fR bin/ tmp/
Feb 15 21:19:29 <philipp64> the dependency wouldn't be resolved if somehow the meta-information wasn't being generated correctly or the format had changed... for eample.
Feb 15 21:19:46 <Borromini> rmilecki: let's hope it's as easy as that. giving it a go
Feb 15 21:20:04 <philipp64> is there a way to run opkg with debugging options so we could see what's going on inside?
Feb 15 21:21:31 <philipp64> Actually, the prior commit looks more high-risk...
Feb 15 21:21:31 <dorf> opkg --verbosity=4
Feb 15 21:21:36 <philipp64> https://git.openwrt.org/?p=project/opkg-lede.git;a=commitdiff;h=efb26a35e4e5446f135307c4ff7df9e9563c23a9
Feb 15 21:21:58 <philipp64> dorf: thanks, I'll try that next time it happens.
Feb 15 21:22:50 <philipp64> Hauke: actually, since you're seeing it now, can you pastebin results?
Feb 15 21:23:50 <Borromini> rmilecki: thanks, that it does indeed.
Feb 15 21:23:52 <Borromini> Hauke: ^^
Feb 15 21:24:13 <Borromini> so probably something in tmp/ since i had wiped bin/ before
Feb 15 21:24:31 <Grommish> There was an ABI commit.. would that have something to do with it?
Feb 15 21:26:55 <ynezz> nbd: it didn't helped
Feb 15 21:27:09 <Hauke> I am also seeing it on a fresh clone
Feb 15 21:28:13 <adrianschmutzler> rmilecki: it's probably not very relevant for bcm4908 at the moment, but be aware that our /lib/functions/leds.sh can not handle function/color properties correctly
Feb 15 21:28:43 <adrianschmutzler> since the upstream DTSes seem to use it ...
Feb 15 21:30:11 <adrianschmutzler> shouldn't matter now, but you e.g. won't be able to use stuff like led-boot etc.
Feb 15 21:34:05 <rmilecki> adrianschmutzler: thanks, I'll have a look at it, I didn't follow recent changes, now even those aliases
Feb 15 21:35:39 <adrianschmutzler> just wanted to put a mark in your mind for when you actually stumble over it
Feb 15 21:36:38 <rmilecki> adrianschmutzler: good idea :)
Feb 15 21:42:52 <rsalvaterra> Uhh…
Feb 15 21:42:55 <rsalvaterra>  * pkg_hash_fetch_best_installation_candidate: Packages for ubus found, but incompatible with the architectures configured
Feb 15 21:42:55 <rsalvaterra>  * satisfy_dependencies_for: Cannot satisfy the following dependencies for base-files:
Feb 15 21:42:55 <rsalvaterra>  * 	libubus20191227
Feb 15 21:43:23 <rsalvaterra> Oh, it's known already. Carry on, then. :P
Feb 15 21:44:21 <Hauke> nbd: I pushed the mac80211 5.10.16 update
Feb 15 21:46:26 <nbd> Hauke: great, thanks
Feb 15 21:55:00 <Hauke> I am seeing this diff between a good and a bad build: https://pastebin.com/H3b7WPPQ
Feb 15 21:55:41 <Hauke> nbd: this is the first bad commit: https://git.openwrt.org/c92165038217e49075098479704da58a2a3a89bd
Feb 15 21:56:31 <nbd> what packages are you currently having issues with?
Feb 15 21:57:06 <Hauke> fdisk
Feb 15 21:57:42 <Hauke> nbd: I am getting this:
Feb 15 21:57:45 <Hauke>  * pkg_hash_fetch_best_installation_candidate: Packages for fdisk found, but incompatible with the architectures configured
Feb 15 21:57:59 <nbd> i'll try to reproduce it
Feb 15 22:00:52 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (0% images and 98.1% packages reproducible in our current test framework.)
Feb 15 22:09:35 <nbd> Hauke: figured it out
Feb 15 22:12:14 <nbd> Hauke: pushed a fix, please clean util-linux and try again
Feb 15 22:25:09 <Hauke> nbd: I am still having the problem
Feb 15 22:25:28 <Hauke> I removed build_dirtarget* and staging_dir/target* and tmp/
Feb 15 22:26:36 <Hauke> still:  * pkg_hash_fetch_best_installation_candidate: Packages for fdisk found, but incompatible with the architectures configured
Feb 15 22:27:59 <Hauke> fdisk has Depends: libc, libblkid1, libsmartcols1, libfdisk1, libncursesw6
Feb 15 22:29:50 <Hauke> but libfdisk1 has: Depends: libc, libuuid, libblkid1
Feb 15 22:33:50 <Hauke> it should be libuuid1
Feb 15 22:39:12 <Grommish> ndb: I just tried your push for dmesg and get the error
Feb 15 22:40:53 <Grommish> at head 7d6a636918
Feb 15 22:42:40 <mangix> philipp64: hmm?
Feb 15 22:44:17 <owrt-snap-builds> build #788 of lantiq/xway_legacy is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxway_legacy/builds/788
Feb 15 22:46:34 <mangix> Grommish: do you know if n32 is broken for mips64?
Feb 15 22:46:59 <Grommish> mangix: I've only ever used .. n64?
Feb 15 22:47:13 <Grommish> but I can test if you want
Feb 15 22:47:41 <Grommish> Umm..
Feb 15 22:47:45 <mangix> Grommish: so the story there is interesting. musl only supports n32/634 , not o32
Feb 15 22:47:45 <Grommish> n32 isn't an option
Feb 15 22:47:47 <Grommish> just o32
Feb 15 22:47:55 <Grommish> and n64
Feb 15 22:47:59 <mangix> right
Feb 15 22:48:18 <mangix> that's actually a bug in the sense that when you select o32, you get n32
Feb 15 22:48:18 <Grommish> MIPS64 user-land ABI (o32)  But, I've only ever had it on n64
Feb 15 22:48:33 <Grommish> I can switch it if you'd like
Feb 15 22:51:01 <Grommish> Want I should try?
Feb 15 22:51:38 <mangix> https://github.com/neheb/openwrt/commit/1e81d2afde2becfa82bdf4fdc1fb404756ac5ca4 <-- don't apply that
Feb 15 22:52:06 <Grommish> and if so, should I remove the -mabi=64 from the target options?
Feb 15 22:52:06 <mangix> so the funny thing is that under O32 , ABI is set to 32, which is actually N32
Feb 15 22:52:31 <mangix> setting N32 sets the ABI to n32 , which may or may not work
Feb 15 22:54:21 <mangix> Grommish: try removing the !LIBC_USE_MUSL line and building for n32.
Feb 15 22:54:54 <Grommish> removing it from where?  in the utils-linux?
Feb 15 22:55:13 <mangix> no, toolchain/Config.in
Feb 15 22:55:53 <mangix> i just remembered i could test this locally, facepalm
Feb 15 22:56:09 <Grommish> Got it
Feb 15 22:56:59 <nbd> Hauke: ok, now i just need to reorder the BuildPackage lines and it should hopefully work
Feb 15 22:57:12 <Grommish> mangix: cleaning and building
Feb 15 22:57:23 <Grommish> with the n32 marker that showed up
Feb 15 22:57:42 <philipp64> mangix: had a look at  PR #14708?
Feb 15 22:58:32 <philipp64> mangix: btw, I'm on x86_64 and I've also been seeing the ABI issues...
Feb 15 22:58:59 <philipp64> wait... you're not talking about Hauke's issue, are you?
Feb 15 22:59:28 <philipp64> never mind the latter.
Feb 15 23:00:27 <nbd> Hauke: now it should work
Feb 15 23:02:13 <mangix> philipp64: i don't use strongswan. I don't have much input.
Feb 15 23:05:31 <mangix> ugh i hate debian
Feb 15 23:06:42 <lipnitsk> mangix: use arch :)
Feb 15 23:09:07 <philipp64> Seeing CI/CD failures popping up unrelated to the commits... https://github.com/openwrt/packages/pull/14758/checks?check_run_id=1906631217
Feb 15 23:09:21 <philipp64> https://github.com/openwrt/packages/pull/14758/checks?check_run_id=1906631217#step:5:28254
Feb 15 23:09:22 <Hauke> nbd: I still have the problem ;-)
Feb 15 23:09:44 <Hauke> but the Depends lines for util linux are the same as before
Feb 15 23:10:09 <mangix> lipnitsk: i'm trying to debug a build failure on GCC 6
Feb 15 23:10:23 <mangix> lipnitsk: I can't get debian working
Feb 15 23:11:02 <lipnitsk> ah, in a VM or something?
Feb 15 23:11:52 <Grommish> mangix: I know there has to be a reason, but why 6?
Feb 15 23:12:37 <Grommish> and should I not be building with 10.2 for testing for you?
Feb 15 23:14:01 <mangix> Grommish: doesn't matter
Feb 15 23:14:07 <mangix> lipnitsk: yeah
Feb 15 23:14:13 <mangix> this is not OpenWrt related btw
Feb 15 23:16:59 <Grommish> mangix: that's alright.. I figure anything you find mips related will eventualy get back to fixing something with OpenWrt
Feb 15 23:17:56 <mangix> Grommish: out of curiosity, have you ever tried running normal mips binaries on your mips64 device?
Feb 15 23:18:09 <mangix> actually...what does cat /proc/cpuinfo say?
Feb 15 23:18:31 <Grommish> mangix: I'd hve to go check I don't have the device hooked up here.. one min
Feb 15 23:21:26 <Grommish> mangix: https://gist.github.com/Grommish/7889770c827dc3b1311a9eacf39e7aa9
Feb 15 23:24:51 <Grommish> I really should probably set the second device up out here so I can get to it.. I've got that device on an isolated segment so I can use upnp
Feb 15 23:28:21 <philipp64> anyone else seeing perl-try-tiny failures in the CI/CD pipeline?
Feb 15 23:31:13 <Grommish> mangix: if I've got a package that has hte options to use libcxx, would using the boost libraries do anything? Also a seperate discussion from the errors or the o32/n32 thing
Feb 15 23:32:12 <Grommish> I'm still compiling the toolchain, so.. I figure'd I'd ask
Feb 15 23:35:57 <hurricos> If I have a patch for an additional driver, say https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-contrib/commit/?h=apaliwal/octeon&id=be29f646aac2d548f189d49e971ceb693c1efcf2, how do I -- do I need to? -- select the driver for inclusion in my build of OpenWrt?
Feb 15 23:37:29 <Grommish> You would put it in target/linux/octeon/patches hurricos
Feb 15 23:38:12 <Grommish> then it'll show up in kernel_menuconfig
Feb 15 23:38:16 <hurricos> Oh I see, you can actually do that, like target/linux/ath79/patches-5.4/0003-leds-add-reset-controller-based-driver.patch
Feb 15 23:38:20 <hurricos> oh
Feb 15 23:38:31 <Grommish> right
Feb 15 23:39:13 <hurricos> But then -- I see, it's in a device-specific config. So I could just add CONFIG_LEDS_RESET=y and it'd pop open the driver.
Feb 15 23:39:21 <hurricos> rather than menuconfigging at all :^)
Feb 15 23:39:25 <hurricos> or ...
Feb 15 23:39:41 <hurricos> no I'd frankly just patch it in directly into the config-5.4 for testing. I'll figure that one out later :^)
Feb 15 23:39:53 <hurricos> I'm only building for one device for now after all B)
Feb 15 23:40:08 <Grommish> Yeahm but if you upstream it to the repo, remember I share that config-5.4 ;p
Feb 15 23:40:13 <Grommish> don't break me! hahha
Feb 15 23:40:42 <hurricos> Yeah. It will need cleaned up. I just have a lot of work to fix this up. E.g. dealing with the dependency on openfirmware in that patch.
Feb 15 23:40:49 <Grommish> Althought, isn't the Liquid stuff under octeontx?
Feb 15 23:41:02 <hurricos> Not the older stuff.
Feb 15 23:41:10 <Grommish> Gotcha
Feb 15 23:41:24 <Grommish> I never really looked into octeontx once I saw it wasn't me
Feb 15 23:41:52 <hurricos> Yeah, octeontx is ARM.
Feb 15 23:42:00 <Grommish> Ahh
Feb 15 23:44:12 <hurricos> Oh. Wait, you answered my other question -- so if I want to add an arbitrary module that OpenWrt doesn't provide packaging for,  but which is part of the Linux Kernel, I can find it in the kernel_menuconfig?
Feb 15 23:44:13 <mangix> Grommish: libcxx
Feb 15 23:44:14 <mangix> ?
Feb 15 23:44:20 <mangix> I removed that from OpenWrt
Feb 15 23:44:51 <philipp64> mangix: okay, I'll look for another reviewer for the strongswan changes...
Feb 15 23:45:09 <Grommish> Its an option in a package I'm working on.. That it isn't in Owrt just means I don't have to worry about it
Feb 15 23:45:18 <Grommish> I sent you a DM with the n32 error
Feb 15 23:46:18 <philipp64> what's Hans Dedecke's handle?
Feb 15 23:46:34 <T-Bone> dedeckeh
Feb 15 23:47:10 <philipp64> thanks
Feb 15 23:47:17 <philipp64> champtar: ping
Feb 16 00:05:24 <Hauke> nbd: I fixed also some other libraries and the Depends lines are loking now ok, but I am still getting this error
Feb 16 00:58:39 <rsalvaterra> adrianschmutzler: remember that issue I had, with sysupgrade failing sometimes (the system rebooting without upgrading)? I just sysupgraded my Redmi AC2100 after *six* attempts. Five sysupgrade -u -v <image> failed, the sixth sysupgrade <image> (without fancy arguments) worked. I don't know if it was a fluke, but it's not the first time this happens.
Feb 16 01:08:23 <lipnitsk> rsalvaterra: if you have rs232 connected to your box a failure log would help - may be some issue with non-vol partitions
Feb 16 01:09:39 <rsalvaterra> lipnitsk: right, here's the rub… It never happens when I do it through serial.
Feb 16 01:10:06 <lipnitsk> well you can still do it through network, but while reading and saving serial output
Feb 16 01:10:17 <lipnitsk> don't send any data via rs232
Feb 16 01:10:45 <lipnitsk> just reading from uart should not affect anything
Feb 16 01:11:44 <lipnitsk> are you sysupgrading an image in /tmp? or some remote location?
Feb 16 01:12:24 <rsalvaterra> Yes, /tmp. It's mandatory, iirc.
Feb 16 01:13:01 <rsalvaterra> Oh, well… off to bed, getting late here.
Feb 16 01:15:39 <lipnitsk> good night. Try to reproduce with serial connected when you get a chance :)
Feb 16 01:53:29 <m4t> philipp64: i replied to your github comment, dunno what's going on...
Feb 16 02:02:05 <m4t> btw, is there any way to get that dump.txt file from CI? logs/feeds/packages_ci/lang/perl-try-tiny/dump.txt
Feb 16 02:03:57 <m4t> only thing that comes to mind is maybe CI doesn't like include $(TOPDIR)/feeds/packages/lang/perl/perlmod.mk
Feb 16 02:05:00 <m4t> but it's not happening all the time :/
Feb 16 02:36:16 <philipp64> Odd that it would start now... missing dependency maybe?
Feb 16 02:37:09 <m4t> well, for the build error you saw, sure
Feb 16 02:37:22 <m4t> but for the try-tiny thing, idk. maybe CI lays out the feeds dir outside of $(TOPDIR) only sometimes
Feb 16 02:37:33 <m4t> anyways, i'll open a PR for that shortly
**** ENDING LOGGING AT Tue Feb 16 03:00:33 2021