You first chmod -x and then run brp-strip, how is it going to strip debuginfo
from *.so?!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mikhailnov commented on this pull request.
> @@ -0,0 +1,13 @@
+#!/bin/sh
+# If using normal root, avoid changing anything.
+if [ -z "$RPM_BUILD_ROOT" ] || [ "$RPM_BUILD_ROOT" = "/" ]; then
+ exit 0
+fi
+
+ELFCLASSIFY=/usr/bin/eu-elfclassify
BSD
12.10.2020 12:01, Panu Matilainen пишет:
>
> A different kind of approach to the issue could be continuing to require
> executable bit for requires generation, but have a brp-script strip the
> x-bits from all ET_DYN files that are not actually executable. eu-elfclassify
> could probably be
Thanks!
--
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/1426#issuecomment-723808513___
Rpm-maint mailing list
There is a package which requires "java-devel":
```
$ rpm -qR wildfly | grep ^java
java-devel >= 1:1.7
```
The package which provides it is the following:
```
$ rpm -q --whatprovides java-devel
java-1.8.0-openjdk-devel-1.8.0.252.b02-0.0.ea.x86_64
```
Now I want to find out why
The only place where `%{__spec_build_shell}` is used is the shebang of the
build script, but the script is executed by `%__spec_build_cmd`, I think
shebang is useless there.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
`__spec_*_cmd` do work however.
--
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/1399#issuecomment-708217633___
Rpm-maint
I want to define _different_ shells for %prep, %build and %install (because I
want to wrap pvs-studio analyzer in strace mode). But it does not work with
neither rpm 4.15.1 not 4.16.0
`%global __spec_prep_shell /bin/false` - does nothing, /bin/sh iss till use.
`%global __build_shell /bin/false`
It seems strange to me to default to assume-exec=false in the code of
`elfdeps`, but turn on `--assume-exec` by default. If we do not want to track
executability of ELFs, we would better switch the defaults in the code and
allow to add `--no-assume-exec` for example if needed.
--
You are
cc @mlschroe
--
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/1393#issuecomment-706605037___
Rpm-maint mailing list
Here you force to generate requires for non-executable files in e.g. /usr/bin
or elsewhere, does it make sense?
To my mind it does make sense to generate requires and provides for non
executable `%_libdir/*.so*` because they are not required to be executable to
work.
--
You are receiving
Do I understand correctly that IMA will verify signatures of binaries before
running them , but fsverity can verify _any_ file when it is being accessed and
block access if the signature is invalid?
--
You are receiving this because you are subscribed to this thread.
Reply to this email
Is NEVR format saved in headers? If it was, it could be used when parsing NEVR.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
There is SOURCEPACKAGE, but it is not used:
```
[root@rosa-2019 metacity]# rpm -q --querytags bash | grep SOURCE
NOSOURCE
SOURCE
SOURCEPACKAGE
SOURCEPKGID
SOURCERPM
[root@rosa-2019 metacity]# rpm -q --qf '%{SOURCEPACKAGE}\n' bash
(none)
```
--
You are receiving this because you are subscribed
I am a bit fed up with RPM's inability to show the value of "Name:" tag of the
spec from which the package was built. `rpm -q --qf '%{sourcerpm}\n` shows
something like `metacity-3.34.1-1.src.rpm` and I have to use strange
combinations of comsnds to extract the real name "metacity" from this.
you probably miss `-g` in %optflags or do not pass it to the compiler
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I actually don't know how to debug this, especially bdb operations, so posted a
link to LiveCD above. Or maybe someone may explain how to debug this.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
```
live@rosa2019 ~ $ export LC_ALL=C
live@rosa2019 ~ $ dnf repoquery --whatrequires bootsplash
Last metadata expiration check: 0:01:21 ago on Fri Aug 21 23:12:52 2020.
Rosa-theme-EE-0:2.0.0-115.noarch
bootsplash-themes-0:2.1.0-10.noarch
live@rosa2019 ~ $ rpm -q --whatrequires bootsplash
no
rpmlint thinks that /usr/share/gnome/help is documentation:
`FilesCheck.py:188:doc_regex =
re.compile(r^/usr(/share|/X11R6)?/(doc|man|info)/|^/usr/share/gnome/help)`
and gives a warning that those files are not marked as docs in RPM packages.
It seems a good idea to treat help files as
Does this mean that constructions like "OrderWithRequires: >= VERSION" are
supported?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
OrderWithRequires(pre) would probably be better for the use case which is
described in this PR, but OrderWithRequires without pre also worked. This is
probably some undocumented behaviour in dependency resolution, probably it
tries to install required packages before the package which requires
@ffesti I see that you added "RPMTAG_ORDERNAME, RPMTAG_ORDERVERSION,
RPMTAG_ORDERFLAGS," (
https://github.com/rpm-software-management/rpm/pull/1262/files#diff-ddf4f9f570183f31f3d5ba0a715a954fR1406
), but I added "RPMTAG_ORDERNAME, RPMTAG_ORDERFLAGS,". I actually did not test
Thanks. One question: do I understand correctly that currently there is no way
to make a generator of Requires(pre), Requires(post), Requires(postun),
OrderWithRequires(pre) etc.?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
If there is just a scriptlet which calls `systemctl preset`, in _some_ cases it
may silently fail to enable a service which must be enabled.
In most cases, I agree, it is not needed, but seems to be not harmful.
--
You are receiving this because you are subscribed to this thread.
Reply to this
But why? If a package contains a config is /usr/lib/sysusers.d/, why not to
ensure that it is installed after systemd-sysusers binary is present and so the
scriptlet which creates users can be executed?
--
You are receiving this because you are subscribed to this thread.
Reply to this email
If %_nonzero_exit_pkgcheck_terminate_build is true, then the build fails,
otherwise it does not. This regressed and the build never failed
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
RPM build did not fail if rpmlint (%_build_pkgcheck_set) failed when checking
binary RPMs
(it did fail correctly when rpmlint failed when checking SRPMs)
Probably fixes regression introduced by 78f61f273 (Refactor package set
checking out of packageBinaries())
You can view, comment on, or merge
It was possible to generate Requires, Recommends etc. using external dependency
generators.
Adding ability to generate OrderWithRequires.
Example use case:
When a package contains a systemd unit, %systemd_* macros are usually used;
it is usefull to add OrderWithRequires: systemd in this case to
Sounds like system consistency self test, that must be useful
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I meant not function multiversioning
(https://docs.01.org/clearlinux/latest/tutorials/fmv.html), but building a
separate binary is built with optimizations -
https://clearlinux.org/news-blogs/transparent-use-library-packages-optimized-intel-architecture
Where needed, building if optimized libs
Did anyone measure the real performance gain from having a separate znver1
architecture? It is a lot of maintenance and QA burden, but what is the result?
As time goes futher, probably new hardware instructions will apear in modern
x86 CPUs, so new arches like znver1 will have to be added.
Also
Of course I understand that it is not a goal, I wanted to say that another
implementation of rpm grammar behaves differently and at the same time I do not
understand why it should behave like rpm4 does.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
Example piece of code in `%prep`
```
( cd asedriveiiie-usb
%patch1 -p1
)
```
Result:
```
DEBUG: + cd asedriveiiie-usb
DEBUG: + %patch1 -p1
DEBUG: BUILDSTDERR: /var/tmp/rpm-tmp.A0WUoX: line 45: fg: no job control
```
But it works in rpm5. I had to put `%patch1` to the beginning of the line to
RPM 5 did it: https://abf.io/soft/rpm5/blob/master/rpmio/rpmiotypes.h#lc-204
Will the same approach be acceptable in rpm4?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> The other option would be detaching the digest algorithm enumeration used by
> rpm for non-PGP purposes from the OpenPGP values
If to make values out of the range specified by the OpenPGP RFC (e.g. 250 and
251 or whatever else), they will still be called `PGPHASHALGO_*`, but may it
break
mikhailnov commented on this pull request.
> @@ -266,6 +266,8 @@ typedef enum pgpHashAlgo_e {
PGPHASHALGO_SHA384 = 9, /*!< SHA384 */
PGPHASHALGO_SHA512 = 10, /*!< SHA512 */
PGPHASHALGO_SHA224 = 11, /*!< SHA224 */
+PGPHASHALG
Ok, another hack is possible. I can make a macro ` %__scriptlets_directory`,
create that directory inside the buildroot and copy scriptlets there. Then
process them with a dependency generator. But, according to docs
https://rpm.org/user_doc/dependency_generators.html , a generator cannot make
`rpmMkTempFile()` stores scriptlets in `%_tmppath` (`/var/tmp`), I have made a
dependency generator which runs `ls /var/tmp`, it showed that there are no
files with scriptlets in %_tmppath at that stage :-(
I thought to process them via a generator as a hack.
--
You are receiving this because
ALT's rpm-build does have this feature. I am unsecsessfully trying to find
where and how they do it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> They do nothing as far as I know. I'm pretty sure those are just stubs.
Thay seems to work, `build/build.c`. For me it is not very clear what code like
`(void) fputs(buildPost, fp);` does. And I see that `doScript()` does create
temporary files with scriptlets (`rpmMkTempFile()`). That is
```
macros.in:918:#%__spec_autodep_shell%{___build_shell}
macros.in-919-#%__spec_autodep_args %{___build_args}
macros.in-920-#%__spec_autodep_cmd %{___build_cmd}
macros.in-921-#%__spec_autodep_pre %{___build_pre}
macros.in-922-#%__spec_autodep_body %{___build_body}
Thanks for explaining. Very bad! I see that scriptlets are not treated as
separate files there. Maybe it is possible to send scriptlet text to stdin of a
generator?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Here I would appreceate pointing to code that generates dependencies by
shebangs for scriplets to see how it works.
> Moreover, attempts to identify programs in shell scripts have been
> problematic.
If this identifies >50% of programs and does not produces a lot of unresolvable
Requires,
mikhailnov commented on this pull request.
> @@ -3107,7 +3107,7 @@ rpmRC processBinaryFiles(rpmSpec spec, rpmBuildPkgFlags
> pkgFlags,
int didInstall, int test)
{
Package pkg;
-rpmRC rc = RPMRC_OK;
+rpmRC res = RPMRC_OK;
How reliable is it
Why znver1 only, why only this architecture? It looks a bit strange
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
It would be nice to add e2k here
--
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/1038#issuecomment-581179105___
Rpm-maint
As far as I understand, dependencies for %port/%pre and other scripltets are
generated only by schebang. I want to try to generate them for the content of
the script itself by feeding the path or content of the script to a dependency
generator like `%__script_requires`. But I do not know if it
mikhailnov commented on this pull request.
> @@ -3107,7 +3107,7 @@ rpmRC processBinaryFiles(rpmSpec spec, rpmBuildPkgFlags
> pkgFlags,
int didInstall, int test)
{
Package pkg;
-rpmRC rc = RPMRC_OK;
+rpmRC res = RPMRC_OK;
Do you mean that not eve
mikhailnov commented on this pull request.
> @@ -3107,7 +3107,7 @@ rpmRC processBinaryFiles(rpmSpec spec, rpmBuildPkgFlags
> pkgFlags,
int didInstall, int test)
{
Package pkg;
-rpmRC rc = RPMRC_OK;
+rpmRC res = RPMRC_OK;
@pmatilai I agree that *
mikhailnov commented on this pull request.
> @@ -3107,7 +3107,7 @@ rpmRC processBinaryFiles(rpmSpec spec, rpmBuildPkgFlags
> pkgFlags,
int didInstall, int test)
{
Package pkg;
-rpmRC rc = RPMRC_OK;
+rpmRC res = RPMRC_OK;
`res` is also use
mikhailnov commented on this pull request.
> @@ -3107,7 +3107,7 @@ rpmRC processBinaryFiles(rpmSpec spec, rpmBuildPkgFlags
> pkgFlags,
int didInstall, int test)
{
Package pkg;
-rpmRC rc = RPMRC_OK;
+rpmRC res = RPMRC_OK;
but I can resto
mikhailnov commented on this pull request.
> @@ -3107,7 +3107,7 @@ rpmRC processBinaryFiles(rpmSpec spec, rpmBuildPkgFlags
> pkgFlags,
int didInstall, int test)
{
Package pkg;
-rpmRC rc = RPMRC_OK;
+rpmRC res = RPMRC_OK;
rc stands for "return
@mikhailnov pushed 1 commit.
e6eb6a3caa22ae4332433b23c440322d6980ddf1 Print all build errors and do not
stop after the first error
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1020/files
Example situation:
in the spec file, I had: %{_libdir}/pulse/gsettings-helper and I
got an error that this file had not been found,
but in reality that file existed but in %{_libexecdir}/pulse/gsettings-helper.
I had to _guess_ that it exists. According to RPM log, it was not obvious.
RPM 5
Btw, there is a typo:
> Generators can be declare in the file attributes
declare -> declared
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> Um, input and output format haven't changed since beginning of times, the
> generator doc says:
> "A generator is just an executable that reads file name(s) from stdin and
> writes out Provides: or Requires: on stdout"
>
> It's always been one per line, but added a note about that to the doc
Maybe `echo -n ` is used to additionally print `= XXX`, then the output format
must be just line-by-line values?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I have found what was wrong ("NAME needs to be replaced by the name choosen for
the file attribute and needs to be the same as the file name of the macro file
itself").
But please document the input and output format. `pkgconfigdeps.sh` uses `echo
-n 'value '` and then `echo` an empty line,
I have been writing an RPM generator
(https://rpm.org/user_doc/dependency_generators.html) and I can't understand
which output format it must have.
Script is here: https://abf.io/import/devel-rpm-generators/
It simply does not work, no provides/requires are generated, I have looked into
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1007
-- Commit Summary --
* xzdio: Add line break to warning
-- File Changes --
M rpmio/rpmio.c (2)
-- Patch Links --
This seems to be related:
https://github.com/rpm-software-management/rpm/commit/74766d30b95f1575df8a42d185f2643caa235a8b
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
We have implemented Stribog 256bit filedigest algorithm in RPM 5.
Let's dump hashes of files inside it using RPM which has Stribog-256
implemented:
```
[root@rosa-2019 tmp]# rpm -qp --dump grep-3.3-3-rosa2019.0.x86_64.rpm
/bin/egrep 28 1574950713
62 matches
Mail list logo
