Jeff Johnson wrote:
On Jun 8, 2007, at 9:35 AM, Andy Green wrote:
Jeff Johnson wrote:
2) absolute argv[0] path will be used if present to find
configuration. relative argv[0] path will be
made absolute using PATH lookup.
That sounds like a very good idea, cf compilers finding
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.)
The reason we're interested is that we have mechanisms that track
patches being applied (think quilt), and
In my environments, I setup the compiler and CFLAGS before calling
configure w/ the right information to build 32, or 64 bit binaries.
Having configure try to guess and pass in additional values is a royal
pain. Passing in --libdir=/usr/lib64 (or equiv) is really the right
answer. There
Ralf, keep on chopping.. I owe you a beer or beverage of choice! (This
makes cross compiling SOOO much easier with this stuff removed.)
--Mark
Ralf S. Engelschall wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
This actually points out a bug I found the other day, but haven't been
able to figure out how to solve.
Using echo $* in this way causes variable or argument expansions that
include a space to fail.
We have a few cases where we need to pass in CFLAGS w/ multiple elements
or CC='distcc ccache
Ralf S. Engelschall wrote:
On Wed, Jun 27, 2007, Mark Hatle wrote:
This actually points out a bug I found the other day, but haven't been
able to figure out how to solve.
Using echo $* in this way causes variable or argument expansions that
include a space to fail.
We have a few cases
I'd have to double check this in the code, but if the __dbabi is 0 (or
maybe it was -1), rpm will work w/ both sqlite and db databases..
basically it'll try to open it as one, if it can't it'll fall back to
the other format. (I don't remember the order it looks in.)
--Mark
Ralf S. Engelschall
Ahh you just reminded me of a bug. I'm not sure how to fix this using
the dynamic values.. But basically, Depends can't be in the _dbi_tags
if you are using sqlite. If you notice in the fragment below, on db3
it's setup as a temporary private database used for single-run
optimization. On the
Is TEMPORARY TABLE something special? I knew about the :memory:
before, but not the other.
Otherwise this looks good to me. It may even speed things up slightly.
--Mark
Ralf S. Engelschall wrote:
On Thu, Jun 28, 2007, Mark Hatle wrote:
Ahh you just reminded me of a bug. I'm not sure how
I can't configure while outside of the RPM src directory. A relatively
simple change to acinclude.m4 appears to fix the problem.. But there are
other problems later, where it appears the db3 stuff isn't configured.
I figured I would start w/ the simple patch, and hope it leads to some
quick
For the case w/o db3 header being available, there is the db_emu.h
file. Put that value in there, and it is supposed to be picked up if db
items are not defined.
--Mark
Ralf S. Engelschall wrote:
On Thu, Jun 28, 2007, Mark Hatle wrote:
Is TEMPORARY TABLE something special? I knew about
Jeff Johnson wrote:
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 with the same stuff that has been in rpm
for years. That includes internal db,
Any objections to the attached change?
I believe this will work in any POSIX shell. The idea is instead of
processing all of the arguments and possibly blowing away quoting and
such, we process them one at a time and use shift and set to recreate
the argument list.
In my testing, this fixed the
Ralf S. Engelschall wrote:
On Mon, Jul 02, 2007, Mark Hatle wrote:
Ralf S. Engelschall wrote:
On Mon, Jul 02, 2007, Jeff Johnson wrote:
On Jul 2, 2007, at 5:23 AM, Ralf S. Engelschall wrote:
[...]
it is time to start the engineering to get
(*dbiCompile) and (*dbiExec) methods
I don't think the internal dependency generator is working in HEAD.
I'm currently tracing through the code trying to understand what is
happening.. as far as I can tell it gets into rpmfcApply and the ddict
is empty. So it never generated the per file dependencies.
Any pointers on where to
Jeff Johnson wrote:
On Jul 3, 2007, at 1:09 PM, Mark Hatle wrote:
Jeff Johnson wrote:
What behavior is expected if the _rpmfc_magic_path is not set, but yet
rpm was compiled w/ HAVE_MAGIC_H?
UNSPECIFIED ;-)
Ok, I'll go with the pretend there is no magic_h/file available
currently using...
--Mark
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 lead). Maybe
Jeff Johnson wrote:
On Jul 4, 2007, at 3:54 AM, Mark Hatle wrote:
I am getting the following error after using rpm to install source
packages:
Is the srpm signed?
Add --nosignature to not access a rpmdb installing a src.rpm.
Alternatively, try importing the pubkey.
The above
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) never got to the point of loading
the manifest.. so
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.
If having a typo in the manifest (on a query) causes a failure, this is
new behavior. The commands I am
Jeff Johnson wrote:
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
The only thing I can think of is it's either configuration or OS
dependent. I'm running FC7 currently.
--Mark
Jeff Johnson wrote:
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
Jeff Johnson wrote:
I suspect that at least for elf, RPMTAG_FILEBUILDID should be added to
package
metadata, if for no other reason, so that the 2 proposed symlinks can be
created as
a side effect of installing the file without the additional files being
added to all packages.
Are non-elf
Arkadiusz Miskiewicz wrote:
Try this:
./configure LDFLAGS=-Wl,--as-needed
It will fail miserably because things are not linked properly.
Do we actually need separate librpmXYZ for anything?
Doing single librpm.so would solve the problem.
quick summary of the discussion we had on #rpm
The mono-find-provides file appears to have been missed in the previous
check in.
--Mark
__
RPM Package Managerhttp://rpm5.org
Developer Communication List
I'll leave that to someone else.. probably should file a defect in the
tracker on this. I just copied it wholesale so I could build HEAD again.
--Mark
Arkadiusz Miskiewicz wrote:
On Friday 13 of July 2007, Mark Hatle wrote
My preference is external helpers. I'm not sure if curl, wget, and/or
rsync is the right interface though.
I'd like to see something that goes out and says I need the following
information, and then the external interface can then use curl, wget,
rsync, neon, or something custom to do what it
options to
disappear.
I don't see a simple implementation for this, so should I back
out/disable by change for now?
--Mark
Hmmm ...
73 de Jeff
On Jul 12, 2007, at 10:11 PM, Mark Hatle wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs
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 for the implementation, now deal with the consequences
Jeff Johnson wrote:
Thanks for the %patchNN rewrite. Holler if %patch breaks.
I'm about to run it through another build sanity check.. (thats how I
noticed the '\' was missing suddenly nothing was patched..)
--Mark
On Jul 14, 2007, at 7:03 PM, Mark Hatle wrote:
RPM Package Manager, CVS
Ok, I'm not sure how to resolve this other then in the specfile.
The vim package (from Fedora Core) is doing:
PATCH001: foo
%patch001
This is failing with:
cat: %PATCH001: No such file or directory
Any suggestions? (Any easy way to trim leading zeros?)
--Mark
I just noticed the macro files was getting host information instead of
target information. Attached is a patch to change references from build
to target.
Since I'm not the autoconf wizard, I didn't want to commit this until it
was reviewed.
Ralf?
--Mark
Index: configure.ac
Thomas Lotterer wrote:
I tried to understand the view points of all authors in recent
discussions on this list regarding the developer build environment,
handling of extra metadata, hooks and calls to external helper
applications and support for embedded script languages. I failed.
In the
sure how to deal
with that in a general case.
So the values that I am using in a modifiable way are:
/etc/rpm/sysinfo - %{_etcrpm}/sysinfo
LOCALEDIR
RPMPOPTFILE
_usrlibrpm
_etcrpm
/etc/rpm/platform - %{_etcrpm}/platform
--Mark
Ralf S. Engelschall wrote:
On Mon, Jul 16, 2007, Mark Hatle wrote
I think this is a good check to add. Basically what it does is check
the files for embedded references to the buildroot location vs the
expected install location.
--Mark
Robert Scheck wrote:
On Mon, 16 Jul 2007, Jason Corley wrote:
So being far too lazy to look on my own, what is
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.
...
After about 6
Olivier Thauvin wrote:
Le mardi 17 juillet 2007, Ralf S. Engelschall a écrit :
1. except for very small and harmless hacks, the RPM 5 build environment
is now really acceptably clean and mostly untwisted
again. Especially, mostly all hard-coded (and often even
distribution-specific)
Ralf S. Engelschall wrote:
Jeff: what about rolling daily _SNAPSHOT_ tarballs for RPM 5 (like
rpm-5.0-SNAPSHOT-MMDD.tar.gz)? These would already contain all the
pre-generated files from ./devtool autogen and this way we could let
people more easy try out our latest sources without the need
Ralf S. Engelschall wrote:
On Tue, Jul 17, 2007, Peter O'Gorman wrote:
On Tue, 2007-07-17 at 09:37 -0500, Peter O'Gorman wrote:
On Tue, 2007-07-17 at 10:19 +0200, Ralf S. Engelschall wrote:
Well, I do have to ask why you're using here, I think it
ought to be
Jeff Johnson wrote:
On Jul 17, 2007, at 12:10 PM, Mark Hatle wrote:
Jeff Johnson wrote:
On Jul 17, 2007, at 11:37 AM, Mark Hatle wrote:
*) file based provide and requires (again WR is not using this... yet)..
but having a mechanism to define dependencies on individual files vs on
a per
Jeff Johnson wrote:
On Jul 17, 2007, at 4:29 PM, Mark Hatle wrote:
I agree, doesn't make sense to have multiple occurrences, but I need to
be able to change the location based on run-time path. :P
Why? You plain and simply shouldn't be using per-system configuration paths
if the paths
I was looking at something today, and noticed that the MIPS64 n32
dependencies did not get (32bit) appended to them... I looked briefly
and found the place where that would need to be done. But what I didn't
understand is how to tell if the item was N32 or not?
(I'm also not finding where the
Thomas Lotterer wrote:
On Monday, 30. July 2007 at 9:26 pm, Jeff Johnson [EMAIL PROTECTED] wrote:
On Jul 30, 2007, at 2:58 PM, Thomas Lotterer wrote:
Decision:
- exclusively use Berkeley DB
I'd change exclusively to primarily. Otherwise we have an
external feature regression.
That's
Jeff Johnson wrote:
There is also the existing %_solve_dbpath. There is a need for a per-rpmts
database for headers passed to rpmtsAddInstallElement that could/should
be used to eliminate the nasty code with a largish in-memory footprint in
lib/rpmal.c.
But if other means to an integrated
Thomas Lotterer wrote:
On Tuesday, 31. July 2007 at 3:04 pm, Jeff Johnson wrote:
On Jul 31, 2007, at 5:02 AM, Thomas Lotterer wrote:
On Monday, 30. July 2007 at 9:26 pm, Jeff Johnson wrote:
On Jul 30, 2007, at 2:58 PM, Thomas Lotterer wrote:
Decision:
- exclusively use Berkeley DB
3)
I strongly suggest that the Copyright be amended to either be you jbj or
rpm5.org or something. Leaving it at 2002 - Red Hat may give the wrong
impression as to the status of this fork.
--Mark
Jeff Johnson wrote:
Index: rpm/rpmqv.c
Jeff Johnson wrote:
On Jul 31, 2007, at 6:39 PM, Mark Hatle wrote:
Thomas Lotterer wrote:
On Tuesday, 31. July 2007 at 3:04 pm, Jeff Johnson wrote:
On Jul 31, 2007, at 5:02 AM, Thomas Lotterer wrote:
On Monday, 30. July 2007 at 9:26 pm, Jeff Johnson wrote:
On Jul 30, 2007, at 2:58 PM
When cross-compiling the rpm python module I'm getting a bogus -rpath
being added to the compilation.
The problem is the code is designed to be run on the target and is
picking up host libraries and corrupting my build.
The python/Makefile.am has no references to -rpath $(rpmdir), but the
Jeff Johnson wrote:
On Aug 1, 2007, at 4:03 PM, Mark Hatle wrote:
SQLite has a locking mechanism that will work on shared filesystems (w/
proper locking.) Ignore NFS.. thats just one way to get a shared
filesystem, but not the only way.) The assumption here is we have a
shared
Ralf S. Engelschall wrote:
On Wed, Aug 08, 2007, Mark Hatle wrote:
I'm trying to use lua to implement some complex transaction scripts..
specifically adduser, addgroup and chkconfig functionalities. Due to my
cross compile environment, I can't actually execute the adduser,
addgroup
Jeff Johnson wrote:
On Aug 8, 2007, at 4:19 PM, Mark Hatle wrote:
Where does this DSO live? If it's inside of the chroot, I'm back to
where I started because the chroot contains code that I can't possibly
execute.
If all you're trying to do is run in a chroot where /bin/sh is
non
Jeff Johnson wrote:
On Aug 8, 2007, at 4:53 PM, Mark Hatle wrote:
Jeff Johnson wrote:
Same problem though. the -p is executed inside of the chroot.. Which
means I still need to have enough of a (host) environment somehow
prepopulated in the chroot to work. And I'm really trying
From somebody who has done a lot of this type of target compilation.
Just limit to one target argument and make the builder issue multiple
rpmbuild commands. IMHO thats the only reasonable solution to this.
There is little to gain from having the ability to build multiple target
packages w/ a
Jeff Johnson wrote:
Very specifically _NOT_ attempted are the mechanics of entering/leaving
a chroot,
installing missing build elements, remote scriptlet execution, logging
output, etc.
None of that is needed for a cross-compile rpmbuild.
Yep. But the major impediment I hear of is that
Jeff Johnson wrote:
On Aug 20, 2007, at 11:53 AM, Mark Hatle wrote:
One bit of advice to folks doing this.. use the %build and %install
override macros and seed your environment w/ CC, LD, etc values there...
Override the %configure macro w/ one that specifies the correst build
Personally.. I like make check. With the belief that it would run
through James Olin Odin's test suite as one of the checks, as well as
the trpm stuff.
--Mark
Jeff Johnson wrote:
Its likely time to commit to some test harness methodolgy for rpm-5.0.
There are several candidate choices
Jeff Johnson wrote:
Because of the often requested feature to be able to install using rpm
--root as an
unprivileged user (chroot(2) is limited to uid=0), the forward looking
development
answer will be to attempt to emulate chroot prefixing for unprivileged
users,
but that too is a largish
This would be useful to us. I'm not sure we'll use it right away, but I
would expect we'll use it within a year.
--Mark
Jeff Johnson wrote:
Right next to the mechanism for filtering internally generated soname
dependencies in the PLD patch, is a means to map all dependencies back
to package
I know there have been an awful lot of people who want to do this kind
of filtering. perl, dlopen have been the primary ones I know about.
Does the filtering affect the internal per-file dependencies or just the
overall package dependencies once they are rolled together?
personally I'd like a
I think this would be useful functionality to track package movement in
a system. So it's worth exploring to me.. but I'm on the fence on if it
should really be in or not.. It would be nice to understand the
ramifications of the patch to how RPM operates. (Also any logging needs
to deal with
Arkadiusz Miskiewicz wrote:
Does the filtering affect the internal per-file dependencies or just the
overall package dependencies once they are rolled together?
PLD patch applies to overall deps for entire spec. So it's not per-pkg. It's
per-spec. Both per-{pkg,spec} are actually useful but
We use sqlite, but my recommendation is unless there is a very specific
reason to use sqlite, don't.
In my case I need to use sqlite due to multiple glibc locking issues.
(db4 is really unhappy when built w/ one version of glibc and run on
another.. most likely due to various locking issues.)
Jeff Johnson wrote:
2) Supporting asm locking on a myriad of embedded tool chains. Of course
fcntl locking with BDB would have solved exactly the same problem.
I tried this a month or so ago and it was incredibly unreliable. I
didn't have the time to track down the issues.
The symptom was
Two items from extensive use of fakeroot and fakechroot (from Debian).
fakeroot has some many gotcha's.. it in essence has to be built to match
the glibc that it will be overriding. There are a million and one
overrides. We've recently been fighting a problem where building
fakeroot for RHEL 4
Just an FYI of what we are doing here at Wind River with Lua and RPM.
We have a need to install packages that will run on a target machine
perhaps running an ARM process on a ia32 host system. So we run into
all sorts of issues where transaction scripts (pre/post install/remove,
etc) are not
This is a fairly interesting patch that was sent to the rpm.org list.
Is this something we're interested in? It may point out some issues
with rpm5, or future development.. (At the expense of gcc 4...)
--Mark
Original Message
Subject: [Rpm-maint] [patch] warnings for
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?
--Mark
Anders F. Björklund wrote:
RPM Package Manager, CVS
Just an FYI, we're interesting in similar partial download and update mechanisms
for embedded systems. If you want to bounce ideas off me, feel free. I can't
guaranty I'll have time to contribute with code, but I can certainly vet ideas.
Most of the systems I'm currently working with have
While I don't have an answer for you, my concern with any change to rpmvercmp is
around compatibility.. bugs become features
What I've never seen well documented is the actual algorithm that rpmvercmp uses
for it's comparison (in a human readable form). I attempted to write one once
and
I like the idea of changing the locations to be loaded into macros. This helps
my relocatable RPM mechanism.. ;)
My only concern is how do we deal with working with roots or not? In my case, I
doubt I ever want to load interpreters from inside of a chroot, however I think
I can fairly
and paths inside of the /usr/lib*/rpm framework.
--Mark
Jeff Johnson wrote:
On May 7, 2009, at 9:15 AM, Mark Hatle wrote:
I like the idea of changing the locations to be loaded into macros.
This helps my relocatable RPM mechanism.. ;)
Using a macro for the path doesn't tell me what I
that already exist.)
--Mark
Jeff Johnson wrote:
On May 7, 2009, at 9:57 AM, Mark Hatle wrote:
Then I misunderstood the original question. I was reading it as to
what path(s) are used to initialize the interpreters.. i.e. load
includes, modules, etc. That is what I was referring to.
ATM
Jeff Johnson wrote:
On May 7, 2009, at 12:42 PM, Mark Hatle wrote:
Jeff Johnson wrote:
On May 7, 2009, at 10:55 AM, Mark Hatle wrote:
Ok.. I understand now.. then my suggestion is that these should be
macros so that individual distributions can set specific
initialization options
We handle this by doing installs in the following order:
*) passwd/group (rpm2cpio)
*) filesystem/basesystem/setup
*) Everything else
This appeared to be the only safe way to setup the environment (even prior to us
using RPM5.)
--Mark
Jeff Johnson wrote:
This issue was reported on #rpm, and
I saw the forwarded come across the rpm-maint list.
My understanding is there is currently not any SE Linux integration in rpm5
correct?
Is there any desire to include support for the %policy that they seem to be
adding below?
(I agree incorporating selinux into RPM is dangerous.. but it
Jeff Johnson wrote:
On Jul 6, 2009, at 4:03 PM, Mark Hatle wrote:
I saw the forwarded come across the rpm-maint list.
My understanding is there is currently not any SE Linux integration in
rpm5 correct?
The logic test for SELinux was inverted. So --nofcontexts enabled rather
than
Jeff Johnson wrote:
I did -- in fact -- implement all of the SELinux within RPM packaging,
working 14+ hours a day over Xmas without pay @redhat.com, and have
multiple times discussed what was desired for SELinux in RPM, usually
at my own expense. But I digress ...
Do you have any pointers to
I've always thought fileconflict mechanism that simply checked md5/sha1, mode,
owner and group would be adequate. The creation time I would expect to be
different between packages.
In the case of compressed man pages, this seems like it would require special
processing to be able to deal with
I've just started working with RPM 5.4.0. Some of this strange things I've been
doing with RPM has me creating databases while never installing any files to the
disk.
Before I could use:
-D _dbi_tags_3 Packages:Name:Basenames:Providename:Nvra \
but now if I enable that RPM doesn't return any
I disabled the rpmdsFree in the previous chunk of code, and now showrc works as
expected.
In lib/rpmrc.c
@@ -1216,11 +1229,15 @@
if (DNEVR != NULL)
fprintf(fp, %s\n, DNEVR+2);
}
+#if 0
(void)rpmdsFree(ds);
ds = NULL;
PM, Jeff Johnson wrote:
On Feb 15, 2011, at 7:27 PM, Mark Hatle wrote:
the rpmdsRpmlib is the function causing the issue. Prior to this ds is
freed,
and I'm wondering if that is causing the problem. But I'm not sure how to
diagnose any of the memory pool functions or even if Merge
I'm currently using rpm-5.4.0, and I've encountered a few issues.. however
during this I'm trying to diagnose loading of certain files using --showrc. But
when I do, I get a segfault.
Looking at valgrind output I get:
==3492== Invalid read of size 8
==3492==at 0x53E862A: rpmioGetPool
On 2/16/11 11:22 AM, Jeff Johnson wrote:
On Feb 15, 2011, at 7:18 PM, Mark Hatle wrote:
I'm currently using rpm-5.4.0, and I've encountered a few issues.. however
during this I'm trying to diagnose loading of certain files using --showrc.
But
when I do, I get a segfault.
Looking
On 2/16/11 12:21 PM, Jeff Johnson wrote:
On Feb 16, 2011, at 12:35 PM, Mark Hatle wrote:
I'll dig the rest of the fix out over the next few days.
So what I was working on was a situation where the automatic dep solver
wasn't
finding packages. It turns out that there were some
I'm getting a message:
warning: package rpm-5.4.0-r13.ppc603e is intended for a ppc603e-pc-linux-gnu
platform
In my /etc/rpm/platform file I have:
qemuppc-poky-linux-gnu
ppc603e-poky-linux-gnu
powerpc-poky-linux-gnu
noarch-poky-linux-gnu
any-poky-linux-gnu
all-poky-linux-gnu
the package was
On 2/24/11 3:39 PM, Jeff Johnson wrote:
On Feb 24, 2011, at 4:18 PM, Mark Hatle wrote:
I'm getting a message:
warning: package rpm-5.4.0-r13.ppc603e is intended for a ppc603e-pc-linux-gnu
platform
In my /etc/rpm/platform file I have:
qemuppc-poky-linux-gnu
This one is a string.
So
I'm trying to validate prelinked binaries and I'm getting a somewhat strange
result:
/bin
S.?./bin/bash
/bin/bashbug
The macro setting being used is:
%__prelink_undo_cmd /usr/sbin/prelink prelink -y library
I'm not sure what the '?' indicates, but I suspect
On 2/24/11 10:41 PM, Jeff Johnson wrote:
On Feb 24, 2011, at 11:14 PM, Mark Hatle wrote:
I'm trying to validate prelinked binaries and I'm getting a somewhat strange
result:
/bin
S.?./bin/bash
/bin/bashbug
The macro setting being used
On 2/25/11 8:40 AM, Mark Hatle wrote:
On 2/24/11 10:41 PM, Jeff Johnson wrote:
On Feb 24, 2011, at 11:14 PM, Mark Hatle wrote:
I'm trying to validate prelinked binaries and I'm getting a somewhat
strange result:
/bin
S.?./bin/bash
/bin/bashbug
Ok, I've
On 3/1/11 1:27 PM, Jeff Johnson wrote:
On Mar 1, 2011, at 2:20 PM, Mark Hatle wrote:
I think jbj might have figured out the problem. Zypper is not using pcre,
but
is instead causing mire to use the system regex.
I made some local changes in an attempt to point the #include of regex.h
The following patch was sent to the oe-core mailing list. This fixes a problem
when RPM5 (5.4.0) is linked on an Ubuntu 11.04-alpha host.
--Mark
Original Message
Subject: [OE-core] [PATCHv4 6/6] rpm: Fix linking error encountered in
rpm-native
Date: Thu, 3 Mar 2011 08:09:06
, at 2:28 PM, Mark Hatle wrote:
The following patch was sent to the oe-core mailing list. This fixes a
problem
when RPM5 (5.4.0) is linked on an Ubuntu 11.04-alpha host.
--Mark
Original Message
Subject: [OE-core] [PATCHv4 6/6] rpm: Fix linking error encountered
On 3/3/11 2:00 PM, Jeff Johnson wrote:
On Mar 3, 2011, at 2:54 PM, Mark Hatle wrote:
On 3/3/11 1:44 PM, Jeff Johnson wrote:
Hmmm ... I'l try, but I'll bet that both
beecrypt and syck are external in this bug report.
(See above, it's internal)
If its internal, then BeeCrypt/syck
On 3/4/11 2:54 AM, devzero2000 wrote:
On Thu, Mar 3, 2011 at 9:09 PM, Mark Hatle mark.ha...@windriver.com wrote:
On 3/3/11 2:00 PM, Jeff Johnson wrote:
On Mar 3, 2011, at 2:54 PM, Mark Hatle wrote:
On 3/3/11 1:44 PM, Jeff Johnson wrote:
Hmmm ... I'l try, but I'll bet that both
beecrypt
On 3/4/11 7:16 AM, devzero2000 wrote:
On Fri, Mar 4, 2011 at 2:15 PM, devzero2000 pinto.e...@gmail.com
mailto:pinto.e...@gmail.com wrote:
Just for security can you download foo{1,2,4}.c and compile.sh from
:
On Fri, Mar 4, 2011 at 2:27 PM, Mark Hatle mark.ha...@windriver.com
mailto:mark.ha...@windriver.com wrote:
On 3/4/11 7:16 AM, devzero2000 wrote:
On Fri, Mar 4, 2011 at 2:15 PM, devzero2000 pinto.e...@gmail.com
mailto:pinto.e...@gmail.com
mailto:pinto.e...@gmail.com
On 6/10/11 6:33 PM, Jeff Johnson wrote:
On Jun 10, 2011, at 4:39 PM, Mark Hatle wrote:
I've been trying to reconcile the behavior between rpm and deb packages in
the
way their directories are handled.
In rpm, we can set the directories to own in various ways. If there is a
conflict
I'm working on multilib/multiarch support in the oe-core stuff. And I've hit an
issue. I'm trying to query for a package of a specific arch.
rpm -q zlib
returns:
zlib-1.2.5-r0.x86_64
if I do:
rpm -q zlib-1.2.5 or zlib-1.2.5-r0 or zlib-1.2.5-r0.x86_64
I get the same result..
however, I
On 6/30/11 11:37 AM, Jeff Johnson wrote:
On Jun 30, 2011, at 12:29 PM, Mark Hatle wrote:
I'm working on multilib/multiarch support in the oe-core stuff. And I've
hit an
issue. I'm trying to query for a package of a specific arch.
rpm -q zlib
returns:
zlib-1.2.5-r0.x86_64
if I do
On 12/22/11 10:22 AM, Jeffrey Johnson wrote:
On Dec 22, 2011, at 10:40 AM, Mark Hatle wrote:
On 12/22/11 7:56 AM, Jeffrey Johnson wrote:
On Dec 22, 2011, at 7:24 AM, Paul Eggleton wrote:
Hi there,
Whilst working on Poky/OpenEmbedded I found the need to list all of the hard
dependencies
1 - 100 of 107 matches
Mail list logo
