As always, I suggest to put the description to the commit message, not just the
PR description.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@hroncok approved this pull request.
I've already approved this in Fedora and I've asked @frenzymadness to bring it
here as well.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@hroncok
--
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/1320#issuecomment-663508390___
Rpm-maint mailing list
@dmnks pushed 1 commit.
c9b9a299d93ead98e1f05098b3f80d46f8813153 Docs: Add DYNAMIC BUILD DEPENDENCIES
section
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks commented on this pull request.
> +to run this command (followed by new dependency resolution) repeatedly until
> it
+no longer exits with code 11.
New revision force-pushed.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
Sometimes, byte-compilation might produce two functionally identical pyc files
that are not byte-to-byte identical which might cause problems.
Disabled hash seed randomization does not solve this problem entirely but helps
a lot by lowering probability.
You can view, comment on, or merge this
@dmnks commented on this pull request.
> +to run this command (followed by new dependency resolution) repeatedly until
> it
+no longer exits with code 11.
OK, thinking about it more, a situation could arise where a missing dep can't
be resolved or installed (with `dnf builddep`) for whatever
> I'll implement support in deltarpm and you can port it to drpm, ok?
Sure, appreciate that!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I'll implement support in deltarpm and you can port it to drpm, ok?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> Looks good to me, thanks. (Of course the deltarpm and drpm need to be updated
> now so that they support a ZSTD_THREADED compression type as well.)
Thanks.
I can start working on the support for the mentioned tools. Can you please
guide me a bit what would be needed?
--
You are receiving
Looks good to me, thanks. (Of course the deltarpm and drpm need to be updated
now so that they support a ZSTD_THREADED compression type as well.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@dmnks commented on this pull request.
> +to run this command (followed by new dependency resolution) repeatedly until
> it
+no longer exits with code 11.
Yeah, "new dependency resolution" sounds a bit awkward and isn't exactly clear.
Will fix.
As for the "until" clause, I wonder if
@ignatenkobrain commented on this pull request.
> +to run this command (followed by new dependency resolution) repeatedly until
> it
+no longer exits with code 11.
```suggestion
to run this command (followed by installation of the generated dependencies)
repeatedly
until no new dependencies
@dmnks pushed 1 commit.
6c358561b2b7593c9717797305d96d4133140ba6 Docs: Add note on buildreqs.nosrc.rpm
and code 11
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 1 commit.
96bf7343c84bf463baf7eb0f40a617c9019dd74f Docs: Add note on buildreqs.nosrc.rpm
and code 11
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
> I've just asked about this explicitly here:
> [facebook/zstd#2238
> (comment)](https://github.com/facebook/zstd/issues/2238#issuecomment-662906821)
And `zstd` folks confirmed that a number of threads does not influence the
stability of the "threaded" compression mode.
--
You are receiving
16 matches
Mail list logo
