Re: [Rpm-maint] [rpm-software-management/rpm] First iteration of a 4.14.3 update release (#1078)
This pull request **fixes 1 alert** when merging 025537a689d8016d086935afda82266c3fa0199c into 4a9440006398646583f0d9ae1837dad2875013aa - [view on LGTM.com](https://lgtm.com/projects/g/rpm-software-management/rpm/rev/pr-dca2d891d691d6eba68127307abea1cabcc8d08c) **fixed alerts:** * 1 for FIXME comment -- 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/1078#issuecomment-587328617___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] First iteration of a 4.14.3 update release (#1078)
You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1078 -- Commit Summary -- * Remove capabilities instead of setting empty caps via. --setcaps * Add + use a bitmask for order-agnostic dependency types * Add support for sorting caret (^) higher than base version * %verify scriptlet dependencies are not supposed to affect ordering * build: check rich dependencies for special characters * Handle unsupported digests the same as disabled ones (RhBug:1652529) * Handle whitespace in uncompressed tar archive names, duh * Fix headerCheck() return code mismatch regression in 4.14.x * rpm2cpio cannot handle files over 4GB, error out cleanly (RhBug:1662481) * Dont let rpmlog() affect errno * fix small typos * rpm2archive: Fix file names for source rpms * find-debuginfo.sh: Handle position-independent executables * Correct rpm -ql exit value when optional -p is omitted (RhBug:1680610) * Show list of files only once when use rpm -ql and multiple rpm files * Drop internal-only visibility on rpmvs-related API * Make rpmsign exit values more consistent with our other tools * Add missing --fsmdebug output to capability setting * Fix copy-paste error wrt rpm-misc reference in manual (RhBug:1692724) * rpmio/digest_nss.c: fix build on musl * Fix segfault on fingerprinting symlink round (RhBug:1660232) * Detect kernel modules by .modinfo section presence for build-id generation * Support build-id generation from compressed ELF files (elfutils = 0.175) * Initialize verifyFlags for specialdir * Sort list of hard linked files in find-debuginfo.sh (RhBug:1421272) * Python generators: console_scripts entry points require setuptools * Use --dpbath only with full path (RhBug:1696408) * Fix rpm2archive behavior with multiple arguments * Fix recently introduced uninitialized variable warning in rpm2archive * Fix memleak in rpmfcApplyInternal() in standalone operation (eg rpmdeps) * Fix packages getting erased on failed update with dnf (RhBug:1620275) * Fix rpmfiles memory leak on %postuntrans file trigger preparation * Add step to find-debuginfo.sh script to compress annobin notes. * Canonicalize Python versions and properly handle != spec * Raise an error if reading a file during rpmbuild fails (#776) * rpmsign man page: Add line about rpmsign requiring a valid checksum * rpmpgp: Handle EOF without EOL better at END PGP * Fix off-by-one in hdrblobGet() making last entry unreachable (RhBug:1722921) * Fix memleak during transaction verify step in the NOKEY case. * Suppress inhibition lock warning message when DBus service is not available * Fix suspicious condition in selinux plugin * Handle incomplete escape seq in queryformat (RhBug:1755230) * Fix ancient memleak on %patch -P from unused popt arg pointer * Fix ancient memleak on %setup arguments * Document popt build-requirement and point a download location * Explicitly mention that the rpmio/ sub dir is under LGPL * Fix a minor memory leak on suppressed inhibition lock warning message * Fix regression reading some old v4.0 era packages (#610) * Add a local vasprintf() clone rvasprintf() to match rasprintf() * Fix rpmVerifySignatures() passing garbage as verify flags in rpm = 4.14 * Fix excessive use of thread local storage (RhBug:1722181) * Fix excessive use of thread local storage (RhBug:1722181), part II * Honor RPMSENSE_MISSINGOK on src.rpm rpmlib() dependencies too * Dont require signature header to be in single contiguous region part II * Fix regression on v3 package handling on database rebuild -- File Changes -- M COPYING (4) M INSTALL (4) M build/files.c (34) M build/pack.c (34) M build/parsePrep.c (10) M build/rpmbuild_internal.h (6) M build/rpmfc.c (4) M build/spec.c (2) M configure.ac (4) M doc/rpm.8 (2) M doc/rpmbuild.8 (5) M doc/rpmsign.8 (3) M lib/depends.c (3) M lib/fprint.c (6) M lib/fsm.c (4) M lib/header.c (5) M lib/headerfmt.c (12) M lib/order.c (2) M lib/package.c (80) M lib/poptALL.c (4) M lib/psm.c (2) M lib/query.c (9) M lib/rpmchecksig.c (3) M lib/rpmcli.h (2) M lib/rpmdb.c (2) M lib/rpmds.c (3) M lib/rpmds.h (3) M lib/rpmtriggers.c (1) M lib/rpmvercmp.c (19) M lib/rpmvs.c (3) M lib/rpmvs.h (11) M lib/signature.c (2) M lib/transaction.c (4) M plugins/selinux.c (2) M plugins/systemd_inhibit.c (6) M rpm2archive.c (35) M rpm2cpio.c (5) M rpmio/digest_nss.c (1) M rpmio/rpmlog.c (5) M rpmio/rpmpgp.c (5) M rpmio/rpmsq.c (10) M rpmio/rpmstring.c (32) M rpmio/rpmstring.h (6) M rpmpopt.in (9) M rpmsign.c (8) M scripts/find-debuginfo.sh (7) M scripts/pythondistdeps.py (28) M tests/rpmquery.at (33) M tests/rpmvercmp.at (26) -- Patch Links --
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] New setexecfilecon() errors on chroot installs (#1077)
The "obviously correct" fix in commit ab601b882b9d9d8248250111317615db1aa7b7c6 causes rpm --root installs to spit out errors that were not there before, eg > error: setexecfilecon: (/usr/sbin/glibc_post_upgrade.x86_64) No such file or > directory 15:bash-4.4.19-2.fc28 # [ 94%] 16:libsepol-2.7-6.fc28 # [100%] error: setexecfilecon: (/bin/sh) No such file or directory error: setexecfilecon: (/bin/sh) No such file or directory error: setexecfilecon: (/bin/sh) No such file or directory So setexecfilecon() has been routinely returning -1 but the buggy condition previously masked this. Our own code that does seemingly the exact same thing "manually" does not exhibit this behavior on chroot installs. Whether its a bug in libselinux or rpm, it needs investigating and fixing. -- 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/1077___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Sqlite --verifydb improvements (#1076)
The verify method on sqlite backend was buggy due to misunderstanding what and how PRAGMA integrity_check reports things. In addition, let sqlite do a foreign key check on our indexes on verify. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1076 -- Commit Summary -- * Fix sqlite verify results checking * Also do foreign key integrity check on sqlite db verify -- File Changes -- M lib/backend/sqlite.c (32) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1076.patch https://github.com/rpm-software-management/rpm/pull/1076.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/1076 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RFE: subdirectory handling in %autosetup (#1075)
In our package (nss), the release tarballs contain an extra directory hierarchy `nss-X.XX/nss`, while the upstream repo doesn't have it. So we need to use `pushd nss` and `popd` to apply patches from upstream. This practice doesn't work well with `%autosetup`, and even if we split the call to `%setup` and `%autopatch`, SCMs other than quilt get confused. It would be nice if there is a native way to support subdirectory inside tarballs. -- 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/1075___ 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 "%patchlist -f patches" work. v2 (#1043)
> readFileManifest strips them manually We seem to be talking about two different codebases, I don't see anything like that in here: https://github.com/rpm-software-management/rpm/blob/879dbdc0201f02fc0a04516be6f4c3e4a7a4fdd4/build/files.c#L2273 And looking at rpm 4.14 version of readFilesManifest(), it doesn't do anything about trailing blanks either. Which is all to be expected as that's the code from which readManifest() was adopted from. And neither does parseFiles(). I wouldn't exactly be shocked if there are bugs in how this all is handled, but lets get the facts straight first. Also, readManifest() needing such code smells like papering over the real issue somewhere else. -- 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/1043#issuecomment-586959163___ 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 "%patchlist -f patches" work. v2 (#1043)
pmatilai commented on this pull request.
> +spec->lineNum, name, poptStrerror(rc));
+ goto exit;
+}
+
+optCon = poptGetContext(NULL, argc, argv, optionsTable, 0);
+while ((arg = poptGetNextOpt(optCon)) > 0) {
+
+ char * filename = poptGetOptArg(optCon);
+ if (!filename) {
+ rpmlog(RPMLOG_ERR,
+ _("line %d: \"%%%s -f\" requires an argument.\n"),
+ spec->lineNum, name);
+ goto exit;
+ }
+
+ addSource(spec, 0, filename, RPMTAG_SOURCE);
With all the other -f's it's intentionally left to be somebody elses headache:
if you want it to be shipped with your srpm, you manually add a Source: for it,
but if not then its assumed to be something from the build environment, one way
or the other. Of course most of the time such things should be specified as
sources. So adding a source for the file in which your sources are defined ...
this gets a bit crazy.
And yeah, unlike %files -f, these cannot really be created by the build itself.
Which means this is for most practical purposes just a specialized version of
%include, with many/most of the same problems.
So what I'm really saying here is that we need to think this whole thing
through properly before digging further into implementation details.
--
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/1043#discussion_r380126703___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Auto-enable optimizations for non-rotational disks on Linux (#949)
Well, the question is whether we need minimize_writes and flush_io as separate parameters. If we think we do there is really no less complicated option. Adding a third switch really doesn't help. I'd rather set them both to autodetect pre default and have people that really need something else set them to their desired value. -- 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/949#issuecomment-586933276___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] More fpLookupSubdir cleanups (#1071)
Regarding your b81b4a35240f16fa8b45156b0151fab9e130a8e8 commit: fpLookupSubdir's slash handling is still somewhat broken, it tends to duplicate slashes when creating the link. The fingerprint lookup fortunately calls rpmCleanPath() with gets rid of the extra slashes again. BTW, why do the subDir entries in the fingerprints both have a leading and a trailing `/`? Is that something we should fix? -- 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/1071#issuecomment-586929882___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] More fpLookupSubdir cleanups (#1071)
Ok, that's what I thought. But it's somewhat brittle, that example from the mail will not work if FOO-DOC is installed before FOO as then /usr/share/FOO-1 will get created as directory and the install of FOO will fail with a RPMERR_EXIST_AS_DIR error. (I'm trying to make dir -> symlink-to-dir transactions work in the easy cases, I think this will be fixed with the changes as well.) -- 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/1071#issuecomment-586927889___ 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 "%patchlist -f patches" work. v2 (#1043)
ffesti commented on this pull request.
> +spec->lineNum, name, poptStrerror(rc));
+ goto exit;
+}
+
+optCon = poptGetContext(NULL, argc, argv, optionsTable, 0);
+while ((arg = poptGetNextOpt(optCon)) > 0) {
+
+ char * filename = poptGetOptArg(optCon);
+ if (!filename) {
+ rpmlog(RPMLOG_ERR,
+ _("line %d: \"%%%s -f\" requires an argument.\n"),
+ spec->lineNum, name);
+ goto exit;
+ }
+
+ addSource(spec, 0, filename, RPMTAG_SOURCE);
So what are you suggesting here beyond dropping the addSource()? Not supporting
-f for %sourcelist?
Thinking a bot more about this: The files containing the patches and sources
need to be there right at the beginning of the build - before %prep. So there
are not that many opportunities to create them during build. So one wonders
what to do with them other than adding them to the sources. We might need to
check that they are in the right place.
But if they are not part of the sources installing and building the SRPM will
surely fail.
--
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/1043#discussion_r380103106___
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 "%patchlist -f patches" work. v2 (#1043)
> Do you have a case where the STRIP_TRAILINGSPACE thing actually makes a > difference? > As commit > [b7d4277](https://github.com/rpm-software-management/rpm/commit/b7d427728b8ba8734ba47d51849a5736bdd727cd) > where readManifest() is added notes: > > > STRIP_TRAILINGSPACE is a bit misleading here as it actually affects whether > > a newline is added or not, but that's kind of consistent how its used > > elsewhere. > > There never was any handling for trailing spaces (beyond the newline) in the > originating readFilesManifest() either, so I'm dubious. Yes, without the patch the lines contain the trailing new line. readFileManifest strips them manually, so it does not depend on readManifest doing that. For the stringBuffer those newlines are added back (when STRIP_TRAILINGSPACE is set) as they are used as separators. But without stripping them first they get doubled. -- 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/1043#issuecomment-586920718___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] More fpLookupSubdir cleanups (#1071)
Yes, that's pretty much it. The finger printing code calculates a unique identifier for each file's location. This is comprised out of the device id and inode number of the parent dir and the filename. If the parent dir is not on disk yet, the closest dir is used + the path down to the parent to be installed. fpLookupSubdir looks for symlinks that may alias the files in this - not yet installed - part of the path. Yes, it assumes that the symlink actually gets installed. But this is not an unreasonable assumption as we do a file conflict checks for this symlinks, too. -- 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/1071#issuecomment-586885629___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] More fpLookupSubdir cleanups (#1071)
In case you wonder, I remember due to encountering this during the string-pool mass changes, and I do remember having a manual test-case for commit b81b4a35240f16fa8b45156b0151fab9e130a8e8. Too bad I didn't create an automated test back then :disappointed: -- 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/1071#issuecomment-586872904___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] More fpLookupSubdir cleanups (#1071)
IIRC this is the reproducer case: http://lists.rpm.org/pipermail/rpm-maint/2008-April/002051.html -- 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/1071#issuecomment-586870800___ 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)
That sounds really, really bizarre and wrong. headerUnlink() is an internal-only leftover, you always simply call headerFree() when you're done with it, and that takes care of the refcount internally. There aren't that many cases where you'd call headerLink() either, typically its used to hang on to a header retrieved from rpmdbNextIterator() (because you only get a weak ref there). And like you noticed, rpm internals don't generally call headerLink() either, headerGetString() and the like certainly do not. The main (and probably only) candidate for wildly increasing reference count that I can think of is calling rpmteHeader() without calling headerFree() when done. What version of rpm are we talking about here, and is the source to your program somewhere that I could see? -- 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-586868453___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] update OCaml requires/provides to cover also cmx (#1070)
> Three problems with it: > > 1. It would be regressive to current functionality for no good reason. > 2. We don't have a way of distributing this in any kind of reasonable > fashion through rpm-extras. > 3. IMO, That's not what rpm-extras is for. It's for staging things to > eventually integrate into rpm tree. Negative on 3, that's exactly the other way around. Rpm itself is still carrying far too much baggage that doesn't belong in it, and these language specifics are exactly the kind of thing that we're pushing *out* of rpm. Not because they're inherently bad or anything, but because we are the worst possible keepers of that stuff, this belongs into hands of people who know and care about those languages. As for 1, that's a distro integration issue. We did similar things with 4.15 and the world didn't collapse. 2. is a legit concern wrt rpm-extras though. -- 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/1070#issuecomment-586864142___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
