On my rawhide box, the config.sub from rpm-build and automake-1.13 seem
to support aarch64 already whereas the ones provided by libtool,
redhat-rpm-config, and older automakes do not.
I would suggest to use automake's version also. It is the place where the
config.{guess,sub} files come
Background story is in rhbz#1374138, having the warning better
spelled before would simplify macro debugging a lot in that case.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/91
-- Commit Summary --
* build: better
You can probably use ``` for diffs.
Is the 'second' correct? I way about to use `multiple` because the warning can
occur several time for each (sub)package.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
xref: https://bugzilla.redhat.com/show_bug.cgi?id=1443034
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
If we had `%build_requires -f
On Saturday, February 17, 2018 7:40:53 AM CET Jeff Johnson wrote:
> If -- as this RFE seems to assume -- you are going to limit the implementation
> to "... (Rust, Python, golang) ..." that have alternative non-specfile means
> to specify BuildRequires, then all known rpm build systems will
On Saturday, February 17, 2018 12:08:53 AM CET Jeff Johnson wrote:
> @nim-nim: there are classes of BuilRequires: that are not known until after a
> build
This sounds interesting, don't you have specific example? It rather
sounds like bootstrapping issue which the BuildRequires generator isn't
On Saturday, February 17, 2018 9:57:13 AM CET nim-nim wrote:
> > [snip, mock could ... ]
> > - does installroot and installs BuildRequires as usually
> > - runs %prep
> > - runs %foo_analyzer from %build_requires
> > - runs the rest of the build
> [snip]
>
> That would work too, as long as you
> With git clone so easy nowadays I'm pretty sure some of the language
> upstreams will bake multi-phase BR solving in their tooling sooner or later
> (if not already done).
Seeing an existing example would really help to justify the additional
complexity.
Such problem smells like equivalent
On Saturday, February 17, 2018 7:18:47 AM CET Jeff Johnson wrote:
> Contrarian examples are trivial to devise. Consider an autoconf based
> generated file that builds if (and only if) certain files are detected.
> None of those BuildRequires can be automated and generated during a spec
> file
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/452
-- Commit Summary --
* Fix typo in trigger docs
-- File Changes --
M doc/manual/triggers (2)
-- Patch Links --
Some RPM installed `%( shell )` macros pollute stderr (under e.g. `rpmbuild
-bs`) if some of their run-time dependencies is missing, e.g.:
```
%python_sitelib %(%{__python} -Es %{_rpmconfigdir}/python-macro-helper sitelib)
%python_sitearch %(%{__python} -Es %{_rpmconfigdir}/python-macro-helper
Good one, thanks! ;) And yeah, maybe this is more like "documentation fix"
request, or request like "hey, rpm maintainers, please show us exemplary
rock-solid macros ...". Because RPM is certainly not responsible for all those
kind of errors.. But with all the minimization efforts, those "No
That's interesting think for policy POV, thanks. That would certainly be an
issue for FESCO before allowing us to use that in Fedora. But I don't think it
is necessarily a blocker for the actual implementation in mock/rpm.
--
You are receiving this because you are subscribed to this thread.
On Thursday, October 25, 2018 11:23:58 AM CEST Florian Festi wrote:
> There are two options:
> [..second option..] This seem much more fragile and dangerous as it
> requires root operations being triggered from a non root build.
1. You **wouldn't** trigger root actions (the fact that pm_request
On Saturday, October 20, 2018 2:51:03 PM CEST nim-nim wrote:
> So, with a year of hindsight, I've simplified the requirements to
>
> 1. run `%prep`
> 2. run BuildRequires computation logic (either as part of prep or in a new
>`%reqs` section between prep and build)
I'd still prefer the
Of course, the SRPM format needs to be updated first; so we can store the
dynamic build requires "unexpanded" there.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I proposed somewhere above a %build_requires (with some options, too), but that
would probably be too huge overlap, right? Can we operate with brackets or
options? Like `%dynamic_requires -t build`?
--
You are receiving this because you are subscribed to this thread.
Reply to this email
> But for determining the dynamic BuildRequires (or even just running %prep) you
will need additional tools. So the question is where do you get the Requires
from for these.
You have static `BuildRrequires` for this puprose. Those should be installed
first, so
the dynamic build requires can be
praiskup commented on this pull request.
> +}
+
+fprintf(fp, "cd '%s'\n", buildDir);
+
+if (spec->buildSubdir)
+ fprintf(fp, "cd '%s'\n", spec->buildSubdir);
+fprintf(fp, "%s", getStringBuf(spec->buildrequires));
+(void) fclose(fp);
+
+if (test) {
+ rc =
@xsuchy wrote:
> What exit code rpmbuild returns when a build fails because of
> %generate_buildrequires?
I'd say it can be non-zero, as mock doesn't necessarily have to expect a
"specific" exit status in this case. Yes, specific exit status would make it
easier for mock, but I fail to see
On Tuesday, March 12, 2019 9:55:29 AM CET nim-nim wrote:
> I think there are two different things here, how you format rpmbuild error
> output to stdou/err
Why we should care about 'rpmbuild' stdout/stderr here? That should be
just informative thing. For machines, rpmbuild just fails, and doing
praiskup commented on this pull request.
> +// XXX set flags
+
+rpmdsPutToHeader(*packageDependencies(spec->sourcePackage,
RPMTAG_REQUIRENAME), spec->sourcePackage->header);
+
+rpmps ps = rpmSpecCheckDeps(ts, spec);
+
+if (ps) {
+ rpmlog(RPMLOG_ERR, _("Failed build
BuildRecommends is semantically wrong, if it happens to be needed then it is
needed (not recommended).
These problems have no solution on SRPM level. Unless the spec file is
preprocessed by rpm, no-one knows whether the package will depend on dynamic
buildrequires feature or not.
If
https://github.com/rpm-software-management/mock/issues/432 is probably related
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Because it uses systemd-nspawn, I guess.
--
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/978#issuecomment-566432700___
I thought that `-f` is better, because of the "reversed" patch semantics
reject. But the
fix should IMO go to redhat-rpm-config, not to RPM if this was implemented.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> And here it hangs and waits for user input.
Weird, the patch file should go to patch from stdin ... so there should be
clear EOF, and patch shouldn't really wait for anything. Is that bug in patch?
--
You are receiving this because you are subscribed to this thread.
Reply to this email
Do we have to bind the nosrc.rpm with exit status 11?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> Whether SRPM uses DynamicBuildRequires feature
This is can not be answered, though, by looking at the SRPM. It depends on what
system the srpm is built on. It is similar to conditional BuildRequires, etc.
> Whether SRPM has DynamicBuildRequires inserted into it
You mean whether RPM has some
Yes, from mock perspective it shouldn't be huge problem (I guess we'll
stop depending on defaults, and pre-define some pattern by macros). Still,
having a month or two in advance to have a chance to wrap new mock
release is worth it. What is the ETA, and any more details how the new
pattern will
No thoughts from me ATM. I think mock will have to adapt, whatever change
will be done here (mock uses target-chroot rpmbuild).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> We cannot rely on this file if we want rpm to be able to auto-download
> sources with any degree of confidence.
Why? _Technically_ there shouldn't be a problem.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
>From the manual page it isn't entirely clear:
```
-baBuild binary and source packages (after doing the %prep, %build,
and %install stages).
-bbBuild a binary package (after doing the %prep, %build, and
%install stages).
-bs
Shouldn't we at least document somewhere what the exit status 11 means then?
Ie why
we are returning that value?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Is this contribution ever meant to modify the built source RPM content?
I.e. can `%postbuild` be (mis-)used so that `rpmbuild -ba` and `rpmbuild -br`
both generate a different variant of source RPM?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
> My guess is you want that rpmbuild man page is more clear
Yes.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> or missing build deps (11)
Yes, and we return 11 also when `--nodeps` is specified (no matter if all build
requires are installed).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> So for rpmbuild none are installed.
I don't see any practical reason to exit status 11 in such case. That's why I
filled this issue originally.
Since we aren't entirely consistent here, we should document that exit status
11 might be result of the `--nodeps` option.
--
You are receiving
Yes, that's what I meant. Some implicit hook in %prep implementation, or
before.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Lemme know if you think that some PoC macro in /usr/lib/rpm/macros.d doing
exactly
this would be useful (as first %prep instruction).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Could RPM hook in a check right before executing `%prep` section if e.g. macro
like
`%global source_1_sha256 ` is defined? Older RPM implementations
would
just ignore such macro.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
> This is mixing two separate issues. The one originally discussed here is
> about RPM respecting the config/macro files in the target root when
> called with --root. Populating the root with the desired configuration
> is a then a separate matter and one that would need to be discussed on
>
Yes, correct.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2623#issuecomment-1758963263
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing
When we talk about configuration, what's meant by that? All macro definitions?
Because there seems to be an issue with `/etc/rpm/macros.image-language-conf`
like things.
As you asked for ideas; I think there's a space for a low-level,
distro-specific, rpm-sub-package that would install the
E.g. Red Hat UBI images contain:
```
[root@c5436d2dbebf /]# cat /etc/rpm/macros.image-language-conf
%_install_langs C.utf8
```
This though affects `dnf --installroot` using `rpm --root`:
```
$ podman run --privileged -it --rm registry.access.redhat.com/ubi9/ubi
[root@85d37140e490 /]# cat
In Copr, we "prolong" the expiration time of GPG keys with `gpg --edit-key`,
with `expire` => `5y` => `save` commands. See the [Copr
issue](https://github.com/fedora-copr/copr/issues/2878) for more info. After
this action, RPM stops trusting all the signatures done _before_ the time of
`gpg
Thank you for your comment. I wish you stated your opinion on what to do about
this. But to me it eventually doesn't seem that much controversial to just
remove the `/etc/rpm/macros.image-language-conf` file, which will lead to the
default `%_install_langs all` behavior. This is likely the
See also: https://github.com/rpm-software-management/rpm/issues/424
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/919#issuecomment-1562765066
You are receiving this because you are subscribed to this thread.
Message ID:
Could the default %clean script automatically change the mode of directories
before doing `rm -rf`? To avoid build failures caused by unsuccessful `rm`
calls:
```
$ mkdir nonremovable
$ touch nonremovable/protect-parent
$ chmod a-r nonremovable
$ rm -rf nonremovable/
rm: cannot remove
Let me just back-reference https://bugzilla.redhat.com/show_bug.cgi?id=1134397
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2631#issuecomment-1823540534
You are receiving this because you are subscribed to this thread.
Message ID:
The last time I observed (few years ago in 1464368) the tooling did not seem to
exist. Would you mind providing such a tool in glibc-devel?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2872#discussioncomment-8241796
You are
Seems related https://bugzilla.redhat.com/show_bug.cgi?id=2266553
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2872#discussioncomment-8615424
You are receiving this because you are subscribed to this thread.
Message ID:
Agreed, especially with the [CI gating
part](https://matrix.to/#/!IHsypFkurbRbXzkjTO:matrix.org/$Jo1uzuG9SVrm__zmNvoYXXI2EarBYgIt-WdTu8TPBVg?via=fedora.im=matrix.org=fedoraproject.org).
--
Reply to this email directly or view it on GitHub:
I hit this accidentally with `rpm-build-4.19.91-1.fc41.x86_64` (not yet build
in Rawhide, or already untagged, not sure). Happened to me when I was
reproducing [FTBFS against a Copr project that contained that pre-release
version](https://bugzilla.redhat.com/show_bug.cgi?id=2279987).
Mock
Corresponding
[line-in-Mock-code](https://github.com/rpm-software-management/mock/blob/3986df1555780b76811b5aa1c199429ee8b09cc0/mock/py/mockbuild/backend.py#L792).
--
Reply to this email directly or view it on GitHub:
Hehe, this is a complete coincidence (no prior talk with Miro about this) - I
just debugged two FTBFSs the Python team opened (weeks ago) against the
packages I maintain. Kudos the Python team can explore these problems before
they even land Rawhide!
--
Reply to this email directly or view
> They can affect the build in a different way depending whether its run
> multiple times, there's no guarantee of indempotence there.
It would be nice if we started a separate Mock issue, not to steal the topic
here. Maybe the related #1358. There are these premises:
- Mock has to repeat
58 matches
Mail list logo
