rpm 4.5: i686-x86_64 migration
Hi, I'm still at rpm 4.5 and I'm looking for a way to replace all i686 packages with x86_64 ones on a existing system. My rpm is already x86_64 one. How can I trick rpm to treat i686 and x86_64 packages equally, possibly without any colors? (so newer x86_64 versions would replace i686 packages like a upgrade) -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
define/undefine as stack but how to undefine permamently?
%define puts variables on stack, undefine pops them from stack. Now i need a
way to undefine variable permamently.
Suppose
%define crap 1
%define crap 2
%define crap 3
%undefine crap
(now crap is == 2)
and what I need is some
%undefineall crap
which will make crap undefined regardless of how many defines/undefines were
there earlier.
Any ideas how to do that on macro level?
Some
while [ %{defined crap} ]; do
%undefine crap
done
that will actually work (this one won't obviously).
The other solution is to add %undefineall macro on *.c level (this one is easy
but I'm looking for a on-macro level thing).
Ideas?
--
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: define/undefine as stack but how to undefine permamently?
On Saturday 08 of August 2009, Arkadiusz Miskiewicz wrote:
%define puts variables on stack, undefine pops them from stack. Now i need
a way to undefine variable permamently.
Suppose
%define crap 1
%define crap 2
%define crap 3
%undefine crap
(now crap is == 2)
and what I need is some
%undefineall crap
which will make crap undefined regardless of how many defines/undefines
were there earlier.
Any ideas how to do that on macro level?
Some
while [ %{defined crap} ]; do
%undefine crap
done
that will actually work (this one won't obviously).
Ok, it's not possible to do that on macros level/lua level etc. Too bad.
The other solution is to add %undefineall macro on *.c level (this one is
easy but I'm looking for a on-macro level thing).
%unglobal thing does exactly that:
http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/rpm/rpm-
unglobal.patch?rev=1.1
--
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: Avoiding dependencies
On Tuesday 23 of December 2008, Bernhard Rosenkränzer wrote: I've just run into the old avoiding dependency problems again, and (unless I'm overlooking something and there already is a fix for this) I guess we need to add a new tag for it... In this particular case, a package containing a /proc/self/fd/0 - /dev/stdin symlink is causing a dependency on /proc/self/fd/0, which (obviously) isn't provided by any package. The usual tricks of removing the executable bit doesn't apply here, so the best thing to do is %define __find_requires to a script that runs /usr/lib/rpm/find-requires |grep -v /proc That, however, turns off the internal dependency generator and all the features it brings. Any chance for a DoesntRequire: or FilterRequires: tag, or for calling the internal dependency generator from a __find_requires script? Or [ar...@tarm ~]$ grep /etc/rpm/sysinfo/* /etc/rpm/sysinfo/Filelinktos:/proc/self/fd /etc/rpm/sysinfo/Filelinktos:/dev/fd/0 /etc/rpm/sysinfo/Filelinktos:/dev/fd/1 /etc/rpm/sysinfo/Filelinktos:/dev/fd/2 -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: new DISTEPOCH tag and cleaning of RELEASE tag polution
On Saturday 20 of December 2008, 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
%{EPOCH}:%{VERSION}-%{RELEASE}:%{DISTEPOCH}, ie. 1:2.3.4-5:2009.1.
In PLD this won't fly because
1:2.3.4-5 in new devel version of distro can be newer than
1:2.3.4-7 in old still maintained one.
(versioning is separate for each line)
For now in such case -5 would be bumped to something bigger than in old
version manually.
Regards,
Per Øyvind
--
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: %patch as a macro (or not) flip flops
On Friday 07 of November 2008, Jeff Johnson wrote:
On Nov 7, 2008, at 10:58 AM, Jason Corley wrote:
On Fri, Nov 7, 2008 at 9:35 AM, Jeff Johnson [EMAIL PROTECTED] wrote:
But there are rpmbuild behavior changes, now reported as issues
#40 and #41, and show-stoppers for PLD using rpm-5.x.
For some reason I read this as bugs in PLD's bug tracker, not PLD put
bugs in rpm5's bug tracker... Seems like both tickets are of the
should fail on non-existence type and while I'm not sure I agree
that those are bugs in rpm I have to ask: How hard would it be to add
a test/exit condition to the macro?
There are two levels of exit, one for expansion, the other for the
execution
of the expansion.
It __IS__ one line of shell once the expansion is complete, and ||
exit 1
__COULD__ be added to the pipeline trivially:
It doesn't fail with exit 1 - tested. See below.
%prep
%setup -q -n %{name}
%patch0 -p1
Source0: exists
Patch1: points_to_notexisting_file
[EMAIL PROTECTED] SPECS]$ rpmbuild -bb alien.spec
Fetching(Patch0): alien-DESTDIR.patchxx
error: Fetching Patch0 failed: Unknown or unexpected error
error: Missing Patch0: alien-DESTDIR.patchxx: No such file or directory
Executing(%prep): /bin/sh -e /home/users/arekm/tmp/rpm-tmp.33473
+ umask 022
+ cd /home/users/arekm/rpm/BUILD
+ exit 0
rpm-5.2a1
- Source is not unpacked, no idea why since %prep is run
- patch doesn't exist but since it's supposed to be just macro then why
there is no expansion here and why it doesn't try to apply it?
- error: Missing Patch0: alien-DESTDIR.patchxx: No such file or directory - is
that from patch expansion? Doesn't look so - why it doesn't fail here then?
--
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: Failed dependencies: perl(\s+) is needed by rpm-build
On Saturday 25 of October 2008, Robert Scheck wrote: Good evening, today I bootstrapped latest HEAD and I got the following error when trying to install the RPM packages: error: Failed dependencies: perl(\s+) is needed by rpm-build-5.2-0.1.20081025cvs.i386 Try HEAD now. Greetings, Robert -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm5 run-time probe: a closer look
On Sunday 03 August 2008, devzero2000 wrote: it is really necessary ? What is the difference from %pre id root /dev/null || exit 1 You meant %pretrans I guess. This requires working shell and id anyway (think about installations with --root). Thanks in advance -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/rpmio/ argv.h
On Wednesday 30 July 2008, Jeff Johnson wrote: Is it __REALLY_ that hard to get application developers to add #include stdint.h where needed? argv.h is broken and fix is needed in this file. Why do you insist of external application developer to workaround someone else bugs if you can fix the source of the problem? -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/rpmio/ argv.h
On Wednesday 30 July 2008, Jeff Johnson wrote: On Jul 30, 2008, at 6:21 AM, Arkadiusz Miskiewicz wrote: On Wednesday 30 July 2008, Jeff Johnson wrote: On Jul 30, 2008, at 5:50 AM, Ralf S. Engelschall wrote: On Wed, Jul 30, 2008, Jeff Johnson wrote: This band-aid prevents installing argv.h in /usr/include/rpm w/o messy AutoFu. Really? If no Autoconf #defines are present, _nothing_ happens. The stuff degrades gracefully to just no #include at all. So, this should not cause any problems. And the degradation was the problem that arekm set out to solve. The problem is that public rpm headers are not self contained. They use stuff like different types but don't include required headers. Example: And rpm has never __EVER__ promised that each and every include file is self contained. Uhm, ok. Nor is there any need for the files to be self contained. Yes I know what you want ... Try #include rpmcli.h http://pld.pastebin.com/f6a8d5a98 73 de -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/rpmio/ argv.h
On Wednesday 30 July 2008, Arkadiusz Miskiewicz wrote: On Wednesday 30 July 2008, Jeff Johnson wrote: On Jul 30, 2008, at 5:50 AM, Ralf S. Engelschall wrote: Instead of arguing abt stdint.h (which I will start ripping after my 2nd cup of coffee today, sigh), let's try the forward looking goal. Ok, so the agreement is that rpmcli.h should be self consistent right? There is a little discussion about this on irc ... so stay tuned for the +- finals. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_1: rpm/rpmio/ argv.h
On Tuesday 29 July 2008, Ralf S. Engelschall wrote: On Tue, Jul 29, 2008, Arkadiusz Miskiewicz wrote: type of solution. Does that work for you? In general I'm ok with an approach which punishes only old/obsolete/deprecated/whatever platforms. But in this case I'm more thinking about neither distinguishing between old and new and more about mostly feature based testing: #ifdef HAVE_CONFIG_H #include config.h #endif #if defined(HAVE_STDINT_H) || (defined(__STDC_VERSION__) __STDC_VERSION__+0 = 199901L) #include stdint.h #endif #if defined(HAVE_INTTYPES_H) #include inttypes.h #endif This approach works fine for building rpm itself but it doesn't work when you are building external app that doesn't use autoconf and that app includes rpm public headers. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/rpmdb/ rpmdb.c
On Friday 02 of November 2007, Jeff Johnson wrote: On Friday, November 02, 2007, at 03:59PM, Arkadiusz Miskiewicz [EMAIL PROTECTED] wrote: On Friday 02 of November 2007, Jeff Johnson wrote: Doesn't work :-( What does not work? It doesn't issue error but creates some additional directories like /q/q/.. structure or /q/home/users/arekm/q/var/lib which weren't there before rebuilddb. Ah got it. Yes there's still some path problems, I've been examining the -vv spew and the paths reported there, not the find output. I'll have a fix this evening. Did I miss it or it didn't happen yet? -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Compile Error on 5.0a1
On Monday 12 of November 2007, Ralf S. Engelschall wrote: The librpmmisc.vers file was missing from the EXTRA_DIST variable in misc/Makefile.am and this way was not picked up by make dist for inclusion into the release tarball. Now fixed: http://rpm5.org/cvs/chngview?cn=8738. Thanks for your feedback. make dist make distcheck didn't detect that? Ralf S. Engelschall -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES rpm/rpmdb/ rpmdb.c
On Friday 02 of November 2007, Jeff Johnson wrote: On Nov 2, 2007, at 6:10 AM, Arkadiusz Miskiewicz wrote: On Friday 02 of November 2007, Jeff Johnson wrote: = == = $ cvs diff -u -r1.195 -r1.196 rpmdb.c --- rpm/rpmdb/rpmdb.c22 Oct 2007 02:48:42 - 1.195 +++ rpm/rpmdb/rpmdb.c2 Nov 2007 03:07:46 - 1.196 @@ -3917,7 +3917,7 @@ } dbpath = rootdbpath = rpmGetPath(prefix, tfn, NULL); if (!(prefix[0] == '/' prefix[1] == '\0')) -dbpath += strlen(prefix) - 1; +dbpath += strlen(prefix); tfn = _free(tfn); It looks like this part is changed over and over, adding -1, stripping -1 http://rpm5.org/cvs/filediff?f=rpm/rpmdb/rpmdb.cv1=1.127v2=1.128 Backporting and testing... Likely. Again, this command has never been well implemented rpm --rebuilddb --root /q Doesn't work :-( Friend tested on backported 4.4.9: [EMAIL PROTECTED] /]# rm -fr /q/; mkdir /q; rpm -r /q --initdb; rpm -r /q --rebuilddb [EMAIL PROTECTED] /]# find /q/ /q/ /q/var /q/var/lib /q/var/lib/rpm /q/var/lib/rpm/Packages /q/q /q/q/var /q/q/var/lib /q/q/var/lib/rpmrebuilddb.29601 I tested HEAD from 1 min ago: [EMAIL PROTECTED] ~]# rm -rf /q/ [EMAIL PROTECTED] ~]# mkdir /q [EMAIL PROTECTED] ~]# ~arekm/rpm-test/bin/rpm --root /q --initdb [EMAIL PROTECTED] ~]# ~arekm/rpm-test/bin/rpm --root /q --rebuilddb [EMAIL PROTECTED] ~]# find /q /q /q/var /q/var/lib /q/var/lib/rpm /q/home /q/home/users /q/home/users/arekm /q/home/users/arekm/q /q/home/users/arekm/q/var /q/home/users/arekm/q/var/lib /q/home/users/arekm/q/var/lib/rpmrebuilddb.22315 /q/home/users/arekm/q/var/lib/rpmrebuilddb.22315/__db.001 /q/home/users/arekm/q/var/lib/rpmrebuilddb.22315/__db.002 /q/home/users/arekm/q/var/lib/rpmrebuilddb.22315/__db.003 /q/home/users/arekm/q/var/lib/rpmrebuilddb.22315/Packages 73 de Jeff -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Segfault because librpmio is missing -lpcre
On Thursday 01 of November 2007, Jeff Johnson wrote: There's a segfault reported last week by arekm when rpm is compiled to use PCRE because of a missing linkage from rpmmire in librpmio to -lpcre. No idea whether miscompiled or actually missing. Could someone take a look please? -Wl,-as-needed is too smart here [EMAIL PROTECTED] ~]$ gcc test.c -lpcre [EMAIL PROTECTED] ~]$ objdump -p a.out | grep NEEDE NEEDED libpcre.so.0 NEEDED libc.so.6 [EMAIL PROTECTED] ~]$ gcc test.c -Wl,-as-needed -lpcre [EMAIL PROTECTED] ~]$ objdump -p a.out | grep NEEDE NEEDED libc.so.6 [EMAIL PROTECTED] ~]$ but the problem is more generic one. If a program is linked to 2 or more libraries that provide exactly the same symbol (function) - from which library symbol is going to be used? randomly? Where it's said that pcre regcomp() will be used and not glibc one if progam is linked to both glibc and pcre? 73 de Jeff -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
is root support working for anyone with bdb 4.6?
Hello, I have some problems with rpm 5.0 and bdb 4.6.X: http://rpm5.org/cvs/tktview?tn=20 http://rpm5.org/cvs/tktview?tn=21 Does --root work reliably for anyone in 5.0 with bdb 4.6.x [1]? 1. something has changed in bdb 4.6 that makes these problems visible -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Segfault because librpmio is missing -lpcre
On Thursday 01 of November 2007, Arkadiusz Miskiewicz wrote: On Thursday 01 of November 2007, Jeff Johnson wrote: There's a segfault reported last week by arekm when rpm is compiled to use PCRE because of a missing linkage from rpmmire in librpmio to -lpcre. No idea whether miscompiled or actually missing. Could someone take a look please? -Wl,-as-needed is too smart here [EMAIL PROTECTED] ~]$ gcc test.c -lpcre [EMAIL PROTECTED] ~]$ objdump -p a.out | grep NEEDE NEEDED libpcre.so.0 NEEDED libc.so.6 [EMAIL PROTECTED] ~]$ gcc test.c -Wl,-as-needed -lpcre [EMAIL PROTECTED] ~]$ objdump -p a.out | grep NEEDE NEEDED libc.so.6 [EMAIL PROTECTED] ~]$ Hm, a mistake here. I should link with pcreposix not pcre. rpm doesn't link to pcreposix at all (while it should when pcre is enabled) 73 de Jeff -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: is root support working for anyone with bdb 4.6?
On Thursday 01 of November 2007, Jeff Johnson wrote: On Nov 1, 2007, at 9:20 AM, Arkadiusz Miskiewicz wrote: [...] http://rpm5.org/cvs/tktview?tn=20 [...] Let's try to flesh out the problem with some details. rpm uses a dbenv for concurrent access, which adds persistent state to all accesses. rpm --root does several chroot(2) entries and exits, which forces trimming paths to rpmdb files after a chroot(2). The constraint on the solution is being able to support external, virgin, untouched, Berkeley DB for PLD. I'm happy with internal BDB 4.6 (not 4.5). BDB is a nightmare, external BDB is a huge nightmare. I'm finally convinced that internal BDB is better for sake of everyone. So the current solution is to add a 10 line system open(2) wrapper that knows the chroot(2) path and strip the leading part of the path while rpm is within a chroot. All that works fine for a single process execution. open wrapper fixed one issue for me. The issue that you are now reporting is harder because the persistent state spans this sequence: rpm -ivh --root /root chroot /root /bin/sh rpm -qa So the paths that are saved persistently in the dbenv usually have the /root prefix, leading to failures. I'm almost certain that doing (in the chroot) rm -f /var/lib/rpm/__db* works. Yes, that works but it's worse than using dbenv-remove() right? On IRC you said that remove() cannot be used due to some reason (?) Identifying if/when chroot(2) has been done (by another process) so that the validity of the paths persistently stored in the dbenv can be determined, and rpm can magically Just Work will involve identifying if chroot(1) has been run. Not pretty. Yeah, ugly. The other solution is hacking deep in system Berekeley DB to remove the persistently saved path. But that is at odds with the constraint of virgin/untouched external system Berkely DB. Do you know where BDB stores that exactly? So I could play with reverting that part to 4.5 state. SOmethoing has to change to solve this problem. Meanwhile, can you confirm that indeed rpm works if you do chroot /root /bin/sh rm -f /var/lib/rpm/__db* Worse than remove() right? What about other root problem - http://rpm5.org/cvs/tktview?tn=21 ? 73 de Jeff -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Segfault because librpmio is missing -lpcre
On Thursday 01 of November 2007, Arkadiusz Miskiewicz wrote: On Thursday 01 of November 2007, Jeff Johnson wrote: There's a segfault reported last week by arekm when rpm is compiled to use PCRE because of a missing linkage from rpmmire in librpmio to -lpcre. Commited patch separating pcre from pcreposix untill (so you can use pcre for lua but not for rpm*/*.c). The problem below is NOT solved: If a program is linked to 2 or more libraries that provide exactly the same symbol (function) - from which library symbol is going to be used? randomly? Where it's said that pcre regcomp() will be used and not glibc one if progam is linked to both glibc and pcre? -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ configure.ac
On Thursday 01 of November 2007, Ralf S. Engelschall wrote:
I understand what you are trying to do, but instead of separating
libpcre from libpcreposix, the better solution IMHO is to add the
missing AC_CHECK_LIB(pcreposix) check to the old RPM_CHECK_LIB()
of PCRE! Because RPM currently cannot use PCRE alone anyway and
libpcreposix cannot be used without libpcre, too.
So, what the Autoconf glue for PCRE _REALLY HAS TO_ check for is
whether _both_ pcreposix.h _and_ -lpcreposix are available and if
available also really link against -lpcreposix or not try to use PCRE's
POSIX API at all. AFAIK the segfault just occurred because RPM thought
pcreposix.h is available but forgot to link against the corresponding
-lpcreposix library and this way picked up the POSIX API from glibc.
There is still symbol clash between glibc and pcreposix.
regcomp configure checking won't work for those who avoid symbol clash by
using recently posted patch:
http://cvsweb.openwall.com/cgi/cvsweb.cgi/~checkout~/Owl/packages/pcre/pcre-7.4-deb-pcreposix.diff
You will probably need to actually try to compile + link some test code like:
#include pcreposix.h
int main() { regcomp(); }
to get properly working detection in this case.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
--
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: Filtering automagically generated dependencies
On Friday 05 of October 2007, Jeff Johnson wrote: On Oct 4, 2007, at 12:52 PM, Arkadiusz Miskiewicz wrote: Note that -x binary is not a option since it has some other autogenerated deps that we want to have. Not true. chmod -x is _ALWAYS_ an option, re-add the execute bits with %attr. Not true? AFAIK deps autogenerator ignores binaries that aren't executable. So it won't find any deps for binary A and that's what I'm talking about. Example: bin/blah generates R: libjbj.so.1, R: libwrum.so.3. You want to filter out libwrum.so.3 only. chmod -x bin/blah is not a option. It will require manual R: libjbj.so.1 in spec which sucks. personally I'd like a mechanism to do this kind of filtering on a per package basis... but so far you've talked me out of it. per-spec, too. per-pkg only would require to put filtering 10 times in one spec if it generates 10 pkgs from single spec. Say what? Adding a pattern once in a per-distro filtering file somehow becomes 10 additions for sub-pkgs? Explicit details please ... There is package A that Requires: libcrap.so.1 and there is package B that Requires: libcrap.so.1. Tell me now how to filter out libcrap.so.1 ONLY for package A but NOT B with per-distro filtering rule. 73 de Jeff -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Filtering automagically generated dependencies
On Friday 05 of October 2007, Jeff Johnson wrote: On Oct 5, 2007, at 2:25 AM, Arkadiusz Miskiewicz wrote: Sucks is a different mtter. How many packages need this functionality? Acroread, which isn't built correctly. How many other packages __NEED__ a grep -v filtering mechanism in rpm because add some Requires: manually sucks? Only few. In PLD $ grep '_noauto' *.spec | cut -d: -f1 | sort | uniq | wc -l 498 $ ls *.spec |wc -l 12169 There is package A that Requires: libcrap.so.1 and there is package B that Requires: libcrap.so.1. Tell me now how to filter out libcrap.so.1 ONLY for package A but NOT B with per-distro filtering rule. Presumably A and B are binary subpkgs of a single build No. Different specs. And you can use only per-distro filtering and cannot use manual Requires:. Try that ;-) 73 de Jeff -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Filtering automagically generated dependencies
On Friday 05 of October 2007, Jeff Johnson wrote: On Oct 5, 2007, at 7:56 AM, Arkadiusz Miskiewicz wrote: On Friday 05 of October 2007, Jeff Johnson wrote: On Oct 5, 2007, at 2:25 AM, Arkadiusz Miskiewicz wrote: Sucks is a different mtter. How many packages need this functionality? Acroread, which isn't built correctly. How many other packages __NEED__ a grep -v filtering mechanism in rpm because add some Requires: manually sucks? Only few. In PLD $ grep '_noauto' *.spec | cut -d: -f1 | sort | uniq | wc -l 498 498?!? How many of those packages have mis-built executables like acroread? http://pastebin.com/m1bc94410 well, much less, libGL.so.1 things are lefover from NEVR deps era and are to be dropped. Mainly perl/pear stuff. How many have dlopen modules, which arguably don't need anexcutable bit, and may have other mens to function when necessary linkage symbols are not present (i.e. may not need a Requires: at all)? The answer is zero (or close to zero) :-) --as-needed linker flag strips such useless dependencies from binaries for us already. How many of those filtering operations are simply unnecessary? I would guess like 2/3 of that on pastebin. 73 de Jeff -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Mechanism to generate *only* pkg NEVR dependencies
On Thursday 04 of October 2007, 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 NEVRA. Not only. also NEVR. The goal was to get name of required packages directly at installation time when rpm prints unsatisfied deps. The rationale for the mapping (as far as I understand) is to simplify finding the name of the object that contains the provides that satisfies a require. It's nice because people instead of seeing: libz.so.1 is needed by xyz.i686 will see: libz.so.1 is needed by xyz.i686 zlib-libs is needed by xyz.i686 so they will immediately know which package is needed. BUT there is one important but. If for example few packages provide libz.so.1 then the dependency will be generated on installed (at build time) one and others won't even be allowed (if they conflict). That's what happens in PLD with: xorg-driver-video-nvidia-100.14.19-1.i686 xorg-driver-video-fglrx-8.40.4-3.i686 Mesa-libGL-7.0.1-2.i686 and ~3 other. All provide the same file libGL.so.1 and conflict on each other. Due to this reason we no longer use this feature. 73 de Jeff -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-4_5: rpm/ configure.ac rpm/po/ nb.po no.po
On Friday 28 of September 2007, Jeff Johnson wrote: On Sep 28, 2007, at 9:15 AM, Jason Corley wrote: +Report-Msgid-Bugs-To: [EMAIL PROTECTED]\n Shouldn't we be changing these to rpm5.org? They are being changed. The problem is how merges are done, fresh hot PO files end up dragging in the old email address again and again. I personally have gone through and made the change 2-3 times now. Probably due to po/Makevars settings (changed now). 73 de Jeff -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Yet Another internal - external linkage problem
On Tuesday 24 of July 2007, Ralf S. Engelschall wrote: On Tue, Jul 24, 2007, Jeff Johnson wrote: On Jul 24, 2007, at 3:47 PM, Ralf S. Engelschall wrote: Yes. And if you spin this thought one step further one ends up with something like devtool standalone or even the OpenPKG bootstrap package where _ALL_ third-party stuff is locally provided to be maximum independent of the underlying OS (as one usually never can depend on anything there except perhaps the existence of /bin/sh ;-) Find an answer for bloaty, as well as -Wl,-as-needed, and I'm not at all averse to going this way. Err... what was the issue again in detail with -Wl,--as-needed? I know that it was mentioned once on this list, but I've still not 100% understood what problem is we are faced with and what is wished as the solution here. Each binary needs to have direct linking with all required libraries. So if rpm needs neon then it needs -lneon even if it's linked with -lrpmsomething where rpmsomething is already linked to neon. http://www.gentoo.org/proj/en/qa/asneeded.xml Ralf S. Engelschall -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/scripts/ mono-find-provides
On Friday 13 of July 2007, Mark Hatle wrote: === = $ cvs diff -u -r0 -r1.1 mono-find-provides --- /dev/null 2007-07-13 04:56:02 +0200 +++ mono-find-provides 2007-07-13 04:57:03 +0200 @@ -0,0 +1,42 @@ +#!/bin/bash +# Ehem, could you fix that script to be POSIX shell compatibile? I don't even want to have bash on my system 8-) -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: librpmmisc approach for handling shared external libraries doesn't look sane
On Wednesday 11 of July 2007, Ralf S. Engelschall wrote: On Wed, Jul 11, 2007, Arkadiusz Miskiewicz wrote: Try this: ./configure LDFLAGS=-Wl,--as-needed It will fail miserably because things are not linked properly. It's like in the patient/doctor joke: Patient: 'Doctor, it hurts when I do this'. Doctor: 'Well, then just don't do it'... as-needed is like vaccine which helps prevent some (described in this thread) problems before these happen and injection hurts, too. Seriously, the current linking approach certainly is a little bit peculiar on the first spot and doesn't work as expected for various special approaches like your --as-needed above. But I've really investigated here very deep for us and AFAIK the current approach IMHO is the only _really_ portable way to reasonably _balance out_ all the issues related to the RPM libraries, their third-party dependencies and especially the various way the RPM libraries and their third-party dependencies can be built and installed. I'm thinking about leaving thing as is + add option like --enable-direct-linking which would cause each librpmXXX to be linked with libs that it uses directly. Not sure if this will work (due to interdeps), have to test first. That helps me and ALT and doesn't break others. Ralf S. Engelschall For those interested - more details about --as-needed: http://www.gentoo.org/proj/en/qa/asneeded.xml -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
librpmmisc approach for handling shared external libraries doesn't look sane
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. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmdb/ Makefile.am
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 RPM with an external Berkeley-DB _without_ having to patch the RPM sources. The only patch is the robust mutexes. There's likely a vector in Berkeley DB that can be overridden, and the POSIX shared mutex locking can be carried privately within rpm if external db is absolutely desired. Where is that patch? We at PLD don't like internal libs, we prefer to patch external ones. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmdb/ Makefile.am
On Thursday 28 of June 2007, Jeff Johnson wrote: # rpm -qa rpmdb: unable to initialize mutex: Operation not supported rpmdb: PANIC: Operation not supported You have misbuilt rpm. There is autoconfiggery necessary and the build system must be setup +NPTL. The setup always has been nptl ready (glibc 2.6; = 2.6.16 kernels) +1 for support problems with external Berkeley DB. Looks like these new things from robustness patch require kernel = 2.6.17 (because the problem is not visible on such kernels with exactly the same userspace environment). I've dropped robustness patch from our system db. PLD lived for a very (very) long time with external db and without the patch btw :) 73 de Jeff -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/rpmdb/ Makefile.am
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 ready is not sufficient, there are explicit autoconf tests in Berkeley DB that will misbuild if the build system is not set up correctly. checking for mutexes... POSIX/pthreads/library is the good one afaik. Specifically, if nptl-devel is not installed, you will fail with exactly the above system. nptl-devel - looks like some very ancient Linux distribution. Starting from glibc 2.4 there is no other option than NPTL (linuxthreads not even supported). Robustness adds the missing property, but is not in 2.6.17 AFAIK. 2.6.16 actually. 2.6.17 works fine. So my problem is kernel related problem only. 73 de Jeff -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES configure.ac
On Monday 25 of June 2007, Andy Green wrote: Arkadiusz Miskiewicz wrote: Log: allow one to control/override the /usr/lib64 use via Autoconf option --enable-build-lib64 Usually this is done by ./configure --libdir=/usr/lib64. Possibly I misunderstand, but is that true? I believe --libdir just sets where make install is going to place built libraries, Correct. --enable-build-lib64 sets MARK64=64 which is used somewhere so looks like it's needed and --libdir=/usr/lib64 will not help here too much. Unless doing detection in such way: case $libdir in *64*) MARK=64 it doesn't build against libs in the root filesystem /usr/lib64, which I understood Ralf's comment to mean (like LDFLAGS=-L/usr/lib64 would). -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Flexibly building against third-party libraries (RPM_CHECK_LIB)
On Friday 22 of June 2007, Jeff Johnson wrote: Hmm, apologies for empty message. I swear I wrote something. What I said is that there is a possibility that 2 -lz linkages might be needed for -lneon external and zlib internal. Huh, that would only mean that your libneon.so is broken (not properly linked). Fix it. Hack with -lz won't work if you use --as-needed btw. 73 de Jeff -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Flexibly building against third-party libraries (RPM_CHECK_LIB)
On Thursday 21 of June 2007, Ralf S. Engelschall wrote: On Wed, Jun 20, 2007, Arkadiusz Miskiewicz wrote: On Wednesday 20 of June 2007, Arkadiusz Miskiewicz wrote: Right now from config.log: configure:27985: error: unable to find available BeeCrypt library but why it told so, you have to guess and digg. We have beecrypt includes in /usr/include/beecrypt/ so the only option is --with-beecrypt=/usr configure complains: find: warning: Unix filenames usually don't contain slashes (though pathnames do). That means that '-name beecrypt/api.h' will probably evaluate to false all the time on this system. You might find the '-wholename' test more useful, or perhaps '-samefile'. Alternatively, if you are using GNU grep, you could use 'find ... -print0 | grep -FzZ beecrypt/api.h'. Ok, but I'm wondering why line 210 of acinclude.m4 does not already catch your /usr/include/beecrypt/api.h? + test -f /usr/pkg-config + set -x + test .no = .no + test -f /usr/include/beecrypt/beecrypt/api.h + test -f /usr/include/beecrypt/api.h + CPPFLAGS= -I/usr/include btw. isn't adding such system wide paths broken anyway? It will break heavily if you have two copies of for example beecrypt, one in /usr/include and one in /usr/something/ because checking for other components (let be it) popt will add -I/usr/include already and you won't be able to use /usr/something beecrypt correctly. + __rcl_found=yes + break + test .yes = .yes + __rcl_found=no + test -f /usr/lib/beecrypt/libbeecrypt.la The macro doesn't know that there are 64bit systems out there that use /usr/lib64/ (for 64bit libs) not /usr/lib/ (for 32bit) (AFAIK FHS says something about systems that use /usr/lib32 (for 32bit libs) and /usr/lib (for 64bit), too). Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ INSTALL
On Thursday 21 of June 2007, Jeff Johnson wrote: 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 Email: [EMAIL PROTECTED] Module: rpm Date: 21-Jun-2007 10:59:28 Branch: HEAD Handle: 2007062109592800 Modified files: rpm INSTALL Log: bundle optional and mandatory parts together and make Zlib optional according to the code information I'd like to see Zlib internal mandatory. ... and pld will have to patch it (well, small patch but still) ;-( If noone else cares, then I will cease to care and shut up too. Make internal default, external *requiring* option. Is there some simple way to detect if zlib is rsyncable or not? configure could exit(1) when nonrsyncable lib found. 73 de Jeff -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Flexibly building against third-party libraries (RPM_CHECK_LIB)
On Wednesday 20 of June 2007, Ralf S. Engelschall wrote: On Wed, Jun 20, 2007, Jay Soffian wrote: On Jun 20, 2007, at 3:06 PM, Ralf S. Engelschall wrote: + [external:internal:none], [beecrypt], + [], [ AC_ERROR([mandatory BeeCrypt library not found]) ]) ... + [external:internal:none], [file:src:src], + ], [ AC_ERROR([mandatory File (magic) library not found]) ]) Should these be [external:internal:abort] ? Yes, you're right. BeeCrypt and File are de-facto not really optional. The code base currently does not allow us to keep them out. Now fixed. Thanks for the feedback. btw. can this macro be more verbose (logging things to config.log) ? Right now from config.log: configure:27985: error: unable to find available BeeCrypt library but why it told so, you have to guess and digg. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Flexibly building against third-party libraries (RPM_CHECK_LIB)
On Wednesday 20 of June 2007, Arkadiusz Miskiewicz wrote:
Right now from config.log:
configure:27985: error: unable to find available BeeCrypt library
but why it told so, you have to guess and digg.
We have beecrypt includes in /usr/include/beecrypt/ so the only option is
--with-beecrypt=/usr
configure complains:
find: warning: Unix filenames usually don't contain slashes (though pathnames
do).
That means that '-name beecrypt/api.h' will probably evaluate to false all the
time
on this system. You might find the '-wholename' test more useful, or perhaps
'-samefile'.
Alternatively, if you are using GNU grep, you could use 'find ... -print0 |
grep -FzZ beecrypt/api.h'.
maybe (not sure about non-coreutils find)
--- acinclude.m4 2007-06-20 23:10:19.0 +0200
+++ acinclude.m42007-06-20 23:51:42.123505988 +0200
@@ -241,7 +241,7 @@
dnl # in any sub-area
if test .${__rcl_found} = .no; then
dnl changequote(, )dnl
-for __rcl_file in _ `find ${__rcl_location} -name $5
-type f -print`; do
+for __rcl_file in _ `find ${__rcl_location} -wholename
$5 -type f -print`; do
test .${__rcl_file} = ._ continue
__rcl_dir=`echo ${__rcl_file} | sed -e
's;[[^/]]*[$];;' -e 's;\(.\)/[$];\1;'`
CPPFLAGS=${CPPFLAGS} -I${__rcl_dir}
@@ -251,7 +251,7 @@
if test .${__rcl_found} = .yes; then
__rcl_found=no
m4_foreach_w([__rcl_lib], [$3], [
-for __rcl_file in _ `find ${__rcl_location}
-name lib[]m4_defn([__rcl_lib]).* -type f -print | \
+for __rcl_file in _ `find ${__rcl_location}
-wholename lib[]m4_defn([__rcl_lib]).* -type f -print | \
egrep '\.(a|so|sl|dylib)$'`; do
test .${__rcl_file} = ._ continue
__rcl_dir=`echo ${__rcl_file} | sed -e
's;[[^/]]*[$];;' -e 's;\(.\)/[$];\1;'`
configure: error: unable to find available File (magic) library
The same for file package :-)
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
--
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
