Patch: Add %_specfile macro
This one has been commited by devzero2000 (IIRC) on HEAD branch, but not in rpm-5_4. It simply adds a %_specfile macro to get the file name of the spec file parsed. -- Regards, Per Øyvind rpm-5.4.4-add-_specfile-macro.patch Description: Binary data
Fix rpm -qa \*foo\*
The following patch fixes querying rpmdb with wildcards, whereas without this fix, it'll return all entries and not just those matching. -- Regards, Per Øyvind rpm-5.4.9-fix-rpm_qa-pattern.patch Description: Binary data
Support for terminate build on duplicate files
This patch enables termination of build on duplicate files by setting %_duplicate_files_terminate_build . -- Regards, Per Øyvind rpm-5.4.10-duplicate_files_terminate_build.patch Description: Binary data
Don't display suggests with --requires
This patch fixes so that soft dependencies won't be displayed with 'rpm -q --requires', only with 'rpm -q --suggests' -- Regards, Per Øyvind rpm-5.4.8-dont-show-suggests-with-requires.patch Description: Binary data
Silence excessive output from eu-strip
This patch silences excessive output from eu-strip during find-debuginfo.sh usage. -- Regards, Per Øyvind rpm-5.4.4-find-debuginfo-avoid-excessive-output-from-eu-strip.patch Description: Binary data
Some ruby 1.9 fixes
This patch fixes compatibility with ruby 1.9. -- Regards, Per Øyvind rpm-5.4.9-ruby1.9-fixes.patch Description: Binary data
Don't include buildroot in list of duplicate files printed
This patch will strip away the buildroot prefix for duplicate files listed, providing greater consistency with behaviour otherwise. -- Regards, Per Øyvind rpm-5.4.9-strip-buildroot-away-from-duplicate-files-list.patch Description: Binary data
Re: Fix rpm -qa \*foo\*
On Aug 26, 2013, at 2:19 PM, Per Øyvind Karlsen wrote: The following patch fixes querying rpmdb with wildcards, whereas without this fix, it'll return all entries and not just those matching. The issue of wildcard queries is/was discussed years ago when implemented, and the behavior implemented is/was as decided (for legacy compatible and principle of least surprise reasons) at the time. Discuss the feature, providing explicit usage cases and tests, under the existing CI framework if you wish the patch applied upstream @rpm5.org. I need to see consensus, not de facto, before enabling wild hacks (other than my own) in RPM releases. I personally have no interest in enabling foolish/sloppy queries on a random feature walk through patch streams of unknown viability, and poorly understood consequences, @rpm5.org, particularly when I am obligated to do the maintenance work to respond to future flaws and objections of other people's efforts. Last I heard you were too discouraged to undertake the reasonably sane effort(s) that are needed ... YMMV. Short answer (which I have said many times already): A blueprint at http://launchpad.net/rpm is the starting point for new feature deployment. 73 de Jeff__ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Fix incorrect sizeof usage to get string length
This patch fixes an incorrect attempt to get the string length with sizeof on a string allocated on the heap. -- Regards, Per Øyvind rpm-5.4.12-rpmfc-use-strlen-not-sizeof.patch Description: Binary data
Support terminate build on files listed twice.
This patch adds support for termination builds with files listed twice by setting %_files_listed_twice_terminate_build -- Regards, Per Øyvind rpm-5.4.10-files-listed-twice-terminates-build.patch Description: Binary data
Only generate ruby and python deps for executables and modules
This patch will make the dependency generator only generate ruby and python dependencies for executable and modules, this way preventing dependencies being generated for such as ie. private python files shipped with some package at some non-standard location, not meant to be available/exported for other use by other software. -- Regards, Per Øyvind rpm-5.4.7-only-generate-ruby-and-python-deps-for-executables-and-modules.patch Description: Binary data
Re: Don't display suggests with --requires
On Aug 26, 2013, at 2:21 PM, Per Øyvind Karlsen wrote: This patch fixes so that soft dependencies won't be displayed with 'rpm -q --requires', only with 'rpm -q --suggests' This patch can be done (by masking RPMSENSE_MISSINGOK using awk) without changing any C code. I'm also very reluctant to change existing/useful behavior of --requires with grep -v because it breaks compatibility behavior (that I rely on while developing) on systems with @rpm.org installed. 73 de Jeff -- Regards, Per Øyvind rpm-5.4.8-dont-show-suggests-with-requires.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Fix rpm -qa \*foo\*
2013/8/26 Jeffrey Johnson n3...@me.com On Aug 26, 2013, at 2:19 PM, Per Øyvind Karlsen wrote: The following patch fixes querying rpmdb with wildcards, whereas without this fix, it'll return all entries and not just those matching. The issue of wildcard queries is/was discussed years ago when implemented, and the behavior implemented is/was as decided (for legacy compatible and principle of least surprise reasons) at the time. Discuss the feature, providing explicit usage cases and tests, under the existing CI framework if you wish the patch applied upstream @rpm5.org. I need to see consensus, not de facto, before enabling wild hacks (other than my own) in RPM releases. We actually discussed this one quite a while a ago, where you acknowledged it yourself (the regression were introduced here: http://rpm5.org/cvs/chngview?cn=16299 ) I've provided you with a trivial reproducer, but considering the large amount of patches I have in queue, I don't really have the time nor that much incentive for starting on writing accompanying regression tests, especially not when I'm not overly existed about how the current regression tests are implemented/maintained, nor is my motivation for writing regression tests for (yet a bunch of) bug fix patches I maintain locally for a package. If commit access were restored, doing more of that kind maintenance work again would be of greater interest, but when not, I'm not very eager to take on responsibilities with the resulting tediousness.. I personally have no interest in enabling foolish/sloppy queries on a random feature walk through patch streams of unknown viability, and poorly understood consequences, @ rpm5.org, particularly when I am obligated to do the maintenance work to respond to future flaws and objections of other people's efforts. Last I heard you were too discouraged to undertake the reasonably sane effort(s) that are needed ... YMMV. And I'm now trying to, am I not? :) Seriously speaking, a lot of things came up and in the way for things, but I will at least sporadically be trying to push all ~fixes for now, then get back to ~features etc. with blueprints provided and code cleaned up whenever I find the time. :) Short answer (which I have said many times already): A blueprint at http://launchpad.net/rpm is the starting point for new feature deployment. This isn't a feature, but rather a bug fix. -- Regards, Per Øyvind
Change default package suffix for debug packages to -debuginfo
As -debuginfo is the most commonly used suffix for debug packages, there's also code with special behaviour for naming convention (see lib/dependens.c where '-debuginfo' rather than '-debug' is used, not to forget other software such as ie. gdb etc. also that expects this), this patch changes the default to -debuginfo. -- Regards, Per Øyvind rpm-5.4.7-change-to-debuginfo-suffix.patch Description: Binary data
Re: Don't display suggests with --requires
2013/8/26 Jeffrey Johnson n3...@me.com On Aug 26, 2013, at 2:21 PM, Per Øyvind Karlsen wrote: This patch fixes so that soft dependencies won't be displayed with 'rpm -q --requires', only with 'rpm -q --suggests' This patch can be done (by masking RPMSENSE_MISSINGOK using awk) without changing any C code. Feel free to provide a better solution. :) I'm also very reluctant to change existing/useful behavior of --requires with grep -v because it breaks compatibility behavior (that I rely on while developing) on systems with @rpm.org installed. IIRC rpm.org hasn't implemented support for RPMSENSE_MISSINGOK on dependencies, have they? Ie. isn't there's some incompatibilities in place already? :o) Well, you know better than me, at least behaviour introduced by this patch is what's been preferred by cooker users. :) -- Regards, Per Øyvind
Re: Don't include buildroot in list of duplicate files printed
On Aug 26, 2013, at 2:24 PM, Per Øyvind Karlsen wrote:
This patch will strip away the buildroot prefix for duplicate files listed,
providing greater consistency with behaviour otherwise.
While the approach is sensible, the deeper flaw is that duplicate
file checks added by Alexey Tourbin around the time of rpm-5.1.9
release do not scale.
Far deeper changes than cosmetically stripping a builroot path are
needed, likely with Bloom filters attached to all the binary packages
produced in a build, so that
/**
* Return intersection of two Bloom filters.
* @retval aBloom filter
* @param b Bloom filter
* @return 0 on success, -1 if {m,k} disagree or NULL pointers.
*/
int rpmbfIntersect(rpmbf a, const rpmbf b)
/*@modifies a @*/;
can be used to detect duplicate (and similarly shared/conflicting) files.
Build a kernel package (which has many more paths than most packages)
and time the additional checks added by Alexey Tourbin if you wish
to see the scaling problem in the existing implementation.
Or try building tests/millionfile-insanity.spec to measure the cost of
the added checks.
Note that the check sadded by Alexey are useful: my only objection is
that the implementation did not (and does not) scale with lots of files.
73 de Jeff
--
Regards,
Per Øyvind
rpm-5.4.9-strip-buildroot-away-from-duplicate-files-list.patch
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Make sure hdrfmt argv element is initialized
This patch should be pretty self-explaining.. :) -- Regards, Per Øyvind rpm-5.4.7-hdrfmt-fix-unitialized-argv-element.patch Description: Binary data
Re: Don't include buildroot in list of duplicate files printed
2013/8/26 Jeffrey Johnson n3...@me.com
On Aug 26, 2013, at 2:24 PM, Per Øyvind Karlsen wrote:
This patch will strip away the buildroot prefix for duplicate files
listed, providing greater consistency with behaviour otherwise.
While the approach is sensible, the deeper flaw is that duplicate
file checks added by Alexey Tourbin around the time of rpm-5.1.9
release do not scale.
Far deeper changes than cosmetically stripping a builroot path are
needed, likely with Bloom filters attached to all the binary packages
produced in a build, so that
/**
* Return intersection of two Bloom filters.
* @retval aBloom filter
* @param b Bloom filter
* @return 0 on success, -1 if {m,k} disagree or NULL
pointers.
*/
int rpmbfIntersect(rpmbf a, const rpmbf b)
/*@modifies a @*/;
can be used to detect duplicate (and similarly shared/conflicting) files.
Build a kernel package (which has many more paths than most packages)
and time the additional checks added by Alexey Tourbin if you wish
to see the scaling problem in the existing implementation.
Or try building tests/millionfile-insanity.spec to measure the cost of
the added checks.
Note that the check sadded by Alexey are useful: my only objection is
that the implementation did not (and does not) scale with lots of files.
I can't remember whether I've even actually run into any problems related
to this myself, but on a related note, the unpackage sub directory check is
very often giving false positives..
I have a patch to add support termination of build on unpackaged sub
directories, but considering that the check isn't reliable, I've left it
disabled by default, but I'll attach the patch none the less.
--
Regards,
Per Øyvind
rpm-5.4.10-unpackaged_subdirs_terminate_build.patch
Description: Binary data
Fix minor memlead
The following patch fixes a couple of minor memleaks. -- Regards, Per Øyvind rpm-5.4.7-fix-minor-memleaks.patch Description: Binary data
Fix miRE strings lacking null terminator
This patch ensures that strings has a null terminator at end, otherwise strings passed to mireRegexec might be missing it. -- Regards, Per Øyvind rpm-5.4.9-mire-fix-strings-lacking-null-terminator.patch Description: Binary data
Fix typo in rpmtag.h
Requires no explanation.. -- Regards, Per Øyvind rpm-5.4.9-fix-typo-in-rpmtag-header.patch Description: Binary data
Fix a couple of debugedit memleaks
Simple enough.. -- Regards. Per Øyvind rpm-5.4.10-fix-a-couple-of-debugedit-memleaks.patch Description: Binary data
Re: Support for terminate build on duplicate files
On Aug 26, 2013, at 2:25 PM, Per Øyvind Karlsen wrote: This patch enables termination of build on duplicate files by setting %_duplicate_files_terminate_build . This (and many other patches of yours) merely detect flaws which all have fairly simple resolutions that could be fully automated, not just terminating a build, creating a support issue, training up package monkeys to conform with mysterious distro packaging policies, etc. RPM is hard enough to use without creating quality assurance mechanisms and infrastructure that can be (and often are) disabled to Get The Job Done. rpmbuild seemed to be The Right Place to add additional bui9ld checks, like automating rpmlint. The rationale for augmenting rpmbuild was to detect problems earlier as part of the complex processes by which linux distros distribute packages. The problem with adding additional enforcing quality assurance checks to rpmbuild is that rpmbuild does not behave the same when additional checks are enabled/disabled. There are also no clearly better build process controls around imho. And that is watching your efforts in ROSA/OMA to improve package quality with rpmlint metrics and a score of 50 used as a threshhold rejection criteria. Instead, all that happens is that a support issue, and a frequently asked question, is created How do I disable these checks? The better approach (for simple problems like duplicate files) is to implement a resolution mechanism. There are certainly no consequences (which is why duplicate files is implemented as a warning, not an error, where this patch just adds FULLSTOP configurable rejection criteria to rpmbuild that is specific to distros and cannot be generally enabled/distributed with rpm). There is also no reason whatsoever why automation on %files manifests cannot be undertaken outside of rpmbuild using rpm -qlvp markup to mass change entire distro build recipes. Adding patches to rpmbuild which are normally disabled in distributed rpm releases just delays, not enhances, existing distro build systems). 73 de Jeff -- Regards, Per Øyvind rpm-5.4.10-duplicate_files_terminate_build.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Fix tagSwab handling of RPM_UINT64_TYPE
This patch fixes tagSwab() to work with RPM_UINT64_TYPE. I'm not sure why it's not using newer functions (ie. from endian(3)) with support for 64 integers rather than using two 32 bit integers, but I guess it might be related to legacy compatibility..? And if so, is it still relevant, or should code be updated? (I first did the fix with 64 bit swab function, but then figured that it might not be all too welcome upstream) Oh well, either way, this patch makes it anyways work though. :) -- Regards, Per Øyvind rpm-5.4.10-fix-64bit-tagSwab.patch Description: Binary data
Strip newlines from mono requires
This patch strips newlines for mono dependencies generated that really shouldn't be there.. ;) -- Regards. Per Øyvind rpm-5.4.7-mono-find-requires-strip-newlines.patch Description: Binary data
Re: Silence excessive output from eu-strip
The existing behavior of find-debuginfo.sh is already configurable: there is no One True Answer, nor is there any benefit to cosmetically removing errors from eu-strip. The far deeper flaw is that package executables are stripped multiple times even if no one has noticed. The entire means by which ELF executables are stripped (and -debuginfo packages are automatically produced) is overly complex and fragile when implemented through helper scripts. The better approach imho is to reimplement stripping/debuginfo production directly in RPM, which has linked against elfutils libraries since elfutils was written. There's nothing particularly hard about stripping/debuginfo, but the existing mechanisms are rather gross and cumbersome. 73 de Jeff On Aug 26, 2013, at 2:27 PM, Per Øyvind Karlsen wrote: This patch silences excessive output from eu-strip during find-debuginfo.sh usage. -- Regards, Per Øyvind rpm-5.4.4-find-debuginfo-avoid-excessive-output-from-eu-strip.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Fix rpm --verify segfault
This fixes a segfault with --verify (IIRC on packages signed with old signature type). The bug is discussed at https://qa.mandriva.com/show_bug.cgi?id=64378 No definite consensus were ever achieved in previous discussions about the correct fix for this bug, but the patch does at least work (tm) ;) -- Regards, Per Øyvind rpm-5.4.9-fix-verify-segfault.patch Description: Binary data
Don't remap i18n trings if enabled
This patch disables remapping of i18n strings if support of is enabled. Considering i18n strings are getting phased out, the importance of this patch is of course rather diminishing, but at least it does fix what it's supposed to fix. :) -- Regards, Per Øyvind rpm-5.4.9-dont-remap-i18n-strings-if-enabled.patch Description: Binary data
Re: Some ruby 1.9 fixes
On Aug 26, 2013, at 2:30 PM, Per Øyvind Karlsen wrote: This patch fixes compatibility with ruby 1.9. There are far far far deeper issues with ruby 1.8.x != 1.9.x behavior that need to be addressed. There is no consensus (no even a goal) stated that might lead to a more useful implementation. Instead there are gobs of macro magic glue to enable/disable and otherwise diddle up band-aids to a fundamentally flawed approach. Please read my comments (Sept 2009 iirc, +/- a year, was September) on rpm-devel@rpm5.org on fundamental design differences between embedding (as undertaken by me @rpm5.org) and bindings for a build system in ruby (as my existing implementation was (ab)used for). I see no rational way to extend RPM+RUBY usefully and portably by applying Yet More Macro Madness (in distro-du-jour dialect), with known and large differences in embedding behavior between ruby 1.8.x != 1.9.x implementations, particularly when all the cool kids interest is in creating a native ruby packaging system, not in devising more standard ruby *.rpm packaging. YMMV 73 de Jeff -- Regards, Per Øyvind rpm-5.4.9-ruby1.9-fixes.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Avoid double slashes in path for dirname trigger matching
This patch ensures that double '/' doesn't end up in dirname paths triggers matched against. -- Regards, Per Øyvind rpm-5.4.9-avoid-double-slash-in-path-for-dirname-filetrigger-matching.patch Description: Binary data
Don't try generate rpmfc dependencies from doc files
This patch prevents automatic dependencies from being generated for doc files. -- Regards, Per Øyvind rpm-5.4.12-dont-try-generate-rpmfc-dependencies-from-doc-files.patch Description: Binary data
Skip dependencies for block character devices
This patch prevents dependencies being generated for block character devices. -- Regards, Per Øyvind rpm-5.4.5-skip-dependencies-for-character-devices.patch Description: Binary data
Actually link against internal lua
This patch fixes an issue with internal lua not being linked against even if enabled. -- Regards, Per Øyvind rpm-5.4.7-actually-perform-linking-against-internal-lua.patch Description: Binary data
Apply python coloring from magic
Add missing string reported by libmagic on some python files. -- Regards, Per Øyvind rpm-5.4.5-rpmfc-apply-python-coloring-from-magic.patch Description: Binary data
Don't add rpmlib(VersionedDependencies) feature dependency
This patch comes from some discussion of ours longlong time ago about there no longer being any need for the rpmlib(VersionedDependencies) feature dependency.. So as I understood from you it being of no use, I yanked it locally in cooker at least.. :) -- Regards, Per Øyvind rpm-5.4.9-dont-add-versioneddependency-rpmlib-feature-dependency.patch Description: Binary data
Don't generate php dependencies on only executable php scripts
Subject says it all.. rpm-5.4.5-dont-generate-php-dependencies-only-when-executable.patch Description: Binary data
Re: Fix incorrect sizeof usage to get string length
On Aug 26, 2013, at 2:36 PM, Per Øyvind Karlsen wrote: This patch fixes an incorrect attempt to get the string length with sizeof on a string allocated on the heap. The line numbers and code both indicate that this patch is not against rpm5.org code. The proper fix here (imho) is _NOT_ to implement filtering policies (in this case perl only) for automagically filtering %defaultdocdir paths out of the set of executable files from which rpm dependencies are extracted. One approach (which I have pointed out to you and ROSA/Cooker developers several times) would be to steal the existing configurable hierarchy for enabling/disabling dependency extraction (though there is really little difference in compiling/reading various patterns, the whole idea that MIME suffixes and paths can be used as filtering policy hints is fundamentally flawed and non-portable). The value of checking %defaultdocdir is also fundamentalkly broken since there are many, not just one, path prefixes which cause files to automagically acquire a %doc attribute. The only reason for permitting the change where this flaw resides was to squash endless repeated complaints about RPM sux because it finds dependencies in %doc files! when there already exist several mechanisms/answers to the issue including chmod -x /usr/share/doc/*.pl and Don't put *.pl scripts in /usr/share/doc/*/ directories. that are adequate. Meanwhile I've fixed the de facto equivalent flaw in lib/rpmfc.c. Odd that coverity did not detect the flaw, but perhaps I wasn't paying attention at the time. 73 de Jeff -- Regards, Per Øyvind rpm-5.4.12-rpmfc-use-strlen-not-sizeof.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
find-debuginfo.sh: strip reloc debug sections
Here's a patch from devzero2000 that got lost on HEAD... -- Regards, Per Øyvind rpm-5.4.9-find-debuginfo-strip-reloc-debug-sections.patch Description: Binary data
Set proper file color for scripts using env in shellbang
I'm almost done with the first round of pushing (mainly ~pure) bug fix(/more trivial) patches for now.. -- Regards, Per Øyvind rpm-5.4.5-set-proper-file-color-for-scripts-using-env-in-shellbang.patch Description: Binary data
Re: Only generate ruby and python deps for executables and modules
See my other comments regarding path based filtering, all of which is non-portable even in linux, where paths/needs are on a de facto per-interpreter, per-distro, and per-FHS-version basis. General rule based filtering on content (i.e. using man 5 magic strings), or a more general configuration mechanism, needs to be attempted. I also see little need to expose (as @rpm.org has done) configuration that hardly anyone changes, and the need for changes is often measured in years, where a later version of RPM could easily be deployed). Short answer: Not the right fix. *shrug* 73 de Jeff On Aug 26, 2013, at 2:57 PM, Per Øyvind Karlsen wrote: This patch will make the dependency generator only generate ruby and python dependencies for executable and modules, this way preventing dependencies being generated for such as ie. private python files shipped with some package at some non-standard location, not meant to be available/exported for other use by other software. -- Regards, Per Øyvind rpm-5.4.7-only-generate-ruby-and-python-deps-for-executables-and-modules.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Update brp-compress with support for xz/lzma compression
This patch adds support for compressing man info pages with xz or lzma compression. -- Regards, Per Øyvind rpm-5.4.10-update-and-use-brp-compress.patch Description: Binary data
Fix neon saving error pages as target file
This patch fixes neon saving error pages when encountered to target file. I'm not entirely sure if this is the *correct* way to fix it though, but at least it does work... ;) On a related note, is neon failing to download whenever being redirected (ie. when downloading from sourceforge.net) a known issue? -- Regards, Per Øyvind rpm-5.4.10-fix-neon-saving-error-pages-as-target-file.patch Description: Binary data
Re: Fix rpm -qa \*foo\*
On Aug 26, 2013, at 2:51 PM, Per Øyvind Karlsen wrote: 2013/8/26 Jeffrey Johnson n3...@me.com On Aug 26, 2013, at 2:19 PM, Per Øyvind Karlsen wrote: The following patch fixes querying rpmdb with wildcards, whereas without this fix, it'll return all entries and not just those matching. The issue of wildcard queries is/was discussed years ago when implemented, and the behavior implemented is/was as decided (for legacy compatible and principle of least surprise reasons) at the time. Discuss the feature, providing explicit usage cases and tests, under the existing CI framework if you wish the patch applied upstream @rpm5.org. I need to see consensus, not de facto, before enabling wild hacks (other than my own) in RPM releases. We actually discussed this one quite a while a ago, where you acknowledged it yourself (the regression were introduced here: http://rpm5.org/cvs/chngview?cn=16299 ) Everyone's opinions -- including mine -- change with experience. Expecting me to remember and be consistent with a patch from 2y ago that you claim is/was related to rpm -qa \*foo\* regression from a wildcard behavior that has never been specified, only de facto, when there are other non-feature related behaviors that are often in need of fixing is unwise. The issue that needs consensus is whether rpm -qa \*foo\* is useful, particularly when there are other designed/planned/implemented implicit switches to permit rpm -qa ^.*foo.* i.e. your trivial reproducer is already a malformed *RE pattern, rather a sloppy/foolish DWIM naive fuzz-busting query. There already is a means I've provided you with a trivial reproducer, but considering the large amount of patches I have in queue, I don't really have the time nor that much incentive for starting on writing accompanying regression tests, especially not when I'm not overly existed about how the current regression tests are implemented/maintained, nor is my motivation for writing regression tests for (yet a bunch of) bug fix patches I maintain locally for a package. If commit access were restored, doing more of that kind maintenance work again would be of greater interest, but when not, I'm not very eager to take on responsibilities with the resulting tediousness.. I personally have no interest in enabling foolish/sloppy queries on a random feature walk through patch streams of unknown viability, and poorly understood consequences, @rpm5.org, particularly when I am obligated to do the maintenance work to respond to future flaws and objections of other people's efforts. Last I heard you were too discouraged to undertake the reasonably sane effort(s) that are needed ... YMMV. And I'm now trying to, am I not? :) At the time I replied, there was only a single patch in my mbox. I am proceeding through your e-mails as rapidly as I can. Seriously speaking, a lot of things came up and in the way for things, but I will at least sporadically be trying to push all ~fixes for now, then get back to ~features etc. with blueprints provided and code cleaned up whenever I find the time. :) Short answer (which I have said many times already): A blueprint at http://launchpad.net/rpm is the starting point for new feature deployment. This isn't a feature, but rather a bug fix. We disagree on what is a bug and what is a feature here. Which is why I suggested an explicit blueprint rather than willy-nilly application of hacky patches. 73 de Jeff 73 de Jeff -- Regards, Per Øyvind
Re: Change default package suffix for debug packages to -debuginfo
This patch is to macro madness configuration. RPM is expected to be legacy compatible even if distros don't give a hoot about what packaging conventions/naming might have been in place when a distro was released. You have also pointed out that gdb, not rpm, is responsible for establishing conventions. RPM is already sufficiently reconfigurable no matter what is distributed in @rpm5.org releases. See other comments re creating -debug* whatchamacallits in C internal to RPM+ELFUTILS and ripping out some hugely fragile/complex scripting. 73 de Jeff On Aug 26, 2013, at 3:01 PM, Per Øyvind Karlsen wrote: As -debuginfo is the most commonly used suffix for debug packages, there's also code with special behaviour for naming convention (see lib/dependens.c where '-debuginfo' rather than '-debug' is used, not to forget other software such as ie. gdb etc. also that expects this), this patch changes the default to -debuginfo. -- Regards, Per Øyvind rpm-5.4.7-change-to-debuginfo-suffix.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Don't display suggests with --requires
On Aug 26, 2013, at 3:06 PM, Per Øyvind Karlsen wrote: 2013/8/26 Jeffrey Johnson n3...@me.com On Aug 26, 2013, at 2:21 PM, Per Øyvind Karlsen wrote: This patch fixes so that soft dependencies won't be displayed with 'rpm -q --requires', only with 'rpm -q --suggests' This patch can be done (by masking RPMSENSE_MISSINGOK using awk) without changing any C code. Feel free to provide a better solution. :) Expecting me to address your needs if foolish. I have other tasks to do than write and test an awk script. I'm also very reluctant to change existing/useful behavior of --requires with grep -v because it breaks compatibility behavior (that I rely on while developing) on systems with @rpm.org installed. IIRC rpm.org hasn't implemented support for RPMSENSE_MISSINGOK on dependencies, have they? Ie. isn't there's some incompatibilities in place already? :o) You will need to address the issue with @rpm.org, not here. Meanwhile all the reasoning and the complete implementation was done a long time ago. Using a bit that other implementations/distros choose not to honor has nothing to do with what is implemented, nor what might need to be displayed using rpm -q. Well, you know better than me, at least behaviour introduced by this patch is what's been preferred by cooker users. :) And this isn't the place to honk you cooker warez. You submitted a patch for upstream inclusion, and you have my reply. 73 de Jeff -- Regards, Per Øyvind
Re: Make sure hdrfmt argv element is initialized
On Aug 26, 2013, at 3:09 PM, Per Øyvind Karlsen wrote: This patch should be pretty self-explaining.. :) A reproducer please. This may (or may not) be the right pace to fix, and there may be other places in need of fixing. None of this is self-explanatory. I routinely run under valgrind and in CI harnesses and fix all detected problems. The fact that thgere is some path that has not been exercised needs to be addressed no matter what patch is applied. 73 de Jeff -- Regards, Per Øyvind rpm-5.4.7-hdrfmt-fix-unitialized-argv-element.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Support terminate build on files listed twice.
On Mon, 26 Aug 2013, Jeffrey Johnson wrote: See other comments: Resolving simple build flaws rather than detecting and terminating a build configurably is what is needed. Avoiding unexpected breakage and avoiding new support load models is a Good Thing (tm) I would write that: Resolving simple build flaws and emitting a warning, rather than ... just as GCC permits, but does not require, -Werror and -pedantic-error as options That enables the Pedant to engage in self-abuse, without permitting him to become the dictator to require everyone else to follow the pedant's path to salvation or damnation -- Russ herrold __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Fix miRE strings lacking null terminator
On Aug 26, 2013, at 3:17 PM, Per Øyvind Karlsen wrote: This patch ensures that strings has a null terminator at end, otherwise strings passed to mireRegexec might be missing it. Is there a specific problem here? DO you have a reproducer? The use of alloca tells me that I applied a band-aid here for some reason I've long since forgot. The real problem (and fix) is likely elsewhere, not here, imho. 73 de Jeff -- Regards, Per Øyvind rpm-5.4.9-mire-fix-strings-lacking-null-terminator.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Fix typo in rpmtag.h
On Aug 26, 2013, at 3:24 PM, Per Øyvind Karlsen wrote: Requires no explanation.. So _THAT_ is why the harmless message is being displayed. ;-) Applied, thanks. The better (and p[lanned) fix is to rip out all code marked with SUPPORT_I18NSTRING_TYPE now that distros have had almost 1.5y to adjust to the change. 73 de Jeff -- Regards, Per Øyvind rpm-5.4.9-fix-typo-in-rpmtag-header.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Fix a couple of debugedit memleaks
Send to @rpm.org. So far, I track _EXACTLY_ what the @redhat.com glibc cabal recommends with no other changes. And the entire debugedit code base, replacing NSS with BeeCrypt digests (the right fix is to add a SHA1 implementation to debugedit.c directly to simplify upgrading changes). I also believe that debugedit.c should be distributed by other means than inclusion in RPM itself. There are at least 2 distros I am aware of that wish to use debugedit but not RPM that have asked for external debugedit.c 73 de Jeff On Aug 26, 2013, at 3:28 PM, Per Øyvind Karlsen wrote: Simple enough.. -- Regards. Per Øyvind rpm-5.4.10-fix-a-couple-of-debugedit-memleaks.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Fix variables getting overriden by /etc/os-release
The follow patch fixes /etc/os-release being sourced right into same environment as the configure script runs in, meaning that any existing variables with same names as found in /etc/os-release gets overriden. This patch sources /etc/os-release and prints the $ID variable in a sub-shell in order to avoid this problem. rpm-5.4.13-dont-override-existing-variables-with-etc-os-release.patch Description: Binary data
Re: Fix tagSwab handling of RPM_UINT64_TYPE
On Aug 26, 2013, at 3:42 PM, Per Øyvind Karlsen wrote:
This patch fixes tagSwab() to work with RPM_UINT64_TYPE.
I'm not sure why it's not using newer functions (ie. from endian(3)) with
support for 64 integers rather than using two 32 bit integers, but I guess it
might be related to legacy compatibility..?
And if so, is it still relevant, or should code be updated?
(I first did the fix with 64 bit swab function, but then figured that it
might not be all too welcome upstream)
Oh well, either way, this patch makes it anyways work though. :)
Patch looks correct, but there's likely other places that need fixing.
Yes this is ancient hysterically remnant code when unsigned long long
wasn't reliably/portably implemented.
There are no RPMTAG_* tags with RPM_UINT64_TYPE (though
@rpm.org may have added something).
Without a usage case, carrying around support for RPM_UNIT64_TYPE
is largely an unnecessary pointless task. Meanwhile there are most definitely
uses for UINT64 these days, just adding a mandatory tag with a UINT64 type
introduces instant legacy incompatibility and confusion at least at the
level of, say, changing to SHA256 or XZ compression.
Sure you can wave your hands (as @rpm.org may have done, not checked, dunno) and
make the use of UINT64 tags conditionally opt-in somehow.
I chose to fix slightly differently:
Index: header.c
===
RCS file: /v/rpm/cvs/rpm/rpmdb/header.c,v
retrieving revision 1.198.2.8
diff -p -u -w -r1.198.2.8 header.c
--- header.c28 Jun 2013 16:57:10 - 1.198.2.8
+++ header.c26 Aug 2013 21:34:57 -
@@ -398,7 +398,7 @@ static unsigned char * tagSwab(/*@out@*/
switch (he-t) {
case RPM_UINT64_TYPE:
{ rpmuint32_t * tt = (rpmuint32_t *)t;
-assert(nb == (he-c * sizeof(*tt)));
+assert(nb == (2 * he-c * sizeof(*tt)));
for (i = 0; i he-c; i++) {
rpmuint32_t j = 2 * i;
rpmuint32_t b = (rpmuint32_t) htonl(he-p.ui32p[j]);
--
Regards,
Per Øyvind
rpm-5.4.10-fix-64bit-tagSwab.patch
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: Fix variables getting overriden by /etc/os-release
*shrug* applied The entire idea that one can specify a vendor reliably in a file for access portably by AutoCrap is naive. 73 de Jeff On Aug 26, 2013, at 5:27 PM, Per Øyvind Karlsen wrote: The follow patch fixes /etc/os-release being sourced right into same environment as the configure script runs in, meaning that any existing variables with same names as found in /etc/os-release gets overriden. This patch sources /etc/os-release and prints the $ID variable in a sub-shell in order to avoid this problem. rpm-5.4.13-dont-override-existing-variables-with-etc-os-release.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Fix rpm --verify segfault
On Aug 26, 2013, at 3:52 PM, Per Øyvind Karlsen wrote: This fixes a segfault with --verify (IIRC on packages signed with old signature type). The bug is discussed at https://qa.mandriva.com/show_bug.cgi?id=64378 No definite consensus were ever achieved in previous discussions about the correct fix for this bug, but the patch does at least work (tm) ;) Yep, all very well known. I suspect the patch is correct in avoiding the segfault, but not personally looked at a reproducer, and CI test harnesses, all of which also need to change to achieve coverage testing. Meanwhile, as long as ROSA/Mandriva choose _NOT_ to officially support automated hkp:// retrieval, I choose a similar stance and choose _NOT_ to fix what is likely a bug officially. Any distro that wishes to pursue MANDATORY signature checking and elimination of --nodigests/--nosignatures everywhere in RPM on an official ROADMAP will have my immediate attention. Until then: *shrug* 73 de Jeff -- Regards, Per Øyvind rpm-5.4.9-fix-verify-segfault.patch
Re: Don't try generate rpmfc dependencies from doc files
See other comments regarding automagically filtering autodeps manifests based on either MIME suffix or paths. Its all fabulously fg=fragile and broken and needs to be implemented intelligently and generally, not ad hoc patches to fix Yet Another just realized convention. Note that the existing chmod -x /path/to/some/file can be used to disable extraction any time someone wishes to fix their packages, not complain about RPM. You can also re-enable the execute bit using %attr if youy truly need an executable file in %doc paths for wahtever bizarre reason. 73 de Jeff On Aug 26, 2013, at 4:02 PM, Per Øyvind Karlsen wrote: This patch prevents automatic dependencies from being generated for doc files. -- Regards, Per Øyvind rpm-5.4.12-dont-try-generate-rpmfc-dependencies-from-doc-files.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Skip dependencies for block character devices
On Aug 26, 2013, at 4:04 PM, Per Øyvind Karlsen wrote: This patch prevents dependencies being generated for block character devices. Any packaging that includes block/char devices is intrinsically busted. Use %dev instead. Its been implememnted for a L-O-N-G time. 73 de Jeff -- Regards, Per Øyvind rpm-5.4.5-skip-dependencies-for-character-devices.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Actually link against internal lua
Not the right fix afaict. lua is treated as a helper library and merged into librpmmisc when internal. But how lua gets linked into rpm is rather complicated. 73 de Jeff On Aug 26, 2013, at 4:05 PM, Per Øyvind Karlsen wrote: This patch fixes an issue with internal lua not being linked against even if enabled. -- Regards, Per Øyvind rpm-5.4.7-actually-perform-linking-against-internal-lua.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Debugedit busted in rpm-5.4.13
The following change breaks debugedit: http://rpm5.org/cvs/chngview?cn=17180 With this patch applied, debugedit will fail in following fashion: extracting debug info from /home/peroyvind/ABF/queue/augeas/BUILDROOT/augeas-1.0.0-4-mdk2013.0.x86_64-buildroot/lib64/libaugeas.so.0.16.0 Failed to produce debuginfo: debug format not supported: .init In the changelog there's a reference to some commit in rpm.org, yet I cannot seem to find any trace of it there either though.. -- Regards, Per Øyvind
Re: Apply python coloring from magic
Not the right fix. Here's why: RPM includes/uses magic strings returned from libmagic. For reproducible results, where external system magic changes arbitrarily, there are any number of problems that ensue because the (what used to be) /etc/magic text has changed. The only proper reproducible solution is to distribute/maintain (what used to be) /etc magic content directly in RPM. RPM used to carry --with-file=internal, removed by popular outcry. But chasing arbitrary strings across per-distro content isn't a solvable problem generally. Maintain per-distro patches as you wish. 73 de Jeff On Aug 26, 2013, at 4:07 PM, Per Øyvind Karlsen wrote: Add missing string reported by libmagic on some python files. -- Regards, Per Øyvind rpm-5.4.5-rpmfc-apply-python-coloring-from-magic.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Don't add rpmlib(VersionedDependencies) feature dependency
I'd love to apply this patch, but the ensuing legacy compatibility discussions would eat months of my time. So I choose my battles wisely, and won't apply the patch. tracking dependency is a polite euphemism for I-N-C-O-M-P-A-T-B-I-L-E invented to distract LSB (and others) from recognizing an incompatibility per-se. It truly the wrong engineering to mark all future packages forevermore with an unresolvable dependency simply to deploy a (usually necessary) incompatibility. Otherwise tracking dependencies -- particularly with no coordination between multiple forks/versions of rpm around -- are merely a pleasant fiction. 73 de Jeff On Aug 26, 2013, at 4:10 PM, Per Øyvind Karlsen wrote: This patch comes from some discussion of ours longlong time ago about there no longer being any need for the rpmlib(VersionedDependencies) feature dependency.. So as I understood from you it being of no use, I yanked it locally in cooker at least.. :) -- Regards, Per Øyvind rpm-5.4.9-dont-add-versioneddependency-rpmlib-feature-dependency.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Don't generate php dependencies on only executable php scripts
On Aug 26, 2013, at 4:13 PM, Per Øyvind Karlsen wrote: Subject says it all.. Um no. I can't tell whether you have sent a reversed patch or are attempting a change in behavior. RPM SHOULD extract dependencies only from executable files. This is advertised behavior because of chmod -x ... disabling. Feel free to start a discussion if you wish to change the implementation. But I have no desire to wander into a known mine field interpreter by interpreter. 73 de Jeff rpm-5.4.5-dont-generate-php-dependencies-only-when-executable.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Set proper file color for scripts using env in shellbang
On Aug 26, 2013, at 4:21 PM, Per Øyvind Karlsen wrote: I'm almost done with the first round of pushing (mainly ~pure) bug fix(/more trivial) patches for now.. This has _NOTHING to do with file colors (because its a script). Only elf executables have colors. Meanwhile I have no desire to chase the myriad recommended ways of having a script re-execute itself with an interpreter on an arbitrary path. Its not just #!/usr/bin/env /usr/bin/interpreter that need to be dealt with generally: see what perl does. One can _ALWAYS_ patch the code to invoke an interpreter on a known path, adding dependencies manually as needed to ensure that the interpreter exists on that path, for any distro serious about quality rpm packaging. 73 de Jeff -- Regards, Per Øyvind rpm-5.4.5-set-proper-file-color-for-scripts-using-env-in-shellbang.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Update brp-compress with support for xz/lzma compression
No interest because already there are huge amounts of breakage making *.spec files tied to per-distro choices of what compressor to invoke. I have to fix issues like this in nearly every Fedora package I look at, to replace explicit suffixes with a glob in %files manifests. Maintain outside of rpm as you wish: what compression is chosen by various/sundry distros isn't a solvable problem imho. 73 de Jeff On Aug 26, 2013, at 4:27 PM, Per Øyvind Karlsen wrote: This patch adds support for compressing man info pages with xz or lzma compression. -- Regards, Per Øyvind rpm-5.4.10-update-and-use-brp-compress.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Some ruby 1.9 fixes
Config vs RbConfig : https://github.com/ruby/ruby/blob/v1_9_3_327/lib/rbconfig/obsolete.rb#L4 so i understand 1.8.x (latest is 1.8.7 [1]) works with RbConfig too [2] ftp://ftp.ruby-lang.org/pub/ruby/1.8 On Mon, Aug 26, 2013 at 10:57 PM, Jeffrey Johnson n3...@me.com wrote: On Aug 26, 2013, at 2:30 PM, Per Øyvind Karlsen wrote: This patch fixes compatibility with ruby 1.9. There are far far far deeper issues with ruby 1.8.x != 1.9.x behavior that need to be addressed. There is no consensus (no even a goal) stated that might lead to a more useful implementation. Instead there are gobs of macro magic glue to enable/disable and otherwise diddle up band-aids to a fundamentally flawed approach. Please read my comments (Sept 2009 iirc, +/- a year, was September) on rpm-devel@rpm5.org on fundamental design differences between embedding (as undertaken by me @rpm5.org) and bindings for a build system in ruby (as my existing implementation was (ab)used for). I see no rational way to extend RPM+RUBY usefully and portably by applying Yet More Macro Madness (in distro-du-jour dialect), with known and large differences in embedding behavior between ruby 1.8.x != 1.9.x implementations, particularly when all the cool kids interest is in creating a native ruby packaging system, not in devising more standard ruby *.rpm packaging. YMMV 73 de Jeff -- Regards, Per Øyvind rpm-5.4.9-ruby1.9-fixes.patch __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org -- glen
Re: Don't include buildroot in list of duplicate files printed
I'm unconvinced that directories need to be treated differently than files.
There has been
%unpackaged_files_terminate_build
since forever. I still believe that the macros need to be removed
and the behavior needs to be made MANDATORY (if desired).
Alexey Tourbin also implemented some silent fixes to add
subdirs that were not specified, which is why you found it
more convenient to add a new macro for directories rarther
than files.
The core issue in need of resolving is when directories should
(or should not) be added to packaging.
I believe that all directories mentioned on every path (including /)
should be added to every package because that is the logical
end-point if _ANY_ directory is added to packaging. One can
quite easily design a packaging system that _NEVER_ includes any
directory, but rather creates directories as needed when mentioned
in file paths, and manages only files not directories, setting directory
permissions as side effects and lazily removing empty directories.
Meanwhile RPM permits both only files and every subdir component
without a clear consensus on what the Right Thing To Do actually is.
OTOH, I personally think that ignoring any/every file not mentioned
explicitly (or implicitly with glob patterns), with an explicit warning
listing all the unpackaged files, is better behavior. Its certainly useful
to cut-n-paste a bunch of paths into a %files manifest and then
adjust to whatever level of macro madness one wishes, a task
I do all the time when creating packages.
All of the rather pugly macro enablers/disablers was Red Hat
control phreak manglement ordered because a FULLSTOP
build failure is all that most package monkeys understand
about proper packaging.
YMMV and my personal packaging checks are clearly different than yours
if we disagree on mileage.
On Aug 26, 2013, at 3:12 PM, Per Øyvind Karlsen wrote:
2013/8/26 Jeffrey Johnson n3...@me.com
On Aug 26, 2013, at 2:24 PM, Per Øyvind Karlsen wrote:
This patch will strip away the buildroot prefix for duplicate files listed,
providing greater consistency with behaviour otherwise.
While the approach is sensible, the deeper flaw is that duplicate
file checks added by Alexey Tourbin around the time of rpm-5.1.9
release do not scale.
Far deeper changes than cosmetically stripping a builroot path are
needed, likely with Bloom filters attached to all the binary packages
produced in a build, so that
/**
* Return intersection of two Bloom filters.
* @retval aBloom filter
* @param b Bloom filter
* @return 0 on success, -1 if {m,k} disagree or NULL pointers.
*/
int rpmbfIntersect(rpmbf a, const rpmbf b)
/*@modifies a @*/;
can be used to detect duplicate (and similarly shared/conflicting) files.
Build a kernel package (which has many more paths than most packages)
and time the additional checks added by Alexey Tourbin if you wish
to see the scaling problem in the existing implementation.
Or try building tests/millionfile-insanity.spec to measure the cost of
the added checks.
Note that the check sadded by Alexey are useful: my only objection is
that the implementation did not (and does not) scale with lots of files.
I can't remember whether I've even actually run into any problems related to
this myself, but on a related note, the unpackage sub directory check is very
often giving false positives..
I have a patch to add support termination of build on unpackaged sub
directories, but considering that the check isn't reliable, I've left it
disabled by default, but I'll attach the patch none the less.
--
Regards,
Per Øyvind
rpm-5.4.10-unpackaged_subdirs_terminate_build.patch
