On Jun 2, 2007, at 1:45 AM, Michael Jennings wrote:
On Friday, 01 June 2007, at 10:30:04 (-0400),
Jeff Johnson wrote:
(aside) Yes there;'s breakage wrto zlib building rpm on x86_64. I
had noticed about 2 weeks ago (I don't normally have access to
x86_64) and the fix is in some tree
On Jun 2, 2007, at 11:19 AM, Michael Jennings wrote:
On Saturday, 02 June 2007, at 09:18:09 (+0200),
Ralf S. Engelschall wrote:
Please do not use Bash features in Autoconf scripts. Please use:
LDFLAGS=`echo $LDFLAGS | sed 's/-pie//g'`
$((...)) is a bash feature. $(...) is not.
$(...)
Hi Andy!
Sorry to hijack the thread, but:
I still have never figured out in my own mind whether compressing
signed headers,
or signing compressed headers, is what I need to implement in rpm.
I'm maybe a month away from an implementation, the preliminaries
to XAR package format are removing
On Jun 4, 2007, at 10:50 AM, Jason Corley wrote:
So what do people think of a reference implementation distribution
around rpm5? I recognize that the politics could quickly overshadow
the utility, but my idea was nothing fancy, no patches, just a
minimalist Linux system that reflects how to
On Jun 4, 2007, at 2:12 PM, Andy Green wrote:
Hatle, Mark wrote:
I'm more of the mindset for this we need to be Fedora based, or some
other common point of reference (both cross compiled and not) so that
it's easy to see what changes we made to another frame of reference.
I'm familiar with
On Jun 4, 2007, at 1:07 PM, Patryk Zawadzki wrote:
As you could see on the pld-devel-en list (a topic called poldek is
dead) there are some problems that seem to be more specific to PLD
than other desktop distros (RHEL or Fedora).
Both RHEL and Fedora have a policy to only ship one-of-a-kind.
On Jun 5, 2007, at 5:17 PM, Jason Corley wrote:
A lot of those macros are bit-rotted at this point. I could narrow
them down to what is actually used by JPackage specs but I figured
exactly what we distribute was best to start with.
Yep.
Wait for the madriva/macros checkin. ;-)
And if you
I started adding robust posix mutexes support to rpm the day I read
this posting:
http://lkml.org/lkml/2006/10/21/183
Here is a patch (against db-4.5.20, other versions of Berekeley DB
are likely extremely
similar) to handle locked mutexes left over from rpm application
abnormal exit
On Jun 6, 2007, at 12:33 PM, Ralf S. Engelschall wrote:
Jeff, small hint: pthread__np(3) functions are non-portable and
not
standard Pthread API additions. If you want to use them and not break
on lots of platforms you at least have to wrap their usage with some
Autoconf-based
There's a design flaw in headerGetEntry() wired into rpm's API.
The 4th arg should have been a ptr to union, not a void ptr.
Since I screw myself with headerGetEntry() way more often than I'm
willing to admit in public, I tried to prototype the 4th argument as a
void ** rather than void *.
On Jun 7, 2007, at 7:37 PM, Olivier Thauvin wrote:
The topic can surprise you, but here the reason of this question.
Rpm has internal dependencies (you can see it in rpm --showrc), and
some of
this dependencies are set into rpm archive (Requirement in header).
I hope all on this list know
On Jun 9, 2007, at 1:40 PM, Jeff Johnson wrote:
On Jun 9, 2007, at 12:54 PM, Ralf S. Engelschall wrote:
I'll clean sweep the changes from rpm-4_5 and have on HEAD
by next weekend?
I should supply more details and start setting some explicit guidelines.
All changes on rpm-4_5
On Jun 9, 2007, at 2:58 PM, Olivier Thauvin wrote:
This software is munin, and there are other application doing that.
If the packaging can't be changed, then I'll resurrect everywhere
compatible
%clean behavior for Mandriva.
The vast majority of spec files are not doing anything more
All --
I'm gonna try to rearrange rpm packaging today quite dramatically.
And I'll likely screw up the packaging, rpm is so unforgiving ;-)
I'm hoping to get what I think are necessary big changes out of the way
as soon as possible. I'm more than willing to revert any/all changes
that anyone
On Jun 10, 2007, at 9:06 PM, Jason Corley wrote:
I can do RHEL 3, 4, and 5.
OK. I had hoped to have gotten farther, but the wifey has been
patient all
weekend and is starting to look rather bored. So ...
My last build this evening is at
On Jun 11, 2007, at 9:43 AM, Ralf S. Engelschall wrote:
On Mon, Jun 11, 2007, Jeff Johnson wrote:
plug the other memory leaks too.
Thanks, Jeff. That's exactly what I hoped you will do ;-)
Be forewarned: There's some weird complicated issues with
huge legacy ramifications regarding
This is likely a popular thread (if I'm not mistaken ;-).
Permitting rpmbuild to produce noarch sub-packages is mostly as simple
as changing the arch argument to headerAddEntry() in build/
parseSpec.c:612
(void) headerAddEntry(pkg-header, RPMTAG_ARCH,
RPM_STRING_TYPE,
On Jun 14, 2007, at 12:28 PM, Wichmann, Mats D wrote:
[EMAIL PROTECTED] wrote:
The LSB packaging cabal has decided that what 3rd party ISV's really
want is the ability to run their own installers on rpm managed
systems.
jeez, you always have to put things in such positive terms,
doncha?
Development on rpm cvs HEAD is well under way. I can almost
see what I was working on before rpm5.org setup distracted me.
Note: For those who believe that rpm should not automatically import
pubkeys, disable (by commenting out or setting to %{nil}) these two
macros
and stop reading now:
On Jun 14, 2007, at 2:32 PM, Wichmann, Mats D wrote:
Not likely. InstallShield probably has a good 90+% of the ISV
installer market, and they have supported RPM since 2004.
InstallShield supports RPM, but many ISVs don't use that support
because the software in question is also released
On Jun 15, 2007, at 4:56 AM, Ralf S. Engelschall wrote:
On Fri, Jun 15, 2007, Jeff Johnson wrote:
Should we build rpm-5.0-0.1? I see no reason not to.
You mean to really _roll_ a SRPM? Let's wait a few more hours as I'm
still hacking wild on HEAD. I got HEAD now FINALLY building under
*non
On Jun 15, 2007, at 10:01 AM, Ralf S. Engelschall wrote:
On Fri, Jun 15, 2007, Jeff Johnson wrote:
linux amd64/ppc cannot reuse a va_list. make a copy instead.
The use of va_copy is the right fix. Unfortunately, from my
experiences
I know that va_copy is still a horribly unportable
On Jun 15, 2007, at 12:56 PM, Ralf S. Engelschall wrote:
On Fri, Jun 15, 2007, Jeff Johnson wrote:
On Jun 15, 2007, at 12:09 PM, Ralf S. Engelschall wrote:
Ok, thanks for the hint.
You've likely seen
foo = xmalloc(...)
...
foo = _free(foo)
habits of mine. Feel free to suggest
On Jun 15, 2007, at 1:45 PM, Ralf S. Engelschall wrote:
On Fri, Jun 15, 2007, Jeff Johnson wrote:
Yes, I've seen that _free is spreaded in the sources in a rather
redundant way. What about the following in system.h and then
replace all
foo = _free(foo); with just xfree(foo)?
#define
In order to clear the construction dust from the cvs tree branches,
I've just built and uploaded rpm-5.0-0.1.src.rpm to
http://rpm5.org/files/rpm/rpm-5.0
I've added file internal, and reverted the spec file to the contents
that I normally distribute with rpm (i.e. reverting last weekends
After thinking really hard and long, the obvious and simple solution
of adding per-version configuration and helpers and ... in a per-version
directory seems best to me.
There are certainly other solutions. Feel free to suggest alternatives.
Meanwhile, I needed a solution, and there's certainly
On Jun 18, 2007, at 5:13 PM, Ralf S. Engelschall wrote:
Yes, the CVS files you had directly correspond to the files we have
in the max-rpm module -- just modulo a generated file and two lines
changes to the XML stuff AFAIK. So we should try to regenerate this
stuff in our max-rpm module via
On Jun 19, 2007, at 10:37 AM, Mark Hatle wrote:
I believe the MYPATH stuff is specified this way so that the items in
/bin and /usr/bin take precedence when RPM is discovering the
locations
of /bin/sh, grep, sed, cut, etc.. all of the things that get encoded
into the rpm-macros file.
I
On Jun 19, 2007, at 12:20 PM, Ralf S. Engelschall wrote:
On Tue, Jun 19, 2007, Jeff Johnson wrote:
Getting mmap enabled is likely a large performance win.
Maybe, yes. I've now added the missing Autoconf glue AC_FUNC_MMAP for
checking whether the system supports a reasonable mmap(2). Let's
On Jun 20, 2007, at 9:57 AM, Jeff Johnson wrote:
completiion. At that point bug, identifying the feature set for
rpm-4_5
--^ fixing and ...
73 de Jeff
__
RPM Package Manager
On Jun 20, 2007, at 1:02 PM, Jason Corley wrote:
1.1 +95 -0 rpm/scripts/brp-java-repack-jars
Please please please don't do anything with this other than look at
it... It causes immense pain for us in JPackage land, so much so that
we are officially recommending committers
On Jun 20, 2007, at 3:04 PM, Ralf S. Engelschall wrote:
On Tue, Jun 19, 2007, Ralf S. Engelschall wrote:
[...]
We investigated another workday and now have the changes bug fixed,
polished up and also tested on a number of non-Linux platforms. We are
still testing under Solaris, but once we
On Jun 21, 2007, at 4:59 AM, Ralf S. Engelschall wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
__
__
Server: rpm5.org Name: Ralf S. Engelschall
Root: /v/rpm/cvs
On Jun 21, 2007, at 9:08 AM, Ralf S. Engelschall wrote:
Although %setup and %patch look like regular RPM macros on the first
spot they are not real macros, of course. Instead they are parsed and
treated very special by RPM internally.
Unfortunately, this internal handling didn't allow for any
On Jun 21, 2007, at 9:29 AM, Ralf S. Engelschall wrote:
On Thu, Jun 21, 2007, Jeff Johnson wrote:
Are there hi-resolution timers available on *BSD w/o a gettimeofday
system call? Just curious. rdtsc has its own problems, but does make
examining strace more pleasant, gettimeofday gets really
On Jun 21, 2007, at 9:27 AM, Ralf S. Engelschall wrote:
On Thu, Jun 21, 2007, Jeff Johnson wrote:
As I watch the vendor defines proliferate, I wonder whether
#if defined(HAVE_DIRENT_D_OFF)
might not be a better approach.
Yes, in general we always have to prefer feature tests instead
This thread makes me kinda sad
https://www.redhat.com/archives/fedora-devel-list/2007-June/
msg02196.html
The gist of the thread is that some *really* smart hackers are no
longer capable
of changing what is ultimately a trivial call in rpmlib to
strcmp(i586, i686)
And no one seems
On Jun 21, 2007, at 12:12 PM, Ralf S. Engelschall wrote:
This certainly is confusing at the first spot, but OTOH better to
keep it this way than to automatically expand to an empty string. The
%{?bar}%{?!bar:bar} construct is handy enough and even the
expansion of
%foo to %foo is used in
On Jun 21, 2007, at 12:27 PM, Jeff Johnson wrote:
On Jun 21, 2007, at 12:12 PM, Ralf S. Engelschall wrote:
This certainly is confusing at the first spot, but OTOH better to
keep it this way than to automatically expand to an empty string. The
%{?bar}%{?!bar:bar} construct is handy enough
On Jun 21, 2007, at 12:35 PM, Jeff Johnson wrote:
That way all path macros can be defined trivially as
%__mv %{?=_mv}
Another nice touch. All undefined %__foo macros could be default
initialized as
%{?=_foo}
by rule, and then there is no need for macros.path baggage
On Jun 21, 2007, at 12:42 PM, Mark Hatle wrote:
This brings up something we've discussed here at Wind River. Would it
be possible to make %setup and/or %patch into macros (perhaps using
lua?) (I'm thinking for rpm5 - HEAD, not 4_5.)
Why ask for a buttload of legacy pain? Just use names
On Jun 21, 2007, at 1:32 PM, Ralf S. Engelschall wrote:
So as a short-hand I personally would expect something like
%{?__bar:-bar}
Noted. I 'spose I can figger a 2 character token lexer in the year
2007 ;-)
(similar to the Bourne-Shell construct) or if this breaks the usual
syntax
On Jun 21, 2007, at 1:33 PM, Ralf S. Engelschall wrote:
On Thu, Jun 21, 2007, Jeff Johnson wrote:
On Jun 21, 2007, at 12:35 PM, Jeff Johnson wrote:
That way all path macros can be defined trivially as
%__mv %{?=_mv}
Another nice touch. All undefined %__foo macros could
While there's nothing wrong withe your patch, there's simply
no reason not to just pass *all* patch options directly to
patch. That dumps a bunch of silly code from rpmbuild.
The reason for the parsePrep.c jiggery pokery is transparently remapping
ancient patch's CLI option change that was
On Jun 21, 2007, at 2:11 PM, Ralf S. Engelschall wrote:
On Thu, Jun 21, 2007, Jeff Johnson wrote:
On Jun 21, 2007, at 1:33 PM, Ralf S. Engelschall wrote:
[...]
We should be carefully and not introduce too much magic here
or nobody else will ever understand it ;-)
I bow to the autoconf
On Jun 21, 2007, at 4:20 AM, Ralf S. Engelschall wrote:
Ok, please retry with the latest incarnation of RPM_CHECK_LIB in HEAD.
You should be now able to build with a simple --with-beecrypt[=yes] in
order to build against a BeeCrypt in default system locations. I've
still not tried it myself
On Jun 22, 2007, at 9:10 AM, Alex Myltsev wrote:
Hello,
what is the best way to store (more or less) arbitrary metadata in
RPM headers?
The issue for rpm is arbitrary because any metadata in headers (if
successful)
will eventually need a well defined usage semantic.
The thing is,
Time to get with the RPM_CHECK_LIB program.
I managed to fumble my way to a successful build last
night. Now I'm trying to get a fire-and-forget setup
together.
Here's the linux build I usually do:
db internal
zlibinternal
fileinternal
lua internal
neon
On Jun 22, 2007, at 11:50 AM, Ralf S. Engelschall wrote:
Log:
allow people like Jeff to build with more internal stuff
(although I
personally think we shouldn't do this ;-)
We agree.
I still gotta get 4.5/5.0 srpm snapshots together this evening.
Shall I feature regress?
73
On Jun 22, 2007, at 11:58 AM, Ralf S. Engelschall wrote:
On Fri, Jun 22, 2007, Jeff Johnson wrote:
All fine except that I think file (as it is not modified, isn't it?)
you can easily keep externally.
Yes, file is unmodified.
The ratinale for internal file is solely to control for magic
On Jun 22, 2007, at 12:32 PM, Jeff Johnson wrote:
OK. I'll likely have more info shortly.
Here's config.status snippet:
s,@CFLAGS@,|#_!!_#|-g -O2 -fPIC -DPIC -D_GNU_SOURCE -D_REENTRANT -
Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wno-
char-subscripts -fpie -I/usr
On Jun 24, 2007, at 4:19 PM, Pawel A. Gajda wrote:
rpm -qa slowness (even with --no{digest,signature}) makes poldek
(suppose other tools too) uncomfortable in use. Although poldek
manages its own rpmdb cache, every installation/removal made by rpm
(and other tools) forces package database
On Jun 24, 2007, at 5:50 PM, Alex Myltsev wrote:
In ALT Linux we often use uncompressed tarballs as RPM Source files.
RPM's LZMA compression support breaks our packages: in many cases, the
tarball will contain zeroes at offsets 9..12, and isCompressed() will
report it to be an LZMA-compressed
On Jun 26, 2007, at 12:28 PM, Tim Mooney wrote:
rpm 4.4.9 on sparcv9-sun-solaris2.8 (LP64) compiled with the Sun
Workshop
11 compiler gets a reproduceable SIGBUS when installing a package or
importing a key with a fresh database. I haven't seen this problem on
my x86_64-sun-solaris2.10
On Jun 27, 2007, at 2:55 PM, Tim Mooney wrote:
This bug was reported by PLD/sparc64 abt a week ago. There's an
alignment
issues with hcolor. See recent checkin for fix on both HEAD and
rpm-4_5.
Thanks for the info, sorry for the duplicate report.
Heh, thanks for reporting even if
On Jun 27, 2007, at 3:20 PM, Ralf S. Engelschall wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
__
__
Server: rpm5.org Name: Ralf S. Engelschall
Root: /v/rpm/cvs
On Jun 27, 2007, at 6:44 PM, Ralf S. Engelschall wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
__
__
Server: rpm5.org Name: Ralf S. Engelschall
Root: /v/rpm/cvs
On Jun 28, 2007, at 5:33 AM, 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.
This thread is likely the only doco on
On Jun 28, 2007, at 2:06 AM, Ralf S. Engelschall wrote:
Fair enough! It certainly is a difficult balance between avoiding the
trouble with lusers and still allowing packagers to build RPM with an
external Berkeley-DB _without_ having to patch the RPM sources.
The only patch is the robust
On Jun 28, 2007, at 11:52 AM, Ralf S. Engelschall wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
__
__
Server: rpm5.org Name: Ralf S. Engelschall
Root: /v/rpm/cvs
On Jun 28, 2007, at 12:06 PM, Arkadiusz Miskiewicz wrote:
On Thursday 28 of June 2007, Jeff Johnson wrote:
On Jun 28, 2007, at 2:06 AM, Ralf S. Engelschall wrote:
Fair enough! It certainly is a difficult balance between avoiding
the
trouble with lusers and still allowing packagers to build
On Jun 28, 2007, at 12:42 PM, Mark Hatle wrote:
I'd like to see the memory db implemented.. but so far, no time. I
think that makes the most sense in this case though.
What is memory db? Using DB_PRIVATE? That also disables
all locking, forcing fcntl exclusive/shared.
73 de Jeff
On Jun 28, 2007, at 2:28 AM, Russell Coker wrote:
When upgrading a package with RPM version 4.4.2 in SUSE doesn't
call fsync()!
It creates a temporary file (without using O_SYNC), writes all the
data to
it, closes it, and then renames it to replace the original file.
The temporary file
On Jun 28, 2007, at 3:45 PM, Arkadiusz Miskiewicz wrote:
On Thursday 28 of June 2007, Jeff Johnson wrote:
On Jun 28, 2007, at 3:13 PM, Arkadiusz Miskiewicz wrote:
On Thursday 28 of June 2007, Jeff Johnson wrote:
The setup always has been nptl ready (glibc 2.6; = 2.6.16 kernels)
NPTL
On Jun 29, 2007, at 12:44 PM, Tim Mooney wrote:
Why don't you include an rpm-bug-report script, a la bashbug, that
automates much of that, including relevant information about how rpm
was configured, the environment, etc, and then update the docs and
begin
to encourage users to use that
I have a feature deliverable with my name attached.
Next weekend I start converting *.rpm to *.xar format.
Originally, I planned to do the development on a branch.
However, after seeing recent breakages, I will be doing my
development on HEAD, just like everyone else.
I will be building rpm
On Jun 29, 2007, at 6:04 PM, Russell Coker wrote:
On Saturday 30 June 2007 02:04, Jeff Johnson [EMAIL PROTECTED] wrote:
Should I add O_SYNC when opening files on delayed write file systems?
Doable, but annoying mapping the path back to a file system type to
infer functionality.
O_SYNC
On Jul 2, 2007, at 5:23 AM, Ralf S. Engelschall wrote:
H... I've today test-rolled an RPM 5 tarball for myself and
recognized that the resulting file is about 12MB in size:
-rw-r--r-- 1 rse rse 12180476 Jul 2 11:05 rpm-5.0.tar.gz
The unpacked RPM 5 sources have 57MB in size but
On Jul 3, 2007, at 6:19 AM, Michael Schroeder wrote:
On Tue, Jul 03, 2007 at 08:10:04PM +1000, Russell Coker wrote:
Do you consider systems that lose data, have internal databases
that don't
match their own state, and generally cause down-time for people to be
correct?
You might as well
%__tar instead of %_tarbin. I fixed that but haven't checked in.
73 de Jeff
On Jul 2, 2007, at 8:55 PM, Mark Hatle wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
__
__
Server: rpm5.org
On Jul 2, 2007, at 11:36 AM, Ralf S. Engelschall wrote:
In SQLite we can precompile expressions to make the queries
faster. We
don't have this implemented because there is no way to Compile and
Execute the queries except in real time. In some informal testing
way back when the initial
On Jul 3, 2007, at 11:53 AM, Ralf S. Engelschall wrote:
On Tue, Jul 03, 2007, Mark Hatle wrote:
Jeff Johnson wrote:
IMHO, this is the wrong fix.
per-system configuration belongs in the per-system configuration
directory, which is /etc everywhere.
scarcasm
Or perhaps I missed some n00bie
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 3, 2007, at 1:16 PM, Olivier Thauvin wrote:
BTW: The API of this function seems a bit complicated for any
external tools
and probably many argument are not usefull for most of them.
What about having a simplified wrapper
On Jul 3, 2007, at 1:50 PM, Michael Schroeder wrote:
On Tue, Jul 03, 2007 at 12:49:14PM -0400, Jeff Johnson wrote:
On Jul 3, 2007, at 12:16 PM, Michael Schroeder wrote:
No, as one needs a patch to Berkeleydb to make it support
individual syncing.
What's the patch? Overloading the sync
On Jul 3, 2007, at 5:39 PM, Mark Hatle wrote:
Ok, I found the problem, but I don't know how to fix it.. The code in
lib/rpmgi.c
if (!(gi-flags RPMGI_NOHEADER)) {
h = rpmgiReadHeader(gi, fn);
if (h != NULL)
rpmrc = RPMRC_OK;
} else
On Jul 4, 2007, at 3:56 AM, Michael Schroeder wrote:
On Tue, Jul 03, 2007 at 04:04:22PM -0500, Mark Hatle wrote:
The manifest files don't seem to be working for me. But I can't
debug
rpm due to it being stripped.
A manifest file needs to be at least 96 bytes long (the size of
the rpm
Actually I think this patch is unneeded.
I do believe Mark has a typo in his manifest that he needs to correct
before we starting mucking about with rpmgi behavior.
73 de Jeff
On Jul 4, 2007, at 12:16 PM, Ralf S. Engelschall wrote:
RPM Package Manager, CVS Repository
On Jul 4, 2007, at 12:28 PM, Mark Hatle wrote:
Mark Hatle wrote:
Jeff Johnson wrote:
Actually I think this patch is unneeded.
I do believe Mark has a typo in his manifest that he needs to
correct
before we starting mucking about with rpmgi behavior.
Wait.. the system (due to the ENOENT
On Jul 4, 2007, at 12:52 PM, Mark Hatle wrote:
Reproducer. Build rpm5 HEAD as of about 15 minutes ago...
(remove the workaround for the ENOENT)
rpm5/HEAD/rpm/configure --disable-nls --with-libelf --without-selinux
--without-perl --without-python --with-zlib --with-bzip2 --with-
beecrypt
Not sure what happened to this message, so here it is again.
Begin forwarded message:
From: Jeff Johnson [EMAIL PROTECTED]
Date: July 5, 2007 11:54:19 AM EDT
To: rpm-devel@rpm5.org
Subject: Adding rpm-common, eliminating rpmrc entirely.
The last remaining usage case that I'm aware
On Jul 8, 2007, at 4:34 PM, Ralf S. Engelschall wrote:
On Sun, Jul 08, 2007, Jeff Johnson wrote:
AFAICT, the core problem preventing populating dependency_libs
is that automake is confused by having two -lz libraries.
Can you be more specific here, Jeff? What particular
error occurs under
On Jul 10, 2007, at 1:44 PM, Ralf S. Engelschall wrote:
On Tue, Jul 10, 2007, Jeff Johnson wrote:
On Jul 10, 2007, at 12:36 PM, Ralf S. Engelschall wrote:
On Tue, Jul 10, 2007, Jeff Johnson wrote:
[...]
For a native approach see what I've done with mod_so in Apache.
For Apache 2.2 you
rpmsx is on death row, libselinux now has methods to achieve
the same parsing.
Updating SELinux is likely the most important patch that needs merging
from rpm.org, the issue is that the patch is not sensitive to --
disable-selinux
compilation because of hardwired
#include selinux.h
But
This ancient bug
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=83006
keeps resurfacing.
It's trivial to add to main()
mode_t mask = 002;
(void) umask(mask)
and ignore the umask issue forevermore.
The trickier problem is that once rpm starts to manage its own
environment,
Nice. Thanks for the help.
73 de Jeff
On Jul 10, 2007, at 3:46 PM, Ralf S. Engelschall wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
__
__
Server: rpm5.org Name:
On Jul 10, 2007, at 3:48 PM, Ralf S. Engelschall wrote:
On Tue, Jul 10, 2007, Arkadiusz Miskiewicz wrote:
On Tuesday 10 of July 2007, Ralf S. Engelschall wrote:
On Tue, Jul 10, 2007, Mark Hatle wrote:
For something to software installs, I think it's reasonable to
set the
default umask
On Jul 10, 2007, at 6:55 PM, Russell Coker wrote:
On Wednesday 11 July 2007 05:26, Jeff Johnson [EMAIL PROTECTED] wrote:
But +1 for the 2 line hack noted.
Another +1.
The sys-admin should be able to run rpm and have the packages
either correctly
installed or the installation should
On Jul 10, 2007, at 8:04 PM, Olivier Thauvin wrote:
Here a classic scenario observed with rpm 4.4.8:
vi /etc/foo.config
rpm -Uvh foo...rpm
= /etc/foo.config which is %config(noreplace) in foo...rpm were
replace.
This does not happend when /etc/foo.config was own by a package.
This is a
On Jul 11, 2007, at 5:40 AM, Michael Schroeder wrote:
On Tue, Jul 10, 2007 at 03:14:11PM -0400, Jeff Johnson wrote:
This ancient bug
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=83006
keeps resurfacing.
It's trivial to add to main()
mode_t mask = 002;
Uh, not 002 please
On Jul 11, 2007, at 7:00 AM, Ralf S. Engelschall wrote:
On Wed, Jul 11, 2007, Michael Schroeder wrote:
On Tue, Jul 10, 2007 at 03:14:11PM -0400, Jeff Johnson wrote:
It's trivial to add to main()
mode_t mask = 002;
Uh, not 002 please, 022 is the standard. Make it configurable if you
On Jul 12, 2007, at 11:39 AM, Jay Soffian wrote:
On Jul 12, 2007, at 7:20 AM, Jeff Johnson wrote:
mmazur from PLD has asked for support for combined install/erase
transactions from the rpm command line.
The syntax (planned for years) will be
rpm -Uvh -- +foo.rpm -bar
to create
On the feature set of rpm-5.0 is an integrated dependency solver.
A dependency solver needs information about the package universe.
The information is time sensitive, and is usually not resident on the
local client.
Which means that an integrated dependency solver must undertake
transport
On Jul 13, 2007, at 11:24 AM, Mark Hatle wrote:
My preference is external helpers. I'm not sure if curl, wget, and/or
rsync is the right interface though.
Another external helper vote tallied.
I'd like to see something that goes out and says I need the following
information, and then the
On Jul 13, 2007, at 1:02 PM, Jay Soffian wrote:
On Jul 13, 2007, at 11:43 AM, Jeff Johnson wrote:
On Jul 13, 2007, at 11:24 AM, Mark Hatle wrote:
My preference is external helpers. I'm not sure if curl, wget,
and/or
rsync is the right interface though.
Another external helper vote
I fixed a problem with file magic previously, now this
make tmacro
...
macro.c: In function ‘expandMacro’:
macro.c:1455: error: ‘rpmlua’ undeclared (first use in this function)
macro.c:1455: error: (Each undeclared identifier is reported only once
macro.c:1455: error: for each function it
On Jul 14, 2007, at 11:10 AM, Paweł A. Gajda wrote:
Since 4.4.7 rpm checks (auto-generated) dirnames deps, but I haven't
found how to ask rpmdb for packages which requires particular
directory,
i.e. something like:
$ rpm -q --what-requires-dir /etc
Is there any way to do this? I need it
On Jul 14, 2007, at 11:22 AM, Paweł A. Gajda wrote:
On 7/14/07, Jeff Johnson [EMAIL PROTECTED] wrote:
On Jul 14, 2007, at 3:37 AM, Ralf S. Engelschall wrote:
For RPM itself it could make sense to ship with either #%
_extra_tags
* (backward compatibility mode), %_extra_tags X-* (escaping
On Jul 14, 2007, at 4:30 PM, Mark Hatle wrote:
Ralf S. Engelschall wrote:
On Sat, Jul 14, 2007, Jeff Johnson wrote:
[...]
I don't agree, but I do not wish to discuss further. The cost of
the discussion is already higher than the cost of the preemptive
implementation.
Lusers asked
Thank you.
A regression test of macro syntax is almost certainly gonna be
needed, sez'
the guy who just spent the day debugging a smallish %patch macro
expansion.
Recursive expansions are tough debugging.
I shudder when I think of the amount of time that I will have to
spend on IRC
dumpasn1 is carried for X.509 signatures somewhen.
On Jul 14, 2007, at 6:45 PM, Ralf S. Engelschall wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
__
__
Server: rpm5.org
1 - 100 of 1739 matches
Mail list logo
