We should export our Python module documentation to the web.
`pydoc -w rpm` gives you a starting point, it just needs prettying up some.
There must be a pre-existing solution to that...
Then it will become available on the web as you'd expect these days. Eventually
we'd want them in the referenc
What verification are you talking about, specifically? The term is overloaded
in multiple places around rpm...
If an unknown algorithm causes us to give an OK to an unverifiable signature
then we obviously do have a rather bug someplace.
--
Reply to this email directly or view it on GitHub:
ht
NAK, this is stuff we do NOT want to know about (but historically, know too
much).
An unsupported signature algorithm will cause signature checking to fail, and
that's all we care about.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3
You don't need that %quote macro at all:
```
rpm -D "name string-io" -D "string_io_prerelease .dev" --eval '%{sub
%{expand:%%?%{gsub %{name} - _}_prerelease} 2 -1}'
```
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3412#issuecomment-
No, please do not change this. `%{macro:something}` is a way to expand a macro
with exactly one argument. gsub needs more than one argument, thus the error.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3410#issuecomment-2446531693
Y
Hmm, I don't remember the : syntax being intentionally one argument only but
then it's been a while.
But in that case this is a documentation issue.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3410#issuecomment-2446549350
You are re
And don't apologize for spotting typos, there's nothing worse than a typo in a
commit message because you can't fix it afterwards and yep, it often makes
finding the thing you're looking for much more difficult.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-softwa
Argh, I didn't even realize there was a second instance :laughing:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3414#issuecomment-2446405076
You are receiving this because you are subscribed to this thread.
Message ID: ___
Merged #3414 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3414#event-15002638437
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mail
@JetXujing pushed 1 commit.
1f071c8f73006ce12d021f2e7062e4a1e504b2ad Check the validity of hash algo
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3416/files/75e64330aa964d145470e6e3b39d62ca6822..1f071c8f73006ce12d021f2e7062e4a1e504b2ad
You are receiving this bec
> I expected that the line Reading /var/tmp/rpm-tmp.bSC32X is not present,
> because I used -q option.
In rpmspec, -q means query, not quiet. rpmbuild is verbose by default, rpmspec
is not, it's just that the "Reading..." message was in the "wrong" level for
this purpose, in the original contex
I haven't had a chance to dig into that construct, it just looks so fishy that
my recommendation is simply: don't bother, use lua.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3411#discussioncomment-11097488
You are receiving th
> It would help to understand the actual use-case behind this.
This is the original macro:
https://src.fedoraproject.org/rpms/ruby/blob/05a6c9c8f3bbc26d12835736791431c74d07552d/f/macros.rubygems#_15
And here you can see its usage:
https://src.fedoraproject.org/rpms/ruby/blob/05a6c9c8f3bbc26d128
Dynamic spec parsing emits "Reading " messages to make it
clear something out of the ordinary is going on, but this is undesireable on
rpmspeq queries. Luckily there's a trivial solution: rpmbuild where you
want these messages runs in verbose mode by default whereas rpmspec does not.
So j
If an RPM package has been signed and the hash algorithm is not supported by
the current version, no error is reported during the verification of the RPM
package, and "$?" return 0. Fix this problem.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-softwar
You just need to escape the first % in the expand macro:
```
rpm -D "name string-io" -D "string_io_prerelease .dev" --eval
"%{expand:%%{?%{gsub %{name} - _}_prerelease}}"
.dev
```
Without the expand:
```
$ rpm -D "name string-io" -D "string_io_prerelease .dev" --eval "%%{?%{gsub
%{name} - _}_pre
See also:
```
$ rpm --eval '%{len foo bar}' --eval '%{len:foo bar}'
3
7
```
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3410#issuecomment-2446541400
You are receiving this because you are subscribed to this thread.
Message ID: _
These are internal only for now to allow us gain soem more confidence on the
design.
rpmlogOnce allows showing a log message only once. rpmlogReset allows purging
the list of known message keys for a given domain. This allows for different
live times e.g. per transaction or per package.
Use in
@dmnks pushed 1 commit.
326937c3f6393451909f50479ad042bb98473dfc Support Fedora 41 in Dockerfile
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3418/files/b75ecc6ebdaa73407f8a964ab5ba9d95bf51d0c6..326937c3f6393451909f50479ad042bb98473dfc
You are receiving this because
Fixed by #3414, just a typo in the Fixes clause, doh.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3413#issuecomment-2447273514
You are receiving this because you are subscribed to this thread.
Message ID: ___
Closed #3413 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3413#event-15007812132
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint m
> rpm -D "name string-io" -D "string_io_prerelease .dev" --eval '%{sub
> %{expand:%%?%{gsub %{name} - _}_prerelease} 2 -1}'
Thx for the tip. I was getting to the point of trying multiple `%`. You have
saved me some time 👍
There is also different variant it seems:
~~~
$ rpm -D "name string-io"
Argh, it really was not my morning:
`Fies: #3413`
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3414#issuecomment-2447271529
You are receiving this because you are subscribed to this thread.
Message ID: _
Fixed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3418#issuecomment-2447262931
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-m
May be just add a two line comments before or just in the class declaration
stating that this si for getting a lock on a macro context and use it to do
macro stuff with it.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3408#issuecommen
@dmnks commented on this pull request.
A couple of questions:
1. We already know what messages (code & string) have been emitted in the log
context as they're stored in the `recs` member (currently a vector). Is there
any benefit of adding a new `seen` map, instead of turning `recs` into such a
> See also:
>
> ```
> $ rpm --eval '%{len foo bar}'
> 3
> ```
And TBH, this is also quite questionable behavior.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3410#issuecomment-2447713591
You are receiving this because you are subscr
> Funnily enough, we were forced to use Lua for
> [c9s](https://gitlab.com/redhat/centos-stream/rpms/ruby/-/blob/stream-ruby-3.3-rhel-9.6.0/macros.rubygems?ref_type=heads#L15),
> because RPM does not support %{sub:...} there. ATM, I don't think it is more
> readable nor shorter. But admittedly,
> Hmm, I don't remember the : syntax being intentionally one argument only but
> then it's been a while. But in that case this is a documentation issue.
I'd argue this is just documentation issue. The "one arguments" syntax likely
has some merit, but then the error message is quite unintuitive
> > Hmm, I don't remember the : syntax being intentionally one argument only
> > but then it's been a while. But in that case this is a documentation issue.
>
> I'd argue this is just documentation issue. The "one arguments" syntax likely
> has some merit, but then the error message is quite uni
In the meanwhile: if you can do so in your environment, turning on enforcing
signature checking (that _pkgverify_level thing) is very much recommended,
that's supported since 4.14.2. It's just that so many workflows are based
around the traditional no-signature behavior that changing the upstrea
With extra {}:
```
rpm -D "name string-io" -D "string_io_prerelease .dev" --eval '%{sub
%{expand:%%{?%{gsub %{name} - _}_prerelease}} 2 -1}'
dev
```
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3412#issuecomment-2446517851
You are
This is needed for "make check" to work on a Fedora 41 host where the
FROM directive is overridden to fedora:41.
- Drop the workaround for gdb-headless, the old version no longer exists in F41
and the bug has been fixed in both F40 and F41:
https://bugzilla.redhat.com/show_bug.cgi?id=2310156
-
Oh, right: an unsupported algorithm will be treated equally to non-existent
ones, and if it's a signature the package will simply be considered unsigned.
And, in the traditional configuration a signature is not required.
Add this to the verify command and it will fail because there's no positive
Closed #3416.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3416#event-15005153964
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Rpm
Oops, I completely forgot why we added the gdb-headless version range via
ea4a98bc669a8403d9b490f5aa692d25cca01a9f. Spoiler alert: to support F39. We
don't want to drop support for F39 just yet so let me fix this up.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-s
> What verification are you talking about, specifically? The term is overloaded
> in multiple places around rpm...
>
> If an unknown algorithm causes us to give an OK to an unverifiable signature
> then we obviously do have a rather bug someplace.
If xxx.rpm has been signed (Assume that the has
@JetXujing pushed 1 commit.
8a22a51af8e9f7de274f49c3a392ba0af66f4ff2 Check the validity of hash algo
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3416/files/1f071c8f73006ce12d021f2e7062e4a1e504b2ad..8a22a51af8e9f7de274f49c3a392ba0af66f4ff2
You are receiving this bec
The macro class needs a bit more doc strings. It is kinda weird that it is
basically just a lock around the macro context. Not that there is anything
wrong with that - it's just weird
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3408#
It would help to understand the actual use-case behind this.
I'll also note that this is in already in the territory where doing things in
Lua with proper program logic will be much easier to both write and read.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-softw
Your different variant drops the `?` character:
```
$ rpm -D "name string-io" -D "string_io_prerelease .dev" --eval '%?%{gsub
%{name} - _}'
%string_io
```
Please do not rely on rpm to not expand a unknown macro name, but instead use
`%%`.
--
Reply to this email directly or view it on GitHub:
Oh and thanks for reporting!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3413#issuecomment-2447274682
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-
> The macro class needs a bit more doc strings.
I don't disagree, but we don't traditionally have much in the way of docs for
internal APIs. What do you want to see documented, the locking scheme?
> It is kinda weird that it is basically just a lock around the macro context.
> Not that there
Closed #3412 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3412#event-15008085366
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint m
Yeah both syntaxes should work. Thanks for reporting.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3410#issuecomment-2446054284
You are receiving this because you are subscribed to this thread.
Message ID: ___
This will happen with any spec using Buildsystem, there's no difference from
any 4.20 preversion to upstream git master so it's not a regression within
Buildsystem-using packages, but for rpmspec in general yes.
Luckily it's also trivial to fix.
--
Reply to this email directly or view it on Gi
@dmnks commented on this pull request.
Two nitpicks for the commit message:
* `rpmspeq` would be a funny contraction of `rpmspec -q` but probably just a
typo :smile:
* `rpmbuild --quiet` doesn't seem to be affected by this, it sets the log level
up to `RPMLOG_WARNING` whereas `RPMLOG_NOTICE` is
Heh, funny typo indeed :smile:
And right, I didn't actually try rpmbuild --quiet with this, would've been
obvious it already works the way it should. Will fix, just a sec.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3414#issuecomment
Either way, Lua or not, I still find surprising that plain `?` does not work in
the expand.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3411#discussioncomment-11097332
You are receiving this because you are subscribed to this t
Sorry to be that guy... but the commit summary still says rpmspeq :laughing:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3414#issuecomment-2446252920
You are receiving this because you are subscribed to this thread.
Message ID: _
50 matches
Mail list logo
