Re: rpm on OSX Lion
On Mar 28, 2012, at 12:50 AM, Henri Gomez wrote: I removed everything in /usr/local and changed PATH to hide contents in /opt/local Good. So question about pcre used with --with-pcre=Internal is still opened. I cannot diagnose your error until you add --miredebug. There are 2 plausible causes: 1) you are using a macro in Version: in your maven.spec 2) you build with pcre isn't correct somehow. Since rpm-5.4.7 runs fine on Lion (for me), and there are many dialects in use for *.spec in Mandriva, I'm almost certain 2) is the answer. But I need to see --miredebug output in order to confirm. Otool reported a shared lib pcre in /usr/local/lib OK. Using Internal change pcre func name isnt'it ? Instead go guessing, I'd rather place friendly wagers. What odds would you like on the testable hypothesis The internally changed pcreposix name disambiguation isn't functional. I can/will give you good odds (before you looksto see whether pcre_regcomp is actually a defined symbol in librpmmisc.a ;-) hth 73 de Jeff ' __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: rpm on OSX Lion
In make install I noticed : bin/sh ../../libtool --tag=CC --mode=link /usr/bin/clang -pipe -O2 -arch i386 -arch x86_64 -D_GNU_SOURCE -D_REENTRANT -L/usr/local/lib -arch i386 -arch x86_64 -Wl,-search_paths_first -o update update.o ../../rpmio/librpmio.la ../../misc/librpmmisc.la -L/usr/local/lib -lintl -liconv -lc -R/usr/local/lib -Wl,-framework -Wl,CoreFoundation -ldb-5.3 -lbeecrypt -lbz2 -lz -lpopt -lpthread libtool: link: /usr/bin/clang -pipe -O2 -arch i386 -arch x86_64 -D_GNU_SOURCE -D_REENTRANT -arch i386 -arch x86_64 -Wl,-search_paths_first -o .libs/update update.o -Wl,-framework -Wl,CoreFoundation -L/usr/local/lib ../../rpmio/.libs/librpmio.dylib -lm ../../misc/.libs/librpmmisc.dylib -L../pcre /Users/henri/Downloads/rpm-5.4.7/pcre/.libs/libpcreposix.dylib /Users/henri/Downloads/rpm-5.4.7/pcre/.libs/libpcre.dylib /usr/local/lib/libintl.dylib -lc /usr/local/lib/libdb-5.3.dylib /usr/local/lib/libbeecrypt.dylib -lbz2 -lz /usr/local/lib/libpopt.dylib -liconv -lpthread ld: warning: directory not found for option '-L../pcre' ld: warning: directory not found for option '-L../pcre' make[3]: Nothing to be done for `install-exec-am'. make[3]: Nothing to be done for `install-data-am'. pcre directory exist under rpm-5.4.7, why ../pcre error ? 2012/3/28 Henri Gomez henri.go...@gmail.com: I removed everything in /usr/local and changed PATH to hide contents in /opt/local So question about pcre used with --with-pcre=Internal is still opened. Otool reported a shared lib pcre in /usr/local/lib Using Internal change pcre func name isnt'it ? Le 28 mars 2012 à 00:32, Jeffrey Johnson n3...@me.com a écrit : On Mar 27, 2012, at 6:17 PM, Henri Gomez wrote: This error looks moderately serious (you can comment out the patterns in macros/* if you must: but pattern matching looks fubar): error: ^[A-Za-z0-9+._]+$: regexec failed: regexec() failed to match(1) Because -lpcreposix and the system regexec(3) routines have identical symbols, there's a high risk of collision. I've re-added --with-pcre=internal in order to avoid some issues on RHEL6. I'm rebuilding rpm 5.4.7 (not from cvs) with --with-pcre=internal Studying devtool.conf I could see for Lion : %falmouth %autogen %configure \ --verbose \ --prefix=/opt/local \ --enable-shared \ --with-db \ --with-dbsql \ --without-db-tools-integrated \ --with-zlib \ --with-bzip2 \ --with-xz \ --with-file \ --with-path-magic=/opt/local/share/misc/magic \ --with-lua=internal \ --with-tcl \ --without-sqlite \ --with-syck=internal \ --with-readline \ --with-augeas \ --with-beecrypt=internal \ --without-java \ --with-openssl \ --with-nss \ --with-gcrypt \ --with-tomcrypt \ --without-tpm \ --with-libtasn1 \ --without-pakchois \ --without-gnutls \ --with-neon=external \ --without-libproxy \ --with-expat \ --with-pcre=internal \ --enable-utf \ --with-uuid=/opt/local/lib:/opt/local/include/ossp \ --without-attr \ --without-acl \ --with-xar=/opt/local/lib:/opt/local/include/xar \ --with-popt=internal \ --without-keyutils \ --with-pthreads \ --without-libelf \ --with-cudf \ --without-ficl \ --without-aterm \ --without-nix \ --without-bash \ --without-rc \ --without-js \ --without-gpsee \ --with-python=system \ --with-pythonembed=/usr/lib:/usr/include/python2.7 \ --without-perl \ --without-perl-urpm \ --without-perlembed \ --with-ruby=/opt/local/lib/ruby/1.8 \ --without-selinux \ --without-sepol \ --without-semanage \ --without-libgit2 \ --without-squirrel \ --with-installed-readline \ --with-valgrind \ --disable-openmp \ --enable-build-warnings \ --enable-build-debug \ --enable-maintainer-mode Did you use macports libraries ? Yes: bog-standard MacPorts at --prefix=/opt/local found by RPM_CHECK_LIB() used in ./configure. What could you suggest for 100% MacPorts Free build ? Well that usually means Choose a Newer! Better! Bestest! value for --prefix!!! I would _NOT_ suggest defaulting to --prefix=/usr/local because that ends up in compiler search paths and there's already 2-3 choices for prefixes that are dueling for supremacy on Mac OS X (fink/macports/homebrew) Personally I like --prefix=/usr which (if everything is done careful;y) isn't likely to collide with Apple warez any time soon. standalone mode ? That's another approach, but a bit more complex because of the need to script everything into devtool.conf (which can/will get tedious because of the complexity of RPM's builds). I'm personally just working out of the tests/ sub-directory in a RPM checkout. All *.src.rpm's copied
Re: rpm on OSX Lion
On Mar 26, 2012, at 10:49 AM, 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) Good. Careful about sqlite, its rather tricky. Preferred is building/using the sqlite layer in Berkeley DB (which is exactly sqlite with a Berkeley DB storage). For configure I forced dual arch : ./configure --prefix=/usr/local CC=/usr/bin/clang 'CFLAGS=-pipe -O2 -arch x86_64' 'LDFLAGS=-L/usr/local/lib -arch x86_64' CPPFLAGS=-I/usr/local/include CXX=/usr/bin/clang++ 'CXXFLAGS=-pipe -O2 -arch x86_64' For beecrypt, I disabled some options with : --disable-openmp --without-cplusplus --without-java --without-python Yes OpenMP is problematic on Mac OS X because of LLVM != GCC. You might want to look at --with-java: it was rather nice. rpm is only using system or prebuilt libraries : otool -L /usr/local/bin/rpm /usr/local/bin/rpm: /usr/local/lib/librpmbuild-5.4.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/local/lib/librpm-5.4.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/local/lib/librpmdb-5.4.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/local/lib/librpmio-5.4.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/local/lib/librpmmisc-5.4.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) /usr/local/lib/libpcreposix.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/local/lib/libdb-5.3.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/local/lib/libbeecrypt.7.dylib (compatibility version 8.0.0, current version 8.0.0) /usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5) /usr/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.6) /usr/local/lib/libpopt.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/local/lib/libpcre.1.dylib (compatibility version 2.0.0, current version 2.0.0) You likely should add neon to that mix. 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. The very first thing you should do is cd tests make -k clean test and examine that output for serious flaws. The cpu-os-macros.tar.gz is likely of little use on Mac OS X: what is inside is the thundering herd of platforms that RPM used to attempt to provide a default configuration for. There's too many dialects from distro vendors for any one-size-fits-all default RPM configuration. hth 73 de Jeff Cheers __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: rpm on OSX Lion
Good. Careful about sqlite, its rather tricky. Preferred is building/using the sqlite layer in Berkeley DB (which is exactly sqlite with a Berkeley DB storage). How can I select such preferred building ? Yes OpenMP is problematic on Mac OS X because of LLVM != GCC. You might want to look at --with-java: it was rather nice. --with-java should be done or output silly messages ? :) You likely should add neon to that mix. i'll do 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. The very first thing you should do is cd tests make -k clean test and examine that output for serious flaws. test running, nothing weird for now The cpu-os-macros.tar.gz is likely of little use on Mac OS X: what is inside is the thundering herd of platforms that RPM used to attempt to provide a default configuration for. There's too many dialects from distro vendors for any one-size-fits-all default RPM configuration. Any suggested macros for OSX ? May be provided by some OSX user in mailing list ? __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: rpm on OSX Lion
But see the options use when db-5.3.15 is built. This
is what I use to build Berkely DB on Mac OS X (after
creating a build_macosx directory to build in)
===
#!/bin/sh
prefix=/opt/local
configure_cmd=../dist/configure
configure_args=
--prefix=${prefix}
--enable-cxx
--enable-java
--enable-sql
--includedir=${prefix}/include/db53
--libdir=${prefix}/lib/db53
--program-transform-name=s,^db,db53,
--enable-tcl
--with-tcl=${prefix}/lib
$configure_cmd $configure_args
===
Ok, I'll compare.
BeeCrypt was heavily used in Java long ago: dunno if still useful.
RPM doesn't need/use.
So no need for me to support Java for bee crypt :)
Any suggested macros for OSX ?
OSX has a fat architecture that is essentially the same as noarch.
EVeryone invents new names and the diversity just confuses.
True ;(
The default macros SHOULD be gud enuf on Mac OS X.
Perfect
Anders Bjorkland's Mac OS X distro based on RPM is still likely
the best around.
This one (http://www.algonet.se/~afb/rpm/) ?
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.
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.
Then we could works on building a community for RPMs production :)
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 :)
__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org
Re: rpm on OSX Lion
BTW, I attached tests results :
2012/3/26 Henri Gomez henri.go...@gmail.com:
But see the options use when db-5.3.15 is built. This
is what I use to build Berkely DB on Mac OS X (after
creating a build_macosx directory to build in)
===
#!/bin/sh
prefix=/opt/local
configure_cmd=../dist/configure
configure_args=
--prefix=${prefix}
--enable-cxx
--enable-java
--enable-sql
--includedir=${prefix}/include/db53
--libdir=${prefix}/lib/db53
--program-transform-name=s,^db,db53,
--enable-tcl
--with-tcl=${prefix}/lib
$configure_cmd $configure_args
===
Ok, I'll compare.
BeeCrypt was heavily used in Java long ago: dunno if still useful.
RPM doesn't need/use.
So no need for me to support Java for bee crypt :)
Any suggested macros for OSX ?
OSX has a fat architecture that is essentially the same as noarch.
EVeryone invents new names and the diversity just confuses.
True ;(
The default macros SHOULD be gud enuf on Mac OS X.
Perfect
Anders Bjorkland's Mac OS X distro based on RPM is still likely
the best around.
This one (http://www.algonet.se/~afb/rpm/) ?
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.
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.
Then we could works on building a community for RPMs production :)
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 :)
rpm-test-results
Description: Binary data
Re: rpm on OSX Lion
On Mar 26, 2012, at 11:53 AM, Henri Gomez wrote:
rpm-test-results
Quick drive-by browse:
--14: __gpg %{_bindir}/gpg2
That is used by make test to generate a pub key for testing.
That is these failures:
sh genpgp.sh genpgp.h
genpgp.sh: line 15: gpg2: command not found
hint: You will see the %{_bindir} change to an actual path
if/when the executable is found in the usual places.
wget -nv http://rpm5.org/files/popt/popt-1.14-1.src.rpm
make: wget: No such file or directory
There is tools/wget that is good enuf (when I'm paying attention, not yet)
to replace system wget for simple downloads. But you need
--with-neon
first.
This error looks moderately serious (you can comment out the patterns
in macros/* if you must: but pattern matching looks fubar):
error: ^[A-Za-z0-9+._]+$: regexec failed: regexec() failed to match(1)
Because -lpcreposix and the system regexec(3) routines have
identical symbols, there's a high risk of collision. I've re-added
--with-pcre=internal
in order to avoid some issues on RHEL6.
Hint: If you add --miredebug to the command in the makefile you will
get pattern matching debugging sewage. This is generally true for
all 30-40 RPM objects: you will at least get a ctor/dtor message which
is often enough to get sufficient context to identify what is wrong. But
in this case, you likely have broken pattern matching in you build everywhere.
There's a fair number of tests that were not run because packages
failed to build. See the
http://harwich.jbj.org:8010
waterfall, look for the test: stage, to see what SHOULD be happening.
hth
73 de Jeff
Re: rpm on OSX Lion
On Mar 26, 2012, at 12:31 PM, Henri Gomez wrote: Use noarch. What would be kinda spiffy is to automate lipo under RPM control and strip out the unused architectures in universal executables (and if one trusts the automated dependencies are accurate) the libraries. I've also been waiting (like 8 years now, sigh) to internalize MACH-O like ELF in RPM. Using helper scripts like find-requires/find-provides is fine of now, but an implementation in C is precise and accurate and maintainable in a way that scripts will never be. We should stay careful about architecture. Well my mantra is this: RPMTAG_ARCH needs to DIE! DIE! DIE! Seriously: in the real world (i.e. not linux) there are several important identifying attributes that need to be controlled for. And there are some seriopus pending changes in order to handle ARM platforms, which have features that are disabled/enabled. Already there is serious confusions attempting using architecture for Linux/ARM. Each variant feature leads to a new architecture forcing some compatibility chains that are simply fictions (i.e. there is more compatibility than promised by choices for RPM arch compatibility). Apple moved from 68k to PowerPC, and then to x86 (32 and 64 bits). And who knows what future processor they could bring in desktop :) It will more than likely be an A6 ;-) Also, Xcode build tools may stop supporting PowerPC in a near future, so packages will lost their 'universal' architecture. (aside) If you have Xcode skills, I'd like to see RPM build under Xcode. I'm still in denial there however ;-) I recall some packages who need to go up to Assembly level and I'm not sure OSX build tools could embed many builds in a single binary. But for now, x86 (32/64bits) is a general consensus No iPads for you eh? 73 de Jeff __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: rpm on OSX Lion
On Mar 26, 2012, at 12:39 PM, Henri Gomez wrote:
I'll add gpg, neon and wget, and redo tests.
About pcre, I build rpm with 8.30 (as seen in otool log).
Should I disable it ?
PCRE is MANDATORY (because RPM has compiled in patterns
written in the PCRE dialect).
8.30 was what I used when I re-enabled
--with-pcre=internal
Meanwhile the issue is symbol collision because of -lpcreposix.
Everything must be linked consistently You miss, you die.
The internal version of PCRE adds these defines to avoid
symbol pollution at the end of pcreposx.h
/* The functions */
PCREPOSIX_EXP_DECL int pcre_regcomp(regex_t *, const char *, int);
PCREPOSIX_EXP_DECL int pcre_regexec(const regex_t *, const char *, size_t,
regmatch_t *, int);
PCREPOSIX_EXP_DECL size_t pcre_regerror(int, const regex_t *, char *, size_t);
PCREPOSIX_EXP_DECL void pcre_regfree(regex_t *);
#define regcomp pcre_regcomp
#define regexec pcre_regexec
#define regerror pcre_regerror
#define regfree pcre_regfree
Most linux distros (but not Red Hat) are doing similar for many years.
hth
73 de Jeff
2012/3/26 Jeffrey Johnson n3...@me.com:
On Mar 26, 2012, at 11:53 AM, Henri Gomez wrote:
rpm-test-results
Quick drive-by browse:
--14: __gpg %{_bindir}/gpg2
That is used by make test to generate a pub key for testing.
That is these failures:
sh genpgp.sh genpgp.h
genpgp.sh: line 15: gpg2: command not found
hint: You will see the %{_bindir} change to an actual path
if/when the executable is found in the usual places.
wget -nv http://rpm5.org/files/popt/popt-1.14-1.src.rpm
make: wget: No such file or directory
There is tools/wget that is good enuf (when I'm paying attention, not yet)
to replace system wget for simple downloads. But you need
--with-neon
first.
This error looks moderately serious (you can comment out the patterns
in macros/* if you must: but pattern matching looks fubar):
error: ^[A-Za-z0-9+._]+$: regexec failed: regexec() failed to match(1)
Because -lpcreposix and the system regexec(3) routines have
identical symbols, there's a high risk of collision. I've re-added
--with-pcre=internal
in order to avoid some issues on RHEL6.
Hint: If you add --miredebug to the command in the makefile you will
get pattern matching debugging sewage. This is generally true for
all 30-40 RPM objects: you will at least get a ctor/dtor message which
is often enough to get sufficient context to identify what is wrong. But
in this case, you likely have broken pattern matching in you build
everywhere.
There's a fair number of tests that were not run because packages
failed to build. See the
http://harwich.jbj.org:8010
waterfall, look for the test: stage, to see what SHOULD be happening.
hth
73 de Jeff
__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org
__
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 on OSX Lion
Anders, your expertise on OSX and RPM will be very helpfull. Could we team up for providing Snow/Lion packages (RPM yum/zypper/wharever) ? Le 26 mars 2012 à 20:35, Anders F Björklund a...@rpm5.org a écrit : Henri Gomez wrote: Also, Xcode build tools may stop supporting PowerPC in a near future, so packages will lost their 'universal' architecture. Xcode 4.2+ doesn't support PowerPC, and neither does the 10.7 SDK. I recall some packages who need to go up to Assembly level and I'm not sure OSX build tools could embed many builds in a single binary. It's better to build twice and lipo, then doing a fat configure. --anders __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: rpm on OSX Lion
If MacPorts could provide a RPM based distribution, may be need for recreating
a new distribution may be less urgent.
Better if they push dependencies in ... RPMs.
MacPorts team did a tremendous works and duplicating effort may not be
mandatory.
About RPM on MacPorts, could it be updated to 5.4.7 ?
Le 26 mars 2012 à 20:17, Anders F Björklund a...@rpm5.org a écrit :
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
__
RPM Package Managerhttp://rpm5.org
User Communication List rpm-users@rpm5.org
Re: rpm on OSX Lion
On Mar 26, 2012, at 4:54 PM, Henri Gomez wrote: What's devtool.conf ? This is the file where various build option stanzas are kept. Building from CVS, the workflow goes like cvs co rpm ./devtool checkout ./devtool falmouth # -- the build options I use on Lion server There is another bootstrapping stanza (i.e. all build prerequisites are downloaded/built and rpm is linked against those builds) in a %standalone stanza. I personally don't use %standalone because I need to see a maximally configured rpm to prevent bit rot while developing. But the %standalone stanza is very useful for testing builds across a variety of platforms without installing anything whatsoever on that machine (which is what aft was referring to). All that is in devtool (and devtool.conf) is a series of %foo shell stanzas. Think portable shell functions and you will figure out what is being done with ./devtool checkout ./devtool falmouth and also ./devtool standalone 73 de Jeff __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: rpm on OSX Lion
On Mar 26, 2012, at 4:57 PM, Henri Gomez wrote: MacPorts team did a tremendous works and duplicating effort may not be mandatory. I should explain the fundamental disconnect between RPM - MacPorts (and more generally *BSD) here. There are build dependencies and there are install dependencies. These sets are quite different. RPM is all about install dependencies and binary packaging. MacPorts (and *BSD) is all about build dependencies. RPM confuses things further because (in fact) the build - install dependencies are essentially the same because of dog food and creating build systems using binary packages. MacPorts confuses things further with +variants in build recipes that are actually attributes on edges between package nodes in the dependency graph. The closest similar analogue in linux is flavors (iirc) usined by Conary from rPath (but there are other attempts at +foo variants in linux, just none are worth a damn, including bonds in RPM using --with and --without). Which comes to what has been attempted with RPM binary packages built by Portfile recipes but creating *.rpm binary packages. The port implementation attempted to map make world build dependencies out of port(1) Portfile recipe builds directly into a *.spec template using Requires: … and Provides: … with some modest filtering. At the same time RPM is/was automating what are essentially install dependencies and also adding those to *.rpm packages. This leads to rather a snarly mess because build != install dependencies: the graphs are quite different. Instead of explaining this Yet Again, its literally (for me anyways) to embed a tcl interpreter, dink a bit with how the port cli arguments are passed into tcl, and just hijack all the recipes, and rely on FULLY automated (rather package manual goo) dependency extraction by rule to fill in binary package metadata without all the associated discussions that MacPorts volunteers continue to voice. MacPorts is nicely done. Just they haven't yet the experience with dependency graphs and binary packaging because of cultural (like make world and *.dmg and bundles) issues. Short answer: I don't think there is sufficient interest in MacPorts in using RPM intelligently. JMHO, YMMV. 73 de Jeff__ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: rpm on OSX Lion
On Mar 25, 2012, at 2:59 AM, Henri Gomez wrote: Jenkins is spiffy, buildbot -- particularly with older python-2.4 -- is a bit of wrestling match. I set up both on the same machine. Jenkins/Hudson needed 500 Mb and filled /var/log within a week with useless messages. Yep, Jenkins could be very verbose, but well, it fit well Continuous Integration need (more than just a build engine). And I'm pretty experienced with it :) Either Jenkins/Hudson or buildbot are adequate to my usage case. Yes more than a build engine is needed. Note that de facto CI in RPM is currently using OWL2/OWL3/IDMS (because those distros are small and the packaging has few errors), installing into a chroot, and undertaking packaging QA (and explicit code coverage of common production RPM code paths). Buildbot is lighter weight and sooner or later one figures out the double half nelson hammerlock to pin buildbot in the wrestling match of CI. You want a full distro on Mac OS X based on RPM? Count me in … I'd like to. May be it's covered by OpenPKG project ? Yes OpenPKG runs on Mac OS X. But the OpenPKG approach is running on multiple platforms reliably in a *BSD jail. That's very different than a MacPorts or Homebrew replacement. BTW, we are many tired to see MacPorts or Brew requiring to download all internet and build it locally. There is a strong interest for RPMs on OSX. Well … maybe. There is interest in RPM on Mac OS X this week, not just from you. The interest historically has been in binary packages, not in RPM (which has been available in MacPorts and *BSD thanks to Anders Bjorkland for years). I tried to build various versions of rpm but they required beecrypt and popt. Yes: neither bee crypt nor popt is optional. Both are distributed with RPM batteries included. What do you means by RPM batteries included ? I meant 2 things: 1) This is a whole lot of batteries (i.e. libraries) linked into an ELF executable: $ ldd .libs/rpm | wc -l 92 2) The AutoFu is unusual because RPM supports -with-foo=internal for libraries that are problematic. All of the build problems you reported Berkeley DB BeeCrypt popt are problematic for different reasons. When RPM is built batteries included, your problems building RPM pre-requisites case to exist: those libraries are built with RPM and are installed with RPM in -lrpmmisc. beecrypt and popt are reported mandatory in 5.x release (from what I see in configure). Yes: common digests are computed by BeeCrypt and option processing is perfumed by popt. RPM has used bee crypt and popt since forever. My Lion machine is using 64bits kernel and I can't succeed build beecrypt in universal mode (32/64 bits) ;( Beecrypt ends up in -lrpmmisc if building --with-beecrypt=internal beecrypt internal means it will be build statically in rpm ? Not statically but otherwise yes. So beecrypt lib sources should be included somewhere I guess Beecrypt (and popt) sources are added to RPM's build tree by ./devtool checkout when building from CVS. And a concept of a tar ball release isn't all that useful because on set of files needs to be chosen for distribution. E.g. Berkeley DB isn't (currently) being distributed within RPM tar balls largely because I got tired of hearing Bloat! Bloat! Bloat!. The cost of a smaller tar ball is that the build is harder: detecting/linking all possible versions on all possible platforms for BDB is exactly one of the problems that you (and others) are reporting. So the choice in RPM is 1) distribute RPM+BDB and build internally and users complain about Bloat! 2) target a single version of Berkeley DB external installed one specific way and users complain about hard to build. So I'd like to avoid requiring MacPorts but it seems we need many bootstrap libraries like popt/beecrypt (and in Universal Format). Only if you choose to build against external libraries. E.g. Berkeley DB can be built and distributed with RPM as well. In fact that is what I would do if the decision was mine: writing AutoFu tests for all possible versions of Berkeley DB is much harder than just bundling Berkeley DB within RPM (as was done for years). +1 for embebed Berkeley DB inside RPM, there is just too many versions on BDB around and it could be a nightmare. Sadly votes and opinions and engineering do not matter: building RPM with BDB externally (and cutting the size of the distributed rpm-X.Y.Z.tar.gz by more than 50%) was hugely popular. Meanwhile, if you untar db-5.3.15.tar.gz in the top level directory, and rename to db, you likely have a pretty good chance that internal Just Works (but there are other and more complex issues with embedded sqlite3) What is involved with Universal Format for you? OSX could build it binaries including many formats, aka x86 32bits and x86 64bits. Take a look here, I detail build process for mod_jk in dual model mode :
Re: rpm on OSX Lion
On Mar 25, 2012, at 11:18 AM, Henri Gomez wrote: First thing I'd like to do is building RPM 5.x from tarball or SCM with no dependencies on MacPorts. Here's the build incantations: $ cvs -d ':pserver:anonym...@rpm5.org:/v/rpm/cvs' get -r rpm-5_4 -d wdj54 rpm $ cd wdj54 $ ./devtool checkout $ ./devtool falmouth $ make $ cd tests $ make clean test You WILL need (on Lion) to install db-5.3.15 (I'm told that a db53 port was just added). I do this one expedient hack with db-5.,3.15 (because its a PITA to fix properly): cd /opt/local/lib ln -s db53/* . Change the %falmouth stanza to lose any build prerequisites (mostly bog standard MacPorts but I do what is needed to enable _EVERYTHING_ for RPM development) that you do not wish to fight with. Advices very welcomed :-) If build scripts are available I'll study them closely. The build scripts above are all that is needed. What is harder is ensuring all the build prerequisites are in place and choosing the build options. The above is essentially what is running in the LION_rpm_rpm54 waterfall. Examine those builds to see what is needed. Building RPM is _NOT_ as simple as doing ./configure --prefix=/usr which everyone expects. The ./devtool … paradigm is based on GNU shtool. Another piece of RPM's build puzzle is a very slick RPM_CHECK_LIB() m4 macro that Just Works in most cases (note: that it took me more than a year to learn how to use RPM_CHECK_LIB() and 'm still learning tricks and twists even today …) Both devtool and RPM_CHECK_LIB are from Ralf S Engelschall at OpenPKG: _REALLY_ nicely done engineering imho. hth 73 de Jeff Le 25 mars 2012 à 14:33, Jeffrey Johnson n3...@me.com a écrit : On Mar 25, 2012, at 2:59 AM, Henri Gomez wrote: Jenkins is spiffy, buildbot -- particularly with older python-2.4 -- is a bit of wrestling match. I set up both on the same machine. Jenkins/Hudson needed 500 Mb and filled /var/log within a week with useless messages. Yep, Jenkins could be very verbose, but well, it fit well Continuous Integration need (more than just a build engine). And I'm pretty experienced with it :) Either Jenkins/Hudson or buildbot are adequate to my usage case. Yes more than a build engine is needed. Note that de facto CI in RPM is currently using OWL2/OWL3/IDMS (because those distros are small and the packaging has few errors), installing into a chroot, and undertaking packaging QA (and explicit code coverage of common production RPM code paths). Buildbot is lighter weight and sooner or later one figures out the double half nelson hammerlock to pin buildbot in the wrestling match of CI. You want a full distro on Mac OS X based on RPM? Count me in … I'd like to. May be it's covered by OpenPKG project ? Yes OpenPKG runs on Mac OS X. But the OpenPKG approach is running on multiple platforms reliably in a *BSD jail. That's very different than a MacPorts or Homebrew replacement. BTW, we are many tired to see MacPorts or Brew requiring to download all internet and build it locally. There is a strong interest for RPMs on OSX. Well … maybe. There is interest in RPM on Mac OS X this week, not just from you. The interest historically has been in binary packages, not in RPM (which has been available in MacPorts and *BSD thanks to Anders Bjorkland for years). I tried to build various versions of rpm but they required beecrypt and popt. Yes: neither bee crypt nor popt is optional. Both are distributed with RPM batteries included. What do you means by RPM batteries included ? I meant 2 things: 1) This is a whole lot of batteries (i.e. libraries) linked into an ELF executable: $ ldd .libs/rpm | wc -l 92 2) The AutoFu is unusual because RPM supports -with-foo=internal for libraries that are problematic. All of the build problems you reported Berkeley DB BeeCrypt popt are problematic for different reasons. When RPM is built batteries included, your problems building RPM pre-requisites case to exist: those libraries are built with RPM and are installed with RPM in -lrpmmisc. beecrypt and popt are reported mandatory in 5.x release (from what I see in configure). Yes: common digests are computed by BeeCrypt and option processing is perfumed by popt. RPM has used bee crypt and popt since forever. My Lion machine is using 64bits kernel and I can't succeed build beecrypt in universal mode (32/64 bits) ;( Beecrypt ends up in -lrpmmisc if building --with-beecrypt=internal beecrypt internal means it will be build statically in rpm ? Not statically but otherwise yes. So beecrypt lib sources should be included somewhere I guess Beecrypt (and popt) sources are added to RPM's build tree by ./devtool checkout when building from CVS. And a concept of a tar ball release isn't all that useful because on set of files needs to be chosen for distribution.
Re: rpm on OSX Lion
You're amazing guys ! Well, I feel I have works-fun next week. I'll avoid /opt of course, first step will be to install rpm under /usr/bin for a test drive and test some of my own rpms. If it works great, next step may be a relocation under /opt/rpm4osx or something like this, ie using a specific bin/lib paths for packages (like MacPorts/Brew does). I now some guys who'll be happy to get a rpm based way to get packages installed via yum for example. Stay tuned, I'll probably ask you more questions in a very near futur. Long live RPM ! :-) 2012/3/25 Jeffrey Johnson n3...@me.com: On Mar 25, 2012, at 1:07 PM, Anders F Björklund wrote: Jeffrey Johnson wrote: First thing I'd like to do is building RPM 5.x from tarball or SCM with no dependencies on MacPorts. Here's the build incantations: $ cvs -d ':pserver:anonym...@rpm5.org:/v/rpm/cvs' get -r rpm-5_4 -d wdj54 rpm $ cd wdj54 $ ./devtool checkout $ ./devtool falmouth $ make $ cd tests $ make clean test Installing things, not managed by MacPorts, into the /opt/local prefix is bound to cause some conflicts one way or another. Wouldn't recommend it. Yes: when the content collides port(1) whines. Meanwhile, I can/will revert my builds lave hacks as MacPorts catches up. (aside) All of the *BSD distros are surprisingly up to date. E.g. I was surprised to see libgit2 appear in MacPorts out of nowhere a coupl;e weeks back. Just seeing libgit2 adoption _SOMEWHERE_ was enough to increase my interest. Otherwise its just Yet Another Battle of irrelevant software from linux distros that are increasingly unwilling to update and maintain (and with libgit2: augment) their Pwecious Wepositowies You WILL need (on Lion) to install db-5.3.15 (I'm told that a db53 port was just added). I do this one expedient hack with db-5.,3.15 (because its a PITA to fix properly): cd /opt/local/lib ln -s db53/* . It should be enough to use the regular CPPFLAGS+=-I/opt/local/include/db53 and LDFLAGS+=-L/opt/local/lib/db53, rather than setting up symlinks, I think. Quite easy for a human yes. OTOH, buildslaves require 100% fully automated builds, and that last 0.1% is exceptionally painful to deploy. E.g. I (and with help from you ;-) have wasted days just trying to get the AutoFu in place to find what used to be a very simple and common uglix path /etc/magic and which is now installed on some path that correlates with almost nothing sane. Change the %falmouth stanza to lose any build prerequisites (mostly bog standard MacPorts but I do what is needed to enable _EVERYTHING_ for RPM development) that you do not wish to fight with. Adding a rpm54 port would be the most straight-forward way to include it. I'll see what I can do about it, should be a copy of the existing rpm52… I'd be a bit lazy about rpm54 which is quite active atm. Meanwhile, rpm-5.3.11++ is production and stable and all that good stuff. Of course, neither the %falmouth nor the (post-5.2) %macosx devtool target nor the mac ports will help if one wants to make a stand-alone distribution. I still prefer --prefix=/usr on Mac OS X just because its KISS. There's literally no reason for multiple interoperable versions of RPM unless one wants to have a FUD fight with the Script Kiddie in the cafeteria for some reason. Then you need to start from the beginning, by installing all dependencies. Just like the %standalone target used to do, while it was still alive ? The %standalone could be dusted off and resurrected and even attempted in builds laves if there was interest. Just that RPM's feature set is growing rapidly and there isn't any sense of sanity any more. Note all of these fairly aggressive features in rpm-5_4: RPM+GIT RPM+ODBC and today RPM + version-sets (aside) Alt has dependencies (and a rpmlib(SetVersions) tracking dependency: eeek!) that look like this: Unsatisfied dependencies for librpm-4.0.4-alt100.48.x86_64: Requires: ld-linux-x86-64.so.2()(64bit) = set:ihidc Requires: libbeecrypt.so.7()(64bit) = set:mhhDthCzKb1jmWTlFex3hTP1fZ9qdjdg5R0Ki9ZGsyUwKAWfS Requires: libbz2.so.1()(64bit) = set:ifKTc38cpjCTVElPz9 Requires: libdb-4.7.so()(64bit) = set:jgqkEXaUzonx2 Requires: libelf.so.1()(64bit) = set:kgwCsW8ZzioOVCwIkTfY6HIZl1 Requires: liblzma.so.5()(64bit) = set:khmhwPSISTidIxcswe Requires: libpopt.so.0()(64bit) = set:ihGO1 Requires: libselinux.so.1()(64bit) = set:lh0RFVmZz943Uzb6j7vuSMCo1 Requires: libz.so.1()(64bit) = set:kg0hJg923EZ3mQTTIo11VHd … I'm sure you recognize base62 encoding when you see it ;-) I haven't a clue what Alexey Tourbin did (well I know conceptually) yet. I'm hoping to get the set-version functionality in place to feed Sisyphus sausages to the hungry buildslaves waiting to do cd tests make Install-ALT51
Re: rpm on OSX Lion
Excellent. I now well Jenkins but not Waterfall, seems interesting. I build the latest rpm-5_4 from CVS on Lion Server using a buildbot here: http://harwich.jbj.org:8010/waterfall Both Lion Server (and Leopard) are there in the waterfalls. (aside) Both are broken atm just because I haven't bothered fixing bleeding edge functionality on Mac OS X quite yet. Note that bleeding edge is currently attempting to use an embedded perl interpreter to load a perl-URPM CPAN module that isn't installed. i.e. no one but me needs/uses this RPM functionality yet. But there are older successful logs which show the build options in use and the results of buildbot testing on both Lion and Leopard (and if you want Snow Leopard or Mountain Lion, I can likely attempt that too). The majority of the packages in use are bog standard installs from MacPorts port(1). There's a few packages (like db-5.3.15) that aren't in MacPorts yet that I build manually. The really hard part of building RPM is figuring out the build options. Its not as simple as just doing ./configure --prefix=/opt/local make make install But feel free to make suggestions on what you want to see. I'd love to see RPM in use on Mac OS X. My goal was to bring RPM natively to OSX and see if it would be possible to set a RPM distribution like one available from MacPorts or Brew but without requiring to build it. I tried to build various versions of rpm but they required beecrypt and popt. My Lion machine is using 64bits kernel and I can't succeed build beecrypt in universal mode (32/64 bits) ;( So I'd like to avoid requiring MacPorts but it seems we need many bootstrap libraries like popt/beecrypt (and in Universal Format). __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: rpm on OSX Lion
On Mar 24, 2012, at 9:12 AM, Henri Gomez wrote: Excellent. I now well Jenkins but not Waterfall, seems interesting. Jenkins is spiffy, buildbot -- particularly with older python-2.4 -- is a bit of wrestling match. I set up both on the same machine. Jenkins/Hudson needed 500 Mb and filled /var/log within a week with useless messages. Buildbot is lighter weight and sooner or later one figures out the double half nelson hammerlock to pin buildbot in the wrestling match of CI. I build the latest rpm-5_4 from CVS on Lion Server using a buildbot here: http://harwich.jbj.org:8010/waterfall Both Lion Server (and Leopard) are there in the waterfalls. (aside) Both are broken atm just because I haven't bothered fixing bleeding edge functionality on Mac OS X quite yet. Note that bleeding edge is currently attempting to use an embedded perl interpreter to load a perl-URPM CPAN module that isn't installed. i.e. no one but me needs/uses this RPM functionality yet. But there are older successful logs which show the build options in use and the results of buildbot testing on both Lion and Leopard (and if you want Snow Leopard or Mountain Lion, I can likely attempt that too). The majority of the packages in use are bog standard installs from MacPorts port(1). There's a few packages (like db-5.3.15) that aren't in MacPorts yet that I build manually. The really hard part of building RPM is figuring out the build options. Its not as simple as just doing ./configure --prefix=/opt/local make make install But feel free to make suggestions on what you want to see. I'd love to see RPM in use on Mac OS X. My goal was to bring RPM natively to OSX and see if it would be possible to set a RPM distribution like one available from MacPorts or Brew but without requiring to build it. You want a full distro on Mac OS X based on RPM? Count me in … I tried to build various versions of rpm but they required beecrypt and popt. Yes: neither bee crypt nor popt is optional. Both are distributed with RPM batteries included. My Lion machine is using 64bits kernel and I can't succeed build beecrypt in universal mode (32/64 bits) ;( Beecrypt ends up in -lrpmmisc if building --with-beecrypt=internal So I'd like to avoid requiring MacPorts but it seems we need many bootstrap libraries like popt/beecrypt (and in Universal Format). Only if you choose to build against external libraries. E.g. Berkeley DB can be built and distributed with RPM as well. In fact that is what I would do if the decision was mine: writing AutoFu tests for all possible versions of Berkeley DB is much harder than just bundling Berkeley DB within RPM (as was done for years). What is involved with Universal Format for you? 73 de Jeff __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
Re: rpm on OSX Lion
On Mar 23, 2012, at 7:41 PM, Henri Gomez wrote: Hi to all, I'm a long time rpm user and packager and I'd like to experiment it on OSX (10.7.3) and Xcode 4.3.2. Good. snip Did someone succeed to build rpm 5.x on OSX Lion ? Advices more than welcomed. I build the latest rpm-5_4 from CVS on Lion Server using a buildbot here: http://harwich.jbj.org:8010/waterfall Both Lion Server (and Leopard) are there in the waterfalls. (aside) Both are broken atm just because I haven't bothered fixing bleeding edge functionality on Mac OS X quite yet. Note that bleeding edge is currently attempting to use an embedded perl interpreter to load a perl-URPM CPAN module that isn't installed. i.e. no one but me needs/uses this RPM functionality yet. But there are older successful logs which show the build options in use and the results of buildbot testing on both Lion and Leopard (and if you want Snow Leopard or Mountain Lion, I can likely attempt that too). The majority of the packages in use are bog standard installs from MacPorts port(1). There's a few packages (like db-5.3.15) that aren't in MacPorts yet that I build manually. The really hard part of building RPM is figuring out the build options. Its not as simple as just doing ./configure --prefix=/opt/local make make install But feel free to make suggestions on what you want to see. I'd love to see RPM in use on Mac OS X. hth 73 de Jeff __ RPM Package Managerhttp://rpm5.org User Communication List rpm-users@rpm5.org
