<ppetrov^>
hi guys, due to an unknown reason wxgtk kept installing /usr/lib/cmake, although there's this row: rm -r $PKG/usr/{include,lib/{cmake,libwx_base*},bin/wxrc*}
<ppetrov^>
i had to modify it like this: rm -r $PKG/usr/{include,lib/{cmake/,libwx_base*},bin/wxrc*} and it works (notice: cmake/)
<beerman>
so... is he telling us he misconfigured his build environment? I'm confused..
<farkuhar>
well, he left before we could ask him to post a build log. I do recall seeing a message during my test, that cmake was ignoring one of the variables passed on the command line (CMAKE_INSTALL_LIBDIR, iirc). But no filesystem collisions ensued, so I couldn't reproduce ppetrov^s report.
<beerman>
¯\_(ツ)_/¯
<beerman>
he has a gtk1 port online
<beerman>
therefor i expect the worst from his system
<beerman>
even inkscape 😆 damn
<beerman>
and no sense for indenting code in Pkgfiles, rip
<jaeger>
OK, finally going to commit and bump pkgutils today, been super busy
<beerman>
the good kind of busy, hopefully
<jaeger>
Some yes, some no
<beerman>
gotcha
<beerman>
hopefully you get to be less busy soon
<jaeger>
thanks
ppetrov^ has joined #crux-devel
<ppetrov^>
hey, i saw the chat log. How can I check if I misconfigured sth in my build setup?
<beerman>
i dunno, i just booted the server to investigate your error in my container, but it has been tested by jaeger and farkuhar which lets me believe: the build will come back clean.
<ppetrov^>
ok
<beerman>
like i wrote: i expect something is not properly in place on your system.
<ppetrov^>
mhm, because I have a gtk1 port and i lack identation :P
<beerman>
yep
<ppetrov^>
i'll double check, thanks
<beerman>
np
<ppetrov^>
for the record, if ports that build old stuff are a problem, feel free to remove me from portdb
<beerman>
i don't care, you can do what you want, but that also means that you may find yourself in a situation where nobody can help you without spending a ton of time to go with you over your system
<jaeger>
ppetrov^: posting a full build log might help
<jaeger>
No, old stuff is not a problem. Your ports, your choice
<beerman>
i don't have that time, sorry. I can rebuild your problematic port and see if that shows that there is a problem with the port, only using core, opt, contrib. if there is no problem.. see aboce
<beerman>
and yes: a full build log is always a good idea 😄
<jaeger>
We may not be able to fully help if we don't have the same things installed, of course... but it's not like you can't do what you want with your own system :)
<beerman>
so, rebuilding wxgtk-common as a first step was a success, no missing, no new, no weird stuff during the build. now i'll try with wxgtk (which I still feel like we should just drop)
<beerman>
and again: no missing, no new, and no conflicting
<beerman>
jaeger: i disagree, btw. old stuff can be a problem. if there is anything on his system that triggers wxgtk to build other files in addition, we have no idea about that. and it seems like ppetrov^ doesn't either. whatever it is, its not part of the default dependency chain as of now
<jaeger>
For me it's subjective. I don't have a need or desire to run gtk1 on my system but I'm not going to attempt to dictate what ppetrov^ can or can't run. Just making it clear that supporting that is no guarantee
<ppetrov^>
ok, don't bother with this, if it happens just here. i'll double check my system. Sorry for wasting your time
<beerman>
Sure, anybody is free to run whichever gtk version and stick to whatever ancient version they desire, but they can't "open bug reports" for those
<jaeger>
Anyway, my guess about the /usr/lib/cmake thing was going to be one of two things: 1. maybe a CONFIG_SHELL expansion issue, or 2. maybe wxgtk installs it outside $PKG
<jaeger>
The former because dash, for example, won't expand $PKG/usr/{include,lib/{cmake,libwx_base*},bin/wxrc*} like bash
<jaeger>
But it's a cmake build rather than autotools, I guess
<jaeger>
And this wouldn't make sense anyway since the rm command is in the build() function, not the wxgtk source
<jaeger>
So ignore me, off in the weeds
<beerman>
no worries, but its all just ideas but ppetrov^ has to supply logs etc
<farkuhar>
one benefit of dropping wxgtk is that it allows us to consolidate the remaining two wxwidgets ports into wxgtk3. There wouldn't need to be any rm -r commands in the build() function of a consolidated port.
<beerman>
and when there is a need for wxgtk4 we do it all again
<beerman>
if there is any, at least, i didn't look for it
<farkuhar>
looks like it was May 2020 when Romster split one port into wxgtk, wxgtk-common, and wxgtk3. Audacity's dependency chain went with the wxgtk3 branch, leaving few ports (if any) still requiring wxgtk.
<beerman>
be precise: none in contrib
<farkuhar>
at the moment, none in contrib, true. But in May 2020 when the split happened? Maybe there were a few wxgtk-dependent ports, which have since been dropped. More digging through the commit history is needed.
<beerman>
in may 2020 is almost 3 years in the past 😄
<beerman>
2015 gtk1 was still in, thats no argument
<beerman>
though, i think it wasn't anymore, ignore that, but you see the point i'm trying to make
<farkuhar>
yes, three years does make a rather lengthy commit history. But grep for "dropped" and the search becomes more manageable. Probably not worth the effort, though.
<beerman>
exactly, what good does it make if it only produces problem where a user actually chooses to still run that stuff?
<beerman>
exchanging gtk2 -> gtk3 -> gtk4 is the way, same as for python2 -> python3 and qt5 -> qt6
<beerman>
when there is nothing left for it, drop it
<farkuhar>
`prt-get dependent --all python | wc -l` still shows four ports (all Romsters). clink at least looks easy to modify for python3 (would be even easier if we had 3.11 hashlib functions, rather than the more limited hashlib of python 3.10).
<farkuhar>
but that's a pull request better sent to the upstream author
<beerman>
clinks last release was in 2006...
<farkuhar>
trying to fix clink reminded me that python2 was much more forgiving than python3, when it comes to whitespace and indentation. If I submit a PR to its author, more than half the diff will be whitespace edits.
<beerman>
i'd vote for dropping again
<ppetrov^>
k, sorry for the delay. I rebuilt so I can provide you with a log, and I do not get that "problem" anymore.
<beerman>
😉
<ppetrov^>
I don't know what went wrong before, and I apologize for the useless discussion
<ppetrov^>
i am open to comments, jokes and degrading criticism :P
<beerman>
you seem to have that all in your head by yourself, no need to add any more to it 😉
<beerman>
most likely it was left over files: one truth about a source base distro (especially like ours where we often do not bump release numbers in ports to force a rebuild) - rebuild often.
<farkuhar>
ppetrov^: regarding your fontconfig issue, does your pkgadd.conf have a directive that allows UPGRADE ^etc/fonts/conf.*$ ? The conf.avail directory might not have been populated correctly if you didn't override the default UPGRADE ^etc/.*$ NO.
<farkuhar>
normally what doesn't get installed is saved for later review using rejmerge, but symlinks appear to get treated differently (as we know from FS#15). You might want to rebuild fontconfig after appending another line to pkgadd.conf.
<ppetrov^>
hmm, farkuhar, did i have a fontconfig issue?
<ppetrov^>
aaah, yes... but the readme was updated, right?
<farkuhar>
aaah, yes it was, only one day after your post in #crux. Nevermind, then.
<beerman>
I like how farkuhar seems to have read the whole CRUX backlog and never forgets a single thing, it seems 😄 i also liked the contrib/dia change, even though I would most likely be to drop that as well lol
<ppetrov^>
or maybe he just searched for me to see if i was whining about sth else
<beerman>
he is referencing FS#15, which is a ticket from 2006..
<pitillo>
farkuhar: when did you start with CRUX? if that could be known
<farkuhar>
pitillo: I started around CRUX 3.1 or 3.2
<farkuhar>
just never thought to join the IRC channel until about two years ago
<pitillo>
that has sense... I disconnected a bit (I kept checking -devel) near 6 years ago when my son was born... and I saw your work these last two years (same as beerman)
<pitillo>
I was just curious. Keep up the good work :)
<farkuhar>
aw, shucks (as dlcusa might say). You're no slouch yourself, with all the work involved in porting CRUX to ARM hardware.
<pitillo>
work is done upstream :P
<jaeger>
Anyone get segfaults with itstool recently?
<jaeger>
For some reason I can no longer build the latest version of mate-applets even though it worked fine in initial testing, heh
<jaeger>
Unrelated, did we have something recently about 'w' not working? I vaguely remember it but searching for 'w' in logs is kinda challenging
<jaeger>
It shows uptime but not users on one system
<beerman>
jaeger: w works for me
<beerman>
at least appears to be
<beerman>
not sure about itstools
<jaeger>
Yeah, it works for me as well on most systems... but not one system
<beerman>
for me, shared-mime-info is failing, complaining about xmlto, guess i'll have to rebuild something. all else which depends on itstool rebuilt fine (gtk-doc, zenity, engrampa)
<jaeger>
updating to libxml2 master fixes the mate-applets build but also requires rebuilding some other packages linked against libxml2
<jaeger>
I wonder why it's a problem now, though... libxml2 was updated to 2.10.3 in october last year, that's not a new change
<beerman>
no idea either
<jaeger>
itstool's last update was a year before that
<jaeger>
Maybe something to do with the latest python
<beerman>
i am rebuilding all dependencies of shared-mime-info to give the good ol' shotgun method a try
<beerman>
well, yeah, seems like those patches might help to fix that
<farkuhar>
beerman: distros "like ours where we often do not bump release numbers in ports to force a rebuild" -- guilty as charged (xmlto). shared-mime-info is rebuilding fine here, fwiw.
<farkuhar>
jaeger: the itstool segfault with mate-applets has happened before, but reproducing is hit-or-miss, as you noted with a successful initial test. Something about a "use after free" bug that is triggered by mismatched opening/closing xml tags. https://github.com/mate-desktop/mate-applets/issues/388
<jaeger>
Been to that bug report as well but it's happening again in 1.26 despite their saying it's fixed/closed in 1.20, 1.22, and master
<jaeger>
And the age of the bug
<farkuhar>
Even if itstool say it's fixed/closed, the fact remains that it's happened in that codebase once before, and such segfaults have never been blamed on libxml2.
<farkuhar>
But you got a successful build after updating to libxml2 master, so there must be some interaction that all these bug reports haven't yet uncovered.
<jaeger>
yep
<jaeger>
They weren't blamed on libxml2 then, they are now it seems
<jaeger>
One of those (don't remember which, doesn't really matter) directed me to the gitlab.gnome.org issue
<jaeger>
unrelated, can anyone duplicate this rhash failure?
<jaeger>
install: cannot change permissions of '/usr/ports/work/rhash/pkg/usr/bin/rhash': No such file or directory