<cruxbot>
[opt.git/3.7]: bindutils: update to 9.18.18
<cruxbot>
[opt.git/3.7]: firefox-bin: update to 116.0.3
<cruxbot>
[core.git/3.7]: cmake: update to 3.27.3
<cruxbot>
[xorg.git/3.7]: xorg-libxcb: update to 1.16
<cruxbot>
[xorg.git/3.7]: xorg-xcb-proto: update to 1.16.0
farkuhar has joined #crux
<dim44>
How to know which package owns a file that gives me the "Already installed, please use -f to force" error?
<SiFuh_>
prt-get fsearch <filename>
<SiFuh_>
You will probably find it is the same package that you are installing since in most cases
<farkuhar>
pkginfo -o <filename> might work too, but pkginfo is not very smart in its handling of symlinks, so SiFuh's solution is preferred.
ppetrov^ has quit [Quit: Leaving]
<dim44>
SiFuh: If I find that it is the same package then that means that it didn't get removed/uninstalled properly and I can safely force the install right?
<SiFuh_>
I'd check if the old package is installed first. Then uninstall it and try installing the new package. If there is still a conflict, I'd then compare the old packages footprint with the new footprint. Then search for rememnants left over in the system and remove them manually.
<dim44>
I just wrote a script to check the leftovers from the .footprint. Is there also a command to do it?
<dim44>
Also for a year or so now I've been getting problems with .la files. In this build libpixman-1.la is the main culprit. How do you guys solve this? I usually just find the .la file online
<farkuhar>
dim44: one downside of delaying for so long the CRUX 3.6 -> 3.7 upgrade is that some of the packages you had installed are now listed under new names. As the most recent example, python3-mysql got renamed to python3-mysqlclient.
<dim44>
jaegar, farkuhar: thanks for the libtool tip, it's been bugging me for some time now, nuked appropriately
<farkuhar>
A less drastic solution to the problem of missing .la files is to grep recursively /usr/lib for any references to the supposedly-missing .la file, and rebuild the ports that own any files found.
<farkuhar>
You could also prevent the .la files from getting installed in the first place, by putting the line "INSTALL ^usr/lib/.*\.la$ NO" in your pkgadd.conf.
<dim44>
farkuha: I tried that, didn't work. It was probably from an older version
<dim44>
farkuhar: The pkgadd.conf addition seems to be the easiest solution
<farkuhar>
dim44: be careful, though ... it might have unwanted side effects
<dim44>
farkuhar: About packages having new names. For things that are so high up the stack I don't really mind. It's usually problems with base packages that I find difficult to deal with.
ppetrov^ has joined #crux
<dim44>
farkuhar: I've got some errors building that seem difficult but I wanna finish with the easy errors first.
<farkuhar>
dim44: point taken. The maintainers are usually more cautious with renaming core ports than with renaming opt/xorg/contrib ports. I was just offering another possible reason for seeing the error "Already installed, please use -f to force".
<dim44>
The nvidia port has a footprint mismatch (MISSING) for 2 wine files ( usr/lib/nvidia/wine/_nvngx.dll, usr/lib/nvidia/wine/nvngx.dll). Is this safe to ignore?
<SiFuh_>
An underscore is the new file or old?
<dim44>
Sifuh_: not even the folder nvidia/wine itself exists. That's why I thought that it was related to the fact that I don't have wine
<SiFuh_>
Not sure what is going on there then
<farkuhar>
dim44: that's the expected behaviour on a system without wine, in light of the nvidia Pkgfile stanza that starts "if prt-get listinst --regex '^wine'" ... Most likely the maintainer accidentally updated the footprint after building on a system with wine installed.
<dim44>
farkuhar: Ah thanks for the confirmation
<dim44>
I'm getting a compile error for lld. I'm using gcc 12.3.0. I'm also getting errors with llvm and clang but they should be related to lld.
<dim44>
I mean because one of the reasons using crux is that you don't really need to do a fresh install
<SiFuh_>
I don't know about that ;-)
<dim44>
It's like Linux From Scratch with helper scripts
<SiFuh_>
I have never upgraded CRUX in my life. I have always just done a complete fresh install and used my backup to assist in configuration. It is more of a "Well I have done it, and it is fresh" kind of feeling
<dim44>
I guess that if you setup your system from the beginning with this in mind it would be easier
<dim44>
By the time the next update comes perhaps I'll have made sure that my configuration is easier to transport
<dim44>
Btw I think I solved the lld llvm problem
<dim44>
The llvm Pkgfile uses lld if available (but in this case it's broken) so one package was depending on the other
<dim44>
and vice versa
<SiFuh_>
CRUX might be fine for an upgrade, but the contributed packages from other users may cause you a headache
<dim44>
Sifuh_: btw, how do I see which of the installed packages come from where (core,contrib, custom)? prt-get listinst -vv doesn't show it. Is there a utility to do it or just awk?
<farkuhar>
dim44: prt-get printf '%i:%p:%n\n' | grep -v no
<dim44>
farkuhar: nice, thanks!
<farkuhar>
actually the consumer of the pipe should be "grep -v ^no"
<dim44>
Thanks everyone for the help. The last few errors seem to all be related to cyclic dependencies.
<dim44>
Btw I really learned a lot about Crux going through this process
<SiFuh_>
Yeah, I was thinking the same
<cruxbot>
[core.git/3.7]: util-linux: update to 2.39.2
<cruxbot>
[opt.git/3.7]: screen: update to 4.9.1
<farkuhar>
dim44: in addition to cyclic dependencies, you should also be mindful that a major upgrade like CRUX 3.6 -> 3.7 might involve ports that have acquired new dependencies since your last successful build. If those new dependencies weren't previously installed for other reasons, then your sysup command might fail.
<farkuhar>
See Flyspray issues 849 and 1605, for further discussion of how we might address this shortcoming of prt-get.
<dim44>
farkuhar: I did get some new dependencies errors, but they were easy to solve with prt-get deptree. The problem with the cyclic ones was that they were not immediately visible especially in the beginning when I had about 15 packages failing.
<dim44>
farkuhar: the depcheck patch from 1605 looks pretty nice though. I was thinking of asking how to do this. Mostly as a sanity.