new version v1.x

[sjaeckel]

A placeholder issue to reference PR's that should be (at least partially) included in a potential 1.2.1 or 1.3.0

[minad]

Suffix renamings #437 or #446 should be backported (only the renaming and deprecations in order to ease the transition)

[minad]

#442 min_prec too small

[minad]

#450 deprecate mp_div_3 (private in 2.0)

[minad]

#452 MP_HAS issue

[minad]

#471 overflow check for safety

[minad]

#476 double cpp check

[dod38fr]

Hi

Debian will enter freeze in January to prepare next Debian release. Currently, Debian ships libtommath 1.2.0.

If you think libtommath should be updated for next Debian release, you should cut a new libtommath release no later than December.

All the best

Dod (for Debian)

[royjit]

Hi,

Do you have plans or ETA of when the next stable version will be released?

Thanks,
Jithin

[dod38fr]

Hi
The next Debian stable version (2) will be released in Summer 2023.

To prepare this release, freeze will begin in January.

All the best

[dod38fr]

Hi

Debian will begin freeze process in January to prepare Debian 12 release. Currently, Debian still ships libtommath 1.2.0 which is 3 years old.

If you think libtommath should be updated for Debian 12, you should cut a new libtommath release as soon as possible.

All the best

Dod (for Debian)

[czurnieden]

Oh crap! Too late again, hu?
Otherwise: it would be ready as it it is.
@sjaeckel I haven't done a proper publishing before and am too afraid to eff up, sooooo...if you don't mind :-)
Or is there a hindrance I am unaware of?

[dod38fr]

Oh crap! Too late again, hu?

Not too late. Barring backward compatibility issue, I should be able to update libtommath for Debian 12 if it's released in the next 3 weeks. But the sooner a new release is done, the better.

Happy new year !

[sjaeckel]

Cool, could you please take develop and check whether a release would be fine?

[dod38fr]

