<beerman>
compiler-rt will need a footprint update
<pitillo>
checking
<pitillo>
I had rust and llvm updated here too but haven't pushed (32b)
<beerman>
do mind that with ports like rust we have added a maintainer-clean-footprint script, to clean up the footprint of a port. it depends on setting "IGNORE_NEW_FILES" or whatever it was called.. but the problem is that certain ports produce inconsistent footprint, like files that have random hashes as file names etc. rust, grafana, gtk4 come to mind. the latter will build a stupid printer backend based on if you have cups installed or not
<beerman>
so it will produce two different files, which is kind of stupid... but oh well
<pitillo>
interesting... a bit messy
<pitillo>
but probably a handy way to manage this situation
<beerman>
i have a script to build ports in my container, it will run the file if it exists in the end so i don't miss executing it. its the easiest solution that comes to mind
<beerman>
ah, mh, i dunno if its different on arm, its not perfect on my x86_64 hosts but it does help
<pitillo>
ummmm at a first sight it remembers me to scx (safe-crux script we had to build ports inside jails)
<pitillo>
but I believe that one can be adapted to get a ARM rootfs and create the container (similar to what jaeger_ explained me to create a docker image)
<beerman>
well, this builds a persistent container image
<beerman>
i never used the safe-crux script, but i agree, its similar
<beerman>
yep, exactly
<beerman>
i just like lxc over docker for that purpose
<pitillo>
scx is to sort and work with jails which are directories, images... but if finish being just a chroot managed over bash
<beerman>
speaking of scripts, i refined my create-kernel script
<pitillo>
I haven't experience with lxc and not much more with docker
<pitillo>
I've being creating some for the chromebook too (which can be interesting to manage gcc dependencies in some cases, for example, old kernel 3.4 requiring gcc 4.X)
<beerman>
but as a package you don't really get to supply your own config without going around pkgmks security
<pitillo>
so we can maintain old gcc ports outside main and use them to build specific kernel versions
<pitillo>
yeah, but think that we can provide a way to build a tested kernel for a specific device
<pitillo>
and if the user knows about crux, it's easy to use the port's source to create a custom kernel config file
<pitillo>
security in this case will be related only to kernel source
<beerman>
i am not the biggest fan, but i see the advantages of that
<beerman>
in any case, you would just need to add a defconfig line in there, and pull tagged balls from git
<pitillo>
all can be hardcoded into the Pkgfile just to get the exact kernel version which is supposed to be the right one
<pitillo>
which builds and provides good support... letting the used add whatever needs
<beerman>
well, yeah, we can put that on a todo if you want
<pitillo>
of course, there is no hurry
<beerman>
first to do should be getting the raspberry pi firmware tool into the rpi4 repository
<beerman>
the pi i am working on i had to update before i could boot off the ssd 😄
<pitillo>
on llvm you haven't specified the target to build. It's aarch64 detected by default and other targets aren't built or are all the targets built?
<beerman>
all targets are built
<pitillo>
interesting
<beerman>
like i said, its what is expected actually
<pitillo>
I had lot of problems and like we spoke the other day, I cut them off building only ARM target (32b)
<beerman>
if you cut down targets you criple the build and certain software might not build/run
<pitillo>
sounds great IMHO
<pitillo>
if you are able to build all targets without problems... it's the way to go
<beerman>
it builds a bit longer but i don't really care about the build time
<beerman>
it finished fine 🙂
<pitillo>
build time shouldn't be a problem.... if builds finish right
<beerman>
since adding swap i have only failed the qt6-webengine build. which is huge, so...
<beerman>
firefox took around 8-9 hours too but went through perfectly fine with the overlayed pkgfile I shared earlier, cbindgen etc
<beerman>
but wasi-libc would fail without the llvm build target for it etc
<pitillo>
interesting the llvm part... I didn't know about all the targets stuff
<pitillo>
about FF is fine, lot of dependencies, some of them must be adapted and give time to its build.... 8-9h are a lot, but less than more than a day xD
<beerman>
yup
<beerman>
http://sprunge.us/8e0LZv i missed to include the patch for x265, i pulled that off archarm
<pitillo>
ummmmm
<pitillo>
+ message(STATUS "Detected ARMV7 system processor")
<beerman>
arch does all arches in the same package file
<pitillo>
interesting
<beerman>
indeed
<pitillo>
does your build get the flag DX265_ARCH_ARM64=1 ?
<beerman>
if a Pkgfile can be spared the overlay by using cmake/meson instead of autotools or to run autoreconf -fvi on an autotools project it should rather be fixed in x86_64 core/opt/contrib/xorg, imo
<beerman>
pitillo: haven't checked tbh
<beerman>
the build is dramatically different to the x86_64 build
<pitillo>
yeah, there are a lot of "critical" ports which builds are very different between ARCH
<beerman>
true
<beerman>
minimizing the overlay collection would be good though, and often (e.g. a few python ports) its just the arch spelled out in the footprint that differs
<pitillo>
yeah, most overlays were maintained just for a different footprint
<pitillo>
another bunch due to --build specification for aarch64 which wasn't detected and must be forced at that time (some of them are correct now and removed from the overlay)
<beerman>
ok, i am here pulling a backup of my old armv7 install, i will duplicate the install after that and boot the other one up
<pitillo>
sounds like a plan xD
<beerman>
man i should have skipped the pkgmk dir, fml
<beerman>
3 years worth of compiled packages, whyyyy
<pitillo>
here I'm testing the crux-arm-release build again... I've found libgmp download problem, so I need to review where is the problem
<pitillo>
jaajaajjajaaja
<beerman>
the ssl certificate expired for libgmp lol
<pitillo>
3yrs of work duplicated...
<beerman>
rip
<pitillo>
f
<beerman>
😆
<pitillo>
at least not our fault and no update... so with a source copy I can go ahead building and look for errors
<beerman>
Wednesday, 28 December 2022 at 00:59:59
<beerman>
everybody is on vacation i guess 😄
<pitillo>
xDDD
<pitillo>
and a good day here in spain to be down (your aprils fool is on 28th december here xD)
<jaeger>
In most of my testing of crux-arm-release I duplicated PKGMK_SOURCE_MIRRORS into the local pkgmk.conf
<jaeger>
Mostly to save time downloading but helps with things like that upstream cert issue
<beerman>
i haven't checked out the release build script yet
<beerman>
so, i took the alpine container I pulled yesterday and just exchanged the rootfs, needs a few fixes for sure but it works, got my aarch64 CRUX container 😄
<jaeger>
nice
<beerman>
yep, the container now runs fine. I applied the fixes from the script manually. it should be easy enough to build a clean rootfs image thats properly importable
<pitillo>
yeah jaeger, here I'm using it too, but testing a fully clean build to get things like this one
<pitillo>
let's see if I can check sepen test to get fixed the optimization problem