<owrt-snap-builds> build #661 of ath79/generic is complete: Failure [failed pkgbuild] Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fgeneric/builds/661 blamelist: Rosen Penev <rosenp@gmail.com>, Paul Spooren <mail@aparcar.org>, Petr ?tetiar <ynezz@true.cz>, John Audia <graysky@archlinux.us>, Adrian Schmutzler
<owrt-snap-builds> <freifunk@adrianschmutzler.de>, Paul Fertser <fercerpav@gmail.com>, Felix Fietkau <nbd@nbd.name>, Kurt Roeckx <kurt@roeckx.be>
<lipnitsk> maybe patchelf messed with the .so's in a bad way somehow?
<lipnitsk> let me stare at it for a few min... but yeah may need to revert if we don't figure it out
<lipnitsk> https://github.com/NixOS/patchelf does seem to receive a fair bit of turmoil, let me try updating to v0.12
<owrt-snap-builds> build #774 of lantiq/ase is complete: Failure [failed pkgbuild] Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fase/builds/774 blamelist: Rosen Penev <rosenp@gmail.com>, Paul Spooren <mail@aparcar.org>, Petr ?tetiar <ynezz@true.cz>, John Audia <graysky@archlinux.us>, Adrian Schmutzler <freifunk@adrianschmutzler.de>,
<owrt-snap-builds> Paul Fertser <fercerpav@gmail.com>, Felix Fietkau <nbd@nbd.name>, Kurt Roeckx <kurt@roeckx.be>
<russell--> Hauke: not sure, i was just looking ... the only other semi-relevant change that might have fixed my freeze was 69551a244292f5baf0aee205ec6b891a03f1ee15
<mangix> lipnitsk: you the same guy as https://github.com/openwrt/packages/pull/14646 ?
<lipnitsk> haha, yeah that's me
<mangix> aparcar[m]: ping
<mangix> I have no idea where to add a quilt check to GitHub Actions
<mangix> looks like most of the functionality is in the container
<lipnitsk> Hauke: looks like patchelf 0.12 is still broken, but using patchelf master seems promising - I got mtd to build at least - trying with the whole build now
<russell--> Hauke: nope, i tried reverting 69551a244292f5baf0aee205ec6b891a03f1ee15 and my freeze didn't come back ... baffled.
<lipnitsk> There are several "suspicious" endianness-related commits in patchelf in the last few months
<lipnitsk> lantiq_xrx200 builds fine with master patchelf for me. let me try ath25 and ath79
<lipnitsk> mangix: Yeah, somewhere in the container or https://github.com/openwrt/gh-action-sdk is probably where the change will need to be made
<lipnitsk> once we agree on what exactly to do..
Grommish has quit [Ping timeout: 264 seconds]
<aparcar[m]> mangix: what do you want to implement?
Grommish has joined #openwrt-devel
swalker has quit [Remote host closed the connection]
Tapper has quit [Ping timeout: 240 seconds]
<mangix> aparcar[m]: a CI check for https://github.com/openwrt/packages/pull/14646 . Basically run make package/x/refresh and test to see if there are any changes and fail on it
<mangix> my theory is something like if patches-dir-exists; $HASH=$(sha256sum patches/*) make package/$package/refresh; $HASH2=$(sha256sum patches/*); if $HASH != $HASH2; error
dangole has joined #openwrt-devel
<mangix> quilt doesn't give fancy error codes on success unfortunately
Grommish has quit [Read error: Connection reset by peer]
<lipnitsk> yeah something like that or use git dirty tree check if there is a git index available
adrianschmutzler has quit [Quit: ~ Trillian - www.trillian.im ~]
<lipnitsk> git diff --quiet should work, so you could simplify to if patches-dir-exists; make package/$package/refresh; git diff --quiet (will exit with code 1 if there are differences in the tree)
<aparcar[m]> Add anything you like
<lipnitsk> one approach could be to just roll out this check and then only incrementally fix packages as they get changes, as opposed to my huge commit touching many packages.
<lipnitsk> aparcar[m]: so we are able to use 'git' commands in that context?
<lipnitsk> i.e. /home/build/openwrt/ is an actual repo with a .git dir in it?
swalker has joined #openwrt-devel
<mangix> lipnitsk: yeah git is available
<mangix> ./scripts/feeds uses git
<lipnitsk> yeah well the build dir also needs to have .git in it for git to recognize it as a repo
<lipnitsk> so that depends on how that dir is created in the container
<lipnitsk> (could be just a snapshot tarball unzipped into that dir, as opposed to git clone)
<mangix> right but the packages feed has a .git
<lipnitsk> that's true
<lipnitsk> and actually that's the repo you want to check anyway, so you need to `cd feeds/packages` then do the git check
<lipnitsk> if patches-dir-exists; make package/$package/refresh; cd feeds/packages; git diff --quiet
<lipnitsk> I assume it automatically cleans itself for next run? or do we need to git reset --hard on fail?
<mangix> wouldn't hurt :\
<lipnitsk> if patches-dir-exists; make package/$package/refresh; cd feeds/packages; git diff --quiet || (git reset --hard && exit 1)
<lipnitsk> I can cobble together a pull request for gh-action-sdk, but have no way of testing it..
<mangix> i assume you could test locally
<lipnitsk> yeah
<lipnitsk> still should test with a test action run before enabling it, or just watch it really closely the first few times :)
<lipnitsk> should package/$package/refresh happen after package/$package/check?
<mangix> yes
<mangix> check checks the hash of the downloaded file
<lipnitsk> makes sense, you kind of need a good package to operate on
<lipnitsk> okay I'll put together a PR, then you guys can figure out how to best roll it out.
<lipnitsk> mangix: do I need to reset the repo in case of error, or does the whole thing get blown away anyway?
<lipnitsk> aparcar[m]: actually that's more of a question for you.
dangole has quit [Ping timeout: 272 seconds]
Grommish has joined #openwrt-devel
larsan has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
larsan has joined #openwrt-devel
<lipnitsk> aparcar[m]: Also, is quilt in the container configured to use the OpenWrt format (https://openwrt.org/docs/guide-developer/build-system/use-patches-with-buildsystem#prepare_quilt_configuration)
<lipnitsk> I guess I can just set QUILT_REFRESH_ARGS to be safe
<hurricos> Grommish: It will be very tricky .. you need to rebuild a few things: the dts, the board.c and the board.h
<hurricos> it's very non-standard ...
rsalvaterra1 has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 256 seconds]
rsalvaterra1 has quit [Ping timeout: 246 seconds]
rsalvaterra has joined #openwrt-devel
<mangix> great
<mangix> oh nice. dango made it easier to remove dnsmasq
<hurricos> I have brcmfmac flowring overflow issues using bcm4366 on Aerohive HiveAP 330. Does anyone recall how to debug these?
<hurricos> I suspect it might be architecture specific. You don't see brmcmfac on powerpc boards much.
<mangix> sounds like it
<mangix> all broadcom devices are little endian
<hurricos> Hmmm ....
<Grommish> hurricosL I had to change the cvmx executive anyway in my device and can make the dts stub from the dtsi
<hurricos> mangix: ... is ppc32 usually little-endian?
hbug__ has joined #openwrt-devel
<hurricos> Err. Sorry. I seem to remember powerpc is usually either-way, but I wonder how we compile our targets
<hurricos> The card *does* work on OpenWrt x86.
<hurricos> ah wait. Another mistake. x86 is LE :^)
<mangix> hurricos: PPC is big endian
<mangix> very rarely little
<mangix> almost all platforms are little endian for speed reasons
<hurricos> Got it. Is there any way to ... 'gdb kernel drivers'?
hbug_ has quit [Ping timeout: 268 seconds]
<owrt-snap-builds> build #684 of imx6/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/imx6%2Fgeneric/builds/684
<owrt-snap-builds> build #682 of gemini/generic is complete: Failure [failed images] Build details are at http://buildbot.openwrt.org/master/images/builders/gemini%2Fgeneric/builds/682 blamelist: Rosen Penev <rosenp@gmail.com>, Paul Spooren <mail@aparcar.org>, Petr ?tetiar <ynezz@true.cz>, Daniel Golle <daniel@makrotopia.org>, John Audia <graysky@archlinux.us>, Adrian
<owrt-snap-builds> Schmutzler <freifunk@adrianschmutzler.de>, Paul Fertser <fercerpav@gmail.com>, Felix Fietkau <nbd@nbd.name>, Kurt Roeckx <kurt@roeckx.be>, Hauke Mehrtens <hauke@hauke-m.de>
<hurricos> kgdb
tobleminer-tSYS has quit [Quit: AS4242423214]
tobleminer-tSYS has joined #openwrt-devel
<aparcar[m]> mangix: what did dango do?
<aparcar[m]> nevermind found it
<aparcar[m]> lipnitsk: did you test your script somewhere?
<lipnitsk> locally
<lipnitsk> by forcing PKG on a dirty package
<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
<lipnitsk> I think one improvement might be to fail with a different message if make package/$PKG/refresh failed for whatever reason
<lipnitsk> or at least do a || exit $? after make
<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
<mangix> aparcar[m]: I've removed dnsmasq before as an experiment. odhcpd works as a DHCP server. The issue is DNS
<rr123> still quite a few build errors related to ubus, "incompatible with the architectures configured" https://pastebin.ubuntu.com/p/ZgY2ssVhZ5/
<rr123> Cannot satisfy the following dependencies for base-files:libblobmsg-json20201212
<rr123> tplink,archer-a7-v5, master branch fresh checkout
<aparcar[m]> mangix: iI think you're pretty good at C, can't you just code something?
<mangix> DNS is something I don't dare touch
<aparcar[m]> lipnitsk: okay I'll run an actual test with the CI in a bit
<aparcar[m]> thanks for the PR
<lipnitsk> okay, no problem. hope it makes mangix's life easier
<lipnitsk> aparcar[m]: Looking at the entrypoint.sh script, should V=s be replaced with V=$V everywhere?
<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.
<aparcar[m]> lipnitsk: sounds good
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
black_ant has joined #openwrt-devel
<mangix> hahaha manual git am of that patch doesn't apply. of course now.
<mangix> *not
<lipnitsk> aparcar[m]: okay, pushed V=s -> V="$V" to same PR
<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.
<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)
<mangix> it doesn't but the change in that patch is questionable
<mangix> utils/mc/patches/010-subshell.patch also looks strange
<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
<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
<mangix> LOL the issue with utils/mc/patches/010-subshell.patch is actually quite hillarious. it's missing a -
<lipnitsk> oh.
<lipnitsk> that is funny. why didn't it just remove the old stuff
<lipnitsk> looks like maybe we need to patch quilt itself :)
<mangix> to be fair, the patch is illformer
<mangix> *illformed
<lipnitsk> yeah, really just need a - in the first line
<lipnitsk> but I don't like that quilt can't handle renames, or is that a feature, not a bug?
<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.
<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 ====
<mangix> lang/python/python-requests/patches/0001-idna-dependency-bump.patch also needs to be split in two
<lipnitsk> well that's one disadvantage of forcing this I think is that quilt does seem to remove descriptions.
<mangix> that's all problems i see so far
<mangix> not usually. for that file specifically it's getting tripped up on the =========
<lipnitsk> okay, so renames are really the only showstopper here?
<mangix> yeah. Maybe I can get rid of that rename patch in open-vm-tools
<lipnitsk> fortunately that's the only one, at least in packages feed
<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
<mangix> hmmmm
<mangix> i think one way to fix it is with --diff=utility
<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
<lipnitsk> git diff [<options>] --no-index [--] <path> <path> might work
<mangix> I'll do some tests once my toolchain compiles
<lipnitsk> let me see if I can make open-vm-tools refresh happier with git diff
<mangix> maybe passing diff -s also works
<mangix> no idea yety
<mangix> *yet
<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
<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
<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
<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
<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
<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
<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
<lipnitsk> it does seem like quilt is hard-coded to use GNU diff
<mangix> well, good news is that the open-vm-tools patch is useless
<mangix> seems some other ones are too
<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
<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?
lipnitsk has quit [Quit: Leaving.]
<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
<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
<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
<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
danitool has quit [Ping timeout: 240 seconds]
<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
<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
rmilecki has joined #openwrt-devel
<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
<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
<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
<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
<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
valku has quit [Quit: valku]
<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
voxadam has quit [Ping timeout: 264 seconds]
<mangix> wait a minute....
<mangix> o32 is specific to mips32 only
nitroshift has joined #openwrt-devel
dedeckeh has joined #openwrt-devel
<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
guidosarducci has joined #openwrt-devel
<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
mattsm has quit [Quit: The Lounge - https://thelounge.chat]
ivanich has joined #openwrt-devel
voxadam has joined #openwrt-devel
<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
dansan has quit [Ping timeout: 264 seconds]
<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
finsternis has quit [Remote host closed the connection]
ivanich_ has joined #openwrt-devel
ivanich has quit [Quit: Konversation terminated!]
heffer has quit [Quit: heffer]
heffer has joined #openwrt-devel
danitool has joined #openwrt-devel
feriman has joined #openwrt-devel
shibboleth has joined #openwrt-devel
Tapper has joined #openwrt-devel
guidosarducci has quit [Quit: Connection closed]
guidosarducci has joined #openwrt-devel
voxadam has quit [Ping timeout: 264 seconds]
user| has joined #openwrt-devel
guidosarducci has quit [Quit: Connection closed]
Net147 has quit [Quit: Quit]
Net147 has joined #openwrt-devel
rsalvaterra has quit [Read error: Connection reset by peer]
rsalvaterra has joined #openwrt-devel
ephemer0l has quit [Ping timeout: 265 seconds]
svanheule has quit [Remote host closed the connection]
Monkeh has quit [Quit: No Ping reply in 180 seconds.]
<mangix> rsalvaterra: you using turrisos?
Monkeh has joined #openwrt-devel
svanheule has joined #openwrt-devel
<rsalvaterra> mangix: I used before OpenWrt supported the Omnia, yes.
<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
<rsalvaterra> But I haven't used it in years.
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Tost has joined #openwrt-devel
Tapper has quit [Quit: Instantbird 1.6a1pre -- http://www.instantbird.com]
daregap has joined #openwrt-devel
<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
shibboleth has quit [Quit: shibboleth]
goliath has joined #openwrt-devel
<aparcar[m]> nbd: you just reverted the revert of the ABI changes?
<nbd> yes, because the reason for the revert is resolved
<nbd> there was a bug in patchelf
<nbd> and i merged the fix
<zorun> Hauke: I just merged the fix I wanted to have in 19.07.7, so it's good to go from my side
<zorun> I'll prepare the release notes
<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
<rmilecki> master has stopped building for me
<rmilecki> Package libuci is missing dependencies for the following libraries:
<rmilecki> libubox.so
<rmilecki> define Package/libuci contains DEPENDS:=+libubox
<rmilecki> libubox & PKG_ABI_VERSION is smells fishy
<rmilecki> i already tried rm -fr bin/ tmp/
<rmilecki> fun! Package jsonfilter is missing dependencies for the following libraries:
<rmilecki> libubox.so
opal has quit [Remote host closed the connection]
opal has joined #openwrt-devel
<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
<rmilecki> rm -fR build_dir/target-*
<nbd> rmilecki: did you have libubox unpacked with quilt or git-src?
f00b4r0 has joined #openwrt-devel
dengqf6 has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
<rmilecki> nbd: i didn't use QUILT=1 if that answers your question
<rmilecki> nbd: i just let "make" do unpackaging & compiling
dengqf6 has joined #openwrt-devel
<nbd> i just tested making a change to the libubox abi version and it rebuilt jsonfilter as well
<nbd> so not sure where your build error is coming from
<rmilecki> nbd: can it be because my "git pull" pulled both: revert & your commit?
<mangix> jow: any plans to update the buildbots to debian 10?
glyph has quit [Quit: End of line.]
glyph has joined #openwrt-devel
Tapper has joined #openwrt-devel
ephemer0l has joined #openwrt-devel
<rmilecki> DonkeyHotei: i'm going to reference problem you got 1,5 year ago, be aware ;)
<rmilecki> DonkeyHotei: you got ath79 device with two denx,uimage partitions
<rmilecki> only 1 of them should be used for finding kernel & rootfs
<rmilecki> i added support for very similar case in BCM4908
<rmilecki> you can check my commit ac7d45b5e783fdd4ca35fe53a0921d8972f3f53b ("kernel: backport "ofpart" mtd parser upstream quirks support")
<DonkeyHotei> i was hoping a more universal solution could be deployed, as the upstream mainline kernel was getting some work to support such
<rmilecki> f00b4r0: ynezz: you were also dealing with device with similar problem I believe, 922UAGS-5HPacD I think
<f00b4r0> rmilecki: I don't have the backlog, what's this about?
Borromini has joined #openwrt-devel
<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?
<f00b4r0> rmilecki: you're aware that I've put code to do just that in the tree, right? :)
<rmilecki> f00b4r0: no
<rmilecki> f00b4r0: can you point me to that?
<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
<f00b4r0> not a model of elegance, I'll admit readily. But it works.
<rmilecki> f00b4r0: thanks, i'll check that!
<f00b4r0> np, yw
<f00b4r0> it's basically an enhanced version of ofparts
<DonkeyHotei> rmilecki: your patch is moved to generic but is still specific to the bcm4908
<f00b4r0> I wish i could have avoided some code duplication, but couldn't find a way to do so.
<rmilecki> DonkeyHotei: i moved it to generic as it's upstream backport that other targets may want to use as well
<rmilecki> DonkeyHotei: bcm53xx will need that too
nmrh has joined #openwrt-devel
csrf has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
csrf has joined #openwrt-devel
<DonkeyHotei> rmilecki: this is the mechanism "blessed" by upstream as i understand it: https://lore.kernel.org/patchwork/patch/1047244/
<DonkeyHotei> but last i checked, it was still being worked on
<DonkeyHotei> i've lost track of its progress
<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
<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
<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
<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>
<DonkeyHotei> it would eliminate ugly hacks on ppc and ipq40xx
<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 :-)
zjason has joined #openwrt-devel
Tapper has quit [Ping timeout: 272 seconds]
<russell--> xback: is this a case of kernel-too-bit-for-routerboot?
<russell--> big*
Tapper has joined #openwrt-devel
<blogic> xback: i got part done then got side tracked
<blogic> shall I mail you latest patch version that I have ?
<xback> blogic: yes. please do :-)
<xback> appreciated!
<xback> russell--: No, it's not. this is about adding support for rb912 to ath79 in master
OutBackDingo has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<blogic> xback: sent
<xback> tyvm
<blogic> basically the read and write functions are left to make work
<blogic> also still some commented out code in there where i bumped apis
* rmilecki starts wondering if he didn't break fixed-partitions
<rmilecki> i fuc* did
Jusic has quit [Quit: Quit]
Jusic has joined #openwrt-devel
<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 :-)
<Hauke> nbd: thank you for adding it again
<Hauke> rmilecki: the lantiq/xway_legacy build failed becasue of some mtd patch not applying, could you have a look please
<rmilecki> Hauke: i broke things totally, I'm working on it right now
<Hauke> rmilecki: thanks
noltari has quit [Ping timeout: 240 seconds]
<blogic> xback: yeah, sent it just now
<rmilecki> i'll get mtd fixed in ~30 minutes, hopefully less
<rmilecki> i'm also working with mtd guys at the same time on it
<Tapper> rmilecki is mtd broken on all targets? I just did a build from master is it ok to flash?
<rmilecki> Tapper: don't know your devices, better wait
<nick[m]1> ping aparcar please finally merge the luci-app-babeld stuff :D https://github.com/openwrt/luci/pull/4791
nmrh has quit [Quit: nmrh]
<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
noltari has joined #openwrt-devel
noltari has quit [Client Quit]
noltari has joined #openwrt-devel
<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.
<rmilecki> Hauke: Tapper: rr123: fix pushed
<rmilecki> sorry for that
<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...
<nbd> ynezz: maybe you can do the test runs with BUILD_LOG=1 to see if we have spurious rebuilds in there somewhere
guerby has quit [Remote host closed the connection]
guerby has joined #openwrt-devel
<hurricos> rmilecki: Do you recall fixups for flowrings in brcmfmac?
<rmilecki> hurricos: i don't
<hurricos> s/.*//; -- no problem, I will probably just flyspray the bug instead, the stack trace when brcmfmac crashes on ppc32 has much more information.
f00b4r0 has quit [Quit: Leaving]
<rmilecki> hurricos: send me a link please
<Hauke> hurricos: did I break brcmfmac with the mac80211 update?
<hurricos> rmilecki: I will. Fairly sure nobody broke anything. This is nonstandard configuration that was never confirmed-working.
<blogic> Cloning into './feeds/packages'...
<blogic> fatal: unable to access 'https://git.openwrt.org/feed/packages.git/': GnuTLS recv error (-24): Decryption has failed.
<blogic> failed.
<blogic> ermmm
<blogic> ok, rerunning that and it works
<hurricos> bcm4366c as mPCIe card (eBay bcm43465) in Aerohive HiveAP 330. I have to rebuild with symbols
<rr123> Package wpad-wolfssl is missing dependencies for the following libraries:libubox.so.20201212
f00b4r0 has joined #openwrt-devel
<rr123> Hauke: you reverted libubox but it's re-reverted back?
<Borromini> rr123: does a make clean/compile fix it?
<Borromini> on those single packages (wpad-wolfss, maybe also libubox)
nitroshift has quit [Quit: Gone that way --->]
Tapper has quit [Ping timeout: 240 seconds]
<ynezz> nbd: I've removed tmp, then 1st was 17m17s, 2nd 2m23s, 3rd 2m22s so seems better now
<ynezz> but I was bisecting so maybe hit some corner case
feriman has quit [Quit: WeeChat 3.0.1]
<enyc> OoooOoo 21.02 goals now includes "Add AX support. "
<enyc> I guess that means, initial support, and only on a few targets
<enyc> aiui there is a very complex feature set in wifi-6 etc.
<rr123> Borromini: you're right, clean hostapd and libubox and the build completed
<Borromini> enyc: i think only Mediatek support (MT7915 probably)
<Borromini> rr123: good :)
dorf has joined #openwrt-devel
adrianschmutzler has joined #openwrt-devel
<adrianschmutzler> apm821xx/sata und mvebu/cortexa53 still fail with:
<adrianschmutzler> pkg_hash_fetch_best_installation_candidate: Packages for fdisk found, but incompatible with the architectures configured
<Borromini> adrianschmutzler: hi! can i prod you to accept the following? :) https://patchwork.ozlabs.org/project/openwrt/patch/20210214100322.246853-1-sander@svanheule.net/
<Borromini> i've been testing the device for weeks now (mostly because of the 5 GHz wireless driver)
<adrianschmutzler> Borromini: I probably won't have time for reviewing a device support right now.
<Borromini> ok.
<adrianschmutzler> But I could be convinced into "backporting" something like this after 21.02 branch easily
<Borromini> ok, cool. would be nice if it could make it into 21.02 releases still :)
<nbd> adrianschmutzler: btw. i just now noticed that you removed the generic profiles from some targets
<nbd> let me explain why those profiles were there in the first place
<nbd> the point was to have a default selection that builds a common image that works on all devices supported by the target
<nbd> instead of selecting just one random device that the target supports
<nbd> (random == the first one from the alphabetically sorted list)
<adrianschmutzler> nbd: that's what I thought it does. But does this make sense on ath79?
<adrianschmutzler> because that's why I only removed it on specific targets where I thought it's moot ...
joaohcca has joined #openwrt-devel
<enyc> Borromini: and that not to hold up the fork/release too much?
<adrianschmutzler> nbd: maybe it makes sense to have it for a mere target build test ...
<nbd> the default config is a trade-off
<nbd> it may not include some big drivers that are only needed for a few devices
<nbd> but it should produce something that boots fine on all devices
<adrianschmutzler> without dts?
<nbd> what do you mean?
<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
<nbd> i mean it still builds one image per device (with the per-device dts of course), but only one rootfs
<adrianschmutzler> does it? hmm ...
<adrianschmutzler> how is that different from multi-profile without rootfs_per_device?
<nbd> the main difference is that it doesn't build in all device specific packages
<nbd> for instance on ath79 it would not build in all the different ath10k firmwares
<nbd> because that would bloat up the default rootfs a lot
<adrianschmutzler> okay, I understand.
<adrianschmutzler> I'm still not sure whether we really need this, particularly since nobody cried so far.
<adrianschmutzler> But if you think it's valuable, feel free to revert my commits.
<nbd> ideally i'd like to replace it with something cleaner
<nbd> but i don't have a good solution yet
<adrianschmutzler> But be aware that there are targets where it never has been added in the first place.
<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
<adrianschmutzler> Or ramips, where five subtargets had it and one didn't
<rr123> my openwrt build sysupgrade.bin increase 200KB in the last two days, no config changes other than git-pull and rebuild
<ynezz> nbd: 4min difference seems like quite huge overhead for "just" that ABI changes
<rr123> some new packages made it from 8061740 to 8323884
<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.
<rr123> 260KB that is
<adrianschmutzler> So, I have no strong opinion or interest there
<Borromini> rr123: new extra required packages?
<nbd> ynezz: seems to me like there must be some spurious rebuild in there somewhere
<adrianschmutzler> And at some point, we have to discuss this whole DEVICE_PACKAGES subject anyway, since we have that other problem with initramfs
<nbd> ynezz: can you figure out what it keeps rebuilding in your test or where it spends most of the time?
<rr123> Borromini: just did a binwalk -e, and found the increased 260KB(after unsquash it's >1MB) is mainly from libubox
<nbd> ynezz: ah, i think i may have found it
<rr123> in fact under /lib, libblobmsg_json.so.20201212 libjson_script.so.20201212 libubox.so.20201212 are each 200KB+ now
<rr123> something is wrong with dynamic library soft links there
<rr123> let me reflash it to the board and see if that's true
<Borromini> rr123: that sounds fishy indeed
opal has quit [Remote host closed the connection]
<nbd> ynezz: please test if this helps: https://termbin.com/9l98
opal has joined #openwrt-devel
<enyc> Borromini: hrrm, regression potential? etc hrrm
<Borromini> it's master eh? :P
<rr123> https://imgur.com/a/dkNEavE yes libubox/libblogmsg/ etc definitely messed up with size after installation
<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
dorf has quit [Remote host closed the connection]
<karlp> they better not care... :)
<karlp> and if they are, they "correctly" depended on teh ABI they intended :)
<nbd> i think it's another bug in patchelf
<nbd> it seems to mess up the ELF headers somehow
<Borromini> is the .so/.so.$ABI split intended?
<Borromini> oh nevermind, there's just one libubox.so.$ABI
<Borromini> rr123: that's beefy. Feb 13th master build here and libubox is 33351
<Borromini> that's x10
kontaxis has quit [Remote host closed the connection]
kontaxis has joined #openwrt-devel
<rr123> libwolfssl.so. increased 100K from libwolfssl.so.24.3.0, jshn increase from 16 to 144KB
<joaohcca> adrianschmutzler do you think you'll be able backport ath79 support from https://github.com/openwrt/openwrt/pull/3319 to 20.02 ?
<ynezz> nbd: 1st run 5:44, 2nd run 4:11, 3rd run 4:19
<ynezz> nbd: revert, 1st 0:41, 2nd 28s, 3rd 28s
lucenera has quit [Quit: The Lounge - https://thelounge.chat]
lucenera has joined #openwrt-devel
<ynezz> + is addition in log from the longer run
<ynezz> that's comparison of the 1st run with and without the ABI changes
<ynezz> that 1st run takes longer due to fresh config and defconfig
<nbd> i think i'll abandon the patchelf idea, it seems to be too fragile
<nbd> better to just patch packages to allow the build to specify soname
Tapper has joined #openwrt-devel
shibboleth has joined #openwrt-devel
danitool has joined #openwrt-devel
<nbd> ynezz: pushed some commits that remove the soname patching and instead build libubox and wolfssl with the updated soname
<nbd> please test if it's still slow for you
<nbd> rr123: this will also fix the size issues you were running into
zx2c4 has quit [Ping timeout: 268 seconds]
zx2c4 has joined #openwrt-devel
HeN has quit [Ping timeout: 260 seconds]
HeN has joined #openwrt-devel
lipnitsk has joined #openwrt-devel
<ynezz> ugh it seems like it's rebuilding kernel now
<ynezz> maybe due to rebase
T-Bone has joined #openwrt-devel
f00b4r0 has quit [Ping timeout: 272 seconds]
<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
<ynezz> nbd: magic! 1st 7:06, 2nd 0:21, 3rd 0:22
<ynezz> thanks!
<nbd> cool
<nbd> thanks for testing
<shibboleth> is there a way to generate "generic" images like the ones for 1907?
Tost2 has joined #openwrt-devel
Tost has quit [Ping timeout: 265 seconds]
<Grommish> Oo.. So, what's broken with libubox? I saw someone mention something on it earlier but I just hit the wall with it
<Grommish> Package libuci is missing dependencies for the following libraries: libubox.so
<Borromini> Grommish: still broken with latest master?
<Grommish> I just rebased a few hours ago, so.. yes
<Grommish> It's there though in the file.. ./target-mips64_octeonplus_64_musl/root-octeon/lib/libuci.so
<Borromini> well last push is 45' ago
<Grommish> and ./target-mips64_octeonplus_64_musl/uci-2020-10-06-52bbc99f/libuci.so
<Grommish> Gotcha.. I was building.. I'll rebase
<Borromini> with the ABI stuff involved
<Grommish> Rebased .. I'll clean and build.. Thanks Borromini :)
<Borromini> well i'm doing one myself, just hoping it's fixed ;)
<Grommish> Someone found another reason for rust-lang, so it's getting some interest finally hehe
<Borromini> =)
<Borromini> i'm also getting uci build failuers now
<Borromini> * failures
<Grommish> Do me a favor while you're digging thru you source?
<Grommish> and run: ls ./staging_dir/toolchain-*_gcc-*/bin/*-gcc and DM me with it?
Tapper has quit [Ping timeout: 240 seconds]
<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
<Grommish> I'm not going anywhere. time to turtle up
<Borromini> US?
<Grommish> Yeah.. Ohio
<Borromini> :)
<Grommish> Not as bad as Texas because we see snow more often but it'll not be fun
<Grommish> Those poor folks just don't have the infrastructure for that kinda weather
<Borromini> ok
Tapper has joined #openwrt-devel
ivanich_ has quit [Quit: Konversation terminated!]
jmv has joined #openwrt-devel
ivanich has joined #openwrt-devel
<Grommish> Borromini: I just finished building out with ndb last push
<Grommish> My HEAD is at 542eab31a6 and it worked after I cleaned
Night-Shade has joined #openwrt-devel
<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.
<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
<Grommish> jmv: Luci isn't installed by default on Snapshots
<Grommish> jmv: but there was a libubox/libuci issue that was just pushed an hour ago
<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
<Borromini> Grommish: it works here too, but full (util-linux) dmesg doesn't want to cooperate here
<Grommish> Or rather, it BUILDS.. I've not flashed
<Borromini> me neither :P
<Borromini> mangix: cbedb5de75440b336072ee32bf97a81fac529a6a is breaking dmesg build for me on mt7621
goliath has quit [Quit: SIGSEGV]
dorf has joined #openwrt-devel
<Borromini> mangix: error i'm seeing is "pkg_hash_fetch_best_installation_candidate: Packages for dmesg found, but incompatible with the architectures configured"
<rr123> updated master and now everything seems fine to me
<philipp64> What's Rosen's handle? For that matter, where is the real name to handle mapping for this channel?
<Borromini> philipp64: mangix
<philipp64> right. thanks
<Borromini> philipp64: util-linux problem?
<philipp64> mangix: wither art thou?
<philipp64> um, no. why?
<Borromini> i'm seeing one and his commit seems to blame :P
<philipp64> link?
<Grommish> Rosen? Neheb
<Grommish> I believe
<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.
<Grommish> but I could be wrong.. I'm not up on everyones name heh
joaohcca has quit [Quit: Connection closed]
<EqUaTe> jmv: normally I'd say that would be opkg
<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)
<jmv> It says: configuring rpcd-mod-rrdns. Command filed: Not found.
<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
<jmv> "command failed: Not found"
<EqUaTe> something in the postinst script for rpcd-mod-rrdns then, presuming that that package name is accurate
<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...
bala has joined #openwrt-devel
<jmv> Same for opkg install rpcd-mod-luci.
<ynezz> nbd: just pulled again your latest changes and it's back to 4min28sec
<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?
goliath has joined #openwrt-devel
<Grommish> The build system doesn't use ccache by default, correct?
<Borromini> philipp64: how would one do that?
<Borromini> besides building different targets
<nbd> ynezz: just found another old bug that was causing spurious rebuilds
philipp64 has quit [Quit: philipp64]
Night-Shade has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Borromini> mangix: for what it's worth: https://paste.debian.net/1185622/
philipp64 has joined #openwrt-devel
<Hauke> did someone look into the problem with opkg and fdisk on some targets?
<Hauke> some builds are failing because of some strange error "Packages for fdisk found, but incompatible with the architectures configured"
<Hauke> I can reproduce it now and will have a look
<Borromini> Hauke: i am seeing something similar with dmesg here
<Hauke> Borromini: thanks for the info
<Borromini> mangix: sorry for the noise the revert helping seems to have been a one-off
<Hauke> most of the fails in build bot are caused by this: http://buildbot.openwrt.org/master/images/waterfall
<Borromini> Hauke: doing a make package/util-linux/{clean,compile} helps for the package itself but not for the full build
<rr123> incompatible with the architectures -- looks familiar, with the newest master along with a fresh build might get that cleaned?
<Grommish> Borromini: That is a different package than the busybox dmesg?
<Borromini> rr123: i've done a make clean already, no dice
<Borromini> Grommish: yes it's a 'full' dmesg, part of util-linux
* rr123 does not use util-linux dmesg, try to enable and build now
<Grommish> Ok.. I'll try that package when/if this build finishes
<Grommish> to see if its target dependent
<Borromini> ok
<rr123> 23767 Feb 15 14:35 packages/mips_24kc/base/dmesg_2.36.1-2_mips_24kc.ipk built fine for me
<Borromini> rr123: my package architecture is mipsel_24kc, and it has built fine for ages
<Borromini> i'm not seeing any weirdness about architectures in the util-linux Makefile either
<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
pine127 has joined #openwrt-devel
<Borromini> rr123: the package gets built just fine, it's just the final image stage that seems to throw that error
<rr123> that just reminds me the libubox thing since yesterday, some endian weirdness
<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)
opal has quit [Remote host closed the connection]
<Hauke> Borromini: I am bisecing the problem
opal has joined #openwrt-devel
<Borromini> Hauke: ok
<Borromini> just wanted to make sure i was still sane after my own local breakage :)
jmv has quit [Quit: Connection closed]
<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...
<lipnitsk> are there plans on using CI to compile patches/PRs for openwrt similar to feeds/packages? Should make trunk more stable
<Borromini> philipp64: ok, but i was wrong. reverting the last util-linux commit didn't help any.
<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?
<philipp64> well, not for fdisk, but for other packages.
<philipp64> Odd that our CI/CD didn't detect that.
jmv has joined #openwrt-devel
<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?
<karlp> lipnitsk: that would require all submissions to be proposed as patches/PRs first...
<philipp64> Who owns the CI/CD, anyway? Charpentier used to be very involved in that but that was a couple of years ago.
<philipp64> karlp: that wouldn't be a bad thing.
<lipnitsk> karlp: uhm, that's most of the changes already, isn't it? Pushing straight to master is a bit of a cowboy approach :)
<lipnitsk> if CI was reasonably responsive then forcing PRs wouldn't be a bad idea.
<philipp64> Hauke: here's another example: https://github.com/openwrt/packages/issues/14735
<karlp> philipp64: never said it was :)
<philipp64> lipnitsk: I think a lot still gets reviewed via mailing out patches, and then individual sandboxes get themselves rebased into master...
lipnitsk has quit [Read error: Connection reset by peer]
lipnitsk has joined #openwrt-devel
<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.
<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
<rmilecki> this ain't a good day for OpenWrt deps :|
<rmilecki> * pkg_hash_fetch_best_installation_candidate: Packages for ubus found, but incompatible with the architectures configured
jmv has quit [Quit: Connection closed]
<rmilecki> * satisfy_dependencies_for: Cannot satisfy the following dependencies for base-files:
<rmilecki> * libubus20191227
<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...
<lipnitsk> not that we want to totally rely on github, but why not use it while it fits the bill
<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
<Borromini> rmilecki: Hauke is looking into it :)
<philipp64> aparcar[m]: you've got fingerprints on "opkg" (as does dangowrt)... could the last commit of "opkg" (Christmas eve) have broken anything?
<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
<Hauke> this was merged on 24. Dec
<Hauke> build bot saw it the first time yesterday
<aparcar[m]> Why the delay?
<nbd> typically that msg appears when a dependency can't be resolved, i think
<rmilecki> Borromini: Hauke: i fixed above problem by rm -fR bin/ tmp/
<philipp64> the dependency wouldn't be resolved if somehow the meta-information wasn't being generated correctly or the format had changed... for eample.
<Borromini> rmilecki: let's hope it's as easy as that. giving it a go
<philipp64> is there a way to run opkg with debugging options so we could see what's going on inside?
jmv has joined #openwrt-devel
<philipp64> Actually, the prior commit looks more high-risk...
<dorf> opkg --verbosity=4
<philipp64> https://git.openwrt.org/?p=project/opkg-lede.git;a=commitdiff;h=efb26a35e4e5446f135307c4ff7df9e9563c23a9
<philipp64> dorf: thanks, I'll try that next time it happens.
<philipp64> Hauke: actually, since you're seeing it now, can you pastebin results?
<Borromini> rmilecki: thanks, that it does indeed.
<Borromini> Hauke: ^^
<Borromini> so probably something in tmp/ since i had wiped bin/ before
<Grommish> There was an ABI commit.. would that have something to do with it?
<ynezz> nbd: it didn't helped
<Hauke> I am also seeing it on a fresh clone
<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
<adrianschmutzler> since the upstream DTSes seem to use it ...
<adrianschmutzler> shouldn't matter now, but you e.g. won't be able to use stuff like led-boot etc.
<rmilecki> adrianschmutzler: thanks, I'll have a look at it, I didn't follow recent changes, now even those aliases
<adrianschmutzler> just wanted to put a mark in your mind for when you actually stumble over it
<rmilecki> adrianschmutzler: good idea :)
Borromini has quit [Ping timeout: 240 seconds]
<rsalvaterra> Uhh…
<rsalvaterra> * pkg_hash_fetch_best_installation_candidate: Packages for ubus found, but incompatible with the architectures configured
<rsalvaterra> * satisfy_dependencies_for: Cannot satisfy the following dependencies for base-files:
<rsalvaterra> * libubus20191227
<rsalvaterra> Oh, it's known already. Carry on, then. :P
<Hauke> nbd: I pushed the mac80211 5.10.16 update
bala has left #openwrt-devel ["WeeChat 2.8"]
jmv has quit [Ping timeout: 240 seconds]
<nbd> Hauke: great, thanks
<Hauke> I am seeing this diff between a good and a bad build: https://pastebin.com/H3b7WPPQ
<Hauke> nbd: this is the first bad commit: https://git.openwrt.org/c92165038217e49075098479704da58a2a3a89bd
<nbd> what packages are you currently having issues with?
<Hauke> fdisk
<Hauke> nbd: I am getting this:
<Hauke> * pkg_hash_fetch_best_installation_candidate: Packages for fdisk found, but incompatible with the architectures configured
<nbd> i'll try to reproduce it
<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.)
dedeckeh has quit [Quit: Connection closed]
dorf has quit [Remote host closed the connection]
<nbd> Hauke: figured it out
dorf has joined #openwrt-devel
dorf_ has joined #openwrt-devel
<nbd> Hauke: pushed a fix, please clean util-linux and try again
dorf has quit [Remote host closed the connection]
dorf has joined #openwrt-devel
<Hauke> nbd: I am still having the problem
<Hauke> I removed build_dirtarget* and staging_dir/target* and tmp/
dorf_ has quit [Ping timeout: 264 seconds]
<Hauke> still: * pkg_hash_fetch_best_installation_candidate: Packages for fdisk found, but incompatible with the architectures configured
ivanich has quit [Quit: Konversation terminated!]
<Hauke> fdisk has Depends: libc, libblkid1, libsmartcols1, libfdisk1, libncursesw6
black_ant has quit [Ping timeout: 256 seconds]
<Hauke> but libfdisk1 has: Depends: libc, libuuid, libblkid1
dorf has quit [Ping timeout: 240 seconds]
<Hauke> it should be libuuid1
<Grommish> ndb: I just tried your push for dmesg and get the error
<Grommish> at head 7d6a636918
<mangix> philipp64: hmm?
opal has quit [Ping timeout: 268 seconds]
<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
opal has joined #openwrt-devel
<mangix> Grommish: do you know if n32 is broken for mips64?
<Grommish> mangix: I've only ever used .. n64?
<Grommish> but I can test if you want
<Grommish> Umm..
<mangix> Grommish: so the story there is interesting. musl only supports n32/634 , not o32
<Grommish> n32 isn't an option
<Grommish> just o32
<Grommish> and n64
<mangix> right
<Grommish> MIPS64 user-land ABI (o32) But, I've only ever had it on n64
<mangix> that's actually a bug in the sense that when you select o32, you get n32
<Grommish> I can switch it if you'd like
luke-jr has quit [Ping timeout: 264 seconds]
<Grommish> Want I should try?
<Grommish> and if so, should I remove the -mabi=64 from the target options?
<mangix> so the funny thing is that under O32 , ABI is set to 32, which is actually N32
<mangix> setting N32 sets the ABI to n32 , which may or may not work
goliath has quit [Quit: SIGSEGV]
<mangix> Grommish: try removing the !LIBC_USE_MUSL line and building for n32.
<Grommish> removing it from where? in the utils-linux?
<mangix> no, toolchain/Config.in
<mangix> i just remembered i could test this locally, facepalm
<Grommish> Got it
<nbd> Hauke: ok, now i just need to reorder the BuildPackage lines and it should hopefully work
<Grommish> mangix: cleaning and building
<Grommish> with the n32 marker that showed up
<philipp64> mangix: had a look at PR #14708?
<philipp64> mangix: btw, I'm on x86_64 and I've also been seeing the ABI issues...
<philipp64> wait... you're not talking about Hauke's issue, are you?
<philipp64> never mind the latter.
<nbd> Hauke: now it should work
luke-jr has joined #openwrt-devel
<mangix> philipp64: i don't use strongswan. I don't have much input.
shibboleth has quit [Quit: shibboleth]
<mangix> ugh i hate debian
embargo has quit [Remote host closed the connection]
<lipnitsk> mangix: use arch :)
embargo has joined #openwrt-devel
<philipp64> Seeing CI/CD failures popping up unrelated to the commits... https://github.com/openwrt/packages/pull/14758/checks?check_run_id=1906631217
<Hauke> nbd: I still have the problem ;-)
<Hauke> but the Depends lines for util linux are the same as before
<mangix> lipnitsk: i'm trying to debug a build failure on GCC 6
<mangix> lipnitsk: I can't get debian working
<lipnitsk> ah, in a VM or something?
<Grommish> mangix: I know there has to be a reason, but why 6?
<Grommish> and should I not be building with 10.2 for testing for you?
<mangix> Grommish: doesn't matter
<mangix> lipnitsk: yeah
<mangix> this is not OpenWrt related btw
<Grommish> mangix: that's alright.. I figure anything you find mips related will eventualy get back to fixing something with OpenWrt
<mangix> Grommish: out of curiosity, have you ever tried running normal mips binaries on your mips64 device?
<mangix> actually...what does cat /proc/cpuinfo say?
<Grommish> mangix: I'd hve to go check I don't have the device hooked up here.. one min
<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
philipp64 has quit [Quit: philipp64]
philipp64 has joined #openwrt-devel
<philipp64> anyone else seeing perl-try-tiny failures in the CI/CD pipeline?
<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
<Grommish> I'm still compiling the toolchain, so.. I figure'd I'd ask
rmilecki has quit [Ping timeout: 240 seconds]
<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?
<Grommish> You would put it in target/linux/octeon/patches hurricos
<Grommish> then it'll show up in kernel_menuconfig
<hurricos> Oh I see, you can actually do that, like target/linux/ath79/patches-5.4/0003-leds-add-reset-controller-based-driver.patch
<hurricos> oh
<Grommish> right
<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.
<hurricos> rather than menuconfigging at all :^)
<hurricos> or ...
<hurricos> no I'd frankly just patch it in directly into the config-5.4 for testing. I'll figure that one out later :^)
<hurricos> I'm only building for one device for now after all B)
<Grommish> Yeahm but if you upstream it to the repo, remember I share that config-5.4 ;p
<Grommish> don't break me! hahha
<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.
<Grommish> Althought, isn't the Liquid stuff under octeontx?
<hurricos> Not the older stuff.
<Grommish> Gotcha
<Grommish> I never really looked into octeontx once I saw it wasn't me
<hurricos> Yeah, octeontx is ARM.
<Grommish> Ahh
<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?
<mangix> Grommish: libcxx
<mangix> ?
<mangix> I removed that from OpenWrt
<philipp64> mangix: okay, I'll look for another reviewer for the strongswan changes...
<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
<Grommish> I sent you a DM with the n32 error
<philipp64> what's Hans Dedecke's handle?
<T-Bone> dedeckeh
T-Bone is now known as f00b4r0
<philipp64> thanks
<philipp64> champtar: ping