<PulkoMandy>
waddlesplash, zdykstra: one quirk of translators is their config view may be used in both layout and non-layout windows, be sure to check both cases (probably by testing then in a beos app?)
<OscarL>
Begasus: just got another smiley from korli. Think he's getting softer :-P
<Begasus>
running Haiku on 2 laptops atm, so no more fuzz with the password, thanks!
<OscarL>
Mmm, we have a recipe for mesa 7.9.2, that reads: ARCHITECTURES="x86_gcc2 !x86" and.... SECONDARY_ARCHITECTURES="?x86_gcc2" 8-/
freddietilley has quit [Quit: WeeChat 3.8]
<OscarL>
(and using python2, of course)
<Begasus>
heh
<OscarL>
guess I'll stick to things under dev-python for at least today.
Diver has joined #haiku
<Begasus>
probably kept for compatibility?
<OscarL>
Not sure how useful that would be today, but... not really up-to-speed with Haiku's needs/interactions with Mesa, so... task for people that knows better.
freddietilley has joined #haiku
<OscarL>
oh, good. nothing depends on pychart... will work on that one then :-D
<Begasus>
yeah, some things are better left alone :)
<OscarL>
my cunning plan is to slowly remove the rest of 3.7 (and 2.7), so in the end... those old stuff are either forced to switch to at least 3.9, or have to be dropped :-D
<Begasus>
right, like I did for boost :)
<Begasus>
well, did quite some work on removing python2.7 back then too :)
<OscarL>
lots of work required to remove that one, indeed.
<Begasus>
now focus on the static ones (only few side tracks allowed) :P
<OscarL>
Mmm from PyChart's docs: "compiling python.tex requires..." yeah..... no thank you!
<OscarL>
mime sniffing rules for html seems a bit wacky. it marked a .py as html because it contains a string (at line 28) that reads: index_fp.write("<head><title>pychart Samples</title></head><body>\n")
<Begas_VM>
lol
freddietilley has quit [Quit: WeeChat 3.8]
<OscarL>
pychart recipe buids for 3.9/3.10, but it is too ancient to run on those versions. Last release from 2009, nothing uses it in-tree.
<OscarL>
I think that's a goner.
<Begas_VM>
another one nuked! ;)
<OscarL>
Too bad, looked like a cool project/lib... but I'm not going to patch it myself to make it work :-/
diver1 has joined #haiku
Diver is now known as Guest9371
diver1 is now known as Diver
<OscarL>
(porting it to 3.x, I mean). I think nobody actually tried to run it on 3.x when updating recipes :-)
<Begasus>
OscarL, jumping over dev-python, caught up with you! ;)
<OscarL>
ouch! :-P
pvalue has joined #haiku
pvalue has quit []
<Begas_VM>
ok, seems like libsolv needs a change in one of the older recipes to rebuild :)
AlaskanEmily has quit [Remote host closed the connection]
<PulkoMandy>
trungnt2910[m]: no, we release the buildtools repository, but use as a generic cross compiler is "some assembly required". Which is what the Docker does
<PulkoMandy>
You can maybe use the dockerfile as installation instructions to do it manually?
<PulkoMandy>
Yes, you can't just run ./configure-make-make install. It needs header files from Haiku repository and I think some setup of PATH and other environment variables
<trungnt2910[m]>
The problem here is I don't think organizations like .NET would accept unofficial builds.
<PulkoMandy>
They want to work with binaries instead of sources? Seems strange to me. In any case, we don't have any signing process or anything, so, what would make it official?
<trungnt2910[m]>
PulkoMandy: Building the cross tools is slow.
<trungnt2910[m]>
PulkoMandy: I guess being downloaded from a GitHub/whatever account controlled by Haiku and/or from *.haiku-os.org
<PulkoMandy>
Personally I prefer "slow" over "someone else built these binaries, I don't know how, if it breaks I can't fix it". But maybe other people have different priorities
<trungnt2910[m]>
PulkoMandy: Currently the cross-compilation environment setup script is building Haiku _and_ its cross tools from source.
<PulkoMandy>
Ok, so we just have to fork your repo or you transfer it to the haiku organization or maybe haikuarchives, if that makes them happy I don't think there's a problem with it
<trungnt2910[m]>
trungnt2910[m]: We can instead just fetch a bunch of hpkg files and the cross tools.
<PulkoMandy>
Yes. If you have something that works, I think we can make it the official thing
<trungnt2910[m]>
PulkoMandy: I'm just asking for now, when the problem actually comes I'll address it.
<botifico>
[haikuports/haikuports] Begasus b926ddf - libsolv, revbump for rebuild (#8188)
<OscarL>
I don't think anyone really tested the jsonrpcclient package. It is missing several dependencies. Lets see how long this takes.
<OscarL>
Same thing with jsonschema.
<Begas_VM>
You'll probably find some more
diver1 has joined #haiku
Diver is now known as Guest9377
diver1 is now known as Diver
<OscarL>
At least these one actually list some requirements on their setup.{cfg,py} files, albeit you can't always trust those either :-D
<OscarL>
(testing what's really needed is a bit time consuming, but... oh well)
DKnoto has joined #haiku
<OscarL>
For example, jsonschema listed six as runtime requirement. It doesn't actually needs it.
<OscarL>
(not at least for newer Pythons)
<OscarL>
Well, scratch that. It does use it :-D
<Begasus>
that's what testing is about, some builds here weren't needed because no static libraries were even installed, can't always tell that without building :)
Guest9377 has quit [Ping timeout: 480 seconds]
matt1 has joined #haiku
<OscarL>
(or installing, or runing the programs, or actually hitting a specific path of a program, in case of Python)
<matt1>
do you like pascal ?
<OscarL>
I used to do Delphi around the early 2000s. Used to like it quite a lot, still love that RAD, but find ObjectPascal too verbose after using Python for many years.
<OscarL>
good day to you, btw, matt1. Hope you're having a good day, health wise.
<matt1>
thank you OscarL very much, thanks ...
<matt1>
i hope you all are ok ...
<OscarL>
Today is not a terrible day, so... all good :-D
DKnoto has quit [Ping timeout: 480 seconds]
<matt1>
:)
HaikuUser has joined #haiku
<Begasus>
'lo matt1
<matt1>
hello Begasus
HaikuUser has quit []
<matt1>
Begasus : do you prefer cheers in basic or pascal ? a game ... ;)
<OscarL>
regarding pascal... I remember oco's and Baldur's efforts on BePascal/BeFPC (original project by memson). I helped a bit doing some Pascal bindings for some classes, but then... life happened :-/
<Begas_VM>
wasn't done in dev-lua ;)
<matt1>
ok OscarL , i also dream about pascal but too much with beos api ...
<matt1>
i apologize : too much
<Begas_VM>
there is Lazarus that you can build with ...
<Begas_VM>
name drops me ...
<Begas_VM>
fpcupdeluxe ;)
<matt1>
already done, Begas_VM
<Begas_VM>
I know matt1 :)
DKnoto has joined #haiku
<OscarL>
k, PR open for jsonschema. Let's go back to JSON-RPC-client.
xet7 has quit [Quit: Leaving]
jason123santa has joined #haiku
matt1 has left #haiku [#haiku]
solitudi has joined #haiku
<x512[m]>
PulkoMandy: Why avoid Trak keywords?
<Begas_VM>
k, closing down on toluapp, should be good
<OscarL>
so.... silly noob question Begasus... how do create symlinks from the recipe ("ln -s") so $binDir/script points to $binDir/script3.9... was doing just that: "ln -s $binDir/script3.9 $binDir/script", but after installation, the symlink is broken, as it points to /packages/[....]/script3.9
<Habbie>
ln -s $binDir/script3.9 script
<OscarL>
I now tried using "cd $binDir" before doing the "ln -s", that seems to work.... but I was wondering if ther's a better way.
<Habbie>
oops
<Habbie>
ln -s script $binDir/script3.9
<Habbie>
ln -s script3.9 $binDir/script
<Habbie>
third time's the charm
jason123santa has left #haiku [#haiku]
<Habbie>
the trick is leaving out $binDir on the target, so that eventually, it is just resolved inside the same dir
<OscarL>
ahhh! thanks Habbie! Sometimes (most of the time) I get lost in the silliest of things :-)
<Habbie>
hehe
freddietilley has quit [Quit: WeeChat 3.8]
<Habbie>
also, i did this last week for the vis recipe, to make a vi symlink (but i removed it again)
solitudi has quit [Quit: Page closed]
<PulkoMandy>
x512[m]: we can use them if we need them (to tag tickets for queries for example), but copying randow words from the description is not helpful
Kokito has joined #haiku
Kokito has quit []
<Habbie>
OscarL, so like your version with cd i guess, except it turns out you don't need cd :)
<OscarL>
yeah... I *knew* there should be a better way :-)
<OscarL>
matt1: most of the people in this channel alreay knows how to do VMs, so I guess we're not the right audience for a ready-made vm image.
zard has joined #haiku
<OscarL>
and "haiku" is just a form of poetry (originally from Japan), in the same way sonnetos are a form of poetry originally from Italy. Nothing "evil" about either :-)
<OscarL>
We had this conversation already a few months back :-D
<nekobot>
[haiku/haiku] e37168ad4f9c - kits/app: fix unaligned copy in BMessage
<Begasus>
added a note to summon 3dEyes in the issue OscarL
<Begasus>
skipping them for now
<OscarL>
+1
freddietilley has quit [Quit: WeeChat 3.8]
nosycat has joined #haiku
<OscarL>
I'm not sure pyrsistent was actually ever tested either.
<OscarL>
The recipe is marked as "any", but the sources include a ".c" python module extension (that the recipe does not compiles nor installs) :-/
<OscarL>
(unless that's somehow optional)... let's try to run its tests.
<OscarL>
Well, the test attempt to run, gives a warning about the missing compiled extension, module will still work, but less performant.... and then the tests crash :-(
<Begasus>
robxnano[m], does libmatroska produce a static library?
<Begasus>
try to build it with the extension OscarL :)
<OscarL>
did already, needs a "setarch x86" first.
<Begasus>
yep
<Begasus>
thought so ;)
<OscarL>
test crash in the same spot.
<Begasus>
nothing at repology?
<OscarL>
I think this thing is too old for Python 3.10
<Begasus>
heh
BrunoSpr has joined #haiku
BrunoSpr has quit []
<OscarL>
jsonrpserver needs jsonschema (not mentioned in the recipe). jsonchema needs pyrisistent (but didn't had it in the REQUIRES). Added python 3.10 to the first two, only to find out that pyrsistent didn't provided _python310 :-(
<OscarL>
This is a mess :-D
<OscarL>
and nobody uses jsonrpcserver, apparently.
<nosycat>
This is Python.
B2IA has quit [Quit: Vision[]: i've been blurred!]
<Begasus>
told you it was a mess ;)
<OscarL>
I'm still not entirely convinced we should pack so much python packages. I would do: main Python + pip/setuptools/wheels, and let the user use pip as they please.
<Begasus>
they still can :)
KapiX has quit [Quit: KapiX]
<OscarL>
(while also providing packages for modules that need patching/platform support, of course)
BrunoSpr has joined #haiku
<bbjimmy>
The kernel thread "fbsd callout" is pegging one of my four processors acording to ProcessController.
<waddlesplash>
probably because I messed something up in my change yesterday
<waddlesplash>
what network device do yo uhave?
<bbjimmy>
ippro 1000
<waddlesplash>
hmm, I tested with that in a VM, no problems here...
<nekobot>
[haiku/haiku] 2393d22cdbf7 - kernel/util: Add static assert that the two list links are the same size.
<nekobot>
[haiku/haiku] ff6e777d2863 - kernel/util: Clear list links on removal under KDEBUG.
<OscarL>
we don't have pandoc in the repos, yet there's a pypandoc (thin wrapper) :-/
<OscarL>
Seems it was added for gertty, originally, but now gertty recipe doesn't requires it. /me is considering "git rm"
<waddlesplash>
or just disable till we have pandoc
<waddlesplash>
I think we had a partially working GHC at one point...
mmu_man has quit [Ping timeout: 480 seconds]
<OscarL>
k. Will do minor clean up, and just disable.
BrunoSpr has quit [Quit: Vision[]: Ich wurde verwaschen!]
tqh has joined #haiku
mmu_man has joined #haiku
<OscarL>
why do we keep 37 different recipes for rust?
<OscarL>
all the <1.50 ones require cmd:python (2.7)
mbrumbel_ has joined #haiku
<OscarL>
gah! BeCJK also wants cmd:python (for its use of the SCons build system). I have, somewhere, a version that uses the makefile-engine instead. Using anything else for BeCJK seems way overkill for me.
mbrumbel_ has quit []
<OscarL>
(with the possible exception of using the jamfile-engine, of course :-P)
<nekobot>
[haiku/haiku] 11e68e0c546e - apps/haiku3d: Swap then unlock to fix rendering on glvnd
gouchi has joined #haiku
<OscarL>
"waddleannoyed" LMAO
<Begasus>
going down, g'night peeps
Begasus has quit [Quit: Leaving]
<jessicah>
OscarL: huh, the example doesn't strictly reproduce in putty
<OscarL>
:-(
<jessicah>
whole row is red seems wrong
<jessicah>
you immediately reset to defaults after "whole row is red"
<jessicah>
haiku & putty agree for the second line, which I also agree with; there's no background colour after "Whole row is red" set
<jessicah>
it's just the first line that seems erroneous
<OscarL>
I've no idea really. I just saw that ticket, remembered a weird redrawing issue in "ne", and I thought they might be related.
DKnoto has quit [Quit: Leaving]
<waddlesplash>
zdykstra: bbjimmy: I managed to confirm the problem is caught by the list assertions I added earlier today; and also it seems the refactors I did also earlier may fix or at least mitigate the problem
<waddlesplash>
I have one more fix I'm going to make later, and then I'll leave it to nightlies testing
tqh has quit [Quit: Leaving]
<waddlesplash>
hopefully it will KDL instead of hanging and that will be useful enough that the real cause can be fixed, if I didn't get it already
<bbjimmy>
ok
<waddlesplash>
also note the list KDLs may catch other latent issues like this one lurking around the tree
<waddlesplash>
there are some long standing tickets that I wouldn't be surprised if this uncovers the root cause of those too
<bbjimmy>
Thanks waddlesplash
<waddlesplash>
:)
<waddlesplash>
it is definitely intermittent. in 3 hours I have triggered it 3 times, completely randomly each time
<waddlesplash>
the first 2 was the hang before the assertions, then I switched to the new build and couldn't reproduce at all, then I reverted that last commit I made earlier, and reproduced within minutes
<waddlesplash>
oops, it just happened again actually!
<zdykstra>
I triggered it that once and then never again. I tried generating load + network traffic via speedtest.net, turning off most of my CPU cores, etc.
<waddlesplash>
so, I've got a consistent trigger now
gouchi has quit [Remote host closed the connection]
<pairisto[m]>
I am having some trouble with getting the tun.cpp file to start on Haiku since most VPN applications need to talk to a system TUN driver. I compiled it using jam -jN tun and it is now in .../generated/objects/haiku/x86_64/release/add-ons/kernel/network/devices/tun but I do not know where to go from there to start it for it to show up in ifconfig. Though I also do not know if it is best to start with tun.cpp since it seems to be a
<pairisto[m]>
module rather than a driver so any input on that would also be appreciated.
<PulkoMandy>
No one knows, I think?
<PulkoMandy>
I think a module makes sense because it's not really a driver (there is no related hardware)
<PulkoMandy>
The closest thing we have is the localhost interface, did you look at how that's done? I think it hublishes a device in /dev/net? So that gives you an idea how to do it
<pairisto[m]>
yeah, it is classified as a virtual driver so I want to take more inspiration from the loopback driver code since loopback is also a virtual driver
<PulkoMandy>
You can find it somewhere in build/jam (cd build/jam : git grep localhost) to see how it's added to haiku.hpkg and add tun in a similar way?
<x512[m]>
Some my illustration about device manager node tree.
<pairisto[m]>
is it a module? is doesn't seem to have module_info or device_module_info and some other module stuff defined in the documentation?
<OscarL>
pairisto[m]: that file is only part of it... you have to see its directory, where there's also a ps2_module.cpp file (and a Jamfile for them all)
FreeFull has joined #haiku
<pairisto[m]>
@x512 So how do you get
<PulkoMandy>
There are two parts: devfs_publish_device is what you need to publish a device in /dev
<pairisto[m]>
x512: what do I do to make the device publish? would it have to be through the Jam file with the KernelAddon section?
<pairisto[m]>
along with a publish device section*
<PulkoMandy>
The other part is getting your module loaded by the kernel, drivers are one special case of this, there are two types, "old" drivers are loaded usind symlinks in a specific directory and "new" drivers are loaded by the config_manager
<PulkoMandy>
But I don't know if the tun module has to be a driver, since it isn't attached to any specific hardware
<x512[m]>
ps2 seems not use proper device manager architecture.
<pairisto[m]>
* along with a publish device section in the code*
<PulkoMandy>
No, ps2 does not use device manager (yet?)
<pairisto[m]>
but wouldn't it still need to be put under /dev/net?
<PulkoMandy>
you cun publish devices using devfs_publish_devices, under /dev/net if you want/need to
<PulkoMandy>
That's unrelated to being a driver or not
<pairisto[m]>
okay, I'm slightly going off of the Linux reasoning behind it being a driver like the Universal TUN/TAP Driver
xet7 has quit [Ping timeout: 480 seconds]
<PulkoMandy>
However, the config_manager can load your module automatically when some app acgesses /dev/net, so that can be useful
<PulkoMandy>
Linux doesn't usually use a devfs like ours, so the model is a bit different on that part of things
<pairisto[m]>
agreed and I am trying to take that into account, its a bit harder since there is no modprobe
<PulkoMandy>
On Linux, udev will do the work of creating device nodes in /dev, and "link" them with the corresponding devices using major and minor device numbers. Haiku does not work like that
<pairisto[m]>
or mknod
<PulkoMandy>
Yes, it works the other way around. When an app opens /dev/net, that triggers events in the kernel (through devfs) which end up loading the corresponding drivers (either through device_manager or the old style symlinks)
<x512[m]>
pairisto: Haiku have no mknod and device major/minor codes.
<pairisto[m]>
that I know
<pairisto[m]>
its just having those tools in linux makes the driver development easier but the underlying base of how a driver is loaded is much different
<pairisto[m]>
PulkoMandy: when you say "corresponding drivers" how does device manager know what to load
vdamewood has quit [Remote host closed the connection]