cc @davide125
--
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/1485#issuecomment-758602337___
Rpm-maint mailing list
@hroncok
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1320#issuecomment-663508390___
Rpm-maint mailing list
@ignatenkobrain commented on this pull request.
> +to run this command (followed by new dependency resolution) repeatedly until
> it
+no longer exits with code 11.
```suggestion
to run this command (followed by installation of the generated dependencies)
repeatedly
until no new dependencies
@ignatenkobrain approved this pull request.
>From my POV it is good to go and we can follow up with improvements like
>auto-detection of cores.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ignatenkobrain commented on this pull request.
> @@ -256,6 +266,18 @@ options are currently set in
\fIrpmrc\fR and
\fImacros\fR
configuration file(s).
+.SS "DYNAMIC BUILD REQUIREMENTS"
+.PP
+When the %generate_buildrequires stage is executed and some of the resulting
+requirements are not
@ignatenkobrain commented on this pull request.
> @@ -256,6 +266,18 @@ options are currently set in
\fIrpmrc\fR and
\fImacros\fR
configuration file(s).
+.SS "DYNAMIC BUILD REQUIREMENTS"
+.PP
+When the %generate_buildrequires stage is executed and some of the resulting
+requirements are not
@hroncok @torsava take a look please :)
--
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/1317#issuecomment-662881689___
Rpm-maint
@mlschroe works for me too :)
--
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/1314#issuecomment-662318724___
Rpm-maint mailing
So the `%define`/`%global` is a stack-based, however sometimes you want to
undefine variable no matter how many times it was defined. I think
`%undefine_all` would be the best name.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
@ignatenkobrain commented on this pull request.
> @@ -1072,6 +1072,7 @@ static rpmzstd rpmzstdNew(int fdno, const char *fmode)
char *t = stdio;
char *te = t + sizeof(stdio) - 2;
int c;
+int threads = -1;
```suggestion
int threads = 0;
```
to satisfy @ffesti
--
You
@ignatenkobrain approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> no matter if all build requires are installed
because rpmbuild does not check them because `--nodeps` is specified :) So for
rpmbuild none are installed.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> it compresses a bit worse
I was testing it on xonotic-data and it was 873M in single-threaded compression
and the same size in multi-threaded mode.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ignatenkobrain approved this pull request.
LGTM with very small suggestion.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ignatenkobrain commented on this pull request.
> goto err;
}
+
+ if (threads == -1)
+ threads = rpmExpandNumeric("%{getncpus}");
+ if (threads > 1)
After all I think
```suggestion
if (threads > 0)
```
should be used.
--
You are receiving
With my suggestions, and a proper build of libzstd in Fedora it works as
expected, it fully utilizes my system. Testing on `xonotic-data` which is 873M.
```
before:
284.05user 3.03system 4:48.64elapsed 99%CPU (0avgtext+0avgdata
153540maxresident)k
88inputs+5456312outputs
@ignatenkobrain commented on this pull request.
> goto err;
}
+
+ if (threads > 0)
```suggestion
if (threads == -1)
threads = rpmExpandNumeric("%{getncpus}");
if (threads > 0)
```
--
You are receiving this because you are subscribed to this
@ignatenkobrain commented on this pull request.
> goto err;
}
+
+ if (threads > 0)
+ if (ZSTD_isError (ZSTD_CCtx_setParameter(_stream, ZSTD_c_nbWorkers,
threads)))
Oh my, Fedora ships libzstd without MT support. ignore this one.
--
You are receiving this
@ignatenkobrain commented on this pull request.
> goto err;
}
+
+ if (threads > 0)
+ if (ZSTD_isError (ZSTD_CCtx_setParameter(_stream, ZSTD_c_nbWorkers,
threads)))
hmmpf, this always gives me an error on Fedora Rawhide:
```
warning: zstd library does not
@ignatenkobrain commented on this pull request.
> goto err;
}
+
+ if (threads > 0)
+ if (ZSTD_isError (ZSTD_CCtx_setParameter(_stream, ZSTD_c_nbWorkers,
threads)))
+ rpmlog(RPMLOG_WARNING, "zstd library does not support
multi-threading");
@ignatenkobrain commented on this pull request.
> + ++s;
+ c = *s;
```suggestion
c = *s++;
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@marxin I've tried this on my laptop and it does not seem to work?
```
$ /usr/bin/time ~/Projects/upstream/rpm/rpmbuild -bb xonotic-data.spec -D
"_sourcedir $PWD" -D "_binary_payload w19T8.zstdio"
...
289.90user 3.08system 4:54.67elapsed 99%CPU (0avgtext+0avgdata
155348maxresident)k
@ignatenkobrain commented on this pull request.
> goto err;
}
+
+ if (threads > 0)
hmmm, thinking about it more..
```
/* These parameters are only useful if multi-threading is enabled (compiled
with build macro ZSTD_MULTITHREAD).
```
And checking code, yeah - it
@ignatenkobrain commented on this pull request.
LGTM with small nitpicks
> goto err;
}
+
+ if (threads > 0)
If I read https://facebook.github.io/zstd/zstd_manual.html correctly, even if
you set it to `0`, it will use single thread which makes this if unneeded.
> @@
@ignatenkobrain commented on this pull request.
>AS_IF([test "$enable_zstd" = "yes"], [
if test "$have_zstd" = "no"; then
AC_MSG_ERROR([--enable-zstd specified, but not available])
fi
])
+ PKG_CHECK_MODULES([ZSTD], [libzstd], [have_zstd=yes], [have_zstd=no])
I think it
I did take quick look into the code base: for `%doc` the `addSpecialFile()` is
used that just inserts file entries. That does not copy files into the
%{_docdir}. Rather, it is done from `processPackageFiles() ->
processSpecialDir()` at which point it already packages the RPM. The `%exclude`
is
I think it would be quite useful to implement this and should not be very hard,
in theory... Still, you should just wipe those files and not use %exclude for
that. I think that is on the roadmap that it will throw unpackaged files if you
%exclude files and do not put them anywhere.
--
You are
Just curious, what's your use-case?
--
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/1297#issuecomment-652382807___
Rpm-maint
I think we should keep it for master and revert fo 4.16
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Generally you should try out #1239 , but for that you need to find out few
things.
How do you detect a binary that will want to load some specific translations?
Is it just some guess or should be up to packager to fill in or?
--
You are receiving this because you are subscribed to this
Can you elaborate more please? What missing / unpacked files, waht subpackages,
what report?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
:tada:
Would be nice to get that into 4.16.
--
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/1271#issuecomment-645323467___
@ignatenkobrain approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Seems to fix my problem :)
--
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/1265#issuecomment-641855601___
Rpm-maint mailing list
Backported to rawhide & fixed in master.
--
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/1261#issuecomment-640492804___
Closed #1261.
--
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/1261#event-3419175160___
Rpm-maint mailing list
Sent patch yesterday https://github.com/rpm-software-management/rpm/pull/1259
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I think this should set _with_check unless _without_check is defined already.
Basically to have `%bcond_without check` by default without having to put it in
all spec files. But still need to make sure that somebody defines
`%bcond_without check`, this code won't override it.
--
You are
```
❯ sudo rpm -ivh
/home/brain/rpmbuild/RPMS/x86_64/newsflash-1.0~rc1-1.fc33.x86_64.rpm --debug
--rpmfcdebug
[sudo] password for brain:
D: ==
/home/brain/rpmbuild/RPMS/x86_64/newsflash-1.0~rc1-1.fc33.x86_64.rpm
D: loading keyring from pubkeys in /var/lib/rpm/pubkeys/*.key
D:
Also I checked `stat /usr/share/icons/hicolor/icon-theme.cache` and that does
not change during the RPM run. But if I run command from trigger manually, it
updates that file.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> 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.
I think I disagree here, it is only some specific cases where this needs to be
used.
cc
Please backport to 4.16.x
--
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/1259#issuecomment-640211823___
Rpm-maint mailing list
Somehow it wasnt noticed before.
Fixes: 9464926456125dacb8046767f1fe4235471986e9
Signed-off-by: Igor Raits i.gnatenko.br...@gmail.com
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1259
-- Commit Summary
@ignatenkobrain approved this pull request.
LGTM
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai fixed and rebased.
--
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/1235#issuecomment-636714949___
Rpm-maint mailing
As you can see, I'm touching rpmbuild code, morning else. So this should not
break.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai oh, in that case - I would ditch bdb backend and possibly enable
bdb_ro by default for 4.17 and then in 4.18 disable it by default.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai I think we need to deprecate it in 4.17 and ditch it in 4.18 while
keeping bdb_ro only.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
:rocket: :+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/pull/1245#issuecomment-635278798___
Rpm-maint mailing list
```
RPM build errors:
line 223: %package -n rust-libc-devel: package rust-libc-devel already
exists
fish: Job 2, “~/Projects/upstream/rpm/rpmbuil…” terminated by signal SIGSEGV
(Address boundary error)
```
Segfault if the package redefinition happens is not expected.
---
```
error: line
@pmatilai hopefully should be fixed and rebased.
--
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/1235#issuecomment-634501079___
I would move `import re` to the top imports and just be done with it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Fine with me, did not want to get this in 4.16 anyway :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
makes sense, I can rework tarball case to create tempdir and set _specdir
there. I guess we can drop creation of sourcedir as well.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ignatenkobrain commented on this pull request.
> @@ -451,6 +453,7 @@ const char * rpmSpecGetSection(rpmSpec spec, int section)
case RPMBUILD_BUILD:return getStringBuf(spec->build);
case RPMBUILD_INSTALL: return getStringBuf(spec->install);
case RPMBUILD_CHECK:
@ignatenkobrain commented on this pull request.
> +while (1) {
+ if ((rc = _readLine(spec, 0, 1)) > 0) {
+ res = PART_NONE;
+ break;
+ } else if (rc < 0) {
+ res = PART_ERROR;
+ break;
+ }
+ if (!strncmp(spec->line, "%%end",
Some bikeshedding here: I'd call it `%generate_spec` because that's what it
essentially is for.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai FYI, this case have been fixed. This PR works fine from my testing.
Sorry, forgot to type this before :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Btw, I have sent https://github.com/rpm-software-management/rpm/pull/1235 to
avoid printing warnings in the CLI when using %{name} in the %{_sourcedir}:
https://github.com/rpm-software-management/rpm/pull/1235
--
You are receiving this because you are subscribed to this thread.
Reply to this
Ehh, it seems that this breaks building from tarball :/
I'll check if I can make it work.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I guess this might affect some kind of %include usage, but the difference
between not being able to read file from folder that does not exist or from the
folder that does and is empty is not something what we should be worried about
I think.
--
You are receiving this because you are
.
Signed-off-by: Igor Raits i.gnatenko.br...@gmail.com
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1235
-- Commit Summary --
* rpmbuild: Create build tree after parsing a spec file
-- File Changes --
M rpmbuild.c (14
So I have discussed this privately with @decathorpe and the issue here is in
rpmdev-spectool as I guessed.
Next time, please open issues with as much information as possible and a
minimal reproducer.
Ref: https://pagure.io/rpmdevtools/issue/40
--
You are receiving this because you are
Closed #1234.
--
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/1234#event-3360119174___
Rpm-maint mailing list
Probably you can paste the spec file here and method how to reproduce? Probably
it is `rpmdev-spectool` does something wrong with it…
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> I guess the easiest way to provide this is a spec file section that is not
> evaluated at parse time but is parsed after the build. We might want to
> disallow some things there but it will basically allow declaring sub
> packages. These could also be created by macros or by scripts
I think `%{upstream_version}` would be better. However, probably in this case,
we should just define %{pypi_version}, %{semver_version} because those have
different rules.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Can you provide a reproducer? We use rich dependencies in BuildRequires at
least in 2000 packages in Fedora.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ignatenkobrain pushed 1 commit.
e0d63c40c4eef27b45791130858bf6e97c985922 macros: Drop internal macros which
are not used in RPM and Fedora
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@pmatilai too late , but I will split PR in to small commits.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1211#issuecomment-626622183___
Those are either not used or almost not used in whole collection of
Fedora spec files. Neither they are used anywhere in RPM internally.
References: https://github.com/rpm-software-management/rpm/issues/1211
Signed-off-by: Igor Raits i.gnatenko.br...@gmail.com
You can view, comment on, or merge
>
> Note that %__remsh (and through that, %__rsh and %__ssh) are actually used by
> rpm itself (in %___build_cmd) for remote execution of build scripts (a kind
> of cross-build setup).
Ah, that is trivial.
```
801:%___build_cmd %{?_sudo:%{_sudo} }%{?_remsh:%{_remsh}
> Note that %__remsh (and through that, %__rsh and %__ssh) are actually used by
> rpm itself (in %___build_cmd) for remote execution of build scripts (a kind
> of cross-build setup).
hmm, probably I did not notice that.
> The selinux stuff can probably go without further ado, ditto with the
>
Most of __id_u occurrences are from BuildRoot definition. The javadir and
javadocdir are overriden by javapackages, so I'd proposed to keep:
```
%__sed
%__cp
%__mv
%__cc
%__cxx
%__cpp
```
the rest IMO can be dropped without problems.
--
You are receiving this because you commented.
Reply to
@pmatilai in Fedora specs, rough numbers are:
```
%_javadir - 209
%__sed - 168
%_javadocdir - 114
%__cp - 113
%__mv - 76
%__cc - 72
%__ln_s - 24
%__id_u - 20
%__ar - 19
%__cxx - 15
%__grep - 7
%__file - 4
%__as - 3
%__ranlib - 2
%__chgrp - 2
%__restorecon - 1
%__cpp - 1
%_unzipbin - 0
%__ssh - 0
> It is user friendly. It is not maintenance friendly because it workarounds
> rpm deficiencies. A lot of the complexity is simulating arrays from
> individual suffixed variables when rpm does expose an array element.
That is exactly why I said having new section like `%subpackages` where
> A lot of those things are already handled Fedora-side in our fonts and go
> packaging macros.
Sorry, I'm not interested in this black magic which nobody except you
understand. I am interested in user-friendly solution which is supposed to be
implemented in RPM.
> You end up with a huge list
Oh yeah, this way we can solve problem described in #1073 but having some
script which will put license thing into the `$pkgname.license`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Forgot to mention that %subpackages section should store files in the
%{buildroot} too, so that there is possibility to write generators which would
depend on whole state of subpackages (current problem with dependency
generators).
--
You are receiving this because you are subscribed to this
So I guess this is waiting for me to put my thoughts here…
# Features (extras)
* In Rust, `Cargo.toml` contains information about all "features" which should
be in their own subpackages, like `%package devel+$FEATURE`.
* In Python, `egg-info` or `dist-info` or similar contain info about
> For no real value, yes but still they do are used in the wild and so the
> potential for breakage is quite wide…
Of course, but it is not different from changing other behaviors of RPM. Those
macros are not documented, they are explicitly described as *private to RPM* so
I think making such
Also we probably should rethink `%_(build|host|target)_*` macro. They are not
really used by RPM for anything, rpmPlatform() has its own auto-detection
anyway. I guess they were meant for RPM to support cross-compilation, but this
never happened from what I know.
Probably best would be to get
Basically these macros do not seem to belong to RPM at all:
```diff
--- a/macros.in
+++ b/macros.in
@@ -26,35 +26,18 @@
%__awk @AWK@
%__bzip2 @__BZIP2@
%__cat @__CAT@
-%__chgrp @__CHGRP@
%__chmod @__CHMOD@
-%__chown
I was looking into the macros which RPM ships and there are many things like
aforementioned %__ranlib which is not used in the RPM at all but has been there
forever (at least from 1998).
>From what I understand, %__* is supposed to be something which can affect RPM
>itself, the %_* is for
@DimStar77 ,
> Just to chime in here as well: openSUSE has the 'distro bootstrap' split and
> tries to keep it under control. It's right that python3 is already in that
> chain (we build python3 is a minimal set with as few deps as possible, and an
> enhanced set, in two runs)
I am curious,
85 matches
Mail list logo
