<jaeger>
you can fix a lot of problems with the boot media :)
<jaeger>
boot/install
<braewoods>
ahmadraniri[m]: when they said to nuke it from orbit, they were kidding. :P
SiFuh_ has joined #crux
SiFuh has quit [Ping timeout: 264 seconds]
deltahotel has joined #crux
deltahotel has quit [Quit: deltahotel]
ppetrov^ has joined #crux
pitillo has quit [Ping timeout: 246 seconds]
pitillo has joined #crux
budzak has joined #crux
budzak has left #crux [#crux]
SiFuh has joined #crux
SiFuh_ has quit [Ping timeout: 260 seconds]
elderK has joined #crux
<elderK>
Hey guys, are there any gotchas regarding Crux 3.7 if I want to upgrade?
<elderK>
Say, from 3.6?
<SiFuh>
3.7 frieds your hard drive
<SiFuh>
Fries*
<elderK>
Good to know. Does it go well with salt? :P
<elderK>
The main thing I was curious about is like, you know, how it will deal with packages I already have installed and what not.
<SiFuh>
Hahaha I think you 'gotcha'd me
<elderK>
I was thinking of doing a full reinstall anyway. It's been a pretty long time since I reinstalled this system and it's probably getting cruft, even though I work hard to keep it clean :)
<SiFuh>
I have installed it yet. So I can't really comment. I will soon, I just have to finish work first. So probably end of the week. I heard mostly good and easy things.
<SiFuh>
The guys did work pretty hard on it
<elderK>
Excellent. I guess I'll try it out, too. If it doesn't go so well, well, I was going to reinstall anyway.
<SiFuh>
I did hear upgrading but not sure.
<SiFuh>
I will only do a reinstall myself
<elderK>
I really need to find a nicer way to keep my system totally clean.
<elderK>
Soon I will start working to learn Docker so I can do my packaging work there :)
<elderK>
I figure it's really just a cool way to run a chroot inside of a container.
<elderK>
That'll be useful.
<elderK>
I wonder what advantages docker has over a simple chroot?
<SiFuh>
I use a VM and have never been able to get my head around a docker
<elderK>
I guess I'll have to learn. AFAIU, it's just a lightweight vM in a sense.
<elderK>
Instead of virtualizing the hardware, it's just sealed off from the rest of the system, in a way that's much more "boxed in" than say, a chroot.
<elderK>
Like jails in FreeBSD.
<elderK>
Or some kinds of QEMU virtualization.
<elderK>
Since I'm here: What's a good way to find out what the dependencies of some python library are?
<elderK>
Say, you know, I'm trying to build a package for some python program. Github doesn't mention all the deps.
<SiFuh>
Or vmd in OpenBSD?
<SiFuh>
elderK: trial an error
<SiFuh>
I build the system in a core only system and then add the deps as I go.
<elderK>
It must take a lot of time to package things?
<SiFuh>
Gentoo, Arch, Alpine and so on have will list dependencies but they usually use a lot of dependencies that most of us don't really need.
<elderK>
Aye. I generally try to find out the minimum set of dependencies that I want.
<SiFuh>
Like this, you can get ideas
<elderK>
Aye, but that means I need to "rip" from Archj
<elderK>
I'd prefer to be more self sufficient.
<SiFuh>
Yes, that is why I build from core only
<elderK>
I was hoping like, you know, there was some way for me to determine what libraries a python program needed without actually going through the source code of that program.
<elderK>
So, why a VM and not a chroot, Sifuh?
<SiFuh>
It will complain when you build it
<elderK>
Python things sometimes build but fail only at runtime :(
<elderK>
You know, they try to import some module that doesn't exist.
<SiFuh>
VM was already here
<elderK>
Fair enough :)
<SiFuh>
I also test what I build to see if they segfault
<SiFuh>
I have actually dumped entire ports because of the segfaulting and created new ports of a similar program to replace the segfaulting prick
<SiFuh>
I can't think of the latest port. But one particular port was Openshot was continually causing issues so I dumped it and now use Shotcut.
<elderK>
Nice :)
<ivandi>
elderK: No gotchas so far but a lot of rebuilds. started with packages pointed by revdep, then all python3-*, all p5-*, everything compat-32, everything wayland. After that i just rebuilt everything in my pkg folder that was older than the upgrade date. so reinstalling is not a bad idea. or bumping ports and rebuilding slowly to avoid a lot of broken stuff after upgrading from the iso.
<farkuhar>
elderK: your latest question about dependencies is focused on the python ecosystem, in which the upstream devs typically write a Requirements file (https://pip.pypa.io/en/latest/user_guide/#requirements-files ). Referring to such a file is arguably more self-sufficient than to "rip" from Arch.
<farkuhar>
if a project has been around long enough, though, the devs might forget to update their documentation when a dependency becomes stale. To illustrate: https://github.com/apple/swift-corelibs-libdispatch still mentions libbsd in the Linux section of its INSTALL.md (last updated 4 years ago), but the latest code compiles just fine without libbsd installed.
groovy2shoes has quit [Remote host closed the connection]
ty3r0x_ has joined #crux
ty3r0x__ has joined #crux
ty3r0x_ has quit [Ping timeout: 268 seconds]
elderK has quit [Quit: Connection closed for inactivity]
ivandi has quit [Quit: WeeChat 3.6]
ivandi has joined #crux
ppetrov^ has quit [Quit: Leaving]
<farkuhar>
Re: "ccache is pretty cool. It doesn't speed up the initial (first) build though." <- seems intuitive, but when ccache is configured to invoke distcc (by exporting the CCACHE_PREFIX variable), you can benefit from distcc indirectly (i.e. without prepending /usr/lib/distcc to your $PATH). This speedup happens despite the CMake warning that "Manually specified variable LLVM_CCACHE_BUILD was not used by the project."
<farkuhar>
but braewoods had a suggestion better suited to users with only one CRUX machine: define the CMake variable LLVM_TARGETS_TO_BUILD more narrowly (it defaults to 'all' otherwise). Our current llvm Pkgfile does not disable the non-native targets.
<stenur>
it adds in all sort of stuff that i guess 99% of CRUX users do not use; it was a tad different in the past
<stenur>
clang is unbelievable 945.9 MiB. gcc is 204.9 MiB. tcc is 1149.5 KiB.
<stenur>
clang is grazy.
<stenur>
llvm is 566.4 MiB.
<stenur>
somehow i guess our build is "broken" and clang includes llvm again. 1.5 GiB. Oh. My. God.
<stenur>
A nice sunday everybody nonetheless.
pvn has quit [Read error: Connection reset by peer]
<brian|lfs>
its still saturday here
ty3r0x__ has quit [Quit: Konversation terminated!]