<farkuhar>
Flyspray bug #1576 proposes a complicated workaround to the problem of soft dependencies in CRUX ports. Dealing with optional dependencies and footprint mismatches is a common source of contention, but I'm curious what else Mellowlink finds dissatisfying about the current system.
pedja has quit [Quit: Leaving]
tilman has quit [Ping timeout: 256 seconds]
tilman has joined #crux
SiFuh has quit [Ping timeout: 240 seconds]
SiFuh has joined #crux
<braewoods>
farkuhar: the only true solution requires something more capable than what crux has. which, if that's what crux users wanted, would probably be using gentoo already.
<braewoods>
but gentoo's source packages give a lot more options. but they're also a bigger hassle to maintain. :P
<braewoods>
honestly question the value of fine-tuned dependency management like this
<braewoods>
it introduces more variables so it can make tracing strange issues more difficult
<cruxbot>
[contrib.git/3.6]: remind: update to 03.04.00
<SiFuh>
Fsck intel
<ppetrov^>
software-upgradeable CPUs?
<ppetrov^>
the times we live in
volgk has joined #crux
volgk has quit [Client Quit]
<farkuhar>
braewoods: "a bigger hassle to maintain"? I wonder whether we all agree on the same definition of hassle. It could be measured in the L-infinity norm (maximum hours of upkeep spent by any one user), or the L-1 norm (total number of person-hours spent on package upkeep). CRUX appears less of a hassle on the first measure, at the expense of widely distributing the port customization tasks among its users.
volgk has joined #crux
pedja has joined #crux
<braewoods>
farkuhar: well every so often you get weird issues due to differences in people's build environments. since this is source based you have to factor that in as well.
<braewoods>
with binary repos you can more readily reproduce issues because everyone uses exactly the same packages
<braewoods>
this is especially the case with optional depends they didn't have installed
<braewoods>
of course... not the only variable but it's one of the few you can factor out.
Mellowlink has quit [Quit: Mellowlink]
ben-linux23 has joined #crux
<ben-linux23>
hey all, i am installing crux for the 1st time on my hp laptop, and i see a port for KDE4, but i dont know how to add it, i did check the wiki but i still dont know how to add the .rsync file tbh
<farkuhar>
braewoods: I agree that fine-tuned dependency management as proposed in FS#1576 is overly complicated for most environments. Fun's argument against PKGMK_IGNORE_NEW ("reduces the utility of the .footprint file") seems like grasping at straws, imho.
<stenur>
ben-linux23: add a prtdir in /etc/prt-get.conf, and use an .rsync from /etc/ports as an example
<ben-linux23>
ok
<braewoods>
ben-linux23: i would advise caution. KDE4 has been dead for years, upstream wise.
<ben-linux23>
yeah i know, i just dont have a better gui i'd wanna use imho
<farkuhar>
Fun's cited disadvantage of the make-your-own-port workaround ("reduces the likelihood for a new user to become a contrib maintainer") is more interesting. I think the larger barrier to becoming a contrib maintainer is that the application process emphasizes the addition of new ports to the repository, rather than the upkeep of existing ports.
<stenur>
i think most projects struggle with too few and too old maintainers
<stenur>
'Just heard that on an OpenBSD list, this or last week (or so).
<stenur>
...and there you could have Hackathons all around the world, .... aka by plane and give a shit on environment
<stenur>
:-)
<farkuhar>
Candidates who are more interested in relieving the workload of maintaining the existing ports than in adding new ports will self-select against applying for contrib, on a naive reading of the ContribRules wiki. A more welcoming ContribRules page would offer entry points for people who just want to help out with the existing ports.
<stenur>
But hey! Nothing compared to environmental killings by military manouveurs or how is it written in english; the US army alone burns more than several large European countries (Portugal plus)
<pedja>
iirc, that's how I eventually ended as contrib maintainer: sent patches/updates for existing ports until devs decided I can join the fun directly :)
<ben-linux23>
ok guys so i added the kde4.rsync file to my /etc/ports and prtdir /usr/ports/kde4 to my /etc/prt-get.conf now how do i get the kde4 packages installed as a whole? i dont want just specific kde4 apps/pkgs
<ben-linux23>
i want the whole kde4 thing
<pedja>
might be better off with xfce, that one is at least maintained
<pedja>
(afaik)
<ben-linux23>
yeah its just i already added the .rsync file for kde4 and i would prefer to install it
<ppetrov^>
ben-linux23, it may break. I don't know when the last time was someone tested it
<ben-linux23>
i see, well, fingers crossed it dont
<ppetrov^>
openbox runs ok?
<ben-linux23>
i just ran prt-get and it didnt find the kde4 pkgs and im unsure how to sync the repos to add kde4
<ppetrov^>
ports -u
<ben-linux23>
oh ok
<ben-linux23>
running it rn
<pedja>
'prt-get depinst kde4-meta-full' should do it, but check other kde-meta-* ports
<ben-linux23>
ok
<ppetrov^>
what ISO did you use to install CRUX? The default or the unofficial updated?
<ben-linux23>
i used the updated one
<ppetrov^>
ok
ben-linux23 has quit [Quit: Client closed]
<cruxbot>
[xorg.git/3.6]: mesa: update to 21.3.6
<cruxbot>
[opt.git/3.6]: glib: update to 2.70.4
<cruxbot>
[opt.git/3.6]: imlib2: update to 1.8.0
<cruxbot>
[opt.git/3.6]: lcms2: update to 2.13.1
<dlcusa>
frinnst, ppetrov, IBM developed this concept decades ago for mainframes, and most customers appreciate having a much better box than they're paying for that they can temporarily upgrade when a crunch comes without having to upgrade hardware. Of course, mainframes have a ton more overhead than most servers. This may not work as Intel hopes.
<dlcusa>
s/overhead/logistical overhead/
ppetrov^ has quit [Quit: Leaving]
_moth_ has quit [Remote host closed the connection]
_moth_ has joined #crux
Guest35 has joined #crux
ben-linux23 has joined #crux
<ben-linux23>
heya guys, i got the crux ports of kde4 installing now, no error so far
<Guest35>
hi ben-linux23, good luck to finish kde! i am just trying to finish my sysup on a very basic install. i get out of space error on my gcc update but I don't know how it could be... my root is 20G and only 7.7G used.
<ben-linux23>
that's ironic, although this is my first crux install, did you use a seperate home partition by chance?
<Guest35>
yes, i have a separate home 20G also and less than 1G in use.
<ben-linux23>
weird, it shouldnt be out of space then
<ben-linux23>
out of curious how much space do you have in your computer you put crux to?
<Guest35>
my disk 120 ssd but i only set up 20g root 4g swap and 20g home
<ben-linux23>
right i would say 20gb each is maybe too small for each one
<ben-linux23>
i would suggest maybe 50gb for root, 4gb for swap and the rest to home
<Guest35>
ben-linux23, i am just experimenting with different setups so my final system will have bigger partitions.
<ben-linux23>
gotcha
<Guest35>
ben-linux23, my attraction to crux is that it is hands on and minimalist distribution. how about you?
<ben-linux23>
i just wanted to try a new distro tbh
ty3r0x has joined #crux
<Guest35>
just trying to understand how pkgmk works... 1) source code tar.gz downloaded 2) tar.gz made into a package pkg.tar.gz 3) pkg.tar.gz untarred and unzipped 4) source code compiled 5) the resulting compilation is installed on the system. Is that correct?
<SiFuh>
No
<SiFuh>
1) download source, 2) extract source, 3) compile source, 4) package built source, 5) install built source
<SiFuh>
sleep and bye bvye
<Guest35>
SiFuh, so is package built source is a binary which later gets installed?
<ben-linux23>
im back was afk
<farkuhar>
Guest35: /usr/bin/pkgmk is a bash script, pretty well-documented if you open it in a pager. Steps 1--4 of the process SiFuh outlined all have their corresponding functions within pkgmk.
<farkuhar>
Step 5 is done by pkgadd, which is a binary executable compiled from pkgadd.cc (and linked to other shared object files). pkgadd performs Step 5 of the process SiFuh outlined.
<Guest35>
farkuhar, thanks for the info. I will review the script in /usr/bin/pkgmk
<farkuhar>
Both pkgmk and pkgadd can be tuned to suppress the installation of certain files you don't want on your system, using the corresponding *.conf files in /etc. Read their manpages for the syntax.
<Guest35>
my follow up question is if there is any point in keeping pkg.tar.gz files?
<farkuhar>
The most common reason to keep the pkg.tar.gz files is if you have a less-powerful computer also running CRUX, and you want to share the built packages without using any CPU time on the slow computer. Just share your $PKGMK_PACKAGE_DIR on the local network, and mount it from the slower computer. You can then pkgadd the fruits of your faster CPU's labor.
<farkuhar>
Flyspray issue #1888 claims that a rule like "INSTALL etc/.*$ NO" in pkgadd.conf will result in data loss. I haven't been able to reproduce this bug yet, but if you do try to customize pkgadd.conf, it's best to stick with UPGRADE directives for now.
<Guest35>
farkuhar, the packages in crux are binaries in the sense of other linux binary distributions?
ben-linux23 has quit [Quit: Client closed]
<farkuhar>
Guest35: each pkg.tar.gz is a tarball archive of the binaries built by the compiler, along with manpages, headers, and other needed files. But each user's build environment is slightly different, so the binary you build of, say, mpd, might be linked to a library that's not present on some other CRUX user's system. You can't easily share the built CRUX packages because of the soft-dependency problem.
<farkuhar>
So what we share with each other instead are the Pkgfiles, hosted in our own port repositories. If you take care to build in a minimal container, then the footprint that appears in your port repository won't trigger any MISSING errors when another user tries to build your port.
<cruxbot>
[opt.git/3.6]: thunderbird-bin: updated to version 91.6.0
Guest35 has quit [Quit: Client closed]
volgk has quit [Quit: Client closed]
Guest35 has joined #crux
<Guest35>
my mesa update fails due to footprint mismatch but all my dependencies show up as installed. what could it be?
ty3r0x has quit [Quit: Konversation terminated!]
<farkuhar>
Guest35: what is the exact error reported by prt-get? Is it a MISSING files error, or a NEW files error?
<farkuhar>
If you leave PKGMK_IGNORE_MISSING and PKGMK_IGNORE_NEW turned off, then prt-get will abort the update for any kind of footprint mismatch (expected files not generated by the build function, or unexpected files generated by the build function). The latter type of error is usually safe to ignore.
<farkuhar>
Your built package made use of the soft dependency libvdpau, and generated more files than are listed in the footprint. That's the expected behaviour, so go ahead and pkgadd the resulting package.
<farkuhar>
In future you could set PKGMK_IGNORE_NEW="yes" in /etc/pkgmk.conf, and prt-get will do the upgrade without your manual intervention.
<Guest94>
farkuhar, thank you! where can I learn how to interpret this for myself?
<farkuhar>
The pkgutils commands all have incredibly useful manpages, as do many of the associated *.conf files. Then there's the CRUX handbook, especially the section on maintaining ports.
<Guest94>
farkuhar, thank you.
<farkuhar>
Fun writes in Flyspray issue #1576 that the IGNORE_NEW workaround "reduces the utility of the .footprint file". I wonder if Fun was thinking about the scenario when a Man-in-the-Middle somehow persuades wget to download a corrupted tarball, injecting malicious files into the $PKG folder. That scenario is hardly worth contemplating now that most packagers use signify(1) for their ports.
<farkuhar>
I would argue that the .footprint file is still just as useful even if you only leave PKGMK_IGNORE_MISSING="no". That way you'd still catch the odd situation where the build function acts as if your CPU architecture was unknown, populating /usr/share with the exact same filenames that show up under /usr/lib in the footprint.
<Guest35>
was there a way to avoid the soft dependency on libvdpau? what was pkgmk expecting instead?
Guest94 has quit [Quit: Client closed]
<farkuhar>
You could modify the port and explicitly tell the configure script (or cmake, meson, whatever) NOT to use an optional library. But why do that, since the additional functionality comes at little extra expense now that you've got libvdpau installed anyway?