erilun06-mobile has quit [Ping timeout: 244 seconds]
erilun06-mobile has joined #crux-social
ppetrov^ has quit [Quit: Leaving]
ppetrov^ has joined #crux-social
ppetrov^ has quit [Remote host closed the connection]
ppetrov^ has joined #crux-social
ppetrov^ has quit [Quit: Leaving]
ppetrov^ has joined #crux-social
farkuhar has joined #crux-social
<farkuhar>
ppetrov^: libexec appears on lines 764--767 of the gimp footprint. If you sync the contrib repo using git, you can figure out when those lines were added: `git blame -L 764,767 gimp/.footprint` reports that they were inserted by commit d80fb059fb on 2025-03-17.
<farkuhar>
That was the major version bump 2.10.38 -> 3.0.0, by the way.
<ppetrov^>
farkuhar , beerman said he's onto it
<ppetrov^>
btw, seems it was up to you to handle the handbook and jue said he does not know why you removed the install dirs section
<ppetrov^>
they included OTB fonts for Terminus, which is nice. I just asked 2 days ago
<farkuhar>
The PmWiki counterpart to git-blame(1) is "Page History", where you can see it was one of my clumsy attempts to reorganize Handbook3-8-Package that resulted in the loss of the PackageGuidelines section. I restored that section a few minutes ago.
<ppetrov^>
great, thanks
<ppetrov^>
i may open another ticket, vte3 installs desktop icons with a missing icon
<ppetrov^>
farkuhar, may I ask another thing... why does the Development section of the webpage list "Commit timeline for core and opt ports ", but not for xorg and contrib?
<farkuhar>
According to https://www.pmwiki.org/wiki/PmWiki/PageHistory , the site's wiki administrator can customize the $DiffKeepDays and $DiffKeepNum variables, to automatically discard edits older than a specified range.
<farkuhar>
ppetrov^: No idea why they restricted the commit timeline to show only those two repos.
<ppetrov^>
btw, what happened with the isea of pkgmk handling git natively?
<farkuhar>
Heh, the new-fangled way they want proposals introduced is via Gitea pull requests. If nobody bothers to create a PR, it's as if the discussion never happened.
<farkuhar>
You would think that the commit timeline would definitely include the xorg repo, if it's going to include core and opt. One of olutmies' replies to alexmat's Flyspray ticket "libxpixman and QEMU on headless host" said it was an unsupported use-case to disable the xorg repo, if you're going to keep the opt repo enabled.
<ppetrov^>
so, I should do a PR, not just write commens on an issue?
<ppetrov^>
what if I cannot fix something
<farkuhar>
According to pitillo, the more durable way to start a discussion is via mailing list, if you don't have an example of working code that can be merged. It seems that IRC is not the preferred venue for user feedback to the core team.
<ppetrov^>
i get it... however, i did a request about a font, and they did it real fast
<ppetrov^>
so, opening a ticket seems productive
<farkuhar>
opening a ticket about the ports, yes. I'm not sure you'd get the same result if you opened a ticket about our distro-specific tooling. The sheer variety of possible enhancements to pkgutils and prt-get makes it hard to assign the ticket to a single maintainer, and expect a quick resolution pleasing to all parties.
zorz has joined #crux-social
<ppetrov^>
farkuhar, how about /usr/share/doc
<ppetrov^>
i see 4 packages installing stuff there
<ppetrov^>
one installs config files
<zorz>
'lo cruxers.... let's socialize:P
<zorz>
SiFuh_: Fuck you!
<zorz>
:P
<farkuhar>
ppetrov^: zorz came here to socialize, not to read serious discussion about CRUX. If he wanted serious discussion, he would have joined #crux-musl.
<ppetrov^>
k, shall I ask you the same question in #crux, then?
<ppetrov^>
i am not interested in musl
<farkuhar>
ppetrov^: /usr/share/doc is in the footprint of more than 4 ports. Maybe on your machine only 4 of the installed ports put stuff in /usr/share/doc, but if users want the most abundant /usr/share/doc they could install calf, coturn, hwloc, kodi, libvirt, mpv, opendmarc, openpmix, passt, prrte, and wireplumber.
<ppetrov^>
so, that's the desired outcome?
<ppetrov^>
the handbook lists usr/doc/* as junk, not usr/share/doc
<ppetrov^>
i cannot explain why this irks me
<zorz>
hahahha
<farkuhar>
ppetrov^: Don't read too much into the name of the channel. Not everyone who joins #crux-social is interested in socializing, either. We got told to take the random chit-chat out of #crux, but by coming here we depleted #crux of its most valuable resource: knowledgeable users who can help troubleshoot problems with the distro.
<zorz>
ppetrov^: thumbs up!
<zorz>
as SiFuh_ said, farkuhar should keep his serious discassion in #crux-musl
<farkuhar>
Maybe the handbook singled out /usr/doc because that's a non-standard location. Meanwhile /usr/share/doc has a more respectable history, so it was allowed to remain.
<ppetrov^>
"README, *.info, *.html"
<ppetrov^>
bunch of htmls there...
<ppetrov^>
e.g. flac
<farkuhar>
ppetrov^: zorz is echoing the assertion that it was becoming hard to navigate a rapid-fire conversation between SiFuh and zorz, when I was periodically injecting paragraph-length expositions on a completely different topic. So they created a new channel to serve as a scratchpad for these digressions. That's the real purpose of #crux-musl, and hence why you shouldn't read too much into the "musl" part of the name.
<ppetrov^>
farkuhar, you have to admit, a bunch of stuf that is being talked here is quite random and non crux related
<ppetrov^>
imagine i posted all the stupid memes in #crux
<ppetrov^>
or, how about #crux-devel
<ppetrov^>
they'd love that, i'me sure
<ppetrov^>
and when lababall was here it was even worse
<ppetrov^>
so yes, they did have a point
<farkuhar>
ppetrov^: I pointed out this contrast before... KISS Linux has managed to avoid partitioning their IRC conversation into discrete channels. They manage to keep it all in one big channel. Meanwhile, CRUX has a history of always creating a new channel when they feel that a small minority of users is hijacking the old channel and interfering with what everyone else wants to discuss.
<ppetrov^>
so, what do we do?
<ppetrov^>
just list #crux-social on crux.nu, with a warning
<ppetrov^>
for me, this became _de facto_ the main community channel for crux
<farkuhar>
Even if #crux-social isn't listed on the homepage, users who join the officially-recognized channels might find their way here after following the link (in the topic) to the whitequark logs, and seeing other #crux-* channels listed.
<farkuhar>
zorz: Did you rewrite pip2crux yet?
<farkuhar>
zorz: SiFuh was asking if anybody had hardware for building a new ISO. As I recall, your machine is capable of building firefox in 30 minutes, so would you be willing to put it to work building an entire CRUX ISO?
<zorz>
yes i put
<zorz>
but my machine is the same as sifuh
<zorz>
we have the same laptop
<zorz>
farkuhar: tell me how i i will burn it
<ukky>
ppetrov^: imho, this _is_ main Crux channel. There is no feedback in #crux, about Crux, unless it is an install/upgrade/port issue.
<ppetrov^>
ukky, well it kinda seems so
<farkuhar>
Even if you grant pitillo's claim that the core team is more responsive to mailing list posts than to questions in #crux, there's the inconvenient fact that Markus' recent question was met with 3+ days of silence, apart from stenur chiming in to support him.
zorz has quit [Quit: leaving]
<farkuhar>
stenur's reply suggested we should reconsider the distro policy of not listing runtime dependencies provided by the core collection (the list can contain build-time dependencies that are dynamically linked-in). Runtime dependencies like perl and python might explain the stale files reported by Markus, and they might not have been generated at all if the update of those packages had been deferred until after perl and python.
<ppetrov^>
i do not list deps from core in my ports
zorz has joined #crux-social
ivandi has quit [Quit: WeeChat 4.6.2]
ivandi has joined #crux-social
<farkuhar>
The stale files reported by Markus are probably an artifact of the 3.7 -> 3.8 "in place" upgrade. Obviously the ISO cannot provide the 3.8 version of every package, so some ports that Markus had on his 3.7 installation would not have been updated. If the 3.8 ports trees don't have different values for $version and $release, then he would have to force a rebuild to get rid of the old /usr/lib/python3.10/ stuff.
<farkuhar>
Forcing a rebuild by bumping $release ... that's how we were supposed to do the recent python3 "do not force a bytecode level" commits. Otherwise, users aren't alerted to the need for a rebuild (by `prt-get diff`).
<farkuhar>
ppetrov^: Are you sure it's the presence of poppler-ink that triggers the failure? Did you get a successful build of gimp, when poppler-ink was not installed?
<ppetrov^>
yes, i did
<farkuhar>
Hmm, can you insert debug commands into the gimp build(), echoing the values of $PKG_CONFIG_PATH, $LDPATH or similar? Because poppler-ink is supposed to live unobtrusively in a directory that won't be auto-detected by meson build systems.
<ppetrov^>
how do i do that
SiFuh is now known as SiFuh__
SiFuh_ is now known as SiFuh
SiFuh__ is now known as SiFuh_
<farkuhar>
ppetrov^: Check the contents of /usr/share/pkgconfig/poppler-data.pc, and see if it mentions the directories associated with poppler-ink.
<ppetrov^>
poppler_datadir=/usr/share/poppler
<ppetrov^>
Name: poppler-data
<ppetrov^>
Description: Encoding files for use with poppler
<farkuhar>
ppetrov^: Okay, I don't see anything in the poppler-data.pc file that would activate the eager linking of poppler-ink stuff. Maybe you should attach a full build log for gimp.
<ppetrov^>
what was the command "| tee" something?
<ukky>
zorz: good job. I just wonder if starting udev late, in 2nd stage of runit, would stutter some of the tasks in /etc/rc because of udev delayed start.
<zorz>
ukky
<zorz>
i totally rewrite the thing.... i use SiFuh_ rc as 1
<zorz>
you like to send 1,2,3 etc by email or x0st ?
<ppetrov^>
so, zorz will totally rewrite the thing and make it better
<ukky>
zorz: I know, as you already asked me to review your /etc/runit/1. But SiFuh's /etc/rc starts udevd as daemon, which will not be handled by runit.
<zorz>
now i am creating the services
<farkuhar>
"totally rewrite the thing", heh. From the context I suppose you're not talking about pip2crux any more.
<ppetrov^>
i was
<zorz>
ukky: as I said i changed it
<ppetrov^>
wut, did i miss sth
<ppetrov^>
i am drinking...
<zorz>
farkuhar: pip2crux, when i finish with runnit.....
<farkuhar>
ppetrov^: Blink^H^H^H^H^HDrink and you miss a revolution.
<zorz>
since, crux devs dont understand.... i will do pkgrm sysvinit && pkgrm rc and pkgadd runit#2
<ppetrov^>
farkuhar, if you are in charge of the webpage, can you add contrib and xorg to the Development section?
<farkuhar>
ppetrov^, did you see jue's reply to your #38 gimp build failure?
<ppetrov^>
yes
<farkuhar>
So was nss one of the ports you deleted, in your obsession to reduce ports?
<ppetrov^>
nope, i was talking about my own ports
<farkuhar>
So revdep didn't report any breakage elsewhere in the gimp dependency tree?
<ppetrov^>
nope
<ukky>
zorz: /etc/runit/1 seems okay for a test. I would move 'runsvcdir' execution from /etc/runit/1 to /etc/runit/2 after testing/debugging.
<farkuhar>
Well, revdep doesn't catch everything. As braewoods pointed out, it works at the level of libraries, not individual symbols. So if you check the timestamps in $PKGMK_PACKAGE_DIR, you can see whether nss got updated after poppler.
<ppetrov^>
revdep does not catch stull that needs a rebuild after qt5 update
<farkuhar>
ppetrov^: Maybe you could add your voice here, https://git.crux.nu/ports/core/issues/6 , so that `prt-get sysup` will recognize the eager linking between poppler and nss, pushing nss earlier in the queue.
<ppetrov^>
is "quickdep --softdeps" a thing in prt-get?
<farkuhar>
The default behaviour is to ignore Optional dependencies completely. If you build the prt-get from my forked repo, you get softdeps awareness in many of the commands, but sysup is the one that would have affected your gimp build.
<zorz>
ukky: yes... as I said... i did it copy paste cut fast and it works
<ppetrov^>
farkuhar, not everything that a port wil link to is mentioned on the "Optional" line
<zorz>
now it needs sulogin etc etc
<zorz>
but... its a good start to have my computer fuctionning on runit and then slowly slowly make the canges.
<ppetrov^>
farkuhar, I would be happy if prt-get handled NEW dependencies automatically upon prt-get sysup
<farkuhar>
ppetrov^, true, we can't expect maintainers to be aware of every possible eager linking. But the ones they are aware of, they can list. And then prt-get can make use of that information.
<farkuhar>
ppetrov^, injecting NEW dependencies is also possible in my forked prt-get. You can raise that point when adding your voice to stenur's Gitea issue.
<ppetrov^>
so, why the hell is not your changes a part of the offical prt-get?
<ppetrov^>
ok, I will, just let me sober up
<zorz>
ukky boot.conf is the rc.conf
<ukky>
zorz: /etc/runit/shutdown.local should be executed _before_ services are stopped/killed.
<ukky>
zorz: boot.conf should be renamed. It has definitions for system-wide settings. The fact it is used at boot is not a good reason to name it 'boot.conf'
<zorz>
okay
<ukky>
zorz: '/sbin/poweroff' and '/sbin/reboot' should not be used, unless you make 'sysvinit' as a dependency of 'runit' and require 'sysvinit' installed.
<zorz>
let me do a reboot with dhcpcd and nftables as service to see if they work....
<farkuhar>
ppetrov^s gimp failed at target 1705/2586. My gimp build has proceeded to target 2545/2574 and is still going. If the build is going to fail, it doesn't have too many targets left for that to happen.
<farkuhar>
Heh, my gimp build failed on the final target. First it complained about "illegal variable name in environment file gimp-3.0.2/data/environ/meson.build", then python-eval.py got an unexpected EOF, breaking the pipe that was being consumed by src/build/app/gimp-console-3.0 (which segfaulted as a result).
<farkuhar>
Too bad I forgot to pass the --keep-work flag. Now I have to run the whole build again, to see what part of gimp-3.0.2/data/environ/meson.build triggered the "illegal variable name" warning.
<ppetrov^>
:(
<farkuhar>
In any case, I don't think I've managed to reproduce ppetrov^s #38 exactly. If it weren't for the python script being so finicky about variable names, I think the build would actually have succeeded.
* farkuhar
starts the gimp build again, this time with -kw
erilun06-mobile has quit [Ping timeout: 248 seconds]
erilun06-mobile has joined #crux-social
<zorz>
SiFuh: sounds better than sex :P
<zorz>
brb
zorz has quit [Quit: leaving]
<farkuhar>
ppetrov^: https://dpaste.com/DP4X8SKC3 <- somehow gimp got the idea that I was building on a Windows platform? I don't even reboot into Windows to play Fallout!
<ppetrov^>
interesting, farkuhar
<farkuhar>
I'll try again after inserting `sed -i '3,7s/^/# /' gimp-3.0.2/data/environ/meson.build` into the Pkgfile. That should stop it from trying to export BIN_PATH on the final target.
<farkuhar>
Actually the Pkgfile is moot at this point, since I kept the work directory. I can just edit it in-place and re-run `meson compile` from the work directory.
<SiFuh>
farkuhar: Did you notice that there are all these extra things inside of the Pkgfiles like renaming and moving stuff and erasing things that were not required when using ./configure but now have to be added when using meson?
<ppetrov^>
but why does it do this at all?
<ppetrov^>
you are using bash, right?
<ppetrov^>
does this matter, actually?
<farkuhar>
ppetrov^: Same error even after manually editing gimp-3.0.2/data/environ/meson.build (which appears to be reverted to its previous state by the `meson compile` command). Maybe there are too many artifacts in the build directory, from the last unsuccessful attempt.
zorz has joined #crux-social
<SiFuh>
zorz: Yeah, when I hit enter at the boot prompt for syslinux, the screen goes black to refresh the display and when it returns a second later, the entire system has already booted faster than the screen refresh. But still ironing out some code. I was just doing it for fun. But damn it is fast even for a dinosaur machine.
<zorz>
ansi c
<zorz>
i modified your rc for /runit/1 and runit/3
<zorz>
SiFuh: is gods present :P
<zorz>
after that as i said to farkuhar
<SiFuh>
Well it is better than satan olutmies crap
<SiFuh>
I was here the whole day. I read everything. I just couldn't be bothered to reply
<zorz>
no i got upset... cause the other day i do sysup it updates rc and i still get the old crap
<zorz>
so they can do as they pleased :P
<farkuhar>
zorz: It's sad. jue knew what we were working on, yet he pushes only a minor fix that still leaves the rc scripts looking like a mess.
<SiFuh>
zorz: I am using the old rc script. But I boot with /etc/init.d/rc the ANSI C one. But when it has an issue, I can just run /etc/rc from the prompt and it finishes booting which is pretty cool. So I don't need any emergency rescue disk or anything.
<SiFuh>
zorz: I find it funny how farkuhar sees things my way after I have explained it to him :-P
<farkuhar>
SiFuh_: autotools and autoconf builds are not without problems, though. Consider the nmap build failures that ivandi pointed out in #crux.
<SiFuh>
farkuhar: Well, so far I have switched everything back to ./configure and I find I have to erase most of the gobbledygook at the bottom then compare the .footprints
<SiFuh>
farkuhar: I still have no cmake or meson in core yet. But I haven't done any work on it since yesterday.
<farkuhar>
SiFuh_: I still find it suspicious that the join/leave timestamps show jue spending a few hours in #crux and #crux-devel on the very day that he pushes the "fix" to tools/rc. I wonder if there was a private communication behind the scenes, which persuaded him not to adopt our modularized rc scripts.
<SiFuh>
farkuhar: One could speculate
zorz has quit [Ping timeout: 260 seconds]
<SiFuh>
farkuhar: I find it disgusting that olutmies insults a newbie and I told him not to be a dick and suddenly he has so much animosity like I popped his bubble
<SiFuh>
Poked his pride
zorz has joined #crux-social
<farkuhar>
ppetrov^: Okay, even with gimp-3.0.2/data/environ/meson.build edited in the Pkgfile (before running `meson setup`), I still hit the same error on the final target. I note that the "illegal variable name" is only a Warning, but it's serious enough to break the pipe being consumed by src/build/app/gimp-console-3.0
<ppetrov^>
well,... my issues were different
<SiFuh>
ppetrov^: I found it funny that jue said he will pass gimp to beerman. :-P If you know what a gimp is
<farkuhar>
Yeah, I don't think this major version of gimp is ready for mass rollout. Better stick with the previous version.
<farkuhar>
On my last attempt at building gimp, the spawned python script didn't even exit cleanly, where before it at least returned me to a prompt without further intervention. This time I had to kill that runaway python script with Ctrl+C.
<zorz>
SiFuh: this is cool boot with /etc/init.d/rc the ANSI C one. But when it has an issue, I can just run /etc/rc. Myself untill complete runit, i had to boot with system-rescue mount crux and cp /sbin/init.bak to /sbin/init
<farkuhar>
I'm done testing gimp-3.0.2; somebody else can take over and try to reproduce ppetrov^s #38. pkgrm gegl appstream-glib graphviz mypaint-brushes gexiv2 poppler-data libmypaint python3-gobject babl python3-cairo exiv2 json-c libart_lgpl inih keyutils
<zorz>
SiFuh: is a way to log the boot ? prosseces? now with runit?
<SiFuh>
zorz: Little tips. I did few custom CRUX ISO's back in the day. So it was a good thing to remember.
<zorz>
i might install sysvinit, only for bootlogd... till check runit rc is okay.
<farkuhar>
`pkgrm graphviz` still leaves /usr/lib/graphviz in the filesystem, because it contains "config6" which was generated by the graphviz post-install script. Here's why we need a pre-remove hook, to undo anything created by post-install.
<dlcusa>
SiFuh, I'm reconsidering my priorities regarding building the ISO. Please send me what doc there is on the process so I can intelligently determine if I can make it happen. I'm been away from that kind of effort for many years, so I'll be on a serious re-learning curve.
<SiFuh>
dlcusa: But there are other ways to do it. And ukky has his way too.
<SiFuh>
dlcusa: Problem with jaegers script is if it fails in the chroot fakeroot it will erase everything you did. So you need to comment out that because it doesn't properly umount everything.
<dlcusa>
Part of my deliverable will be doc on how I did it.
<SiFuh>
dlcusa: I usually just build it the ports I want. Extract to a new root. Setup chroot, and rebuild again. Then do the same again with new ports instead of relying on the script. I then run only the final parts for the ISO build after that.
<ppetrov^>
pre-remove hook: I have given up and accepted that some junk will be left, because of post-install scripts
<dlcusa>
...reading... I'll keep you posted on how it's going...
<SiFuh>
ppetrov^: I mentioned that back in 2018 but it fell on deaf ears.
<SiFuh>
No, that's not my job. CRUX users are not meant to just fix problems for the dev team or the port maintainers. That's a fallacy they created to get out of fixing their mess and to insult users for complaining.
<ppetrov^>
for example, check "# DESCRIPTION: Updates the system mime database."
<SiFuh>
ppetrov^: Everytime I'd tell beerman his port was broken. He'd insult the living shit out of my system blaming me. Romster would verify it and then beerman would fix it. Never any apologies.
<ppetrov^>
back to beerman, i see
<SiFuh>
That's where all the problems lie
<SiFuh>
I will be chainsawing again tomorrow and bottling beer on Monday. So I won't really get a chance I think to finish my ANSI C super rc until maybe Tuesday while waiting for paint to dry.
<farkuhar>
It would be nice if the post-install scripts that create new files, could also edit the pkgdb so that those new files are regarded as belonging to the port. That way they aren't left behind if you later decide to pkgrm something.
<SiFuh>
farkuhar: A second footprint ;-)
<ppetrov^>
farkuhar, is it possible these files be included in the package?
<farkuhar>
ppetrov^: for some of the ports, maybe. For other ports it really is easier to unpack the tarball to disk first, and then generate the additional files using post-install.
<dlcusa>
SiFuh, you recommend using the 3.7 version over the 3.8?
<ppetrov^>
and the way Slackware does it?
<SiFuh>
dlcusa: No.
<dlcusa>
Good to know, thanks.
<SiFuh>
dlcusa: Use the new rc we wrote and don't worry about rc-colours for now. That can be introduced later.
<SiFuh>
And if you are building an ISO, get rid of that stupid rc.shutdown.local that farkuhar introduced and change it to rc.shutdown
<dlcusa>
Yeah, that's a significant part of the current mess.
<SiFuh>
dlcusa: rc.shutdown.local only makes sense if you don't want to erase the old rc.shutdown.
<farkuhar>
ppetrov^: What do you mean "the way Slackware does it"?