Oh my. Thanks for sharing, I'll check that.
--
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/1290#issuecomment-648804803___
@dmnks commented on this pull request.
> +to run this command (followed by new dependency resolution) repeatedly until
> it
+no longer exits with code 11.
OK, thinking about it more, a situation could arise where a missing dep can't
be resolved or installed (with `dnf builddep`) for whatever
@dmnks pushed 1 commit.
c9b9a299d93ead98e1f05098b3f80d46f8813153 Docs: Add DYNAMIC BUILD DEPENDENCIES
section
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks commented on this pull request.
> +to run this command (followed by new dependency resolution) repeatedly until
> it
+no longer exits with code 11.
New revision force-pushed.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1318
-- Commit Summary --
* Docs: Revamp BUILD OPTIONS section in rpmbuild(8)
* Docs: Add note on buildreqs.nosrc.rpm and code 11
-- File Changes --
M doc/rpmbuild.8
@dmnks 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 satisfied,
@dmnks 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 satisfied,
@dmnks 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 satisfied,
> > no matter if all build requires are installed
>
> because rpmbuild does not check them because `--nodeps` is specified :) So
> for rpmbuild none are installed.
Which does not necessarily mean that they are *missing*. But yeah, we still
return 11, to "signal" that the deps weren't checked
This issue stems from the fact that the line continuation marker `\` has
*different* semantics in the spec-level context and in a macro definition. On
the spec level, it is used to break long `%if` statements into multiple lines.
Inside macro definitions, it's the whole body that's broken down.
This is because of the `rpmio/digest_libgcrypt.c:rpmDigestLength()` function
not recognizing the `PGPHASHALGO_GOST12_256` and `PGPHASHALGO_GOST12_512` enums
introduced in the [RPM 5 patch for
Streebog](https://abf.io/staszhukov/rpm/blob/master/1082-add-GOST-R-34.10-2012-gcrypt-imaevm.patch).
Closed #959.
--
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#event-3588768486___
Rpm-maint mailing list
@dmnks commented on this pull request.
> +to run this command (followed by new dependency resolution) repeatedly until
> it
+no longer exits with code 11.
Yeah, "new dependency resolution" sounds a bit awkward and isn't exactly clear.
Will fix.
As for the "until" clause, I wonder if
Also, if we decide to go with the messages in the end, we should end them with
a `\n`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
LGTM, thanks!
--
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/1313#issuecomment-661722877___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
Merged #1313 into master.
--
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/1313#event-3570031458___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
@dmnks 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 satisfied,
@dmnks pushed 1 commit.
96bf7343c84bf463baf7eb0f40a617c9019dd74f Docs: Add note on buildreqs.nosrc.rpm
and code 11
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 1 commit.
6c358561b2b7593c9717797305d96d4133140ba6 Docs: Add note on buildreqs.nosrc.rpm
and code 11
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Closed #1185.
--
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/1185#event-3604860188___
Rpm-maint mailing list
So I did some more testing and it turns out, after all, that rpmbuild only
spends a tiny fraction of time in the `processPackageFiles()` function;
dependency generators (kmod.prov in particular) are a much bigger bottleneck
but also vastly trickier to parallelize.
The speed improvements that I
LGTM
--
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/1450#issuecomment-735747755___
Rpm-maint mailing list
@dmnks pushed 1 commit.
2730ecbae50d766829d324af2f25065037eecb76 Indent
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Fixed here: https://github.com/rpm-software-management/rpm/pull/1455
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Fix up for commit 6a780f1.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1455
-- Commit Summary --
* Really disable OpenMP if too old
-- File Changes --
M configure.ac (1)
-- Patch Links --
@dmnks approved this pull request.
> @@ -383,12 +385,22 @@ static char * getTarSpec(const char *arg)
if (!gotspec) {
rpmlog(RPMLOG_ERR, _("Failed to read spec file from %s\n"), arg);
- specFile = NULL;
+} else {
+ /* remove trailing \n */
+
Closed #1454.
--
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/1454#event-4067094114___
Rpm-maint mailing list
OK. In that case, there *is* one thing to be done, which is to fix the bug in
that check (that I mentioned above). I'll do that, and close this PR. Thanks!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Oh, no worries at all, we are in agreement here. That said, in this particular
case, I don't consider the time wasted since it helped me find a little bug in
the openmp check which has confused a couple of people already, and has a
trivial solution :)
--
You are receiving this because you are
LGTM :smile:
--
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/1457#issuecomment-740570412___
Rpm-maint mailing list
@dmnks pushed 6 commits.
1c332a1cfd24ce98c0a765f93ac3d45c819df376 Add rpmlogPrettyPrint() function
09be300f7c97f8959c2ba983af079af413ca6d72 Refactor
2f05222886e6927a97b944d3029eed52a361e8b8 Ensure EOL in last line buffer
44c98a8a0d01e9ba7bfca3a3c986df1165219335 NOEOL
@dmnks pushed 2 commits.
6fbfcfe7bb1dce6ce926602d6bc5800150c17994 Add rpmlogGetNrecsByMask() function
a520b3fabbb744163cb9cad2441976e001549ec8 Add summary
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
> I was about to ask whether you're expecting a review on this (generally PR's
> with failing tests will not be looked at), but then I noticed this is a
> "draft", I didn't even know GH has such a (handy looking) feature so thanks
> for the tip
Yeah, it's nice. It's just the `[WIP]` prefix,
Sorry... wanted to give a peek, but of course, didn't make a note in my todo
list, so there you go... I'll check it nevertheless, as part of the BZ backport
that I'm assigned to :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Thank you. This is indeed a bug in the configure script. We shouldn't apply the
`OPENMP_CFLAGS` macro if we just evaluated that the required version of OpenMP
is not available. Let me fix that quickly.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
I can see two aspects being discussed here:
1) We don't want to error out if OpenMP is older than expected. This is what
happens at the moment, though - we only error out if `--enable-openmp` is
issued, but not otherwise.
2) We want to allow builds without OpenMP support. This is already
All that being said, I wonder if making OpenMP's `priority` support itself
optional (which is the reason for mandating version 4.5 in the first place)
wouldn't be better after all, especially considering that this is not the first
issue reported after the OpenMP version
@dmnks commented on this pull request.
> FD_t fd = NULL;
static const char *tryspec[] = { "Specfile", "\\*.spec", NULL };
-if (!(fd = rpmMkTempFile(NULL, )))
+specDir = rpmGetPath("%{_tmppath}", NULL);
Cosmetic: For clarity, I would move this line to before the `specBase =`
Other than my inline comments, looks good to me!
--
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/1397#issuecomment-735952852___
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1454
-- Commit Summary --
* Fix
* Drop dependency on OpenMP 4.5
* Add conditional for OMP priority clause
-- File Changes --
M INSTALL (7)
M build/pack.c (4)
@dmnks commented on this pull request.
> @@ -22,6 +22,10 @@
#include "debug.h"
+#if _OPENMP < 201511
+#define priority(x)
Hmm, now that I think about it - wouldn't this be too brittle a macro? What if
we define/include a function `priority()` in the future? Wouldn't this replace
it?
--
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1429
-- Commit Summary --
* Add each macro for concise log queue iteration
* Extract log iteration from rpmlogPrint()
* Print only errors in rpmbuild summary (#793)
--
Correct, this is caused by the compiler not supporting some of the OpenMP
features (it's actually the `priority` clause). We've added a check into the
`configure` script recently to "fix" this: #1325
--
You are receiving this because you are subscribed to this thread.
Reply to this email
@dmnks pushed 1 commit.
5f79f49e1b331bef57c46303f7648280b36ee9e7 Add section for warnings to rpmbuild
output
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 2 commits.
fd4e326f52a9a62fd9a665636be13c0efbfd1b0e Ensure EOL in last line buffer
8173d570998a91ade0c27e35d8ecd86f21c64a19 NOEOL
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Closed #1420.
--
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/1420#event-4210938187___
Rpm-maint mailing list
This has been resolved by #1455 (as also discussed in #1433), so closing now.
Thanks again!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@dmnks commented on this pull request.
> @@ -633,7 +633,17 @@ assert(otherFi != NULL);
rConflicts = handleColorConflict(ts, fs, fi, i,
otherFs, otherFi, otherFileNum);
- if (rConflicts && reportConflicts) {
+
@dmnks commented on this pull request.
> @@ -633,7 +633,17 @@ assert(otherFi != NULL);
rConflicts = handleColorConflict(ts, fs, fi, i,
otherFs, otherFi, otherFileNum);
- if (rConflicts && reportConflicts) {
+
@dmnks commented on this pull request.
> @@ -633,7 +633,17 @@ assert(otherFi != NULL);
rConflicts = handleColorConflict(ts, fs, fi, i,
otherFs, otherFi, otherFileNum);
- if (rConflicts && reportConflicts) {
+
@dmnks commented on this pull request.
> @@ -633,7 +633,17 @@ assert(otherFi != NULL);
rConflicts = handleColorConflict(ts, fs, fi, i,
otherFs, otherFi, otherFileNum);
- if (rConflicts && reportConflicts) {
+
@dmnks pushed 1 commit.
3522418539d20a4e2871e17daaab213b441528cb Allow file namesakes on symlink->dir
replacement
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 1 commit.
45211103cea7452ae4c6bab24e46ba836a0d6967 Allow file namesakes on symlink->dir
replacement
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Spurious file conflicts may appear when a package update replaces a
directory symlink with a plain directory *and* also installs the same
file name(s) in it, but with different contents, as is the case with
RhBug 1936422:
$ rpm -i /path/to/squid-4.rpm
$ rpm -ql squid-4:
...
These were found by static analysis (Coverity).
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1734
-- Commit Summary --
* Fix memory leak in sqlexec()
* Always free the arg list passed to rpmGlob()
* Fix resource leak
@dmnks pushed 0 commits.
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1734/files/96896bd3692a900cf7e50722503c2af7d6dadeb3..268643ddca0121facb6b0e5cb5e887a160fa4907
These curly brackets are already treated as literals by the shell, so
lets make that explicit for clarity, and silence a Coverity warning at
the same time.
More info: https://github.com/koalaman/shellcheck/wiki/SC1083
Found by ShellCheck.
You can view, comment on, or merge this pull request
@dmnks pushed 2 commits.
ddcd717b69591342faec6ccdb83fed964ea5edb9 Fix memory leak with multiple %lang-s
in one line
f997e9da2c54d160a773dd528459cea469ec2d3b Fix memory leaks in Lua rex extension
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Otherwise SecureBoot signatures may be stripped too.
We used to exclude shared libraries from this strip as they were
supposed to be covered by another brp script (brp-strip-shared), however
it turned out the latter was never really used, so we removed the
exclusion in commit
Yup, that's correct - they would be skipped by the loop anyway (and calling
`strip(1)` on them would have no effect either).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Please see commit messages for more info.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1591
-- Commit Summary --
* Ensure EOL in last line buffer parsed from spec
* Drop extra newlines from spec parser messages
--
Anyway, no point in arguing about the proper status. It is a defect which we'd
like to fix at some point, so let's reopen. There are higher priority items at
the moment, but we do have other such long-standing issues open for tracking
purposes, too.
--
You are receiving this because you are
Reopened #1473.
--
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/1473#event-4499000879___
Rpm-maint mailing list
Whether or not a patch will be accepted has nothing to do with the status of
this issue.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Forgot to reference this issue directly in the above commit (with a "Fixed:
#1444" in the commit message), so closing manually.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #1444.
--
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/1444#event-4506693758___
Rpm-maint mailing list
Also, it would be nice to mention in the commit message why the type check is
being changed. In the case of `rpmtsObject_Check`, it's to allow for passing an
`rpm.TransactionSet` instance to `rpm.spec()` which is not of the built-in
`rpmts_Type` class that we define in C, but rather of a
@dmnks pushed 1 commit.
92971cc4a66853b22582830564aba3a46acd2607 Collapse unexpanded macro definitions
(#1198)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@pmatilai, do we want to re-open this RFE/bug and keep it open in the long run?
The help page has its shortcomings for sure, but I'm not sure if we want to
track stuff that's not worked on currently.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
I should've mentioned in the commit message that this wasn't intended as a 100%
fix of all the messages that print a spec line. Although I did, of course, look
through all of them in `parseSpec.c`, so that file is covered.
--
You are receiving this because you are subscribed to this thread.
> FYI, a PR with failed checks will generally not get much attention. This
> looks like it just needs some test output updated to the new reality. That
> case is actually a good argument for the change, the newline(s) make no sense
> at all.
Yeah, I'll fix that.
> I'm inclined to think the
Looking again, it seems like we already do store the length, in `ofi->readPtr`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> On a related note, we could use a dedicated spec error reporting function.
> Our error messages are _all over_ the place in terms of formatting and style.
> If there was one place to fixup such things...
>
> (and here we have another seemingly trivial ting threatening to quickly
> escalate
OK, turns out the other `parse*.c` files also emit such messages.
So my next plans are:
1. Check if the extra newlines are also present with the other messages that
format a spec line (outside of `parseSpec.c`)
2. See if we could have a specialized logging function for spec parsing
Confusingly, the RPM build errors section also includes messages
logged as warnings. That gives the false impression that they somehow
contributed to the actual build failure and therefore were turned into
errors.
This appears to be a historical artifact; when a message passes through
the
@dmnks pushed 1 commit.
d63e9bdaaf6b69c34136a608319e93d20a93fc06 Separate build warnings from error
summary
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
FWIW, the way I use Podman here is pretty much the same - I just bind-mount my
git checkout into the container and do the building and testing (including
running the testsuite) from there. I do have a fancy
[script](https://github.com/dmnks/dotfiles/blob/master/utils/bin/codebox) for
making
Correct; it's a Fedora-based image, similar to our
[ci/Dockerfile](https://github.com/rpm-software-management/rpm/blob/master/ci/Dockerfile).
You're right - Re-reading her comment, it does seem she's using an empty image,
after all. Something like toolbox, in fact.
I wonder, though - what
Containers aside, I'm still now sure why the `TMPDIR` variable would be set to
anything other than a directory?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
That said, I don't want to discourage you (or anyone, really) from exploring
this in more detail. There certainly are ways to make this better (it is not
great at the moment, we all agree).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
I didn't mention this explicitly (sorry), but the usage string is generated
automatically from the *same data* (popt tables) that the sections in the
longer `--help` output are.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
> I consider the following approach less confusing:
>
> ```
> Query options:
> --queryretrieve information
> about packages
> etc.
> ```
>
> It would help if we could rearrange the sections so that mode selectors come
> up first.
You
> How about the following approach:
>
> ```
> -q, --queryretrieve information about packages, in
> particular:
Yes, that would be an improvement.
However, my worry would be that the user would still need to read the
description of the first option on the list, in
Oh, indeed. Thanks for spotting this!
Also kudos for checking for the `fprintf()` return value - although it still
returns a positive value in case of an `ENOSPC`, there could be other errors,
so why not check for them right away.
That said, I realized I should've moved the `free(val)`
I routinely do a `make check` in Podman containers and never encountered this
issue. Is there some specific set-up (of the testsuite) that you're referring
to?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merged #1566 into 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/pull/1566#event-4460234433___
Rpm-maint mailing list
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/pull/1566#issuecomment-799620888___
Rpm-maint mailing list
What you're looking for is the `%{quote:...}` macro, documented
[here](https://rpm.org/user_doc/macros.html).
Example without the quote macro:
```
$ rpm --define 'hello() %{**}' --eval "%hello 1 2"
1 2
```
And with the macro:
```
$ rpm --define 'hello() %{**}' --eval "%hello 1 %{quote:
Closed #1439.
--
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/1439#event-4390300429___
Rpm-maint mailing list
Closed #1429.
--
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/1429#event-4402868369___
Rpm-maint mailing list
Thanks, Mirku, for looking into this! I like the simplicity of your solution,
here's how it would look like:
```
Usage: rpm [-afgplsiv?] [-a|--all] [-f|--file] [-g|--group] [-p|--package]
[--pkgid] [--hdrid] [--triggeredby] [--whatconflicts] [--whatrequires]
[--whatobsoletes] [--whatprovides]
This is a bit more complicated than one would think. The `--query` option is
deliberately hidden from the usage/help output because there simply isn't a
good help section to house it:
```
$ rpm --help
[...]
Query/Verify package selection options:
Query/Verify file selection options:
Query
Closed #1473.
--
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/1473#event-4371833918___
Rpm-maint mailing list
This is a known limitation in RPM, but there's a simple workaround, see below.
The way RPM
[derives](https://github.com/rpm-software-management/rpm/blob/d601a7b7ae764b31ad74b2dceff1eafb5297147f/build/parsePreamble.c#L125)
the target file name from a Patch/Source tag is by taking everything
Closed #1407.
--
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/1407#event-4396891954___
Rpm-maint mailing list
Since --eval only has one job - to actually *print* something to stdout,
we should fail completely if thats not possible due to an external
error, instead of just not printing anything. One particular case is
redirecting stdout to a file on a file system thats full (generating
the ENOSPC error).
LGTM
--
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/1535#issuecomment-778130486___
Rpm-maint mailing list
Closed #1519.
--
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/1519#event-4324579306___
Rpm-maint mailing list
Thanks, closing in lieu of
https://github.com/rpm-software-management/rpm-web/issues/19.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hmm, although it would probably be easier to just allow a list of package in
the `--add-install` and `--add-erase` options themselves:
```
--add-install foo,bar --add-erase baz
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
101 - 200 of 1032 matches
Mail list logo
