Re: [Rpm-maint] [rpm-software-management/rpm] Remove remaining Python helpers and scripts from the repo (#1607)
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 https://github.com/rpm-software-management/python-rpm-packaging , but I am a bit confused because it seems that nobody really uses them and there is even no Makefile or instruction how to install it (of course it is quite clear where to put different files, but still...). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1607#issuecomment-1594619197 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove remaining Python helpers and scripts from the repo (#1607)
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. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Print that package is not installed into stderr (#1794)
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: https://github.com/rpm-software-management/rpm/pull/1794#issuecomment-93788___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Print that package is not installed into stderr (#1794)
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}
kernel-source-nvidia390 | awk -F . {print $2} || echo 0)
...
Requires:
(kmod-nvidia390.%{nvidia_390_n}-kabi(5.10.71-generic-1rosa2021.1-x86_64) if
nvidia390)
However, when SRPM was built, kernel-source-nvidia390 was not installed, and
output to stdout went into the value of the macro.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1794
-- Commit Summary --
* https://github.com/rpm-software-management/rpm/pull/1794/commits/a625a8e0538f4b53eb49b2fe7e371a8364da78a0;>Print
that package is not installed into stderr
-- File Changes --
M lib/query.c (2)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/1794.patch
https://github.com/rpm-software-management/rpm/pull/1794.diff
--
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/1794
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] No way to get rid of duplicated packages of ther same NEVR (#1792)
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: https://github.com/rpm-software-management/rpm/issues/1792#issuecomment-938418434___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] No way to get rid of duplicated of ther same NEVR (#1792)
[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 gnome-session-bin-40.1.1-8.x86_64 gnome-session-bin-40.1.1-8.x86_64 ошибка: "gnome-session-bin-40.1.1-8.x86_64" specifies multiple packages: gnome-session-bin-40.1.1-8.x86_64 gnome-session-bin-40.1.1-8.x86_64 ошибка: "gnome-session-bin-40.1.1-8.x86_64" specifies multiple packages: gnome-session-bin-40.1.1-8.x86_64 gnome-session-bin-40.1.1-8.x86_64 I have duplicated packages of the same NEVR, seems that there is no way to delete them using rpm cli. -- 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/1792___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] [regression?] rpm 4.17 can't find group declared inside sceleton package (#1789)
> 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: https://github.com/rpm-software-management/rpm/issues/1789#issuecomment-933409187___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] [regression?] arg[2] to lua scriptlet became a string instead of number (#1790)
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 expert in lua, but `2` here seems to be an integer, not a string.
I can suspect commit
https://github.com/rpm-software-management/rpm/commit/717a3f7ecf0af7c453cd1bcb3f49b5ea4941817e
"Pass install scriptlet arguments to Lua as real local arguments", it states
that "Lua will automatically convert numbers as necessary so this should not
break anything", but seems that it broke something.
I "fixed" the problem by just removing that scriptlet because it is not needed
any more
(https://abf.io/import/filesystem/commit/5806ae4e0504314bdcd0417be94d4637d76d3eb1)
but it looks like an unexpected breakage.
--
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/1790___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] [regression?] rpm 4.17 can't find group declared inside sceleton package (#1789)
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: https://github.com/rpm-software-management/rpm/issues/1789#issuecomment-932683903___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] [regression?] rpm 4.17 can't find group declared inside sceleton package (#1789)
> > 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. That doesn't change the fact that rpm cannot bootstrap > > user/group info, never could. > > What is the “correct” way to do this? Explicit chown in a postinst script? > Write the files using Lua in a pretrans script? Is lua in rpm able to call chown() without the chown usitility from coreutils being present in the new chroot? -- 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/1789#issuecomment-932683758___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] [regression?] rpm 4.17 can't find group declared inside sceleton package (#1789)
> `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 > outside the chroot. But I can't find anything to support that... +1, I have the same thoughts -- 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/1789#issuecomment-932682952___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] [regrerssion?] rpm 4.17 can't find group declared inside sceleton package (#1789)
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) %config(noreplace,missingok) %{_sysconfdir}/gshadow
Group shadow is defined inside those sceleton files.
rpm 4.16 worked ok, but rpm 4.17 cannot find group shadow and uses root.
nscd is not running.
--
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/1789___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Boolean (rich) Obsoletes (#1772)
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 email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1772#issuecomment-919444977___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Boolean (rich) Obsoletes (#1772)
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. We want to ship ESR Firefox and/or Thunderbird in the distro ISO, but we do not want to keep old ESR installed after it becomes EOLed. So, the idea was to make a package `task-thunderbird` which would depend from thunderbird-78, later from thunderbird-83 etc. The problem is that conflicts between deiiferent versions of thunderbird prevents dnf from installing task-thunderbird despite the old version of thunderbird becoming orphaned. -- 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/1772#issuecomment-914248759___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Boolean (rich) Obsoletes (#1772)
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 reasons why package
%name cannot Obsolete firefox-esr52 only if %name is installed and do not
obsolete it if it is 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/1772___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Obsoleted-by: would be useful in some cases (#1768)
> 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`, it's up to the > distro to use that. +1 Different sonames can be packaged in packages with different names -- 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/1768#issuecomment-914229084___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: export preamble tags as macros (#1753)
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 subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1753#issuecomment-896764780___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %epoch is defined globally if is set only in one subpackage (#1745)
> 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 `%{VERSION}`.
Thanks a lot!
--
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-896762044___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: export preamble tags as macros (#1753)
> 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,
```diff
diff --git a/build/parsePreamble.c b/build/parsePreamble.c
index ac3d9159e..f90ae4b15 100644
--- a/build/parsePreamble.c
+++ b/build/parsePreamble.c
@@ -1020,7 +1020,7 @@ static struct PreambleRec_s const preambleList[] = {
{RPMTAG_BUILDARCHS,0, 0, 0, LEN_AND_STR("buildarch")},
{RPMTAG_BUILDCONFLICTS,0, 0, 0, LEN_AND_STR("buildconflicts")},
{RPMTAG_BUILDPREREQ, 0, 1, 0, LEN_AND_STR("buildprereq")},
-{RPMTAG_BUILDREQUIRES, 0, 0, 0, LEN_AND_STR("buildrequires")},
+{RPMTAG_BUILDREQUIRES, 0, 0, 1, LEN_AND_STR("buildrequires")},
{RPMTAG_AUTOREQPROV, 0, 0, 0, LEN_AND_STR("autoreqprov")},
{RPMTAG_AUTOREQ, 0, 0, 0, LEN_AND_STR("autoreq")},
{RPMTAG_AUTOPROV, 0, 0, 0, LEN_AND_STR("autoprov")},
```
will do the job? Commit 7ca0392 closed issue
https://github.com/rpm-software-management/rpm/issues/689 , it looks alike
https://github.com/rpm-software-management/rpm/issues/1745
Will such change allow to redefine buildrequires in unpredictable ways? I think
it will not?
Why will such a change be worse than "access to the headers under construction"?
--
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/1753#issuecomment-896761772___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: export preamble tags as macros (#1753)
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,
rpmlog(RPMLOG_WARNING, _("line %d: %s is deprecated: %s\n"),
spec->lineNum, p->token, spec->line);
}
+ rpmPushMacro(NULL, p->token, NULL, spec->line, RMIL_GLOBAL);
break;
}
if (p == NULL || p->token == NULL)
```
because:
1. BuildRequires can be formed from multiple preamble lines
2. `spec->line` will be not the value of the tag 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/issues/1753#issuecomment-896758491___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: export BuildRequires as a macro (#1753)
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: https://github.com/rpm-software-management/rpm/issues/1753#issuecomment-896755711___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RFE: export BuildRequires as a macro (#1753)
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 repoclosure`.
Currently I build such packages with a script:
https://abf.io/import/rpm-mk-build-deps/blob/rosa2021.1/rpm-mk-build-deps.sh
I tried to do like `%_debuginfo_template`:
```
%package build-deps
Summary: Build dependencies of %{name}
Group: Development/Debug
AutoReq: 0
AutoProv: 1
Requires: %{buildrequires}
%description build-deps
Build dependencies of %{name}
%files build-deps
```
but macro `%buildrequires` does not exist, so I cannot get BuildRequires from
inside the same spec.
--
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/1753___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %epoch is defined globally if is set only in one subpackage (#1745)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] %_docdir is not defined (#1746)
`%_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 defined by default. Some usages of it in
`macros.in` assume that it can be not defined, but some assume that is is
defined.
Also I do not see differences with `%_defaultdocdir`.
soemthing seems to be wrong 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/issues/1746___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't brp-strip .ko files (#1744)
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: https://github.com/rpm-software-management/rpm/pull/1744#issuecomment-878384188___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't brp-strip .ko files (cfdb830)
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/commit/cfdb8300f6e3aed0abc41406a3c4737eb1192067#commitcomment-53373486___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Don't brp-strip .ko files (#1744)
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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Use `%_platform_multiplier'` (#1700)
> 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: https://github.com/rpm-software-management/rpm/issues/1700#issuecomment-878382861___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %epoch is defined globally if is set only in one subpackage (#1745)
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
%build
%install
echo %{epoch} > %{buildroot}/epoch.txt
```
Build packages: `rpmbuild -bb rpm-1745.spec`
Check epochs:
```
$ rpm -qp --qf '%{epoch}\n' rpm-1745-0-0-rosa2019.1.x86_64.rpm
rpm-1745-sub1-0-0-rosa2019.1.x86_64.rpm
(none)
2
```
They are correct. But "2" was written to "epoch.txt".
--
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-878305718___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] %epoch is defined globally if is set only in one subpackage (#1745)
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 with kernel modules are generated here:
[2] https://abf.io/mikhailnov/kernel-5.4/blob/cd156877bc/macros.ksobirator#lc-30
[3] https://abf.io/mikhailnov/kernel-5.4/blob/cd156877bc/kernel.spec#lc-840
Macro is defined in [2] and is used in [3]. Macro `%{EVRD}` is used in [2]. It
is defined in ROSA and OpenMandriva in `/usr/lib/rpm/openmandriva/macros` as
the following:
`%EVRD %{?epoch:%{epoch}:}%{?version:%{version}}%{?release:-%{release}}`
And here the resulting subpackages are not intallable:
```
DEBUG util.py:621: Problem 1: conflicting requests
DEBUG util.py:621:- nothing provides kernel-5.4-generic(x86-64) =
1:5.4.130-1 needed by kernel-module-vboxsf-5.4-generic-5.4.130-1.x86_64
DEBUG util.py:621: Problem 2: conflicting requests
```
It is because it should have required "kernel-5.4-generic(x86-64) = 5.4.130-1"
without Epoch.
So, the macro `%epoch` is leaked from a subpackage to the global world.
--
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___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Use `%_platform_multiplier'` (#1700)
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 mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Please provide source package name to dependency generators (#1736)
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: https://github.com/rpm-software-management/rpm/issues/1736#issuecomment-878294691___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add a build root policy for removing executable bits from shared libr… (#1395)
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: https://github.com/rpm-software-management/rpm/pull/1395#issuecomment-734501309___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add a build root policy for removing executable bits from shared libr… (#1395)
@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 systems will want /usr/local/bin (`./configure --bindir= --prefix=) 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/1395#pullrequestreview-539570683___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] elfdeps: Generate dependencies on non-executable shared libraries (#1393)
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 used for that... > Are dependency generators run after %__spec_install_post / brp-strip? -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1393#issuecomment-734499098___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm --whatrequires does not resolve provides (#1426)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] rpm --whatrequires does not resolve provides (#1426)
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 `java-1.8.0-openjdk-devel` was installed and make a query: ``` $ rpm -q --whatrequires java-1.8.0-openjdk-devel no package requires java-1.8.0-openjdk-devel ``` But: ``` $ rpm -q --whatrequires java-devel wildfly-10.1.0-14.noarch ``` I expected to see `wildfly` in the output of `rpm -q --whatrequires java-1.8.0-openjdk-devel`. Is it a bug or a feature? RPM is 4.16.0: ``` user@ROSA-Nickel ~ $ rpm -q rpm rpm-4.16.0-6.x86_64 ``` -- 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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] __spec_*_shell macros do not work (#1399)
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:
https://github.com/rpm-software-management/rpm/issues/1399#issuecomment-708218687___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] __spec_*_shell macros do not work (#1399)
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` does work, but defines shells for all sections (%prep, %build, %install). To my mind `__spec_prep_shell ` is the shell which is used to execute the %build script, no? I cannot find where `__spec*shell` macros are used in the code, they seem to be dead. -- 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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] elfdeps: Generate dependencies on non-executable shared libraries (#1393)
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 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-706605898___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] elfdeps: Generate dependencies on non-executable shared libraries (#1393)
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 Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] elfdeps: Generate dependencies on non-executable shared libraries (#1393)
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 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-706604955___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add support for fsverity signatures (#1121)
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 directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1121#issuecomment-703518161___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add tag with %{NAME} of SRPM (#1364)
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: https://github.com/rpm-software-management/rpm/issues/1364#issuecomment-697122139___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add tag with %{NAME} of SRPM (#1364)
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 to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1364#issuecomment-695352021___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add tag with %{NAME} of SRPM (#1364)
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. Why
can't there be a tag the value of which will be just "metacity"?
--
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/1364___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] 4.15.1: issue with debug info stipping procedure (#1362)
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: https://github.com/rpm-software-management/rpm/issues/1362#issuecomment-695348482___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm -q --whatrequires loosing packages (#1342)
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: https://github.com/rpm-software-management/rpm/issues/1342#issuecomment-678501299___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] rpm -q --whatrequires loosing packages (#1342)
``` 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 package requires bootsplash live@rosa2019 ~ $ rpm -qR Rosa-theme-EE /bin/sh /bin/sh /bin/sh bootsplash >= 3.3.0 plymouth-plugin-script >= 0.8.2 plymouth-system-theme rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 live@rosa2019 ~ $ ``` `rpm -q --whatrequires bootsplash` must have shown Rosa-theme-EE and bootsplash-themes but has not. BerkelyDB is used for now. Seems to be a bug. If it is useful, this is an out of the box issue in this LiveCD: https://abf.io/platforms/rosa2019.1/products/273/product_build_lists/34888 -- 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/1342___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Treat /usr/share/gnome/help as docs (#1295)
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 documentation (for example, if someone wants to reduce disk usage by not installing documentation, he will also not want help files), so lets add them to the default %__docdir_path You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1295 -- Commit Summary -- * Treat /usr/share/gnome/help as docs -- File Changes -- M macros.in (2) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1295.patch https://github.com/rpm-software-management/rpm/pull/1295.diff -- 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/1295 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add OrderWithRequires dependency generation (32e2bc5)
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: https://github.com/rpm-software-management/rpm/commit/32e2bc50cff9db05729349ff6645a0251d5719fb#commitcomment-39775833___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add OrderWithRequires dependency generation (#1257)
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 them, but I'm not sure. ``` # rpm -E %systemd_ordering OrderWithRequires(post): systemd OrderWithRequires(preun): systemd OrderWithRequires(postun): systemd ``` Implemention of Requires(pre) etc. generators will be ugly because it will requires to add each RPMTAG separately. It would be nice if the generator could print e.g. `post: xxx` to stdout, but it cannot be implemented with the current architecture of generators as far as I understand. Scriptlets can be converted into files (https://github.com/rpm-software-management/rpm/issues/1033#issuecomment-583142300), it would easify making generators for them. @Conan-Kudo pointed that most scriptlets are designed to fail silently, e.g. scriptlets that call `systemctl` fail silently if systemd is not installed, what allows to make a minmal system aithout systemd. Adding 'Requires(pre): systemd' will break this usecase. 'OrderWithRequires(pre): systemd' would solve that. In some other cases it is useful to make sure that the binary which is called is already installed and has all its dependencies satisfied when the scriptlet is executed. `bash --rpm-requires` can be used to generate (OrderWith)Requires for scriptlets. Maybe generatore 'Provides: cmd(xxx)' for files inside /sbin /usr/sbin /bin /usr/bin and convert the output of `bash --rpm-requires` to 'OrderWithRequires(scriptlet type): cmd(xxx)' These are just some thoughts... -- 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/1257#issuecomment-641245796___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add OrderWithRequires dependency generation (32e2bc5)
@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 %__find_orderwithrequires because I am not sure how it should work, probably off the internal dependency generator and define this macro? Which variant is correct? -- 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/commit/32e2bc50cff9db05729349ff6645a0251d5719fb#commitcomment-39774778___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add OrderWithRequires dependency generation (#1257)
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 GitHub: https://github.com/rpm-software-management/rpm/pull/1257#issuecomment-641206157___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add OrderWithRequires dependency generation (#1257)
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 email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1257#issuecomment-640264300___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add OrderWithRequires dependency generation (#1257)
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 directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1257#issuecomment-640263148___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fail the build if %_build_pkgcheck_set failed (#1258)
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: https://github.com/rpm-software-management/rpm/pull/1258#issuecomment-640224570___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Fail the build if %_build_pkgcheck_set failed (#1258)
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 this pull request online at: https://github.com/rpm-software-management/rpm/pull/1258 -- Commit Summary -- * Fail the build if %_build_pkgcheck_set failed -- File Changes -- M build/pack.c (7) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1258.patch https://github.com/rpm-software-management/rpm/pull/1258.diff -- 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/1258 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add OrderWithRequires dependency generation (#1257)
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 ensure that systemd is installed before that package. It will help to avoid adding %systemd_ordering manually to all packages using systemd. Having systemd preinstalled before packages with systemd scriptlets is really important, otherwise those scriptlets fail silently, and the resulting ISO or chroot may be broken. The same makes sense for e.g. systemd-sysusers, systemd-tmpfiles. An RPM generator using this functionality was implemented: https://abf.io/import/order-rpm-generators Rebuilding packages with systemd stuff in rosa2019.05 using this generator has already helped to improve installation order, e.g. make e.g. openvpn be installed when systemd already exists in a big transaction with ~3500 packages when building a big ISO image. Before that openvpn was installed when systemd did not exist yet. P.S. This patch adds %__find_orderwithrequires, maybe that is legacy code that should not be changed. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1257 -- Commit Summary -- * Add OrderWithRequires dependency generation -- File Changes -- M build/rpmfc.c (10) M build/rpmfc.h (7) M tools/rpmdeps.c (6) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1257.patch https://github.com/rpm-software-management/rpm/pull/1257.diff -- 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/1257 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add support for fsverity signatures (#1121)
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: https://github.com/rpm-software-management/rpm/issues/1121#issuecomment-600920484___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add znver1 arches with 32-bit + 64-bit variants and proper CPU detection (#1035)
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 may be turned on by a macro and thay can be automatically put to packages of an optimized subarch. -- 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/1035#issuecomment-596231656___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add znver1 arches with 32-bit + 64-bit variants and proper CPU detection (#1035)
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 do not forget about function multiversioning in Clear Linux - this is when some specific libraries are compiled in different variants. I think that here a more generic approach is needed. In the vast majority of cases building packages for an a86_64 subarch like znver1 will not make sense, for example, is there a reason to make and test by QA separate variants of e.g. lightdm, sddm, plasma5-workspace, thunar, nautilus etc.? Is there any reason to spend resources on testing a separate branch of packages? OpenMandriva does not have QA mostly, they probably did not consider this aspect. So, to my mind, a more generic approach must allow to build only some special packages for a subarch and keep most of the packages of the main architecture. Something like function multiversioning intergated into the packaging system. -- 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/1035#issuecomment-596158605___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %patch from not the start of the line does not work (#1088)
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 directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1088#issuecomment-591927356___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] %patch from not the start of the line does not work (#1088)
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 make it work in rpm 4.15.1. -- 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/1088___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add ability to calculate filedigests using Streebog-256 and Streebog-… (#1082)
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: https://github.com/rpm-software-management/rpm/pull/1082#issuecomment-590254191___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add ability to calculate filedigests using Streebog-256 and Streebog-… (#1082)
> 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 anything elsewhere in RPM? -- 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/1082#issuecomment-590251268___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add ability to calculate filedigests using Streebog-256 and Streebog-… (#1082)
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 */
+PGPHASHALGO_GOST12_256 = 100, /*!< GOST R 34.11-2012 256 */
+PGPHASHALGO_GOST12_512 = 101, /*!< GOST R 34.11-2012 512 */
@mlschroe What is "the GOST project"? I am not aware of any attempts to include
GOST to OpenPGP RFC, but maybe someone tried, I do not know. We in ROSA with
@StZhukov first wanted to implement signing RPM payload with GOST as it is
signed with gpg, but then we found out that OpenPGP RFC does not support GOST,
so implementing it does not make much sense. I would not expect GOST algos to
appear in the RFC in the nearest future. Because of all this I would suggest to
use values >110 here, which are not specified in the RFC and so will never
become used by other algorithms.
--
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/1082#discussion_r382622766___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Process scriplets by dependency generators (#1033)
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 "Requires(pre)" or "Requires(post)" needed here, only just "Requires". Does e.g. `dnf `guarantee that "Requires" are installed before %pre and %post are executed? I am pretty sure that no. ` %__scriptlets_directory` can be removed before packing the package or can be left, e.g. if `%__scriptlets_directory_remove` == 0. -- 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/1033#issuecomment-583142300___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Process scriplets by dependency generators (#1033)
`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 you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1033#issuecomment-583138042___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Process scriplets by dependency generators (#1033)
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: https://github.com/rpm-software-management/rpm/issues/1033#issuecomment-583109582___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Process scriplets by dependency generators (#1033)
> 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 already interesting. -- 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/1033#issuecomment-583108854___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Process scriplets by dependency generators (#1033)
```
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}
macros.in-923-#%__spec_autodep_post %{___build_post}
```
What is this and what do they do?
--
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/1033#issuecomment-582670875___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Process scriplets by dependency generators (#1033)
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: https://github.com/rpm-software-management/rpm/issues/1033#issuecomment-582021939___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Process scriplets by dependency generators (#1033)
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, than it will be a big win to set correct order of installing packages, I am pretty sure. -- 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/1033#issuecomment-581984720___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Print all build errors and do not stop after the first error (#1020)
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 to see if %_debug_package is %nil to disable filtering
*.debug files?
--
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/1020#discussion_r373877391___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add znver1 arches with 32-bit + 64-bit variants and proper CPU detection (#1035)
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: https://github.com/rpm-software-management/rpm/pull/1035#issuecomment-581179453___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] elfdeps: Add full multiarch deps support (#1038)
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 mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Process scripltlets by dependency generators (#1033)
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 is already possible or not and cannot find relevant code where dependencies by shebang are generated for scriptlets. Is it possible to do, and where is that code? -- 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/1033___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Print all build errors and do not stop after the first error (#1020)
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 everybode will have ```%__check_files``` defined to that
script?
--
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/1020#discussion_r373415590___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Print all build errors and do not stop after the first error (#1020)
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 *.debug files are odd there, may be you know how to fix
it rather simply?
--
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/1020#discussion_r372304597___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Print all build errors and do not stop after the first error (#1020)
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 used, e.g. in parseForSimple() and in many other palces (`grep
-nHr 'res ='`) and usage of `res` there is much more alike the case that we are
dicscussing than usage of `rc`
--
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/1020#discussion_r372284493___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Print all build errors and do not stop after the first error (#1020)
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 restore `rc` if it is a common variable across the whole code
--
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/1020#discussion_r372127007___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Print all build errors and do not stop after the first error (#1020)
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 code", res stands for "result", "return code" is not what
this variable means
--
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/1020#discussion_r372126274___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Print all build errors and do not stop after the first error (#1020)
@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/339a3ac7d5b1961fbfbaa37b87958bc225fb528f..e6eb6a3caa22ae4332433b23c440322d6980ddf1 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Print all build errors and do not stop after the first error (#1020)
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 printed both not found and unpackaged files, and this RPM 4 behaviour
seems to cause waste of a lot of time.
Lets print both not found and not packaged files and all other errors that
have happened.
TODO: eliminate `*.debug` from the output. Current output is like this:
```
error: Installed (but unpackaged) file(s) found:
/usr/lib/debug/usr/lib64/pulse-13.0/modules/module-gsettings.so-13.0-2.x86_64.debug
/usr/lib/debug/usr/libexec/pulse/gsettings-helper-13.0-2.x86_64.debug
/usr/libexec/pulse/gsettings-helper
File not found:
/tmp/abf/rpmbuild/BUILDROOT/pulseaudio-13.0-2.x86_64/usr/lib64/pulse/gsettings-helper
Installed (but unpackaged) file(s) found:
/usr/lib/debug/usr/lib64/pulse-13.0/modules/module-gsettings.so-13.0-2.x86_64.debug
/usr/lib/debug/usr/libexec/pulse/gsettings-helper-13.0-2.x86_64.debug
/usr/libexec/pulse/gsettings-helper
```
I do not know yet how to deal with `*.debug`, any ideas?
Also I am not sure about possible side effects.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1020
-- Commit Summary --
* Print all build errors and do not stop after the first error
-- File Changes --
M build/files.c (17)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/1020.patch
https://github.com/rpm-software-management/rpm/pull/1020.diff
--
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/1020
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Document RPM generator input and output format (#1011)
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: https://github.com/rpm-software-management/rpm/issues/1011#issuecomment-575351245___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Document RPM generator input and output format (#1011)
> 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 now. It is better now. But still it is not clear that it must print e.g not `Requires: xxx`, but just `xxx`. -- 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/1011#issuecomment-575350441___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Document RPM generator input and output format (#1011)
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: https://github.com/rpm-software-management/rpm/issues/1011#issuecomment-574770755___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Document RPM generator input and output format (#1011)
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, `find-provides.php` uses just
`echo`
(https://github.com/rpm-software-management/rpm/blob/master/scripts/find-provides.php#L14).
Also in https://rpm.org/user_doc/dependency_generators.html it is first written:
"generation of Provides: and Requires:"
but then examples are givven for recommends etc.
--
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/1011#issuecomment-574765409___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Document RPM generator input and output format (#1011)
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 `pkgconfigdeps.sh`, tried to make the same output format, but it still does not work. Neither stdout not stderr are printed. But, if I run it locally, it works correctly: `` ` bash-4.4# ls /usr/lib64/*.so | $(rpm --eval %__devel_provides) 2>/dev/null devel(libBrokenLocale(64bit)) devel(libanl(64bit)) devel(libatomic(64bit)) devel(libc(64bit)) devel(libcrypt(64bit)) devel(libdl(64bit)) <...> ``` Just as `pkgconfigdeps.sh`: ``` bash-4.4# ls /usr/lib64/pkgconfig/*.pc -1v | /usr/lib/rpm/pkgconfigdeps.sh --provides pkgconfig(libzstd) = 1.4.3 pkgconfig(popt) = 1.16 pkgconfig(rpm) = 4.15.1 ``` Example build log with this generator enabled: https://abf.io/build_lists/3186141 Currently the output method is: ``` echo -n "$@ " echo ``` (https://abf.io/import/devel-rpm-generators/blob/rosa2019.1/develgen.sh#lc-7) It is like https://github.com/rpm-software-management/rpm/blob/master/scripts/pkgconfigdeps.sh#L34 Please help to understand what is wrong in https://abf.io/import/devel-rpm-generators/ . There is no documentation. -- 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/1011___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] xzdio: Add line break to warning (#1007)
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 -- https://github.com/rpm-software-management/rpm/pull/1007.patch https://github.com/rpm-software-management/rpm/pull/1007.diff -- 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/1007 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Incorrect length of unknown filedigest algos (#959)
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: https://github.com/rpm-software-management/rpm/issues/959#issuecomment-570789766___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Incorrect length of unknown filedigest algos (#959)
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 aa4ae578ca2323caf35beab739f88ea577ab0119063b1aa47954cbe92b686fbc 0100755 root root 0 0 0 X ``` Now let's do the same using RPM 4 (and 5 as well) which does not know about Stribog: ``` $ rpm -qp --dump ./grep-3.3-3-rosa2019.0.i586.rpm /bin/egrep 28 1574950717 aa4ae578ca2323caf35beab739f88ea5 0100755 root root 0 0 0 X $ rpm --version RPM version 4.14.2.1 ``` The length of the hash is incorrect. ``` aa4ae578ca2323caf35beab739f88ea577ab0119063b1aa47954cbe92b686fbc aa4ae578ca2323caf35beab739f88ea5 ``` I think it is a bug, RPM should have failed to print hashes, but may be it is a feature... As I did not investigate the issue, I can't say anything about its root cause, may be the size of the hash is not stored anywhere? That RPM: https://file-store.rosalinux.ru/download/948bd31596c572664b870a226f252e38707ad137 (grep-3.3-3-rosa2019.0.i586.rpm) -- 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/959___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
