<|cos|>
Given that mentioned package has no dependencies, merely prints a greeting and fails to install even with pip, I guess releasing the rm -rf shark in /boot/system/non-packaged is the first step.
Begasus_32 has quit [Quit: Vision[]: i've been blurred!]
Aedil has quit [Remote host closed the connection]
Begasus_32 has joined #haiku
<Begasus_32>
jmairboeck, if you read the logs, testing the PR worked ok :)
<Begasus_32>
k, reboot
Begasus_32 has quit [Quit: Vision[]: i've been blurred!]
<|cos|>
Is there a way to know which value haikuporter sets $binDir to? I would expect either that --verbose showed what it did, that there was a specific flag to output such stuff. I've tried --print-raw which appears to be a NOP, and did read both chapters of the gentle introduction.
<|cos|>
Ah. Adding an echo in the recipe did of course work. Guess that should had been obvious enough, but it seems I'm slower than usual today.
<Begasus[m]>
|cos| $prefix always default to /boot/system on primary architectures
<Begasus[m]>
so $binDir to /boot/system/bin (on 32bit secondary architecture that is /boot/system/bin/x86"
<|cos|>
What I actually attempted was to gain a faster hack-rebuild-check cycle than the full rebuild haikuporter does + uninstalling the hpkg + installing the new locally built one.
<nekobot>
• jmairboeck (ac097970): fix "any" arch ports being considered buildable on secondaryArch (#335)…
<jmairboeck>
Begasus[m]: thanks for the check, I added a TODO comment to the code for the further enhancements and merged it then.
<Begasus[m]>
no problem jmairboeck nothing planned today anyway :)
<jmairboeck>
I checked haikuports for "SECONDARY_ARCHITECTURES_", the only recipe which has that is util_linux, and that isn't "any", so that restriction is no problem for now.
<Begasus[m]>
let's see what this brings, I mostly keep haikuporter on track with master, so I guess we'll bump into something sooner or later when there is an issue :)
<jmairboeck>
kallisti5[m]: can you create a new release of haikuporter for that fix and deploy it for the 32 bit x86 buildmaster and builder?
<jmairboeck>
also, the "repository" directory, specifically the package-to-port mapping files have become slightly wrong for the "any" packages that have been built since the last update. I don't know how much of a problem that is and whether they should be regenerated manually.
<jmairboeck>
at least locally that is the case, and I guess that buildmaster is also affected
<|cos|>
Despite the slow modify-build-run cycle, I managed getting my patch itto a PoC. Any Haiku gvim users around? or people actually knowing the Haiku GUI API:s?
<|cos|>
The LLM scrapers have killed my web gui, but cloning ssh://anonymous@git.netizen.se/vim should give a repo with a haiku-fullscreen branch.
<|cos|>
Review comments welcome! It's far from ready for a PR to vim yet. No documentation updates, nor extensive testing. It does make gvim work in fullscreen though. I suppose there are better places to jack in than in DispatchMessage()? I tried KeyDown() first, but that one didn't get executed.
<Begasus[m]>
merging gtk4 also, if no one objects (been open long enough for comments)
<Begasus[m]>
despite not fully functional, it's in a working state things are usable and testing could be done (maybe others can still fine-tune the recipe also)
<jmairboeck>
Begasus[m]: If you don't want to rename the _docs packages and still want the same outcome, you could add SUMMARY_docs="$SUMMARY (documentation)" to these recipes ;)
<jmairboeck>
I think that type isn't used for anything else
<jmairboeck>
with _doc you get that automatically, if you don't override it (which you still can if you want a different summary)
<Begasus[m]>
for the boost ones it shouln't be too big of a problem
<Begasus[m]>
but will check atleast one or two on 32bit before pushing anything there
<jmairboeck>
although the special handling in haikuporter suggests that "_doc" is the expected suffix
<Begasus[m]>
+1
<Begasus[m]>
I think I mentioned using _doc for that many years ago already :) just never tackled the existing ones so far