<mpark>
qt6 didn't come up. I'll try installing it
<mpark>
and see if it fixes the issue
<ukky>
it was included in qt-6.8.1, but missing in qt-6.9.0
<mpark>
yeah, that would be the problem
<mpark>
in any case, in it's current state with the current pkg builds, plasma-6 may be unbuildable. But I'm going to try a few things first before I determine that.
<ukky>
good luck. sorry I couldn't help.
<mpark>
ukky: don't worry, you got me on the right path
<mpark>
if it's unbuildable, I'll just make my own build instructions by getting them from BLFS or something to see if I can't make it work.
<mpark>
if it comes to that, I'm starting over though, and doing this all in a git repo
<ukky>
I suspect qt-6.9.0 renamed qgenericunixservices_p.h into qdesktopunixservices_p.h
<mpark>
because, damn
<mpark>
hmmm
<ukky>
there is no Qt installed on my system, so cannot confirm
<mpark>
I'm also going to make it so my repo loads before the crux repos... because I don't want the crux versions of my modifications.
<mpark>
I want my mods to load first
<mpark>
I'll make a kernel build package later, but for now, the linux folder is just a copy of my kernel config.
<mpark>
I only changed one flag from stock
<mpark>
sometimes I'm a dummy... I forgot to do modules_install when I rebuilt my guest machine.... and then wondered why it had no network. That tells me I need to take a break.
<mpark>
I'm really starting to dislike how crux handles packaging.
<mpark>
I like the concept, but it seems to fail in some critical areas.
<mpark>
for instance, if I update xorg, it doesn't automatically update the associated drivers. I mean, I get why it doesn't, but it's frustrating.
<mpark>
it should have ```prt-get update $(prt-get dependent xorg-server)``` as part of the build script probably.
<mpark>
I'm not sure that would work, but yeah.
<mpark>
actually, as I think, it wouldn't work
<mpark>
because the new X wouldn't be installed yet.
<mpark>
we need post install scripts
serpente has left #crux-social [ERC 5.6 (IRC client for GNU Emacs 29.4)]
ppetrov^ has joined #crux-social
SiFuh_ has quit [Remote host closed the connection]
SiFuh_ has joined #crux-social
ppetrov^ has quit [Quit: Leaving]
<farkuhar>
Part 3 of the CRUX Mantra might explain the packaging decisions that mpark found so frustrating. Utilities like prt-get are "meant to be tools, not assistants; they should do the work for you, not the thinking." https://crux.nu/Main/Mantra
<farkuhar>
That being said, Part 1 of the mantra ("simple to understand and extend") makes it possible for the target audience (experienced users) to write wrappers around these low-level tools, which would automate repetitive tasks like rebuilding affected ports.
<farkuhar>
beerman responded to therealfun's FS#1410 (why do people leave CRUX?) by suggesting that "new users are not being helped properly. Instead of getting to learn our system tools, they are told to write wrapper scripts, patch prt-get themselves or whatever."
<farkuhar>
Having forked the prt-get repo to add some useful features like a mixed install/update mode and support for optional dependencies, I could be accused of doing exactly what beerman says is "not helping new users properly."
ppetrov^ has joined #crux-social
<farkuhar>
I doubt that beerman himself is restricting his toolkit to the low-level commands, executed by hand; he probably has some custom scripts and cronjobs to automate the repetitive work of port maintenance. If he still believes in his FS#1410 reply, it must come with the caveat that wrapper scripts are allowed if the invoking user actually wrote them.
<farkuhar>
ppetrov^: You left and then came back.
<ppetrov^>
there and back again
<farkuhar>
dlcusa: The NY Times investigation into the DCA helicopter/airplane crash was published in a story dated last Sunday, but the print copy of the newspaper doesn't appear to include it. Maybe it was only available to digital subscribers.
<farkuhar>
I don't suppose it affects their chances of earning a Pulitzer prize for reporting, given that the judges for such awards probably aren't blocked by a paywall. But it seems odd that they would decide to keep the story out of the print version.
ppetrov^ has quit [Quit: Leaving]
ppetrov^ has joined #crux-social
<ppetrov^>
findredundantdeps -s works fine all of a sudden
<ppetrov^>
i am going nuts...
<SiFuh_>
Or you are becoming redundant
<farkuhar>
erik_ in #crux doesn't need his help, then, if he suddenly became redundant.
<farkuhar>
I've never played around much with VMs myself. I'm guessing each of them has a different way of selecting whether to boot using UEFI or BIOS. It would be interesting to know how erik_ was booting the 3.8 ISO on his VM.
<farkuhar>
The other #crux question that hasn't received a timely follow-up is bleb's: why isn't there a more convenient way to navigate the mailing list archive nowadays? Ripping out the old interface in favor of Hyperkitty seems to have impacted usability.
<ppetrov^>
farkuhar, I wonder why he would use efi in a VM
ppetrov^ has quit [Quit: Leaving]
serpente has joined #crux-social
serpente has quit [Remote host closed the connection]
<zorz>
farkuhar: new /etc/rc is changed... much better
<SiFuh_>
I think I am done with CRUX. stick to OpenBSD only
<zorz>
why stenur disappered from crux ports?
<zorz>
i think stenur is down with crux
<zorz>
done*
<farkuhar>
zorz: "they changed a few things" <- Who is "they"? The script you pasted is the same abomination that SiFuh_ was complaining about.
<SiFuh_>
farkuhar: Hehe, I think zorz is his own little world.
<farkuhar>
Maybe zorz pasted the old script by accident. But if there is a new /etc/rc, it hasn't appeared in the crux.nu git repo yet.
<SiFuh_>
farkuhar: It is the second time zorz has said the rc script has been changed when it has not.
<farkuhar>
SiFuh_: In zorz's world, stenur might be done with crux, but from what I can tell, stenur continues to use it quite regularly. Regularly enough to open Gitea issues like core #17 about the python3 test framework.
<farkuhar>
At least it made sense to open #17 in the ports/core repo. But when stenur opens an issue about merging my changes to prt-get, that request is more appropriate for the tools/prt-get repo, not the ports/core repo.
<farkuhar>
tools/pkgutils deserves to have a pull request opened for the libarchive fixes that braewoods wrote six years ago. By defining a new struct to hold the file information, he avoids making duplicate passes through the archive when generating the footprint.
<farkuhar>
It would appear that their preferred mode of reviewing patches is now through Gitea, not the mailing list or dpaste+IRC. So if we want to raise awareness about old patches that have lingered in mailing list archives without any action, we should use the newfangled Gitea features.
zorz_ has joined #crux-social
<zorz>
farkuhar: is not the same.... they change the lvm
<zorz>
maybe my fisrt script was from rc4,,, now is official iso
<zorz>
btw farkuhar bravo for adding brightnessctl
<SiFuh_>
zorz: if lvm2 is fine then you should join #crux and inform jaeger that lvm is fine.
<SiFuh_>
Then that would mean we'd only have to get a rc fix for the colour scheme.
<SiFuh_>
farkuhar: Do you think the removal of rc.functions is a good idea?
<zorz>
wait
<farkuhar>
SiFuh_: I tend to prefer not repeating the same code across multiple scripts. If there are common snippets that can be reused by all the rc scripts, why not put them into a standalone file? (almost like a C++ header)
<zorz_>
if [ -x /sbin/lvm ]; then printinfo "Found lvm, creating device nodes and lvm volumes" /sbin/vgscan --mknodes --ignorelockingfailure || printf "$(BOLD "$(RED)")" "[ERROR]" /sbin/vgchange --sysinit -a y || printf "$(BOLD "$(RED)")" "[ERROR]"
<zorz_>
fi
<zorz_>
this was not this in rc4
<farkuhar>
SiFuh_: You were right about zorz living in his own world. Everybody else has moved on from rc4, but he's still complaining about code that only appeared in rc4.
<zorz>
it was rc4 and then an update with the official
<zorz>
the update screw it
<zorz>
anyway the current works fine
<farkuhar>
zorz: Did you change pkgadd.conf before the update? The default rule "UPGRADE ^etc/rc.*$ YES" should have allowed pkgadd to replace all your old versions of /etc/rc{,.multi,.shutdown,.single} (i.e., without populating /var/lib/pkg/rejected and forcing a manual rejmerge later)
<SiFuh_>
zorz: So only the colour issue needs to be looked at
<zorz_>
now will be busy, make runit 1 read crux /etc/rc.
<zorz_>
and runit 3 read the crux shutdown
<zorz_>
and i am fine no more writting bash scripts
<zorz_>
SiFuh_: maybe at the beggining of the /etc/rc add this dmesg -n 1
<zorz_>
to print only emergency messages
<farkuhar>
zorz_: On the subject of dmesg, would you please explain what's wrong with /bin/dmesg > /var/log/boot , and why you prefer to see /sbin/bootlogd used instead?
<zorz_>
aaaaaaaaaaaa
<zorz_>
wait
<zorz_>
fuckin hell what kind of memory this boy has
<zorz_>
wait
<zorz_>
it was written as boot logs
<zorz_>
# Save boot messages
<zorz_>
/bin/dmesg > /var/log/boot
<zorz_>
now its messages
<zorz_>
dmesg is not bootlogs.
<zorz_>
maybe good to add
<zorz_>
dmesg >/var/log/dmesg
<zorz_>
chmod 640 /var/log/dmesg
<SiFuh_>
farkuhar: So in Back to the Future 3. He has no gasoline. So what happened to the gasoline that was in the time machine that Emmett Brown stashed into a cave?
<SiFuh_>
And why did he need to engine parts when he could get the parts from the stored Delorean?
<SiFuh_>
And why didn't he change engine parts*
<farkuhar>
SiFuh_: I can't even recall the plotlines of films that I watched within the past year. I certainly can't remember the details of BTTF3, which I haven't watched in at least a decade.
<SiFuh_>
Hmm, farkuhar I watched it at the drive in cinema :-P
<SiFuh_>
farkuhar: This man goes ice fishing. He comes to the ice and sets up a stool. He gets out a saw and starts to cut. Suddenly he hears a very loud voice. "THERE IS NO FISH UNDER THE ICE!" He looks around and sees no one. So he picks up his stool and moves about 10 feet away and starts to cut another hole. Then hears the voice again "THERE IS NO FISH UNDER THE ICE" He looks up and asks "Is that you
<SiFuh_>
God?" and the voice replies "NO! (Over the speakers) I AM THE MANAGER OF THE ICE RINK."
<zorz_>
SiFuh_: did you watch Havoc
<zorz_>
not bad action movie
<SiFuh_>
zorz_: Yep, long and boring.
<zorz_>
heh
<SiFuh_>
zorz_: Not joking. It took me 3 days to watch it.
<zorz_>
SiFuh_: i understand you, but lately everything is crap. so... it was not bad.
<zorz_>
let me give a nice alias to my friend farkuhar
<zorz_>
heh
<zorz_>
farkuhar: try this for ls
<zorz_>
l() {
<zorz_>
ls -gGAhF --color=always "$@" |
<zorz_>
sed -e 's/--x/1/g;s/-w-/2/g;s/-wx/3/g;s/r--/4/g;s/r-x/5/g;s/rw-/6/g;s/rwx/7/g;s/---/0/g;s/rwt/7/g' |
<zorz_>
sed 's/^\(....\) [[:digit:]] /\1 /'
<zorz_>
}
<zorz_>
d755 4.0K Apr 21 13:43 udev/
<zorz_>
d755 4.0K Apr 30 19:29 udevil/
<zorz_>
-644 315 Apr 21 13:47 updatedb.conf
<SiFuh_>
That 1985 Toyota SR5 Xtra Cab that Mart McFly drives is cool
<SiFuh_>
Marty*
<farkuhar>
SiFuh_: What do you think of /etc/rc.functions?
<SiFuh_>
I don't like it existing to be honest farkuhar especially for those users who don't want colour. But it makes sense to have it for those who do because it is an easy file to edit so all rc scripts can have universal colour
<farkuhar>
SiFuh_: If it's something the user might want to edit, then the handbook should say something to that effect. It won't be obvious to the new user, which startup scripts are meant to be customized (/etc/rc.d/{net,wlan} for example), and which are meant to be left alone.
<zorz_>
something wrong with crux.nu
<zorz_>
[20:36:44] < zorz_> look now i am checking the https://crux.nu/ports/crux-3.7/core/rc/Pkgfile it says source=(inittab rc rc.modules rc.single rc.multi rc.local rc.fix rc.shutdown rc.conf)
<zorz_>
[20:37:11] < zorz_> why 3.7, why source are the files?
<farkuhar>
Hence the existence of an entire section in the Handbook, documenting the possible customizations a user might want to make to /etc/rc.d/net. Any other file owned by the rc package, which the user is meant to edit in-place, should also be documented appropriately.
<farkuhar>
zorz_: Yes, I pointed out the commit where they changed the source array.
<SiFuh_>
Seems I might be installing a new auto-gate system on Sunday at her parents home.
<zorz_>
install a bomb man!
<SiFuh_>
Heh
<zorz_>
heh
<SiFuh_>
No I will need to remove the old PCB and install a new more modern one, then after wiring it up test the which frequencies to use and program about 6 remotes
<zorz_>
mmmm nice idea electroshockcute them!!!
<farkuhar>
Regarding the name of the sourced file, if we follow jaeger's example and rewrite BOLD, RED, GREEN as shell variables rather than functions, does the name "rc.functions" deserve to be reconsidered too?
<SiFuh_>
farkuhar: I'd prefer it to be in /etc/rc but as ppetrov^ was saying about Wi-Fi, feels wrong to edit the rc files
<farkuhar>
SiFuh_: It only feels wrong to edit the rc files if the Handbook doesn't explicitly endorse such in-place modification. In the case of network configuration, that section has been unchanged for the past several CRUX releases, so users are aware that all their configurations are done through direct editing of /etc/rc.d/{net,wlan}
<SiFuh_>
No, it feels wrong
<SiFuh_>
There should be a net.conf and a wlan.conf or merge both together.
<farkuhar>
Okay, if you insist. But if we extract the user-editable variables into a separate file, the Handbook should be updated accordingly.
<SiFuh_>
And rc.functions should be rc.colours
<SiFuh_>
farkuhar: Yes
<SiFuh_>
farkuhar: Well to be honest rc.conf basically means what it says in the name.