Well, `%install` following the preamble is technically a different issue.
`%prep` is setting `%buildsubdir` via `%setup` and everything that makes use of
that needs to be after `%prep`. This is not limited to the debuginfo magic -
although it is especially non-obvious there.
--
Reply to this e
There are some "interesting" gotchas in this direction. I have draft patches to
turn %patch and %setup into actual macros so they get processed with the normal
spec readLine() machinery but as long as the macro engine cannot handle
multiple options of the same type, this is a no-go. The other, a
Adding %end works for terminating %prep, but it doesn't help %install following
the preamble.
The proper fix for this is to eliminate the %install override macro hack.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1870#issuecomment-12
Hi, I debugged the code of gunpg2 found that it seemed to have special
treatment on ```\n \r \t ``` and whitespace
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2184#issuecomment-1258842527
You are receiving this because you are
It closes a section. So it would end the `%prep` section. Idea is that the
debuginfo magic wold then be evaluated after the `prep` section. Basically the
same as if there was another section inbetween.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-managem
What does `%end` do?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1870#issuecomment-1258534865
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint ma
I wonder if adding `%end` to the `%install` macro fixes the issue. The `%end`
would be useful for once...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1870#issuecomment-1258384207
You are receiving this because you are subscribed to
%prep is very special. It is first parsed completely and only then are `%setup`
and `%patch` replaced. While these two need to do special things they should
still be internal macros that are processed right when they are encountered.
One side effect of this is #1870
--
Reply to this email dire
Golang library packages often don't ship any go binaries and thus no arched
(sub)packages, but they're built on all arches to ensure that the tests pass
everywhere and that the noarch `-devel` subpackage does not contain different
contents when built on different architectures. Rust libraries wo
OK, I think I have an idea what's wrong here:
If `%install` is encountered after/as part of `%prep` debuginfo does not work.
The reason is that `%prep` is first parsed and `%setup` - which is setting
`%buildsubdir` - is only executed after the whole `%prep` section is processed
and all macros a
Yup. The reason I remembered debuginfo depending on %build section is easily
demonstrated with the golang example too (after removing the line to disable
debuginfo):
1. move %generate_buildrequires before %prep, debuginfo disappears
2. add (an empty) %build section between %prep and %install, a
Ehm, scratch the above, the debuginfo stuff is hooked on %install, not %build.
Sorry for the misleading comment.
This seems one of those "spec specials", really. It's probably some interplay
between how the spec parser works and expands macros and sections - if you move
the %generate_buildrequi
While looking at something else, I discovered that the debuginfo machinery is
still hooked on to this ugly hack of overloading `%install` with a macro:
```
%install %{?_enable_debug_packages:%{?buildsubdir:%{debug_package}}}\
%%install\
%{nil}
```
I'm sure this was initially intended as just a q
> Some obscure corner-cases changing behavior is kinda expected in this kind of
> cleanup. Is there some real-world usage which breaks because of this,
> something that can't be trivially fixed?
Through test cases, I found that the
https://github.com/rpm-software-management/rpm/commit/aec8bdb53
For giggles... I've looked at this a few times over the years, here's the
earliest reference I can find:
```
[pmatilai🎩︎localhost hacks]$ ls -l *postun*
-rw-rw-r--. 1 pmatilai pmatilai 12438 Mar 2 2010
rpm-postuntrans-hackery-0.patch
```
This has been a long time coming :smile:
--
Reply to
Merged #2177 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2177#event-7457689352
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint maili
Closed #2119 as completed via #2177.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2119#event-7457689454
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rp
Some obscure corner-cases changing behavior is kinda expected in this kind of
cleanup.
Is there some real-world usage which breaks because of this, something that
can't be trivially fixed?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/
@dmnks approved this pull request.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2177#pullrequestreview-1119969758
You are receiving this because you are subscribed to this thread.
Message ID: ___
Squashed. It's quite a monster of a commit, really:
29 files changed, 234 insertions(+), 29 deletions(-)
For adding two tiny scriptlets :roll_eyes:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2177#issuecomment-1257798951
You are re
@dmnks requested changes on this pull request.
Just marking the PR as "changes requested" so that the fixups are squashed
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2177#pullrequestreview-1119879982
You are receiving this because y
Oh, I think @pmatilai actually has to squash those fixups himself, not sure if
GH is smart enough to do that.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2177#issuecomment-1257739453
You are receiving this because you are subscribed t
Makes sense. Feel free to merge then, it otherwise looks good to me.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2177#issuecomment-1257737622
You are receiving this because you are subscribed to this thread.
Message ID: __
Well, those switches are basically for disabling a single, problematic
scriptlet. Yes, it is not likely that you want to disable preuntrans and not a
postuntrans - simply because they will still be very rare. But the semantics
here is that you can at least target a specific type and mixing thing
Then there's the argument for consistency, of course, which we discussed
above... It's a tough decision, for sure :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2177#issuecomment-1257715390
You are receiving this because you are
I'm not a fan of the last fixup commit (adding the CLI switches), to be
completely honest :smile: Is there a realistic scenario in which you'd want to
keep a pre/posttrans scriptlet enabled but a preun/postuntrans one disabled, or
vice-versa?
--
Reply to this email directly or view it on GitHu
Indeed, I think there are worse bugs in the internal parser (e.g., [not being
able to deal with some
subpackets](https://github.com/rpm-software-management/rpm/pull/1813)).
Nevertheless, if we want RPM to deal with such malformed certificates, perhaps
it makes sense to add a unit test, which I
...and so it begs the question whether it's worth bothering to fix at all: it's
not a common thing, it's not a hard to work around and the internal PGP code is
supposedly frozed for anything but critical fixes. This isn't one.
--
Reply to this email directly or view it on GitHub:
https://github
That's because the reproducer was buggy, ie missing the problematic whitespace
:facepalm:
But indeed, this only affects the internal OpenPGP parser.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2184#issuecomment-1257574907
You are re
29 matches
Mail list logo
