From arekm at maven.pl Sun Jan 1 21:36:34 2017 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Sun, 1 Jan 2017 21:36:34 +0100 Subject: gcc-dirs - how it is supposed to work? Message-ID: <201701012136.34304.arekm@maven.pl> gcc for multilib on x86_64 needs gcc x32 installed. That requires gcc-dirs from both architectures but: [root at carme-pld ~]# rpm -q gcc-dirs gcc-dirs-1.0-6.x86_64 [root at carme-pld ~]# poldek -n th -n th-i686 -n th-x32 Loading [pndir]th-arch... Loading [pndir]th-noarch... Loading [pndir]th-i686... Loading [pndir]th-x32... 58789 packages read Loading [rpmdb]/var/lib/rpm... 5621 packages loaded Welcome to the poldek shell mode. Type "help" for help with commands. poldek:/all-avail> install --test gcc-dirs-1.0-6.x32 Processing dependencies... gcc-dirs-1.0-6.x86_64 obsoleted by gcc-dirs-1.0-6.x32 There are 1 package to install, 1 to remove: I gcc-dirs-1.0-6.x32 R gcc-dirs-1.0-6.x86_64 Need to get 3.6KB of archives (3.6KB to download). ^^^^^^^^^^ wants to remove x86_64 - why? lack of colored binary files in package? poldek:/all-avail> just-install --test gcc-dirs-1.0-6.x32 gcc-dirs-1.0-6.x32: equal version installed, skipped Nothing to do poldek:/all-avail> that also doesn't work How is that supposed to work? -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From glen at pld-linux.org Sun Jan 1 23:19:54 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 2 Jan 2017 00:19:54 +0200 Subject: gcc-dirs - how it is supposed to work? In-Reply-To: <201701012136.34304.arekm@maven.pl> References: <201701012136.34304.arekm@maven.pl> Message-ID: <5869808A.9040800@pld-linux.org> On 01.01.2017 22:36, Arkadiusz Mi?kiewicz wrote: > poldek:/all-avail> just-install --test gcc-dirs-1.0-6.x32 > gcc-dirs-1.0-6.x32: equal version installed, skipped > Nothing to do poldek -i should work i.e afaik: just-install and poldek -i behave differently -- glen From glen at pld-linux.org Sun Jan 1 23:21:09 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 2 Jan 2017 00:21:09 +0200 Subject: [packages/zlib] - rel 2; disable asm optimizations; cause segfaults; (are these really better than C code optimizati In-Reply-To: <42be448dacd9c9a5aca26c88c90c16dd4f438f76_refs_heads_master@pld-linux.org> References: <981b9e44ca9a1553ab1d8258b3394e6a6bc5116a_refs_heads_master@pld-linux.org> <42be448dacd9c9a5aca26c88c90c16dd4f438f76_refs_heads_master@pld-linux.org> Message-ID: <586980D5.5060401@pld-linux.org> On 01.01.2017 23:07, arekm wrote: > - rel 2; disable asm optimizations; cause segfaults; (are these really better than C code optimization these days?) cause segfault in what package? in what arches? rather incomplete "bug report". zlib itself has no binaries. -- glen From ed at yen.ipipan.waw.pl Sun Jan 1 23:27:04 2017 From: ed at yen.ipipan.waw.pl (=?utf-8?B?xYF1a2FzeiBNYcWba28=?=) Date: Sun, 01 Jan 2017 23:27:04 +0100 Subject: [packages/zlib] - rel 2; disable asm optimizations; cause segfaults; (are these really better than C code optimizati In-Reply-To: <586980D5.5060401@pld-linux.org> References: <981b9e44ca9a1553ab1d8258b3394e6a6bc5116a_refs_heads_master@pld-linux.org> <42be448dacd9c9a5aca26c88c90c16dd4f438f76_refs_heads_master@pld-linux.org> <586980D5.5060401@pld-linux.org> Message-ID: <3085857.nlEUC8GdJH@laptok> Dnia poniedzia?ek, 2 stycznia 2017 00:21:09 Elan Ruusam?e pisze: > On 01.01.2017 23:07, arekm wrote: > > - rel 2; disable asm optimizations; cause segfaults; (are these > > really better than C code optimization these days?) > cause segfault in what package? in what arches? rather incomplete "bug > report". zlib itself has no binaries. x86-64 -- ?ukasz Ma?ko _o) Lukasz.Masko(at)ipipan.waw.pl /\\ Registered Linux User #61028 _\_V Ubuntu: staroafryka?skie s?owo oznaczaj?ce "Nie umiem zainstalowa? Debiana" From arekm at maven.pl Mon Jan 2 06:22:35 2017 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Mon, 2 Jan 2017 06:22:35 +0100 Subject: gcc-dirs - how it is supposed to work? In-Reply-To: <5869808A.9040800@pld-linux.org> References: <201701012136.34304.arekm@maven.pl> <5869808A.9040800@pld-linux.org> Message-ID: <201701020622.35804.arekm@maven.pl> On Sunday 01 of January 2017, Elan Ruusam?e wrote: > On 01.01.2017 22:36, Arkadiusz Mi?kiewicz wrote: > > poldek:/all-avail> just-install --test gcc-dirs-1.0-6.x32 > > gcc-dirs-1.0-6.x32: equal version installed, skipped > > Nothing to do > > poldek -i should work > > i.e afaik: > just-install and poldek -i behave differently doesn't work: [root at carme-pld ~]# poldek -n th -n th-i686 -n th-x32 -i gcc-dirs-1.0-6.x32 Retrieving th-i686::packages.ndir.md... Retrieving th-i686::packages.ndir.gz... .............................. 100.0% [14.2M (175.7K/s)] Retrieving th-i686::packages.ndir.dscr.gz... .............................. 100.0% [2.1M (2.1M/s)] Retrieving th-x32::packages.ndir.md... Retrieving th-x32::packages.ndir.gz... .............................. 100.0% [10.8M (2.3M/s)] Retrieving th-x32::packages.ndir.dscr.gz... .............................. 100.0% [1.5M (319.3K/s)] Loading [pndir]th-arch... Loading [pndir]th-noarch... Loading [pndir]th-i686... Loading [pndir]th-x32... 58789 packages read gcc-dirs-1.0-6.x32: equal version installed, skipped Nothing to do [root at carme-pld ~]# rpm -q gcc-dirs gcc-dirs-1.0-6.x86_64 -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From arekm at maven.pl Mon Jan 2 06:24:09 2017 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Mon, 2 Jan 2017 06:24:09 +0100 Subject: [packages/zlib] - rel 2; disable asm optimizations; cause segfaults; (are these really better than C code optimizati In-Reply-To: <3085857.nlEUC8GdJH@laptok> References: <981b9e44ca9a1553ab1d8258b3394e6a6bc5116a_refs_heads_master@pld-linux.org> <586980D5.5060401@pld-linux.org> <3085857.nlEUC8GdJH@laptok> Message-ID: <201701020624.09325.arekm@maven.pl> On Sunday 01 of January 2017, ?ukasz Ma?ko wrote: > Dnia poniedzia?ek, 2 stycznia 2017 00:21:09 Elan Ruusam?e pisze: > > On 01.01.2017 23:07, arekm wrote: > > > - rel 2; disable asm optimizations; cause segfaults; (are these > > > really better than C code optimization these days?) > > > > cause segfault in what package? in what arches? rather incomplete "bug > > report". zlib itself has no binaries. > > x86-64 poldek quit 0x00007ffff4e022a0 in LookaheadLess () from /lib64/libz.so.1 (gdb) bt #0 0x00007ffff4e022a0 in LookaheadLess () from /lib64/libz.so.1 #1 0x00007ffff4df6e68 in deflate_fast (s=0x0, flush=0) at deflate.c:1854 #2 0x00007ffff4df7d5d in deflate (strm=strm at entry=0x2332d48, flush=flush at entry=0) at deflate.c:998 #3 0x00007ffff4e016f7 in gz_comp (state=state at entry=0x2332cd0, flush=flush at entry=0) at gzwrite.c:125 #4 0x00007ffff4e01a22 in gz_write (state=0x2332cd0, buf=, len=790) at gzwrite.c:217 #5 0x00007ffff4e01b5e in gzwrite (file=, buf=, len=) at gzwrite.c:269 ... -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From arekm at maven.pl Mon Jan 2 09:46:14 2017 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Mon, 2 Jan 2017 09:46:14 +0100 Subject: gcc-dirs - how it is supposed to work? In-Reply-To: <201701020622.35804.arekm@maven.pl> References: <201701012136.34304.arekm@maven.pl> <5869808A.9040800@pld-linux.org> <201701020622.35804.arekm@maven.pl> Message-ID: <201701020946.14404.arekm@maven.pl> On Monday 02 of January 2017, Arkadiusz Mi?kiewicz wrote: > On Sunday 01 of January 2017, Elan Ruusam?e wrote: > > On 01.01.2017 22:36, Arkadiusz Mi?kiewicz wrote: > > > poldek:/all-avail> just-install --test gcc-dirs-1.0-6.x32 > > > gcc-dirs-1.0-6.x32: equal version installed, skipped > > > Nothing to do > > > > poldek -i should work > > > > i.e afaik: > > just-install and poldek -i behave differently > > doesn't work: > > [root at carme-pld ~]# poldek -n th -n th-i686 -n th-x32 -i gcc-dirs-1.0-6.x32 > Retrieving th-i686::packages.ndir.md... > Retrieving th-i686::packages.ndir.gz... > .............................. 100.0% [14.2M (175.7K/s)] > Retrieving th-i686::packages.ndir.dscr.gz... > .............................. 100.0% [2.1M (2.1M/s)] > Retrieving th-x32::packages.ndir.md... > Retrieving th-x32::packages.ndir.gz... > .............................. 100.0% [10.8M (2.3M/s)] > Retrieving th-x32::packages.ndir.dscr.gz... > .............................. 100.0% [1.5M (319.3K/s)] > Loading [pndir]th-arch... > Loading [pndir]th-noarch... > Loading [pndir]th-i686... > Loading [pndir]th-x32... > 58789 packages read > gcc-dirs-1.0-6.x32: equal version installed, skipped > Nothing to do > [root at carme-pld ~]# rpm -q gcc-dirs > gcc-dirs-1.0-6.x86_64 Maybe creating single noarch package with all directories for all our architectures would be a better solution? -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From glen at pld-linux.org Mon Jan 2 11:05:41 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 2 Jan 2017 12:05:41 +0200 Subject: gcc-dirs - how it is supposed to work? In-Reply-To: <201701020946.14404.arekm@maven.pl> References: <201701012136.34304.arekm@maven.pl> <5869808A.9040800@pld-linux.org> <201701020622.35804.arekm@maven.pl> <201701020946.14404.arekm@maven.pl> Message-ID: <586A25F5.7000908@pld-linux.org> On 02.01.2017 10:46, Arkadiusz Mi?kiewicz wrote: > Maybe creating single noarch package with all directories for all our > architectures would be a better solution? what are you doing anyway? describe the usecase then with big picture given can suggest actually something. -- glen From glen at pld-linux.org Mon Jan 2 11:06:40 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 2 Jan 2017 12:06:40 +0200 Subject: startssl gets banned Message-ID: <586A2630.2030003@pld-linux.org> https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html we used startssl certs in few places. those should be replaced with letsencrypt. -- glen From arekm at maven.pl Mon Jan 2 11:12:23 2017 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Mon, 2 Jan 2017 11:12:23 +0100 Subject: gcc-dirs - how it is supposed to work? In-Reply-To: <586A25F5.7000908@pld-linux.org> References: <201701012136.34304.arekm@maven.pl> <201701020946.14404.arekm@maven.pl> <586A25F5.7000908@pld-linux.org> Message-ID: <201701021112.23289.arekm@maven.pl> On Monday 02 of January 2017, Elan Ruusam?e wrote: > On 02.01.2017 10:46, Arkadiusz Mi?kiewicz wrote: > > Maybe creating single noarch package with all directories for all our > > architectures would be a better solution? > > what are you doing anyway? describe the usecase then with big picture > given can suggest actually something. See first mail "gcc for multilib on x86_64 needs gcc x32 installed. That requires gcc-dirs from both architectures" so I want to install gcc x86_64 and gcc x32 on the same machine. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From glen at pld-linux.org Mon Jan 2 11:48:01 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Mon, 2 Jan 2017 12:48:01 +0200 Subject: gcc-dirs - how it is supposed to work? In-Reply-To: <201701021112.23289.arekm@maven.pl> References: <201701012136.34304.arekm@maven.pl> <201701020946.14404.arekm@maven.pl> <586A25F5.7000908@pld-linux.org> <201701021112.23289.arekm@maven.pl> Message-ID: <586A2FE1.6@pld-linux.org> On 02.01.2017 12:12, Arkadiusz Mi?kiewicz wrote: > "gcc for multilib on x86_64 needs gcc x32 installed. That requires gcc-dirs > from both architectures" > > so I want to install gcc x86_64 and gcc x32 on the same machine. but aren't there multilib packages (ix86 and x32) built from gcc-x86-64 .spec? i.e install "gcc-x32 -n th-x64_64" not "gcc -n th-x32" why do we have *multilib* packages then? perhaps those should be dropped in favour of using builds from specific arch trees? as for the gcc-dirs problem: i would package x32/ix86 dirs in x86_64 gcc-dirs.spec -- glen From arekm at maven.pl Mon Jan 2 11:55:57 2017 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Mon, 2 Jan 2017 11:55:57 +0100 Subject: gcc-dirs - how it is supposed to work? In-Reply-To: <586A2FE1.6@pld-linux.org> References: <201701012136.34304.arekm@maven.pl> <201701021112.23289.arekm@maven.pl> <586A2FE1.6@pld-linux.org> Message-ID: <201701021155.57482.arekm@maven.pl> On Monday 02 of January 2017, Elan Ruusam?e wrote: > On 02.01.2017 12:12, Arkadiusz Mi?kiewicz wrote: > > "gcc for multilib on x86_64 needs gcc x32 installed. That requires > > gcc-dirs from both architectures" > > > > so I want to install gcc x86_64 and gcc x32 on the same machine. > > but aren't there multilib packages (ix86 and x32) built from gcc-x86-64 > .spec? > > i.e install "gcc-x32 -n th-x64_64" not "gcc -n th-x32" > > why do we have *multilib* packages then? Ahh. With -multilib-x32 packages it installs fine. -- Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org ) From glen at pld-linux.org Tue Jan 10 07:55:49 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 10 Jan 2017 08:55:49 +0200 Subject: depsolver stupid Message-ID: <58748575.8080601@pld-linux.org> given such package: $ rpm -qp --requires closure-compiler-20161201-1.noarch.rpm /bin/sh java(ClassDataVersion) >= 49.0 java(ClassDataVersion) >= 50.0 java(ClassDataVersion) >= 51.0 rpmlib(PayloadIsLzma) <= 4.4.6-1 poldek/rpm installs: icedtea6-jre-base, icedtea6-jre , oracle-java8-jre-base resulting java binary from icedtea6 which is incapable of handling 51.0 bytecode: Exception in thread "main" java.lang.UnsupportedClassVersionError: com/google/javascript/jscomp/CommandLineRunner : Unsupported major.minor version 51.0 more detailed log: closure-compiler-20161201-1.noarch marks icedtea6-jre-1.12.4-3.x86_64 (cap java(ClassDataVersion) >= 49.0) icedtea6-jre-1.12.4-3.x86_64 marks icedtea6-jre-base-1.12.4-3.x86_64 (cap icedtea6-jre-base = 1.12.4-3) closure-compiler-20161201-1.noarch marks oracle-java8-jre-base-1.8.0.112-1.x86_64 (cap java(ClassDataVersion) >= 51.0) oracle-java8-jre-base-1.8.0.112-1.x86_64 marks xorg-lib-libX11-1.6.4-1.x86_64 (cap libX11.so.6()(64bit)) to solve this, ClassDataVersion dep should be moved out of -base packages? -- glen From glen at pld-linux.org Tue Jan 10 17:23:15 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 10 Jan 2017 18:23:15 +0200 Subject: ERRORS: rpm.spec In-Reply-To: References: Message-ID: <58750A73.5050604@pld-linux.org> what is this? i didn't know we have hava Java JNI support? ./configure --help outputs: --with-java build RPM with java support --with-jvm=ARG build with JVM embedding library (no) (location path: "external:none") looks like it is not enabled by default? or is? full build log can be obtained from http://buildlogs.pld-linux.org//index.php?dist=th&arch=x32&ok=0&name=rpm&id=33897391-b034-4086-98fd-daf0adcdb290&action=tail On 10.01.2017 18:10, PLD th-x32 builder wrote: > libtool: compile: x86_64-pld-linux-gnux32-g++ -DHAVE_CONFIG_H -I. -I.. -I. -I.. -I../build -I../lib -I../lib -I../rpmdb -I../rpmio -I../misc -I../lua/local -I../lua/local -I../lua -I../lua -DRPM_OS_LINUX=320000 -I/usr/include/db5.2 -I/usr/include/ossp-uuid -I/usr/include/ossp-uuid -O2 -fwrapv -pipe -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4 -fPIC -mtune=generic -march=x86-64 -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -MT rpmjni.lo -MD -MP -MF .deps/rpmjni.Tpo -c rpmjni.cc -fPIC -DPIC -o .libs/rpmjni.o > In file included from /usr/include/c++/6.3.0/stdlib.h:36:0, > from ../system.h:196, > from rpmjni.cc:1: > /usr/include/c++/6.3.0/cstdlib:143:11: error: '::getenv' has not been declared > using ::getenv; > ^~~~~~ > In file included from ../system.h:196:0, > from rpmjni.cc:1: > /usr/include/c++/6.3.0/stdlib.h:62:12: error: 'std::getenv' has not been declared > using std::getenv; > ^~~~~~ > make[4]: *** [Makefile:2146: rpmjni.lo] Error 1 > make[4]: Leaving directory '/tmp/B.1bBTqf/BUILD/rpm-5.4.15/rpmio' > make[3]: *** [Makefile:2187: all-recursive] Error 1 -- glen From n3npq at me.com Tue Jan 10 17:28:33 2017 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 10 Jan 2017 11:28:33 -0500 Subject: ERRORS: rpm.spec In-Reply-To: <58750A73.5050604@pld-linux.org> References: <58750A73.5050604@pld-linux.org> Message-ID: > On Jan 10, 2017, at 11:23 AM, Elan Ruusam?e wrote: > > what is this? > > i didn't know we have hava Java JNI support? Yes, where support == RPM embeds a Java JVM running the bean shell interpreter > > ./configure --help outputs: > --with-java build RPM with java support > --with-jvm=ARG build with JVM embedding library > (no) (location path: > "external:none") > > looks like it is not enabled by default? or is? > Not enabled by default because of ?(no)? Add ?without-java to configure will disable no matter what the default is. 73 de Jeff From glen at pld-linux.org Tue Jan 10 17:35:11 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 10 Jan 2017 18:35:11 +0200 Subject: ERRORS: rpm.spec In-Reply-To: References: <58750A73.5050604@pld-linux.org> Message-ID: <58750D3F.1030407@pld-linux.org> On 10.01.2017 18:28, Jeffrey Johnson wrote: > Add ?without-java to configure will disable no matter what the default is. ./rpmio/Makefile.am compiles rpmjni.cc with no conditions. at least 5.4.15 and seems the gcc error is outside of WITH_JNIEMBED cpp defines. and --without-java seems to be already active: ./config.h:1369:/* #undef WITH_JNIEMBED */ skipping rpmjni.cc from makefile of course yields linking error: ./.libs/librpmio.so: undefined reference to `_rpmjniI' ./.libs/librpmio.so: undefined reference to `_rpmjniPool' collect2: error: ld returned 1 exit status -- glen From n3npq at me.com Tue Jan 10 17:38:43 2017 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 10 Jan 2017 11:38:43 -0500 Subject: ERRORS: rpm.spec In-Reply-To: <58750D3F.1030407@pld-linux.org> References: <58750A73.5050604@pld-linux.org> <58750D3F.1030407@pld-linux.org> Message-ID: <7FC6CCD4-BC0B-40C2-89E1-9B8011A67EBA@me.com> > On Jan 10, 2017, at 11:35 AM, Elan Ruusam?e wrote: > > On 10.01.2017 18:28, Jeffrey Johnson wrote: >> Add ?without-java to configure will disable no matter what the default is. > > ./rpmio/Makefile.am compiles rpmjni.cc with no conditions. at least 5.4.15 > The configure option ?without-java is known to work in CVS and in rpm-5.4.17. Meanwhile: What is the issue here? Do you want embedded java or wish java cleanly disabled? 73 de Jeff From glen at pld-linux.org Tue Jan 10 17:44:43 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 10 Jan 2017 18:44:43 +0200 Subject: ERRORS: rpm.spec In-Reply-To: <7FC6CCD4-BC0B-40C2-89E1-9B8011A67EBA@me.com> References: <58750A73.5050604@pld-linux.org> <58750D3F.1030407@pld-linux.org> <7FC6CCD4-BC0B-40C2-89E1-9B8011A67EBA@me.com> Message-ID: <58750F7B.9040807@pld-linux.org> On 10.01.2017 18:38, Jeffrey Johnson wrote: >> On Jan 10, 2017, at 11:35 AM, Elan Ruusam?e wrote: >> >> On 10.01.2017 18:28, Jeffrey Johnson wrote: >>> Add ?without-java to configure will disable no matter what the default is. >> ./rpmio/Makefile.am compiles rpmjni.cc with no conditions. at least 5.4.15 >> > The configure option ?without-java is known to work in CVS and in rpm-5.4.17. same error as with 5.4.15, rpmjni.cc is compiled unconditionally (checked sources), rpm-5.4.17/rpmio/Makefile.am line 201 so if you try with gcc6 you should be getting same error. > > Meanwhile: > What is the issue here? > Do you want embedded java or wish java cleanly disabled? i wished to rebuild rpm with tiny patch, but gcc errors in totally unrelated file due gcc 6 on builders. https://github.com/pld-linux/rpm/commit/e9576b98b1c166be5e164c20df8d8659bb0431be there shouldn't be any sniff of java/jvm in rpm binary in pld. -- glen From glen at pld-linux.org Tue Jan 10 17:45:54 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 10 Jan 2017 18:45:54 +0200 Subject: ERRORS: rpm.spec In-Reply-To: <7FC6CCD4-BC0B-40C2-89E1-9B8011A67EBA@me.com> References: <58750A73.5050604@pld-linux.org> <58750D3F.1030407@pld-linux.org> <7FC6CCD4-BC0B-40C2-89E1-9B8011A67EBA@me.com> Message-ID: <58750FC2.1070804@pld-linux.org> On 10.01.2017 18:38, Jeffrey Johnson wrote: > What is the issue here? and some more sources (c++) affected: /usr/lib64/ccache/x86_64-pld-linux-gcc -DHAVE_CONFIG_H -I. -I. -I. -I./build -I./lib -I./lib -I./rpmdb -I./rpmio -I./misc -I./lua/local -I./lua/local -I./lua -I./lua -DRPM_OS_LINUX=040134 -I/usr/include/db5.2 -I/usr/include/ossp-uuid -I/usr/include/ossp-uuid -fopenmp -O2 -fwrapv -pipe -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4 -fPIC -march=x86-64 -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -D_GNU_SOURCE -D_REENTRANT -DIAM_RPMBT -DIAM_RPMDB -DIAM_RPMEIU -DIAM_RPMK -DIAM_RPMQV -o rpm.o -c ./rpmqv.cc In file included from /usr/include/c++/6.3.0/stdlib.h:36:0, from ./system.h:196, from ./rpmqv.cc:1: /usr/include/c++/6.3.0/cstdlib:143:11: error: '::getenv' has not been declared using ::getenv; ^~~~~~ In file included from ./system.h:196:0, from ./rpmqv.cc:1: /usr/include/c++/6.3.0/stdlib.h:62:12: error: 'std::getenv' has not been declared using std::getenv; ^~~~~~ make[2]: *** [Makefile:1653: rpm.o] Error 1 make[2]: Leaving directory '/home/users/glen/rpm/BUILD/x86_64-linux/rpm-5.4.15' didn't even know rpm5 requires g++ to compile! -- glen From glen at pld-linux.org Tue Jan 10 17:58:58 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 10 Jan 2017 18:58:58 +0200 Subject: ERRORS: rpm.spec In-Reply-To: <7FC6CCD4-BC0B-40C2-89E1-9B8011A67EBA@me.com> References: <58750A73.5050604@pld-linux.org> <58750D3F.1030407@pld-linux.org> <7FC6CCD4-BC0B-40C2-89E1-9B8011A67EBA@me.com> Message-ID: <587512D2.4060904@pld-linux.org> On 10.01.2017 18:38, Jeffrey Johnson wrote: > The configure option ?without-java is known to work in CVS and in rpm-5.4.17. 5.4.17 compiles here as well (with gcc6), but pld is not ready, some poldek issues and some RPM_I18NSTRING_TYPE issues i do not understand i've written of it somewhere deep in this thread: http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2016-March/024739.html -- glen From n3npq at me.com Tue Jan 10 18:03:25 2017 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 10 Jan 2017 12:03:25 -0500 Subject: ERRORS: rpm.spec In-Reply-To: <58750F7B.9040807@pld-linux.org> References: <58750A73.5050604@pld-linux.org> <58750D3F.1030407@pld-linux.org> <7FC6CCD4-BC0B-40C2-89E1-9B8011A67EBA@me.com> <58750F7B.9040807@pld-linux.org> Message-ID: <24DC5A38-0413-4E5E-A3CD-350DA768D3A2@me.com> > On Jan 10, 2017, at 11:44 AM, Elan Ruusam?e wrote: > > On 10.01.2017 18:38, Jeffrey Johnson wrote: >>> On Jan 10, 2017, at 11:35 AM, Elan Ruusam?e wrote: >>> >>> On 10.01.2017 18:28, Jeffrey Johnson wrote: >>>> Add ?without-java to configure will disable no matter what the default is. >>> ./rpmio/Makefile.am compiles rpmjni.cc with no conditions. at least 5.4.15 >>> >> The configure option ?without-java is known to work in CVS and in rpm-5.4.17. > > same error as with 5.4.15, rpmjni.cc is compiled unconditionally (checked sources), > rpm-5.4.17/rpmio/Makefile.am line 201 > Yes rpmjni.cc is compiled unconditionally so that wrapper symbols are constant in libraries identical to every other rpmXY wrapping. Meanwhile ? if WITH_JNI_EMBED is undefined ? you end up with an empty pool allocation (empty == the JVM is not instantiated, bean shell isn?t loaded, any/all calls return error). > so if you try with gcc6 you should be getting same error. > Currently with CVS $ rpm -q gcc gcc-6.3.1-1.fc26.x86_64 and (AFAIR) gcc6 was used on rpm-5.4.17 (see 5.4.17 INSTALLATION for tools used). Adding #undef WITH_JNIEMBED at top of rpmio/rpmjni.cc SHOULD disable JVM no matter what. The other way to eliminate is to remove the pool deallocations in rpmio/rpmio.c rpmioClean() by commenting out RPMIOPOOL_INTERP_FREE(js) RPMIOPOOL_INTERP_FREE(jni) to address your reported failures skipping rpmjni.cc from makefile of course yields linking error: ./.libs/librpmio.so: undefined reference to `_rpmjniI' ./.libs/librpmio.so: undefined reference to `_rpmjniPool' collect2: error: ld returned 1 exit status as those are just artifacts used to clean up allocations of the empty rpmjni wrapper. >> >> Meanwhile: >> What is the issue here? >> Do you want embedded java or wish java cleanly disabled? > > i wished to rebuild rpm with tiny patch, but gcc errors in totally unrelated file due gcc 6 on builders. > > https://github.com/pld-linux/rpm/commit/e9576b98b1c166be5e164c20df8d8659bb0431be > > there shouldn't be any sniff of java/jvm in rpm binary in pld. > So you don?t want RPM+JAVA. 73 de Jeff From n3npq at me.com Tue Jan 10 18:11:54 2017 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 10 Jan 2017 12:11:54 -0500 Subject: ERRORS: rpm.spec In-Reply-To: <58750FC2.1070804@pld-linux.org> References: <58750A73.5050604@pld-linux.org> <58750D3F.1030407@pld-linux.org> <7FC6CCD4-BC0B-40C2-89E1-9B8011A67EBA@me.com> <58750FC2.1070804@pld-linux.org> Message-ID: <15C76AE0-E702-4A4C-A35D-171534B4D797@me.com> > On Jan 10, 2017, at 11:45 AM, Elan Ruusam?e wrote: > > On 10.01.2017 18:38, Jeffrey Johnson wrote: >> What is the issue here? > and some more sources (c++) affected: > > /usr/lib64/ccache/x86_64-pld-linux-gcc -DHAVE_CONFIG_H -I. -I. -I. -I./build -I./lib -I./lib -I./rpmdb -I./rpmio -I./misc -I./lua/local -I./lua/local -I./lua -I./lua -DRPM_OS_LINUX=040134 -I/usr/include/db5.2 -I/usr/include/ossp-uuid -I/usr/include/ossp-uuid -fopenmp -O2 -fwrapv -pipe -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4 -fPIC -march=x86-64 -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -D_GNU_SOURCE -D_REENTRANT -DIAM_RPMBT -DIAM_RPMDB -DIAM_RPMEIU -DIAM_RPMK -DIAM_RPMQV -o rpm.o -c ./rpmqv.cc > In file included from /usr/include/c++/6.3.0/stdlib.h:36:0, > from ./system.h:196, > from ./rpmqv.cc:1: > /usr/include/c++/6.3.0/cstdlib:143:11: error: '::getenv' has not been declared > using ::getenv; > ^~~~~~ > In file included from ./system.h:196:0, > from ./rpmqv.cc:1: > /usr/include/c++/6.3.0/stdlib.h:62:12: error: 'std::getenv' has not been declared > using std::getenv; > ^~~~~~ > make[2]: *** [Makefile:1653: rpm.o] Error 1 > make[2]: Leaving directory '/home/users/glen/rpm/BUILD/x86_64-linux/rpm-5.4.15' > > > didn't even know rpm5 requires g++ to compile! > Um, rpmqv.cc compilation with g++ has been in place for several (like 5 years? I forget) years to ensure that *.c and *.cc compiled objects can be freely linked together. You likely can still compile rpmqv.c as C only with some straight forward Makefile.am patching, but you?re on your own there: I wish to be able to use C++ on rpm to ensure that rpm includes and libraries are explicitly tested as C++ ready. hth 73 de Jeff > -- > glen > > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From n3npq at me.com Tue Jan 10 18:46:35 2017 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 10 Jan 2017 12:46:35 -0500 Subject: ERRORS: rpm.spec In-Reply-To: <587512D2.4060904@pld-linux.org> References: <58750A73.5050604@pld-linux.org> <58750D3F.1030407@pld-linux.org> <7FC6CCD4-BC0B-40C2-89E1-9B8011A67EBA@me.com> <587512D2.4060904@pld-linux.org> Message-ID: <1FD7E20A-1FF3-4DA0-9FA7-069EFAE44592@me.com> > On Jan 10, 2017, at 11:58 AM, Elan Ruusam?e wrote: > > On 10.01.2017 18:38, Jeffrey Johnson wrote: >> The configure option ?without-java is known to work in CVS and in rpm-5.4.17. > > 5.4.17 compiles here as well (with gcc6), Good. > but pld is not ready, some poldek issues and some RPM_I18NSTRING_TYPE issues i do not understand > > i've written of it somewhere deep in this thread: > http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2016-March/024739.html > You are going to have (at least) the following speed bumps if you continue back porting changes to rpm-5.4.15 to use newer external libraries: 1) using db-6.1.26/db-6.2.23 (db-6.1.23 and earlier ?work?) you will need a patch to db: http://rpm5.org/community/rpm-devel/5690.html 2) openssl-1.1.x you will need rpmio/rpmssl.c from the rpm-5_4 branch in CVS (and may need to disable FIPS 140-2 by commenting out xx = FIPS_mode_set(1); Then there are the known and well-discussed issues related to RPM_I18NSTRING_TYPE removal and RSA fingerprints. I will (at least) send the patch to re-add RPM_I18NSTRING_TYPE to pld-devel@ when I remove the data type. The RPM_I18NSTRING_TYPE has always been broken in RPM because the type is sometimes a scalar, and sometimes a vector, depending on the desired access context. The RSA fingerprint change is/was a bug in rpm-5.4.15 (and all previous versions), and ?legacy compatibility" would involve support for non-conformant OpenPGP signatures/pubkeys. hth 73 de Jeff From glen at pld-linux.org Tue Jan 10 18:56:34 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 10 Jan 2017 19:56:34 +0200 Subject: ERRORS: rpm.spec In-Reply-To: <1FD7E20A-1FF3-4DA0-9FA7-069EFAE44592@me.com> References: <58750A73.5050604@pld-linux.org> <58750D3F.1030407@pld-linux.org> <7FC6CCD4-BC0B-40C2-89E1-9B8011A67EBA@me.com> <587512D2.4060904@pld-linux.org> <1FD7E20A-1FF3-4DA0-9FA7-069EFAE44592@me.com> Message-ID: <58752052.8040600@pld-linux.org> On 10.01.2017 19:46, Jeffrey Johnson wrote: > I will (at least) send the patch to re-add RPM_I18NSTRING_TYPE to pld-devel@ > when I remove the data type. The RPM_I18NSTRING_TYPE has always been broken in RPM > because the type is sometimes a scalar, and sometimes a vector, depending on the desired > access context. (without understanding what the RPM_I18NSTRING_TYPE problem or change is) is it possible with simple #define get same behaviour that 5.4.15 has? from your post i understand RPM_I18NSTRING_TYPE is still there in 5.4.16/5.4.17 -- glen From n3npq at me.com Tue Jan 10 19:09:48 2017 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 10 Jan 2017 13:09:48 -0500 Subject: ERRORS: rpm.spec In-Reply-To: <58752052.8040600@pld-linux.org> References: <58750A73.5050604@pld-linux.org> <58750D3F.1030407@pld-linux.org> <7FC6CCD4-BC0B-40C2-89E1-9B8011A67EBA@me.com> <587512D2.4060904@pld-linux.org> <1FD7E20A-1FF3-4DA0-9FA7-069EFAE44592@me.com> <58752052.8040600@pld-linux.org> Message-ID: <695AB9F4-78EF-476B-BB2F-C75D8EFD9530@me.com> > On Jan 10, 2017, at 12:56 PM, Elan Ruusam?e wrote: > > On 10.01.2017 19:46, Jeffrey Johnson wrote: >> I will (at least) send the patch to re-add RPM_I18NSTRING_TYPE to pld-devel@ >> when I remove the data type. The RPM_I18NSTRING_TYPE has always been broken in RPM >> because the type is sometimes a scalar, and sometimes a vector, depending on the desired >> access context. > > (without understanding what the RPM_I18NSTRING_TYPE problem or change is) > is it possible with simple #define get same behaviour that 5.4.15 has? > ATM (and through rpm-5.4.17), the RPM_I18NSTRING_TYPE removal is conditioned by a #define at the bottom of system.h. PLD (likely) wants this /** * Eliminate RPM_I18NSTRING_TYPE. */ #define SUPPORT_I18NSTRING_TYPE 1 (aside) And while looking at system.h, I am reminded of the well-discussed removal of ?nosignatures/?nodigests in order to support MANDATORY signature verification in RPM. PLD (likely) wants this /** * Eliminate signature/digest disablers. */ #define SUPPORT_NOSIGNATURES 1 #define SUPPORT_NODIGESTS 1 Patches to re-add the code of both of the above will be made available when the code is removed (before rpm-5.4.18 is released). Through rpm-5.4.17, RPM has been tested with/without those defines and is known to ?work? with either setting. The remaining step is to commit RPM to a simpler release pathway by removing the code. > from your post i understand RPM_I18NSTRING_TYPE is still there in 5.4.16/5.4.17 > Yes. 73 de Jeff From glen at pld-linux.org Tue Jan 10 20:36:24 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 10 Jan 2017 21:36:24 +0200 Subject: pld rpm 5.4.17 Message-ID: <587537B8.50603@pld-linux.org> not cool. $ rpm -q rpm BDB0056 DB->cursor: DB_READ_COMMITTED, DB_READ_UNCOMMITTED and DB_RMW require locking error: db3copen:db3.c:1470: db->cursor(22): Invalid argument BDB0056 DB->cursor: DB_READ_COMMITTED, DB_READ_UNCOMMITTED and DB_RMW require locking error: db3copen:db3.c:1470: db->cursor(22): Invalid argument BDB0630 DB_THREAD mandates memory allocation flag on primary key DBT error: db3cpget:db3.c:1568: db->pget(22): Invalid argument error: error(22) getting keys from Nvra index error: error(1) getting records from Nvra index package rpm is not installed luckily was able to downgrade. and even blink information was preserved: $ rpm -q rpm --blink rpm-5.4.15-38.x86_64.rpm <= rpm-5.4.17-0.6.x86_64.rpm -- glen From n3npq at me.com Tue Jan 10 20:49:12 2017 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 10 Jan 2017 14:49:12 -0500 Subject: pld rpm 5.4.17 In-Reply-To: <587537B8.50603@pld-linux.org> References: <587537B8.50603@pld-linux.org> Message-ID: > On Jan 10, 2017, at 2:36 PM, Elan Ruusam?e wrote: > > not cool. > You (likely) have misbuilt rpm somehow, likely by picking up #include in /usr/include rather than the version specific db.h using -I/usr/include/dbXY. > $ rpm -q rpm > BDB0056 DB->cursor: DB_READ_COMMITTED, DB_READ_UNCOMMITTED and DB_RMW require locking > error: db3copen:db3.c:1470: db->cursor(22): Invalid argument > BDB0056 DB->cursor: DB_READ_COMMITTED, DB_READ_UNCOMMITTED and DB_RMW require locking > error: db3copen:db3.c:1470: db->cursor(22): Invalid argument > BDB0630 DB_THREAD mandates memory allocation flag on primary key DBT > error: db3cpget:db3.c:1568: db->pget(22): Invalid argument > error: error(22) getting keys from Nvra index > error: error(1) getting records from Nvra index > package rpm is not installed > > luckily was able to downgrade. > By explicit intent, you have copious spewage identifying the flaw immediately *shrug*. What version of Berkeley DB are you intending? Did you run sed across configure to change the 2 strings that look like (from configure.ac, but the patterns will persist into configure) DBXY=db62 db-6.2 ? All RPM releases are tied to the latest available Berkeley DB at the time of release, which (for rpm-5.4.17 iirc) was db-6.1.23. 73 de Jeff From n3npq at me.com Tue Jan 10 21:00:59 2017 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 10 Jan 2017 15:00:59 -0500 Subject: pld rpm 5.4.17 In-Reply-To: References: <587537B8.50603@pld-linux.org> Message-ID: <46A1D83A-8E47-4910-AF48-D0F579DADB3A@me.com> > On Jan 10, 2017, at 2:49 PM, Jeffrey Johnson wrote: > >> >> On Jan 10, 2017, at 2:36 PM, Elan Ruusam?e > wrote: >> >> not cool. >> > > You (likely) have misbuilt rpm somehow, likely by picking up > #include > in /usr/include rather than the version specific db.h using -I/usr/include/dbXY. > >> $ rpm -q rpm >> BDB0056 DB->cursor: DB_READ_COMMITTED, DB_READ_UNCOMMITTED and DB_RMW require locking >> error: db3copen:db3.c:1470: db->cursor(22): Invalid argument >> BDB0056 DB->cursor: DB_READ_COMMITTED, DB_READ_UNCOMMITTED and DB_RMW require locking >> error: db3copen:db3.c:1470: db->cursor(22): Invalid argument >> BDB0630 DB_THREAD mandates memory allocation flag on primary key DBT >> error: db3cpget:db3.c:1568: db->pget(22): Invalid argument >> error: error(22) getting keys from Nvra index >> error: error(1) getting records from Nvra index >> package rpm is not installed >> Another possibility is that your Berkeley DB needs locking: my guess above is based on experience only, and its impossible to diagnose without more info. (aside) db3.c is known to work with many many versions of Berkeley DB, and there has been no change in the rpmdb code for 5+ years. YMMV (and clearly does). 73 de Jeff From glen at pld-linux.org Tue Jan 10 22:50:25 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 10 Jan 2017 23:50:25 +0200 Subject: pld rpm 5.4.17 In-Reply-To: References: <587537B8.50603@pld-linux.org> Message-ID: <58755721.1050004@pld-linux.org> On 10.01.2017 21:49, Jeffrey Johnson wrote: > What version of Berkeley DB are you intending? pld still intends to use db5.2, not changing db version in "patch" release of rpm (5.4.15->5.4.17) will check the build logs tomorrow. i sent it also to pld builders, so you can inspect the logs if you wish. but do note that is not the same build i had problem with, so it's not definitive answer to everything https://srcbuilder.pld-linux.org/th/queue.html#155086 -- glen From n3npq at me.com Tue Jan 10 23:33:08 2017 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 10 Jan 2017 17:33:08 -0500 Subject: pld rpm 5.4.17 In-Reply-To: <58755721.1050004@pld-linux.org> References: <587537B8.50603@pld-linux.org> <58755721.1050004@pld-linux.org> Message-ID: > On Jan 10, 2017, at 4:50 PM, Elan Ruusam?e wrote: > > On 10.01.2017 21:49, Jeffrey Johnson wrote: >> What version of Berkeley DB are you intending? > > pld still intends to use db5.2, not changing db version in "patch" release of rpm (5.4.15->5.4.17) > db5.2 should be fine. Better imho would be to add db-6.1.23 or db-6.1.26/db-6.2.23(+PATCH) for RPM-only use, relatively easy to add parallel to ?system db? since rpm uses db versioned paths. *shrug* Remember: you will have to run something like sed -e ?s/db61/db52/g? -e ?s/db-6.1/db-5.2/g? across the rpm-5.4.17 distributed configure. You will also need to set the #define?s in system.h. > will check the build logs tomorrow. > > i sent it also to pld builders, so you can inspect the logs if you wish. > > but do note that is not the same build i had problem with, so it's not definitive answer to everything > https://srcbuilder.pld-linux.org/th/queue.html#155086 > That?s the build queue? Ok, will look later. 73 de Jeff From glen at pld-linux.org Thu Jan 12 18:03:46 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Thu, 12 Jan 2017 19:03:46 +0200 Subject: pld rpm 5.4.17 In-Reply-To: References: <587537B8.50603@pld-linux.org> <58755721.1050004@pld-linux.org> Message-ID: <5877B6F2.20609@pld-linux.org> On 11.01.2017 00:33, Jeffrey Johnson wrote: > db5.2 should be fine. Better imho would be to add db-6.1.23 or db-6.1.26/db-6.2.23(+PATCH) for RPM-only use, > relatively easy to add parallel to ?system db? since rpm uses db versioned paths.*shrug* pld "system" db version is 5.3, so that's not the issue here. i'm still against updating db version in rpm patchlevel update (5.4.x -> 5.4.y), but th release manager may override this opinion. -- glen From glen at pld-linux.org Thu Jan 12 18:05:00 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Thu, 12 Jan 2017 19:05:00 +0200 Subject: pld rpm 5.4.17 In-Reply-To: References: <587537B8.50603@pld-linux.org> <58755721.1050004@pld-linux.org> Message-ID: <5877B73C.50401@pld-linux.org> On 11.01.2017 00:33, Jeffrey Johnson wrote: >> >i sent it also to pld builders, so you can inspect the logs if you wish. >> > >> >but do note that is not the same build i had problem with, so it's not definitive answer to everything >> >https://srcbuilder.pld-linux.org/th/queue.html#155086 >> > > That?s the build queue? Ok, will look later. it's link to the specific build i was referring to. each architecture link can be followed from there. also the link wont work forever. older jobs get pruned from that view. -- glen From n3npq at me.com Thu Jan 12 18:20:05 2017 From: n3npq at me.com (Jeffrey Johnson) Date: Thu, 12 Jan 2017 12:20:05 -0500 Subject: pld rpm 5.4.17 In-Reply-To: <5877B73C.50401@pld-linux.org> References: <587537B8.50603@pld-linux.org> <58755721.1050004@pld-linux.org> <5877B73C.50401@pld-linux.org> Message-ID: <474288BB-B55D-4AF7-A36F-843E97A45A82@me.com> > On Jan 12, 2017, at 12:05 PM, Elan Ruusam?e wrote: > > On 11.01.2017 00:33, Jeffrey Johnson wrote: >>> >i sent it also to pld builders, so you can inspect the logs if you wish. >>> > >>> >but do note that is not the same build i had problem with, so it's not definitive answer to everything >>> >https://srcbuilder.pld-linux.org/th/queue.html#155086 >>> > >> That?s the build queue? Ok, will look later. > it's link to the specific build i was referring to. each architecture link can be followed from there. > rpm-5.4.17 seemed to build when I looked. Hmmm: generating the documentation needs work, todo++. I have been assuming that no-one reads rpm API documentation these days. FWIW, you can add a simple %check to fail the build immediately if there are issues: %check make -C tests check-init check-pubkeys That?s usually enough to trigger a build failure and takes a minute or so to run. Otherwise: Did rpm-5.4.17 build correctly? 73 de Jeff From glen at pld-linux.org Thu Jan 12 18:51:03 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Thu, 12 Jan 2017 19:51:03 +0200 Subject: pld rpm 5.4.17 In-Reply-To: <474288BB-B55D-4AF7-A36F-843E97A45A82@me.com> References: <587537B8.50603@pld-linux.org> <58755721.1050004@pld-linux.org> <5877B73C.50401@pld-linux.org> <474288BB-B55D-4AF7-A36F-843E97A45A82@me.com> Message-ID: <5877C207.30604@pld-linux.org> On 12.01.2017 19:20, Jeffrey Johnson wrote: > Otherwise: > Did rpm-5.4.17 build correctly? yes. otherwise i wouldn't able to get the db error, right? :) anyway, i haven't looked yet the logs if proper db was linked, but i'm sure it was because there was no other db version available at build time. but need to check to be sure. -- glen From n3npq at me.com Thu Jan 12 19:01:59 2017 From: n3npq at me.com (Jeffrey Johnson) Date: Thu, 12 Jan 2017 13:01:59 -0500 Subject: pld rpm 5.4.17 In-Reply-To: <5877C207.30604@pld-linux.org> References: <587537B8.50603@pld-linux.org> <58755721.1050004@pld-linux.org> <5877B73C.50401@pld-linux.org> <474288BB-B55D-4AF7-A36F-843E97A45A82@me.com> <5877C207.30604@pld-linux.org> Message-ID: <91BE9497-16CE-4B2B-AF42-F64233682F1D@me.com> > On Jan 12, 2017, at 12:51 PM, Elan Ruusam?e wrote: > > On 12.01.2017 19:20, Jeffrey Johnson wrote: >> Otherwise: >> Did rpm-5.4.17 build correctly? > yes. otherwise i wouldn't able to get the db error, right? :) > > anyway, i haven't looked yet the logs if proper db was linked, but i'm sure it was because there was no other db version available at build time. but need to check to be sure. > The issue has to do with explicit -I/usr/include/dbXY in CFLAGS and implicit /usr/include for #include when /usr/include/dbXY is not present or is empty and ?system db? != dbXY. The wrong (with different #define values) can be included, leading to very bizarre/scary rpmdb failures at run time. A proper fix to limit the include search somehow is a huge PITA (and so I haven?t bothered). But I see rpmdb issue(s) frequently while developing RPM on various platforms that aren?t yet setup correctly, sigh. 73 de Jeff From qboosh at pld-linux.org Thu Jan 12 20:26:52 2017 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Thu, 12 Jan 2017 20:26:52 +0100 Subject: pld rpm 5.4.17 In-Reply-To: <91BE9497-16CE-4B2B-AF42-F64233682F1D@me.com> References: <587537B8.50603@pld-linux.org> <58755721.1050004@pld-linux.org> <5877B73C.50401@pld-linux.org> <474288BB-B55D-4AF7-A36F-843E97A45A82@me.com> <5877C207.30604@pld-linux.org> <91BE9497-16CE-4B2B-AF42-F64233682F1D@me.com> Message-ID: <20170112192652.GA3305@mail> By the way - are there any plans to implement fcaps in rpm5? (like in rpm.org since 4.7.0) e.g. mtr.spec looks sad with %attr(4755,root,root) %{_bindir}/mtr instead of %caps(cap_net_raw=ep)... -- Jakub Bogusz http://qboosh.pl/ From n3npq at me.com Thu Jan 12 20:58:51 2017 From: n3npq at me.com (Jeffrey Johnson) Date: Thu, 12 Jan 2017 14:58:51 -0500 Subject: pld rpm 5.4.17 In-Reply-To: <20170112192652.GA3305@mail> References: <587537B8.50603@pld-linux.org> <58755721.1050004@pld-linux.org> <5877B73C.50401@pld-linux.org> <474288BB-B55D-4AF7-A36F-843E97A45A82@me.com> <5877C207.30604@pld-linux.org> <91BE9497-16CE-4B2B-AF42-F64233682F1D@me.com> <20170112192652.GA3305@mail> Message-ID: > On Jan 12, 2017, at 2:26 PM, Jakub Bogusz wrote: > > By the way - are there any plans to implement fcaps in rpm5? > (like in rpm.org since 4.7.0) > > e.g. mtr.spec looks sad with > %attr(4755,root,root) %{_bindir}/mtr > instead of %caps(cap_net_raw=ep)? > The problem I have with capabilities in RPM attached to files is how to represent the values. Adding an entire array for every file in order to attach a couple of values is rather overkill. Even if the tag is optional (which has other runtime issues testing return codes everywhere), its kinda hard (IMHO) to justify the bloat for the handful of files that would benefit from capabilities. There?s some subtle hackery that could be done for efficiency, but the hackery would most definitely be incompatible with the existing rpm.org representation. And if capabilities are implemented, then act?s and xattr?s (beyond SELinux) likely should be implemented too. (aside) What RPM needs is a way to handle sparse arrays, with memorization for repeated values. This is one of (of many) constraints on the existing header format. I am currently looking at flatcc flat buffers as a possible replacement for existing Headers, and there is some hope that flat buffers can/will handle * a sparse array (for capabilities and other sparse arrays), * a mapping (to replace RPM_I18NSTRING_TYPE removal) * an array of RPM_BIN_TYPE (so that file digests don?t need to be represented in hex) but I?m some months away from attempting flat buffers in ?production? RPM. The rpm.org syntax could be parsed pretty easily, with associated ignore/warning/error messages if that helps. However implementing the syntax without adding the values to a header likely creates False Hope for users, and I?m trying to resist adding bloat/change everywhere to support capabilities as a ?feature?. Does my explanation make sense? I?m certainly willing to discuss further if you wish, can easily generate a patch for you (but I?d like not to maintain that patch upstream, ?legacy compatibility? usually takes years to undo or fix correctly in RPM. AFAIK there?s only a handful of files that benefit from capabilities (but I haven?t looked recently: for all I know there may be tens of thousands of files that now use/need capabilities these days). FWIW: handling capabilities (and acls/xattrs) within %post/%preun/%verifyscript scriptlets isn?t all *THAT* ugly. JMHO, YMMV. From gotar at polanet.pl Thu Jan 12 22:23:22 2017 From: gotar at polanet.pl (Tomasz Pala) Date: Thu, 12 Jan 2017 22:23:22 +0100 Subject: pld rpm 5.4.17 In-Reply-To: References: <587537B8.50603@pld-linux.org> <58755721.1050004@pld-linux.org> <5877B73C.50401@pld-linux.org> <474288BB-B55D-4AF7-A36F-843E97A45A82@me.com> <5877C207.30604@pld-linux.org> <91BE9497-16CE-4B2B-AF42-F64233682F1D@me.com> <20170112192652.GA3305@mail> Message-ID: <20170112212322.GA18424@polanet.pl> On Thu, Jan 12, 2017 at 14:58:51 -0500, Jeffrey Johnson wrote: > AFAIK there???s only a handful of files that benefit from capabilities (but I haven???t looked recently: for all I know For the start - almost every SUID binary. Then - binaries that are currently run with EUID==root only to provide CAP_NET_BIND_SERVICE. While Linux capabilities are often referred as 'broken' (many of the cases are covered only by CAP_SYS_ADMIN), the counterpart you've mentioned, xattrs, are much more widely usable. Some of the caps security (i.e. dropping unneeded ones) can be handled by systemd units, but since they are in general upstream-provided, we shouldn't mess with them here. This won't help for overrided units anyway. > FWIW: handling capabilities (and acls/xattrs) within %post/%preun/%verifyscript scriptlets isn???t > all *THAT* ugly. JMHO, YMMV. It doesn't need to be *THAT* ugly; it is 'so' ugly, that nobody uses them in such way. -- Tomasz Pala From n3npq at me.com Fri Jan 13 21:52:36 2017 From: n3npq at me.com (Jeffrey Johnson) Date: Fri, 13 Jan 2017 15:52:36 -0500 Subject: pld rpm 5.4.17 In-Reply-To: <20170112212322.GA18424@polanet.pl> References: <587537B8.50603@pld-linux.org> <58755721.1050004@pld-linux.org> <5877B73C.50401@pld-linux.org> <474288BB-B55D-4AF7-A36F-843E97A45A82@me.com> <5877C207.30604@pld-linux.org> <91BE9497-16CE-4B2B-AF42-F64233682F1D@me.com> <20170112192652.GA3305@mail> <20170112212322.GA18424@polanet.pl> Message-ID: <063018B3-95A8-455B-B3B1-D71207093E40@me.com> > On Jan 12, 2017, at 4:23 PM, Tomasz Pala wrote: > > On Thu, Jan 12, 2017 at 14:58:51 -0500, Jeffrey Johnson wrote: > >> AFAIK there???s only a handful of files that benefit from capabilities (but I haven???t looked recently: for all I know > Hmmm ? that seems to be about the same state of affairs when I last looked at capabilities. > For the start - almost every SUID binary. Then - binaries that are Ok, so linux wishes capabilites rather than setuid. IMHO a better implementation (rather than adding spec file syntax and RPMTAG_* to packages), might be to test RPMTAG_FILEMODES for the setuid (and setgid) and add a capability dynamically instead of setuid/setgid. Some benefits of above (JMHO) are 1) switching to capabilities becomes a per-system, not a per-package, policy. If implemented correctly, a popt alias for rpm could be added to switch between capabilities <-> setuid/setgid even for already installed packages dynamically. 2) no bloat in package tag content, no ?legacy compatibility? issues with rpmlib() tracking etc. The costs are 1) insufficiently general (but handles ?almost every SUID/SGID case instantly) 2) invisible implicit behavior invisible in tag content and depsolver metadata. > currently run with EUID==root only to provide CAP_NET_BIND_SERVICE. Last I checked, CAP_NET_BIND_SERVICE protected raw sockets in ping* and a handful of other programs. > While Linux capabilities are often referred as 'broken' (many of the > cases are covered only by CAP_SYS_ADMIN), the counterpart you've > mentioned, xattrs, are much more widely usable. > Hmmm ? (I.ve not looked) CAP_SYS_ADMIN is a way to control access to a class of programs that users should NOT be executing (and I?d agree that batter?s are a far better implementation: but RPM cannot dictate implementations, and would need to support all of capabilities/xattrs/acls/? equally well, broken or not. > Some of the caps security (i.e. dropping unneeded ones) can be handled > by systemd units, but since they are in general upstream-provided, we > shouldn't mess with them here. This won't help for overrided units > anyway. > This affects RPM only because of scriptets being run by the installer. E.g. one might expect RPM to drop privileges after forking before running scriptlets or adding CAP_SYS_ADMIN to run programs in the script let that would normally not need to be run by a user. Yes, inheritance across fork already takes care of most of the issues, but I?m sure there are some who would like to limit what RPM can do while running scriptlets. >> FWIW: handling capabilities (and acls/xattrs) within %post/%preun/%verifyscript scriptlets isn???t >> all *THAT* ugly. JMHO, YMMV. > > It doesn't need to be *THAT* ugly; it is 'so' ugly, that nobody uses them in such way. > The SUID/SGID <-> capabilities is entirely invisible: UGLY is in the eye of the beholder, and usually what you cannot see won?t bother you ;-) JMHO, YMMV, etc etc 73 de Jeff From baggins at pld-linux.org Sun Jan 22 11:19:54 2017 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sun, 22 Jan 2017 11:19:54 +0100 Subject: snapshot 2016 Message-ID: <20170122101954.GA6661@tachikoma> Hi, 2016 snapshot will be a bit late, I plan on doing it around 27-29 January based on current contents of main + ready. If there is anything you want included, now it's the time to get thing cleaned/added. -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From baggins at pld-linux.org Sun Jan 29 13:15:20 2017 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sun, 29 Jan 2017 13:15:20 +0100 Subject: Th 2016 snapshot released Message-ID: <20170129121519.GA19177@tachikoma> Th 2016 snapshot has been released, see the announcment on http://www.pld-linux.org/ for details. -- Jan R?korajski | PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ From glen at pld-linux.org Sun Jan 29 16:06:09 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Sun, 29 Jan 2017 17:06:09 +0200 Subject: [packages/php-pear-PEAR] - up to 1.10.1; Console_Getopt to 1.4.1; Structures_Graph to 1.1.1 In-Reply-To: <810752ac0789f4ce6eccd7405e37542d58d025a5_refs_heads_master@pld-linux.org> References: <810752ac0789f4ce6eccd7405e37542d58d025a5_refs_heads_master@pld-linux.org> Message-ID: <588E04E1.8020000@pld-linux.org> On 29.01.2017 09:23, arekm wrote: > Author: Arkadiusz Mi?kiewicz > Date: Sun Jan 29 08:23:25 2017 +0100 > > - up to 1.10.1; Console_Getopt to 1.4.1; Structures_Graph to 1.1.1 this version increased minimum php requirement. please update dependencies in package as well! that's why it's update was postponed for so long time. -- glen From glen at pld-linux.org Tue Jan 31 13:40:59 2017 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=c3=a4e?=) Date: Tue, 31 Jan 2017 14:40:59 +0200 Subject: [packages/bacula] Up to 7.4.4 In-Reply-To: <09ca754c3005e4f0f7b4a7909b5ad774ac7b9355_refs_heads_master@pld-linux.org> References: <77a4fc1f5ac032936982edb75eddf0789eba7ae7_refs_heads_master@pld-linux.org> <09ca754c3005e4f0f7b4a7909b5ad774ac7b9355_refs_heads_master@pld-linux.org> Message-ID: <589085DB.7020109@pld-linux.org> On 31.01.2017 11:41, mmazur wrote: > Name: bacula > -Version: 7.0.5 > -Release: 2 > +Version: 7.4.4 > +Release: 1 > License: AGPL v3 .. > @@ -495,7 +495,6 @@ touch $RPM_BUILD_ROOT/var/log/bacula/log > # 5.0 -> 5.2 : 12_to_14 > install -p updatedb/update_*_tables_10_to_11 $RPM_BUILD_ROOT%{_libexecdir}/%{name} > install -p updatedb/update_*_tables_11_to_12 $RPM_BUILD_ROOT%{_libexecdir}/%{name} > -install -p updatedb/update_*_tables_12_to_14 $RPM_BUILD_ROOT%{_libexecdir}/%{name} > so it's a downgrade? or why no models upgrade path? -- glen From mariusz.g.mazur at gmail.com Tue Jan 31 16:19:34 2017 From: mariusz.g.mazur at gmail.com (Mariusz Mazur) Date: Tue, 31 Jan 2017 16:19:34 +0100 Subject: [packages/bacula] Up to 7.4.4 In-Reply-To: <589085DB.7020109@pld-linux.org> References: <77a4fc1f5ac032936982edb75eddf0789eba7ae7_refs_heads_master@pld-linux.org> <09ca754c3005e4f0f7b4a7909b5ad774ac7b9355_refs_heads_master@pld-linux.org> <589085DB.7020109@pld-linux.org> Message-ID: Don't know, those files just aren't there anymore. 2017-01-31 13:40 GMT+01:00 Elan Ruusam?e : > On 31.01.2017 11:41, mmazur wrote: >> >> Name: bacula >> -Version: 7.0.5 >> -Release: 2 >> +Version: 7.4.4 >> +Release: 1 >> License: AGPL v3 > > > .. >> >> @@ -495,7 +495,6 @@ touch $RPM_BUILD_ROOT/var/log/bacula/log >> # 5.0 -> 5.2 : 12_to_14 >> install -p updatedb/update_*_tables_10_to_11 >> $RPM_BUILD_ROOT%{_libexecdir}/%{name} >> install -p updatedb/update_*_tables_11_to_12 >> $RPM_BUILD_ROOT%{_libexecdir}/%{name} >> -install -p updatedb/update_*_tables_12_to_14 >> $RPM_BUILD_ROOT%{_libexecdir}/%{name} >> > > so it's a downgrade? or why no models upgrade path? > > -- > glen > > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en