Ralf S. Engelschall wrote:
As it is AFAIK not documented anyhwere and also far away from being
obvious, here is a short tutorial for the RPM hackers on how to migrate
the RPM DB of RPM 5 between Berkeley-DB and SQLite.
Thanks for the detailed information, I'll add some commands
that I found
# dump a Berkeley-DB database as text
/opt/local/lib/rpm/rpmdb_dump /opt/local/var/lib/Packages
# dump a SQLite database as text
echo .dump | sqlite3 /opt/local/var/lib/Packages
Make that /opt/local/var/lib/rpm/Packages, duh.
--anders
Ralf S. Engelschall wrote:
Some status quo on RPM 5 from my personal point of view:
As you perhaps recognized yourself, just about 4 weeks ago building
RPM was (sorry that I have to say this) still more or less a real
nightmare -- even for a hard-core developers.
I personally even was under
Seems like the internal zlib ignores any CFLAGS passed,
such as the required ones for building universal binaries...
The reason for this seems to be a typo/thinko in configure:
CFLAGS=-DHAS_snprintf -DHAS_snprintf
http://www.algonet.se/~afb/rpm/5.0/rpm-5.0-zlib_configure_cflags.patch
--anders
Jeff Johnson wrote:
When upgrading to RPM 5.0 CVS I now find that it has been
moved to the development directory (%{_topdir}) instead...
Although I do agree that hardcoding /var/spool/repackage
is bad, I had placed %{_topdir} in the developer category.
That sounds like a bad place to me.
Jay Soffian wrote:
So nothing to change or see here, just little Mac quirks.
Is this for MacPorts? If so, I'd think you'd want to have an
rpm+python variant that uses the MacPorts Python, not the system
python.
It wasn't. The MacPorts rpm and rpm-devel ports use the
MacPorts python/perl
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
___
_
Server: rpm5.org Name: Olivier Thauvin
Root: /v/rpm/cvs Email: [EMAIL PROTECTED]
Module: rpm
Olivier Thauvin wrote:
This commit broke the MacPorts rpm-devel port (again):
/opt/local/include/beecrypt/api.h:66: error: redefinition of typedef
'byte'
../rpmio/rpmpgp.h:18: error: previous declaration of 'byte' was here
I changed it back to #if 1 for the MacPorts build...
Feel free to fix
Ralf S. Engelschall wrote:
The choice _IS_ a bad place for default, but is certainly
configurable.
I'll probably change it back to my previous,
@prefix@/var/spool/repackage
(but I'll wait for the rationale from cse, for keeping TR in the
_topdir)
[...]
Well, please feel free to choose a
Ralf S. Engelschall wrote:
On Thu, Aug 16, 2007, Jason Corley wrote:
I've attached my %jasonc devtool target (modified %standalone) that I
just got working in case it helps anyone. It's targeted for my mac so
a lot of the tests and conditionals are stripped out (nothing wrong
with them in
Ralf S. Engelschall wrote:
Well, please feel free to choose a better location. My personal main
concern was just that it can be still configured via macros and the
default is really usable out-of-the-box after a make install (which
wasn't the case in the past). The actual default location I
* it ignores any unrecognized LDFLAGS: (MakeMaker problem ?)
Unrecognized argument in LIBS ignored: '-arch'
Unrecognized argument in LIBS ignored: 'ppc'
Unrecognized argument in LIBS ignored: '-arch'
Unrecognized argument in LIBS ignored: 'i386'
Unrecognized argument in LIBS ignored:
Olivier Thauvin wrote:
* it ignores any unrecognized LDFLAGS: (MakeMaker problem ?)
Unrecognized argument in LIBS ignored: '-arch'
Unrecognized argument in LIBS ignored: 'ppc'
Unrecognized argument in LIBS ignored: '-arch'
Unrecognized argument in LIBS ignored: 'i386'
Unrecognized argument in
When I am building a program against rpm libraries,
I get an error due to WITH_DB not being defined...
/usr/local/include/rpm/rpmdb.h:16:20:
error: db_emu.h: No such file or directory
If those are supposed to be known, shouldn't they
be autoconfed into the headers or pkg-config etc. ?
They
When building/using RPM with an static/internal popt,
is it OK to include the required popt.h in rpm/ ?
Several of the RPM headers requires popt.h, so I will
need to install it (somewhere) for them to work...
I could of course copy it to include/ directly, but
then it might theoretically
When I am building a program against rpm libraries,
I get an error due to WITH_DB not being defined...
/usr/local/include/rpm/rpmdb.h:16:20:
Is this an external or internal program that needs
#include rpmdb.h
The fixing is different for external/internal.
External.
Those are supposed to
Jeff Johnson wrote:
There's other ways to address then autoconf expansions to eliminate
WITH_DB and WITH_SQLITE in rpmdb.h then.
Sure, but I figured since they were in autoconf already...
Then again, different headers for different configurations
does sound like it could lead to some
C and Perl bindings seems to be working OK.
And Now for Something Completely Different:
Seems like expat dependency was missing from my rpmio library:
ImportError:
dlopen(/System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/site-packages/rpm/_rpmmodule.so, 2): Symbol not
Jeff Johnson wrote:
I'm also interested in using the Mac OS X keyring in ways similar to
how keyutils
is going to be used. Does anyone have a ptr to a reasonable
implementation
in some non-interpreted language?
The only pointer I have is
http://developer.apple.com/reference/Security,
but
Ralf S. Engelschall wrote:
Modified files:
rpm CHANGES devtool devtool.conf
Log:
make devtool %standalone fully modular for allowing its modules to
be
reused in other devtool targets.
-%thirdpartydefs
-@source %thirdpartydefs
+#
Ralf S. Engelschall wrote:
I'll add some snippets for building Universal Binaries on Mac OS X...
See %universal, in http://www.algonet.se/~afb/rpm/5.0/devtool.conf
Basically I build the dependencies in the same way, but I build RPM
dynamically and use the internal implementations of
Ralf S. Engelschall wrote:
[...]
Here's the PKG: http://www.algonet.se/~afb/rpm/rpm5-installer.png
Cool...
I'm just curious: in what programming language is such a GUID-based Mac
OS X installer written?
None at all, actually. You provide the resources, and the Installer.app
presents the
Robert Scheck wrote:
IMHO the second result is simply wrong. RPM.so is not linked to
librpm* somehow.
Why? What went wrong? Ideas?
FYI: During make in koji, the following showed up, too. Maybe this
could be
relevant:
Note (probably harmless): No library found for -lrpmio
Note (probably
Robert Scheck wrote:
On Tue, 04 Sep 2007, Jeff Johnson wrote:
If this is what fixes make -jX, then there is a missing dependency
from minigzip - libz.a somewhere. Note that eliminating example
and minigzip eliminates, rather than fixes, the make -jX problem.
I didn't call this fix. It simply
Seems like rpm library users are relying on RPMSENSE_ANY
to be some kind of default value, can this be made into
non-internal (i.e. public) in the RPM 4.5 API perhaps ?
enum evrFlags_e {
RPMSENSE_ANY= 0,
#if defined(_RPMEVR_INTERNAL)
--anders
Jeff Johnson wrote:
RPM_Transaction.xs:308: error: too many arguments to function
'rpmdbAdd'
RPM_Transaction.xs: In function 'XS_RPM__Transaction_dbremove':
An argument was removed in 3 functions. I can back an unused argument
if necessary. Lemme look this evening. The quick hack is to
Jeff Johnson wrote:
Shouldn't this use the new lzma command from LZMA Utils 4.32,
rather than the old lzmash shell wrapper script for LZMA SDK ?
(the old lzma command from LZMA Utils 4.27 and/or LZMA SDK has
now been renamed as lzma_alone instead, to avoid name conflicts)
(aside) It never
Ralf S. Engelschall wrote:
I'm currently in the progress of releasing 5.0a2, but the devtool
standalone testdrive procedure already fails with errors like the
following:
| error: rpmdbNextIterator: skipping h# 1 tag[20]: BAD, tag
1834043241 type 765558 offset 1919830354 count
Jeff Johnson wrote:
I'm still debating xar - rpmio Payload compression, as well as
whether
rpmio should swallow libxar, or vice versa. There's some twists and
turns
in the code paths I'd like to see, but that's likely just my fetishes.
I'll hack out something this weekend, the problem is
Jeff Johnson wrote:
On Nov 23, 2007, at 2:50 PM, Ralf S. Engelschall wrote:
On Fri, Nov 23, 2007, Jeff Johnson wrote:
- jbj: re-add rpm2cpio.c.
Nice. Should we also install _this_ program instead of the weak
scripts/rpm2cpio script?
Depends on your religion. Some like simple
Ralf S. Engelschall wrote:
Log:
indicate that the 'lzma' here is the command line tool and use
sub-shell constructs to more portably support the situation where
no
lzma(1) is in PATH at all (and hence the shell itself already
complains with a confusing 'lzma: file not
Jeff Johnson wrote:
Modified files:
rpm CHANGES
rpm/build parsePreamble.c
rpm/rpmdb hdrfmt.c rpmtag.h tagname.c
rpm/rpmio argv.c argv.h librpmio.vers
Log:
- using tagValue instead permits queries of arbitrary
Ralf S. Engelschall:
Latest HEAD is broken this morning:
Fixed, http://rpm5.org/cvs/chngview?cn=8940 (same as with Perl earlier)
I don't know why we need the extra declaration for byte (we could
just include beecrypt/api.h, I think).
Moving to uint8_t is another option, to avoid
Jeff Johnson wrote:
Which is not true with the (arguably standard rpmbuild invocation
here,
at least as consistent as possible with what is documented in Maximum
RPM and
The RedHat RPM Guide and with the default distributed rpm macro
configuration):
/var/tmp/devtool-test-root: No such file
Ralf S. Engelschall wrote:
On Fri, Dec 07, 2007, Jeff Johnson wrote:
The team consensus decision was both, but the path
choice(s) need finalization.
As rpm2cpio is often needed also on the shell, I personally vote to
just
install it into bindir and let the script stuff live in the
Jason Corley wrote:
The lack of lazy mkdir is one problem, the other appears to be the
macros.in doesn't use $prefix but rather %{_var} for repackage dir...
Would it be a good idea to change all the filesystem macros in
macros.in to obey $prefix?
I changed the %{repackagedir} away from
Do we need some pre-defined RPM macro values that
contain the file extensions for exe and shlib ?
Currently these are usually hardcoded in specs as
and .so respectively, which usually works...
(and not applicable to spec files that doesn't use
%files for listing names, but instead %files -f)
Jeff Johnson wrote:
Do we need some pre-defined RPM macro values that
contain the file extensions for exe and shlib ?
Currently these are usually hardcoded in specs as
and .so respectively, which usually works...
(and not applicable to spec files that doesn't use
%files for listing names, but
When building with the local static OSSP uuid (standalone/macosx):
checking uuid.h usability... no
checking uuid.h presence... yes
configure: WARNING: uuid.h: present but cannot be compiled
configure: WARNING: uuid.h: check for missing prerequisite headers?
configure: WARNING: uuid.h: see
./devtool.log:/usr/bin/ld: multiple definitions of symbol
_strict_erasures
./devtool.log:../lib/.libs/librpm.a(fsm.o) definition of
_strict_erasures in section (__DATA,__data)
./devtool.log:../rpmio/.libs/librpmio.a(iosm.o) definition of
_strict_erasures in section (__DATA,__data)
Seems to
Ralf S. Engelschall wrote:
HEAD is of today is broken:
../rpmio/.libs/librpmio.a(iosm.o): In function `iosmMapAttrs':
/u/rse/prj/rpm/src/rpm/rpmio/iosm.c:948: undefined reference to
`headerIsEntry'
/u/rse/prj/rpm/src/rpm/rpmio/iosm.c:962: undefined reference to
`headerIsEntry'
collect2:
Ralf S. Engelschall wrote:
Maybe the iosm needs a new explicit use-runtime-owner-group option,
than have rpmio call out to the rpmdb function to check for a SRPM ?
Like the --no-same-owner option in tar (or some other bad analogue).
But what I meant was that maybe it should be made into more
When using a librpm with internal Lua, I'm running into
library conflicts with a program also using Lua... (=APT)
/usr/bin/ld: multiple definitions of symbol _luaA_pushobject
/usr/local/lib/librpmmisc.dylib(liblua_la-lapi.o) definition of
_luaA_pushobject
./.libs/liblua.a(liblua_la-lapi.o)
Server: rpm5.org Name: Per Øyvind Karlsen
Root: /v/rpm/cvs Email: [EMAIL PROTECTED]
Module: rpm Date: 05-Mar-2008
17:45:17
Branch: rpm-5_0 Handle: 2008030516451700
Modified
Ralf S. Engelschall wrote:
Hmmm... IMHO this
was a NO-OP semantically and just broke many things? Can we backout
and
keep the code we had before? As I mentioned in INSTALL, just a few
days
ago I reviewed the code against 4.57 and it is identical except for
our
already applied fixes. But
checking for poptGetContext in -lpopt... no
checking whether to build with POPT library... no
This is because it misses a libtool dependency*:
...
* PS. this dependency is new for popt 1.14,
as popt 1.13 didn't depend on libiconv.
Apparently this also works, to disable iconv usage:
Pazzo Da Legare wrote:
I'm having problem with archs. I found the function rpmSetMachine
which change build_arch (of --showrc) I would like to change
programmatically (or better at compile time of my version of librpm)
other parameters: compatible build archs, install arch, install os,
Pazzo Da Legare wrote:
devzero200, I'm using 4.4.2.2. I don't understand from where one can
setup information about custom architecture (as x86_586). I tried
you like but it seems broken.
It seems that those infos, about arch, are used at compile time from
librpm. I found this page about
Pazzo Da Legare wrote:
I apologize for my noise in this ML.
No problem, it's just that if you want to set the _build_arch
either approach (--target or /etc/rpm/platform) works in RPM5.
Normally it would be i586 rather than x86_586, though.
I wrote to rpm maint too but nobody seems to be
Jeff Johnson wrote:
I have multip[le issues with changes like this:
1) the patch uses envvar's
Using envvar's forces remote rpm to carry an environment along
in order to run remote commands, and largely forces remote
execution with
shell. There are many times/places that
And the feeping creaturism starts to try to accomodate automatic
detection for
a functionality that isn't needed or used by rpmbuild itself.
Feel free to revert... It was just that proyvind's original
implementation returned RPM_BUILD_NCPUS = undefined here. :-)
And what happens in a VM,
Jeff Johnson wrote:
Can anyone explain to me why this macro is initrddir when
/etc/init.d and /etc/rc.d/init.d have absolutely nothing
whatsoever to
do with the initial RAM disk? Shouldn't it be initdir?
Hysterical accident is what my bleached neurons remember.
Either Mandriva or PLD was
It was Mandriva, says the changelog:
http://rpm5.org/cvs/filediff?f=rpm/platform.inv1=2.6v2=2.7
Couldn't find their original changelog,
seems like it was reset at 2005 or so ?
Didn't look hard enough:
* Mon Aug 21 2000 Frederic Lepied [EMAIL PROTECTED] 3.0.5-11mdk
- added _initrddir macro to
Ralf S. Engelschall wrote:
RPM Package Manager, CVS Repository
+else if ( (file_len 3 strcasecmp(file+file_len-3,
.lz) == 0)
+ || (file_len 3 strcasecmp(file+file_len-3, .
7z) == 0)
+ || (file_len 5 strcasecmp(file+file_len-5,
.lzma) == 0)) {
But it should probably be:
else if ( (file_len 4 strcasecmp(file+file_len-3,
.tlz) == 0)
|| (file_len 5 strcasecmp(file+file_len-5,
.lzma) == 0)) {
Stupid copy/paste bugs...
else if ( (file_len 4 strcasecmp(file+file_len-4, .tlz)
== 0)
||
Jeff Johnson wrote:
make[1]: *** No rule to make target `../rpmio/librpmio.la', needed
by `rpmdigest'. Stop.
make[1]: *** Waiting for unfinished jobs
The flaw seems to be that librpmio.la and $(top_builddir)/rpmio/
librpmio.la are not
being perceived as the same object.
Yup,
Dan Nicholson wrote:
The default rpm %configure passes --host=%_host, which is derived at
rpm build time. Probably better would be to pass %_target_platform as
--host, --build and --target.
I thought it used ./configure --host=%{_host} --build=%{_build} \
--target=%{_target_platform} so it
Ralf S. Engelschall wrote:
OK, lua/{chconfig,shadow} backport should be gud enuf to build
rpm-5.1.4+ afaict. If not, holler at me and I'll fix whatever.
There is still an issue left:
../misc/.libs/librpmmisc.a(liblua_la-lwrs.o): In function
`wrs_groupadd':
Modified files:
rpm CHANGES autogen.sh configure.ac
devtool.conf
rpm/misclibrpmmisc.vers
Log:
- jbj: remove internal zlib.
Index: rpm/devtool.conf
==
==
$
This change isn't working for me, rpmgrep won't link now...
/usr/bin/ld: Undefined symbols:
_adler32_combine
_crc32_combine
Strange thing is it does have a -lz for /usr/lib/libz.dylib ?
Missed that the SDK version of zlib was different from System,
the old version was indeed missing
Jeff Johnson wrote:
Increasingly I'm seeing spec file recipes (and rpmbuild) used in
horrendously
complicated ways.
rpm spec file recipes contain known good (at least wrto rpmbuild
parsing/execution)
content that results in successful builds and binary packages to be
distributed.
That
Jeff Johnson wrote:
Oooh, nice clean.
Could you add to rpmpopt.in on HEAD? I think its time to start
collecting examples of alternative build recipe representations,
the rubyforge YAML is very aesthetically pleasing.
Unfortunately you get indentation errors with non-trivial files.
(could be
Tim Mooney wrote:
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
Jeff Johnson wrote:
BSD Make isn't fully compatible either, but you can usually make
a file
that works in both... (Same thing goes for GNU sh by the way, vs.
BSD sh)
Sure there are dialects of make. There is a subset syntax that is
well supported
by make(1), that is all that is being
Jeff Johnson wrote:
There are two big lies with rpm packaging methodolgy.
(aside) The other lie is that rpm install transactions are
atomic iff there are no packaging flaws or install host failures.
But this lie is reproducible builds, which is true wrto rpmbuild
iff the build
host is set
Ralf S. Engelschall wrote:
I do not understand the !defined(WITH_ZLIB) part here.
If would have expected either...
#if defined(HAVE_ZLIB_CRC32_COMBINE)
...or..
#if defined(WITH_ZLIB) defined(HAVE_ZLIB_CRC32_COMBINE)
...but not the above variant.
Can you shed some light onto this, please.
Jeff Johnson wrote:
Fussing with --fuzz opens up a world of pain and voids the warranty
of %patch macros.
Right, so that's why I left the default as -1 (which translates to 2)
rather than changing the default to the stricter 0 as done elsewhere.
If you want pain, try
#%patchN
in spec
Ralf S. Engelschall wrote:
- proyvind: add support for xz for all tools shipped with rpm.
- proyvind: lzdio: add support for xz format. (removes liblzma
4.999.3 support)
[...]
Where can this new xz stuff be found on the net?
Google shows me just a few mail postings but where is the
Jeff Johnson wrote:
It sure would be nice to have %patch as a macro rather
than flip-flopping and jiggering up Yet More Complicated
Silly Stuff, all forcing rpm rpm be recompiled.
The change was supposed to be to macros (and %patch)...
I haven't a clue anymore (because of the number of
Per Øyvind Karlsen wrote:
I've modified DISTTAG tag to be specified in macros file just like
DISTRIBUTION, VENDOR etc.
and commited it to CVS already.
Here's my next step, a DISTEPOCH tag where distribution version can
be added.
This will change EVR to EVRD which will be represented as
Per Øyvind Karlsen wrote:
So this DISTEPOCH would also work for OSVERSION on other
systems ?
Like darwin8 or 10.5osx or freebsd-7.0 or whatever it might
be ?
Yes, that's kinda the idea, except for DISTEPOCH would only contain
the version,
where the DISTTAG would contain the short
Per Øyvind Karlsen wrote:
Well, for Mandriva 'Distribution:' would still be 'Mandriva
Linux' while 'DistTag':
would be 'mdv'.
And elsewhere, they have Distribution = Unknown and Vendor =
Fedora Project
Oh, really? I thought they had more similar to us, ie. we have
'Vendor: Mandriva'
Jeff Johnson wrote:
Most of the XZ (nee LZMA) code on HEAD is likely stable, and XZ
is (last I heard) on final approach to a release, with stable
format and API/ABI.
Should the changes be pushed into rpm-5.1.7 or not?
I would leave RPM 5.1 with LZMA 4.999.3 (LZMA_Alone only)
as the minimum,
Jeff Johnson wrote:
I do point out that once RPM starts parsing secret sauce comments
there's no way to establish a useful syntax/grammar for whatever is
being represented, defacto vendor enhanced comments will rule
forevermore (imho).
Seeing a similar problem when trying to parse .repo
Jeff Johnson:
Preprocessing filter sounds like a good idea, sort it out with
yamlspec ?
Preprocessing filter seems like the only win! == win! solution to
me as well.
In order to proceed with a pre-processing filter, I'm instantly
shopping an industrial strength data rewrite language in
Mark Hatle wrote:
I have some concern that this could still cause problems on other
systems.. but of course at a much lower rate then before.
Is there any way to only run this when we're using Mac OS X to
eliminate the remaining possibility?
I'll fit in an if (`uname` == Darwin) there
Per Øyvind Karlsen wrote:
--- rpm/lib/rpmrc.c 12 Mar 2009 08:39:28 - 2.255
+++ rpm/lib/rpmrc.c 12 Mar 2009 09:14:25 - 2.256
@@ -551,6 +551,11 @@
xx = mireAppend(RPMMIRE_REGEX, 0, ppc, NULL, mi_re, mi_nre);
#endif
+#if defined(__powerpc__) ||
Jeff Johnson wrote:
I just noticed these AutoFu tests:
GCC extensions:
checking for simple visibility declarations... yes
checking if gcc -std=gnu99 accepts -Wno-uninitialized... yes
checking if gcc -std=gnu99 accepts -Wredundant-decls... yes
checking if gcc -std=gnu99 accepts
Jeff Johnson wrote:
I believe this is because xz's configure.ac uses AC_PROG_CC_C99 ?
Is XZ the only issue? Splint (which is non-C) is routinely
finding C declarations in-line outside of XZ, all of which are full-
stop
parser failures for C99.
And perl was being built with --std=gnu99
Jeff Johnson wrote:
The AutoFu (which has been remarkably resilient, thank you!)
for RPM may soon have two or more meanings for --with-perl
if I seriously pursue embedding perl (and python and ...) into rpm.
I'll use --with-embedded-perl as a marker for my insanities
for now, that is rather
Jeff Johnson wrote:
Log:
- ruby: add --with-ruby for embedding ruby.
Shouldn't that be --with-rubyembed then, like the others ?
(Or maybe --with-embedded-ruby like you mentioned earlier.)
--with-ruby should be for building the ruby bindings, yes ?
(like the ones available from
Jeff Johnson wrote:
Shouldn't that be --with-rubyembed then, like the others ?
(Or maybe --with-embedded-ruby like you mentioned earlier.)
I still haven't a clue whether (or how) embedding script
interpreters is a good idea or not.
All I've been doing so far is looking at feasibility, and
Jeff Johnson wrote:
I'm thinking that Tcl is about as heavy as I want myself,
but that's another story. (i.e. Perl/Python/Ruby too much)
If you grep WITH_TCL in rpm code (and look at rpmio/rpmtcl.[ch]),
the manifestation of tcl-rpm is quite small and reasonable.
[...]
But I wholeheartedly
Jeff Johnson wrote:
SO initializing to NULL was the problem?
The problem is most likely elsewhere altogether.
BUT, initializing it made it appear again - so...
Sick, but I can easily revert to my old fetishistic practices.
Not sure it warrants a change in practices, this
was a workaround
This config change probably went to the wrong devtool target,
%macosx instead of %standalone ? (needed in both, though...)
--anders
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
__
__
Server:
Ralf S. Engelschall wrote:
This config change probably went to the wrong devtool target,
%macosx instead of %standalone ? (needed in both, though...)
No, I intentionally changed both %standalone and %macosx because it is
needed in both and I don't wanted that it is forgotten for %macosx.
devzero2000 wrote:
What approach to using Augeas with RPM should be pursued first
@rpm5.org?
I would be prefer the first. But as other puppist tell me in
other occasion would are the advantage of integrating a
configuration management library in a package manager versus using
puppet or
Ralf S. Engelschall wrote:
Remains the choice of shell. Dash or ash? I prefer the dash
https://wiki.ubuntu.com/DashAsBinSh
Well, for RPM itself I would vote for Dash, but in OpenPKG we use Bash
everywhere. So, from my personal point of view, I would like to see
support for both in RPM... ;-)
Jeff Johnson wrote:
The random disablers that are being slammed into cvs within
24 hours of any added development are -- how shall I say it --
interesting ;-)
I think those are mostly a side effect of the development
breaking the HEAD build with a different ./configure set...
Like a human
Server: rpm5.org Name: Jeff Johnson
Root: /v/rpm/cvs Email: j...@rpm5.org
Module: rpm Date: 20-Apr-2009
17:45:43
Branch: HEAD Handle: 2009042015454201
Added files:
Jeff Johnson wrote:
Sorry for the b0rkage. rpmio/rpmjsio.c will be short lived,
will end up in js/* when finished.
No problem, just checking out the development (pun intended).
--anders
__
RPM Package Manager
Michael Jennings wrote:
We now released RPM 5.1.9, a distribution tarball bugfix
release from the stable RPM 5.1 branch. Find it under:
http://rpm5.org/files/rpm/rpm-5.1/
Other than extraneous liblzma-type files (liblzma.pc, headers,
binaries, and even man pages) being installed under
Pinto Elia wrote:
Log:
rework security CFLAGS without autofu. Add also some other
-AC_ARG_ENABLE(build-optimization,
-AS_HELP_STRING([--enable-build-optimization], [build RPM
instrumented for extra optimization/security (GCC only)]), [dnl
-if test .$enableval = .yes;
cc1: error: unrecognized command line option -fstack-protector
No absolutely, sure. The best portable thing to do is to check the
flags first. What gcc version are you using ?
Apple GCC.
They haven't switched entirely over to LLVM (just yet).
--anders
Pinto Elia wrote:
Modified files:
rpm/scripts gendiff
Log:
drop gendiff checkbashisms complaint; use unipolar branches for
readability
Nice, that'll also fix the FreeBSD problems better than current:
@${REINPLACE_CMD} -e s:/bin/sh:/usr/bin/env bash: \
Tor Lillqvist wrote:
Hello,
I have been doing some initial small steps to make RPM work on
Windows. (Well, a subset, just package management, definitely not the
rpmbuild aspect for instance.)
I have done this using the RPM 4.7 codebase. (Without bothering with
any upstreaming attempts, as
Todd Rinaldo wrote:
Situation: I have an rpm that needs to depend on libjpeg version 8.
The OS this will run on still comes with libjpeg 7. It would break
too many other packages that depend on libjpeg 7 if I were to
upgrade the libjpeg that comes with the OS in place.
Normally some
Jeff Johnson wrote:
There are some very simple data reductions on hierarchical
paths too. One of the best known is
Run a dictionary: assign an integer weighted by # of
occurences to favor small integers for frequently
encountered tokens between /.../ (all of usr and bin
Jeff Johnson wrote:
I was recently looking at making a manifest for FreeBSD,
which consists of a simple files listing for *each package*.
ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8.1-release/All/*.tbz
I was looking at the Slackware MANIFEST as a reference, which
is just a
Matthew Dawkins wrote:
I recently updated my snapshot of 5.2 to build around a perl upgrade to
5.12.2, but I didn't expect any problems really.
Well pkgs that have requires like the following:
Provides: libpq = %{version}-%{release}
now also have this half distepoch after it :2011.1
1 - 100 of 122 matches
Mail list logo
