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:
```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:
__
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 us
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
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/
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/277
@pmatilai pushed 5 commits.
6805bd7fded2d83369d9317c7fdeb1063f2d1af4 Use rpmSpecGetSection() internally
where appropriate
40c0721f8055378bdc3461b155c97438945bc498 Store spec section string buffers as
an array
ddb1c4bdf23ab1074049d827990170074e02901f Implement declarative buildsystem
support
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
@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: __
@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..c4be21841fbdde56f647247758f
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 mail
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#issuecomm
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
13 matches
Mail list logo
