<Hanicef[m]>
fyi, the jxl translator is updated now, and it fixed the file saving bug
<Begasus[m]>
hmm, pulled the changes about an hour ago I think?
<Hanicef[m]>
ah, i saw your comment now
<Hanicef[m]>
interestingly, i tested with a png file, so that should work, too
<Begasus[m]>
yeah, working on jpg files it seems
<Hanicef[m]>
my guess is that it's caused by pixel encoding
<Begasus[m]>
the heic file that worked before (with the weird coloring) doens't now
<Hanicef[m]>
have you tried transparent vs non-transparent picture?
<Begasus[m]>
ok, png (screenshot) file does work
<Begasus[m]>
ah the GSoC-Haiku-2024-Flyer-thumbnail.png file has transparant parts in it
<Hanicef[m]>
just fyi, stuff like that matters more than the actual file format, since everything is translated into a minimal internal format before being passed to the jxl converter, so jxl doesn't know what format the image originates from (which is a bit unfortunate, since if that information was available, it could adjust it's output to minimize pixel loss and convert jpeg files losslessly)
<Hanicef[m]>
ah, yeah, since distance is not 0, they aren't pixel-by-pixel identical, but close enough for the discrepancies to not be noticable
<Hanicef[m]>
it's really unfortunate that we can't do lossless conversion
<Begasus[m]>
1.42MiB vs 808.4KiB
<Begasus[m]>
it's more then what is there now :)
<Hanicef[m]>
can you try cjxl -e 10 -j 1 Vanka.jpg Vanka-c.jxl and compare?
<Hanicef[m]>
just to see how much we would gain by using lossless conversion
<Begasus[m]>
Error parsing flag -e
<Begasus[m]>
lol
<Begasus[m]>
sorry, wrong tools package :)
<Begasus[m]>
getting a crash on the cmd now Hanicef
<Hanicef[m]>
:v
<Hanicef[m]>
i fail to see how these are related, since afaik libjxl don't preserve any state and the jxl tools aren't touched by jxlconverter
<Begasus[m]>
I didn't have the tools installed, so for the cmd I installed the older version from the tools which seem to work a bit different then the 0.11 one
<Begasus[m]>
ah, seems it error'd because the output file already existed
<Hanicef[m]>
yeah, there was a reason why i added the -c at the end there, since i wanted you to keep the old jxl file
<Hanicef[m]>
what's the file size difference between the one created by cjxl and the one created by jxltranslator?
<Begasus[m]>
1.15MiB now
nephele has joined #haiku
* nephele
waves
<Hanicef[m]>
yeah, that's what i was worried about :/
<Begasus[m]>
the one with the translator was 808.4KiB
<Hanicef[m]>
henlo nephele
<Begasus[m]>
hi nephele !
<nephele>
The intel arc a750 seems to work just fine with EFI framebuffer! :)
<Begasus[m]>
progress? :)
<Hanicef[m]>
Begasus[m]: you're comparing lossless conversion vs lossy comparison, so if you want a fair comparison, you have to set distance to 0
<Begasus[m]>
ps nephele llvm-ar seems to be fine here
<nephele>
Not really Begasus[m], I had to send in the other gpu as it was broken *again*
<nephele>
the intel one works atleast
<Begasus[m]>
jikes
<nephele>
Begasus[m]: you have too much stuff installed
<Begasus[m]>
not arguing there :P
<nephele>
so if a dependency is wrongly not declared it's not suprising that it will work for you (tm) :)
<Begasus[m]>
but only 1 llvm version :)
<nephele>
really?
<Begasus[m]>
yep
<Begasus[m]>
ah no :D
<nephele>
I have atleast two llvm libs versions because varies things are stuck on old lib versions
<nephele>
including haiku mesa
<Begasus[m]>
llvm12_libs and llvm18_libs also
<Begasus[m]>
yeah llvm12 is used/needed by the system iirc
<nephele>
Yeah okay. updating llvm 20 libs was the solution
jmairboeck has joined #haiku
<nephele>
it ought to declare this as a dep if it needs it in that revision though....
<nephele>
ticket can be closed i guess :)
<Begasus[m]>
llvm20-20.1.4-2-x86_64.hpkg that's the package containing llvm-ar
Begasus has joined #haiku
<Begasus>
lag on the matrix, will close the ticket nephele, thanks for checking!
<Begasus[m]>
hi jmairboeck
<Begasus[m]>
+1 korli mentioned it on the issue also
<Begasus[m]>
nephele: can be closed then?
<Begasus>
lol
<nephele>
I guess. I'd assume this dependency (for that version) has to be declared explicitly if they change the api, but i'm not gonna complain about that :)
* phschafft
/me offers Begasus and nephele each a cookie before heading to his corner.
* Begasus[m]
gladly accepts the nice offer from phschafft
* phschafft
nods.
<nephele>
phschafft: the .desktop files on debian have one advantage
<phschafft>
I hope they have some!
<nephele>
I can delete all the entries for the crap that is preinstalled, to only show actually usefull applications in the menu :)
<phschafft>
there is specifically a hide flag so you can hide stuff you don't like to see.
jmairboeck_ has joined #haiku
<nephele>
I wish KDE's menu wasn't soo slow :(
OscarL has joined #haiku
* phschafft
however wonders why that is a problem. he only has very little in there after a fresh install.
<OscarL>
Morning folks.
<Begasus[m]>
Hola OscarL
<OscarL>
o/
<Hanicef[m]>
i've given up on linux on the desktop ever since i found haiku, since there really is no way to get linux to be unified enough for the system to be cohesive
<Hanicef[m]>
henlo OscarL
<OscarL>
I think we should fix that llvm20 dependency.
<nephele>
phschafft: kde has lots of stuff that is basically pointless preinstalled on Debian
<Hanicef[m]>
it feels like every attempt on unifying the linux desktop only makes the situation worse
<nephele>
like three terminal emulators
<Begasus[m]>
OscarL: that will be hard
<OscarL>
bit weird that (after pkgman refresh), pkgman search -r llbLLVM returns nothing.
<OscarL>
*libLLVM
<Begasus[m]>
since it requires the base package, and you can't uninstall llvm12
<nephele>
Hanicef[m]: I don't know if unifying is the probelm. Seems the problem is people using complexity to fix more complexity
<Begasus[m]>
ah no :) base should then require the _libs package OscarL
<OscarL>
is the base package the one that needs the lib: dep.
<phschafft>
nephele: I have a system that is now in active use since 2018. it has 21 menu entries. and most of them are stuff that was installed later on by me.
<nephele>
like flatpack, more complexity, and now i have apps that can't even launch on the steam deck because flatpack doesn't do locales correctly apparently
jmairboeck has quit [Ping timeout: 480 seconds]
<phschafft>
there are a few that I never clicked before, sure. like there are two for xterm. not sure why.
jmairboeck_ is now known as jmairboeck
<nephele>
phschafft: 37, with me already deleting about 6 or 7 entries, and me having installed 3 apps about
<nephele>
yes sure. but KDE already has a terminal emulator, i don't need xterm
<phschafft>
are you sure you didn't hit like 'just install everything there is' on OS install?
<nephele>
and it's more annoying because the menu is so fucking slow
<Hanicef[m]>
nephele: wayland is far more simpler than x11 was, but since stuff still depends on x11, we need to support both
<nephele>
I clicked the "KDE desktop" option in the debian installer...
<nephele>
Hanicef[m]: ?
<phschafft>
on mate the xterm entries are only there if xterm is installed. which I personally keep around.
<phschafft>
but totally safe to uninstall it.
<Begasus[m]>
x11 is on it's way out
<phschafft>
nephele: you mean in tasksel?
<Hanicef[m]>
there are cases where stuff are simplified, but it still only makes things worse because of backwards compatibility
<nephele>
phschafft: no clue what that is. i just used the debian installer
<Hanicef[m]>
wayland is one of those cases
<nephele>
Hanicef[m]: wayland is not really simpler, it's just different
<nephele>
in some cases it makes some stuff much much harder to implement
<phschafft>
nephele: my guess is that you click something strange in tasksel.
<Hanicef[m]>
Begasus[m]: yup, but there are still programs that depend on x11, hence why xwayland exists
<phschafft>
tasksel is a mess, but that is a tasksel problem, not a problem of the rest of the OS.
<Begasus[m]>
yeah, they are not done there (there was a feed not that long ago about this)
<Hanicef[m]>
nephele: x11 was abandoned because it was impossible to implement from scratch, and the only implementation left was brutally hard to maintain
<nephele>
phschafft: Okay. I'm telling you that i installed the OS normally. It can install stuff more than it needs. But there is no need for KDE to expose stuff like an editor for email headers in the menu instead of the mail app
<nephele>
Hanicef[m]: that's nonsense
<phschafft>
for a user that only wants software that he wants and no extras I recommend not to use tasksel and just install what you want.
<nephele>
there have been many different X11 implementations
<nephele>
Linux just doesn't *want* to maintain it
<nephele>
They totally could
<Hanicef[m]>
wayland, even if it's hard to implement, is possible, and we have multiple implementations of wayland thanks for that (wlroots, kwayland, whatever the name of the one gnome is using is)
<nephele>
Or they could have made an X12, straighten out the annoying parts of the protocol, which kind of was the plan with wayland, but instead it's something much different
<nephele>
Those only implement wayland because they needed to. On X11 there was no need for these programms to implement wayland
* phschafft
has used a number of X11 servers over the years...
<Hanicef[m]>
i agree, a stripped x11 would've been a better strategy
<nephele>
OpenBSD maintains their own Xorg server in tree for example
<nephele>
MacOS Had their own X11 server
<Hanicef[m]>
xorg is an implementation
<nephele>
There have been portable ones, etc
<nephele>
Hanicef[m]: yes, but i'm fairly certain it is forked from Xorg
<nephele>
in openbsd
<phschafft>
in the past when it was still a thing we used a X server that was running as java applet in a browser.
<Hanicef[m]>
i mean, the same is true for browsers: there are multiple implementations but all except gecko is based on chromium
<nephele>
you mean khtml? ;)
<Hanicef[m]>
same issue there: the specs are so complex that it's impossible to implement from scratch
<phschafft>
or the links and the dillo engine? ;)
<nephele>
As someone who uses 0 gecko or chromium browsers i kind of disagree with that
<OscarL>
Begasus[m]: will comment about adding that dep on llvm20, and see what korli shouts :-)
<nephele>
but for "the web" you have a much stronger argument of why it's too complex
<nephele>
for X11 not really
<phschafft>
naturally the specs are complex. partly because they grew, but partly also because people want to do complex stuff with them.
<Begasus[m]>
+1 OscarL
<Hanicef[m]>
phschafft: they don't work on all sites :)
<phschafft>
as long as the majority of people want highly advanced web applications the web standards will be complex.
<Hanicef[m]>
phschafft: in general, as long as the specification authors push back against complexity, it's fine
<phschafft>
Hanicef[m]: so? just because they don't work on all sites there are doesn't mean they aren't a valid, independent implementation.
<Hanicef[m]>
c is a great example of that
jmairboeck_ has joined #haiku
<phschafft>
Hanicef[m]: and they do. some of those new web standards are specifically to make things simpler.
<nephele>
the modern web sucks. sure. But that is mostly because of monopolistic exploits from google
<phschafft>
so, time for me do get my head back into this new specs I do to make yet another abstraction layer for stuff!
<nephele>
abstractions are leaky!
<Hanicef[m]>
phschafft: the issue is that these implementation will never reach broad use because they don't work for a lot of cases that people want it for
<nephele>
Some part in Haiku is simple because we don't have abstractions for everything ;)
<phschafft>
Hanicef[m]: so?
<nephele>
Hanicef[m]: I refuse to believe that adaption of software is mainly because of quality. That theory doesn't explain why most people use such slow garbage on their computer
<Hanicef[m]>
well, what's the point of standardization if there is only one implementation that everyone uses?
<phschafft>
so basically you draw a totally arbitrary line in the sand and then claim the problem is that only one thing is on your side of the line?
jmairboeck has quit [Ping timeout: 480 seconds]
jmairboeck_ is now known as jmairboeck
<Hanicef[m]>
phschafft: what arbitrary line? stardards exists so multiple implementations can cooperate
<phschafft>
I use links as an integral part of the set of software for daily use. so my line clearly includes it as a useful implementation.
<nephele>
you'd need the web spec *even* if you had only one web server and only one browser
<phschafft>
it's not complete in any way. but so are the others.
<nephele>
but that is not the situation we have, we have countless web browsers and servers
<phschafft>
no browser supports all of the standards.
<nephele>
phschafft: links2's caching behaviour is great tbh
<phschafft>
Hanicef[m]: yes, and links2 for example is powered by the very existance of those standards.
<nephele>
I *Love* that you can go back and have the prior page there instantly
<nephele>
I really want such functionalit
<phschafft>
without them is would not be possible to have that nice tool that helped me so often.
<phschafft>
nephele: :)
<nephele>
also, the only browser I know off that has display gamma calibration
<phschafft>
nephele: there are a few options in firefox you can set for a bit more aggressive caching. it is not that good, but it improves the situation.
<nephele>
phschafft: probably would try to implement this in WebPositive
* phschafft
nods.
<nephele>
We have insufficinet caching right now, hurting performance, so adding some is neccesary in any case. We can go full on mad with this, maybe with webkit2 archiving the page state on navigation, and then immidiently restoring it once you go back a page
<nephele>
maybe keep the -1 or -2 page in ram aswell
* phschafft
nods.
<phschafft>
just keep RAM usage in mind.
<phschafft>
so you might want something a little more dynamic. like go for at least one back state, but if you have room, allow for more to be in the history.
<phschafft>
like you use xxxMB for the history, and it is at least one entry long, but other than that it is as long as that amount of RAM can hold.
<phschafft>
waddlesplash: do you maybe know how many files bfs (on Haiku) can handle per directory before falling apart (hard limits, performance, ...)?
<nephele>
Hmm, I'd probably try to keep all session in memory as long as the application is running, maybe explicitly with SWAP or so
<phschafft>
nephele: then at least implement like in firefox where 'clear cache and history' also clears those states (that are otherwise hidden to the user).
<phschafft>
otherwise one would need to restart the browser to clear them when you run low on resources.
cassisian has quit [Remote host closed the connection]
JakeSays has joined #haiku
<nephele>
Uhh, why can't the OS just do that?
<nephele>
we already mark what stuff is or isn't cache iirc. so we can clear this out when needed, depending on the cache strategy selected
<phschafft>
if Haiku has a way to tell the process that it is low on RAM.
<phschafft>
such as... all mobile OS can do.
<phschafft>
sure, that would be nice.
mmu_man has joined #haiku
<nephele>
Android tells you nicely that it is low on RAM by killing you, right? :P
<nephele>
I think such a mechanism might exist, and if it doesn't. it should
<Hanicef[m]>
nephele: yup, that mechanism is called "overcommit" and comes from linux
<nephele>
No Hanicef[m]
<nephele>
that's something different
<phschafft>
nephele: no, you get a callback.
<nephele>
Hanicef[m]: also, we don't use overcommit like linux does
<Hanicef[m]>
yeah, i know that
JakeSays1 has quit [Ping timeout: 480 seconds]
<nephele>
if you want overcommited memory on Haiku you have to request it. And that is almost never the case
<nephele>
especially not if you want to allocate RAM for a cache. The semantics of "yeah but this might not work if you already have youe entire RAM filled" doesn't really match what we want here
<phschafft>
nephele: you could also consider having a memory flag so you can madvice() the kernel that it is allowed to remove a range, but only do the full range not parts of it.
<nephele>
we want webpositive to release RAM it uses when the OS tells it that it needs more memory, and webpositive should be able to decide what should be released
<phschafft>
and if you access again after the kernel removed you would read a freshly mapped range.
<nephele>
phschafft: maybe, but that seems a bit annoying from the application side and potentially racy
<nephele>
and wouldn't allow stuff like clearing older caches first
<phschafft>
so with just setting a single bit you could tell if the kernel removed it or not, and then load the state or drop it.
<phschafft>
to avoid the race you have the all-or-nothing contract.
<phschafft>
also as long as the range is mlock()ed or similar it is not allowed to be dropped.
<nephele>
This sounds simple, but seems much more complex in practice than just asking the application to drop some caches
<phschafft>
you would surely need to see what good specifics of such a contract would be, but I think the general idea could be useful.
<phschafft>
nephele: again, callbacks are also totall fine with me.
<phschafft>
even signals like ulimit soft limits.
<nephele>
you could even tell it how much it should roughly release, so we can decide how much cache to keep, and for webposivie how much to release maybe to disk instead of only evicting it
<phschafft>
if you make such a callback, consider however that it might be useful that the kernel can tell which resource it wants you to release.
<nephele>
such as=
<nephele>
?*
<phschafft>
it might not only be RAM. other resources can also become low supply.
<phschafft>
CPU, network, disk space, ...
<phschafft>
'we are now running on battery, please avoid unnecessary background work'
<phschafft>
'we are now on metered network, please avoid background downloads not required at this time'
<phschafft>
a browser for example may change load policy for off-screen elements if it knows that network is now metered.
<nephele>
those are both things that sound like the app should "just" discover
<nephele>
since that info is already available
cassisian has joined #haiku
Aedil has joined #haiku
<phschafft>
if that info is nicely available, sure. but it might be important to have a way to actively tell the application that state has changed.
<nephele>
metered connection would be something that the network interface should expose i think?
<phschafft>
all I'm asking is that if you implement something it should not be closed minded as 'in no possible way could requirements be different in the future!'
<nephele>
I'll totally be close minded ;)
<phschafft>
;)
<phschafft>
and that things should not be 'use this hugely compley and resource heavy API to poll every 1ms if we are low on power'
<phschafft>
;)
<nephele>
are we yet?
<nephele>
I think i should poll for low power every 200NS on a desktop computer
<nephele>
you know, to quicker respond, when someone pulls the plug from the PSU :)
<phschafft>
sounds like a good plan!
<Begasus[m]>
OscarL: almost done! :)
<OscarL>
nodejs?
<Begasus[m]>
yep
<Begasus[m]>
mimesetting files for package nodejs20_x86_source-20.15.1-2-source.hpkg ...
<OscarL>
noice.
<Begasus[m]>
:P
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #haiku
Nasina has quit [Read error: Connection reset by peer]
<Begasus[m]>
oh, Qt6.9.1 release ... QtCreator 17.0.0 RC out ....
Nasina has joined #haiku
mmu_man has quit [Ping timeout: 480 seconds]
cassisian has quit [Remote host closed the connection]
mmu_man has joined #haiku
cassisian has joined #haiku
<OscarL>
Begasus[m]: remind me, please... what was the veredict on qgis? using python3.10 was ok for 3.24.3 at least, no?
<OscarL>
if so, maybe we can just do s/python3.9/python3.10/ on that recipe, without a rev-bump?
<OscarL>
Also... what's your opinion about dropping the Blender-2.79b recipe? (already disabled for all platforms)
<Begasus[m]>
I think qgis was fine for python3.10 (need to re-check that)
* OscarL
want to get 0 results for "inrecipe python3.9" soon :-P
<Begasus[m]>
about blender, I would launch a topic at least on the forum for it
<nephele>
why? you don't like python? :P
<Begasus[m]>
heh
<OscarL>
I'll see if I can tackle fife, to move it to 3.10.
<OscarL>
(I'm tempted to just drop fife, as I can't find any good use for it but... :-D)
<Begasus[m]>
isn't fife part of Haiku?
<Begasus[m]>
or was that "file" ... me got lost ...
<OscarL>
is an isometric game engine that moslty targets python users, so I doubt Haiku depends on fife :-P
<Begasus[m]>
;)
<OscarL>
re: blender, we could, but what would be the expectation there? for someone to volunteer to revive/maintain that version for 32 bits?
Nasina has quit [Read error: Connection reset by peer]
<Begasus[m]>
maybe I'll try to tackle qt6_tools to split the lib vs apps for this version :)
<Begasus[m]>
if any out there is still using it OscarL ?
<Begasus[m]>
not a user myself for it, but iirc blender2 ran smoother then blender3?
<OscarL>
if they already have a .hpkg, I guess. but the recipe has been disabled for 32 bits already. Do repos still have it for download?
<Begasus[m]>
there is still the 64bit package for it
<OscarL>
getting 404 on depot :-/
<Begasus[m]>
packaging qt6_base atm, will check in a bit
<OscarL>
I only see 3.3.21 on 64 bits.
<Begasus[m]>
pkgman also no listing?
<OscarL>
that's with pkgman search blender
<Begasus[m]>
ah :)
Nasina has joined #haiku
<OscarL>
(no blender results on Haiku depot server for 32 bits)
<OscarL>
nephele: re: liking python. not much the packaging side of it, no :-D
<Begasus[m]>
you could try fixing this for llvm20 OscarL ? :P
<OscarL>
yeah, just let me hook up first all the crappy Atom N4xx netbooks I have lying around, and build a "Beowolf cluster" for compiling purposes!
<OscarL>
(might end up being about 0.2 the speed of this slow Celeron N4020 :-D)
<Begasus[m]>
;)
<Begasus[m]>
or just add one line in the recipe (or 2) and push it to the buildmaster :P
Nasina has quit [Read error: Connection reset by peer]
<Begasus[m]>
grabbing qt6_base-6.9.1-1-x86_64.hpkg and moving it to /Opslag/haikuports/packages/qt6_base-6.9.1-1-x86_64.hpkg
<OscarL>
I might do that one of these days... but I'll prolly start with something less likely to get me getting cursed at by korli :-P
nephele has quit [Quit: Vision[]: i've been blurred!]
cassisian has quit [Remote host closed the connection]
cassisian has joined #haiku
mmu_man has quit [Ping timeout: 480 seconds]
mmu_man has joined #haiku
<OscarL>
Begasus[m]: I think korli means that using $portVersion as a constraint is not enoug, as revision 1 of the package (that people might still have installed) would also match, but as this breakage shows, we would have needed the full "20.1.4-2" (version+revision) to match.
<Begasus[m]>
-- Starting SBOM generation in build dir: /sources/qtdeclarative-everywhere-src-6.9.1/build/qt_sbom/staging-qtdeclarative.spdx.in
<Begasus[m]>
glad this is working :)
<Begasus[m]>
hmm ... dangerous combination I think OscarL
<Begasus[m]>
could easaly be missed when updating?
<Begasus[m]>
can it even work? (don't think we've got one where this is already required?)
mmu_man has quit [Ping timeout: 480 seconds]
<OscarL>
no idea if revisions can be used to enforce constraints. (but regarding "missing them when updating", I think "$portVersion-$REVISION" should work at least).
<Begasus[m]>
how about cycling dependency as _libs already require base? (haven't looked into the recipe yet, but my guess is that it is depending on it)
<OscarL>
I don't see "_libs" requiring the base package.
<OscarL>
it only requires Haiku and lib:libz
<OscarL>
base package is a bit weird, because it includes the cli "tools", plus devel stuff. normally, one would expect both _devel and "_tools" to depend on base, if base was the one providing the libs.
<Begasus[m]>
k, see it now too
<Begasus[m]>
yeah, caught my eye too, I'm not fiddling too much in there though :P
mmu_man has joined #haiku
<OscarL>
makes sense to be able to install only the libs (for mesa for example), and nothing for development (ends user wouldn't need any of that :-D)
<Begasus[m]>
seeing it like that it makes sense for the missing symbol
<OscarL>
but the fact that base doesn't depends on the libs sounds pretty wrong.
<Begasus[m]>
right, but the cmd's should require libs
<OscarL>
(even if it would still not help with this particular breackage)
<OscarL>
(as the break was after a new revision added a bunch of new targets)
<Begasus[m]>
even with the devel: in there it should
<OscarL>
right
<Begasus[m]>
looks more like _libs is the actual "base" package
<OscarL>
kinda, yes.
nephele has joined #haiku
<Begasus[m]>
_clang already has this cmd + lib
<Begasus[m]>
so the issue here is more like can or will pkgman install _libs and update base when revision is still at 1?
<OscarL>
no idea, would still be an improvement over current situation.
<OscarL>
did nephele even had the previous version of the libs?
<OscarL>
if no... pretty clear sign the llvm20 package is just broken.
<OscarL>
(its dependencies, I mean)
<nephele>
i had one thing on revision 1 and the other newly installed one on revision 2 OscarL
<OscarL>
I see.
<phschafft>
and he is back.
<Begasus[m]>
so could be the missing symbol wasn't/isn't present in revision 1
<Begasus[m]>
nephele: did the one with revision 1 updated when you installed the _libs package?
<nephele>
Which one when?
<Begasus[m]>
1 you got a missing symbol 2 fix was to install the _libs package
<Begasus[m]>
so did the base llvm20 still had revision1?
<Begasus[m]>
OscarL: speaking of, the missing symbol probably originates from the library (would make sense?), so if installing _libs you will get revision 2 anyway
<nephele>
the package containing llvm-ar had revision -2 the other had revision -1
<Begasus[m]>
ah OK, so the symbol was missing in revision 1 from _libs then
* OscarL
tries to pkginstall llvm20 (just to see what it would pull down)
<OscarL>
so... llvm20 ends up requiring the "_libs" package in a very roundabout way... by requiring clang, which requires libLLVM
Guest14842 has left #haiku [#haiku]
<nephele>
is llvm-ld an alias that used to exist for lld?
<Begasus[m]>
ah right OscarL so it's actually already in there, but doesn't seem to be picky on which _libs it sees?
Guest14842 has joined #haiku
<OscarL>
not regarding the revision, no.
<Begasus[m]>
nor any portVersion
<Begasus[m]>
just has lib:libLLVM$secondaryArchSuffix
<Begasus[m]>
nephele: no idea there
<OscarL>
welll, pkgman shows that lib:libclang *does* wants >= 20.1.54
<OscarL>
*libclang_cpp
<nephele>
this was a fault between specific revisions of the package though
<nephele>
and not the version only
<Begasus[m]>
it's a wonder those base packages don't conflict with eachother
<nephele>
so unless this pins the revision it's probably not working the same
<OscarL>
but I kinda thinking that it would be better if requirements were more direct/explicit (and also could take the revision as constraint)
<Begasus[m]>
OscarL: maybe those libraries in the _libs section could use a portVersionCompat?
<Begasus[m]>
keeping an eye on the Qt build processes here also, so can mix somethings up in between :)
<OscarL>
Begasus[m]: FWIW, I can't install llvm20 without having to uninstall YouCompleteMe, because it want to unninstall llvm16... because you know... requiring >= 16.x is not satisfied by having llvm >= 20.x :-/
<Begasus[m]>
I'm not a fan of using $REVISION to add to $portVersion (but that's just me) :)
<nephele>
How can I save that gvim uses the "industry" colorscheme by default?
<Begasus[m]>
don't have YCM installed here, so no issue for me :P
<Begasus[m]>
up it to llvm20 OscarL ?
* OscarL
still can't wrap his head around that one (llvm20 not being able to satisfy the >= 16 constraint)
<OscarL>
I rather have packagekit version constraints be less weird on that regard.
<nephele>
iirc the ">=" doesn't mean what you think it does
<Begasus[m]>
that's wrong, it shouldn't use >= there
<OscarL>
nephele: yes :-D, but I keep forgetting that, because is is far from being intuitive.
<OscarL>
"how the hell 20.x isn't a valid answer for >= 16.x !"--- turns out it kinda only means it 16.2 and 16.9 will work, but 17.0 won't, right?
<Begasus[m]>
the more I look into the recipe/packages the more I get confused :P
<nephele>
OscarL: maybe this is from the wierd idea that a new major version is a API breaking thing.... :)
<OscarL>
"semver was a mistake"
<Begasus[m]>
cmd:clang >= 16 for Genio still ok with 20
<OscarL>
:^P
<OscarL>
Begasus[m]: really? it didn't worked last times I've tried (had to modify the package locally in the past... haven't tried with newer one, though)
<Begasus[m]>
I only have clang20 installed
<OscarL>
and you installed Genio while only having that one installed?
<Begasus[m]>
granted I build the latest PR for genio :)
<OscarL>
(as in... after you had llvm20, as opposed to: have llvm16, install genio, then update to llvm20)
<Begasus[m]>
install package genio-4.0-1 from repository HaikuPorts
<Begasus[m]>
no error on the installed clang
<Begasus[m]>
not installing llvm16 to check :P
<Begasus[m]>
that llvm12 still poking me in the eye :P
<OscarL>
no problem. welp, if it works... better that way. I know I cursed it a lot in the past.
<OscarL>
shouldn't we drop the older genio recipe?
<Begasus[m]>
yeah I know
<Begasus[m]>
there is still a PR atm to include support for the documentation
FreeFull has quit []
<Begasus[m]>
but yes, older is obsolete anyway
<nephele>
i have a intel arc now. maybe we can add support for it in the intel driver
<Begasus[m]>
genio? or llvm? support in the intel driver? ;)
* Begasus[m]
ducks
<nephele>
intel arc is a name of a group of graphics card
<Begasus[m]>
wasn't sure nephele (hence me trying to make a joke) :)
<jmairboeck>
OscarL: the >= in version constraints isn't >= in the mathematical sense. ">= x" is satisfied by any version x.y.z but not anything that has not x as its first part. ">= x.y" means that x and y have to match but it can have any z part.
<Begasus[m]>
out of practice on hardware here
<OscarL>
(/me re-reads logs). Begasus[m] you said youcompleteme should not use >= 16 (via $CLANG_VERSION). but I don't think it will work with older. if that's wrong..... why Genio using cmd:clang >= 16 is OK then?
<jmairboeck>
on the contrary, when using just = it wouldn't match with sub-versions that aren't 0
<OscarL>
(asking because I really don't know if there's subtleties I'm just missing)
<Begasus[m]>
well it probably doesn't fix anything OscarL , but it's not how we use version strings in recipes
<jmairboeck>
but it isn't really clear about the operators and their exact meaning
<Begasus[m]>
bookmarked for now :)
<OscarL>
bloddy "supplements" is in there, MF! :-)
<Begasus[m]>
yeah ;)
<OscarL>
hate that thing :-P
<Begasus[m]>
too much input for my brains now :P
<OscarL>
oh... "freshens"...would be cool if that worked, to update "broken" setting files when updating.
mmu_man has quit [Ping timeout: 480 seconds]
<OscarL>
Thanks for the link jmairboeck.
<OscarL>
I'll try to take some notes and maybe add some "for dummies" version on the haikuports wiki.
<Begasus[m]>
+1 from here too
HaikuUser has joined #haiku
HaikuUser has quit []
<Begasus[m]>
woot! nim finished on 32bit already OscarL :D
<OscarL>
so... we *can* have revisions in provides/requires (if those are enforced... TBD).
HaikuUser has joined #haiku
HaikuUser has quit []
<OscarL>
Begasus[m]: at least some good news :-)
mmu_man has joined #haiku
<Begasus[m]>
yeah, 2 buggers down :D
<OscarL>
now do blender 32 bits! /me ducks
<Begasus[m]>
and update on nodejs not going anywhere anytime soon
<Begasus[m]>
not touching that monster :P
<bjorkintosh>
may I ask, is there a benefit to the 32bit versions?
* Begasus[m]
writes it down in local todo list in capitals NOGOBLENDER
<Begasus[m]>
I guess it comes down to personal hardware bjorkintosh , up to a few years back I was mainly busy on 32bit
<OscarL>
bjorkintosh: from my side... none. But many users still use only the 32 bits version for BeOS compat.
<OscarL>
for the ones running on 32-bits only hardware... little sense on using these "monster apps" anyway.
<bjorkintosh>
hmm.
<Begasus[m]>
right on that one
<bjorkintosh>
but shouldn't it be an automatic process.
<bjorkintosh>
write for 64 bit, automatically adjust for 32?
<bjorkintosh>
or vice-versa
<OscarL>
in an ideal world? yes. In practice? many (most?) upstreams barely even tests on 32 bits anymore, so bugs abound.
<bjorkintosh>
so it helps with robustness then?
<OscarL>
add that the fact that we're a niche platform... and you are bound to face many corner cases.
<bjorkintosh>
well.
<bjorkintosh>
I think it's great.
<OscarL>
could, if our patches are clean enough to be sent upstream, and they care enough at to merge them.
<Begasus[m]>
and a few idiots like us around :)
<bjorkintosh>
I'm all about niche platforms. I've been running medos (modula 2) on lilith lately
<bjorkintosh>
all emulated of course.
<Begasus[m]>
OscarL: plenty of patches are still fine to upstream, just no one cared to do it
<OscarL>
right, issue is... in can be a drag to have to interact with some upstreams.
<Begasus[m]>
it used to be like that years ago, Haiku has gained a lot of interest and upstream noticed that too
<OscarL>
some are pretty cool... others are a bit bitchy... others you need to sign forms, and jump through several hoops before being able to contribute.
<Begasus[m]>
so aside from a few, they are more open to it now
<Begasus[m]>
the last one is a bitch yes OscarL
<Begasus[m]>
tried that for ICU, to no aveal :(
<OscarL>
In my case... I shy away of sending patches to "big" projects... because I'm just not skilled enough to answer follow up questions (or at least it induces a level of anxiety I rather avoid :-D)
<Begasus[m]>
fpc, no response ...
<Begasus[m]>
lol
<Begasus[m]>
right there with you OscarL , specially if I didn't know what I did even though it fixed the thing at hand :)
<OscarL>
I may try to clean up the Python .patchsets more for someone else to send, for example... I'm *not* interacting with the python foundation anytime soone :-)
<Begasus[m]>
but it helps if you present them with the actual error you run against
<Begasus[m]>
maybe they even have a better solution then you already had (did a few times in my case)
<OscarL>
Begasus[m]: we should contact nodejs about our latest 32 bits hacking session :-P
<OscarL>
and they will send us up to google (for that v8 related changes). "Fun" :-)
<bjorkintosh>
is there anyway I could steal the beos icons and look?
<bjorkintosh>
it is so beautiful.
<bjorkintosh>
the whole theme is so well thought out.
<OscarL>
I remember "stealing" Haiku's icon (in bitmap form), to make a Nokia 5200 theme. Looked gorgeous :-)
<Begasus[m]>
latest nodejs24 should build first OscarL :)
<Begasus[m]>
I had my ZETA look like OSX :P
<OscarL>
bjorkintosh: depends on what platform you're running I guess... I remember some BeOS inspired themes for at least some older Qt/KDE, and some window mananger I can't quite remembe the name of.
<Begasus[m]>
it was pretty easy there to create icon themes
<OscarL>
There was a ZevenOS too.
<Begasus[m]>
yeah, linux made BeOS alike
<Begasus[m]>
wasn't that from Ralf?
<OscarL>
"Openbox" I think was one window-manager that had BeOS-inspired decorations at least.
<Begasus[m]>
doesn't ring a bell here
* phschafft
adds cat ears to windows.
<OscarL>
openbox was mosly used as the wm part of other full "deskops".
<nephele>
phschafft: I used to have a window sitter on linux
<phschafft>
hm?
<nephele>
a character that sits on your window in X11
<phschafft>
uh, fun.
<OscarL>
I kinda recall one that was a little cat that "slept" on the taskbar, will chase the mouse cursor, and also jump around over the window's title bars.
<phschafft>
:)
flag has joined #haiku
<OscarL>
Begasus[m]: Mmm, was about to directly push to master for the first time... got nervous and opened a branch/pr instead :-P
<OscarL>
Begasus[m]: looking at fixing the YCM recipe issues now. Removed the >=$CLANG_VERSION from the "lib:clang" requires (left it only on devel:). sounds OK/enough?
<Begasus[m]>
whohoo OscarL ! your first merge!
<OscarL>
yeah! finally got to hit the green button :-P
<Begasus>
have to make changes to the qt6_multimedia patch/source, check if it works for YCM OscarL :)
<Begasus>
otherwise I'm going into overload :P
<OscarL>
no problem, just asking in case you remembered something else just off the top of your head.
jmairboeck_ has quit [Ping timeout: 480 seconds]
<OscarL>
first proper haikuports build on the N4020... let's see how it goes.
<Habbie>
nice
<Begasus>
brain is already haiwire here OscarL :)
<Begasus>
input/output code has changed in qt6_multimedia
<OscarL>
makes the host OS quite a bit sluggish... might need to use -j1, or just leave it be while building :-D
<Begasus>
at least the part we're patching atm :P
<OscarL>
temps seems to max out at 83ºC and throttles down. As long as it doesn't gets any hotter. I'm cool with that.
<OscarL>
k, removed the >= from lib: requires. and resulting package has: "lib:libclang >= 16.0.6". sounds about right.
<OscarL>
weirdly, the "lib:libabsl_base" requirement on .PackageInfo doesn't has a version (while all the rest of requirements do)
<OscarL>
heh, "haiku" requieres *do* include the package revision :-)
<Begasus>
checked provides in abseil_cpp?
<OscarL>
will do.
<Begasus>
that I knew kinda (thirdparty lib in nodejs24) :)
<OscarL>
damn unset variables (noticed a broken provides)
<Begasus>
no version set?
<OscarL>
had the wrong variable name.
<Begasus>
ouch
<OscarL>
(on the YCM, haven't looked at abseil yet)
<Begasus>
those things tend to back slash when changed
<OscarL>
after a quick search... shouldn't haikuporter run with "set -o nounset" to avoid such errors?
<Begasus>
don't ask me, that's one for jmairboeck :)
<OscarL>
right :-)
Forza has joined #haiku
<OscarL>
one thing I would change in Python too.... make variable declarations explicit. "let x = foobar" can't be that hard.
<nephele>
why are you using python then? ;)
<bjorkintosh>
nephele: w$rk is usually the reason.
<OscarL>
I needed an out from dealing with a nightmare inducing WSH (VBscript mostly) work environment at the time :-)
<OscarL>
and even effin VBscript had an "option explicit" mode :-)
<OscarL>
3 different abseil_cpp versions on repo. "nice" :-/
<nephele>
I'm so happy this gpu now works
<nephele>
i can even reboot the system and get video output
<Begasus>
at least there is this new team member to help out with cleaning ;)
<OscarL>
yeah... should get that guy working already!
gouchi has joined #haiku
<phschafft>
I was always wondering how that implicit stuff came to be. I mean it's old. and back in the day computers were way more limited than today.
<phschafft>
so one would think that explicit stuff would have been the way to go, to allow easier memory management.
<OscarL>
(after looing up the specs of Arc A750... 225W TDP. whoop! /me would like a A310 or A380 at 75W though)
<Begasus>
Begasus confirmed it builds and runs OK (thanks!). tsss :P
<OscarL>
needed to have someone to blame, you see.
<Begasus>
right, hence I've put your credits in the nodejs20 patch :P
<OscarL>
gotcha.... I learned from the best :-)
<Begasus>
lol
<Begasus>
grabbing qt6_multimedia-6.9.1-1-x86_64.hpkg and moving it to /Opslag/haikuports/packages/qt6_multimedia-6.9.1-1-x86_64.hpkg
<Begasus>
another one down ...
* Begasus
hopes to have some sound output later ...
<OscarL>
phschafft: right. and on more modern times... one would think that avoiding such obvious footguns would be a no-brainer... seems they had no-brains indeed.
* phschafft
nods.
<phschafft>
what I find specifically strange is that most languages have no concept of read only data.
<phschafft>
but many have keywords for things that are just a tiny bit similar.
<nephele>
heh, in Lua you can just mod yourself in support for this stuff :)
<nephele>
have a project that explicitly errors out if you try to work with a global variable that hasen't been declared before
<nephele>
handy if you keep mispelling variables
<nephele>
(and wanted to work with a local variable, but used a global one because of mispelling it...)
frkazoid333 has joined #haiku
gouchi has quit [Quit: Quitte]
<OscarL>
nephele: on python, one can install a custom charset-decoder, and have that instead parse files in some custom syntax and sphew something Python can understand. I remember one that allowed you to use Lua syntax, for example :-D
<OscarL>
"lib:libabsl_base = 2301.0.0 compat >= 2301.0.0" <<< from abseil_cpp-20230125.3-1-x86_64.hpkg, and similar for the devel: / _devel.hpkg pair. So that looks ok at least.
erysdren has quit [Quit: Konversation terminated!]
cassisian has quit [Remote host closed the connection]
erysdren has joined #haiku
cassisian has joined #haiku
<Begasus>
k, still output with qt6_multimedia, I didn't screw everything :P
Begasus has quit [Quit: Vision[]: i've been blurred!]
<Begasus[m]>
back in NeoChat :)
cassisian has quit [Ping timeout: 480 seconds]
Guest14842 has left #haiku [#haiku]
Guest14842 has joined #haiku
deneel has joined #haiku
Anarchos has joined #haiku
<Begasus[m]>
closing down here
<Begasus[m]>
cu peeps
gouchi has joined #haiku
gouchi has quit [Remote host closed the connection]
erysdren has quit [Quit: Konversation terminated!]
mmu_man has quit [Read error: Connection reset by peer]
nephele has quit [Quit: Vision[]: i've been blurred!]
Anarchos has quit [Quit: Vision[]: i've been blurred!]
nephele has joined #haiku
Anarchos has joined #haiku
<Anarchos>
Interesting : since i installed/uninstall my home-made haiku package, the logo in AboutSystem is blocked on Walter after each pkgman update :)
Aedil has quit [Quit: leaving]
<nephele>
this depends on if you compiled haiku with branding or not
<Anarchos>
nephele no, to use the walter logo to see if i was on my local or official version
<Anarchos>
nephele but i uninstalled it ! And the walter logo persists
<OscarL>
Anarchos: if you have more than one copy of AboutSystem anywhere, it might be starting that one up.
<nephele>
why would it?
<nephele>
if that is the case you can verify this with listimage in any case
<OscarL>
dunno, but it does pretty frequently.
<nephele>
deskbar does?
<OscarL>
"query AboutSystem" anarchos.
<OscarL>
nephele: yes.
<Anarchos>
indeed i still have the old AboutSystem in «/boot/home/HAIKU/haiku/generated/objects/haiku/x86_64/release/apps/aboutsystem/AboutSystem»
<nephele>
sounds like a bug Anarchos
<nephele>
err OscarL
<nephele>
i ment
<Anarchos>
but weird it is launched before the /system one !
<OscarL>
it uses app signature to start it, IIRC.
<OscarL>
uses whatever it finds first.
<OscarL>
Anarchos: remove the one from objects... you should get rid of that walter icon at last :-)
<nephele>
rather fix the bug... :)
<OscarL>
nephele: meh... I rather try to stop Open with.. showing a bazillion copies of crap I don't want :-)
<nephele>
Sure, you can do that
<OscarL>
I sure *wish* I could do that, at least :-P
<nephele>
why wouldn't you be able to?
<OscarL>
Mainly... problems getting focused long enough to understand how to, I guess.
nephele_ has joined #haiku
nephele is now known as Guest17704
nephele_ is now known as nephele
Guest17704 has quit [Quit: Vision[]: i've been blurred!]
dodo75 has quit [Quit: Vision[]: i've been blurred!]
<Anarchos>
OscarL but why is roster registering the AboutSystem from ~/<subfolders> instead of /system ?
dodo75 has joined #haiku
<OscarL>
since BeOS days, if you have more than one app with the same signature... you may not be getting the one you expect. I'm not sure how they get sorted... but results are at least consistent between runs/reboots.
<Anarchos>
OscarL it makes sense to privilege ~ ones over /system, or else you could never test local version !
<Anarchos>
OscarL but i would prefer roster to respect $PATH
<nephele>
not really. you should not run this stuff over signatures at all
<nephele>
it's usefull if you need a specific app, to open a file with
<Anarchos>
nephele i just run it from Deskbar !
<OscarL>
heh, in src/kits/app/Roster.cpp, many doc-comments mention "\see FindApp() for how the application is searched.", but BRoaster::FindApp() has no docs at all :-D
<OscarL>
s/BRoaster/BRoster/
chilledfrogs has quit [Quit: connection reset by purr]
gouchi has quit [Remote host closed the connection]
<scanty>
OscarL: BRoaster::FindMeat() plz :^)
<OscarL>
hey there scanty! yeah, was thinking along those lines when I noticed my typo :-D
<scanty>
OscarL: i worked on keywords.asm in Pe (the one you started), now there are over 1400 instructions, and all NASM/YASM keywords have highlighting.
<scanty>
OscarL: yeah, i was going to actually ask you how to do that, but i have to run out for some errands right now.
<scanty>
i will look for you later
* Anarchos
wonder if somebody remembers BeTeX
<OscarL>
(I used to have merge rights on the Pe repo, but seems I lost them when its repo got moved from olta's to HaikuArchive)
<scanty>
ah
<scanty>
ok bbl.
<OscarL>
scanty: in any case, I guess I could open a PR on your behalf.
<OscarL>
later!
<scanty>
i'll let you know.
<OscarL>
Anarchos: I remember the name and icon from the old days, but never was much of a TeX user myself.
<OscarL>
I *think* I used BeTeX once or twice as a .ps viewer (or maybe I'm mixsing up with some other app that used ghostscript ?)
* OscarL
stripts a 8 MiB .so... ends up with a 88 KiB. Mmm.
<OscarL>
*strips
<Habbie>
i remember when stripping .so files made your system unbootable!
<Habbie>
fun times.
arti_ has quit []
arti has joined #haiku
<OscarL>
lol, yeah... happened once to me... was pretty happy getting more free space for free... until kaput.
<OscarL>
extensive use of upx also comes to mind, when trying to squeeze some life out of a tiny 640 MB HDD.
<Habbie>
hehe
<nephele>
I wish debug symbols would actually work
<nephele>
I don't understand why you can't always install debug symbols for the betas and stuff
<nephele>
Instead the stuff seems compiled that debugger just gives up, and can't even be made to use source files
<OscarL>
I guess is a mix of changes in compilers and/or debug info formats/versions, and not having someone like Rene keeping up Debugger "up to speed" and fixing bugs in it.
cassisian has joined #haiku
cassisian has quit [Ping timeout: 480 seconds]
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
OrangeBomb has quit [Quit: Slacking off]
OrangeBomb has joined #haiku
jmairboeck has quit [Quit: Konversation terminated!]
nephele has quit [Quit: Vision[]: i've been blurred!]
cassisian has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
HaikuUser has joined #haiku
cassisian has quit [Ping timeout: 480 seconds]
HaikuUser has quit []
AndrevS has quit [Quit: umount /dev/irc]
OscarL has quit [Remote host closed the connection]
Anarchos has quit [Quit: Vision[]: i've been blurred!]
Nasina has joined #haiku
<PulkoMandy>
Works just fine when I use it, so I can't fix it...
<PulkoMandy>
I think the thing nephele is complaining about is the lack of a debuginfo package for haiku itself. Which isn't really a Debugger problem, you could use gdb and have the same issue
cassisian has joined #haiku
neoncortex has quit []
cassisian has quit [Ping timeout: 480 seconds]
Nasina has quit [Read error: Connection reset by peer]
cassisian has joined #haiku
vdamewood has joined #haiku
Nasina has joined #haiku
Nasina has quit [Remote host closed the connection]
Nasina has joined #haiku
Nasina has quit [Ping timeout: 480 seconds]
Nasina has joined #haiku
cassisian has quit [Remote host closed the connection]
bjorkintosh has quit [Ping timeout: 480 seconds]
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
cassisian has joined #haiku
Nasina has quit [Ping timeout: 480 seconds]
HaikuUser has joined #haiku
HaikuUser has quit []
Nasina has joined #haiku
Nasina has quit [Read error: Connection reset by peer]