Re: Flexibly building against third-party libraries (RPM_CHECK_LIB)
In regard to: Re: Flexibly building against third-party libraries...: maybe (not sure about non-coreutils find) That's the problem. The find implementation on most commercial UNIX platforms won't support -wholename, so you would have a configure test that requires the GNU version of find. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
LP64 alignment issue in 4.4.9 and CVS
rpm 4.4.9 on sparcv9-sun-solaris2.8 (LP64) compiled with the Sun Workshop
11 compiler gets a reproduceable SIGBUS when installing a package or
importing a key with a fresh database. I haven't seen this problem on
my x86_64-sun-solaris2.10 workstation which is also running rpm 4.4.9.
x86_64 must be more forgiving of alignment than LP64 sparc.
I've done some digging and I think the problem is basically the same as
this one, but in a different spot:
https://lists.dulug.duke.edu/pipermail/rpm-devel/2006-October/001791.html
The stack trace looks like
$ dbx .libs/rpmk core
core file header read successfully
Reading ld.so.1
Reading librpm-4.4.so
Reading librpmdb-4.4.so
Reading librpmio-4.4.so
Reading libpopt.so.0
Reading libelf.so.1
Reading libbeecrypt.so.7
Reading libneon.so.26
Reading libexpat.so.1
Reading libm.so.1
Reading libdl.so.1
Reading libz.so
Reading libintl.so.8
Reading libc.so.1
Reading librt.so.1
Reading libpthread.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libthread.so.1
Reading libCstd.so.1
Reading libCrun.so.1
Reading libaio.so.1
Reading libmp.so.2
Reading libc_psr.so.1
[EMAIL PROTECTED] ([EMAIL PROTECTED]) terminated by signal BUS (invalid address
alignment)
Current function is intGetEntry
1784 if (p) *p = NULL;
(dbx) print p
p = 0x7fffe78c
(dbx) print *p
*p = (nil)
(dbx) where
current thread: [EMAIL PROTECTED]
=>[1] intGetEntry(h = 0x100145960, tag = 1184, type = (nil), p = 0x7fffe78c, c =
0x7fffe75c, minMem = 1), line 1784 in "header.c"
[2] headerGetEntryMinMemory(h = 0x100145960, tag = 1184, type = 0x7fffe77c, p =
0x7fffe78c, c = 0x7fffe75c), line 1876 in "header.c"
[3] headerGetEntryMinMemory(h = 0x100145960, tag = 1184, type = 0x7fffe77c, p =
0x7fffe78c, c = 0x7fffe75c), line 299 in "hdrinline.h"
[4] rpmdbAdd(db = 0x10012cc00, iid = 1182551776, h = 0x100145960, ts = (nil), hdrchk =
(nil)), line 3125 in "rpmdb.c"
[5] rpmcliImportPubkey(ts = 0x10013fc00, pkt = 0x100142e00 "\x99^A\xa1^D:\xb1Br^Q^D",
pktlen = 1638), line 539 in "rpmchecksig.c"
[6] rpmcliImportPubkeys(ts = 0x10013fc00, qva = 0x7f286d18, argv =
0x100111c38), line 620 in "rpmchecksig.c"
[7] rpmcliSign(ts = 0x10013fc00, qva = 0x7f286d18, argv = 0x100111c30), line
1080 in "rpmchecksig.c"
[8] main(argc = 3, argv = 0x7fffee28, envp = 0x7fffee48), line 794 in
"rpmqv.c"
It looks like the problem begins in rpmdbAdd() in rpmdb.c, with:
uint32_t hcolor = 0;
...
if (!hge(h, RPMTAG_PACKAGECOLOR, &bnt, (void **) &hcolor, &count)) {
Because hcolor starts out as a 32 bit quantity, it's aligned on a 4-byte
boundary. It's later used in a context where it would need to be aligned
on an 8-byte boundary. If I make the same "fix" that I did for the
problem I reported last October, changing the type from uint32_t to
uint64_t, the problem goes away.
It looks like there might be another problem lurking nearby with the
int32_t tid = iid;
but I haven't actually triggered that problem yet.
Jeff, if you need any additional information to formulate a correct fix,
let me know.
Tim
--
Tim Mooney[EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building(701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: LP64 alignment issue in 4.4.9 and CVS
In regard to: Re: LP64 alignment issue in 4.4.9 and CVS, Mark Hatle said...:
Have you tried compiling w/ -mstrict-align (assuming you are using gcc)?
This might at the least work around the issue.
I'm not using gcc, although your comment is still useful, since it
got me looking at the alignment options for the Sun compilers. I think if
I wanted to work around this issue, I could use
-xmemalign=8i
Also:
uint32_t hcolor = 0;
...
if (!hge(h, RPMTAG_PACKAGECOLOR, &bnt, (void **) &hcolor, &count)) {
Because hcolor starts out as a 32 bit quantity, it's aligned on a 4-byte
boundary. It's later used in a context where it would need to be aligned
on an 8-byte boundary. If I make the same "fix" that I did for the
problem I reported last October, changing the type from uint32_t to
uint64_t, the problem goes away.
It looks like there might be another problem lurking nearby with the
int32_t tid = iid;
but I haven't actually triggered that problem yet.
After looking at it further, I don't think "int32_t tid" is going
to be a problem, since it's used in a different way and not cast to (void
**).
Tim
--
Tim Mooney[EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building(701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: LP64 alignment issue in 4.4.9 and CVS
In regard to: Re: LP64 alignment issue in 4.4.9 and CVS, Jeff Johnson said...: On Jun 26, 2007, at 12:28 PM, Tim Mooney wrote: rpm 4.4.9 on sparcv9-sun-solaris2.8 (LP64) compiled with the Sun Workshop 11 compiler gets a reproduceable SIGBUS when installing a package or importing a key with a fresh database. I haven't seen this problem on my x86_64-sun-solaris2.10 workstation which is also running rpm 4.4.9. x86_64 must be more forgiving of alignment than LP64 sparc. This bug was reported by PLD/sparc64 abt a week ago. There's an alignment issues with &hcolor. See recent checkin for fix on both HEAD and rpm-4_5. Thanks for the info, sorry for the duplicate report. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmdb/ Makefile.am
In regard to: Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmdb/...: On Wed, Jun 27, 2007, Jeff Johnson wrote: On Jun 27, 2007, at 6:44 PM, Ralf S. Engelschall wrote: Simplify internal Berkeley-DB handling in rpmdb/ even further and as a wished side-effect allow (at least in an clearly unsupported way to make Jeff not panic ;-) the use of --with-db=external. It's not a question of panic, but rather support and feature regression. [...] I *really* don't want to diagnose these problems again and again and again because lusers want choice until it hurts. Fair enough! It certainly is a difficult balance between avoiding the trouble with lusers and still allowing packagers to build RPM with an external Berkeley-DB _without_ having to patch the RPM sources. But we can even go one step further: on "--version" or "--help" GNU tools often output "Report bugs to <[EMAIL PROTECTED]>.". We could use this with rpm-devel@rpm5.org and in case someone wants to use an option like --with-db=external he _FIRST_ has to specifiy something like "--with-bugreport=" in his packaging or an Autoconf error will occur. This way the packager also is _FORCED_ to take action (and this way has to know what he is doing) _AND_ the end user is also informed explicitly who to contact for support. For instance in OpenPKG I would like to use --with-bugreport="[EMAIL PROTECTED]" to make sure the OpenPKG users do not directly contact rpm5.org. Why don't you include an "rpm-bug-report" script, a la bashbug, that automates much of that, including relevant information about how rpm was configured, the environment, etc, and then update the docs and begin to encourage users to use that for bug reporting? Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: No Neon patch...
In regard to: No Neon patch..., Mark Hatle said (at 1:22pm on Jun 29, 2007): Taken from rpm.org rpm-4.4.2.1 tree. Any comments or may I commit. (I didn't just hit go, since I figured there might be some "discussion" on this issue.) :) neon can be a PITA, especially because it defaults to static lib only and has non-obvious dependencies so linking with it can be challenging, but I'm concerned about the proliferation of rpm "flavors". Your flavor might be built without neon at all so it won't support certain functionality, someone else's rpm might have neon support but no lua, etc. Sure, it's possible to have rpm's internal dependencies such that when someone tries to install a package that "Requires(interp): lua" (or whatever) the install aborts immediately if the rpm on the box doesn't provide that, but that's not the point. People writing spec files, or whatever packaging recipe format eventually evolves, will write their recipes to use the functionality that they know is guaranteed to be available in the rpm command that users have available on their systems -- the minimal subset of features that every rpm command supports. Pretty soon, people won't try make use of lua or neon or anything else that falls outside of that minimal subset, and those features in rpm will become the software equivalent of my appendix -- evolutionary leftovers that have ceased to serve a useful purpose. I know I'm frequently in left field WRT rpm, but I think if you make stuff like neon or lua too easily "optional", those things will fall outside of the minimal subset, and at that point one needs to decide if it wouldn't be better to just remove the evolutionary leftovers completely. Just MHO, Tim (who still has his appendix, thank you very much) -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: No Neon patch...
In regard to: Re: No Neon patch..., Michael Jennings said (at 3:12pm on Jun...:
On Friday, 29 June 2007, at 14:05:10 (-0500),
Tim Mooney wrote:
People writing spec files, or whatever packaging recipe format
eventually evolves, will write their recipes to use the
functionality that they know is guaranteed to be available in the
rpm command that users have available on their systems -- the
minimal subset of features that every rpm command supports.
I wish that were true. But the unfortunate reality is that each
distro writes their spec files to use their own proprietary set of
capabilities and macros. RHEL RPM's may not build without
redhat-rpm-config. Mandriva RPM's frequently require custom macros,
not the least of which being %{make}. Few people actually strive to
create portable spec files.
You're more familiar with more Linux distributions than I am (we have
only RHEL 2.1-5 and a small number of SuSE here), but I believe what
you're saying and I'm not at all surprised.
I was thinking mainly of the application vendors when I replied earlier --
companies like EMC, Oracle, IBM, etc., that want to claim that their
application supports at least RHEL, SuSE, and possibly other rpm-based
distributions. It's their packaging people (or monkeys, as the case
may be) that will focus on the minimal subset, in the interest of making
their packages install on the widest range of rpm-based distributions.
As Mats Wichmann's email about ISV installers on June 14th made abundantly
clear, ISVs packaging software for multiple distributions would just as
soon have one format (probably good old tar!) for all platforms. MHO is
that that's a crappy attitude for a vendor (make things easy for our
packaging and docs people, not the customer) and I personally tend to
award negative points to any vendor that takes that approach, but that's
just me standing alone in left field again. ;-)
Tim
--
Tim Mooney[EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building(701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: No Neon patch...
In regard to: Re: No Neon patch..., Michael Jennings said (at 9:19pm on Jun...: On Friday, 29 June 2007, at 14:28:46 (-0500), Tim Mooney wrote: I was thinking mainly of the application vendors when I replied earlier -- companies like EMC, Oracle, IBM, etc., that want to claim that their application supports at least RHEL, SuSE, and possibly other rpm-based distributions. It's their packaging people (or monkeys, as the case may be) that will focus on the minimal subset, in the interest of making their packages install on the widest range of rpm-based distributions. If that's the assumption we're operating under, should we even bother trying to allow ISV rpmdb entries? I'm more inclined to think in the opposite direction: add important features that ISV's can't live without so that they will pressure distributions to update to and support those features. I would prefer that over the scenario I'm afraid we're heading for too. The question is, what shiny features will ISVs clamor for? The concerns I've voiced could turn out to be completely unfounded, too. It would be great if were the case. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: RPM 5 distribution tarball size?
In regard to: RPM 5 distribution tarball size?, Ralf S. Engelschall said...: I don't think we should do this. We really can shrink this. The Berkeley-DB documentation is available online (in case one needs it during code hacking) and even if we keep the actually used db/docs/api_c/ stuff (which is just 1.3MB in size) we still can get rid of about 21MB useless data. I haven't looked at the distribution terms for Berkeley DB, since I don't distribute it. If you can legally remove the docs and still distribute the remaining parts internal to RPM, I think getting rid of the docs in the distributed tarball would be good. You should carefully review their distribution terms, though. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Eliminating Berekeley DB/Sqlite3 in favor of a flat file rpmdb
In regard to: Re: Eliminating Berekeley DB/Sqlite3 in favor of a flat file...: Evening folks, On Wed, 18 Jul 2007, Jeff Johnson wrote: Using flat files avoids all the complexity of rpmdb iterator methods, maximizes access of installed information because only files need to be opened, and permits 3rd party software installers to simply write their metadata file goop to the file system, no fuss no muss. well...so far so good. What's up to the performance? Is a flat file rpmdb faster rather Berkeley DB? I would be shocked if it were. I would expect (but have not done any benchmarks to confirm or refute my expectation) that writes especially would be slower, but I also would expect that writes to the rpm database at package install time are already a vanishingly small part of the overall time it takes to install a package. In other words, I doubt it matters that writes will be slower, because that's a negligible portion of the time it takes to install a package. I've discovered a lot while lurking on the list. I never would have guessed that there are so many people that think that having rpm use Berkeley DB is a bad thing. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Eliminating Berekeley DB/Sqlite3 in favor of a flat file rpmdb
In regard to: Re: Eliminating Berekeley DB/Sqlite3 in favor of a flat file...: On Jul 18, 2007, at 1:44 PM, Jeff Johnson wrote: A single flat file with an offset can be substituted that is at least as well performing, but the implementation is more subtle because one needs to keep track of the offset value to debug the mess. Not true for files in a directory, ls -al suffices. Actually two files iirc, see the Mercurial OLS 2006 paper. Caveat: this is from my 1+ year old memory, further study is needed if flat files are to be used. The uglix directory trick is ancient, see ls -al /usr/share/terminfo for similar. Yup, I've actually used that trick myself on a couple occasions. For those projects my "database" needs were pedestrian, though. I agree with your previous post, that robustness and scalability are also important factors to consider -- performance shouldn't trump those. I've long considered Berkeley DB both robust and scalable. Maybe not as robust as opendir()/readdir()/stat()/open()/write(), but not too far off that mark. I'm not at all against moving to a directory-as-key database, I'm just surprised that a project that has such a long history with bdb has that on the table as an option. It's probably good to "rethink everything" once in a while, but most projects go the opposite direction -- start with lame-o filesystem database and move up to BDB later on. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Eliminating Berekeley DB/Sqlite3 in favor of a flat file rpmdb
In regard to: Re: Eliminating Berekeley DB/Sqlite3 in favor of a flat file...: ;-) Glad to hear there are a few who do not dislike Berkeley DB. I don't know that it's to the level of "Gold Standard", but Berkeley DB is, in my experience, an extremely high quality piece of software. I'm not a worrier, but if I were, there are hundreds of software components in the environment I work in that are *less* critical than Berkeley DB that I would worry more about breaking and ruining my day (or week). I've probably just jinxed myself, ;-) Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Eliminating Berekeley DB/Sqlite3 in favor of a flat file rpmdb
In regard to: Re: Eliminating Berekeley DB/Sqlite3 in favor of a flat file...: ...snip... but most projects go the opposite direction -- start with lame-o filesystem database and move up to BDB later on. Subversion is a good example of a large and popular software project that went the other direction with good results. Good point. I didn't realize that svn was now preferring fsfs as the repository store instead of bdb -- I just thought it was a "new" option. subversion's history with bdb is rather shorter than rpm's, though. In the end, I'm with you -- it doesn't matter to me whether RPM sticks with Berkeley DB or switches to using the filesystem. If switching ends some of the points of contention, great. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm 4.4.9 missing neon support in Solaris 9 - build issue?
In regard to: Re: rpm 4.4.9 missing neon support in Solaris 9 - build...: If start this command in another wndow (within a short interval): wget ftp://rpm.rutgers.edu/solaris/solaris9-sparc64/hydrogen/RPMS.main/openssl-0.9.8g-1.solaris2.9-sparc64.rpm then the first command wakes up and continues to completion. That looks like a ProFTPD 1.3.0a server problem with EPSV mode to me. Thank you very much for debugging this. After your reply there has been some discussion here on whether the problem is server related, or at the switch level. This might have actually tipped up a bug in our networking, but we're not sure yet. I'm going to upgrade proftpd to the latest stable anyways. The question that I'm really wondering about now is why did Tim Mooney have the same results with his Solaris 10 setup. I'm not sure if he was actually using our repo when testing or whether it was his own. I'm curious to find out if this same issue is happening to him using a repo that isn't rpm.rutgers.edu. I was using our own, which was connecting to a Red Hat Linux 4 server running vsftpd 2.0.1. The same issue was happening for me there. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm 4.4.9 missing neon support in Solaris 9 - build issue?
In regard to: Re: rpm 4.4.9 missing neon support in Solaris 9 - build...: On Nov 6, 2007, at 12:15 PM, Tim Mooney wrote: I was using our own, which was connecting to a Red Hat Linux 4 server running vsftpd 2.0.1. The same issue was happening for me there. Hmm, then perhaps there is some issue wrto the getpeername(2) or getnameinfo(3) lookup. The code certainly looks obvious, and "works" against vsftpd on my F* box ... I just tried again with a different RPM and against proftpd 1.3.1, and I get the same result (failure). Note that like David, I also don't get any additional debugging information when using --ftpdebug. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm 4.4.9 missing neon support in Solaris 9 - build issue? (fwd)
In regard to: Re: rpm 4.4.9 missing neon support in Solaris 9 - build...: I'll likely replace the "r.ufdio" with a macro for each Fopen so that users/distros can control whether, say, queries should be network aware, but installs should not be permitted network access. That's what I was going to suggest. That will be a nice enhancement. The only development that has not been request driven since July was speeding up queries by 10x 2 weeks ago (which also helped stabilize HEAD at the time). That alone will be a good reason to upgrade. Not a problem on my end, but Tim has said that a Solaris rpm client could not access a RHEL vsftpd server. That's correct, and there's no NAT or anything else between my workstation and the ftp server I tried. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Comments on 5.0b4
In regard to: Re: Comments on 5.0b4, Ralf S. Engelschall said (at 11:23pm...: On Fri, Jan 04, 2008, Michael Jennings wrote: %_lib is incorrectly being set to "/lib" instead of "/lib64". This used to be automatically handled by RPM until someone "fixed" it. So what is the "new and improved" way of doing this? :) There was consensus here that the whole /lib vs. /lib64 fiddling is totally platform-specific and too intrusive in a cross-platform/cross-vendor world and hence has to be decided and implemented outside of the stock RPM 5 code base. Usually, the "right" way IMHO is to handle this in a rpm.spec of the particular Linux vendor... I clearly wasn't paying attention at the right time. Can you give a more specific example of what you believe the "right" way of handling this is? I'm picturing a lot of boilerplate goop propagated into hundreds of spec files, and that can't imagine how that's the right way to accomplish anything. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Permitting noarch subpkgs from a per-arch build
In regard to: Permitting noarch subpkgs from a per-arch build, Jeff Johnson...: So there's a need for an explicit check that indeed, a noarch package contains only file types that reasonably make sense to include in a noarch subpkg. Agreed. If someone helps defining "reasonably permitted" patterns, I'll be happy to do the rest of the implementation necessary to permit noarch subpkgs from a single build. It depends on what your timeframe is on this, but I would be willing to help. On a sort-of related note: you told me once long ago that the only barrier to having "noos" packages was getting the os_compat chains set up. rpmrc is no longer the way to accomplish that, but is noos packaging something that also could be accomplished with a little support from "the community"? Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Permitting noarch subpkgs from a per-arch build
In regard to: Re: Permitting noarch subpkgs from a per-arch build, Jeff...: After spending 15 minutes writing a script that does 1) Get RPMTAG_CLASSDICT for every package. 2) Get RPMTAG_CLASSIDICT for noarch packages. 3) Exclude noarch types from other types to generate file types that should not be permitted in noarch packages. (with some modest filtering using sed), I come to the rather unsurprising blacklist rule on linux/ix86 for noarch packages RPMTAG_CLASSDICT should never contain the string "ELF". When it's regexed, it should probably be something like (^ELF | ELF ) but I agree that ELF is the prime candidate to watch for. Looking through what I currently have installed on my ELF/ELF64 x86_64-sun-solaris2.10 workstation, the only other thing I see that stands out as something that we might want to exclude from noarch packages is current ar archive It's certainly possible that an ar archive could contain platform neutral files, but that's pretty uncommon (maybe not on OS X, though?). Other possible candidates to watch for (that might apply to non-ELF platforms too) would be , dynamically linked , (not )?stripped$ Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [PATCH]: possibility to disable dependencies on parent dir
In regard to: Re: [PATCH]: possibility to disable dependencies on parent...: I personally am still unsure whether having files depend on their parent directory (and symlinks depend on their end-point) was the right thing to do in rpm or not. I think it was. It causes a little bit of pain at the start, but ultimately I think it was the right idea. The only challenge I've found with it is one I brought up a while back -- how to decide what package should claim a particular directory, when there are multiple packages that might install files into that directory and no real required base package. In my experience, this happens most with perl modules and directories under perl's site_lib. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
In regard to: rpm3 package still exist, devzero2000 said (at 4:53pm on Jun...:
rpm -qi TIVsm-API
Name: TIVsm-APIRelocations: /opt
Version : 5.3.0 Vendor: IBM
Release : 0 Build Date: Wed 08 Dec 2004
01:29:20 PM CET
Install Date: Wed 06 Jun 2007 11:42:51 AM CEST Build Host:
darkover.mainz.de.ibm.com
Group : Utilities/Archiving Source RPM:
TIVsm-5.3.0-0.src.rpm
Size: 13934052 License: Commercial
Signature : (none)
URL : http://www-3.ibm.com/software/tivoli/products/storage-mgr/
Summary : the API
Description :
IBM Tivoli Storage Manager API
rpm -q --qf '%{RPMVERSION}\n' TIVsm-API
3.0.6
That was built by ibm, and the commercial UNIX vendors are notorious for
sticking with a particular version of some software to maintain backward
compatibility.
This segues nicely into a question that just came up on the NetWorker
(backup software) mailing list. EMC also packages all their RPMs for
their backup software using RPM 3.0.6, and EMC and IBM aren't the only
ones doing this.
If you try sign an RPM built with 3.0.x with a 4.X.Y version of RPM, the
RPM becomes corrupted.
Would this be something that's easy to fix -- make RPM 5.1.x capable of
signing both modern and ancient RPMs? It sure would make a lot of
sysadmins lives easier, as they wouldn't have to keep an old copy of RPM
around just to sign packages they get from vendors.
Tim
--
Tim Mooney[EMAIL PROTECTED]
Information Technology Services (701) 231-1076 (Voice)
Room 242-J6, IACC Building(701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
In regard to: Re: rpm3 package still exist, Jason Corley said (at 12:35pm...: On Wed, Jun 25, 2008 at 12:06 PM, Tim Mooney <[EMAIL PROTECTED]> wrote: If you try sign an RPM built with 3.0.x with a 4.X.Y version of RPM, the RPM becomes corrupted. Would this be something that's easy to fix -- make RPM 5.1.x capable of signing both modern and ancient RPMs? It sure would make a lot of sysadmins lives easier, as they wouldn't have to keep an old copy of RPM around just to sign packages they get from vendors. Having asked this question once or twice over the last few years I'll save Jeff the hassle of telling you that it's an insoluble problem. So short answer is if it ain't happened by now, it ain't gonna happen. Jason Thanks Jason. I pretty much figured that was the case, but hope springs eternal, as they say. ;-) Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
In regard to: Re: rpm3 package still exist, Jeff Johnson said (at 12:41pm...: Could a converter be written if preserving header+payload MD5 was not an issue? You betcha. The details necessary to do so I tried to send to <[EMAIL PROTECTED]> this weekend past, but apparently e-mail is becoming increasingly unreliable for communication, I can't seem to find what I sent in the archives. Oh well ... So support for signing ancient RPMs is a no-go, but it might be possible to convert ancient RPMs to a more modern format? Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
In regard to: Re: rpm3 package still exist, Jeff Johnson said (at 2:35pm on...: On Jun 25, 2008, at 1:26 PM, Tim Mooney wrote: In regard to: Re: rpm3 package still exist, Jeff Johnson said (at 12:41pm...: Could a converter be written if preserving header+payload MD5 was not an issue? You betcha. The details necessary to do so I tried to send to <[EMAIL PROTECTED]> this weekend past, but apparently e-mail is becoming increasingly unreliable for communication, I can't seem to find what I sent in the archives. Oh well ... So support for signing ancient RPMs is a no-go, but it might be possible to convert ancient RPMs to a more modern format? Yes. But it won't be the same package any more, any digital signatures done by the vendor will be lost, and the header+payload MD5 digest will change. :-) I personally don't care about the loss of vendor signatures. Since I'm not very familiar with RPM internals, I'm not sure what all the implications are for the loss of header+payload MD5, but I'm guessing most RPM users won't care. Meanwhile, the incidence of "LSB format" packages is almost zero these days. The problem will eventually solve itself, adding a conversion tool changes almost nothing. But I will likely write the converter this summer no matter what. That's great to hear. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
In regard to: Re: rpm3 package still exist, devzero2000 said (at 10:06pm on...: Why lusers want to resign package they have not created in first place: if they want signed package, well, they have to ask the vendor alongside the pub key - they have already paid anymore. So they can distribute it via their software distribution infrastructure. For example, Red Hat Satellite Server. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
In regard to: Re: rpm3 package still exist, Jeff Johnson said (at 3:25pm on...: Modern == what has been widely deployed for 6+ years. Jeff, I totally agree. The problem is, for better or worse, there are plenty of large commercial vendors that are still providing software that's been packaged with non-modern RPM. It's the sysadmins that are the ones who suffer. I would love to see every vendor that distributes RPMs upgrade to something that's been released in the last couple years, but based on past experience with large vendors and what I've seen so far, that's not going to happen any time soon, even with customers pushing the vendors to do so (and we are). As devzero points out, the even larger problem isn't what version the RPM is built with, it's how the software is packaged in the first place. There are a lot of really bad vendor RPMs that do pretty crazy stuff. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
In regard to: Re: rpm3 package still exist, devzero2000 said (at 10:56pm on...: I can sign the document i wrote. I can sign document, written by other, on which i have control, can update, verify the quality or, almost, i have trust. If i have to sign document, which i have paid and not have control, weel, i am crazy or silly. It is as i have to sign m$ software. Only for distribute it. So the digital signature became a joke. And i not like this. I'm not saying you're wrong, but look at it this way: any time you accept a package (whether it's an RPM on Linux or a "setup.exe" on Windows) from a vendor and you install it on your system, you're placing a significant amount of trust in that vendor. If you sign a package for distribution via your software distribution mechanism (maybe it's yum, maybe it's Red Hat Satellite, maybe it's something different), you're not say that you wrote the software and that you vouch for the quality of the software: you're saying that you obtained the software from the vendor. You're vouching for its provenance, not its quality. By vouching for its provenance, you can now easily distribute this software via your software distribution method to whatever systems should have it. If "whatever systems should have it" == 10,000 systems, isn't it better to distribute it easily via your software distribution method than to do it the hard way? Either way, the software gets installed on the system. You're in no worse position by having signed it for internal distribution than you are if you hadn't. There's also no danger that some third party might see your signature on an RPM and take that as a sign that you're vouching for the quality of the software, because all of the vendors that we're talking about as part of this discussion, that are still using rpm 3.0.x, have legal restrictions on redistributing the software you've obtained from them. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm3 package still exist
In regard to: Re: rpm3 package still exist, Jeff Johnson said (at 4:21pm on...: Why lusers want to resign package they have not created in first place: if they want signed package, well, they have to ask the vendor alongside the pub key - they have already paid anymore. So they can distribute it via their software distribution infrastructure. For example, Red Hat Satellite Server. Sounds like Red Hat Satellite Server, not rpm, is missing an essential tool, if resigning "LSB format" rpms from other vendor's is the usage case. I would agree that it's more pressing for Satellite to have this capability than it is for rpm5. I asked about it here because of the great segue that devzero provided, and because I knew that you would have a lot of useful info to provide on the problem, even if I didn't really expect that there would be any solution or workaround. I frankly agree with you: vendors using rpm 3.0.6 to do packaging in 2008 is just silly. Unfortunately, my experience with vendors and "vendor inertia" is that they're not going to change their ways and get the modern RPM religion any time soon. The Red Hat Satellite development team has been uniformly pleasant, helpful and responsive when people have asked questions about Satellite on the mailing list, but based on how long it's taking to get other critical features into the product, I don't see Satellite getting this support any time soon, if ever. Tim -- Tim Mooney[EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building(701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: strange RPMDB problem: messed up entries (regularily)
In regard to: Re: strange RPMDB problem: messed up entries (regularily),...: If/when I know how to reproduce the DB_PAGE_NOTFOUND issue I will most certainly take you up on the offer. Meanwhile, there's been a continuous stream of credible DB_PAGE_NOTFOUND failure reports from x86_64 (the real correlate is "64bit", there's a few ppc64 reports too) for years. That's one I've not seen on x86_64-sun-solaris2.10. I don't do very frequent queries of my RPM database, though. Maybe I should add a cron job to run a periodic query, and see if I can tickle the problem too. I'm still running rpm 4.4.9, but I've been thinking about upgrading this fall, after the initial craziness of the start of school subsides. Tim -- Tim Mooney [EMAIL PROTECTED] Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Eliminating internal zlib.
In regard to: Eliminating internal zlib., Jeff Johnson said (at 6:15pm on...: Should I rip out internal zlib on HEAD and rpm-5.1.4? Yes, please. Tim -- Tim Mooney [EMAIL PROTECTED] Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Converting *.spec to Makefiles
In regard to: Re: Converting *.spec to Makefiles, Jeff Johnson said (at...: make has the advantage that its universal, and one can take a Makefile and run it. That's probably true if you're talking about Linux, where every distribution uses some recent version of GNU Make. It's not as true when you consider other platforms like Solaris or HP-UX. I don't think it's necessarily true even for the BSD-derivatives, but I haven't looked at one in a while. I also think that there wouldn't be so many alternatives to "make" (cmake, smake, ant, etc.) if everyone agreed that it was the right solution to most build problems. autoconf + make works just great for my needs, but apparently not everyone agrees. That's not true with dialects of spec files. I support any effort you'll undertake to regularize spec files or provide an alternative, either of which hopefully will result in more cross-distribution interoperatiblity (I'm not convinced that will actually happen, but hope springs eternal, as they say). I have had very few experiences with ant, but I have to say that those experiences have so far left me hating it. Hopefully whatever comes out of this doesn't end up with 1000+ line XML files just to build the simplest package. Maybe something like http://bee.rubyforge.org/ would keep more within the existing YAML-ish syntax, while still allowing for a Real Language ? Oh good. Another competing build system. ;-) Tim -- Tim Mooney [EMAIL PROTECTED] Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: RPM DB, Berkley DB and journal files
In regard to: RPM DB, Berkley DB and journal files, Mark Hatle said (at...: I was hoping someone can help me understand what is happening and how to address it for our embedded system needs. For reference: http://bugzilla.pokylinux.org/show_bug.cgi?id=1174 from the above, the complaint is: When using zypper/rpm install/removal package, database files and log files cost a lot of disk space and may cause target image out of space. The first time when we use RPM, a lot of database files will be created, larger than 10MB. That's a separate issue from the logs. Does your platform support System V IPC? If so, have you considered using a shared memory key, instead of mmap(2)? That should completely remove several of the __db* files. On some platforms, it will also be significantly faster, too. --- Each of the __db.* files created are large. Nearly 10 MB each. In addition in the "log" directory are additional files that are also nearly 10 MB each. As Per suggested, you probably want to at least investigate automatic log file removal. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: R: Re: RPM DB, Berkley DB and journal files
In regard to: R: Re: RPM DB, Berkley DB and journal files, pinto.elia@gmail...: Perhaps OT, but just a my random thought about this thread about rpm5 and berkley DB. most of which is discussed here is very similar, or equal sometime, on similar question on openldap. Apparently strange but not so quite if someone think carefully at the rpm5 rpm acid feature. Just for Remainder my self, and Who is interested, that the rpm acid docu, not so much at this moment, need also on a tuning guide. Sound like a plan ? :-) It's funny you mention OpenLDAP, since most of what I've learned about BDB in the past year has been because of the work I did to upgrade my site's primary and secondary LDAP servers to OpenLDAP 2.4.25. OpenLDAP, being long-running and highly performance-sensitive, demands a lot more tuning of BDB than RPM does and not all of the same considerations will apply, but learning something about BDB for one of those two packages will still help with tuning the other. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: RPM DB, Berkley DB and journal files
In regard to: Re: RPM DB, Berkley DB and journal files, Jeff Johnson said...: Meanwhile: Do you agree that increasing mmap size is the most important performance related tunable? First, although I have indeed learned a lot about BDB from OpenLDAP, that still doesn't mean I know much. ;-) I went from knowing nothing about it to knowing just a little, and most of that specific to how OpenLDAP uses BDB. You're still the expert, not me. That said, if you're going to use mmap at all, then I trust you're correct about mmap size being the most important tunable. However, there has been considerable discussion on the OpenLDAP mailing list about how on certain platforms, using mmap for the BDB env is much, much slower than using System V IPC shared memory. For example, on Solaris using shared memory is an order of magnitude faster than using mmap for the env: http://www.openldap.org/lists/openldap-technical/201103/msg00069.html Howard Chu has also stated that IPC shared memory is also beginning to be a performance win (at least for OpenLDAP) on recent Linux kernels too, though I don't believe it's the order of magnitude difference you see elsewhere: http://www.openldap.org/lists/openldap-technical/201104/msg00150.html I can find more references to the issue with some more digging, but basically, for at least how OpenLDAP uses BDB, System V IPC can be a big win. That doesn't necessarily mean it's a good idea for RPM in general, or RPM on an embedded platform in particular. It would get rid of most of the __db* files that the original bug report mention, though. ;-) Possibly at the expense of making RPM not work at all on that platform. I've diddled most of the tunables at some point or another using rpm --stats as a measurement, and mmap'd I?O is/was the most important tunable (disabling sync cannot be done in "production" imho). Makes sense. Using RAM for the db env is always going to be faster than using disk. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: What should the contents of /etc/rpm/platform be ?
In regard to: What should the contents of /etc/rpm/platform be ?, Sriram...:
sriram@ram-oi:/usr/src/rpm/RPMS/i86pc$ uname -a
SunOS ram-oi 5.11 oi_147 i86pc i386 i86pc Solaris
sriram@ram-oi:/usr/src/rpm/RPMS/i86pc$ ls /usr/src/rpm/RPMS/i86pc/
autoconf-2.68-1.i86pc.rpm cmake-2.8.5-1.i86pc.rpm nginx-1.0.4-1.i86pc.rpm
axel-2.4-1.i86pc.rpm git-1.7.6-1.i86pc.rpmrepodata
I build some packages already. (I now install from rpm packages only).
rpm --eval "%{_arch}-%{_vendor}-%{_os}%{?_gnu}"
i386-pc-solaris
On my x86_64-sun-solaris2.10 workstation I have
02:46 PM dogbert ~$cat /etc/rpm/platform
x86_64-sun-solaris
x86_64-sun-solaris2.10
i686-sun-solaris
i686-*-solaris
i686-sun-solaris2.10
x86_64-[^-]*-solaris.*
noarch-[^-]*-.*
[^-]*-[^-]*-noos
Not all of those are relevant (or probably even valid...), but you get
the idea.
You may also want to consider overriding %_arch, %_vendor, and potentially
other platform-related macros in your host-specific RPM macros (probably
/etc/rpm/macros).
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
script for BuildRequires to graphviz?
All- Before I re-invent the (possibly simple) wheel, I have a vague recollection of seeing a script that can take a collection of spec files and build a directed graph from the BuildRequires, for graphing in something like graphviz. I'm not finding it right now, and Google isn't giving me what I want either. I can do it myself and share if need be, but if there's prior art, I would appreciate a pointer to it. Thanks! Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: script for BuildRequires to graphviz?
In regard to: Re: script for BuildRequires to graphviz?, Jeff Johnson said...: On Sep 15, 2011, at 1:23 PM, Jeff Johnson wrote: On Sep 15, 2011, at 12:43 PM, Tim Mooney wrote: All- Before I re-invent the (possibly simple) wheel, I have a vague recollection of seeing a script that can take a collection of spec files and build a directed graph from the BuildRequires, for graphing in something like graphviz. Yep. I can resurrect that tool (rpmgraph.c? I fergit) if interested. Dunno if you are using @rpm5.org or not. But there are two options --needswhat --whatneeds that look up towards the root of the dependency graph, or down into the sub-graph, displaying the packages found including all dependencies. I'm currently using rpm 5.1.9. Thanks for the heads-up on those two options. I wasn't aware of them. The man pages for rpmgraph are still part of the source from RPM, but rpmgraph.c appears to no longer be present. I think it was rpmgraph that I was remembering. I don't think there's anything that you need to do, especially since most of the options are designed to work with information from the database and operate upon Requires, and I'm more interested in starting with a heap of spec files and generating the graph for BuildRequires (not Requires). It should be pretty easy to script what I need, so I think I'll just go that route. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Requires: python(foo) = bar
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? All of these are python scripts are generating *.dot output. So one approach to better Requires: python(foo) = bar would be to write a parser for *.dot format (which is pretty damn trivial, even sed(1) is almost enough) to automagically generate better python module dependencies. I wrote a brain-dead BuildRequires dependency generator for all my local specs that generated a .dot file, but had real trouble getting graphviz to display it. I would love to know what options people are using with graphviz to get a reasonable display of 1800+ nodes, some of which have 50-100 edges connecting them. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Requires: python(foo) = bar
In regard to: Re: Requires: python(foo) = bar, Jeffrey Johnson said (at...: On May 11, 2012, at 2:46 PM, Tim Mooney wrote: 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. Specific questions: 1) Would rpm-ruby bindings be useful to you? Maybe some day, but at this point, not really. I don't actually want to interface with rpm from ruby (yet, and maybe not ever), I just want rpm to automatically figure out all the junk (module or gem) that is required when I rpm install something like rubygem-puppet-lint. 2) Are you doing DevOPS? I'd like to see a unification of configuration <-> package management, actually looked at puppet/chef/cfengine 6 weeks ago. Yes, that's what's driving ruby in our environment: puppet. cfengine would be easiest to link into RPM and has definite design strengths (i.e. I like "promises"). But clearly PUPPET! PUPPET! PUPPET! is the loudest chant from the Linux advocates everywhere. It does have tremendous momentum. It's changing a lot and is a serious moving target, though. A lot of what was done in our environment when our primary puppet advocate was beginning to deploy puppet here will need to be reworked considerably for the forthcoming puppet 3.0. Meanwhile I was underwhelmed with most of what I saw with DevOPS: simple tasks became hugely complex and there were no apparent complex tasks that the tools simplified enough to interest me. But that was merely a drive-by review of current state-of-the-art; I'm sure there are features/benefits that I entirely missed in all of the 3 DevOPS applications (2 in ruby) that I looked at. I'm hard pressed to say that you're wrong; There is a lot (I mean *a lot*) of work that needs to be invested up front to get any benefits out of devops. If there's much variation in one's environment (as there is in an academic environment like mine) that also adds a lot of complexity, and it's complexity that one isn't necessarily prepared to handle when they're initially rolling out something like puppet. The benefits start to become pretty significant once you have a good portion of your hosts included in your CM infrastructure. It's really nice to be able to make one change (like remove a sysadmin when he leaves) in one spot and have it automatically applied to your entire environment automatically. Or know that your entire web farm is configured identically *and* will be re-configured to be identical even if an admin makes a change "just for testing" on just one of the web servers, and then forgets to either undo or propagate it. It's no panacea, but once you get critical mass, the benefits do start to become much more apparent. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Requires: python(foo) = bar
In regard to: Re: Requires: python(foo) = bar, Jeffrey Johnson said (at...: Meanwhile the very ida of running multiple versions of ruby and modules out of a per-user shadow tree in ~/.rvm drove me to some serious drinking to forget what I saw ;-) Ruby, in general, has inspired beverage consumption in me. rpm-5.3.11 is "production", rpm-5.4.x will be rather active until mid-late summer preparing for ROSA 2012. I'll give 5.3.11 a whirl in a couple weeks. Thanks for the pointer. Using graphviz on Mac OS X (used to be very very nice, dunno if still actively distributed in *.dmg) and choosing PDF as a display was the _ONLY_ means I could find to handle large dependency graphs. I was hoping for PDF display, but that was a no-go for me on both Solaris 10 and Linux. The only option that actually worked at all was png, and it wasn't very usable. I still think a tree map rather than nodes <-> edges is a better easier to understand display format for "packages" because of the ability to map multiple attributes into size/color/adjacency/labels/shapes. At some point all you have is a huge snarly yarn ball with dotty. That's exactly what I had, and I was only tracking manually specified BuildRequires dependencies on my Solaris system. It was a mess... Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
patches for OpenIndiana/Solaris 11
Jeff, et. al. - I'm replacing my current x86_64-pc-solaris2.10 (traditional Solaris 10 from before Oracle bought Sun, 10u6 to be exact) build box with a new x86_64-pc-solaris2.11, which is actually OpenIndiana 151a8. The RPM 5.1.9 I've been using for packaging and installing local software on the Solaris 10 box continues to work just fine on the new OI box, but I'm planning on taking a run at current rpm (5.4.12?). Because I'm a glutton for punishment, I'll also be using the no-cost Oracle Studio 12.3 compiler toolchain. ;-) I plan on submitting build patches, but where would you like them submitted? Here? launchpad? As you well know, I'm a sysadmin that happens to be able to muddle around in C, not a developer, so I expect that any patches will need feedback and probably multiple revisions before they might be palatable to upstream. Some will likely never be acceptable for inclusion, but I'll submit them and let you sort them out. Be expecting to see some patches in the coming days. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: patches for OpenIndiana/Solaris 11
In regard to: Re: patches for OpenIndiana/Solaris 11, Jeffrey Johnson said...: I'm replacing my current x86_64-pc-solaris2.10 (traditional Solaris 10 from before Oracle bought Sun, 10u6 to be exact) build box with a new x86_64-pc-solaris2.11, which is actually OpenIndiana 151a8. Be expecting to see some patches in the coming days. Several procedural details that would help me immensely: 1) a devtool.conf stanza that indicates what build options you are (or wish) to use on OpenSolaris. That I think I can do. I'll try get something wired up. I've saved previous emails to the list about devtool going all the way back to when you and Ralf first implemented it, so I should have enough in the way of context and examples so I can come up with something useful. 2) hosting a build slave on OpenSolaris This I would like to do, but I'm not certain if I'll be able to. Since I work at a university I have a lot more flexibility than most, but OI is pretty niche even for us. We do however have some brand new VMWare infrastructure that's desperately in need of testing, so maybe if I position it that way... I'll let you know on the 2nd item, but don't hold your breath. If I *can't* get a buildbot going, I don't think you should spend any time trying to get one going just for continuous integration on OpenSolaris. If there was demand from some "significant" portion of the OS community for RPM, then sure. I do know that at least one OpenSolaris derivative uses rpm as its native package format, but I don't know how or if it's even active anymore. Other than that possibility, I don't think there's enough demand to justify your time trying to support it. I actually would be totally fine with you not incorporating any of the patches I may come up with; I'm submitting more so that they're on the public record in case any other sole is on the same path. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
OpenIndiana build environment for RPM
32
bit build is configured to search all the following places for .pc files:
--with-pc-path="/local/lib/pkgconfig:/local/gnu/lib/pkgconfig:/local/share/pkgconfig:/local/gnu/share/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig"
while the 64 bit pkgconfig (that gets installed in /local/bin/64) is
configured with
--with-pc-path="/local/lib/64/pkgconfig:/local/gnu/lib/64/pkgconfig:/local/share/pkgconfig:/local/gnu/share/pkgconfig:/usr/lib/64/pkgconfig:/usr/share/pkgconfig"
Because I'm primarily interested in 64 bit builds but it's occasionally
useful to also have 32 bit libraries, the scripts I used build and install
the package twice, once with options for 32 bit and the second time with
options (and paths, like --bindir=/bin/64
--libdir=/lib/64) suitable for 64 bit compilation.
Devtool setup
=
I started with the %indiana devtool.conf entry and created
%oi151a8_studio_64 from it, with settings suitable for using the Studio
compiler to build in 64 bit mode. I also switched "neon" and "beecrypt"
to be "external", and enabled xz and libelf.
I just recently got that entry to the point where RPM will autogen and
run configure to completion, so consider it a work-in-progress. In
particular, I haven't been able to correctly tailor which additional
modules are checked out for building internal to RPM, so I'm currently
using a horrible hack to do the normal %checkout, and then remove
the directories for beecrypt and neon. I also used examples from
elsewhere in devtool.conf to check to make certain that necessary OS
packages are installed and automatically install them if not.
The devtool.conf patch (against current CVS) is after my signature. With
it and the other steps I've describe above, I can get RPM's configure
to complete. I'll be working on the remaining build issues as time permits.
Feedback welcomed!
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
Index: devtool.conf
===
RCS file: /v/rpm/cvs/rpm/devtool.conf,v
retrieving revision 2.382
diff -u -r2.382 devtool.conf
--- devtool.conf6 Apr 2012 10:22:04 - 2.382
+++ devtool.conf17 Oct 2013 21:21:44 -
@@ -1243,6 +1243,152 @@
--enable-build-debug \
--enable-maintainer-mode
+%oi151a8_pkg_prep
+ #
+ # Make certain we have the necessary OS distribution packages
+ # installed.
+ #
+ PKGS=""
+ if test ! -f /usr/include/pthread.h ; then
+ PKGS="$PKGS /system/header"
+ fi
+ if test ! -f /usr/include/math.h ; then
+ PKGS="$PKGS /system/library/math/header-math"
+ fi
+ if test ! -x /usr/bin/ld ; then
+ PKGS="$PKGS /developer/linker"
+ fi
+ if test ! -f /usr/lib/values-xpg6.o ; then
+ PKGS="$PKGS /developer/library/lint"
+ fi
+ if test ! -f /usr/lib/cpp ; then
+ PKGS="$PKGS /developer/macro/cpp"
+ fi
+ if test ! -x /usr/gnu/bin/make ; then
+ PKGS="$PKGS /developer/build/gnu-make"
+ fi
+ if test ! -x /usr/gnu/bin/m4; then
+ PKGS="$PKGS /developer/macros/gnu-m4"
+ fi
+ if test ! -x /usr/bin/cvs; then
+ PKGS="$PKGS /developer/versioning/cvs"
+ fi
+ # if PKGS isn't empty, loop and install
+ if test X"$PKGS" != X"" ; then
+ for p in $PKGS
+ do
+ sudo pkg install $p
+ done
+ fi
+
+# OpenIndiana 151a8 on x86_64 with the Oracle Studio 12.x compiler
+%oi151a8_studio_64
+ %oi151a8_pkg_prep
+ %checkout
+ rm -rf neon popt
+ #
+ # set this to where local packages are installed, both RPM pre-reqs
+ # (autoconf, automake, libtool, gettext, neon, beecrypt) and where
+ # rpm will be installed.
+ #
+ LOCAL=/usr/local
+ #
+ # if GNU software is installed in a directory that's separate from other
+ # local software, specify the prefix here. Otherwise, just set
+ # GNU=${LOCAL}
+ #
+ GNU=/usr/local/gnu
+ #
+ # where the Oracle Studio tar file is extracted. You must install
+ # this manually.
+ #
+ STUDIO=/opt/SUNWspro
+ #
+ # environment setup for building RPM.
+ #
+ PATH=${STUDIO}/bin:${LOCAL}/bin/64:${LOCAL}/bin:${GNU}/bin/64:${GNU}/bin
+ PATH=$PATH:/usr/gnu/bin/64:/usr/gnu/bin:/usr/bin/64:/usr/bin:/usr/sbin
+ export PATH
+ CC='
Re: [CVS] RPM: rpm-5_4: rpm/scripts/ vpkg-provides2.sh
In regard to: Re: [CVS] RPM: rpm-5_4: rpm/scripts/ vpkg-provides2.sh,...: The aim is to modernize a little these shells. The comment should be clear. Why? Was there something broken that you've fixed? Because the change you've made actually makes them less portable. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_4: rpm/scripts/ vpkg-provides2.sh
In regard to: Re: [CVS] RPM: rpm-5_4: rpm/scripts/ vpkg-provides2.sh,...: Certainly lots of the scripts could use an overhaul. Most shells SHOULD be POSIX compliant: but I will defer to Tim's opinion on portability, there may still be some ancient shells in use somewhere. I no longer have access to many of the UNIX variants we used to use, but even Solaris 10 had a /bin/sh that was more traditional Bourne than POSIX. And for Pinto's benefit, specifically related to the vpkg-provides script: that script is really targeted at *non*-Linux, so portability to older variants of /bin/sh is important. No one needs vpkg-provides on an RPM-based system, but it might save the day on an AIX or Solaris system where you're trying to bootstrap RPM. Keep in mind that even older versions of the UNIX variants often had a POSIX shell stashed somewhere (like /usr/xpg4/bin/sh on Solaris 8 or 9), but it wasn't the default shell and a lot of newer admins wouldn't know of its existence. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
