@weblate pushed 5 commits.
d84e86a4699929db5c74428c82781425d695da21 Translated using Weblate (Finnish)
f89d24372a743cfef2ab1f301a2ffa8e13afe025 Translated using Weblate (Korean)
a5cb49cc173efb64710c7887227e524e06f64497 Translated using Weblate (French)
d0a616a3810fdffb2027383d0edd629f6e4dbdb8
@DemiMarie pushed 1 commit.
77488e885aca87492194959296baaca66f1a3c7c More const correctness
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1612/files/4a6084d358c92104c72c9f27ed8d644f2c442c1f..77488e885
See individual commit messages for details.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1612
-- Commit Summary --
* Remove dead code
* A signature is not a key
* Reject unimplemented critical PGP packets
* Reset th
The current argument string mentions an optional integer argument, which does
not exist. This is probably a copy & paste from `rpmarchive_readto`.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1611
-- Commit Summary --
*
This fixes a double-free bug in the OpenSSL backend. This bug is not
considered exploitable as it cannot be reliably triggered by an attacker. It
also deletes a bunch of cruft.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull
> (that stuff really needs proper docs, sigh...)
Is it intended to describe mechanism or policy? It seems that these two are
mixed through the whole code base in an obfuscating and weird way. For example,
what's expected to happen if someone try --nosignature install of a package
build with `%_
The extra newlines are indeed there, try eg "%trigger" line to trigger various
errors, but probably varies from one error to another due to all sorts of
internal wacko.
The path of less changes may be instead eliminating the newlines as we parse,
but there could be dragons in that direction too
OK, turns out the other `parse*.c` files also emit such messages.
So my next plans are:
1. Check if the extra newlines are also present with the other messages that
format a spec line (outside of `parseSpec.c`)
2. See if we could have a specialized logging function for spec parsing
errors/warni
@DemiMarie requested changes on this pull request.
Avoid using “whitelist” and properly quote variables containing special
characters
> +cat > "$BUILDINFO" < "$BUILDINFO"
```
This ensures that we properly abort on errors.
> +rpm -qa --queryformat '%{epoch}:%{name}-%{version}-%{release}.%{arch}
> On a related note, we could use a dedicated spec error reporting function.
> Our error messages are _all over_ the place in terms of formatting and style.
> If there was one place to fixup such things...
>
> (and here we have another seemingly trivial ting threatening to quickly
> escalate ou
I should've mentioned in the commit message that this wasn't intended as a 100%
fix of all the messages that print a spec line. Although I did, of course, look
through all of them in `parseSpec.c`, so that file is covered.
--
You are receiving this because you are subscribed to this thread.
Rep
On a related note, we could use a dedicated spec error reporting function. Our
error messages are *all over* the place in terms of formatting and style. If
there was one place to fixup such things...
(and here we have another seemingly trivial ting threatening to quickly
escalate out of orbit
Another thing is that there are *lot* more error messages referring to spec
lines than the ones updated here. So something is not quite adding up.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-softwa
Looking again, it seems like we already do store the length, in `ofi->readPtr`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1591#issuecomment-809345285__
> FYI, a PR with failed checks will generally not get much attention. This
> looks like it just needs some test output updated to the new reality. That
> case is actually a good argument for the change, the newline(s) make no sense
> at all.
Yeah, I'll fix that.
> I'm inclined to think the for
FYI, a PR with failed checks will generally not get much attention. This looks
like it just needs some test output updated to the new reality. That case is
actually a good argument for the change, the newline(s) make no sense at all.
I'm inclined to think the format string should be in charge of
> So start by explaining what problem you're trying to solve, and not how other
> people might've chosen to solve it.
The purpose of having an automatically generated subpackage `buildinfo` is to
have an exact description of the build environment used to obtain RPMs from a
spec file.
Having t
If you want feedback here, you should explain what it is and why we should
care. Outside references are okay for additional background, but the what it
does and why (as in rationale for the whole) needs to be explained right here
so that it can be discussed.
--
You are receiving this because y
Keep them open, let's close them when we reopen them for the new repo.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-809296777___
@hroncok , any preference wrt this and the other related PR's - should we wait
until you've imported things, or just go ahead and close to signal end of
business? Either way is fine with me.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or vie
I'll import stuff later this week.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-809292477___
Rpm-maint maili
Okay, lang-rpm-packaging it is, end of bikeshed :sweat_smile:
https://github.com/rpm-software-management/python-rpm-packaging created,
@hroncok invited to admin it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://gi
Looking for some precedent...
In Fedora, *all* such packages are *lang*-prefixed, not rpm. In Debian, these
things appear to be called "lang-debian". Note the order again. I'm not sure
about Suse, but it's *not* rpm-prefixed.
I'd think that's a pretty strong hint that lang-prefix is what the
"
`rpm-python-packaging` maybe? It actually describes what it is and the rpm
prefix indicates that it's about the rpm ecosystem...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/
See
https://github.com/rpm-software-management/rpm/blob/375bac6ffbc02d96aea0aaa1a8d39a3e53135430/macros.in#L672
(that stuff really needs proper docs, sigh...)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.c
Another idea: "rpm-build-python" etc.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-809270079___
Rpm-maint ma
> There's already an enforcing mode for signature checking at install time
Is it controlled by the command-line option? I've found only --nodigest and
--nosignature, both meaning an opposite to what we're talking about here.
--
You are receiving this because you are subscribed to this thread.
We'll be living with these names for a long time, so bear a little more
bikeshedding...
@ffesti came up with a better suggestion: "packaging" which I find worlds more
descriptive than "ecosystem" or "extras".
The order of words remains a question: "python-rpm-packaging" or
"rpm-packaging-pytho
Also, it would be nice to mention in the commit message why the type check is
being changed. In the case of `rpmtsObject_Check`, it's to allow for passing an
`rpm.TransactionSet` instance to `rpm.spec()` which is not of the built-in
`rpmts_Type` class that we define in C, but rather of a subclas
The python bindings as a whole are not broken, so you can't fix them. This is a
good example of a bad commit summary ;)
The o -> O change is fine of course, it's just unrelated to the object check
change so should be in a commit of its own. As for the object check change,
it's probably ok, but
There's already an enforcing mode for signature checking at install time, and
that's a point where revocation and expiry checks would seem fairly obvious.
The open questions come after that.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or vie
> we decide to have an rpm-ecosystem repository
We have rpm-extras already, but that's clearly not going anywhere. Which likely
suggests the approach there isn't right. Which reminds me, I think the initial
idea was to build around rpm-extras, so this would be rpm-extras-python. Which
is as g
Looks like nobody's taken out the garbage for a while in there :sweat_smile:
Thanks for the patch!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1609#issuecomment-809109
Merged #1609 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1609#event-4519525026___
Rpm-maint mailing list
Rpm-mai
Closed #1608.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1608#event-4519498248___
Rpm-maint mailing list
Rpm-maint@lists.rpm
@DemiMarie , I've said this quite a few times now: these kind of patches are
not welcome, please let it be now.
There will be further work to do in the header code of course, but this isn't
the time, and this isn't the how.
--
You are receiving this because you are subscribed to this thread.
R
NAK.
I absolutely will not get into this sort of hair-splitting over what is just
your average-if-old codebase of C.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1599#i
Closed #1599.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1599#event-4519474986___
Rpm-maint mailing list
Rpm-maint@lists.rpm
38 matches
Mail list logo
