Both Python 3.14.0 and 3.13.8 got released yesterday, and we managed to add them to the depot before the day ended (still waiting for 3.9 to get officially EOLāed to retire that version).
IMO, most visible change in Python 3.14 for end users is the improved REPL (now with syntax highlighting, code completion, etc), and better error messages in general (more info: here). Makes using a āpython shellā for experimenting/prototyping much nicer, specially for beginners, or folks with poor memory like me .
Also, today weāve updated git to version 2.51.0 (and remembered to include @nepheleās suggestion to allow use of the mouse scroll wheel when the default pager, `less`, is used). This version should bring some performance boost to push and fetch operations. More info here.
Just checked āgit branchā this opens vim(?) now?
EDIT: seems to be ā/bin/less -FXā ? Not really usefull imho.
/Opslag/haikuports_games> git branch
/Opslag/haikuports_games> git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
/Opslag/haikuports_games>
Where are my branches? (closing /bin/less -FX) disables the list
For a quick workaround, till we maybe revert this if other people also do not like itā¦
Comment out (or remove) the line pager = less -+FX in the file :/system/settings/gitconfig.
I had tried it mostly for git diff and git show, and it worked fine, but now that you mention git branchā¦ yeah, a bit annoying there.
I think the issue is that it is calling the pager even when not really needed (as inā¦ when the output would have just fitted on the screen without need for āpagingā it).
Will see if I can find a setting for that. Maybe @nephele has more suggestions on this?
Edit: for reference, one can disable the use of pager for each command in git, for example:
The problem here is if you set this config option git seemingly always uses a pager, even when none is neededā¦. sooo hmm.
less is not in posix, maybe throw it out of the default install and replace it with a more competent pager? (why is this not functionality of the terminal itself?)
Wellā¦ weāll be reverting this core.pager change. Makes git more annoying to use in general. If users want that setting, they can tune it themselves.
This will mean an almost āmeaninglessā git update for those who already update to 2.5.1, though. Sorry for the ānoiseā. Oh wellā¦ live and learn.
BTW, on the topic of pagersā¦ IMO: nost > more > less.
(added benefit of using most as $PAGER, colored man pages! Edit: by having alias man='PAGER=most man' on my bash profile, seems Iām not even using most for anything else )
gitalso respects that (and GIT_PAGER, if you want to set something just for git). So Iād say if someone has less -+FX as their pager of choice, they should export PAGER with that in their profile, and it will work for them with git, man, and other well-behaved commands. One can even put lpe there, though I donāt recommend it.
It seems (i havenāt tried) you can get what you tried to do by setting DEFAULT_PAGERfor the compilation: Makefile.
Just a quickie noteā¦ ELinks (a text-based browser with support for many protocols (http(s), (s)ftp, gopher, gemini, bittorrent, nntp,ā¦) version 0.18.0 is avaialbe on the repos.
Iāve tried enabling JavaScript support for it (via using the mujs ābackendā), but decided to keep that disabled for now, as it needs several dependencies more, and the few websites Iāve tried to test JS capabilities, still complained about using a browser without javascript support
Apparently even SMB/Samba support can be enabled. I kept that off for now, to keep depedencies in check. I need to try that at some point, though!
In any case, for those TUI loversā¦ not bad to have another option in the browser space. Specially one with gemini and gopher protocols supportā¦ both seemed to work well enough on my testing (shout-out to @erysdren for having a gppher server worth visiting!
Bonus track: already have Python 3.15.0 alpha 1 working, LOL! (It was released today. it pays off to closely following each release, at least for people like meā¦ update took only some minor incremental changes). As with Python 3.14, though, I only plan to open a PR for it once it reaches beta state (sometime in 2026).
Nothing fancy maybe, but library glib2 got updated today to 2.81.0, with it it contains gobject-introspection 1.81.2, starting 2.80.0 glib was forced to use a revbump to include the gir objects required for glib but not supplied with gobject-introspection anymore.
This is now fixed with a bootstrap build obsoleting the gobject-introspection (the gi commands and python module are now included in the glib-gir-tools package).
Took about a month to get together all the bits, thanks for helping out here @madmax and @BiPolar !
EDIT: also thanks to @korli for fixing the issue for glib2 in Haiku nightly, once beta6 is out, the patch inside glib2 for this can be dropped!
EDIT2: maybe also mention ECM (extra-cmake-modules) has been updated to 6.19.0, with it it fixes the need to declare: ECM_DIR, QTPLUGINDIR, QMLDIR and QCHDIR. Starting 6.20.0 the frameworks will require Qt >= 6.8.
In the process of pushing recipes for current KDE frameworks 6.19.0, since 6.20.0 requires Qt >= 6.8, this will be the last one in the depot (should still go a long way).
EDIT: looks like upstream still sneaked a few Qt 6.8 functions in there, hence the upgrade wonāt be full, and I probably need to revert the update to 6.18.0 which is still compatible with Qt-6.7.2.
you forgot to mention the most important milestone: the dreaded Global Interpreter Lock (GIL) is finally gone and the speedups in several use cases are considerableā¦
This aligns nicely with Haikuās native multi-threading nature and should make it a great platform for Python development!
I did not mentioned it because we do not ship the āGIL-freeā versions, just the traditional ones. (Even if the free-threaded version could be experimentally be enabled in 3.13 already).
Main issue isā¦ both versions are not compatible with each other, AFAIK. As inā¦ binary extension modules and āwheelsā need to be compiled for one or the other.
We might decide to provide free-threaded packages for some versions eventually, but I would not hold my breath on that.
Whatās more likely, is that we add an option in the recipes, so users that really need those versions, should be able to compile them by themselves without much effort.
(still waiting for 3.9 to get officially EOLāed to retire that version).
.
