Merged #1184 into master.
--
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/1184#event-3250832051___
Rpm-maint mailing list
If you want hacks you can do something like:
```
%if "%{load:/dev/null}" == ""
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
May be you could use alternative approach:
~~~
%{?load:%{SOURCE4}}
%if %{undefined some_known_macro_from_the_SOURCE4}
%include %{SOURCE100}
%{load %{SOURCE4}}
%endif
~~~
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Guys, thanks for your info! It's useful.
For the hacks, it looks working.
With the RPM 4.15.1.
```
$ rpm --version
RPM version 4.15.1
$ rpm -E '%{load:/dev/null}'
<= empty
```
With the RPM 4.11.3.
```
sh-4.2# rpm --version
RPM version 4.11.3
sh-4.2# rpm -E '%{load:/dev/null}'
Merged #1169 into master.
--
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/1169#event-3251107238___
Rpm-maint mailing list
It seems that it's not the local version modifier that breaks this, but version
`0`. See https://github.com/fedora-python/pyp2rpm/pull/233
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Now documented in https://rpm.org/wiki/Releases/4.15.0
(https://github.com/rpm-software-management/rpm-web/commit/5e77e83f004f07fbfcf88bd3a69ac81c9a373d47)
and rpm will issue a warning on undefined macros in buildtree macros (commit
701736a18a4625557a5181df3a4f3aed7ac13506).
Case closed,
Closed #1161.
--
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/1161#event-3251121093___
Rpm-maint mailing list
Thank you.
--
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/1184#issuecomment-616501841___
Rpm-maint mailing list
That fixes the particular problem. But the two remaining points still stand:
- the exception when the conversion fails is not telling anything useful
- the rpmbuild continues (can we abort the build from a dependency generator?)
--
You are receiving this because you are subscribed to this
> the rpmbuild continues (can we abort the build from a dependency generator?)
Well, this is how it is done for all depgens, so this would be RFE on its own.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thanks.
--
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/1183#issuecomment-616505628___
Rpm-maint mailing list
Fedora backport:
https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/12
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The almost-backwards-compatible way would be to have a specific exit code that
should abort the build. E.g. "exit with 66 to abort the build".
Technically, I think it is possible to abort the build by generating an invalid
dependency, but that is hardly an API.
--
You are receiving this
> @torsava OK, let's wait for the next unexpected error. But wrapping
> everything in try-except and failing with useful error message is not a bad
> idea.
Ok, I'll add it to my PR.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
My preliminary testing shows a promising reduction of build time (with the
kernel package) when doing this, but I still have to analyze and understand the
code better, to see if it really is safe to do and nothing breaks as a result.
--
You are receiving this because you are subscribed to this
Backport two more patches to the 4.14.3 release for the selinux plugin
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1186
-- Commit Summary --
* Test for lsetxattr() presence, dont try building IMA plugin without it
*
@dmnks pushed 1 commit.
b5700cb7e707b4b38fa431d25f44df0ff7a5a9b2 build: prioritize large packages
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Many thanks! As I could fixed the issue by the following way, I would close
this ticket.
```
# Call load builtin macro if it is defined, otherwise call own load macro
# to avoid an error by creating SRPM in RPM 4.15+
%if "%{load:/dev/null}" == ""
%{?load:%{SOURCE4}}
%{?load:%{SOURCE5}}
%else
> the exception when the conversion fails is not telling anything useful
As this was an unexpected error, we don't know at what point in the code the
next unexpected error would strike. So the way I see it we would have to wrap
the whole machinery in `try..except` which isn't great, or do you
@torsava OK, let's wait for the next unexpected error. But wrapping everything
in try-except and failing with useful error message is not a bad idea.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #1186.
--
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/1186#event-3251556100___
Rpm-maint mailing list
Arg, wrong place, please ignore.
--
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/1186#issuecomment-616526209___
Rpm-maint
size_t is unsigned, so returning -1 is not going to have the expected
behavior. Fix it to return ssize_t.
Signed-off-by: Jes Sorensen jsoren...@fb.com
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1188
-- Commit Summary --
@pmatilai Fixed and rebased.
Note that I changed `RPMTAG_SIZE` to `RPMTAG_LONGSIZE` because I realized the
former may not be set if the total size is greater than 32 bits (details
[here](https://rpm.org/devel_doc/large_files.html)).
--
You are receiving this because you are subscribed to this
Yup, the generator failure handling is a funny mess:
- in legacy generators (the "external generator") only provide generation can
cause build-failure
- in current generators, all script error codes are ignored
- ...except for buildrequires generator where script errors cause build failure
Of
Backport two more patches to the 4.14.3 release for the selinux plugin
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1187
-- Commit Summary --
* Use common error logic regardless of setexecfilecon() availability
*
That'd make the non-error case buggy as it takes an unsigned size_t as the size
argument, but then returns a signed version which can't express the same range.
I suspect the simplest fix is to just document the error return as (size_t)-1,
similar to time() etc.
--
You are receiving this
28 matches
Mail list logo
