<Begasus>
another small patch upstreamed (kudos to extrowerk_) :)
<Begasus>
OscarL did you read the issue with bakefile?
<Begasus>
that's still reported on the buildmasters reports
<Begasus>
bakefile-0.2.11-1-x86_64.hpkg:
<Begasus>
requires "cmd:python >= 2.7.14" of package "bakefile-0.2.11-1" could not be resolved
<OscarL>
"read the issue" as in a GitHub issue? I've only saw what you wrote on IRC a couple days ago (maybe less). I've "left a note" with my thoughts.
<OscarL>
I couldn't find the Debian package for bakefile... Unless I've missed it.... that's saying something.
<Begasus>
Ah right
<Begasus>
yeah, have been looking over at repology and didn't find any sollution there too
<Begasus>
maybe time to drop it
<Begasus>
nothing uses it ...
<OscarL>
Only saw it mentioned on the wxQt patchset file.
<Begasus>
oh, right, inrecipe doesn't check those
<OscarL>
As I wrote the other day: "01:47 <OscarL> Begasus: Mmm, I only see it mentioned on that wxQt patchset, but the .recipe doesn't even REQUIRES any Python so... maybe we're in the clear with dropping "bakefile" as long as we don't have to re-generate wxQt's bakefiles?"
B2IA has joined #haiku
<Begasus>
yep, I think it's using some internal sourcces for that
<Begasus>
forgot I cleaned the build for llvm12, starting from scratch again :)
<OscarL>
ouch
<OscarL>
mmm that agg-r138 SOURCE_URI that cocobean used is only valid when you use the web UI for sourceforge, and I guess it then times out or something. (you can get it to generate the link using https://sourceforge.net/p/agg/svn/HEAD/tarball?path=)
<OscarL>
That doesn't looks like something usable from HP :-D
<Begasus>
if all goes well on llvm12 I guess it's time to drop the older ones
<Begasus>
prio list, after LO, check work from jmairboeck and tuxpuck (last one should be fast enough to check) ...
<OscarL>
re: report.txt very nice :-)
<Begasus>
it's the number 1 spot to check on some major changes :)
<Begasus>
PS, thanks on the icon for Iaito PulkoMandy!
<Begasus>
OscarL, anything needed on the matplotlib PR? (haven't checked in a while)
<Begasus>
if you are free you could have a look into counterpy ;)
* OscarL
goes to read again the matplotlib... only thing I remember is not wanting it to depend on Qt (just to avoid pulling those deps).
<OscarL>
I'll look at "counterpy" and you at "contourpy", deal! :-P
<Begasus>
that was removed :)
<Begasus>
ah no, still got it in here
<Begasus>
time for the doggies ... biab
<OscarL>
I'll try matplotlib (with the AGG backend) and contourpy tomorrow (already too sleepy, and my Haiku installs have been acting up, network-wise, both on VM and bare-metal :-/).
<botifico>
[haiku/website] trungnt2910 541cac0 - blog/trungnt2910: .NET port progress 5
jmairboeck has joined #haiku
<Begasus>
hi jmairboeck
<jmairboeck>
hi Begasus
<erysdren>
hello all
<Begasus>
hi erysdren
<jmairboeck>
regarding perl: I took a look at the packages that openSUSE is providing; there are "perl-32bit" packages on x86_64 which contain only the architecture specific part in $libDir and no perl binary at all. I think that this wouldn't work for our case though.
<jmairboeck>
first, the architecture is the same for x86 and x86_gcc2, both "BePC-haiku" in terms of perl, so we need a different base directory (i.e. /system/lib/x86) anyway. And second, I think we need an actual perl binary compiled with modern gcc for this to work.
<jmairboeck>
the openSUSE "perl-32bit" package contains libperl.so, but I'm not sure how (or if) this would actually work
AlaskanEmily has quit [Remote host closed the connection]
<Begasus>
haven't investigated further so far other then checking the package content here on 64bit
<jmairboeck>
in short, the new perl_x86 package right now is a full copy of the existing perl package, just for secondaryArch
<Begasus>
binaries located in $binDir? or $prefix/bin
<Begasus>
need to reboot to 32bit to check this out
<jmairboeck>
in $binDir, I didn't remove primary arch perl at all
<Begasus>
nice :)
<Begasus>
so no conflicts there, are breakage
<Begasus>
are/ore*
<jmairboeck>
yes, we now have just 2 different perl versions on x86
<jmairboeck>
for texinfo it is similar, but a bit different: the corresponding primary arch package would be texinfo-6.1 in this case
<Begasus>
yes, as intended by nielx[m]
<jmairboeck>
because it is needed for the Haiku build apparently
<jmairboeck>
ideally, if I understood correctly, we could fix the Haiku build to support gawk_x86 instead, then we could maybe drop texinfo-6.1 and use $prefix/bin for texinfo-7, but that is a different issue :)
<Begasus>
yeah, I'm not touching that :)
<jmairboeck>
it probably involves some massaging of some Jamfiles :)
<nielx[m]>
jmairboeck: what is the problem you are trying to solve? There is nothing preventing you from using or depending on texinfo_x86 on a 32 bit platform
<jmairboeck>
nielx[m]: yes, I am doing that now :)
<nielx[m]>
ok good :-)
<jmairboeck>
a bit of a problem that came up though, that texinfo_x86 also requires a perl_x86
<jmairboeck>
because it is one of 3 packages that uses lib:libperl (now with $secondaryArchSuffix)
<Begasus>
k, so far done at 64bit, reboot to 32bit ...
Begasus has quit [Quit: Vision[]: i've been blurred!]
<jmairboeck>
we didn't have perl_x86 and texinfo_x86 up to now
Begas_VM has joined #haiku
Begasus has joined #haiku
<Begas_VM>
perl_x86 build ok ...
<jmairboeck>
Begas_VM: thanks for checking!
<jmairboeck>
I did build it too yesterday, but didn't really test it, besides using it for building texinfo_x86
<Begas_VM>
jmairboeck, you enabled x86_gcc2 for texinfo, wouldn't that conflict with the 6.* version (needed to build Haiku)?
<Begas_VM>
texinfo_x86 build ok too
<Begas_VM>
don't think we need a primary package on 32bit for version 7.*
<jmairboeck>
yes, sorry, I'll fix that
<Begas_VM>
thanks :)
walkingdisaster has quit [Ping timeout: 480 seconds]
<Begas_VM>
content of perl_x86 looks fine, no conflicts with the primary one
<jmairboeck>
okay, thanks
<Begas_VM>
data files are a bit simular for both packages on texinfo
<jmairboeck>
so, do we need a conflict there?
<Begas_VM>
I don't know, how do they interact with the binaries?
<Begas_VM>
also some *.la files that need removal
<jmairboeck>
I don't know
<Begas_VM>
(seems to be in the primary also), missed those :)
<jmairboeck>
so just "rm *.la" in INSTALL()?
<jmairboeck>
so just "rm $libDir/*.la" in INSTALL()?
<Begas_VM>
yep
<Begas_VM>
lol, there is even a static one in primary :)
<jmairboeck>
I'll let you fix that ;)
<Begas_VM>
yeah, been away from 32bit too long :P
<jmairboeck>
texinfo-6.1 is probably quite old :)
<Begas_VM>
patchset says 2015 ;)
<Begas_VM>
latest entry there 2016
<jmairboeck>
I added a second commit for the cleanup (including a revbump for x86_64)
<Begasus>
yep, saw it
<jmairboeck>
these *.so files are binary perl extensions, it seems (from the XS names), so that is why they need a matching perl
HaikuUser has joined #haiku
<Begas_VM>
Otter crashing, can't upload images atm, but if you are on 32bit you could see simular content in $dataDir for texinfo (primary vs secondary)
HaikuUser has quit []
tqh has quit [Quit: Leaving]
<jmairboeck>
yes, I see that there are mostly the same files there, also for documentation. Should I add a conflict?
<Begasus>
I guess that would be in order, I don't think anything relies on it at runtime, maybe nielx[m] can chime in here too?
<Begasus>
seeing there is also perl specifics in there ...
<jmairboeck>
that's the question: is texinfo a runtime dependency of anything important? (I don't think so, it is a build tool mainly I think)
<Begas_VM>
right
<jmairboeck>
I added the CONFLICTS, like ed, i.e. between REQUIRES and BUILD_REQUIRES, without newline between the former.
<Begasus>
k, will check that later
HaikuUser has joined #haiku
HaikuUser has quit []
walkingdisaster has joined #haiku
walkingdisaster has quit [Read error: No route to host]
<Begas_VM>
jmairboeck, could you speed up the build for lilypond, this seems to take forever ;) ...Making input/regression/out-www/collated-files.texi < tely
<jmairboeck>
you could remove the documentation part, but that would defeat the purpose of this I think ...
<Begas_VM>
nah, will let it finish :)
<jmairboeck>
I didn't test lilypond myself in 32 bit, my VM is not big enough for it
<Begas_VM>
so far no errors (knocks on wood) ...
<jmairboeck>
but yes, it takes a few hours to build, and unfortunately this part can't be parallelzed
<jmairboeck>
last time I tried, it just hung
<Begas_VM>
cpu's still up and runnning, so I guess it's still doing it's thing
<Begas_VM>
avrg cpu usage 20%
<jmairboeck>
you could try that if you want: add the argument CPU_COUNT=$jobs to make doc
<Begas_VM>
jmairboeck, nuked the build, takes too long, but so far build seems ok
<jmairboeck>
okay, then we just need to figure out how to deal with the texinfo conflicts
frkazoid333 has quit [Quit: Leaving]
<Begas_VM>
quick sollution would be to remove the cyclic dependency for install-info
<Begas_VM>
it wasn't there before so should be safe to do so
<jmairboeck>
I think I have a solution, albeit a bit of a hacky one: changing the autoconf package name to texinfo_x86, so that the data files are installed $dataDir/texinfo_x86.
<jmairboeck>
I still have to check if this works though
<Begas_VM>
I'm not sure that is a good solution, $dataDir should be arch independent afaik
<jmairboeck>
that would be a different subdirectory of $dataDir
<jmairboeck>
so that both versions can be installed side by side
<Begas_VM>
that would indeed solve the issue for texinfo
<Begas_VM>
in the case for autocon/automake it would be best to remove dependency for texinto
<jmairboeck>
quick question: when patching Makefiles, is it okay to do it in Makefile.in, or should it be done in Makefile.am and automake be called in the recipe?
<Begasus>
I think Makefile.am should be the one to tackle first (iirc)
<jmairboeck>
ok
Begas_VM has quit [Quit: Vision[]: i've been blurred!]
<jmairboeck>
I need to call autoconf anyway because of patching configure.ac, so changing that to autoreconf would be best I think
<Begasus>
if you can patch it in configure.ac it would be better
<Begasus>
that will pass the things to Makefile.am and configure
<jmairboeck>
two different things need to be changed
<Begasus>
any way, removing the dependency worked on the conflict now, no need to uninstall any of them beside the conflict
<jmairboeck>
one thing statically either in Makefile.am or .in (via the patchset), because they don't use $(pkgdatadir) in 2 places, and the package name in the AC_INIT calls in configure.ac
<jmairboeck>
via the patch function
<jmairboeck>
or do you think I should abandon this if the conflict is okay now?
<Begasus>
I think you already summened korli at the PR about it?
<Begasus>
ah no :)
<jmairboeck>
I didn't see any comment from him yet
<Begasus>
no, I thought you mentioned him in your comment (commented there just now)
<Begasus>
so far only lilypond will need it, and only buildmaster will pick it up
<Begasus>
maybe this will pave the way to use the x86 port for Haiku at one point :)
<Begasus>
biab
Begasus has quit [Quit: Leaving]
ablyss has quit [Ping timeout: 480 seconds]
mmu_man has quit [Ping timeout: 480 seconds]
Begasus has joined #haiku
ablyss has joined #haiku
higen has quit [Quit: Ping timeout (120 seconds)]
higen has joined #haiku
mmu_man has joined #haiku
bbjimmy has joined #haiku
bbjimmy_64 has joined #haiku
frkazoid333 has joined #haiku
zard has quit [Quit: leaving]
<Begasus>
closing down for today
<Begasus>
g'night peeps
Begasus has quit [Quit: Vision[]: i've been blurred!]
jmairboeck has quit [Quit: Konversation terminated!]
HaikuUser has joined #haiku
HaikuUser has quit []
HaikuUser has joined #haiku
HaikuUser has quit []
HaikuUser has joined #haiku
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
HaikuUser has joined #haiku
HaikuUser2 has joined #haiku
<HaikuUser>
Hi. How can I persist the safe gfx mode option so it's always enabled?
HaikuUser3 has joined #haiku
HaikuUser2 has quit [Read error: Connection reset by peer]
HaikuUser has quit [Read error: Connection reset by peer]
HaikuUser3 has quit [Quit: Vision[]: i've been blurred!]
HaikuUser has joined #haiku
HaikuUser has quit []
<waddlesplash>
persisting safe GFX can be done in kernel settings file
<waddlesplash>
~/config/settings/drivers/kernel
<waddlesplash>
iirc
HaikuUser has joined #haiku
HaikuUser has quit []
ablyss has quit [Remote host closed the connection]