Problem was due to a CI bug, which I've included a fix for.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
frozencemetery commented on this pull request.
>
-ts = rpmtsFree(ts);
+if (argc == 1)
+ argv[argc++] = "-";
Now you may not *like* that I'm doing this, which is a perfectly valid
complaint and I'm happy to change it :)
--
You are receiving this because you are subscribed to
frozencemetery commented on this pull request.
>
-ts = rpmtsFree(ts);
+if (argc == 1)
+ argv[argc++] = "-";
Per C standard, argv[argc] is always defined to be a NULL pointer. (Section
5.1.2.2.1, paragraph 2, in ISO/IEC 9899:1999).
--
You are receiving this because you are
Add LIBINTL to rpm2{cpio,archive}_LDADD otherwise build fails on:
/home/buildroot/autobuild/instance-2/output/host/bin/xtensa-linux-gcc
-std=gnu99 -DHAVE_CONFIG_H -I. -I. -I./include/ -I./build -I./lib -I./rpmio
-I./misc -DLOCALEDIR="\"/usr/share/locale\""
OK, I've updated the pull request based on the discussion that we've got so far.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
As one of the maintainers of
[`rpm-config-SUSE`](https://github.com/openSUSE/rpm-config-SUSE), I'm okay with
this idea and we could work out a plan for transitioning things to the
convention in `redhat-rpm-config`. I like them more than the ones in the SUSE
environment, as it's clearer what
> I think switching to `%{build_…}` convention makes much more sense. In the
> old times where `optflags` meant everything, nowadays you want to have
> different CFLAGS, CXXFLAGS. And having `%{build_cflags}` but `%{ldflags}`
> sounds inconsistent.
I'm fine with the `%build_ldflags` name which
Split the regression fix to a separate PR #682 682 as that needs fixing
regardless of this.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Fixes a regression on mixed auto vs manual numbered patches/sources
introduced in commit 5fc4e1dd101b27eb8ed9526552c42bb809ac6790
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/682
-- Commit Summary --
* Continue
Merging it like that would be just nuts (whole lot of work and pain just to
give packagers even more surprise rope to hang themselves with, no thanks), but
seems I introduced a regression in
commi5fc4e1dd101b27eb8ed9526552c42bb809ac6790 - automatic numbering was
supposed to continue from
@pmatilai pushed 1 commit.
e9a52a9f6012d3998b1c4e6a126ba8d4dfc13bff Continue patch/source autorenumbering
from last specified number
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Why don't we merge them automatically then? Like if Source{1,3,4} are taken and
you supply %sourcelist, it will use Source{2,5,6}.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
One point that isn't maybe so obvious is that both these lists are new spec
sections, and entering a new section means that the preamble has ended. And for
that reason, it's not possible to have more Source[n] or Patch[n] lines (or
anything else belonging to preamble) *after* a %patchlist or
I think switching to `%{build_…}` convention makes much more sense. In the old
times where `optflags` meant everything, nowadays you want to have different
CFLAGS, CXXFLAGS. And having `%{build_cflags}` but `%{ldflags}` sounds
inconsistent.
--
You are receiving this because you are subscribed
You can combine all the variants if you take care the numbers don't end up
clashing, in which case you'll just get an error on the source/patch number,
like you'd get if you declare two patches with the same number.
I thought about forbidding mixed autonumber and manual numbering but then I
What will happen if you combine SourceX tag and %sourcelist?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Cool, I'll send patch.
--
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/593#issuecomment-486604885___
Rpm-maint mailing list
> If you are talking about having pythonX-rpm to depend on rpm-build-libs and
> rpm-sign-libs, but keeping C libraries separate, that would make sense to me
> (since it does not affect minimal installations).
Yup, that's exactly what I mean. The python side was split to keep in spirit of
the
Rebased, typo fixed + testcase added.
--
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/679#issuecomment-486602020___
Rpm-maint
ffesti commented on this pull request.
>
-ts = rpmtsFree(ts);
+if (argc == 1)
+ argv[argc++] = "-";
This doesn't look right. You can't just write beyond the bounds of the argv
array. You need to allocate a new - bigger - one.
--
You are receiving this because you are
> No objection to adding LDFLAGS to %configure, it's actually long overdue.
> Fedora has had its own version of this for a quite some time now, but nobody
> got around to upstreaming it. This seems like as good time as any to take a
> look at that and consider which parts would be upstreamable.
Merged #678 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/678#event-2299508152___
Rpm-maint mailing list
Merged #680 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/680#event-2299460223___
Rpm-maint mailing list
> I think a better way would be just merging the python modules back into one
> instead of splitting by C-side library, the split causes way more problems
> than it solves.
If you are talking about having pythonX-rpm to depend on rpm-build-libs and
rpm-sign-libs, but keeping C libraries
> I would vote for removing _doBuild method entirely since it is private so
> nobody should use it anyway.
I think a better way would be just merging the python modules back into one
instead of splitting by C-side library, the split causes way more problems than
it solves.
> You need an empty
Your comments are incorporated in the new version.
--
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/649#issuecomment-486536987___
26 matches
Mail list logo
