Issue40874
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2020-06-05 16:29 by skrah, last changed 2022-04-11 14:59 by admin. This issue is now closed.
Pull Requests | |||
---|---|---|---|
URL | Status | Linked | Edit |
PR 20652 | merged | skrah, 2020-06-05 16:32 | |
PR 20654 | merged | miss-islington, 2020-06-05 17:43 | |
PR 21202 | merged | skrah, 2020-06-28 19:37 | |
PR 21203 | merged | miss-islington, 2020-06-28 20:03 |
Messages (58) | |||
---|---|---|---|
msg370766 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-05 16:29 | |
Synopsis: There are no relevant new features for _decimal, but it would be too much work/error prone to have divergent code in libmpdec-2.5.0 and Python 3.9, especially for the Linux distributions. I'll release libmpdec-2.5.0/libmpdec++-2.5.0 in a month or so. The standalone lib needs the new versions of mpd_qsqrt() and mpd_qdiv(), because it allows identical result/input args. This is not needed for _decimal, but the distributions should have the correct version. In detail ========= - Use Google style guide for header guards and includes. - Update mpdecimal.h for C++11. - Use minimum set of includes. - Whitespace fixes. - Add annotations to suppress false positives from static analyzers. - Small rewrite in base conversion functions to suppress false positives from static analyzers. - MSVC: make libmpdec /W4 warning free and replace UNUSED with void casts. - MSVC: C++ fixes in vccompat.h. - Make a couple of quiet functions safe for being called with a dirty status (irrelevant for _decimal and not recommended anyway -- always set the status to 0 before calling a quiet function). - Add the sqrt/div versions that are already in the Python libmpdec but not in the upstream libmpdec. Also make them safe for identical result/operand arguments (irrelevant for _decimal, since Decimals are immutable). New functions for the upcoming libmpdec++ (unused in _decimal) ============================================================== - mpd_qset_string_exact() - mpd_qset_i64_exact() - mpd_qset_u64_exact() - mpd_qcopy_cxx() |
|||
msg370774 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-05 17:43 | |
New changeset 087d612efebe7c64e5f079b07e0454111859830e by Stefan Krah in branch 'master': bpo-40874: Update to libmpdec-2.5.0 (GH-20652) https://github.com/python/cpython/commit/087d612efebe7c64e5f079b07e0454111859830e |
|||
msg370780 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-05 19:41 | |
New changeset 83bff88b4b16fb30491faa9263bbd6f3df4bab56 by Miss Islington (bot) in branch '3.9': bpo-40874: Update to libmpdec-2.5.0 (GH-20652) https://github.com/python/cpython/commit/83bff88b4b16fb30491faa9263bbd6f3df4bab56 |
|||
msg372530 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-28 20:01 | |
New changeset 8bea91b5e9ea07ca93958e131b436024f0b1b1cf by Stefan Krah in branch 'master': bpo-40874 Update the required libmpdec version for the decimal module (GH-21202) https://github.com/python/cpython/commit/8bea91b5e9ea07ca93958e131b436024f0b1b1cf |
|||
msg372532 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-28 20:25 | |
New changeset 119de0eba839993cf6a909dba5d60202ad5566d6 by Miss Islington (bot) in branch '3.9': bpo-40874 Update the required libmpdec version for the decimal module (GH-21202) https://github.com/python/cpython/commit/119de0eba839993cf6a909dba5d60202ad5566d6 |
|||
msg372534 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-28 21:14 | |
A very brief guide for all users of --with-system-libmpdec: Python 3.7 and Python 3.8 both require the release with this sha256sum: 83c628b90f009470981cf084c5418329c88b19835d8af3691b930afccb7d79c7 mpdecimal-2.4.2.tar.gz Python 3.9 requires the release with this sha256sum: 15417edc8e12a57d1d9d75fa7e3f22b158a3b98f44db9d694cfd2acde8dfa0ca mpdecimal-2.5.0.tar.gz |
|||
msg372579 - (view) | Author: Anthony Sottile (Anthony Sottile) * | Date: 2020-06-29 14:40 | |
this breaks builds for ubuntu, I'd suggest reverting this (especially because it appears to build fine without this patch) 2020-06-29T08:52:56.8303672Z x86_64-linux-gnu-gcc -pthread -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -g -fdebug-prefix-map=/tmp/code=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector -Wformat -Werror=format-security -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -I../Include/internal -DCONFIG_64=1 -DASM=1 -I../Include -IObjects -IPython -I. -I/usr/include/x86_64-linux-gnu -I/tmp/code/Include -I/tmp/code/build-static -c /tmp/code/Modules/_decimal/_decimal.c -o build/temp.linux-x86_64-3.9/tmp/code/Modules/_decimal/_decimal.o 2020-06-29T08:52:56.9003112Z /tmp/code/Modules/_decimal/_decimal.c:40:4: error: #error "libmpdec version >= 2.5.0 required" 2020-06-29T08:52:56.9005053Z #error "libmpdec version >= 2.5.0 required" 2020-06-29T08:52:56.9006190Z ^~~~~ |
|||
msg372580 - (view) | Author: Anthony Sottile (Anthony Sottile) * | Date: 2020-06-29 14:41 | |
especially this late in the beta period for 3.9 -- it would be unfortunate for 3.10 but it's an explicit break of feature freeze for 3.9 |
|||
msg372581 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-29 14:48 | |
Ubuntu is my main system, and it does not break the build. If you use --with-system-libmpdec, you need to keep in sync with the external libmpdec. |
|||
msg372584 - (view) | Author: Anthony Sottile (Anthony Sottile) * | Date: 2020-06-29 14:51 | |
reverting this patch passes all the tests, what's the motivation and why were there no code reviews for this? |
|||
msg372585 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-29 14:52 | |
Please name a buildbot that does not pass. |
|||
msg372586 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-29 14:52 | |
Or is this CoC bait again? |
|||
msg372587 - (view) | Author: Anthony Sottile (Anthony Sottile) * | Date: 2020-06-29 14:56 | |
I package pythons for ubuntu: https://github.com/deadsnakes/python3.9-nightly/actions/runs/151286686 https://github.com/deadsnakes/python3.10-nightly/actions/runs/151287821 |
|||
msg372589 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-29 15:04 | |
If Python is packaged with **system** libmpdec, you can only use the official Ubuntu Python/libmpdec version combination. Which are packaged by Matthias Klose, who is on the CC list here. Otherwise, why use the system libmpdec at all and not the version shipped with Python? If I install into a venv, I also don't use the system libmpdec. |
|||
msg372591 - (view) | Author: Anthony Sottile (Anthony Sottile) * | Date: 2020-06-29 15:12 | |
> Otherwise, why use the system libmpdec at all and not the version shipped with Python? the packages are faithful reproductions of upstream packages, deviating from those introduces surprises for downstreams > If I install into a venv, I also don't use the system libmpdec. that's simply not true: $ python3.9 -m venv vvv $ vvv/bin/python -c 'import _decimal, subprocess; subprocess.check_call(("ldd", _decimal.__file__))' linux-vdso.so.1 (0x00007fff429ec000) libmpdec.so.2 => /lib/x86_64-linux-gnu/libmpdec.so.2 (0x00007fcaeae03000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcaeade0000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcaeabee000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcaeaa9f000) /lib64/ld-linux-x86-64.so.2 (0x00007fcaeae7f000) |
|||
msg372593 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-29 15:22 | |
You are talking to the author of libmpdec *and* the _decimal module. Perhaps this problem has occurred to me, too: $ diff -ur mpdecimal-2.5.0/libmpdec cpython-commit/Modules/_decimal/libmpdec/ Only in mpdecimal-2.5.0/libmpdec: .objs Only in mpdecimal-2.5.0/libmpdec: Makefile.in Only in mpdecimal-2.5.0/libmpdec: Makefile.vc diff -ur mpdecimal-2.5.0/libmpdec/README.txt cpython-commit/Modules/_decimal/libmpdec/README.txt --- mpdecimal-2.5.0/libmpdec/README.txt 2020-06-27 21:41:49.000000000 +0200 +++ cpython-commit/Modules/_decimal/libmpdec/README.txt 2020-06-29 13:46:45.379299458 +0200 @@ -8,6 +8,9 @@ Mike Cowlishaw/IBM's General Decimal Arithmetic Specification. +Files required for the Python _decimal module +============================================= + Core files for small and medium precision arithmetic ---------------------------------------------------- Only in mpdecimal-2.5.0/libmpdec: bench.c Only in mpdecimal-2.5.0/libmpdec: bench_full.c Only in mpdecimal-2.5.0/libmpdec: examples Only in cpython-commit/Modules/_decimal/libmpdec/: mpdecimal.h Only in mpdecimal-2.5.0/libmpdec: mpdecimal.h.in Only in mpdecimal-2.5.0/libmpdec: mpdecimal32vc.h Only in mpdecimal-2.5.0/libmpdec: mpdecimal64vc.h Only in mpdecimal-2.5.0/libmpdec: mpsignal.c You are the one here who wants to ship a non-recommended libmpdec version with Python-3.9. |
|||
msg372597 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-29 16:05 | |
This is no release blocker. Version 2.5.0 has been in 3.9 for a long time, and people should use the correct version. |
|||
msg372598 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-29 16:07 | |
--with-system-libmpdec is a **long term** tool for distributions. Pinning the version number ensures that they use the correct version. |
|||
msg372608 - (view) | Author: Łukasz Langa (lukasz.langa) * ![]() |
Date: 2020-06-29 17:51 | |
Stefan brought libmpdec-2.5.0 to 3.9 shortly before Beta 2. Due to us being busy with the importlib fiasco, this went under our radar. It shouldn't have. It's a large chunk of refactored code merged without review after the beta freeze. Betas aren't for changing style guides and language standards, etc. etc. Sadly, given that this already got released as part of Beta 2 and Beta 3 shortly after, I think at this point it's pointless to revert it. And the new PR simply requires a shared version to match the one that we are bundling now in sources, reverting just this one is out of the question. > Or is this CoC bait again? Stefan, please, don't be like that. What purpose does this serve? Anthony noted a new failure related to your unreviewed and under-documented commit. You slipped in libmpdec-2.5.0 during the beta freeze without any discussion. It catches up to you right now. No reason to shoot the messenger. |
|||
msg372609 - (view) | Author: Anthony Sottile (Anthony Sottile) * | Date: 2020-06-29 18:00 | |
Łukasz: what would you recommend for downstream packagers? I have essentially two options (assuming this isn't reverted in cpython master which I believe makes the most sense since cpython still works fine with older libmpdec): - revert this individual commit as a patch - fork further from debian's packaging and use the vendored libmpdec (this potentially carries other negative side-effects since it makes the packages unlike upstream's -- and potentially susceptible to vendor/security drift since we don't carry patches for vendored components (but would get them from system libmpdec)) I'd rather not carry that patch indefinitely if possible -- especially when this cannot be built in a compatible way on software that's a mere 2 months old (ubuntu 20.04). For similar libraries (ssl, ffi, etc.) this would be a very major break in building. |
|||
msg372613 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-29 18:19 | |
> Anthony noted a new failure related to your unreviewed and under-documented commit. He claimed a failure in Ubuntu (in a manner that I took as petulant), which isn't the case. It is a failure in a custom Ubuntu distro that uses --with-system-libmpdec in an unintended way. > You slipped in libmpdec-2.5.0 during the beta freeze without any discussion. I did not slip it in at all. You were on the nosy list from the very start of this issue, and so was Matthias. > It catches up to you right now. No reason to shoot the messenger. It catches up to people who use --with-system-libmpdec in an unintended manner. It is intended for a scenario like merging Python 3.9 into Sid, then testing, then stable. |
|||
msg372614 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-29 18:21 | |
> unreviewed and under-documented commit. libmpdec has been one of the few zero fault areas of Python. Please stop spreading FUD. |
|||
msg372615 - (view) | Author: Christian Heimes (christian.heimes) * ![]() |
Date: 2020-06-29 18:27 | |
> > unreviewed and under-documented commit. > > libmpdec has been one of the few zero fault areas of Python. > Please stop spreading FUD. This has nothing to do with your excellent fault rate (lack of any issues). The commit had no Misc/NEWS.d blurb and therefore was undocumented. I have opened bpo-41161 to address the issue. There was also no approval or review from another core dev on GH-20652. |
|||
msg372616 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-29 18:35 | |
> This has nothing to do with your excellent fault rate (lack of any issues). I sounds like that though for random people who read this issue and think that Łukasz is the grand release manager who puts a person in his place. That was incredibly inappropriate. libmpdec has **found** issues in decNumber that were acknowledged by Cowlishaw. If one's reputation is questioned every time one opens an issue here (notably by people who are not subject experts at all), then I *have* to respond in no uncertain terms. |
|||
msg372617 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-29 18:37 | |
> I have opened bpo-41161 to address the issue. Thanks, that is a more considerate approach, I'll add the note! |
|||
msg372618 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-29 19:08 | |
Also note that people did not react at all to the fact that coroutine storage was not thread safe across several releases. No one asked for News entry. But "breaking" a fringe distro seems to be a major disaster. |
|||
msg372620 - (view) | Author: Christian Heimes (christian.heimes) * ![]() |
Date: 2020-06-29 19:31 | |
> Also note that people did not react at all to the fact that > coroutine storage was not thread safe across several releases. That's whataboutism. > No one asked for News entry. The bot did ask you to add a news entry. According to https://devguide.python.org/triaging/#github-labels-for-prs the "skip news" label should only be used in trivial cases like fixing a typo. > But "breaking" a fringe distro seems to be a major disaster. I find your choice of words hurtful and it demeaning. Other core developer go through great length to keep backwards compatibility for older or less commonly used systems. In bpo-40810 Erlend researched SQLite version numbers before support for support for ancient SQLite was dropped. I'm spending a considerable effort to keep Python working with unsupported but still widely used OpenSSL and LibreSSL versions. |
|||
msg372623 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-29 19:40 | |
> The bot did ask you to add a news entry. And I deliberately did not, out of politeness. Two release managers were added and they did not ask. > Other core developer go through great length to keep backwards compatibility for older or less commonly used systems. Ok, I take that back then. I go through great lengths to keep libmpdec and Python in sync. |
|||
msg372626 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-29 20:16 | |
Major correction: Victor *did* ask for a news entry, but otherwise I would not have added one. |
|||
msg372629 - (view) | Author: Łukasz Langa (lukasz.langa) * ![]() |
Date: 2020-06-29 20:55 | |
> That was incredibly inappropriate. You'll have to let the readers of this thread judge that for themselves. You're right that you added me to nosy. I missed it as I've been busy with other things at the time. You let *3 hours* pass between opening this issue and merging the original backport PR into Python 3.9. Python users and fellow core developers value your contributions. I personally could not have done them myself. We only ask you to try to play along. For example by letting other core devs stamp non-trivial non-bugfix contributions late in the release cycle. Let's not make this unnecessarily hostile. |
|||
msg372632 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-29 21:01 | |
> You'll have to let the readers of this thread judge that for themselves. Ask Cowlishaw or the mpfr developers to read this thread. As for politeness, msg372581 was entirely polite and directly answered by an inappropriate and petulant msg372584. This no way to talk to an experienced core developer. |
|||
msg372635 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-06-29 21:14 | |
Since this is an ongoing problem: When I submitted the decNumber patches to Cowlishaw, he asked me if I would be interested in maintaining decNumber. I declined at the time due to time constraints. Had I accepted, I'd control 2/3 of the decimal market now, the Intel library being the remaining 1/3. I'm unwilling to justify my competence to random bug reporters in this forum, especially when I'm nice to them initially. |
|||
msg372917 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-07-03 11:39 | |
It is instructive that ArchLinux quietly and professionally packaged mpdecimal-2.5.0 hours after the release: https://www.archlinux.org/packages/?sort=&q=mpdecimal&maintainer=&flagged= This is in stark contrast with Python-dev, where a maintainer of an *experimental* *nightly* Ubuntu package that abuses --with-system-libmpdec claimed that "Ubuntu builds are broken". And a release manager who has no libmpdec expertise or authority took the side of the "bug" reporter without much thought. I presume that ArchLinux still follows the "shut up and hack" philosophy. |
|||
msg372918 - (view) | Author: Christian Heimes (christian.heimes) * ![]() |
Date: 2020-07-03 11:57 | |
As soon as a Python release enters beta phase, all dependencies are locked. Since Python 3.9.0-b1 supported --with-system-libmpdec with libmpdec-2.4.2, all future releases of 3.9.0 until EOL of 3.9 branch have to support 2.4.2. Since 3.9.0-b3 does not work with libmpdec-2.4.2 you have introduced a regression. It's always possible to drop support for older versions of a dependency. A developer has to make a formal case for deprecation, provide technical arguments why an old version of a dependency cannot be support without great effort, and get written permission from the release manager. It's the release manager's discretion what they consider a regression. It's well in their power and authority to refuse and even revert a change if a release manager considers a change a regression. A developer can call upon the steering council to mediate. Any kind of personal attacks on community members, core developers, or release manage is not acceptable way to resolve a dispute. |
|||
msg372919 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-07-03 12:02 | |
I was the one being attacked in this issue, while releasing a zero fault library whose release procedures resemble those found in avionics software. |
|||
msg372920 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-07-03 12:05 | |
Christian, you are also completely ignoring the original attack of Anthony, so you are biased and there is no point continuing. |
|||
msg372921 - (view) | Author: Christian Heimes (christian.heimes) * ![]() |
Date: 2020-07-03 12:10 | |
> I was the one being attacked in this issue, while releasing a zero fault library whose release procedures resemble those found in avionics software. I have reported this incident to the steering council and Code of Conduct working group. I let them decide who attacked whom. In the mean time may I request that you follow our protocol for code review and backwards incompatible changes? There is no "Quod licet Iovi, non licet bovi" in Python (except that RM is close to the power of Zeus). Everybody has to follow the rules no matter who you are. |
|||
msg372922 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-07-03 12:14 | |
I was accused of breaking the release, which is false. It is outside of a release manager's authority to claim that an *experimental* and *nightly* build that uses a flag in an unintended manner needs counts as breakage. |
|||
msg372924 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-07-03 12:24 | |
Raymond, Mark, Antoine: If you think this should be reverted, I'll revert it. |
|||
msg372926 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-07-03 12:26 | |
> backwards incompatible changes. It is not a backwards incompatible change. Slamming a 3.9 into a nightly build has never been supported. |
|||
msg372928 - (view) | Author: Matthias Klose (doko) * ![]() |
Date: 2020-07-03 12:34 | |
I'm +-0 on if that should be integrated into 3.9. Only a few people are using --with-system-libmpdec. However the way that mpdecimal 2.4 and 2.5 are released, they are not usable for Debian or Ubuntu for the transition from 3.8 to 3.9. For that, both 3.8 and 3.9 have to be available on the systems for the transition period, and that's just not possible without mpdecimal changing it's soname, or building one Python version with the internal libmpdec. |
|||
msg372930 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-07-03 12:44 | |
Since this issue has been brought to the attention of the CoC committee. Here is how *I* report issues: https://bugs.python.org/issue40223#msg372578 https://bugs.python.org/issue40223#msg372637 https://github.com/google/sanitizers/issues/1257 Note that I do not go straight into accusing people, especially in uncertain cases. I never have any problems with my bug reports. |
|||
msg372931 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-07-03 13:06 | |
Matthias, to tell the truth, I was never sure about the soname. I read this: https://www.debian.org/doc/debian-policy/ch-sharedlibs.html """ The SONAME and binary package name need not, and indeed normally should not, change if new interfaces are added but none are removed or changed, since this will not break binaries linked against the old shared library. Correct versioning of dependencies on the newer shared library by binaries that use the new interfaces is handled via the symbols or shlibs system (see Dependencies between the library and other packages). """ I took the interface to mean ABI, which did not change. Also this: """Every time the shared library ABI changes in a way that may break binaries linked against older versions of the shared library, the SONAME of the library and the corresponding name for the binary package containing the runtime shared library should change. Normally, this means the SONAME should change any time an interface is removed from the shared library or the signature of an interface (the number of parameters or the types of parameters that it takes, for example) is changed. This practice is vital to allowing clean upgrades from older versions of the package and clean transitions between the old ABI and new ABI without having to upgrade every affected package simultaneously. """ So I left the soname at 2. |
|||
msg372932 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-07-03 13:19 | |
> In the mean time may I request that you follow our protocol for code review. Ah, who reviews libffi? It is just updated. Not counting the thousands of other cases people commit unreviewed, like in changing the C-API. And no, Christian, that isn't "whataboutism", that is comparative analysis. |
|||
msg372935 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-07-03 14:31 | |
> both 3.8 and 3.9 have to be available on the systems for the transition period. If sonames can be incremented for libraries even if they are ABI compatible, how about using up as many as you need for the Debian package? Next time when I release mpdecimal, I'll ask you about the highest version that's in use at Debian and increment it by one. |
|||
msg372943 - (view) | Author: Łukasz Langa (lukasz.langa) * ![]() |
Date: 2020-07-03 16:43 | |
> And a release manager who has no libmpdec expertise or authority took the side of the "bug" reporter without much thought. What is this elusive "authority" you keep bringing up? > Note that I do not go straight into accusing people, especially in uncertain cases. Neither did Anthony. He observed breakage in his builds and reported it. He noted that the change happened during the beta freeze which is documented to only allow bug fixes: https://devguide.python.org/devcycle/#beta Anthony's only fault here was depending on the system libmpdec which you claim is invalid use. As he explained, he did this to mirror behavior of the official Python packages. And it worked for the first three betas. His surprise breakage report wasn't unreasonable, let alone "petulant". Compare with your own responses which to many of us read unnecessarily defensive. Nobody is challenging your competence. The problem is entirely with the timing and making non-bugfix changes during the beta phase. Bringing up credentials, track records, or listing professional networks doesn't change that. Finally, while Raymond and Antoine are welcome to voice their opinions on the matter, your change is landing in 3.9.0b4 which I'm about to announce. So we won't be reverting it. In the future let's make sure we stick to the release calendar to avoid similar heat. If we need to bend a rule or two, that's okay, it happens. Making a fellow core developer stamp your change in such case will increase visibility, and is a good practice regardless, required for example in avionics software. |
|||
msg372944 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-07-03 16:51 | |
Łukasz, which one is nicer? > reverting this patch passes all the tests, what's the motivation and why were there no code reviews for this? or: > Yeah, I already felt a bit guilty about adding you -- it could be a compiler bug or an actual overflow. My bet is also that the reordering exposes an existing overflow. The reordering itself certainly looks correct to me. I'm always astonished that some of the CoC proponents (and reporters) have little idea about actual politeness, a fact which is a main source of friction. Hint: I'd prefer actual politeness. |
|||
msg372945 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-07-03 16:52 | |
Finally, about the Debian issue, of course you could also link 3.8 against the static lib. |
|||
msg372946 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-07-03 17:27 | |
> Finally, while Raymond and Antoine are welcome to voice their opinions on the matter, your change is landing in 3.9.0b4 which I'm about to announce. So we won't be reverting it. In the future let's make sure we stick to the release calendar to avoid similar heat. If we need to bend a rule or two, that's okay, it happens. Making a fellow core developer stamp your change in such case will increase visibility, and is a good practice regardless, required for example in avionics software. I've added Antoine, Mark and Raymond because they know the history of libmpdec, unlike people who came later. Like for libffi, it is not feasible to get review, because there is no time. This would effectively mean that nothing ever changes. The alternative is to trust that the zero fault situation continues. Or download *one* of the gigantic test suites, which I have laboriously updated for this release: http://www.bytereef.org/software/mpdecimal/releases/mpdecimal-testit-2.5.0.tar.gz The second one isn't even published. So again, just clamoring for review (which often is just rubber stamping) leads to nothing but scoring a few cheap points. |
|||
msg372947 - (view) | Author: Christian Heimes (christian.heimes) * ![]() |
Date: 2020-07-03 17:43 | |
Are you saying that you are not follow advises and guidelines of the developer guide? |
|||
msg372948 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-07-03 17:46 | |
How witty! |
|||
msg373001 - (view) | Author: Antoine Pitrou (pitrou) * ![]() |
Date: 2020-07-04 23:01 | |
Hmm, I'm only taking notice of this comment thread now. (sorry, but due to spam filtering issues I only receive bpo e-mail notifications intermittently... and that's despite having tried two separate e-mail providers which otherwise give me no problems :-/) In any case, I would have had a hard time giving a competent opinion on this issue. But I'm a bit saddened by how heated the discussion went. Hopefully this is all over. |
|||
msg373003 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-07-04 23:44 | |
> In any case, I would have had a hard time giving a competent opinion on this issue. Essentially it's a really simple Linux packaging issue for the external libmpdec. To have the exact same behavior for the external libmpdec as for the included libmpdec, packagers must use: 3.8 <--> 2.4.2 3.9 <--> 2.5.0 ArchLinux had no problems. Debian, and by extension Ubuntu, requires 3.8 and 3.9 to be on the same system during a transitional period, as pointed out in msg372928 (which is really the most important message of this whole thread). The commit that pinned _decimal to libmpdec version 2.5.0 broke this use case, but there are workarounds. My stance is that it is important that libmpdec is pinned so distros don't use a divergent version. Since there are multiple mitigations for Debian, I don't feel particularly guilty. Review of the commit that pinned 2.5.0 would have led to the exact same outcome: I would have pointed that out on GitHub. Note that with the Debian scheme there is never a good time to update libmpdec, regardless of the release cycle. |
|||
msg373005 - (view) | Author: Antoine Pitrou (pitrou) * ![]() |
Date: 2020-07-05 00:13 | |
Thanks for the clarification. I agree this does not seem to be a very big deal, if slightly annoying for the packager who will have to deal with it. |
|||
msg373021 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-07-05 09:26 | |
Thanks for taking a look, Antoine. IIRC, the version pinning already accommodates Debian: #if !defined(MPD_VERSION_HEX) || MPD_VERSION_HEX < 0x02050000 #error "libmpdec version >= 2.5.0 required" #endif In the first libmpdec versions, I had a stricter equality check, and I *think* (but I'm not 100% sure) that it was Matthias who requested the relaxation. Based on that, perhaps Debian should just use 2.5.0 for both 3.8 and 3.9 in the transition period. I'm more comfortable with 3.8 using 2.5.0 than 3.9 using 2.4.2. |
|||
msg373093 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-07-06 11:10 | |
As noted in the first message of this thread, the sqrt-max-prec feature (requested by Mark and Tim) was already in 3.9 long before the beta freeze. I'm not sure why this is not clear from the original message. That fix is safe for Python, but not for the standalone libmpdec. The standalone libmpdec had to be updated, and was updated according to the Debian-friendly way requested by Matthias himself. Note that a pinning issue in another area of Python has surfaced in the last 24 hours. I wonder if the reaction will be a strong as here. |
|||
msg373094 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-07-06 11:18 | |
> The standalone libmpdec had to be updated, and was updated according to the Debian-friendly way requested by Matthias himself. Not updated, of course the sqrt-max-prec *had never been* in the standalone libmpdec, it is new in 2.5.0. |
|||
msg373096 - (view) | Author: Stefan Krah (skrah) * ![]() |
Date: 2020-07-06 11:31 | |
More than that, I had *promised* Matthias privately to release a new libmpdec for the sqrt-max-prec feature a couple of months ago. I request that further packaging issues will be dealt with primarily by Matthias and myself. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:59:32 | admin | set | github: 85051 |
2020-07-06 11:31:49 | skrah | set | messages: + msg373096 |
2020-07-06 11:28:25 | christian.heimes | set | nosy:
- christian.heimes |
2020-07-06 11:18:13 | skrah | set | messages: + msg373094 |
2020-07-06 11:10:49 | skrah | set | messages: + msg373093 |
2020-07-05 09:26:19 | skrah | set | messages: + msg373021 |
2020-07-05 00:13:46 | pitrou | set | messages: + msg373005 |
2020-07-04 23:44:06 | skrah | set | messages: + msg373003 |
2020-07-04 23:01:16 | pitrou | set | messages: + msg373001 |
2020-07-03 17:46:22 | skrah | set | status: open -> closed type: behavior messages: + msg372948 resolution: fixed stage: patch review -> resolved |
2020-07-03 17:43:50 | christian.heimes | set | messages: + msg372947 |
2020-07-03 17:27:51 | skrah | set | messages: + msg372946 |
2020-07-03 16:52:07 | skrah | set | messages: + msg372945 |
2020-07-03 16:51:00 | skrah | set | messages: + msg372944 |
2020-07-03 16:43:57 | lukasz.langa | set | messages: + msg372943 |
2020-07-03 14:31:35 | skrah | set | messages: + msg372935 |
2020-07-03 13:19:36 | skrah | set | messages: + msg372932 |
2020-07-03 13:06:51 | skrah | set | messages: + msg372931 |
2020-07-03 12:44:20 | skrah | set | messages: + msg372930 |
2020-07-03 12:34:59 | doko | set | messages: + msg372928 |
2020-07-03 12:26:45 | skrah | set | messages: + msg372926 |
2020-07-03 12:24:35 | skrah | set | nosy:
+ rhettinger, mark.dickinson, pitrou messages: + msg372924 |
2020-07-03 12:14:28 | skrah | set | messages: + msg372922 |
2020-07-03 12:10:12 | christian.heimes | set | status: closed -> open type: behavior -> (no value) messages: + msg372921 resolution: fixed -> (no value) stage: resolved -> patch review |
2020-07-03 12:08:05 | skrah | set | status: open -> closed type: behavior resolution: fixed components: + Extension Modules stage: patch review -> resolved |
2020-07-03 12:05:02 | skrah | set | messages: + msg372920 |
2020-07-03 12:02:03 | skrah | set | messages: + msg372919 |
2020-07-03 11:57:03 | christian.heimes | set | messages: + msg372918 |
2020-07-03 11:39:32 | skrah | set | messages: + msg372917 |
2020-06-29 21:14:03 | skrah | set | messages: + msg372635 |
2020-06-29 21:01:50 | skrah | set | messages: + msg372632 |
2020-06-29 20:55:00 | lukasz.langa | set | messages: + msg372629 |
2020-06-29 20:16:03 | skrah | set | messages: + msg372626 |
2020-06-29 19:40:33 | skrah | set | messages: + msg372623 |
2020-06-29 19:31:14 | christian.heimes | set | messages: + msg372620 |
2020-06-29 19:08:46 | skrah | set | messages: + msg372618 |
2020-06-29 18:37:33 | skrah | set | messages: + msg372617 |
2020-06-29 18:35:29 | skrah | set | messages: + msg372616 |
2020-06-29 18:27:06 | christian.heimes | set | messages: + msg372615 |
2020-06-29 18:21:16 | skrah | set | messages: + msg372614 |
2020-06-29 18:19:20 | skrah | set | messages: + msg372613 |
2020-06-29 18:00:36 | Anthony Sottile | set | messages: + msg372609 |
2020-06-29 17:51:24 | lukasz.langa | set | messages: + msg372608 |
2020-06-29 16:07:37 | skrah | set | messages: + msg372598 |
2020-06-29 16:05:17 | skrah | set | priority: release blocker -> normal messages: + msg372597 |
2020-06-29 16:00:50 | christian.heimes | set | priority: normal -> release blocker nosy: + christian.heimes |
2020-06-29 15:22:21 | skrah | set | messages: + msg372593 |
2020-06-29 15:12:04 | Anthony Sottile | set | messages: + msg372591 |
2020-06-29 15:04:39 | skrah | set | messages: + msg372589 |
2020-06-29 14:56:31 | Anthony Sottile | set | messages: + msg372587 |
2020-06-29 14:52:59 | skrah | set | messages: + msg372586 |
2020-06-29 14:52:20 | skrah | set | messages: + msg372585 |
2020-06-29 14:51:35 | Anthony Sottile | set | messages: + msg372584 |
2020-06-29 14:48:33 | skrah | set | messages: + msg372581 |
2020-06-29 14:41:28 | Anthony Sottile | set | messages: + msg372580 |
2020-06-29 14:40:37 | Anthony Sottile | set | nosy:
+ Anthony Sottile messages: + msg372579 |
2020-06-28 21:14:26 | skrah | set | messages: + msg372534 |
2020-06-28 20:25:05 | skrah | set | messages: + msg372532 |
2020-06-28 20:03:15 | miss-islington | set | pull_requests: + pull_request20357 |
2020-06-28 20:01:10 | skrah | set | messages: + msg372530 |
2020-06-28 19:37:54 | skrah | set | pull_requests: + pull_request20355 |
2020-06-05 19:41:25 | skrah | set | messages: + msg370780 |
2020-06-05 17:47:25 | skrah | set | versions: + Python 3.10 |
2020-06-05 17:43:52 | miss-islington | set | nosy:
+ miss-islington pull_requests: + pull_request19874 |
2020-06-05 17:43:08 | skrah | set | messages: + msg370774 |
2020-06-05 16:32:01 | skrah | set | keywords:
+ patch stage: patch review pull_requests: + pull_request19872 |
2020-06-05 16:29:23 | skrah | create |