I think the database is abnormal because the verification fails when I run the
rpm command, or the "rpm -qa" command cannot find the kernel package, but the
"rpm -q" command can find the kernel package. According to the result, the
problem is caused by the database. However, this does not mean t
Closed #2878 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2878#event-11734044206
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint m
This is a bug fix only release addressing a number of regressions, memory leaks
and build system issues, namely:
* *Packaging:* Don't warn about missing user/group on skipped files
Regression
([#2814](https://github.com/rpm-software-management/rpm/pull/2814))
* *Packaging:* Make user/group look
This is a bug fix only release addressing a number of regressions, memory leaks
and build system issues, namely:
* Packaging: Don't warn about missing user/group on [...] [Regression] (#2814)
* Packaging: Make user/group lookup caching thread-safe [Regression] (#2843)
* Lua interface: Fix re
Merged #2888 into rpm-4.19.x.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2888#event-11732556078
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
OK, I've picked the memleak fixes from #2879, namely 26a132302, 04b3317e6,
7bf818c83 and 5f5fa8852. The first one (f83640306) isn't applicable to the
4.19.x branch since the offending commit isn't there.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-manag
Okay, managed to produce one by myself:
> [pmatilai🎩︎localhost ~]$ clang -target bpf -c bpf.c -o bpf.o
> [pmatilai🎩︎localhost ~]$ file bpf.o
> bpf.o: ELF 64-bit LSB relocatable, eBPF, version 1 (SYSV), not stripped
So it's an architecture by itself, speced to be always 64bit:
https://www.ietf.
Other ponderings include the per-build directory macro name, should it be just
%builddir without the underscore (instead of %pkgbuilddir)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1931865327
You are receiving this
Merged this into a single commit at least for now as the changing paths clashed
in maddening ways in the test-suite on rebases, making simple changes too hard
to bother with.
Buildroot is just BUILDROOT now. I would've used name-version-release.arch for
the per-build directory, but this turns
@pmatilai commented on this pull request.
> @@ -303,6 +300,24 @@ static rpmRC doCheckBuildRequires(rpmts ts, rpmSpec
> spec, int test)
return rc;
}
+static rpmRC doBuildDir(rpmSpec spec, int test, StringBuf *sbp)
+{
+char *doDir = rstrscat(NULL,
+ "rm -rf ",
@pmatilai pushed 1 commit.
9d19699f6c8dc0c3eeaf8dcea820e76171aac84d Introduce an rpm-controlled per-build
directory
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885/files/80a60aa2bddb78a897e6279891ec58d862d92d74..9d19699f6c8dc0c3eeaf8dcea820e76171aac84d
You are re
The thing is (well, one of the things) is that, foo-1.0/foo-1.0 can mask a bug
or packaging error. The ugly -PKG suffix was absolutely necessary for seeing
which path a thing is actually trying to use when developing this PR, and will
be equally necessary for packagers trying to troubleshoot som
Um, what exactly do you mean by "database being abnormal" then?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2828#issuecomment-1931688028
You are receiving this because you are subscribed to this thread.
Message ID: _
Actually, the ndb database is seldom faulty. There is a high probability that
the database is abnormal due to abnormal power-off or abnormal mount directory.
If you think it is not appropriate to back up the database, you can consider
closing the issue.
--
Reply to this email directly or view i
> > Not a fan of the `-PKG` and `-root` suffixes.
>
> If you just have 'foo-1.0/foo-1.0/' its easy to mix up etc.
I don't mind this path. But if the path actually was 'foo-1.0/SOURCE/' that
could mitigate your concern. And yes, there is #2859 always expanding the
tarball into name-version direc
Just as datapoint: SUSE switched to ndb a couple of years ago and I've not
heard of any problems with the ndb database.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2828#issuecomment-1931583617
You are receiving this because you are
AFAICS --target was always wrong from the autoconf cross-compilation
terminology point of view. For what it does in rpm, --host would be closer to
the mark. But outside a autoconf terminology explanation, would anybody ever
guess that --host somehow relates to output architecture and stuff?
--
**Describe the bug**
A Red Hat customer is using the [gradle
plugin](https://plugins.gradle.org/plugin/com.netflix.nebula.ospackage) to
build his RPM packages.
When using a snippet as shown below, it ends up creating a RPM with directories
marked with %config flag, e.g.:
~~~
from ('src'){
f
> Not a fan of the `-PKG` and `-root` suffixes.
The -PKG is ugly for sure, but *some* differentation from the traditional
%setup created directory seems necessary to drive the point across, and make
logs easier to look at. If you just have 'foo-1.0/foo-1.0/' its easy to mix up
etc. NEVRA might
@pmatilai commented on this pull request.
> @@ -303,6 +300,24 @@ static rpmRC doCheckBuildRequires(rpmts ts, rpmSpec
> spec, int test)
return rc;
}
+static rpmRC doBuildDir(rpmSpec spec, int test, StringBuf *sbp)
+{
+char *doDir = rstrscat(NULL,
+ "rm -rf ",
20 matches
Mail list logo
