Fantastic, thank you very much!
--
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#issuecomment-496427088___
Rpm-maint mailing
Awesome. Thank you, guys!
--
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#issuecomment-496388368___
Rpm-maint mailing list
Merged #593 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/593#event-2370694142___
Rpm-maint mailing list
pmatilai approved this pull request.
Looking fine now.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Okay, I think that was all. BTW @ffesti, please add at least a brief comment
when pushing updates, I only noticed this had been updated by accident this
morning when it could've been merged yesterday already.
--
You are receiving this because you are subscribed to this thread.
Reply to this
Some minor tweaks to do still:
- Squash the tests to the commit that adds the feature, that's where they belong
- There's an way too long parseRCPOT() line in doBuildRequires() for loop
still, not sure if it's been mentioned before, if not sorry for missing on
previous rounds
- Clean up the test
Ok, --quiet issue is fixed. Thank to Igor for helping with this!
Test are also added - and should now also include the new spec and tar ball...
--
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.
> @@ -228,12 +229,13 @@ static rpmRC doCheckBuildRequires(rpmts ts, rpmSpec
> spec, int test)
rpmps ps = rpmSpecCheckDeps(ts, spec);
if (ps) {
- rpmlog(RPMLOG_ERR, _("Failed build dependencies:\n"));
- rpmpsPrint(NULL, ps);
pmatilai commented on this pull request.
> @@ -228,12 +229,13 @@ static rpmRC doCheckBuildRequires(rpmts ts, rpmSpec
> spec, int test)
rpmps ps = rpmSpecCheckDeps(ts, spec);
if (ps) {
- rpmlog(RPMLOG_ERR, _("Failed build dependencies:\n"));
- rpmpsPrint(NULL, ps);
-
@ignatenkobrain pushed 1 commit.
cc8b9865b13bc06c96b404f12a9ea531e46ac4de Fix dynbrs with --quiet
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Found one more issue: --quiet also makes the BuildRequires disappear as the
output of all build scripts is piped to /dev/null. OK, when exactly are those
macro expanded...?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
As the GH interface doesn't allow commenting on individual commits, I'll just
make a general comment... In the "Pass rpmts object to rpmSpecBuild()" commit,
there are two minor issues:
- a stray empty line added before buildSpec()
- a change to rpmbuild.c that belongs to the next commit (move to
pmatilai commented on this pull request.
> @@ -273,20 +287,6 @@ static struct poptOption optionsTable[] = {
POPT_TABLEEND
};
-static int checkSpec(rpmts ts, rpmSpec spec)
-{
-int rc;
-rpmps ps = rpmSpecCheckDeps(ts, spec);
-
-if (ps) {
- rpmlog(RPMLOG_ERR, _("Failed
pmatilai commented on this pull request.
> * @param spec spec file control structure
* @param buildArgsbuild arguments
- * @return RPMRC_OK on success
+ * @return 0 on success, 1 on build error,
+ * RPMRC_MISSINGBUILDREQUIRES on
pmatilai commented on this pull request.
> +freeStringBuf(sb_stdout);
+free(output);
+return rc;
+}
+
+static rpmRC doCheckBuildRequires(rpmts ts, rpmSpec spec, int test)
+{
+rpmRC rc = RPMRC_OK;
+rpmps ps = rpmSpecCheckDeps(ts, spec);
+
+if (ps) {
+
pmatilai commented on this pull request.
> (what & ~RPMBUILD_RMSOURCE) |
(x ? 0 : (what & RPMBUILD_PACKAGESOURCE) {
goto exit;
}
}
} else {
int didBuild = (what &
OK, that should be the requested changes. Still missing is squashing of the
three patches from "Pass rpmts object to rpmSpecBuild" onward and a test case
or two.
Patch set also get rebased to current head.
--
You are receiving this because you are subscribed to this thread.
Reply to this
ffesti commented on this pull request.
> @@ -273,20 +287,6 @@ static struct poptOption optionsTable[] = {
POPT_TABLEEND
};
-static int checkSpec(rpmts ts, rpmSpec spec)
-{
-int rc;
-rpmps ps = rpmSpecCheckDeps(ts, spec);
-
-if (ps) {
- rpmlog(RPMLOG_ERR, _("Failed build
ffesti commented on this pull request.
> @@ -16,6 +16,8 @@
#include "debug.h"
+#define RPMRC_MISSINGBUILDREQUIRES 11
Oh, this acentially moved to the _internal header. Will move again...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
ffesti commented on this pull request.
> +
+if (!spec->buildrequires) {
+ rc = RPMRC_OK;
+ goto exit;
+}
+
+if ((rc = doScript(spec, RPMBUILD_BUILDREQUIRES, "%generate_buildrequires",
+ getStringBuf(spec->buildrequires), _stdout, test)))
+ goto
ffesti commented on this pull request.
> @@ -47,7 +47,7 @@ static rpmRC doRmSource(rpmSpec spec)
* @todo Single use by %%doc in files.c prevents static.
*/
rpmRC doScript(rpmSpec spec, rpmBuildFlags what, const char *name,
- const char *sb, int test)
+ const char
pmatilai requested changes on this pull request.
As per above, changes requested. Hopefully this resets the review state
properly, things have gotten a bit confused here (my bad)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
In the commit to pass rpmts object ro rpmSpecBuild() there's a stray empty line
added to build/build.c, but it seems to get lost somewhere in the birds-eye
view that GH considers review mode.
The birds-eye view of things is useful for, well, a birds-eye view, but
bulls*** for reviewing patch
pmatilai commented on this pull request.
> if (rstreqn(N, "rpmlib(", sizeof("rpmlib(")-1)) {
- if (tagN != RPMTAG_REQUIRENAME) return 1;
+ if (tagN != RPMTAG_REQUIRENAME &&
+ (tagN == RPMTAG_PROVIDENAME && !(Flags & RPMSENSE_RPMLIB)))
+ return 1;
Fix the
pmatilai commented on this pull request.
> rpmlog(RPMLOG_NOTICE, _("\n\nRPM build errors:\n"));
rpmlogPrint(NULL);
}
rpmugFree();
-
+if (missing_buildreqs && !rc) {
+ rc = RPMRC_MISSINGBUILDREQUIRES;
+}
+if (rc == RPMRC_FAIL)
+ rc = 1;
Please use
pmatilai commented on this pull request.
> @@ -273,20 +287,6 @@ static struct poptOption optionsTable[] = {
POPT_TABLEEND
};
-static int checkSpec(rpmts ts, rpmSpec spec)
-{
-int rc;
-rpmps ps = rpmSpecCheckDeps(ts, spec);
-
-if (ps) {
- rpmlog(RPMLOG_ERR, _("Failed
pmatilai commented on this pull request.
> @@ -273,20 +287,6 @@ static struct poptOption optionsTable[] = {
POPT_TABLEEND
};
-static int checkSpec(rpmts ts, rpmSpec spec)
-{
-int rc;
-rpmps ps = rpmSpecCheckDeps(ts, spec);
-
-if (ps) {
- rpmlog(RPMLOG_ERR, _("Failed
pmatilai commented on this pull request.
> @@ -894,6 +895,9 @@ static rpmSpec parseSpec(const char *specFile,
> rpmSpecFlags flags,
case PART_PREP:
parsePart = parsePrep(spec);
break;
+ case PART_BUILDREQUIRES:
+ parsePart =
pmatilai commented on this pull request.
> goto exit;
+ if (what & RPMBUILD_BUILDREQUIRES)
+rc = doBuildRequires(spec, test);
+ if ((what & RPMBUILD_CHECKBUILDREQUIRES) &&
+ (rc == RPMRC_MISSINGBUILDREQUIRES))
+ rc =
pmatilai commented on this pull request.
> +/* add results to requires of the srpm */
+argvSplit(, getStringBuf(sb_stdout), "\n\r");
+outc = argvCount(output);
+
+if (!outc) {
+ rc = RPMRC_OK;
+ goto exit;
+}
+
+for (int i = 0; i < outc; i++) {
+
pmatilai commented on this pull request.
> @@ -213,24 +278,58 @@ static rpmRC buildSpec(BTA_t buildArgs, rpmSpec spec,
> int what)
} else {
int didBuild = (what & (RPMBUILD_PREP|RPMBUILD_BUILD|RPMBUILD_INSTALL));
+ if (!spec->buildrequires && (what &
pmatilai commented on this pull request.
> @@ -16,6 +16,8 @@
#include "debug.h"
+#define RPMRC_MISSINGBUILDREQUIRES 11
Hmm, we're actually returning this in the API so I think it should actually go
into rpmbuild.h
--
You are receiving this because you are subscribed to this thread.
pmatilai commented on this pull request.
> +for (int i = 0; i < outc; i++) {
+ parseRCPOT(spec, spec->sourcePackage, output[i], RPMTAG_REQUIRENAME, 0,
0, addReqProvPkg, NULL);
+}
+
+rpmdsPutToHeader(*packageDependencies(spec->sourcePackage,
RPMTAG_REQUIRENAME),
pmatilai commented on this pull request.
> @@ -172,9 +179,67 @@ rpmRC doScript(rpmSpec spec, rpmBuildFlags what, const
> char *name,
return rc;
}
-static rpmRC buildSpec(BTA_t buildArgs, rpmSpec spec, int what)
+static rpmRC doBuildRequires(rpmSpec spec, int test)
+{
+StringBuf
pmatilai commented on this pull request.
> +
+if (!spec->buildrequires) {
+ rc = RPMRC_OK;
+ goto exit;
+}
+
+if ((rc = doScript(spec, RPMBUILD_BUILDREQUIRES, "%generate_buildrequires",
+ getStringBuf(spec->buildrequires), _stdout, test)))
+
pmatilai commented on this pull request.
> @@ -283,7 +284,7 @@ static rpmRC buildSpec(BTA_t buildArgs, rpmSpec spec, int
> what)
return rc;
}
-rpmRC rpmSpecBuild(rpmSpec spec, BTA_t buildArgs)
+int rpmSpecBuild(rpmts ts, rpmSpec spec, BTA_t buildArgs)
Just noting that this is an API
pmatilai commented on this pull request.
> @@ -172,6 +172,7 @@ rpmRC doScript(rpmSpec spec, rpmBuildFlags what, const
> char *name,
return rc;
}
+
Stray newline added.
Like said in an earlier comment, the addition of rpmtsFromPyObject() could be
merged with this commit because it
pmatilai commented on this pull request.
> @@ -47,7 +47,7 @@ static rpmRC doRmSource(rpmSpec spec)
* @todo Single use by %%doc in files.c prevents static.
*/
rpmRC doScript(rpmSpec spec, rpmBuildFlags what, const char *name,
- const char *sb, int test)
+ const
Argh, I didn't mean to approve the whole thing, thought I could do it for the
couple of earlier commits separately.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
pmatilai 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/593#pullrequestreview-235945251___
RPM does not consider provides of SRPM for dependency check.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
OK, here is the rebased and squashed patch set. Let's hope not too many things
broke during this process...
I noticed that we are using the same rpmlib name for indicating that the SRPM
has an %generate_buildrequires script (and though needs support for this
feature) and that it already
Ah yup, include the doScript() changes too. Redoing the series with fixes
included is usually not that much effort when you have the whole thing working,
just take the resulting big diff and commit necessary infra changes first. Most
of this belongs into a single commit to add the finished
I'll fix the cosmetics.
I also have patches to use doScript() for the running the buildRequires script
that removes a lot of duplicated code but have not made it into this PR yet.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Please clean up the recurring cosmetic issues mentioned above, and redo the
series to include later fixes from the start so we get a nice, logical patch
series for proper review.
Adding rpmtsFromPyObject() can be merged in the commit to pass rpmts to spec
build, because it's a small thing
pmatilai commented on this pull request.
> @@ -274,17 +414,22 @@ static rpmRC buildSpec(BTA_t buildArgs, rpmSpec spec,
> int what)
exit:
free(cookie);
spec->rootDir = NULL;
-if (rc != RPMRC_OK && rpmlogGetNrecs() > 0) {
+if (rc != RPMRC_OK && rc != RPMRC_MISSINGBUILDREQUIRES
pmatilai commented on this pull request.
> @@ -172,9 +174,113 @@ rpmRC doScript(rpmSpec spec, rpmBuildFlags what, const
> char *name,
return rc;
}
-static rpmRC buildSpec(BTA_t buildArgs, rpmSpec spec, int what)
+static rpmRC doBuildRequires(rpmSpec spec, int test) {
In case of
@pmatilai I think this is ready to go. could you review it, please?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
So this is passing now. :champagne:
--
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#issuecomment-487371014___
Rpm-maint
@ignatenkobrain pushed 1 commit.
3ec53ad49a5b002e71d9aed97938e50ffb5eb9fa fixup! Add support for dynamic
BuildRequires
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
I have rebased this on top of
https://github.com/rpm-software-management/rpm/pull/686 so that one needs to go
first.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Cool, I'll send 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/593#issuecomment-486604885___
Rpm-maint mailing list
> If you are talking about having pythonX-rpm to depend on rpm-build-libs and
> rpm-sign-libs, but keeping C libraries separate, that would make sense to me
> (since it does not affect minimal installations).
Yup, that's exactly what I mean. The python side was split to keep in spirit of
the
> I think a better way would be just merging the python modules back into one
> instead of splitting by C-side library, the split causes way more problems
> than it solves.
If you are talking about having pythonX-rpm to depend on rpm-build-libs and
rpm-sign-libs, but keeping C libraries
> I would vote for removing _doBuild method entirely since it is private so
> nobody should use it anyway.
I think a better way would be just merging the python modules back into one
instead of splitting by C-side library, the split causes way more problems than
it solves.
> You need an empty
@nim-nim if you have bootstrap enabled then yes, different dnf is being used.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@xsuchy: that was I thought too but the first install report in the log does
not have the problem. Unless mock uses a different dnf for different build
stages?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
You mean that 'noarch1.3.0-1.fc3'? But that is printed by DNF. You can run
'mock -v' to see what mock pass to DNF.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@xsuchy the glued `ArchVersion` (without separator) in package install reports
seems like a mock bug
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
```
INFO: mock.py version 1.4.14 starting (python version = 3.7.3)...
Start: init plugins
[…]
Finish: chroot init
Start: build phase for golang-github-sirupsen-logrus-1.1.0-1.0.fc31.src.rpm
Start: build setup for golang-github-sirupsen-logrus-1.1.0-1.0.fc31.src.rpm
Building target platforms:
@Conan-Kudo empty `%build` didn’t work so in the past, you needed no `%build`
section at all. If someone changed the logic to empty `%build`, that's gonna
break loads of specs
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
You need an empty build section to get out defined properly, I think.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Ok, with `rpm-4.14.2.1-7.fc31+buildreqs.1.x86_64` and
`mock-1.4.14-1.git.34.3723a7c.fc31.noarch` I see the whole build chain working.
*However* something seems to have broken debug generation logic, I get the
dreaded
```
Empty %files file /builddir/build/BUILD/logrus-1.1.0/debugsourcefiles.list
> The problem is that the function lives in an entirely different DSO (_rpm.so)
> which is not linked in by the build module (_rpmb.so)
I spent 30 minutes googling and trying things and I could not find way how to
link it.
---
I would vote for removing `_doBuild` method entirely since it is
This is what's wrong with rpmtsFromPyObject():
```
/usr/bin/ld: .libs/spec-py.o: in function `spec_doBuild':
/home/pmatilai/repos/rpm/python/spec-py.c:303: undefined reference to
`rpmtsFromPyObject'
collect2: error: ld returned 1 exit status
```
The problem is that the function lives in an
> Yes, building rpm-python I sing system library as I reported this few years
> ago .. it was not fixed.
Well, you kinda promised to fix it yourself in here:
https://github.com/rpm-software-management/rpm/issues/130#issuecomment-273552868
;)
--
You are receiving this because you are
ffesti commented on this pull request.
> @@ -237,11 +343,45 @@ static rpmRC buildSpec(BTA_t buildArgs, rpmSpec spec,
> int what)
} else {
int didBuild = (what & (RPMBUILD_PREP|RPMBUILD_BUILD|RPMBUILD_INSTALL));
+ if (!spec->buildrequires && (what & RPMBUILD_PACKAGESOURCE)
Yes, building rpm-python I sing system library as I reported this few years ago
.. it was not fixed.
--
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.
> @@ -237,11 +343,45 @@ static rpmRC buildSpec(BTA_t buildArgs, rpmSpec spec,
> int what)
} else {
int didBuild = (what & (RPMBUILD_PREP|RPMBUILD_BUILD|RPMBUILD_INSTALL));
+ if (!spec->buildrequires && (what &
8108cc7aa9735f629d7380f94690d2947abeb9db still trips up test 135. My guess is
there is something wrong with the test suite. Probably linking the Python
bindings to the outside (system) rpmlib. It passes if I don't access the new
rpmtsFromPyObject() function. The import also works when run on
@ffesti pushed 4 commits.
3feac842c7a4fbfb1fde68ed5c15a389fb9ec941 Add rpmtsFromPyObject
8108cc7aa9735f629d7380f94690d2947abeb9db Pass rpmts object to rpmSpecBuild()
346e561a0be8366290026bdfd360983e36a834e8 Do build dependency check in
build/build.c instead of rpmbuild
For the record - related changes in redhat-rpm-config
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/51
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ignatenkobrain The example in
https://fedoraproject.org/wiki/Changes/DynamicBuildRequires?rd=Changes/BuildRequires_Generators#Example
is too complicated. I would suggest to put there some artificial example which
add one artificial dependency and it will use just cat/echo and everything
@ignatenkobrain `rpm-build-4.14.2.1-7.fc31+buildreqs.1.x86_64` works for me:
```console
$ grep BuildRequires ~/fedora/rpm/golist/golist.spec
$ LANG=C.utf8 rpmbuild -ba ~/fedora/rpm/golist/golist.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.t0kf16
+ umask 022
+ cd
@ignatenkobrain pushed 3 commits.
19961172f5ebc3d728eeeb6463d6478a3278bd59 rpmbuild: Generate
buildreqs.nosrc.rpm properly with --nodeps
c2f5358a3346eb8b886d87aeb2b66605094aa19a rpmbuild: Put dynamic BuildRequires
into src.rpm even with --nodeps
7d339dff7a69c778bdef4bdbae16e52ed20ac36a Fix
> @ignatenkobrain can you please send me some spec/src.rpm with dynamic
> dependencies?
@xsuchy you have another one here
https://copr.fedorainfracloud.org/coprs/nim/macros-ng/build/881699/
(needs the rest of the copr, and obviously failing to build in copr)
--
You are receiving this because
@ignatenkobrain your releases are not big enough to be picked up over the rpm
version in koji rawhide
Koji rawhide is already at release 6
https://koji.fedoraproject.org/koji/packageinfo?packageID=319
Also, the modified rpm seems to break some copr assumptions
* with `
@ffesti pushed 2 commits.
a27f82f955b6f09d5f44fa7627f7db2f8b867d81 fixup! Add support for dynamic
BuildRequires
93e5e3e408caf4d94eeb4acf412a8ca341cb93df fixup! Add support for dynamic
BuildRequires
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
> Thinking about this a bit more, rpmbuild should probably get an option to
> just execute genbr section without checking dependencies.
> @ffesti thoughts?
The thing is that I had (and in the code still have) the execution of the br
script separate from the dependency check. But this makes the
Just some update on this from my side:
* RPM with this PR
* Latest mock
** With https://github.com/rpm-software-management/mock/pull/246
** With removed `--nodeps` from mock (@xsuchy is going to test whether it will
break anything)
* rust-packaging with
ffesti 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) {
+
@ffesti pushed 5 commits.
b2bb450b8b9a8548d10b8e6a3911f73f0ea9211d fixup! Add support for dynamic
BuildRequires
3a8b02d637a1c083463357fdb3b6c8cb5273813c fixup! rpmbuild: Allow to build
source with dymamic build dependencies included
23fcd00c01aca50ff00588106c23a7e764ca2a8b Use
Based on the comment there, the idea there is to set RPMBUILD_PREP bit to zero,
|= is certainly wrong for that purpose (but I dont know if there's something
else wrong in the surrounding logic). However the general rpm-style for
disabling bits would is:
```
what &= ~RPMBUILD_PREP;
```
@ffesti you have one more bug which is breaking basically everything :)
```diff
@@ -354,7 +353,7 @@ static rpmRC buildSpec(BTA_t buildArgs, rpmSpec spec, int
what)
!(what & (RPMBUILD_BUILD|RPMBUILD_INSTALL|RPMBUILD_PACKAGEBINARY))){
/* don't run prep if not needed for
Lets discuss Mock implementation here:
https://github.com/rpm-software-management/mock/issues/245
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thinking about this a bit more, rpmbuild should probably get an option to just
execute genbr section without checking dependencies. The reason why mock does
`--nodeps` because rpmbuild in target environment might be older/compiled with
different features so it can't read rpmdb within chroot
I have used standard `fedora-rawhide-x86_64.cfg` with 2 additional repos:
```ini
[ignatenkobrain-rpm-buildreqs]
name=Copr repo for rpm-buildreqs owned by ignatenkobrain
baseurl=https://copr-be.cloud.fedoraproject.org/results/ignatenkobrain/rpm-buildreqs/fedora-rawhide-$basearch/
type=rpm-md
Seems that it doesn't quite work (not sure why yet):
```
INFO: ENTER ['do'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bb --target
x86_64 --nodeps /builddir/build/SPECS/rust-warp.spec'],
chrootPath='/var/lib/mock/fedora-rawhide-x86_64-buildreqs/root'env={'TERM':
'vt100', 'SHELL':
FYI:
https://github.com/rpm-software-management/mock/commit/1c73a7ac7659d852a4d38e4bd5ba4641e224b206
Copr build with this commit is here
https://copr.fedorainfracloud.org/coprs/g/mock/mock/package/mock/ I did not
test it yet.
--
You are receiving this because you are subscribed to this
@ignatenkobrain can you please send me some spec/src.rpm with dynamic
dependencies?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I have built 4.14 RPM with necessary changes (obviously, only for testing.
f28/f29/f30/f31):
https://copr.fedorainfracloud.org/coprs/ignatenkobrain/rpm-buildreqs/
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
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.
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:
> 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
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"),
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"),
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,
@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`
> @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
@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:
1 - 100 of 138 matches
Mail list logo