<chrcav>
thanks jaeger. are pull requests on gittea desireable? or would an issue be better?
<stratofall>
I know this isn't the intended use of prt-get. But it stumps me a little why it does this... I setup /mnt/share/crux/{source,packages} on my server. I have it hosted via nfs. I have the programs compiled on my server. I wanted to share out the source and packages to my other machines to help eliminate compiling. The problem is...
<stratofall>
WHen I setup a fresh machine. Mount the nfs shares and setup the directories in pkgmk to where they need to be. When I run prt-get depinst i3 lets say. It will use the source but it will recompile the package instead of pulling the one that is already in the package folder.
<stratofall>
If I prt-get remove i3. And then prt-get depinst i3 it works as intended. If I remove i3 from the server and reinstall it. It also doesn't recompile.
<stratofall>
I just found it odd it didn't just use the package that was already made. Thinking I did something wrong somewhere. So I am looking at pkg-get to see if that will do what I want. Is there is more complete how to with pkg-get somewhere? For setting up the .REPO file that it wants?
<stratofall>
Or is this something I should just keep different packages built for different machines seperate?
<stratofall>
Also, thanks for the kernel change jaeger :)
serpente has quit [Remote host closed the connection]
<jaeger>
chrcav: the only problem with a PR is no access to the signing key
<jaeger>
Also, I didn't see it until after I fixed the port anyway :P
<jaeger>
I'm not sure if I've ever looked into prt-get's logic for checking existing packages, maybe it could use some improvement?
<jaeger>
stratofall: no problem
<jaeger>
Maybe there's some straightforward way to sign a PR and merge but I haven't looked into that
ppetrov^ has joined #crux
<stratofall>
Maybe a better question. How do people with multiple computers in the house or business that run Crux deploy Crux over multiple systems fast? rsync exclusivly? All the same system designs via hardware?
lavaball has joined #crux
<r0ni>
stratofall: use pkg-get for this, not prt-get. setup the dirs like you would for ports, but in the pkg dirs to create an index run "pkg-repgen"
<r0ni>
then "pkg-get sync" and then use normal prt-get commands after that
<r0ni>
but replace with pkg-get
<stratofall>
So, do I need to make completely new directories with each individual port? I place the pre-made port in that dir?
<stratofall>
Thank you for the response as well. Kind of wondering where I am going yet with this. I know I want it faster, custom, Crux. :)
<ppetrov^>
stratofall, I keep my own packages repo
<r0ni>
stratofall: nah, i keep ports in respective dirs core, opt, xorg, etc just to organize them but you could have one big dir if you wanted
<stratofall>
ppetrov^: very cool thank you. I just read through it and this will definately help me. r0ni ok, yeah it seems I'll need to decide how I will do this. I'll be testing it seems the next few days. Much appreciated to the both of you.
<ppetrov^>
stratofall, optionally make sure your own ports are archived the same way as the packages from the CD: tar.xz, so modify PKGMK_COMPRESSION_MODE="xz" in /etc/pkgmk.conf
<stratofall>
dude, super cool, I have a few pi's... Crux on my pi's would be awesome.
<ppetrov^>
then you can place whatever packages you had on the install cd together with the rest of your own packages
<ppetrov^>
so, you will generate a pkackages repo containing also stuff from the initial installation
<stratofall>
ok, I was using gz ... I'll change it to xz for simplicity.
<ppetrov^>
if you do this, you will need to rebuild all
<ppetrov^>
pkg-repgen can work with either gz or xz, but not both. Or at least in my experience
<r0ni>
ya just make sure compression equals what you're using, else it won't find them
<stratofall>
yeah, I plan to get a base install setup with everything I want, then do a full rebuild so all packages are built accordingly.
lavaball has quit [Remote host closed the connection]
<ppetrov^>
farkuhar, may have fixed these things but what I did was slightly modify pkg-repgen and make it work with xz
<ppetrov^>
sed "s:gz:xz:g" pkg-repgen > pkg-repgen-xz
<ppetrov^>
and save it with a different name
<r0ni>
it works with xz, thats what i'm using it with
<ppetrov^>
ah, so farkuhar fixed this. OK, pls ignore my rambings
<stratofall>
It's good info if I run into a problem.
<ppetrov^>
stratofall, keep in mind that your packages may have linked against something more than what is specified at the Depends on: row
<ppetrov^>
so, upon packages update, always check with revdep
<ppetrov^>
you may need to install extra stuff
<stratofall>
yeah, I saw that on your page.
<stratofall>
I have it bookmarked :)
<r0ni>
ya, deps only list hard ones, not optional ones so it can be an issue occasionally unless you keep things stock opts (or try to)
<ppetrov^>
also this: oldfiles | grep "packages" | xargs rm -rf can easily be: oldfiles -p | xargs rm -rf
<ppetrov^>
obligatory: be careful when running rm -rf
<stratofall>
oh yeah
lavaball has joined #crux
<cruxbot>
[opt/3.7]: transmission-qt: updated to version 4.0.6
<cruxbot>
[opt/3.7]: transmission: updated to version 4.0.6
<cruxbot>
[opt/3.7]: mariadb: updated to version 11.4.2
<cruxbot>
[opt/3.7]: gnuplot: updated to version 6.0.1
<cruxbot>
[opt/3.7]: conky: updated to version 1.21.2
<cruxbot>
[core/3.7]: meson: updated to version 1.4.1
<cruxbot>
[core/3.7]: xz: updated to 5.6.2
<cruxbot>
[contrib/3.7]: transmission-gtk: updated to version 4.0.6
ppetrov^ has quit [Quit: Leaving]
<cruxbot>
[opt/3.7]: ruby-doc: updated to version 3.3.2
<cruxbot>
[opt/3.7]: ruby: updated to version 3.3.2
<farkuhar>
stratofall: how are you sharing the ports collections among the different machines? Are they also mounted via nfs? The logic in pkgmk's build_needed() is based on comparison of timestamps, package vs. each existing source file (line 713), and also package vs. the Pkgfile (line 720). Share only the source and package directories via nfs, and you satisfy the first comparison but perhaps not the second.
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux
bru-barwal has quit [Read error: Connection reset by peer]
<stratofall>
farkuhar: I was planning on using nfs for just the source and packages directory. And that is how I setup my first test computer.
<stratofall>
I'll try to see how sharing the Pkgfile ports dirs deals with this as well when I have time later tonight. I'm kind of curious. But from what I gather the pkg-get and using ppetrov^ and r0ni's examples should also satisfy my needs.
<stratofall>
Sharing out the ports dirs via nfs makes it so the client will also re-download the source and still compile the package. I'll move toward pkg-get now.
ppetrov^ has joined #crux
ente has joined #crux
<ente>
hi
<ente>
long time no see
<jaeger>
heyo
<ente>
I think it's time for me to reinstall my linux machine
<ente>
maybe crux+pkgsrc, I've never tried that combo
<jaeger>
Tired of whatever's running currently?
farkuhar is now known as jmq
<ente>
I have my personal laptop on antix and the work machine on nixos
<ente>
antix is nice because it bundles a lot of lightweight tools into something that can be administered by someone who is just starting to learn linux skills on a deep level, and ships a bunch of non-default-desktop-environment tools that you otherwise wouldn't hear about
<ente>
but I also have a kinda complicated installation (granted, my choice but with crux I always felt it didn't interfere much with my meddling on a system on pretty much any level) and their stuff does a bit too much for my taste, for example the scroll direction changes randomly
<ente>
close but no cigar
<ente>
nixos... well
<ente>
I actually kinda regret it
<ente>
have to compile in a debian chroot because their gcc wrapper inserts some commandline arguments that are nixos specific but for work I'm cross-compiling to first host-x86 and then ARM
<ente>
(yocto does this part of the build automatically)
<ente>
so I actually have a debian chroot to do the compile work in
<ente>
nixos has 5000 open bugs, some long-standing, including concerning the way their python infrastructure loads shared libraries - I provided a workaround but got no response
<ente>
I like the whole idempotent nix-store blabla in theory but would rather use something else
<ente>
haven't tried guix yet, that's also on my list of potential future guinea pigs
<ente>
also nix (the programming language) has some awkward unusual syntax not inspired by any other programming language aside from "" for strings and # for comments
<ente>
so hm
<ente>
jaeger: tired of inconsistent inoperable systems that break during boot or updates maybe?
<ente>
I know, I'm kinda asking for a unicorn there :)
<ente>
that's the crux of it, badum-tish
<jaeger>
fair enough, heh
<ente>
and pkgsrc because I always liked BSD-style base-system-does-base-stuff-packages-live-out-of-tree
<ente>
I don't see why every distribution ever should repackage every package ever
<ente>
plus it's well-documented, clean and easy to use but not as frugal as prt-get
<ente>
maybe it even has binary packages for linux these days, who knows
<ente>
anyway, that's not happening today
<ente>
did any of you try bcachefs?
<ente>
seems like a good choice for a ports collection file system
<jaeger>
It's been a long time since I looked at it last
<ente>
the last straw on antix for me was that suspend to ram broke. it was working for ages, now it doesn't.
<ente>
# stat /
<ente>
...
<ente>
Birth: 2023-02-06 00:40:24.000000000 +0100
<ente>
not great, not terrible
lavaball has quit [Remote host closed the connection]