<BiPolar>
I'm doing some touch ups to the recipe... it is a PITA to have to way 13 minutes for each build (I keep making silly mistakes on the recipe :-( )
<Begasus>
OK, give me a yell if you got something to check ;)
<BiPolar>
will do!
Begas_VM has joined #haiku
<BiPolar>
So... Web+ just pegs one core to 100% on Github for everyone, or just for me?
<Begasus_32>
err, the libs are already installed in the python package
<BiPolar>
welp, I removed the "lib" from the unicorn package, and now I can't import it anymore :-D
<BiPolar>
I think this will require patching unicorn.py
<BiPolar>
bah... just adding .2 to _uc = _load_lib(_path, _lib.get(sys.platform, "libunicorn.so"))" makes it load the one installed by the system package :-D
<Begas_VM>
+1
<BiPolar>
so "_path" is correct... we're just missing the "libunicorn.so" symlink to libunicorn.so.2... or just rename the god damned thing :-D
<BiPolar>
(and also make sure they don't get included in the python package)
<BiPolar>
I've just manually removed "unicorn-2.0.1-1-x86_64.hpkg" from /system/packages, and hit "Cancel" when asked about uninstalling unicorn_python39-2.0.1-1-x86_64.hpkg
<Begasus>
tried that yesterday too (also used "haiku" there) ;) (instead of haiku1) +1
<BiPolar>
still can "import unicorn"
<BiPolar>
so we might want to drop the "lib:libunicorn$secondaryArchSuffix" and "unicorn$secondaryArchSuffix" for the python package?
<BiPolar>
(the .so on the python one seems to be statically linked to the other one... that's why it's bigger :-D)
<BiPolar>
"<Begasus> lol, 'haiku1': 'libunicorn.so.2'" <<< hey! don't laugh at my mighty one-liners! :-P
<Begasus>
I'm laughing at myself :)
<Begasus>
added the +1 for you ;)
<BiPolar>
damn 1 and the end.. got me good.
<Begasus>
how's that?
<BiPolar>
I also forgot to add it first, and had to rebuild it AGAIN :-(
<Begasus>
k, now I have to grab your changes and check again here :)
<Begas_VM>
first need to check on something else
<Begas_VM>
I'm doing stupid things sometimes too :P
<jmairboeck>
I'm now trying to build texlive_core against ICU 70. Apparently getting that to work (not requiring icu66_devel) was not too hard. Besides enabling icu70, the only package that I needed to actually rebuild against icu70 is libxml2. What do you think, could this be done?
<jmairboeck>
I decided against using the ICU that comes bundled with texlive, because I suppose I would need to patch that also, just as the standalone ICU package
* BiPolar
runs "inrecipe libxml2"...
<BiPolar>
ouch.
<Begas_VM>
heh
<jmairboeck>
uninstalling icu66_devel did uninstall a few others, but they could all be reinstalled again after installing the rebuilt libxml2_devel
<Begas_VM>
probably will get a boost effect :) (nothing provides icu* for *) :)
<jmairboeck>
I also added a CONFLICTS_devel="icu66${secondaryArchSuffix}_devel" to icu70. I think it would make sense that the devel packages conflict. Should I create an issue for that?
white-wolf has quit [Remote host closed the connection]
<jmairboeck>
I tried rebuilding all the packages that were uninstalled together with icu66_devel, but cairo fails to build (missing gtkdocize). Could someone check this?
<Begas_VM>
gtkdocize is used to build documentation, adding it to BUILD_PREREQUIRES should fix it?
<jmairboeck>
ok, maybe I'll try again later
<BiPolar>
cmd:gtkdocize
<jmairboeck>
(texlive is currently building)
<Begas_VM>
ah, unicorn is still building here
<BiPolar>
from "gtk_doc"
<Begas_VM>
BiPolar, does it seem like unicorn is build twice there too?
<Begas_VM>
-- Build files have been written to: /sources/unicorn-2.0.1.post1/build_python
<Begas_VM>
and then it starts again
<jmairboeck>
"-- Build files have been written to ..." looks like cmake to me
<Begas_VM>
yep, is is
<Begas_VM>
it is*
<BiPolar>
Begas_VM: the "python setup.py build" is calling:
<Begas_VM>
guess I'll have to re-format that partition :/
<Begas_VM>
-DUNICORN_BUILD_TESTS=OFF
<BiPolar>
thanks!
<Begas_VM>
adding "-L" to the cmake option should tell you what you can use :)
* BiPolar
learns things.
<Begas_VM>
or read the cmake file :)
<Begas_VM>
it's a bit like "./configure --help"
<BiPolar>
that one I'm more familiar with, at least :-D
<Begas_VM>
for meson there isn't an option (that I know of), so you need to read the meson.build file to find them
<Begas_VM>
k, skipped the second build now (disabling the tests didn't do much)
<Begas_VM>
needs to strip the library in the python package too I guess :)
<Begasus>
guess it's time for backups ...
<BiPolar>
real 8m3.514s instead of almost 14m. on my PC.
<Begas_VM>
that pretty fast :)
<BiPolar>
pretty chonky python package at 37 MB, LOL.
<Begas_VM>
yep, my point :)
jmairboeck_haiku has joined #haiku
<BiPolar>
"strip prebuilt/libunicorn.*" good enough?
<Begas_VM>
ah, the easy way? ;) (added it to the debug package) (probably overkill though)
<jmairboeck_haiku>
the inverted requirements for texlive don't work, haikuporter throws an error when building texlive_core: "Warning: Error: found provides for "texlive == 2023", but none matching the version requirement"
<Begas_VM>
:/
<jmairboeck>
or would that work in non-strict mode?
Begasus_32 has quit [Quit: Vision[]: Gone to the dogs!]
<Begas_VM>
doubt it, then you would have had a POLICY ERROR
<BiPolar>
Mmm. /bindings/python/build/lib/unicorn/lib ALSO has a copy of libunicorn.* (300+ MB).
<BiPolar>
this feels all kinds of wrong.
<Begas_VM>
eeps
<BiPolar>
too much copying around of huge ass libs... libunicorn.so == libunicorn.so.2 (exact copies)... under prebuilt...
<BiPolar>
there must be a better way :-)
<BiPolar>
I've striped and compared libunicorn.so.2, one from "build", the other from "bindings/python/build/lib/unicorn/lib"
<BiPolar>
exact matches.
<x512[m]>
What happens in IRC if edit a message in Matrix bridge?
<BiPolar>
x512[m] try editing that one, and we'll see.
<x512[m]>
Test.
<x512[m]>
* Test. Appended text.
<BiPolar>
First "<x512[m]> Test", then another line: "<x512[m]> * Test. Appended text."
<BiPolar>
Begas_VM: I think I got it right at the beginning, the python package does not needs to include libunicorn.so.2, it can use the one from the base package.
Begasus_32 has joined #haiku
<BiPolar>
We just need to figure out how to install it cleanly (and without the lib).
<Begasus>
still some work in process :)
<Begasus>
food :)
<x512[m]>
Is it possible to show available package versions for pkgman search command results?
<BiPolar>
x512[m] pkgman search -D package
<x512[m]>
Thanks.
<BiPolar>
np!
HaikuUser has joined #haiku
<Begasus>
k, partition removed, created, formatted, haikuporter updating dependencies, so far so good
<BiPolar>
Nailed it! unicorn_python39-2.0.1-1-x86_64.hpkg is now <75 KB...
<jmairboeck>
BiPolar: I noticed something about your recent python changes: there are a few recipes where you provide a separate PROVIDES without $secondaryArchSuffix. Maybe it would be better to check `if [ -n $secondaryArchSuffix ]` (i.e. if there is a secondaryArch) instead of checking for x86_gcc2 specifically?
<jmairboeck>
this way, it would also work if we have more than one secondaryArch one day (e.g. x86 on x86_64)
<BiPolar>
Could be, yes. I was just following korli's advice. He pointed me to that check from the cython recipe.
<BiPolar>
And... I'm still not confident enough to rock the boat too much :-P
<jmairboeck>
as long as x86 on x86_gcc2 is the only secondaryArch, it doesn't really matter
<BiPolar>
But that could also be made as a suggestion on the issue tracker, I guess, no?
<trungnt2910[m]>
Currently Haiku does not support mmaping files located on userlandfs right?
<jmairboeck>
yes, I can do that
<BiPolar>
jmairboeck: +2 :-D
HaikuUser has joined #haiku
HaikuUser has quit []
<BiPolar>
Rebooting into 32 bits...
BiPolar has quit [Quit: Vision[]: i've been blurred!]
AtomoZero has joined #haiku
OscarL_32 has joined #haiku
<x512[m]>
trungnt2910: Really? Running executables depending of file mapping.
<x512[m]>
s/depending/depends/, s/of/on/
<trungnt2910[m]>
x512[m]: What do you mean?
<x512[m]>
You can't run executables located at file system if file system do not support file mapping.
Diver has quit [Ping timeout: 480 seconds]
<trungnt2910[m]>
<x512[m]> "You can't run executables..." <- I know. So what I'm asking is that if Haiku currently supports `mmap`ing files on `userlandfs` or not.
<trungnt2910[m]>
And if not, what are the technical limitations preventing that from happening, especially when FUSE on Linux has that capability?
bbjimmy has quit [Quit: Vision[]: i've been blurred!]
<x512[m]>
vfs_set_vnode_cache function attach VMCache object to VFS vnode object.
bbjimmy has joined #haiku
<x512[m]>
VMCache class name is a bit confusing, it represent a set of physical pages or how to get this pages (read from disk etc.).
<trungnt2910[m]>
Hmmm why can't we export the same thing in userlandfs driver then?
OscarL_32 has quit [Quit: I'll be back!]
<x512[m]>
VMCache is kernel only object that is not exposed to userland. Userland can use VMCache indirectly by using areas. Area consists of rererences to VMCache objects.
<botifico>
[haikuports/haikuports] threedeyes 7f9419b - OpenJDK: add recipe for 16.0.2+7 version
<robxnano[m]>
<Begas_VM> "for meson there isn't an option..." <- You can use meson configure <builddir> to display the option list with all the currently selected options. Or if the project hasn't been set up yet, meson configure <sourcedir> will show the defaults
<x512[m]>
trungnt2910: How Linux FUSE handle mapped files?
<trungnt2910[m]>
x512[m]: Well, we can have the userlandfs kernel driver access the VMCache and then ask the userlandfs_server for data, no?
<x512[m]>
Yes, it should be possible to subclass VMCache so it will fetch pages from userland.
<botifico>
[haikuports/haikuports] korli c3a8470 - snowball_stemmer: missing lib dir
OscarL has joined #haiku
nosycat has joined #haiku
<jmairboeck>
the inverted dependencies for texlive don't work. texlive can't be built like that. haikuporter checks dependencies before activating build packages apparently.
gouchi has joined #haiku
<OscarL>
Buildmaster checking also REQUIRES (besides BUILD_{PRE}REQUIRES) surprised me the other day.
<x512[m]>
Mystery top level committer that do not communicate directly.
HaikuUser has joined #haiku
HaikuUser has quit []
_Dario_ has joined #haiku
AtomoZero has quit [Ping timeout: 480 seconds]
<OscarL>
Just in case Begasus returns while I'm asleep... 32 bits version of unicorn worked! Maybe you can do the honors and do the PR/Merge dance (previous review, of course) :-D (newest commit on OscarL/haikuports/tree/unicorn).
* OscarL
zzzZZZzzz
OscarL has quit []
<tqh>
x512[m], he does in tickets he has been here from the start of the project. Back when we had the BeGeistert conferences in Dusseldorf (sorry for mangling the u) you could have met a lot of people.
<tqh>
I miss BeGeistert...
<augiedoggie>
i passed ingo to take the #12 spot for most port commits a month or so ago, now i'm coming for mmu_man :P
<augiedoggie>
he needs to quit slacking off
<tqh>
Not sure how I moved up, only reviewed ARM related changes :)
<tqh>
augiedoggie, nice, keep at it!
<PulkoMandy>
I can confirm that I have met korli at begeistert several times and he's not mistery at all :) and easy to reach by github tickets, trac tickets or gerrit reviews or email if needed. Not everyone need to spend their day on IRC and forums :)
<x512[m]>
Are BeGeistert planned to be resumed?
<PulkoMandy>
no, no one is organizing them anymore
<tqh>
Not that I know of, it kind of ebbed out after Be went out of business.
<PulkoMandy>
Charlie who used to do it is not really doing anything related to Haiku anymore for several years
<tqh>
over a long time that is.
<PulkoMandy>
there was one BeGeistert not organized by Charlie, but with 8-10 people it's not worth it
<PulkoMandy>
after that I organized a few coding sprints, the first one worked well, the next ones not so much (3-4 persons)
<PulkoMandy>
probably someone in a more easily reachable place than me should organize them?
<PulkoMandy>
we tried an "online sprint" during the lockdowns I think, or shortly after, but I don't think that works quite as well (it is not very different from what I do every weekend...)
floof58 is now known as Guest8851
floof58 has joined #haiku
<tqh>
I kind of left due to arguments, still don't really commit. But if I can help others moving things forward I think it is good.
<PulkoMandy>
silly mailing list arguments. I think real life meetups would help with improving that too?
Guest8851 has quit [Ping timeout: 480 seconds]
<tqh>
not sure, the way we commit, the flow and such seems to be very controlled. I am fine with it, but I also not touch UEFI and ACPI anymore and moved to unsupported platforms where we are more ok with things.
<x512[m]>
UEFI and ACPI moved to unsupported platforms?
<PulkoMandy>
I do my best to do code reviews and get things merged, but there are just too much changes waiting. And sometimes things don't get merged and it's annoying, and sometimes they are merged too quickly and it break things. Maybe we should merge things more easily, but then that means we need more frequent releases so it's OK to break things in nightlies while people run betas
<tqh>
no, I just used to work on those things. I started the UEFI work for haiku here (I was not the one to finish it) before there was any free docs on it: https://github.com/tqh/efi-example
<tqh>
And I guess I am the only one who knows how to upgrade ACPICA
<x512[m]>
About interrupts: It seems that introducing some flag B_MANUAL_COMPLETION is needed for installing interrupt handlers that allows device driver to signal end of interrupt later outside of interrupt handler.
<tqh>
it's mostly just removing the acpica tree and unpacking the new one, checking that API's havn't changed decide what files are added/removed, and then testing all power management on a few computers..
printedz has left #haiku [Error from remote client]
<TkTech>
It's been a long time since I've checked, does Haiku have support for SCSI/ATA pass-through now?
<x512[m]>
tqh: Do ACPICA need some special interaction with PCI bus driver?
<tqh>
x512[m], not really, it needs to have support functions to talk to pci but afaik not while starting. You are allowed to init tables, do low level setup etc early. Then add handlers and init.
<tqh>
We don't really do it the right way, and there is non acpica code for early table handling.
<tqh>
We init handlers after acpica due to the modules of Be/Haiku.
<x512[m]>
It can be done more properly after PCI refactor.
<Begasus>
robxnano[m], thanks on that pointer, will need to check it out next time (on meson)
<tqh>
It would be better to do most ACPI things very early, but everyone was opposed to ACPI for many years. Still to this day it is a question to disable ACPI, which you should never do.
<x512[m]>
I don't know hot is it important, but Haiku still may run on old hardware without ACPI support.
<tqh>
yes, then bios sets everything up, and you use old power management.
<tqh>
It's just that hardware moved on from that many years ago.
<x512[m]>
ACPI is mostly device tree definition, not power management.
<x512[m]>
Naming is misleading.
<x512[m]>
It is similar to FDT.
<tqh>
fdt I think is acpi now :)
<x512[m]>
But more complex (can contain executable code etc.).
<tqh>
GPT is ACPI, UEFI is ACPI, Devicetree is acpi.
<tqh>
ACPI is like a VM I guess.
<tqh>
but it is a lot easier for us as they handle a lot of hw interaction, so we do not have to write native code for it.
<tqh>
But I spent years and years trying to figure out each end every power down failure for Haiku.
<tqh>
And to sum it up, old ACPI needed shutdown to be on CPU0, new doesn't
<tqh>
we can't shutdown on CPU 0 because some IPC bug between CPU's when shutdown, and since that old hw is now so old no one cares it is done...
<tqh>
anyway, it was an area I worked a lot on, but don't anymore...
<tqh>
they are all the same now, and that is why it was easy for me to work on ARM bootstrapping
<x512[m]>
UEFI can be used without ACPI as it often occurs on non-x86.
Diver has joined #haiku
<tqh>
yes but UEFI has taken over ACPI and FDT to become open specs there.
<tqh>
it is where hardware is going, bios is dead, non gpt partitions are dead, non uefi booting most likely dead soon ...
<tqh>
devicetrees is alive and prospering..
<tqh>
but used through ACPI.
<x512[m]>
HiFive Unmatched use UEFI+FDT combination.
<x512[m]>
ACPI is proposed for RISC-V server platforms, but it seems no real hardware released yet.
<tqh>
they ported uboot I think, it is current hardware, not the trend. uboot added UEFI, uefi took over device trees and ACPI
<tqh>
implementors are 2-5 years behind.
<tqh>
It makes things simpler, as long as it is open. UEFI API is ok, ACPI and UEFI devicetree not that much, but now that secure boot seems to be optional I think it is mostly good.
<jmairboeck>
PulkoMandy: I'm a bit shocked that I am the third-largest "knowledge carrier" in haikuports, according to the stats (thanks to TexLive ...)
<tqh>
compared to the past it much better. If only Lenovo and HP did things correctly we would be done.
<x512[m]>
It will be also nice to implement UEFI runtime services calling from Haiku kernel to edit boot menu.
<tqh>
yes that is the last step for full UEFI booting I think, unless we add native support for writing boot options directly.
<tqh>
we need something like efibootmgr on Haiku, to update flash. Long time since I worked on so don't remember terminology.
<tqh>
ARM64 or in the future risc-v is kind of what keeps me interested now though.
<x512[m]>
If I remember correctly, there are UEFI runtime services API that allows to edit boot menu. It is callable after exiting UEFI boot services and need reserving runtime services memory regions to be functional.
<x512[m]>
If it also works with U-Boot, I can try to experiment with RISC-V UEFI.
<x512[m]>
For some reason I prefer to use RISC-V for testing, not x86.
<tqh>
feel free to do anything.
<tqh>
I just think it is sad that we parse partitions, when with uefi you can just pass in the uuid or the uuid for the type for the partition and not need any of our logic.
<tqh>
pass in uuid for bfs type, get list of partitions back. if more than one show boot menu..
<x512[m]>
Parsing partitions should be not a problem.
<tqh>
no, just that we don't use UEFI correcly and reread from disk.
<x512[m]>
It is needed anyway for non UEFI (legacy BIOS etc.).
<tqh>
why spend a second or two there (old hw) when it is the fallback.
<x512[m]>
It should not matter what method is used for GPT partitions reading as long it is correct.
<tqh>
uefi does this beforehandoff, then we do it again. It takes time and shows in boot time.