frkzoid has quit [Read error: Connection reset by peer]
frkzoid has joined #haiku
OscarL has joined #haiku
<OscarL>
Aloha folks.
<OscarL>
Sark: were you really wanting to mess around with Haikuporter+recipes, or you just wan't to be able to use pycrypotodome and be done with it? (asking because if the latter... I would suggest you just wait a bit longer, and you should be able to just do "pgkman install pycryptodome_python39").
<OscarL>
*pkgman.... my legenday typing skills showing up again. Sigh.
<OscarL>
*legendary, darn it!
<Sark>
Ah! Welcome back OscarL! I mean, the goal is to get pycryptodome to work so I can use my code on Haiku, but I also wanted to know how haikuporter worked. The actual process seems fairly logical, even if GitHub's user interface is crap. lol
<OscarL>
ok, I was just reading the logs, and I felt the pain... and I thought.... I bet he misses his "pip install" :-D
<Sark>
haha
<OscarL>
The thing is Sark, at least as far as I can tell...
<Sark>
I mean, building stuff with haikuports shouldn't be terrible, the most convoluted part is that GitHub doesn't have a "download" option, and Web doesn't have a "save".
<OscarL>
as many Python packages never get tested on Haiku.... most are not even aware of it...
<OscarL>
you can't just simply "pip install" them as you do on supported platforms.
<Sark>
So it's either cut and paste all the text out of files that are convoluted to get the full version of out of GitHub... or wget individual files once you decrypt the bass-ackwards GitHub user interface enough to find the link to the actual file :)
<OscarL>
And you neeed instead to rely on the Haikuports provided ones (that are patched/configured to work on Haiku).
<OscarL>
not ideal... because you also don't wanto do do "apt_get pycryptodome" on your Linux installs (unless it is needed for system stuff), but..
<OscarL>
the only other alternative is getting the fixes merged upstream, and as Haiku is so little known, that not always works.
<Sark>
Yeah. Ideally the python packages all get handled through pip - I guess I should probably just wait until it's updated, and not risk breaking something by manually building it outside of python
<OscarL>
The fix for pycryptodome is farly small... I might attempt to upstream that... but even if they accept it... you'll sill need to wait for a new release from them to get it :-)
<OscarL>
with some luck... Begasus and I would be able to iron out the details, and packages should be ready "Really Soon Now" (tm).
<OscarL>
(the "convoluted" part regarding Github is that you're supposed to use "git" to work with the repos most of the time :-D) But that's another can of worms... and why I was wondering if you were REALLY into doing this :-P
* OscarL
starts his VM to give that recipe another go.
<OscarL>
Sark: just in case you trust random beta quality packages from strangers... https://gofile.io/d/DQRV95
<OscarL>
Double clicking each of them should open a HaikuDepot window with an "install" button on the top right. After you dismiss the dialog that will appear then, you should be able to "import Crypto" and "import Cryptodome" from your Python 3.9 interpreter.
Kokito has joined #haiku
<Sark>
Awesome! Thanks! Yeah, that'll be a big help :) And then when they're available in pip I should be able to do that too and keep up to date, right?
<OscarL>
these packages won't be availble via PIP unless the bugfix gets accepted by the pycryptodome developers.
<OscarL>
theses are just regular .hpkg files, and will receive the same treatment as all HaikuPort stuff... get updated when someone finds the time to do it :-P
<Sark>
hehe
<Sark>
Thanks again for your help - I'll definitely play with this tonight, hopefully I can get my stuff going :)
<OscarL>
Good luck with that, and report back!
<Sark>
Thanks! Will do!
Kokito has quit [Quit: Vision[]: i've been blurred!]
rennj has quit [Ping timeout: 480 seconds]
Kokito has joined #haiku
Kokito has quit []
rennj has joined #haiku
mmu_man has quit [Ping timeout: 480 seconds]
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
bbjimmy has joined #haiku
rennj has quit [Ping timeout: 480 seconds]
rennj has joined #haiku
freakazoid332 has joined #haiku
bbjimmy has quit [Read error: Connection reset by peer]
frkzoid has quit [Ping timeout: 480 seconds]
frkzoid has joined #haiku
Maturi0n_ has joined #haiku
freakazoid332 has quit [Ping timeout: 480 seconds]
rennj has quit [Ping timeout: 480 seconds]
mtsfz2 has quit [Remote host closed the connection]
mtsfz2 has joined #haiku
Maturi0n has quit [Ping timeout: 480 seconds]
kikadf has joined #haiku
rennj has joined #haiku
Guest2 has quit [Ping timeout: 480 seconds]
rennj has quit [Ping timeout: 480 seconds]
x10z has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rennj has joined #haiku
smokku has joined #haiku
smoku has quit [Read error: Connection reset by peer]
x10z has joined #haiku
rennj has quit [Ping timeout: 480 seconds]
bbjimmy has joined #haiku
rennj has joined #haiku
x10z has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
freakazoid332 has joined #haiku
rennj has quit [Ping timeout: 480 seconds]
frkzoid has quit [Ping timeout: 480 seconds]
rennj has joined #haiku
floof58 has quit [Remote host closed the connection]
floof58 has joined #haiku
rennj has quit [Ping timeout: 480 seconds]
x10z has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
rennj has joined #haiku
HaikuUser has joined #haiku
<rennj>
just include a local cache of haikudepot/this constant loading it painful....
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
<Begasus>
it's not required for all python packages :)
<OscarL>
sure. but... woudlnn't it fit better to keep it grouped with the "default" ones, like "BUILD_REQUIRES" and the ones above?
<OscarL>
not that it would change much, I guess, and I'll do as you suggest, just double checking :-)
* OscarL
goes to check the guidelines
<Begasus>
hmm
<Begasus>
don't think there is an official rule there (yet) for python recipes
<OscarL>
not much help there, no :-D
<OscarL>
My intention, if any... was to follow the recomended ordering, but first for the "default" packages, and then do the same inside the "package loop".
<OscarL>
Well, with TEST at the bottom, it seems, KOK.
<OscarL>
*LOL
<Begasus>
;)
<Begasus>
it works * :P
<Begasus>
For my point of view, I'd like to keep BUILD_REQUIRES and BUILD_PREREQUIRES in the loop (so I need to correct myself and put haiku_devel in there too :P
<OscarL>
maybe TEST_REQUIRES is the one that should be moved on top of the package loop... dunno.
<Begasus_32>
src/DES.c:42:10: fatal error: tomcrypt.h: No such file or directory
<Begasus>
lol, first clean ... then rebuild ...
<Begasus>
No that should stay
<Begasus>
if you would build multiple python versions, you would still need only one to build the tests
<OscarL>
ah... I see that inside the loop I have "BUILD_REQUIRES=" and NOT "BUILD_REQUIRES_$pythonPackage=" or something.... yes... I see what you mean now.
<OscarL>
(regarding moving tha BUILD_PREREQUIRES)
<Begasus>
yeah, those are not stricktly bound to the python version, that's taken care of upfront
illwieckz has quit [Ping timeout: 480 seconds]
<Begasus_32>
License 'Unlicense' isn't contained in package!
<Begasus>
Ha! that was what Sark saw yesterday
<Begasus>
nah, forget that, didn't copy it ^^
<OscarL>
the what now? it builds ok here
<OscarL>
ah. :-D
<Begasus>
in regards to pycryptodomex, it doesn't conflict with pycrypto?
<Begasus>
like functions etc ...
<OscarL>
no. it installs in as a different python package name.
<Begasus>
yeah, saw that
<OscarL>
just to be clear... I should just move the line "cmd:cc$secondaryArchSuffix" right above "cmd:python$pythonVersion", and remove the "BUILD_PREREQUIRES" that will be now empty, right?
<Begasus>
right, but let me check here first (I had cmd:gcc there so should be ok)
<OscarL>
I had "cmd:cc" only and I was wondering why I was getting weird errors in 32 bits :-P
<OscarL>
with "cmd:cc$secondaryArchSuffix", it worked without issues, go figure :-P
<OscarL>
cmd:cc$secondaryArchSuffix will make it work if Haiku switches to CLANG :-P
<Begasus>
;)
* OscarL
's a forward thinker, you see.
illwieckz has joined #haiku
<Begasus>
That probably won't happen before R1 I guess (would mean dropping gcc2?)
<OscarL>
I should do some thinking in the present instead :-D
<Begasus>
I tend to go with what I "see" ;)
<Begasus>
OK, moving the 2 lines in BUILD_REQUIRES inside the loop works also :)
<OscarL>
in reality... that was already there in the original pycrypto recipe I've used, heh (cmd:cc).
<Begasus>
yeah, it's no big deal and works fine
<OscarL>
also has that "BUILD_PREREQUIRES" on top... I tend to do minimal changes at first... trying to avoid breaking things.
<OscarL>
Should we move the BUILD_REQUIRES inside the loop too? the "default" package isn't building anything really, so doubt it needs the compiler and such.
<OscarL>
Begasus: I'm just browsing on old PRs... what confict is there on https://github.com/haikuports/haikuports/pull/6804 ? (I can't seem to find the "This branch has conflicts that must be resolved" issue :-D)
<Begasus>
so yes, this probably means depending packages need to be rebuild against the new library (could also check if there are new version from those) :)
<x512[m]>
OscarL: Forked gists...
<OscarL>
Also handy, yes
<OscarL>
Begasus: first let me finish the coffee, and see if I get this libcompat thingie right :-) (then I'll try building/bumping "links" , I guess)
<Begasus>
sure :)
<Begasus>
one option is to just revbump and be done with it :)
<OscarL>
Or.... I could just undo the "git mv", and only add a new recipe and call it a day :-P
<Begasus>
won't work :P
<OscarL>
buuuh!
<Begasus>
it's still called libevent21 so will supersede the previous one
<Begasus>
otherwise I would have merged dtc already ;)
<OscarL>
the thing is.. we need to move to at least 2.1.11 to get rid of the python 2.7 dependency.
nephele has joined #haiku
<Begasus>
then might as well move to the latest around
<nekobot>
[haiku/haiku] e9154f59e65e - Menu: disable triggers when SetTriggerEnabled(false) is called
matt3 has joined #haiku
matt3 has left #haiku [#haiku]
<Begasus>
almost half-way through mesa
<OscarL>
"qtwebengine_bin (64bit)" I'm not going anywhere near that one :-D
<Begasus>
lol
<Begasus>
it even get's a bit more spooky, libevent-2.0.21 also provide lib:libevent_2.0 :P
<Begasus>
so you can't tell without looking into the packages which SONAME they require :P
<OscarL>
OR... I could nuke that PR from orbit, forget about it... and play some video games... :-D
Begas_32 has quit [Quit: Vision[]: i've been blurred!]
<Begasus>
you COULD :P
<Begasus>
well, trying to install qtwebengine reports installing libeven21-2.1.8-4 ^^
<Begasus>
scalapack disabled, so one less
<Begasus>
down to 5 :) not all that bad
Begas_64 has joined #haiku
<OscarL>
enough to help me distract from this covid, thing (it is kicking my but right now... with BOTH legs :-/ )
<Begasus>
:D
<Begasus>
building libeven21 on 64bit
<Begasus>
I'll boost a build for qtwebengine_bin here, so you can take a look at the others :)
<OscarL>
awesome.
matt3 has joined #haiku
<Begasus>
mayb it finishes by the time mesa is done :)
matt3 has left #haiku [#haiku]
<OscarL>
my PC could also take a minute for mesa... to make it meltdown if I've attempted to build it :-D
chocabloc has joined #haiku
<Begasus>
this one isn't suited for anything, have to disable SMP on boot or disable some CPU's in Haiku to get something stable (but even on Ubuntu it tends to freeze/fly off) :)
<Begasus>
for a new version one only needs to change the libVersion then :)
<OscarL>
Thanks for the help. Will push that one, and reboot into 64 bits (where I can share clipboard with my host system) and start looking at the dependent packages.
<Begasus>
thanks!
matt3 has joined #haiku
matt3 has left #haiku [#haiku]
OscarL_32 has quit [Quit: Vision[]: i've been blurred!]
jmairboeck has joined #haiku
<Begasus>
qtwebenging_bin isn't build, it pulls the hpkg files from 3dEyes :)
<Begasus>
no issues with newer libevent when installing ... I'm done! :P
<OscarL>
lol
<OscarL>
does it starts with the newer libevent-2.1.so.7 being installed?
<Begasus>
lol not ...
<Begasus>
Falkon doesn't :)
x10z has joined #haiku
<Begasus>
Dooble also not
matt3 has joined #haiku
<OscarL>
we could update all the rest... merge all at once... and then tell to 3dEyes... "Surprise! that one's on you!" :-D
<Begasus>
I'm not sure ... the _bin didn't seem to have issues with it
<OscarL>
any messages on the console when you try starting those apps?
<Begas_64>
runtime_loader: Cannot open file libevent-2.1.so.6 (needed by /boot/system/lib/libQt5WebEngineCore.so.5.15.2): No such file or directory
<OscarL>
gah... I thought you had a typo there Begasus, but you ARE doing *a*transmission indeed :-D
<Begasus>
yep, adding the "a" in there moves it up in the alphabet, tip I got from Diver :)
<mooes>
grrrr, missing iconv.h - but that shold be libiconv_devel ... another try. but I have already gotten much further than all my previous tries.
<Begasus>
64bit mooes ?
<mooes>
yes
<Begasus>
ok, no worries then if you have the ivonv_devel package installed
<Begasus>
4.2.2? :)
<mooes>
yeah, this is just the usual process of collecting all the right devel packages. if I get this to run, then I got a spare T410s to finally run Haiku on bare metal (so far only running it under Virtualbox).
<Begasus>
jikes, our port indeed is way behind
<mooes>
yes, want to run 4.2.2
<mooes>
not sure why the porting stopped at 4.0.3
<Begasus>
no one bothered?
<OscarL>
no enough man-power mooes.
<Begasus>
and that
<Begasus>
OscarL, is helping out now though :D
<mooes>
indeed -- if I can figure out how to contribute in this manner, I would be happy to contribute up-to-date ports of R.
<Begasus>
ps, poked 3dEyes in the comment OscarL
<OscarL>
"helping" :-D
<OscarL>
more like getting in the way, but... :-D
<Begasus>
nah, in a few years you'l be teaching me :)
<mooes>
are there any go-to docs for how to contribute ports like this to HaikuDepot?
<mooes>
would love to. you've already given me the essential hint -- and it is compiling now and as far as I can tell, it should go through. really excited about this as this as R is one of the tools I must have.
<Begasus_32>
grabbing atransmission_x86-3.00-2-x86_gcc2.hpkg and moving it to /Opslag/haikuports/packages/atransmission_x86-3.00-2-x86_gcc2.hpkg
<Begasus_32>
grabbing atransmission_x86_debuginfo-3.00-2-x86_gcc2.hpkg and moving it to /Opslag/haikuports/packages/atransmission_x86_debuginfo-3.00-2-x86_gcc2.hpkg
<Begasus>
good there too :)
<Begasus>
no ... bugger, it still used the old libevent
<OscarL>
remind me....(or explain, really) why the added "a" infront?
rennj has joined #haiku
<Begasus>
t is further up in the alphabet, sometimes when hitting "waiting for package ..." it helps to move it up in the alphabet
<OscarL>
(me still doesn't understands all these tricks :-D)
<OscarL>
Ah... that one!
<OscarL>
did you ran the build with the old libevent2_devel installed?
<Begasus>
thought I had the new one still in */haikuports/packages, but didn't
<OscarL>
(I only have the newer ones installed)
<Begasus>
err ... haven't update on 32bit for the new one :)
<OscarL>
heh
mtsfz2 has quit [Remote host closed the connection]
mtsfz2 has joined #haiku
<OscarL>
that's why I also do the lddtree, listimage, stuff like that... I don't trust myself to not forget something :-D
<Begasus>
it shows when the build is finished :)
<tqh>
x512[m], that bbitmap review only needs some style fixes as pulkomandy pointed out.
<x512[m]>
tqh: Maximum line length increased so some comments are not actual anymore.
<tqh>
ah, I thought the comments were from new 100 char limit.
x10z has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<tqh>
x512[m], approved.
<OscarL>
nice!
x10z has joined #haiku
<OscarL>
So, Begasus... should we do individual PRs for each revbump related to libevent-2.1? or one for (almost) all of them? (thinking of leaving qtwebengine out :-D)
<Begasus>
You can add them in the PR OscarL (or do seperate ofter the merge), let's wait a bit if 3dEyes reacts there, once this gets merged at least Falkon and Dobble are broken
<Begasus_32>
runtime library [libevent-2.1.so.7] in /packages/libevent21_x86-2.1.12-1/.self/develop/lib/x86 may be hidden by files in:
<Begasus_32>
/boot/system/lib/x86
<Begasus>
so picked up the new version
<OscarL>
yea, I've no hurry to have it merged, just wanting to know how to proceed.
<Begasus>
qtwebengine-${portVersion}-4-x86_64.hpkg is build against the current libevent
<Begasus>
biab
bbjimmy has quit [Quit: Vision[]: i've been blurred!]
bbjimmy has joined #haiku
x10z has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
x10z has joined #haiku
<rennj>
kde neon vs fedora37 ...qt vs gtk, both vm's identical .vmx configs..kde/plasma/wayland feels sluggish compared to fedora/gnome foo. in live mode
<rennj>
fedora includes vmtoolsd resizing the vm to any size desktop/xrandr foo resizes automatically
<rennj>
win10,fedora,freebsd all included that nice feature
<win8linux[m]>
x512: What AMD GPUs or GPU gens does RadeonGfx support?
<rennj>
vendor id's model id's someone posted the .c file other day had the list like 252
<rennj>
radeongfx-1.0.0-1-x86_64.hpkg radeongfx_x86-1.0.0-1-x86_gcc2.hpkg cocobeans dump other day i want to say
<OscarL>
but that lists what the underlying 2d driver supports. He specifically mentioned the Radeon Southern Islands.
<rennj>
yeah pcids
<OscarL>
(as being the ones that should have 3D possibly working now)
<rennj>
listdev/devices gui
<rennj>
it was a 2013 amd apu
<rennj>
line 413
<rennj>
// Introduced: Late 2013
<rennj>
// Codename: Sea Islands
<rennj>
// Process: 28 nm
floof58 is now known as Guest67
floof58 has joined #haiku
Guest67 has quit [Ping timeout: 480 seconds]
rennj has quit [Ping timeout: 480 seconds]
<OscarL>
Sark: before I forget... you might want to manually uninstall the pycryptodome packages I've shared, and re-install them from the official repos: "pkgman install pycryptodome_python39" and ""pkgman install pycryptodomex_python39"
<OscarL>
Sark: also... pycryptodome got the fix already, so, hopefully, with the next release you should be able to "pip install" it instead.
<Begasus>
k, need to head out again :) r still building, cu l8r peeps
<OscarL>
later Begasus!
* OscarL
unplugs too.
<Begasus>
l8r OscarL
OscarL has quit [Quit: I'll be back!]
BrunoSpr has joined #haiku
rennj has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
<Sark>
Morning guys!
<Sark>
Just tried the new pycryptodome package, works great!
HaikuUser has joined #haiku
BrunoSpr has quit [Quit: Vision[]: i've been blurred!]
BrunoSpr has joined #haiku
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
Blendie has joined #haiku
BrunoSpr has quit [Quit: Vision[]: i've been shreederd!]
x10z has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Maturi0n_ has quit [Ping timeout: 480 seconds]
<Sark>
Also, I got my loader software running on Haiku and communicating properly via the USB serial adapter. The crypto library worked pefectly for my needs(which is just DES anyway), and it pretty much just ran!
<Sark>
For some reason I had to change the stop bits from two to one, but whatever. Works :)
frkzoid has joined #haiku
<Sark>
Now, another thing I'm realizing is that there is no getty in Haiku, so another use for this won't be usable in Haiku, since I can't spawn a session on a serial port. But that's not super necessary.
<Sark>
I mean, it makes sense because Haiku is not multiuser.
mmu_man has quit [Ping timeout: 480 seconds]
xoblite has joined #haiku
freakazoid332 has quit [Ping timeout: 480 seconds]
DragonMaus has quit [Quit: Vision[]: i've been blurred!]
HaikuUser has joined #haiku
HaikuUser has quit []
mmu_man has joined #haiku
x10z has joined #haiku
x10z has quit []
HaikuUser has joined #haiku
<andreasdr[m]>
cocobean: do we get a new package with RadeonGfx and all required other components? Would be a dream.
cocobean has quit [Remote host closed the connection]
<Blendie>
i'm planning to get a computer exclusively to run haiku on it
cocobean has joined #haiku
<cocobean>
You'll want AMD A6/A8/A10 7000-based Series APUs or the Radeon HD 7000-based discrete cards. Although, the current infrastructure supports up to RX 5000 series - I think the driver is limited to Radeon SI for now.
<cocobean>
(Actually, we can support up RX 6800 as well - since I did update myend)
<cocobean>
Anyhow... the final architectural layout of all of this stuff.
xoblite has quit [Quit: Vision[]: i've been blurred!]
<rennj>
mame will be rocking now
<andreasdr[m]>
Hi!
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
DragonMaus has joined #haiku
BaltaHarry has joined #haiku
gouchi has joined #haiku
BaltaHarry has quit [Remote host closed the connection]
<nekobot>
[haiku/haiku] f6c51a5dc40b - BBitmap: add ability to specify client-defined area
<Begasus>
mooes, I could push my changes to haikuports for a recent version for "r", but if you like to do it I would be happy to help you through the process :)
<mooes>
Begasus: okay, it now works with ./configure ... --prefix=[something sensible], make, make install.
<Begasus>
nice, does it work for you as expected?
<Begasus>
never really used it so I'm unfamiliar there
<mooes>
one snafu: when I install texlive (which R uses to build pdfs of manuals), then I run into a problem with texi2dvi. But I will try to figure this out later.
<Begasus>
texlive is another thing, the core package doesn't provide all things needed to be able to realy "use" it
<mooes>
yes, it works as expected. well, no graphics, since that requires X (that's why it needs to be configured with --with-x=no), but it creates pdfs for the figures instead.
<mooes>
Yes, I figured out the same with respect to texlive. It's really just the core.
<Begasus>
in Haiku we've got xlibe
<Begasus>
counterpart to X11
<mooes>
okay, that will require some experimentation if that can be used.
<Begasus>
nice, I'll leave you up to that, maybe it can be done :)
<Sark>
Speaking of X11 stuff - I see lots of X libraries and stuff - is there an X server framework that runs anywhere in Haiku, so one could forward X from another machine?
<Begasus>
not that I know of
<Begasus>
waddlesplash, is the guy behind xlibe
<mooes>
if I leave out the --with-x=no, then I get the configure error "X11 headers/libs are not available"
<mooes>
(I have xlibe_devel installed)
<Sark>
I didn't think there was a way to do it, since there'd be no display server unless one existed that would run with the Haiku interface. I can ssh -X but if I try to run any X program it can't open the display.
HaikuUser has joined #haiku
<waddlesplash>
mooes: check confg.log
<waddlesplash>
mooes: wait are you trying to build inside HaikuPorter?
<mooes>
no, just plain configure from the terminal
<waddlesplash>
ok. so then do check config.log and try and find out why it didn't detect what was installed
<waddlesplash>
Sark: I once managed to build Xnest on top of Xlibe, but I didn't manage to get it to start successfully
<waddlesplash>
Sark: possibly XWayland would be a better way to go about this now that we have the libwayland compat layer
<HaikuUser>
hey, random hangs with qemu on linux? is it a known thing?
<waddlesplash>
HaikuUser: happens when you use virtio block device apparently
<waddlesplash>
use something else (nvme, sata, ide) and the problem should go away
<waddlesplash>
there's a ticket, nobody's investigated very far I don't think
<Sark>
Huh, yeah - that would be interesting if it were possible to use that compatibility layer to do X display... if it were possible to forward X to Haiku that opens up a whole world of interoperability, and lets you use the Haiku interface with other stuff at the same time. But I realize that it's not a simple problem to solve.
<HaikuUser>
Ok, I'll try and let you know. Thanks.
<Begasus_32>
conftest.c:254:10: fatal error: X11/Xlib.h: No such file or directory
<Begasus_32>
254 | #include <X11/Xlib.h>
<Begasus>
with haikuporter (not added devel:libX11)
<mooes>
this might be a no-go
<mooes>
but it's not a show stopper. when creating a graph, it just outputs it as a pdf file. so one can simply open up the pdf.
<Begasus>
try to "pkgman install xlibe_devel"
<Begasus>
and run configure again
<Sark>
So, I realize this is a silly thing to ask about... but Haiku doesn't have any sort of getty-equivalent, does it? I'm pretty sure Be did, but the whole concept is kinda obsolete at this point, despite me using it all the time with Linux. The full terminfo database is here though.
<Begasus_32>
conftest.c:282:10: fatal error: X11/Intrinsic.h: No such file or directory
<Begasus_32>
282 | #include <X11/Intrinsic.h>
<Begasus>
seems to be missing waddlesplash ?
<Sark>
Yeah, I didn't think so, there's so little reason to have it on Haiku. Just would be fun to attach to a shell over serial. Not sure how the terminal windows are spawned, but surely whatever process starts them probably won't work directed to a serial port :)
<Begasus>
Or I'm missing one of the packages providing it
<Begasus>
libXt
<waddlesplash>
Begasus: yes it's in another package
<waddlesplash>
Xt sounds right
<waddlesplash>
Sark: there's SerialConnect for interfacing with serial ports
<waddlesplash>
directing a process to use serial IO instead of standard IO is another matter
<waddlesplash>
Begasus: motif won't work with Xlibe
<waddlesplash>
there's a lot of compatibility problems
<mooes>
with libxt_devel installed, then ./configure does run through!
<mooes>
but let's see ...
<waddlesplash>
ah if it just needs Xt then you're OK
<Begasus>
not sure if it will work, but just checking
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
<mooes>
grrr, make fails now
KapiX has quit [Quit: KapiX]
<Begasus>
error?
<Begasus_32>
using X11 ... yes
<mooes>
one sec
<Begasus>
probably could use libXmu also
orealis has joined #haiku
<Begasus_32>
Interfaces supported: X11
<Sark>
Ah! I hadn't actually seen SerialConnect, that looks prety useful in general. It seems to work fine, but it's a terminal emulator, rather than something that can drive a terminal. So, like, the terminal on the serial port can talk to SerialConnect, but I can't get a shell up on it, for instance.
setuid has joined #haiku
x10z has joined #haiku
<setuid>
huzzah! Ok, does anyone know of a working r1beta2 repository anywhere? Seems everything older than beta4 is dead/404, DOA.
<setuid>
Looks like that mirror list has been dead for 2 years
HaikuUser has joined #haiku
HaikuUser has quit []
cocobean has quit [Remote host closed the connection]
HaikuUser has joined #haiku
HaikuUser has quit []
Abhoerschutz has quit [autokilled: This host violated network policy. Contact support@oftc.net for further information and assistance. (2023-01-02 18:59:05)]
<mooes>
giving this another try with libxmu_devel installed
<Begasus>
:)
HaikuUser has joined #haiku
HaikuUser has quit []
<mooes>
/boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/11.2.0/../../../../x86_64-unknown-haiku/bin/ld: devX11.o: in function `X11_Open':
<mooes>
/Main/home/downloads/R-4.2.2/src/modules/X11/devX11.c:1760: undefined reference to `XSetState'
<mooes>
/boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/11.2.0/../../../../x86_64-unknown-haiku/bin/ld: devX11.o: in function `SetColor':
<mooes>
/Main/home/downloads/R-4.2.2/src/modules/X11/devX11.c:1149: undefined reference to `XSetState'
<mooes>
nope
<setuid>
Looks like all prior releases have been nuked, that's a shame
<Begasus>
with libXmu enabled?
<mooes>
Begasus: you mean installed? yes
<Begasus>
here it worked fine without issues enabling libX11 and libXt
<Begasus>
didn't check libXmu (yet)
<Begasus_32>
grabbing r_x86-4.2.2-1-x86_gcc2.hpkg and moving it to /Opslag/haikuports/packages/r_x86-4.2.2-1-x86_gcc2.hpkg
<mooes>
hmmm, if I want to install libx11_devel, then it wants to deinstall a bunch of stuff
<Begasus>
xlibe_devel
HaikuUser has joined #haiku
<mooes>
yes, I have that installed
<Begasus>
that should be OK
<Begasus>
bbl
setuid has left #haiku [#haiku]
HaikuUser has quit []
rennj has quit [Ping timeout: 480 seconds]
freakazoid332 has joined #haiku
rennj has joined #haiku
frkzoid has quit [Ping timeout: 480 seconds]
rennj has quit [Ping timeout: 480 seconds]
<Begasus>
k, enabling libXmu seemed to work fine here, but it seems they are only requested at build time, I don't see any errors after build completed with haikuporter for POLICY ERRORS
<waddlesplash>
we don't have an X server, only Xlibe is any use
<mooes>
Begasus: so say I want to use that recipe which I assume is meant to be used together with haikuporter. what would I need to do to get this to run?
<Begasus>
mooes, setup haikuporter/haikuports as mentioned earlier
<jmairboeck>
waddlesplash: did you try Tk 8.6.13 already? (i.e. the current relatively new version)
<waddlesplash>
no, I don't think it'd be any differen
<waddlesplash>
there's some critical bug in Xlibe here that I haven't yet figured out :/
<Begasus>
copy the content of that paste to: dev-lang/r/r-4.2.2.recipe (in your haikuports tree
<jmairboeck>
I noticed that they updated their bundled X11 headers significantly
<jmairboeck>
at least those that are installed on Windows
<waddlesplash>
it doesn't matter
<jmairboeck>
so it seems they did some updates regarding X11
<waddlesplash>
if you want interoperability with other things using X11 we need to use a real Xlib implementation and not Tk's very stub version
nephele has joined #haiku
nephele has quit []
dby has joined #haiku
<x512[m]>
waddlesplash: > we don't have an X server, only Xlibe is any use
<x512[m]>
Xsdl exists.
<waddlesplash>
yes, and isn't in the repos
<waddlesplash>
I haven't ever built it successfully myself anyway
<Begasus>
so fa any attempts there failed
<Begasus>
far*
<x512[m]>
I managed to build and run Xsdl.
<Begasus>
(but it's been a while sonce I checked and before xlibe)
<Begasus>
since*
<extrowerk>
i also managed to build xsdl some years ago
<Begasus>
think it's time to call it a day, OscarL typing skills are catching :)
dby has quit []
<jmairboeck>
hm, I see there are both tcl 8.6.11 and 8.6.12 in haikuports? do we need both of them? (I think I'll try updating it to 8.6.13)
<Begasus>
go for it jmairboeck :)
<Begasus>
been a while since i've been there
<jmairboeck>
should I remove the older versions?
<Begasus>
check on depending recipes first :)
<Begasus>
probably won't be that many
<Begasus>
but python probably (for tkinter)
<xoblite>
ehh... stupid question? How do you center (h/v) draw text inside a rect in Haiku?
<xoblite>
(read: no dedicated view etc)
<waddlesplash>
you can't?
<waddlesplash>
all drawing happens with views
<waddlesplash>
so do whatever math you need to inside the Draw() function of the actual view, then DrawString at the right point
<xoblite>
ah yes, but iirc there's a couple of more dedicated view for strings too right? Anyway, it's a regular view
<waddlesplash>
yeah, there's BStringView
<waddlesplash>
that just does all the math and drawing for you, not that special
<xoblite>
ok but in none of these cases there's a flag a la ALIGN_CENTER / ALIGN_VCENTER or similar, if you know what I mean?
<xoblite>
or setting some draw mode doing something similar?
<waddlesplash>
no
<waddlesplash>
don't think so, anyway
<xoblite>
that is... ouch
Begasus_32 has quit [Quit: Vision[]: Gone to the dogs!]
<Begasus>
heading down here, g'night peeps
<xoblite>
so basically I'll have to fetch the size of the text to be drawn, and do the centering myself?
Begasus has quit [Quit: Leaving]
B2IA has quit [Ping timeout: 480 seconds]
<waddlesplash>
think so
<waddlesplash>
PulkoMandy may know more
<xoblite>
ok thanks!
<waddlesplash>
but this is quite typical for low-level drawing APIs. what are you trying to do, anyway?
<PulkoMandy>
yes, if you do your own drawing in a view you have to compute the positionning yourself
<xoblite>
nah I'm just coming from Windows recently, and there and in many other cases there are DrawString "flags" to align the text inside a RECT
<PulkoMandy>
or use one of the existing views: BStringView for simple labels, or BTextView for complex text with multiple lines, paragraphs, etc
<xoblite>
hmm, ok, does BStringView provide alignment options you mean? (have to read the docs again of course)
<waddlesplash>
yes
<xoblite>
aha, ok, thanks.
<PulkoMandy>
BStringView just makes itself as small as possible, just fitting the text
<PulkoMandy>
then you can put it inside a BLayout and have the layout align the whole view left, right or center
<xoblite>
adapting to the font as specified etc?
<waddlesplash>
BStringView itself has a SetAlignment flag
<PulkoMandy>
ah yes, that's an option too
<xoblite>
it's a bit overkill for self-managed drawing though, so perhaps a rect+alignment-aware regular DrawString would be of interest (?)
<PulkoMandy>
it looks like the code in BStringView::Draw could be easily extracted in a function like that
<xoblite>
btw, since I have you both on the line: fetching all windows for a given team, I think I have seen that somewhere but for the life of me I can't find it again?
<xoblite>
PulkoMandy: Sounds interesting :)
<waddlesplash>
you can do it for your own team via BApplication
<waddlesplash>
for other teams I don't know if we have public API for this?
<x512[m]>
xoblite: Scripting can be used for enumerations windows of another team.
<x512[m]>
Or API used by Deskbar.
<PulkoMandy>
I don't know, but ProcessController, DeskBar and Switcher does it so we probably have something
<xoblite>
I was looking at the Deskbar code trying to wrap my head around its structure, and how it goes partly private (?) for some simple thing is a bit itchy
<x512[m]>
> Private BeOS compatible window API
<xoblite>
yeah I've seen the do_window_action etc
<xoblite>
but unless I misunderstand the inner workings here one shouldn't have to go via limited private functions to do basic window handling stuff (?)
<waddlesplash>
asking about the windows of other applications is something that rarely needs to be done?
<waddlesplash>
so, what are you trying to do
<PulkoMandy>
this API is for writing a window manager or something like deskbar. That's the job of the OS so the API doesn't need to be public
<xoblite>
for example, one can activate and minimize via that function, but not zoom, etc
<PulkoMandy>
for that you could use scripting. But managing windows is the job of the OS, not 3rd party apps
<xoblite>
like I said I'm trying to understand Deskbar better because it's fundamental to the Haiku UX
HaikuUser has joined #haiku
<waddlesplash>
if you want different window management behavior, write a decorator, probably
HaikuUser has quit []
<x512[m]>
Decorators are currently unsafe and can crash app_server.
<waddlesplash>
yes, we need to do a major overhaul and boot decorators to an app_addon_server probably
<PulkoMandy>
don't write code that crashes :)
<x512[m]>
Why memory protection was invented then?
<waddlesplash>
it's a joke, of course
<Skipp_OSX>
because the alternative was worse
<xoblite>
if you own the window, there's Minimize(), Zoom() etc, but regardeless if Deskbar is trusted maybe it shouldn't require private functions to do this. In Windows for example, you can FindWindow() to get the HWND (window handle), then send window management messages - maximize, minimize, restore etc - to said window.
<waddlesplash>
just because $thing is possible on $other_os doesn't mean we need to or should implement such an API
<Skipp_OSX>
I thought about writing a different WindowBehaviour and I thought about taking the u out
<waddlesplash>
LOL
<waddlesplash>
also, good to see you Skipp_OSX :)
<x512[m]>
waddlesplash: It would be still useful to have an API to get a window BMessanger by x, y coordinates.
<Skipp_OSX>
we should probably have classes for both variants and Colour variants as well
<waddlesplash>
x512[m]: yes, that seems more presumably useful
<xoblite>
waddlesplash: then again, how big an issue would it be to provide such functionality? you can still do it today, just convoluted an approach...
<PulkoMandy>
xoblite, you can do that with scripting (see for example the "hey" command, try "hey Tracker getsuites Window 0" to see a list of available commands)
<x512[m]>
Can be used by various tools to pick a window.
<PulkoMandy>
this is accessible from C++ as well
<xoblite>
PulkoMandy: hmm will check later, thanks
<Skipp_OSX>
WindowBehaviour subclass would change the move and resize behavior and drag and drop which I am not a fan of either because of their Linux/WIndows influence
<xoblite>
btw the Deskbar design around Menu concepts is... messy
<waddlesplash>
Skipp_OSX: the entire Decorator system is a total mess of broken abstractions
<waddlesplash>
xoblite: yes, it sure is, and probably deserves cleanup
B2IA has joined #haiku
<waddlesplash>
Skipp_OSX: I don't know if I trust myself to redesign it however, I have a hard time visualizing how things fit together and what a more ideal setup would be
<xoblite>
waddlessplash: I would also separate the Desktop from Tracker, but maybe that's just me... ;)
<Skipp_OSX>
yeah well I am afraid that my TabDecorator class isn't helping much because I intended to make a BarDecorator for MacDecoartor and WinDecorator but I have already made MacDecorator support Stack & Tile using TabDecorator
<waddlesplash>
xoblite: what? uh, absolutely not?
<Skipp_OSX>
xoblite Macintosh heritage
<waddlesplash>
xoblite: the Desktop is literally just an Icon view of Tracker
<waddlesplash>
that's good
<Skipp_OSX>
Finder includes the Desktop, so Tracker does too
<xoblite>
File Manager != Desktop
<waddlesplash>
File Manager == Desktop
<Skipp_OSX>
Finder circa 1995 anyway well also today
<xoblite>
Windows Explorer too
<xoblite>
wasn't a good idea there either...
<PulkoMandy>
well you won't agree with Haiku devs on that...
<Skipp_OSX>
yeah but that's why it is like that now anyway
<waddlesplash>
well, considering both Windows and macOS have done this exact same thing from 1990s to today
<waddlesplash>
I don't think there's much argument for your position that "file manager != desktop"
<waddlesplash>
only some weird Linux environments decided otherwise
<PulkoMandy>
we are possibly the last OS exploring the "spatial navigation" metaphor, where the desktop roughly matches with the root of the filesystem (the / directory)
<Skipp_OSX>
Desktop is literally a Tracker window
<waddlesplash>
yeah
<xoblite>
yes.
<waddlesplash>
xoblite: you do know you can set backgrounds on non-Desktop folders, right
<waddlesplash>
that's not something special reserved to the Desktop
<xoblite>
but (IMO) file management is one thing, the desktop something else (typically).
<waddlesplash>
people rarely do this but Tracker fully supports it
<waddlesplash>
xoblite: it's ... not?
<xoblite>
waddlesplash: yes
<Skipp_OSX>
Deskbar menu design I agree with you there
<waddlesplash>
again, macOS, Windows, and also BeOS have done this since the 1990s
<PulkoMandy>
waddlesplash, I would do it more if the attribute stored the path relative to the folder, so I can put the image inside the folder and distribute my apps this way
<Skipp_OSX>
also the similar Tracker menu design
<waddlesplash>
PulkoMandy: does Tracker not accept relative paths?
<waddlesplash>
that seems like a very easy fix
<xoblite>
the desktop could have spatial navigation and still be separate code-wise from the file manager, if that's the issue.
<PulkoMandy>
I didn't get it to work when I tried, but I don't remember the details
<waddlesplash>
xoblite: I don't understand why you would write a totally separate app
<waddlesplash>
if it's going to have spatial navigation ... we already have an app that does that!
<PulkoMandy>
I think it computed paths relative to the "current" directory from chdir, which isn't the one of the Tracker folder being shown
<xoblite>
modularity. then again, the Haiku desktop is not my cup of tea.
<PulkoMandy>
modularity is not "there are two apps that do the exact same thing"
<waddlesplash>
PulkoMandy: ouch. but sounds like it should be fixable
<PulkoMandy>
and also modularity is not exactly one of the goals of Haiku
<Skipp_OSX>
Desktop is separate code-wise and data-wise using a different attribute than other folders
<waddlesplash>
yes, "two apps that do the exact same thing" is ... the exact opposite of modularity
<PulkoMandy>
yes, it should not be hard to fix. But I have a lot of more useful things to do first :)
<waddlesplash>
xoblite: I guess Windows and macOS desktops are not your cup of tea either then?
<waddlesplash>
I don't know what would be your cup of tea I suppose
<waddlesplash>
seeing as Haiku is not some weird special casehere
<Skipp_OSX>
Linux obviously
<xoblite>
PulkoMandy: Again, depends on your viewpoint I guess. For me, I dislike icons on the desktop (need the zen of a clean desktop like many/most (?) others), and coming from a *box background I know the power in more flexible context menus etc.
<waddlesplash>
what, so we adopt the GNOME model of a completely useless desktop?
<Skipp_OSX>
I like some of Gnome's ideas like the shortcut list
<waddlesplash>
gnome has a good idea once and a while
<Skipp_OSX>
would be handy to have a dropdown of the available shortcuts, I know they're in the menu but the way Gnome does it is pretty helpful
<waddlesplash>
xoblite: "most others" is again, "just Linux"
<waddlesplash>
90-whatever percent of people are coming from Windows and macOS, not Linux
<x512[m]>
I agree that desktop icons is bad idea because it are hard to access if windows a open.
<x512[m]>
a open -> are open
<xoblite>
well, again viewpoint I guess. There are mice with 17 buttons now, yet Haiku works off the good old Apple "1 button is enough for anybody" heritage, adding other buttons just sparingly (?).
<PulkoMandy>
I have always an empty workspace, and really I access a lot of things through the "xray" navigation menu, so basically right click on desktop -> reach any of my current work in progress files
<xoblite>
x512[m]: Exactly!
<Skipp_OSX>
we use right click too much if anything
sanzfc has joined #haiku
<Skipp_OSX>
primary mouse button, with secondary for context menus only, except the windowbehaviour in Tracker that I dislike
<x512[m]>
windowbehaviour in Tracker?
<xoblite>
btw changing subject: is there a more limited dev SDK for non-packaged developers, or should there be one?
<waddlesplash>
what do you mean by "more limited dev SDK"?
<PulkoMandy>
I don't know what non-packaged developers means
<Skipp_OSX>
well, both the of moving and resizing windowbehaviour and also right-click drag and drop in Tracker
<PulkoMandy>
and also yes, what the limitations would be and why there would be limitations
<Skipp_OSX>
former from Linux, latter from WIndows
robson has quit [Quit: Leaving]
<xoblite>
right now, since there are so many different ways to do some things (part of some maintenance debt perhaps), should there be a more limited SDK that doesn't include the private stuff, perhaps with an example app showing the state-of-the-art of application development anno 2023?
<waddlesplash>
there... really aren't that many ways to do things
<waddlesplash>
and if you think there's "many different ways to do things" on Haiku, well, do I have some news for you about Linux
<xoblite>
oh yes! :)
<waddlesplash>
the private stuff is just that: private. you shouldn't need it when developing applications
<waddlesplash>
and if you do it should only be private/shared/ stuff, which is "maybe in the public API someday but just not ABI-stable yet"
<x512[m]>
xoblite: Do you mean that headers and libraries don not work if put to non-packaged/develop?
<Skipp_OSX>
well a lot of the private stuff is stuff we added on top of BeOS that we'd like to make public
<xoblite>
still, my point was really that for app dev, you don't need to full shebang of the haiku tree.
<waddlesplash>
well, no?
<Skipp_OSX>
I'd like to make BSpinner's public bc a lot of apps do use those
<waddlesplash>
I don't think anything at HaikuArchives needs a full tree
<waddlesplash>
maybe one or two apps that do weird stuff in app_server
<PulkoMandy>
you need an haiku install with the haiku_devel package
<xoblite>
exactly - so do we have a smaller app SDK one could download if you're only going to work on non-packaged creations?
<PulkoMandy>
(but I think it's very hard to do any serious app without using some private APIs still)
<Skipp_OSX>
but that's just bc it's an addition and we're not at R1 yet so we don't want to be stuck with it
<PulkoMandy>
that's the haiku_devel package
<x512[m]>
private headers are included in haiku_devel package.
<waddlesplash>
xoblite: the haiku_devel package is 4MB, not sure how things could be smaller
<PulkoMandy>
you don't need anything else and it's shipped in all haiku releases