Re: [Rpm-maint] [rpm-software-management/rpm] Make "rpmspec -q --srpm foo.spec" say .src, not .%{arch} (#1116)
@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:
https://github.com/rpm-software-management/rpm/pull/1116/files/72d0d656b9d95469e9b6297850384c11f2ab5926..5fa11af61ae2545ad94f351379222829810bb020
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make "rpmspec -q --srpm foo.spec" say .src, not .%{arch} (#1116)
> 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 to do that. -- 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/1116#issuecomment-598228143___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Make "rpmspec -q --srpm foo.spec" say .src, not .%{arch} (#1116)
I noticed that rpmspec -q --srpm foo.spec winds up getting evaluated
as the arch that youre running it on, which I expected, but also that
the arch winds up in the output, which I did not. I asked a pile of
other people and they were all surprised by this as well.
This patch changes rpmspec -q --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
-- Commit Summary --
* Make rpmspec -q --srpm foo.spec say .src, not .%{arch}
-- File Changes --
M lib/query.c (13)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/1116.patch
https://github.com/rpm-software-management/rpm/pull/1116.diff
--
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/1116
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] [RFC] Make "%patchlist -f patches" work. (#874)
> 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: https://github.com/rpm-software-management/rpm/pull/874#issuecomment-537574869___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpmbuild: %patch: fix a memory leak (#873)
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 own patches for safety errors. There's another piece of chaff that shows up as well, but it's the GOMP TLS initialization, so it should be handled in a valgrind suppression that's not specific to rpm. Aside from those, the codepaths I've been hacking near don't have anything show up in valgrind, so removing this one makes checking my code changes much easier. -- 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/873#issuecomment-537574552___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] [RFC] Make "%patchlist -f patches" work. (#874)
@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: https://github.com/rpm-software-management/rpm/pull/874/files/de678886588f17a4541d388e56e1708372df4f41..ef44ff173f42517ebebfe5b31c35e3bd1e9c6388 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] [RFC] Make "%patchlist -f patches" work. (#874)
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. 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. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/874 -- Commit Summary -- * Make %patchlist -f patches work. -- File Changes -- M build/parseList.c (84) M system.h (1) M tests/Makefile.am (1) A tests/data/SOURCES/patchlist (2) A tests/data/SPECS/hello-patchlist-f.spec (30) M tests/rpmbuild.at (18) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/874.patch https://github.com/rpm-software-management/rpm/pull/874.diff -- 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/874 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] rpmbuild: %patch: fix a memory leak (#873)
While debugging something else, I noticed that when I run rpmbuild, valgrind says: ==189844== ==189844== HEAP SUMMARY: ==189844== in use at exit: 12,088 bytes in 45 blocks ==189844== total heap usage: 61,336 allocs, 61,291 frees, 28,975,297 bytes allocated ==189844== ==189844== 24 bytes in 4 blocks are definitely lost in loss record 4 of 21 ==189844==at 0x483880B: malloc (vg_replace_malloc.c:309) ==189844==by 0x4FB5168: poptSaveArg (popt.c:1206) ==189844==by 0x4FB5168: poptGetNextOpt (popt.c:1510) ==189844==by 0x485EDF0: doPatchMacro (parsePrep.c:442) ==189844==by 0x485F44A: parsePrep (parsePrep.c:513) ==189844==by 0x4862C9F: parseSpec (parseSpec.c:924) ==189844==by 0x40322C: buildForTarget.constprop.0 (rpmbuild.c:506) ==189844==by 0x40340A: build.constprop.0 (rpmbuild.c:539) ==189844==by 0x40267F: main (rpmbuild.c:701) ==189844== This looks pretty suspicious to me, so I went and looked at the code. poptSaveArg() says: case POPT_ARG_STRING: /* XXX memory leak, application is responsible for free. */ arg.argv[0] = (con-os-nextArg) ? xstrdup(con-os-nextArg) : NULL; This is the case where weve got a string argument pointer in poptOption-arg. In the case of %patch -P, we also keep a second copy of it, obtained from poptGetNextArg(), which we *are* freeing. This patch makes doPatchMacro() not need an extra allocated copy of opt_P, and frees all the poptOption-arg strings that are allocated. 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/873 -- Commit Summary -- * rpmbuild: %patch: fix a memory leak -- File Changes -- M build/parsePrep.c (14) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/873.patch https://github.com/rpm-software-management/rpm/pull/873.diff -- 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/873 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Improve "git am" support. (#854)
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.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/854#issuecomment-536041506___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make "%patchlist -f patches" work. (#866)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make "%patchlist -f patches" work. (#866)
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: https://github.com/rpm-software-management/rpm/pull/866#issuecomment-535539048___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make "%patchlist -f patches" work. (#866)
@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: https://github.com/rpm-software-management/rpm/pull/866/files/9c4d96081a31acb2d1d06dd5c9f8bf34b2b56260..99f643c6b8d17ebe99d397f4fa91d2955deecc64 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Make "%patchlist -f patches" work. (#866)
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. 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 at: https://github.com/rpm-software-management/rpm/pull/866 -- Commit Summary -- * Make %patchlist -f patches work. -- File Changes -- M build/parseList.c (39) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/866.patch https://github.com/rpm-software-management/rpm/pull/866.diff -- 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 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Improve "git am" support. (#854)
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: https://github.com/rpm-software-management/rpm/pull/854#issuecomment-535160958___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Improve "git am" support. (#854)
> 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 change and should
> arguably be done for all scm's that meaningfully support it
I see your point, and I agree with it, but I have a concern: I wouldn't know
where to begin for any of the other scm systems, so I'm not writing support for
all of them. That said, I don't see that there's much generalization to be had
here (in terms of the code); it appears they'll all have to be separate
implementations entirely. It doesn't seem like there's much good reason to gate
one scm doing this on support in the others, so I'll send this as its own patch
for git.
> * support for options in apply should also be a general thing, not
> limited to git am, and adding a mechanism generally should be separated from
> adding particular defaults
Sure - but again I'm only comfortable implementing that for git. Tell me what
/sort/ of mechanism are you looking for, and I'll happily write it for all the
git cases, and write the general hook for it so others can implement it for the
other scm systems. Are you okay with the approach I took with seeing if
%{expand:%%{?_scm_apply_%{_scm}_options}} exists as the method for generalizing
it?
> * I do see the point with `git am --continue` but short-cutting to
> %{patches} breaks other use-cases like applying ranges of patches. Need to
> find a way to do this without breaking others.
Would you be prefer something like a global that can be defined to control this
(a la disabling debuginfo), or would you prefer an argument to %autosetup, or
some other method I haven't thought of?
--
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/854#issuecomment-535051561___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make %setup use %{__tar_opts} to set tar options. (#859)
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: https://github.com/rpm-software-management/rpm/pull/859#issuecomment-535045928___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make %{buildsubdir} usable without being a side effect of %setup. (#860)
> %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. If we're already documenting it as exposed, doing it without the underscore is just fine by me. In that case all this does is make it be exposed more like other variables are. > What's the actual use-case behind this? It helps me subclass debuginfo generation on weird platforms and packages that build for more than one target inside the same build. -- 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/860#issuecomment-535043577___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make %{buildsubdir} usable without being a side effect of %setup. (#860)
@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:
https://github.com/rpm-software-management/rpm/pull/860/files/57b69b312d551a33fcbae47c965893da1ec5a687..43c0982a97a5c600f00b8108ef1765bc15ee563f
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make %{buildsubdir} usable without being a side effect of %setup. (#860)
> 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 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/860#issuecomment-534763882___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Make %{buildsubdir} usable without being a side effect of %setup. (#860)
This patch makes a couple of related changes:
- lets you set %{_buildsubdir} as a global to expose it everywhere,
rather than just specific parts of %prep (%setup and %patch*)
- lets you choose what path is used independently of the unpack
options in %setup
- allows you to use a different %{_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 at:
https://github.com/rpm-software-management/rpm/pull/860
-- Commit Summary --
* Make %{buildsubdir} usable without being a side effect of %setup.
-- File Changes --
M build/build.c (13)
M build/files.c (8)
M build/pack.c (2)
M build/parsePrep.c (24)
M build/policies.c (2)
M build/rpmbuild_internal.h (1)
M build/spec.c (2)
M macros.in (4)
M tests/data/macros.debug (2)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/860.patch
https://github.com/rpm-software-management/rpm/pull/860.diff
--
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/860
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Make %setup use %{__tar_opts} to set tar options. (#859)
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/rpm-software-management/rpm/pull/859
-- Commit Summary --
* Make %setup use %{__tar_opts} to set tar options.
-- File Changes --
M build/parsePrep.c (4)
M macros.in (2)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/859.patch
https://github.com/rpm-software-management/rpm/pull/859.diff
--
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/859
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add all of the rpmbuild macro aliases to rpmspec as well (#848)
@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: https://github.com/rpm-software-management/rpm/pull/848/files/6070700791f61a27436a694471d1e8493b0ddb7a..3046bf9b66f8098bacc48be7fe141b91aea87410 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add all of the rpmbuild macro aliases to rpmspec as well (#848)
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`' \
--POPTdesc=$"generate GPG signature (deprecated, use command rpmsign
instead)"
-# [--trace] "trace macro expansion"
-rpmbuild alias --trace --eval '%trace'
+rpmspec alias --trace --eval '%trace' \
Yep; will fix.
--
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/848#discussion_r326684026___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add all of the rpmbuild macro aliases to rpmspec as well (#848)
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-management/rpm/pull/848 -- Commit Summary -- * Add all of the rpmbuild macro aliases to rpmspec as well -- File Changes -- M rpmpopt.in (25) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/848.patch https://github.com/rpm-software-management/rpm/pull/848.diff -- 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/848 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFC: rpmlib efi provides (#438)
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: https://github.com/rpm-software-management/rpm/pull/438#issuecomment-384979282___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RFC: rpmlib efi provides (#438)
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: https://github.com/rpm-software-management/rpm/pull/438 -- Commit Summary -- * rpmlib: add mechanism for system(...) RPMSENSE_RPMLIB provides. * rpmlib: Make rpmlib give us a provide when we're on a UEFI system. -- File Changes -- M build/reqprov.c (3) M lib/rpmds.c (28) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/438.patch https://github.com/rpm-software-management/rpm/pull/438.diff -- 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/438 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Bounds check strings to print correctly in %trace mode. (#160)
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 thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/160#issuecomment-281162118___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Bounds check strings to print correctly in %trace mode. (#160)
In %trace mode, evaluating a macro which is undefined causes an invalid
read of 1 byte when searching for the end of the string:
trillian:~$ valgrind rpmspec --eval '%trace' --eval '%{?myUndefinedMacro}'
==21534== Memcheck, a memory error detector
==21534== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==21534== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==21534== Command: rpmspec --trace --eval %{?myUndefinedMacro}
==21534==
1> %{?myUndefinedMacro}^==21534== Invalid read of size 1
==21534==at 0x55018D4: printMacro (macro.c:296)
==21534==by 0x5502DFC: expandMacro (macro.c:1077)
==21534==by 0x5503710: doExpandMacros (macro.c:1280)
==21534==by 0x5504AB6: rpmExpand (macro.c:1629)
==21534==by 0x508F59A: rpmcliAllArgCallback (poptALL.c:120)
==21534==by 0x6DAF71D: invokeCallbacksOPTION (popt.c:156)
==21534==by 0x6DAF75B: invokeCallbacksOPTION (popt.c:139)
==21534==by 0x6DB1428: poptGetNextOpt (popt.c:1515)
==21534==by 0x508F912: rpmcliInit (poptALL.c:302)
==21534==by 0x1095B2: main (rpmspec.c:63)
==21534== Address 0x8a010f3 is 0 bytes after a block of size 19 alloc'd
==21534==at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
==21534==by 0x5507C17: rmalloc (rpmmalloc.c:44)
==21534==by 0x5502788: expandMacro (macro.c:927)
==21534==by 0x5503710: doExpandMacros (macro.c:1280)
==21534==by 0x5504AB6: rpmExpand (macro.c:1629)
==21534==by 0x508F59A: rpmcliAllArgCallback (poptALL.c:120)
==21534==by 0x6DAF71D: invokeCallbacksOPTION (popt.c:156)
==21534==by 0x6DAF75B: invokeCallbacksOPTION (popt.c:139)
==21534==by 0x6DB1428: poptGetNextOpt (popt.c:1515)
==21534==by 0x508F912: rpmcliInit (poptALL.c:302)
==21534==by 0x1095B2: main (rpmspec.c:63)
==21534==
1> %{?_transaction_color}^
1> %{?_prefer_color}^
1> %{_netsharedpath}^
1> %{_install_langs}^
==21534==
==21534== HEAP SUMMARY:
==21534== in use at exit: 7,183 bytes in 71 blocks
==21534== total heap usage: 7,811 allocs, 7,740 frees, 3,500,361 bytes
allocated
==21534==
==21534== LEAK SUMMARY:
==21534==definitely lost: 19 bytes in 1 blocks
==21534==indirectly lost: 0 bytes in 0 blocks
==21534== possibly lost: 0 bytes in 0 blocks
==21534==still reachable: 7,164 bytes in 70 blocks
==21534== suppressed: 0 bytes in 0 blocks
==21534== Rerun with --leak-check=full to see details of leaked memory
==21534==
==21534== For counts of detected and suppressed errors, rerun with: -v
==21534== ERROR SUMMARY: 5 errors from 1 contexts (suppressed: 0 from 0)
trillian:~$
This can easily be avoided by checking the first byte as well as the
second for 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 Changes --
M rpmio/macro.c (2)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/160.patch
https://github.com/rpm-software-management/rpm/pull/160.diff
--
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/160
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] rpm2cpio and rpm2archive: don't write archive data to a terminal. (#116)
rpm2cpio and rpm2archive happily write binary data to the output terminal. This happens, for example, when I'm typing a command such as "rpm2cpio foo.rpm | less" and I make a typo, hitting instead of the pipe key. This often results in hilarious (if bewildering) font and character 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> You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/116 -- Commit Summary -- * rpm2cpio and rpm2archive: don't write archive data to a terminal. -- File Changes -- M rpm2archive.c (6) M rpm2cpio.c (4) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/116.patch https://github.com/rpm-software-management/rpm/pull/116.diff -- 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/116 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [PATCH] Add efi arch macro
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 Alpha processors
%alpha alpha alphaev56 alphaev6 alphaev67
+#--
+# arch macro for all EFI-compatible architectures
+%efi %{ix86} x86_64 ia64
+
#
# Use in %install to generate locale specific file lists. For example,
#
--
1.7.4
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
