i.svm: Add libsvm-based image classification

[marisn]

A pair of modules revealing most of features of libsvm to GRASS.
Libsvm is a popular library used in many machine learning programs (including scikit-learn). Contrary to some add-ons, this is a pure C implementation thus bypassing Python and depending on presence of libsvm.

Missing features:

• ability to use a precomputed kernel
• ability to provide weights for classifying unbalanced data
• parallel processing for value prediction/estimation

This is still a WIP as some rough edges still need to be ironed out.

[wenzeslaus]

I clicked the Update branch (with merge) to see if this passes after #2281 (see comment from @echoix).

[nilason]

I clicked the Update branch (with merge) to see if this passes after #2281 (see comment from @echoix).

configure need to be regenerated, now with autoconf 2.71.

[wenzeslaus]

configure need to be regenerated, now with autoconf 2.71.

I don't like that neither Git nor CI see that issue. (I don't either, but that's an expected behavior.)

[echoix]

I clicked the Update branch (with merge) to see if this passes after #2281 (see comment from @echoix).

configure need to be regenerated, now with autoconf 2.71.

My initial implementation of the periodic update workflow in #3200 was explicitly checking that, by regenerating configure each month, no make sure nothing changes, a bit like what the existing procedure in the docs were mentioning. But it got reviewed down to simply updating the config.guess and config.sub, and nothing more, since it was thought that the ubuntu version of autoconf might be too customized and if it was the case, the output could be slightly different. But when done manually, is autoconf really compiled from source just for that?

In either case, if its now autoconf 2.71 that is used, we might have to update the dependency listed in here

grass/.github/workflows/python_apt.txt

Line 1 in da06dd1

autoconf2.13

[nilason]

Sorry, but here we go again, also with 2.71.

[echoix]

In Ubuntu, that patch seems to be in 2.73-3, and not in 2.73-2, and Ubuntu Jammy (22.04) didn't get 2.73-3, stays at 2.73-2.

We must decide which type of system is the source of truth, and all other systems should rerun autoconf (like they should, committing configure as a generated file isn't the best recommandation except for releases) to have the appropriate patches for their system.

And is there a real issue with that makes the software unbuildable or incorrect with this ? The patches seem to originate from a bug that the packagers had to patch for.

[nilason]

In Ubuntu, that patch seems to be in 2.73-3, and not in 2.73-2, and Ubuntu Jammy (22.04) didn't get 2.73-3, stays at 2.73-2.

We must decide which type of system is the source of truth, and all other systems should rerun autoconf (like they should, committing configure as a generated file isn't the best recommandation except for releases) to have the appropriate patches for their system.

And is there a real issue with that makes the software unbuildable or incorrect with this ? The patches seem to originate from a bug that the packagers had to patch for.

As long as we pre-generate configure it has to be done with a patch-free version (easy to compile if needed), to avoid unrelated back-and-forth changes. If absolutely needed by packaging it may be re-generated on-the-fly.

[marisn]

As long as we pre-generate configure it has to be done with a patch-free version (easy to compile if needed), to avoid unrelated back-and-forth changes. If absolutely needed by packaging it may be re-generated on-the-fly.

This is problematic as I even had no idea I have some kind of "special" version that should not be used. Besides, as a former Gentoo user, I got used to run patched versions of packages ;-)

[nilason]

As long as we pre-generate configure it has to be done with a patch-free version (easy to compile if needed), to avoid unrelated back-and-forth changes. If absolutely needed by packaging it may be re-generated on-the-fly.

This is problematic as I even had no idea I have some kind of "special" version that should not be used. Besides, as a former Gentoo user, I got used to run patched versions of packages ;-)

I understand it is an annoyance. The changes I noted are, by the way, included with autoconf 2.72 and as far as I can tell not critical at all for us. For this PR it is enough to revert the two lines, no need to generate.

[nilason]

Great, do hurry up to merge as soon as the CIs are done! :)

[nilason]

@echoix Better leave the merge to @marisn .

[nilason]

@echoix Better leave the merge to @marisn .

He is the author and assignee of this PR.

[nilason]

@echoix Better leave the merge to @marisn .

He is the author and assignee of this PR.

Thinking about it, please, do not activate auto-merge at all: with squash the commit message more often than not need to be refined.

[echoix]

Thinking about it, please, do not activate auto-merge at all: with squash the commit message more often than not need to be refined.

In what other cases would you hope to tune the squash message (to know when it applies)? You have the box to edit it when using that option, it shows the same thing as normally, but earlier instead of later.

[nilason]

Thinking about it, please, do not activate auto-merge at all: with squash the commit message more often than not need to be refined.

In what other cases would you hope to tune the squash message (to know when it applies)? You have the box to edit it when using that option, it shows the same thing as normally, but earlier instead of later.

List is long, but not every commit message in a PR is a candidate for merge commit message, some obvious ones: "fix typo", "apply black", "revert thisorthat"; nor any rebase/merge on main (I noticed if someone hits the "update branch", that person is also added as co-author, which is not a good reason for co-authorship).
It should be a clear summary of the purpose of the final commit, which is the job for the assignee to compose.