I've tried at multiple different times of day though ( morning, mid-day, night ). Also when I check the Buildbot, some times has been mostly idle, with the target showing having built up to 18 hours ago.
As an alternative to retrying the build repeatedly and waiting to see if it errors out; is there somewhere / something else I could check to see what is holding up kmod-lib-crc32c, or when it is available? Thank you.
Oh, ok! When I looked it up, it appeared to be a dependency for several core components. I didn't realize it had been deprecated, I have a list of packages in a txt file to paste when I cusotm build. I have removed kmod-lib-crc32c from it. Thank you.
From that I am interpreting that it is indicating I have too many packages selected for the device. The package list is the same I have used repeatedly for that target though.
For long term maintenance, it does make sense to distinguish betwen addon packages you actually want to add - and mere dependencies and/ or default packages that will be there anyways. That approach makes situations like this easier, when dependencies change (hint, it's very rare that explicitly depending on a lib package is needed, similar (but not quite this black&white) for kmods, most of these should be pulled in via package dependencies as needed).
What confused it for me a bit is that I used to use this to get package list to when I was going to do a new version build / fresh install on a device.
opkg list-installed | cut -f 1 -d " "
Since opkg was replaced with apk, now I have been doing this to get the installed package list for new builds:
That library's functionality has been subsumed into other kmods in the 6.18 kernel. Normally, the ASU package_changes would handle this removal, but since there is currently a mix of 6.12 and 6.18 on main snapshot, something will break for somebody.
As soon as 6.18 is in production across the board (or nearly so), I'll fix the package changes to do auto-removal...
For the purpose of ASU in main, I can't really imagine any realistic use case where someone would explicitly/ intentionally install kmod-lib-crc32c, it should (almost?) always be pulled in via dependencies. Just talking about this specific package, of course - not in general. So even with targets remaining on v6.12 (for now), it should be safe to assume the v6.18 state of letting it go (in main).
--
Yes, I totally understand not wanting to go this deep into packaging details for individual packages.
Yeah, that's the weird thing, that specific package as you say should be only ever be a dependency, so is excluded from normal ASU requests, which only include top-level packages. Yet, I've seen this specific error a dozen times now, on the forums and github issues, so there's apparently something going on here. I suspect I'll do as you suggest and just drop it now.
Aside: I've been collecting the errors from the sysupgrade.openwrt.org server for most of the year, and it shows this happening 4-6 times per day. Maybe people just blasting Firmware Selector with every package under the sun, bypassing all the analysis that LuCI ASU and owut do???
The reason I ended up in that situation is that over the years, the number of packages I have discovered, found use for, and installed has grown. Software tab currently shows 308. I can't remember them all and hard to distinguish between them at a glance.
I realize many of those are dependencies. I just don't know of a way to parse them out, so have been relying on the installed package list (contents of the 'world' file in etc / apk folder) when doing a new build.
If you are rebuilding from Firmware Selector, I'd keep the paste-in list to packages you deliberately asked for, not the whole installed set. Anything that is just a lib/kmod dependency is usually safer to leave out and let apk pull in again. For the size error, I would also try one build with only the must-have extras, then add the rest in small chunks so the failing group is obvious.
Yes, I will need to parse out my package list which has built up over time. The challenge is figuring out what is actually a dependency.
Not sure how accurate this is, as being results from search engine on a query about "Are all "kmods-" dependencies?"
There are a couple of simple ways. First is the canonical method, used by all sorts of tools. It grabs the underlying opkg or apk database and computes the full package list ({"all": true}) or as below, just the top-level packages which leaves out all the depenencies:
Here's a nice little educational exercise. Compare the output from these two commands and see if you can figure out what's common among the packages that package_list includes, but owut does not. (Hint: go over to the firmware selector and look at its default packages for your device.)
PR submitted. 