Re: Embedded python fix
2013/8/9 Jeffrey Johnson n3...@me.com On Aug 8, 2013, at 9:29 PM, Per Øyvind Karlsen wrote: 2013/8/8 Per Øyvind Karlsen pkarl...@rpm5.org The following patch fixes the syntax of the python initialization code that resulted in neither the output redirection working nor the rpm python module being loaded. This patch makes sure that the output buffer gets truncated after use, otherwise new output will be appended to it and it all being printed each time. Regression test please. It would also help if you stated the goal of the exercise: I am unaware of any current usage case for embedded python anywhere. Yes I know auite well what I intended when I did the implementation. Here's an updated version of the python module init patch with a regression test added. -- Regards, Per Øyvind rpm-5.4.13-fix-rpmpython-module-import-init.patch Description: Binary data
Re: Fix neon saving error pages as target file
2013/8/29 Jeffrey Johnson n3...@me.com On Aug 29, 2013, at 4:13 PM, Matthew Dawkins wrote: Idk if this an official item on the ROADMAP, but having support for 30+ diff redirects in RPMIO would be a nice feature, useful to us hobbyists. Especial redirects from sourceforge or googlecode. Network support is not an official ROADMAP item: in fact quite the opposite, as Have it your own way! desired distributing RPM with network support (not just redirects) disabled. Then there is the perceived issue of external vs internal network transport that has been discussed for years. And external downloader support, with RPM denied all network access on build machines and in chroot's, is what I am continually told is what rpm SHOULD do. Both ROSA/Mandriva have chosen _NOT_ to support network transport in RPM. ? I've enabled it since long ago: https://qa.mandriva.com/show_bug.cgi?id=64914 -- Regards, Per Øyvind
Re: Set proper file color for scripts using env in shellbang
2013/8/27 Jeffrey Johnson n3...@me.com 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. Well, terminology was probably adopted by what used in rpmfc.c, quoting a few lines below change and included in patch: Set color based on interpreter name 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. I'm not sure whether I'm following you or not, do you mean to imply that any distro with /usr/bin/env in shell bang isn't serious about quality rpm packaging? /usr/bin/env in shellbang is quite widespread in use, and if one wanna do automatic dependency generation with correct detection of script types, one kinda have to take it into consideration.. If you have any details on providing any better solutions, I'm all ears. -- Regards, Per Øyvind
Re: Don't generate php dependencies on only executable php scripts
2013/8/27 Jeffrey Johnson n3...@me.com 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. Well, considering that php is pretty much near exclusively used on server side for web development and that these php files are ~never invoked directly as executable files, I figured that why extracting php dependencies from executable files only is unfeasible should be fairly obvious enough by itself..? :) -- Regards, Per Øyvind
Re: Fix rpm -qa \*foo\*
2013/8/26 Jeffrey Johnson n3...@me.com 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 Other and more efficient means are rather irrelevant in this context... The undeniable fact is that the existing and expected behaviour changed in changeset #16299 due to what seems like an apparent coding mistake, breaking usage of 'rpm -qa \*foo\*' as is used by many (whether it being inefficient, better ways exists or not etc. is really besides the point as educating end users about habits goes beyond the scope of the discussion and bug fix here), making it hard to dismiss as not being a regression that should be fixed.. Luser will only notice what's expected and used to work, no longer working, blissfully ignorant and careless about what you debate and reject this patch based on.. -- Regards, Per Øyvind
Fix perl bindings breakage over xmalloc() use
Seems like xmalloc() is no longer exported by the rpm libraries, leading to situations like this with the perl bindings that uses it a couple of places: t/01.rpm.t .. 1/12 # Failed test 'use RPM;' # at t/01.rpm.t line 7. # Tried to use 'RPM'. # Error: Can't load '/home/peroyvind/ABF/queue/rpm/BUILD/rpm-5.4.13/perl/blib/arch/auto/RPM/RPM.so' for module RPM: /home/peroyvind/ABF/queue/rpm/BUILD/rpm-5.4.13/perl/blib/arch/auto/RPM/RPM.so: undefined symbol: xmalloc at /usr/lib/perl5/5.16.3/x86_64-linux-thread-multi/DynaLoader.pm line 190. # at (eval 4) line 2. Attached you'll find a patch changing it to use malloc() in stead. :) -- Regards, Per Øyvind rpm-5.4.13-perl-bindings-do-not-use-xmalloc.patch Description: Binary data
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
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: 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
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
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
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
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
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
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
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
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: Embedded python fix
2013/8/9 Jeffrey Johnson n3...@me.com On Aug 9, 2013, at 1:59 AM, Per Øyvind Karlsen wrote: 2013/8/9 Jeffrey Johnson n3...@me.com On Aug 8, 2013, at 9:29 PM, Per Øyvind Karlsen wrote: 2013/8/8 Per Øyvind Karlsen pkarl...@rpm5.org The following patch fixes the syntax of the python initialization code that resulted in neither the output redirection working nor the rpm python module being loaded. This patch makes sure that the output buffer gets truncated after use, otherwise new output will be appended to it and it all being printed each time. Regression test please. It would also help if you stated the goal of the exercise: I am unaware of any current usage case for embedded python anywhere. Ah, yeah, I guess I could do a bit better explaning things, too much tunnel focus too easily assuming that anything I focus on of course must be obvious to everyone else.. ;) I'll try get around to write one. PS: I'm planning on pushing all of my patches that I've labelled as upstream friendly ready to merge over the next period. You can push all you want. I've already incorporated all the patches that I consider acceptable, and responded with suggestions on what changes I think need doing. This cannot be right.. Quite a while ago, I did start on documenting all of my patches with instructions on whether to commit etc. for mdawkins, something that he started on (ie. see all entries in changes starting with - mdawkins: applied mdv, which are all patches of mine), which you then later told him (before finishing) to stop doing related to your professional interests. You can find these patches with comments at https://abf.rosalinux.ru/mdk/rpm/blob/master/rpm.spec Many of these are plain and simple bug fixes not related to anything distro specific . I refuse to claim any responsibility nor involvement in the issues of yours (that I've been just as much affected by myself) that's been preventing these from being merged. Repeatedly, just not publically because I get gang-raped by distro politics on ROSA and Mandriva mailing lists. It's not like you're alone, not at all... The relevance of this, however, is rather questionable in this context. I'm wondering however if perhaps doing a import of cvs to git, apply my patches to my branch and make available (be it the repo itself, or patches generated with 'git format-patch') might just be a more convenient way to make things a bit less messy and more convenient for you to review.. You have heard me respond to cvs-git many many many times: Who does the work? Note that the _ENTIRE_ repository needs to be converted, not just whatever branch you happen to want to hack on. I wasn't speaking about doing the conversion for the upsteam repo, but rather merely importing to a repo of mine in order to easier keep track of changes and better be able to perform any maintenance work and what not (ie. such as bothering with writing more regression tests, which my motivation for doing has been running quite low from maintaining every change as patches for rpm package). This way it would be easier for me to maintain different kind of changes in different repos and easily be able to clean up and do improvements to code without having to rediff a whole lot of patches over and over.. I'm merely trying to be service minded and better meet whatever expectations that you might have for your convenience, I'm really running out of ideas here.. And if you think the conversion is trivial, then please go examine launchpad.net/rpm cvs - bzr import, where paid Canonical professional support staff have been unable to fix the import for years. Please note that the problems are due to the complexity of the task and ancient breakage in cvs: Canonical support staff are highly competent, polite, and professional in every interaction I've ever had in Launchpad. I'm just saying that cvs - VCS-du-jour is a highly non-trivial task that will likely take weeks to accomplish. I've expressed interest in this before, but currently it's just not what I'm talking about nor what I have the time and interest in giving any priority to look at.. I personally like cvs, its more than good enough for small teams, and there plain and simply aren't any patch submissions that I cannot review in moments. Your recent patch submissions were all 1-liners, with obvious visual flaws. Sure, for some, but not all of.. So no, git does not make reviews easier. Okay, I'll start just posting the patches to this list then. I have almost 200 patches maintained locally, roughly 1/3 of those patches are bug fixes (not distro specific in most cases IIRC) which I think should be pretty much obvious enough by themself without any mess for most cases. SInce what you consider a bug is detected/fixed on ROSA/Mandriva, all your patches are distro-specific. Ehr, no? The patches are fixed in, but not specific to.. Meanwhile I won't discuss what hasn't been
Re: Embedded python fix
2013/8/11 Jeffrey Johnson n3...@me.com
On Aug 8, 2013, at 4:01 PM, Per Øyvind Karlsen wrote:
The following patch fixes the syntax of the python initialization code
that resulted in neither the output redirection working nor the rpm python
module being loaded.
The original syntax WORKSFORME and I cannot reproduce the
problem you claim to be seeing:
[jbj@ha wdj54]$ ./rpm -E '%{python:print -- python: Snake Eggs!,}'
-- python: Snake Eggs!
[jbj@ha wdj54]$ export foo=`./rpm -E '%{python:print -- python:
Snake Eggs!,}'`
-bash: !,}'`: event not found
[jbj@ha wdj54]$ export foo=$(./rpm -E '%{python:print -- python:
Snake Eggs!,}')
[jbj@ha wdj54]$ echo $foo
-- python: Snake Eggs!
Please stop sending silly patches (this patch adds semi-colons at end of
statement),
and is otherwise wasting my time attempting to discover a reproducer.
Increasingly I suspect that its all those patches that you are about to
push that may be related to differences in behavior.
Have you ever actually tested these embeddings in actual usage beyond
regression tests?
The issue here is the same as for the lua bug fix I submitted earlier,
namely that the output is printed directly to stdout without being
redirected as intended.
Try expand your python example above within an actual spec file and you'll
notice that the output won't actually end up in the parsed spec file, but
rather be printed to stdout right away.
This illustrates some of the same problems as with the wast amount of bug
fixes I maintain locally, namely the lack of testing in real world usage,
leaving you to categorically dismiss any bugs found.
Not really something that's to encouraging for reporting any bugs nor
submitting any patches..
--
Regards,
Per Øyvind
Re: Embedded python fix
2013/8/9 Jeffrey Johnson n3...@me.com On Aug 8, 2013, at 9:29 PM, Per Øyvind Karlsen wrote: 2013/8/8 Per Øyvind Karlsen pkarl...@rpm5.org The following patch fixes the syntax of the python initialization code that resulted in neither the output redirection working nor the rpm python module being loaded. This patch makes sure that the output buffer gets truncated after use, otherwise new output will be appended to it and it all being printed each time. Regression test please. It would also help if you stated the goal of the exercise: I am unaware of any current usage case for embedded python anywhere. Ah, yeah, I guess I could do a bit better explaning things, too much tunnel focus too easily assuming that anything I focus on of course must be obvious to everyone else.. ;) I'll try get around to write one. PS: I'm planning on pushing all of my patches that I've labelled as upstream friendly ready to merge over the next period. I'm wondering however if perhaps doing a import of cvs to git, apply my patches to my branch and make available (be it the repo itself, or patches generated with 'git format-patch') might just be a more convenient way to make things a bit less messy and more convenient for you to review.. I have almost 200 patches maintained locally, roughly 1/3 of those patches are bug fixes (not distro specific in most cases IIRC) which I think should be pretty much obvious enough by themself without any mess for most cases. Beyond these, I have some various new features and enhancements that's spread apart way too many patches for them to be anything else than scary to others, I intend to clean up these and hopefully get around to write some regression tests, I'm thinking that having my own git repo checked out from cvs might be even more convenient for these.. WDYT? I'm eager to rid myself of the far too many patches I've maintained locally and I really think a significant part of these might just be of some nice value to others as well. :) Lemme know what way you'd prefer for me to contribute them, I at figure that I should at least not just start spamming this list with each and everyone of them at once.. :o) -- Regards, Per Øyvind Yes I know auite well what I intended when I did the implementation. 73 de Jeff
some regressions in rpm 5.1.12
The following patch fixes a regression in rpmlua where it no longer overrides the luaB_print() function with the one provided by rpm_print(). -- Regards, Per Øyvind rpm-5.4.12-fix-rpmlua-print.patch Description: Binary data
Embedded python fix
The following patch fixes the syntax of the python initialization code that resulted in neither the output redirection working nor the rpm python module being loaded. -- Regards, Per Øyvind rpm-5.4.12-fix-rpmpython-module-import-init.patch Description: Binary data
Re: Embedded python fix
2013/8/8 Per Øyvind Karlsen pkarl...@rpm5.org The following patch fixes the syntax of the python initialization code that resulted in neither the output redirection working nor the rpm python module being loaded. This patch makes sure that the output buffer gets truncated after use, otherwise new output will be appended to it and it all being printed each time. -- Regards, Per Øyvind rpm-5.4.12-truncate-output-buffer-after-use.patch Description: Binary data
Re: rpm 5.4.12 regressions
2013/8/6 Jeffrey Johnson n3...@me.com
On Aug 6, 2013, at 12:31 PM, Jeffrey Johnson wrote:
On Aug 6, 2013, at 9:55 AM, Per Øyvind Karlsen wrote:
Meanwhile Write a test case. is the only sane response to preventing
regressions.
Yes, I've included a simple regression test in the patch included which
fixes the regression as well.
And the regression test case is visibly syntactically incorrect:
--- rpm-5.4.12/tests/Makefile.am.rpmluaext~ 2013-08-06 15:52:53.941594400
+0200
+++ rpm-5.4.12/tests/Makefile.am 2013-08-06 15:52:42.851402687 +0200
@@ -974,6 +974,7 @@ check-convert:
check-lua:
@echo === $@ ===
@-${rpm} -E '%{lua:print(-- lua: Hard Rocks!)}'
+ @-${rpm} -E '%{lua:print(rpm.expand(-- lua: rpm macro expansion
works on rpm %{_rpmversion}!))
@-${rpm} -e lua-test
@-${rpm} -U lua-test/lua-test-*.noarch.rpm
@-${rpm} -e lua-test
One last note:
rpm -E '%{_rpmversion}'
expands a macro without any need for lua or rpmlua modules.
You really need to think through how Mandriva-like is using RPM. If through
bindings, there are any number of ways to expand a macro through most (I
suspect all)
of the bindings.
Its sheer lunacy to add complexity when simple gets the job done.
As said before, it was nothing but a reproducer, it could've just as well
expanded any other macro or used any other function provided by the lua rpm
extension..
--
Regards,
Per Øyvind
perl-URPM upstream git repo
Hi! I noticed the following commit: http://rpm5.org/cvs/chngview?cn=17164 The correct location of the upstream code repositoy is found at: https://abf.rosalinux.ru/moondrake/perl-URPM -- Regards, Per Øyvind
Re: perl-URPM upstream git repo
2013/8/6 Jeffrey Johnson n3...@me.com On Aug 6, 2013, at 11:47 AM, Per Øyvind Karlsen wrote: Hi! I noticed the following commit: http://rpm5.org/cvs/chngview?cn=17164 The correct location of the upstream code repositoy is found at: https://abf.rosalinux.ru/moondrake/perl-URPM Perhaps, from a moondrake POV. I haven't any idea what reality actually is. I haven't time to sift through Mandriva distro politics: the svn repository will be used because the code is stable and available. Considering that I'm the (only) one who maintained the code that was in the Mandriva svn and the one who maintains the code in the git repo on ABF, also being the only one who does so (at least for what rpm5 compatible version conserns), while it's from what the version in cooker is using, it seems a bit silly sticking to an obsolete version from a repository that hasn't been in use since for over a year.. -- Regards, Per Øyvind
Re: perl-URPM upstream git repo
2013/8/6 Jeffrey Johnson n3...@me.com On Aug 6, 2013, at 12:31 PM, Per Øyvind Karlsen wrote: 2013/8/6 Jeffrey Johnson n3...@me.com On Aug 6, 2013, at 11:47 AM, Per Øyvind Karlsen wrote: Hi! I noticed the following commit: http://rpm5.org/cvs/chngview?cn=17164 The correct location of the upstream code repositoy is found at: https://abf.rosalinux.ru/moondrake/perl-URPM Perhaps, from a moondrake POV. I haven't any idea what reality actually is. I haven't time to sift through Mandriva distro politics: the svn repository will be used because the code is stable and available. Considering that I'm the (only) one who maintained the code that was in the Mandriva svn and the one who maintains the code in the git repo on ABF, also being the only one who does so (at least for what rpm5 compatible version conserns), while it's from what the version in cooker is using, it seems a bit silly sticking to an obsolete version from a repository that hasn't been in use since for over a year.. Perhaps silly ... I am doing releases more often than monthly, and building directly from multiple checkouts from tip directly into RPM's source tree. I cannot afford to be stopped by confused issues of perl-URPM upstream that cause an RPM build to fail. Note that my current rpm tree (headed for release) of 488K LOC (from scan.coverity.com) looks like this: [jbj@ha wdj54]$ ldd .libs/rpm | wc -l 100 That is 100 libraries linked with a maximally configured rpm. (and that 100 libraries does not include additional libraries linked by modules) *shrug* wrto perl-URPM integration into RPM. I haven't time to identify what perl-URPM upstream actually is. In fact I'm told privately that it isn't your tree (yes I quite well understand the efforts you have put into the Moondrake perl-URPM). Whoever told you so, must have a good imagination or some other agenda.. There's noone else doing any work on perl-URPM (except for in Mageia), and this is the tree that the perl-URPM version in cooker is based on. -- Regards, Per Øyvind
Re: rpm 5.4.12 regressions
2013/7/31 Jeffrey Johnson n3...@me.com
On Jul 31, 2013, at 1:49 PM, Per Øyvind Karlsen wrote:
Attached you'll find a couple of patches fixing regressions in rpm
5.4.12.
The first patch is a lua, not an rpm, problem.
Your 2nd patch introduces a memory leak: every pointer passed is malloc'd.
Indeed, I guess this one might be more correct then..?
Another regression I'm more puzzled by though is a lua one:
$ rpm -E '%{lua:print(rpm.expand(%_rpmversion))}'
error: Lua script failed: [string lua]:1: attempt to index global
'rpm' (a nil value)
0 (empty)
Dunno ... write a test case if you wish to prevent regressions in the
rpmlua module.
To add some more context, what happens is that the 'rpm' lua module
(luaopen_rpm()) no longer works, I'm trying to study the API to figure out
what goes wrong without any luck..
I suppose I'm not alone experiencing this one?
--
Regards,
Per Øyvind
rpm-5.4.12-fix-double-free.patch
Description: Binary data
rpm 5.4.12 regressions
Attached you'll find a couple of patches fixing regressions in rpm 5.4.12.
Another regression I'm more puzzled by though is a lua one:
$ rpm -E '%{lua:print(rpm.expand(%_rpmversion))}'
error: Lua script failed: [string lua]:1: attempt to index global 'rpm'
(a nil value)
0 (empty)
Skimming through changes to rpmlua.c, I'm not able to spot anything
obviously wrong..?
--
Regards,
Per Øyvind
rpm-5.4.12-drop-missing-NODEV-lua-constant-on-linux.patch
Description: Binary data
rpm-5.4.12-copy-Value-string.patch
Description: Binary data
Re: Does rpm really need to stop file check immediately when an issue is detected?
2013/5/24 Denis Silakov dsila...@gmail.com Hi all, During discussions with ROSA and OpenMandriva maintainers, we have found out that update of packages to newer versions sometimes takes much longer than it could due to rpmbuild specifics (I mean not 'rpm -iU', but the process of adopting spec file for a newer upstream version). The particular claiming is about rpmbuild exiting immidiately when a critical error concerning file lists is detected (file not found, installed but unpackaged file found, and some other issues like file listed twice which terminate the build in ROSA/MDV). However, the rpmbuild could continue the work to detect more issues with files, otherwise maintainers are able to detect and fix only one error per build iteration. And in case of large packages with large changes, this leads to a need to perform a lot of build iterations to eliminate all issues, though the build itself is proved to be successful and just takes the time. The particular improvement suggestions are like the following: 1) If a package has several subpackages, then check file lists in every subpackage 2) Perform all checks at once, do not return RPMRC_FAIL immediately if one of them failed Here is a rough patch implementing this behavior which is currently used in OpenMandriva and available for ROSA, as well: https://abf.rosalinux.ru/**openmandriva/rpm/raw/master/** rpm-5.4.10-postpone_**subpackage_build_failures.**patchhttps://abf.rosalinux.ru/openmandriva/rpm/raw/master/rpm-5.4.10-postpone_subpackage_build_failures.patch What do people think? Are others interested in such modifications? I've had it on my mind myself, but never followed up on implementing such behaviour, but I'll take a closer look at and review your patch. :) -- Regards, Per Øyvind
Re: Corrupt RPM
2012/10/16 Janis Elmeris janis.elme...@intelligentsystems.lv Hello! I accidentally upgraded a package with a lot of dependencies inluding rpm and db, and at some point also aborted the upgrade, and now I have a broken RPM. :( Right after sending the abort command I got these error messages: rpmdb: unrecognized name-value pair: set_create_dir rpmdb: unrecognized name-value pair: set_create_dir error: db4 error(22) from dbenv-open: Invalid argument error: cannot open Packages index using db3 - Invalid argument (22) error: //var/lib/rpm: open rpm database failed Aborted (core dumped) I've done rm /var/lib/rpm__db.00* and rpm --quiet -qa (the __db* files reappeared) and rpm -qa gives me the list of installed packages all right, including: db4.7-4.7.25.4-6.x86_64 db5.3-5.3.21.0-1.x86_64 rpm-5.4.10-18.x86_64 However, rebuilding still complains: # rpm -vv --rebuilddb D: pool fd: created size 392 limit -1 flags 0 D: pool iob:created size 48 limit -1 flags 0 D: pool mire: created size 136 limit -1 flags 0 D: pool lua:created size 64 limit -1 flags 0 D: pool ts: created size 1200 limit -1 flags 0 D: pool db: created size 328 limit -1 flags 0 D: pool dbi:created size 472 limit -1 flags 0 D: rpmdb: cpus 8 physmem 12042Mb D: opening db environment /var/lib/rpm/Packages thread:lock:log:mpool:txn D: opening db index /var/lib/rpm/Packages create:thread:auto_commit mode=0x2 rpmdb: BDB0641 __db_meta_setup: /var/lib/rpm/Packages: unexpected file type or format D: closed db index /var/lib/rpm/Packages D: closed db environment /var/lib/rpm/Packages error: cannot open Packages(0) index: Invalid argument(22) DB: Berkeley DB 5.3.21: (May 11, 2012) error: cannot open Packages database in /var/lib/rpm D: pool tsi:created size 48 limit -1 flags 0 D: pool tsi:reused 1, alloc'd 1, free'd 1 items. D: pool ts: reused 0, alloc'd 1, free'd 1 items. D: pool db: reused 0, alloc'd 1, free'd 1 items. D: pool dbi:reused 0, alloc'd 1, free'd 1 items. D: pool lua:reused 0, alloc'd 1, free'd 1 items. D: pool mire: reused 0, alloc'd 1, free'd 1 items. D: pool iob:reused 0, alloc'd 1, free'd 1 items. D: pool fd: reused 5, alloc'd 1, free'd 1 items. D: exit code: -2 In addition, when I run the server package manager (poldek, which BTW also decided to get upgraded along the way), I get an additional complaint about Requirename: BDB0641 __db_meta_setup: /var/lib/rpm/Requirename: unexpected file type or format This is what has to say about the file formats: # file /var/lib/rpm/Requirename /var/lib/rpm/Requirename: Berkeley DB (Hash, version 9, native byte-order) # file /var/lib/rpm/Packages /var/lib/rpm/Packages: Berkeley DB (Hash, version 9, native byte-order) Can someone advice me on how to get the package manager back up, please? You need to convert your database type to btree and swapping the indexes to big endian, this can be done with '/usr/lib/rpm/bin/dbconvert -b -B -r' :) -- Regards,
Re: Requires: python(foo) = bar
2012/5/11 Tim Mooney tim.moo...@ndsu.edu: In regard to: Requires: python(foo) = bar, Jeffrey Johnson said (at 2:11pm...: Matthew Dawkins mentioned an interest in better python module dependencies in RPM earlier today. I'm still running rpm 5.1.9 and meaning to upgrade, but I've been meaning to ask about ruby dependencies. For better or worse, ruby is becoming a big party of my life. 5.1.9 isn't doing anything for automatic ruby module dependencies, has that improved with any of the more recent RPM releases? Ruby complicates things somewhat over other scripting languages because of the not-yet-complete transition from standard modules to gems, so automatic dependency tracking has to do some extra work for ruby, I think. Also, if I were looking to settle on a particular stable version of rpm for the next year or so, what's the recommended stable version to pick? Just 5.4.latest, or something earlier? I introduced support for ruby gems around rpm 5.2.x, with fairly completetion of current support in 5.3.x. 5.4.x contains new fixes that you need for ruby 1.9 though, which hasn't been backported to older branches. Also there's some new helpers and macros available to make it easier to auto-generate ruby packages from gems, adapted to rpm5: http://gitorious.org/+rpm5distro/rpm5distro/gem2rpm5 This work has been carried out in Mandriva Linux, so if you need to look around for additional info on, you should probably try visit our wiki, mailing lists, repositories etc. :) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: refined implementation of set-versions
2012/4/28 Jeffrey Johnson n3...@me.com:
On Apr 26, 2012, at 10:48 PM, Per Øyvind Karlsen wrote:
But set:versions looks quite useful, and far more effective at reducing
the number
of dependencies than attempting a pin-hole optimizations with boolean
expressions, discarding inequalities which are implied by other
dependencies,
as Per Oyvind has been attempting in Mandriva.
Where can I find more information about this work?
http://svn.mandriva.com/viewvc/packages/cooker/rpm/current/
Notice that pretty much all of the work related on this has been done outside
of upstream, with much regard for it in the more experimental patches adding
new functionality like this, hence the code certainly would need to be
cleaned
up, refactorized and sanitized before even being considered being pushed
anywhere else than
Well your overlapping dependencies removal checked in upstream is about
to get ripped out for lack of generality and bugginess.
Here's one failure case:
]$ Xrpm -ba probes-test.spec
warning: R diskspace(/tmp) 1 overlaps R diskspace(/tmp) = 1Kb, removing R
diskspace(/tmp) 1
warning: R diskspace(/tmp) 1 overlaps R diskspace(/tmp) = 1Kb, removing R
diskspace(/tmp) 1
warning: R diskspace(/tmp) 1 overlaps R diskspace(/tmp) = 1Kb, removing R
diskspace(/tmp) 1
error: Failed build dependencies:
gnupg(/X/probes-test/test1.asc) =
4E23E878D41A0A88EDFCFA5A6E744ACBA9C09E30 is needed by probes-test-1-0.src
gnupg(/X/probes-test/test2.asc) =
7D121A8FC05DC18A4329E9EF67042EC961B7AE34 is needed by probes-test-1-0.src
gnupg(/X/probes-test/test3.asc) =
7D121A8FC05DC18A4329E9EF67042EC961B7AE34 is needed by probes-test-1-0.src
That's a probe, not a string, dependency. The EVR field cannot be simply
compared
because {K,M,G}b suffixes are permitted and your overlap has just removed a
necessary
and useful dependency. There are going to be many such failures with probe
dependencies
because the EVR string and flags are arguments to a probe function, not
strings to
be compared by rpmvercmp and its ilk.
The overlap removal is also going to have issues with set:versions because
the dependcies are sorted using strcmp(1), and there is no guarantee that
you will find an overlap in adjacent items in the dependency set, or even find
*with binary search) what you wish to find. There are even deeper issues
with %_use_internal_dependency_generator 0, where the order of the
dependencies is UNSPECIFIED and not even de facto mostly works.
A linear search will not scale either. Don't even bother hacking that in.
Perfectly understood, I didn't even think that I had commited it upstream?
If so, it must've been done under a #ifdef or something?
As I don't consider any of it ready for upstream or general enough, it's no
problem, I'll be continuing my work on and improving these things gradually
outside of upstream, then I'll start address these issues you bring up as well
when I get to your latest code. :)
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: refined implementation of set-versions
oops. managed to accidentallly send this while getting on the airport train.. Den 04:48 27. april 2012 skrev Per Øyvind Karlsen pkarl...@rpm5.org følgende: Den 13:27 21. april 2012 skrev Alexey Tourbin alexey.tour...@gmail.com følgende: On Fri, Apr 20, 2012 at 5:16 PM, Jeffrey Johnson n3...@me.com wrote: The methods in the existing encoding/decoding are in rpmio/set.c @rpm5.org: the algorithm is unchanged from Alt. A change to the existing scheme over the next few months doesn't bother me at all. But legacy compatibility has instantly appeared as an issue for an @rpm5.org implementation that has been working for less than 24 hours, and where the need is to attempt to install Alt packages into a chroot, sounds like @rpm5.org is going to be forced to both old and new encodings merely to continue trying to do continuous integration with Alt packages. But legacy compatibility is an insoluble problem which need not be discussed. If there's a better encoding scheme available soon, then switching is better done earlier than later. The amount of compatibility with the existing Alt format is negotiable. If you think that rpm5 must be able to install Alt packages into chroot, then there is little choice but to 1) design the new format with a clear distinction, so that older set-strings don't get confused with the newer ones; and 2) to provide an additional decoding routine. However, no additional support is required in e.g. the comparison routine, since the decoding routine simply restores the array of hash values. So this doable. There another option, however. For the reason which shall remain nameless, I find it tempting to produce the new and incompatible format without any clear signs of distinction. :-) ATM, rpm-5.4.9 does only doing decoding (and comparison) of set:versions. The need was to be able to install Alt sisyphus packages (with set:versions dependencies) into a chroot. Generating set:versions (Alt uses a helper script, multilib packaging needs to use the gelf* API) will be harder, particularly if interoperability is desired. Using gelf* API probably won't do, since it is best to use ldd(1)-based tool which will basically invoke ld.so(8) to resolve symbols and dump associations between the symbols and the libraries. It can't be easily done with *gelf ABI, unless you actually try to reimplement a substantial portion of the dynamic linker, which is a bad idea anyway. So using the script is the only realistic options. If the script cannot be used at all (i.e. due to issues with multilib attributes), this probably indicates a problem within rpmbuild itself. But set:versions looks quite useful, and far more effective at reducing the number of dependencies than attempting a pin-hole optimizations with boolean expressions, discarding inequalities which are implied by other dependencies, as Per Oyvind has been attempting in Mandriva. Where can I find more information about this work? http://svn.mandriva.com/viewvc/packages/cooker/rpm/current/ Notice that pretty much all of the work related on this has been done outside of upstream, with much regard for it in the more experimental patches adding new functionality like this, hence the code certainly would need to be cleaned up, refactorized and sanitized before even being considered being pushed anywhere else than in Mandriva Linux currently, with my focus currently being on doing aggressive and efficient development to meet deadlines I've set for myself in order to finish the complete planned feature set of mine in time, for only then start to really focus on sanitizing and get rid of fugly hacks and what not. None the less, I did do some pretty detailed commenting on status and instructions on what to do and not to do in order to help out mdawkins aiding in the work of getting the work back upstream, which I commited earlier today, so I hope these should be of at least some help about what's crack, what's whack and what's sound and correct. :) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: refined implementation of set-versions
Den 13:27 21. april 2012 skrev Alexey Tourbin alexey.tour...@gmail.com følgende: On Fri, Apr 20, 2012 at 5:16 PM, Jeffrey Johnson n3...@me.com wrote: The methods in the existing encoding/decoding are in rpmio/set.c @rpm5.org: the algorithm is unchanged from Alt. A change to the existing scheme over the next few months doesn't bother me at all. But legacy compatibility has instantly appeared as an issue for an @rpm5.org implementation that has been working for less than 24 hours, and where the need is to attempt to install Alt packages into a chroot, sounds like @rpm5.org is going to be forced to both old and new encodings merely to continue trying to do continuous integration with Alt packages. But legacy compatibility is an insoluble problem which need not be discussed. If there's a better encoding scheme available soon, then switching is better done earlier than later. The amount of compatibility with the existing Alt format is negotiable. If you think that rpm5 must be able to install Alt packages into chroot, then there is little choice but to 1) design the new format with a clear distinction, so that older set-strings don't get confused with the newer ones; and 2) to provide an additional decoding routine. However, no additional support is required in e.g. the comparison routine, since the decoding routine simply restores the array of hash values. So this doable. There another option, however. For the reason which shall remain nameless, I find it tempting to produce the new and incompatible format without any clear signs of distinction. :-) ATM, rpm-5.4.9 does only doing decoding (and comparison) of set:versions. The need was to be able to install Alt sisyphus packages (with set:versions dependencies) into a chroot. Generating set:versions (Alt uses a helper script, multilib packaging needs to use the gelf* API) will be harder, particularly if interoperability is desired. Using gelf* API probably won't do, since it is best to use ldd(1)-based tool which will basically invoke ld.so(8) to resolve symbols and dump associations between the symbols and the libraries. It can't be easily done with *gelf ABI, unless you actually try to reimplement a substantial portion of the dynamic linker, which is a bad idea anyway. So using the script is the only realistic options. If the script cannot be used at all (i.e. due to issues with multilib attributes), this probably indicates a problem within rpmbuild itself. But set:versions looks quite useful, and far more effective at reducing the number of dependencies than attempting a pin-hole optimizations with boolean expressions, discarding inequalities which are implied by other dependencies, as Per Oyvind has been attempting in Mandriva. Where can I find more information about this work? http://svn.mandriva.com/viewvc/packages/cooker/rpm/current/ Notice that pretty much all of the work related on this has been done outside of upstream, with much regard for it in the more experimental patches adding new functionality like this, hence the code certainly would need to be cleaned up, refactorized and sanitized before even being considered being pushed anywhere else than - ø-ø-øø-øøøpppøppppøøø
Re: [CVS] RPM: rpm-5_4: rpm/ CHANGES Makefile.am rpm/scripts/ Makefile.am
Den 20:16 16. februar 2012 skrev Jeff Johnson j...@rpm5.org følgende: RPM Package Manager, CVS Repository http://rpm5.org/cvs/ Server: rpm5.org Name: Jeff Johnson Root: /v/rpm/cvs Email: j...@rpm5.org Module: rpm Date: 16-Feb-2012 20:16:11 Branch: rpm-5_4 Handle: 2012021619161001 Modified files: (Branch: rpm-5_4) rpm CHANGES Makefile.am rpm/scripts Makefile.am Log: - autofu: make peace with automake-1.11.2. Summary: Revision Changes Path 1.3501.2.191+1 -0 rpm/CHANGES 2.263.2.6 +3 -2 rpm/Makefile.am 1.75.2.12 +3 -2 rpm/scripts/Makefile.am patch -p0 '@@ .' Index: rpm/CHANGES $ cvs diff -u -r1.3501.2.190 -r1.3501.2.191 CHANGES --- rpm/CHANGES 15 Feb 2012 20:35:04 - 1.3501.2.190 +++ rpm/CHANGES 16 Feb 2012 19:16:10 - 1.3501.2.191 @@ -1,4 +1,5 @@ 5.4.4 - 5.4.5: + - jbj: autofu: make peace with automake-1.11.2. - jbj: hkp: default to standard SKS pool for now, todo++. - jbj: rpmdb: upgrade to db-5.3.15, todo++. - jbj: start rpm-5.4.5 development. @@ . patch -p0 '@@ .' Index: rpm/Makefile.am $ cvs diff -u -r2.263.2.5 -r2.263.2.6 Makefile.am --- rpm/Makefile.am 9 May 2011 04:06:33 - 2.263.2.5 +++ rpm/Makefile.am 16 Feb 2012 19:16:10 - 2.263.2.6 @@ -104,8 +104,9 @@ done endif -pkglibdir = @USRLIBRPM@ -pkglib_DATA = rpmpopt macros/macros macros/macros.rpmbuild cpuinfo.yaml +# XXX automake-1.11.2 is stricter +Xpkglibdir = @USRLIBRPM@ +Xpkglib_DATA = rpmpopt macros/macros macros/macros.rpmbuild cpuinfo.yaml Notice how you forgot to update $(pkglibdir) below: pkgbindir = $(pkglibdir)/bin pkgbin_SCRIPTS = install-sh mkinstalldirs This results in files being installed into $pkglibdir, which now will be /usr/lib64/rpm.. :| I chose to use a more appropriate new name as well in my fix: http://svn.mandriva.com/viewvc/packages/cooker/rpm/current/SOURCES/rpm-5.4.5-automake-1.11.2-fix.patch?view=markup -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_4: rpm/ CHANGES rpm/js/ rpmmpw-js.c rpm/python/ heade...
Den 14:06 1. februar 2012 skrev Pinto Elia devzero2...@rpm5.org følgende:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
Server: rpm5.org Name: Pinto Elia
Root: /v/rpm/cvs Email: devzero2...@rpm5.org
Module: rpm Date: 01-Feb-2012 14:06:26
Branch: rpm-5_4 Handle: 2012020113062402
Modified files: (Branch: rpm-5_4)
rpm CHANGES
rpm/js rpmmpw-js.c
rpm/python header-py.c rpmdb-py.c rpmfts-py.c rpmmacro-py.c
rpmmodule.c rpmtd-py.c rpmts-py.c spec-py.c
rpm/rpmio rpmpython.c
Log:
call with safety some python API that can segfault if called with a NULL
pointer.
Based of the original patch of David Malcom
http://lists.rpm.org/pipermail/rpm-maint/2011-December/003139.html
Summary:
Revision Changes Path
1.3501.2.189+4 -0 rpm/CHANGES
1.21.4.2 +1 -1 rpm/js/rpmmpw-js.c
1.110.4.5 +57 -11 rpm/python/header-py.c
1.28.4.1 +1 -1 rpm/python/rpmdb-py.c
1.24.6.1 +4 -4 rpm/python/rpmfts-py.c
1.7.6.1 +3 -3 rpm/python/rpmmacro-py.c
1.180.2.2 +12 -10 rpm/python/rpmmodule.c
1.3.6.1 +3 -0 rpm/python/rpmtd-py.c
1.111.2.1 +20 -13 rpm/python/rpmts-py.c
1.14.6.1 +7 -0 rpm/python/spec-py.c
2.16.2.1 +1 -1 rpm/rpmio/rpmpython.c
patch -p0 '@@ .'
Index: rpm/CHANGES
$ cvs diff -u -r1.3501.2.188 -r1.3501.2.189 CHANGES
--- rpm/CHANGES 10 Nov 2011 12:47:49 - 1.3501.2.188
+++ rpm/CHANGES 1 Feb 2012 13:06:24 - 1.3501.2.189
@@ -1,4 +1,8 @@
5.4.3 - 5.4.4:
+ - devzero2000: call with safety some python API that
+ can segfault if called with a NULL pointer.
+ Based of the original patch of David Malcom
+ http://lists.rpm.org/pipermail/rpm-maint/2011-December/003139.html
- proyvind: add support for filtering of files to find-debuginfo.sh.
- proyvind: fix find-debuginfo.sh mime-type matching.
- jbj: debuginfo: use current dir instead of $RPM_BUILD_DIR.
@@ .
patch -p0 '@@ .'
Index: rpm/js/rpmmpw-js.c
$ cvs diff -u -r1.21.4.1 -r1.21.4.2 rpmmpw-js.c
--- rpm/js/rpmmpw-js.c 24 Sep 2011 19:36:11 - 1.21.4.1
+++ rpm/js/rpmmpw-js.c 1 Feb 2012 13:06:25 - 1.21.4.2
@@ -1167,7 +1167,7 @@
/* Grab long as big-endian unsigned octets. */
if (_PyLong_AsByteArray(lo, zb, nzb, is_littleendian, is_signed)) {
- Py_DECREF(z);
+ Py_XDECREF(z);
return NULL;
}
@@ .
patch -p0 '@@ .'
Index: rpm/python/header-py.c
$ cvs diff -u -r1.110.4.4 -r1.110.4.5 header-py.c
--- rpm/python/header-py.c 28 Jan 2011 00:27:09 - 1.110.4.4
+++ rpm/python/header-py.c 1 Feb 2012 13:06:25 - 1.110.4.5
@@ -170,7 +170,9 @@
HeaderIterator hi;
list = PyList_New(0);
-
+ if (!list) {
+ return NULL;
+ }
for (hi = headerInit(s-h);
headerNext(hi, he, 0);
he-p.ptr = _free(he-p.ptr))
@@ -186,8 +188,14 @@
case RPM_UINT8_TYPE:
case RPM_STRING_ARRAY_TYPE:
case RPM_STRING_TYPE:
- PyList_Append(list, o=PyInt_FromLong(he-tag));
- Py_DECREF(o);
+ o=PyInt_FromLong(he-tag);
+ if (!o) {
+ headerFreeIterator(hi);
Ehhk!
This shoulda rather been 'headerFini(hi);'
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: Listing hard dependencies of a package
Den 13:24 22. desember 2011 skrev Paul Eggleton
paul.eggle...@linux.intel.com følgende:
Hi there,
Whilst working on Poky/OpenEmbedded I found the need to list all of the hard
dependencies of an RPM package within a shell script. Unfortunately --requires
or the REQUIRES tag seem to also include soft dependencies (i.e.
suggests) which is not really what I need. FYI we're using RPM 5.4.0.
After a little digging I found REQUIREFLAGS, here's an example listing from
our system:
snip
paul@helios:~/poky/poky/build$
/home/paul/poky/poky/build/tmp/sysroots/i686-linux/usr/bin/rpm --dbpath
/var/lib/rpm
--root=/home/paul/poky/poky/build/tmp/work/qemux86-poky-linux/core-image-sato-1.0-r0/rootfs
-q --qf [%{REQUIRENAME} %{REQUIREFLAGS}\n] connman-gnome
libglib-2.0-0 12
hicolor-icon-theme 0
libdbus-glib-1-2 12
libgtk-2.0 12
libc6 12
connman-plugin-loopback 524288
connman 524288
python 524288
python-dbus 524288
connman-plugin-dnsproxy 524288
connman-plugin-bluetooth 524288
connman-plugin-udhcp 524288
connman-plugin-ofono 524288
connman-plugin-wifi 524288
connman-plugin-ethernet 524288
connman-plugin-fake 524288
/bin/sh 1280
/bin/sh 4352
rtld(GNU_HASH) 16384
libgtk-x11-2.0.so.0 16384
libdbus-glib-1.so.2 16384
libc.so.6(GLIBC_2.0) 16384
libc.so.6(GLIBC_2.2) 16384
libgdk-x11-2.0.so.0 16384
libgobject-2.0.so.0 16384
libpthread.so.0 16384
libglib-2.0.so.0 16384
libc.so.6 16384
snip
These values are not ideal for filtering via a shell script and I don't know
what the values mean. Mark Hatle pointed me to its fflags modifier which does
appear to translate some of the flags but not for the suggests (e.g.
connman-plugin-* above), here's what it says for the same package:
snip
paul@helios:~/poky/poky/build$
/home/paul/poky/poky/build/tmp/sysroots/i686-linux/usr/bin/rpm --dbpath
/var/lib/rpm
--root=/home/paul/poky/poky/build/tmp/work/qemux86-poky-linux/core-image-sato-1.0-r0/rootfs
-q --qf [%{REQUIRENAME} %{REQUIREFLAGS:fflags}\n] connman-gnome
libglib-2.0-0 m
hicolor-icon-theme
libdbus-glib-1-2 m
libgtk-2.0 m
libc6 m
connman-plugin-loopback
connman
python
python-dbus
connman-plugin-dnsproxy
connman-plugin-bluetooth
connman-plugin-udhcp
connman-plugin-ofono
connman-plugin-wifi
connman-plugin-ethernet
connman-plugin-fake
/bin/sh r
/bin/sh r
rtld(GNU_HASH)
libgtk-x11-2.0.so.0
libdbus-glib-1.so.2
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.2)
libgdk-x11-2.0.so.0
libgobject-2.0.so.0
libpthread.so.0
libglib-2.0.so.0
libc.so.6
snip
Any suggestions? Would we need to look at patching RPM to implement better
expansion of the flags? If so, are these flags documented anywhere or is the
source the only reference?
(Clearly some of this might be related to our specific configuration of RPM
within Poky/OE, in which case I'll defer to Mark for further elaboration on
that if needed.)
Here's a recent patch of mine coming from past discussions about the subject:
http://svn.mandriva.com/viewvc/packages/cooker/rpm/current/SOURCES/rpm-5.4.4-dont-show-suggests-with-requires.patch?view=log
I think this should be just exactly what you want! :o)
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: Listing hard dependencies of a package
Den 13:24 22. desember 2011 skrev Paul Eggleton paul.eggle...@linux.intel.com følgende: Hi there, Whilst working on Poky/OpenEmbedded I found the need to list all of the hard dependencies of an RPM package within a shell script. Unfortunately --requires or the REQUIRES tag seem to also include soft dependencies (i.e. suggests) which is not really what I need. FYI we're using RPM 5.4.0. Here's a recent patch of mine coming from past discussions about the subject: http://svn.mandriva.com/viewvc/packages/cooker/rpm/current/SOURCES/rpm-5.4.4-dont-show-suggests-with-requires.patch?view=log I think this should be just exactly what you want! :o) Btw. when moving to rpm 5.4 in Manriva, I hit several nasty regressions which since has been fixed, so I would advice you to at least use rpm 5.4.4 if you're still stuck on rpm 5.4.0 (which probably a tons of bugs was already fixed by Jeff previous rpm 5.4.x releases by Jeff already...;). -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Listing hard dependencies of a package
Den 13:24 22. desember 2011 skrev Paul Eggleton paul.eggle...@linux.intel.com følgende: Hi there, Whilst working on Poky/OpenEmbedded I found the need to list all of the hard dependencies of an RPM package within a shell script. Unfortunately --requires or the REQUIRES tag seem to also include soft dependencies (i.e. suggests) which is not really what I need. FYI we're using RPM 5.4.0. Here's a recent patch of mine coming from past discussions about the subject: http://svn.mandriva.com/viewvc/packages/cooker/rpm/current/SOURCES/rpm-5.4.4-dont-show-suggests-with-requires.patch?view=log I think this should be just exactly what you want! :o) (btw. if you're actually still using rpm 5.4.0, you *REALLY* should update to rpm-5.4.4, a lot of bugs has been fixed since..) -- Regards, PEr Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_4: rpm/ CHANGES rpm/macros/ macros.rpmbuild.in rpm/sc...
Den 17:39 21. oktober 2011 skrev Jeff Johnson j...@rpm5.org følgende:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
Server: rpm5.org Name: Jeff Johnson
Root: /v/rpm/cvs Email: j...@rpm5.org
Module: rpm Date: 21-Oct-2011 17:39:03
Branch: rpm-5_4 Handle: 2011102115390101
Modified files: (Branch: rpm-5_4)
rpm CHANGES
rpm/macros macros.rpmbuild.in
rpm/scripts find-debuginfo.sh
Log:
- debuginfo: use current dir instead of $RPM_BUILD_DIR.
D'oh, a bit late discovered, but better than never..
$RPM_BUILD_DIR == %{_builddir}
while
$PWD == %{_builddir}/%{?buildsubdir}
So for most packages which have their own %buildsubdir, this will mess
up the paths for debug packages, ie. see the following example:
[peroyvind@t61 linux_logo]$ rpm -qpl
/home/peroyvind/RPM/linux_logo/RPMS/x86_64/linux_logo-debug-5.11-1-mdv2012.0.x86_64.rpm
/usr/lib/debug
/usr/lib/debug/.build-id
/usr/lib/debug/.build-id/02
/usr/lib/debug/.build-id/02/da5f6707c052c4293ea8e055de33d2704a3933
/usr/lib/debug/.build-id/02/da5f6707c052c4293ea8e055de33d2704a3933.debug
/usr/lib/debug/usr
/usr/lib/debug/usr/bin
/usr/lib/debug/usr/bin/linux_logo.debug
/usr/src/debug/defaults.h
/usr/src/debug/home
/usr/src/debug/home/peroyvind
/usr/src/debug/home/peroyvind/RPM
/usr/src/debug/home/peroyvind/RPM/linux_logo
/usr/src/debug/home/peroyvind/RPM/linux_logo/BUILD
/usr/src/debug/home/peroyvind/RPM/linux_logo/BUILD/linux_logo-5.11
/usr/src/debug/libsysinfo-0.2.2
/usr/src/debug/libsysinfo-0.2.2/Linux
/usr/src/debug/libsysinfo-0.2.2/Linux/cpuinfo_x86.c
/usr/src/debug/libsysinfo-0.2.2/Linux/sysinfo_linux.c
/usr/src/debug/libsysinfo-0.2.2/all
/usr/src/debug/libsysinfo-0.2.2/all/fix_mhz.c
/usr/src/debug/libsysinfo-0.2.2/all/parsing.c
/usr/src/debug/libsysinfo-0.2.2/all/sysinfo_common.c
/usr/src/debug/libsysinfo-0.2.2/all/uname.c
/usr/src/debug/libsysinfo-0.2.2/sysinfo.h
/usr/src/debug/linux_logo.c
/usr/src/debug/linux_logo.h
/usr/src/debug/load_logo.c
/usr/src/debug/load_logos.h
/usr/src/debug/logo_types.h
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_4: rpm/ CHANGES rpm/macros/ macros.rpmbuild.in rpm/sc...
Den 16:16 20. desember 2011 skrev Jeffrey Johnson n3...@me.com følgende:
On Dec 20, 2011, at 9:55 AM, Per Øyvind Karlsen wrote:
Den 17:39 21. oktober 2011 skrev Jeff Johnson j...@rpm5.org følgende:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
Server: rpm5.org Name: Jeff Johnson
Root: /v/rpm/cvs Email: j...@rpm5.org
Module: rpm Date: 21-Oct-2011 17:39:03
Branch: rpm-5_4 Handle: 2011102115390101
Modified files: (Branch: rpm-5_4)
rpm CHANGES
rpm/macros macros.rpmbuild.in
rpm/scripts find-debuginfo.sh
Log:
- debuginfo: use current dir instead of $RPM_BUILD_DIR.
D'oh, a bit late discovered, but better than never..
$RPM_BUILD_DIR == %{_builddir}
while
$PWD == %{_builddir}/%{?buildsubdir}
So for most packages which have their own %buildsubdir, this will mess
up the paths for debug packages, ie. see the following example:
I hope … have their own %buildsubdir … doesn't mean that some
package monkey is trying to set/change %builddubdor in a *.spec file.
Nope, I'm referring to whether %buildsubdir is set or not (as
controlled by %setup).
For most packages it's set, with the default being %{name}-%{version}.
So %{_builddir} / %{buildsubdir} will be ie. /usr/src/rpm/BUILD / foo-1.2.3.
Meanwhile, I'm not sure what you have discovered: literally nothing has
changed in this area for most of this century, the whole mechanism
if fabulously broken and mis-designed and mis-implemented imho.
Simply that $PWD == %{_builddir}/%{?buildsubdir}, thus $RPM_BUILD_DIR=`pwd`
is incorrect with the consequence of messing up paths in debug packages..
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: How to disable rpm5 log?
2011/11/16 Mei, Lei lei@intel.com: Hi all, I am a developer of Yocto project(http://www.yoctoproject.org/), our project is for embedded industry. we support rpm5 in our project, but the /var/lib/rpm/log grows indefinitely, it's unacceptable in embedded device. I am trying to disable these logs in rpm5, but didn't find a good way. Anyone can supply some help? Thanks a lot! You can manually remove log files no longer needed with 'db_archive -d'. You can also enable automatic removal of these logs by enabling the berkeley db configuration flag DB_LOG_AUTO_REMOVE (this way only one 10MB log file will be kept around). -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_4: rpm/rpmdb/ rpmdb.c
2011/11/2 Jeffrey Johnson n3...@me.com:
xrealloc please so that there's no need to check NULL.
empty statement semi-colons on next line as well. even better, move tmp++
out of the for statement:
for (i = 0; (tmp = strchr(tmp, '-')); i++, tmp++);
Will fix.
There's no reason for advocacy/apology hack in comments either.
Stating what is wrong (accessing multiple times, doing a headerlaod), or
suggesting
what could be done (changing the Nvra table to include additional
tags concatenated) is perhaps clearer than making hand waving promises.
Agreed.
All that's needed to solve this issue correctly is to commit to a
string representation that is parsable usin a *RE when optional values
like Epoch: and Distepoch:/Disttag: are there. You chose to add the pesky
extra '-' to what had been previously devised … which forces
additional input/output reformatting on retunred values. There are
other representations that are unambigously parseable.
Without a parseable string from which the tuple elements might be matched,
well, rpm has
*always* been doing secondary lookups from a primary key with
a necessary headerLoad(). Its only the rpmdb access rewrite with RPM ACID
that avoids the
overhead of the headerLoad() (which was part of the measured 14.6x improvement
in database lookups).
The Nvra table conversion can be done in %postrans like
rm -f /var/lib/rpm/Nvra
rpm -q rpm /dev/null
You can easily check that cost any time you wish.
I know, but jI've just not made my way back to this one yet.. :|
Hmmm … there's other code that starts to use this patch coming
shortly, correct?
urpmi is depending on this, as it's using NVRA for package removal..
hth
73 de Jeff
On Nov 2, 2011, at 9:51 AM, Per Øyvind Karlsen wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
Server: rpm5.org Name: Per Øyvind Karlsen
Root: /v/rpm/cvs Email: pkarl...@rpm5.org
Module: rpm Date: 02-Nov-2011 14:51:38
Branch: rpm-5_4 Handle: 200213513800
Modified files: (Branch: rpm-5_4)
rpm/rpmdb rpmdb.c
Log:
add disttag/distepoch matching hack forgotten on rpm-5_3
Summary:
Revision Changes Path
1.392.2.8 +85 -0 rpm/rpmdb/rpmdb.c
patch -p0 '@@ .'
Index: rpm/rpmdb/rpmdb.c
$ cvs diff -u -r1.392.2.7 -r1.392.2.8 rpmdb.c
--- rpm/rpmdb/rpmdb.c 5 Sep 2011 23:49:41 - 1.392.2.7
+++ rpm/rpmdb/rpmdb.c 2 Nov 2011 13:51:38 - 1.392.2.8
@@ -2448,6 +2448,91 @@
rpmRC rc;
rc = dbiFindMatches(dbi, keyp, set);
+#if defined(RPM_VENDOR_MANDRIVA)
+ /*
+ * Hack to workaround disttag/distepoch pattern matching issue to buy
some
+ * time to come up with better pattern fix..
+ * One size should fit all now.. ;)
+ *
+ * This patch will try match NVR first, then for all matches returned,
+ * it will match disttag, distepoch arch individually.
+ */
+
+ /* We'll only try this if query fails */
+ if(!rc ((const char*)keyp)[0] != '^' tag == RPMTAG_NVRA
+ (set == NULL || set-count 1)) {
+ size_t i;
+ char *tmp = (char*)keyp;
+
+ /* If pattern has less than three '-', it can't contain disttag, so
+ * no point in trying */
+ for (i = 0; (tmp = strchr(tmp, '-')); i++, tmp++);
+ if (i = 3) {
+ dbiIndex pdbi;
+ DBC *pdbc;
+ const char *origkeyp = keyp;
+ size_t klen = strlen(keyp)+1;
+ size_t size = 0;
+ int xx;
+
+ keyp = alloca(klen);
+ stpcpy((char*)keyp, origkeyp);
+ tmp = strrchr(keyp, '-');
+ *tmp = '\0';
+ rc = dbiFindMatches(dbi, keyp, set);
+
+ pdbi = dbiOpen(db, RPMDBI_PACKAGES, 0);
+ xx = dbiCopen(pdbi, dbiTxnid(pdbi), pdbc, 0);
+
+ for(i = 0; set i set-count; i++) {
+ DBT k = DBT_INIT;
+ DBT v = DBT_INIT;
+ Header h;
+ uint32_t offset = _hton_ui(set-recs[i].hdrNum);
+ rpmTag checkTags[] =
+ { RPMTAG_DISTTAG, RPMTAG_DISTEPOCH, RPMTAG_ARCH };
+ int j;
+
+ memset(k, 0, sizeof(k));
+ memset(v, 0, sizeof(v));
+ k.data = offset;
+ k.size = sizeof(offset);
+
+ xx = dbiGet(dbi, pdbc, k, v, DB_SET);
+ h = headerLoad(v.data);
+ tmp = (char*)((size_t)keyp + strlen(keyp) + 1
RPM features/issues/wishlist
I've started to ramble on some of the features, issues, ideas etc. to work on and consider for our (Mandriva Linux) next development cycle, and in the interest of sharing work and coordinating efforts with others, while inviting others to contribute: http://wiki.mandriva.com/en/Development/Tasks/Packaging/Tools/RPM/TODO While it's certainly written from a vendor POV (and also rather crude for the moment), I'm cross-posting this one as it's of potential interest to others as well and the idea is for things to be as generic as possible anyhows.. :) So I invite others with the interest to contribute to the discussion on the list and wiki, proposing ideas, gather a list of issues that needs to be addressed, and do some general brainstorming and uhm.. stuff. ;) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Distepoch identification (was Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ transaction.c)
2011/7/12 Jeff Johnson n3...@mac.com:
Lemme split this into 2 threads to try to address
two twisted issues properly. The other thread will be
Transaction sanity checks
On Jul 12, 2011, at 8:48 AM, Jeff Johnson wrote:
You need to figure a better *RE pattern, not whack in
lots of gunky code to fix it somehow.
Yes, I kinda suspected this certainly wasn't the most optimal
way to solve this.. :|
The problem basically is that it's doing comparision of RPMTAG_NVRA
between the installed packaged and the package to be installed, which
will give us problems when only distepoch differs since RPMTAG_NVRA
still isn't consistent with %___NVRA.
There's a fundamental confusion here between identification
and versioning (as used in assertion checking).
The %___NVRA is there purely for identification. Whatever
elements you wish to add/delete in a chosen identification
string can be added at will. One can also undertake encoding
conversions, and attaching other data, from sources not
just derived from *.rpm metadata contents if you wish to
go to the trouble of adding a header tag/format extension
(which can be done without changing one line of RPM code
if necessary).
OTOH, versioning is hierarchical, and depends on a sequence
of comparison operations applied to well defined data, done
strictly in the same order, with choices for results when
missing (as in not present or empty, different meanings for
missing).
Your Distepoch: (and Disttag) implementation is nearly perfect (even if
unlikely
to be used outside of Mandriva derived packaging).
But there's several sick hacks in need of improvement. There's
nothing whatsoever wrong with the hacks, just its time to
refactor the code to the right place.
The hard hack is re-writing the *RE pattern applied to NVRA keys.
I can/will fix (by refactoring and writing a better *RE) that
properly, but identifying how the problem is to be fixed is the
point of this thread.
The one wartlet with Distepoch: is
How SHOULD a {N,E,V,R,D} tuple be serialized/concatenated in a string?
There is what is currently in Mandriva 2011 (I'll use popt for explicit
example):
$ rpm -q libpopt0
libpopt0-1.16-2-mdv2011.0.i586
And there is also the legacy compatible (with %mkrel) concatenation that
would (not checked) look like this:
libpopt0-1.16-2mdv2011.0.i58
So the incompatibility is largely whether a '-' is added or not.
The incompatible '-' is added in %__NVRA (poifect!):
$ rpm --showrc | grep __NVRA
-14: ___NVRA
%%{NAME}-%%{VERSION}-%%{RELEASE}%%|DISTTAG?{-%%{DISTTAG}%%|DISTEPOCH? …
^ here is
the incompatibility
The fundamental problem has to do with the one or two remaining
non-identification
usage cases of RPMTAG_NVRA in RPM code.
The resolution will be to cleanly and _ENTIRELY_ split all uses of
%__NVRA and RPMTAG_NVRA from all versioning usage cases in RPM.
The subtlety (and the hacks) come from confusing the identification context
from the assertion versioning context. Yes it is _VERY_ confusing when its
just a string that needs to be sliced and diced differently depending on
whether its an identification (i.e. intended for human display) or an
assertion context.
The assertion context (and its what you originally agreed at least
implicitly
back in 2009 when implemented) is in the pattern that splits the EVRD
string into a tuple for use by assertion version comparisons. You already
know
(because I'm sure you've stared at the problems a zillion times) that the
code is
almost exactly what you want implemented: i.e. you really haven't had to
change
much in the EVRD tuple parsing (your other check-in today was dead-on).
The parsing hint for splitting an assertion string into a {E,V,R,D} tuple
is a ':' as described here:
# STEP 1: Match the string and capture regex parts
# 1 2 3 4
# X : X -X :X
%evr_tuple_match ^(?:([^:-]+):)?([^:-]+)(?:-([^:-]+))?(?::([^:-]+))?$
OTOH, the %___NVRA identification and RPMTAG_NVRA (which uses %___NVRA as a
configurable
template) and the table /var/lib/rpm/Nvra (which is based on RPMTAG_NVRA and
configurable %___NVRA) are quite useful and important because its
identification
and package names which everyone focusses on.
So there's still a few places where RPM uses RPMTAG_NVRA in the wrong
context, one of
the places being what you just patched (I donna bother fixing properly there
because
its my belief that the test is bullshot and needs to be eliminated, not
fixed).
K, I'll try coming up with a better solution for this one then. :)
So ultimately we have a ':' and a '-' character as explicit tuple separators
and have dueling identification and assertion parsers.
There are 2 approaches to fixing:
1) (recommended) Rip out
Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ transaction.c
2011/7/12 Jeff Johnson n3...@mac.com:
On Jul 12, 2011, at 8:21 AM, Per Øyvind Karlsen wrote:
2011/7/12 Jeff Johnson n3...@mac.com:
This isn't at all the right approach because
its doesn't scale.
You have changed a single high performing rpmdb
access that applies patterns to keys only, and added
a hack-o-round that then goes and loads multiple
headers repeatedly to try and adjust the set
returned by the original access to fit some desired
semantic goal.
You need to figure a better *RE pattern, not whack in
lots of gunky code to fix it somehow.
Yes, I kinda suspected this certainly wasn't the most optimal
way to solve this.. :|
The problem basically is that it's doing comparision of RPMTAG_NVRA
between the installed packaged and the package to be installed, which
will give us problems when only distepoch differs since RPMTAG_NVRA
still isn't consistent with %___NVRA.
There's a fundamental confusion here between identification
and versioning (as used in assertion checking).
The %___NVRA is there purely for identification. Whatever
elements you wish to add/delete in a chosen identification
string can be added at will. One can also undertake encoding
conversions, and attaching other data, from sources not
just derived from *.rpm metadata contents if you wish to
go to the trouble of adding a header tag/format extension
(which can be done without changing one line of RPM code
if necessary).
OTOH, versioning is hierarchical, and depends on a sequence
of comparison operations applied to well defined data, done
strictly in the same order, with choices for results when
missing (as in not present or empty, different meanings for
missing).
ie. for:
foo-1-1-mdv2011.0.x86_64 vs foo-1-1-mdv2012.0.x86_64,
NVRA will be 'foo-1-1.x86_64' for both.
So any good suggestions on performing the check on distepoch in addition
without heavy drawbacks?
The very simplest solution is
Call rpmtsRun() with RPMPROB_FILTER_REPLACEPACKAGE set.
That is what the flag is implemented and intended for.
The next most simple fix starts to address a design flaw:
A sanity check on the elements in a transaction set
needs to be done somewhere else instead. Checking
in rpmtsRun() is far far far too late todo anything
but best effort fudging or bizarre FULLSTOP termination,
All of the checks, not just the *_REPLACEPKG check we happen to
be discussing, are total bullshit: if the check finds something
wrong, well, its some programmer's brain fart choosing what
packages to add to a transaction, not anything else.
But if you simply MUST fix *_REPLACEPG, then the right fix is to
change rpmdbMireApply() to not use the identification RPMTAG_NVRA
string but rather construct whatever tag tests one wishes however
one wants. Post processing fiddle ups (like you just checked in)
to correct a call that should have been done differently are silly
band-aids.
Checking distepoch of the package to be installed is easy and fast enough
with rpmteD(p), but any chance of providing distepoch with the keys returned
by rpmdbMireApply on RPMTAG_NVRA in some way..?
Um, not true: rpmteD is a simple getter, does no checking whatsoever,
so I have no idea how easy/fast applies to something that isn't being done.
Passing keys Somewhere Else Instead isn't needed either: rpmdbMireApply()
is perfectly capable of being used intelligently, to perform a bullshit
test that isn't necessary at all, however you wish.
Would this be more acceptable? :)
--- transaction.c 2011-07-12 11:50:34.229520174 +0200
+++ /home/peroyvind/RPM/rpm/BUILD/rpm-5.3.12/lib/transaction.c
2011-07-13 19:52:43.668223410 +0200
@@ -1165,32 +1165,10 @@ rpmlog(RPMLOG_DEBUG, D_(sanity checking
if (!(rpmtsFilterFlags(ts) RPMPROB_FILTER_REPLACEPKG)) {
ARGV_t keys = NULL;
int nkeys;
- xx = rpmdbMireApply(rpmtsGetRdb(ts), RPMTAG_NVRA,
- RPMMIRE_STRCMP, rpmteNEVRA(p), keys);
+ xx = rpmdbMireApply(rpmtsGetRdb(ts), RPMTAG_HDRID,
+ RPMMIRE_STRCMP, rpmteHdrid(p), keys);
nkeys = argvCount(keys);
-#if defined(RPM_VENDOR_MANDRIVA)
- /* mdvbz: #63711
-* workaround for distepoch never being added to RPMTAG_NVRA yet,
-* leading to packages of same EVRA but with different distepoch
-* being treated as the same package */
- if (nkeys 0) {
- int i;
- for (i = 0; i nkeys; i++) {
- rpmmi mi = rpmtsInitIterator(ts, RPMTAG_NVRA, keys[i], 0);
- Header h;
- while ((h = rpmmiNext(mi)) != NULL) {
- HE_t he = memset(alloca(sizeof(*he)), 0, sizeof(*he));
- he-tag = RPMTAG_DISTEPOCH;
- xx = headerGet(h, he, 0);
- if (strcmp(he-p.str ? he-p.str : ,
rpmteD(p) ? rpmteD(p) : ))
- nkeys
Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ transaction.c
2011/7/13 Jeff Johnson n3...@mac.com: On Jul 13, 2011, at 1:54 PM, Per Øyvind Karlsen wrote: Passing keys Somewhere Else Instead isn't needed either: rpmdbMireApply() is perfectly capable of being used intelligently, to perform a bullshit test that isn't necessary at all, however you wish. Would this be more acceptable? :) This is fine with me but changes the meaning of identical which is almost certainly not going to meet someone's expectations. Using RPMTAG_HDRID instead of RPMTAG_NVRA is entirely consistent with a change in another part of RPM (grep RPMTAG_HDRID) where it was necessary (for Alt or PLD I fergit) to narrow down identical to exactly the same package instead of a package with the same name. (aside) There's a silly legacy compatible fallback to good old NEVRA that likely just needs to be ripped out there. There are no circumstances in which a fallback for legacy compatible is meaningful any more, and everyone has had 5+ years to switch and/or suggest better and none has: Time to haul out the trash … … meanwhile if you back up a bit and look where and how this patch is being executed, its *insane* to apply a sanity check of this sort through rpmtsRun(). The reason the test was done in rpmtsRun() originally is/was because this is the earliest chance that RPM gets to see the _ENTIRE_ transaction fully formed. This sanity check pre-dates anaconda and goes all the way back to RHL 6.0 when one could justify an extra insurance sanity check. But these days (10+ years later) its an API design failure: If some script kiddie wants/needs training wheels from -lrpm for the feeble installer hacks, well RPM should hand the training wheels (and diaper) to the script kiddie on a non-critical code path, and let Darwinian evolution punish the installer mutatations harshly, not pretend at errors or features or anything else. So back up a bit, look at the code path on which this bullshit test is being performed, think a bit, and just rip the entire test out. Yeah, not disagreeing with you on that one.. :) What about the other checks done in rpmtsSanityCheck()? The same seems to apply to at least the RPMPROB_FILTER_OLDPACKAGE check as well..? Or can rpmtsSanityCheck() be dropped entirely? Just skimming through code, about to leave the office, not the right moment to start think on my own.. ;) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ transaction.c
2011/7/12 Jeff Johnson n3...@mac.com: This isn't at all the right approach because its doesn't scale. You have changed a single high performing rpmdb access that applies patterns to keys only, and added a hack-o-round that then goes and loads multiple headers repeatedly to try and adjust the set returned by the original access to fit some desired semantic goal. You need to figure a better *RE pattern, not whack in lots of gunky code to fix it somehow. Yes, I kinda suspected this certainly wasn't the most optimal way to solve this.. :| The problem basically is that it's doing comparision of RPMTAG_NVRA between the installed packaged and the package to be installed, which will give us problems when only distepoch differs since RPMTAG_NVRA still isn't consistent with %___NVRA. ie. for: foo-1-1-mdv2011.0.x86_64 vs foo-1-1-mdv2012.0.x86_64, NVRA will be 'foo-1-1.x86_64' for both. So any good suggestions on performing the check on distepoch in addition without heavy drawbacks? Checking distepoch of the package to be installed is easy and fast enough with rpmteD(p), but any chance of providing distepoch with the keys returned by rpmdbMireApply on RPMTAG_NVRA in some way..? -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/js/ rpmaug-js.c rpmbc-js.c rpmbf-js.c rpmcudf-js.c rpmd...
2011/6/3 Jeff Johnson n3...@mac.com: Talk to me first *PLEASE* ... nothing at all wrong with what you are doing _EXCEPT_ you aren't talking. Yeah, I just realised that I left it quite broken earlier and figured that I'd might as well just go ahead fixing it.. For the actual changes, I seem to have only partly ported some of the code to the newer API..(!) I'm not sure what might've happened, my guess is that I probably had both the libraries and the headers of both versions installed, then it must've included them both and managed to build and link it using some headers from newer version together with the older or something.. There's a a couple issues remaining (ie. JS_PushArguments() being removed from API) and some memleaks due to API changes that still needs to be fixed, I've left those with a #warning in the code for now.. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/rpmdb/ rpmdb.c
2011/5/27 Jeff Johnson n3...@mac.com: Nice! \o/ Still needs to be done somewhere else though for performance. Nothing at all wrong with this patch, just SHOULD be done deeper in dbiFindMatches() for highest performing, most general, etc etc. Yupp, there's still a lot room for improvement, I've tried to minimize the use of the patch as much as possible as is though, but of course it's not really very optimal several queries gets done using it.. Berkeley db is still a bit arcane to me, and whenever I start looking at wressling with it again after a couple of months not messing with, I spend way too much time having to refresh my memory again.. :| Oh well, this one at least works now and should finally put the last real issue with this migration for cooker to rest, one less thing to keep concerning myself about.. :p Might just try optimize it a bit further later on.. :) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
[PATCH]: glob on paths for macro files with %{load:}
When adding macros/mandriva in the past, I tried adding %{load:
/etc/rpm/macros.d/*.macros}
to it for loading macros rather than specifying it during ./configure,
but I quickly discovered that support for wildcards wasn't supported and didn't
care much about it since, figguring that I'd look into implementing it sometime
later.
I guess that the mandriva macros probably served as inspiration for
adding this to the other vendor macros recently checked in as well,
so as I take blame for this, I might as well implement the actual support
for this at the same time.
I dunno if there's any specific reason for why this wasn't implemented
earlier..?
If there's none, the usefulness of adding support for this is rather obvious and
if noone objects, I'll commit the following patch. :)
--
Regards,
Per Øyvind
--- rpmio/macro.c 2011-01-09 07:26:56.780028249 +0100
+++ /home/peroyvind/RPM/rpm/BUILD/rpm-5.3.11/rpmio/macro.c 2011-05-25 19:04:13.076558612 +0200
@@ -2788,6 +2788,9 @@ rpmLoadMacroFile(MacroContext mc, const
/* Parse %{load:...} immediately recursively. */
if (s[1] == '{' !strncmp(s+2, load:, sizeof(load:)-1)) {
char * se = (char *) matchchar(s, '{', '}');
+ const char ** argv = NULL;
+ int argc = 0;
+ int i;
if (se == NULL) {
rpmlog(RPMLOG_WARNING,
_(%s:%u Missing '}' in \%s\, skipping.\n),
@@ -2804,7 +2807,10 @@ rpmLoadMacroFile(MacroContext mc, const
continue;
}
se = rpmMCExpand(mc, s, NULL);
- rc = rpmLoadMacroFile(mc, se, nesting - 1);
+ rc = rpmGlob(se, argc, argv);
+ for(i = 0; i argc; i++)
+ rc |= rpmLoadMacroFile(mc, argv[i], nesting - 1);
+ argv = _free(argv);
se = _free(se);
if (rc != 0)
goto exit;
Re: split formats.c?
2011/5/22 Robert Xu rob...@gmail.com: Hi all, I've been going through opensuse patches with quilt (sorry Jeff, I couldn't wait to build RPM5, but didn't want to throw away whatever SuSE does completely)... I ran across localetag.diff, and then ran through the rpm5 repository, only to discover that rpm.org split formats.c into formats.c and tagext.c. Now with this patch, I'm wondering - what should I do with it? Provide us with the patch, and it'll be easier for us to comment on.. ;) (I'm way too lazy to even consider tracking it down myself.. :p) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/rpmdb/ rpmdb.h
2011/5/11 Jeff Johnson n3...@mac.com: This isn't your code. Leave it be. Huh? You don't want me to commit this change at all, or you just don't want me to commit it on HEAD..? In the past you've told me to *always* commit to HEAD first.. WTF does C++ typecasting have to do with anything? I am playing around with porting URPM to C++.. You've expressed interest in being able to compile rpm with g++ in the past, so I thought it'd be to your interest.. Do we go through a repeat of last week? Again? I don't get the problem... -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Fwd: Repodata additions
-- Forwarded message -- From: Per Øyvind Karlsen peroyv...@mandriva.org Date: 2011/5/3 Subject: Re: Repodata additions To: rpm-t...@rpm5.org 2011/5/3 Jeff Johnson n3...@mac.com: A sane opinion as always, and Distepoch is nicely done and handled. Would you mind reposting on the Cooker list? My private agenda is trying to get some abstraction layer on top of the spewage before having to do battle with DUDF and synthesis/hdlists directly in RPM itself. DUDF is this huge pugly mish-mosh of JSON and perl dump that someone whacked together in afternoon and proudly blogged about the hack. And synthesis/hdlists have pushed file paths into Provide: /foo/bar/baz totally boogering up MM distro packaging to save bandwidth. You sare aving bandwidth by _ADDING_ dependencies?!? Does not compute, sorry. tnx 73 de Jeff The On May 3, 2011, at 5:12 AM, Anders F Björklund wrote: Hi, Matthew Dawkins pointed me to the Cooker discussion (http://lists.mandriva.com/cooker/2011-05/msg00069.php) about extending rpm-metadata with disttag/distepoch... (http://lists.mandriva.com/cooker/2011-04/msg00423.php) Last year, Unity wanted to show the disttag/distepoch in the package version (e.g. -unity2010, -mdv2011.0) so the repodata had to be extended with that information in order to match the versions from the rpm header loader: rpm:disttagunity/rpm:disttag rpm:distepoch2011.0/rpm:distepoch I helped implement this for createrepo, similar to how repodata was earlier extended to add a hint value for Requires(hint) like the earlier pre for Requires(pre) and matching retrofits for the missing RPMSENSE_PREREQ The Smart version parser had to be modified too, so that it wouldn't choke on the double dash in rpm versions. i.e. going from foo-1.2-3mdv2010.0 to foo-1.2-3-mdv2011.0 it now needs to parse version-release-distepoch as well. The next change was when the :distepoch was added to the dependencies, and going from EVR to EVRD in comparisons. This required modifying the vercmp routine used, as well as making sure it was called rather than a plain strcmp. Smart doesn't support EVRD, so does plain EVR_ comparisons (in future, this might become be pluggable / use rpmvercmp) Likewise, there has been no attempts done to add EVRD support to yum/createrepo and the rpm-metadata package and friends: rpm-5.3.9-0.20110330.6-mdv2011.0.i586.rpm (filename) # rpm-1:5.3.9-0.20110330.6-mdv2011.0@i586 (in smart) package type=rpm namerpm/name archi586/arch version epoch=1 ver=5.3.9 rel=0.20110330.6/ format rpm:provides rpm:entry name=rpm flags=EQ epoch=1 ver=5.3.9 rel=0.20110330.6/ The version comparison routine used makes it still match rpm = 1:5.3.9-0.20110330.6:2011.0 (=ignoring distepoch) You can find the createrepo and smart patches / branches here, also including the openSUSE additions made earlier: http://afb.users.sourceforge.net/repodata/ https://code.launchpad.net/~afb/smart/dist/ As far as I know, all attempts to add distepoch= and pre= are blocked upstream at createrepo.baseurl.org and the XML format deprecated in favor of SQL format... (which is harder to extend without changing dbversion) All the yum code (as required and used by createrepo now) uses EVR tuples internally, so changing to EVRD requires modifying all that. I don't think it is worth the effort, and I don't see the benefit of distepoch in dependencies. Feel free to open new Smart bugs about how EVRD is as important as CVOG, meanwhile it'll just use EVR and A. https://bugs.launchpad.net/smart https://bugs.launchpad.net/smart/+bug/587448 (archscore) Btw. Jeff, I think you're free to redesign DUDF format and also implement it directly in RPM, and we'll use adopt it right away. :) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_4: rpm/lib/ rpmts.h rpm/rpmdb/ rpmns.h rpmtypes.h
2011/5/3 Jeff Johnson n3...@mac.com: Seriously you have better things to do than diddle w commas and -pedantic. If not, well mdawkins has a reproducer with --xml due to my --json changes that could/should be brought back to rpm-5.3.x. Give me a pointer and I'll get to it. :) Just a reality check ... Yes, but just cleaned out some warnings cluttering output when building and debugging.. :) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/lib/ rpmfc.c
2011/4/16 Jeff Johnson n3...@mac.com: Ok enough. We _ARE_ headed for a fork between rpm5.org - Mandriva if these check-ins continue. I've asked for discussion first. Not happening. I've asked for a feature list. Not seen. I've pointed out that many of these changes are ancient hysteria being recycled as Newer! Better! Bestest! There is noone asking for these changes. Show me. These are already in use on Mandriva and part of the helpers migrated from rpm-mandriva-setup. There are no test cases. I will make that policy MANDATORY if necessary. There is nothing but a 1-line description, essentially Add new stuff. No examples, no writeup, no usage case, nothing. ? Both commit messages, entry in CHANGES and the code itself should generally have at least the bare minimum to provide some pointers for it.. Its happening on the production branch (in this case) creating divergence that I have to muck about with later, often breaking code because I haven't any clue what is what. I've placed it under mandriva #ifdef, so it shouldn't break things for anyone else on the production branch.. None of this code is maintainable or useful imho until some of the above is corrected. If I'm gonna be able to migrate to the internal dependency generator, I must add these to avoid ~regressions. If a discussion and test cases is required provided first, I won't be able to have time to switching to the internal dependency before after next mandriva release.. Or I can go back to maintaining patches locally in cooker svn..? -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/ CHANGES rpm/lib/ rpmds.c
2011/4/16 Jeff Johnson n3...@mac.com: And so now we have the start of Yet More peculier dependencies, not just devel(...) but now uClibc(...). Yes, this is to avoid conflicts with sonames linked against glibc, ie. see: [peroyvind@lappis rpm-5.3.9]$ echo /usr/uclibc/usr/lib64/libz.so.1.2.5 | LD_LIBRARY_PATH= tools/.libs/rpmdeps -P elf(buildid) = 436568eecd8496e8648066fcacd79919833499b0 libz.so.1()(64bit) libz.so.1(ZLIB_1.2.0)(64bit) libz.so.1(ZLIB_1.2.0.2)(64bit) libz.so.1(ZLIB_1.2.0.8)(64bit) libz.so.1(ZLIB_1.2.2)(64bit) libz.so.1(ZLIB_1.2.2.3)(64bit) libz.so.1(ZLIB_1.2.2.4)(64bit) libz.so.1(ZLIB_1.2.3.3)(64bit) libz.so.1(ZLIB_1.2.3.4)(64bit) libz.so.1(ZLIB_1.2.3.5)(64bit) $ LD_LIBRARY_PATH=/usr/uclibc/lib64 ldd /usr/uclibc/usr/lib64/libz.so.1.2.5 linux-vdso.so.1 = (0x7fff68dff000) libc.so.0.9.30.3 = /usr/uclibc/lib64/libc.so.0.9.30.3 (0x7f99798ff000) ld64-uClibc.so.0.9.30.3 = /usr/uclibc/lib64/ld64-uClibc.so.0.9.30.3 (0x7f99796f7000) Currently the uClibc-linked libraries are shipped together with the same library packages to ensure rpm not pulling in uClibc-linked library package only to satisfy dependency for non-uClibc-linked stuff. This adds a mandatory depedendency on uClibc for basesystem and relevant packages for where shared uClibc-linked libraries are built for.. :| Revert. Would you prefer for the patches to be maintained locally in cooker svn rather than under mandriva #ifdef? And get the fiddle ups in lib/psm.c for triggers removed as well. Will do when I get there. If you want hacked up RPM in Mandriva, by all means hack away. I am commiting the changes under mandriva #ifdefs only.. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/ CHANGES rpm/lib/ rpmds.c
2011/4/16 Jeff Johnson n3...@mac.com:
On Apr 16, 2011, at 11:34 AM, Per Øyvind Karlsen wrote:
2011/4/16 Jeff Johnson n3...@mac.com:
And so now we have the start of Yet More peculier dependencies,
not just devel(...) but now uClibc(...).
Yes, this is to avoid conflicts with sonames linked against glibc, ie. see:
[peroyvind@lappis rpm-5.3.9]$ echo /usr/uclibc/usr/lib64/libz.so.1.2.5
| LD_LIBRARY_PATH= tools/.libs/rpmdeps -P
elf(buildid) = 436568eecd8496e8648066fcacd79919833499b0
libz.so.1()(64bit)
libz.so.1(ZLIB_1.2.0)(64bit)
libz.so.1(ZLIB_1.2.0.2)(64bit)
libz.so.1(ZLIB_1.2.0.8)(64bit)
libz.so.1(ZLIB_1.2.2)(64bit)
libz.so.1(ZLIB_1.2.2.3)(64bit)
libz.so.1(ZLIB_1.2.2.4)(64bit)
libz.so.1(ZLIB_1.2.3.3)(64bit)
libz.so.1(ZLIB_1.2.3.4)(64bit)
libz.so.1(ZLIB_1.2.3.5)(64bit)
$ LD_LIBRARY_PATH=/usr/uclibc/lib64 ldd /usr/uclibc/usr/lib64/libz.so.1.2.5
linux-vdso.so.1 = (0x7fff68dff000)
libc.so.0.9.30.3 = /usr/uclibc/lib64/libc.so.0.9.30.3
(0x7f99798ff000)
ld64-uClibc.so.0.9.30.3 =
/usr/uclibc/lib64/ld64-uClibc.so.0.9.30.3 (0x7f99796f7000)
Note that the ldd will _ALWAYS_ display DT_NEEDED - DT_SONAME linkages
because that is in fact exactly the ELF feature:
Identical SONAME == Identical content
when usual library conventions are done correctly (i.e.
different/incompatible content
always has different soname).
The example you gave is exactly what is _SUPPOSED_ to happen.
I'm almost certain that is even the intent: so that uClibc can interoperate
with existing ELF libraries.
No, for uClibc there's a complete toolchain for it living under
/usr/uclibc, which
has it's own elf interpreter
(/usr/uclibc/{lib/ld-uClibc.so.0,lib64/ld64-uClibc.so.0})
which everything is linking against and the libraries aren't anywhere
near ABI compatible, they might even be built with different options.
Now for the package dependencies: You (or Mandriva) wish different policy for
packages
than how ELF SONAMES are used. If the example you gave using
Requires: libz.so.1()(64bit)
doesn't Just Work from all ELF executables, well that's no problem that
could or should be fixed with Yet More Package Dependencies like
Requires: uClibc(libz)
It is in fact not even the right goal to add dependencies to prevent
uClibc packages from using whatever ELF libraries are available.
No, that won't work, uClibc lives in a separate root that is not in the standard
library paths, it has a separate elf interpreter which everything links against,
and to make sure everything works outside the uClibc's root
(/usr/uclibc) as well,
rpaths are used.
Determining whether uClibc or not based on the elf interpreter used is
if anything
the closest you'll get to right, considering this is how the linker
actually behaves.
If Mandriva truly wants to segregate uClibc - other ELF linkages, then the
proper way to do that is to change the SONAMES to ensure that indeed, uClibc
links only uClibc specific libraries. It isn't terribly hard to
change the linkage line to make that happen.
Considering the idea is to maintain a complete toolchain with several shared
libraries etc., the headaches of changing SONAME and adjusting any dependencies
accordingly should be rather obvious.
If you want preference of uClibc dependent packages, well that can be done
too, just not in the ELF code in RPM. There's lots of ways to add dependencies
without scrapping-and-replacing (the _ONLY_ serious difference is a
readlink(2)
call to follow a symlink gawd knows where before doing what RPM is already
doing
with ELF dependencies, the rest is just strings) the existing mechanism in
RPM.
Wrong, if you take a closer look at the code, you'll see that the
result of readlink()
placed on 'path' is never even used currently.
I'll be commenting out this code for now to avoid any further
confusion concerning
this..
Notice that the devel() dependencies generated does *not* add any dependencies
on any of the SONAME packages/provides at all and has *nothing* to
do/relate with
the current automatic symlink dependencies in place either
All of the above comments apply equally to devel(...) and uClibc(...)
namespaces.
Figure out some other means than scrapping-and-replacing the ELF dependency
code generation to do whatever you wish
You're wrong in the assumptions made both wrt. devel() and uClibc(),
meaning that
I've either not written the code clearly enough, and/or caused by the
obvious lack
of documentation.
I will document this through blueprints on launchpad in the not so
distant future as
soon as I find the time.
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ librpm.vers rpmds.c rpmds.h rpmfc.c
I hate gmail... 2011/4/11 Per Øyvind Karlsen peroyv...@mandriva.org: 2011/4/11 Jeff Johnson n3...@mac.com: On Apr 11, 2011, at 12:29 AM, Per Øyvind Karlsen wrote: wrong sender.. fgrf -- Forwarded message -- From: Per Øyvind Karlsen peroyv...@mandriva.org Date: 2011/4/11 Subject: Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ librpm.vers rpmds.c rpmds.h rpmfc.c To: rpm-devel@rpm5.org 2011/4/11 Jeff Johnson n3...@mac.com: I knew I'd seen this symlink patch before: https://lists.dulug.duke.edu/pipermail/rpm-devel/2006-April/001037.html I did not like the patch the first time, and I don't like it 5 years later. I will rework the issue under #if RPM_VENDOR_MANDRIVA across the board. Note that the rule (already implemented except you've turned it off) All symlinks depend on their end-point. not only covers the special case of ELF libraries (when the symlink is explicitly owned by a package), but all other cases of symlinks to end-points in other packages. Yes you will need to teach URPMI and other depsolvers about symlink end-points constructed from RPMTAG_FILELINKTOS data, very not hard. The only remaining feature is the explicit Requires: devel(whatever) added to metadata. I fully realize the difficulties of transitive closure in dependency hell, but hey, lets not go around in circles all over again. Note that the rule I've stated requires zero additional metadata, the linkto dependency is constructed on the install box from the symlink end-points that are already in metadata (but you're likely choosing to disable that functionality some 4? 5? years after being implemented). Hm, I suspect you're misunderstanding the purpose of the devel() dependencies.. See the link where Stefan advocated. They're not in place for adding dependencies on where symlinks points at, but rather as an identifier for where 'symlink to SONAME ending with .so in filename' You will need to give me an explicitly worked example because there can be multiple symlinks like here: lrwxrwxrwx 1 root root 13 Feb 22 18:11 /usr/lib/libz.so - libz.so.1.2.5* lrwxrwxrwx 1 root root 13 Feb 14 12:33 /usr/lib/libz.so.1 - libz.so.1.2.5* lrwxrwxrwx 1 root root 23 Feb 14 12:33 /usr/lib/libz.so.1.2.5 - ../../lib/libz.so.1.2.5* The DT_SONAME is actually: $ readelf -a /usr/lib/libz.so.1.2.5 | grep SONAME 0x000e (SONAME) Library soname: [libz.so.1] And so I see $ rpm -q --provides libzlib-devel libz-devel = 1.2.5-3mdv2011.0 libzlib-devel = 1.2.5-3mdv2011.0 zlib-devel = 1.2.5-3mdv2011.0 uClibc-zlib-devel = 1.2.5-3mdv2011.0 uClibc-zlib1-devel = 1.2.5-3mdv2011.0 pkgconfig(zlib) = 1.2.5 == devel(libz) libzlib-devel = 1.2.5-3mdv2011.0 libzlib-devel(x86-32) = 1.2.5-3mdv2011.0 and devel(libz) isn't an SONAME at all but rather something that you are calling a SONAME. pedant, I could've implied the distinction by saying ~SONAME, SONAME-so.1 or whatever, I assumed what was implied/my laziness would be easy enough to grasp without obsessing about inaccuracies by my laziness.. I'm too tired for anal retentiveness right now.. And I don't know what you mean by identifier since I haven't any idea Identifier == 'libfoo.so' symlink to ELF file with SONAME (ie. libfoo.so - libfoo.so.1) Which implies ie. use with '/usr/bin/ld -lfoo', being part of -devel package, and again devel(libfoo) -lfoo - devel(libfoo) Notice the context? what is being identified (except de facto what Mandriva wants and what Stefan wanted etc). If you understood what Stefan wanted here, then you should understand what is wanted at: https://lists.dulug.duke.edu/pipermail/rpm-devel/2006-April/001054.html then you should understand what is wanted here as well as it's the exactly same. If not, then you didn't understand what Stefan wanted. is considered as being part of a devel package, hence the devel(soname) provides, with requires added for all devel(SONAME) found under DT_REQUIRED (so it's more dependencies related to what libraries linked at rather than symlinks endpoints to). And so the DT_NEEDED (there is no DT_REQUIRED afaik) is actually: DT_NEEDED, DT_REQUIRED, whatever, linguisticly equivalent enough for my brain to mixing the name, and easy enough for others to figgure.. $ readelf -a /usr/lib/librpmio-5.3.so | grep NEEDED ... 0x0001 (NEEDED) Shared library: [libz.so.1] or if you prefer $ ldd /usr/bin/rpm ... libz.so.1 = /lib/libz.so.1 (0xb65a7000) All of which appear consistently to claim libz.so.1 as the SONAME. And libz.so.1 does _NOT_ appear in Requires: devel(libz) libz.so - .so With the -devel package depending on the library package with libz.so.1, there's no need for specifying the full
Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ librpm.vers rpmds.c rpmds.h rpmfc.c
ps: if you still don't get it, it should be fairly easy grasping just by looking at the packages in cooker which has devel() dependencies, and see how these dependencies gets automatically pulled in from other packages providing devel() when installng a -devel package... ps: Excuse my aggitation, too little sleep and a bit stressed.. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/macros/ macros.rpmbuild.in rpm/scripts/ Ma...
2011/4/10 Per Ųyvind Karlsen pkarl...@rpm5.org:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
Server: rpm5.org Name: Per Ųyvind Karlsen
Root: /v/rpm/cvs Email: pkarl...@rpm5.org
Module: rpm Date: 10-Apr-2011 15:50:29
Branch: HEAD Handle: 2011041013502801
Added files:
rpm/scripts check-multiarch-files mkmultiarch
multiarch-dispatch multiarch-dispatch.h
multiarch-platform
Modified files:
rpm CHANGES
rpm/macros macros.rpmbuild.in
rpm/scripts Makefile.am
Log:
merge multiarch-utils from mandriva.
*phew*
With that, I'm aaalmost done merging, the only remaining script
is the perl dependency extractor, which I want to rewrite a and
improve a bit as well... I hate perl...
I think the perl dependency extractor will be the only mandriva
specific script left now, I think I'll just consider myself satisified
with using it as is for now, then perhaps rewrite later..
At least now it's out there! :)
I'll try merge the remaining macros from rpm-{mandriva,manbo}-setup
into macros/mandriva or the corresponding macro files where
appropriate, almooost done putting it to rest now.
And then there will be cleaning.. *yawn* I need a few minutes break
now..
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_4: rpm/lib/ rpmds.c
2011/4/10 Hatle, Mark mark.ha...@windriver.com:
See below inline
On Apr 9, 2011, at 11:57 PM, Per Øyvind Karlsen pkarl...@rpm5.org wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
Server: rpm5.org Name: Per Øyvind Karlsen
Root: /v/rpm/cvs Email: pkarl...@rpm5.org
Module: rpm Date: 10-Apr-2011 08:57:24
Branch: rpm-5_4 Handle: 2011041006572300
Modified files: (Branch: rpm-5_4)
rpm/lib rpmds.c
Log:
filter out some redundant devel(...) dependencies
Summary:
Revision Changes Path
2.170.2.7 +23 -10 rpm/lib/rpmds.c
patch -p0 '@@ .'
Index: rpm/lib/rpmds.c
$ cvs diff -u -r2.170.2.6 -r2.170.2.7 rpmds.c
--- rpm/lib/rpmds.c 10 Apr 2011 06:05:58 - 2.170.2.6
+++ rpm/lib/rpmds.c 10 Apr 2011 06:57:23 - 2.170.2.7
@@ -2904,21 +2904,19 @@
if (!devel s[strlen(s)-1] != ')')
(void) stpcpy( stpcpy(tmp, s), ()(64bit));
else {
- char *suffix;
tmp = stpcpy(tmp, s);
- if (devel (suffix = strstr(t, .so)))
- tmp = suffix;
+ if (devel)
+ tmp = strstr(t, .so);
tmp = stpcpy(tmp, (64bit));
}
}else
#endif
tmp = stpcpy(tmp, s);
if (devel) {
- char *suffix;
- tmp = stpcpy(tmp, s);
- if (devel (suffix = strstr(t, .so)))
+ char *suffix = strstr(t, .so);
+ if (suffix)
tmp = suffix;
- (void) stpcpy(tmp, ));
+ tmp = stpcpy(tmp, ));
}
return t;
@@ -3282,8 +3280,16 @@
int skipR = (flags RPMELF_FLAG_SKIPREQUIRES);
int lnklen;
char path[MAXPATHLEN];
+ /*
+ * We filter out these as they come with glibc, making dependencies on
+ * them rather redundant.
+ */
+ const char *filterRequires[] = {ld-linux, ld64-linux
libBrokenLocale.so,
+ libanl.so, libc.so, libcidn.so, libcrypt.so, libdl.so,
libm.so,
+ libnsl.so, libnss_compat.so, libnss_dns.so, libnss_files.so,
+ libnss_hesiod.so, libnss_nis.so, libnss_nisplus.so,
libpthread.so,
+ libresolv.so, librt.so, libutil.so, libthread_db.so};
ARGV_t deps = NULL;
- size_t nb = strlen(fn);
Filtering out the items below on embedded systems can break things (if I'm
understanding the code right)... In many embedded systems we use eglibc
which is configurable, we also some times break up the libc package into many
small sub packages so that we can only bring in the libraries that are
actually being used.
Yeah, I did initially do it more minimally, and certainly when splitting up
the libraries in multiple packages, it might easily become a source of grief.
But remember that this is only for devel() dependencies, usually you
don't bother splitting
up the -devel packages that much as you'd might desire to do with the
library packages..
This is an initial implementation ported from bash scripts in mandriva
though, so
there's certainly gonna be some rough edges.. ;)
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_4: rpm/ CHANGES rpm/macros/ macros.rpmbuild.in rpm/sc...
2011/4/10 Jeff Johnson n3...@mac.com:
On Apr 10, 2011, at 10:30 AM, Hatle, Mark wrote:
Do you have a pointer or any documentation on how to use these new macros
and helpers?
The multiarch macros?
I can tell you what I see:
Instead of ensuring that /usr/include/*.h is independent of arch
(this was what was done @redhat, took several months of churn-and-burn
to get the packaging policy to the MANDATORY/ENFORCING level),
Mandriva has chosen a VPATH-like approach in the build environment,
where a %{_arch}-mumbo-jumbo is automagically added to rpmbuild
CFLAGS and there's additional macro magic to rearrange %files.
Yeah, it provides support for working around it easily rather than fixing
it, but once I've fixed the multiarch check, it will be useful for detecting
offenders for fixing (rather than working around by rearranging) as well. :)
Since the whole scheme is based on consistent use of %{_arch}, the
scheme can/will depend on build system setup in some excruciatingly
painful ways.
This has just happened in Mandriva Cooker, where %{_arch}
happened to end-up with i586 not i386 (the correct value afaik).
First and only time it has happened, related to me wiping away the
same macros maintained for mandriva specifically from rpm-setup,
ie. a rpm bug. /sarcasm ;p
hehe
sarcasm
And for extra speshul painfulness on my own aging box, libcpuinfo
has decided to put pentium4 into varous arch-related configgery
in order to assist me with RPM configgery.
/sarcasm
The pentium4 macros was already part of cpu-os-macros.tar.gz before
me touching it, otherwise I wouldn't have added it.. :p
You WILL got nutso if you attempt Mandriva multiarch packaging
policy like this in Poky imho. Cleaner/easier is to patch out
(or use) @redhat derived packaging instead.
Fixing is of course preferred and often what is being done, but
maintainers doesn't always have the necessary insight and knowledge
to fix this, which makes it convenient to workaround it easily.
Detection during build is useful either direction. :)
But you are not using rpmbuild w Poky so it hardly matters.
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/macros/ python.in
2011/4/11 Jason Corley jason.cor...@gmail.com: -# Note: Used iff _use_internal_dependency_generator is non-zero. The +# Note: Used if _use_internal_dependency_generator is non-zero. The As a completely useless aside I see this kind of change from proyvind in almost every patch. I'm assuming it's because he thinks iff is a typo rather than shorthand for if and only if. Jason Hum? I thought it was a typo? Putting emphasis on and only if seems a bit redundant.. ;p Nice to see you alive though, haven't seen you posting to this list for a while. :o) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Fwd: [CVS] RPM: rpm/ CHANGES rpm/lib/ librpm.vers rpmds.c rpmds.h rpmfc.c
wrong sender.. fgrf -- Forwarded message -- From: Per Øyvind Karlsen peroyv...@mandriva.org Date: 2011/4/11 Subject: Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ librpm.vers rpmds.c rpmds.h rpmfc.c To: rpm-devel@rpm5.org 2011/4/11 Jeff Johnson n3...@mac.com: I knew I'd seen this symlink patch before: https://lists.dulug.duke.edu/pipermail/rpm-devel/2006-April/001037.html I did not like the patch the first time, and I don't like it 5 years later. I will rework the issue under #if RPM_VENDOR_MANDRIVA across the board. Note that the rule (already implemented except you've turned it off) All symlinks depend on their end-point. not only covers the special case of ELF libraries (when the symlink is explicitly owned by a package), but all other cases of symlinks to end-points in other packages. Yes you will need to teach URPMI and other depsolvers about symlink end-points constructed from RPMTAG_FILELINKTOS data, very not hard. The only remaining feature is the explicit Requires: devel(whatever) added to metadata. I fully realize the difficulties of transitive closure in dependency hell, but hey, lets not go around in circles all over again. Note that the rule I've stated requires zero additional metadata, the linkto dependency is constructed on the install box from the symlink end-points that are already in metadata (but you're likely choosing to disable that functionality some 4? 5? years after being implemented). Hm, I suspect you're misunderstanding the purpose of the devel() dependencies.. They're not in place for adding dependencies on where symlinks points at, but rather as an identifier for where 'symlink to SONAME ending with .so in filename' is considered as being part of a devel package, hence the devel(soname) provides, with requires added for all devel(SONAME) found under DT_REQUIRED (so it's more dependencies related to what libraries linked at rather than symlinks endpoints to). These are actually quite convenient dependencies added, as it prevents having to manually add dependencies on other -devel packages in the -devel package that it usually tends to depend on. I'm okay with the helper beng disabled by default, but I really don't see any good reason for moving it under #ifdef mandriva, that would be a step away from any attempts at vendor neutral approach IMO. The devel() dependencies are way more useful in real world cooker usage than ie. the pkgconfig() etc. dependencies at least to my experienec.. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/ CHANGES rpm/macros/ macros.in rpm/ rpmpopt.in
2011/4/10 Jeff Johnson n3...@mac.com:
You ought to pull back lib/verify.c (header signature checks re-implemented)
and rpmdb/hdrfmt.c changes (the sql/json part is done, works afaict, I'm
just waiting
to see if there's anything else before doing XML spewage the same way
with EVRD parsing).
k, will (or someone else, please) do!
I'm currently working on finishing up implementing/merging mandriva-specific
parts of /usr/lib/rpm/mandriva/find-{provides,requires} in/with the internal
dependency generator, trying to finish up to prepare for a migration in proper
time to make it for 2011.0, which I wanna finish up first though..
Starting to run out of time left, so any help on remaining issues help would be
appreciated..
I have the bits and pieces to put together the list with details, which I can do
sooner if someone would be willing to take a look at and help out on..
Pinto Matthew, wanna gimme a lending hand? :o)
If so, I'll get around to providing you with the details right away!
Ps: Matthew is missing from http://rpm5.org/team.php btw. ;)
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES build.c
2011/4/5 Jeff Johnson n3...@mac.com: No way Jose! rpmbuild (and *.rpm metadata) can NOT have any encoding assumed. Encoding is for DISPLAY, not for octets. Put unicode into package metadata at your own peril. Meanwhile -- without an means to specify encoding in metadata -- rpm in C has *ONLY* 8 bit clean octet's and the usual conventions for NUL terminated strings. Until there's a well defined means of specifying encoding for all tag strings -- and that's a fundamental design change to *.rpm packaging that likely will NEVER happen -- the problem simply CANNOT be fixed to meet naive luser expectations, and all attempts to fix anything are just doomed. C has octest, not utf8, and rpmdb strings are _NOT_ based on LC_ALL and other i18n/l10n conventions. You can of course put whatever garbage you wish into strings that will be stored as keys in an rpmdb, subject to all the usual GIGO conventions distro's wish to inflict upon their customers. Okay, my mistake anyways, I was looking into an issue with unicode strings, then I specified wrong locale when testing. I notice now that with properly specified locale, it accepts unicode characters. Still though, using '%description -l', descriptions disappears.. :| -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES build.c
2011/4/5 Jeff Johnson n3...@mac.com: On Apr 5, 2011, at 3:49 PM, Per Øyvind Karlsen wrote: 2011/4/5 Jeff Johnson n3...@mac.com: No way Jose! rpmbuild (and *.rpm metadata) can NOT have any encoding assumed. Encoding is for DISPLAY, not for octets. Put unicode into package metadata at your own peril. Meanwhile -- without an means to specify encoding in metadata -- rpm in C has *ONLY* 8 bit clean octet's and the usual conventions for NUL terminated strings. Until there's a well defined means of specifying encoding for all tag strings -- and that's a fundamental design change to *.rpm packaging that likely will NEVER happen -- the problem simply CANNOT be fixed to meet naive luser expectations, and all attempts to fix anything are just doomed. C has octest, not utf8, and rpmdb strings are _NOT_ based on LC_ALL and other i18n/l10n conventions. You can of course put whatever garbage you wish into strings that will be stored as keys in an rpmdb, subject to all the usual GIGO conventions distro's wish to inflict upon their customers. Okay, my mistake anyways, I was looking into an issue with unicode strings, then I specified wrong locale when testing. I notice now that with properly specified locale, it accepts unicode characters. The test is way way feeble, but once the expectation starts, well there's nothing to do but solve the problem correctly. What is broken -- by design -- is that *.spec recipes have multiple encodings, not a per-file encoding. And all hell starts to break loose in *.rpm packages when retrievals using keys pick up a per-key encoding. You tell me how to lookup all possible encodings from a database without specifically tying an encoding to every possible tag. Still though, using '%description -l', descriptions disappears.. :| C permits octets, not encodings. All possible encodings fit into octets with NUL terminated strings. The only thing that saves %description (which doesn't belong in *.rpm packages, another design issue that I don't feels like arguing about because you somplly will NOT like the answer of specifying possibly hundreds of properly encoded %description's in a single *.spec using the full-blown form of the 4-tuple used for encoding on a per-tag basis. Package metadata will simply explode for no known purpose. And RPM_I18NSTRING_TYPE has been on death row all of this century, is carried along solely because PLD and a few other distros *still* insist on inserting translations into *.spec recipes directly. A data type that is sometimes an arary, and sometimes a scalar dependent on the context of interpretation just isn't a useful data type. Nor is there any known/modern reason why all possible encodings MUST be carried in each and every package header in the year 2011. There's specspo and other means of %description et al distribution that are far far superiour to RPM_I18NSTRING_TYPE pulled in from *.spec recipes. This was _NOT_ true back in 1998 when RPM_I18NSTRING_TYPE was devised. Hm, okay, so better obviously needs to be done. For what currently is though, is it supposed to be broken or...? -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES build.c
2011/4/5 Jeff Johnson n3...@mac.com:
On Apr 5, 2011, at 4:13 PM, Per Øyvind Karlsen wrote:
Hm, okay, so better obviously needs to be done.
Have a go at fixing if you wish.
Here's the code that breaks things:
/* Lose the inheirited %description (if present). */
{ HE_t he = memset(alloca(sizeof(*he)), 0, sizeof(*he));
int xx;
he-tag = RPMTAG_DESCRIPTION;
xx = headerGet(pkg-header, he, 0);
he-p.ptr = _free(he-p.ptr);
if (xx he-t == RPM_STRING_TYPE)
xx = headerDel(pkg-header, he, 0);
}
I assume that what's intended is that headerGet() should set the following:
he-t = RPM_I18NSTRING_TYPE,
but in stead it will always be
he-t = RPM_STRING_TYPE.
So the result is that the only the last description gets added to the package.
Is there a bug in headerGet(), or something about the logic I fail to comprehend
here?
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/build/ reqprov.c
2011/4/1 Jeff Johnson n3...@mac.com: Under #ifdef RPM_VENDOR_MANDRIVA please. It already is. ;) -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpmqv.c
2011/3/27 Jeff Johnson n3...@mac.com: This patch (and devzero's change) make no sense. rpm -ba is _ALWAYS_ in short-cicuit mode by definition, because the starting point for --short-circuit is a non-existent directory and nothing is built. The --short-circuit is to resume a build from a partially built tree at a given point and run to completion. Dare I ask? WTF do you want --short-circuit with -ba?!? Because some script has decided to _ALWAYS_ add --short-circuit? That's stoopid ... Because I was thinking of -ba to have similar expected behaviour as -bb + -bs. Ie. I've made the false assumption when doing 'rpm -ba --short-circuit', where rpm did the complete build process rather than just -bb.. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: RPM+Augeas - Cooker?
d'oh, used wrong sender.. 2011/3/24 Per Øyvind Karlsen peroyv...@mandriva.org: 2011/3/24 Jeff Johnson n3...@mac.com: Cool! Cooker finally has an Augeas package in main! The issue with the rpm+augeas embedding is that augeas development is pretty active, with lots of patterns in lenses and more. SO I did an implementation against the git check-out in order to keep up. Augeas is just starting to get picked up by distros like Cooker, so it is difficult to design the AutoFu to Just Work because there isn't any clear reference point with a released version. Now there is a reference point: augeas in cooker devel Note that augtool is/was the basis (as a nicely designed CLI tool) for all of the embeddings in RPM. And the embedding used in RPM isn't really any different than the libffi in the Python augeas bindings. Nother are quite simple to do because of the excellently designed augtool high level library API. Per Oyvind: Would you like to try RPM+Augeas in Cooker? You are the maintainer, I'm just the asshole here ;-) I need to read up on it, but I don't mind if you go ahead try it, I'm feeling that I'm lagging behind you enough already trying to keep up, while having other things to do as well.. :| While I'm having main responsibility for rpm in cooker context and such, I certainly wouldn't mind if you and/or Pinto Elia want to share the maintenance of rpm stuff in cooker. I have other responsibilities as well, so I'd be overexcited and reliefed by having more active help on cooker directly. :) (aside) If you could also arrange to link against the OSSP uuid in the Cooker packaging, I can start demonstrating how UUID's can be used for package identification. Sound like a plan? Sure. :) __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: RPM+Augeas - Cooker?
2011/3/24 Jeff Johnson n3...@mac.com: On Mar 24, 2011, at 12:40 PM, Per Øyvind Karlsen wrote: d'oh, used wrong sender.. 2011/3/24 Per Øyvind Karlsen peroyv...@mandriva.org: 2011/3/24 Jeff Johnson n3...@mac.com: Cool! Cooker finally has an Augeas package in main! The issue with the rpm+augeas embedding is that augeas development is pretty active, with lots of patterns in lenses and more. SO I did an implementation against the git check-out in order to keep up. Augeas is just starting to get picked up by distros like Cooker, so it is difficult to design the AutoFu to Just Work because there isn't any clear reference point with a released version. Now there is a reference point: augeas in cooker devel Note that augtool is/was the basis (as a nicely designed CLI tool) for all of the embeddings in RPM. And the embedding used in RPM isn't really any different than the libffi in the Python augeas bindings. Nother are quite simple to do because of the excellently designed augtool high level library API. Per Oyvind: Would you like to try RPM+Augeas in Cooker? You are the maintainer, I'm just the asshole here ;-) I need to read up on it, but I don't mind if you go ahead try it, I'm feeling that I'm lagging behind you enough already trying to keep up, while having other things to do as well.. :| While I'm having main responsibility for rpm in cooker context and such, I certainly wouldn't mind if you and/or Pinto Elia want to share the maintenance of rpm stuff in cooker. I have other responsibilities as well, so I'd be overexcited and reliefed by having more active help on cooker directly. :) (aside) If you could also arrange to link against the OSSP uuid in the Cooker packaging, I can start demonstrating how UUID's can be used for package identification. Sound like a plan? Sure. :) BTW, expect some bit rot when you get to -laugeas. Augeas was NICETOHAVE untikl yesterday ;-) Nothing will be too hard to fix, David Lutterkort has designed a nice API into Augeas, just that configuration management is a never ending battle and there's endless details to fiddle with. Biut with a stable reference target to shoot at, well, it won't be too hard to get augeas embedded into RPM. I'll write up some toy test cases for tests/ make check. Basically the embedding is one-to-one with augtool(8) so you can probably wing it with man augtool I've just commited support, will submit a new rpm build with it enabled shortly.. -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ configure.ac
2011/3/24 Jeff Johnson n3...@mac.com: Nice! Hacks == hacks (the uuid_t on Mac OS X is dreadfully annoying). Thanks for -luuid! Now I can write up how to use (original work was ~ May, 2008 on rpm-devel@rpm5.org archives if interested) I've commited some various fixes for ossp_uuid for it to build, work properly without conflicts and also pass all regression tests as well: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/ossp_uuid/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
