Funny/strange case.
Anyway, thanks for the 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/1336#issuecomment-677272176___
Merged #1336 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/1336#event-3673689476___
Rpm-maint mailing list
Rpm-mai
For complicated macros beyond "grab the output of foo -l" scale, Lua is
recommended. It's by far the fastest scripting language available in rpm
context, no forks involved to invoke the interpreter or shell etc.
--
You are receiving this because you are subscribed to this thread.
Reply to this
@Conan-Kudo approved this pull request.
--
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/1336#pullrequestreview-471049794___
R
> This is a valid use case. But I dislike the idea of adding a new tag for
> this. I'd rather like to see something that is closer to the hack without its
> drawbacks
> `Source1: https://foo.bar/baz -> ba-1.2.tgz` or
> `Source1: https://foo.bar/baz : ba-1.2.tgz`
I definitely like this better tha
> if you write compatibly and avoid using any possible extensions there are
You end up having to invoke forty-eleven other tools (awk, sed, grep, tr, etc.)
to do what bash can do. :-(
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it o
Well, /bin/sh is by definition *the POSIX shell* - if you avoid using any
possible extensions there are... (but yes of course accumulating eg bashism is
creepishm easy :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
htt
Fair enough on being able to invoke various interpreters. I don't have enough
interest to lobby for that.
But being able to define the posix shell that `%()` uses would be useful and
make for more portable specfiles.
--
You are receiving this because you are subscribed to this thread.
Reply t
The garbage collection happens in background, based on heuristic.
This means that sometimes, when subsequent commands run,
some files might disappear in the middle of an action.
For example, when a find is used in %prep:
+ /usr/bin/git commit -m ... --author 'rpm-build '
Auto p
Preparation for rpm 4.16.0 rc1.
This pulls in most of the code changes since beta3 release, and I'm having
doubts whether we should do that or only concentrate on bugfixes here. Of
particular concern are those rpmio threading changes that *just* landed.
Thoughts/comments?
You can view, comment
@Conan-Kudo, thanks for the pointers, I had the feeling this had been discussed
in the past.
--
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/1334#issuecomment-676224334__
We don't want embedded Python now any more than we did back then.
A generic way of grabbing output from a command without invoking the shell in
between I might consider, but nothing that adds language specifics into rpm,
when we're in the process of getting rid of them alltogether. And I'm dubio
@dmnks There were multiple pull requests to attempt to add `%{python:}` several
years ago, unfortunately they didn't go anywhere. If we want to add this
functionality, we should probably start from #190 (which was the last attempt
to do this).
--
You are receiving this because you are subscrib
Okay no further comments / feedback, back to the drawing board for now.
--
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/1050#issuecomment-676041391__
Closed #1050.
--
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/1050#event-3669947490___
Rpm-maint mailing list
Rpm-maint@lists.rpm
On Wed, 19 Aug 2020 11:14:20 +0200, Panu Matilainen wrote:
> Should be pretty obvious really, starting with: it's a bit much to ask
> people to (possibly build and) install a whole another compiler just for
> a few test-cases that might not even concern them.
OK, sorry I forgot the upstream point
I don't care much about the lead contents as such (and neither should anybody
else), but changing it does seem wrong.
--
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/1326
Merged #1324 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/1324#event-3669884791___
Rpm-maint mailing list
Rpm-mai
Okay, the first commit could've used a more elaborate commit message but I what
I missed I missed. I do blame the GH interface to some extent on that though :(
Thanks for the patches!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it o
> On Wed, 19 Aug 2020 09:25:22 +0200, Panu Matilainen wrote: We can't really
> require both gcc and clang for rpm compilation,
> I do not understand why but OK.
Should be pretty obvious really, starting with: it's a bit much to ask people
to (possibly build and) install a whole another compiler
On Wed, 19 Aug 2020 09:25:22 +0200, Panu Matilainen wrote:
> We can't really require both gcc and clang for rpm compilation,
I do not understand why but OK. Do you plan to update the .spec BuildRequires?
> we need to skip (instead of failing) debugedit tests that depend on
> a non-present compi
@marxin commented on this pull request.
> @@ -523,6 +523,27 @@ fprintf(stderr, "*** ufdOpen(%s,0x%x,0%o)\n", url,
> (unsigned)flags, (unsigned)mo
return fd;
}
+/* Return number of threads ought to be used for compression based
+ on a parsed value threads (e.g. from w7T0.xzdio or w7T16
@marxin pushed 2 commits.
2c659f7ec7dea6fb1a4a25d13a91592c0acb7d97 Add get_compression_threads and
refactor code.
c771b3b43d05d76d0b19df9a2c25eba3c9f1e6a1 Enable thread autodetection for a
parallel compression.
--
You are receiving this because you are subscribed to this thread.
View it on
@pmatilai commented on this pull request.
> @@ -523,6 +523,27 @@ fprintf(stderr, "*** ufdOpen(%s,0x%x,0%o)\n", url,
> (unsigned)flags, (unsigned)mo
return fd;
}
+/* Return number of threads ought to be used for compression based
+ on a parsed value threads (e.g. from w7T0.xzdio or w7T
@marxin pushed 2 commits.
854bf2775fbaaa7b0621de46f3e42a165a5fd60c Add get_compression_threads and
refactor code.
b490f59832a056a897cd1835d7faed4a41585327 Enable thread autodetection for a
parallel compression.
--
You are receiving this because you are subscribed to this thread.
View it on
@pmatilai requested changes on this pull request.
See above.
--
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/1256#pullrequestreview-470197533_
Merged #1333 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/1333#event-3669460881___
Rpm-maint mailing list
Rpm-mai
Just for the record, this is not for 4.16 except to document it as deprecated.
--
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/1333#issuecomment-675905368___
We can't really require both gcc and clang for rpm compilation, we need to skip
(instead of failing) debugedit tests that depend on a non-present compiler (see
various AT_SKIP_IF examples in the testsuite) . This is equally true for both
gcc and clang, perhaps it could be centrally handled in RP
29 matches
Mail list logo