<mnkydeth>
So, most of my projects have gone by the wayside. However, I'm to the point where I am satisfied with the default Crux install. I've been using Crux for a long time and I have made some of my own packages in the past but never shared them. I've read the wiki and man pages a couple times. But I'm sure I have missed stuff. Is there any stuff that helps with making Pkgfile's? Like a default layout? Whats the
<mnkydeth>
best way to test a build and show the files that have been created so we can see if there is any cruft that we need to remove? I'd like to start exploring this as I have a need to start making a few of my own packages again. But if I feel confident I may want to share my httpup.
<mnkydeth>
I mostly plan on using a live environment that is my current working install. How do you test without messing stuff up?
<farkuhar>
mnkydeth: prtverify is good at alerting you to "junk files" in the footprint, or other oversights in your port. You probably also want to run findredundantdeps on your port, and finddeps after the package is installed.
<farkuhar>
as for making Pkgfiles, it helps to have at least one good reference example for each of the major build systems (autotools, meson, cmake). When developing a port for an upstream project that gives sparse documentation, you can refer to one of those familiar examples to reacquaint yourself with all the steps in a cmake build, or a meson/ninja build, or whatever the project is using.
<mnkydeth>
I'm familiar with the ./configure style... Anything else... not really. I'm looking at Jellyfin right now as I would like to replace Plex. I also have a driver I would like to automate the install on. Whenever I update my kernel. Not sure how that will go but.... I want to replace Ubuntu on my server because of this Pro thing they are doign now.
<mnkydeth>
I used to make Pkgfiles of eterm and e16 for myself. But nothing beyond that. And I don't know if I ever did them correctly. Im pretty solid in sway and wayland now. So I don't plan on going back.
<farkuhar>
even if the upstream project gives good documentation, there are some CRUX conventions that the upstream compilation instructions often omit. Here for example was one reaction to such omissions in the deep42thought repo: https://lists.crux.nu/pipermail/crux-contrib/2021-March/000684.html
<farkuhar>
as for testing your ports to ensure they aren't picking up too much cruft from the live environment that is your current working install ... some maintainers prefer lxc containers for testing their ports, others use docker. You could also run pkg-clean on a secondary CRUX install (e.g. external hard drive), and see if your port builds there using the --install-root option of prt-get.
<mnkydeth>
hmm, yeah, I was thinking I was going to need a kind of base install that could be clean for every package.
<farkuhar>
Here's how jaeger outlined the setup of a clean docker container: http://ix.io/4nan
<mnkydeth>
Oh wow, I'm not incredibly familiar with docker. But I have used it for lancache so I know a little. I at least understand what he's doing there. I think...
<mnkydeth>
Extracting the iso into docker, then essentially booting it.
<ivandi>
i build a dynamically linked pkgadd and use fakeroot, but if you run it as root it is not necessary
<jaeger>
Another option for clean builds is a VM snapshot you can repeatedly reset... it gets you similar functionality to that of lxc or docker, just depends on your comfort level
ppetrov^ has joined #crux
<cruxbot>
[xorg.git/3.7]: xkeyboard-config: update to 2.38
<cruxbot>
[xorg.git/3.7]: xorg-libx11: update to 1.8.4
<cruxbot>
[opt.git/3.7]: dnsmasq: update to 2.89
ardo has quit [Ping timeout: 252 seconds]
ardo has joined #crux
ardo has quit [Ping timeout: 252 seconds]
ardo has joined #crux
ppetrov^ has quit [Quit: Leaving]
ardo has quit [Read error: Connection reset by peer]
ardo has joined #crux
SiFuh has quit [Remote host closed the connection]