[Rpm-maint] [rpm-software-management/rpm] Duplicate __debug_package causes problems for spec files directly using %debug_package (Issue #3290)
The change introduced in /usr/lib/rpm/macros in
1a9803d0f8daf15bb706dc17783ab19589906487 started causing the rpminspect test
suite to fail for the debuginfo package tests. Looking in to it, I found that
the duplicate __debug_package definition was causing spec file errors in
rpmbuild.
I use the rpmfluff Python module in the rpminspect test suite to generate RPMs
to run through rpminspect. In a lot of these cases I deliberately make
mistakes because I want to make sure rpminspect finds the problems. In the
case of the debuginfo package tests, that means checking to see if debuginfo is
missing and so on.
Here is an example spec file that rpmfluff generated for a particular test:
```
# autogenerated specfile
%global __os_install_post %{nil}
Summary: Dummy summary
Name: vaporware
Version: 0.1
Release: 1
License: GPL
Group: Applications/Productivity
Source0: main.c
%description
This is a dummy description.
%prep
cp %{SOURCE0} .
%build
%if 0%{?__isa_bits} == 32
%define mopt -m32
%endif
gcc %{?mopt} -g main.c
%install
mkdir -p $RPM_BUILD_ROOT/usr/bin
cp a.out $RPM_BUILD_ROOT/usr/bin/hello-world
%files
/usr/bin/hello-world
%debug_package
%changelog
* Sun Jul 22 2018 John Doe - 0.1-1
- Initial version
```
The problem occurs with the %debug_package line. In rpm 4.19.93, I am getting
this output from rpmbuild:
```
Building target platforms: x86_64
Building for target x86_64
setting SOURCE_DATE_EPOCH=1532217600
Executing(%mkbuilddir): /bin/sh -e /var/tmp/rpm-tmp.cCa2fi
+ umask 022
+ cd
/tmp/rpmfluff-acrwm0em/test-rpmbuild-vaporware-0.1-1/BUILD/vaporware-0.1-build
+ test -d
/tmp/rpmfluff-acrwm0em/test-rpmbuild-vaporware-0.1-1/BUILD/vaporware-0.1-build
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w
/tmp/rpmfluff-acrwm0em/test-rpmbuild-vaporware-0.1-1/BUILD/vaporware-0.1-build
+ /usr/bin/rm -rf
/tmp/rpmfluff-acrwm0em/test-rpmbuild-vaporware-0.1-1/BUILD/vaporware-0.1-build
+ /usr/bin/mkdir -p
/tmp/rpmfluff-acrwm0em/test-rpmbuild-vaporware-0.1-1/BUILD/vaporware-0.1-build
+ /usr/bin/mkdir -p
/tmp/rpmfluff-acrwm0em/test-rpmbuild-vaporware-0.1-1/BUILD/vaporware-0.1-build/SPECPARTS
+ RPM_EC=0
++ jobs -p
+ exit 0
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.bdRuAj
+ umask 022
+ cd
/tmp/rpmfluff-acrwm0em/test-rpmbuild-vaporware-0.1-1/BUILD/vaporware-0.1-build
+ cp /tmp/rpmfluff-acrwm0em/test-rpmbuild-vaporware-0.1-1/SOURCES/main.c .
+ RPM_EC=0
++ jobs -p
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.awC3HQ
+ umask 022
+ cd
/tmp/rpmfluff-acrwm0em/test-rpmbuild-vaporware-0.1-1/BUILD/vaporware-0.1-build
+ CFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer '
+ export CFLAGS
+ CXXFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer '
+ export CXXFLAGS
+ FFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64
-march=x86-64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -mtls-dialect=gnu2
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-I/usr/lib64/gfortran/modules '
+ export FFLAGS
+ FCFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64
-march=x86-64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -mtls-dialect=gnu2
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-I/usr/lib64/gfortran/modules '
+ export FCFLAGS
+ VALAFLAGS=-g
+ export VALAFLAGS
+ RUSTFLAGS='-Copt-level=3 -Cdebuginfo=2 -Ccodegen-units=1 -Cstrip=none
-Cforce-frame-pointers=yes
-Clink-arg=-specs=/usr/lib/rpm/redhat/redhat-package-notes --cap-lints=warn'
+ export RUSTFLAGS
+ LDFLAGS='-Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin
Re: [Rpm-maint] [rpm-software-management/rpm] Make user/group info reliable operation across chroot (PR #2503)
@dcantrell commented on this pull request.
> + long *ret)
+{
+char *buf = NULL;
+int rc = lookup_field(path, val, vcol, rcol, &buf);
+if (rc == 0) {
+ long num = atol(buf);
+ *ret = num;
+ free(buf);
+}
+return rc;
+}
+
+static int lookup_name(const char *path, long val, int vcol, int rcol,
+ char **ret)
+{
+char vbuf[256];
I thought about asprintf() but that's not portable. rasprintf() would work.
Honestly, even though it's silly I say use rasprintf(). Static buffers always
lead to future problems, at least in my experience.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2503#discussion_r1189856745
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] Make user/group info reliable operation across chroot (PR #2503)
@dcantrell commented on this pull request.
> + }
+ }
+}
+
+fclose(f);
+
+return rc;
+}
+
+static int lookup_num(const char *path, const char *val, int vcol, int rcol,
+ long *ret)
+{
+char *buf = NULL;
+int rc = lookup_field(path, val, vcol, rcol, &buf);
+if (rc == 0) {
+ long num = atol(buf);
Oh I've been there. I will definitely add error checking later. :)
This one stood out to me because of the 0 returned for errors which would be
UID or GID 0.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2503#discussion_r1189854210
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] Make user/group info reliable operation across chroot (PR #2503)
@dcantrell commented on this pull request. > #include #include #include "lib/misc.h" #include "lib/rpmug.h" #include "debug.h" +#define PWFILE "/etc/passwd" +#define GRPFILE "/etc/group" I would say testing is the most relevant use here to define these paths in a config file. In current practice, I think the only relevant systems that have a different path for this file are BSD systems with /etc/master.passwd. But even still I think they provide /etc/passwd for compatibility. Still this one strikes me as the kind of thing that systemd or some project like that would go and change and then rpm would get blamed when things break. (And np on the review) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2503#discussion_r1189853254 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] Make user/group info reliable operation across chroot (PR #2503)
@dcantrell commented on this pull request.
Added some comments and questions.
> #include
#include
#include "lib/misc.h"
#include "lib/rpmug.h"
#include "debug.h"
+#define PWFILE "/etc/passwd"
+#define GRPFILE "/etc/group"
I'm not aware of another system that would put passwd and group somewhere other
than /etc, but then I think maybe CoreOS would and I'm sure MacOS X has a place
like /private/etc or something like that. Could these be defined in
/usr/lib/rpm/macros or /usr/lib/rpm/rpmrc or is that too much yak shaving for
unknown future proofing? I personally like giving integrators the ability to
adjust file locations at runtime if possible, but I know these are special
files.
> + }
+ }
+}
+
+fclose(f);
+
+return rc;
+}
+
+static int lookup_num(const char *path, const char *val, int vcol, int rcol,
+ long *ret)
+{
+char *buf = NULL;
+int rc = lookup_field(path, val, vcol, rcol, &buf);
+if (rc == 0) {
+ long num = atol(buf);
Any reason to not use strtol() here? In the error case here, doesn't atol()
give you 0 which may or may not be fine. But strtol() could catch errors for
reporting here.
> + long *ret)
+{
+char *buf = NULL;
+int rc = lookup_field(path, val, vcol, rcol, &buf);
+if (rc == 0) {
+ long num = atol(buf);
+ *ret = num;
+ free(buf);
+}
+return rc;
+}
+
+static int lookup_name(const char *path, long val, int vcol, int rcol,
+ char **ret)
+{
+char vbuf[256];
Where does 256 come from?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2503#pullrequestreview-1418656356
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] Bring RPM_MASK_RETURN_TYPE in to the signed int range (PR #2459)
Updated. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2459#issuecomment-1494250574 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] Bring RPM_MASK_RETURN_TYPE in to the signed int range (PR #2459)
@dcantrell pushed 1 commit. c9bb079d2b24a980228d7c2acfb4be040d231b5f Remove RPM_MASK_RETURN_TYPE from rpmTagReturnType_e; make it a macro -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2459/files/dfe986b9ec9c73d18c2fc9c0139887bc3a35ae4d..c9bb079d2b24a980228d7c2acfb4be040d231b5f 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] Bring RPM_MASK_RETURN_TYPE in to the signed int range (PR #2459)
Set to 0x (or 4294901760), I was getting: error: ISO C restricts enumerator values to range of 'int' (4294901760 is too large) [-Werror,-Wpedantic] This happened not when building rpm itself, but when building rpminspect which links with librpm and uses rpm's headers. The system in question was FreeBSD 13.1 which has clang 13.0.0. It is a corner case, but I like testing things on non-Linux platforms as often as I can to find errors like this. With this change, the rpm test suite passes for me. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2459 -- Commit Summary -- * Bring RPM_MASK_RETURN_TYPE in to the signed int range -- File Changes -- M include/rpm/rpmtag.h (2) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2459.patch https://github.com/rpm-software-management/rpm/pull/2459.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2459 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] Replace rpmTagType_e with a list of defines and an rpmTagType typedef (PR #2417)
Closed #2417. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2417#event-8889124014 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] Replace rpmTagType_e with a list of defines and an rpmTagType typedef (PR #2417)
Dropping this as I started over with my findings and have a new patch. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2417#issuecomment-1490519747 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] Replace rpmTagType_e with a list of defines and an rpmTagType typedef (PR #2417)
That's reasonable. Let me dig in to the clang error a bit more here and restructure things. I will also track down the RPMTAG_NOT_FOUND issue too. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2417#issuecomment-1460324651 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] Replace rpmTagType_e with a list of defines and an rpmTagType typedef (PR #2417)
I ran in to a problem with some versions of clang building rpm where the value of RPM_MASK_TYPE (0x) triggered an overflow error. Per the C standard, the underlying type of the enum is implementation defined. It should be an int unless the values of the enum cannot fit in an int or unsigned int. I think that gcc is more forward thinking here than clang because with clang this particular enum becomes an int and when RPM_MASK_TYPE is used, you get an overflow error. RPM_MASK_TYPE is not part of the enum. I generally find enums in header files to lead to confusion and problems anyway. And especially in cases like this where developers may be expecting to use the preprocessor to determine if values are defined or not. Changing this enum to be a list of defined macros resolves the issue for me. I retained the rpmTagType variable type as well, but made it be a uint32_t. I originally wanted to make it a uint16_t because RPM_MASK_TYPE is 0x, but that causes overflow warnings as well because rpmTagType sometimes gets RPMTAG_NOT_FOUND, which is a uint32_t. So just use uint32_t consistently. If this looks reasonable to people, I do not mind fixing up the other enums in header files. I just wanted to start with this one. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2417 -- Commit Summary -- * Replace rpmTagType_e with a list of defines and an rpmTagType typedef -- File Changes -- M include/rpm/rpmtag.h (34) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2417.patch https://github.com/rpm-software-management/rpm/pull/2417.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2417 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] Mark man pages with RPMFILE_MAN and info pages with RPMFILE_INFO (#1404)
Define two additional file flags. One for man pages and one for info pages. These files are currently marked as RPMFILE_DOC during rpmbuild. This patch also marks man pages with RPMFILE_MAN and info pages with RPMFILE_INFO. The idea is that while they are still documentation, there will be further file flag details in the RPM header indicating what kind of docs they are. This patch could be extended to allow rpm to carry options like --excludeman and --excludeinfo, though if that happens the file flags may want to exclude man and info pages from RPMFILE_DOC entirely. My motivation for these additional file flags are for use in rpminspect when performing tests on man pages or info pages. Right now tools like rpminspect have to match man pages based on path and file type, which rpm already knows about. If the RPM header can carry a flag marking each man page, it makes tests in other tools easier. The same for info pages. Signed-off-by: David Cantrell <dcantr...@redhat.com> You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1404 -- Commit Summary -- * Mark man pages with RPMFILE_MAN and info pages with RPMFILE_INFO -- File Changes -- M build/files.c (40) M lib/rpmfiles.h (2) M macros.in (6) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1404.patch https://github.com/rpm-software-management/rpm/pull/1404.diff -- 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/1404 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] rpmbuild sets RPMFILE_DOC on files in %{_datadir}/doc regardless of spec file notation (#1368)
On lines 1228 and 1229 in build/files.c, I found this: if (!isSrc && isDoc(fl->docDirs, flp->cpioPath)) flp->flags |= RPMFILE_DOC; git blame shows this has been around for at least 8 years, so this is hardly anything new. I noticed that any files in install to %_defaultdocdir as defined in the macros end up getting marked in the rpm header with RPMFILE_DOC. This is regardless of how I mark the files in the spec file. If I use any path other than %_defaultdocdir and install files marked as %doc, the spec file rules take effect. But it seems any time you list a file in %files that begins with %_defaultdocdir, it will also be marked as an RPMFILE_DOC in the package. This feels like incorrect behavior to me because the %doc macro is ignored only for these cases. Shouldn't the %doc macro in the spec file control the RPMFILE_DOC bit in the header? -- 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/1368___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Is it necessary to headerUnlink() headers? (#1072)
Closed #1072. -- 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/1072#event-3043972015___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Is it necessary to headerUnlink() headers? (#1072)
It was definitely weird and confusing and after staring at it for a while, I decided to ask. However, running regular rpm operations with my modified librpm that displays the reference count showed everything behaving normally. The bug has to be in my code. Looked at it again just now and found it. It was a separate function for a separate part of the code that was using headerLink(). Thought I had gotten rid of all those. Leak fixed, everything working normally now. For reference, my project is rpminspect: https://github.com/rpminspect/rpminspect -- 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/1072#issuecomment-587023599___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Is it necessary to headerUnlink() headers? (#1072)
I use rpmReadPackageFile() to get RPM headers then use headerGetString() and headerIsSource() during the lifetime of the program. At the end, I call headerFree() on the RPM headers I read in at the beginning but these are not freed because the reference counts are at 67. I see headerUnlink() is not available directly, so I don't know what I'm doing incorrectly. The program itself functions but it's leaking memory at the end. Do headerGetString() and headerIsSource() increment the reference count? Looking at the lib/ source, I don't see that obviously standing out. I only see headerLink() doing and it's not called from many places. I've modified my local librpm and have it dumping the Header nrefs count. When I call rpmReadPackageFile(), that reference count becomes 1. At the end of the program when I call headerFree(), it's 67. What is the correct way to read a header and not have the reference count grow? 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/issues/1072___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] User IDs used in RPM packages.
On Tue, 2007-03-27 at 13:53 +0100, Richard Hodson wrote: > Sorry if this seems slightly off topic, but it seems off topic everywhere I > have looked online for info on RPMs. > > I am building a package for some company software, and the safest thing to do > is run it from Init under its own user ID, just like eg Apache web server uses > user apache. Thing is, how do I get a user ID that no-one else it using? > > If you can point me in the right direction, I would be happy to put any such > infomation into your wiki given that this is the root of all things RPM! This is definitely a problem outside the scope of RPM. Selecting a user ID for a daemon process is a matter of policy. I highly suggest selecting one that is high and will be available on all systems you plan to deploy the software on. But, to answer the question, there's no simple way to get a user ID that is available on a particular system. Accounts don't really work that way. The big problem is where is the account information coming from on your system. /etc/passwd, LDAP, NIS, etc? Pick an ID for this application and set that in stone as the one you'll use on all platforms. -- David Cantrell <[EMAIL PROTECTED]> Red Hat / Westford, MA signature.asc Description: This is a digitally signed message part ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
