<fire_varan>
wanted to upload rdsosreport.txt too, but when I mounted image to another machine it wasn't there unfortunately
<fire_varan>
Steps to reproduce - create a default vmware machine for linux and make sure that SCSI (not IDE, SATA or NVMe) is chosen for the hard disk
<fire_varan>
and then compile a kernel with default .config
<fire_varan>
run dracut as well of course
<fire_varan>
by the way, tested with SATA too, and this time everything worked just fine
fire_varan has left #crux [#crux]
pitillo has quit [Ping timeout: 244 seconds]
pitillo has joined #crux
pitillo has quit [Changing host]
pitillo has joined #crux
brian|lfs has quit [Remote host closed the connection]
lavaball has quit [Remote host closed the connection]
brian|lfs has joined #crux
thingsis has joined #crux
maledictium has quit [Ping timeout: 245 seconds]
farkuhar has joined #crux
lavaball has joined #crux
pitillo has quit [Ping timeout: 252 seconds]
<jaeger>
oldradio: great :)
ppetrov^ has joined #crux
<ppetrov^>
farkuhar, findredundantdeps -s does not seem to work properly on 3.8
<ppetrov^>
it returns pretty much everything that was on the Depends on line, separated by a comma
<jaeger>
fire_varan: which SCSI controller does the default vmware machine emulate specifically?
thingsis has quit [Ping timeout: 244 seconds]
<farkuhar>
ppetrov^: I can't reproduce the findredundantdeps problem here. Are you trying it on a port that's not in the active collections?
<ppetrov^>
hmm... it should be in my active collection, will check what I messed up
<farkuhar>
Internally, it relies on `prt-get deptree`. So if prt-get doesn't know about the port, the dependency tree won't be generated accurately.
lavaball has quit [Remote host closed the connection]
<ppetrov^>
farkuhar, does findredundantdeps return the right order separated by commas?
<ppetrov^>
it does now, but not on crux 3.7
<farkuhar>
ppetrov^: I'm confused what you mean by "right order". There's no requirement that the dependencies be listed in any particular order, that's a job for prt-get to figure out.
<ppetrov^>
no, i mean, removing redundant deps
braewoods has quit [Remote host closed the connection]
braewoods has joined #crux
braewoods has quit [Remote host closed the connection]
braewoods has joined #crux
<ppetrov^>
farkuhar, I tried findredundantdeps from 3.7, and I can confirm it works fine on 3.8, but the new one does not
<farkuhar>
ppetrov^: Thanks for the report. I'll look into it.
<farkuhar>
ppetrov^: Can you provide the names of the ports you're passing as argument to findredundantdeps? (just so we're on the same page when it comes to testing)
<ppetrov^>
aiksaurus
<ppetrov^>
for example
<ppetrov^>
i still have not updated for 3.8 opublicly
<ppetrov^>
publicly
<ppetrov^>
but i first put all deps outside core, as reported by finddeps
<ppetrov^>
then i check with findredundant deps
<ppetrov^>
i do this every now and then for my ports
<farkuhar>
ppetrov^: Can you share via pastebin the output of `prt-get deptree aiksaurus`, then?
<ppetrov^>
no, i am not on 3.8 here
braewoods_ has joined #crux
braewoods has quit [Remote host closed the connection]
<mpark>
I was trying out crux, and when I tried to install some stuff with prt-get, I got a bunch of errors - found out that I need to use depinst rather than install if I want to resolve dependencies... needless to say, it's working now
<SiFuh_>
mpark: And don't forget 'revdep' it will be very useful when doing prt-get updates of ports.
<mpark>
yeah, I saw that too, I actually joined the IRC channel to figure out what I messed up and found the answer before I had a chance to ask
<SiFuh_>
I think revdep is one of CRUX's greatest tools
<mpark>
( I always doublecheck my work before asking, because I hate it when people ask me stuff without looking it up first )
<mpark>
Anyway, I'm going to play with it some more in a VM for a bit to see if it fits my needs.
<cruxbridge>
<tim> mpark: consider setting runscripts to yes in /etc/prt-get.conf, as well as PKGMK_IGNORE_NEW="yes" in /etc/pkgmk.conf
<cruxbridge>
<tim> you can check out the scripts in the ports directories, and the latter setting will make new footprint lines not error a build (they are pretty much to be expected nowadays)
<mpark>
I'll consider it tim. Right now I'm mainly interested in it's BSD-style init system and it's package management system. I may want to extend it some as part of a little project I have going on the side to help it scale for mass deployment - compiling everything can be a little time consuming. I'm avoiding systemd, not because I have a problem with it or anything, but rather because it doesn't play nice with a lot of embedded hardware and non glibc installs.
<mpark>
I'm trying to come up with a unified solution where everything operates the same across devices provided the hardware supports the activity.
<cruxbridge>
<tim> Sounds good, have fun
<mpark>
yeah, it's a hobby, so if I fail, it doesn't really matter, but I hope to learn a lot in the process :D Thanks tim
<SiFuh_>
Nah, that init system needs serious attention. It is a mess now.
<SiFuh_>
Unfortunately my comment fell on deaf ears that rc needs to be written correctly.
<SiFuh_>
And I think that it is the most shameful and embarassing code manipulation that should never have faced the public.
<cruxbridge>
<tim> Sifuh: Open a ticket, better yet, a PR can help to get attention. Otherwise, the issue is not by any means critical. While I agree it needs another look, it's not by far as bad as you make it sound.
<SiFuh_>
Why? You are all here.
<cruxbridge>
<tim> So?
<SiFuh_>
Just fix it and write it better. Don't send out shit quality code and expect people to bend over to some gitea ticket.
<cruxbridge>
<tim> See how far your way of expressing yourself gets you?
<SiFuh_>
And your anomisity towards users. Got it! I was quite polite when I told you it needed to be looked at.
<mpark>
I started out on FreeBSD 4.2, so if I see anything that can be fixed while going through it, I'll definitely make some corrections and test them, and then submit a ticket.... that said, there's bound to be some differences since you're all using bash as a base, and bash isn't exactly POSIX
<SiFuh_>
It should be priority number 1 because it is the foundations of a bootable system
<SiFuh_>
Your arrogance tim is insane.
<SiFuh_>
mpark: Didn't like FreeBSD much myself but was a heavy user for a time. I just found it to be messy.
<cruxbridge>
<tim> You are free to have your opinion, no matter how far from the truth it is.
<mpark>
I love it, if you mess anything up, it's super simple to just start over, delete /usr/local and you've reset to a base install and start over.
<SiFuh_>
I don't care tim. It is a serious issue and you snobbed it off because I am the one who mentioned it. Great going.
<cruxbridge>
<tim> Sifuh, please be real: everyone snobbed it off.
<SiFuh_>
mpark: I ended up with OpenBSD myself. Cleaner, neater and easy to repair
<SiFuh_>
tim No they didn't.
<mpark>
anyway, going to run some errands now. this feels like it's going to get a bit tense and I'm not prepared to involve myself in further drama
<cruxbridge>
<tim> mpark: take care
<SiFuh_>
Not my fault you can't write clean code.
<cruxbridge>
<tim> No, thats true. It's your fault that all you do is jab about it
brian|lfs has quit [Remote host closed the connection]
<SiFuh_>
tim you broke it. You fix it. Many users have noticed it.
<mpark>
my only suggestion is that if you don't like the quality of some code, it's an open source project, rewrite it yourself and submit your changes, if you don't posess that ability, how would you even know it's bad
<cruxbridge>
<tim> mpark: word, thanks :)
<SiFuh_>
tim Isn't that what a user does? Find what is broken and tells you where to fix it?
<cruxbridge>
<tim> sifuh: I am not entering a discussion with you either. Please stay civil, write a patch and submit it, you should know how.
<cruxbridge>
<tim> with that said, afk
<SiFuh_>
tim that is unfair. You broke it. I told you that. Shouldn't you look into it and learn and fix it yourself? Then if you refuse, I then provide a patch?
lavaball has joined #crux
lavaball has quit [Remote host closed the connection]
lavaball has joined #crux
<SiFuh_>
I just had a go at beerman because he fucked up the crux rc init script. I mentioned it needed to be fixed and it was ignored. Then today a new guy was excited about the BSD init system and beerman was just like so blasé about it. So I had to vent steam.
lavaball has quit [Remote host closed the connection]
<SiFuh_>
jue if I do a patch, do you mind reviewing it for me, to make sure it is clean and clear and up to specks?
<SiFuh_>
My plan is to probably appoach it in May. Because of time constraints.
<SiFuh_>
jaeger: ^ also
lavaball has joined #crux
<SiFuh_>
I intend to keep his colour options. And on a side note. Some CRUX users were saying LVM is broken in the rc script as well? I am not entirely sure about that.
SiFuh_ has quit [Remote host closed the connection]
<mpark>
hahah, building plasma 6, and libqrencode Pkgfile is wrong. I rewrote it, and had a bunch of signature issues... put it in my own custom repo ( so easy ) and deleted the .signature file, it now builds after my adjustments. But now I'm going through the pipeline of bad package builds that are pulling from no-longer-existent sources, bad-sources, or just skipping build steps.
<mpark>
this is gonna take me a while
<mpark>
looks like the problem with libcanberra is the .footprint file doesn't match the output.
<mpark>
I'm going to check the output to make sure it's good and look into creating a new .footprint.
<mpark>
oh, good, it generates it automagically
<mpark>
I'm going to have to look into how crux handles repo signing and how it prioritizes repos when duplicate packages exist. For now, I've just moving the problematic packages to a separate folder ( which will only work until my next ports -u ) and stripping the .signature file and making my changes.
<mpark>
it generates a .md5sums file automatically when I do that, but obviously that's not an ideal solution longterm
<farkuhar>
mpark: Any suggestions that come to mind while you work around the signatures/md5sums, please share them and we can update https://crux.nu/Wiki/SignedPorts accordingly.
<mpark>
Oh yeah, for sure, I just don't have time to document it right this moment, I'll probably get to it tomorrow - for now I'm just putting them into their own folder for later write-ups as I'm multi-tasking with house chores.
<farkuhar>
"how crux prioritizes repos when duplicate packages exist"? That depends on what tool you're using. prt-get is controlled by /etc/prt-get.conf (dup in the earlier-appearing repo gets priority), but you can spin your own solution, or manually run pkgmk/pkgadd in the dir of the desired dup.
<mpark>
That's what I figured, but I didn't want to assume. In any case, once I'm done finding all the problems in the build, I'll do a ports -u to pull in the other repos fresh and run a diff to help me document the changes.
braewoods__ has joined #crux
braewoods_ has quit [Read error: Connection reset by peer]
<farkuhar>
mpark: I prefer to switch the active repos from the rsync driver to the git driver (after installing opt/git). That way after making any changes locally, you can run `git diff` to obtain nicely-formatted patches.
braewoods__ has quit [Remote host closed the connection]
<mpark>
well, yeah, I guess I could make the local repository a git repo - that would make things easier - I'm ashamed I didnt' think of it myself
braewoods__ has joined #crux
<mpark>
most of the issues I'm having is with .footprint mismatches.
<farkuhar>
mpark: generally it's safe to ignore any NEW files. It's the MISSING files that should trigger greater alarm.
<mpark>
anyway, I've come too far now to do it over, so hey
<mpark>
well, yeah
<mpark>
I'm still going over them to make sure they look correct
<mpark>
and checking the sources are official
<mpark>
plus, this is all being tested in a VM, so my local machine is safe :D
<mpark>
All the problems will be sorted out in the diff :D
<mpark>
anyway, farkuhar thanks for the advice - I'm sure it will be very useful to my workflow when troubleshooting these issues
<farkuhar>
mpark: you're welcome. Good luck getting used to the quirks of CRUX packaging.
<mpark>
once I get a hang for this system, if it's to my liking, I plan on doing some major customization, so I may end up running my own repo anyway just to ensure certain features are compiled in.
<mpark>
I'm retired, and have all the time in the world to play around
<mpark>
so far, out of the packages I've installed, only 6 have been problematic, that's a relatively low number.
<mpark>
of those 6, ony 2 would I run with any regularity on most of my systems.
<mpark>
and of those 6, only qrencode just plain incorrect.
<mpark>
the others have just been .footprint mismatches
<mpark>
but I'm compiling plasma 6, so it's not done yet - there may be more.
<mpark>
I'm testing a desktop setup
<mpark>
I'm just using defaults for the install for now, because I like to make sure something can work before I tinker with it.
<cruxbot>
[opt/3.8]: prt-utils: updated to fix findredundantdeps
<mpark>
farkuhar: the quirks aren't that bad, they're not too different from pacman packages - which is unsurprising as arch started out as a fork of crux from my understanding.
<mpark>
or even APK's from alpine are pretty similar, and I've dealt with those, so I don't hink I'll have too many issues.
lavaball has quit [Remote host closed the connection]