<Not-d5e4>
[haikuports/haikuports] jmairboeck 8618edf - new recipe: lilypond (#6836)
<extrowerk>
waddlesplash: any updates about the openbsd wlan drivers?
<extrowerk>
the idualwifi7260 is really bad currently, and i can't replace the card, because it is whitelisted in the firmware and i aleady updated it past the version which allows to replace wlan cards :(
<Begasus>
nice one, used it to mount the disk and grabbed the packages for a backup :)
<Begasus>
Other error on texlive now jmairboeck (during copying the files) I guess something is bogus there, atleast I got one that has build, so I'll leave it for now
mmu_man has joined #haiku
<jmairboeck>
so it is a different error this time?
<jmairboeck>
some files are missing apparently, so some error messages are expected, but they shouldn't fail the build, I think
<Begasus>
got the 2022 files backed up now, so I'm good :) (no need to keep hunting and maybe get other errors, didn't clean and full rebuild each time, so maybe only invoking INSTALL could trigger something there)
<Begasus>
will do a testrun on frescobaldi
<jmairboeck>
Frescobaldi actually doesn't even depend on lilypond, so theoretically we could merge it even. But it wouldn't be very useful without lilypond. Could you put a "wip-no-merge" label on the Frescobaldi PR? I want to try to get MIDI support working by porting PortMidi. Maybe that will need some changes to the Frescobaldi recipe also.
<Begasus>
ok, saw you already created a branch for that
<jmairboeck>
yes, because I wanted to test it on 32 bit if it works with gcc2
<jmairboeck>
but it doesn't
<jmairboeck>
so I can use some modern C++ for the Haiku implementation :)
<Begasus>
thanks for checking extrowerk ... I just can't get a build for opencv starting (waiting for package to be activated ...) :/
<jmairboeck>
PortMidi is not yet ready, therefore I didn't create a PR yet
<jmairboeck>
I just used github to transfer the recipe to my 32 bit VM
<Begasus>
good thinking :)
<Begasus>
you run them virtual I presume?
<jmairboeck>
yes
<jmairboeck>
the 64 bit one using a physical hard disk on a USB-SATA adapter
<Begasus>
You could also attach an extra disk there, and use it to store thing for haikuports
<jmairboeck>
yes, I know
<jmairboeck>
but I need to push it to github eventually anyway
<Begasus>
one laptop is using USB-SATA adaptor too, 1 partition 64bit, 1 partition 32bit, 1 partition haikuports, 1 partition fat32 (share)
<jmairboeck>
and right now I have my haikuports clone is inside /boot/home, so I would have to copy it somewhere else first to use another disk
<Begasus>
that's why I created a separate partition for it
<Begasus>
1TB birthday present for myself ;)
<Begasus>
hm ... still have an update on poppler to add poppler_qt6 to push
<jmairboeck>
I decided to switch to the "official" texlive_core package, so that I can use SoftwareUpdater and pkgman full-sync again
<Begasus>
Is there an un-official one then?
<jmairboeck>
my local build :)
<Begasus>
ah :)
<jmairboeck>
someone should really fix that "name in use" errors (https://dev.haiku-os.org/ticket/15068) so that this works without uninstalling it first ...
<x512[m]>
And remove package version from package links.
DKnoto has quit [Quit: Leaving]
DKnoto has joined #haiku
<Begasus>
I'm no python expert :)
<jmairboeck>
that has nothing to do with python or haikuporter but Haiku's package kit itself (or package_daemon or something)
<Begasus>
glad I got the backups for texlive, cleaning the build takes forever too ;)
<Begasus>
jmairboeck, for frescobaldi there is a missing package python-ly?
<jmairboeck>
it should already be available, the PR for that was merged already
<Begasus>
ah, maybe you should add that to REQUIRES?
<jmairboeck>
ah, I forgot that, sorry
<Begasus>
nm, launching now :) (that's why it's good to check before merging)
<Begasus>
so build is ok on 32bit :)
<jmairboeck>
it should be, as it is written in python and contains nothing arch-specific, if I'm not mistaken
<Begasus>
right
<Begasus>
do you have a link to a nice lilypond file to open there?
arti has quit [Quit: arti]
<trungnt2910[m]>
Is the folder `/system/cache` the equivalent of `/var/tmp` on Linux systems? Or is it just `/tmp` (as `/tmp` doesn't seem to be cleaned on reboot)
<Begasus>
Heading out for a bit, going to pick up our oldest female :'(
<nephele>
trungnt2910: no /tmp is linked to /system/cache/tmp/
<nephele>
whether /tmp is cleared on reboots depends a lot on linux distro specifics... some do some dont, some symlink var/tmp and /tmp together... (not sure what the difference is)
HaikuUser has joined #haiku
<Begasus>
bbl
HaikuUser has quit []
MajorBiscuit has joined #haiku
<jmairboeck>
Begasus: there is also https://www.mutopiaproject.org/ where you find many music scores online, including sources
<jmairboeck>
Begasus: I added the missing dependency
HaikuUser has joined #haiku
HaikuUser2 has joined #haiku
HaikuUser2 has quit []
<trungnt2910[m]>
<nephele> "trungnt2910: no /tmp is linked..." <- So I currently need a place to store temporary files that are persisted on reboot, similar to `/var/tmp/` on Linux. Is `/system/cache/` the right place for me?
<trungnt2910[m]>
It assumes that `/var/tmp` exists which isn't the case on Haiku, so I'm finding another relevant path to store the temporary files. (These files will be automatically deleted at the end of this test)
<nephele>
I don't think /tmp is a tmpfs, it is a link to the other dir. Anyhow the correct answer is to use find_directory or the finddirectory command to find a dir to use
<nephele>
lrwxrwxrwx 1 user root 22 May 21 14:03 /tmp -> /boot/system/cache/tmp
<nephele>
/tmp or /boot/system/cache or /boot/system/cache/tmp are probably all fine if you dont want to go through the effort to find the correct temporary dir
arti has joined #haiku
<nephele>
(either "finddir B_USER_CACHE_DIRECTORY" or "finddir B_SYSTEM_CACHE_DIRECTORY" probably)
<trungnt2910[m]>
nephele: Yeah I'll take this approach, as the path is defined in a C macro.
<nephele>
trungnt2910: find_directory should be available in C fine iirc
<trungnt2910[m]>
nephele: Yeah but I'm putting stuff in a macro.
<nephele>
The right way is to use the api anyhow. if you don't use the api there is no gurantee that the dir would exist later ;) I would expect tmp to be available normally though
HaikuUser2 has joined #haiku
HaikuUser2 has quit []
Gaspare has joined #haiku
Gaspare has quit []
x10z has joined #haiku
tqh has quit [Quit: Leaving]
Gaspare has joined #haiku
<waddlesplash>
extrowerk: yes! I've got the OpenBSD driver starting and reporting scan results. need to fix some usability things and then implement joining networks
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
Gaspare has quit []
MajorBiscuit has quit [Quit: WeeChat 3.4]
MajorBiscuit has joined #haiku
Gaspare has joined #haiku
<andreasdr[m]>
waddlesplash: Nice!
AlienSoldier has joined #haiku
<x512[m]>
I managed to implement Haiku EGL support over Gallium and made BGLView as wrapoer over EGL. I also used glvnd to load EGL drivers.
<AlienSoldier>
M3dEyes[m] there used to be a speed data section at the bottom of the qbittorrent app (same vertical position as the window resize handle). It is no longer there, do not know if it is app or QT plugin related.
<x512[m]>
radeonsi is Gallium driver for SI+ Radeon GPUs.
<ermo[m]>
x512: r600/radeon is gallium too?
<x512[m]>
Yes. r300 Gallium drivers also exist.
MajorBiscuit has quit [Ping timeout: 480 seconds]
* ermo[m]
really hopes for radeon/r600g support
<andreasdr[m]>
That sounds super nice!!!! x512: How do you do this? GOD MODE.
<x512[m]>
But again, it need GPU control driver that will implement DRM ioctl's.
<ermo[m]>
even if it's old
<andreasdr[m]>
:)
<andreasdr[m]>
But sounds like a feasible way to get older graphics card to work.
<andreasdr[m]>
very feasible.
<x512[m]>
I made EGL working on Haiku, it is not so much code.
<andreasdr[m]>
Cool.
<x512[m]>
Implementing ioctl's for various GPUs is a lot of work and it is not done. Linux kernel drivers are not portable.
<ermo[m]>
ah
<x512[m]>
Currently only some Radeon GPUs work.
arti has quit [Quit: arti]
<x512[m]>
Nvidia released open GPU control driver and it have portable architecture. If Mesa will implement rendering driver part, it will be possible to bring Nvidia GPU acceleration to Haiku.
arti has joined #haiku
<andreasdr[m]>
Yes. Thought of it before. Nice to hear it from you. Lets see if they open the other software driver parts. Or anyone else working on this.
<nephele>
seems very unlikely
<andreasdr[m]>
Hmm. No 100% idea yet about it.
<nephele>
they only have this "Open" because they can now run the majority of the driver code on the gpu itself
<nephele>
and have a predictable interface for this, which on the other end has the open driver
x10z has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andreasdr[m]>
So I guess it has some advantage over the old version?
<nephele>
anyhow... nvidia said for this release that their focus has been on servers and they did not focus on desktops yet, so probably too early to look to port it over
<nephele>
>So I guess it has some advantage over the old version?
<andreasdr[m]>
I meant x512
<nephele>
Ah
<nephele>
I thought you ment the oss nvidia driver
<x512[m]>
nephele: From Haiku perspective moving driver code to GPU itself is good thing, less things to deal with.
<andreasdr[m]>
Nephele: Sorry. No.
<nephele>
x512: indeed
<AlienSoldier>
we need to make an hostile takeover on them :P
<AlienSoldier>
then haiku become sucessfull and all other manufacturer need to follew
<AlienSoldier>
*follow
<x512[m]>
BGLView is very limited interface that not allow to create multiple contexts or specify detailed API options like OoenGL version. I think that is better to use EGL for new applications and keep BGLView for compatibility and simple applucations. Only EGL will be real interface and it will be easier to maintain. glvnd already have to load OpenGL EGL drivers that can be used for Haiku.
<x512[m]>
Multiple OpenGL context are needed for multithreaded usage, for example loading resources in background from another thread.
<x512[m]>
I think that Vulkan drivers are quite enough for new hardware, Zink can be used for OpenGL.
mmu_man has quit [Ping timeout: 480 seconds]
<x512[m]>
Implementing ioctl support for older GPUs is a lot of work and I Haiku have no such resources.
<andreasdr[m]>
I see.
<x512[m]>
Basically modern Radeon, Intel and Nvidia (if someone make open Vulkan/OpenGL rendering driver) are needed.
<andreasdr[m]>
Yes. True that. And yes. Time and resources are usually very limited. Also here.
<andreasdr[m]>
But seems like you find clever ways to get to it.
<andreasdr[m]>
If I have some more money again I will also spent again some money.
<andreasdr[m]>
:)
<andreasdr[m]>
Cool. Any other news about RADEON driver?
<andreasdr[m]>
If I may ask?
<andreasdr[m]>
Also do you plan to support 6600XT?
mmu_man has joined #haiku
<andreasdr[m]>
Just asking. Bought a capable Laptop for 1.1k€ and it has a 6600XT. Performs very well. If it does not yet get planned I might just buy a small computer with older graphics card to play around with Haiku.
<x512[m]>
6600XT is quite new one.
<andreasdr[m]>
True. They even have issues with Linux.
<x512[m]>
Not soon.
<andreasdr[m]>
Wait. It has a VEGA8 or something integrated. So could also be fun already :)
<x512[m]>
I planned to implement GFX8 (RX500 series) next.
<andreasdr[m]>
Nice.
<x512[m]>
It need some header cleanup first.
<x512[m]>
Amdgpu headers are a bit different and incompatible with Radeon ones.
<andreasdr[m]>
Ah I see.
<x512[m]>
For example Radeon MMIO register headers use 1 byte units but Amdgpu use 4 byte units.
<x512[m]>
It need be carefully adapted.
AlaskanEmily has joined #haiku
<andreasdr[m]>
Oh.
<andreasdr[m]>
In germany they say: "The devil lives in the details". And often its trueeee.
<andreasdr[m]>
Also I saw lots of ARM64 work. So cool.
<andreasdr[m]>
Waiting to play around with Haiku and ARM.
<andreasdr[m]>
But have no real use case so its more tinkering.
dpirate has quit [Remote host closed the connection]
<waddlesplash>
trungnt2910[m]: what's the pointer, probably it's NULL?
<trungnt2910[m]>
waddlesplash: `ptr` is a block I just `mmap`ed, with `PROT_NONE`.
<waddlesplash>
oh, no, you just didn't give it PROT_READ
dpirate has joined #haiku
<waddlesplash>
I think this is expected, the kernel is allowed to read whatever it wants?
<waddlesplash>
what does Linux do
<trungnt2910[m]>
waddlesplash: No, I expected the call to write to **FAIL**, but it suceeeded.
<waddlesplash>
write() is a syscall, not a userland call
<trungnt2910[m]>
waddlesplash: It fails with EFAULT, just like the example with 0xDEADBEEF.
<waddlesplash>
hmm. possibly we need to change fix_protection behavior I guess
<waddlesplash>
feel free to open a ticket
<trungnt2910[m]>
waddlesplash: Hmm, this is coming from a test a library uses to check whether the memory it wants is accessible. Currently it relies on `write` and `EFAULT`.
<trungnt2910[m]>
waddlesplash: Ok.
<waddlesplash>
yeah we should likely fix this then
<waddlesplash>
however it will require some careful changes around per-page protections I bet
<trungnt2910[m]>
<waddlesplash> "however it will require some..." <- Is it too complicated? Else can you point me through the source tree so I can take a shot at fixing it myself?
<waddlesplash>
well, you will have to fiddle around in the virtual memory manager
<trungnt2910[m]>
waddlesplash: So it's not related to me messing up with the memory protection?
<waddlesplash>
no, it is
<waddlesplash>
but it's probably just a problem that's exposed by your changes
<trungnt2910[m]>
So then the memory protection is kinda a hack for some other bugs?
<waddlesplash>
no, more like this is the "expected behavior" maybe even dating to BeOS days
<waddlesplash>
so some drivers expect that to happen
<waddlesplash>
we don't maintain kernel level compatibility with BeOS anymore, and especially not after SMAP was introduced. So indeed we need to fix any drivers here to follow the new standard.
austin987 has quit [Remote host closed the connection]
tqh has joined #haiku
austin987 has joined #haiku
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
<trungnt2910[m]>
x512: What's the status of the libunwind pull request right now? Is building Haiku with that patchset from source working properly?
vezhlys has joined #haiku
<x512[m]>
Probably not. It also need CompilerRT parts and libgcc_s.so stub (empty library with soname and list of versions) or recompiling GCC with different options.
<x512[m]>
System works after adding CompilerRT parts and libgcc_s stub.
<x512[m]>
libgcc_s stub is needed because existing binaries import it.
tuaris has joined #haiku
MajorBiscuit has joined #haiku
Diver has joined #haiku
<extrowerk>
there is a jailbreak for my tv, but i updated the firmware, and now i can't jailbreak anymore. too bad, jailbreak allows adblock in the youtube app, now i am forced to watch ads. the jailbreak also allows ssh, and i definetely want to ssh into my tv.
<nephele>
extrowerk: you can set up a dns based adblock
<extrowerk>
i have adguard home, but afaik yt ads served from the same domain as the content, therefore it is hard to filter out the ads
MajorBiscuit has quit [Ping timeout: 480 seconds]
mmu_man has quit [Quit: Lost terminal]
vdamewood has quit [Quit: Life beckons.]
xet7 has quit [Remote host closed the connection]
X512 has quit [Quit: Vision[]: i've been blurred!]