So based on that log, it somehow just skips the rpmtests generation :flushed:
There's not even an error from missing autom4te (from autoconf package), which
is what I got when removing autoconf to try and reproduce.
Try 'rm -rf'ing the entire _build and start from scratch. So far I'm finding
th
@JetXujing pushed 2 commits.
03b8785f5dba0975c73253b1da6943b1a0d58baa tests: add test for parseForVerify
8c63ec4ff6d8c9ae37c9f7334cd0a4fcf3c06b5a tests: add test for Obsoletes
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2254/files/6ebc7495d9291469b86202f1bcf5f77e7
@pmatilai please check it
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2261#issuecomment-1302911904
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
Note: I'm testing with 40d66336a243093d6d67d1203f511d3831ecbc7a
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2262#issuecomment-1302188743
You are receiving this because you are subscribed to this thread.
Message ID: _
I'm splitting [this
comment](https://github.com/rpm-software-management/rpm/issues/2258#issuecomment-1301807221)
into a separate issue.
```
$ make check VERBOSE=1
/usr/bin/cmake -S/home/us/neal/work/pep/rpm -B/home/us/neal/work/pep/rpm/_build
--check-build-system CMakeFiles/Makefile.cmake 0
mak
I make a patch to fix it.
[https://github.com/rpm-software-management/rpm/pull/2261](url)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2195#issuecomment-1301983612
You are receiving this because you are subscribed to this thread.
Me
fix
[https://github.com/rpm-software-management/rpm/issues/2195](https://gitee.com/link?target=https%3A%2F%2Fgithub.com%2Frpm-software-management%2Frpm%2Fissues%2F2195)
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2261
-- C
> Is it possible to open the FIFO file in non-blocking mode when it is detected?
I find that when opening a file in non-blocking mode, -1 is returned in this
case, so this is not a good idea.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/is
Merged #2260 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2260#event-7731157691
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint maili
Closed #2258 as completed via #2260.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2258#event-7731157876
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rp
Also, "make check VERBOSE=1" should give some clues. In particular, this is how
the rpmtests script gets generated:
> Scanning dependencies of target check
make[3]: Leaving directory '/root/rpm/_build'
make -f tests/CMakeFiles/check.dir/build.make tests/CMakeFiles/check.dir/build
make[3]: Enteri
Maybe we need to start with the "obvious": does rpmtests script exist in tests/
of the build tree? It sounds as if it's not, but the other alternative is some
current dir based mixup.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/225
Hmm, trying to compile on Debian (starting from a minimal container) I can
produce all manner of unhandled error cases from the build system, but not that
:thinking:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2258#issuecomment-13
@pmatilai commented on this pull request.
> @@ -273,6 +273,15 @@ static int doSetupMacro(rpmSpec spec, const char *line)
free(buf);
}
+/* mkdir for dynamic specparts */
+buf = rpmExpand("%{__mkdir} SPECPARTS", NULL);
+appendBuf(spec, buf, 1);
+free(buf);
+
+buf
That solves the lua problem for me. make check now fails:
```
...
Built target populate_testing
Built target librpmio
Scanning dependencies of target rpmpgppubkeyfingerprint
Building C object
tests/CMakeFiles/rpmpgppubkeyfingerprint.dir/rpmpgppubkeyfingerprint.c.o
Linking C executable rpmpgppubk
Doh, there was a copy-paste error, referring to librpmio does not help getting
it included in librpm :facepalm: Pushed a fix for that now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2258#issuecomment-1301772305
You are receiving th
...or maybe we should get into the habit of including these design docs in a
directory someplace in the source tree.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485#issuecomment-1301768925
You are receiving this because you are subsc
> Final patch might still deserve a bit longer commit message. Otoh there is
> docs on this and there is no need to duplicated that in the patch.
Yep, there's no point duplicating the user docs in the commit message. What
belongs in the commit message is a condensed version of the design spec:
@pmatilai commented on this pull request.
> @@ -1129,3 +1157,26 @@ rpmSpec rpmSpecParse(const char *specFile,
> rpmSpecFlags flags,
{
return parseSpec(specFile, flags, buildRoot, 0);
}
+
+rpmRC parseGeneratedSpecs(rpmSpec spec)
+{
+ARGV_t argv = NULL;
+int argc = 0;
+int i;
+
@pmatilai commented on this pull request.
> + if (checkForEncoding(pkg->header, 0) != RPMRC_OK) {
+ badenc = 1;
+ }
+ }
+ if (badenc)
+ goto errxit;
+}
+
+closeSpec(spec);
+
+exit:
+return spec;
+
+errxit:
+if (!secondary)
+
I get further, but I still get a complaint about lua.h being missing:
```
[ 40%] Building C object lib/CMakeFiles/librpm.dir/rpmscript.c.o
/tmp/rpm/rpm/lib/rpmscript.c:7:10: fatal error: 'lua.h' file not found
#include
^~~
1 error generated.
make[2]: *** [lib/CMakeFiles/librpm.dir/bu
@pmatilai commented on this pull request.
> @@ -273,6 +273,15 @@ static int doSetupMacro(rpmSpec spec, const char *line)
free(buf);
}
+/* mkdir for dynamic specparts */
+buf = rpmExpand("%{__mkdir} SPECPARTS", NULL);
+appendBuf(spec, buf, 1);
+free(buf);
+
+buf
Merged #2242 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2242#event-7729582571
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint maili
Looks fine now. I realized just now there was at least one case where the
if-indentation rule was broken in the existing code (the "more than on key"
test), these *fine details* slip past so easily, sigh.
Would be wonderful to have an automated coding style checker on GH.
Anyway, thanks for the
Does #2260 fix it for you?
In addition, there's a known issue of Debian shipping multiple versions of Lua,
with the version in the pkg-config name, and at least the autotools build
typically failed to find any. You seem to be past that, so either "lua" works
on Debian nowadays, or you already f
We should really do this for all our dependencies, but notably Debian and
derivates have multiple versions of Lua available, each in different
includedir, and build fails without this.
Fixes: #2258
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software
26 matches
Mail list logo
