ChanServ changed the topic of #haiku to: Open-source operating system that specifically targets personal computing. | | Nightlies: | Bugtracker: | SCM: | Logs: | Matrix: | XMPP:
Blendie has quit [Quit: Connection closed for inactivity]
AlaskanEmily has joined #haiku
<zdykstra> Nice little fix in open
<trungnt2910[m]> Anyone knows any documentation on FUSE receipt ACK requests?
<trungnt2910[m]> Currently the `vmhgfs-fuse` port is crashing because of missing `RECEIPT_ACK_REPLY` requests.
mmu_man has quit [Ping timeout: 480 seconds]
mmu_man has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
<trungnt2910[m]> I think I found the problem. It's in the userlandfs kernel driver.
x10z has joined #haiku
bronzie94[m]1 has joined #haiku
Kokito has joined #haiku
Maturi0n_ has joined #haiku
Maturi0n has quit [Ping timeout: 480 seconds]
<trungnt2910[m]> You cannot map_file or create_area using FUSE filesystems on Haiku right?
mmu_man has quit [Ping timeout: 480 seconds]
x10z has quit [Quit: Textual IRC Client:]
<botifico> [haikuports/haikuports] threedeyes pushed 1 commit to master [+0/-0/±1]
<botifico> [haikuports/haikuports] threedeyes a18997b - Calligra: remove mime cache files
HaikuUser has joined #haiku
HaikuUser has quit []
raymondmendoza has joined #haiku
<jessicah> zdykstra: thanks, was confusing the heck out of me :p
HaikuUser has joined #haiku
HaikuUser has quit []
kinkinkijkin has joined #haiku
Kokito has quit [Quit: Vision[]: i've been blurred!]
probono9 has quit [Quit: The Lounge -]
probono9 has joined #haiku
kinkinkijkin is now known as Guest8805
kinkinkijkin has joined #haiku
Guest8805 has quit [Ping timeout: 480 seconds]
OscarL_32 has joined #haiku
Diver has joined #haiku
hackkitten has joined #haiku
sahilister has quit [Quit: The Lounge -]
sahilister has joined #haiku
humdinger has joined #haiku
Begasus has joined #haiku
<Begasus> g'morning peeps
<humdinger> morning all!
<Begasus> hi humdinger !
* humdinger raises coffee mug
<Begasus> ah, HDS up on par again, can finaly link the tuxpaint packages for the tuxpaint maintainers now :)
<humdinger> putting Haiku on the map
<Begasus> arggh, 32bit isn't :(
<Begasus> humdinger, can't you poke something there?
<humdinger> Doubt it. what's missing?
<Begasus> latest version for 32bit
<humdinger> last version should be what?
OscarL_32 has quit [Quit: Vision[]: i've been blurred!]
<augiedoggie> hds is broken, it hasn't been updating for several days
<Begasus> 64bit:!/?bcguid=bc1-KTLJ&repos=haikuports&arch=x86_64&viewcrttyp=FEATURED&srchexpr=tuxpaint
<Begasus> 64bit seems ok now augiedoggie
<augiedoggie> yeah
<humdinger> man, I'm sooo tired of Web+'s bloody curlThread blocking...
<Begasus> anyway latest tuxpaint version is 0.9.29-rc2
AlienSoldier has quit [Quit: Vision[]: i've been blurred!]
<humdinger> weirdly, I can't find tuxpaint at the buildbot logs. neither 64bit nor 32bit..
Begasus_32 has joined #haiku
<Begasus> With pkgman it fetches the latest version
<humdinger> maybe it takes a few days. At HDS the date for the 64bit version is 2023-03-25 05:00:25
<humdinger> your link suggests it built the 32bit version on 22/3
<Begasus> it was build on buildmaster the same day
<humdinger> give it a few more hours...
<Begasus> I know waddlesplash mentioned poking someone for it yesterday, so yes, gonna wait for a bit to link the 32bit version
<humdinger> I'm afraid, I have no poking capabilities.
<Begasus> Bill has always been keen and helpfull to get the Haiku version on par also, gotta respect too :)
<Begasus> Same as the people for scummvm :)
BiPolar has joined #haiku
<humdinger> Hey BiPolar
<BiPolar> Halo!
<humdinger> you guys been busy. pages and pages of python stuff in the recent HDS pages.
<BiPolar> Saw the new Clipdinger release.
<humdinger> yeah just a quick fix for the missing context menu. didn't notice that sooner...
<humdinger> must've been broken forever...
<BiPolar> humdinger: re: python's recipes... korli basically replaced me with some regex scripts (he did a bulk update of recipes).
<humdinger> work smart not hard... :)
<BiPolar> Then I just *had* to fix the broken pieces :-P
<BiPolar> (kidding, kidding).
<humdinger> the reliable haikuports janitor...
floof58 is now known as Guest8813
floof58 has joined #haiku
<Begasus> 'lo BiPolar !
Guest8813 has quit [Ping timeout: 480 seconds]
<Begasus> gave up on unicorn, checked on 64bit yesterday evening with the same result as on 32bit
HaikuUser has joined #haiku
HaikuUser has quit []
mmu_man has joined #haiku
humdinger has quit [Quit: Vision[]: Oi with the poodles already!!]
<BiPolar> Hey Begasus. Just got it working... but with a hack.
tqh has joined #haiku
<BiPolar> it needs the lib named "" under it's python package dir... as in: "unicorn/lib/", with no ".2" at the end.
<BiPolar> I've just copied the modules under "/boot/home/config/non-packaged/lib/python3.9/site-packages/"...
<BiPolar> and after renaming that library... I could do "import unicorn" and also "help(unicorn)".
<Begasus> ah!
<BiPolar> Also... that unicorn/lib/ contains an .a file :-D
<nekobot> [haiku/haiku] 7beba9238874 - Update translations from Pootle
<nekobot> [haiku/haiku] autocommitter pushed 1 commit to master [hrev56862] -
<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
<BiPolar> particularly... "_uc = _load_lib(_path, _lib.get(sys.platform, ""))"
<BiPolar> that "_path" sounds promising :-P
<Begas_VM> linked that yesterday ;)
<BiPolar> missed it.
<BiPolar> also... the base package installs ""... with no symlink to "".
<BiPolar> and that "" is expecting the library to be named just that: "".
<Begasus> 10:20 <Begasus> ps, I think the search path for the library comes from somewhere around here:
<Begasus> ;)
<BiPolar> bah... just adding .2 to _uc = _load_lib(_path, _lib.get(sys.platform, ""))" makes it load the one installed by the system package :-D
<Begas_VM> +1
<BiPolar> so "_path" is correct... we're just missing the "" symlink to or just rename the god damned thing :-D
<BiPolar> (and also make sure they don't get included in the python package)
<Begas_VM> trying with:
<Begas_VM> rm $installLocation/unicorn/lib/libunicorn.a
<Begas_VM> mv $installLocation/unicorn/lib/ $installLocation/unicorn/lib/
<BiPolar> Begas_VM: I'm trying with this one:
<BiPolar> (uses $pythonVersion and $pythonPackage)
kinkinkijkin has quit [Ping timeout: 480 seconds]
<BiPolar> ... just in case we want to move it to another python version :-)
<Begas_VM> that could work too :)
<Begas_VM> looks better also +1
<Begas_VM> ok, that works now, going with your changes now
<BiPolar> Wish we could just call the install step separately (to avoid BUILD()ing everything :-/
<Begas_VM> yeah, even commenting it out it doesn't :/
<BiPolar> AAARRRHHH!!!!
<BiPolar> "rm: cannot remove '/unicorn/lib/libunicorn.a': No such file or directory" :-/
* BiPolar bangs head against keyboard.
<Begas_VM> hence I put that inside BUILD()?
<Begas_VM> don't know if INSTALL() takes the installLocation variable
<BiPolar> it doesn :-D
<BiPolar> *doesn't
<BiPolar> So,,, that would be the last step on BUILD(), right? just after "python build install" ?
<Begas_VM> yep
<Begas_VM> already moved them there now (for the ones in the python package)
<Begas_VM> getting KDL's on the other laptop, guess my partition is borked :/
<BiPolar> I'm almost sure the python package doesn't needs to include the libs. (I'm just running a build with "rm -f" on them now).
<Begas_VM> °_O
<Begas_VM> doesn't it need the devel package then ( is moved there)?
<BiPolar> it loads the lib from /system/lib/
<BiPolar> unlike in other packages... this one is not a python extension ".so" module (those need to be inside the packages).
kinkinkijkin has joined #haiku
<BiPolar> this is just loading the library from, and calling functions from them, AFAICT...
<BiPolar> ... after just a cursory inspection (and the fact that I managed to import it with the libs under /system/lib :-D)
<Begas_VM> right, but for 32bit they are in /system/lib/x86
<BiPolar> that's why I mostly use 64 bits, and my recipe is ?x86 :-P
<BiPolar> then it indeed might need patching to, so it can find it in 32 bits... should be not too complicated :-)
<BiPolar> (if not for the long build times... yikes)
<Begas_VM> can't stand loose ends :P
<BiPolar> Actually knowing what I'm doing would indeed help reduce the need for repeated builds :-)
<BiPolar> (I still get lost in the chroot tree, and the packaging step/process)
kinkinkijkin is now known as Guest8821
kinkinkijkin has joined #haiku
Begasus_32 has quit [Quit: Vision[]: Gone to the dogs!]
<Begas_VM> some day you will be teaching me :)
<BiPolar> :-)
Guest8821 has quit [Ping timeout: 480 seconds]
jmairboeck has joined #haiku
<Begas_VM> OK, with the one you linked things are looking OK here
<BiPolar> me does "hp -e unicorn-2.0.1"
<Begasus> +1
<BiPolar> just added a one-line patch to
<Begasus> why the version?
<Begasus> "hp -e unicorn" should work too
<BiPolar> on 32 bits too? I could swear it tried to build the older one for me today.
AlaskanEmily has quit [Remote host closed the connection]
<BiPolar> (at first I got in 32 bits by mistake, while attempting to test unicorn on 64 bits :-D)
<botifico> [haikuports/haikuports] Begasus pushed 1 commit to master [+0/-0/±1]
<botifico> [haikuports/haikuports] Begasus f5fe31f - geoip, disable static library (#8104)
<BiPolar> Ah. now I recall....
<Begasus> if you try to build an older one yes
<Begasus> not the most recent :)
<BiPolar> I had a broken unicorn-2.0.1 recipe... so it tried building the older one with "hp unicorn" :-D
<Begasus> hehe
<BiPolar> got me REALLY confused there.
<Begasus> that's not haikuporters fault :P
<BiPolar> thus... the version :-D
<Begasus> been there though ;)
<botifico> [haikuports/haikuports] threedeyes pushed 1 commit to master [+1/-0/±1]
<botifico> [haikuports/haikuports] threedeyes 8228cf9 - openjdk15: fix build for x86 arch
<BiPolar> After this unicorn thing... I plan to give a touch up to some recipes from korli's bulk commit, where I've noticed just minor things.
<BiPolar> Maybe after that we could have another bulk update adding 3.10 to the ones that miss it.
<BiPolar> Oh... c'mon! not again: "Haikuporter could not unmount 'system' volume in chroot", and when so close to finishing!
<Begas_VM> whoot!
<Begas_VM> it's not that long since this message has popped up
<BiPolar> Mmm /me finds the packages under "/unicorn/work-2.0.1/hpkgs" :-D
<Begas_VM> ;)
<BiPolar> Attempting to install and test under python3.9 now... /me crosses fingers.
<BiPolar> Annd... didn't work :-(
<BiPolar> I got the famouse "by 1" type of error...
<BiPolar> I forgot that "sys.platfom" == "haiku1" not "haiku" :-(
<BiPolar> I think I got it the other way around... the under the python package IS a C module extension...
__gyr has quit [Ping timeout: 480 seconds]
<BiPolar> but seems to include the one from the base package, so maybe unicorn_python39 could be a "standalone" package? (not depending on "unicorn")
<BiPolar> will test that.
<Begas_VM> reduces build time by 2 minutes ;)
<BiPolar> Again with the "could not unmount 'system' volume on chroot" :-(
<BiPolar> might need a reboot?
<Begas_VM> I don't know :/
<BiPolar> Well, just installed the resulting python, and now I can do: "import unicorn; help(unicorn.unicorn)".
<Begas_VM> +1 :)
<BiPolar> even more... I can try calling code from it. Wish I knew how to test it better, but... seems to at least load the damn
<BiPolar> "uc = unicorn.unicorn.Uc()" ---> it complains I'm missing parameters, which I am. :-D
<Begas_VM> you're the python master :)
<Begasus> lol, 'haiku1': '',
<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': ''" <<< 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
<botifico> [haikuports/haikuports] Begasus pushed 1 commit to master [+0/-0/±1]
<botifico> [haikuports/haikuports] Begasus 915cf2f - grantlee, fix, clean build (#8105)
<Begas_VM> ok, back on par, grabbing
<BiPolar> minor update...
<BiPolar> (had a typo in there)
<BiPolar> (on a comment, nothing critical)
<Begas_VM> k, build just started
<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 build" is calling:
<BiPolar> cmake_args = ["cmake", '-B', BUILD_DIR, "-DCMAKE_BUILD_TYPE=" + conf]
<BiPolar> not sure if it could use the .a that was already build for the main library... out of my league :-/
<Begas_VM> there's "build" and "build_python", both contain about the same
<botifico> [haikuports/haikuports] korli pushed 1 commit to master [+0/-0/±1]
<botifico> [haikuports/haikuports] korli d2a611a - calibre: fix reference to python3.8
<BiPolar> but the library sizes do not match (I thought they did at first, that's why I thought we could do without it for the py package)
<botifico> [haikuports/haikuports] korli pushed 1 commit to master [+0/-0/±1]
<botifico> [haikuports/haikuports] korli 160bc69 - mpd: rebuild with setuptools_python39
<Begas_VM> k, looks fine now BiPolar
<Begas_VM> import works ok on 32bit now too :)
<BiPolar> Begas_VM: from that "# check if a prebuilt library exists" ... and "# if so, use it instead of building"
<BiPolar> 8-O
<BiPolar> Seems like it expects it to find some libs under "ROOT_DIR/prebuilt".
<Begas_VM> how or where does it look for ROOT_DIR?
<BiPolar> I assume that ROOT_DIR is the dir where is?
<BiPolar> maybe we could copy the libs there, and see if that cuts the build time :-D
<BiPolar> that's because that variable is from the (python specific I assume?)
<BiPolar> something from setuptools?
<Begasus> you're the master ;)
<BiPolar> that's a scary thought :-D
<Begas_VM> prebuild is inside the python directory
Blendie has joined #haiku
<Begas_VM> manualy cp'd the library in there now to check
<BiPolar> so... cp build/libunicorn.* bindings/python/prebuilt ?
<Begas_VM> yep, only did it manualy now
<BiPolar> k
<Begas_VM> and disabled the tests
Begasus_32 has joined #haiku
<Begasus_32> guessing this isn't looking good:
<Begas_VM> quite a few others there too :/
<BiPolar> ouchie
<BiPolar> what's the magic to disable the tests?
<Begas_VM> guess I'll have to re-format that partition :/
<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 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... == (exact copies)... under prebuilt...
<BiPolar> there must be a better way :-)
<BiPolar> I've striped and compared, 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, 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...
HaikuUser has quit []
<Begasus> nice BiPolar !
<BiPolar> "requires: lib:libunicorn>=2.0.1", and can "import unicorn" :-D
<Begasus> ow bugger, so simple? +1
<BiPolar> minor cleanups to the recipe, and I'll push for review.
<Begasus> thanks!
<BiPolar> needed to add also an export variable.
<Begasus> heading out to our grandchildren in a bit, I'll check 32bit (if you haven't already) later then
<BiPolar> build time down to 7m30s. too :-)
<Begasus> whoot! :D
<BiPolar> :-D
<Begasus> k heading out, cu later!
<jmairboeck> I have uninstalled texlive (the 2022 version) and now it works!
<BiPolar> nice work jmairboeck!!!
<jmairboeck> now let's see if texlive-2023 can be built like this ...
<BiPolar> (oh... hope I didn't jinxed you :-D)
<jmairboeck> unpacking and initializing the Git repo for that will take a while (I downloaded it already yesterday)
<jmairboeck> can the creation of a git repo be skipped on a per-recipe basis?
<jmairboeck> maybe it could be skipped automatically if the recipe contains no patches and no PATCH() function ...
<botifico> [haikuports/haikuports] korli pushed 1 commit to master [+0/-0/±1]
<botifico> [haikuports/haikuports] korli 55a4519 - snowball_stemmer: fix shared library
<jmairboeck> although texlive contains a PATCH function, so that wouldn't help in this case
<BiPolar> maybe add that as an enhancement proposal over haikuporter?
<BiPolar> sounds reasonable to me (not like that says much, but... :-P)
systwi_ has joined #haiku
<botifico> [haikuports/haikuports] korli pushed 1 commit to master [+0/-0/±1]
<botifico> [haikuports/haikuports] korli ee76b8c - calibre: trigger build
<jmairboeck> BiPolar: I created an issue:
systwi has quit [Ping timeout: 480 seconds]
<BiPolar> +1
<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?
<x512[m]> Confused packagefs with userlandfs...
<trungnt2910[m]> With this:, I've managed to build vmhgfs-fuse ( on Haiku and got it working. But I could not execute a Haiku executable on the shared path.
<x512[m]> File system kernel module should exposed VMCache object for files to make mmap functional.
<trungnt2910[m]> Can't we do the same for userlandfs?
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 pushed 1 commit to master [+1/-0/±0]
<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 pushed 1 commit to master [+0/-0/±1]
<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.
matt1 has joined #haiku
matt1 has left #haiku [#haiku]
<PulkoMandy> is updated with the latest contribution stats for haikuports
<x512[m]> > korli 4858 (21.88%) 54 (0.24%)
<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?
<x512[m]> Covid unrelated?
<PulkoMandy> yes, that was all before covid
<botifico> [haikuports/haikuports] korli pushed 1 commit to master [+0/-0/±1]
<botifico> [haikuports/haikuports] korli 47937e4 - calibre: trigger build
<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:
<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> It is more UEFI is ACPI and all the other things, for whoever is keeping score:
<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.
<tqh> yes I think it is enough to update nvram
<tqh> From Fuchsia originally
<x512[m]> It should be SetVariable function.
<tqh> yes
<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.
<botifico> [haikuports/haikuports] Begasus pushed 1 commit to master [+0/-0/±1]
<botifico> [haikuports/haikuports] Begasus 0621acc - highway, cleanup (#8107)
<x512[m]> Isn't Haiku boot loader reuse kernel partition read code?
<tqh> but I guess I am the one who want's instant on like C64.
<tqh> it reparses partitions with our code yes.
<tqh> but gpt partitions are already parsed by UEFI.
<tqh> it knows partition type and partion id.
<tqh> if you have either of those you can iterate or pick directly.
dairyhungWL has joined #haiku
botifico has quit [Remote host closed the connection]
dairyhungWL has quit [Remote host closed the connection]
dairyhungWL has joined #haiku
tqh has quit [Quit: Leaving]
bbjimmy_64 has joined #haiku
nosycat has quit [Quit: Leaving]
diver1 has joined #haiku
Diver is now known as Guest8861
diver1 is now known as Diver
Guest8861 has quit [Ping timeout: 480 seconds]
<PulkoMandy> instant boot would be cool but I'm not getting that with the time the firmware needs on my laptop :(
Begasus_32 has quit [Quit: Vision[]: Gone to the dogs!]
botifico has joined #haiku
<botifico> [haikuports/haikuports] Begasus pushed 1 commit to master [+0/-0/±2]
<botifico> [haikuports/haikuports] Begasus 487116e - hiredis, fix install for the *.cmake files (#8108)
Begas_VM has quit [Quit: Vision[]: i've been blurred!]
<andreasdr[m]> Arrr. Hi there!
<Begasus> hi andreasdr[m]
<Begasus> bugger, forgot to revbump
<botifico> [haikuports/haikuports] Begasus pushed 1 commit to master [+0/-0/±1]
<botifico> [haikuports/haikuports] Begasus 8463ddd - hiredis, revbump (#8109)
<Begasus> k, all good now
<Begasus> time to close down
<Begasus> g'night peeps!
Begasus has quit [Quit: Leaving]
<andreasdr[m]> Good night Begasus
vdamewood has joined #haiku
<andreasdr[m]> I would love to have something like a BeGeistert somewhere here. :)
<andreasdr[m]> x512: Any 3d hw news If I may ask (If not just ignore the question)
dairyhungWL has quit [Quit: Leaving]
vezhlys has joined #haiku
AtomoZero has joined #haiku
selfish- has joined #haiku
selfish has quit [Read error: Connection reset by peer]
tqh has joined #haiku
Blendie has quit [Quit: Connection closed for inactivity]
tqh has quit [Quit: Leaving]
tqh has joined #haiku
AlaskanEmily has joined #haiku
tqh has quit [Quit: Leaving]
Diver has quit [Quit: Leaving.]
gouchi has quit [Remote host closed the connection]
mrnhmath has joined #haiku
mrnhmath has quit [Remote host closed the connection]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
AtomoZero has quit [Quit: Vision[]: i've been blurred!]
hackkitten has quit [Ping timeout: 480 seconds]