Unfortunately, at least a symbol is gone (mp_iseven is replaced by a #define). This breaks the ABI compatibility of libtommath.

Which means libtommath must be released with a new major version (e.g. something like libtommath.so.2.x.y). Which will requires a rebuild (and may be code modifications) of all reverse dependencies in Debian.

I'm afraid it's too late for Debian 12.

That said, I would welcome a new release, this way we'll have enough time for Debian 13.

[sjaeckel]

Could you please list all ABI breaks so we can check whether it'd make sense to take the effort to backport and release another version of libtommath.so.1? ... and at the same time also release a libtommath.so.2 ...

[dod38fr]

Hi

For what it's worth, here's a diff comparing the old and new list of symbols:

--- /tmp/libt.old       2023-01-03 18:53:12.541434141 +0100
+++ /tmp/libt.new       2023-01-03 18:52:51.730263028 +0100
@@ -1,15 +1,9 @@
-fast_mp_invmod
-fast_mp_montgomery_reduce
-fast_s_mp_mul_digs
-fast_s_mp_mul_high_digs
-fast_s_mp_sqr
 mp_2expt
 mp_abs
 mp_add
 mp_add_d
 mp_addmod
 mp_and
-mp_balance_mul
 mp_clamp
 mp_clear
 mp_clear_multi
@@ -20,74 +14,51 @@
 mp_complement
 mp_copy
 mp_count_bits
-mp_decr
 mp_div
 mp_div_2
 mp_div_2d
-mp_div_3
 mp_div_d
 mp_dr_is_modulus
 mp_dr_reduce
 mp_dr_setup
 mp_error_to_string
 mp_exch
-mp_export
-mp_expt_d
-mp_expt_d_ex
 mp_exptmod
-mp_exptmod_fast
-mp_expt_u32
+mp_expt_n
 mp_exteuclid
 mp_fread
 mp_from_sbin
 mp_from_ubin
 mp_fwrite
 mp_gcd
-mp_get_bit
 mp_get_double
 mp_get_i32
 mp_get_i64
-mp_get_int
 mp_get_l
-mp_get_ll
-mp_get_long
-mp_get_long_long
 mp_get_mag_u32
 mp_get_mag_u64
 mp_get_mag_ul
-mp_get_mag_ull
 mp_grow
-mp_import
-mp_incr
+mp_hash
 mp_init
 mp_init_copy
 mp_init_i32
 mp_init_i64
 mp_init_l
-mp_init_ll
 mp_init_multi
 mp_init_set
-mp_init_set_int
 mp_init_size
 mp_init_u32
 mp_init_u64
 mp_init_ul
-mp_init_ull
 mp_invmod
-mp_invmod_slow
-mp_iseven
-mp_isodd
 mp_is_square
-mp_jacobi
-mp_karatsuba_mul
-mp_karatsuba_sqr
 mp_kronecker
 mp_lcm
-mp_log_u32
+mp_log_n
 mp_lshd
 mp_mod
 mp_mod_2d
-mp_mod_d
 mp_montgomery_calc_normalization
 mp_montgomery_reduce
 mp_montgomery_setup
@@ -97,28 +68,22 @@
 mp_mul_d
 mp_mulmod
 mp_neg
-mp_n_root
-mp_n_root_ex
 mp_or
 mp_pack
 mp_pack_count
 mp_prime_fermat
 mp_prime_frobenius_underwood
-mp_prime_is_divisible
 mp_prime_is_prime
 mp_prime_miller_rabin
 mp_prime_next_prime
 mp_prime_rabin_miller_trials
 mp_prime_rand
-mp_prime_random_ex
 mp_prime_strong_lucas_selfridge
 mp_radix_size
+mp_radix_size_overestimate
 mp_rand
-mp_rand_digit
 mp_rand_source
 mp_read_radix
-mp_read_signed_bin
-mp_read_unsigned_bin
 mp_reduce
 mp_reduce_2k
 mp_reduce_2k_l
@@ -127,74 +92,29 @@
 mp_reduce_is_2k
 mp_reduce_is_2k_l
 mp_reduce_setup
-mp_root_u32
+mp_root_n
 mp_rshd
 mp_sbin_size
 mp_set
 mp_set_double
 mp_set_i32
 mp_set_i64
-mp_set_int
 mp_set_l
-mp_set_ll
-mp_set_long
-mp_set_long_long
 mp_set_u32
 mp_set_u64
 mp_set_ul
-mp_set_ull
 mp_shrink
-mp_signed_bin_size
 mp_signed_rsh
-mp_sqr
 mp_sqrmod
 mp_sqrt
 mp_sqrtmod_prime
 mp_sub
 mp_sub_d
 mp_submod
-mp_tc_and
-mp_tc_div_2d
-mp_tc_or
-mp_tc_xor
-mp_toom_mul
-mp_toom_sqr
 mp_to_radix
-mp_toradix
-mp_toradix_n
 mp_to_sbin
-mp_to_signed_bin
-mp_to_signed_bin_n
 mp_to_ubin
-mp_to_unsigned_bin
-mp_to_unsigned_bin_n
 mp_ubin_size
 mp_unpack
-mp_unsigned_bin_size
 mp_xor
 mp_zero
-s_mp_add
-s_mp_balance_mul
-s_mp_exptmod
-s_mp_exptmod_fast
-s_mp_get_bit
-s_mp_invmod_fast
-s_mp_invmod_slow
-s_mp_karatsuba_mul
-s_mp_karatsuba_sqr
-s_mp_montgomery_reduce_fast
-s_mp_mul_digs
-s_mp_mul_digs_fast
-s_mp_mul_high_digs
-s_mp_mul_high_digs_fast
-s_mp_prime_is_divisible
-s_mp_prime_random_ex
-s_mp_rand_jenkins
-s_mp_rand_jenkins_init
-s_mp_rand_platform
-s_mp_reverse
-s_mp_sqr
-s_mp_sqr_fast
-s_mp_sub
-s_mp_toom_mul
-s_mp_toom_sqr

The diff was done with:

nm -g -D build/libtommath.so.1.2.0  | grep ' T ' | cut -d ' ' -f 3 > /tmp/libt.new
nm -D /usr/lib/x86_64-linux-gnu/libtommath.so.1.2.0  | grep ' T ' | cut -d ' ' -f 3 > /tmp/libt.old
diff -u /tmp/libt.old /tmp/libt.new

[sjaeckel]

OK, we won't backport.

I'm afraid it's too late for Debian 12.

Then it is as it is.

@minad I guess you closed all those 2.0 tickets to have the release sooner?

@czurnieden @minad: Now that it doesn't matter anymore should we re-open them again and tackle them before a 2.0 or should we keep them closed and simply "slap a tag on develop"?

[czurnieden]

Now that it doesn't matter anymore should we re-open them again and tackle them before a 2.0 or should we keep them closed and simply "slap a tag on develop"?

There is nothing in the closed issues that are actually an issue in the sense of "bug or bug like" (including documentation), these were more or less discussions that were left open or--more likely--forgotten.

We have to start somewhere: why not actually just call it 2.0.0 and let the first bugfix(es) be 2.0.1 and the first change(es) 2.1.0? As the old saying goes: "Release early, release often!" (McCarthy 1995). (Assuming no conflicts with e.g.: distributions!)

And admitted: it would save me from the headaches with #523 if the version in "master" has cmake ;-)

[sjaeckel]

If I'm not mistaken this is all solved by 1.3.0.

Please re-open if that's not the case.