<ukky>
Dependency on shared-mime-info has been removed from opt/gdk-pixbuf in 3.8. It is still required.
<farkuhar>
shared-mime-info shows up for me on the third level of `prt-get deptree gdk-pixbuf`. So it should be available for gdk-pixbuf after recursive dependency resolution.
<ukky>
Are you testing on 3.7?
<farkuhar>
`git status` says my opt repo is "up to date with 'origin/3.8'"
<farkuhar>
Hmm, but my xorg repo is "up to date with 'origin/3.7'" ... that's a recipe for breakage
<ukky>
No port in my 3.8 copy has dependency on shared-mime-info
<farkuhar>
Okay, I just synced my xorg repo to 3.8, and shared-mime-info still shows up on the third level of `prt-get deptree gdk-pixbuf`, as a dependency of gobject-introspection.
<ukky>
s/'gdk-pixbuf'/'gdk-pixbuf' for 3.7 branch
<ukky>
You are right, I missed that. My grep pattern is fscked up then
<ukky>
Just for some feedback, I have 88 failures to fix, from original 152 or something. Building llvm now. Many of 88 might simply need a rebuild.
<zorz>
ooooooooo
<zorz>
ukky: being busy eeh
<ukky>
A bit. Full-time job plus snow removal affects the build process.
<zorz>
its good
<ukky>
I think it would be good to have a list of ports required to build ISO. We cannot build it from a minimal chroot environment.
<zorz>
the time and effort you put in this, as i said to farkuhar, get xbps from xtraeme... or anothe package manager and build your own.
<ukky>
The complexity of Crux ISO building comes from simplicity of Crux Pkgfiles and simplicity of packaging tools.
<zorz>
truth
<zorz>
but somebody has to update pkgmk to build in isolated enviroment.
<zorz>
the only thing missing to crux, is this.
ppetrov^ has joined #crux-social
SiFuh_ has quit [Remote host closed the connection]
SiFuh has joined #crux-social
<farkuhar>
As SiFuh rediscovered with the rdate build failure, distro policy prevents maintainers from listing core ports in the "Depends on" line unless they're dynamically linked in. core/patch is merely a build-time dependency, hence rdate did not list it. I suggested using the ISO Makefile itself to inject extra knowledge of these build-time dependencies, since make has its own method for ordering targets.
<SiFuh>
farkuhar: On the bright side. My modification is only temporary as when you do eventually update rdate the Pkgfile would be replaced
<SiFuh>
I don't mind have no deps on core ports since they are suppose to rely soley on core ports. But when a dep is on opt or contrib then you really need to specify that as a dependency.
<SiFuh>
on/in
<SiFuh>
I should say specify a dependency as a 'make dependency'.
<SiFuh>
Would be nice to have 'make dependencies' that don't get installed
<SiFuh>
Because you could do the same with a custom packages.core
<farkuhar>
SiFuh: Hmm, I think you're onto something. Notice how the manually-curated list puts libbsd and libmd at the end, so they'll be built *after* all the other ports and won't get eagerly linked.
ppetrov^ has quit [Quit: Leaving]
<farkuhar>
httpup has more life in it than a CD-R that I burned eight years ago. Every time I try to mount that CD-R on Linux, some process eventually hangs when trying to read from the disc. But then I take it to a Windows PC, extract the data just fine, and a few months later I forget that it will cause I/O errors on Linux.
<SiFuh>
farkuhar: You can't dd_rescue the raw ISO from the CD-R?
<farkuhar>
SiFuh: Maybe I'll try that next time. But if all the needed data can be recovered on a Windows PC, I'll just stick the files onto a thumb drive and throw out the CD-R.
<SiFuh>
What if the Drive is the problem and not the CD-R?
<SiFuh>
farkuhar: You build the core ports based on your current system. Sometimes you need to install extra packages occasionally so those core ports can be built. It is recommended that your current system is updated first. Then those packages you built are installed into a fake root. So when you build inside the fake root those packages should already exist. Except the packages you needed to build for core
<SiFuh>
to begin with that you had to install on your system.
<SiFuh>
farkuhar: I will back up everything I have done, and start again. But slowly. And I will record step by step everything I do.
<farkuhar>
SiFuh: Regarding https://dpaste.com/4NKFH4AMN.txt , you do know that `prt-get quickdep` accepts multiple arguments, right? In one command you can obtain the list of install targets, sorted by dependencies.
<SiFuh>
No
<farkuhar>
It's probably better not to parse the output of ls, though. Just run `find -L /usr/src/crux/3.8-broken-glib-introspection/iso/ports/core -maxdepth 1 -type d -printf "%f\n" | xargs prt-get quickdep`
<SiFuh>
So pedantic
<farkuhar>
The -L flag is just in case you're using symlinks to populate the core repo, otherwise the -type d test might omit something.
<SiFuh>
Won't work.. name is used a lot in pkg files.
<SiFuh>
Pkgfiles
<farkuhar>
Yes, but name as defined by the Pkgfile is supposed to agree with the name of the directory, anyway, so why not just use the -type d test?
<SiFuh>
I ain't making a shell script. I am just typing in some commands. So who gives a flying fsck
<farkuhar>
Anyway, `prt-get quickdep` won't have any knowledge that musl{,-fts,-obstack} should appear early in the list (I assume you aren't manually adding musl to the "Depends on" line everywhere), so the output of the quickdep command will still need to be adjusted manually.
<SiFuh>
And why waste my time messing around with this mess --> "%f\n"
<SiFuh>
farkur hard to find glibc and replace it with musl at the same place
<SiFuh>
Huh?
<SiFuh>
Not hard*
<farkuhar>
The -printf "%f\n" makes it easier for piping to xargs; otherwise you have to strip away the leading directory components using an extra pipeline through sed, or the bash pattern trimming operator ${param##pattern}.
<farkuhar>
SiFuh powered on a second-hand laptop, and one day later it still hadn't booted. On his suggestion that maybe my drive was at fault for problems reading an 8-year-old CD-R, I tried mounting it with a different optical drive. Five minutes later, the mount command still hasn't completed.
<SiFuh>
2 dead drives
<farkuhar>
I suppose I could wait another 24 hours to see if the mount command ever finishes, but I think at this point it's a problem with the disc. Maybe I created it with a buggy version of mkisofs, or less-than-fully-compatible options.
<SiFuh>
Download a live CD like ParrotOS and go to that Windoze Machine and boot from it. Then see
<SiFuh>
You might have two buggy drives
<SiFuh>
Then you should know for sure
<farkuhar>
But the drives don't have problems reading any of my other CD-Rs. It's just that one CD-R.
<SiFuh>
You might have two buggy drives
<farkuhar>
It would be interesting to go through the ChangeLog of cdrtools (or cdrkit) to see if there was a known issue with mkisofs (genisoimage) 8 years ago. But I'm leaning towards the explanation that I forgot to pass a particular flag to the mkisofs command, and now the disc is only readable on Windows machines.
<SiFuh>
You might have two buggy drives
<farkuhar>
Two buggy drives that don't have any problem reading my other CD-Rs, some of which date from the same time period?
<SiFuh>
I installed crux 3.8 rc3 on to a hard drive then ports -u and then ran that.
<SiFuh>
So it isn't technically the ISO it is what is there in core
<SiFuh>
And I installed EVERYTHING even the multiple bootloaders
<SiFuh>
Would be nice to sort out what are makedepends and what are actual depends. To make the ISO smaller
<farkuhar>
SiFuh: I could use your help in #crux-devel, if you have anything to add to the libbsd discussion.
<SiFuh>
You can't always get what you want......
<SiFuh>
Haha
<farkuhar>
In this case I got a report about json-c, which I hadn't noticed before, thanks to my libbsd installation being hidden in /usr/opt.
<SiFuh>
farkuhar: ukky and I were discussing it for ages
<zorz>
json-c is bullshit
<SiFuh>
So is zorz-c ;-)
<SiFuh>
zorz: With that git link, I will try to build the MUSL toolchain under glibc
<zorz>
zorz-c is cool!
<zorz>
SiFuh: always busy experimenting :)
<zorz>
who was this guy, arachsys
<zorz>
something like that
<zorz>
libelf — freestanding libelf extracted from elfutils
<zorz>
This builds cleanly without autotools on both musl and glibc, using either clang or gcc. On musl systems it doesn’t need extra argp, fts or obstack libraries, just zlib for handling compressed ELF sections.
<SiFuh>
That's kind of cool. Able to build the complete set of packages.
<zorz>
SIFUH_VER = 20.25
<SiFuh>
zorz: No, I'd be version 6.7
<SiFuh>
And so would you
<SiFuh>
isl is a library for manipulating sets and relations of integer points bounded by linear constraints. Supported operations on sets include intersection, union, set difference, emptiness check, convex hull, (integer) affine hull, integer projection, computing the lexicographic minimum using parametric integer programming, coalescing and parametric vertex enumeration. It also includes an ILP solver based
<SiFuh>
on generalized basis reduction, transitive closures on maps (which may encode infinite graphs), dependence analysis and bounds on piecewise step-polynomials. For more information see the online user manual (html) or the complete manual (pdf). For an introduction to the underlying concepts, see Presburger Formulas and Polyhedral Compilation. The barvinok package contains an iscc calculator that exposes
<SiFuh>
some of the operations supported by isl.
<SiFuh>
Not sure CRUX or MUSL would need that
<SiFuh>
We could replace all the ports (non-standard) like binutils gcc musl libgmp libmpc libmpfr linisl and linux-headers with a port called musl-toolchain
<SiFuh>
TARGET = x86_64-linux-musl
<SiFuh>
Which is kind of non-standard since it installs directly to a folder called this
<zorz>
in SiFuh we Trust! Free to do as you wish!
<zorz>
:pP
<SiFuh>
I wonder what that actually means on the USD