Re: [Rpm-maint] [rpm-software-management/rpm] Sending multiple identical options to a macro will leak them to the next macro accepting the same option (Issue #3056)
It's a bug alright. I actually just stumbled on that code a couple of days ago
thinking this doesn't look right. It isn't.
It's not just multiple identical options, it's any local macro multiply
defined, issue being that freeArgs() only ever pops once. Easily reproduced
with eg
> rpm --define "aa 0" --define "my() %{define:aa 1} %{define:aa 2}" --eval
> "%my" --eval "%aa"
> warning: Macro %aa defined but not used within scope
>
>1
It should "obviously" output 0.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3056#issuecomment-2074090243
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] I is currently not possible to completely disable rpm own debuginfo generation code (Issue #3057)
**Describe the bug**
I have spent some time trying to create a completely custom debuginfo file for
a package I maintain.
Currently it is not possible to do so. Even disabling the custom package
template and the whole debug_package machinery via `%global debug_package
%{nil}` if rpm build see a package named `%{name}-debuginfo` it will always
interfere with the build process of that package.
Namely the code will disregard any file list provide by either the %files
section or via __find_debuginfo script and will instead process to reconstruct
a new file list by searching for files named
*-%{name}-%version}.%{release}.debug
**To Reproduce**
Steps to reproduce the behavior:
1. Disable debug package creation
2. Add an explicit %{name}-debuginfo package
3. Try to include arbitrary files in it
Please link or attach the packages or spec files involved.
**Expected behavior**
When debug package creation is disabled the "main" debuginfo package file lists
should not be tampered with.
**Additional context**
At the moment the only workaround I found was to create a fake subpackage and
debuginfo subpackage and that allows me to include whatever content I need, but
this is not a good solution.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3057
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] [bug] posttrans $1 equals 1 which should be 2 according the documents (Issue #3033)
Note the patch was never backported to RHEL-8, hence CentOS 8 being affected too. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3033#issuecomment-2072488384 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] [bug] posttrans $1 equals 1 which should be 2 according the documents (Issue #3033)
This was fixed "recently" (in 2022) via #2176, closing. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3033#issuecomment-2072485700 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] [bug] posttrans $1 equals 1 which should be 2 according the documents (Issue #3033)
Closed #3033 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3033#event-12576755985 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] Sending multiple identical options to a macro will leak them to the next macro accepting the same option (Issue #3056)
Saner handling of multiple identical options would be nice, but even without that, the described behavior is wrong. Agreed? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3056#issuecomment-2072404151 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] Sending multiple identical options to a macro will leak them to the next macro accepting the same option (Issue #3056)
Yes, it's because the engine pushes the macro with each option but only pops it once. I guess we could modify freeArgs that it pops until the level is clear, or we could change setupArgs so that it pushes just once. But see also https://github.com/rpm-software-management/rpm/pull/2449 that asks of a saner handling of multiple identical option. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3056#issuecomment-2072388595 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] Sending multiple identical options to a macro will leak them to the next macro accepting the same option (Issue #3056)
**Describe the bug**
Consider this situation:
Macros:
```
%macro_leaking(E:) %{nil}
%macro_infected(E:) echo -- "%{-E:-E was provided: %{-E*}}%{!-E:there was no
-E}"
```
Notice both macros take an `-E` option with a value. The exact name of that
option is not limited to `E`.
And run:
```
%macro_leaking -E myEoption1 -E myEoption2
%macro_infected
%macro_infected
%macro_infected
```
Results in:
```
echo -- "-E was provided: myEoption1"
echo -- "there was no -E"
echo -- "there was no -E"
```
See that the value passed to `-E` leaks to the infected macro. Moreover:
```
%macro_leaking -E myEoption1 -E myEoption2 -E myEoption3 -E myEoption4
%macro_infected
%macro_infected
%macro_infected
%macro_infected
```
Leads to:
```
echo -- "-E was provided: myEoption3"
echo -- "-E was provided: myEoption2"
echo -- "-E was provided: myEoption1"
echo -- "there was no -E"
```
The leaking and infected macros can even be the same:
```
%macro_infected -E myEoption1 -E myEoption2 -E myEoption3 -E myEoption4
%macro_infected
%macro_infected
%macro_infected
%macro_infected
```
Leads to:
```
echo -- "-E was provided: myEoption4"
echo -- "-E was provided: myEoption3"
echo -- "-E was provided: myEoption2"
echo -- "-E was provided: myEoption1"
echo -- "there was no -E"
```
**To Reproduce**
Spec:
```
Name: reproducer-eee
Version:0
Release:0
Summary:...
License:...
%description
...
%define macro_leaking(E:) %{nil}
%define macro_infected(E:) echo -- "%{-E:-E was provided: %{-E*}}%{!-E:there
was no -E}"
%macro_leaking -E myEoption1 -E myEoption2
%macro_infected
%macro_infected
%macro_infected
```
Run `rpmspec -P reproducer-eee.spec`.
---
This impacts macros in Fedora. When I run:
```
%check
%pyproject_check_import -e '*django*' -e '*flask*' -e '*httpx*' -e '*requests*'
-e '*sqla*' -e '*starlette*'
%tox
```
The `%tox` macro will receive one of the `-e` values (coincidentally, `%tox`
also uses `-e` for one of its options).
**Expected behavior**
Passing option values multiple times should never leak to other macro calls.
**Environment**
- OS / Distribution: Fedora 39, 41
- Version rpm-4.19.1.1-1.fc39, rpm-4.19.1.1-1.fc40
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3056
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] Pass arg3 to regular and file trigger scripts (PR #3018)
@dmnks commented on this pull request. > @@ -32,7 +32,7 @@ directories, symlinks etc. The file triggers are defined in spec files of packages. E.g. file trigger executing `ldconfig` could be defined in glibc package. -Similarly to regular triggers, file trigger scripts (except the `%transfiletrigger*` variants) are passed the number of instances of the triggered and triggering package (as the `$1` and `$2` arguments, respectively) that will remain when the file trigger has completed. This can be useful in order to perform a certain operation when either of the packages is updated or removed. +Similarly to regular triggers, file trigger scripts are passed the number of instances of the triggered and triggering package (as the `$1` and `$2` arguments, respectively) that will remain when the file trigger has completed, as well as which of those two packages has activated the trigger (the `$3` argument). As an exception, the `%transfiletrigger*` variants are always passed the value of -1 as the `$2` argument. Yep... I just didn't feel like copy the same text from the trigger page but $1 and $2 are described here, and so should $3, so ack, will fix. FWIW, this will be refactored anyway as part of the (planned) consolidation of the two trigger flavours into one page. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3018#discussion_r1575863971 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] Pass arg3 to regular and file trigger scripts (PR #3018)
@dmnks commented on this pull request.
> @@ -248,4 +248,29 @@ char *argvJoin(ARGV_const_t argv, const char *sep)
return dest;
}
-
+
+ARGV_t argvFromVaList(const char *fmt, va_list ap)
+{
+ARGV_t argv = argvNew();
Oh, fair points, thanks. Will update the PR later.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3018#discussion_r1575861228
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] Pass arg3 to regular and file trigger scripts (PR #3018)
After a quick chat on our team channel, this may benefit from packagers' feedback. It's meant for them, after all. I'll ask for it, let's convert to a draft meanwhile. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3018#issuecomment-2071705760 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] Pass arg3 to regular and file trigger scripts (PR #3018)
@pmatilai commented on this pull request.
> @@ -248,4 +248,29 @@ char *argvJoin(ARGV_const_t argv, const char *sep)
return dest;
}
-
+
+ARGV_t argvFromVaList(const char *fmt, va_list ap)
+{
+ARGV_t argv = argvNew();
No need for argvNew(), argvAdd*() handles that as needed. Without this, an
invalid fmt will return NULL which is what we probably want.
I think I'd also make this a private helper inside rpmscript.c, all of argv.*
is considered deprecated going forward so maybe we shouldn't add more public
APIs there.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3018#pullrequestreview-2016536902
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] Upstream debuginfo enablement (PR #3040)
@pmatilai commented on this pull request.
> @@ -145,6 +145,9 @@
#%__systemd_sysusers @__SYSTEMD_SYSUSERS@
%__systemd_sysusers%{_rpmconfigdir}/sysusers.sh
+# enable debug package generation
+%_enable_debug_packages 1
I realized this doesn't belong to the main macros.in, really - it should
probably be in platform.in instead. For one, this is a Linux-only feature due
to the ties elfutils, but also: we don't want debug packages for noarch
packages, *that* is the place to express it. Sadly we'll still need the other
noarch checks because the platform files aren't reread on spec parse recursion,
but it's the right direction anyhow.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3040#pullrequestreview-2016452103
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] Upstream debuginfo enablement (PR #3040)
@pmatilai commented on this pull request.
> %global __debug_package 1\
+%(cat > "%{specpartsdir}/rpm-debuginfo.specpart" << EOL\
I'd like it a whole lot more if the `cat` was in the template part. This is an
ugly side-effect for a macro to have, eg somebody doing `rpm --eval
"%{debug_package}"` to see what it's made of.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3040#pullrequestreview-2016438413
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] Adapt tests to current state of the "legacy" parser (PR #3055)
Nice, thanks! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3055#issuecomment-2071520497 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] Adapt tests to current state of the "legacy" parser (PR #3055)
Merged #3055 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3055#event-12570092472 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] `%build -a` and `%install -a` overwrite build/installation instructions from `%buildsystem_*_*` (Issue #3024)
Closed #3024 as completed via #3047. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3024#event-12570032397 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] Fix build scriptlet append/prepend interaction with Buildsystem (PR #3047)
Merged #3047 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3047#event-12570032216 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] Convert a bunch of librpmio stuff to native C++ (PR #3054)
Merged #3054 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3054#event-12570029080 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] Convert a bunch of librpmio stuff to native C++ (PR #3054)
Added a bunch of rationale/background to the first commit message, no code changes. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3054#issuecomment-2071512091 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
