New release?

[minad]

@sjaeckel Would it make sense to cut a new release at some point and remove deprecated stuff afterwards? Are there open issues right now which stand in the way of a new release?

Or do you want to have all the open PRs resolved until then?

[sjaeckel]

Would it make sense to cut a new release at some point and remove deprecated stuff afterwards?

definitely!

Are there open issues right now which stand in the way of a new release?

not that I know of

Or do you want to have all the open PRs resolved until then?

not all, but those that make sense to have them rolled out to a wider audience

originally I wanted to make a v1.1.1 but forgot about it and now we can also see if we can immediately go with 1.2.0

@lvc can you please check why ltm isn't updated on https://abi-laboratory.pro/?view=timeline&l=libtommath? I'd like to see the differences to current develop

[lvc]

@lvc can you please check why ltm isn't updated on https://abi-laboratory.pro/?view=timeline&l=libtommath? I'd like to see the differences to current develop

The report has been updated.

[minad]

@sjaeckel Don't know what your plans are now but I think I would rather continue to deprecate a few more things in the public API (some of #243, depending on what you like, starting with #245).

If #244 gets merged the public API will get quite a bit more annoying for the lib user, so it shouldn't matter if we add a few more warnings on top.

We will make sure that everything stays API/ABI backwards compatible obviously until the deprecations are removed.

[minad]

@lvc Doesn't this report update automatically via polling every few days?

[lvc]

@lvc Doesn't this report update automatically via polling every few days?

Working on restoring the service since Apr 4 due to the compute server storage failure. Need 1 more month to complete. So temporarily I update reports manually by request.

[lvc]

Report has been updated.

[lvc]

Feel free to ping me to update reports during this period.

[minad]

@sjaeckel Maybe we could also make a plan here. For now I don't intend to change many more things (deprecation/incompatibilities) in the public api.

[minad]

@lvc Could we please get another compatibility report?

[minad]

Btw, is there something like a global symbol database, e.g. over all debian packages? This would help guiding deprecation decisions and it would help to estimate the impact of certain changes. This is relevant for example for #294. Ping @dod38fr

[dod38fr]

I've never heard of such a DB. OTOH you can search the soon-to-be-deprecated function calls in the source of all packages on https://sources.debian.org/

HTH

[minad]

@dod38fr Thanks! This is better than nothing!

The downside of this search in contrast to symbols from shared objects is that there are many hits due to the library being vendored. In the debian binary packages this duplication would be gone. But who am I to complain - happy Debian user for years :)

[sjaeckel]

ping @lvc :-)

[sjaeckel]

thx @lvc

BTW. I've the impression that the latest build isn't updating correctly, there should be more than 7 new symbols!

[minad]

That's weird. All these set_i32 symbols etc are missing, which were added in 20ae9fba

[lvc]

Report has been updated.

[lvc]

Btw, is there something like a global symbol database, e.g. over all debian packages? This would help guiding deprecation decisions and it would help to estimate the impact of certain changes. This is relevant for example for #294. Ping @dod38fr

@minad

May be https://abi-laboratory.pro/?view=navigator&symbol=mp_get_bit#result ?

[sjaeckel]

thx @lvc and nice tool, the symbol navigator!

[minad]

@lvc Thanks. Regarding the symbol database - it seems your tool allows me to search for a symbol and the location where it is defined. What I would like to have is a tool which also shows me where the symbol is used within the full debian repo for example. Do you have sth like that too?

[lvc]

@minad

@lvc Thanks. Regarding the symbol database - it seems your tool allows me to search for a symbol and the location where it is defined. What I would like to have is a tool which also shows me where the symbol is used within the full debian repo for example. Do you have sth like that too?

The LSB navigator is intended for this purpose: https://www.linuxbase.org/navigator/commons/welcome.php

But unfortunately it is not updated lately(

[sjaeckel]

Looks like @lvc has repaired the ABI lab, thanks for that!

Maybe we could also make a plan here. For now I don't intend to change many more things (deprecation/incompatibilities) in the public api.

sounds like a good idea, now that the year is coming to an end we should make a list of things that should still go in 1.2.0, so we can aim for an RC1

[minad]

I think we should only add the radix/ubin/sbin api cleanup. These should be consistent and safe. Besides that nothing seems ready yet. The mp_to_radix_fast/mp_to_dec_fast patch will be internal and it still needs time to mature.

[minad]

@sjaeckel I added the tags to the things I think should go into 1.2.

[minad]

@sjaeckel It seems we accidentally removed two symbols according to the api checker. I can prepare a PR fixing this.

mp_to_signed_bin ( mp_int const* a, unsigned char* b )
mp_to_signed_bin_n ( mp_int const* a, unsigned char* b, unsigned long* outlen )

[minad]

We already added 44 functions in 1.2 :eyes: Seems about time for a new release...

[sjaeckel]

We already added 44 functions in 1.2

with the two that were missing it's 46, but bn_deprecated.c contains 45 so we basically only added 1 function ;-)

[sjaeckel]

btw. thx a lot @minad and @czurnieden for your work on weeding out, refactoring and improving the functionality and API's!

[sjaeckel]

Now I've only one patch left lying here around...

diff --git a/bn_mp_to_radix.c b/bn_mp_to_radix.c
index 7fa86ca..38fd03e 100644
--- a/bn_mp_to_radix.c
+++ b/bn_mp_to_radix.c
@@ -70,4 +70,2 @@ mp_err mp_to_radix(const mp_int *a, char *str, size_t maxlen, size_t *written, i

-   /* append a NULL so the string is properly terminated */
-   *str = '\0';
    digs++;
@@ -79,2 +77,4 @@ mp_err mp_to_radix(const mp_int *a, char *str, size_t maxlen, size_t *written, i
 LBL_ERR:
+   /* append a NULL so the string is properly terminated */
+   *str = '\0';
    mp_clear(&t);

should I open a PR for it or should we go for the release?

...because currently a failing test can end in a segfault...

[minad]

No, this patch is not good. In the error case, the string is invalid. We also bail out earlier with MP_BUF for example and don't write the trailing 0.

Let's go for the release :)

[sjaeckel]

I've added https://github.com/libtom/libtommath/tree/release/1.2.0

will add archives etc. and update homepage later

[sjaeckel]

@lvc would it be possible to add another build to the ABI checker when a branch called release/* exists?

[sjaeckel]

https://www.libtom.net/news/LTM_1.2.0RC1/

[sjaeckel]

:+1:

[linuxhw]

@lvc would it be possible to add another build to the ABI checker when a branch called release/* exists?

Nope. Only one fixed latest branch (master) can be tracked. But it's possible to automatically track pre-releases (enabled).

[sjaeckel]

Nope. Only one fixed latest branch (master) can be tracked. But it's possible to automatically track pre-releases (enabled).

thanks! that's enough

[sjaeckel]

https://www.libtom.net/news/LTM_1.2.0/