[PATCH]: logging of package install/remove to syslog
Here's an improved and more upstream friendly version of syslog patch from
Mandriva which adds logging of install/remove of packages to syslog.
It will be disabled by default, but can be activated by %_log_to_syslog macro.
Any objections of commiting or ideas of improvement?
--
Regards,
Per Øyvind Karlsen
Mandriva Norway
--- system.h.syslog 2008-02-07 21:18:54.0 +0100
+++ system.h 2008-02-21 16:19:10.339599193 +0100
@@ -9,6 +9,10 @@
#include "config.h"
#endif
+#ifdef HAVE_SYSLOG_H
+#include
+#endif
+
#include
#if defined(HAVE_STDINT_H)
#include
--- config.h.in~ 2008-02-01 01:48:46.0 +0100
+++ config.h.in 2008-02-21 17:29:17.036456904 +0100
@@ -446,6 +446,9 @@
/* Define to 1 if you have the header file. */
#undef HAVE_STRING_H
+/* Define to 1 if you have the header file. */
+#undef HAVE_SYSLOG_H
+
/* Define to 1 if you have the `strndup' function. */
#undef HAVE_STRNDUP
--- configure.ac~ 2008-02-01 01:40:15.0 +0100
+++ configure.ac 2008-02-21 17:30:39.659798279 +0100
@@ -537,7 +537,7 @@ AC_CHECK_HEADERS([dnl
sys/param.h sys/mount.h sys/mntctl.h sys/vmount.h dnl
libio.h err.h mcheck.h limits.h libgen.h float.h dnl
glob.h poll.h netinet/in.h arpa/inet.h stdint.h inttypes.h dnl
-langinfo.h dnl
+langinfo.h syslog.h dnl
])
dnl # GNU gettext support
--- macros.in~ 2008-02-07 06:31:48.0 +0100
+++ macros.in 2008-02-21 17:54:59.113746456 +0100
@@ -900,6 +900,9 @@ print (t)\
# Set this to non-zero at your own risk, it's dangerous.
%_rollback_transaction_on_failure 0
+# Log install/remove of packages to syslog.
+%_use_syslog 0
+
# Verify digest/signature flags for various rpm modes:
# 0x30300 (_RPMVSF_NODIGESTS)--nohdrchk if set, don't check digest(s)
# 0xc0c00 (_RPMVSF_NOSIGNATURES) --nosignature if set, don't check signature(s)
--- lib/psm.c.syslog 2008-02-01 01:40:16.0 +0100
+++ lib/psm.c 2008-02-21 21:29:32.181686473 +0100
@@ -1656,6 +1656,11 @@ rpmRC rpmpsmStage(rpmpsm psm, pkgStage s
int saveerrno;
int xx;
+#ifdef HAVE_SYSLOG_H
+/* XXX log install and removal of packages in syslog */
+int use_syslog = rpmExpandNumeric("%{?_log_to_syslog:1}%{?!_log_to_syslog:0}");
+#endif
+
/* XXX hackery to assert(!scaremem) in rpmfiNew. */
if (fi->h == NULL && fi->te && fi->te->h != NULL) fi->h = headerLink(fi->te->h);
#if 0
@@ -2453,6 +2458,16 @@ assert(psm->mi == NULL);
else
rc = rpmdbAdd(rpmtsGetRdb(ts), tid, fi->h, NULL);
(void) rpmswExit(rpmtsOp(ts, RPMTS_OP_DBADD), 0);
+#ifdef HAVE_SYSLOG_H
+ if(use_syslog) {
+ char *s;
+
+ s = headerSprintf(fi->h, "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}",
+ rpmTagTable, rpmHeaderFormats, NULL);
+ syslog(LOG_NOTICE, "[RPM] %s installed\n", s);
+ s = _free(s);
+ }
+#endif
}
if (rc != RPMRC_OK) break;
@@ -2473,6 +2488,16 @@ assert(psm->te != NULL);
(void) rpmswEnter(rpmtsOp(ts, RPMTS_OP_DBREMOVE), 0);
rc = rpmdbRemove(rpmtsGetRdb(ts), rpmtsGetTid(ts), fi->record, NULL);
(void) rpmswExit(rpmtsOp(ts, RPMTS_OP_DBREMOVE), 0);
+#ifdef HAVE_SYSLOG_H
+if(use_syslog) {
+ char *s;
+
+ s = headerSprintf(fi->h, "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}",
+ rpmTagTable, rpmHeaderFormats, NULL);
+ syslog(LOG_NOTICE, "[RPM] %s removed\n", s);
+ s = _free(s);
+ }
+#endif
if (rc != RPMRC_OK) break;
Re: [CVS] RPM: rpm-5_0: rpm/ macros.in
> The idea that rpm can be distributed with a priori drop-in knowledge > of arch names, and with one-size-fits-all compiler flags, and other > macros, > was known to be naive in the year 2000. > > Patch doesn't hurt at all, just that rpm cannot (and should not, but > I'm a radical) > continue to attempt drop-in no-fuss, no-muss, build configuration > macros. > > Naive has become will never ever be successful. I'm not sure if I get what you mean. The macro was more to avoid having to add every specific sparc arch in a spec if the build target were a specific sparc arch. Different compiler flags per sparc arch would still be independent of this.. I might of course be missing something, wouldn't be the first time. :o) -- Regards, Per Øyvind Karlsen Mandriva Norway __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
URPMI + rpm5 = true & rpm 4 backwards compatibility
Ahoi! With great help from Jeff, I have now successfully ported urpmi (& rpmtools) to rpm5, making it the first dep solver tool to get rpm 5.0 support! :) To make things nicer and easier to maintain in terms of compatibility with older rpm versions & rpm.org a function wrapper was done. It's currently available at http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/rpm/perl-URPM/trunk/rpm5compat.h?revision=238099&view=markup So what do you guys think of inclusion of this in rpm5.org tree? -- Regards, Per Øyvind Karlsen Mandriva Norway __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_0: rpm/ CHANGES rpm/lib/ Makefile.am rpm4compat.h
På Mandag 03 mars 2008 , 09:37:14 skrev Ralf S. Engelschall: > On Mon, Mar 03, 2008, Per Øyvind Karlsen wrote: > > [..] > > add rpm 4 API compatibility wrapper > > [..] > > Only for RPM 5.0 or is the commit to HEAD (for RPM 5.1) still pending? still pending, needs to be tested first -- Regards, Per Øyvind Karlsen Mandriva Norway __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
problem with lua stuff
I have a problem installing a package using lua scripts in %post:
error: Failed dependencies:
rpmlib(BuiltinLuaScripts) <= 4.2.2-1 is needed by
filesystem-2.1.9-3mdv2008.1.x86_64
So if trying to install the package with --nodeps:
rpm -Uvh --nodeps filesystem-2.1.9-3mdv2008.1.x86_64.rpm
warning: filesystem-2.1.9-3mdv2008.1.x86_64.rpm: Header V3 DSA signature:
NOKEY, key ID 26752624
Forbereder... ### [100%]
1:filesystem ### [100%]
rpm: rpmio.c:3203: Fclose: Forutsetningen (assertion) «fd && fd->magic ==
0x04463138» feilet.
Avbrutt (SIGABRT)
%post script
rpm -qp --scripts filesystem-2.1.9-3mdv2008.1.x86_64.rpm
postinstall scriptlet (using ):
function mkdir_missing(dir)
if posix.stat(dir) == nil then
posix.mkdir(dir)
end
end
mkdir_missing("/mnt/disk")
mkdir_missing("/media/floppy")
mkdir_missing("/media/cdrom")
Reproducer (i586, do s/i586/x86_64/ for x86_64;):
ftp://ftp.uninett.no/pub/linux/MandrivaLinux/devel/cooker/i586/media/main/release/filesystem-2.1.9-3mdv2008.1.i586.rpm
--
Regards,
Per Øyvind Karlsen
Mandriva Norway
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
rpmbuild gives errors when patches are commented ou
LC_ALL=C rpmbuild -bb rpm.spec error: File %PATCH69: No such file or directory error: File %PATCH107: No such file or directory error: File %PATCH125: No such file or directory In rpm.spec you can find the following related: #Patch69: rpm-4.5-bb-shortcircuit.patch #%patch69 -p0 -b .trans Both are commented out and should therefore not be of any concern.. -- Regards, Per Øyvind Karlsen Mandriva Norway __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
problem upgrading packages with epoch
This is weird: [EMAIL PROTECTED] SPECS]$ sudo rpm -Uvh /home/peroyvind/RPM/RPMS/x86_64/rpm-5.0.3-1mdv2008.1.x86_64.rpm /home/peroyvind/RPM/RPMS/x86_64/lib64rpm5.0-5.0.3-1mdv2008.1.x86_64.rpm /home/peroyvind/RPM/RPMS/x86_64/lib64rpm-devel-5.0.3-1mdv2008.1.x86_64.rpm /home/peroyvind/RPM/RPMS/x86_64/rpm-build-5.0.3-1mdv2008.1.x86_64.rpm /home/peroyvind/RPM/RPMS/x86_64/python-rpm-5.0.3-1mdv2008.1.x86_64.rpm /home/peroyvind/RPM/RPMS/x86_64/perl-RPM-5.0.3-1mdv2008.1.x86_64.rpm /home/peroyvind/RPM/RPMS/x86_64/rpm-debug-5.0.3-1mdv2008.1.x86_64.rpm error: Failed dependencies: lib64rpm5.0 = 5.0.3-1mdv2008.1 is needed by rpm-5.0.3-1mdv2008.1.x86_64 rpm = 5.0.3-1mdv2008.1 is needed by lib64rpm-devel-5.0.3-1mdv2008.1.x86_64 rpm = 5.0.3-1mdv2008.1 is needed by rpm-build-5.0.3-1mdv2008.1.x86_64 rpm = 5.0.3-1mdv2008.1 is needed by python-rpm-5.0.3-1mdv2008.1.x86_64 [EMAIL PROTECTED] SPECS]$ sudo rpm -Uvh /home/peroyvind/RPM/RPMS/x86_64/*-5.0.3-1mdv2008.1.x86_64.rpm error: Failed dependencies: rpm = 5.0.3-1mdv2008.1 is needed by lib64rpm-devel-5.0.3-1mdv2008.1.x86_64 rpm = 5.0.3-1mdv2008.1 is needed by python-rpm-5.0.3-1mdv2008.1.x86_64 lib64rpm5.0 = 5.0.3-1mdv2008.1 is needed by rpm-5.0.3-1mdv2008.1.x86_64 rpm = 5.0.3-1mdv2008.1 is needed by rpm-build-5.0.3-1mdv2008.1.x86_64 [EMAIL PROTECTED] SPECS]$ rpm -qp --provides /home/peroyvind/RPM/RPMS/x86_64/rpm-5.0.3-1mdv2008.1.x86_64.rpm rpm = 1:5.0.3-1mdv2008.1 So, original packages are 5.0.3-1, new packages are 1:5.0.3-1 and should therefore be newer.. More verbosive rpm output attached. -- Regards, Per Øyvind Karlsen Mandriva Norway D: Expected size: 1102367 = lead(96)+sigs(180)+pad(4)+data(1102087) D: Actual size: 1102367 D: /home/peroyvind/RPM/RPMS/x86_64/lib64rpm5.0-5.0.3-1mdv2008.1.x86_64.rpm: Header SHA1 digest: OK (565162ee7ff39a9b82db11e882edc6f6ee2600ec) D: opening db environment /var/lib/rpm/Packages mpool D: opening db index /var/lib/rpm/Packages rdonly mode=0x0 D: locked db index /var/lib/rpm/Packages D: opening db index /var/lib/rpm/Name rdonly mode=0x0 D: rpmdb: read h#2738 Header SHA1 digest: OK (6ede832e44b411bdd246383b5678af8513ec455f) D:upgrade erases lib64rpm5.0-5.0.3-0.7mdv2008.1.x86_64 D: Expected size: 9031915 = lead(96)+sigs(180)+pad(4)+data(9031635) D: Actual size: 9031915 D: /home/peroyvind/RPM/RPMS/x86_64/lib64rpm-devel-5.0.3-1mdv2008.1.x86_64.rpm: Header SHA1 digest: OK (31b25cf31db0ca957e0c5b5615a5239df7f189c4) D: rpmdb: read h#2740 Header SHA1 digest: OK (f5bb882a22ac98c4c0638c1331a824f1062f0c1d) D:upgrade erases lib64rpm-devel-5.0.3-0.7mdv2008.1.x86_64 D: Expected size: 110011 = lead(96)+sigs(180)+pad(4)+data(109731) D: Actual size: 110011 D: /home/peroyvind/RPM/RPMS/x86_64/perl-RPM-5.0.3-1mdv2008.1.x86_64.rpm: Header SHA1 digest: OK (4d9511726cc8238ed277970f0131718be32f3f89) D: rpmdb: read h#2743 Header SHA1 digest: OK (9bb68023d366d277c4eca09a134cf9463bcfb0fe) D:upgrade erases perl-RPM-5.0.3-0.7mdv2008.1.x86_64 D: Expected size: 314918 = lead(96)+sigs(180)+pad(4)+data(314638) D: Actual size: 314918 D: /home/peroyvind/RPM/RPMS/x86_64/python-rpm-5.0.3-1mdv2008.1.x86_64.rpm: Header SHA1 digest: OK (a5e174039abbc1d557da61bdef82a8b067a11be3) D: rpmdb: read h#2742 Header SHA1 digest: OK (60bb15c067b1e675ee52bf993c1cf700f5945251) D:upgrade erases python-rpm-5.0.3-0.7mdv2008.1.x86_64 D: Expected size: 6528011 = lead(96)+sigs(180)+pad(4)+data(6527731) D: Actual size: 6528011 D: /home/peroyvind/RPM/RPMS/x86_64/rpm-5.0.3-1mdv2008.1.x86_64.rpm: Header SHA1 digest: OK (670f79989ec7c1bbfd9d0b24910f9415d3c1ee61) D: rpmdb: read h#2739 Header SHA1 digest: OK (294b371cc42b1373340f1a9fb74d85427c39c151) D:upgrade erases rpm-5.0.3-0.7mdv2008.1.x86_64 D: Expected size: 248927 = lead(96)+sigs(180)+pad(4)+data(248647) D: Actual size: 248927 D: /home/peroyvind/RPM/RPMS/x86_64/rpm-build-5.0.3-1mdv2008.1.x86_64.rpm: Header SHA1 digest: OK (d8c721fc32d470d3616b627d0ad7856b47866c53) D: rpmdb: read h#2741 Header SHA1 digest: OK (67e96fcd06825c15a1b892cdf447699c9a56f121) D:upgrade erases rpm-build-5.0.3-0.7mdv2008.1.x86_64 D: Expected size: 32988779 = lead(96)+sigs(180)+pad(4)+data(32988499) D: Actual size: 32988779 D: /home/peroyvind/RPM/RPMS/x86_64/rpm-debug-5.0.3-1mdv2008.1.x86_64.rpm: Header SHA1 digest: OK (3148b0db7d0ce387525b4e619cfb2261c9920a94) D: rpmdb: read h#2744 Header SHA1 digest: OK (9ac03c2300bd7286dc993166eddbec3be22b4234) D:upgrade erases rpm-debug-5.0.3-0.7mdv2008.1.x86_64 D: == +++ lib64rpm5.0-5.0.3-1mdv2008.1.x86_64 x86_64/linux 0x0 D: opening db index /var/lib/rpm/Basenames rdonly mode=0x0 D: opening db index /var/lib/rpm/Pubkeys rdonly mode=0x0 D: == DSA pubkey id dd684d7a 26752624 (h#1489) D: rpmdb: read h#2974 Header V3 DSA signature: OK, key ID 26752624 D
Re: problem upgrading packages with epoch
På Tirsdag 04 mars 2008 , 21:55:15 skrev Per Øyvind Karlsen: > This is weird: > [EMAIL PROTECTED] SPECS]$ sudo > rpm -Uvh /home/peroyvind/RPM/RPMS/x86_64/rpm-5.0.3-1mdv2008.1.x86_64.rpm > /home/peroyvind/RPM/RPMS/x86_64/lib64rpm5.0-5.0.3-1mdv2008.1.x86_64.rpm > /home/peroyvind/RPM/RPMS/x86_64/lib64rpm-devel-5.0.3-1mdv2008.1.x86_64.rpm > /home/peroyvind/RPM/RPMS/x86_64/rpm-build-5.0.3-1mdv2008.1.x86_64.rpm > /home/peroyvind/RPM/RPMS/x86_64/python-rpm-5.0.3-1mdv2008.1.x86_64.rpm > /home/peroyvind/RPM/RPMS/x86_64/perl-RPM-5.0.3-1mdv2008.1.x86_64.rpm > /home/peroyvind/RPM/RPMS/x86_64/rpm-debug-5.0.3-1mdv2008.1.x86_64.rpm > error: Failed dependencies: > lib64rpm5.0 = 5.0.3-1mdv2008.1 is needed by > rpm-5.0.3-1mdv2008.1.x86_64 > rpm = 5.0.3-1mdv2008.1 is needed by > lib64rpm-devel-5.0.3-1mdv2008.1.x86_64 > rpm = 5.0.3-1mdv2008.1 is needed by > rpm-build-5.0.3-1mdv2008.1.x86_64 rpm = 5.0.3-1mdv2008.1 is needed by > python-rpm-5.0.3-1mdv2008.1.x86_64 [EMAIL PROTECTED] SPECS]$ sudo > rpm -Uvh /home/peroyvind/RPM/RPMS/x86_64/*-5.0.3-1mdv2008.1.x86_64.rpm > error: Failed dependencies: > rpm = 5.0.3-1mdv2008.1 is needed by > lib64rpm-devel-5.0.3-1mdv2008.1.x86_64 > rpm = 5.0.3-1mdv2008.1 is needed by > python-rpm-5.0.3-1mdv2008.1.x86_64 lib64rpm5.0 = 5.0.3-1mdv2008.1 is needed > by > rpm-5.0.3-1mdv2008.1.x86_64 > rpm = 5.0.3-1mdv2008.1 is needed by > rpm-build-5.0.3-1mdv2008.1.x86_64 [EMAIL PROTECTED] SPECS]$ > rpm -qp --provides > /home/peroyvind/RPM/RPMS/x86_64/rpm-5.0.3-1mdv2008.1.x86_64.rpm rpm = > 1:5.0.3-1mdv2008.1 > > So, original packages are 5.0.3-1, new packages are 1:5.0.3-1 and should > therefore be newer.. > > More verbosive rpm output attached. actually I'm a bit wrong, original packages are 5.0.3-0.7, so these packages should be newer regardless of epoch or not. Btw. I forgot to unset locale for attachment, should be easy to understand, but if not; "JA" = "YES", "NEI" = "NO". :) -- Regards, Per Øyvind Karlsen Mandriva Norway __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_0: rpm/lib/ rpm4compat.h
På Onsdag 05 mars 2008 , 15:49:42 skrev Hatle, Mark: > Søppelpost status: Spamassassin 0% mulighet til å være søppelpost. > > Full rapport: > No, score=-2.0 required=7.0 tests=BAYES_00,FS_GAPPY_2, > HTML_50_60,HTML_MESSAGE,TW_CP autolearn=ham version=3.0.4 I believe the > following chunk of code is now incorrect. "stpcpy" returns the address to > the end of the strip, while strcpy returns the address to the start of the > string. So this stpcpy -> strcpy doesn't take that into account.. so the > results look to me like t="\0". you're right, it did break, reverting.. -- Regards, Per Øyvind Karlsen Mandriva Norway __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: problem upgrading packages with epoch
never mind this one, just a packaging mistake of mine :) -- Regards, Per Øyvind Karlsen Mandriva Norway __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/lib/ rpm4compat.h
På Torsdag 06 mars 2008 , 19:11:48 skrev Jeff Johnson: > Um, hard to say what you are being compatible with. > > Only rpm-4.4.2.2 has chosen to rename the function. Well, I renamed it for rpm-5_0 & rpm-4_5 earlier. Regardless, compatibility with them all is tried at achieving.. ;p -- Regards, Per Øyvind Karlsen Mandriva Norway __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
rpm segfaults when upgrading package if more than one entry in /etc/rpm/platform
Topic says it all, see attachment. -- Regards, Per Øyvind Karlsen ==398== Memcheck, a memory error detector. ==398== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==398== Using LibVEX rev 1804, a library for dynamic binary translation. ==398== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==398== Using valgrind-3.3.0, a dynamic binary instrumentation framework. ==398== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==398== --398-- Command line --398--rpm --398---Uvv --398--rpmtools-5.4-1mdv2008.1.x86_64.rpm --398-- Startup, with flags: --398---v --398-- Contents of /proc/version: --398-- Linux version 2.6.24.3-laptop-4mnb ([EMAIL PROTECTED]) (gcc version 4.2.3 (4.2.3-6mnb1)) #1 SMP Thu Mar 20 15:24:53 CET 2008 --398-- Arch and hwcaps: AMD64, amd64-sse2 --398-- Page sizes: currently 4096, max supported 4096 --398-- Valgrind library directory: /usr/lib64/valgrind --398-- Reading syms from /bin/rpm (0x40) --398-- Reading debug info from /usr/lib/debug/bin/rpm.debug... --398-- Reading syms from /lib64/ld-2.7.so (0x400) --398-- Reading syms from /usr/lib64/valgrind/amd64-linux/memcheck (0x3800) --398--object doesn't have a symbol table --398--object doesn't have a dynamic symbol table --398-- Reading suppressions file: /usr/lib64/valgrind/default.supp --398-- Reading syms from /usr/lib64/valgrind/amd64-linux/vgpreload_core.so (0x4A1B000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so (0x4C1C000) --398--object doesn't have a symbol table --398-- REDIR: 0x40140c0 (index) redirected to 0x4c1fb70 (index) --398-- REDIR: 0x4014270 (strcmp) redirected to 0x4c1fdd0 (strcmp) --398-- REDIR: 0x40142a0 (strlen) redirected to 0x4c1fd00 (strlen) --398-- Reading syms from /usr/lib64/librpmbuild-5.0.so (0x4E23000) --398-- Reading debug info from /usr/lib/debug/usr/lib64/librpmbuild-5.0.so.debug... --398-- Reading syms from /usr/lib64/librpm-5.0.so (0x5054000) --398-- Reading debug info from /usr/lib/debug/usr/lib64/librpm-5.0.so.debug... --398-- Reading syms from /usr/lib64/librpmdb-5.0.so (0x52C8000) --398-- Reading debug info from /usr/lib/debug/usr/lib64/librpmdb-5.0.so.debug... --398-- Reading syms from /usr/lib64/librpmio-5.0.so (0x551C000) --398-- Reading debug info from /usr/lib/debug/usr/lib64/librpmio-5.0.so.debug... --398-- Reading syms from /usr/lib64/librpmmisc-5.0.so (0x5796000) --398-- Reading debug info from /usr/lib/debug/usr/lib64/librpmmisc-5.0.so.debug... --398-- Reading syms from /usr/lib64/libbeecrypt.so.7.0.0 (0x5AC3000) --398--object doesn't have a symbol table --398-- Reading syms from /lib64/libpopt.so.0.0.0 (0x5CEF000) --398--object doesn't have a symbol table --398-- Reading syms from /lib64/libpthread-2.7.so (0x5EF7000) --398-- Reading syms from /lib64/librt-2.7.so (0x6112000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/libelf-0.131.so (0x631B000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/libneon.so.26.0.4 (0x652E000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/libssl.so.0.9.8 (0x6753000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/libcrypto.so.0.9.8 (0x69A3000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/libgssapi_krb5.so.2.2 (0x6D44000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/libkrb5.so.3.3 (0x6F71000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/libk5crypto.so.3.1 (0x7211000) --398--object doesn't have a symbol table --398-- Reading syms from /lib64/libcom_err.so.2.1 (0x7437000) --398--object doesn't have a symbol table --398-- Reading syms from /lib64/libresolv-2.7.so (0x7639000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/libxml2.so.2.6.31 (0x784E000) --398--object doesn't have a symbol table --398-- Reading syms from /lib64/libdl-2.7.so (0x7B8D000) --398--object doesn't have a symbol table --398-- Reading syms from /lib64/libz.so.1.2.3 (0x7D91000) --398--object doesn't have a symbol table --398-- Reading syms from /lib64/libm-2.7.so (0x7FA5000) --398--object doesn't have a symbol table --398-- Reading syms from /lib64/libc-2.7.so (0x8226000) --398--object doesn't have a symbol table --398-- Reading syms from /lib64/libgcc_s-4.2.3.so.1 (0x857A000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/libstdc++.so.6.0.9 (0x8787000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/libkrb5support.so.0.1 (0x8A8C000) --398--object doesn't have a symbol table --398-- REDI
Re: [CVS] RPM: rpm/ CHANGES INSTALL rpm/rpmio/ LzmaDecode.c LzmaDecode.h L...
På Onsdag 02 april 2008 , 10:20:40 skrev Anders F Björklund: > Ralf S. Engelschall wrote: > > Hmmm... IMHO this > > was a NO-OP semantically and just broke many things? Can we backout > > and > > keep the code we had before? As I mentioned in INSTALL, just a few > > days > > ago I reviewed the code against 4.57 and it is identical except for > > our > > already applied fixes. But with the now overwritten code we lost those > > cleanups. What exactly was broken? Tested and seemed to work all fine here.. I updated it since it in terms of maintenance is always a nice thing to keep code in sync with upstream.. > > Please revert, and let's keep LZMA reasonably sane - instead of the > hodge-podge merge of tukaani.org and 7-zip.org that Mandriva uses... As the decoder itself only uses LzmaDecode.c from lzma sdk, I don't see how this relates to lzma utils nor how it's packaged in Mandriva. > > Even if that means staying with LZMA 4.32 until the new one is ready. > (unfortunately also means staying with the old LZMA_Alone file format) I don't see see why this unless there would be any incompatibilities caused by it.. -- Regards, Per Øyvind Karlsen __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES INSTALL rpm/rpmio/ LzmaDecode.c LzmaDecode.h L...
På Onsdag 02 april 2008 , 20:01:34 skrev Per Øyvind Karlsen: > What exactly was broken? Tested and seemed to work all fine here.. > I updated it since it in terms of maintenance is always a nice thing to > keep code in sync with upstream.. Ah, I see now how it was broken for snapshots with LzmaTypes.h being excluded. Why is this? And did it break anything besides this? -- Regards, Per Øyvind Karlsen __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES INSTALL rpm/rpmio/ LzmaDecode.c LzmaDecode.h L...
2008/4/2, Ralf S. Engelschall <[EMAIL PROTECTED]<[EMAIL PROTECTED]> >: > > On Wed, Apr 02, 2008, Per Øyvind Karlsen wrote: > > > På Onsdag 02 april 2008 , 20:01:34 skrev Per Øyvind Karlsen: > > > What exactly was broken? Tested and seemed to work all fine here.. > > > I updated it since it in terms of maintenance is always a nice thing > to > > > keep code in sync with upstream.. > > > > Ah, I see now how it was broken for snapshots with LzmaTypes.h being > excluded. > > Why is this? > > > Because you still had the file locally staying around but in the > snapshot it was not included by "make dist". > > > > And did it break anything besides this? > > > Non-GCC compilers rejected the source at all. The particular error > message I've no longer at hand, but you can try yourself with e.g. Intel > C/C++ under Linux. > ah, I was suspecting that it could be related to something outside the world of gcc. :o)
Re: [CVS] RPM: rpm/ CHANGES macros.in
På Torsdag 10 april 2008 , 13:39:57 skrev Anders F Björklund: > Jeff Johnson wrote: > > I have multip[le issues with changes like this: > > > > 1) the patch uses envvar's > > Using envvar's forces remote rpm to carry an environment along > > in order to run remote commands, and largely forces remote > > execution with > > shell. There are many times/places that macros need expansion outside > > of a shell environment. > > > > 2) the patch adds support for functionality that rpm itself does > > not need or use. > > The number of cpu's has nothing to do with rpmbuild. Of course it does, make is used by rpmbuild, having a macro passing -j argument to it based on number of cpus makes perfect sense. > > > > 3) the patch continues to assume that a one-size-fits-all rpm > > configurations is viable. > > On many if not most vendor systems, rpm configuration is > > controlled outside > > of rpm itself with packages like redhat-rpm-config. I don't really think that something that might not be fitting all sizes (in the one size fits all scheme) should prohibit it's inclusion, if that were true we'd have to clean out things already existing in the macros. If the fear is to stuff too much junk irrelevant for some into the macros, then maybe we could have a second set of macros for such? In my experience and annoyance is that lack of standardization upstream leads to a lot of unnecessary fragmentation in different ways of doing the same thing around various distributions etc. Macros can always be redefined if not appropriate for someone, so even then I think it's good to have the standard macro to use to easily override and adopt for own purpose. So unless something gets actually broken by this, I really don't see the problem. > > > > But you need to find out what will happen. Perfectly understood. > > I didn't like the change either, but made it more portable anyway... > > My main problem is that the number of online processors doesn't > have a straight mapping over to the number of parallel make jobs > For instance, now that containers are fairly common it is regular > to have a build instance with e.g. 8 CPU but only e.g. 256M RAM. > > And running "make -j8" on such a setup, quickly leads to swapping... What a highly usual and standard configuration.. ;p -- Regards, Per Øyvind Karlsen __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES macros.in
På Torsdag 10 april 2008 , 17:19:38 skrev Jeff Johnson: > On Apr 10, 2008, at 11:09 AM, Per Øyvind Karlsen wrote: > > På Torsdag 10 april 2008 , 13:39:57 skrev Anders F Björklund: > >> Jeff Johnson wrote: > >>> I have multip[le issues with changes like this: > >>> > >>> 1) the patch uses envvar's > >>> Using envvar's forces remote rpm to carry an environment along > >>> in order to run remote commands, and largely forces remote > >>> execution with > >>> shell. There are many times/places that macros need expansion > >>> outside > >>> of a shell environment. > >>> > >>> 2) the patch adds support for functionality that rpm itself does > >>> not need or use. > >>> The number of cpu's has nothing to do with rpmbuild. > > > > Of course it does, make is used by rpmbuild, having a macro passing -j > > argument to it based on number of cpus makes perfect sense. > > Note "make", not rpmbuild in your statement. We are saying the same > thing ... Exactly, so you can't really make such distinctions between what is rpm or not.. Just because something isn't part of rpm doesn't mean you can't make macros for it, rpm would after all be pretty useless without all the stuff that's not strictly a part of it.. > > >>> 3) the patch continues to assume that a one-size-fits-all rpm > >>> configurations is viable. > >>> On many if not most vendor systems, rpm configuration is > >>> controlled outside > >>> of rpm itself with packages like redhat-rpm-config. > > > > I don't really think that something that might not be fitting all > > sizes (in > > the one size fits all scheme) should prohibit it's inclusion, if > > that were > > true we'd have to clean out things already existing in the macros. > > OK. So when rpmbuild fails because /usr/bin/getconf is not present, or > not the correct getconf to use because of added --prefix, you will get > the pleasure of designing the portable fix for your patch. Well, it will already fall back to if getconf is missing.. But sure, it still relies on environment variables, so fallback shouldn't rely on this.. > > Hint: rpm has already internalized all of getconf(1) functionality, > which > your patch chooses not to use. Thanks for the hint, will adopt. :) > > > If the fear is to stuff too much junk irrelevant for some into the > > macros, > > then maybe we could have a second set of macros for such? In my > > experience > > and annoyance is that lack of standardization upstream leads to a > > lot of > > unnecessary fragmentation in different ways of doing the same thing > > around > > various distributions etc. > > > > Macros can always be redefined if not appropriate for someone, so > > even then I > > think it's good to have the standard macro to use to easily > > override and > > adopt for own purpose. > > So unless something gets actually broken by this, I really don't > > see the > > problem. > > > >>> But you need to find out what will happen. Perfectly understood. > >> > >> I didn't like the change either, but made it more portable anyway... > >> > >> My main problem is that the number of online processors doesn't > >> have a straight mapping over to the number of parallel make jobs > >> For instance, now that containers are fairly common it is regular > >> to have a build instance with e.g. 8 CPU but only e.g. 256M RAM. > >> > >> And running "make -j8" on such a setup, quickly leads to swapping... > > > > What a highly usual and standard configuration.. ;p > > You gonna get to solve the problem when the time comes, not me ;-) > > Have fun! > > And %_initrd is gonna be even harder to solve than "make -j NCPU". There > are already issues with using /etc/rpm/platform, and that's even a > path that > rpm itself uses. > > You are so so doomed with %_initrd ... I will enjoy reading your > replies ;-) Noone is forced to use %_initrddir, and people who do use it are free to override it. I really don't see the problem, not usable by everyone != real problem.. -- Regards, Per Øyvind Karlsen __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm/ CHANGES macros.in
På Torsdag 10 april 2008 , 17:55:05 skrev Jeff Johnson: > Not true. There are already Packaging Policy Police and you have > chosen a macro > name that falls within their claimed territority, and are going to > attempt to populate > that macro with values that are "generally" useful, rather than > leaving the value > to whatever Packaging Police Authority to chose to do with as they wish. The problem is that such Packaging Police Authority are quite fragmented and implementing the same thing in each their own way due to lack of existing macros upstream. > > You chose to conflict by refactoring a platform specific macro name > into default > rpm configuration. Considering that macros may be overriden, there's no conflict. Leaving a some what standard macro in place then for others to override it for their use is IMHO better since people will then at least use the same name for macro making spec files a hint more portable. I do recall someone criticizing creation of macros like %mkrel in Mandriva that were non-standard and making things less portable. ;p > > rpm5.org devel needs to be vendor neutral in order to focus on more > important > issues than what value (and whether it is a symlink or a directory) > the AutoFu (and > LSB and FHS and MacOSX and ...) chose to configure as default. Unless the use of such macros are forced on anyone, there's no problem. I think one of the biggest problems with rpm these days is lack of standardization and everyone keeping reinvent the weel making it a lot harder to share efforts between distributions, which is in contrast to ie. the Debian world. Having macros in place upstream for common actions won't force anything upon anyone, but will make it more likely that distributions pick up on existing macros.. -- Regards, Per Øyvind Karlsen __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
rpm 5.1 segfaults
See attachment for more info, reproducer found at ftp://ftp.uninett.no/pub/linux/MandrivaLinux/devel/cooker/x86_64/media/main/release/ . -- Regards, Per Øyvind Karlsen ==4687== Memcheck, a memory error detector. ==4687== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==4687== Using LibVEX rev 1804, a library for dynamic binary translation. ==4687== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==4687== Using valgrind-3.3.0, a dynamic binary instrumentation framework. ==4687== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==4687== --4687-- Command line --4687--rpm --4687---Uvv --4687--drakxtools-curses-10.29-1mdv2008.1.x86_64.rpm --4687--drakx-net-text-0.34-1mdv2008.1.noarch.rpm --4687--libdrakx-net-0.34-1mdv2008.1.noarch.rpm --4687-- Startup, with flags: --4687---v --4687----leak-check=full --4687-- Contents of /proc/version: --4687-- Linux version 2.6.24.4-laptop-1mnb ([EMAIL PROTECTED]) (gcc version 4.2.3 (4.2.3-6mnb1)) #1 SMP Thu Mar 27 14:58:35 CET 2008 --4687-- Arch and hwcaps: AMD64, amd64-sse2 --4687-- Page sizes: currently 4096, max supported 4096 --4687-- Valgrind library directory: /usr/lib64/valgrind --4687-- Reading syms from /bin/rpm (0x40) --4687-- Reading debug info from /usr/lib/debug/bin/rpm.debug... --4687-- Reading syms from /lib64/ld-2.7.so (0x400) --4687-- Reading syms from /usr/lib64/valgrind/amd64-linux/memcheck (0x3800) --4687--object doesn't have a symbol table --4687--object doesn't have a dynamic symbol table --4687-- Reading suppressions file: /usr/lib64/valgrind/default.supp --4687-- Reading syms from /usr/lib64/valgrind/amd64-linux/vgpreload_core.so (0x4A1B000) --4687--object doesn't have a symbol table --4687-- Reading syms from /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so (0x4C1C000) --4687--object doesn't have a symbol table --4687-- REDIR: 0x40140c0 (index) redirected to 0x4c1fb70 (index) --4687-- REDIR: 0x4014270 (strcmp) redirected to 0x4c1fdd0 (strcmp) --4687-- REDIR: 0x40142a0 (strlen) redirected to 0x4c1fd00 (strlen) --4687-- Reading syms from /usr/lib64/librpmbuild-5.0.so (0x4E23000) --4687-- Reading debug info from /usr/lib/debug/usr/lib64/librpmbuild-5.0.so.debug... --4687-- Reading syms from /usr/lib64/librpm-5.0.so (0x5053000) --4687-- Reading debug info from /usr/lib/debug/usr/lib64/librpm-5.0.so.debug... --4687-- Reading syms from /usr/lib64/librpmdb-5.0.so (0x52C9000) --4687-- Reading debug info from /usr/lib/debug/usr/lib64/librpmdb-5.0.so.debug... --4687-- Reading syms from /usr/lib64/librpmio-5.0.so (0x551F000) --4687-- Reading debug info from /usr/lib/debug/usr/lib64/librpmio-5.0.so.debug... --4687-- Reading syms from /usr/lib64/librpmmisc-5.0.so (0x579C000) --4687-- Reading debug info from /usr/lib/debug/usr/lib64/librpmmisc-5.0.so.debug... --4687-- Reading syms from /usr/lib64/libbeecrypt.so.7.0.0 (0x5ACF000) --4687--object doesn't have a symbol table --4687-- Reading syms from /lib64/libpopt.so.0.0.0 (0x5CFB000) --4687--object doesn't have a symbol table --4687-- Reading syms from /lib64/libpthread-2.7.so (0x5F04000) --4687-- Reading syms from /lib64/librt-2.7.so (0x611F000) --4687--object doesn't have a symbol table --4687-- Reading syms from /usr/lib64/libelf-0.131.so (0x6328000) --4687--object doesn't have a symbol table --4687-- Reading syms from /usr/lib64/libneon.so.26.0.4 (0x653B000) --4687--object doesn't have a symbol table --4687-- Reading syms from /usr/lib64/libssl.so.0.9.8 (0x676) --4687--object doesn't have a symbol table --4687-- Reading syms from /usr/lib64/libcrypto.so.0.9.8 (0x69B) --4687--object doesn't have a symbol table --4687-- Reading syms from /usr/lib64/libgssapi_krb5.so.2.2 (0x6D51000) --4687--object doesn't have a symbol table --4687-- Reading syms from /usr/lib64/libkrb5.so.3.3 (0x6F7E000) --4687--object doesn't have a symbol table --4687-- Reading syms from /usr/lib64/libk5crypto.so.3.1 (0x721E000) --4687--object doesn't have a symbol table --4687-- Reading syms from /lib64/libcom_err.so.2.1 (0x7444000) --4687--object doesn't have a symbol table --4687-- Reading syms from /lib64/libresolv-2.7.so (0x7646000) --4687--object doesn't have a symbol table --4687-- Reading syms from /usr/lib64/libxml2.so.2.6.31 (0x785B000) --4687--object doesn't have a symbol table --4687-- Reading syms from /lib64/libdl-2.7.so (0x7B9A000) --4687--object doesn't have a symbol table --4687-- Reading syms from /lib64/libz.so.1.2.3 (0x7D9E000) --4687--object doesn't have a symbol table --4687-- Reading syms from /lib64/libm-2.7.so (0x7FB2000) --4687--object doesn't have a symbol table --4687-- Reading syms from /lib64/libc-2.7.so (0x8233000) --4687--object doesn't have a symbol table --4687-- Reading syms from /lib64/libgcc_s-4.2.3.
Re: rpm 5.1 segfaults
På Mandag 14 april 2008 , 18:50:07 skrev Per Øyvind Karlsen: > See attachment for more info, reproducer found at > ftp://ftp.uninett.no/pub/linux/MandrivaLinux/devel/cooker/x86_64/media/main >/release/ . updated running with --rpmdsdebug -- Regards, Per Øyvind Karlsen ==398== Memcheck, a memory error detector. ==398== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==398== Using LibVEX rev 1804, a library for dynamic binary translation. ==398== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==398== Using valgrind-3.3.0, a dynamic binary instrumentation framework. ==398== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==398== --398-- Command line --398--rpm --398---Uvv --398--rpmtools-5.4-1mdv2008.1.x86_64.rpm --398-- Startup, with flags: --398---v --398-- Contents of /proc/version: --398-- Linux version 2.6.24.3-laptop-4mnb ([EMAIL PROTECTED]) (gcc version 4.2.3 (4.2.3-6mnb1)) #1 SMP Thu Mar 20 15:24:53 CET 2008 --398-- Arch and hwcaps: AMD64, amd64-sse2 --398-- Page sizes: currently 4096, max supported 4096 --398-- Valgrind library directory: /usr/lib64/valgrind --398-- Reading syms from /bin/rpm (0x40) --398-- Reading debug info from /usr/lib/debug/bin/rpm.debug... --398-- Reading syms from /lib64/ld-2.7.so (0x400) --398-- Reading syms from /usr/lib64/valgrind/amd64-linux/memcheck (0x3800) --398--object doesn't have a symbol table --398--object doesn't have a dynamic symbol table --398-- Reading suppressions file: /usr/lib64/valgrind/default.supp --398-- Reading syms from /usr/lib64/valgrind/amd64-linux/vgpreload_core.so (0x4A1B000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so (0x4C1C000) --398--object doesn't have a symbol table --398-- REDIR: 0x40140c0 (index) redirected to 0x4c1fb70 (index) --398-- REDIR: 0x4014270 (strcmp) redirected to 0x4c1fdd0 (strcmp) --398-- REDIR: 0x40142a0 (strlen) redirected to 0x4c1fd00 (strlen) --398-- Reading syms from /usr/lib64/librpmbuild-5.0.so (0x4E23000) --398-- Reading debug info from /usr/lib/debug/usr/lib64/librpmbuild-5.0.so.debug... --398-- Reading syms from /usr/lib64/librpm-5.0.so (0x5054000) --398-- Reading debug info from /usr/lib/debug/usr/lib64/librpm-5.0.so.debug... --398-- Reading syms from /usr/lib64/librpmdb-5.0.so (0x52C8000) --398-- Reading debug info from /usr/lib/debug/usr/lib64/librpmdb-5.0.so.debug... --398-- Reading syms from /usr/lib64/librpmio-5.0.so (0x551C000) --398-- Reading debug info from /usr/lib/debug/usr/lib64/librpmio-5.0.so.debug... --398-- Reading syms from /usr/lib64/librpmmisc-5.0.so (0x5796000) --398-- Reading debug info from /usr/lib/debug/usr/lib64/librpmmisc-5.0.so.debug... --398-- Reading syms from /usr/lib64/libbeecrypt.so.7.0.0 (0x5AC3000) --398--object doesn't have a symbol table --398-- Reading syms from /lib64/libpopt.so.0.0.0 (0x5CEF000) --398--object doesn't have a symbol table --398-- Reading syms from /lib64/libpthread-2.7.so (0x5EF7000) --398-- Reading syms from /lib64/librt-2.7.so (0x6112000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/libelf-0.131.so (0x631B000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/libneon.so.26.0.4 (0x652E000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/libssl.so.0.9.8 (0x6753000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/libcrypto.so.0.9.8 (0x69A3000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/libgssapi_krb5.so.2.2 (0x6D44000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/libkrb5.so.3.3 (0x6F71000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/libk5crypto.so.3.1 (0x7211000) --398--object doesn't have a symbol table --398-- Reading syms from /lib64/libcom_err.so.2.1 (0x7437000) --398--object doesn't have a symbol table --398-- Reading syms from /lib64/libresolv-2.7.so (0x7639000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/libxml2.so.2.6.31 (0x784E000) --398--object doesn't have a symbol table --398-- Reading syms from /lib64/libdl-2.7.so (0x7B8D000) --398--object doesn't have a symbol table --398-- Reading syms from /lib64/libz.so.1.2.3 (0x7D91000) --398--object doesn't have a symbol table --398-- Reading syms from /lib64/libm-2.7.so (0x7FA5000) --398--object doesn't have a symbol table --398-- Reading syms from /lib64/libc-2.7.so (0x8226000) --398--object doesn't have a symbol table --398-- Reading syms from /lib64/libgcc_s-4.2.3.so.1 (0x857A000) --398--object doesn't have a symbol table --398-- Reading syms from /usr/lib64/libstdc++.so
Re: rpm 5.1 segfaults
På Tirsdag 15 april 2008 , 11:41:24 skrev Pixel: > Jeff Johnson <[EMAIL PROTECTED]> writes: > > On Apr 14, 2008, at 3:34 PM, Per Øyvind Karlsen wrote: > >> På Mandag 14 april 2008 , 19:52:30 skrev Per Øyvind Karlsen: > >>> På Mandag 14 april 2008 , 18:50:07 skrev Per Øyvind Karlsen: > >>>> See attachment for more info, reproducer found at > >>>> ftp://ftp.uninett.no/pub/linux/MandrivaLinux/devel/cooker/x86_64/ > >>>> media/ma in /release/ . > >>> > >>> updated running with --rpmdsdebug > >> > >> grf, here's the correct one > > > > Um, how was the drakxtools-curses-10.29-1mdv2008.1.x86_64.rpm > > package produced? > > > > Every modern version of rpm attempts to insure that dependencies > > are pre-sorted so that binary, rather than linear, search can be used. > > > > Now I find that one of the packages in your segfault has unsorted > > requires: > > mandriva uses "%define _use_internal_dependency_generator 0" which > causes this behaviour. > > afaik there's no real reason for mandriva using this setting > __ > RPM Package Managerhttp://rpm5.org > Developer Communication Listrpm-devel@rpm5.org Well, the argument says: # Use internal dependency generator rather than external helpers? So by not disabling it our own helpers won't be used, am I missing something here? Anyways, I tried rebuilding it with rpm 5.1.0, same happens. -- Regards, Per Øyvind Karlsen __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm 5.1 segfaults
På Tirsdag 15 april 2008 , 18:02:05 skrev Jeff Johnson: > On Apr 15, 2008, at 11:51 AM, Per Øyvind Karlsen wrote: > > Anyways, I tried rebuilding it with rpm 5.1.0, same happens. > > Unsorted dependencies may be just one of several flaws. > > Did you try reproducing with the patch I posted? The patch > should verify whether my hypothesis that the index into the dependency > set is the fundamental flaw. Yupp, it gives the same assertion error. > > Also try reproducing with --noparentdirs ... I have parent dir deps disabled by default. -- Regards, Per Øyvind Karlsen __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm 5.1 segfaults
På Tirsdag 15 april 2008 , 18:30:31 skrev Jeff Johnson: > On Apr 15, 2008, at 12:19 PM, Per Øyvind Karlsen wrote: > > På Tirsdag 15 april 2008 , 18:02:05 skrev Jeff Johnson: > >> On Apr 15, 2008, at 11:51 AM, Per Øyvind Karlsen wrote: > >>> Anyways, I tried rebuilding it with rpm 5.1.0, same happens. > >> > >> Unsorted dependencies may be just one of several flaws. > >> > >> Did you try reproducing with the patch I posted? The patch > >> should verify whether my hypothesis that the index into the > >> dependency > >> set is the fundamental flaw. > > > > Yupp, it gives the same assertion error. > > Does it say assertion failed or does it just segfault? The assertion > failure is different than the segfault. There is no "same". I noticed just now that my previous mail about this didn't make it to the list since I sent it from the wrong address. This is what happens: [EMAIL PROTECTED] rpms]# LC_ALL=C rpm -Uvh /home/peroyvind/RPM/RPMS/x86_64/drakxtools-curses-10.29-1mdv2008.1.x86_64.rpm /home/peroyvind/RPM/RPMS/noarch/drakx-net-* error: Failed dependencies: drakxtools-backend = 10.29-1mdv2008.1 is needed by drakxtools-curses-10.29-1mdv2008.1.x86_64 libdrakx-net = 0.34 is needed by drakx-net-0.34-1mdv2008.1.noarch libdrakx-net = 0.34 is needed by drakx-net-text-0.34-1mdv2008.1.noarch drakxtools-curses = 10.22-1mdv2008.1 is needed by (installed) harddrake-10.22-1mdv2008.1.x86_64 drakxtools-curses = 10.22-1mdv2008.1 is needed by (installed) drakxtools-10.22-1mdv2008.1.x86_64 rpm: depends.c:1776: zapRelation: Assertion `tsi->tsi_reqx >= 0 && tsi->tsi_reqx < rpmdsCount(requires)' failed. Avbrutt (SIGABRT) > > >> Also try reproducing with --noparentdirs ... > > > > I have parent dir deps disabled by default. > > Which is not rpm-5.1.0 either. ? -- Regards, Per Øyvind Karlsen __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm 5.1 segfaults
På Tirsdag 15 april 2008 , 20:39:46 skrev Jeff Johnson: > On Apr 15, 2008, at 2:10 PM, Jeff Johnson wrote: > >> rpm: depends.c:1776: zapRelation: Assertion `tsi->tsi_reqx >= 0 && > >> tsi->tsi_reqx < rpmdsCount(requires)' failed. > >> Avbrutt (SIGABRT) > > > > Bingo. Thanks. Now to find where tsi->tsi_reqx goes awry ... > > Hmmm, there's only one place that tsi->tsi_reqx is set. > > And AFAICT, addRelation() is called only within an rpmds iteration, > where the value used should be valid. But the code paths are twistier > than I would like because the iteration index is accessed in the > addRelation() > subroutine. > > Can I get you to try reproducing with one more assertion? > > Here is the patch: > > @@ -1902,6 +1903,7 @@ static inline int addRelation(rpmts ts, > > tsi->tsi_tagn = rpmdsTagN(requires); > tsi->tsi_reqx = rpmdsIx(requires); > +assert(tsi->tsi_reqx >= 0 && tsi->tsi_reqx < rpmdsCount(requires)); > > tsi->tsi_next = rpmteTSI(q)->tsi_next; > rpmteTSI(q)->tsi_next = tsi; > > If the new assertion fires, then I'm not reading the rpmds iteration > code correctly. > > If the old assertion fires, then there's a wild pointer somewhere. > > Thanks. [EMAIL PROTECTED] SPECS]# LC_ALL=C rpm -Uvh /home/peroyvind/RPM/RPMS/x86_64/drakxtools-curses-10.29-1mdv2008.1.x86_64.rpm /home/peroyvind/RPM/RPMS/noarch/drakx-net-* error: Failed dependencies: drakxtools-backend = 10.29-1mdv2008.1 is needed by drakxtools-curses-10.29-1mdv2008.1.x86_64 libdrakx-net = 0.34 is needed by drakx-net-0.34-1mdv2008.1.noarch libdrakx-net = 0.34 is needed by drakx-net-text-0.34-1mdv2008.1.noarch drakxtools-curses = 10.22-1mdv2008.1 is needed by (installed) harddrake-10.22-1mdv2008.1.x86_64 drakxtools-curses = 10.22-1mdv2008.1 is needed by (installed) drakxtools-10.22-1mdv2008.1.x86_64 rpm: depends.c:1776: zapRelation: Assertion `tsi->tsi_reqx >= 0 && tsi->tsi_reqx < rpmdsCount(requires)' failed. Avbrutt (SIGABRT) -- Regards, Per Øyvind Karlsen __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpm 5.1 segfaults
På Onsdag 16 april 2008 , 00:48:58 skrev Jeff Johnson: > On Apr 15, 2008, at 6:43 PM, Jeff Johnson wrote: > > Index: > > depends.c= > > ==RCS file: /v/rpm/cvs/rpm/lib/depends.c,vretrieving revision > > 1.394diff -u -b -B -w -p -r1.394 depends.c--- depends.c 1 Apr > > 2008 09:08:49 - 1.394+++ depends.c 15 Apr 2008 22:39:41 > > -@@ -2369,7 +2369,9 @@ rescan:rpmlog(msglvl, > > "%-40s %s\n", (nevra ? nevra : "???"), > > (dp ? dp : "not found!?!")); +#if 0dp = _free(dp); > > +#endif} /* Walk (and erase) linear part of > > predecessor chain as well. */ > > Eeek, So much for Safari cut-n-paste ... > > +#if 0 > dp = _free(dp); > +#endif > > near lib/depends.c:2369. > > 73 de Jeff > __ > RPM Package Managerhttp://rpm5.org > Developer Communication Listrpm-devel@rpm5.org hm, I'm uncertain whether this was supposed to workaround it or not, but I still get the same behaviour.. -- Regards, Per Øyvind Karlsen __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Eliminating internal zlib.
On Tuesday 19 August 2008 00:15:53 Jeff Johnson wrote: > Alexey's flushing patches to rpmio/gzdio.c make the need for internal > zlib (with Rusty Russel's --rsyncable padding) superfluous. > > Should I rip out internal zlib on HEAD and rpm-5.1.4? I see no reason > not > to start this effort, and am fighting dueling -lz <-> -lrpmz if > building --without-neon > anyways. Ripping out internal zlib and backporting rpmio/gzdio.c is > likely > the best long term fix. > > 73 de Jeff > __ > RPM Package Managerhttp://rpm5.org > Developer Communication Listrpm-devel@rpm5.org Would be nice :)
header mess!!!
OUCH! I've just gotten around to update my local rpm to latest from HEAD after not keeping track for a couple of months, there was some minor glitches first to get it to build, but now to get applications building against it is a whole kind of different mess. :(:( A lot of the public headers in /usr/include/rpm #includes files that no longer is installed to system, a lot of stuff also depends on things that's now declared in source files in stead of headers etcetcetc.. A whole lot of headaches, not much that will build against it at all currently and I really dunno or dare to mess too much around with these things to get 'em working again.. Jeff, you're the one who's been doing the major redecorationing, what's the deal? Are you aware of it or not, can you fix please? :)
Re: [CVS] RPM: rpm-5_1: rpm/ CHANGES rpm/rpmio/ lzdio.c
2008/10/4 Ralf S. Engelschall <[EMAIL PROTECTED]<[EMAIL PROTECTED]> > > On Sat, Oct 04, 2008, Per Øyvind Karlsen wrote: > > > [...] > > +lzma_stream tmp = > > +#if LZMA_VERSION == 49990030 > > + LZMA_STREAM_INIT_VAR; > > +#else > > + LZMA_STREAM_INIT; > > +#endif > > What happens on the next versions? > Wouldn't be a LZMA_VERSION >= 49990030 better here? nope, 49990030 is old, and the specific code part will only work with this version, the other code is for the new and hopefully stabilized api from 49990060 and on. (There's been some various api breakages between these versions that I don't care to bother about at all..) One could of course argue that it could be turned around and >= 49990060 or something would be better, but it's not really that relevant, the conditional should die eventually, I only left compatibility with 49990030 there for now since this is the version that most people probably use currently. Still, support for this old version should really die soon..
Re: [CVS] RPM: rpm/ CHANGES VENDOR rpm/lib/ depends.c
2008/10/28 devzero2000 <[EMAIL PROTECTED]> > Could be better also to fullfill automatically /etc/rpm/sysinfo/Dirname e > Filelinkto, giving an hint to the user ? In this case there is the > possibilty to catch this packaging error and to improve the quality of the > system -- and the distro. Enabling it would sure help to spot these and improve package quality in the distro, but as the distro isn't really using this and not all that much attention are paid to these things, fixing every single issue I come across would lead to much work for me doing janitor work.. So that's why I leave it optional in stead of disabling it completely, I intend to deal with this in some way eventually/occationaly. :) -- Regards, Per Øyvind
Re: [CVS] RPM: rpm/ CHANGES VENDOR rpm/lib/ depends.c
2008/11/1 Jeff Johnson <[EMAIL PROTECTED]> > It mostly doesn't matter whether enum's and such are typedef'd or not. > > __BUT__ > > rpmlog is based on syslog(3) and there's really no reason not > to continue exactly that (yes ancient and still widely used) API > in rpm itself. > > From man 3 syslog, the 1st arg to syslog(3) is an int, with multiple > sub-fields > that are supposed to be OR'd together. > > And only one of those bit-fields corresponds to rpmlogLvlType. > > So technically URPMI, not rpmlog, in rpm is b0rken if it is using > only rpmlogLvlType, and the prototype change you made in > lib/depends.c is incorrect. (re-read the very 1st line please). > > Where the issue __DOES__ get to be enormously painful is > when C++ linkage from, say, apt-rpm is attempted. C++ does > not have the same promotion rules as C. > > And so what does (and will) happen, if adding private typedef's for every > steenkin' > integer in rpm is pursued, is that the typedef's will have to be > exposed in includes. ATM rpm is nowhere near the point where a stable > API/ABI can be maintained. Sure I'd like to do to have a stable API/ABI, > but every > rearrangement I make has a ripple effect, and noone is working > on the global API/ABI design issues but me. > > What happens instead is a "This used to work!" bug report, and some > change is hacked in, and that's how rpm arrived at this state of affairs > in the > first place, organically incremental creeping crud. > > 73 de Jeff I guess you're commenting on the previous commit, and not this one? :) I changed the type since I figured that it made the context and valid values more clear, while also nicer for debugging (ie. gdb displaying the enumated value ie. name such as RPMLOG_WARN rather than just the integer) and otherwise as you point out, it mostly doesn't matter :) For URPMI usage of rpmlog, I doubt it using the typedef'd type, this was a purely URPMI non-related commit. ;)
Re: [CVS] RPM: rpm/ CHANGES configure.ac
2008/11/1 Jeff Johnson <[EMAIL PROTECTED]> > What is wrong with >CPPFLAGS="-DRPM_VENDOR_MANDRIVA" > > Its insane to have Yet More Ways to configure "stuff" imho. > > 73 de Jeff It's hidden from "regular user" who'd like to build rpm himself for that specific vendor. Maybe not such an important thing for rpm devels, but I know that if I were to build rpm5 myself for ie. Mandriva without being involved in rpm development nor reading through source just for fun, I'd like to easily find and use the suitable option to pick what to be considered the most proper adaptions using './configure --help'. Moreover, personally, I just find it nicer and more intuitive than passing either CPPFLAGS, or adding it to config.h.. ;)
Re: [CVS] RPM: rpm/ CHANGES rpm/rpmio/ Makefile.am
2008/12/5 Jeff Johnson <[EMAIL PROTECTED]> > What needed "fixing"? > > I have built using internal lua daily without these changes. > > Can you try to pin down what changed so that this patch is now needed > please? > > Likely trying to build rpm-5.1.6, without these changes, would > be the easiest way to identify if there is a regression. > > 73 de Jeff I noticed something being odd about this myself, I've built internal lua with cvs checkout from a couple of weeks ago that didn't have this issue, now it showed up, both me and afb has experienced it, but even while I tried, I didn't manage to figure it out.. I'll try again later.. :)
Re: [CVS] RPM: rpm/ CHANGES rpm/perl/ Makefile.PL.in
2008/12/5 Jeff Johnson <[EMAIL PROTECTED]> > Thanks for cleaning up perl MakeMaker, its always been a bit tweaky, > and I haven't a clue wrto portably building perl. > > However @CPPFLAGS@ is almost certainly going to be needed > for portability, as that is how additional include paths > are added. > Yeah, I guess you're right, it usually shouldn't give any headaches either. I'll add it back. :) -- Regards, Per Øyvind
Cleaning out some local patches of mine..
While I've commited most of the mandriva patches upstream, I still got a few ones left that I've been uncertain about and hasn't bothered with looking at yet: http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-4.4.1-fileconflicts.patch?root=rpm5distro&view=log (https://bugzilla.redhat.com/show_bug.cgi?id=151609) http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-4.4.4-rpmqv-ghost.patch?root=rpm5distro&view=log (https://qa.mandriva.com/show_bug.cgi?id=19392) Reading bugzilla entries, both suggests that these issues has been fixed upstream already, is this the case? Is there no longer any sense to these patches? I'd like to get rid of these, then I'd be down to only three local patches left. :o) (Feel free to comment on the other ones while you're at it;) -- Regards, Per Øyvind
Re: [CVS] RPM: rpm/ CHANGES rpm/rpmio/ Makefile.am
2008/12/5 Jeff Johnson <[EMAIL PROTECTED]> > The flaw will be in -lrpmmisc, not in -lrpmio, is my guess. > > And its likely my portability brain fart somehow if reproducible. > > Doing > cd misc > cvs diff -D "2 months ago" > will show all my changes. > > There's not a whole lot different in misc/* afaict. > > I have seen some issues trying to sort out the SELinux textrel > issue by attempting "ld -pie ..." linkage. But I abandoned those > efforts, none of those changes are on HEAD. > > Note that its *very* easy to get tricked by -lrpmisc because > some of the make dependencies are not included. Adding > those dependencies through AutoFu would be fairly difficult, > what is there is OK for most usage cases even if a developer > can get occaisionally tricked. > You're of course right, as usual! ;) I tend to always forget about misc/librpmmisc.vers when I haven't touched it for a while, then stabbing wildy around in the dark taking the usual (but wrong) route to investigate it. Fixed now! :)
Re: Cleaning out some local patches of mine..
2008/12/5 Jeff Johnson <[EMAIL PROTECTED] > > If you want both a --ghost enabler as well as a --noghost disabler, go for > it. > > However, what works best for rpm (in my experience) is enabled > functionality > with a disabler. Opt-in behavior for new functionality takes many more > years to be used, might as well have not done the implementation at all. > > However, if both enabler/disabler options have to be added everywhere, its > gonna be a bit of a mess, and likely will require automation through > popt for bit field set/clr (which likely needs doing somewhen for other > reasons). > > But as long as the options are not displayed in --help or documented in > rpm.8 > noone will really care. > Ah, I see, I did of course not do any research on this myself before asking.. :p But I feel a bit confused, rpm checks ghost files by default (which is also what this patch activates with --ghost), while --noghost will disable checking? If so, I don't see much sense in the patch and will gladly drop it without giving it any second thoughts. :) > > Reading bugzilla entries, both suggests that these issues has been fixed > upstream already, is this the case? Is there no longer any sense to these > patches? > > > The disagreement over what the default value for file conflicts > has been going on since RHEL4. Nothing has changed. Some > want full stop failure exit, others are okay with "best effort" > continuing. And there is only one default behavior choice possible. > I see, I guess Mandriva has a different take on policies for these things in general, using different package names for situations with several versions of a package and splitting out library packages etc. for different archs to accomplish multilib rather than relying on coloring or large blobs.. Seems to be a clear "cultural" difference between distributions and policies, putting it under #ifdef vendor. :) -- Regards, Per Øyvind
Re: Cleaning out some local patches of mine..
2008/12/5 Per Øyvind Karlsen <[EMAIL PROTECTED]> > While I've commited most of the mandriva patches upstream, I still got a > few > ones left that I've been uncertain about and hasn't bothered with looking > at yet: > > > http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-4.4.1-fileconflicts.patch?root=rpm5distro&view=log > (https://bugzilla.redhat.com/show_bug.cgi?id=151609) > > > http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-4.4.4-rpmqv-ghost.patch?root=rpm5distro&view=log > (https://qa.mandriva.com/show_bug.cgi?id=19392) > > Reading bugzilla entries, both suggests that these issues has been fixed > upstream already, is this the case? Is there no longer any sense to these > patches? > > I'd like to get rid of these, then I'd be down to only three local patches > left. :o) > > (Feel free to comment on the other ones while you're at it;) > -- > Regards, > Per Øyvind Here I got one that I'm not sure if I understand: http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-build-expand-field-for-single-token.patch?root=rpm5distro&view=log The comment I find in spec about it is the following: # rpm now check there is only one token per field # too bad, the check is performed before macro expansion... Oh, and I also got this one: http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-4.4.8-raise-read-timeout-to-60secs.patch?root=rpm5distro&view=log Any suggestions on what would be the best approach? Just use #ifdef vendor? It seems to me that this might be useful also for others that are performing the same task with the possibility of very high load.. I dunno, but it's the last local patch left, would be nice to get rid of it to satisfy my neatfreak urges. ;) -- Regards, Per Øyvind
Re: Cleaning out some local patches of mine..
2008/12/5 Per Øyvind Karlsen <[EMAIL PROTECTED]> > Oh, and I also got this one: > > http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-4.4.8-raise-read-timeout-to-60secs.patch?root=rpm5distro&view=log > > Any suggestions on what would be the best approach? > Just use #ifdef vendor? It seems to me that this might be useful also for > others that are performing the same task with the possibility of very high > load.. I forgot, FYI: # important patch fixing parse_hdlist (and so genhdlist2) on heavy loaded boxes # (without this patch it timeouts after a read miss of 1 second (even a pipe), # and there is no way we can retry since we would need to backtrack the fd) -- Regards, Per Øyvind
new lzma (xz) and support
Hi folks! As some of you might've noticed I commited changes related to lzma last night. This adds support for using the new lzma format, named 'xz' as payload and lzdio.c has been renamed to xzdio.c which handles both the legacy LZMA_Alone format in same way as before (ie. w7.lzdio) and also the new xz format (ie. w7.xzdio). xz (which is the new name of lzma utils, library remains named 'liblzma') will enter beta stage within the next couple of weeks and the format should now (or at least then;) be considered stable with no changes taking place. This means that you then should be able to start using the format without worrying about not being able to decompress the files later, only bugs to worry about from now on! ;) To get xz support in place I had to ditch support for older liblzma 4.999.3 as a lot of API changes has taken place since and also the code for handling new xz format relies on some API changes that were commited to lzma git repo last night. Sooo.. * You need very latest code (you'll find it at http://tukaani.org/lzma/) * Name of the new lzma format is 'xz' * You can still use the legacy format as before without worrying * You can also use new xz format if you're adventurous, brave and on HEAD * XZ payload is NOT backwards compatible * This support will be backported to rpm-5_1 branch soon * Latest code for lzma will be imported for internal build ASAP Have phun! :D
new DISTEPOCH tag and cleaning of RELEASE tag polution
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.
The distepoch tag will behave kinda like the epoch tag in the way that it's
optional, but
it's significance in version comparision will be the least.
ie. this way 1:2.3.4-5:2009.1 will be treated as newer than
1:2.3.4-5:2009.0, so this is
consistent with the behaviour of ie. %{_dist} in Fedora, or %mkrel in
Mandriva.
As you see from this, the distribution tag will be kept out of the actual
versioning,
while the distribution release will be moved to a new tag separately from
%RELEASE.
As the distrib tag is quite nice to have and all, it will still be part of
the package file name.
Consider the following ~/.rpmmacros:
%disttag mdv
%distepoch 2009.0
This will create package with the following filename:
foo-2.3.4-5:mdv2009.0.x86_64.rpm
>From /usr/lib/rpm/macros:
%___NVRDA
%%{NAME}-%%{VERSION}-%%{RELEASE}%%|DISTTAG?{:%%{DISTTAG}%%|DISTEPOCH?{%%{DISTEPOCH}}|}|%%|ARCH?{.%%|SOURCERPM?{%%{ARCH}}:{src}|}:{}|
%_build_name_fmt%%{ARCH}/%{___NVRDA}.rpm
Notice that package filename will only be changed to this new style if
%disttag & %distepoch is used,
otherwise old package file name is kept.
You can also use 'DistTag:' & 'DistEpoch:' per package basis as with ie.
'Distribution:' etc.
This patch is quite non-intrusive and only of concern to anyone choosing to
use these tags,
otherwise you won't be affected by it. There's of course a lot of further
improvements that
can be made, but they're not that important initially.
So WDYT? I personally think this is a very nice solution curing the abuse of
%release for this
purpose while providing a standard way for these things as well.
I'll wait for some comments first in case of any objections before
commiting, meanwhile
you can find the patch here:
http://www.zarb.org/cgi-bin/viewvc.cgi/snapshot/rpm/current/SOURCES/rpm-5.2-distepoch.patch?root=rpm5distro&view=log
--
Regards,
Per Øyvind
Re: [CVS] RPM: rpm/lib/ fsm.c
2008/12/20 Ralf S. Engelschall
> RPM Package Manager, CVS Repository
> http://rpm5.org/cvs/
>
>
>
> Server: rpm5.org Name: Ralf S. Engelschall
> Root: /v/rpm/cvs Email: r...@rpm5.org
> Module: rpm Date: 20-Dec-2008 09:09:47
> Branch: HEAD Handle: 2008122008094700
>
> Modified files:
>rpm/lib fsm.c
>
> Log:
>get rid of one more compile-time warning under non-Linux systems
>
> Summary:
>RevisionChanges Path
>2.180 +1 -2 rpm/lib/fsm.c
>
>
>
> patch -p0 <<'@@ .'
> Index: rpm/lib/fsm.c
>
>
> $ cvs diff -u -r2.179 -r2.180 fsm.c
> --- rpm/lib/fsm.c 13 Dec 2008 20:37:56 - 2.179
> +++ rpm/lib/fsm.c 20 Dec 2008 08:09:47 - 2.180
> @@ -769,9 +769,8 @@
> {
> fsm->fcontext = NULL;
> if (!fsm->nofcontexts) {
> - struct stat * st = &fsm->sb;
>security_context_t scon = NULL;
> - int xx = matchpathcon(fsm->path, st->st_mode, &scon);
> + int xx = matchpathcon(fsm->path, fsm->sb.st_mode, &scon);
>
> /*...@-moduncon@*/
>if (!xx && scon != NULL)
> @@ .
> __
> RPM Package Managerhttp://rpm5.org
> CVS Sources Repositoryrpm-...@rpm5.org
>
fsm.c: In function 'fsmMapFContext':
fsm.c:772: warning: unused variable
'st'
This one?
I get it on linux as well, but I never figured out why it complained about
st being
unused since it seemingly did get used two lines below, but my ignorance
prolly' can't really debate much with technical details..
Could you clarify on why? :)
Re: [CVS] RPM: rpm/lib/ fsm.c
2008/12/20 Ralf S. Engelschall > > On Sat, Dec 20, 2008, Per Øyvind Karlsen wrote: > > > [...] > > fsm.c: In function 'fsmMapFContext': > > fsm.c:772: warning: unused variable > > 'st' > > > > This one? > > Yes, exactly! > > > I get it on linux as well, but I never figured out why it complained > > about st being unused since it seemingly did get used two lines below, > > but my ignorance prolly' can't really debate much with technical > > details.. > > > > Could you clarify on why? :) > > The point is that the variable is used on the matchpathcon() "function > call" only. But matchpathcon() is a _macro_ which is defined only for > Linux's SELINUX situation. On non-Linux (or as in your case, Linux > but not SELINUX-enabled platform) the matchpathcon() macro expands to > nothing which in turn leads to the "unused variable" situation. Ah, no SELINUX here, so I guess that explains things then. :)
Re: [CVS] RPM: rpm/ configure.ac
2008/12/20 Anders F. Björklund > RPM Package Manager, CVS Repository > http://rpm5.org/cvs/ > > > > Server: rpm5.org Name: Anders F. Björklund > Root: /v/rpm/cvs Email: a...@rpm5.org > Module: rpm Date: 20-Dec-2008 11:01:52 > Branch: HEAD Handle: 2008122010015100 > > Modified files: >rpm configure.ac > > Log: >unbreak build, by changing from error to warning > > Summary: >RevisionChanges Path >2.331 +1 -1 rpm/configure.ac > > > > patch -p0 <<'@@ .' > Index: rpm/configure.ac > > > $ cvs diff -u -r2.330 -r2.331 configure.ac > --- rpm/configure.ac 20 Dec 2008 02:27:12 - 2.330 > +++ rpm/configure.ac 20 Dec 2008 10:01:51 - 2.331 > @@ -155,7 +155,7 @@ > if test ".$enableval" = .yes; then > if test ".`$CC --version 2>&1 | grep 'GCC'`" != .; then > dnl # GNU GCC (usually "gcc") > -CFLAGS="$CFLAGS -Wall -W -Wpointer-arith -Wstrict-prototypes > -Wmissing-prototypes -Wno-char-subscripts -Wno-missing-field-initializers > -Wno-unused-parameter -Werror=format-security" > +CFLAGS="$CFLAGS -Wall -W -Wpointer-arith -Wstrict-prototypes > -Wmissing-prototypes -Wno-char-subscripts -Wno-missing-field-initializers > -Wno-unused-parameter -Wformat-security" > elif test ".`$CC -V 2>&1 | grep 'Sun C'`" != .; then > dnl # Sun Studio (usually "cc") > CFLAGS="$CFLAGS -v" > @@ . > __ > RPM Package Managerhttp://rpm5.org > CVS Sources Repositoryrpm-...@rpm5.org > Fix errors in stead!!
Re: [CVS] RPM: rpm/ configure.ac
2008/12/20 Anders F Björklund > Per Øyvind Karlsen wrote: > > Modified files: >> rpm configure.ac >> >> Log: >> unbreak build, by changing from error to warning >> >> > Fix errors in stead!! >> > > The coding errors are fixable either way (warning/error), > but this gets rid of the build failures with GCC < 4.3 : > > cc1: error: unrecognized command line option "-Werror=format-security" > > It's possible that configure could need another option > like --enable-build-error to add -Werror to the CFLAGS ? I'd rather not, too many warnings about stuff not too important too fix when building with --enable-build-warnings. Passing -Werror is anyways quite a trivial thing to do too.. :)
Re: new DISTEPOCH tag and cleaning of RELEASE tag polution
2008/12/20 Jeff Johnson
> Quoting
>
> "Br'er Fox, please don't throw me in the briar patch!", sez Br'er Rabbit.
> [1]
> Adding another structural field to package identifiers everywhere
> just adds complexity for no important gain imho.
>
> The lossages with DISTTAG (and REPOTAG and no DISTEPOCH} are perhaps easier
> (for me) to point out then the gains for an idea that I don't believe in.
>
> Here's a couple of points, you can certainly do whatever you wish:
>
> 1) ATM, rpm <-> dpkg tags can potentially be unified; both dpkg
> and rpm use a {E,V,R} triple for both package names and
> dependencies. Adding other elements structurally to the triple (as
> your patch does) will just make it harder to attempt unification.
> (not that anyone cares much anymore about rpm <-> dpkg unification).
>
> 2) Is there really any usefulness in suffixing, say, "mdv.2009.1" to every
> package (and to many, perhaps the majority, of package dependencies)
> contained in a distro release? The utility gain that is usually reported
> when I ask
> Why do you want to add foo/bar/baz to Release:?
> is usually something along the lines of
> So that I can more easily identify which packages are foo/bar/baz.
> which is an acceptable answer for adding foo/bar/baz identifiers.
>
> However, it is not really a good answer if foo/bar/baz are displayed
> everywhere. The fault in the reasoning neglects the case that not
> every identification needs foo/bar/baz precisely displayed just because
> foo/bar/baz exists.
>
I think it actually is useful, it identifies distribution and distribution
version
just by looking at the filename. Of course one could say that the user
could get this info by querying the rpm, but most people don't do that,
and it's also convenient when searching for files locally or online.
>
> 3) Why not a URI rather than continuing to append suffixes with
> hints on parsing boundaries like, say, the "." is a parsing hint
> in %{RELEASE}.%{DISTTAG}
> A URI has a distinct advantage that '/' or "::" boundary hints are regular
> and predictable. The hierarchy of top-to-bottom as in /bing/bang/boom
> or left-to-right as in bing::bang::boom also assists in building labels
> in context simply and predictably (like baseurl). The mdv2009.1 (and
> the %{?dist} conventions) are much more complicated syntactically.
>
Well, I was first thinking about using '-' in stead of ':', but I chose ':'
out
of convenience for the versioning since it's easier to separate the field
starting from right when there's only one '-' and one ':', and it was also
a more consistent with epoch tag something I thought would help
make it clear that the tag is optional. I chose to use
'%{RELEASE}:%{DISTTAG}' in package filename to be consistent with
this again, I could just as well use '%{RELEASE}-%{DISTTAG}' and
I'm not against that, but I'm against using '%{RELEASE}.%{DISTTAG}'
since then it's not clear by looking at the filename what's part of the
release tag or not.
>
> 4) Longer strings with more complicated structure are increasingly
> useless to package manager implementations. A short list of
> currently known implementations that are trying to remove, not
> add, string redundancy includes:
> EDOS/Mancoosi - replacing strings with an index to hide versioning
> zypp - uses a string store to reduce size .solv files
> rpm.org - added a string store to reduce memory footprint
> and there are several other implementations I'm aware of where the
> increasing length of strings in metadata is visibly becoming a performance
> penalty.
>
> hth
>
> 73 de Jeff
>
> [1] http://en.wikipedia.org/wiki/Tar_baby
>
> On Dec 19, 2008, at 9:57 PM, 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.
> The distepoch tag will behave kinda like the epoch tag in the way that it's
> optional, but
> it's significance in version comparision will be the least.
>
> ie. this way 1:2.3.4-5:2009.1 will be treated as newer than
> 1:2.3.4-5:2009.0, so this is
> consistent with the behaviour of ie. %{_dist} in Fedora, or %mkrel in
> Mandriva.
>
> As you see from this, the distribution tag will be kept out of the actual
> versioning,
> while the distribution release will be moved to a new tag separ
Re: new DISTEPOCH tag and cleaning of RELEASE tag polution
2008/12/21 Arkadiusz Miskiewicz
> 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.
So does this mean that for PLD such a DISTEPOCH tag would be the most
significant value rather than least significant?
Would 1:2.3.4-7 then be a different release other than which distro release
it's
built for?
In Mandriva the packages with the same release are always built from the
same
package between releases, updates etc. of a package in a stable distribution
is rather given a release like 1:2.3.4-5.1 rather than 1:2.3.4-6..
Re: new DISTEPOCH tag and cleaning of RELEASE tag polution
2008/12/22 Per Øyvind Karlsen
> 2008/12/21 Arkadiusz Miskiewicz
>
>> 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.
>
> So does this mean that for PLD such a DISTEPOCH tag would be the most
> significant value rather than least significant?
>
> Would 1:2.3.4-7 then be a different release other than which distro release
> it's
> built for?
> In Mandriva the packages with the same release are always built from the
> same
> package between releases, updates etc. of a package in a stable
> distribution
> is rather given a release like 1:2.3.4-5.1 rather than 1:2.3.4-6..
>
btw. here's some info on release tags in Mandriva Linux:
http://wiki.mandriva.com/en/Policies/Release_Tag
Re: new DISTEPOCH tag and cleaning of RELEASE tag polution
2008/12/22 Anders F Björklund
> 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.
>> The distepoch tag will behave kinda like the epoch tag in the way that
>> it's optional, but
>> it's significance in version comparision will be the least.
>>
>
> So this "DISTEPOCH" would also work for "OSVERSION" on other systems ?
>
> Like "darwin8" or "10.5osx" or "freebsd-7.0" or whatever it might be ?
Yes, that's kinda the idea, except for DISTEPOCH would only contain the
version,
where the DISTTAG would contain the short os/distribution name identifier..
I'm not sure if DISTEPOCH is the best name for the tag though, but that's
something that always can be discussed. :o)
Re: new DISTEPOCH tag and cleaning of RELEASE tag polution
2008/12/22 Jason Corley
> On Fri, Dec 19, 2008 at 9:57 PM, Per Øyvind Karlsen
> wrote:
> > So WDYT?
>
> This seems like yet another magic bit in RPM comparisons with which to
> confuse newbies and old hats alike... Think of how many times you've
> explained epoch to someone on IRC, now add yet another factor to
> comparison operators. I'm sort of on the fence with the whole idea (I
> see you've already merged it) but it doesn't strike me as much
> different than just abusing the existing operators already in place (I
> could abuse epoch as distro identifier, tack more crap onto release,
> etc. etc.) but perhaps that's just me.
>
It's still completely optional and won't confuse anyone now using it..
The case is still that several linux distributions (ie. Fedora & Mandriva)
already (ab)use release tag for this, and it's also done in different
ways giving more confusion and less portability.
The need for an ability to treat a package built on different versions of a
distribution also as different package versions is certainly there, finding
a common and standard is in everyone's interest.. Worth pointing out
is that Panu also was positive towards this idea, so reaching consensus
between rpm5.org & rpm.org and standardize this seems possible. :)
I'm not sure if I explained distepoch good enough, but I guess I should
make it clear again that distepoch would be the least significant value
when doing comparision, not most significant such as epoch is.
This is why I'm a bit certain about whether using "distepoch" as a name
is the best or not..
IMO adding this new tag bring a lot less confusion and is way more
intuitive than Fedora's %{?dist} or Mandriva's %mkrel, and it's also
something that you won't have to pollute the spec file with (reducing
confusion and mess further)..
Re: new DISTEPOCH tag and cleaning of RELEASE tag polution
2008/12/22 Anders F Björklund > Per Øyvind Karlsen wrote: > > So this "DISTEPOCH" would also work for "OSVERSION" on other systems ? >> >> Like "darwin8" or "10.5osx" or "freebsd-7.0" or whatever it might be ? >> Yes, that's kinda the idea, except for DISTEPOCH would only contain the >> version, >> where the DISTTAG would contain the short os/distribution name >> identifier.. >> > > Okay, so DISTTAG would be the OS name and DISTEPOCH would be the OS major. > > Quickly gets boring for "linux2" vs. "linux2" vs. "linux2", I suppose :-) Hm, in general for distributions it would be more of a abbreviation of distribution name, ie. such as 'mdv' for Mandriva, 'fc' for Fedora etc. I'm not sure really how to think through this if one thinks of packages in terms of operating systems rather than distributions, but this isn't really what I've tried to address here either, but I guess it can be used for the same purpose by those who have interest in this. :) > > > I'm not sure if DISTEPOCH is the best name for the tag though, but that's >> something that always can be discussed. :o) >> > > And DISTRIBUTION is the same old useless tag as always ? (e.g. "Unknown") Well, for Mandriva 'Distribution:' would still be 'Mandriva Linux' while 'DistTag': would be 'mdv'. > > > What is the DISTURL then ? Home page of "distro", or some ID-like thing ? No idea, ask Jeff. ;) I chose existing DISTTAG and implemented DISTEPOCH since this was something Jeff suggested looong time ago when we discussed it last time like a year ago.
Re: Perl: Query with RPM-Perl in 5.x for a package?
2008/10/20 Robert Scheck
> On Wed, 13 Aug 2008, Robert Scheck wrote:
> > On Tue, 12 Aug 2008, Michael Jennings wrote:
> > > # perl -MRPM::PackageIterator -e '$iter =
> RPM::PackageIterator->new("NAME", "rpm"); while ($pkg = $iter->next())
> {print $pkg->as_nvre(), "\n";}'
> > > rpm-5.1.4-4.caos
> >
> > Sure?
> >
> > rob...@tux:~ > perl -MRPM::PackageIterator -e '$iter =
> RPM::PackageIterator->new("NAME", "rpm"); while ($pkg = $iter->next())
> {print $pkg->as_nvre(), "\n";}'
> > Speicherzugriffsfehler
> > rob...@tux:~ >
> >
> > "Speicherzugriffsfehler" is German and means "Segmentation fault". Am I
> > too dumb now or is this really a bug? I'm using RPM 5.2.x (HEAD) with a
> > checkout of 2008-06-30.
>
> I'm still seeing this on HEAD with perl 5.10.0 and Fedora. What's needed to
> debug and finally solve this?
I guess rpmtsFree() shouldn't be done before the object is destroyed, I've
added
a destructor function to free the iterator itself, but I don't have good
enough
knowledge of perl xs stuff to figure out the best way to do rpmtsFree()
there as well..
It should at least probably work for you now, although some memory will be
leaked..
(I really hate XS..)
Re: new DISTEPOCH tag and cleaning of RELEASE tag polution
2008/12/22 Anders F Björklund > Per Øyvind Karlsen wrote: > > So this "DISTEPOCH" would also work for "OSVERSION" on other systems ? >>> >>> Like "darwin8" or "10.5osx" or "freebsd-7.0" or whatever it might be ? >>> >> Yes, that's kinda the idea, except for DISTEPOCH would only contain the >> version, >> where the DISTTAG would contain the short os/distribution name >> identifier.. >> > > Okay, so DISTTAG="darwin" and DISTEPOCH="8"... That would probably work. > > Okay, so DISTTAG would be the OS name and DISTEPOCH would be the OS major. >>> >>> Quickly gets boring for "linux2" vs. "linux2" vs. "linux2", I suppose :-) >>> >> Hm, in general for distributions it would be more of a abbreviation of >> distribution name, ie. such as 'mdv' for Mandriva, 'fc' for Fedora etc. >> > > Yeah, since the OS itself failed to produce any reasonable versioning. :-P > > I'm not sure really how to think through this if one thinks of packages in >> terms >> of operating systems rather than distributions, but this isn't really what >> I've >> tried to address here either, but I guess it can be used for the same >> purpose >> by those who have interest in this. :) >> > > It serves a similar purpose, at least. It's the same package "megafreeze". > > And DISTRIBUTION is the same old useless tag as always ? (e.g. "Unknown") >>> >> Well, for Mandriva 'Distribution:' would still be 'Mandriva Linux' while >> 'DistTag': >> would be 'mdv'. >> > > And elsewhere, they have Distribution = Unknown and Vendor = Fedora Project Oh, really? I thought they had more similar to us, ie. we have 'Vendor: Mandriva' & 'Distribution: Mandriva Linux'.
Re: [CVS] RPM: rpm/ CHANGES rpm/build/ files.c pack.c parsePreamble.c rpm/...
2008/12/23 Ralf S. Engelschall > > On Tue, Dec 23, 2008, Jeff Johnson wrote: > > > Put the under a "RPM_VENDOR_FOO" (or any other AutoFu enabler, > > default behavior is "disabled"). > > > > I do not see __ANY__ consensus @rpm5.org that the patch is desired, > > in fact quite the opposite, you have 2 negative comments on your > > proposal. > > > > I'm strongly opposed to the patch because I have __ALREADY__ seen > > Epoch: and then Arch: and Disttag: and Repotag: being added to packaging > > for "identification" purposes (I did the implementations) and no problem > > was > > usefully solved. > > > > Noone (until now, yes you are using Disttag:, but you are still only a > > single person) finds the functionality useful. The homily > > Build and they shall use. > > does not apply in this case there is no consensus on the intended > > "identification". > > I also think the change is too intrusive and hence should be placed > under RPM_VENDOR_XXX until more experience exists with it and consensus > exists that it should be a default functionality. So, please place it > under RPM_VENDOR_XXX... My thought behind commiting this change was that I considered it quite non-intrusive and only affecting those using it while encouraging use, discussion and improvement rather than the several different usages of RELEASE for same purpose. It also made it for me easier to maintain of course since it modifies several files, so would you be okay with the tag itself staying and only the comparision being under #ifdef RPM_VENDOR_XXX? I would think these parts being the most intrusive ones, adding #ifdef's all over for a single line here and there would be a bit messy and I think reserving the tag for possible future usage while also being compatible with packages using DistEpoch: in their spec would be convenient even if not really put to any use currently.
Re: [CVS] RPM: rpm/lib/ filetriggers.c
2008/12/23 Jeff Johnson > > On Dec 23, 2008, at 4:57 PM, Jeff Johnson wrote: > > This patch isn't needed. >> >> system.h will include "config.h" if -DHAVE_CONFIG_H is defined >> in CFLAGS, which is done throughout rpm. >> >> And RPM_VENDOR_FOO is passed through CFLAGS, not config.h, >> simpilarly to -DHAVE_CONFIG_H. >> >> > If you __DO__ insist on RPM_VENDOR_MANDRIVA > in config.h rather than CFLAGS et al, then the right fix is > >#include "system.h" > >#if defined(RPM_VENDOR_MANDRIVA) > Yes, but then some stuff would be compiled into filetriggers.o. > > > consistent with every other file compiled in rpm. > > Slightly worse (but acceptable) is > >#if defined(HAVE_CONFIG_H >#include "config.h" >#endif > >#if defined(RPM_VENDOR_MANDRIVA) > I'll go with this then. :)
Re: [CVS] RPM: rpm/perl/ Makefile.PL.in
2008/12/23 Jeff Johnson > This change "works" iff *.la files are present to hint > additional libraries. E.g. -lrpmio needs -lrpmmisc > whether it as expressed explicitly (as before) or implictly ( > what is likely happening after your patch is applied). > > As long as rpm AutoFu has building without *.la as an > option, then all libraries need to be listed in multiple > places Just In Case. Ah, I see, I didn't think that far, just trying my best cleaning up this MakeMaker headache. Reverted the previous commit now.
Re: Generalizing EVR comparison precedence, preliminaries
2009/1/2 Jeff Johnson > > On Jan 2, 2009, at 3:00 PM, Jeff Johnson wrote: > >> >>Requires: D:R-V:E >> > >Requires: N = D:R-V:E > > And I pointed out the syntax <-> precedence permutations > mostly to illustrate that even if nothing else is done, > what is currently checked in on HEAD is immensely more general > than what used to be there. > > E.g. you already know that OpenPKG can drop D and V comparison > quite easily with the existing implementation, no fuss, no muss. > > And Per Oyvind is just starting to figure out that Distepoch: > can be 1st (and most important) to be compared. How Disttag: > fits into the mess has yet to be specified into syntax. > > 73 de Jeff Hehe, FWIW DistTag doesn't have any relevance for EVRD (or whatever combination one wants to have) comparision in my world, it's just meant to be ditched from Release piggybacking to avoid it being taking into consideration for comparision, while adding it to file name as an identifier. :)
Re: [CVS] RPM: rpm/ CHANGES rpm/rpmdb/ rpmevr.c
2009/1/3 Jeff Johnson > With this patch, the basics to introduce a precedence > permutation into EVRD comparison should now be in place on HEAD. > > (aside) > Yes, I'm still in denial about PCRE <-> ERE issues, and > most certainly a gather operation to collect parsed > sub-patterns is absolutely needed for "full generality". > > There's also some chrome buffing with error returns, as > well as nuking the old <-> new assert construction scaffholding. > > But there's Yet Another parser called parseRCPOT() in > build/parseReqs.c that needs to be converted to regexes > like %evr_tuple_match first. > > This opens another class of issues related to build != install machines. > > Its easy to imagine that rpmbuild needs a different parsing > pattern for EVRD than is used for EVRD comparisons during install, > that's generally true because build != install hosts. > > And, its not too hard to see that different syntax/precedence permutations > on the EVRD tuple might be used to, say, satisify the mythical LSB > "standard" that all > dependencies in "LSB format" packages need to be written as >Requires: N = D:R-V:E > (i.e. always reversed in package tag content), or to satisfy the cAos > distro "feature" > that deletes Epoch: wherever it is found, or the OpenPKG RFE to delete > V and D wherever it is used, and likely everyone but Per Oyvind's desire > to not use D at all because the mysterious Epoch: is already too much pain. > > What I'm suggesting is rewriting (by permuting or deleting tuple elements) > the > parsed EVRD tuple before adding to a header while building packages. > > So there's likely going to be a need to duplicate the existing pattern > and permutation macros for building afaict. > > But I'll use the existing macros while attempting to rewrite the > parseRCPOT() parser. > > Note also: If (or when) this implementation is settled in on HEAD, I'm > *very* > likely to aggressively push the changes all the way back to the -r rpm-4_5 > branch. > This is exactly the type of profound change, like the added > erase-before-install > relation, that I want everywhere, so that I don't get hung up with multiple > branch development. > > If a profound change is broken or screwy somehow, well, its __EVERYWHERE__ > broken or screwy. > That's the rule I try to live by. > > Meanwhile, I ain't hurrying a bit, I'll get there when I get there, not > before ... > > Enjoy! Awesome! I look forward to the next little feature I implement which you'll go on and turn into something much more and state of the art, absolutely encouraging in contributing more! :D Now the pcre beast needs to be dealt with next. :D -- Regards, Per Øyvind
Re: Limiting package Name: field to explicit character set
2009/1/5 Wichmann, Mats D > rpm-devel-ow...@rpm5.org wrote: > > This off-hand comment regarding Mandriva DUDF -> CUDF > > translation needed by the Mancoosi project reminds me > > of a design mis-feature in RPM: > > > >> - package names: they should match the naming convention we > >> discussed, i.e., only lowercase characters, numbers, dashes or > >> pluses [1] or dots (see section 3.2.2 of D5.1, and in particular the > >> definition of type "pkgname") > > > > With the possible addition of '_', that is an unsuprising set > > of characters to limit package Name: fields to explicitly (i.e. > > cause rpmbuild to fail with characters not in the permitted set). > > > > Its really silly that consensus on an obvious "standard" needs > > to be attempted for RPM in 2009 imho. But better late than never ... > > > > Are there any objections if I limit the characters permitted in Name:? > > > > 73 de Jeff > > Well, there sure are a lot of current packages out there > with uppercase characters in the name This limitation sounds good to me, I think many distributions out there has policies on lower case names only, ie. we have in Mandriva (even though it's not always followed by some:/). I still have a concern about compatibility issues though..
Re: [CVS] RPM: rpm/ CHANGES rpm/build/ files.c
2009/1/22 Michael Jennings
> On Thursday, 22 January 2009, at 06:32:24 (+0100),
> Per ?yvind Karlsen wrote:
>
> > $ cvs diff -u -r1.351 -r1.352 files.c
> > --- rpm/build/files.c 17 Jan 2009 00:33:29 - 1.351
> > +++ rpm/build/files.c 22 Jan 2009 05:32:24 - 1.352
> > @@ -1034,7 +1034,6 @@
> > pkg->specialDoc = rpmiobAppend(pkg->specialDoc,
> "DOCDIR=\"$RPM_BUILD_ROOT\"", 0);
> > pkg->specialDoc = rpmiobAppend(pkg->specialDoc, buf, 1);
> > pkg->specialDoc = rpmiobAppend(pkg->specialDoc, "export
> DOCDIR", 1);
> > - pkg->specialDoc = rpmiobAppend(pkg->specialDoc, "rm -rf
> \"$DOCDIR\"", 1);
> > mkdir_p = rpmExpand("%{?__mkdir_p}%{!?__mkdir_p:mkdir -p}",
> NULL);
> > if (!mkdir_p)
> > mkdir_p = xstrdup("mkdir -p");
> > @@ .
>
> This seems wrong. Since normal %doc and the "special" %doc cannot be
> mixed, it is perfectly reasonable for the special form to remove the
> docdir.
>
> Michael
Why do you mean that they cannot be mixed?
If the software installs it's documentation to ie . %{_docdir}/%{name} which
is
where %doc stores it's docs as well, I don't see why these cannot be
packaged
in their place?
Having to do things this like 'mv %{buildroot}%{_docdir}/%{name} docs', then
'%doc docs/*' to get the docs in the same place is just silly, but something
one has to do today to work around this. I can't see any proper reasoning
for it,
if some distributions has a policy on this, I don't think it makes sense to
force
it upon others and not allow for the packager to just do ie.
'%doc %{_docdir}/%{name}/* %doc foo' (which will result in unexpected build
errors which don't really makes sense to the packager, if one really want
an error on this, a proper error should be implemented in stead of cpio
failing at archiving files which suddenly disappears) while
'%doc %{_docdir}/%{name}/*' will work etc..
I think some of the reasoning and idea of people in the past has been that
%doc will store packaging specific files in ie.
%{_docdir}/%{name}-%{version},
while the software might install it's own stuff at a separate location ie.
%{_docdir}/%{name}. If this is something one would want, that's all fine,
but this is not what everyone would want, ie. in Mandriva we've changed
%{_docdir_fmt} to %{NAME} in stead of %{NAME}-%{VERSION} and
prefer to keep everything at one place, but this results in having to do
ugly workarounds with moving files around, deleting unwanted files etc.
But different people, different needs and desires, maybe one could keep
%doc do 'rm -rf $DOCDIR' by default, but if doing '%doc %{_docdir}/%{name}'
(or whatever the arbitrary path might be) it'll disable it?
Would seem like a fairly decent comprise that wouldn't break existing
behaviour
for anyone, while still being intuitive and something to be done explicitly
by
the packager..
WDYT?
--
Regards,
Per Øyvind
automatic ~/rpmbuild by default rather than /usr/src/rpm etc..
I did the other day a fresh mandriva cooker install and noticed with rpm 4.6.0 a welcomed change, the automatic creation and use of a local ~/rpmbuild for user rather than /usr/src/rpm. Since this makes it easier to just get a working rpm build environment for user and also removes the implicit encouragement of packaging using /usr/src/rpm as root, would anyone have anything against introducing same behaviour as rpm.org in rpm5.orgHEAD? -- Regards, Per Øyvind
Re: automatic ~/rpmbuild by default rather than /usr/src/rpm etc..
2009/3/3 Anders F Björklund
> Per Øyvind Karlsen wrote:
>
> I did the other day a fresh mandriva cooker install and noticed with rpm
>> 4.6.0 a welcomed
>> change, the automatic creation and use of a local ~/rpmbuild for user
>> rather than /usr/src/rpm.
>>
>> Since this makes it easier to just get a working rpm build environment for
>> user and also
>> removes the implicit encouragement of packaging using /usr/src/rpm as
>> root, would anyone
>> have anything against introducing same behaviour as rpm.org in rpm5.orgHEAD?
>>
>
> You can set that with the --with-path-sources configure option, if
> scared of ~/.rpmmacros. I believe rpm.org uses "%{getenv:HOME}/rpmbuild"
Yes, but what I also would like is the automatic creation of these
directories as well.
>
>
> There's also the --with-path-buildroot option, if you also want to
> change "%{_tmppath}" for "%{_topdir}/BUILDROOT" like rpm.org does now.
>
>
> Not sure that the default configuration matters all that much, as
> just with the rpm.spec it's bound to be changed by vendors anyway ?
Yes, to some degree, but if you provide a default for local users, the
default
will more likely be adopted and I can't see any reason why anyone would feel
very strongly about changing such a default.
Having this as a default which user can expect to find ~regardless of vendor
seems like a
convenient way to make life easier for users and for anyone helping out
users..
--
Regards,
Per Øyvind
Re: automatic ~/rpmbuild by default rather than /usr/src/rpm etc..
2009/3/3 Jeff Johnson
>
> On Mar 3, 2009, at 6:36 AM, Per Øyvind Karlsen wrote:
>
> 2009/3/3 Anders F Björklund
>
>> Per Øyvind Karlsen wrote:
>>
>> I did the other day a fresh mandriva cooker install and noticed with rpm
>>> 4.6.0 a welcomed
>>> change, the automatic creation and use of a local ~/rpmbuild for user
>>> rather than /usr/src/rpm.
>>>
>>> Since this makes it easier to just get a working rpm build environment
>>> for user and also
>>> removes the implicit encouragement of packaging using /usr/src/rpm as
>>> root, would anyone
>>> have anything against introducing same behaviour as rpm.org in rpm5.orgHEAD?
>>>
>>
>> You can set that with the --with-path-sources configure option, if
>> scared of ~/.rpmmacros. I believe rpm.org uses "%{getenv:HOME}/rpmbuild"
>
> Yes, but what I also would like is the automatic creation of these
> directories as well.
>
>
> Everything except the automatic/lazy creation of %{_topdir} has existed in
> RPM for years IIRC. I certainly use some variant of the lazy creation daily
> while building packages in
> /X/%{NAME}
>
>
>
>>
>> There's also the --with-path-buildroot option, if you also want to
>> change "%{_tmppath}" for "%{_topdir}/BUILDROOT" like rpm.org does now.
>>
>>
>> Not sure that the default configuration matters all that much, as
>> just with the rpm.spec it's bound to be changed by vendors anyway ?
>
> Yes, to some degree, but if you provide a default for local users, the
> default
> will more likely be adopted and I can't see any reason why anyone would
> feel
> very strongly about changing such a default.
> Having this as a default which user can expect to find ~regardless of
> vendor seems like a
> convenient way to make life easier for users and for anyone helping out
> users..
>
>
> There's serious flaws in the logic above. Sure, lusers are sheep likely
> to do whatever is suggested as "default". But that doesn't mean one
> should just go around herding the sheep into other pastures for no
> useful purpose.
>
> If you like the @rpm.org model, by all means, use it. But recommending
> that as "default" to everone is just pointless imho.
>
> On Mar 3, 2009, at 6:36 AM, Per Øyvind Karlsen wrote:
>
> 2009/3/3 Anders F Björklund
>
>> Per Øyvind Karlsen wrote:
>>
>> I did the other day a fresh mandriva cooker install and noticed with rpm
>>> 4.6.0 a welcomed
>>> change, the automatic creation and use of a local ~/rpmbuild for user
>>> rather than /usr/src/rpm.
>>>
>>> Since this makes it easier to just get a working rpm build environment
>>> for user and also
>>> removes the implicit encouragement of packaging using /usr/src/rpm as
>>> root, would anyone
>>> have anything against introducing same behaviour as rpm.org in rpm5.orgHEAD?
>>>
>>
>> You can set that with the --with-path-sources configure option, if
>> scared of ~/.rpmmacros. I believe rpm.org uses "%{getenv:HOME}/rpmbuild"
>
> Yes, but what I also would like is the automatic creation of these
> directories as well.
>
>
> Everything except the automatic/lazy creation of %{_topdir} has existed in
> RPM for years IIRC. I certainly use some variant of the lazy creation daily
> while building packages in
> /X/%{NAME}
>
>
>
>>
>> There's also the --with-path-buildroot option, if you also want to
>> change "%{_tmppath}" for "%{_topdir}/BUILDROOT" like rpm.org does now.
>>
>>
>> Not sure that the default configuration matters all that much, as
>> just with the rpm.spec it's bound to be changed by vendors anyway ?
>
> Yes, to some degree, but if you provide a default for local users, the
> default
> will more likely be adopted and I can't see any reason why anyone would
> feel
> very strongly about changing such a default.
> Having this as a default which user can expect to find ~regardless of
> vendor seems like a
> convenient way to make life easier for users and for anyone helping out
> users..
>
>
> There's serious flaws in the logic above. Sure, lusers are sheep likely
> to do whatever is suggested as "default". But that doesn't mean one
> should just go around herding the sheep into other pastures for no
> useful purpose.
>
> If you like the @rpm.org model, by all means, use it. But recommending
> that as "default" to everone is just pointless imho.
>
Well, it's anyways a better default than what is currently, which makes it
favorable IMO.
--
Regards,
Per Øyvind
Re: [CVS] RPM: rpm/ CHANGES configure.ac rpm/perl/ Makefile.PL.in
2009/3/12 Ralf S. Engelschall > > On Wed, Mar 11, 2009, Per Øyvind Karlsen wrote: > > > perl: make sure to link against all required libraries to fix > > build with --no-undefined. (probably room for improval..) > > Yes, and it has to be improved because linking -lpthread breaks on > platforms where Pthreads are part of libc and no extra libpthread > is existing! So, this really fixes your particular situation and > unfortunately breaks others... > > The correct solution is to improve the --with-pthread > handling itself and then use just its results. Ah, I suck at with autoconf, I already spent some time on figuring out how to best deal with this, especially since I noted that it also might link against a libthread library if present.. I ended up figuring that it at least would always link against pthread and that wouldn't break any stuff by always linking perl module against, but I see now that the check for pthread library doesn't make it mandatory.. I'll try do better. :) -- Regards, Per Øyvind
Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ psm.c
2009/3/15 Jeff Johnson > > On Mar 14, 2009, at 7:54 PM, Jeff Johnson wrote: > > Can you make this truly lazy please? >> >> What you've done is tie "mkdir -p" for a set >> of directories to a single point. >> >> What needs to be done instead is to create the directories as >> needed during install. >> >> The hack will be in lib/rpmfi.c, not in lib/psm.c, where >> directories for SRPM's are expanded and added to a rpmfi >> for a SRPM. >> >> > Actually no hack is needed in lib/rpmfi.c. Installing > wiythe fsm/iosm will always create any "orphan" directories > needed to install files. Yes, but only to install files, it still won't create %_builddir, %_rpmdir & %_srcrpmdir.. Is iosmMkdirs() what I should be looking at? I guess rpmfiNew() would be the right place to add this hack, but I'm uncertain what would be the most correct & consistent way.. :o)
Re: [CVS] RPM: rpm/lib/ rpmrc.c
2009/3/12 Anders F Björklund > Per Øyvind Karlsen wrote: > > --- rpm/lib/rpmrc.c 12 Mar 2009 08:39:28 - 2.255 >> +++ rpm/lib/rpmrc.c 12 Mar 2009 09:14:25 - 2.256 >> @@ -551,6 +551,11 @@ >>xx = mireAppend(RPMMIRE_REGEX, 0, "ppc", NULL, &mi_re, &mi_nre); >> #endif >> >> +#if defined(__powerpc__) || defined(__i386__) || defined(__x86_64__) >> +if(cpuinfo_has_feature(cip, CPUINFO_FEATURE_PPC) || >> cpuinfo_has_feature(cip, CPUINFO_FEATURE_X86)) >> + xx = mireAppend(RPMMIRE_REGEX, 0, "fat", NULL, &mi_re, &mi_nre); >> +#endif >> + >> #if defined(__ia64__) >> if(cpuinfo_has_feature(cip, CPUINFO_FEATURE_IA64)) >>xx = mireAppend(RPMMIRE_REGEX, 0, "ia64", NULL, &mi_re, &mi_nre); >> @@ . >> > > > Out of curiousity, why didn't this include PPC64 as well ? > Another side note is that there are two PPC defines used... > > So maybe add "|| defined (__ppc__) || defined (__ppc64__)" ? > Not that "fat" wasn't a total hack to begin with, but anyway. > > Because I suck and haven't gotten around to deal with ppc yet. ;) I've removed the #ifdef on defines since, should cure this, but better check than on un.machine seems to be better as I understand naming across platforms isn't consistent.. I'll get there, eventually..
Re: [CVS] RPM: rpm/lib/ rpmrc.c
2009/3/17 Jeff Johnson > The DOOM (from aliasing) starts right here ... > > Your desire & approach to "compatibility" is sound, what's wrong is > compiling the > bleeping strings into RPM. That's basically what rpmrc files achieved, > having > strings & number identifiers out of RPM code. > > Note that rpmrc was an exceedingly gross implementation > that was thoroughly rotted in 1998 which is why it was ripped. > The syntax was bizzarre, the hacks on hacks on hacks were unmaintainable, > etc etc etc. And the voo-doo asm necessary to preserve the pretense that > RPM somehow "knew" the architecture, which involved attempting > an instruction and trapping SIGILL when the instruction did not > execute, was just icky poo ... > > Which is why I dropped rpmrc handling and arch detection and > started droning my RPMTAG_ARCH needs to DIE! DIE! DIE! mantra. > > But if you want to pursue "compatibility", then commit to some > reasonable format in a file. Using markup & patterns & templates is a > simpler > and sounder starting point than uname(2) or asm voo-doo qwaziness. > > But __PLEASE__ keep the bleeping "compatibility" strings __OUT__ of RPM C > code. > That will never ever work and will just recreate a problem that > took almost a decade to solve, removing rpmrc file handling. Yeah. you're right, I've had that thought myself more than once already, but my initial focus has been to just do something simple, fairly minimal and working before making it into something nice and sane in addition. Using libcpuinfo OTOH is something I'm planning on sticking with as it's portable and easy enough to maintain without bizarre syntax and any hacks which might be used will anyways be kept outside of rpm. :)
Re: [CVS] RPM: rpm/lib/ rpmrc.c
2009/3/17 Jeff Johnson
>
> On Mar 17, 2009, at 2:02 PM, Per Øyvind Karlsen wrote:
>
>
> Yeah. you're right, I've had that thought myself more than once already,
> but my initial focus has been to just do something simple, fairly minimal
> and working before making it into something nice and sane in addition.
>
> Using libcpuinfo OTOH is something I'm planning on sticking with as it's
> portable and easy enough to maintain without bizarre syntax and any hacks
> which might be used will anyways be kept outside of rpm. :)
>
>
>
> The terms "simple" and "easy" have a way of evolving into "works"
> which then morphs into "used" which then becomes "production"
> concrete with legacy issues etc etc etc
>
> AFAIK, the only flaw that you are unhappy with in the existing miRE
> patterns
> is that you want different /etc/rpm/platform patterns (and scoring),
> dependent
> on, say, whether the One True Arch! is "i386" or "x86_64".
>
> ATM, patterns follow the CPU-VENDOR-OS-GNU platform identifier
> in /etc/rpm/platform so that I did not have to be bothered explaining
> a whole lotta goop to lusers while attempting to get rid of rpmrc files.
>
> But there's literally no reason why that convention cannot be changed
> to move the platform affinity patterns to another path that is macro
> expanded including %{_target_cpu} and the rest of the platform macro
> goopiness.
>
> E.g. put your i386 affinity patterns into /etc/rpm/affinity.i386, similarly
> x86_64,
> and then trick up a diversion in /etc/rpm/platform as (literally)
>
> i386-unknown-linux-gnu
> /etc/rpm/affinity.%{_target_cpu}
>
> diversion == treat any line that starts with '/' as a path to read and
> insert.
>
> That isn't very hard to do at all.
>
> 73 de Jeff
>
I wasn't really unhappy about the platform scoring, that's okay enough, what
I was unhappy with was the inability to set default target platform for
building without platform score being affected, something that was possible
with buildarchtranslate.
This was only one of the issues, the main thing which I was unhappy about
was really the need for /etc/rpm/platform which needs to be maintained
manually by the user and makes it really hard for distributions to support
compatibility with several archs.
Runtime detection of this and the ability to override this with
/etc/rpm/platform is what is currently done in Mandriva Linux. This makes
rpm easier to maintain for the distribution, but the code in rpm for this is
as you said earlier really ugly and horrible to maintain, libcpuinfo solves
this by doing this outside of rpm and the code is much nicer and easier to
maintain as well, leaving only a minor amount of code in rpm to maintain.
This code sure has room for improvement, but it's satisfactory for my needs
for now and makes it possible for me to import rpm5 to Mandriva Linux with
consistent behaviour wrt rpm 4.6.0.
--
Regards,
Per Øyvind
Re: [CVS] RPM: rpm-4_5: rpm/ CHANGES configure.ac rpm/rpmio/ Makefile.am r...
2009/3/18 Michael Jennings > On Wednesday, 18 March 2009, at 20:29:31 (+0100), > Per ?yvind Karlsen wrote: > > > +AC_ARG_WITH(dmalloc, [ --with-uuid build with OSSP uuid > support ]) > > +if test $withval = yes ; then > > + AC_DEFINE(UUID, 1, [Build with OSSP uuid support?]) > > + LIBS="$LIBS -lossp-uuid" > > +fi > > + > > +withval=no > > This, too, could not possibly have been tested. Actually it was, what I wanted was to make it optional and disabled (something which obviously wasn't tested/cared for to begin with) by default, so since I didn't enable it, it worked just fine for me. I assume 'dmalloc' left there is what you're referring to, I've already fixed it, I dunno what you're getting at with "This, too" though.. -- Regards, Per Øyvind
Re: [CVS] RPM: rpm-4_5: rpm/ CHANGES configure.ac rpm/rpmio/ Makefile.am r...
2009/3/18 Michael Jennings > On Wednesday, 18 March 2009, at 22:41:35 (+0100), > Per ?yvind Karlsen wrote: > > > Actually it was, what I wanted was to make it optional and disabled > > (something which obviously wasn't tested/cared for to begin with) by > > default, so since I didn't enable it, it worked just fine for me. > > I assume 'dmalloc' left there is what you're referring to, I've already > > fixed it, I dunno what you're getting at with "This, too" though.. > > I guess I should've said "sufficiently tested." But testing the > default case and nothing else really shouldn't meet anyone's > definition of "tested." Yeah, gosh, testing enabling/disabling of non-standard features at build time which actually should disabled by default, introduced in sloppy fashion breaking for anyone not using it and that also requires stuff I don't even have installed is of course among top priorities of mine to fully test before making one of many commits I have in queue.. Silly mistakes in commits are easy to detect and fix, I'd rather do more testing once I'm done with what I'm working on rather than doing extensive testing for each and every commit. It was only commited to cvs and easy to fix there, it's not like it was anything released as stable to the world.. Silly mistakes in code commited are allowed and expected every now and then, getting anal about it is just silly. -- Regards, Per Øyvind
Re: [CVS] RPM: rpm/lib/ rpmds.c
2009/3/19 Jeff Johnson
> That's better, but there's still a fundamental flaw in what
> you are attempting.
>
>Data has endiannness, not CPU's.
Yes, but the order of the data read depends on the cpu..?
I'm not sure what you mean..
>
>
> So a library for cpuinfo only provides (at best) half of what
> is needed, and the run-time detection of cpu endianness is trivially done
> whenever/wherever needed.
Yeah, but I figured that it could be of convenience otherwise as well, I've
found myself adding several archs as ie. 'ExclusiveArch: {ix86} x86_64 ...'
etc. for packages over the years based on it working on little endian archs
only. A 'BuildRequires: cpuinfo(endianness) == little' would be more
convenient in such situations. :o)
>
>
> Tagging data as "x86_64" or "ppc" only implies endianness.
> Its quite routine to find "other-endian" data no matter
> what CPU you happen to be running on.
Yes, but what I'm doing right here is to determine whether cpu is in little
or big endian mode, to determine whether it's a mips or mipsel, I'm not sure
what you mean here either. :p
>
>
> The point is that the data, not the CPU, is what needs
> an endian tag associated. Pretending "x86_64" or "ppc"
> ordering is no different than what used to be done
> with
>
>#ifdef vax
>
> meant "little endian" and
>
>#ifdef sun
>
> meant "big endian".
>
> All you are doing is moving from a compile -> run-time name space
> with libcpuinfo.
>
Re: [CVS] RPM: rpm/ CHANGES macros.in
you're welcome :)
2009/5/4 Jeff Johnson
> Thank you!
>
> 73 de Jeff
>
> On May 4, 2009, at 12:39 PM, Per Øyvind Karlsen wrote:
>
> RPM Package Manager, CVS Repository
>> http://rpm5.org/cvs/
>>
>>
>>
>> Server: rpm5.org Name: Per Øyvind Karlsen
>> Root: /v/rpm/cvs Email: pkarl...@rpm5.org
>> Module: rpm Date: 04-May-2009 18:39:06
>> Branch: HEAD Handle: 2009050416390500
>>
>> Modified files:
>> rpm CHANGES macros.in
>>
>> Log:
>> get rid of parallel %___NVRDA macro, just merge it with %___NVRA in
>> stead.
>>
>> Summary:
>> RevisionChanges Path
>> 1.2969 +1 -0 rpm/CHANGES
>> 1.282 +3 -6 rpm/macros.in
>>
>>
>>
>> patch -p0 <<'@@ .'
>> Index: rpm/CHANGES
>>
>>
>> $ cvs diff -u -r1.2968 -r1.2969 CHANGES
>> --- rpm/CHANGES3 May 2009 17:35:58 - 1.2968
>> +++ rpm/CHANGES4 May 2009 16:39:05 - 1.2969
>> @@ -1,5 +1,6 @@
>>
>> 5.2a4 -> 5.2b1:
>> +- proyvind: get rid of parallel %___NVRDA macro, just merge it with
>> %___NVRA in stead.
>> - jbj: add RPMSENSE_RPMLIB to new tracking dependencies. at least its
>>consistent even if useless.
>> - jbj: fix: rpmdsMerge() shouldn't leave a result that seems to have
>> @@ .
>> patch -p0 <<'@@ .'
>> Index: rpm/macros.in
>>
>>
>> $ cvs diff -u -r1.281 -r1.282 macros.in
>> --- rpm/macros.in 4 Apr 2009 16:37:39 - 1.281
>> +++ rpm/macros.in 4 May 2009 16:39:05 - 1.282
>> @@ -1,7 +1,7 @@
>> #/*! \page config_macros Default configuration: @USRLIBRPM@/macros
>> # \verbatim
>> #
>> -# $Id: macros.in,v 1.281 2009/04/04 16:37:39 jbj Exp $
>> +# $Id: macros.in,v 1.282 2009/05/04 16:39:05 pkarlsen Exp $
>> #
>> # This is a global RPM configuration file. All changes made here will
>> # be lost when the rpm package is upgraded. Any per-system configuration
>> @@ -861,7 +861,7 @@
>> # binary packages.
>> #
>> # XXX Note: escaped %% for use in headerSprintf()
>> -%_build_name_fmt %%{ARCH}/%{___NVRDA}.rpm
>> +%_build_name_fmt %%{ARCH}/%{___NVRA}.rpm
>>
>> # The default transaction color. This value is a set of bits to
>> # determine file and dependency affinity for this arch.
>> @@ -1011,10 +1011,7 @@
>> # Query macros.
>> #
>> # Default query format string for displaying package names everywhere
>> -%___NVRA
>>
>> %%{NAME}-%%{VERSION}-%%{RELEASE}%%|ARCH?{.%%|SOURCERPM?{%%{ARCH}}:{src}|}:{}|
>> -
>> -# Format string including DistTag & DistEpoch if defined
>> -%___NVRDA
>> %%{NAME}-%%{VERSION}-%%{RELEASE}%%|DISTTAG?{-%%{DISTTAG}%%|DISTEPOCH?{%%{DISTEPOCH}}|}|%%|ARCH?{.%%|SOURCERPM?{%%{ARCH}}:{src}|}:{}|
>> +%___NVRA
>>
>> %%{NAME}-%%{VERSION}-%%{RELEASE}%%|DISTTAG?{-%%{DISTTAG}%%|DISTEPOCH?{%%{DISTEPOCH}}|}|%%|ARCH?{.%%|SOURCERPM?{%%{ARCH}}:{src}|}:{}|
>>
>>
>> # Default headerSprintf() output format string for rpm -qa
>> @@ .
>> __
>> RPM Package Managerhttp://rpm5.org
>> CVS Sources Repositoryrpm-...@rpm5.org
>>
>
> __
> RPM Package Managerhttp://rpm5.org
> Developer Communication Listrpm-devel@rpm5.org
>
Re: [CVS] RPM: rpm-5_2: rpm/ Makefile.am
2009/5/14 Jeff Johnson > Thanks for doing. > > But somehow there has to be a better way to > include files (and sub-trees) in EXTRA_DIST without > explicitly enumerating each and every file. > > E.g. liveconnect is unused by rpmjs, and is highly unlikely > to ever be used. Meanwhile the cost of customizing > imported subtrees is non-trivial, its adds "stuff" > that needs to be vetted each and every import, > and leads to Bloat! complaints for tar-balls. > > I haven't a clue what the better answer is. > > But the explicit enumeration is likely to break > again and again and again. I know my habits well ;-) Yeah, this was quite a bit annoying to include and felt quite & fragile.. btw. I noticed rpm building rpmkey & rpmxar by default now for some reason? (didn't happen with HEAD) How does one disable the build of these if headers missing? I figure that just placing it's code within #ifdefs gets a bit dirty with the expected executable binaries to produce and all.. It's not like it's a big problem for me to make sure to have what provides keyutils.h, xar.h etc. installed, I might as well do that anyways, but I figure that regular users might not be all that happy about it. ;) -- Regards, Per Øyvind
Re: [CVS] RPM: rpm-5_2: rpm/ Makefile.am
2009/5/14 Jeff Johnson > > On May 14, 2009, at 11:53 AM, Per Øyvind Karlsen wrote: > >> >> btw. I noticed rpm building rpmkey & rpmxar by default now for >> some reason? (didn't happen with HEAD) >> How does one disable the build of these if headers missing? >> > > One doesn't disable rpmkey or rpmxar or luac/luav or js or Berkeley > DB utilities or ... during build. > > Remove from /usr/lib/rpm/bin if you don't want the executable. > > The cost of the AutoFu baggage to configure the build is > already groaning from its own weight. > > >> I figure that just placing it's code within #ifdefs gets a bit dirty >> with the expected executable binaries to produce and all.. >> It's not like it's a big problem for me to make sure to have >> what provides keyutils.h, xar.h etc. installed, I might as well >> do that anyways, but I figure that regular users might not >> be all that happy about it. ;) >> >> > You might instead actually look at what is in keyutils (and rpmkey) > rather than just saying Bloat! Bloat! Bloat!. > > And if regular lusers do not know how to use rm(1), well adding > RPM AutoFu is unlikely to enlighten them further. > > (aside wrto rpmkey) > Distributing with rpmkey MANDATORY is the only way I can > see to automate signing packages. That is in fact what rpmkey > can do, add a per-session gpg key for retrieval by rpm. > > All of this functionality is already in rpm-5.0. > > And noone is using largely because they haven't looked and > the functionality is incomplete without additional executables. > > And around and around and around we go ... > >Bloat! Bloat! Bloat! Bloat! Bloat! Bloat! Bloat! Well, bloat wasn't really the issue, but rather build breakages. If mandatory then configure should check for the headers. -- Regards, Per Øyvind
Re: [CVS] RPM: rpm-5_2: rpm/tools/ Makefile.am
2009/5/14 Jeff Johnson > Thank you! > > Meanwhile, you have the same code in both the TRUE and the FALSE > branches of an if ... then ... else ... clause afaict. > > That "works", but perhaps there is simpler? > > ;-) > What? You expect me to think for myself as well now?!?! ;p Trying to focus on too many things at once while getting rpm-5_2 branch working.. Fixed :) > > 73 de Jeff > > > On May 14, 2009, at 3:02 PM, Per Øyvind Karlsen wrote: > > RPM Package Manager, CVS Repository >> http://rpm5.org/cvs/ >> >> ____________ >> >> Server: rpm5.org Name: Per Øyvind Karlsen >> Root: /v/rpm/cvs Email: pkarl...@rpm5.org >> Module: rpm Date: 14-May-2009 21:02:20 >> Branch: rpm-5_2 Handle: 2009051419021900 >> >> Modified files: (Branch: rpm-5_2) >> rpm/tools Makefile.am >> >> Log: >> make sure that the proper, required directory is created now that >> tools are installed under a dedicated 'bin/' directory >> >> Summary: >> RevisionChanges Path >> 2.120.2.2 +2 -1 rpm/tools/Makefile.am >> >> >> >> patch -p0 <<'@@ .' >> Index: rpm/tools/Makefile.am >> >> >> $ cvs diff -u -r2.120.2.1 -r2.120.2.2 Makefile.am >> --- rpm/tools/Makefile.am 7 May 2009 18:57:52 - 2.120.2.1 >> +++ rpm/tools/Makefile.am 14 May 2009 19:02:19 - 2.120.2.2 >> @@ -154,7 +154,7 @@ >> install-data-local: >> if WITH_DB_INTERNAL >> if WITH_DB_TOOLS_INTEGRATED >> - @[ -d $(pkgbindir) ] || $(mkinstalldirs) $(pkgbindir) >> + @[ -d $(DESTDIR)$(pkgbindir) ] || $(mkinstalldirs) >> $(DESTDIR)$(pkgbindir) >>$(INSTALL_PROGRAM_ENV) $(LIBTOOL) --mode=install >> $(pkgbinPROGRAMS_INSTALL) \ >>$(builddir)/db_tool $(DESTDIR)$(pkgbindir)/db_tool >>for tool in . $(my_DB_TOOLS); do \ >> @@ -163,6 +163,7 @@ >>ln $(DESTDIR)$(pkgbindir)/db_tool >> $(DESTDIR)$(pkgbindir)/$$tool; \ >>done >> else >> + @[ -d $(DESTDIR)$(pkgbindir) ] || $(mkinstalldirs) >> $(DESTDIR)$(pkgbindir) >>for tool in . $(my_DB_TOOLS); do \ >>test ".$$tool" = .. && continue; \ >>$(INSTALL_PROGRAM_ENV) $(LIBTOOL) --mode=install >> $(pkgbinPROGRAMS_INSTALL) \ >> @@ . >> __ >> RPM Package Managerhttp://rpm5.org >> CVS Sources Repositoryrpm-...@rpm5.org >> > > __ > RPM Package Managerhttp://rpm5.org > Developer Communication Listrpm-devel@rpm5.org >
Re: [CVS] RPM: rpm-5_2: js/src/ jsprf.c jsstddef.h rpm/ configure.ac
2009/7/23 Jeff Johnson > This isn't the right fix imho. > > js/src needs to build standalone, not include config.h. > > Otherwise, JS is gonna become MANDATORY INTERNAL to rpm. I thought it already was..? -- Regards, Per Øyvind
Re: [CVS] RPM: rpm-5_2: js/src/ jsprf.c jsstddef.h rpm/ configure.ac
2009/7/24 Ralf S. Engelschall > > On Thu, Jul 23, 2009, Per Ųyvind Karlsen wrote: > > > [...] > > fix va_list autofoo stuff breaking libjs build > > I'm wondering: > > 1. Why is HAVE_VA_LIST_AS_ARRAY defined but never used in the code? it's actually used in jsapi.c, if not defined you'll get warnings like this for linux on x86_64: jsapi.c: In function ‘JS_ConvertArgumentsVA’: jsapi.c:273: warning: passing argument 5 of ‘TryArgumentFormatter’ from incompatible pointer type jsapi.c:135: note: expected ‘struct __va_list_tag (*)[1]’ but argument is of type ‘struct __va_list_tag **’ jsapi.c: In function ‘JS_PushArgumentsVA’: jsapi.c:381: warning: passing argument 5 of ‘TryArgumentFormatter’ from incompatible pointer type jsapi.c:135: note: expected ‘struct __va_list_tag (*)[1]’ but argument is of type ‘struct __va_list_tag **’ I notice yet more mess though, I need to improve this one… > > 2. Why are such changes committed directly to 5.2 and not to HEAD first? mainly because I'm not on HEAD myself ATM, so testing and commiting on rpm-5_2 first obviously makes more sense… -- Regards, Per Øyvind
Re: [CVS] RPM: rpm/ CHANGES rpm/rpmdb/ rpmevr.c
2009/8/6 Jeff Johnson > Why are you reverting? The issue in the comment has already been fixed by > committing to > a representation for missing values. hm, really? I merely duplicated the hack used otherwise in rpmEVRoverlap(), what would be the proper solution? -- Regards, Per Øyvind
Re: [CVS] RPM: rpm/ CHANGES rpm/rpmdb/ rpmevr.c
2009/8/6 Jeff Johnson > > On Aug 6, 2009, at 12:26 AM, Per Øyvind Karlsen wrote: > > 2009/8/6 Jeff Johnson > >> Why are you reverting? The issue in the comment has already been fixed by >> committing to >> a representation for missing values. > > hm, really? > > I merely duplicated the hack used otherwise in rpmEVRoverlap(), what would > be the proper solution? > > > The proper solution (imho) is to permit bindings to set their own missing > values. Which simplifies the code in rpmlib, a missing or unspecified value > can either be defaulted (as in the case of Epoch:) or error'ed out. > IMO having rpmEVRparse() automatically taking care of such would be the best, this way you'd be sure to have a standard way sure to work for parsing strings rather than applications using rpmlib implementing their own ways with various success. For the specific situation in question which I started to poke around with rpmEVRparse() for, it was simple strings in the form %epoch:%version-%release vs %version-%release. You can take a look at Pkg_compare* in http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/rpm/perl-URPM/trunk/URPM.xs?view=markupto see the painful code example for urpmi.. :p > > The application, not EVRcmp, has more complete context and can supply > a better error message (or a better default) if necessary. > > The issue is > What is a missing value? A NULL pointer? A "" string? An integer zero? > NULL would be appropriate IMO and also what would be most likely to be passed in such situations, "" feels more like an actual value as well. :o) > > The additional issue is > What is the collation sequence? > Which is subtly at odds with whatever value is attempted by EVRcmp. > collation sequence? Not sure what is mean't by that, fill me in. :o) > > When dealing with a 3- (or with a 4- using Distepoch:) its more > reliable to eliminate NULL as a possible missing value entirely > (treating as an error) when passed in. > IMO that often tends to be more about moving around responsibility of being reliable to other places (and parties). At least rpmEVRparse() seems to be neat and nicely enough ensuring reliability with strings, whatever is decided upon for missing dealing with missing values in rpmEVRcompare() is for me less important than rpmEVRcompare() sorting it out without requiring complete EVRD strings. :) -- Regards, Per Øyvind
Re: [CVS] RPM: rpm/ CHANGES rpm/rpmdb/ rpmevr.c
2009/8/6 Jeff Johnson > > On Aug 6, 2009, at 4:09 AM, Per Øyvind Karlsen wrote: > > 2009/8/6 Jeff Johnson > >> >> On Aug 6, 2009, at 12:26 AM, Per Øyvind Karlsen wrote: >> >> 2009/8/6 Jeff Johnson >> >>> Why are you reverting? The issue in the comment has already been fixed by >>> committing to >>> a representation for missing values. >> >> hm, really? >> >> I merely duplicated the hack used otherwise in rpmEVRoverlap(), what would >> be the proper solution? >> >> >> The proper solution (imho) is to permit bindings to set their own missing >> values. Which simplifies the code in rpmlib, a missing or unspecified >> value >> can either be defaulted (as in the case of Epoch:) or error'ed out. >> > IMO having rpmEVRparse() automatically taking care of such would be the > best, this way you'd be sure to have a standard way sure to work for parsing > strings rather than > applications using rpmlib implementing their own ways with various success. > > > Lots of opinions "automatic". > > Clearly a change in EVRcmp() affects every code path through EVRcmp(), > including error paths ... > > For the specific situation in question which I started to poke around with > rpmEVRparse() for, it was simple strings in the form > %epoch:%version-%release vs %version-%release. > You can take a look at Pkg_compare* in > http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/rpm/perl-URPM/trunk/URPM.xs?view=markupto > see the painful code example for urpmi.. :p > > > ... and "simple strings". EVRcmp() is not a useful API for rpmlib, nor > should it attempt to correct or change arguments passed. > > Does glibc try to "automate" this "missing value" passed to strcmp(3)? > char * a = NULL; > char * b = ""; > ... > return strcmp(a, b)l > > Why should rpmlib automate "missing value" replacement? > But I'm not really suggesting for EVRcmp() to do do this, but rather rpmEVRparse() to do this.. > > >> The application, not EVRcmp, has more complete context and can supply >> a better error message (or a better default) if necessary. >> >> The issue is >> What is a missing value? A NULL pointer? A "" string? An integer zero? >> > NULL would be appropriate IMO and also what would be most likely to be > passed in such situations, "" feels more like an actual value as well. :o) > > > Lots of opinions for what "missing" means. > > NULL has the distinct disadvantage that rpmlib segfaults if not corrected > everywhere. > > >> The additional issue is >> What is the collation sequence? >> Which is subtly at odds with whatever value is attempted by EVRcmp. >> > collation sequence? > Not sure what is mean't by that, fill me in. :o) > >> >> When dealing with a 3- (or with a 4- using Distepoch:) its more >> reliable to eliminate NULL as a possible missing value entirely >> (treating as an error) when passed in. >> > IMO that often tends to be more about moving around responsibility of being > reliable to other places (and parties). At least rpmEVRparse() seems to be > neat and nicely enough ensuring reliability with strings, whatever is > decided upon for missing dealing with missing values in rpmEVRcompare() is > for me less important than rpmEVRcompare() sorting it out without requiring > complete EVRD strings. :) > > > With "simple strings", EVRcmp() cannot tell whether NULL is an "error" or > "missing". Nor is there any means to warn, or return an error, or configure > a "Have it yer own way!" representation for the behavior. > But I don't really care that much about EVRcmp(), I only care about rpmEVRparse(). In case of missing values rpmEVRparse() would set a null value, which EVRcmp() again wouldn't work with. I only made the change for it to set a valid value for EVRcmp(). > > If you want D "automatically" inserted, then do what every one else is > doing and rebuild your packages. Automatically inserting a constant value > when missing is useful only because DistEpoch: is hardly being used > and its not at all clear whether DistEpoch: will ever be useful. > Yet again, this had nothing specifically to do with distepoch.. For the situations that I actually experienced myself, it was actually missing epoch values that gave me problems.. -- Regards, Per Øyvind
Re: Two problems with file triggers
2009/9/1 David Smid > I revealed two problems in RPM5 file triggers implementation: > > 1. _filetriggers_dir macro is expected to end with slash, otherwise rpmGlob > can't find any *.filter files. Unfortunately, Mandriva RPM setup defines > this > macro without the ending slash as RPM4 doesn't have this limitation. > > 2. If there are no *.filter files in %_filetriggers_dir, > /var/lib/rpm/files-awaiting-filetriggers is never removed and keeps > growing. > > Both issues can be fixed by attached patches. Tested in Unity Linux. > Commited to HEAD & rpm-5_2, thx. :) -- Regards, Per Øyvind
Re: [CVS] RPM: rpm-5_2: rpm/rpmio/ rpmio.c
2009/11/11 Jeff Johnson > This likely should be perhaps 4 or so. 60 is way too long. > > The "heavily loaded" is really a red herring. Any modern kernel > on any reasonably configured linux box should easily be able to > satisfy a read request in much much less than 60 seconds. > > The original intent of the timeout was to deal with flakey hardware > that just disappeared, therebv leading to a difficult to debug > installer hang-up. > > Diddling up timeouts without reproducers and random claims of "heavily > loaded" is just silly. Whatever ... > Which are just yet another reason for why the patch hasn't been given much of a priority and just maintained as-is locally untill now. :p -- Regards, Per Øyvind
Re: [CVS] RPM: rpm-5_2: rpm/ CHANGES VENDOR rpm/lib/ psm.c rpm/ system.h
2009/11/11 Jeff Johnson > There's lots cheaper ways to get NVR than calling headerSprintf() here. > > See some of the rpmteFoo getters. > Yeah, rpmteNEVR() perhaps? Still, I'm wondering perhaps if using %_query_all_fmt as a default and maybe making it overridable through macros as well in stead might be a better idea.. Hmm... -- Regards, Per Øyvind
Re: [CVS] RPM: rpm-5_2: rpm/rpmio/ rpmio.c
2009/11/11 Jeff Johnson > Hmmm, careful here, Fclose() is the twistiest > > piece of code in RPM, hands down. > > For starters, fdFree() doesn't really free anything, > but rather decrements a reference count, and returns > the same fd pointer. If fdPop() is getting a NULL > pointer, then a refcount, likely on an error pathway, > has gone awry. But its the refcount, not the relative > ordering of fdFree() <-> fdPop() that needs fixing usually. > Ah, but doesn't seem to get a NULL pointer though.. > > Do you have a reproducer for whatever prompted this change? > --> fd 0xb4a3c30 ++ 4 Fclose at rpmio.c:2464| LIBIO 0xb4a11f0(-1) fdno -1 | LZD 0xb4e36b8 fdno 9 | UFD -1 fp (nil) ==> xzdClose(0xb4a3c30) rc 0| LIBIO 0xb4a11f0(-1) fdno -1 | LZD 0xb4e36b8 fdno 9 | UFD -1 fp (nil) XZDIO: 255 reads, 2084744 total bytes in 9.019816 secs --> fd 0xb4a3c30 -- 4 open (xzdClose) at xzdio.c:466| LIBIO 0xb4a11f0(-1) fdno -1 | LZD 0xb4e36b8 fdno 9 | UFD -1 fp (nil) ==32090== Invalid read of size 4 ==32090==at 0x5C699E0: fileno (fileno.c:37) ==32090==by 0x5582B3D: fdbg (rpmio.c:234) ==32090==by 0x558D35A: rpmioFreePoolItem (rpmmalloc.c:182) ==32090==by 0x55865B5: Fclose (rpmio.c:2526) ==32090==by 0x5085DD1: rpmpsmStage (psm.c:2536) ==32090==by 0x5085570: rpmpsmStage (psm.c:2792) ==32090==by 0x50ADB8E: rpmtsRun (transaction.c:1865) ==32090==by 0x509DD25: rpmcliInstallRun (rpminstall.c:327) ==32090==by 0x509F7FC: rpmcliInstall (rpminstall.c:697) ==32090==by 0x404A18: main (rpmqv.c:963) ==32090== Address 0xb4a11f0 is 0 bytes inside a block of size 280 free'd ==32090==at 0x4C2231D: free (vg_replace_malloc.c:323) ==32090==by 0x5C61C5C: fclose@@GLIBC_2.2.5 (iofclose.c:88) ==32090==by 0x558658F: Fclose (rpmio.c:2524) ==32090==by 0x5085DD1: rpmpsmStage (psm.c:2536) ==32090==by 0x5085570: rpmpsmStage (psm.c:2792) ==32090==by 0x50ADB8E: rpmtsRun (transaction.c:1865) ==32090==by 0x509DD25: rpmcliInstallRun (rpminstall.c:327) ==32090==by 0x509F7FC: rpmcliInstall (rpminstall.c:697) ==32090==by 0x404A18: main (rpmqv.c:963) --> fd 0xb4a3c30 -- 3 fopencookie (Fclose) at rpmio.c:2526 | LIBIO 0xb4a11f0(-1) fdno -1 | LZD 0xb4e36b8 fdno 9 | UFD -1 fp (nil) ==> fdClose(0xb4a3c30) rc fffe | UFD -1 fp (nil) Happened with: [r...@localhost rpm-5.2.DEVEL]# valgrind --track-origins=yes .libs/rpm --rpmiodebug -Uvh --force ~peroyvind/lib64directfb1.4_0-1.4.2-2mdv2010.1.x86_64.rpm Prolly' happens whenever using --rpmiodebug..? -- Regards, Per Øyvind
Re: [CVS] RPM: rpm-5_2: rpm/rpmio/ rpmio.c
2009/11/12 Jeff Johnson > > On Nov 11, 2009, at 5:58 PM, Per Øyvind Karlsen wrote: > > Hmmm ... > > > >> Happened with: >> [r...@localhost rpm-5.2.DEVEL]# valgrind --track-origins=yes .libs/rpm >> --rpmiodebug -Uvh --force >> ~peroyvind/lib64directfb1.4_0-1.4.2-2mdv2010.1.x86_64.rpm >> >> > Got a pointer to the package? IMHO its likelier that something else > has rotted than Fclose. For starters, I'm surprised to see UFD > underneath XZ using --rpmiodebug, XZ should be bottom of the stack IIRC, > but XZ is different than gzdio/bzdio, which have a private I/O pointer > at the bottom of the stack. > ftp://ftp.uninett.no/pub/linux/MandrivaLinux/devel/cooker/x86_64/media/main/release/lib64directfb1.4_0-1.4.2-1mdv2010.1.x86_64.rpm -- Regards, Per Øyvind
rpmdb segfaults after upgrade from rpm 4.6.0
I just did a fresh install of Mandriva Linux and updated to rpm 5.2 now, and this happens: [r...@localhost rpm]# valgrind rpm --rebuilddb -vvv --rpmdbdebug ==23457== Memcheck, a memory error detector ==23457== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==23457== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==23457== Command: rpm --rebuilddb -vvv --rpmdbdebug ==23457== D: pool fd: created size 896 limit -1 flags 0 D: pool ds: created size 224 limit -1 flags 0 D: pool syck: created size 32 limit -1 flags 0 D: pool ht: created size 64 limit -1 flags 0 D: pool mire: created size 128 limit -1 flags 0 D: pool lua:created size 56 limit -1 flags 0 D: pool ts: created size 1208 limit -1 flags 0 D: pool db: created size 304 limit -1 flags -1 ==> rpmdbNew(/, (null), 0x0, 0644, 0x0) db 0xb604a30 --> db 0xb604a30 ++ 1 rpmdbNew at rpmdb.c:1219 ==> dbiOpen(0xb604a30, Packages(0), 0x0) D: opening db environment /var/lib/rpm/Packages auto_commit:create D: opening db index /var/lib/rpm/Packages rdonly mode=0x0 D: locked db index /var/lib/rpm/Packages D: rebuilding database /var/lib/rpm into /var/lib/rpmrebuilddb.23457 D: creating directory /var/lib/rpmrebuilddb.23457 D: opening old database with dbapi 3 ==> rpmdbNew(/, /var/lib/rpm, 0x0, 0644, 0x2) db 0xb48a6e0 --> db 0xb48a6e0 ++ 1 rpmdbNew at rpmdb.c:1219 ==> dbiOpen(0xb48a6e0, Packages(0), 0x0) D: opening db environment /var/lib/rpm/Packages auto_commit D: opening db index /var/lib/rpm/Packages rdonly mode=0x0 D: opening new database with dbapi 3 ==> rpmdbNew(/, /var/lib/rpmrebuilddb.23457, 0x42, 0644, 0x0) db 0xb497910 --> db 0xb497910 ++ 1 rpmdbNew at rpmdb.c:1219 ==> dbiOpen(0xb497910, Packages(0), 0x0) D: opening db environment /var/lib/rpmrebuilddb.23457/Packages auto_commit:create D: opening db index /var/lib/rpmrebuilddb.23457/Packages create mode=0x42 ==> dbiOpen(0xb48a6e0, Packages(0), 0x0) D: pool mi: created size 200 limit -1 flags 0 --> db 0xb48a6e0 ++ 2 matchIterator at rpmdb.c:2913 ==> dbiOpen(0xb48a6e0, Packages(0), 0x0) D: pool dig:created size 408 limit -1 flags 0 ==23457== ==23457== Process terminating with default action of signal 11 (SIGSEGV) ==23457== Bad permissions for mapped region at address 0x403639C ==23457==at 0x531E0FD: headerVerifyInfo (header_internal.c:50) ==23457==by 0x5322EC1: headerCheck (pkgio.c:1022) ==23457==by 0x532B4A3: rpmmiNext (rpmdb.c:2605) ==23457==by 0x533039B: rpmdbRebuild (rpmdb.c:4198) ==23457==by 0x50C2680: rpmtsRebuildDB (rpmts.c:146) ==23457==by 0x404801: main (rpmqv.c:765) ==23457== ==23457== HEAP SUMMARY: ==23457== in use at exit: 190,626 bytes in 3,311 blocks ==23457== total heap usage: 10,231 allocs, 6,920 frees, 88,236,867 bytes allocated ==23457== ==23457== LEAK SUMMARY: ==23457==definitely lost: 0 bytes in 0 blocks ==23457==indirectly lost: 0 bytes in 0 blocks ==23457== possibly lost: 4,529 bytes in 8 blocks Gonna do some debugging myself now, but I figure others might have a better idea about it already.. ;) -- Regards, Per Øyvind
Re: rpmdb segfaults after upgrade from rpm 4.6.0
2009/11/17 Jeff Johnson
>
> On Nov 17, 2009, at 12:40 PM, Per Øyvind Karlsen wrote:
>
> > I just did a fresh install of Mandriva Linux and updated to rpm 5.2 now,
> > and this happens:
> >
>
> Yup. Attached patch avoids the segfault:
>
> Index: rpmdb/header_internal.c
> ===
> RCS file: /v/rpm/cvs/rpm/rpmdb/header_internal.c,v
> retrieving revision 1.19
> diff -p -u -w -r1.19 header_internal.c
> --- rpmdb/header_internal.c 31 Jul 2008 02:40:08 - 1.19
> +++ rpmdb/header_internal.c 17 Nov 2009 17:43:21 -
> @@ -47,7 +47,9 @@ int headerVerifyInfo(rpmuint32_t il, rpm
>/* XXX Convert RPMTAG_FILESTATE to RPM_UINT8_TYPE. */
>if (info->tag == 1029 && info->type == 1) {
>info->type = RPM_UINT8_TYPE;
> +#ifdef DYING
>pe[i].type = (rpmuint32_t) htonl(info->type);
> +#endif
>}
>info->offset = (rpmint32_t) ntohl(pe[i].offset);
> assert(negate || info->offset >= 0); /* XXX insurance */
>
> headerCheck is rather useless now that header blob's are PROT_READ
> protected.
>
> 73 de Jeff
d'oh:
==> dbiOpen(0xb604a30, Pubkeys(266),
0x0)
D: opening db index /var/lib/rpm/Pubkeys rdonly
mode=0x0
--> db 0xb604a30 ++ 2 matchIterator at
rpmdb.c:2913
==> dbiOpen(0xb604a30, Packages(0),
0x0)
D: pool h: created size 344 limit -1 flags
0
==> dbiOpen(0xb604a30, Packages(0),
0x0)
--> db 0xb604a30 -- 2 rpmdbClose at
rpmdb.c:1034
D: pool iob:created size 40 limit -1 flags
0
D: == DSA pubkey id dd684d7a 26752624
(h#1)
D: rpmdb: read h# 769 Header V3 DSA signature: OK, key ID
26752624
error: rpmdb: damaged header #769 retrieved --
skipping.
D: rpmdb: read h#1538 Header V3 DSA signature: OK, key ID 26752624
error: rpmdb: damaged header #1538 retrieved -- skipping.
==740==
==740== Process terminating with default action of signal 11 (SIGSEGV)
==740== Bad permissions for mapped region at address 0x4217000
==740==at 0x4C23414: memcpy (mc_replace_strmem.c:482)
==740==by 0x6900C8B: __db_goff_rpmdb (db_overflow.c:174)
==740==by 0x690F487: __db_ret_rpmdb (db_ret.c:46)
==740==by 0x68E7F1E: __dbc_get_rpmdb (db_cam.c:868)
==740==by 0x68F8607: __dbc_get_pp_rpmdb (db_iface.c:2095)
==740==by 0x533A718: db3cget (db3.c:765)
==740==by 0x53250F9: dbiGet (rpmdb.h:643)
==740==by 0x532AD5A: rpmmiGet (rpmdb.c:2472)
==740==by 0x532B2EF: rpmmiNext (rpmdb.c:2563)
==740==by 0x53303F7: rpmdbRebuild (rpmdb.c:4198)
==740==by 0x50C2730: rpmtsRebuildDB (rpmts.c:146)
==740==by 0x404801: main (rpmqv.c:765)
==740== Invalid free() / delete / delete[]
==740==at 0x4C21A58: free (vg_replace_malloc.c:325)
==740==by 0x5D5911A: ??? (in /lib64/libc-2.10.1.so)
==740==by 0x5D58CB1: ??? (in /lib64/libc-2.10.1.so)
==740==by 0x4A1D518: _vgnU_freeres (vg_preloaded.c:62)
==740==by 0x7FEFFF60F: ???
==740==by 0x6900C8B: __db_goff_rpmdb (db_overflow.c:174)
==740==by 0x690F487: __db_ret_rpmdb (db_ret.c:46)
==740==by 0x68E7F1E: __dbc_get_rpmdb (db_cam.c:868)
==740==by 0x68F8607: __dbc_get_pp_rpmdb (db_iface.c:2095)
==740==by 0x533A718: db3cget (db3.c:765)
==740==by 0x53250F9: dbiGet (rpmdb.h:643)
==740==by 0x532AD5A: rpmmiGet (rpmdb.c:2472)
==740== Address 0x403b398 is not stack'd, malloc'd or (recently) free'd
==740==
==740==
==740== HEAP SUMMARY:
==740== in use at exit: 209,881 bytes in 3,346 blocks
==740== total heap usage: 10,386 allocs, 7,044 frees, 88,845,335 bytes
allocated
==740==
==740== LEAK SUMMARY:
==740==definitely lost: 0 bytes in 0 blocks
==740==indirectly lost: 0 bytes in 0 blocks
==740== possibly lost: 13,176 bytes in 16 blocks
==740==still reachable: 196,705 bytes in 3,330 blocks
==740== suppressed: 0 bytes in 0 blocks
==740== Rerun with --leak-check=full to see details of leaked memory
==740==
==740== For counts of detected and suppressed errors, rerun with: -v
==740== ERROR SUMMARY: 4 errors from 1 contexts (suppressed: 4 from 4)
Minnesegmentsfeil
Re: rpmdb segfaults after upgrade from rpm 4.6.0
2009/11/17 Jeff Johnson
>
> On Nov 17, 2009, at 12:49 PM, Per Øyvind Karlsen wrote:
>
>
>
> 2009/11/17 Jeff Johnson
>
>>
>> On Nov 17, 2009, at 12:40 PM, Per Øyvind Karlsen wrote:
>>
>> > I just did a fresh install of Mandriva Linux and updated to rpm 5.2 now,
>> > and this happens:
>> >
>>
>> Yup. Attached patch avoids the segfault:
>>
>> Index: rpmdb/header_internal.c
>> ===
>> RCS file: /v/rpm/cvs/rpm/rpmdb/header_internal.c,v
>> retrieving revision 1.19
>> diff -p -u -w -r1.19 header_internal.c
>> --- rpmdb/header_internal.c 31 Jul 2008 02:40:08 - 1.19
>> +++ rpmdb/header_internal.c 17 Nov 2009 17:43:21 -
>> @@ -47,7 +47,9 @@ int headerVerifyInfo(rpmuint32_t il, rpm
>>/* XXX Convert RPMTAG_FILESTATE to RPM_UINT8_TYPE. */
>>if (info->tag == 1029 && info->type == 1) {
>>info->type = RPM_UINT8_TYPE;
>> +#ifdef DYING
>>pe[i].type = (rpmuint32_t) htonl(info->type);
>> +#endif
>>}
>>info->offset = (rpmint32_t) ntohl(pe[i].offset);
>> assert(negate || info->offset >= 0); /* XXX insurance */
>>
>> headerCheck is rather useless now that header blob's are PROT_READ
>> protected.
>>
>> 73 de Jeff
>
> d'oh:
> ==> dbiOpen(0xb604a30, Pubkeys(266),
> 0x0)
> D: opening db index /var/lib/rpm/Pubkeys rdonly
> mode=0x0
> --> db 0xb604a30 ++ 2 matchIterator at
> rpmdb.c:2913
> ==> dbiOpen(0xb604a30, Packages(0),
> 0x0)
> D: pool h: created size 344 limit -1 flags
> 0
> ==> dbiOpen(0xb604a30, Packages(0),
> 0x0)
> --> db 0xb604a30 -- 2 rpmdbClose at
> rpmdb.c:1034
> D: pool iob:created size 40 limit -1 flags
> 0
> D: == DSA pubkey id dd684d7a 26752624
> (h#1)
> D: rpmdb: read h# 769 Header V3 DSA signature: OK, key ID
> 26752624
> error: rpmdb: damaged header #769 retrieved --
> skipping.
> D: rpmdb: read h#1538 Header V3 DSA signature: OK, key ID 26752624
> error: rpmdb: damaged header #1538 retrieved -- skipping.
>
>
> Disable all the header check's.
>
> The root issue (my guess) is likely RPM_CHAR_TYPE == 1
> or not. RPM_CHAR_TYPE was removed in rpm-5.0, but
> is still present in @rpm.org code.
>
> RPM_CHAR_TYPE is used solely for keeping track of
> file state after install. Its a bit mask of 8 bits, the typing
> Simply Does Not Matter (but headerCheck() will fail headers)
>
> Also see the patch I sent back in June knocking out as
> many incompatibilities with rpm-4.7.x as possible.
>
> 73 de Jeff
>
Well, I've tried disabling both headerVerifyInfo() & headerCheck(), idn't
really do much about the segfault it seems.. :/
Not sure what exactly I should be looking for in the patches..
--
Regards,
Per Øyvind
Re: rpmdb segfaults after upgrade from rpm 4.6.0
2009/11/18 Jeff Johnson > > On Nov 17, 2009, at 12:49 PM, Per Øyvind Karlsen wrote: > > > D: == DSA pubkey id dd684d7a 26752624 > (h#1) > D: rpmdb: read h# 769 Header V3 DSA signature: OK, key ID > 26752624 > error: rpmdb: damaged header #769 retrieved -- > skipping. > D: rpmdb: read h#1538 Header V3 DSA signature: OK, key ID 26752624 > error: rpmdb: damaged header #1538 retrieved -- skipping. > ==740== > ==740== Process terminating with default action of signal 11 (SIGSEGV) > ==740== Bad permissions for mapped region at address 0x4217000 > ==740==at 0x4C23414: memcpy (mc_replace_strmem.c:482) > ==740==by 0x6900C8B: __db_goff_rpmdb (db_overflow.c:174) > ==740==by 0x690F487: __db_ret_rpmdb (db_ret.c:46) > ==740==by 0x68E7F1E: __dbc_get_rpmdb (db_cam.c:868) > ==740==by 0x68F8607: __dbc_get_pp_rpmdb (db_iface.c:2095) > ==740==by 0x533A718: db3cget (db3.c:765) > ==740==by 0x53250F9: dbiGet (rpmdb.h:643) > ==740==by 0x532AD5A: rpmmiGet (rpmdb.c:2472) > ==740==by 0x532B2EF: rpmmiNext (rpmdb.c:2563) > ==740==by 0x53303F7: rpmdbRebuild (rpmdb.c:4198) > ==740==by 0x50C2730: rpmtsRebuildDB (rpmts.c:146) > ==740==by 0x404801: main (rpmqv.c:765) > ==740== Invalid free() / delete / delete[] > ==740==at 0x4C21A58: free (vg_replace_malloc.c:325) > ==740==by 0x5D5911A: ??? (in /lib64/libc-2.10.1.so) > ==740==by 0x5D58CB1: ??? (in /lib64/libc-2.10.1.so) > ==740==by 0x4A1D518: _vgnU_freeres (vg_preloaded.c:62) > ==740==by 0x7FEFFF60F: ??? > ==740==by 0x6900C8B: __db_goff_rpmdb (db_overflow.c:174) > ==740==by 0x690F487: __db_ret_rpmdb (db_ret.c:46) > ==740==by 0x68E7F1E: __dbc_get_rpmdb (db_cam.c:868) > ==740==by 0x68F8607: __dbc_get_pp_rpmdb (db_iface.c:2095) > ==740==by 0x533A718: db3cget (db3.c:765) > ==740==by 0x53250F9: dbiGet (rpmdb.h:643) > ==740==by 0x532AD5A: rpmmiGet (rpmdb.c:2472) > ==740== Address 0x403b398 is not stack'd, malloc'd or (recently) free'd > ==740== > > > (from #rpm irc) > There is something funky here. Reverting the rpmmiGet() patch > that is doing PROT_READ is fine for now. But if headers can > be PROT_READ protected, there's no reason for any > signature/digest/sanity checks on header blob's any more. > > But also try rpm -qavv --nosignature and see if that "works". > > FWIW, given your /var/lib/rpm/Packages file, I'm able to do > rpm -qavv and --rebuilddb using rpm-5.2 on F11 (and some minor > debugging patches I can send along if needed) without difficulty. > > hth > > 73 de Jeff > hmm, I might've misunderstood you..? I provided you with the rpmdb that I had rebuilt with --rebuilddb, where only rpm -qa foo\* didn't work.. I should've perhaps provided you the one that resulted in segfaults with --rebuilddb etc. in stead? If so, here it is: http://212.251.243.147/~peroyvind/Packages-rpm-4.6.0ish.xz -- Regards, Per Øyvind
Re: rpmdb segfaults after upgrade from rpm 4.6.0
2009/11/18 Jeff Johnson
>
> So what is needed is a --rebuilddb with the PROT_WRITE added, and
> then revert to only setting PROT_READ. How you wish to achieve
> that conversion on the fly is up to you. The forward looking goal
> is to use PROT_READ hardware protection rather than all the
> overly complex and senseless digest/signature/sanity checking
> with is most definitely cpu intensive and largely unnecessary.
>
Hmm, if not automatically handling this in code, what about some option,
macro or something? It obviously seems like something that a lot of people
is likely to run into and therefore should be dealt with in a way easily
usable for everyone.
>
> So headerVerifyInfo() (and the attempt to change PROT_READ memory
> that results in a SIG11) is going into the bit bucket where
> signature/digest
> checking of rpmdb Headers has already been discarded.
>
> (aside)
> There's another way to "fix" this issue by re-adding RPM_CHAR_TYPE rather
> than attempting to change a data type in a PROT_READ header on the fly
> as is being done in rpmdb/header_internal.c.
>
> The goal in RPM-5.0 is/was to make all header data types unsigned,
> and that goal was most definitely achieved, and signified by doing a major
> release of RPM in which no compatibility was promised or intended.
>
> I'm not about to go all the way back and re-release every version of RPM
> since rpm-5.0
> to retrofit "compatibility" for distros that don't use rpm5.orgcode
> particularly since this issue
> was both known and discussed before rpm-5.0 was released. See rpm-devel
> archives.
>
> But a conversion tool could be written rather easily.
>
> The RPM_CHAR_TYPE is never found in package headers,
> is used solely in one place, adding RPMTAG_FILESTATES while
> installing by rpm-4.x.
>
> Here is the patch that "fixes" by re-adding RPM_CHAR_TYPE . There's
> additional places needed
> to remove compiler warnings (at a minimum), and likely to display
> RPM_CHAR_TYPE if
> the already removed data type is to be retrofitted.
>
Hmm, so if you'd like to attempt achieving "some" compatibility with rpm.org,
this would be preferred?
>
> $ cvs diff rpmtag.h header_internal.c
> Index: rpmtag.h
> ===
> RCS file: /v/rpm/cvs/rpm/rpmdb/rpmtag.h,v
> retrieving revision 1.62.2.2
> diff -p -u -w -r1.62.2.2 rpmtag.h
> --- rpmtag.h 25 Jul 2009 00:56:51 - 1.62.2.2
> +++ rpmtag.h 18 Nov 2009 03:58:11 -
> @@ -25,7 +25,7 @@ typedef /*...@abstract@*/ /*...@refcounted@*/
> */
> enum rpmTagType_e {
> /* RPM_NULL_TYPE = 0 - never been used. */
> - /* RPM_CHAR_TYPE = 1 - never been used, same as RPM_UINT8_TYPE. */
> +RPM_CHAR_TYPE = 1,
> RPM_UINT8_TYPE = 2,
> RPM_UINT16_TYPE = 3,
> RPM_UINT32_TYPE = 4,
> @@ -37,7 +37,7 @@ enum rpmTagType_e {
> /* RPM_ASN1_TYPE = 10 - never been used. */
> /* RPM_OPENPGP_TYPE= 11 - never been used. */
> };
> -#define RPM_MIN_TYPE 2
> +#define RPM_MIN_TYPE 1
> #define RPM_MAX_TYPE 9
> #define RPM_MASK_TYPE 0x
>
> Index: header_internal.c
> ===
> RCS file: /v/rpm/cvs/rpm/rpmdb/header_internal.c,v
> retrieving revision 1.19
> diff -p -u -w -r1.19 header_internal.c
> --- header_internal.c 31 Jul 2008 02:40:08 - 1.19
> +++ header_internal.c 18 Nov 2009 03:58:11 -
> @@ -44,11 +44,13 @@ int headerVerifyInfo(rpmuint32_t il, rpm
> for (i = 0; i < il; i++) {
> info->tag = (rpmuint32_t) ntohl(pe[i].tag);
> info->type = (rpmuint32_t) ntohl(pe[i].type);
> +#ifdef DYING
> /* XXX Convert RPMTAG_FILESTATE to RPM_UINT8_TYPE. */
> if (info->tag == 1029 && info->type == 1) {
> info->type = RPM_UINT8_TYPE;
> pe[i].type = (rpmuint32_t) htonl(info->type);
> }
> +#endif
> info->offset = (rpmint32_t) ntohl(pe[i].offset);
> assert(negate || info->offset >= 0); /* XXX insurance */
> if (negate)
>
> Checking yes the above patch "works" with "rpm -qavv" and --rebuilddb.
>
rpm -qa foo\* is still broken though.. ;p
Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ filetriggers.c
2009/11/18 Jeff Johnson
>
> On Nov 18, 2009, at 10:00 AM, Per Øyvind Karlsen wrote:
>
> > Index: rpm/lib/filetriggers.c
> >
>
> > $ cvs diff -u -r2.19 -r2.20 filetriggers.c
> > --- rpm/lib/filetriggers.c 2 Sep 2009 10:29:13 - 2.19
> > +++ rpm/lib/filetriggers.c 18 Nov 2009 15:00:27 - 2.20
> > @@ -328,6 +328,9 @@
> > goto exit;
> >
> > fd = Fopen(fn, "r.fpio");
> > +if (fd == NULL)
> > +goto exit;
> > +
> > fp = fdGetFILE(fd);
> >
> > if (fp != NULL) {
> > @@ .
>
> Slightly better (it won't ever matter) is
>
>fd = Fopen(fn, "r.fpio")
> if (fd == NULL || Ferror(fd)) {
>if (fd) (void) Fclose(fd);
>goto exit;
>}
>
> And FPIO as in "r.fpio" can likely be removed with
> a little thought. The benefit is that you will have
> simpler code paths, without the complexity of
> stacked handlers and Fclose() issues, if you
> just use the default.
>
> I'll knock out the "r.fpio" for you if asked.
>
I certainly wouldn't mind. :)
--
Regards,
Per Øyvind
Re: Fix a missing value issue with Conflicts: behavior in rpm-4.6.0
2009/11/20 Jeff Johnson
>
> On Nov 20, 2009, at 11:46 AM, Jeff Johnson wrote:
>
> > Attached is a patch that should fix
> >
> > https://qa.mandriva.com/show_bug.cgi?id=55810
> >
> > Tested by running
> > rpm -Va --nofiles
> > on a 2010.RC2 VM.
> >
> > WORKSFORME
> >
> > Note that this patch is for @rpm.org code. The
> > identical issue was fixed last January @rpm5.org AFAIK.
> >
> > hth
>
> Attached is a better version of the patch, that captures the
> Conflicts: behavior without changing any Requires: behavior
>
> This command was run on Mandriva 2010 RC2:
>
> [...@localhost lib]$ rpm -Va --nofiles
> Unsatisfied dependencies for acpid-2:1.0.10-1mnb2.i586:
>suspend-scripts < 1.27-2mdv2007.1 conflicts with
> acpid-2:1.0.10-1mnb2.i586
> Unsatisfied dependencies for pm-utils-1.2.5-4mdv2010.0.i586:
>suspend-scripts < 1.27-2mdv2007.1 conflicts with
> acpid-2:1.0.10-1mnb2.i586
> [...@localhost lib]$
>
> hth
>
> 73 de Jeff
>
> This breaks Conflicts: foo <= 1.1, Conflicts: foo = 1.1 and Requires: foo
<= 1.1..
Hm, what about replacing:
if (((rpmdsTagN(A) == RPMTAG_REQUIRENAME) ||
(rpmdsTagN(B) == RPMTAG_REQUIRENAME))
&& (*aR == '\0' || *bR == '\0'))
{
aR = NULL;
bR = NULL;
}
with:
if(((B->Flags[B->i] & (~(RPMSENSE_LESS | RPMSENSE_GREATER)) &
RPMSENSE_EQUAL)
|| ((B->Flags[B->i] & RPMSENSE_LESS) && (B->Flags[B->i] &
RPMSENSE_EQUAL)))
&& *bR == '\0')
{
aR = NULL;
bR = NULL;
}
?
Ie. this would give us consistent behaviour for both requires & conflicts,
while
also giving same behaviour with Requires: foo = 1.1 and Requires: foo <= 1.1
as earlier.
This "should" solve the issues reported and those only without changing
behaviour otherwise..(?)
WDYT?
--
Regards,
Per Øyvind
rpm-4.6.0-rpmvercmp-handle-missing-release.patch
Description: Binary data
Re: Fix a missing value issue with Conflicts: behavior in rpm-4.6.0
2009/11/21 Jeff Johnson
>
> On Nov 20, 2009, at 7:53 PM, Per Øyvind Karlsen wrote:
>
> 2009/11/20 Jeff Johnson
>
>>
>> On Nov 20, 2009, at 11:46 AM, Jeff Johnson wrote:
>>
>> > Attached is a patch that should fix
>> >
>> > https://qa.mandriva.com/show_bug.cgi?id=55810
>> >
>> > Tested by running
>> > rpm -Va --nofiles
>> > on a 2010.RC2 VM.
>> >
>> > WORKSFORME
>> >
>> > Note that this patch is for @rpm.org code. The
>> > identical issue was fixed last January @rpm5.org AFAIK.
>> >
>> > hth
>>
>> Attached is a better version of the patch, that captures the
>> Conflicts: behavior without changing any Requires: behavior
>>
>> This command was run on Mandriva 2010 RC2:
>>
>> [...@localhost lib]$ rpm -Va --nofiles
>> Unsatisfied dependencies for acpid-2:1.0.10-1mnb2.i586:
>>suspend-scripts < 1.27-2mdv2007.1 conflicts with
>> acpid-2:1.0.10-1mnb2.i586
>> Unsatisfied dependencies for pm-utils-1.2.5-4mdv2010.0.i586:
>>suspend-scripts < 1.27-2mdv2007.1 conflicts with
>> acpid-2:1.0.10-1mnb2.i586
>> [...@localhost lib]$
>>
>> hth
>>
>> 73 de Jeff
>>
>> This breaks Conflicts: foo <= 1.1, Conflicts: foo = 1.1 and Requires: foo
> <= 1.1..
>
>
> Back up please.
>
> The above Conflicts: was what was reported broken (as in not reported as a
> Conflict:)
>
> My first patch broke Requires: (because I got tricked)
>
> The "rpm -Va --nofiles" shows that no extra Requires: fail and the one
> (known broken) Conflicts:
> is now reported correctly.
>
> So please add details for your claim. I do not see the flaws.
>
Well, to be more accurate:
1:
Package a:
Provides: foo = 1.1-2
Package b:
Conflicts: foo <= 1.1
Old rpmvercmp() behaviour:
a Provides: foo = 1.1
b Conflicts: foo <= 1.1
Which will satisfy dependency.
New rpmvercmp() behaviour:
a Provides: foo = 1.1-2
b Conflicts: foo <= 1.1-
Will not satisfy dependency.
2:
Package a:
Provides: foo = 1.1-2
Package b:
Conflicts: foo = 1.1
Old rpmvercmp() behaviour:
a Provides: foo = 1.1
b Conflicts: foo = 1.1
Which will satisfy dependency.
New rpmvercmp() behaviour:
a Provides: foo = 1.1-2
b Conflicts: foo = 1.1-
Will not satisfy dependency.
3:
Package a:
Provides: foo = 1.1-2
Package b:
Requires: foo <= 1.1
Old rpmvercmp() behaviour:
a Provides: foo = 1.1
b Requires: foo <= 1.1
Which will satisfy dependency.
New rpmvercmp() behaviour:
a Provides: foo = 1.1-2
b Requires: foo <= 1.1-
Will not satisfy dependency.
> Hm, what about replacing:
> if (((rpmdsTagN(A) == RPMTAG_REQUIRENAME) ||
> (rpmdsTagN(B) == RPMTAG_REQUIRENAME))
> && (*aR == '\0' || *bR == '\0'))
> {
> aR = NULL;
> bR = NULL;
> }
> with:
> if(((B->Flags[B->i] & (~(RPMSENSE_LESS | RPMSENSE_GREATER)) &
> RPMSENSE_EQUAL)
> || ((B->Flags[B->i] & RPMSENSE_LESS) && (B->Flags[B->i] &
> RPMSENSE_EQUAL)))
> && *bR == '\0')
> {
> aR = NULL;
> bR = NULL;
> }
> ?
>
> Ie. this would give us consistent behaviour for both requires & conflicts,
> while
> also giving same behaviour with Requires: foo = 1.1 and Requires: foo <=
> 1.1 as earlier.
>
> This "should" solve the issues reported and those only without changing
> behaviour otherwise..(?)
>
> WDYT?
>
>
> I've told you what I think. In order to change rpmdsCompare() _AFTER_ RC2,
> one needs to do "rpm -Vavv --nofiles" with and without any patch, and diff,
> to ensure that there are no unknown changes in behavior.
>
> Anything else is called "hacking". ;-)
>
Yeah, but the cases where things breaks aren't very common in Mandriva Linux
and isn't found in any of the packages found in a standard installation...;p
--
Regards,
Per Øyvind
Re: Fix a missing value issue with Conflicts: behavior in rpm-4.6.0
2009/11/21 Jeff Johnson > > On Nov 20, 2009, at 8:58 PM, Jeff Johnson wrote: > > > New rpmvercmp() behaviour: > a Provides: foo = 1.1-2 > b Requires: foo <= 1.1- > Will not satisfy dependency. > > > This is what I expect (although I'm surprised at the change). > > > Hmm I got tricked by the trailing '-' typo on a small screen. > > With a '-' then \0 (which happens to be the same as a missing value > but is actually _THE_ value) should behave as I described. > > But its a typo ... > > Lemme think some more on this one. I'm still pretty sure that > Requires: behavior has not changed from previously, that's > verifiable with -Vavv. > > But you're asking a harder question, what is "correct", and that I have to > think about. > > Note that getting Requires: correct (because a failed Requires: match is > FULLSTOP) > is always more important than getting Conflicts: correct. > > > 73 de Jeff > yawn, I'm really tired and about to go to bed now, so I don't feel like refreshing specifics of #3 as I'm too tired to understand it myself now and my reproducer didn't seem to reproduce any unsatisfied dependencies.. (which is probably also why I'm mixing rpmvercmp() with rpmdsCompare() as well;) :p but here's the behaviour of conflicts when using either old rpm 4.6.0 behaviour or my patch: [r...@proyvind ~]# rpm -Uvh --test /home/peroyvind/RPM/RPMS/noarch/b1-1.0-1.noarch.rpm /home/peroyvind/RPM/RPMS/noarch/b2-1.0-1.noarch.rpm error: Failed dependencies: foo <= 1.1 conflicts with b1-1.0-1.noarch foo = 1.1 conflicts with b2-1.0-1.noarch with your patch: [r...@proyvind ~]# rpm -Uvh --test /home/peroyvind/RPM/RPMS/noarch/b1-1.0-1.noarch.rpm /home/peroyvind/RPM/RPMS/noarch/b2-1.0-1.noarch.rpm Preparing...### [100%] provides/conflicts: [r...@proyvind ~]# rpm -qp --provides /home/peroyvind/RPM/RPMS/noarch/a-1.1-1.noarch.rpm foo = 1.1-2 a = 1.1-1 [r...@proyvind ~]# rpm -qp --conflicts /home/peroyvind/RPM/RPMS/noarch/b1-1.0-1.noarch.rpm foo <= 1.1 [r...@proyvind ~]# rpm -qp --conflicts /home/peroyvind/RPM/RPMS/noarch/b2-1.0-1.noarch.rpm foo = 1.1 So here you'll see for your change that 1) it changes/breaks this certain behavior 2) behaviour of requires & conflicts is inconsistent. I'll see if I can clean up my thoughts on the requires (#3) whether the issue was bogus or not tomorrow, but now I'm gonna get to bed first. :) Btw. does my patch look sane? g'nite! :) -- Regards, Per Øyvind
Re: Fix a missing value issue with Conflicts: behavior in rpm-4.6.0
2009/11/21 Jeff Johnson
>
> On Nov 20, 2009, at 10:19 PM, Per Øyvind Karlsen wrote:
>
>
> yawn, I'm really tired and about to go to bed now, so I don't feel like
> refreshing specifics of #3 as I'm too tired to understand it myself now and
> my reproducer didn't seem to reproduce any unsatisfied dependencies.. (which
> is probably also why I'm mixing rpmvercmp() with rpmdsCompare() as well;) :p
>
> but here's the behaviour of conflicts when using either old rpm 4.6.0
> behaviour or my patch:
> [r...@proyvind ~]# rpm -Uvh --test
> /home/peroyvind/RPM/RPMS/noarch/b1-1.0-1.noarch.rpm
> /home/peroyvind/RPM/RPMS/noarch/b2-1.0-1.noarch.rpm
> error: Failed dependencies:
> foo <= 1.1 conflicts with b1-1.0-1.noarch
> foo = 1.1 conflicts with b2-1.0-1.noarch
>
> with your patch:
> [r...@proyvind ~]# rpm -Uvh --test
> /home/peroyvind/RPM/RPMS/noarch/b1-1.0-1.noarch.rpm
> /home/peroyvind/RPM/RPMS/noarch/b2-1.0-1.noarch.rpm
> Preparing...###
> [100%]
>
> provides/conflicts:
> [r...@proyvind ~]# rpm -qp --provides
> /home/peroyvind/RPM/RPMS/noarch/a-1.1-1.noarch.rpm
> foo = 1.1-2
> a = 1.1-1
> [r...@proyvind ~]# rpm -qp --conflicts
> /home/peroyvind/RPM/RPMS/noarch/b1-1.0-1.noarch.rpm
> foo <= 1.1
> [r...@proyvind ~]# rpm -qp --conflicts
> /home/peroyvind/RPM/RPMS/noarch/b2-1.0-1.noarch.rpm
> foo = 1.1
>
> So here you'll see for your change that 1) it changes/breaks this certain
> behavior 2) behaviour of requires & conflicts is inconsistent.
>
>
> I'm not arguing. There are no reference points, only behaviors. Whatever
> behavior you wish to see is the one you should use.
>
> You might try writing your test cases in CUDF and sending
> through a SAT solver. That process is what identified the
> Conflicts: problem in RPM originally.
>
> I'll see if I can clean up my thoughts on the requires (#3) whether the
> issue was bogus or not tomorrow, but now I'm gonna get to bed first. :)
>
>
> I think you also need to see whether the original problem with Conflicts:
> is
> still solved with your patch or not.
>
It is. :)
>
> The real issue is what @rpm.org code does and what Mandriva wants. I
> cannot answer in that area beyond diagnosing and suggesting:
> 1) fix the packages
> 2) supplying a patch
>
> I diagnosed a problem, attempted a patch, boogered that up per
> https://qa.mandriva.com/show_bug.cgi?id=55810
> and supplied a corrected patch.
>
> Btw. does my patch look sane?
>
>
> The patch looks overly complicated because the logic uses dependency flags.
>
> Missing value definitions should not depend on type of comparison.
>
> Missing value definitions should also not depend on whether
> Conflicts: or Requires: is being compared (as I have done), but I see no
> other
> way to retrofit a fix for the problem(s) that needed to be solved.
>
> 73 de Jeff
>
Well, the change could be simplified this way, but sure, it still uses
dependency flags..
if((B->Flags[B->i] & (~RPMSENSE_GREATER & RPMSENSE_EQUAL))
&& *bR == '\0')
{
aR = NULL;
bR = NULL;
}
Oh, btw. disregard issue #3 (requires: foo <= 1.1), it was only an issue
with the first patch I noticed, but with your patch you'll still have the
same issue with requires as was originally reported with conflicts, (ie. a
provides foo = 1.1, b requires foo < 1.1-2, a wouldn't satisfy b's
dependency) even less common scenario, but possible, and behaviour for
conflicts vs requires would also be inconsistent..
--
Regards,
Per Øyvind
rpm-4.6.0-rpmvercmp-handle-missing-release.patch
Description: Binary data
Re: Fix a missing value issue with Conflicts: behavior in rpm-4.6.0
2009/11/21 Per Øyvind Karlsen > Well, the change could be simplified this way, but sure, it still uses > dependency flags.. > if((B->Flags[B->i] & (~RPMSENSE_GREATER & RPMSENSE_EQUAL)) > d'oh, should've been: if((B->Flags[B->i] & RPMSENSE_EQUAL) && !(B->Flags[B->i] & RPMSENSE_GREATER) patch kept at: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/rpm/current/SOURCES/rpm-4.6.0-rpmvercmp-handle-missing-values.patch -- Regards, Per Øyvind
Re: [CVS] RPM: rpm/ CHANGES rpm/js/ rpmte-js.c rpm/lib/ rpmgi.c
2009/11/27 Pinto Elia : > RPM Package Manager, CVS Repository > http://rpm5.org/cvs/ > > > Server: rpm5.org Name: Pinto Elia > Root: /v/rpm/cvs Email: devzero2...@rpm5.org > Module: rpm Date: 27-Nov-2009 15:29:06 > Branch: HEAD Handle: 2009112714290401 > > Modified files: > rpm CHANGES > rpm/js rpmte-js.c > rpm/lib rpmgi.c > > Log: > complete changing db2offset data type to uint32_t everywhere Should've rather been rpmuint32_t, no? -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/ Makefile.am
I forgot, out of practice.. ;) 2010/5/7 Jeff Johnson : > check-ins on HEAD first please, or same old same old gets to be > redone all over again. > > 73 de Jeff > > On May 7, 2010, at 1:41 PM, Per Øyvind Karlsen wrote: > >> RPM Package Manager, CVS Repository >> http://rpm5.org/cvs/ >> >> >> Server: rpm5.org Name: Per Øyvind Karlsen >> Root: /v/rpm/cvs Email: pkarl...@rpm5.org >> Module: rpm Date: 07-May-2010 19:41:38 >> Branch: rpm-5_3 Handle: 2010050717413700 >> >> Modified files: (Branch: rpm-5_3) >> rpm Makefile.am >> >> Log: >> add ruby files to generated tarball >> >> Summary: >> Revision Changes Path >> 2.247.2.3 +1 -0 rpm/Makefile.am >> >> >> patch -p0 <<'@@ .' >> Index: rpm/Makefile.am >> >> $ cvs diff -u -r2.247.2.2 -r2.247.2.3 Makefile.am >> --- rpm/Makefile.am 23 Apr 2010 18:33:57 - 2.247.2.2 >> +++ rpm/Makefile.am 7 May 2010 17:41:37 - 2.247.2.3 >> @@ -12,6 +12,7 @@ >> lua/[A-Z]* lua/*.[ch] lua/local/l* \ >> file/src/[A-Z]* file/src/*.[ch] file/python file/magic file/doc >> file/[A-Z]* file/acinclude.m4 file/aclocal.m4 \ >> file/autogen.sh file/config* \ >> + ruby/*.[ch] ruby/Makefile.in ruby/Makefile.am \ >> macros/*.in \ >> perl/typemap \ >> perl/Makefile.PL.in \ >> @@ . >> __ >> RPM Package Manager http://rpm5.org >> CVS Sources Repository rpm-...@rpm5.org > > __ > RPM Package Manager http://rpm5.org > Developer Communication List rpm-de...@rpm5.org > __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
rpmdb barf after upgrading to rpm 5.3
I just upgraded to latest rpm-5_3 checkout from rpm 4.6, and sure, I see that the segfault that would occur with 5.2 no longer happens, but I'm not really left with a very usable rpmdb either.. Too lazy to investigate myself today, I'll just post my results with --rebuilddb and hope for any instructions to deal with, sparing me from any efforts involving any thinking on my own: [r...@localhost rpm]# LC_ALL=C rpm -vvv --rebuilddb D: pool fd: created size 384 limit -1 flags 0 D: pool ds: created size 224 limit -1 flags 0 D: pool syck: created size 32 limit -1 flags 0 D: pool ht: created size 64 limit -1 flags 0 D: pool mire: created size 128 limit -1 flags 0 D: pool lua:created size 56 limit -1 flags 0 D: pool ts: created size 1200 limit -1 flags 0 D: pool db: created size 320 limit -1 flags 0 D: pool dbi:created size 440 limit -1 flags 0 error: unrecognized db option: "mp_mmapsize" ignored. error: unrecognized db option: "mp_size" ignored. error: unrecognized db option: "verify" ignored. D: rpmdb: cpus 2 physmem 3271Mb D: opening db environment /var/lib/rpm/Packages create:mpool rpmdb: unable to allocate memory for mutex; resize mutex region rpmdb: PANIC: Cannot allocate memory ==> rpmdbe_event_notify(0x1243f70, NO_SUCH_EVENT(0), 0x7fffa6a53c2c) app_private (nil) rpmdb: unable to join the environment error: db_init:db3.c:949: dbenv->open(-30973): DB_RUNRECOVERY: Fatal error, run database recovery Re-opening dbenv with DB_RECOVER ... D: opening db environment /var/lib/rpm/Packages create:mpool rpmdb: unable to allocate memory for mutex; resize mutex region rpmdb: PANIC: Cannot allocate memory ==> rpmdbe_event_notify(0x1243f70, NO_SUCH_EVENT(0), 0x7fffa6a53c2c) app_private (nil) rpmdb: unable to join the environment error: db_init:db3.c:949: dbenv->open(-30973): DB_RUNRECOVERY: Fatal error, run database recovery recovery failed. Exiting ... -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: rpmdb barf after upgrading to rpm 5.3
2010/5/24 Jeff Johnson : > > On May 24, 2010, at 10:53 AM, Jeff Johnson wrote: >> >> The easiest way to swap the indices is to do db_dump -> sed -> db_load. >> The db_dump looks something like this (this happens to be big endian already) >> >> VERSION=3 >> format=bytevalue >> type=btree >> db_pagesize=4096 >> HEADER=END >> >> af03 > ^^ this is "native endian" not big endian. >> 0001 >> 004413dc003f00070f3c001000640008000 >> 103e800060002000103e900060012000103ea000 >> 6001a000103ec0009002103ed0009004c000 >> 103ee000401d103ef000601d4000103f1000 >> 401f4000103f2000601f8000103f30006020 >> > > pologies for the error. -ENOPCOFFEE. > 73 de Jeff > __ > RPM Package Manager http://rpm5.org > Developer Communication List rpm-de...@rpm5.org > hmm, even after swapping, I still get the same error.. :/ -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: Endianness script
2010/8/27 Jeremy Huntwork : > Hello, > > Jeff Johnson mentioned that there was a script he shared back in May which > swapped endianness when converting data from a 5.2 rpm db to 5.3. Anyone > happen to have that on-hand? This one probably: #!/bin/sh mv $1 $1-ORIG /usr/lib/rpm/bin/db_dump $1-ORIG | sed -e 's/^ \(..\)\(..\)\(..\)\(..\)$/ \4\3\2\1/'| /usr/lib/rpm/bin/db_load $1 -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
