<Begasus>
you got a bit more knowlidge on python things :)
<OscarL>
I'll have to take a closer look. In general... I also find that added "_x86" to the patchsets names a bit annoying, but...
<OscarL>
the "big guys" might disagree :-)
<Begasus>
the "big" guys have been silent for a while :)
<Begasus>
if there was/is a real objection I'm sure there was some comments left behind
scanty has quit [Remote host closed the connection]
* OscarL
says, f**k it, and posts a new forum topic.
<Begasus>
oh well, CudaText displays docbook files good enough to read :)
<Begasus>
ow ... lol
* Begasus
heads to the forum ....
<OscarL>
did some more testing earlier today, to see what works and what doesn't, but doubt I'll be able to do much more today (except upload my changes, and try to do some more reading on /bin/mdnsd configuration files)
<Begasus>
He has been around as long as we are OscarL :)
<OscarL>
yep... just saying hello because I haven't talked to him in a while :-)
<Begasus>
jmairboeck, maybe that archPatchSetFileName refers to the architecture used? like it could get _riscv64 or the likes, but maybe it's only used with a secondary arch patchset?
<jmairboeck>
no idea actually, I haven't really looked at the code of haikuporter much
<Begasus>
same here, I leave that to the experts, but I can check the outcome
<Begasus>
checking now without the change for archPatchSetFileName
<Begasus>
still good
<Begasus>
reverse check
<jmairboeck>
there are some recipes which use architecture specific patchsets, IIRC (mostly gcc2 stuff I think), but I think they are added with explicit ifs in the recipe. Maybe this was intended to support these directly in haikuporter?
<Begasus>
would have to check the logs when they were inserted then
<OscarL>
Python used to have an _x86 specific one that I removed, in favor of doing the "if 32bits" check on the .py sources instead :-P
<Begasus>
I got those _x86 or _gcc.patchset files in the past also, specificly for those, but when running 'hp -e" they are joined into the base patchset
<Begasus>
ok, with archPatchSetFileName set to baseName it still produces a _x86 patchset
<Begasus>
so right on that jmairboeck, shouldn't be in there
<Begasus>
well, as long as we're not sure why it's used
<OscarL>
just to warn about the presence of platform specific patches. So... I think I think jmairboeck was right, and it should remain using "self.name".
<Begasus>
+1 ... we all agree on this then :)
<Begasus>
OscarL, could you add your 2 cents to that PR? :)
<OscarL>
I'm out of pocket change :-P
<OscarL>
will re-read, just in case, and add a comment.
<Begasus>
added my findings
<Begasus>
edited a few times so it should be clear now :)
<jmairboeck>
+1 Begasus
<Begasus>
this is at least something I can read and understand :D
<OscarL>
done.
<Begasus>
went over the other PR's, quite some got conflicts (looks at kallisti5[m]) :)
<Begasus>
thanks OscarL and jmairboeck!
<Begasus>
one more check
<Begasus>
now I have a "name" and a "baseName" patchset in there ...
<Begasus>
like a foo.patchset and foo_x86.patchset ... let's see if hp now errors
<Begasus>
still good, let's see if I can apply foo_x86.patshet in the recipe :)
<Begasus>
well ... foo$secondaryArchSuffix.patchset ...
<OscarL>
Begasus: it should print "arch-specific patchset file %s requires manual update" when using "hp -e", if you have an _x86 patchset in there.
<OscarL>
as in... 'arch-specific patchset file foo_x86.patchset requires manual update'
<Begasus>
was trying to do "hp -c" "hp -b" with both patchsets around
<Begasus>
k, the "hp -b" with "foo$secondaryArchSuffix.patchset" didn't work
<Begasus>
let's try this now with both in and do a "hp -e"
<Begasus>
if I understand you correctly it should print that message then OscarL?
<OscarL>
yes, if a "foo_x86.patchset" exists, and you attempt to extract "foo.patchset"
<Begasus>
no message, it just re-produces the _x86 patchset
<OscarL>
"hp -b" should only apply the patches defined in PATCHES (say: foo.patchset), regardless if foo.patchset and foo_x86.patchset exist
<Begasus>
yes it does that
<OscarL>
k, wasn't sure as you said "didn't work" :-)
<Begasus>
entering "foo$secondaryArchSuffix.patchset" in PATCHES didn't work :)
<OscarL>
mmm, that might be problematic, due to existing _x86.patchsets.
<Begasus_32>
Error: Error: Patch file chessx-1.5.0.patchset is not referenced in PATCHES, so it will not be used
<Begasus_32>
Error: No version of chessx_x86 can be built
<Begasus>
moved it out, but still with that message
<OscarL>
haikuporter does some crazy caching, and sometimes old stuff keeps getting in the way.
<Begasus>
maybe PATCHES isn't aware of $secondaryArchSuffix?
<Begasus>
I know, been there ;)
<Begasus>
mostly small change in the recipe refreshes that
<OscarL>
No idea, we'll need to test things locally (and it won't happen today :-D)
<jmairboeck>
it could be that PATCHES is indeed evaluated when $secondaryArchSuffix isn't set (yet)
<Begasus>
np, at least we got some understanding here
<jmairboeck>
That comment contains what would be done conceptually, i.e. put the output of createSubpackageInfos.pl there, but this doesn't work, so the pre-generated version is included instead.
<jmairboeck>
"source" (or ".") is a shell command which includes the contents of a file as if that content where directly there instead, like #include in C or C++
<jmairboeck>
the package infos for the subpackages (as well as the packageEntries below) are generated, because they would be very long otherwise, especially with the "tex:" provides
<Begasus>
it's a good thing we got you around for that :D
<Begasus>
[4288/5288] Building CXX object tools/...Files/llvm-readobj.dir/ELFDumper.cpp.o (getting close at buildmaster) :)
<OscarL>
We should really avoid having files under /system/settings/ that include "package paths" (as in: "/packages/bash_completion-2.11-2/.self/...").
<OscarL>
if you use "keep-old" as policy for GLOBAL_WRITTABLE files... the above file will point to the wrong version when you update the package.
<OscarL>
and the "auto-merge" keeps failing on me quite regularly...
<OscarL>
ended up (again) with broken bash_completion due to that :-D
<jmairboeck>
the current version is 5.40, we currently have 5.32.1
xet7 has quit [Remote host closed the connection]
xet7 has joined #haiku
nosycat has joined #haiku
Begasus_32 has quit [Quit: Vision[]: Gone to the dogs!]
<Begasus>
closing down here, cu later (maybe) :)
Begasus has quit [Quit: Vision[]: i've been blurred!]
_-Caleb-_ has left #haiku [#haiku]
_-Caleb-_ has joined #haiku
Begasus has joined #haiku
<Begasus>
ah OscarL, maybe I could try out this thing you are doing with kdnssd6 :)
<Begasus>
Either Avahi or DNSSD is required for KDE applications to make use of multicast DNS/DNS-SD service discovery :)
<OscarL>
seems to cover the dns-sd part of the equation (service discovery). I guess that having mDNSResponder on Haiku will allow to test that KDE code at least.
<OscarL>
(by using, say /bin/mDNSResponder to setup a test service for kdnssd6 to discover)
<OscarL>
either that... or you'll need to check against some linux install :-)
<Begasus>
would have to boot the Neon install then :) (but not today)
HaikuUser has joined #haiku
HaikuUser is now known as Neural
<Neural>
Is there a way to share e folder between a Linux host and Haiku running on qemu/kvm?
<Begasus>
nextcloud?
<Begasus>
gerbera?
<Begasus>
just the 2 that come to mind
<augiedoggie_>
sshfs
<nosycat>
Locally, you can use Midnight Commander to make a SSH connection to your host system.
<OscarL>
midnight commander (mc) also can use "shell link".
* OscarL
was too late :-D
Neural has quit [Quit: Vision[]: i've been blurred!]
<Begasus>
or those ...
<Begasus>
someone scared him :P
<nosycat>
Oops.
<OscarL>
might have missread sshfs for... stfu ? :-)
<Begasus>
lol
<nosycat>
I hope not!
_-Caleb-_ has left #haiku [#haiku]
<jmairboeck>
regarding sdl_perl_x86: I still don't understand what happens. The second XS_handshake check (https://github.com/Perl/perl5/blob/maint-5.32/util.c#L5430) fails and I don't know why. With Compress::Bzip2 it seems to work just fine though. What is different with SDL?
<OscarL>
mmm, loadable modules/dlls can be pain in the rear... still remember that RTLD_LAZY vs RTLD_NOW on CudaText driving me crazy.
erysdren has joined #haiku
<jmairboeck>
on 64 bit it does work too
<Begasus>
rings a bell :)
arti_ has quit []
arti has joined #haiku
<jmairboeck>
it does load the correct libSDL.so (checked with strace), but that isn't the problem, it seems
<jmairboeck>
if our version of perl had this change already: https://github.com/Perl/perl5/pull/19111, it would have been a bit easier to debug ... I've hacked in something similar to check which one of the checks is failing.
<Begasus>
time flies OscarL! :D
<Begasus>
been keeping up now and then on it, even get notices from upstream for important updates :)
<scantysnax>
good morning.
<nosycat>
Hello!
<OscarL>
hey there scantysnax.
<Begasus>
Hi there scantysnax! brought some goodies? ;)
<scantysnax>
hi OscarL, I haven't seen you in a while. Are you OK?
<scantysnax>
Begasus, no goodies today, sorry :-(
<scantysnax>
my BNC seems broken.
<OscarL>
scantysnax: getting better (for now at least), thanks for asking :-)
<scantysnax>
OscarL, glad to hear you are feeling better.
<Begasus>
almost as good as before :) (not saying new) :P
<scantysnax>
Begasus that's good. what are you working on now?
<Begasus>
finishing up on the kde framework update
<scantysnax>
cool. i tried kmail again, still same problem.
<Begasus>
no idea what's going on there
<Begasus>
good thing I didn't push anything for that :)
<scantysnax>
me neither, i can't get anything out of terminal, it segfaults before anything is printed.
<scantysnax>
seems to work in a nightly, but i'm not going to do any upgrades to this install until beta5
<scantysnax>
which will hopefully be soon.
<scantysnax>
iirc, there's only one blocker. but don't quote me on that ^_^
<Begasus>
openssl3 is still an issue I think
<Begasus>
but not sure it's a blocker
<scantysnax>
oh, i didn't know that.
<scantysnax>
i'm thinking of moving to nightlies, but i'm afraid of things breaking, and being dropped to KDL beforei can do anything.
<scantysnax>
i was also told that if i was developing something, i should do it on b4
<scantysnax>
so i guess my hands are tied.
<Begasus>
did some checking, some issues related to our current version I think
<Begasus>
it's specificly handy when working on recipes/packaging for haikuports
<scantysnax>
i remember see a blocker with gcc on 32-bit with exception handling.
<scantysnax>
desktop links to html files aren't working properly in falkon, but what i have going on now is satisfactory for now.
<scantysnax>
thanks!
<OscarL>
scantysnax: np! double check their filetype. if still fail, maybe it is mishandling symlinks, and you should report it on HaikuPorts, or on 3dEyes' repos
<scantysnax>
ok
<scantysnax>
have to work on some video code for my emulator, but keep putting it off.
<scantysnax>
going to drop support for 8/15/16 colour depths to simplify things a bit. I don't think anyone is *not* using a 32-bit desktop, so it's not really a big deal
<OscarL>
jmairboeck: just curious (after reading your last link to that perl PR)... are you having problems with a newer build of sdl_perl_x86, or with the one Begasus added 9 months ago?
xet7 has quit [Quit: Leaving]
<jmairboeck>
it is still the same version
<OscarL>
sorry, I meant to ask if it is a build against the newer perl, or just the old package the one with problems.
<jmairboeck>
on x86 it has never worked, I think
xet7 has joined #haiku
<jmairboeck>
after the perl changes
<jmairboeck>
I rebased the branch
<OscarL>
I see. Welp... no idea then, sorry :-/
<jmairboeck>
in fact, last week I pushed a bunsh of commits for all the dependencies that don't cause problems, so the sdl_perl PR only contains the changes for alien_sdl and sdl_perl itself now
<jmairboeck>
I am thinking whether a "threaded" build of perl would help, because there the XS handshake checks are different
<jmairboeck>
but threaded and unthreaded builds are ABI incompatible, so that would require a rebuild of all perl packages which use binary parts (including texinfo-7)
<jmairboeck>
and a few others
<OscarL>
scantysnax: makes sense... hate the 15/16 bit usual color-banding. Although... I remember fondly using BeOS with different color-depths on each workspace. 256 colors was actually quite good looking still :-)
* OscarL
nods pretending he understood more than 50% of jmairboeck comments.
<OscarL>
it is all a house of cards... pretty amazing most software works as "well" as it does, at the end of the day :-)
<scantysnax>
indeed. plus it's less code to worry about and have to maintain.
<scantysnax>
the video code i have now actually has been working since BeOS R5 in the early 2000's. I hardly had to change anything to get it to work on haiku
<scantysnax>
but like i said, it's kind of bloated now.
<scantysnax>
going to keep the BDirectWindow, and mostly throw away the BBitmap code, except for the Overlay, when we finally get hardware video.
<OscarL>
scantysnax: if by "throw away" you mean "git rm"... that's fine. You never know when you (or someone else) goes too deep doing "source code spelunking" :-)
* OscarL
can't English properly... oh well.
<scantysnax>
no, just working on trimming down the actual code, not removing it from the tree itself.
<OscarL>
+1
<scantysnax>
sources, rather
<nosycat>
Lately a lot of people are rediscovering the value of stable old languages and APIs.
<OscarL>
(just in case, I meant: "as long as the code remains in git/hg/whatever...". Always good to be able to dig things up if needed.)
<OscarL>
nosycat: what? don't you love microsoft using a different GUI framework every few years? :-P
<scantysnax>
we have a git repo
<OscarL>
(meanwhile the devs that stuck with Win32... still laughing :-D)
<nosycat>
No, I "love" Linux doing that with Gtk. :P
<Anarchos>
thanks OscarL
<nosycat>
While FLTK apps from 1999 probably still compile.
<OscarL>
Anarchos: seems "councourse" (the thing generating the nightly images) got stuck, so better avoid updating further than hrev57755
<OscarL>
*concourse
<OscarL>
speaking of stable apis (and abis)... wish more Python extensions targeted the "limited API" (aka "abi3"), instead of forcing you to recompile for each version..
<nosycat>
Python extension developers are something else.
<nosycat>
I remember when Python 3.10 came out. There was this GitHub project that already required it, like a couple of days after the official release.
<nosycat>
Like, when did you have time to use the new features.
Anarchos has quit [Quit: Vision[]: i've been blurred!]
erysdren has quit [Quit: Konversation terminated!]
<OscarL>
speaking of the devil... Python 3.13.0b2 released 10 days ago... I should check if my beta1 patches still apply :-)
<OscarL>
(for 3.12.0, I also was doing regular updates to the patches... much smoother experience than my jump from 3.10 to 3.11 :-D)
<nosycat>
They don't make it easy, I hear.
<OscarL>
Worse part is having to deal with packages for multiple versions... many with sometimes conflicting dependencies, even on "mainstream" OSes, let alone on Haiku.
<OscarL>
removal of lib2to3 on 3.13 will be "fun".
<nosycat>
Good luck.
<nosycat>
That's why I'm always on the lookout for alternatives to popular languages.
<nosycat>
Or anything else.
<OscarL>
wish nim used 4-spaces for its coding style instead of 2. I'd probably be doing more reading on that then.
<nosycat>
Meh, wish it allowed tabs like any other language.
<Habbie>
a user reports that 57755 on an AMD Athlon II is stable
<Habbie>
sadly 57754 was not stable for me
<OscarL>
Habbie: isn't the issue with AMD CPUs *after* K10 the ones with issues on Haiku? I had zero issues with any Athlon II or Phenom II (not at least related to the CPU :-D)