<fishe>
ld is in /usr/bin which is in PATH so i'm not sure what the issue is
SiFuh has quit [Ping timeout: 244 seconds]
SiFuh has joined #crux
SiFuh has quit [Ping timeout: 252 seconds]
SiFuh has joined #crux
SiFuh_ has joined #crux
SiFuh has quit [Ping timeout: 264 seconds]
<jaeger>
odd
SiFuh_ has quit [Ping timeout: 265 seconds]
SiFuh has joined #crux
_moth_ has joined #crux
fishe has quit [Quit: Connection closed for inactivity]
_moth_ has quit [Remote host closed the connection]
_moth_ has joined #crux
_moth_ has quit [Quit: _moth_]
ocb has quit [Ping timeout: 258 seconds]
ocb has joined #crux
ppetrov^ has joined #crux
pvn has joined #crux
groovy2shoes has quit [Remote host closed the connection]
guido_rokepo has joined #crux
ocb has quit [Remote host closed the connection]
ocb has joined #crux
groovy2shoes has joined #crux
mkf has joined #crux
<mkf>
hi all. i can see cmake and ninja are in core repo of crux now, does it mean they are included in default install?
<mkf>
if yes, is it possible to remove them?
<SiFuh>
If they are in core then they are in the default install
<SiFuh>
If you wish to remove them, then you may have to rebuild all of core without them
<SiFuh>
cmake and ninja were included as far as I know because more and more ports were built with them
<mkf>
so it goes like "base builds base" like in OpenBSD?
<SiFuh>
Basically
<mkf>
neat.
<mkf>
another question, is there support for binary packages in system or via a 3rd party project?
<SiFuh>
Limited
<mkf>
please explain.
<SiFuh>
People install different things, and the packages they build may pick up other dependencies that the maintainer of the port hadn't included, or listed under 'nice to have' or 'optional'. So a binary would need to be built only on a core only system that pulls in all the dependencies that it needs.
<SiFuh>
So although there are some binary packages laying around they are considered non-standard and not really recommended.
<mkf>
i see. thank you.
<SiFuh>
Some of the larger ports have binary builds. But I heard that rust-bin may end up being dropped. But firefox-bin for example is still around
<mkf>
/4
<SiFuh>
/3
Guest12 has joined #crux
Guest12 has quit [Client Quit]
Romster has joined #crux
ahmadraniri1994[ has joined #crux
ahmadraniri[m] has joined #crux
<farkuhar>
rust-bin has already been dropped, but there's talk about reviving it (not a CRUX-hosted build, but the upstream build fetched by rustup.sh)
<SiFuh>
Heh
<farkuhar>
mkf: the opt/pkg-get port lets you install binary packages, but there's no centralized server that shares *pkg.tar.gz files for every port in the repos. You have to set up your own network server and build each port with the desired soft dependencies installed. ppetrov^ has lots of experience in this area.
<ppetrov^>
and about missing dependencies, i (with the help of farkuhar here) prepared a few small scripts: https://github.com/slackalaxy/depsck
<ppetrov^>
pkg-get will use deps info form the ports, however packages were built probably against other things. so i ended up with missing libraries. To quickly check what package is needed, i used revlibpkg
<ppetrov^>
these are all for CRUX 3.6
<cruxbot>
[opt.git/3.7]: gvim: update to 9.0.0621
<cruxbot>
[opt.git/3.7]: evilwm: update to 1.4.0
<cruxbot>
[opt.git/3.7]: dbus: update to 1.14.2
<cruxbot>
[core.git/3.7]: vim: update to 9.0.0621
<cruxbot>
[core.git/3.7]: libuv: update to 1.44.2
<cruxbot>
[core.git/3.7]: libcap: update to 2.66
<cruxbot>
[core.git/3.7]: bash: update to 5.2
<cruxbot>
[core.git/3.7]: readline: update to 8.2
<cruxbot>
[core.git/3.7]: tzdata: update to 2022d
SiFuh has quit [Ping timeout: 264 seconds]
SiFuh has joined #crux
<mkf>
thanks farkuhar, ppetrov^.
belgacem1958 has joined #crux
belgacem1958 has quit [Remote host closed the connection]
<jaeger>
I'm also experiencing the dvdread build error, haven't found a solution to it yet
<jaeger>
Though yours looks a bit different than mine, seems like it failed on both dvdread and ffmpeg, I only get the dvdread failure
<SiFuh>
Looks like dav1d is missing
<jaeger>
that guy... sheesh
<SiFuh>
Or exists and is screwing with his build ;-)
<jaeger>
can't trust him
<SiFuh>
Agreed
<jaeger>
I'm going to try building kodi in both 3.6 and 3.7 containers, see what differences I can find
<SiFuh>
Ooo new episode of Archer. BBL
<jaeger>
There's a kodi package built on 3.7 available at https://crux.ninja/tmp/ if you want it
<jaeger>
No idea how I was able to get it to build before but it's failing now, heh
<SiFuh>
Hopes, dreams and a bit of fairy dust ;-)
<jaeger>
sometimes it's like that
elderK has joined #crux
<elderK>
Moin all!
<SiFuh>
Yep
<elderK>
Lately I've been considering moving to another distribution: Not so much because Crux is bad, as I love Crux and have been using it since 2012 but rather because time is increasingly scarce and the convenience of a larger package repository (say Arch or Debian) is appealing.
<elderK>
I was wondering why you guys prefer Crux.
<elderK>
For me, it was the simplicity of the system and also how easy it is to make your own pacakges.
<elderK>
At least, the Pkgfile stuff is nice and simple compared to other stuff like RPM
<jaeger>
I still like the simplicity and enjoy tinkering, learning, etc... but if you don't have time, you don't have time
<SiFuh>
To be frank, all other distros are just shit. Too much crap, junk, bloat, and stupid software that just gets in the way
<SiFuh>
CRUX is also the closest Linux distro to a BSD I can find.
<SiFuh>
elderK: have you looked at Void Linux?
<elderK>
I haven't seen Void, no.
<brian|lfs>
odd I have dav1d but will rebuild him
<elderK>
I like the simplicity of Crux, a lot. It's why I've used it for so long.
<elderK>
I like how it doesn't cram stuff in that I don't need.
<SiFuh>
brian|lfs: The existence of dav1d might be the cause
<elderK>
But, it does take some time to create packages and it's not always easy to find out what dependencies a package actually has.
<elderK>
I could do the pkgbuild stuff on Docker or a clean chroot each time, but that takes more time.
<brian|lfs>
ok I can nuke dav1d
<brian|lfs>
since I never got firefox to compile
<SiFuh>
elderK: Void is rather simple as well. It has both binary and source. You can live off binary completely though
<elderK>
The only real reason I'd consider moving to say, Debian, is that the majority of what I want is in the upstream package repository. The moment something I want isn't, it starts to suck more.
<elderK>
I need a better way to determine what stuff a thing needs, rather than manually reading through CMakeLists or configure and stuff.
<brian|lfs>
kodi still faild
<SiFuh>
brian|lfs: did you revdep after deleting dav1d?
<SiFuh>
elderK: When i moved to Kyrgyzstan I installed Debian so I wouldn't have much to worry about. Everything worked, but it wasn't for me. When I moved back to South East Asia I went straight back to CRUX
<elderK>
What did you dislike about Debian?
<elderK>
I usually stay away from big name distributions but I do use Debian for work and it's not so bad.
<SiFuh>
Bloatware and uneeded crap like systemd
<elderK>
What bloatware springs to mind?
<SiFuh>
None, but I don't see the point of installing 200 deb pkgs to get 1 program
<elderK>
What was the program in question?
<SiFuh>
Most
<brian|lfs>
compiled kodi package works fine
<brian|lfs>
the one that jaeger posted
<SiFuh>
As I said nothing springs to mind because it was in 2015 and I moved on
<elderK>
Fair enough :) Thank you for answering my questions.
<brian|lfs>
why do some people hate systemd
<SiFuh>
Slackware was good, but similar issues
<elderK>
It's not an easy decision to change distribution.
<brian|lfs>
sure it is lol
<elderK>
I used Slack before Crux and it was okay but the lack of real package management sucked hard.
<brian|lfs>
I might pound my head at sourcemage again for shits lol
<SiFuh>
brian|lfs: same reason I don't like 12 computers in my car governing everything when a car from the 80's works fine.
<brian|lfs>
lol
<SiFuh>
brian|lfs: Not joking. My car had sensors everywhere to detect faults. Unfortunately the sensors go first and the computer sees no fault. 3K damage because i cooked the heads. ECT sensor failed and the computers in the car believed the car was fine.
<jaeger>
Here's a diff between the successful and failed dvdnav parts of the kodi build if anyone's interested: http://ix.io/4bPS
<SiFuh>
+configure:14322: error: Package requirements (dvdread >= 5.0.3) were not met:
<SiFuh>
jaeger: What is this 'virtual:world'? A python thing?
<SiFuh>
brian|lfs: After that, I sold the car and only own motorcycles since
<jaeger>
no idea
<elderK>
How do you guys go about packaging things? How do you determine what dependencies some program needs when it is not easily documented?
<elderK>
Do you build in docker? In a CRUX chroot?
<elderK>
Also, how do you deal with the situation when ports change names or require new deps?
<elderK>
For new deps, I often just run a little script that checks if there are any unmet deps before I update.
<jaeger>
I generally build first on a live system if I already have the previous version of whatever package it is installed... then if it all works as expected I build it in a clean container
<jaeger>
If it's a new port from scratch I'll start in a container and find deps either in the documentation or as I build
<elderK>
What kind of container?
<jaeger>
A barebones crux container. I keep a couple of variants around, one with core and a few useful non-core things like fakeroot and prt-utils, and one with core and xorg
<SiFuh>
^ Similar to jaeger. I build on my full system, then build in a VM using only core ports installed. Whatever it requires to build I add and what ever exists in ports it pulls and I add.
<elderK>
A chroot or a docker container? Or something else?
<jaeger>
docker in my case
<elderK>
Is there an official Crux docker?
<elderK>
Does it not take serious time to like, rebuild all the necessary deps?
<jaeger>
None of which I'm aware, I just make my own
<jaeger>
Depends on what port it is.. if there are a lot of deps, sure
<elderK>
How hard is it to learn docker?
<elderK>
I've not used it but it seems useful.
<SiFuh>
elderK: I have never figured it out
groovy2shoes has quit [Remote host closed the connection]
<jaeger>
Not hard in my opinion but I use it a lot for both personal and work stuff
<jaeger>
Another option would be a VM or lxc containers if you're more comfortable with those
<elderK>
I'll have to look into it I guess.
<elderK>
I have no idea what it would take to create a docker image :)
<elderK>
It might be worth learning though :)
<SiFuh>
I stick to VM because I couldn't get my head around dockers
<jaeger>
In the past I sometimes used a VM with a clean install snapshot to build something, then reverted to the snapshot to clean it up
<elderK>
Virtualbox or Qemu?
<SiFuh>
VirtualBox
<jaeger>
As for creating an image, it's very simple with a system like crux
<SiFuh>
I hear a lot of good about docker. So if you can learn, I would suggest to do it.
<jaeger>
create a target directory, install packages from the ISO into it, tar it up, 'docker import' the tarball
<jaeger>
That gets you a basic image, then you can customize it however you like. For me that means adding fakeroot and setting up a build user
<jaeger>
Then, periodically you start a container with that image, run a sysup, and commit the changes back to the image
<jaeger>
I'm currently using a 3.6 and a 3.7 container to test these kodi builds
<jaeger>
speaking of which, interesting data point: the 3.7 one succeeds if I replace pkgconf with pkg-config
<jaeger>
tried that for science (tm) due to the pkg-config errors in the build
<SiFuh>
Han talked me into learning emacs a while back and I use it a lot now. I still can't get my head around docker
<elderK>
Vi user here :)
<SiFuh>
Most people are including me
<jaeger>
I poke at other editors every now and then but still using vi/vim after 26 years
<SiFuh>
It is easier to type 'vi' than 'emacs'. 3 letter difference and habit ;-)
<jaeger>
I guess you could always alias ait if you wanted to, heh
<jaeger>
s/ait/it/
<SiFuh>
Yeah alias it to vi
<SiFuh>
Hahaha but to be honest I can do some stuff faster in vi than emacs, and other things faster in emacs than vi. So I use them for certain things
<SiFuh>
For example. If I want to do a mass rename of files. I will use emacs. If I want to write a quick shell script I will use vi.
<jaeger>
depending on how complex your rename task is, the 'rename' program is handy sometimes
<farkuhar>
elderK: if an upstream README or INSTALL is so poor in its documentation of dependencies that you'd consider learning docker to discover them, then my first thought is to try finding an alternative to that software. Second thought: if it does appear in the Arch repos, start from the dependencies listed in its Arch PKGBUILD (which after all was modeled on CRUX Pkgfile) and translate them to CRUX ports.
<farkuhar>
That's how ppetrov^ made his rstudio CRUX port, btw. You get the convenience of a larger package repository, and you don't have to give up the simplicity of CRUX.
<elderK>
farkuhar: Aye, that's what I tend to do when I create a new port: See if it's in Arch and if so, tweak the pkgfile as needed.
<elderK>
But that feels lazy, you know?
<cruxbot>
[contrib.git/3.6]: inkscape: fix build with new poppler
tilman has quit [Ping timeout: 260 seconds]
tilman has joined #crux
stenur has quit [Remote host closed the connection]