Re: [Rpm-maint] [rpm-software-management/rpm] Enhance the recoverability and location of database exceptions (Issue #2828)

2024-02-07 Thread xujing
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 that the problem 
is caused by the internal logic of the database. It may be caused by the sudden 
shutdown, or the /var/ directory is the mount directory.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2828#issuecomment-1933290561
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] RPM 4.19.x bugfix release (Issue #2878)

2024-02-07 Thread Michal Domonkos
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 mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[Rpm-maint] [rpm-software-management/rpm] RPM 4.19.1.1 released! (Discussion #2891)

2024-02-07 Thread Michal Domonkos
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 lookup caching thread-safe Regression 
([#2843](https://github.com/rpm-software-management/rpm/pull/2843))
* *Lua interface:* Fix regression in Lua scriptlet runaway child detection 
Regression 
([#2818](https://github.com/rpm-software-management/rpm/pull/2818))
* *Build:* CMakeLists.txt: restore readline support as an explicit option 
Regression 
([#2852](https://github.com/rpm-software-management/rpm/pull/2852))
* *Build:* Fix unconditional uses of Linux-specific extensions 
Regression 
([#2812](https://github.com/rpm-software-management/rpm/pull/2812))
* *Build:* Add missing include for `check_symbol_exists` 
([#2831](https://github.com/rpm-software-management/rpm/pull/2831))
* *Build:* Don't use `_nl_msg_cat_cntr` if it's not available 
([#2856](https://github.com/rpm-software-management/rpm/pull/2856))

For download information, visit: https://rpm.org/wiki/Releases/4.19.1.1

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2891
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[Rpm-maint] RPM 4.19.1.1 released!

2024-02-07 Thread Michal Domonkos
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 regression in Lua scriptlet [...] [Regression] (#2818)
  * Build: CMakeLists.txt: restore readline support [...] [Regression] (#2852)
  * Build: Fix unconditional uses of Linux-specific [...] [Regression] (#2812)
  * Build: Add missing include for check_symbol_exists (#2831)
  * Build: Don't use _nl_msg_cat_cntr if it's not available (#2856)

For download information, visit:
  https://rpm.org/wiki/Releases/4.19.1.1

___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] RPM 4.19.1.1 bugfix update (PR #2888)

2024-02-07 Thread Michal Domonkos
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 mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] RPM 4.19.1.1 bugfix update (PR #2888)

2024-02-07 Thread Michal Domonkos
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-management/rpm/pull/2888#issuecomment-1932056945
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Noarch RPMs that contain EBPF binaries code incorrectly fail with "Arch dependent binaries in noarch package" (Issue #2875)

2024-02-07 Thread Panu Matilainen
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.org/archive/id/draft-thaler-bpf-elf-00.html so any "coloring" 
(meaning 32/64bitness in rpm) is just wrong. Luckily it should also be trivial 
to fix.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2875#issuecomment-1932013089
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Introduce an rpm-controlled per-build directory (PR #2885)

2024-02-07 Thread Panu Matilainen
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 because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Introduce an rpm-controlled per-build directory (PR #2885)

2024-02-07 Thread Panu Matilainen
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 out to break a buildid no-recompute 
test which assumes that a buildid remains the same regardless of the release. 
So it's name-version-arch now, for the better or worse.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1931858395
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Introduce an rpm-controlled per-build directory (PR #2885)

2024-02-07 Thread Panu Matilainen
@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 ", spec->buildDir, "\n",

Quotes added now.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#discussion_r1481332954
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Introduce an rpm-controlled per-build directory (PR #2885)

2024-02-07 Thread Panu Matilainen
@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 receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Introduce an rpm-controlled per-build directory (PR #2885)

2024-02-07 Thread Panu Matilainen
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 something more exotic.

So it doesn't need to be -PKG but it needs to be something that is easily 
distinguishable from something %setup normally does.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1931703744
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Enhance the recoverability and location of database exceptions (Issue #2828)

2024-02-07 Thread Panu Matilainen
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: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Enhance the recoverability and location of database exceptions (Issue #2828)

2024-02-07 Thread xujing
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 it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2828#issuecomment-1931615721
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Introduce an rpm-controlled per-build directory (PR #2885)

2024-02-07 Thread Vít Ondruch
> > 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 directory, so if the expansion was instead always 
into `SRC` that would not be so bad IMHO.

But arguably, quite some projects place their real sources into something like 
`src` directory, so then there could be patch like 'foo-1.0/SOURCE/src' 🙈

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1931607769
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Enhance the recoverability and location of database exceptions (Issue #2828)

2024-02-07 Thread Michael Schroeder
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 subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Clarify %_build*, %_host* and %_target* macros (Discussion #2889)

2024-02-07 Thread Panu Matilainen
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? 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2889#discussioncomment-8392654
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[Rpm-maint] [rpm-software-management/rpm] RPM fails to install paths when a path is a directory and marked with "%config" flag (Issue #2890)

2024-02-07 Thread Renaud Métrich
**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'){
fileType CONFIG
into '/opt/foo/bar'
createDirectoryEntry true
addParentDirs false
}
fileMode = 0755
~~~

ends up getting a RPM with `/opt/foo/bar` being tagged:
~~~
# rpm -qp --qf "[%{filenames} %{fileflags:fflags} \n]"  ~/foo-1.0.noarch.rpm
/opt/foo/bar c
/opt/foo/bar/somedir c
/opt/foo/bar/somefile c
~~~

This leads to getting the following error when installing the package with 
latest RPM found on Fedora 38 (`rpm-4.18.2-1.fc38`) and RHEL8 
(`rpm-4.14.3-28.el8_9`), in case `/opt/foo/bar` doesn't already exist:
~~~
# rpm -i ~/foo-1.0.noarch.rpm 
error: failed to open dir platform of /opt/foo/bar/: No such file or directory
error: unpacking of archive failed on file /opt/foo/bar/somedir: cpio: open 
failed - No such file or directory
error: foo-1.0.noarch: install failed
~~~

On RHEL8, such package could be installed with older releases of RPM, up to 
`rpm-4.14.3-26.el8` included, i.e. before fixing CVE-2021-35937, CVE-2021-35938 
and CVE-2021-35939.

We believe (@ffesti and myself) that tagging a directory with %config flag is 
an error, the flag should only be used with regular files.

Could you please confirm it's indeed an error to flag directories with %config 
flag.
If so, would it be possible to harden RPM to fail with a different error, 
clearly stating the RPM is not following the spec.

**To Reproduce**
Steps to reproduce the behavior:

I don't know, this seems to require gradle plugin.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2890
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Introduce an rpm-controlled per-build directory (PR #2885)

2024-02-07 Thread Panu Matilainen
> 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 be more reasonable, and for --rebuild mode it could actually 
be randomized.

> Now that we have the option, why not take full advantage of directories and 
> have a tree like this:
> [...]
> While I like the singular `ROOT` better, maybe `ROOTS` would be more 
> consistent.

For now we only have one buildroot though. I guess I'll just go back to the 
original BUILDROOT inside the new build directory, at least people will know 
what that thing is :sweat_smile: 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#issuecomment-1931534772
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Introduce an rpm-controlled per-build directory (PR #2885)

2024-02-07 Thread Panu Matilainen
@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 ", spec->buildDir, "\n",

Oops, yep 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2885#discussion_r1481068166
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint