<waddlesplash>
you don't need to replicate it exactly, or even have the same software, just something interesting with a whole bunch of stuff running at once :)
<Begasus>
sure will have a look later
<waddlesplash>
very good
<Begasus>
is kqueue also fixed on the buildmasters?
<waddlesplash>
yep
<waddlesplash>
tor build completed successfully
<Begasus>
ok, I think libgit was infected by it, hence it failed on previous bump
<waddlesplash>
ah, that was __inline
<waddlesplash>
but that's also fixed yes
<Begasus>
heh, need to grab the ones from the Depot for some nice screenshots :)
<Begasus>
+1
* Forza
Good Morning! C(_) coffee time :)
<waddlesplash>
btw, so it doesn't get lost in the noise: there's torrent links a bit in the scrollback which could use seeding, if anyone goes for that sort of thing
<Begasus>
g'morning Forza, yeah! that's a nice one :) C(_)
<Begasus>
should check if latest ktorrent is up for the job
<Begasus>
24.07.80, needs a bump here ...
DKnoto_W has quit [Quit: Leaving]
<Begasus>
a mention for KDE KF6 frameworks would be nice too I guess :) mostly the work was done prior on KF5, but it brings us up to the next era in KDE ported apps
<Begasus>
a lot has happened since beta4
<Begasus>
waddlesplash, the iso is on the same hrev as currently the one from the r1beta5 repos?
<Begasus>
got an update to -113 this morning
DKnoto has joined #haiku
<Forza>
How close are we to beta5 at the moment?
<waddlesplash>
Begasus: +113 yes
<waddlesplash>
Forza: we're at the "sync to mirrors and prepare to launch" stage
<Forza>
Cool. I guess i should 'sync' my mirror now then?
<waddlesplash>
that would be nice :)
<waddlesplash>
we'll see how far we get with mirror syncing over the next 12h
<PulkoMandy>
Mh... not sure this will work yet, I should wait until the torrent is downloaded
<PulkoMandy>
It downloaded 5% of the file and then stopped making progress :/
<Begasus>
something strange, ktorrent doesn't build anymore: fatal error: QDBusConnection: No such file or directory
<Begasus>
had that up and running earlier (ps newer then the one in the depot)
<PulkoMandy>
Well these torrents don't seem to really work for me
<PulkoMandy>
I'll try a different client...
m_eiman has joined #haiku
tuaris has quit [Quit: Leaving.]
m_eiman has quit [Read error: Connection reset by peer]
m_eiman has joined #haiku
<Begasus>
am I wrong or not a lot of new was done for GTK lately?
<Begasus>
ClawsMail has seen some work ... but other then that?
<BlueSky76>
Added both torrents to my transmission client (actually transmission daemon running on my Linux machine). x86_64 version already downloaded and seeding. x86_gcc2h taking much longer. Something seems not quite right with that one. For 160 MB of verified data it has already downloaded 7.7GB of corrupt data.
<Begasus>
nice, Dolphin24 from the Depot pretty good! :P
* phschafft
carefully checks for nephele first.
* phschafft
then opens a cookie jar offering Begasus it's content.
* Begasus
slowly shufles towards phschafft, grabs 2 and runs like **** to his own place while wispering "thank you sir!"
* phschafft
nods with a friendly smile before closing the jar again and puting it back into his secret place.
<Begasus>
+1
diver has joined #haiku
<phschafft>
:)
_-Caleb-_ has left #haiku [#haiku]
_-Caleb-_ has joined #haiku
<dovsienko>
OscarL: worked for me for both, although the 32-bit one was slower
<dovsienko>
actually, still is slower because it is still in progress
<OscarL>
I see. I did find it odd that the web seed was missing for the gcc2 one.
<OscarL>
try manually adding it if your bittorrent client allows you to do that_
<OscarL>
s/_/?/
<dovsienko>
so, I managed to hang my temporary Haiku PC by compiling libpcap (both with and without RAMFS), so this morning I disabled hardware watchdog in the BIOS and reinstalled it using beta5. let's see if that makes any difference...
<dovsienko>
OscarL: I did not add anything manually, the 32-bit one already uses https://s3.us-east-1.wasabisys.... wait
<dovsienko>
in the 32-bit torrent file the web seed is for the 64-bit file, as far as I see
<OscarL>
for me it was empty, so I copied the 64 bit one, and changed the "x86_64" to "x86_gcc2h" :-)
<OscarL>
smoke tested both isos in VBox, both looked fine (and with the correct content).
<botifico>
[haikuports/haikuports] Begasus 439a868 - dolphin24, put Deskbar link in main menu (#11118)
<dovsienko>
this is what my Transmission shows in the torrent properties: https://0x0.st/Xx3w.png
<dovsienko>
grep --text wasabisys haiku-r1beta5-x86_gcc2h.torrent and you see it. something must be wrong
<OscarL>
seems more than a bit off (32 bits off, one could say :-P)
<Begasus>
heh
HaikuUser has joined #haiku
HaikuUser is now known as JackDaniel
<OscarL>
yeah, right at the end of the .torrent file, I see "url-list89:https://s3.us-east-1.wasabisys.com/haiku-release/r1beta5/haiku-r1beta5-x86_64-anyboot.isoe". kallisti5[m] must have just pasted the wrong link there.
<dovsienko>
does it explain why the sizes are the same and does it mean the contents is wrong after the download?
<OscarL>
file sizes being the same might just be because of differing free-space on the images.
<OscarL>
content for me was OK on both (but I *did* changed the web-seed URL)
<dovsienko>
alright, I am downloading both files from S3 to compare the sizes and the checksums with Transmission downloads
<OscarL>
Just in case... these are the sha1sum for both files I got:
<botifico>
[haikuports/haikuports] Begasus 1346141 - konsole24, add KF6 version (#11119)
HaikuUser has joined #haiku
<OscarL>
JackDaniel: what's "better" is a bit subjective, I'm afraid. Most Haiku-fans would prefer native apps, but that might not make sense if you intend for your apps to be available on other OSes.
<OscarL>
Also... what's "faster" would also more likely depend on your familiarity with a given API than anything else, I would assume.
<OscarL>
*faster for writting apps, I mean.
<HaikuUser>
./nick rui
HaikuUser is now known as rui
<OscarL>
JackDaniel: if you want a mix of both... you can try the Python bindings for the Haiku API...
rui is now known as ruid
<Begasus>
JackDaniel, iirc there is no pyqt6, so if you plan to use both Qt5 is the only option there
<PulkoMandy>
well I'm deleting the nonworking 32bit torrent from my machine for now, let me know when there is a working one that doesn't need manual tweaking
<dovsienko>
if this improvised Haiku box hangs during the build again, perhaps the next best move will be to replace the thermal paste anyway
<dovsienko>
the 32-bit torrent somehow managed to "download" 14.5% and is still downloading something from somewhere; if that manages to complete, I am going to compare the checksum
ruid has quit [Quit: Vision[]: i've been blurred!]
<OscarL>
dovsienko: earlier BlueSky76 mentioned that for him it donwnloaded "7.7GB of corrupt data".
<dovsienko>
oh
<OscarL>
before he paused it,
<Begasus>
Dolphin24 on 32bit OK too! :D
xet7 has joined #haiku
<dovsienko>
remarkably, the number of megabytes downloaded for this torrent goes not only up, but also occasionally down
<Begasus>
eeps :)
<dovsienko>
so I suppose it is not going to complete
<Begasus>
nuked the 32bit one also
JackDaniel has quit [Quit: Vision[]: i've been blurred!]
<dovsienko>
214.7 -> 215.0 -> 216.7 -> 214.8 ...
<dovsienko>
"15 minutes remaining"
nephele has joined #haiku
<phschafft>
nephele is here!
* Begasus
tries to whisle .... ffffppppppppp (doesn't work atm)
<Begasus>
hi nephele! :)
mmu_man has quit [Ping timeout: 480 seconds]
<nephele>
camping for my arrival? :P
<nephele>
hi phschafft, Begasus
* phschafft
looks at Begasus and then back to nephele: kind of....
<nephele>
TIL, if you send a pdf document without naming it ".pdf" you might get an email back that the document could not be opened... jeee
<Begasus>
lol
<Begasus>
phishing are we? :)
<Begasus>
biab
<nephele>
Yes, of course :D .pdf.exe.elf
<dovsienko>
something is off with the Clock demo
<dovsienko>
it is 12:07 and the minute hand looks about in the right place, but the hours hand is still behind 12
<dovsienko>
does anybody else see the same?
<nephele>
it seems slightly off, yes. But I don't know if this is significant, some physical clocks do that too ;)
<nephele>
although under the magnifier it looks correct, might have to do with the subpixel layout?
novaphoenix has quit [Quit: gone fishing]
novaphoenix has joined #haiku
andreaa71 has joined #haiku
<andreaa71>
peace and love :)
nephele_xmpp has joined #haiku
rexbinary_ has joined #haiku
rexbinary has quit [Ping timeout: 480 seconds]
rexbinary_ is now known as rexbinary
nephele has quit [Quit: Vision[]: i've been blurred!]
nephele_xmpp has left #haiku [Disconnected: Replaced by new connection]
<dovsienko>
aha... so it reset during the build again. turns out I do not have a reliable Haiku box :-/
bjorkintosh has joined #haiku
<kallisti5[m]>
OscarL: uh oh
<kallisti5[m]>
let me check
<kallisti5[m]>
the x86_gcc2 torrent has the x86_64 webseed 😥
<OscarL>
dovsienko: which CPU does that PC has? (some AMD ones are known to be unstable with Haiku.... the Jaguar/Puma/Bulldozer ones, IIRC).
<dovsienko>
OscarL: "AMD Turion(tm) II Neo N40L Dual-Core Processor"
<OscarL>
Athlon/Athlon II work, Ryzens too, but the ones in middle of those... not so much.
DKnoto_W has joined #haiku
<dovsienko>
does it have to do with SMP or something else that can be disabled in the BIOS?
<kallisti5[m]>
the webseed on the x86_gcc2h torrent has been fixed. Though, I don't see the "isoe" part
<OscarL>
kallisti5[m]: that was when I opened the .torrent with a text editor.
<kallisti5[m]>
ah, ok
<OscarL>
dovsienko: not sure. But that turion seems to be from the Athlon/Phenom II era, so not sure it would be the same issue as with the Bulldozer CPUs.
<kallisti5[m]>
😓 I thought I accidentally pushed to master
<OscarL>
:-D
<dovsienko>
actually, I stand corrected: on the inside it is one of those designs where one needs to unscrew a hunder hidden screws to get access to the SATA disk...
<Begasus>
k, once you know where to look ... :) Okular latest with Haiku icons and using system colors :D
Begasus_32 has quit [Quit: Vision[]: i've been blurred!]
<Begasus>
OscarL, what was this thing with scipy again?
<Begasus>
still have the packages here for 64bit and noteshrink seems to be ok with those installed
<OscarL>
it worked locally (1.6.3 IIRC), but failed on the buildmasters (it made them hang)
<Begasus>
maybe could host them temp so we could clean the report? :)
<Begasus>
biab
<OscarL>
or retry a build now, surely nothing bad can happen on a friday 13th, and on the day of beta5 release! :-P
<Forza>
Hi. Im looking at the haikuports mirror stuff. The file ' listing.txt' has a very old date in the past, but shpuldn't it be updated with the current hkpgs?
<OscarL>
no idea how any of that works, Forza. You could poke kallisti5[m] about it.
<Forza>
Hm looks like it doesnt't have new packages in it, so maybe it isnt used nowadays?
<Forza>
Friday the 13th are the best to release on. :)
<kallisti5[m]>
We're about to switch to s3 haikuports at some point, so a lot is going to change once r1beta5 calms down
<waddlesplash>
yeah, we need haikuports mirrors, but we are missing things for that
<waddlesplash>
need signature verification... it's on the TODO list
<waddlesplash>
OscarL: actually I intend to write a separate monthly report today or Monday :P
<PulkoMandy>
Forza, the previous release was on 24th of december, we have a few other interesting dates to try :D
<OscarL>
waddlesplash: noice! :-)
mmu_man has joined #haiku
<OscarL>
in my part of the world, the "unlucky day" is Tuesday 13th, maybe we could try that one next time! :-)
<botifico>
[haikuports/haikuports] Begasus 564b7d0 - libgit2, revbump for rebuild (#11120)
<kallisti5[m]>
I can play 4 , 4k videos at the same time smoothly on my desktop
<kallisti5[m]>
Without any acceleration 😁✨
<kallisti5[m]>
waddlesplash: your performance improvement commits were absolutely amazing ✨️
<waddlesplash>
lol that change is probably just multithreading FFmpeg
<waddlesplash>
that's mostly userspace CPU not I/O or page faults
<waddlesplash>
but, :)
Atomozero has quit [Ping timeout: 480 seconds]
dby has joined #haiku
Coldfirex has joined #haiku
axeld has joined #haiku
<Begasus>
nice to be mentioned in the release notes :) KDE's full-featured applications run natively on Linux, BSD, Windows, Haiku, and macOS. https://kde.org/announcements/gear/24.08.1/
<Begasus>
and me hopping behind again :P
<Begasus>
ghostwriter and kdevelop end of story there (until qt6webengine is around)
gouchi has joined #haiku
Chai-T-Rex has quit [Ping timeout: 480 seconds]
ChaiTRex has joined #haiku
<Coldfirex>
Well done!
humdinger has joined #haiku
Nasina has quit [Ping timeout: 480 seconds]
nephele_xmpp has joined #haiku
itaipu has quit [Ping timeout: 480 seconds]
nephele_xmpp has left #haiku [Disconnected: Hibernating too long]
itaipu has joined #haiku
nephele_xmpp has joined #haiku
<Forza>
Btw, what's up with the IPFS mirror? It hasn't worked for a long time for me.
<waddlesplash>
it's dead I think
<Forza>
Begasus: that's impressive (the KDE support)
<Forza>
waddlesplash: you mean cloudflare ipfs gateway!
<Forza>
Oups.. should be a question mark..
<Forza>
I found that IPFS just is too resource demanding for what it does.
<Begasus>
Konqueror still being developed it seems :)
<Begasus>
Forza, the ones doing the prior work on it are to be credited :)
<Forza>
Indeed
<Begasus>
still no login possible with latest tokodon :/
humdinger has quit [Quit: Vision[]: Oi with the poodles already!!]
nephele_xmpp has left #haiku [Error from remote client]
ChaiTRex has quit [Ping timeout: 480 seconds]
nephele_xmpp has joined #haiku
<nephele_xmpp>
Hello
<waddlesplash>
hello nephele_xmpp
<waddlesplash>
you're just in time for the release?
<dovsienko>
here is what I figured out so far: Mac mini 2006 does not boot Haiku (neither BIOS-preinstalled nor EFI-preinstalled disk, nor anyboot USB)
<kallisti5[m]>
I pinned it globally
<waddlesplash>
dovsienko: try with rEFInd
<waddlesplash>
for some reason it works better to launch the Haiku loader from rEFind than from the Apple BIOS
<dovsienko>
thank you for the suggestion, maybe that will be one of the next things I try
<dovsienko>
so I replaced the thermal paste on the old PC and removed the remote management card, which made the box use its onboard video card, which turned out to be a rather well supported Radeon
<dovsienko>
so the pixels are sharp on the VGA output, but there's still some delay on VNC, which is acceptable
<dovsienko>
so, I was going to start stress_ng on it to see if the problem is with the CPU/chipset still overheating, when I noticed a very odd thing
<dovsienko>
after I have reinstalled Haiku two times over (with two filesystem initialisations and one SATA TRIM in between), the SSH host public key is still the same
<dovsienko>
debug1: Host 'x.x.x.x' is known and matches the ED25519 host key.
<waddlesplash>
ouch
<waddlesplash>
oh, wait. are you installing from writable media?
<waddlesplash>
this may copy the host keys... it probably shouldn't but it might
weda[m] has joined #haiku
<dovsienko>
yes, the anyboot image written to USB storage
m199 has joined #haiku
<waddlesplash>
by default Installer basically copies your whole system including any files you have modified
HaikuUser has joined #haiku
<waddlesplash>
it probably should skip the host keys, I guess
<dovsienko>
I did run that USB storage in the "try, do not install" mode a couple times
HaikuUser has quit []
<dovsienko>
let me plug it into the running system and see
<dovsienko>
/system/settings/ssh and its contents is identical in the on-disk Haiku and on-USB Haiku
<dovsienko>
that explains it, but indeed these files are supposed to be unique
nephele_xmpp has left #haiku [Error from remote client]
<dovsienko>
waddlesplash: the TMPFS bug fixes (trailing memory page in mmap() and O_DIRECTORY in open()) likely qualify for the POSIX compliance section of the release notes
<waddlesplash>
dovsienko: yes, but there were way more than just those fixes
<waddlesplash>
rather than include every last fix, I left it with just some highlights
<dovsienko>
alright
nephele_xmpp has left #haiku [Error from remote client]
<waddlesplash>
they're in the ticket log if anyone clicks that
<waddlesplash>
which is linked from the release notes page
<JulesEnriquez[m]>
waddlesplash: Ok, the post just appeared on the account here.
nephele_xmpp has joined #haiku
<JulesEnriquez[m]>
Meanwhile, I'll post to cohost while it's still around. There's a surprising number of people there interested in Haiku.
<dovsienko>
waddlesplash: 18903 does not appear in the list because it has no milestone
<waddlesplash>
dovsienko: fixed
<dovsienko>
thanks
Nasina has joined #haiku
Nasina has quit []
Nasina has joined #haiku
ChaiTRex has joined #haiku
nephele_xmpp has left #haiku [Error from remote client]
Anarchos has joined #haiku
<PulkoMandy>
Anyone sharing the release image on beshare? (I'm not home this weekend to do it myself)
mmu_man has quit [Ping timeout: 480 seconds]
Anarchos has quit [Quit: Vision[]: i've been blurred!]
tqh has joined #haiku
<Begasus>
closing down here, maybe I'll pop in again later
<Begasus>
cu peeps
Begasus has quit [Quit: Vision[]: i've been blurred!]
nephele_xmpp has joined #haiku
<Forza>
Not seeing too much bandwidth going yet. But definitely there is an increase
<erysdren>
it'll take some time to ramp up
<erysdren>
i've been doing my part posting it in places
<nephele_xmpp>
kinda regret not bringing a laptop :)
<nephele_xmpp>
phone irc is not that great, even over xmpp
<B2IA>
(Forza) Hi!
<bjorn3[m]>
would it be possible to add support for the vmware absolute mouse coordinate protocol? qemu implements this too and avoids having to use an emulated usb tablet for getting the mouse working without capturing it.
<waddlesplash>
what's wrong with emulated USB tablet?
Anarchos has joined #haiku
Anarchos has quit []
<waddlesplash>
if it really uses the VMware protocol then you can try installing the vmware_addons package
<waddlesplash>
it works in VMware for me at least, I've never tried to use it in QEMU
<bjorn3[m]>
there is nothing really wrong with it other than that it isn't enabled by default.
<waddlesplash>
well, there's a "Virtualizing in QEMU" guide somewhere which suggests turning it on, I think
Nasina has quit [Read error: Connection reset by peer]
<Forza>
It would be fun to try haiku on my intel compute stick
<nephele_xmpp>
bjorn3: the defaults of qemu are not that nice generally, and usually involve setting up multiple things
<waddlesplash>
ah, we have one, it's just called "KVM"
<bjorn3[m]>
i played around with haiku a bit like a year ago or so.
<Forza>
Haiku works good with virt-manager/kvm/libvirt
<waddlesplash>
but it doesn't mention it either, huh
<waddlesplash>
the VirtualBox guide does though
<waddlesplash>
Forza: yeah, QEMU/KVM is definitely the best virtualizer for Haiku at the moment
<Forza>
I use tablet input device "EvTouch USB Graphics Tablet" with haiku
<waddlesplash>
VMware second best, everything else further down
<Forza>
And a ps/2 input device emulation
<waddlesplash>
VirtualBox performance is still abysmal due to that interrupts issue that we've never managed to solve
<waddlesplash>
at least with SMP anyway
<Forza>
:(
<Forza>
Can't virtualbox emulate kvm?
<waddlesplash>
no idea
<waddlesplash>
I haven't had VirtualBox installed for a long time
<waddlesplash>
and I don't have any remaining bare metal Linux installs either
mmu_man has joined #haiku
<bjorn3[m]>
whether usage of usb-tablet is documented or not, adding native support for the vmware mouse protocol would make things work out of the box.
<Forza>
:/ virtualbox was usually bettet than vmware for windows stuff
<Forza>
bjorn3[m]: why not a virtio input device?
<nephele_xmpp>
forza: what do you mean by emulate kvm? kvm is a linux subsystem, not something the client OS interacts with
Anarchos has joined #haiku
<waddlesplash>
nephele_xmpp: VirtualBox does support other hypervisors than its own, I'm pretty sure
<waddlesplash>
bjorn3[m]: the vmware_addons package does implement it but it's not installed by default
<Anarchos>
how to know which hrev is my kernel ?
<nephele_xmpp>
Maybe? but that isn't emulating it :) hence the question
<bjorn3[m]>
Forza: just like usb-tablet it isn't enabled by default on the host side
<Forza>
nephele_xmpp: yes and no. There are kvm interfaces for interrupt, mmu stuff, clock, etc
<nephele_xmpp>
Anarchos: open aboutSystem
<nephele_xmpp>
or use uname
<waddlesplash>
or uname -a
<waddlesplash>
yeah
<Anarchos>
version : walter
<nephele_xmpp>
the hrev version of the OS is your kernel version, there is no distinction
<waddlesplash>
you can also use: $ catattr SYS:PACKGE /system/kernel*
<botifico>
[haiku/website] kallisti5 9f6831f - get-haiku/r1beta5: Display now-synced Australia mirror
mmu_man has quit [Ping timeout: 480 seconds]
<OscarL>
VirtualBox performance with 4 cores is not *abismal* for me, just a tad slower than VMWare (on Win10).
<OscarL>
But yea... Qemu > VMware > VBox in terms of speed. I still use VBox mostly because it is the only one of the 3 that lets me access my Haiku installs on the same HDD/SSD as the host OS, and because VMware eats more memore than VBox for me in Win10.
<OscarL>
erysdren: only Easy2Boot claimed support for booting Haiku (But easy2boot is way too messy for my taste). Ventoy was a no go last time I've tried. It would be awesome to be able to just drop the .iso in a pendrive instead of having too "dd" it.
tqh has quit [Remote host closed the connection]
tqh has joined #haiku
<erysdren>
isee
Nasina has joined #haiku
nephele_xmpp has left #haiku [Error from remote client]
tqh has quit [Quit: Leaving]
nephele_xmpp has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
<bjorn3[m]>
i found a glitch: if in tracker you choose get info for a file and then in the attributes tab resize the value column such that the type column goes out of bounds and then slowly shrink it again, the contents of the type column gets rendered incorrectly. kind of like sub-pixel anti-aliasing gone very wrong to the point that it becomes hard to read.
<bjorn3[m]>
looks like doing the resizing and slowly shrinking in any table in tracker has the same problem.
<waddlesplash>
if you do a "full invalidate" does it render correctly?
<waddlesplash>
e.g. drag another window overtop
<waddlesplash>
note that the Info window columns are rendered with an entirely different codepath than the main window
nephele_xmpp has left #haiku [Error from remote client]
<bjorn3[m]>
yes, hiding the window behind another window and showing it again fixes the issue.
<waddlesplash>
so, just an invalidate bug then
<bjorn3[m]>
it happens both with the info window and the main list view of tracker
nephele_xmpp has joined #haiku
<waddlesplash>
could be the same bug but odds are that it's two different bugs
<waddlesplash>
I'm not seeing any existing tickets for this, so if you could create one, that would be nice :)
erysdren has quit [Quit: Konversation terminated!]
<bjorn3[m]>
(your set of patches to rustc is refreshingly sane compared to what some linux distros do)
ChaiTRex has quit [Ping timeout: 480 seconds]
DKnoto has joined #haiku
ChaiTRex has joined #haiku
<waddlesplash>
bjorn3[m]: ah, you are a "rustacean" then?
<waddlesplash>
our rust port is mostly upstreamed, thanks to the great work of nielx
nephele_xmpp has left #haiku [Error from remote client]
<x512[m]>
waddlesplash: rust_bin package still use old openssl 1.
<waddlesplash>
I'm sure nielx will fix that whenever he bumps the version next
<bjorn3[m]>
waddlesplash: yes, i'm part of the compiler team contributors team
<waddlesplash>
(or perhaps someone else will get to it first)
<waddlesplash>
bjorn3[m]: HaikuPorts prefers to keep as small of patchsets as possible and upstream what we can. Some projects aren't amenable to Haiku patches so we wind up with huge ones, but Rust has taken ours so indeed you just get small fixes here and there, pretty much
<bjorn3[m]>
that's a great mentality to have. i've seen distros change things without consulting upstream rustc at all and break stuff in the process. we generally only find out about it when users of said distro go complain to us about things being broken.
<x512[m]>
waddlesplash: Rust also have rustup tool to automatically install binaries bypassing packaging system. It will be nice to have it supported.
<waddlesplash>
that will only work if upstream starts providing Haiku binaries
<waddlesplash>
which would be neat, but we aren't there yet :P
<x512[m]>
Maybe it can be built using upstream Rust infrastructure.
<bjorn3[m]>
x512: that will require moving the haiku target to tier 2 with host tools
<x512[m]>
And not need running Haiku instance.
<bjorn3[m]>
Getting tier 2 support requires being able to bootstrap from linux, macos or windows as those are the only host OSes our CI supports.
<x512[m]>
What is a problem with that?
<waddlesplash>
well there's full support for -target Haiku in clang and llvm now
<waddlesplash>
so it should be possible
<x512[m]>
Just provide Haiku sysroot, no?
<bjorn3[m]>
s/bootstrap/cross-compile
<bjorn3[m]>
yeah, if providing a haiku sysroot is enough, that should be just fine
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<bjorn3[m]>
One thing that would be required for tier 2 support and nice to have either way is a page at https://github.com/rust-lang/rust/tree/master/src/doc/rustc/src/platform-support describing the target, it's current tier, who are the target maintainers and how to build for it. It doesn't seem like one exists for haiku yet.
jmairboeck has quit [Quit: Konversation terminated!]
nephele_xmpp has joined #haiku
<bjorn3[m]>
Other than that assuming rust builds fine for haiku, you don't have a significant amount of the standard library stubbed out and at least some basic programs compiled using it work fine, I think all that would block promoting Haiku to tier 2 would be requesting approval from the compiler team and making a PR to actually promote it.
<nephele_xmpp>
bjorn3: it does need some C headers on Haiku, to link against syscall stubs. Because those are not stable between haiku versions
<waddlesplash>
nephele_xmpp: no, the Rust port has most defines inside Rust
<waddlesplash>
and it calls the C functions not the syscall stubs (because nothing should call the syscall stubs outside Haiku, ideally)
<waddlesplash>
bjorn3[m]: also, as regards the earlier conversation... well, we do change ports without consulting upstream first rather frequently, because communication takes a lot of work and we are often understaffed, so it's easier to just make changes and not try to coordinate across projects a lot of the time. But we also tell users to report bugs to us, not just because of that but because we know Haiku is so "sui generis" in most ways
<waddlesplash>
so it should work out one way or the other in the end
<bjorn3[m]>
is the libc abi stable on haiku?
<waddlesplash>
yes
<waddlesplash>
last time we broke libc ABI was time64, and that was many years ago
<waddlesplash>
we've added stuff since then but it's all been new functions
<bjorn3[m]>
great! that simplifies a lot of things wrt providing precompiled versions of rustc and the standard library.
<waddlesplash>
and honestly we didn't need to break ABI with time64 but doing symbol versions would've been very annoying
<waddlesplash>
and we weren't as big then as now, so we could get away with "just rebuild the world"
<waddlesplash>
(32-bit x86 still is on 32-bit time_t for BeOS ABI)
<nephele_xmpp>
waddlesplash: ah okay. Aslong as it goes through the C functions that is fine then.
<bjorn3[m]>
re porting: Makes sense. For rust we've had stuff like a distro which used the wrong llvm data-layout in the target spec and when rustc complained removed the check that complained rather than fixing the target spec and as a result getting crashes due to using the wrong data-layout.
<waddlesplash>
how does one even make that mistake in the first place, I wonder?
<waddlesplash>
doesn't make sense to me how you would intentionally change the layout anyway
HaikuUser has joined #haiku
HaikuUser has quit []
<bjorn3[m]>
i don't recall the exact issue anymore, but one thing i can think of is: the data layout changed when an abi incompatibility for 128bit ints between gcc and clang got fixed. maybe they used the data layout before that fix and removed the compat check when llvm changed the data layout to fix this abi incompat?
<bjorn3[m]>
in any case rustc requires you to specify the data layout for each target as it internally uses it too for calculating type layouts, but needs to do so in a way that works with non-llvm codegen backend too.
<bjorn3[m]>
the compat check is there to ensure the target spec and llvm don't go out of sync.
<waddlesplash>
ah
<waddlesplash>
so perhaps they used the old one to retain compatible
<waddlesplash>
compatibility
<waddlesplash>
but then didn't patch llvm accordingly or let them get out of sync
<waddlesplash>
that sounds more understandable
HaikuUser has joined #haiku
<bjorn3[m]>
another distro patch that broke things: one distro has a policy that libexec must not exist. rust-analyzer depends on rust-analyzer-proc-macro-server which upstream installs in libexec. this distro patched it to put it in lib instead, which then causes the version of rust-analyzer shipped with the vscode extension to not find rust-analyzer-proc-macro-server. if they asked, maybe we would have unconditionally moved it to lib.
HaikuUser has quit []
<gordonjcp>
bjorn3[m]: you sound like you know your way round vscode
<bjorn3[m]>
i'm mostly a vscode user
<gordonjcp>
bjorn3[m]: same, I love how I can just tell it to work remotely
<gordonjcp>
I've confused it now though because it has to cope with C code where ints are 32-bit and C code where ints are 16-bit, in the same codebase
_Dario_ has quit [Ping timeout: 480 seconds]
<zdykstra>
bjorn3[m]: which distro doesn't believe in libexec ?
<bjorn3[m]>
Arch
<nephele_xmpp>
what does libexec do?
<zdykstra>
it's always arch or nix doing something stupid
<bjorn3[m]>
nephele_xmpp: libexec is a directory in /usr. it is for executables that the user is not directly supposed to be executing.
<zdykstra>
libexec is meant to hold binaries that are exclusively called by other programs - never directly executed by users / scripts
<bjorn3[m]>
is it just me or is the option to enter the bootloader options broken for the beta 5 live cd?
<gordonjcp>
I liked Arch but I got pissed off with having to constantly compile my own kernel to get round their fatally broken kernel packages
<nephele_xmpp>
bjorn3: how are you trying to entrr it? on bios hold shift, and on efi mash space
<zdykstra>
head over to Void, where we have sane kernel packaging policies
<bjorn3[m]>
mashing spacebar seems to work in uefi mode
<zdykstra>
pretty sure you have to repeatedly hit the space bar in UEFI mode, not hold it
<nephele_xmpp>
I use arch linux a lot. On my steam deck. a.k.a not my problem but valves :)
<zdykstra>
it's quite tricky
<bjorn3[m]>
for bios repeatedly hitting shift also seems to work, but the window is much smaller. i basically have to click the reset button in qemu and immediately start hitting shift.
<zdykstra>
a big thank you / congratulations to everybody involved with Beta 5 - a lot of hard work by a lot of people to get it there!
<nephele_xmpp>
:)
<gordonjcp>
I can't wait to try it :-)
<nephele_xmpp>
bjorn3: you are correct, the userguide documentation is confusing/wrong. Especially now that efi booting is the more dominant way... should change it to advice hitting the spacebar repeatedly and not holding it
<bjorn3[m]>
would it make sense to support the spacebar method for bios booting too and then only document the spacebar method?
<bjorn3[m]>
or equivalently supporting the shift method for uefi too
<nephele_xmpp>
I don't think the shift method can be supported for efi, otherwise this would likely have been done already
<zdykstra>
I'm guessing there were technical reasons that influenced the design choice there
<nephele_xmpp>
but supporting space for bios would likely work
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #haiku
tqh has joined #haiku
HaikuUser has joined #haiku
HaikuUser2 has joined #haiku
HaikuUser2 has quit []
HaikuUser has quit [Remote host closed the connection]
DKnoto has quit [Ping timeout: 480 seconds]
axeld has quit [Ping timeout: 480 seconds]
OscarL has quit [Read error: Connection reset by peer]
DKnoto has joined #haiku
<PulkoMandy>
Space bar is supported for both, but you have to repeatedly press it
<PulkoMandy>
In the bios we can additionally detect that shift is pressed, in uefi we can't
<tqh>
we can detect shift in uefi, we just need to use a different protocol
* phschafft
thinks someone should paint little rockets on space bars.
Nasina has quit [Quit: Quit]
<waddlesplash>
tqh: is that protocol actually supported anywhere?
<waddlesplash>
a lot of these "it works in an extension protocol" for something that's also in a base protocol, the extension protocol seems rarely supported
<waddlesplash>
but we should do it anyway, of course
<tqh>
I havn't checked in many years, but I think it was old hw back then that didn't support it.
nephele_xmpp has left #haiku [Disconnected: Hibernating too long]
tqh has quit [Quit: Leaving]
Nasina has joined #haiku
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #haiku
m199 has quit [Remote host closed the connection]
gouchi has quit [Remote host closed the connection]
nephele_xmpp has joined #haiku
Nasina has quit [Read error: Connection reset by peer]
nephele_xmpp has left #haiku [Error from remote client]
nephele_xmpp has joined #haiku
Nasina has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
deneel has quit [Ping timeout: 480 seconds]
Nasina has quit [Read error: Connection reset by peer]
deneel has joined #haiku
Nasina has joined #haiku
nephele_xmpp has left #haiku [Disconnected: Hibernating too long]
deneel has quit [Ping timeout: 480 seconds]
deneel has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
Coldfirex has quit [Remote host closed the connection]
HaikuUser has joined #haiku
HaikuUser has quit []
<dovsienko>
gordonjcp: don't look for a video card, I fixed that problem by removing the remote control card, which enabled a supported variety of onboard Radeon
HaikuUser has joined #haiku
HaikuUser has quit []
HaikuUser has joined #haiku
HaikuUser has left #haiku [#haiku]
DigitalBox98 has joined #haiku
DigitalBox98 has quit []
Nasina has quit [Remote host closed the connection]