Re: [Rpm-maint] [rpm-software-management/rpm] Add rpmLogOnce to filter log message (Issue #3395)
Hmm, so you could of course easily count the times you get called per each key, and then optionally emit a "repeated X times" when on reset so you'd basically get the #3336 behavior and the more regular log suppression style from the same thing. The lifetime could be handled by throwing in a context or id to the mix, this could be an arbitrary 64bit int so you can pass in a pointer (ts, spec, whatever), have the keys hang off that, and then have a function to reset the context. So that'd become something like this, with id 0 (zero) being a global aka per-process lifetime context always, the rest are up to the caller: void rpmlogOnce (uint64_t id, const char * key, int code, const char *fmt, ...); void rpmlogReset(uint64_t id, int suppress); One thing here is that I'd much rather add an internal-only API for this first, that lets us experiment and fiddle with it until we're happy and then make it public if/when the time comes. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3395#issuecomment-2443867384 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] Add rpmLogOnce to filter log message (Issue #3395)
#3336 calls for this to be independent of the process life time. The issue here is that the whole logging system is bound to the process as it is build on top of a global variable. The right thing IMHO would be adding this functionality to the global log context for now and deal with the issue of non-global logging separately. For now we could add just one new function: void rpmlogOnce (const char * key, int code, const char *fmt, ...); `rpmlogClose` would also clear the memory of what has already logged. So far this is only used in `rpmcliFini` which is only called at the end of the command line tools. So this is basically a non solution but it moves it in with the logging global context issue that we do have anyway. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3395#issuecomment-2443717627 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] Add rpmLogOnce to filter log message (Issue #3395)
OK; let's start with the second thing first. void rpmlogOnce (uint64_t ctx, const char * key, int code, const char *fmt, ...); void rpmlogReset(uint64_t ctx, int suppress); Look fine to me. `suppress` probably morphing into a enum for the different modes of operation. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3395#issuecomment-2444244887 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] Implement a native C++ macro API + use it to replace manual macro locking (PR #3408)
This started with the innocent intention of making a couple of C++ string expand variants available, but then I got carried away... There are no added tests because this is all covered by existing functionality testing. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3408 -- Commit Summary -- * Return C++ string from macro expansion internals * Replace macro locking with an internal RAII-style C++ API * Convert a couple of rpmExpand() usages to the C++ versions -- File Changes -- M build/build.cc (24) M build/rpmfc.cc (7) M rpmio/macro.cc (327) M rpmio/rpmmacro_internal.hh (39) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3408.patch https://github.com/rpm-software-management/rpm/pull/3408.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3408 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] Add rpmLogOnce to filter log message (Issue #3395)
Hmm, "last warning repeated 123 times" works fine if there is only one message repeated all over. There surely are cases like this in rpmbuild. But for things like the signature results they are interwoven with other messages. Same is probably true with for other things. E.g. warnings for non declared macros - if we want to add those. Alternative would be listing the suppressed messages and their number at the end. Or we could add "further messages are left out" to the second message. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3395#issuecomment-2444005620 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] Add rpmLogOnce to filter log message (Issue #3395)
Yeah there are two separate things there: for the "last warning repeated 123 times" you'd want to have automatically detected and supressed on all rpmlog() calls. The other case - the original case this ticket started with - is the case where the caller needs to be aware and do their own suppression mechanism. For this case, you'd optionally output on the context reset with a slightly different message based on the key and the original message. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3395#issuecomment-2444030598 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] How to expand user possibly non-existent user constructed variable name? (Discussion #3411)
Actually, it seems that I have found a cure:
~~~
$ rpm -D "name foo" -D "string_io_prerelease .dev" --eval
'%{expand:%{%{quote:?}%{gsub %{name} - _}_prerelease}}'
$ rpm -D "name string-io" -D "string_io_prerelease .dev" --eval
'%{expand:%{%{quote:?}%{gsub %{name} - _}_prerelease}}'
.dev
~~~
But why the `quote` macro makes a difference?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3411#discussioncomment-11090540
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] Regression: addtional output in rpmspec with -q (Issue #3413)
**Describe the bug**
When I run:
```
rpmspec -q --qf '%{license}\n' '--define=_sourcedir .'
~/spdx/cfn-lint/cfn-lint.spec 2>/dev/null
```
on this spec file
https://src.fedoraproject.org/rpms/cfn-lint/blob/rawhide/f/cfn-lint.spec
I get:
```
Reading /var/tmp/rpm-tmp.bSC32X
MIT-0 AND MIT
MIT-0 AND MIT
MIT-0 AND MIT
MIT-0 AND MIT
MIT-0 AND MIT
```
which is more lines than expected and contains line that should be on stderr
(or not printed at all because of `-q`)
**To Reproduce**
Steps to reproduce the behavior:
1. fedpkg clone cfn-lint
2. cd cfn-lint
3. rpmspec -q --qf '%{license}\n' '--define=_sourcedir .' cfn-lint.spec
2>/dev/null
Please link or attach the packages or spec files involved.
**Expected behavior**
I expected that the line `Reading /var/tmp/rpm-tmp.bSC32X` is not present,
because I used `-q` option.
And I would expect the line with the license printed only once.
**Output**
**Environment**
- Fedora 41
- rpm-build-4.20.0-1.fc41.x86_64
**Additional context**
I believe this did not happened a week ago (when I used F41 Beta).
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3413
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] `%{sub:...}` macro does not work with `%{expand:...}` (Issue #3412)
The subject is likely wrong, because I don't understand the mechanism. But for
some reason, it does not seem that the value provided by `%{expand:...}` is
properly used by `%{sub:...}`
**Expected behavior**
~~~
$ rpm -D "name string-io" -D "string_io_prerelease .dev" --eval '%{sub
%{expand:%{%{quote:?}%{gsub %{name} - _}_prerelease}} 2 -1}'
dev
~~~
**Output**
~~~
$ rpm -D "name string-io" -D "string_io_prerelease .dev" --eval '%{sub
%{expand:%{%{quote:?}%{gsub %{name} - _}_prerelease}} 2 -1}'
{?string_io_prerelease}
~~~
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3412
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] `%{sub:...}` macro does not work with `%{expand:...}` (Issue #3412)
This works:
~~~
$ rpm -D "name string-io" -D "string_io_prerelease .dev" --eval '%{sub
%{expand:%{%{expand %{quote:?}}%{gsub %{name} - _}_prerelease}} 2 -1}'
dev
~~~
So this is likely related to #3411. Is there chance to make it somehow more
straight forward?
BTW this also works:
~~~
$ rpm -D "name string-io" -D "string_io_prerelease .dev" --eval '%{sub
%{expand:%{%{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-2445113781
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] `%{gsub:...}` throws error (Issue #3410)
>From
>[documentation](https://github.com/rpm-software-management/rpm/blob/ebc406862053815528c00095f9f991d649fa33a0/docs/manual/macros.md?plain=1#L119),
> I would think this should work:
~~~
$ rpm --eval "%{gsub:foo o i}"
error: lua script failed: [string "gsub"]:1: bad argument #2 to 'gsub' (string
expected, got no value)
~~~
Please note the example works just fine without the collon:
~~~
$ rpm --eval "%{gsub foo o i}"
fii
~~~
Testing on Fedora Rawhide:
~~~
$ rpm -q rpm
rpm-4.20.0-1.fc42.x86_64
~~~
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3410
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] Add rpmLogOnce to filter log message (Issue #3395)
Right, there could be more than two modes of operation for reset, so "suppress" might be overly limiting as a name - see what comes up. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3395#issuecomment-2444252967 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] Add rpmLogOnce to filter log message (Issue #3395)
Let's look at the bigger picture here a bit, because #3336 is an isolated use-case and rather unusual at that so it's actually not that interesting in itself. The typical case of log suppression we'd want is of the "last message repeated 123 times" kind rather than silence *all* the following messages. We have at least the following cases with different needs wrt lifetime: 1) per transaction 2) per package in transaction 3) spec parse (optionally followed by package build) 4) process lifetime 1-2 and 3 are kinda separate groups and typically don't exist within the same process. I'm quite sure we technically have stuff that would qualify for 1) besides #3336, and 4) is all we have at the moment. I see two ways to think about #3336: either its about unknown key tracking with specific semantics, or its just a warning message with a particular implementation. In the latter case we could just replace the existing behavior of unknown key tracking with the "last warning repeated 123 times" that the rest of the log suppression wants. I don't know if we have anything else that has the same semantics as the current unknown key warning - maybe we do, I just don't remember any atm. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3395#issuecomment-2443807770 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] How to expand user possibly non-existent user constructed variable name? (Discussion #3411)
I have this snippet:
~~~
$ rpm -D "name string-io" -D "string_io_prerelease .dev" --eval
"%{expand:%{%{gsub %{name} - _}_prerelease}}"
.dev
~~~
But if the `name` does not match to the next definition, the non existing
variable is printed out:
~~~
$ rpm -D "name foo" -D "string_io_prerelease .dev" --eval "%{expand:%{%{gsub
%{name} - _}_prerelease}}"
%{foo_prerelease}
~~~
But I would like to just ignore such output, but this (the additional `?`) does
not work (the output is always empty):
~~~
$ rpm -D "name foo" -D "string_io_prerelease .dev" --eval "%{expand:%{?%{gsub
%{name} - _}_prerelease}}"
$ rpm -D "name string-io" -D "string_io_prerelease .dev" --eval
"%{expand:%{?%{gsub %{name} - _}_prerelease}}"
~~~
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3411
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] A halloween story 👻 (Discussion #3409)
As you may know, RPM packages may contain something called ghost files. Or rather, the point is that the files that are not there. While this may sound weird to the uninitiated, this is actually quite common need. Consider for example a log file that gets created when a software you packaged runs - you don't want to ship a file for that, but you'd want the file to be identified with your package, and possibly removed when the package is removed. Yep, that's what `%ghost` is for. So %ghost file in an rpm package is a file that might exist in the buildroot, but the file contents do not get packaged at all, only the metadata like path, permissions etc are registered in the package. Originally this was the only supported case, later we added support for what you might call declarative ghosts - files and directories that never existed at all. You can perhaps imagine, these entities that exist on one level and not on the other tend to cause all sorts of special casing around the codebase. A %ghost file is not created on install, because there's nothing to create it from. A normal %ghost file gets removed when the owner package is removed, as you'd probably want for some uninteresting runtime state data. But if you also mark it as a %config file, then it is left behind on package removal - as you'd want to do for more valuable data. That much seems simple enough, but there are all manner of weird questions waiting for those who stick their nose a bit too deep into the ghosts' business. Such as myself, one day in the winter of 2012-2013. I was working on adding tests and cleaning up the %config and %ghost file management, when I suddenly ran into a %ghost that did not obey the rules. It was a %ghost %config but got removed along with the package. There didn't seem to be anything special about the package or the file, and I stared and stared at the code, not seeing how it could possibly behave that way. Of course, there's nothing a sufficient amount of printf()'s wont find (yes, I'm of that school): the reason that one file in that one package was behaving differently was that the sha256sum of the file on my laptop disk happened to match the sha256sum of the file that had been in the buildroot. Somewhere far away in the Fedora buildsystem, probably months earlier. That was a properly spooky moment, and the reason I call this a halloween story. [A ghost identifying with its past self](https://github.com/rpm-software-management/rpm/commit/26389a69ac37f37dd35b12ef340316dc903b3955), or something. Past the initial surprise, this was of course perfectly logical. Rpm thinks a modified %config file is valuable and is preserved on erasure, but an unmodified %config file is not valuable and thus is erased along with the package. Otherwise we'd leave an useless litter trail behind. And while %ghost file contents is not packaged, the metadata is, and for a file that exists in the buildroot, part of that metadata is its checksum. If there's a checksum, it's possible it matches with something. And if there's logic that depends on whether a checksum matches or not, it can trigger. It was just a special case somebody forgot to add. I ran into lots of those that winter, but this is one I'm unlikely to forget. To this day, I don't know for sure whether this %ghost %config behavior is intentional or not. The commit logs from the early days tend to be terse and light on the level of information provided. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/3409 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] Implement a native C++ macro API + use it to replace manual macro locking (PR #3408)
Got carried away enough that I forgot to explain a key benefit: This gives the caller the ability to control locking, so if you need to do 1000 expands in a loop you no longer need to go through lock+unlock cycles for each as it is with the C versions. Gaining those benefits of course requires changing callers to the new API, I've only converted a couple of calls here for examples and to provide tests for the string/vector variants. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3408#issuecomment-2443736385 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
