Closed #147.
--
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/147#event-947661857___
Rpm-maint mailing list
Rpm-maint@lists.rpm.
Right, thanks for reporting. Fixed in commit
db1a33c8d36868478f1e2d32261ab99c9b55756f.
When you say "attached files", did you intend to attach something here or did
you mean the packages in your other recent reports? At least I was not able to
reproduce this with those, but found a reproducer
I would hazard to say I would _almost never_ recommend switching to
multithreaded stuff by default, after accounting for how it would potentially
break DeltaRPM. Unless there's a way to make _that_ deterministic, I see no
pathway that would allow for widespread usage of multithreaded compression
@toabctl I'm not particularly a fan of the late byte-compilation technique
Debian uses, and I'd rather not propagate that down to everyone.
However, @bmwiedemann's idea of getting the .py files set to
`$SOURCE_DATE_EPOCH` to embed that in .pyc files is interesting.
--
You are receiving this be
The attached files will cause an invalid free or double free. As they're both
in the same code line I assume it's the same bug in different variations.
This only affects the git code, not the latest release (otherwise I wouldn't
have reported it to a public bug tracker). This is obviously a very
SELinux recommends to use string_to_security_class() instead of referencing
class IDs directly. This also fixes a build issue for systems that don't
include flask.h by default.
References:
https://selinuxproject.org/page/NB_Imp_SELinux-aware_Apps#Implementing_SELinux-aware_Applications_2
https://g
See also: https://github.com/ClusterLabs/pacemaker/pull/1218
--
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/145#issuecomment-277055423
Currently:
```
$ cat newpackage.spec
%define __os_install_post %(echo '%{__os_install_post}' \
| sed -e
's!/usr/lib[^[:space:]]*/brp-python-bytecompile[[:space:]].*$!!g')
Name: foo
Version:1
Release:1%{?dist}
Summary:bar
License:GPLv2
URL:
> I was thinking that it would be better to do it like Debian and generate
> those in %post
> which also reduces the size of rpms and allows it to be noarch
Yes that would be good. Here is the relevant debian policy for that:
https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_pa
I put it there because the spec says:
> Build systems MUST NOT overwrite this variable for child processes to consume
> if it is already present.
But then, it probably does not apply if we had set it ourselves (and not the
user) for the previous rpm to build.
--
You are receiving this because
-K aka --checksig has been just a popt alias to `rpmkeys` for quite some time
now, and popt aliases don't work so great from a git checkout. Try using
./rpmkeys -K instead.
Note that what that codepath does is vastly different from what happens during
eg rpm -U or rpm -q which have their own, d
On 2017-02-02 13:46, Florian Festi wrote:
> I am not too keen on the use of global variable
Do you refer to "oneshot" or "SOURCE_DATE_EPOCH"?
> I wonder how we want to address the Python .pyc file issue
I was thinking that it would be better to do it like Debian and generate
those in %post
which
I am not too keen on the use of global variable(s) here. May be we can renew
loading the environ variable for each build and store it in the spec or package
variable instead.
While it may not matter much in practise I'd rather not like to add more
technical debt there.
Other than that the patch
Hmm, I am wondering if the
getenv("SOURCE_DATE_EPOCH") == NULL
condition is really correct here. The problem is that rpmbuild might be used to
build multiple packages in one go. But even if that was not possible someone
using the API could.
Do we really need to give precedence of an already set
> Also it's perhaps worth pointing out that none of the packages in the series
> crash nor pass through 'rpm -K' verification.
Maybe a bit offtopic here, but I noted that the "-K" parameter no longer works
in the current git code. Is this intentional? (and if yes: why?) Because I
specifically w
Just FWIW, this is enough to catch all of #133, #135, #136, #138 and #139:
```
--- a/lib/header.c
+++ b/lib/header.c
@@ -255,6 +255,8 @@ static rpmRC hdrblobVerifyInfo(hdrblob blob, char **emsg)
if (end > info.offset)
goto err;
+ if (info.tag < HEADER_I18NTABLE)
+
Two ways to drive the adoption of multi threaded compressors could be
a) Talk to distributions to make those compressors part of their core set of
packages and change the macros in their rpm package
b) Offer patches upstream to add those compressors as alternatives in the
macros.in or configure f
Multithreaded compression is not some magic holy grail. Sure it can make the
compression phase faster but it requires considerably more memory and more
importantly the compression ratio degrades so for distros it might be a bad
choice. Also AFAICT deltarpm requires bit-by-bit equivalent compress
> It is the decision of the distributions to support them and change the macros
> accordingly.
> Upstream may follow the consensus of the distributions later.
Right. However, I hope that rpm upstream will enable multi threaded xz
compression by default for them. :) For example,
```
# https://
19 matches
Mail list logo
