@xsuchy,
> 2.1) dnf install $(rpm -qpR foo.buildreqs.nosrc.rpm)
Please use `dnf builddep --srpm foo.buildreqs.nosrc.rpm` instead.
---
I think that 2.3 should be 'repeat until no new dependencies appear' or
something like this.
--
You are receiving this because you are subscribed to this thr
In Mock, I plan to have this workflow:
1) rpmbuild
2) if exit code == 11
2.1) dnf install $(rpm -qpR foo.buildreqs.nosrc.rpm)
2.2) rm foo.buildreqs.nosrc.rpm
3) rpmbuild
But yeah, you can do the cleanup in rpmbuild as well.
--
You are receiving this because you are subscribed to this thread.
Re
The buildreqs.rpm is placed in the SRPMS/ dir right now (as it uses the srpm
code path). But Panu is right. We need to clean it up, upon successful build.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rp
> Since the buildreqs package is a short-lived artifact and not something
> people would want to hang on to, I think we should cleanup step on successful
> build, or maybe use /var/tmp to create it in the first place. And might want
> to have the directory configurable separate from src.rpm crea
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/651#issuecomment-480871462___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
The reason to use a package for storing the build deps is that this is the
format most tools use when dealing with dependencies. Yes, it is kinda weird
from a human perspective as one would rather expect some text file. But there
is not really a text format that it widely understood by the vario
ffesti commented on this pull request.
> +if (Ferror(fd)) {
+ rpmlog(RPMLOG_ERR, _("Unable to open temp file: %s\n"), Fstrerror(fd));
+ goto exit;
+}
+
+if ((fp = fdopen(Fileno(fd), "w")) == NULL) {
+ rpmlog(RPMLOG_ERR, _("Unable to open stream: %s\n"), strerror(err
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:
https://github.com/rpm-software-management/rpm/pull/659#pullrequestreview-223873342___
pmatilai commented on this pull request.
> +if (Ferror(fd)) {
+ rpmlog(RPMLOG_ERR, _("Unable to open temp file: %s\n"), Fstrerror(fd));
+ goto exit;
+}
+
+if ((fp = fdopen(Fileno(fd), "w")) == NULL) {
+ rpmlog(RPMLOG_ERR, _("Unable to open stream: %s\n"), strerror(e
Simplifies the code and could be of use to PR #593
The downside is that it eats more memory due to buffering the entire build
output but whether that matters... and could be conditionalized of course.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-softw
pmatilai commented on this pull request.
> +if (Ferror(fd)) {
+ rpmlog(RPMLOG_ERR, _("Unable to open temp file: %s\n"), Fstrerror(fd));
+ goto exit;
+}
+
+if ((fp = fdopen(Fileno(fd), "w")) == NULL) {
+ rpmlog(RPMLOG_ERR, _("Unable to open stream: %s\n"), strerror(e
Yes, I know, it's a next step kind of thing, the usefulness of `BuildProvides`
is not really evident, until you start generating `BuildRequires` automatically.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.c
pmatilai commented on this pull request.
> +if (Ferror(fd)) {
+ rpmlog(RPMLOG_ERR, _("Unable to open temp file: %s\n"), Fstrerror(fd));
+ goto exit;
+}
+
+if ((fp = fdopen(Fileno(fd), "w")) == NULL) {
+ rpmlog(RPMLOG_ERR, _("Unable to open stream: %s\n"), strerror(e
The buildreqs rpm does indeed seem a bit weird, but probably makes a lot of
sense in practise. nosrc.rpm is indeed better than src.rpm.
Since the buildreqs package is a short-lived artifact and not something people
would want to hang on to, I think we should cleanup step on successful build,
or
We don't even _have_ `BuildProvides` as it is...
--
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/657#issuecomment-480818360___
@Conan-Kudo but to retrieve `%generate_buildrequires` you need to execute
`%prep` which is a non-trivial task. And somehow pass the output. I actually
like the `.buildreqs` as parsing Requires is well defined and you can do that
well as human and as a machine.
@ffesti `.buildreqs.nosrc.rpm` so
@ffesti Well, I mean why don't we just query for the static builddeps and
install them, then retrieve the `%generate_buildrequires` section and grab the
output and install that, then go forth and build normally?
--
You are receiving this because you are subscribed to this thread.
Reply to this
> @ffesti Is there a reason we can't just do this by evaluating the spec file
> instead of producing weird (no)src rpms?
Yes.
If the dynamic dependencies go into a spec file there is the risk of the spec
file getting built. That's not what we want. The dynamic dependencies need to
stay dynamic
@ffesti Is there a reason we can't just do this by evaluating the spec file
instead of producing weird (no)src rpms?
--
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/593#iss
> I am not sure about that `.builreqs.rpm` suffix. These suffixes are hardcoded
> in several places. And e.g. I filed a lot of bug reports about ignoring
> `nosrc.rpm` when handling src.rpm. When .buildreqs.rpm is a src.rpm ... what
> about calling it .buildreqs.src.rpm? This way we can signaliz
pmatilai commented on this pull request.
> +rpmtsSetFlags(ts, rpmtsFlags(ts) | RPMTRANS_FLAG_NOPLUGINS);
+
+rpmps ps = rpmSpecCheckDeps(ts, spec);
+
+if (ps) {
+ rpmlog(RPMLOG_ERR, _("Failed build dependencies:\n"));
+ rpmpsPrint(NULL, ps);
+}
+if (ps != NULL)
+
pmatilai commented on this pull request.
> @@ -350,6 +350,18 @@ static rpmRC buildSpec(BTA_t buildArgs, rpmSpec spec,
> int what)
if ((what & RPMBUILD_CHECKBUILDREQUIRES) &&
(rc = doCheckBuildRequires(spec, test))) {
if (rc == RPMRC_MISSINGBUILDREQUIRES) {
+
pmatilai commented on this pull request.
> +rpmtsSetFlags(ts, rpmtsFlags(ts) | RPMTRANS_FLAG_NOPLUGINS);
+
+rpmps ps = rpmSpecCheckDeps(ts, spec);
+
+if (ps) {
+ rpmlog(RPMLOG_ERR, _("Failed build dependencies:\n"));
+ rpmpsPrint(NULL, ps);
+}
+if (ps != NULL)
+
Oh and thanks for the patch.
--
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/656#issuecomment-480783158___
Rpm-maint mailing lis
Closed #655.
--
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/655#event-2259276371___
Rpm-maint mailing list
Rpm-maint@lists.rpm
Fixed by commit 966863911c872405ee36b4eb8bcbfdbfd76e9431
--
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/655#issuecomment-480782853
pmatilai approved this pull request.
What I said above...
--
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/656#pullrequestreview-223768749_
Merged #656 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/656#event-2259269042___
Rpm-maint mailing list
Rpm-maint
The pre-existing line seemed looked a little odd there so I dug up history a
bit. The line added here was intentionally removed (instead of fixing the typo)
in commit bde88ada3a0fbd17f9b5db9fb5426eb0f1ff5efd, but I'm not so sure about
the rationale now: current flags are copied everywhere else s
Yeah looks pretty obvious. 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/658#issuecomment-480736918___
Rpm-maint mailin
Merged #658 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/658#event-2258904111___
Rpm-maint mailing list
Rpm-maint
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:
https://github.com/rpm-software-management/rpm/pull/658#pullrequestreview-223681084___
It helps to make build results reproducible. Based on Mark Wielaard's idea.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/658
-- Commit Summary --
* Sort list of hard linked files in find-debuginfo.sh (RhBug:1421272)
-- F
33 matches
Mail list logo
