<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
<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>
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
<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)
<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.
<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
<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
<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
<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 & 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? :)
<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.
<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
<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.4.6.0.66253b90 increased 100K from libwolfssl.so.24.3.0, jshn increase from 16 to 144KB
<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>
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>
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...
<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
<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
<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