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
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
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
> 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
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:
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
@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
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,
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:
```
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}
> 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
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:
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
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
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
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:
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
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
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 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;
@pmatilai I agree that *
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
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 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
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,
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 --
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
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:
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
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:
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
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`
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:
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
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
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
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
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
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 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.
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
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 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
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
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
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
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
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:
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
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
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
Wow! I thought that name of source package is passed to generators. If the name
of subpackage is passed, it is easier to make generators in case that I wanted
to.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> How does this help to set ecosystem-wide macro?
I meant setting macros that rpm-build will use inside mock.
Ok, now I see your point.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I am building RPMs from https://abf.io/mikhailnov/kernel-5.4/tree/cd156877bc
The only subpackage that has Epoch is `kernel-headers`:
[1] https://abf.io/mikhailnov/kernel-5.4/blob/cd156877bc/kernel.spec#lc-776
The problem is that it makes ther macro `%epoch` be defined globally.
Some subpackages
Minimal reproduction, `rpm-1745.spec`:
```
Name: rpm-1745
Summary: %name
License: no
Version: 0
Release: 0
Group: System/Base
%description
%name
%files
/epoch.txt
#--
%package sub1
Summary: sub1
Group: System/Base
Epoch: 2
%description sub1
sub1
%files sub1
#--
%prep
You can define macros via mock config
--
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/1700#issuecomment-878296136___
Rpm-maint
Kernel modules may be *.ko.xz, *.ko.zst, *.ko.gz
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Kernel modules may be *.ko.xz, *.ko.zst, *.ko.gz
--
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/1744#issuecomment-878383675___
Ah, sorry, such files probably will not be detected as ELFs
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> I'm not sure what problem this solves. It sounds like the actual problem is
> that you want `hwloc1` and `hwloc2` to be parallel installable on RHEL 8.3.
> This is pretty much a distro policy issue, and while RPM provides mechanisms
> for solving this problem without needing `Obsoleted-by`,
The actual problem that I am trying to solve is the following.
There multiple versions of firefox available in the repository: firefox-esr52,
firefox-esr78.
We package ESR versions of Firefox and Thunderbird for users who reply on some
extensions which are often broken by new major versions.
I wanted to make a boolean Obsoletes:
`Obsoletes: (firefox-esr52 if %{name})`
but it is not allowed:
```
ошибка: строка 8: No rich dependencies allowed for this type: Obsoletes:
(firefox-esr52 if task-firefox_esr)
```
I understand why Provides cannot be boolean, but do not see
Thanks for explaining!
> Why not add the Obsolete to the firefox-esr78 packages as soon as
> firefox-esr52 is outdated (no longer supported)
That can be done, but may break extensions and established workflows
--
You are receiving this because you are subscribed to this thread.
Reply to this
The same problem is with any other spec preamble tag
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I want to build subpackages `%{name}-build-deps` and put them into a separate
repository like -debuginfo subpackages.
Such package would depend from what is BuildRequires in the spec/SRPM. The
purpose is to work with build-deps repository using `dnf reqpoquery
--whatrerquires` dnf `dnf
And I cannot add exporting macros easily like:
```diff
diff --git a/build/parsePreamble.c b/build/parsePreamble.c
index ac3d9159e..1e3c55a1b 100644
--- a/build/parsePreamble.c
+++ b/build/parsePreamble.c
@@ -1048,6 +1048,7 @@ static int findPreambleTag(rpmSpec spec,rpmTagVal * tag,
> I don't think this is a bug, it behaves exactly like `%{version}`. You'll
> always get the values of the last definition for the macros, i.e. from the
> last subpackage.
>
> If you want the definitions of the main package, you're supposed to uppercase
> the macro names, e.g. `%{EPOCH}` and
Will it work correctly when BRs are generated by a generator
(%generate_buildrequires)? Will the `%buldrequires` macro have a correct value
including the results of that generation? I am trying to understand why "Macros
are unsuited to the task".
--
You are receiving this because you are
> This is intentional, see commit
> [7ca0392](https://github.com/rpm-software-management/rpm/commit/7ca03925d88d27266a4f8bec7a35e8c3b1117279)
>
> Macros are unsuited to the task, you'd need access to the headers under
> construction and that's a can of worms I'm not willing to look into.
So,
[user@rosa2019 tmp]$ sudo rpm -e --nodeps -vh gnome-session gnome-session-bin
[sudo] пароль для user:
ошибка: "gnome-session-bin" specifies multiple packages:
gnome-session-bin-40.1.1-8.x86_64
gnome-session-bin-40.1.1-8.x86_64
[user@rosa2019 tmp]$ sudo rpm -e --nodeps -vh gnome-session
I don't think that many things parse output of rpm -q, because it gives a
correct exit code, but maybe I am too optimistic
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
It was printed to stdout:
$ LC_ALL=C.UTF-8 rpm -q --qf %{version} kernel-source-nvidia390
2/dev/null || echo 0
package kernel-source-nvidia390 is not installed
0
But I wanted to define a version of rpm package as an rpm macro:
%define nvidia_390_n %(rpm -q --qf %%{version}
Thanks, forgot about it. But error messages acould be somehow more obvious
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
There is a package "setup" which contains sceleton files /etc/shadow,
/etc/shadow, /etc/passwd, /etc/group etc.
Files /etc/shadow and /etc/gshadow are owned by root:shadow:
%attr(0440,root,shadow) %config(noreplace,missingok) %{_sysconfdir}/shadow
%attr(0440,root,shadow)
> `chgrp` in the `%post` scriptlet should do the trick - although I admit it is
> not a great solution
Yeah, it is what I did, but in %posttrans, to lighten dependency graph. But the
warning from rpm is still present.
> I still have this vivid memory of rpm no longer using the the files from
by the way, I am not sure that root:shadow owner of /etc/shadow makes sense,
Fedora uses just root:root
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> > Commit
> > [f9c7b53](https://github.com/rpm-software-management/rpm/commit/f9c7b53f50adc129baee809692d4c80b3bd15432)
> > is supposed to be a no-op, so if that is the thing changing behavior then
> > we need to look at it, I don't remember any intentional change to this
> > effect anyway.
The following scriptlet worked ok in rpm 4.15 and 4.16:
```
%post -p
if arg[2] >= 2 then
vr = posix.stat("/var/run")
<...>
```
But it stopped working in rpm 4.17:
```
lua script failed: [string "%post(filesystem-2.1.9-48.x86_64)"]:2: attempt to
compare number with string
```
I am not an
> It won't solve the issue though, as the group still doesn't exist when the
> files are created
But it is possible to chown by a numeric UID/GID, isn't it?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
`%_docdir` macro is used multiple times in `macros.in`:
```
%__global_requires_exclude_from %{?_docdir:%{_docdir}}
%__global_provides_exclude_from %{?_docdir:%{_docdir}}
```
```
%___build_pre \
<>
RPM_DOC_DIR=\"%{_docdir}\"\
```
The problem is that this macro is not
Is it a bug or not?
--
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/1745#issuecomment-886640177___
Rpm-maint mailing list
We in ROSA rosa2021.1 in rpm 4.17 restored removed stuff with a patch
(https://abf.io/import/rpm/blob/rosa2021.1/0024-Restore-python-helpers.patch),
now in the new platform rosa2023.1 I am updating rpm from 4.17 to 4.18 and will
try to use
Do any RPM distros use
https://github.com/rpm-software-management/python-rpm-packaging ?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-1594614838
You are receiving this because you are subscribed to this thread.
93 matches
Mail list logo
