@pmatilai commented on this pull request.
> @@ -523,6 +523,28 @@ 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
@pmatilai commented on this pull request.
> +/* Return number of threads ought to be used for compression based
+ on a parsed value threads (e.g. from w7T0.xzdio or w7T16.xzdio).
+ Value -1 means automatic detection. */
+
+static int
+get_compression_threads (int threads)
+{
+if
@pmatilai commented on this pull request.
> @@ -1143,9 +1132,11 @@ static rpmzstd rpmzstdNew(int fdno, const char *fmode)
goto err;
}
- if (threads > 0)
+ threads = get_compression_threads (threads);
As noted above, there's an extra space before (threads)
@pmatilai commented on this pull request.
> @@ -797,8 +822,7 @@ static LZFILE *lzopen_internal(const char *mode, int fd,
> int xz)
ret = lzma_easy_encoder(>strm, level,
LZMA_CHECK_SHA256);
#ifdef HAVE_LZMA_MT
} else {
- if (threads == -1)
-
Closed #1324.
--
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-3669326500___
Rpm-maint mailing list
Yeah, overall looks like intended now, just minor nits/cosmetics.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Reopened #1324.
--
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-3669326724___
Rpm-maint mailing list
Note that having a *compile-time* way of hardwiring the shell of rpm macro
engine would be an entirely different thing. But that would mean abandoning
popen() and doing all the lifting by ourselves, popen() is hardwired to
/bin/sh. Doesn't seem worth it to me.
--
You are receiving this
@pmatilai commented on this pull request.
> @@ -1143,9 +1132,11 @@ static rpmzstd rpmzstdNew(int fdno, const char *fmode)
goto err;
}
- if (threads > 0)
+ threads = get_compression_threads (threads);
+ if (threads > 0) {
if (ZSTD_isError
Oops sorry, closing was accidental.
--
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#issuecomment-675888299___
Rpm-maint
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
> 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
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
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
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:
@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
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
@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:
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
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:
@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 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
@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
@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
@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:
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
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
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 rpm-build
Auto
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:
> 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
Preparation for rpm 4.16.0 rc1.
This pulls in most of the code changes since beta3 release, and Im 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
> 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
@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___
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
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
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
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:
37 matches
Mail list logo
