<MichaelKnight>
I've just spun up a new instance of the 64-bit version of Haiku in a VirtualBox machine. My problem is, I can't change the screen resolution!
<OscarL>
Quick tips on how to get decent graphics on VBox.
<OscarL>
Also... if you cannot change resolutions our of the box, that means you were not using the VESA driver. Only reason for that... you had EFI boot mode enabled on the VM. No realy reason for that, unless you're trying to test some EFI bugfix, or something.
<OscarL>
(should not matter once you swithc to VMSVGA, and install the vmware_addons, though)
OFTC has joined #haiku
OFTC has left #haiku [#haiku]
MichaelKnight has quit [Ping timeout: 480 seconds]
<waddlesplash>
adrian_: I don't know FreeBSD install process so idk
<waddlesplash>
I know my way around fixing a Haiku install so I'd pick that first myself
<waddlesplash>
adrian_: Haiku can deal with GPT even on MBR boot systems I believe
<waddlesplash>
wait, T440s, is that EFI?
<waddlesplash>
in that case I recommend spinning up an EFI partition with rEFInd installed
<waddlesplash>
it's a great boot menu and general EFI utility
<waddlesplash>
and then you just shove the .EFI loaders in there
deneel has quit [Quit: deneel]
deneel has joined #haiku
<OscarL>
+1 for rEFInd on EFI only systems. On some BIOS, you can even use it on MBR partitioned HDD :-D (allowed me to have a BootManager/rEFInd Frankenstein multiboot system than can do BIOS and EFI.)
<adrian_>
ok
<adrian_>
so efi and two or more EFI partitions, and give half of em to haiku
<adrian_>
it's fine, if I have to reinstall it a couple times, why not
<augiedoggie>
you only need one efi partition, and you can copy whichever bootloaders you want to it
<Halian>
o/
<Halian>
+2 rEFInd
<waddlesplash>
adrian_: & yeah, one EFI partition
<waddlesplash>
*^
<waddlesplash>
just install rEFInd in the partition and then copy the .EFI loaders to it
<waddlesplash>
you don't even need to edit the config files, refind will find the loaders in the ESP
<coolcoder613>
Anyone here know how to install maturin on Haiku?
<coolcoder613>
OscarL: Have you ever got it working?
<OscarL>
if you're asking about maturin, coolcoder613, I'm afraid I haven't even heard of it, sorry.
<Skipp_OSX>
ah yeah if dual booting I suppose you'll need something more complicated
<OscarL>
coolcoder613: if it is this one (https://github.com/PyO3/maturin)... doubt I'll ever will (I may use stuff writen in rust if .hpkg are available, but won't be compiling them myself :-D)
<coolcoder613>
I think so, yeah
mmu_man has quit [Ping timeout: 480 seconds]
<OscarL>
Seems I have missed those message from Begasus back then about maturin. Would have replied the same tough... "Wish you good luck with it!" :-P
<Begasus>
nice coolcoder613_hk, saw the log earlier :)
<Begasus>
not sure why I was temped to try it out earlier :)
MisthaLu has joined #haiku
<coolcoder613>
I did because it is a dep of openai and ollama python packages
<Begasus>
did you try installing it with pip?
<coolcoder613>
And I want to write a tutorial on writing a ChatGPT/ollama client with Haiku-PyAPI
<coolcoder613>
Begasus: yes
<Begasus>
eeps an chatgpt client?
<coolcoder613>
Well, I'll be connecting it to ollama, but i'll probably be using the openai python library so even those without hardware to run ollama can use it
<Begasus>
SUMMARY="Kirigami client for Ollama" :)
<Begasus>
alpaka, got a recipe for that here, I knew it sounded familiar :D
AlienSoldier has quit [Quit: Vision[]: i've been blurred!]
deneel has quit [Quit: deneel]
deneel has joined #haiku
<Begasus>
bbl
Begasus has quit [Quit: Vision[]: i've been blurred!]
coolcoder613_hk has quit [Remote host closed the connection]
deneel has quit []
<andreasdr[m]>
Hi there.
HaikuUser has joined #haiku
HaikuUser2 has joined #haiku
HaikuUser2 has quit []
HaikuUser has quit []
humdinger has quit [Quit: Vision[]: Oi with the poodles already!!]
draKon has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
HaikuUser has joined #haiku
MisthaLu has quit [Quit: Leaving]
HaikuUser2 has joined #haiku
HaikuUser3 has joined #haiku
HaikuUser3 has quit []
HaikuUser2 has quit []
HaikuUser has quit [Ping timeout: 480 seconds]
<draKon>
haiku uppercut
draKon has quit [Remote host closed the connection]
draKon has joined #haiku
<MonniTheCat>
waddlesplash: I think the issue with create_pipe is that package_daemon switch to older libroot.so (from +122 beta 5) when building a package... I've seen weird things happen with package_daemon since I switched from beta 5 to nightlies... Only real fix for this and similar issues is to reset the added syscall parameter to default value when it's clearly invalid... Just masking out the unused bits can result in random behaviour...
draKon has quit [Quit: Vision[]: i've been blurred!]
draKon has joined #haiku
dalme has joined #haiku
object_reference has joined #haiku
object_reference has quit []
object_reference has joined #haiku
draKon has quit [Ping timeout: 480 seconds]
object_reference has quit [Quit: Konversation terminated!]
<x512[m]>
Mika Lindqvist: Haiku do not maintain kernel ABI stability.
<x512[m]>
Mika Lindqvist: > I think the issue with create_pipe is that package_daemon switch to older libroot.so (from +122 beta 5) when building a package...
<x512[m]>
Where it take old Haiku package from?
<MonniTheCat>
x512[m]: That's the problem... Another problem is package_daemon switching libroot.so when older package is loaded...
<x512[m]>
Not maintaining Kernel UAPI stability is fundamemtal Haiku architecture decision, like in Windows or MacOS. Haiku is not Linux and you can't run older Haiku system libraries in chroot.
<MonniTheCat>
x512[m]: I had a long talk with korli about some packages needing rebuild as they depend on older system libraries... He said there is no issue, but I again proved that he has no clue what he is talking about...
<x512[m]>
libroot.so + kernel is a pair that require exact version match. The same with libbe.so + app_server.
<x512[m]>
Haiku system libraries API is stable and is should be not needed to rebuild software for newer Haiku versions.
<MonniTheCat>
x512[m]: I know that, but pinning version of haiku.pkg is not supported in package_daemon... It doesn't follow the expected version numbering...
<x512[m]>
How package_daemon even managed to find another version of haiku.hpkg ?
<MonniTheCat>
x512[m]: Because haiku-devel has it as requirement...
<x512[m]>
Are you sure that you are in a middle of system update and forget to reboot?
<x512[m]>
* you are not in a
<MonniTheCat>
x512[m]: waddlesplash made me clean whole Haiku source tree and rebuild, but same issue happened with the clean image...
<x512[m]>
That is reproduce sequence? Is it already reported in bug tracker?
<waddlesplash>
MonniTheCat: package daemon does not choose the packages for building in HaikuPorter chroot.
<waddlesplash>
HaikuPorter manually selects the packages itself and does its own dependency solving
<waddlesplash>
and then mounts them in the chroot
<MonniTheCat>
waddlesplash: It definitely does... I get shitload of errors in syslog...
<waddlesplash>
nope
<waddlesplash>
it checks the mounted volume's consistency
<waddlesplash>
but it doesn't select the packages
<waddlesplash>
so korli does know what he is talking about here
<waddlesplash>
in every run of HaikuPorter it lists the actual package set active in the chroot before running any commands
<waddlesplash>
so, check what Haiku package is active in that set and what its path is
<MonniTheCat>
And that is from a clean nightly build...
<x512[m]>
Mika Lindqvist: `find /boot/system/packages -name "haiku-*.hpkg" -type f`
<MonniTheCat>
Same happens on hrev57937_125-1, which isn't a nightly...
<MonniTheCat>
x512[m]: Already did that too...
<x512[m]>
Where 2 haiku.hpkg files with divverent versions come from?
<x512[m]>
Where is second one?
<MonniTheCat>
That command lists 25 files... One for each version released since I installed HaikuPorter...
<MonniTheCat>
Tried delecting every except latest one and Haiku stops booting...
<MonniTheCat>
s/delecting/deleting/
<x512[m]>
Are you booting by choosing older Haiku version in boot loader menu?
<waddlesplash>
MonniTheCat: that's not a clean nightly then.
<MonniTheCat>
Had no issues before hrev58421, so I proved my point...
<waddlesplash>
how did those packages wind up there?
<waddlesplash>
yes, because the ABI hadn't been fully broken yet
<waddlesplash>
now it's broken vs. beta5 so you can't use beta5 libroot anymore
<waddlesplash>
having multiple haiku base packages is an invalid state anyway and you cannot get into it without manually modifying the packages directory
<MonniTheCat>
waddlesplash: That means bash needs to be rebuilt... But there is no new package and building on nightly itself won't result in working binary...
<waddlesplash>
so there's no Haiku bug here that I can see
<waddlesplash>
MonniTheCat: No. bash works fine. it's libroot and kernel ABI that was broken.
<x512[m]>
MonniTheCat: Bash do not use kernel syscalls directly, so it is fine.
<waddlesplash>
You need to just not mix beta5 and nightly components and this will all work out
<MonniTheCat>
waddlesplash: All other applications work, it's just bash that try to use incompatible libroot.so
<waddlesplash>
no, the problem is the chroot
<waddlesplash>
it gets the older haiku package
<waddlesplash>
the base system uses the newer package because newer files override older files within packages
<MonniTheCat>
waddlesplash: chroot isn't a hpkg package... but what package does have it... that's the next question...
<waddlesplash>
no, it is
<waddlesplash>
chroot is made by mounting packages
<waddlesplash>
independent of the system mount
<MonniTheCat>
The crash was with /bin/package... I'm pretty sure that isn't part of HaikuPorter...
<waddlesplash>
HaikuPorter takes the packages that it has decided to activate in the chroot and runs "mount -t packagefs ..."
<waddlesplash>
MonniTheCat: you already showed us the package path that HaikuPorter selected for use in the chroot and that package is beta5 not nightly
<waddlesplash>
so that is where all the problems come from
<waddlesplash>
the libroot active in the chroot is incompatible with the running kernel
<x512[m]>
find /boot/system/packages -maxdepth 1 -name "haiku-*.hpkg" -type f Should list only one file.
<waddlesplash>
so all applications in the chroot, bash included, malfunction as a result
<MonniTheCat>
waddlesplash: And that version is the only one it ever uses.... since beta 5 was released... and as there is no beta6 repository, it can't use more recent one...
<waddlesplash>
wrong
<waddlesplash>
HaikuPorter just picks packages from the ones available on your system
<MonniTheCat>
waddlesplash: And it fails without those two specific files... As I pointed out days ago...
<waddlesplash>
then clearly something else is broken or gone wrong too
<waddlesplash>
or maybe you just removed them incorrectly
<waddlesplash>
either way my system and every other user's still works fine
<MonniTheCat>
waddlesplash: That's what I've been telling since I started using nightlies...
<waddlesplash>
okay? and?
<waddlesplash>
none of what you have told us so far refutes what we are saying
<x512[m]>
Why it may work, it is better no not manually touch contents of /boot/system/packages directory.
<MonniTheCat>
waddlesplash: I had same issue when bootloader and kernel didn't mismatch... and that had nothing to do with HaikuPorter...
<x512[m]>
s/Why/While/, s///`//, s//`/
<MonniTheCat>
s/didn't/did/
<waddlesplash>
MonniTheCat: yes, and?
<waddlesplash>
you have an invalid package set
<x512[m]>
You can install local hpkg files with pkgman.
<waddlesplash>
different parts of Haiku may handle this in different ways
<MonniTheCat>
waddlesplash: packagefs is the only common denominator...
<waddlesplash>
because it's an invalid state and undefined behavior
HaikuUser has joined #haiku
HaikuUser has quit []
<x512[m]>
pkgman full-sunc may fix things.
<waddlesplash>
MonniTheCat: no. because the bootloader has its own packagefs code. The only common denominator is the invalid state
<x512[m]>
s/sunc/sync/
<MonniTheCat>
waddlesplash: But what causes the invalid state...
<x512[m]>
MonniTheCat: Manual manipulation of /boot/system/packages directory.
<waddlesplash>
yes
<waddlesplash>
that
<MonniTheCat>
x512[m]: That was already ruled out...
<waddlesplash>
how?
<waddlesplash>
there is no other way this can happen
<waddlesplash>
package daemon doesn't allow multiple packages with the same name and differing versions to be active at once
<MonniTheCat>
waddlesplash: package_daemon self-destructed even without manual alteration if I delete the current state...
<waddlesplash>
okay
<waddlesplash>
that's unsurprising
<waddlesplash>
so don't do that
<waddlesplash>
you just want to delete the few package files that are duplicates and leave only one version of each
<waddlesplash>
don't touch the administrative folder
<waddlesplash>
only do that once you've got everything else sorted, and even then the only thing one should do in there is delete old state files
<waddlesplash>
MonniTheCat: and how didn't it boot?
<waddlesplash>
there are many ways it could not boot
<MonniTheCat>
waddlesplash: Didn't find boot volume in boot loader...
arjen_ has joined #haiku
<waddlesplash>
then check the boot loader log
<waddlesplash>
perhaps you deleted one too many packages
<waddlesplash>
please see if "pkgman full-sync" fixes thus
<MonniTheCat>
waddlesplash: I didn't... It booted after I deleted the state file...
<waddlesplash>
this
<waddlesplash>
okay?
<MonniTheCat>
waddlesplash: That does nothing... Doesn't even try to downgrade or reinstall single package...
<waddlesplash>
I find that hard to believe
<waddlesplash>
it must offer to at least upgrade the packages
<waddlesplash>
to the newest versions available
<waddlesplash>
and in doing so will remove the older versions
<waddlesplash>
so see if that works.
<x512[m]>
Do *.hpkg file count match line count in "administrative/activated-packages" file?
<MonniTheCat>
waddlesplash: Just ask Begasus if you don't believe me... He has known me for decades and knows I will dig a hole to China if something doesn't work 100%...
<waddlesplash>
you still haven't answered my question or tried that
<waddlesplash>
or answered x512[m] 's question
<MonniTheCat>
waddlesplash: I won't retry a command that I have already tried when diagnosing this same issue...
<MonniTheCat>
Either things will crash or it renders the volume unbootable...
<waddlesplash>
okay
<waddlesplash>
then do the other things we suggested
<PulkoMandy>
Even if you don't run it to the end, check what packages pkgman offers to update or uninstall
<PulkoMandy>
At least we will have a better idea what's wrong
<MonniTheCat>
PulkoMandy: fish ;)
<waddlesplash>
or at worst, boot from a freshly built image, delete the /system/packages directory, and replace it with the one of the newly built and working image
<waddlesplash>
then you will be in a fully consistent state
<MonniTheCat>
upgrade package fish-3.7.1-1 to 3.7.1-2 from repository HaikuPorts
<waddlesplash>
that's with full-sync?
<x512[m]>
Can you send output of cd /boot/system/packages; ls -1 *.hpkg and contents of /boot/system/packages/administrative/activated-packages?
<waddlesplash>
MonniTheCat: yeah please do as x512[m] is asking
<MonniTheCat>
x512[m]: Nope... Not yet... I need to make a copy of the files first...
<PulkoMandy>
Also check if you have packages installed in /boot/home/config/packages/
<Begasus[m]>
<MonniTheCat> "Just ask Begasus if you don't..." <- I also told you you got a weird setup there :)
<waddlesplash>
MonniTheCat: ? he's asking you to send text output
<MonniTheCat>
Begasus[m]: Yup... And I said that it's not a lie...
<MonniTheCat>
waddlesplash: I can only do one thing at a time... Otherwise the output will not make any sense...
<x512[m]>
This is wrong and should not happen. When you install new package version, old one is automatically moved to administrative/states directory.
<x512[m]>
This usually means that hpkg files was put manually.
<MonniTheCat>
x512[m]: Like I said earlier, package_daemon self-destructs when trying to upgrade haiku-r1*.pkg
<x512[m]>
Can you also send activated-packages file?
<MonniTheCat>
x512[m]: I can, but it takes a while to copy it from Haiku...
<Begasus[m]>
Mika Lindqvist as x512 mentioned, there should only be 1 haiku_devel in /system/packages? How did those end up together?
<MonniTheCat>
Begasus[m]: package_daemon not finishing updating packages correctly
<Begasus[m]>
well, never seen it happen (and glad it didn't here) , but could explain the weird errors
* Begasus[m]
another reason to stick to plain beta :D
<MonniTheCat>
Begasus[m]: Almost all packages depend on haiku-devel... and usually only haiku-devel depend on haiku-r1...
<Begasus[m]>
haiku_devel shouldn't be required on runtime, maybe the Haiku base, don't know there, but not for packages (already) installed from depot or local packages
<Begasus[m]>
on build time it is though
<MonniTheCat>
Begasus[m]: It was crashing when I was trying to build irssi... Just because it doesn't take hours to build...
<Begasus[m]>
could check a build there, but I doubt I'll see those errors
<MonniTheCat>
I built about 120 packages without crash... only few ones did crash... and always on same place...
<Begasus[m]>
building the frameworks alone results in over 130 packages (not including if debug packages are build)
<MonniTheCat>
Begasus[m]: I deleted all built packages and still could reproduce the crash just by trying to build single package...
<MonniTheCat>
I can safely delete all the other versions except haiku_devel-r1~beta5_hrev57937_122-1-x86_64.hpkg
<Begasus[m]>
does it have the same hrev as the haiku base package?
<MonniTheCat>
Begasus[m]: Nope...
<Begasus[m]>
no expert on the matter, but I "think" they should match?
<MonniTheCat>
Begasus[m]: Should... But base package is at least 3 commits ahead...
<Begasus[m]>
well if it would be synced both should be +129 (iirc)
<MonniTheCat>
Begasus[m]: last time I started with +125 and went up to hrev58440...
<Begasus[m]>
that's from beta to nightly
<MonniTheCat>
Begasus: Yup... Had to go to nightly to test the usb_disk fix...
<Begasus[m]>
OK, that direction should work in most cases, but I've seen it happen that reverting to beta from nightly tends to brake things
<Begasus[m]>
morso if you got packages build against nightly and try to revert the system to beta
<MonniTheCat>
Begasus[m]: I'm still running nightly... hrev58452
<Begasus[m]>
MonniTheCat: is that for beta or nightly then?
<MonniTheCat>
Begasus[m]: +3 is still beta 5... after that I went to hrev58296, which is nightly...
<Begasus[m]>
well, seeing you still got haiku_devel from beta doesn't look like a good situation to be in
<MonniTheCat>
Begasus[m]: I can't delete that... Without that, HaikuPorter doesn't start...
<Begasus[m]>
"pkgman up haiku_devel" doesn't bring it on par with base?
<MonniTheCat>
Begasus[m]: Nope... Not at least without rebooting first...
<Begasus[m]>
that's normal on that package (reboot)
_-Caleb-_ has left #haiku [#haiku]
<Begasus[m]>
if it was me* I'd try to remove it and replace it with the one in sync with base package, haikuporter should work then
<Begasus[m]>
other then that I wouldn't know what happened there to get it out of sync
san2ban has joined #haiku
_-Caleb-_ has joined #haiku
<san2ban>
Hi all....for contacts, I was using people ...now there is Deeper people on haikuports. Is this an improved version of people or an entirely new software?
<MonniTheCat>
<Begasus[m]> "other then that I wouldn't..." <- Only real cause is when package_daemon can't resolve dependencies because two packages want different version of same dependency...
<x512[m]>
Begasus: I do not use Betas, only Nightlies and have no such problems.
<MonniTheCat>
x512[m]: I was upgrading from one nightly to another when shit did hit the fan...
<Begasus[m]>
x512 you are supposed to use nightlies, otherwise we won't get new beta's :) +1
<x512[m]>
<MonniTheCat> "https://gist.github.com/mtl1979..."; <- You need to delete all hpkg files in /boot/system/packages that are not mentioned in this list.
<MonniTheCat>
x512[m]: Already did that...
<MonniTheCat>
I only have two versions of some package when I build them from sources... and that doesn't happen very often...
<Begasus[m]>
x512 at one point I had over 2.5K packages installed, still didn't encounter those problems Mika Lindqvist is facing
* Begasus[m]
checks current stat on that ...
<Begasus>
1380 items in /system/packages
<MonniTheCat>
I only have 607 after cleaning up ;)
<Begasus>
remove the userguides, another 10sh down :)
<MonniTheCat>
I could reboot and see package_daemon delete all packages... down by 607 ;)
<x512[m]>
MonniTheCat: How you install package built from sources?
<MonniTheCat>
x512[m]: Old school CD-ROM drive with full image built on Linux...
<draKon>
would any developers here like a copy of my site to test out as something being installed within haiku? i want it to be a desktop bg option. if ye want a site to develop around or just a decent set of music playlists heres a link
<draKon>
well pm me for it
<x512[m]>
MonniTheCat: What do you exactly do with that image?
<MonniTheCat>
x512[m]: Mount and copy to /system/packages and wait for package_daemon to crash in KDL ;)
<x512[m]>
MonniTheCat: Wrong. You should use pkgman install *.hpkg or Installer app.
<x512[m]>
Finally found root issue.
<MonniTheCat>
x512[m]: Installer app refuse to install to already existing Haiku partition...
erysdren has quit [Quit: Konversation terminated!]
<draKon>
i want to offer service of making USB bootsticks for Haiku
<draKon>
id make like 50 of them as a donation to the service
<x512[m]>
MonniTheCat: What about `pkgman install *.hpkg`?
<draKon>
just give me preference of USB STICKS
<MonniTheCat>
x512[m]: Never tried that...
<x512[m]>
Installer can be used if you are fine with wiping /boot/system.
<draKon>
not sure how anyone would like it done?? whether ye or me supply USB Drives. id also make DVD / CD copies but no compatible burner yet
<x512[m]>
It is always bad idea to touch /boot/system/packages, including copying something inside it. You should use HaikuDepot or pkgman instead. It will automatically move old packages to /administrative/states directory.
<draKon>
should be able to do CD boot copies soon
<x512[m]>
Manually adding/removing hpkg files to /boot/system/packages = high change of getting broken system.
<Begasus>
+1
<MonniTheCat>
x512[m]: Doesn't work...
<x512[m]>
MonniTheCat: Error messages?
<MonniTheCat>
x512[m]: *** failed to commit transaction: The to be activated package "ca_root_certificates-2024_07_02-1-any.hpkg" does already exist.
<Begasus>
not every package in an image is updated, so your bound to get failures like that
<Begasus>
s/your/you're
<MonniTheCat>
Begasus: That's exactly why I don't use pkgman for updating system packages...
<x512[m]>
pkgman install *hrev*.hpkg
<Begasus>
that or just as waddlesplash told me some time ago, freshly build "pkgman inst haiku haiku_devel" (from the package generated directory iirc)
<MonniTheCat>
x512[m]: That almost works... But the result is I have more packages than before...
<x512[m]>
Almost?
<x512[m]>
It will not automatically remove packages that were not mentioned in activated-packages file.
<x512[m]>
You need to write some script that will delete app hpkg files in /boot/system/packages that are not mentioned activated-packages file to restore system integrity. And never do image extraction to update system again.
<x512[m]>
If pkgman asked to reboot, you need to reboot first.
<MonniTheCat>
x512[m]: Somehow it installed more than simple cp command... or did leave more duplicates than cp command...
<x512[m]>
It may install new required dependencies etc.. It is file as long it is consistent with activated-packages file.
san2ban has quit [Quit: Vision[]: i've been blurred!]
<MonniTheCat>
<x512[m]> "(cd /boot/system/packages ; ls -..." <- Nice script, but that's something package_daemon should do automatically when upgrading or installing packages...
<x512[m]>
It will do if system is in consistent state. System do not touch or use hpkg files that are not mentioned in activated-packages file.
<MonniTheCat>
x512[m]: I only had 553 packages after running the script... That is comparing to 608 packages after using pkgman or 607 packages after using just "cp" command...
<x512[m]>
Never use "just cp command". It will break system.
<MonniTheCat>
x512[m]: worked better than pkgman until now... not gonna even try comparing to SoftwareUpdater
<x512[m]>
MonniTheCat: It is undefined behavior, it may work and may suddenly break. Just don't.
<MonniTheCat>
x512[m]: pkgman breaks 100% of the time, so defined behaviour is better?
<x512[m]>
How pkgman breaks?
<MonniTheCat>
x512[m]: Clearly it leaves some duplicate packages if package count keeps increasing...
<x512[m]>
It do not leave duplicate packages if system is in consistent state.
<x512[m]>
You need to fix system first by running script above.
<MonniTheCat>
x512[m]: Good thing about cp command is that it doesn't depend on state being consistent, which is 100% of the cases when upgrading system packages...
<x512[m]>
System is always consistent if installing/uninstalling/updating packages with pkgman/HaikuDepot.
<x512[m]>
Including system packages.
<x512[m]>
If you are insisting on using "cp" then it is your responsibility and nobody will help you.
<MonniTheCat>
x512[m]: I will use whatever works 100% of the cases... If I find something better than "cp" command, then I will use it...
<x512[m]>
If you are using cp, then please don't ask here when you are experiencing problems with it. It is undefined behavior and it may break system in unexpected ways.
<MonniTheCat>
Even if I would use pkgman, it wouldn't fix the issue that it will use incompatible version of haiku-devel when building packages...
<x512[m]>
It will fix HaikuPorter problem after you run script above.
<MonniTheCat>
x512[m]: Nope... Already did run the script...
<MonniTheCat>
I even tried cleaning up irssi source tree and rebuilding it...
<x512[m]>
Are packages.txt and activated-packages.txt the same after second run?
<MonniTheCat>
x512[m]: That script only runs once and then fails to run...
<x512[m]>
And to-be-deleted.txt should be empty after second run.
<MonniTheCat>
packages.txt and activated-packages.txt are both 17572
<x512[m]>
Did you tried to reboot?
<MonniTheCat>
x512[m]: Yup...
<x512[m]>
Can you paste "Activated packages" part from HaikuPorter log and packages.txt file?
<x512[m]>
* Can you paste "chroot have these packages active" part from HaikuPorter log and packages.txt file?
<MonniTheCat>
The issue is that HaikuPorter stores the current hrev in "repository" directory on first run... So after every hrev, that directory must be deleted...
<MonniTheCat>
obviously I deleted the directory to be able to run HaikuPorter...
<x512[m]>
Looks consistent. Haiku packages are the same in chroot and Haiku itself.
hightower3 has quit [Remote host closed the connection]
hightower3 has joined #haiku
erysdren has joined #haiku
<MonniTheCat>
x512[m]: It works until I update to another hrev... Then I need to cleanup everything again...
<x512[m]>
So problem is solved or something remains unsolved?
<x512[m]>
haikuporter --clean irssi
<x512[m]>
haikuporter irssi
<x512[m]>
This may be enough.
<andreasdr[m]>
Hi there.
<MonniTheCat>
x512[m]: It isn't... because it caches data in "repository" directory...
<x512[m]>
Caches should be fine if system is consistent. At least for me it works after system and HaikuPorts repo update.
<MonniTheCat>
x512[m]: It works for me when HaikuPorts is updated, but not when system repo is updated...
<x512[m]>
It will automatically rebuild caches when needed.
<x512[m]>
MonniTheCat: Update without "cp"?
<MonniTheCat>
x512[m]: If I update using pkgman, it breaks... if I update with "cp" it works...
<MonniTheCat>
obviously rebooting after the update...
<x512[m]>
How it breaks? What errors are displayed?
<Begasus>
repository cache for haikuporter is not influenced on system update
<Begasus>
I would have seen multiple changes there if it would
<MonniTheCat>
x512[m]: It can't find haiku-devel
<Begasus>
it changes when a recipe is added/updated/changed
<Begasus>
only once in a while a "file" in there needs deleting to make it update the cache, but rarely happens
<x512[m]>
MonniTheCat: "cp" may not trigger system packages update at all, keeping using old version of duplicates.
<x512[m]>
It is really undefined behavior.
<Begasus>
hi there andreasdr[m] :)
<MonniTheCat>
x512[m]: Using cp still requires reboot before it starts using the new versions
<andreasdr[m]>
Hi there Begasus.
<Begasus>
how do you know it will replace the old package that way MonniTheCat?
<x512[m]>
Or it may not start using new versions even after reboot because old versions are still there...
<MonniTheCat>
Begasus: Open the About dialog of Haiku itself...
<Begasus>
nope, still doesn't exclude multiple packages
<Begasus>
how would haikuporter know which haiku_devel to use if there are multiple?
<MonniTheCat>
Begasus: It is stored in the "repository" directory...
<Begasus>
packages are not stored there?
<MonniTheCat>
Begasus: Only metadata of the packages... that includes all the dependencies and the version numbers of them...
<Begasus>
I still have ICU75 in haikuporter/packages and ICU74 in system/packages, if I don't provide a version string then ICU75 will be used
<Begasus>
haikuports/packages*
<MonniTheCat>
I think haikuporter/packages and home/config/packages have higher priority than /system/packages
<MonniTheCat>
I suspect deleting just that one file will allow mixing different hrevs...
<Begasus>
never fidled with that one
<MonniTheCat>
I usually just delete whole directory... don't like remembering filenames especially in directory that has shitload of files...
<Begasus>
well, on every new run for haikuporter it will have to be rebuild then, not a joy to do
<MonniTheCat>
Begasus: Exactly my point...
<Begasus>
well, then don't delete?
<MonniTheCat>
It also means that buildmasters will fail to build packages that work locally.... as buildmasters use very old hrev as you already know...
<Begasus>
hence I stay on beta
<MonniTheCat>
Begasus: That's not an option when fixing bugs in bootloader, kernel or drivers...
<Begasus>
it's bad practice to send PR build localy with nightly to the buildmasters, mostly it's fine, but can go wrong
_-Caleb-_ has left #haiku [#haiku]
<Begasus>
understood MonniTheCat, but haikuporter's repository shouldn't have anything to do with that
<MonniTheCat>
Begasus: Not really my choice... Haiku developers will either blame python or HaikuPorter... It's never issue in Haiku itself...
<Begasus>
unless they are packages in use by the system, don't think much would interfere with those you mention
<MonniTheCat>
Begasus: The issue is clearly only with haiku-devel package...
<Begasus>
there should always be one installed and be on par with the base one
<Begasus>
only one*
<Begasus>
those should "afaik" never be installed in user space
<MonniTheCat>
Begasus: In real-life, there is almost always two versions, one activated and one not activated...
<Begasus>
the not activated in states perhaps
<Begasus>
but not in system/packages
<MonniTheCat>
Begasus: Nope...
<MonniTheCat>
As said before, HaikuPorter needs libroot.so and headers from Beta 5, nothing else...
<Begasus>
?
<Begasus>
I've switched to a nightly this week, nothing from beta5 on that (clean install), haikuporter works just fine
<MonniTheCat>
Begasus: I had hrev58296 and all hrevs before that worked just fine... After that there was several hrevs that didn't work with HaikuPorter...
<Begasus>
have to step out in a sec
<Begasus>
I'm just not seeing it here MonniTheCat
<MonniTheCat>
I'm going to go eat something... and then go watch some TV...
<PulkoMandy>
It works just fine for everyone else. Your system was confused by having multiple versions of system packages in the packages directory
<Begasus>
same here, enjoy
<PulkoMandy>
Now that's fixed and you shouldn't have problems anymore
<MonniTheCat>
PulkoMandy: Famous last words... Not first time I have wiped all packages...
<Begasus>
bbl
<PulkoMandy>
Well, works for me without any problems anyways...
HaikuUser has joined #haiku
Yoke is now known as Guest3820
HaikuUser is now known as Yoke
x10z has quit [Quit: My Unrecognized Mac has gone to sleep. ZZZzzz…]
zardshard has left #haiku [Disconnected: Replaced by new connection]
zardshard has joined #haiku
erysdren has quit [Quit: Konversation terminated!]
JakeSays1 has quit [Ping timeout: 480 seconds]
erysdren has joined #haiku
_-Caleb-_ has joined #haiku
MisthaLu has joined #haiku
<Skipp_OSX>
PulkoMandy for live patch, that line is cruft from when I was falling-through on cut=>copy=>paste and can be removed.
<waddlesplash>
Skipp_OSX: PulkoMandy: it seems I still have unaddressed comments on the shortcuts change?
<waddlesplash>
specifically the one about update methods
<waddlesplash>
I don't think we need an Update method for every item
<waddlesplash>
Every single item has a unique "what", right?
<PulkoMandy>
It seems unimportant enough to me that we can merge this and change it later if needed
<waddlesplash>
So we can have just one Update method that takes a BMenu and iterates through it, and updates every BMenuItem based on its "what"
<waddlesplash>
PulkoMandy: well I would also really like more people to test the change besides Skipp_OSX
<waddlesplash>
if Skipp_OSX thinks it's ready then I can test. But also we can ask diver
<waddlesplash>
I'm sure he'll find something that was missed :P
<PulkoMandy>
We test them by getting them into nightlies
<Skipp_OSX>
humdinger has tested this and disks before and it did identify some issues that were fixed
<waddlesplash>
ah good
<Skipp_OSX>
shortcuts and disks at leasat
<waddlesplash>
well that's something
<waddlesplash>
but perhaps we can ask diver anyway
<Skipp_OSX>
I haven't implemented your improvement it's split out into different sections updating only what's needed in each
<PulkoMandy>
some of these changes have more than 60 revisions, I think that's not normal and we should merge things faster :)
KapiX has joined #haiku
<Skipp_OSX>
I was working on splitting the shortcuts patch out into smaller patches but ran into issues getting things working.
KapiX has quit []
<waddlesplash>
I don't think it necessarily needs to be smaller
KapiX has joined #haiku
<waddlesplash>
huge commits in Tracker are a little expected for refactors like this
<waddlesplash>
Skipp_OSX: on mobile so I can't easily add comments on Gerrit. But looking at your BMenu patch: why's that extra message propagation needed?
<waddlesplash>
why doesn't the Super automatically get the same message?
<waddlesplash>
if that's not due to a bug it should probably be explained in the commit message at least
<Skipp_OSX>
it's to propagate the message up the menu chain to the root menu
<Skipp_OSX>
you have to look at the associated bug to get more details sure ok I could update commit message
<PulkoMandy>
Menus are not nested like views, so it seems normal to me
<waddlesplash>
but why is the child menu the one receiving the message I guess is the question
<waddlesplash>
oh... because it's the one that has focus?
<Skipp_OSX>
yes when you push key down
<waddlesplash>
ok makes sense. But do we need BMessenger here?
<Skipp_OSX>
it gets the keyboard input
<waddlesplash>
or can we use PostMessage
<waddlesplash>
and we also don't need to use CurrentMessage because we have the message pointer here already
<Skipp_OSX>
PostMessage only works in same thread each window is in its own thread
<waddlesplash>
no, PostMessage works across threads
<Skipp_OSX>
ok then we could use PostMessage
<waddlesplash>
or at least I'm pretty sure it does
<Skipp_OSX>
BeBook says no
<waddlesplash>
maybe we changed that?
<Skipp_OSX>
It might work idk
<waddlesplash>
I recall having used this at least in the past
<Skipp_OSX>
SendMessage is safer it says
<Skipp_OSX>
(it = the BeBook)
<PulkoMandy>
Yes, it works but you can't be sure if the thing you are posting to still exists (if it's a window and the user closes it at just the "right" time for example)
<waddlesplash>
well we aren't posting to a window
<waddlesplash>
and it shouldn't disappear due to how BMenu locking works
<PulkoMandy>
That's why the be book recommends other ways that can check for this. May not be needed here if we're sure the parent menu can't be closed before the submenu, I guess
<waddlesplash>
yes
<waddlesplash>
let's try it at least
<PulkoMandy>
BMenu is just a window in a trenchcoat
<waddlesplash>
I mean. We already rely on the fSuper not getting deleted during this method call
<waddlesplash>
So just calling PostMessage should be equivalent
<Skipp_OSX>
the two lines could be combined but I don't want to touch that patch it's been +2 for a long time now
<waddlesplash>
okay
<waddlesplash>
I guess that one at least we can break off and merge now
<PulkoMandy>
not every change needs to be perfect before merging
<waddlesplash>
I suppose so
IronJam[m] has joined #haiku
<Skipp_OSX>
With 36 items the performance impact would be negligible and the testing would be easier
<waddlesplash>
?
<waddlesplash>
which are you referring to?
<Skipp_OSX>
as far as one big update method going over all items in the menu whether they may be present or not, 36 Update methods in Shortcuts
<Skipp_OSX>
I am restricting the updates to only those possible for that type of menu which you're on which I suppose is a dubious optimization but still I'm reluctant to change the design.
<waddlesplash>
"premature optimization is the root of evil"
<waddlesplash>
Skipp_OSX: we have to redraw all 36 menu items when the menu is open don't we?
<waddlesplash>
that's FAR more expensive
<waddlesplash>
so doing a for () loop across all the menu items and then a switch (what)
<waddlesplash>
is cheap by comparison
<Skipp_OSX>
max 36 iterations in worst case
<Skipp_OSX>
it's more for subclasses to override just the piece they want leaving the rest default.
Begasus has quit [Quit: Vision[]: i've been blurred!]
<Skipp_OSX>
but that ultimately goes down to the same thing the dubious performance optimization vs always iterating over all items.
_Dario_ has joined #haiku
<scantysnax>
can you mark and cache the "dirty" menu items that need to be drawn and just draw those, or am i missing something?
<Skipp_OSX>
there's no redrawing issue this is all computed prior to the initial draw