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
> 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
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 --
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
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
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:
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
-
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
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
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
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
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
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,
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:
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
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
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
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:
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
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
```
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
22 matches
Mail list logo
