Re: [Rpm-maint] [rpm-software-management/rpm] Always use long filesizes on v6 (80a238d)
Technically `totalFileSize <= UINT32_MAX` ought to be OK? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/commit/80a238d01d9587a53983fc090ee5f2827b8725f5#r136850899 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] First commit of rpm v6: make sha1 and md5 inclusion conditional (83c87b1)
```suggest # Which rpm format to generate (4 or 6) ``` -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/commit/83c87b1c63f6f733971675943a2278549ad07a0a#r136849221 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] check for rpmlib version (Issue #2840)
Is there a way to check at compile time for the rpmlib version? In this particular case I want to use the enum value `RPMTRANS_FLAG_NODB` of `enum rpmtransFlags_e` in `include/rpm/rpmts.h`, but stay compatible with older versions that do not have this implemented. Since it's an enum, I cannot use `#ifdef`. So alternatively I thought I can use a macro that lets me check the version of rpmlib. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2840 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Support rpmver-py comparison operator inheritance (PR #2839)
Hi again, I'm opening this PR due to the main issue I found when writing a `rpm.ver` subclass in python: Trying to compare different subclass instances would raise a `NotImplementedError` while it was supported on base class instances. The reason behind that was that the `verObject_Check` macro checked for operand types to be the same as `rpm.ver`. A way to overcome that, is checking their types are subclasses of `rpm.ver`, or simply calling `PyObject_TypeCheck`. I'm proposing this patch only targeting the `rpm.ver` type as I'm not sure if such behavior was intended in the first place. In fact, most of the python bindings seem to follow the same type check pattern. Moreover, although not directly related to `rpm.ver` (but `rpm.ts`), I found a similar proposal was made but not merged in #1600. In case you consider this to be valid proposal and that it could be helpful for other python bindings, I could try to provide a more general patch as well. Thank you for the attention once again! You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2839 -- Commit Summary -- * Support rpmver-py comparison operator inheritance -- File Changes -- M python/rpmver-py.h (2) M tests/rpmpython.at (27) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2839.patch https://github.com/rpm-software-management/rpm/pull/2839.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2839 You are receiving this because you are subscribed to this thread. Message ID:___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Enhance the recoverability and location of database exceptions (Issue #2828)
In addition, can we provide a command or script to quickly determine whether the database is damaged? At present, there seems to be no concise way to judge, generally by `rpm -qa` to roughly judge. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2828#issuecomment-1887001193 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Declarative buildsystem, take II (PR #2774)
The last commit to not ship our example buildsystem macros could/should be merged into the "Implement..." commit instead, just made it separate to make it easy to back out if necessary. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1886913341 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Declarative buildsystem, take II (PR #2774)
@pmatilai pushed 5 commits. 6805bd7fded2d83369d9317c7fdeb1063f2d1af4 Use rpmSpecGetSection() internally where appropriate 40c0721f8055378bdc3461b155c97438945bc498 Store spec section string buffers as an array ddb1c4bdf23ab1074049d827990170074e02901f Implement declarative buildsystem support 8fed2b58e16f34d3127fca56c7b156873b759a17 Define a global %clean default, reuse for the non-buildsystem, case too 82bab4aa3db71d9945da6ea102b6f2b5553d6e36 Our buildsystem macros are just examples, don't actually ship them -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774/files/9382f3211a202c4e0ebb0e2886d91a5995485270..82bab4aa3db71d9945da6ea102b6f2b5553d6e36 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Return false when comparing different python objects holding the same version tag (PR #2838)
Yeah, I'd have assumed the same thing actually, that's why it was weird to me to see `!=` wasn't acting as a complement of `==` :sweat_smile:(now I've just found why that was intended [0]). I guess that it just implements a `is not` by default? I'm not sure. No problem, thank you for the quick reply! [0] https://peps.python.org/pep-0207/#proposed-resolutions (point 3) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2838#issuecomment-1886833169 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Declarative buildsystem, take II (PR #2774)
@Conan-Kudo approved this pull request. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774#pullrequestreview-1815228582 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Declarative buildsystem, take II (PR #2774)
@pmatilai pushed 1 commit. c4be21841fbdde56f647247758f54e31eb99fc31 Define a global %clean default, reuse for the non-buildsystem, case too -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2774/files/0c9a45e301c222b41f4ec8f43b28d0e1d5b965d7..c4be21841fbdde56f647247758f54e31eb99fc31 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Return false when comparing different python objects holding the same version tag (PR #2838)
Merged #2838 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2838#event-11454466451 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Return false when comparing different python objects holding the same version tag (PR #2838)
Oh, nice catch. I guess I thought/assumed implementing EQ will do the right thing with NE too because .. well, it's just the opposite, right? Guess not. Thanks for the patch! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2838#issuecomment-1886790075 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Return false when comparing different python objects holding the same version tag (PR #2838)
Hello! While I was working on another issue, I found that the inequality operator of python `rpm.ver` objects would not work as I was expecting to. `!=` would always return `True` if the compared objects were not the actual same python object. That was leading to situations as ```python (v := rpm.ver('1.0')) != v# False, we are comparing the object with itself rpm.ver('1.0') != rpm.ver('1.0') # True, although they hold the same version tag string ``` I'm not sure whether that was the intended behavior or not. It was not quite what I expected when I tried applying the operator. I didn't research the topic really exhaustively, but I couldn't find related issues at least in the PRs of this repo. Anyway, this patch adds the `PY_NE` case to the `tp_richcompare` slot function and adds some extra checks to a related existing test. Thanks for the attention! :smile: cc: @luckyh You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2838 -- Commit Summary -- * Add rpmver-py inequality operator -- File Changes -- M python/rpmver-py.c (3) M tests/rpmpython.at (6) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2838.patch https://github.com/rpm-software-management/rpm/pull/2838.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2838 You are receiving this because you are subscribed to this thread. Message ID:___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint