@vathpela pushed 1 commit.
5fa11af61ae2545ad94f351379222829810bb020 Make "rpmspec -q --srpm foo.spec" say
.src, not .%{arch}
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
> What about nosrc packages?
It's a bit harder to do well, as "rpmspec -q" goes through rpmcliQuery(), which
doesn't parse the spec file, and rpmspec.c doesn't know about rpmSpec
internals, so can't access spec->noSource without including
rpmbuild_internals.h, but I've pushed an updated patch
--srpm foo.spec to show
src, like the
package generated by rpmbuild -bs would be named, instead of the
local
machines arch.
Signed-off-by: Peter Jones pjo...@redhat.com
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1116
> Wouldn't this also make sense for `%sourcelist` too?
Yeah - and if you look at the code, it does it for both, I just didn't mention
one in the commit message.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yeah, I noticed that it still leaks on multiple uses, and there may be better
solutions these days. I chose to stop here for an entirely selfish reason -
using -b twice is clearly wrong to do, with only invoking it once, that leak is
chaff that shows up when I'm running valgrind to check my
@vathpela pushed 1 commit.
ef44ff173f42517ebebfe5b31c35e3bd1e9c6388 Make "%patchlist -f patches" work.
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
This adds a -f argument to %patchlist, similar to that for %files.
There is no limit to how many patchlist files you specify, and doing so
does not restrict the use of an inline patch list. Patches get added
from the leftmost list to rightmost, and any patches listed below get
added after that.
-by: Peter Jones pjo...@redhat.com
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/873
-- Commit Summary --
* rpmbuild: %patch: fix a memory leak
-- File Changes --
M build/parsePrep.c (14)
-- Patch Links --
https
Okay, I think this one should be pretty much fully baked - there's test cases
now for %{patches -m N -M N}, %{sources...}, %autosetup -S git_am, %autosetup
-S git, each of those with -N, and %autopatch after each of those.
--
You are receiving this because you are subscribed to this thread.
Closed #866.
--
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/866#event-2665980647___
Rpm-maint mailing list
Don't pull this yet; once I added a test case I realized there's still
something wrong with it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@vathpela pushed 1 commit.
99f643c6b8d17ebe99d397f4fa91d2955deecc64 Make "%patchlist -f patches" work.
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
that.
I couldnt find other code that obviously just reads a list of lines
from a file without assuming its a .spec, so Ive open coded this. If
theres a better way, Im open to suggestions.
Signed-off-by: Peter Jones pjo...@redhat.com
You can view, comment on, or merge this pull request online
In anticipation of your responses above, I've reworked this patch series. If
you'd like it differently than I guessed, let me know.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> Nice to see that at least somebody has discovered this and finding the idea
> useful enough to improve.
>
> Please split to independent commits though, too much unrelated change packed
> into one here:
Sure, that's fine by me.
> * creating a branch where patches are applied is one
That's reasonable enough - what would you prefer I do here, just close this one?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> %buildsubdir is a long-standing documented macro, we can't just rename it on
> a whim as doing so will break packages that were doing nothing wrong.
Okay, I didn't realize that, but the renaming part is only there because I
thought the codebase didn't like to expose non-underscored globals.
@vathpela pushed 1 commit.
43c0982a97a5c600f00b8108ef1765bc15ee563f Make %{buildsubdir} usable without
being a side effect of %setup.
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
> Other than the typo this looks good to me.
>
> `Reviewed-by: Adam Jackson `
Yeah, that's what I get for doing make check and then going "oh that looks
dangerous, but it's an easy fix" while re-reading the patch before pushing.
Anyway, new version that passes pushed.
--
You are receiving
%{_buildsubdir} in different parts of
the .spec, for instance if you have multiple builds of the same code
with different compile options
- renames it to %{_buildsubdir} since its now exposed
Signed-off-by: Peter Jones pjo...@redhat.com
You can view, comment on, or merge this pull request online
This patch adds __tar_opts and __tar_opts_verbose macros, which can be
overriden to change the default tar behavior when called from %setup
while building packages.
Signed-off-by: Peter Jones pjo...@redhat.com
You can view, comment on, or merge this pull request online at:
https://github.com
@vathpela pushed 1 commit.
3046bf9b66f8098bacc48be7fe141b91aea87410 Add all of the rpmbuild macro aliases
to rpmspec as well
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
vathpela commented on this pull request.
> @@ -221,8 +221,8 @@ rpmbuild alias --buildpolicy --define '__os_install_post
> %{_rpmconfigdir}/brp-!#
rpmbuild alias --sign \
--pipe 'rpm --addsign `grep ".*: .*\.rpm$"|cut -d: -f2` < "/dev/"`ps -p
$$ -o tty | tail -n 1`' \
This adds all of the rpmbuild popt aliases that expand to defines to
rpmspec as well.
It also changes --trace to include --POPTdesc argument help.
Signed-off-by: Peter Jones pjo...@redhat.com
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software
How will that work? Is there some mechanism I haven't seen that makes kernel
filesystems work as file provides?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This makes it possible for a package to do:
Requires: system(EFI)
or
Conflicts: system(EFI)
I'm certainly open to other ways to do this, or other ways it needs to be
phrased.
You can view, comment on, or merge this pull request online at:
It's not completely clear to me why the Jenkins check here failed, but it looks
like it has to do with Jenkins, not with this patch. Given that
https://github.com/rpm-software-management/rpm/pull/161 worked, I think this is
fine.
--
You are receiving this because you are subscribed to this
or our sentinal value (NUL).
Signed-off-by: Peter Jones <pjo...@redhat.com>
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/160
-- Commit Summary --
* Bounds check strings to print correctly in %trace mode.
-- File Ch
r encoding changes. On some systems, this can even result in
installation of relatively arbitrary rpms!
Nobody has ever meant to do this, and it's easy to prevent, so that's
what this patch does.
Signed-off-by: Peter Jones <pjo...@redhat.com>
Reviewed-by: Adam Jackson <a...@redhat.com>
Add efi to the arch macro list, so %ifarch %{efi} will work.
---
macros.in |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/macros.in b/macros.in
index a279995..a7e5fdb 100644
--- a/macros.in
+++ b/macros.in
@@ -1040,6 +1040,10 @@ done \
# arch macro for all supported
30 matches
Mail list logo
