<win8linux[m]>
Not sure how to package this without breaking things.
<win8linux[m]>
Replacing gzip and zlib seems like something that could potentially break installs.
acidsys has quit [Server closed connection]
acidsys has joined #haiku
<extrowerk>
win8linux[m]: why do you think it tries to replace gzip and zlib?
<Begasus>
try to create a recipe for the lib win8linux[m] , don't think it would harm, if there would be conflicts all other OS's wouldn't include them :) https://repology.org/project/libdeflate/versions
<extrowerk>
it have an own lib: libdeflate.so
<extrowerk>
it have wrappers for gzip and zlib, but i see no danger here, but i am looking only at the makefile
<extrowerk>
makefile also supports DISABLE_GZIP and DISABLE_ZLIB args
<win8linux[m]>
Maybe I'm misreading the README.
<extrowerk>
it seems it includes a gzip cli program too. you can probably safely delete it before it gets packaged
<win8linux[m]>
Just tried to build it and it fails at hardlinking gunzip to gzip.
<win8linux[m]>
Will look into those args.
<jessicah>
it installs gzip/gunzip as libdeflate-gzip/gunzip
<jessicah>
so it's safe to build and install without patching
<x512[m]>
Is it possible to generate attributes for icon files? mimeset don't work. Only resaving in Icon-O-Matic work.
<waddlesplash>
jessicah: fontforge isn't a real GDK app, it has its own ui toolkit and uses GDK for graphics output. originally it just used raw x11, which I was testing against somewhat for Xlibe
<waddlesplash>
x512[m]: mimeset -f?
<x512[m]>
Still don't work.
<waddlesplash>
maybe a bug in mimeset then
<andreasdr[m]>
Does anyone has a good hint for the tinyest X.509 security library to have HTTPS and TLS for UDP communication. For our 3d engine.
<andreasdr[m]>
I collected mbedtls, GNUTLS and OpenSSL. Hmm. Thought you porter guys would know a fitting library maybe.
HaikuUser has joined #haiku
<waddlesplash>
mbedtls is probably your best bet
<waddlesplash>
or WolfSSL? or whatever its called now
<HaikuUser>
salut/hi. I'm starting last nightly image on several laptop to try Haiku on "real" hardware. Does screen layout is always set to 1080x768 in try mode ? Or is it current limitation with intel HD620 ? Also, black screen on amd ryren4600m or 5700xt ....
<HaikuUser>
Idem on intel hd630 (currently i post from it in try mode)
<PulkoMandy>
I don't see why mimeset would do anything with icon files. All it can do is copy an icon resource to an icon attribute. There is no resource on an icon file since it's not an elf file
<PulkoMandy>
HaikuUser, it should detect your display video mode and use that, but our drivers are not perfect yet
<PulkoMandy>
you can try to enter the boot menu (press space during boot before the boot logo) and select "failsafe graphics driver" there, maybe it will help
<HaikuUser>
so try mode is identical to installed mode ...
<PulkoMandy>
yes
<andreasdr[m]>
Thanks waddlesplash.
<HaikuUser>
OK, i will tru to reboot in safe mode to get 1920x1080
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
HaikuUser has joined #haiku
<HaikuUser>
Re, booted with failback gfx drivers and Desktop uses all the screen at good resolution on Lenovo legion i9/hd630/gtx1660ti. I will try also on my radeon PC. thanks fo tip.
<HaikuUser>
is there anu app to monitoring temps and cpu speed ?
<nephele>
andreasdr: openssl is always use on haiku also
B2IA has quit [Remote host closed the connection]
<nephele>
why do you want to try and use TLS over udp though? wouldn't it make way more sense to use Dtls? (or why are you using udp then)
B2IA has joined #haiku
B2IA has quit []
B2IA has joined #haiku
<Begasus>
it's not my day at git ... good thing you didn't push me earlier nephele :P
HaikuUser2 has joined #haiku
HaikuUser2 has quit []
HaikuUser has quit [Remote host closed the connection]
<nephele>
german wikipedia sais haiku got 3d accel support in 2017 through gsoc?
<waddlesplash>
wut?
<waddlesplash>
no
<nephele>
Well, it sais so
<nephele>
sais that swift was ported in the same sentence aswell
<waddlesplash>
swift was indeed ported
HaikuUser has joined #haiku
HaikuUser has quit []
BeOSLand has joined #haiku
x10z has joined #haiku
<PulkoMandy>
there was a student working on 3D accel in 2017. But the mentor just disappeared in the middle of the project and the student didn't notice the org admin until like a month later...
<PulkoMandy>
and so the project failed and no progress was made
<PulkoMandy>
mentor was Duggan, he is not part of the developer team and as far as I know he has not reappeared since
<BeOSLand>
Hi, is there a tool to show edid info from current screen (with accerated driver) ?
<BeOSLand>
maybe boot log ?
<x512[m]>
So it was an attempt to port Linux DRM (or port of port from *BSD)?
<BeOSLand>
ok, EDID does not seems to be retrieve by intel_extreme or missing from laptop :-(
BeOSLand has quit [Quit: Vision[]: i've been blurred!]
<x512[m]>
As I understand the only functional 3D acceleration except my RadeonGfx was made by Rudolfc for some old nVidia cards. Am I right or I am missing something?
<PulkoMandy>
yes that's right
<PulkoMandy>
there were many attempts at different approaches but nothing else went as far as displaying something on screen
dcatt has joined #haiku
<phschafft>
just so I understand the impact here: does this have any impact on normal desktop operation (excluding things like gaming, animation software, ...)?
<x512[m]>
My RadeonGfx project started as pure acceleration without screen stuff. Currently it still do not support modesetting and depend on BIOS modesetting. But it can flip framebuffers and synchronize of frambuffer flip to avoid tearing and maintaining screen refresh rate rendering.
<PulkoMandy>
phschafft, no, we had no 3d acceleration for the last 21 years and it wasn't a problem, I don't see why it would be a problem now
<x512[m]>
In theory some 2D operations can be accelerated like bitmap scaling and gradients.
<phschafft>
sounds like the answer I expected and also what I wanted to hear.
rhx_irc has joined #haiku
<win8linux[m]>
There are graphical artifacts such as trailing windows and the occasional window element persisting where it shouldn't be.
<win8linux[m]>
Tearing as well.
<x512[m]>
Graphical artifacts are completely unrelated to GPU and hardware. It is pure software problem.
<x512[m]>
Tearing is related to GPU drivers.
<phschafft>
tearing is not a problem for me. doesn't seem to affect me as much as it seems to do for other people.
<phschafft>
that said, time for cake. thank you for the input and see you later. :)
<Begasus>
enjoy :)
<phschafft>
Thank you. :)
HaikuUser has joined #haiku
HaikuUser2 has joined #haiku
HaikuUser has quit []
HaikuUser2 has quit [Remote host closed the connection]
HaikuUser has joined #haiku
<HaikuUser>
Hello
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
<dcatt>
Hey HaikuUser
<Begasus>
no time ;)
x10z has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<nephele>
I'd personally take teating over input latency if those are the only options, desktop linux tries so hard to eliminate tearing everywhere that the input latency is too bad for me most of the time
<nephele>
(though we can likely do better)
<win8linux[m]>
Agreed, but only for games.
<win8linux[m]>
Everything else, I'd pick no tearing over input latency.
<win8linux[m]>
And yeah, hopefully Haiku can do better than Linux.
<win8linux[m]>
Trying to pull in libXinerama as a dep, but neither libxinerama${secondaryArchSuffix}_devel nor lib:libXinerama$secondaryArchSuffix seems to work.
<win8linux[m]>
HaikuPorter fails to find the dep to download.
B2IA has quit [Quit: Vision[]: i've been blurred!]
diver has left #haiku [#haiku]
B2IA has joined #haiku
B2IA has quit []
B2IA has joined #haiku
<Begasus>
stike that win8linux[m] don't think you can use them anymore
<win8linux[m]>
But they're still in HaikuPorts?
<win8linux[m]>
They're not disabled, too.
<win8linux[m]>
Why can't they be used?
<Begasus>
ask waddlesplash :)
<Begasus>
don't know the full details, haven't been there anymore
<Begasus>
I think a bit under 600 recipes out of date, so plenty to look into :P
<win8linux[m]>
<Begasus> "anyway, libdeflate is in the..." <- Perhaps, if I get stuck on the current one later today (need to sleep soon).
<Begasus>
ok, no hurry :)
<win8linux[m]>
<Begasus> "win8linux, maybe you could..." <- Certainly considered looking at old recipes and trying to update them. OpenTTD in particular is very out-of-date and community members have wanted it brought up to snuff.
<jmairboeck>
Begasus: speaking of outdated recipes: texlive is soon to become outdated and I should probably start to look at updating it for 2022 soon (it is planned to be released on 3 April, see https://tug.org/texlive/)
<win8linux[m]>
It's just that I'm hesitant to update packages that are maintained by others.
<Begasus>
Yeah, already saw some thing there jmairboeck , will be a big job again :)
<jmairboeck>
could the existing PR get merged before I start working on version 2022? it can stay disabled I think
<Begasus>
if that was the case my commits were limit win8linux[m] :)
<win8linux[m]>
heh
<Begasus>
I think korli, waddlesplash PulkoMandy diver etc would have to give a green light on that one, don't want to make a miss on such a large one (even though it should be ok)
<Begasus>
let me pull the commit and check with disabled sources in my conf
<win8linux[m]>
Maybe it's a hesitancy to take maintainership away from someone else or another related hangup, IDK.
<jmairboeck>
ok, no hurry, I don't think I will have much time anyway soon.
<PulkoMandy>
I have no idea, merge it and see what happens?
<Begasus>
some ports have been made for a purpose/need back then, some haven't been used or are still working fine for now
Anarchos has joined #haiku
<Begasus_32>
Warning: skipping texlive_x86-2021, as it is unsupported on the target architecture.
<Begasus>
that is with a fork, not sure it would work with branches (saved me earlier) :)
_Dario_ has joined #haiku
<jmairboeck>
Anarchos, Begasus: that pull request was the monolithic package, the splitting one was the one just merged by Begasus. So if you use haikuports from before that, you should still get a monolithic package. Or do you mean before splitting texlive_core off?
<Begasus>
I think texlive_core came later jmairboeck
<jmairboeck>
ah, you are right Begasus
<Begasus>
so in the first commits should still be the full package
<waddlesplash>
i am really hesitant to say we should host a 2GB package
<waddlesplash>
kallisti5[m] might have a fit :)
<Begasus>
buildmaster is set to don't build untested packages, so we should be ok (check here locally)
<jmairboeck>
waddlesplash: right now it consists of (I think) 125 hpkg files, totalling about 4 GB, IIRC
<waddlesplash>
yeah, it would be best if someone else hosted that IMO
<waddlesplash>
considering it's kind of niche
<waddlesplash>
it would be really best if we hosted the tex binary and then used CTAN to download packages...
<jmairboeck>
considering that there are (potentially) other packages depending on Tex packages, that would be difficult for them probably
<jmairboeck>
and haikuports contains package python packages too and not use pypi via pip, if I may use that comparison (I know its not 100% fair ...)
<Begasus>
and you would need to know what sub-packages are needed :)
gouchi has quit [Remote host closed the connection]
<jmairboeck>
we could maybe package individual packages directly from CTAN if they are needed by other packages and not package the rest at all, allowing for manual installation of those, but I have not looked into that yet.
<jmairboeck>
I am not really an expert in texlive packaging anyway, I just "stumbled into it" :)
<waddlesplash>
yeah, let's take that approach
<PulkoMandy>
someone will eventually repackage all of it, so to me it seems like a lot of effort to eventually reach the same result
<PulkoMandy>
is 4GB that large for our package repo, really?
<Begasus>
atleast lmbxx seems to link to x86_gcc2?
<Begasus>
for both 32bit and 64bit, so for that one it seems it's only hosted once
Begasus_32 has quit [Quit: Vision[]: i've been blurred!]
<x512[m]>
Maybe it should be separate arch-independent repository.
_Dario_ has quit [Quit: Vision[]: i've been blurred!]
<waddlesplash>
x512[m]: I investigated doing that once and determined it was not easy to implement given how the package system is set up
<waddlesplash>
somewhere there's a reply on the mailing list from Ingo explaining why
<jmairboeck>
but maybe the builders could be configured that only one of them builds "any" packages and creates symlinks in the other repositories
<x512[m]>
Resolving dependencies from another repository should work.
<Begasus>
heading down here, g'night peeps
Begasus has quit [Quit: Ik ga weg]
<x512[m]>
If it cause some problems, it should be fixed.
<jmairboeck>
yes, because "haiku" is provided by another repository already, so that must woek
<jmairboeck>
*work
<x512[m]>
Secondary packages problem should be also fixed. It should be eliminated completely and allow to install package of any architecture. If architecture don't match, run userland emulator.
waddlesplash has quit []
waddlesplash has joined #haiku
cocobean has joined #haiku
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<cocobean>
kallisti5: Tested icu70 on Haiku R1b3 x86 (GCC 11). Unit testing passed.
<cocobean>
Can drop icu66.
cocobean has quit [Quit: Page closed]
euandreh has quit [Quit: WeeChat 3.4.1]
euandreh has joined #haiku
x10z has joined #haiku
x10z has quit []
gouchi has joined #haiku
kescher has quit [Quit: Bye]
kescher has joined #haiku
tuaris has joined #haiku
<kallisti5[m]>
<cocobean> "kallisti5: Tested icu70 on Haiku..." <- Nice! Once we get icu70 into haikuports I can update the build- packages