lavaball has quit [Remote host closed the connection]
ppetrov^ has quit [Quit: Leaving]
pitillo has joined #crux
pitillo has quit [Changing host]
ppetrov^ has joined #crux
<cruxbot>
[contrib/3.7]: rust-bin: updated to version 1.84.1
ivandi has quit [Quit: WeeChat 4.5.1]
lavaball has joined #crux
ivandi has joined #crux
_moth_ has joined #crux
zorz has joined #crux
jason123onirc has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
jason123onirc has joined #crux
ivandi has quit [Quit: WeeChat 4.5.1]
jason123onirc has quit [Client Quit]
jason123onirc has joined #crux
zorz has quit [Quit: leaving]
ivandi has joined #crux
_moth_ has quit [Remote host closed the connection]
jason123onirc has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
jason123onirc has joined #crux
Laxy has joined #crux
<Laxy>
(test) Hello
<cruxbridge>
<tim> Hello
<Laxy>
i have no info about IRC, its like a chat, but where hosted? the host store plain data? sorry if off-topic
<cruxbridge>
<tim> You can read something about this network on their site https://libera.chat/
<Laxy>
Crux is a OS that have not a default desktop env? just run in cli mode, correct?
<Laxy>
and which desktops compatible with it ?
<cruxbridge>
<tim> I think currently openbox is as default as it gets because its supplied by the ISO to install
<cruxbridge>
<tim> desktops.. mate, kde6 and xfce4 are around, I think enlightment is working too, no idea but there might be more
<Laxy>
i dont see any info about desktops at Crux online Documentation, its better add in future
<Laxy>
Thanks for all cruxbridge
<cruxbridge>
<tim> cheers ;)
<farkuhar>
Laxy: Between CRUX users who take the time to write documentation, and CRUX repository maintainers who successfully build and then daily-drive the desktop environments in their repos, I would trust the latter. Usually the port READMEs are enough to get you going, if there's anything more complicated than what appears in the upstream docs.
<Laxy>
Thanks farkuhar
<farkuhar>
Heh, funny that I happened to stumble upon the Bruce Perens rant against Qt-derived applications about an hour before Laxy's question. `head -n 1000 /usr/share/games/fortune/linux | tail -n 4`
lavaball has quit [Remote host closed the connection]
<darfo>
What is the advantage to PKGMK_PACKAGE_DIR="$PWD" instead of putting them all in one place with PKGMK_PACKAGE_DIR="/usr/ports/packages"?
<jaeger>
No advantage in my opinion, just personal preference.
<ppetrov^>
darfo, I put them in one folder, which i check for old files and make packages repo for my other computers
<ppetrov^>
so, yes, personal pref
<darfo>
That's exactly why I put them in one place too.
<ppetrov^>
then use pkg-get on your other computers
<ppetrov^>
instead of prt-get
<darfo>
Will check out pkg-get. Been using a hack of prt-get.conf makecommand on my other computers.
<farkuhar>
darfo: You might remember this classic observation by Vitaly, that pkgmk.conf governs the behaviour of not just pkgmk, but also prt-get: https://lists.crux.nu/archives/list/crux-devel@lists.crux.nu/thread/BNW2BYKMQ5FJSJ3UKZ4KZVXSRVE7U4YW/ So while arbitrary command substitutions will work when pkgmk uses those variables, prt-get might evaluate the definitions differently, and fail to find the built package.
<darfo>
I only change makecommand in prt-get conf on "other computers" to invoke a script called pkgmk-by-proxy instead of running pkgmk. No changes to pkgmk.conf to access binary packages.
<farkuhar>
In the March 2004 thread, sip and jw both endorsed the existing separation of concerns, where pkgmk would never concern itself with anything outside its current working directory. The default definitions found in /usr/bin/pkgmk and /etc/pkgmk.conf are an artifact of this history.
<darfo>
I like that pkgmk/pkgadd/pkgrm have all remained at a "port level view". prt-get for the high-levels stuff like dependency resolution.
<darfo>
Good to know. I suspected there was a good (historic) reason for the default PKGMK_PACKAGE_DIR="$PWD".
Laxy has left #crux [#crux]
<farkuhar>
Obviously the BSDs were the inspiration for a directory tree containing the ports, but even by the early 2000's the Linux world itself was coming up with innovations in the ports idea, specifically when it came to defining global options affecting how ports are built or configured (think Gentoo-style USE flags). ukky was recently wondering if such innovations had made their way back to *BSD (allowing the user to choose among SSL providers?)
<farkuhar>
SiFuh_ replied that while the BSDs support the possibility of compiling world from source, it's much less supported to try patching individual pieces of the ports tree and getting the resulting build to work with the official binary packages for the rest of the system. But CRUX doesn't suffer from this binary/source hybrid problem, so a global config would be safer to implement.
<farkuhar>
To use ukky's example, we could have in pkgmk.conf or another config file: SSL_PROVIDER=OpenSSL , with the option to change its value to LibreSSL or WolfSSL. Then the tooling could be told to do the right thing when building any port that depends on SSL.
cruxbot has quit [Ping timeout: 252 seconds]
cruxbridge has quit [Ping timeout: 276 seconds]
<farkuhar>
Or to use one of SiFuh_'s pet peeves, define in that same config file: USE_PAM=yes , with the option to change its value to no. Then the affected ports could have their build functions adjusted accordingly (i.e., apply patches or run configure with different flags).