<waddlesplash>
braewoods: what do you mean by "find" the usb device behind a given serial port?
<waddlesplash>
USB serial devices will appear in /dev/ports/usb/
<braewoods>
waddlesplash: from what I can see, under /dev/ports enumerates usb serial ports as usb followed by an integer.
<braewoods>
But how do I know which USB device caused it to be created?
<braewoods>
What hardware does it belong to on the USB bus?
<braewoods>
Under say Linux I could probe /sys to find the serial port that a USB driver created or the reverse.
<braewoods>
e.g., ttyUSB or ttyACM.
<braewoods>
This would be useful if I am trying to find a specific device's serial port interface.
<waddlesplash>
hmm
<waddlesplash>
if you look in the "Devices" app, does it show up there?
<braewoods>
I'll take a look. Moment.
<waddlesplash>
the USB stack is not especially well integrated into the kernel device manager system
<waddlesplash>
a bunch of refactoring is still needed
<waddlesplash>
however, we may have gotten to the point where it will show up in there
<waddlesplash>
yeah it appears we don't
<braewoods>
it does show up, but just the raw USB device.
<waddlesplash>
I have HID devices but in Devices app it just lists the bus hub as the driver
<braewoods>
Ok. In my case I was researching what features I might plan to have beyond Linux. My code will probably still work due to the POSIX layer but some features require OS extensions to work at all.
<waddlesplash>
what does SerialConnect display?
<braewoods>
usb0, basically just the device name.
<waddlesplash>
yeah, ok
<waddlesplash>
we probably should improve this, indeed
<braewoods>
which doesn't help if I'm trying to pair it up with its device.
<braewoods>
But it seems to be a common problem. Most of the BSDs also lack a similar thing.
<waddlesplash>
there are at least 3 potential ways to fix this
<waddlesplash>
1. rename what winds up in /dev/ports/usb/ (easy enough, not sure if that will cause problems elsewhere however)
<waddlesplash>
2. add a custom ioctl to usb_serial (or find a generic one that we should be implementing anyway) to return this information
<braewoods>
actually no directory is created, unless this is recent? I was using the latest beta.
<waddlesplash>
3. refactor more of the device manager to get the information into there
<waddlesplash>
braewoods: oh, right, I'm misreading this code. indeed it's just usb0, etc.
<waddlesplash>
that could also be changed, but, that may break existing software which expects just files in this folder
<braewoods>
which is fine, it's enough to filter out non-USB ports, just not enough to know anything about the backing device.
<waddlesplash>
right
<waddlesplash>
any standard ioctl for this?
<braewoods>
Not really, given that USB isn't even recognized by POSIX. Every OS has their own USB API.
<braewoods>
libusb has to be ported to every variation that exists.
<waddlesplash>
no, I mean a standard TTY ioctl, to get information about the TTY on the other end of the line
<braewoods>
Oh.
<waddlesplash>
braewoods: btw our libusb port really has problems :(
<waddlesplash>
it misbehaves in ways that don't make any sense. I think people have tried to fix it to no avail
<braewoods>
Like what?
<waddlesplash>
using the native userland USB APIs, which are honestly pretty similar to the libusb APIs, works great
<braewoods>
It could be from trying to mix C and C++ improperly.
<waddlesplash>
I don't remember specifics, just that I know PulkoMandy has written native Haiku USB backends to some pieces of software and they work way better than the libusb ones
<waddlesplash>
braewoods: heh, we are experts at mixing C/C++, I sincerely doubt that's the problem
<braewoods>
I see.
<braewoods>
I've mostly written C code, minor contributions to Linux kernel.
<waddlesplash>
here's one example, an upstream'ed backend to android-file-transfer using the native APIs, which as you can see are very straightforward
<braewoods>
If you were wondering, I was wanting to essentially create a portable client/server model that can manage USB connected displays in a generic manner.
<waddlesplash>
braewoods: I actually know less about USB in practice than you might expect; I've not written any USB device drivers
<waddlesplash>
... but I'm the maintainer of Haiku's XHCI driver
<braewoods>
Some example devices? The turing smart screen, vocore displays, or the many ax206 variants floating around.
<waddlesplash>
(and rewrote most of it around 2019. the older version was ... not great)
<waddlesplash>
hmm, interesting concept
<waddlesplash>
well, it should definitely be possible to do this with haiku, and if it isn't, we should fix
<braewoods>
It would only be useful for the USB serial ones like the turing one. The others use custom drivers so this isn't an issue
<braewoods>
I saw the kernel driver's class exposes the usb_device it contains. Maybe that can be used?
<waddlesplash>
you mean the usb_serial SerialDevice class?
<braewoods>
yea, i think so.
<waddlesplash>
well, yes, but nobody else can call that but other code in the usb_serial driver
<waddlesplash>
so, we need to decide how or where this data gets exposed
<braewoods>
Figured.
<waddlesplash>
all drivers on haiku are dynamically linked btw
<braewoods>
I wasn't 100% sure since it's hard to figure out how kernel stuff works.
<waddlesplash>
there is no symbol resolution except into the kernel
<waddlesplash>
(that's honestly a bit of a downside in the USB stack, I'd really like to fix that part)
<braewoods>
does haiku actually use users at all? it seems like everything runs as root.
<waddlesplash>
but it will come with some potential hazards, so, that likely can wait
<waddlesplash>
braewoods: yes
<braewoods>
or user rather.
<waddlesplash>
not by default, but you can useradd, login, etc.
<braewoods>
so file permissions actually matter?
<waddlesplash>
in fact sshd is basically useless out of the box, because we don't set PermitRootLogin
<waddlesplash>
yes ... theoretically
<waddlesplash>
until a few years ago most filesystem drivers and the VFS weren't good about actually checking them
<waddlesplash>
that has since been fixed, there are actual permissions checks done now, however I don't think this has really been stress-tested
<braewoods>
Not complaining, but what inspired my program idea is the fact that most USB code has to run as root just to work so I thought why not make the server and client separate?
<braewoods>
waddlesplash: it's fine, doesn't matter much to my program, i was just surprised.
<waddlesplash>
well, this is mostly due to BeOS compat at this point
<braewoods>
i guess it shows that Haiku wasn't really designed for multiuser systems per say.
<waddlesplash>
I bet if I actually tried, I could get the GUI to run as something other than UID 0 in not much work
<waddlesplash>
braewoods: nah, the kernel developers clearly thought about this
<waddlesplash>
they were preparing for the day to come, and it's slowly coming
<waddlesplash>
when I do cleanups or refactors I try to audit for this and add missing pieces where necessary
<braewoods>
does Haiku follow unix convention where unlinked files remain available until the last reference is dropped?
<waddlesplash>
yes we do!
<braewoods>
Ok. I was planning to use that when writing my shared memory code to limit who else can access it to just who I shared the FD with over unix sockets.
<waddlesplash>
uh
<waddlesplash>
you can't share FDs over unix sockets on haiku
<waddlesplash>
we don't actually support that
<braewoods>
You can't? But you have SCM_RIGHTS and all.
<waddlesplash>
I heard someone saying we didn't and they proposed a new API to supplant this not long ago
<waddlesplash>
so this then asks the question, do we handle reference loops here properly?
<waddlesplash>
(I'm not seeing that we do)
<braewoods>
well, you should use the existing convention for compatibility instead if it exists.
<braewoods>
but this feature is used heavily by some things like the X server.
<braewoods>
as there's only two ways to share memory. you share the name of the segment or the FD to it.
<waddlesplash>
we have a third
<waddlesplash>
you share the area's ID and make it cloneable
<waddlesplash>
(all virtual memory regions on Haiku are "area"s -- yes, everything; mmap or otherwise.)
<braewoods>
I see. I may have to just use more platform specific code for the Haiku port once I get around to finishing the unix side.
<braewoods>
I was planning to use shared memory to reduce copies of large blocks of image data.
mmu_man has quit [Ping timeout: 480 seconds]
<x512[m]>
braewoods: Memory FDs are also supported by Haiku.
<x512[m]>
Memory FD can be created with shm_open POSIX call.
<waddlesplash>
yes, you can use memory FDs
<waddlesplash>
"area"s are just the native API, but there's no reason you have to use that
<braewoods>
x512[m]: ok. i was just wondering if it would still work properly when shared via SCM_RIGHTS and the original file was unlinked, having only FDs to access it.
<x512[m]>
Yes, it should work.
<braewoods>
shm_open on Haiku appears to be implemented the same way as on Linux. a special ram backed FS is used.
<braewoods>
but seems like /proc and /sys are mostly Linuxisms. only /dev seems consistent at all.
<braewoods>
I was comparing different POSIX implementations. Kinda interesting how much things can vary.
<braewoods>
waddlesplash: does Haiku leverage the x86 MMU at all? I would assume so but given some of the designs I kinda wonder.
<waddlesplash>
????
<waddlesplash>
of course we do?
<waddlesplash>
everything leverages the MMU, you can't *not* leverage the MMU
<waddlesplash>
unless you are running DOS or something
<braewoods>
Sorry, stupid question I guess. lol... I still remember the days of using Win 9x.
* braewoods
winces.
<waddlesplash>
lol
<waddlesplash>
anyway, yes, Haiku isn't AROS or something
<waddlesplash>
we are fully POSIX, we have per-process address spaces, memory protection, ...
<braewoods>
Ok, so there's the usual memory protection.
<waddlesplash>
the x64 version of haiku only supports x64 binaries at present
<x512[m]>
Fun detail is that BeOS R3 used PE executables and MS C++ ABI so it may be possible to have compatibility with BeOS R3 applications by using modern Clang with MS ABI support.
<braewoods>
It's a mess to do multiarch.
<braewoods>
I've seen different uses of that x86 feature on Linux. Most people use the multilib approach.
<braewoods>
Meaning that libraries get their own architecture specific locations and the like.
<braewoods>
But if Haiku got multilib or something equivalent, it would make 32 bit only Haiku less important I would think.
<braewoods>
That said it's probably a complex thing to get working. I don't even know how Linux manages mixing the two.
<x512[m]>
The problem is not multilib, the problem is 32 -> 64 syscall translation and 32-64 bit mode switching.
<waddlesplash>
we already have multilib
<braewoods>
Oh.
<waddlesplash>
32-bit Haiku is multilib gcc2/gcc4+
<braewoods>
Interesting none the less... I remember reading about issues related to GCC4 transition when I did distribution work a long time ago.
<waddlesplash>
it appears the usb_disk driver reports something useful for B_GET_DEVICE_NAME
<waddlesplash>
so, we can likely make the usb_serial driver do the same
<waddlesplash>
that will likely solve the use-case you want
<x512[m]>
GCC completely changed C++ ABI. So shared libraries that expose C++ API can't be used with newer compiler.
<braewoods>
Ah, right. That's probably why some of the hardcore C programmers I used to talk to hated C++, the whole mess namemangling can create, or used to anyway.
<x512[m]>
Hopefully C++ ABI is never changed after GCC 3.
<braewoods>
waddlesplash: huh. well it technically just needs to be enough to find the corresponding device under the regular USB interface so maybe that will suffice.
talos has joined #haiku
<braewoods>
waddlesplash: so if I need to write raw USB drivers for Haiku from userspace, the libusb backend isn't very good?
<waddlesplash>
it probably needs to be repaired somehow
<waddlesplash>
if you know something about libusb internals, maybe you are the person to fix it :-p
<braewoods>
What issues are you talking about?
<braewoods>
I mean, surely there's some bug reports or something to go off of.
<braewoods>
The fact native ports that bypass libusb makes it sound like a flaw in the backend.
<waddlesplash>
yes, likely
<braewoods>
Or something else that libusb relies on.
<waddlesplash>
well, android-file-transfer looks like a good benchmark now
<waddlesplash>
since PulkoMandy wrote a native backend that works great
<waddlesplash>
but apparently the libusb backend doesn't
<waddlesplash>
but as for specifics, PulkoMandy is probably the person to ask
<braewoods>
Ok. Where would I find the source?
<braewoods>
It doesn't appear to be in the main haiku one.
<waddlesplash>
Skipp_OSX: we already have something similar for Queuries don't we?
<waddlesplash>
is this the same color I guess?
<OscarL>
uhhh! /me likes!
<Skipp_OSX>
same color yeah
<Skipp_OSX>
B_DARKEN_1_TINT, and if you change your DOCUMENT_BACKGROUND_COLOR it will tint that instead, although I gotta figure out perceptual_brightness still
<OscarL>
that, and a "Mount" menu item on Disk icon... and I'll owe you a beer or something :-D
<Skipp_OSX>
I mean, that's easy I'll put on todo list
<OscarL>
awesomo, thanks!
Begasus has joined #haiku
<Begasus>
g'morning peeps
Begas_VM has joined #haiku
<Begasus>
k, 2 recipes checked without libltdl dependency so far, no issues
<OscarL>
Good day Begasus
<Begasus>
'lo OscarL :)
<OscarL>
(was busy reading the logs :-P)
<Begasus>
np :)
<Begasus>
heading out in a bit, checkup at the hospital today
<OscarL>
Hopefully they'll give you a clean bill of health!
<Begasus>
hmm created the flif recipe myself, not sure why I added the libltdl in there :D
<Begasus>
not sure what to expect, so will see OscarL :)
<OscarL>
My best wishes, in any case! :-)
<Begasus>
Thanks :)
<OscarL>
Speaking of logs... Sometimes you find nice things buried in there... like... now I git a "vimrc" that *might* convince me to actually learn som vim.
<Begasus>
did some basic vim for dummies years ago, don't know where i stashed it, could be handy :P
<OscarL>
looks pretty great, and has autocomplete via /bin/clangd.
<Begasus>
for me nano is enough :)
<OscarL>
I still need to finish tweaking nano's shortcuts to my taste :-)
<OscarL>
and here the file: https://termbin.com/dwq0g (I had to do some touch ups to make it work nicer on Haiku's Terminal, but pretty sweet so far).
<OscarL>
That working autocomplete for C/C++ might really come in handy for me, since Pe's BeBookFetch and BeHappy extension do not work on Haiku :-D.
<Begasus>
Patches welcome :-)
<Begasus>
how's progress on lout btw?
<OscarL>
unless we can have the original Be Book installed... no hope for BeBookFetch, I'm afraid (the BeBook redesign killed the usefulness of the bookmarks it depended on :-/).
<OscarL>
re: lout... lout works fine (albeit I'm might need to patch the makefiles to avoid that extra "/lib" in it's data path)....
<OscarL>
on the Pe side.. AxelD's refactoring from 2008 were fine, it was a change from weinhold in 2013 the one that broke it.
<OscarL>
I managed to fix parts of it.... logs on terminal shows I'm getting the correct paths to the files you can open from the "Headers" button... but Pe somehow still fails to open them.
<OscarL>
And not even a peep on console/syslog... so... I'm a bit lost there :-(
<Begasus>
k, heading out, cu later
<OscarL>
later!
<PulkoMandy>
waddlesplash, braewoods: the issue with libusb is that some operaeions never receive a response from the device. I think it is mainly when reading the device descriptors, which our libusb backend tries to implement on its own instead of using the specialized call to do that. But I found no reason why this wouldn't work
<PulkoMandy>
I'm not sure why you would need to access a device both at the usb_serial level and at the raw usb level at the same time? For me it would be either one or the other, what's the reason for needing both?
glog78 has joined #haiku
<PulkoMandy>
Some time ago I ported http://lcdproc.omnipotent.net/ to Haiku but I don't know if this will do color displays
<braewoods>
PulkoMandy: It will to a limited extent. lcdproc and lcd4linux are actually what inspired my project but I wanted to work with displays that worked with pixels instead of being limited to characters.
<braewoods>
From what I recall digging through lcdproc's source code, it supports graphical displays by basically emulating a conventional character display through custom drawing routines.
freddietilley has joined #haiku
<braewoods>
PulkoMandy: To answer your question, that's not quite correct. It was to enable me to do device matching based on the USB backing device. Like VID, PID, various USB strings.
<braewoods>
But it's not strictly needed. It's just nice to have. Linux and Mac OS seem to be the only unixlike systems that have any kernel APIs that can be used to do this.
<nekobot>
[haiku/haiku] af3dceb2795c - Update translations from Pootle
<braewoods>
It would allow me to limit my application to just serial ports that are likely to support the device protocol.
<OscarL>
darn... I can't see the "I have files to attach to this ticket" checkbox on Trac (with Web+) :-/
<braewoods>
But I understand why this isn't really a common thing. Legacy reasons and all. Serial ports were originally hardwired into the system and it made no difference what the device was beyond its capabilities.
MajorBiscuit has quit [Ping timeout: 480 seconds]
<PulkoMandy>
Ok, yes, sounds like a reasonable usecase
<braewoods>
A number of serial port libraries do this already, where APIs are known to exist. pyserial and libserialport to name a few.
<braewoods>
It could be as simple as providing information about what device nodes are backed by a specific bus device through the existing USB userspace api.
<braewoods>
Like, this device is being used by usb_serial and has ports/usb0 as its device node under /dev.
Diver has joined #haiku
kescher has quit [Quit: Bye]
Blendie has joined #haiku
xet7 has joined #haiku
<glog78>
is there somewhere a description of how to package software ?
<glog78>
specially where to put files like man pages / bash completition files and such ?
<glog78>
i did currently locally build ag (the silver searcher) with --prefix=$HOME/config/non-packaged
freddietilley has quit [Quit: WeeChat 3.8]
diver1 has joined #haiku
Diver is now known as Guest12213
diver1 is now known as Diver
<Begasus>
Glog78, ag is already ported over to haikuports
<Begasus>
you could try next time with "cmd:ag" :)
<Begasus>
works also with pkgman
freddietilley has joined #haiku
<glog78>
fzy is the second tool in the list
<glog78>
is easy to compile too
<glog78>
Begasus thanks for the info with cmd
<glog78>
it's in the packages too
<glog78>
thank you
<Begasus>
best way to add software in the depot is to create a recipe for it
<Begasus>
np :)
MajorBiscuit has joined #haiku
Begasus_32 has joined #haiku
Begasus_32 has quit []
diver1 has joined #haiku
Diver is now known as Guest12215
diver1 is now known as Diver
Guest12215 has quit [Ping timeout: 480 seconds]
Begasus_32 has joined #haiku
<Begas_VM>
waddlesplash ...
<Begas_VM>
checking for lt_dlinit in -lltdl... no
<Begas_VM>
configure: error: libltdl not found. See README.
<Begas_VM>
at least this fails for guile1
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #haiku
MajorBiscuit has quit []
diver1 has joined #haiku
Diver is now known as Guest12220
diver1 is now known as Diver
Guest12220 has quit [Ping timeout: 480 seconds]
<OscarL>
Great... Running a DEBUG=1 build of Pe ended up in a crash report :-D (asser failed, "indx < fLogicalSize" on PTextBuffer:L89).
<OscarL>
I certainly understood some of that, yup!
<Begas_VM>
heh
<OscarL>
I remember Pe used to spam the syslog A LOT back in the day... (complaining about the most simple thing... now I can't get it to spit why it fails to open a file when the path it use clearly exists :-/)
<OscarL>
At some point, I should try to rebuild the VMware driver and shutup that damn "VMware: SHOW_CURSOR" message spamming syslog.
<OscarL>
much better Begas_VM!
<Begas_VM>
not really :/
<Begas_VM>
still tries to install the libltdl package for LO (even wan't to bring in the older redland package) :/
<Begas_VM>
this could take a while :)
<Begas_VM>
back to redland ...
<Anarchos>
Begas_VM what is redland ?
<Begas_VM>
a library used by LO Anarchos
<Begas_VM>
Initialized empty Git repository in /boot/home/haikuports/dev-db/unixODBC/work-x86-2.3.9/sources/unixODBC-2.3.9/.git/
<Begas_VM>
Fetching package for libtool_x86_libltdl == 2.4.6 ...
<Begas_VM>
:/
<Begas_VM>
back to libtool, that's the one pulling in libtool_ltdl
<Begas_VM>
must have missed something there
* Begas_VM
feels stupid now :P
<OscarL>
meh... I do worse daily :-D
<OscarL>
easy to get lost among many recipes.
<Begas_VM>
k, that is fixed
<Begas_VM>
a bit more and I've seen/looked into them all :)
Anarchos has quit [Quit: Vision[]: i've been blurred!]
Anarchos has joined #haiku
<Begas_VM>
k, redland and unixodbc fine for LO
<Anarchos>
i try to make the ocaml development type accept to create an "haiku" os_type, alongside with "win32" and "unix" :)
<Begas_VM>
and got it working Anarchos?
<Begas_VM>
checking for libltdl ...
<Begas_VM>
checking ltdl.h usability... yes
<Begas_VM>
checking ltdl.h presence... yes
<Begas_VM>
checking for ltdl.h... yes
<Begas_VM>
checking for lt_dlinit in -lltdl... yes
<Begas_VM>
checking if libltdl package is complete... yes
<Begas_VM>
so far looking good
<Habbie>
Begas_VM, i did libversionCompat for libtermkey/vis btw
<Begas_VM>
skipping x11-libs
<Begas_VM>
sec, checking Habbie
<Habbie>
no rush
<Habbie>
just wanted to make sure you didn't miss it
<Begasus>
Habbie, I don't see the change in the PR?
<Begasus>
still says: lib:libtermkey$secondaryArchSuffix = $portVersion
<Habbie>
lol
<Habbie>
sorry
<Begasus>
;)
* Habbie
boots haiku
<OscarL>
K. Seems the Lout addon for Pe is calling proxy.AddInclude() with the proper filenames, but when you click on one of the include items to open it...
<OscarL>
the msg_OpenInclude handler contains garbage instead of the correct path :-/
<Habbie>
Begasus, pushed
<Habbie>
i remembered to commit, which is something
<Habbie>
but then i just left the commit there ;)
<Begasus>
IIRC libVersion is not portVersion ;)
<OscarL>
false alarm... using the variable how it its supposed to be used yields the correct path up to that point at least... the search for the bug continues...
<Begasus>
holy moly, think I've made a mistake there Habbie , there is only a static library there?
<Habbie>
i hope not
<Habbie>
but that'll have to wait
<Begasus>
I'm not seeing a shared one ... (although my mind tells me there was one, otherwise I wouldn't have mentioned libVersion..) :/
<Anarchos>
Begas_VM i do my best :)
zard has joined #haiku
<OscarL>
"libtermkey$secondaryArchSuffix = $libVersion" shouldn't that be $portVersion?
<Habbie>
i was also wondering just now
<OscarL>
next line seems fine :-)
<Habbie>
i very much welcome comments, i barely know what i'm doing here
<OscarL>
(assuming that version matches the SONAME thing)
<Begasus>
actually should be libVersionCompat (if there is/was a shared library) instead of libVersion there
<OscarL>
Finally! Seems Pe's "OpenIncludes" didn't expected absolute paths, and that's why it didn't worked.
<OscarL>
(for the Lout's addon, that called AddInclude() with absolute paths)
<OscarL>
Sigh... just a 5 lines change (not counting closing braces)... damn thing was driving me nuts.
<Begasus>
that makes 2 of us today OscarL :)
<zard>
OscarL: Vim also provides an easy mode with `vim -y`. Just beware that Vim is even more difficult to exit in this mode than normal :D
<OscarL>
already noticed zard, heheh, that's why I searched for an alternative :-P
<OscarL>
would be cool to have YouCompleteMe, but while it works for vim, it crashes gvim right at start :-(
<OscarL>
next best thing... this /bin/clangd running with whatever plugin that vimrc from Glog78 is using :-)
<OscarL>
oh nice... on gvim I get an "LSP" menu, making things far more discoverable for a dumb dumb like me :-D
<Anarchos>
OscarL congrat, i will look to it as soon as it will become available on haikuports
<Habbie>
love LSP
<Skipp_OSX>
maybe it's just me but why can't the_silver_searcher_x86 be called 'ag' ? would make my life easier if it was. I realize that's the name of the app but I don't care I call it ag
<Anarchos>
Habbie i too
<Skipp_OSX>
as in `pkgman install ag` instead of `pkgman install the_silver_searcher_x86`
<Habbie>
pkgman install cmd:ag
<OscarL>
Anarchos: YouCompleteMe has a Draft recipe, but not sure who will find and fix the gvim crash. This other thing I'm using now won't be packaged, as is just "user-config stuff".
<Skipp_OSX>
oooooooooo I didn't know you could do that
<Skipp_OSX>
ok
<OscarL>
(the needed pieces are already on the depot: vim, clang)
<Anarchos>
Skipp_OSX there is also a pkgman install lib:XXX syntax
<OscarL>
and "devel:xxx"
<Skipp_OSX>
What can I say, I'm a creature of Habbie
<Skipp_OSX>
but that all sounds very nice
<Habbie>
:)
<Begas_VM>
Think I'm done with the recipes for static libraries (beside the ones I may have missed) :)
<Begas_VM>
libsvn ...
xet7 has quit [Ping timeout: 480 seconds]
hightower2 has joined #haiku
<OscarL>
"query -a name=*.a | wc -l" -->> 202 :-/
<OscarL>
I might need to do some clean up here :-D
<Begasus>
not all need to be removed :)
<Begasus>
llvm, qt ... bundles quite some there that need to stay
<OscarL>
149 under /system. Yup, mostly libclangxxx.a
<OscarL>
still some from both Pythons and some of its packages (numpy, for example)
<Begasus>
those probably are not installed through prepareInstalledDevelLibs
<Begasus>
and don't end up in developLibDir :)
<OscarL>
yup, either under "vendor-packages", or under "python3.x/config-3.x/"
<OscarL>
still got some from SDL here. the rest seems reasonable.
<Begas_VM>
yes, the ones from SDL are not the same name as the shared ones
<OscarL>
I see. then I'm not that far off... just need to clean up some work dirs :-D
<zard>
One method is to use a semaphore, but I would either have to create a semaphore for each event that could be waited on
<zard>
or check if the right event has occurred after the semaphore has been released.
<Anarchos>
zard poll or select ?
<Anarchos>
zard condition variable ?
gouchi has joined #haiku
qwebirc5840 has joined #haiku
<zard>
Condition variables look interesting...
<qwebirc5840>
I need to enable 'fail_safe_video_mode true' in ~/config/settings/kernel/drivers/kernel on the install media but I can only mount it as read-only, so how do I make the kernel modification?
<waddlesplash>
zard: in kernel or userland?
<waddlesplash>
qwebirc5840: you can enable this in the bootloader menu
<waddlesplash>
(only applies to one boot)
<qwebirc5840>
I have Haiku on a 8GB USB disk and need to adjust the video to do the install. OK so when it is booting is there a key combination to press to enter the bootloader. Is it like grub and just pressing 'e'?
freddietilley has quit [Quit: WeeChat 3.8]
<zard>
userland
gouchi has quit [Quit: Quitte]
<zdykstra>
qwebirc5840: are you doing legacy booting, or EFI booting?
<zdykstra>
that doesn't really answer the question - but you can either hold shift to access the menu or bang the space bar until you get there, depending on your system
<qwebirc5840>
I believe that all intel Mac are EFI
<zdykstra>
then you can enable 'Use fail-safe graphics driver' for the purpose of the install and then modify the file you listed previously
mmu_man has quit [Ping timeout: 480 seconds]
<zdykstra>
huh, going back as far as the core2duo era of MacBooks, they are EFI. That's mildly surprising.
<zdykstra>
so repeatedly hitting the space bar is your menu access method
<Skipp_OSX>
how is that mildly surprising?
<Skipp_OSX>
Apple never shipped a machine with a regular PC BIOS, and the earliest Intel Macs from 2006 were the first core series so there should be no surprise.
<zdykstra>
because I wasn't expecting that? Hence, 'mildly surprising'.
<Skipp_OSX>
the early Macs did have a 32-bit EFI which was a bit quirky tho
<Skipp_OSX>
early /Intel/ Macs I mean
<puck_>
i think that was efi 1 as well?
<puck_>
even while they're efi, most of them run windows/bootcamp under CSM
<qwebirc5840>
Well just tried shift and spacebar and neither got me into the boot loader, I guess no Haiku on this old hardware back to Ubuntu. Thanks, will continue playing with Haiku in VMs and maybe someday get real hardware that I can put it on.
<zdykstra>
did you repeatedly hit spacebar? It might take a few tries.
<Skipp_OSX>
hold spacebar
<Skipp_OSX>
it's tricky to do sometimes so I can't blame you for having trouble
<Skipp_OSX>
you gotta wait until after the bios loads but before the OS boots you have a narrow window there to hold spacebar in
<Skipp_OSX>
is Ubuntu still Unity or did they ditch that?
<qwebirc5840>
Yeah I know it is a short window, tried all combinations multiple times and nothing. I am even trying my BeOS 5 CD and it just stops at the loading screen between the PCI card and the lightning bolt.
<OscarL>
Can't mount the usb install media on a a Haiku VM, and edit the vesa file that way?
<qwebirc5840>
I'll give that a try
<Skipp_OSX>
hmmm BeOS doesn't even get the memory count before giving up
<Skipp_OSX>
mmmm or maybe it does, I'm not sure which icon is the memory count on BeOS
<Skipp_OSX>
lemme check... yep pci card icon is memory count, it's expected to fail there if you have > 768MB of RAM
<Skipp_OSX>
which of course you do, as that's a tiny amount of RAM these days
<qwebirc5840>
yeah 4GB of RAM in this 2007 MacBook
<Skipp_OSX>
WAY too much for BeOS R5
<Skipp_OSX>
you might be able to patch the boot-loader but I haven't managed to get that to work yet
<OscarL>
Using a prepatched "distro" like BeOSMaxEdition might help
<qwebirc5840>
Going to try Haiku VM mounting the USB stick and see if I can modify the ~/config/settings/kernel/drivers/kernel to use the fail-safe video mode
<OscarL>
you can even boot that install media on a VM, and just edit the file there.
<OscarL>
then on real hardware it will boot in Desktop mode, and you can open the Installer from Deskbar.
<zdykstra>
good idea
<Anarchos>
Skipp_OSX i remember an option in haiku_loader to limit the memory to 4Gb ?
<Skipp_OSX>
yep
xet7 has joined #haiku
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<zard>
<Skipp_OSX> "is Ubuntu still Unity..." <- No, I believe they use Gnome by default now.
<nekobot>
[haiku/haiku] c7cd1bae689d - BeControlLook: fix clipping rect, part of #12890
Inklime has quit [Ping timeout: 480 seconds]
<OscarL>
On https://review.haiku-os.org/c/haiku/+/5969 PulkoMandy asked for someone to "rebuild the repository" so that change can be merged. Do we need to CC someone in particular? (or perhaps it is just something low prio)
<PulkoMandy>
I can probably do it, just didn't have time
<PulkoMandy>
Waddlesplash or kallisti5 also could
BrunoSpr has joined #haiku
<OscarL>
ah, np! just wondering.
tuaris has joined #haiku
<glog78>
damm v lang has troubles with termio
<glog78>
:(
<glog78>
i am still searching for one of the modern languages to play around
<glog78>
rust -> rust-analyzer seems to have problem (can't say if vim9-lsp or the lsp server)
<glog78>
btw how many hugs do i need to spend to get a newer version of vim ? ... some kinda nice features like virtual text are missing in the current version
<BrunoSpr>
hello all... Where to find the /tmp folder?
<glog78>
vlang -> doesn't compile even it at one time did after commenting out an include according to a github thread i found
<glog78>
go -> is totally outdated on haiku
<glog78>
the idea is ... all of those languages have great and easy to use libraries for networking / json and stuff
<glog78>
a big plus with so much stuff which is only happening online nowadays
<Begasus>
BrunoSpr, /var/tmp ?
<Begasus>
waddlesplash, looks like we need to keep the shared library for libtool, you probably saw the logs from earlier
<BrunoSpr>
ah Begasus... thanks...
<OscarL>
Glog78, I've updated the vim recipe recently to the latest vim version, but didn't touched the features it is build with (as I'm not much of a vim user).
<OscarL>
you may want to open an issue over haikuports listing the features you think we should enable (assuming they work ok on Haiku :-D).
<Begas_VM>
Glog78, you could add an issue for missing features ...
<Begas_VM>
OscarL beats me ;)
<OscarL>
yes! :-P
<Begas_VM>
parse errors for libdvdread (gcc2)
<glog78>
OscarL started to feel more and more love for vim (to be more exactly neovim) like one year ago. And since a while i think once you get into it that it is as powerfull as visual studio code with being much more customisable than visual studio code in terms of resources and what is enabled at a certain time
<glog78>
is it for everyone no -> because you need to want to take your time to make vim / neovim yours. Once you do ... it's just a rabbit hole
<glog78>
@Begas_VM on the official bug tracker ?
<waddlesplash>
for vim, on the haikuports bug tracker
<waddlesplash>
Begasus: all those errors have solutions, but, due to korli's comments I think keeping it does make more sense after all, indeed
<glog78>
thank you guys :) github i am in for it :)
<OscarL>
my main issue with vim and the like, is that they seem (to me at least) assume the user is an English native speaker... so "remembering" commands comes more naturally.
<Begas_VM>
less hastle to fix the current ones still using the shared ones, for those that don't need they can be removed (mpg123 and flif don't use it for instance)
<OscarL>
that's why I tend to favor cua-key-bindings (easier for my muscle memory, and no "translation" involved :-D)
BrunoSpr has quit [Quit: Vision[]: Ich wurde gewaschen!]
BrunoSpr has joined #haiku
<glog78>
OscarL yeah the defaults sometime sucks , good you can remap everything. But in the end vim's way of editing text is different from what i was used before. After slowly getting into i am now as fast as i would most likely be with a "regular" editor but i know that i should improve much more if i would dive deeper into all the shortcuts and put them in a way comfortable for me
Begasus_32 has quit [Quit: Vision[]: Gone to the dogs!]
<Begasus>
OscarL, will have a look at it ;)
<Begas_VM>
17 static ones in /boot/system/develop/lib :)
<Begas_VM>
when the one from libtool is gone 16 (those should be ok)
<OscarL>
damn! vim devs have really embraced the "release earlier, release often" :-D
<Begas_VM>
had that with texsturio once, new release pushed and the next day they released a new version :P
<BrunoSpr>
Begasus... need some help: Can you manage to find the USB descriptors for the mouse? They should be in /tmp when the system is booted. PulkoMandy wrote... How to get these descriptors.. very confusing because I have no /tmp file in there...
<Begas_VM>
no idea there BrunoSpr, sorry
<glog78>
they needed to change considering neovim is a highly active project and in a way neovim and vim fighting for the same people
<OscarL>
if that feature was added in 2022-09-10, shouldn't that be already available in our version Glog78? (it is only 4 days old :-P)
Begas_VM has quit [Quit: Vision[]: i've been blurred!]
<glog78>
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Apr 23 2023 14:28:55) << i could download is from 28 Jun
<glog78>
(vim --version)
<Begasus>
k, done for today, cu peeps!
Begasus has quit [Quit: Leaving]
<glog78>
Begasus thank you alot
<glog78>
i am 99% out of luck with termios and vlang i guess
<OscarL>
vim 9.0 might have been released on Jun 2022, but 9.0.1479 is from 4 days ago.
BrunoSpr has quit [Quit: Vision[]: Ich wurde gewaschen!]
<glog78>
that would be crazy
<OscarL>
vim released twice today only :-D (9.0.1489 and 9.0.90)
<Skipp_OSX>
I see there's a link at the top that says that
<glog78>
btw now its 9.9.1491
<glog78>
btw now its 9.0.1491
<glog78>
rofl
<glog78>
but it should be available since 2022-09-10
<OscarL>
Skipp_OSX, yeah, that worked (adding the www.)
<glog78>
so maybe we really need to add a feature enable for that
<OscarL>
that's what I was after.
<glog78>
but there is nothing in the documentation
<Skipp_OSX>
I see how it is, I can't talk pol here but you all post websites with Ukro flags on them
<glog78>
let me check something
<OscarL>
welcome to the world of software packaging!
<Skipp_OSX>
(osnews.com too, bah)
<OscarL>
there's a difference between sharing a link to a site I don't have control over, that may have unrelated stuff to my main insterest, and just doing that offtopic myself.
<waddlesplash>
yeah, exactly
<Skipp_OSX>
ok fair
<waddlesplash>
and people can get as off topic as they want in #haiku-offtopic
<waddlesplash>
now this is going to be a fun one to try and fix
<OscarL>
I've tried with YouCompleteMe and Python files, worked well, but again, only on vim (seg-faults gvim, some bad interaction there)
<waddlesplash>
(in fact, it was already a fun one to find the cause of in the first place, I ran into it multiple times before without real luck in tracking it down, before last summer's modifications)
<OscarL>
meanwhile I get bamboozled by some missing semicolon :-D
<glog78>
waddlesplash: congratz this is a hard one to track down
<OscarL>
guess some of us need to fill up the rest of the bell curve :-P
<Skipp_OSX>
syntax errors are easy, deadlocks are hard
<OscarL>
^ now I underestood my own joke, thanks!
<glog78>
why do tools complain about not be able to symlink but i an do a ln -s ?
<glog78>
i can do ...
<Habbie>
symlink or hardlink?
<waddlesplash>
there are no hardlinks on BFS, yes
<waddlesplash>
there are symlinks
<waddlesplash>
so an "ln" without "-s" won't work, indeed
<Habbie>
i noticed, yesterday, incidentally
<Habbie>
or a few days ago, when a backup from haiku to a linux system somehow doubled in size
<glog78>
symlink as far as i see
<Habbie>
haven't figured out why yet
<waddlesplash>
(if you mount an ext4 partition or some other FS that does support hardlinks, it will work there just fine. it's just BFS that doesn't support hardlinks, not Haiku)
<glog78>
also npm is another tool which is "outdated" or to be more exactly the node which npm uses
<zdykstra>
mounts a bfs image, rsyncs to it, then rsyncs the image to a remote server where it gets into my ZFS snapshot rotation
<glog78>
OscarL this happened when i tried to use npm install
hightower2 has quit [Ping timeout: 480 seconds]
qwebirc5840 has quit [Quit: [Thanks for the help]]
<waddlesplash>
yeah we need to update node
<waddlesplash>
jessicah was working on that but ran into some bugs in Haiku
<waddlesplash>
I was actually meaning to look at those bugs this week
<Habbie>
zdykstra, why not mkdir -p instead of test || ?
<glog78>
I really don't want to stress anyone !
<Skipp_OSX>
APFS also doesn't support directory hard links, and the reason is the same as BFS, Dominic Giampaolo
<zdykstra>
Habbie: 6 of one, I guess
<glog78>
Just writting down what i notice trying to setup haiku a little further than only the desktop
<Habbie>
zdykstra, trade you for half a dozen
<zdykstra>
deal!
<glog78>
in this case it was installing bash-language-server
jmairboeck has joined #haiku
<Habbie>
zdykstra, ah, an image, clever
<zdykstra>
it's funny having a bandwidth replicant on my desktop. Every key press in my IRC client (weechat over ssh) causes little spikes in the graph.
<Habbie>
haha
<Habbie>
the per-keypress overhead for that mode of operation is huge
<zdykstra>
I made a 10GB image, worked pretty well. But I rely on ZFS snapshots to actually keep old data for me. So the image file only ever holds the most current copy of things.
<Habbie>
right
<Habbie>
i stick most things into restic, but i think it's not in haikuports yet
<nekobot>
[haiku/haiku] 484bf053dc67 - VMCache: Use THREAD_BLOCK_TYPE_OTHER_OBJECT.
<Skipp_OSX>
node is trying to write to a read-only packagefs directory, not a hard link issue
<Skipp_OSX>
node_modules/ directory needs to be put somewhere else (in the package config)
<glog78>
may i ask a design question ?
HaikuUser has joined #haiku
HaikuUser has quit []
<Skipp_OSX>
sure
<glog78>
why not makeing a virtual filesystem which contains the "unix" structure
<glog78>
this "unix" structure is "writeable" and typical unix ports gets installed with this directory as prefix
jmairboeck has quit [Quit: Konversation terminated!]
<Habbie>
what problem are we solving?
<glog78>
this could reduce the porting overhead to adapt every package on the filesystem structure of beos
<glog78>
like for example right now npm
<glog78>
or i used make install which installed man files to $PREFIX/usr/share ...
<glog78>
and and and
<glog78>
also this structure could hold interopt libraries so you could update this side independendly from loosing compatibility with beos
<glog78>
it's just something which got on my mind with my very limited experience
<Skipp_OSX>
Well first of all we don't want the unix directories because we don't like them, ok well some people don't like the way they clutter up the root of the fs. Secondly, we have decided to create packagefs virtual file system that merges in directories from packages with non-packaged directories into read-only file system. Basically we created this problem for package maintainers on purpose because of how we designed our package system.
<Skipp_OSX>
I'm not sure why we call it "non-packaged" instead of the more canonical "unpackaged" would have made more sense and not used a -
<glog78>
i could imagine so much
<Skipp_OSX>
but that's a whole other story
<glog78>
so i did ./configure --prefix=$HOME/config/non-packaged
<OscarL>
doesn't "unpackaged" implies/suggest (or can be read as) that it was packaged and then un-packaged? while non-packaged is... well... that.
<OscarL>
like... unzipped vs non-zipped.
<glog78>
and while the files in $HOME/config/non-packaged/bin was in path and could be used
<Skipp_OSX>
I guess so
<OscarL>
Might be my poor English, thou.
<Skipp_OSX>
your English isn't so bad, that must be the thinking
<glog78>
the man files in $HOME/config/non-packaged/usr..... where not found by man
<Habbie>
man or man -k?
<glog78>
man
<glog78>
maybe something is even missing on my side
<OscarL>
mandoc has problems with man page from packages installed in HOME, at least.
<glog78>
and i could have easily merged this one directory with /boot/system/documenation/man/ where i guess they belong to
<OscarL>
(then man complains everytime you use man after that)
<glog78>
OscarL i did ./configure | compile myself
<Habbie>
from my notes: after installing my wdiff package, man wdiff works but mentions man: outdated mandoc.db lacks wdiff(1) entry, run makewhatis /boot/system/documentation/man. Running that makes the message go away, but should this be automated?
<Habbie>
:)
<glog78>
yeah Habbie that works for /boot/system/documentation/man
<OscarL>
Habbie remembers, I see.
<glog78>
i have seen this a few times when installing packages
<Habbie>
OscarL, maybe - do we even have triggers (like Debian does) for a port to tell another port "i got into your stuff, please see it"?
<Habbie>
(i mean, if we don't, it's still a bug, it just starts outside the man port)
<OscarL>
I think I have it already on my "Things to check if I can try to fix someday" list.
phoenix has joined #haiku
<Habbie>
hehe
<Habbie>
that's this list too
<Habbie>
(it's very big)
<glog78>
and sorry if i asked stupid questions
<glog78>
but while i found alot of documentation towards the api and the desktop usage , the documentation for the command line is very little
<glog78>
or for the packaging (at least what i found so far)
<OscarL>
we are all l33t h4xors! no need for docs!
<glog78>
OscarL ... i would be happy to be able to call myself intermediate pc user i am far from what i call a h4xor
<Habbie>
i know you're joking but it's always a real problem
<glog78>
like another example i run into with my first installation
phoenix has quit []
<OscarL>
Glog78, I'm of course, just kidding. More likely becase the team is really small, and there's so much that people can do.
<glog78>
ssh-copy-id does connect to $HOME but after creates the keys in $HOME/.ssh
<Habbie>
oh, i hadn't even tried ssh-copy-id, but there are more problems there
<glog78>
the default config in haiku expect the files in /boot/system/settings/ssh/
<Habbie>
man ssh_config does not know that
<Habbie>
but i don't think fixing that will fix ssh-copy-id ;)
<glog78>
wrong path
<OscarL>
This OS feels like a restaurant with really tasty food, but if you miss a glass or a fork, or some ketchup... be prepared to help yourself :-D
<Habbie>
yeah, ssh-copy-id can't know that
<Habbie>
the way it is currently written
<glog78>
$HOME/config/settings/ssh/authorized_keys is the right file
<glog78>
there are multiple ways to handle this
<glog78>
but this is making configuring ssh for average user nearly impossible when it comes to a more secure way
<glog78>
and every security specialist suggest you to not use username/password anymore specially since the username is fixed in haiku's case (aka default = user in prebuild installation images)
phoenix has joined #haiku
<Habbie>
to be fair, haiku has zero security focus anyway
<Habbie>
the only user is root
<Habbie>
that said, making remote access secure would be the first step
<Habbie>
and it would be nice if ssh was easier to configure and if ssh-copy-id worked
<Habbie>
making sshd easier to set up should not be hard; making copy-id work feels a bit more complicated
<glog78>
and ssh which should be used instead of both other needs to change a file
<Habbie>
indeed, it should be that easy, and it can be
mattlacey has joined #haiku
<Habbie>
just isn't now
<glog78>
and even than is not as easy to make secure ... average users might use what works
<glog78>
a workaround could be a default symlink
<Habbie>
i thought about that too but it would hide bugs in software that uses the wrong path
<glog78>
yeah but i guess in the end you won't get around to accept $HOME/.ssh being the user directory for ssh
<glog78>
every external tool expect it to be there
<Habbie>
every? or just one?
<glog78>
good question
<glog78>
but this one is used in many user guides
<Habbie>
can't deny that
<glog78>
also even if that is fixed .. it doesn't fix the issue with how to first upload the certificate
<glog78>
even that could be included in the installer
<glog78>
like hey if you want to login using ssh please copy now your public key or select your public key
B2IA has quit [Quit: Vision[]: i've been blurred!]
<glog78>
if a key is uploaded during installation you could enable ssh easy
<Habbie>
the installer, currently, is a terrible place for that
<Habbie>
well, no, take that back
<Habbie>
whatever you get when you boot your usb stick the -first- time is a bad place for that
B2IA has joined #haiku
<glog78>
since you can mount other filesystems during installation (even currently only throu the partition program) you could just mount an other usb device with the pub key (advanced user)
<glog78>
and i am just spinning ideas right now
<glog78>
the big question is how to get the pub key very easy into the system for the users
<waddlesplash>
osnews.com is currently at 400 referrers, and that's of course just people who don't have DNT enabled or other privacy-protecting things that defeat our analytics
<OscarL>
"pkgman install pip"... that might be pip for python2 actually :-D
<Habbie>
ouch
<OscarL>
nah... it is just the generic base package.
<OscarL>
that doesn't includes nothing (known defect of all python packages on Haiku)
<Habbie>
so, ouch
<Habbie>
ack
<OscarL>
Glog78. make sure to "pkgman install pip_python39"
<OscarL>
that should give you /bin/pip, /bin/pip3 and /bin/pip3.9
<glog78>
i have a terminal with Ligatures support so for coding this is amazing for angband it's better to use NoLigatures
<OscarL>
also... the online instructions to installl jetpack fail on Haiku.... curl has problems understanding that it can write in under ~/config/settings/ if you pass it as /boot/system/home/[...]-
<OscarL>
(complains about the FS being RO :-D)
<glog78>
yeah i noticed this ... i was to lazy to check deeper and just made me a notice where the file should be installed
<glog78>
i am also not really happy about jetpack cause JetpackSync seems not to deinstall
<OscarL>
I used wget + cp to the correct place.
<glog78>
maybe dein or plug is a better choice
<glog78>
at least if that should become some sort of guide i would probably switch to something else
<OscarL>
I was just happy to be able to add the cua-mode.vim thing without even knowing what I was doing (as usual)
<OscarL>
Finally! Got both the lout package, and the Pe support for it working as I wanted!
<glog78>
OscarL do you use python ?
<glog78>
i can try pyls
<OscarL>
I used Python daly for 6 years at work (python 2.4-2.7)... then forgot almost 80% of it... :-D
Diver has quit [Quit: Leaving.]
<OscarL>
I think I've tried one of the py lsp... but can't remember which one...
<OscarL>
surely was when trying the CudaText editor.
<OscarL>
don't know which one is the one that YouCompleteMe for vim includes, that seems to work well enough to.
<OscarL>
but having somthing working on gvim will be nice too :-)
<OscarL>
Glog78 you could use a gist over github for your vimrc, so we can keep track of it.
<glog78>
https://termbin.com/9e8lt << last config update ;) it includes now git fugitive and swap files will be created outside of the project directories
<OscarL>
swap fils are temp files?
<glog78>
kinda
<glog78>
if vim breaks you can recover from swap files
<OscarL>
I might might wanna move those to /var/shared_memory/vim_temp.
<glog78>
so it's good to survive a reboot in case of a kernel panic
<OscarL>
I'm YOLOing it baby!
<glog78>
:)
<OscarL>
well... enough keyboard/head smashing finally resulted on 3 small PRs today. I call that a win.
<OscarL>
(unless I get roasted at the reviews :-P)
* augiedoggie
wonders why concourse is paused
OscarL has quit [Ping timeout: 480 seconds]
<augiedoggie>
mm, just the bootstrap builds are paused
<augiedoggie>
the nightly builds are failing on concourse, so it's not just me :P