<botifico-c849d97b>
[haikuports/haikuports] Begasus b0a3254 - docutils, bump version (#8762)
freddietilley has joined #haiku
Diver has joined #haiku
DKnoto has joined #haiku
ReduxFlakes[m] has left #haiku [#haiku]
HaikuUser has joined #haiku
HaikuUser has quit []
<Begasus>
OscarL, speed up on python3.11 (if you read this) :)
Blendie has joined #haiku
Begasus_32 has joined #haiku
OscarL has joined #haiku
* OscarL
is against introducing yet another Python version while already having 5 different ones to deal with.
<Begas_VM>
Hola OscarL!
<OscarL>
Hola Begas_VM :-)
<Begas_VM>
well, korli suggested to add it to setuptools :)
<Begas_VM>
actually only 2 atm OscarL (3.8 doesn't realy count anymore for new things)
<OscarL>
Saw it. Liked it as a joke. Not so much as a serious suggestion :-)
<Begas_VM>
And when I drop 3.8 from setuptools it won't work anymore for those needing a rebuild for that version :)
<Begas_VM>
no official release for 3.11 yet?
<OscarL>
are you dropping it from setuptools now? Doesn't that goes against korli's own "give it 6 more months" ?
<Begas_VM>
check the PR :)
<Begas_VM>
ah! can't be build (python3.11 rc2) with xlibe_devel installed OscarL (conflict with tk)
<OscarL>
I guess I don't considered "maybe add python 3.11 at the same time? :)" a hard yes to your question about dropping it.
<Begasus>
heh, probably read it too serieus :)
<OscarL>
re 3.11, yes, it has officially released already. 3.12 is on the way.
<OscarL>
But I really think we should have some discussions about a "Python support policy for Haiku", before introducing new versions.
<Begasus>
tried it a few times (with other issues), doesn't get the needed attention sometimes
<OscarL>
I would propose to only have, at most, 3 active at any given time. Default one, "intended next default", and "old default version that some user might still need".
<Begasus>
as we got atm
<OscarL>
The rest can be had as disabled recipes (but not get .hpkps for them)
<OscarL>
We currently have 2.7, 3.7, 3.8, 3.9, 3.10. Even if 2.7 and 3.7 are on the way out, and 3.8 is in comma... they are still there :-D
<Begasus>
first 2 are mostly gone from the recipes (only the base packages for those remain atm)
<Begasus>
could be that some old BeOS things still rely on the older ones?
<Begasus>
but I guess we're past that (most of the libraries since then have seen updates to recent versions)
<OscarL>
AFAIK, even Bethon is brokoen now (that would be the mayor Python 2.7 user in Haiku/BeOS that I know of).
<Begasus>
yeah
<OscarL>
Anyway... guess I'll try to update my old 3.11 branch, to get it closer to the finish line. Still I would not want it to be included. I'm seeing it more like a stepping stone to 3.12 (assuming that we can just leap-frog to that one as next Haiku default).
<Begasus>
that's out of my leage :) up to the main Haiku devs :)
freddietilley has quit [Quit: WeeChat 3.8]
freddietilley has joined #haiku
<Begas_VM>
bugger ... done quite some work on babel, should've started on the new version already ...
OscarL has quit [Remote host closed the connection]
OscarL has joined #haiku
<OscarL>
"> inrecipe cmd:python$ | wc -l" Mmm... 116... even Telegram still BUILD_PREREQUIRES "cmd:python" :-(
<OscarL>
why I see "lib:libpython3.7m" in the rizin 0.5.2 recipe?
<Begas_VM>
eeps?
* Begas_VM
hides
<OscarL>
:-D
<Begas_VM>
fixing ...
HaikuUser has joined #haiku
HaikuUser has quit []
<OscarL>
Honest mistake, and not just wanting to see my head explode, I assume, right? RIGHT? :-D
<OscarL>
heh
<Begas_VM>
right .... (ducks)
<Begas_VM>
saw the message yesterday that setup.py will become obsolete by setuptools?
<Begas_VM>
not right away ...
<OscarL>
Saw your linked article, nice one.
<OscarL>
guess time to move to "python3 -m build" all the things! then :-P
<Begas_VM>
new version fixed the versioning also, so now sphinx is working fine
<OscarL>
saw that one too, nice!
<OscarL>
can we retire the opencv-4.5.1 recipe?
<Begas_VM>
yeah, even got it to build tex file that converts fine in texstudio (after the issue with psfonts.map was solved)
<Begas_VM>
is it used? :)
<OscarL>
I see 4.5.5 also active
<Begas_VM>
or even obsoleted by new version?
<Begas_VM>
think it's obsolete now
<OscarL>
I'm not seeing much usage for opencv3 even.
<OscarL>
but as 4.5.1 still requires numpy${secondaryArchSuffix}_python3... (the other two already switched to 3.9).... maybe we can just nuke it, right?
<Begasus>
still around for compat (opencv3)
<Begasus>
no dev package there
<Begasus>
4.5.1 is obsoleted by 4.5.5, so yes
<OscarL>
k.
<OscarL>
wish we did the same with the old rust recipes :-P
<Begasus>
can't be installed :)
<Begasus>
:P
<Begas_VM>
babel package now +9MiB :P
<OscarL>
ouch. was fatter before?
<Begas_VM>
no, not even 300KiB :P
<OscarL>
double ouch.
<Begasus>
Make sure to not forget about the ``import_cldr`` step because otherwise
<Begasus>
you will be missing the locale data.
<Begasus>
was missing that to get sphinx fully functioning
* OscarL
ponders on the idea of writting a ".whl to .hpkg" tool. Mmm.
<Begasus>
they hardcode the cdlr version, so I added a SOURCE_URI for that in the babel recipe
freddietilley has quit [Quit: WeeChat 3.8]
<Begasus>
if only they would add a check for a system version ...
<OscarL>
au contraire. I'm thinking of automating the creation of the recipe, given the .whl contains the right info.
<Begasus>
the templates are working like a charm here :)
freddietilley has joined #haiku
<OscarL>
I want to go to the next lazy step :-D
<OscarL>
give url of .whl / pypi... get .recipe ready. :P
<Begasus>
some things are not clear always (like copyright/license ...)
<OscarL>
license can be read from the pypi page.
<OscarL>
copyright, is the annoying one (we discussed this in the past :-P)
<Begas_VM>
MIT is the easiest (mostly they contain year and author in there)
<OscarL>
.whl contains LICENSE file.
<Begas_VM>
most tgz too
<OscarL>
just saying that, for most simple/small packages... I don't see much point on using the tarball to create the .whl and then install that, when we can just download the .whl and install that :-P (we are not doing much more on many of the simpler ones). Would simplify the BUILD_REQUIRES at least :-)
<OscarL>
Anyway... just adding that to the "ToDo (maybe)" list :-P
<Begasus>
that's an option too
mmu_man has joined #haiku
<Begasus>
but can those "any" whl packages be used always?
<Begasus>
you don't know what dependencies are behind a whl package?
<OscarL>
there's METADATA inside the .whl package
<OscarL>
"Requires-Dist: sphinx ~= 4.0 ; extra == "docs"" <<< example line from that file
<Begas_VM>
Requires-Dist: mypy>=0.990 ; extra == "lint"
<OscarL>
only two packages still requiring a "*_python3" package!
<Begas_VM>
what is the "lint" here?
<OscarL>
another package that will be used by mypy if it finds it, I think.
<Begas_VM>
guess I need to add a few more to my list in the recipe?
<OscarL>
mmm
<Begas_VM>
we don't have mypy?
<Begas_VM>
so it's not like you could drag that information out (installing sphinx will not work without mypy then)
<OscarL>
I think I was reading those wrong... Maybe there meain... "this is needed for the 'lint' step". See there are also "extra == docs" and "extra == test".
<OscarL>
Any way, just wondering, as the 2.79 has "numpy${secondaryArchSuffix}_python3", but commented out... can I just remove those so it stops appearing on my "inrecipe _python3$" searches ? :-D
freddietilley has quit [Quit: WeeChat 3.8]
<OscarL>
("blender: Remove commented out references to _python3 packages, no functional changes." would be my commit message)
<Begas_VM>
if so I wouldn't revbump it (no need for that)
<mrjones>
I gather that. Seeing new mails fetched by mail_daemon are quite fine, I guess a commandline tool based on the parser from mail_daemon would be the way to go
freddietilley has quit [Quit: WeeChat 3.8]
HaikuUser has quit []
HaikuUser2 has quit []
freddietilley has joined #haiku
* OscarL
gives "hp -G u-boot" another go (on 64 bits this time).
<woffs>
hi! wireless iprowifi2200 on x86 (IBM Thinkpad X41) does not want to connect to my mobile hotspot ("wrong password?"), while connecting to fritzbox works fine. how to debug? I'm an experienced linux admin but rather new to haiku
<Begas_VM>
No module named 'exceptiongroup' ...
<Begas_VM>
woffs, welcome, did you check the forum?
<OscarL>
no wonder sphinx was just pip installed when needed.
<Begas_VM>
and only because I wanted the docs for assimp :P
<OscarL>
just another reason to NOT RTFM ;-D
<Begas_VM>
checking pytest for pytz ...
<Begas_VM>
LOL
<OscarL>
welp, this u-boot thing is going nowhere.
<OscarL>
(only available on the depot for x86, it seems)
<OscarL>
arm_none_eabi_gcc << that one, I mean.
<Begas_VM>
you first got to fix the arm_none... stuff
<Begas_VM>
flit_scm :/
<Begas_VM>
the further you go the further you fall into the pit ...
freddietilley has quit [Quit: WeeChat 3.8]
<OscarL>
Begas_VM: do poetry after you finish with this pit! :-D
<Begasus>
I'll start writing python haiku's :P
<OscarL>
(by that time, I guess you'll already had at least half the dependencies ready :-D)
<Begasus>
yeah, but haven't started to fill in all the gaps in the recipe (from template) :)
<Begasus>
first setuptools needs to be merged (atleast for one of the sphinx sub-packages)
<OscarL>
I think I'll just add a PR for u-boot, adding the missing PATCHES, switching to setuptools_python39, and marking it as disabled, as it can't be currently be built due to missing dependencies.
<Begas_VM>
bugger, setuptools_scm needs updating there too
<OscarL>
woffs: maybe add a comment there then, explaing that you had to do that manually despite the ticket marked as closed.
HaikuUser has joined #haiku
HaikuUser has quit []
<woffs>
maybe I should
<woffs>
another problem is the default gw disappearing when switching networks. I re-add it by hand, too, but i wonder
<Begas_VM>
not giving in that easy ... :) grabbing exceptiongroup_python310-1.1.1-1-any.hpkg and moving it to /boot/home/haikuports/packages/exceptiongroup_python310-1.1.1-1-any.hpkg
<OscarL>
10℃ and I'm kinda freezing. thats what I get after too many long summers of 35-40+ ℃ (and lows not lower than 25℃)
<Begas_VM>
eeps OscarL that's cold for the time of year
<OscarL>
not down here :-D
<win8linux[m]>
Canonical recently announced that the next Ubuntu LTS will have an all-Snap release, alongside the regular mixed DEBs/Snap one.
<win8linux[m]>
Would that be the closest thing to a Haiku-esque immutable Linux distro?
<OscarL>
fedora's silversomething already does that, no?
<win8linux[m]>
Sort of, but rpm-ostree is only for system packages while Flatpak is for user applications.
<OscarL>
Porteus uses "modules" you activate without unpacking (IIRC).
<win8linux[m]>
Snap and pkgman meanwhile don't make that distinction and handle all packages.
mrjones has quit [Quit: Vision[]: i've been blurred!]
<Begas_VM>
OscarL ... I'm a bit lost to what to push first now :P
<OscarL>
heh. do a mega PR :-D
<Begas_VM>
Guess I should hook setuptools_scm together with the setuptools one first
<Begas_VM>
for the new ones I plan to
<OscarL>
"Fixes/Adds stuffs" would be a good enough comment, I think.
<Begas_VM>
yeah, but some need the newer ones (like pytest requires exceptiongroup also now)
<OscarL>
(can already imaging korli screaming on the background :-P)
<Begas_VM>
heh
<Begas_VM>
for pytz and flit_scm I had to use the PRETEND fix
<Begas_VM>
should see if there is anything regarding that on the net ...
<Begas_VM>
without "LookupError: setuptools-scm was unable to detect version for /sources/flit_scm-1.7.0."
<Begas_VM>
ah! can't use -G for those OscarL, seems they pull the version from the git tag
mmu_man has quit [Ping timeout: 480 seconds]
freddietilley has quit [Quit: WeeChat 3.8]
<OscarL>
mmm but how the git repo initialized by haikuporter would have anything to do with their true git tags?
<Begas_VM>
__version__ = version = '0.1.dev1+gd8a5e78' ... still looks strange ...
<OscarL>
seems to me that the setup.py/whatever is wronly assuming the .git repo is the upstream one without even checking. and seeing that HP creates a .git... they pull the "tag" from it, then you get those weird ".dev1+sha"
<Begas_VM>
this one is using pyproject.toml
freddietilley has joined #haiku
<OscarL>
same thing, if they are using git to generate the version from tags (or other git info)
nephele has joined #haiku
nephele has quit []
<OscarL>
If SETUPTOOLS_SCM_PRETEND_VERSION works, I say, use that.
<OscarL>
alternatively, maybe there's a "version.txt" file or similar we could patch via sed, for example?
* OscarL
crosses fingers while tryingt to build u_boot on 32 bits.
<Begasus>
idealy it would be fine if we could fix setuptools_scm so we wouldn't need the "fix" :)
<OscarL>
setuptools and friends are on the way out, and that issue with the version affects only a few packages, maybe the issue is on the packages and not on setuptools_scm ?
<OscarL>
We could take a look anyway, but seems low prio, no?
floof58 has quit [Ping timeout: 480 seconds]
<Begasus>
yep, but you know me, first do some digging :)
<OscarL>
:-)
<OscarL>
well. u_boot build failed still/again on 32 bits, same libmpr4.so issue.
<Begasus>
you could poke someone there to have a peek :)
<OscarL>
done.
<erysdren>
gnight all
<OscarL>
hi erysdren.
<OscarL>
Cold 9:00 here. /me goes for coffee after "Failed to find a match for 'six_python3'"
<Begas_VM>
heh
<Begas_VM>
cu erysdren!
<OscarL>
how come "good night all" counts as "goodbye" but "good morning" counts as "hello" ? /me think that wrongly discriminates against nightowls like me :-P
<Begas_VM>
me guesses he's going down (as he already said hey this morning here) :)
<Begas_VM>
it doesn't count in your case :P
<OscarL>
just found it funny that it didn't even registered as a "bye" in my head, and I was even confused by your "cu" reply :-D
<Begas_VM>
I don't think we need the PRETEND= for setuptools_scm recipe
<Begas_VM>
that one is fine ...
* Begas_VM
looks who put it there ...
<OscarL>
mmm I wonder who removed six_python3... me goes to check.
<OscarL>
" * Begas_VM looks who put it there ..." got worried for a sec, korli's avatar and mine kinda look alike at that small sizes.
<Begasus>
heh
<Begasus>
lol ... paging ... :P
<OscarL>
:D
<OscarL>
mmm when will this newbie learn? korli removed six_python3 on his mega patch. :-D
<OscarL>
At least it wasn't I who broke it :-D
<Begas_VM>
well, you wanted to drop python3.7 :P
<OscarL>
and I was being careful about doing so, unlike some folks. /me shakes head. :-P
<Begas_VM>
you just didn't had the time to write a script to do that yourself? ;)
<Begas_VM>
getting close to 100 python packages in the packaged directory ;)
<OscarL>
I was just still not confident enough to script the updates :-D Next time... I migtht just yolo it myself too :-D
<Begasus>
best start with something now :)
<OscarL>
I need to check this mozc recipe against six_python3, because It fails to build with six_python39, and I don't know if that's due to some change in Python, on six, or what. Guess I'll just reactivate six for 3.7 locally now.
<Begasus>
there, added setuptools_scm to the PR
<Begasus>
no patches around for mozc?
<OscarL>
I get lost too easily around repology.
<OscarL>
running hp mozc_x86
<Begas_VM>
heh
<Begas_VM>
OS's I check mostly: Alpine, Arch, Debian, Fedora, Gentoo and openSUSE
<OscarL>
still, our mozc seems to be a fork.
<OscarL>
homepage points to google/mozc on github, but sources are for hanya/mozc (haiku specific fork)
<Begasus>
yeah, just looked
<Begasus>
patch doesn't seem to hard, could you look for the latest version around, I think hanya forked it and used it's own instead of upstream?
<Begasus>
nothing related to haiku in that fork ...
<OscarL>
there are 2 haiku branches, one with 135 commits ahead.
<Begasus>
ah!
<OscarL>
not going there for now, not untill I see if it still builds with Python 3.7
<Begasus>
another story yes ...
<Begasus>
biab
freddietilley has quit [Quit: WeeChat 3.8]
freddietilley has joined #haiku
<Begasus>
re
<OscarL>
building mozc_x86 on 32 bits, with Python3.7 + six_python3: "[677/693]" and seems it ran out of memory :-(
<Begas_VM>
jikes :/
<OscarL>
trying again (hoping it doesn't starts from zero).
<Begas_VM>
guess you should have sticked with the python recipes :)
<OscarL>
indeed.
<Begas_VM>
with the templates you have a package in 5 minutes :)
<OscarL>
but at least it is clear that there's an issue with Python 3.7 vs 3.9 for this recipe... 3.9 is giving some UnicodeDecodeError that 3.7 doesn't seems to complain about.
<OscarL>
yup. std::bad_alloc again. Guess I'll try on bare metal for this one. brb
OscarL has quit [Quit: Page closed]
OscarL_32 has joined #haiku
<OscarL_32>
I had to set IPv4 to Disabled, and then back to Dynamic after rebooting to get networ going. Happened a couple of times already. Weird.
<nekobot>
[haiku/haiku] 1eb7837ddd00 - usb_disk: Ensure we are in a consistent locking state before calling free.
<OscarL>
Begas_VM: you mean that every package using pytest will also depend on, say, hipothesis? (that doesn't feels right to me, TBO)
zard has quit [Quit: leaving]
Blendie has quit [Quit: Connection closed for inactivity]
<Begas_VM>
not OscarL?
CPYou has quit [Quit: Reconnecting]
CPYou has joined #haiku
<Begas_VM>
well, don't think there is any "real" dependency for pytest aside in TEST()?
<OscarL>
similar thing with "build". it has few to none "hard" dependencies. I debated with myself adding at least setuptools to it, because it is used as a fallback if no other build system is specified, but if a project uses build with flit_core instead... why will it need to depend on setuptools?
<OscarL>
I rather be explicit on the direct dependencies. otherwise it makes things harder to understand after time passes.
<Begas_VM>
hmm ... k, can live with that, will be for tomorrow, now trying to round this up :)
frkazoid333 has joined #haiku
<OscarL>
the trick is also not add too much dependencies, just because they usually go together (a risk when using templates).
<Begas_VM>
well, I need some for build dependencies, can't get away there
<OscarL>
sure thing, but, for example.... not every recipe that uses build/installer needs to declare dependencies on setuptools/wheel.
<OscarL>
just a thing to keep an eye out for.
<Begas_VM>
I had to change setuptools to setuptools_scm a few times already
<Begas_VM>
will do
<OscarL>
it is all very tricky, and gets annoying, fast :-)
<Begas_VM>
yeah, and most of the ones I checked in the last days switched to "build" instead of using setup.py
<OscarL>
and when you think you "got it", they came up with yet another build system, new dependencies, or they just drop ones!
<Begas_VM>
right :D
<OscarL>
that's why I try to stick to just the standard library as I can for my own Python code.
<OscarL>
hate this dependency mess.
<Begas_VM>
adding: defaultTestVersion="python39" for TEST_REQUIRES
<OscarL>
s/as I can/as much as I can/
<Begas_VM>
I "could" narrow down the dependencies for the TEST on setuptools_scm (but then I'm lost not knowing if it could work or not) :)
<Begas_VM>
previous test without cmd:hg were skipped, now I know those tests are fine too
<OscarL>
do your best effort, as you always do, but don't sweat too much. can always refine things later.
<OscarL>
Wow, lost track of time, 16:30 already? food break.
<Begas_VM>
heh
<Begas_VM>
enjoy your meal
<jmairboeck>
OscarL: I added another suggestion to your noteshrink PR, which is more work, but would be cleaner IMHO
<OscarL>
thanks jmairboeck!
Begas_VM has quit [Quit: Vision[]: i've been blurred!]