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 becaus
@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 t
@dmnks pushed 1 commit.
b5700cb7e707b4b38fa431d25f44df0ff7a5a9b2 build: prioritize large packages
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1180/files/ad337863bdeb9aed69224159e4be27ab8d2749f4..b57
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
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1188
-- Commit Summary --
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
* Silenc
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
Rpm-maint@lists.rpm
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 mailing
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, don't try building IMA plugin without it
* R
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
> @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
@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:
https://github.com/rpm-sof
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 becaus
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 cou
> 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 pr
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:
https://github.com/rpm-software-management/rpm/pull/1184#issuecomment-616505304___
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
Rpm-maint@lists.r
> 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:
https://github.com
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 thre
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
Rpm-maint@lists.
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
%inc
Closed #1104.
--
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/1104#event-3251381244___
Rpm-maint mailing list
Rpm-maint@lists.r
Addressed here: https://github.com/rpm-software-management/rpm/pull/1184
--
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-616497780___
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
Rpm-maint@lists.r
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, thanks
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
Rpm-mai
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:
https://github.com/rpm-software-manag
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}'
%{load:/dev/
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:
https://github.com/rpm-software-management/rpm/issues/1104#issuecomment-616423526_
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
Rpm-mai
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:
https:
30 matches
Mail list logo