Re: rpm fatal error on osx el capitan
Jacques Knipper wrote:
> Indeed I'm talking about v5.4.15.
> I didn't try with the --rpmdbdebug yet but I will, thanks.
> The problem happen with every rpm.
> I am able to rebuild our rpms with the rpmbuild, but I cannot install them,
> an I think it's because of an issue with Berkeley DB.
FWIW, the issue was reproducible on Mavericks too. You need to install
something to see it, though...
So the default test case a) looks a bit broken and b) doesn't actually test
installing and erasing ?
%_topdir#{testpath}/var/lib/rpm
I think it is something with the (lack of) configuration, that is getting the
rpmdb in a sad state.
--anders__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org
Re: rpm fatal error on osx el capitan
Jacques Knipper wrote: > I already know that brew and rpm are not officially supported on latest > version of osx for now... Whatever official support is, I don't think it is happening on *any* version of OS X. But that particular system version is not even released yet, for another week or so... > I noticed when I installed rpm with brew that rpm is suffixed with > "_el_capitan_bottle", so I allow myself to ask you about an issue I'm facing, > maybe someone is working on it :) Can't say I have any plans to work on it. But the homebrew build is pretty standard, so it should be more or less the same as just building it from release (5.4.15) ? > When we tried to install any rpm with "sudo rpm -ivh ...", the command crash > with an error "error: db3cput:db3.c:1461: dbcursor->put(-30973): BDB0087 > DB_RUNRECOVERY: Fatal error, run database recovery". > > I tried to remove any db files and run rebuilddb but that's not better... Sounds like you have a problem with Berkeley DB ? It seems that you (i.e. brew) is using version 6.1.26. You can also run with additional -v flags, to get some more debugging information. And also --rpmdbdebug. > We also tried to install both of rpm and berkeley-db in debug to step in, but > we do not find any relevant information that help us to get out of this bad > situation... Seems like you didn't get far enough to really create a situation, if the first rpm installation crashed on you ? > Have you any idea why we are able to install all the stuff but not using it? Depends on what you are trying to use it for. Did you plan on doing anything else, after unpacking with brew ? I think the only scenario being tested by the build bot, is being able to make an .rpm and possibly to inspect an empty db: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/rpm.rb#L108 A more extensive test, like installing and erasing packages is probably a good idea - *if* one is planning to use rpm for that... Seems like my /var/lib/rpmbuild hack didn't even make it to the next commit (f386026) --anders
Re: uninstalling old RPM 5.1 from Mac
Nicholas Chubrich wrote: From lsbom it looks like there were some things in /private once, but no more. The Python packages are also gone. The Perl package is still there, and I wonder if I should leave it alone or get rid of it (would there be any non-RPM dependencies it might break?). And then once done should I delete /Library/Receipts/RPM5.pkg itself? You can leave them be (they're rather small anyway), or delete them... Anything actually trying to use the Perl module needs it working anyway, and the receipt is just that - a record of what pkg had been installed. I already followed the previous poster's advice, so I have already (mostly) removed RPM. It was so broken there was no way of querying what was installed anyway. A spotlight search for .rpm files has not turned up anything. It looks like you only installed RPM itself, but not any RPMS with it ? (I did all this because brew doctor complained about the rpm files in /usr/local.) The complaints are valid, anything in /usr/local will affect the system: Warning: Unbrewed dylibs were found in /usr/local/lib. If you didn't put them there on purpose they could cause problems when building Homebrew formulae, and may need to be deleted. Warning: Unbrewed .la files were found in /usr/local/lib. If you didn't put them there on purpose they could cause problems when building Homebrew formulae, and may need to be deleted. Warning: Unbrewed .pc files were found in /usr/local/lib/pkgconfig. If you didn't put them there on purpose they could cause problems when building Homebrew formulae, and may need to be deleted. Warning: Unbrewed static libraries were found in /usr/local/lib. If you didn't put them there on purpose they could cause problems when building Homebrew formulae, and may need to be deleted. For some reason it doesn't whine about /usr/local/include, but that will also affect anything you compile as it's in the default paths. This also means that if you do install your Homebrew to /usr/local, it will interfere with anything else - including MacPorts and Fink. Because of this, many systems avoid using /usr or /usr/local prefix. The mono installation was there, I think, because of Wine, but Wine is gone because it was in a broken Macports installation (all these things seem to break when the transfer to a new laptop happens). MacPorts installs in /opt/local normally, so this would be different. The Mono.framework usually sets up a symlink as /usr/bin/pkg-config, but the provided pkg-config program's PKG_CONFIG_PATH only shows itself. If you know any good web sites that explain Mac software installation (the pkg system, what all the various directories /usr/local, /private, etc. are for), I'd love to hear about it. The pkg system is provided by Apple with Mac OS X, so look there for it. The associated programs are: Installer.app and Xcode's PackageMaker.app. The /private directory is a top-level storage of /etc and /tmp and /var. It needed to be stated explicitly in .pkg, because of Installer.app bugs. If you want to know more about /usr/local (and /usr and /var), you could take a look at the man page for hier(7) or learn more about BSD and Unix. Not sure there's any good summary site with all different distributions, comparing MacPorts, Fink and Homebrew and the other means of installation. For RPM, there's max-rpm and the rpm-guide ? (http://rpm5.org/docs.php) The Darwin installer used to live at http://rpm4darwin.sourceforge.net/ The latest pkg version was RPM 5.2 for Snow Leopard, after that it moved to just using MacPorts. One could install RPM 5.3 and 5.4 (with devtool). There was some discussion recently about doing an updated distribution, but for now there's some (non-rpm) pkg at http://macpkg.sourceforge.net/ --anders __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Requires/Provides
Rick Miller wrote: But even with all the patching, the only yum use is for handling RPM packages for Linux on FreeBSD (like for the linux emulator). It has too many hardcoded assumptions to work for native packages. There is no real interest in having it portable to other systems. I left something out when I explained that we were trying to build Yum. We are looking to install RPM and Yum and use those to manage our homegrown software and packages on FreeBSD. We're not looking to manage anything other than our own software and applicable dependancies. That is a perfectly reasonable usage scenario, just not sure about yum. But just because it isn't supported doesn't mean that it won't work. Having said that, do you believe that portability will continue to be an issue under these circumstances? I haven't looked at the later versions, than rpm-5.2.1 and yum-3.2.29. But yum used to have all kinds of assumptions coded in, like the use of /usr/bin/python and not allowing prefix. Or using redhat-release. And as far as I know, yum still declares conflicts on rpm5 and zif... Should take a look at the later yum code, see how much it would take ? A slight problem is that nobody is maintaining the python at rpm5.org. --anders __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Requires/Provides
Rick Miller wrote: What version of RPM? I *think* its 5.2.x, but not 100% sure. I don't have access to the host today and can let you know tomorrow. It was installed from the FreeBSD ports collection for 8.2-RELEASE. That would be 5.2.1. http://www.freebsd.org/cgi/cvsweb.cgi/ports/archivers/rpm5/ (aside) The RPM I am trying to build is yum. I suspect that I may hit a number of snags with the yum.spec as I try to get an RPM built for FreeBSD. This happens to be the first. Using the yum.spec from Fedora on FreeBSD won't work, and is probably the least of your problems compared with portability. A yum port is available, and it required *lots* of patching: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/150541 But even with all the patching, the only yum use is for handling RPM packages for Linux on FreeBSD (like for the linux emulator). It has too many hardcoded assumptions to work for native packages. There is no real interest in having it portable to other systems. It was mistakenly submitted* as a dependency of createrepo-0.9.8, but it would have been better to use createrepo-0.4.11 instead... (* as per http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/150542) At one point, there was even a port of mock for use in linux-base: http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/linux_base-f10/ (currently it has a long hardcoded list of rpms, and uses rpm2cpio) --anders __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: rpm on OSX Lion
Jeffrey Johnson:
[...]
The .src.rpm format is somewhat troublesome to port, but bundled
rpm2cpio.sh and extracted the tarball in a post-extract {} step.
[...]
But if it gets to be too big a hassle, I'll pop out the tar ball and included
detached signature whenever you wish.
Basically it's only troublesome because there is no built-in support
for the .src.rpm format, while there is for the .tar.gz. format...
But it was not a big deal to add it, to the extract phase:
extract.suffix .src.rpm
extract.cmd ${filespath}/rpm2cpio.sh
extract.pre_args
extract.post_args | cpio -dvim
post-extract {
system -W ${workpath} ${portutil::autoconf::tar_command} -xzf
rpm-${version}.tar.gz
}
So for MacPorts it can remain in that format, if you prefer.
--anders__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org
Re: rpm on OSX Lion
Henri Gomez wrote:
Hi to all,
I success in building rpm 5.4.7 on OSX (from tarball)
First step was to build and install bee crypt 4.2.1, popt 1.1.6,
db-5.3.15, sqlite 3.7.11, pcre 8.30, zlib 1.2.6 libraries under
/usr/local (nothing in)
Great! The only thing I added after that was possibly
redoing everything as .src.rpm for bootstrapping, and
making a .pkg for easier first-time user installation...
You don't need any .dmg, if making packages for 10.5
and beyond - they were only needed for 10.4 and earlier.
(since the newer flatten their directories, into xar)
Question :
What should I do now, I noticed a cpu-os-macros.tar.gz bundled in
source RPM but not macros available for OSX inside.
Build some software, probably. That is, try some .spec
files and see if it actually works and is useful to you.
Historically, the macros were where vendors added value.
You can find my macros in devtool.conf (for rpm-5.2),
if you want to use them. Probably won't need PowerPC,
when only targeting Mac OS X 10.7 and later anyway ?
for ARCH in ppc i386 ppc64 x86_64; do
if [ $ARCH = ppc64 -o $ARCH = x86_64 ]; then BITS=-m64; else
BITS=-m32; fi
mkdir -p /tmp/rpm-root/usr/local/lib/rpm/$ARCH-darwin
sed -e s/^%/%/ __EOF__
/tmp/rpm-root/usr/local/lib/rpm/$ARCH-darwin/macros
# Per-platform rpm configuration file.
#==
# per-platform macros.
#
\%_arch $ARCH
\%_build_arch $ARCH
\%_vendor apple
\%_os darwin
\%_gnu %{nil}
\%_target_platform %{_target_cpu}-%{_vendor}-%{_target_os}
\%optflags -O2 $BITS
__EOF__
done
perl -pi -e
s/^\%_arch.*/\%_arch\t\t\tfat/g;s/^\%_build_arch.*/\%_build_arch\t\tfat/g \
/tmp/rpm-root/usr/local/lib/rpm/macros
perl -pi -e s/^(\%optflags)(\s+)(.*)/\$1\$2\$3 -arch i386 -arch ppc/g \
/tmp/rpm-root/usr/local/lib/rpm/macros
Basically I wanted to build 32-bit for i386/ppc and
64-bit for x86_64/ppc64, and default to fat arch
(which was i386 + ppc, probably x86_64 + i386 now ?)
Didn't use the -g flag, since brp-strip isn't enabled.
(rpm would normally/ELF put the debuginfo into separate
packages, and then strip debugging from the output...)
--anders
__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org
Re: rpm on OSX Lion
Henri Gomez wrote: Not sure what you ask here: you want a rpm-mac mailing list? Nope, I just want to see if there is other guys interested with RPM on OSX. Frankly, I'm borred to rebuild Brew/MacPorts stuff and I'm not alone. I just want to be able to set a package repository and use yum or zypper to get stuff downloaded and installed. Seems your next task is porting either yum or zypper, then. Presumably your repository needs some kind of indexing ? Or are you referring to Anders (who knows way more about RPM on Mac OS X than anyone else, with many other skills ;-) If there is a RPM DMG available right now for Snow and Lion, with a stable RPM, I'll be happy to use it. There is a .pkg for Snow Leopard, but it was using RPM 5.2. Better to offer a new one, if you have rebuilt everything ? Then we could works on building a community for RPMs production :) Probably the best idea, as you won't know until you've tried. Anders is part of the @rpm5.org project: maintains the MacPorts and FreeBSD ports, smart guy too ;-) It seems to be the 'OSX/RPM guru' so willing to heard more from him :) I'm here, but might as well start over than reuse the old... --anders __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: RPM Stub Package
Miller, Vincent (Rick) wrote:
Hi Anders,
I installed sysutils/file and received an error message indicating that
file 5.3 supports only version 7 magic files and that the one installed
was version 8. Perhaps this is the reason that RPM 5.2.1 did not install
sysutils/file?
You'll need to make sure that both the path and the linkage are
pointing to the same installation of file/magic. That is, either
you need to change the rpm macro (%_rpmfc_magic_path) to point to
the system version that the built rpm port has somehow linked to,
/or/
you install sysutils/file and rebuild your rpm port to link to
/usr/local/lib/libmagic.so.1 instead of /usr/lib/libmagic.so.4.
The important part is that the magic file is from the *same*
installation of file as the magic library (i.e. same version).
The easiest change to packaging might be to include the minor:
magic.1:${PORTSDIR}/sysutils/file
That way it will always use the ports version instead of system...
Installing a static version of file would only add to the problem.
But I'm not sure the package really *is* broken ? The one I see
links OK to libmagic.so.1, rather than using e.g. libmagic.so.4 ?
(which isn't really a big problem in itself, other than that the
rpm configuration needs to be updated to match the binaries...)
ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8.2-release/Latest/rpm5.tbz
$ ldd /usr/local/bin/rpm | grep libmagic.so
libmagic.so.1 = /usr/local/lib/libmagic.so.1 (0x80185e000)
$ /usr/local/bin/rpm --eval %_rpmfc_magic_path
/usr/local/share/file/magic
--anders
__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org
Re: RPM5 on FreeBSD: hto* functions
Miller, Vincent (Rick) wrote: The BSD and Mac ports are currently using 5.2.1, that is the pre-ACID RPM: http://www.freebsd.org/cgi/cvsweb.cgi/ports/archivers/rpm5/ https://trac.macports.org/browser/trunk/dports/sysutils/rpm52/ I would be happy with the FreeBSD port of RPM. I did do an install of it and it did not install the rpmbuild binary. This was one of the main reasons for downloading and installing from source... Unlike the Debian package, the FreeBSD port *does* install the rpmbuild binary. If building from the source port fail, you can use the binary package (for instance portinstall archivers/rpm5): ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8.2-release/archivers/rpm-5.2.1.tbz Perhaps I'll setup another VM and give the FreeBSD port another try... It should build using devtool too, just that it has likely bit-rotted a bit since (even if HEAD was dusted off, earlier) And the standalone version isn't operational anymore either, so you will need to install some pre-requisite ports first... --anders __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: RPM5 on FreeBSD: hto* functions
I would be happy with the FreeBSD port of RPM. I did do an install of it and it did not install the rpmbuild binary. This was one of the main reasons for downloading and installing from source... Unlike the Debian package, the FreeBSD port *does* install the rpmbuild binary. [...] My bad, the Debian package does include the rpmbuild binary even if it doesn't allow installing using rpm (by default). --anders __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: rpm errors upon running
Miller, Vincent (Rick) wrote:
I had not loaded berkely-db because I thought I had read somewhere that there
was a bundled berkley-db with RPM5. I have since loaded Berkley-DB 5.1.x
from FreeBSD ports and was able to get the compile to move along further.
There used to be a bundled version, but now you use the regular BerkeleyDB.
You'll need to add the matching flags, like
CPPFLAGS+=-I${LOCALBASE}/include/db51 and LDFLAGS+=-L${LOCALBASE}/lib/db51
It failed later when attempting to link against libgomp which is not
installed on the system. I am planning to reconfigure disabling OpenMP,
unless it provides a feature we might be able to utilize. Can you clarify
the features OpenMP provides to RPM5?
You can use --disable-openmp, if you don't want OpenMP. The main issue with
multi-processing is that you'll need to enable it everywhere, if you use it for
something like BeeCrypt (where it increases performance)
--anders
__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org
Re: RPM5 on FreeBSD: hto* functions
Miller, Vincent (Rick) wrote: I'm compiling RPM 5.3.11 on FreeBSD 8.2-RELEASE and encountered an error that is more fundamental than previous errors. dbconvert.c makes calls to various hto*() functions, which are not defined in FreeBSD's libc. See http://rpm5.org/cvs/chngview?cn=16081 for patch, you can backport that to the rpm-5_3 branch. Why is the compiler unable to reference the bswap32 definition in sys/endian.h? Is there a way to force this or is this a sign that installing RPM5 onto FreeBSD will be more of a pain than I had initially anticipated? Maybe the dbconvert.c #define for bswap32 is colliding with it ? RPM5 should install on FreeBSD... That is: HEAD should be working, I don't think anyone has backported to 5.3.x or 5.4.x due to lack of interest... Most users are on 5.0 - 5.2, if there's indeed any usage on FreeBSD whatsoever (except for archiving). The BSD and Mac ports are currently using 5.2.1, that is the pre-ACID RPM: http://www.freebsd.org/cgi/cvsweb.cgi/ports/archivers/rpm5/ https://trac.macports.org/browser/trunk/dports/sysutils/rpm52/ --anders __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Attempting to compile rpm5 for RH Linux EL5
Saravanan Shanmugham (sarvi) wrote: I pulled xar 1.5.2 from the RPM5, applied the xar 1.5.2.patch. And tried compiling it. ... lib/libxar.a(archive.static.o)(.text+0x2c5d): In function `xar_unserialize': lib/archive.c:1346: undefined reference to `xmlDictCleanup' Your libxml2 is too old (happens a lot on EL5, the too old part) See http://rpm5.org/cvs/filediff?f=xar/lib/archive.cv1=1.8v2=1.9 --anders __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: RPM5 and YML-like Specfiles
Eric MSP Veith wrote: I've been trying to adopt this to my own projects. (I actually just began re-formatting my old specfiles.) What I found out is that it really works in the script parts, a thing that broke the spec file parser before. However, the description part still doesn't seem to get it, or I am making mistakes. When I write something like: %description This is some indented text for this package. It shouldn't look like this when using rpm -qi PKG. The description is indented, too, when I run rpm -qi PKG. While I understand that there's no good way to have YML-like indentation *and* preserve text formatting that might have been done in the description part, I long for a real YML-ish look of my spec files. :-) I think indenting the description could be perceived as a feature, at least I know that OpenPKG was doing this in RPM 4.2.1 as well... If I understand the issue correctly, you *don't* want the indentation stored in the package ? (like it is not being stored for other parts) --anders __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: Spec file help
Eric MSP Veith wrote:
Otherwise one would expect it to work on a basic rpm5.org install,
such as the one (devtool macosx) where I tried it and failed... :-)
Well, I'm not quite clear how this is handled on the list. Jeff on
some
pourposes wrote that this or that is a vendor-specific decision,
leaving me
with the impression that to create a proper or complete build
system a
distributor has to get his hands dirty and create a set of macros
for his
build system.
Yeah, there are few such distributors mentioned in the VENDORS file...
Still, macros such as %{__makeinstall} could very well go upstream ?
But if you have ideas, do bring them up here or on the rpm-devel
list -
maybe they would be useful for everyone and could be included
upstream ?
What about provided a nicely formatted example spec file or spec file
template that could be packed with RPM as additional documentation?
Sure, sounds like a good idea... Someone was doing a packaging of the
LFS bootstrap set as RPM specs, but doesn't seem to have followed
through.
--anders
__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org
