Righty, finally got around to properly look at this: the test-suite
expectations in the *release tarball* are wrong due to somehow missing commit
db48f6b69bdea860a8fa687e95bcb370a86f9984 contents, despite this commit clearly
being visible in the included ChangeLog file. Can't begin to guess as t
FYI I’ve converged on this pattern for my own packaging macros
```rpm
%foometa → munge upstream metadata into rpm metadata
%foopkg -a → create package headers
%foobuild -a → build
%fooinstall -a → install
%foocheck -a → check
%foofiles -a → create files section
```
https://pagure.io/fonts-rpm-macr
While --define '%foo 1' is often equal to --define 'foo 1', if
%foo
happens to be already defined, the define expands to that value,
completely changing the intent of the --define.
Found due to %source_date_epoch_from_changelog being set in Fedora,
causing %source_date_epoch_from_changelog cli de
Thanks, I need to investigate if #860 solves the problem for me
--
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/issues/551#issuecomment-606528690_
Closed #1147.
--
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/1147#event-3182648334___
Rpm-maint mailing list
Rpm-maint@lists.rpm
Okay this is just bollocks afterall.
--
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/1147#issuecomment-606542208___
Rpm-maint ma
While anything would be better than the current situation, from a rpm user POW,
I'd like less magic and special things in rpm, and more generic operators and
constructs.
IE, everything is a variable, except for things that need multiple
declarations, and use tags.
SourceX as a tag is IMHO a m
Fixes the reproducable build test failing in Fedora rpm builds due to
%source_date_epoch_from_changelog being set on the outside, which
leaks the SOURCE_DATE_EPOCH environment into the test-suite and
changes the expectation.
You can view, comment on, or merge this pull request online at:
https:/
Right now a lot of things need special tags in rpm just because they can be
declared multiple times (for example `Requires`).
Tags are hugely inconvenient to manipulate in spec automations because they all
come with their special handling requirements.
Please add real array primitives to rpm, s
Right now a lot of things need special tags in rpm just because they have a
specific (usual subpackage) scope, and can be declared in multiple scopes
Please add a generic construct to specify the scope of a set of variable, so
those special Tag constructs can be ultimately replaced by easy to ma
Closed #1049.
--
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/issues/1049#event-3183244885___
Rpm-maint mailing list
Rpm-maint@lists.r
Closing from the perspective of subject: we're not changing %global behavior,
too many things depend on it being the way it is. We do have %{macrobody:...}
now and could also add a macro primitive to declare literal macros, but that's
beyond the scope here I suppose.
--
You are receiving this
Seems the actual request was totally misunderstood by somebody here...
Anyway, the issue is that there's no way to make such a thing reliable, and we
can't really turn a long-standing explicit known behavior into a heuristic. In
general, heuristics don't work very well in rpm. Stripping out know
Closed #371.
--
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/issues/371#event-3183324011___
Rpm-maint mailing list
Rpm-maint@lists.rpm
How about not storing rpm headers in some binary database anymore but rather as
individual files on disk?
Ie rather than stuffing them into /usr/lib/sysimage/rpm/Packages.$format just
dump them as is, eg
/usr/lib/sysimage/rpm/installed/hello-1.2-3.x86_64.rpm
That opens several possibilities
-
With uncompressed payload one could even copy the full rpm into
/usr/lib/sysimage/rpm/installed and reflink the data.
--
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/issues/1151
I want to work on this and I've opened this issue to track it.
`pythondeps.sh` is written in shell and unlike the Python dist generators, it
uses no Python, it plainly determines the provide / requirement from the path.
As the file is run for every Python file, we are potentially doing hundreds
pythondeps.sh was written in shell and unlike the Python dist generators,
it uses no Python, it plainly determines the provide / requires from the path.
As the script was run for every Python file, we were potentially doing hundreds
of shelling outs to execute a script that calls grep and sed.
In
I have not yet tested this at all.
--
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/1153#issuecomment-606927599___
Rpm-maint maili
This helps ensure that the values of the __cc and __cxx macros are respected
during builds.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1154
-- Commit Summary --
* Export CC and CXX in __build_pre
-- File Changes --
> Is the lua implementation supposed to go to the
> [python.attr](https://github.com/rpm-software-management/rpm/blob/master/fileattrs/python.attr)
> file directly?
Yes. I'll clarify the docs.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
Cool!
You'll need to remove pythondeps.sh from scripts/Makefile.am though, that's
what the CI is failing on. Also please avoid mixing whitespace changes with
actual code changes, especially with %__python_path it's impossible to see
offhand whether the actual line changes here or not.
--
You
We had this up to rpm 4.14 (all macros being local to the surrounding %{}
scope), and the only thing it did was create endless confusion. Okay, buggy
implementation didn't help, but there's no way we're going back to that mess.
Remember the "%define is evil, everybody must use %global" touting i
Also, note that even in >= 4.14, macros (not variables) do have a scope: inside
parametric macros, all %defines are local.
--
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/issues
Macro arrays would be useful every now and then, yes.
OTOH by the time you need arrays you typically need loops and the like, which
is what we have Lua for. I'm not saying "no" to this but in general I rather
put an effort into making Lua more usable in macros than implement new things
in the m
25 matches
Mail list logo
