<dansan>
Hello. I've run into this "pkg_hash_fetch_best_installation_candidate: Packages for kmod-so-and-so found, but incompatible with the architectures configured" error. I believe I've modified kernel patches since I started this build so I'm guessing that's what it doesn't like? Some out-of-tree modules were perhaps build prior to my patch changes? I also changed my kernel config options mid way through. Anyway, what package do I need to manually
<dansan>
clean to make this go away?
<dansan>
package(s)
<PaulFertser>
dansan: any kernel config change makes kmods incompatible
<PaulFertser>
dansan: make target/linux/clean (probably)
<dansan>
PaulFertser: that sounds like the magic bit!
<dansan>
of course, in an ideal world the build system would detect this
<PaulFertser>
dansan: by wasting some time each normal build where this detection wouldn't be needed. I haven't benchmarked though.
<dansan>
hrm, isn't there another package for out-of-tree modules? There used to be a backports package in v19
<dansan>
good point
<PaulFertser>
dansan: backports are still used, yes, mac80211 package name.
<dansan>
Oh yeah, that's right. thanks. I should probably clean all of the packages it complains about as well
<dansan>
I've been in those 802.11 drivers and I'll leave that for somebody else next time. :)
<dansan>
PaulFertser: I don't suppose there's a switch to turn off those checks for when one is hacking is there?
<PaulFertser>
dansan: you can try just scp a .ko file to target and insmod it and see
<dansan>
Oh, I'm just trying to build the firmware right now, not run it
<PaulFertser>
dansan: then you need the checks :)
<dansan>
Not if you're just hacking
<dansan>
Because in the end, once things are correct I can rebuild the whole tree
<dansan>
The next thing I'm probably going to work on is my KConfig mod. I really need to differentiate between a "manually selected" package and one that is selected *by* another package. My .config gets so messy so fast.
<dansan>
Then again, so does my desk :)
<dansan>
hrm, I got the same error :(
indy_ is now known as indy
<dansan>
Does this have anything to do with the git tree? I have uncommitted changes
<PaulFertser>
dansan: probably you already have some kmod-so-and-so.ipk file, it's present in build_dir or even staging_tree but built for wrong architecture and you need to rm it manually?
<dansan>
eew, staging_dir. I blew away any such thing in build_dir
<dansan>
I'll just blow away the staging_dir/target*/root-ramips and bin directors maybe
<PaulFertser>
dansan: you can always run with -j1 V=sc and it'll probably show full path to the ipk in question.
<dansan>
OK, here we go again. I'm glad I have a 16-thread Ryzen, but some of you guys probably have 64 threads on your CPU(s)
<dansan>
PaulFertser: yeah, I probably should have pastebined it earlier: https://bpa.st/MDOQ
* rsalvaterra
hides his 4c8t Haswell
<dansan>
HAHA!
<dansan>
Yeah, I'm talking about YOU!
<dansan>
When I first started this job, I had a 4 core Phenom
<dansan>
single ALU per core
<rsalvaterra>
You mean single FPU, for sure… ;)
<dansan>
Well, "hyperthreading" is just two ALUS and one FPU stuck together in a single "core"
<dansan>
And compiling is 100% ALU
<rsalvaterra>
But I started doing OpenWrt stuff (about a year and a half ago) on a Pentium D 950. :)
<dansan>
oh
<dansan>
oh my
<rsalvaterra>
(Which I used up to until two months ago.)
<dansan>
Oh, that's only 8 threads. I have 16 threads, but yours are faster
<dansan>
PaulFertser: same error :(
<dansan>
I guess I can do a full clean, start the build again and go to sleep :)
<dansan>
But it looks like I'm going to be hacking opkg
aleksander has joined #openwrt-devel
<PaulFertser>
dansan: wrong arch for a kmod is a rather odd error, do not remember seeing it ever.
<dansan>
Yeah, very strange
<PaulFertser>
But probably it's just complaining about the version in fact 5.4.143-1-996c65f322e8a783191e5195e3a4e5b7
<dansan>
eew, CMake
<dansan>
yeah, but I don't understand why
<dansan>
It's the same one in the build tree
<dansan>
Also, it should be printing both of the hashes out. If I have a kernel with a different hash, it should be printed I think
<dansan>
PaulFertser: here ya go: https://git.openwrt.org/?p=project/opkg-lede.git;a=blob;f=libopkg/pkg_hash.c;h=c58703f60e663de224b93aabaa61901cd841e560;hb=refs/heads/master#l397
danitool has joined #openwrt-devel
<dansan>
I was about to criticize the opkg sources and say it should have been written in C++. But then I remembered that we're doing embedded. :)
<PaulFertser>
C++ is good for embedded
<dansan>
Yeah, but you can get more compact code if you disable exceptions. But then you loose a lot of libraries that need them.
<dansan>
I would rather use stl than roll my own containers though :)
<PaulFertser>
So you can always choose what you really need from the features offered.
<dansan>
Yeah, but in most cases I find it justified to have them enabled and just not worry about the small difference.
<dansan>
So I'm not really certain, but it *may* be that some packages built prior to my changing the kernel patches embedded the "architecture" of the kernel with its hash -- which later thought it wasn't compatible. I'll know in about 40 minutes.
<Tapper>
Hi people if one wanted to test out firewall4 would you just do make menuconfig and unselect firewall 3 and then select firewall 4?
<dansan>
Probably only 20 minutes, but it *feels* so much longer
<dansan>
Tapper: last I looked "firewall" translates to "firewall3" so I think you will just need to modify the Makefile
<Tapper>
Would makemenuconfig handle any deps? all so is luci OK with firewall4?
<rsalvaterra_>
tohojo: Nope, I've seen that happen before my commit, sorry… :)
<tohojo>
which could have switched the loader to 'modprobe' instead of 'insmod', which I suppose may be louder?
<tohojo>
assuming busybox includes both?
<rsalvaterra_>
Not really, this is something else… modprobe -> /sbin/kmodloader
<rsalvaterra_>
Module handling in OpenWrt is "special".
<tohojo>
well in that case I don't see how it could have been after upgrading to 1.5.1
<tohojo>
the base loading logic is unchanged for a while before that
<rsalvaterra_>
Now that you mention it, sqm-scripts is probably innocent and it's kmodloader that needs to shut up.
<rsalvaterra_>
I'll dig a bit deeper, sorry for the noise. :)
<tohojo>
hmm, yeah, sqm uses 'logger -t SQM', so I guess that should be prefixed there?
<tohojo>
although you could argue that we should be smarter than that '[ -d /sys/modules/$m ]' check
<tohojo>
though IDK if there's an easy way to check for builtins?
fda- has joined #openwrt-devel
<rsalvaterra_>
tohojo: I thought about that too, looked at sysfs, but not all modules show up. :/
<rsalvaterra_>
So, probably no easy to way (that I know of, at least).
<PaulFertser>
rsalvaterra_: so I spent quite some time trying zram-swap with you half a year ago, all in vain. Now the new SDRAM IC finally arrived and with 64 MiB my old router does everything I want :)
<tohojo>
no, probably not... I guess we could try instantiating each qdisc, but that seems a bit much
<tohojo>
I mean, ideally, module autoload should just handle everything and we could remove the check entirely
<tohojo>
but I don't suppose that's the case on openwrt still, right?
fda| has joined #openwrt-devel
<PaulFertser>
And I just wanted to run the latest OpenWrt release with Unbound.
<rsalvaterra_>
Oh, cute… kmodloader is a multicall binary too. https://git.openwrt.org/?p=project/ubox.git;a=blob;f=kmodloader.c;h=6f06ee3939f2f3e151357d33cfd165603cb40e4d;hb=HEAD#l1056
<rsalvaterra_>
tohojo: I don't know how smart it is yet. :)
<PaulFertser>
Hm, talking about modprobe, now I remember, it ignores module arguments on command line. I wonder if I submitted a patch to print a warning for that or not.
<rsalvaterra_>
tohojo: Yeah, we're hitting this sucker… https://git.openwrt.org/?p=project/ubox.git;a=blob;f=kmodloader.c;h=6f06ee3939f2f3e151357d33cfd165603cb40e4d;hb=HEAD#l909
<PaulFertser>
Apparently I have forgotten
fda has quit [Ping timeout: 480 seconds]
<rsalvaterra_>
PaulFertser: Hey, zram isn't magic… ;) If your working set doesn't fit the RAM at all, well… tough luck. :P
<tohojo>
rsalvaterra_: ah, so we could use 'modprobe -q' ?
<rsalvaterra_>
tohojo: Oh…! Maybe… Let me give it a try here.
<rsalvaterra_>
If it works, I'll send you a pull. :)
fda- has quit [Ping timeout: 480 seconds]
<tohojo>
cool - you could just add it to the openwrt-specific sqm.conf :)
<shibboleth>
speaking of 21.02, any reason why the mikrotik nor 4k erase patch wasn't merged in? this way 21.02 won't support mikrotik out of the gate
rmilecki has quit [Ping timeout: 480 seconds]
<slh>
there's a cut-off, at some point it's too late
<slh>
and in case of PR#4499, it was much, much, much too late
<Slimey>
heh
danitool has joined #openwrt-devel
<dwfreed>
There's a reason it's version 21.02, hint, it's a YY.MM version
rsalvaterra_ has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
cp- has quit [Remote host closed the connection]
Rentong has joined #openwrt-devel
<rsalvaterra_>
tohojo: Come to think of it, I'd rather not hardcode executable locations in sqm.conf… Finding them at runtime makes things more robust, if for some reason they're relocated (unlikely, I know, but still…)
<tohojo>
well, you could still do the 'command -v' in sqm.conf I suppose? it's just sourced as a shell file
<rsalvaterra_>
Hm, sure, I guess… but in that case I think it would have to be the whole enchilada. Let me show you…
tmn505 has quit [Remote host closed the connection]
<tohojo>
yup, that's better... of course this will also affect platforms other than openwrt, but that's probably fine, since regular modprobe also seems to have a -q switch
Tapper has quit [Quit: Tapper]
goliath has quit [Quit: SIGSEGV]
pmelange has quit [Quit: Leaving.]
fda has quit [Read error: Connection reset by peer]
fda has joined #openwrt-devel
fda has quit [Read error: Connection reset by peer]
fda has joined #openwrt-devel
<rsalvaterra_>
tohojo: Yeah, I went through the modprobe manpage just to make sure. :)