From gotar at polanet.pl  Fri Jan  2 11:06:05 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Fri, 2 Jan 2015 11:06:05 +0100
Subject: [packages/grep] - move from GREP_OPTIONS environmental
 variable to alias due to its obsolescence
In-Reply-To: <5488419D.7050801@jajcus.net>
References: <23ca4364a0c6cf68fca3432a517ec04a28c22e22_refs_heads_master@pld-linux.org>
 <274761483d541b779ab9135532aecf8aadc550e8_refs_heads_master@pld-linux.org>
 <54861430.3040103@pld-linux.org>
 <201412101246.26382.arekm@maven.pl> <5488419D.7050801@jajcus.net>
Message-ID: <20150102100605.GA24730@polanet.pl>

On Wed, Dec 10, 2014 at 13:50:37 +0100, Jacek Konieczny wrote:

> Implementing any such non-standard behaviour in the distribution is a
> very bad idea. Not only we make the shell load ages to initialize
> features most users don't even know about, but we may find great

1. Having zsh one can precompile shell scripts using zcompile (builtin).
2. How about colorls.sh from coreutils? I see this commit more harmful:

http://git.pld-linux.org/gitweb.cgi?p=packages/coreutils.git;a=commitdiff;h=e8b91122bfecdc518241fc478b8123d0501a9318

3. WTF is that?! It alternates entire output!

alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'

$  which ls
ls='ls --color=tty'
        /bin/ls
$  \which ls
ls: aliased to ls --color=tty

Especially --show-dot and --show-tilde are potentially dangerous (noone
should put directory starting with a dot into PATH and noone should see
automated relative paths to binaries, which copy&pasted into some script
might become something entirely different). This comes from which
manpage, but apparently it's author ignores security implications.

(and another zsh hint: one get path by prepending binary with =)

> fuck-ups years later, like this one:
> 
> http://seclists.org/fulldisclosure/2014/Nov/74

There is no fuckup, otherwise you should consider a bug in every
tool aggregating application helpers (mailcap, mc, firefox) and every
raw terminal output (cat). This is not a bit less secure than calling
these tools directly (if someone wants to see contents of cab file, he
will end up calling cabextract anyway), it might be more secure as it
eventually pipes output to less (which might prevent some control
characters from executing malicious code using invoking terminal).

What next, removing xdg-open and entire desktop-entry? Auditing every
image on a web page and every PDF to read before rendering contents?
This is not a way to go, if someone is paranoid he should not run ANY
tool on not-sandboxed environment, after all he might be targetted by
NSA with some 0-days. Breaking application handlers stream won't help in
any way, having some "ancient and obscure" compressed file one WANTS to
see won't make him magically write his own parser, audit appropriate
tool or any other action increasing security, unless we remove these
tools from repo. The solution similar to removing firefox and telling
people to use wget+more to read web pages.

-- 
Tomasz Pala <gotar at pld-linux.org>


From gotar at polanet.pl  Fri Jan  2 11:10:50 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Fri, 2 Jan 2015 11:10:50 +0100
Subject: [packages/grep] - move from GREP_OPTIONS environmental
 variable to alias due to its obsolescence
In-Reply-To: <54897180.7000409@pld-linux.org>
References: <23ca4364a0c6cf68fca3432a517ec04a28c22e22_refs_heads_master@pld-linux.org>
 <201412101246.26382.arekm@maven.pl> <5488419D.7050801@jajcus.net>
 <201412101414.41206.arekm@maven.pl> <54884CCC.4050202@jajcus.net>
 <20141210201029.327b23c6@zonk.pl> <54897180.7000409@pld-linux.org>
Message-ID: <20150102101050.GA29736@polanet.pl>

On Thu, Dec 11, 2014 at 12:27:12 +0200, Elan Ruusam?e wrote:

>> $ grep alias/etc/shrc.d/*.sh
>> [...]
>> /etc/shrc.d/which.sh:alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'
>> [...]
> 
> "which" needs to be alias to handle shell builtins (--read-alias option)

"which" needs to be aliased to handle shell functions as well.
But which doesn't have to handle aliases nor functions!

And don't anyone dare 'fixing' this according to man which, as zsh completion creates:

$ declare -f | wc -l
2657

-- 
Tomasz Pala <gotar at pld-linux.org>


From gotar at polanet.pl  Fri Jan  2 11:32:49 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Fri, 2 Jan 2015 11:32:49 +0100
Subject: [packages/grep] - move from GREP_OPTIONS environmental
 variable to alias due to its obsolescence
In-Reply-To: <54884CCC.4050202@jajcus.net>
References: <23ca4364a0c6cf68fca3432a517ec04a28c22e22_refs_heads_master@pld-linux.org>
 <201412101246.26382.arekm@maven.pl> <5488419D.7050801@jajcus.net>
 <201412101414.41206.arekm@maven.pl> <54884CCC.4050202@jajcus.net>
Message-ID: <20150102103249.GB29736@polanet.pl>

On Wed, Dec 10, 2014 at 14:38:20 +0100, Jacek Konieczny wrote:

>>>> if [ -r /etc/env.d/GREP_OPTIONS ]; then
[...]
>>> Why?
>> 
>> For backward compat with what we had so far.
> 
> Such a shell script for any interactive shell started, just because one
> or two PLD users have uncommented the /etc/env.d/GREP_OPTIONS we might
> have wrongly introduced long time ago?
> 
> I don't think it is worth it.

We shouldn't create workarounds for upstream abandoned functions -
that's their decision to blame, agreed (so no env.d/GREP_OPTIONS parsing in
some script).

However, we should keep our improvement base available. In this case -
the alias should be installed. I'm not even sure if there's any
rationale to have it back in commented-out version, but IF there is - we
should drop at least colorls and which - people NEED to set them on
their own, don't they?

-- 
Tomasz Pala <gotar at pld-linux.org>


From baggins at pld-linux.org  Mon Jan  5 21:18:14 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 5 Jan 2015 21:18:14 +0100
Subject: [2014/01/05] Removed packages from Th
Message-ID: <20150105201813.GA2278@home.lan>

The following packages have been removed today from Th due to broken
deps:

i486 build of libreoffice

pnetC-0.7.4-2
pypy-1.9-5
squeak-3.9-2

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From zawadaa at gmail.com  Tue Jan  6 23:20:26 2015
From: zawadaa at gmail.com (Andrzej Zawadzki)
Date: Tue, 06 Jan 2015 23:20:26 +0100
Subject: PostgreSQL and uuid-ossp
In-Reply-To: <20141230192307.GG2275@home.lan>
References: <54A092C1.1030502@gmail.com> <20141230192307.GG2275@home.lan>
Message-ID: <54AC5FAA.8030501@gmail.com>

On 30.12.2014 20:23, Jan R?korajski wrote:
> On Mon, 29 Dec 2014, Andrzej Zawadzki wrote:
>
>> Hi!
>>
>> I need help: what configure option should I use according to:
>> www.postgresql.org/docs/9.4/static/uuid-ossp.html
>>
>>
>> With --with-uuid=ossp
>>
>> configure: WARNING: uuid.h: accepted by the compiler, rejected by the
>> preprocessor!
>> configure: WARNING: uuid.h: proceeding with the compiler's result
>> checking for uuid.h... yes
>> configure: error: header file <uuid.h> does not match OSSP UUID library
> Can you check config.log why it thinks uuid.h from ossp-uuid is not from
> ossp-uuid?
>
I've changed configure.in - now this step is passed.

--- configure.in.orig   2015-01-05 23:55:32.000000000 +0100
+++ configure.in        2015-01-06 00:03:58.433386714 +0100
@@ -1166,13 +1166,13 @@
          [AC_MSG_ERROR([header file <uuid.h> does not match E2FS UUID 
library])])],
        [AC_MSG_ERROR([header file <uuid/uuid.h> or <uuid.h> is required 
for E2FS UUID])])])
  elif test "$with_uuid" = ossp ; then
-  AC_CHECK_HEADERS(ossp/uuid.h,
-    [AC_EGREP_HEADER([uuid_export], ossp/uuid.h, [],
-      [AC_MSG_ERROR([header file <ossp/uuid.h> does not match OSSP UUID 
library])])],
+  AC_CHECK_HEADERS(ossp-uuid/uuid.h,
+    [AC_EGREP_HEADER([uuid_export], ossp-uuid/uuid.h, [],
+      [AC_MSG_ERROR([header file <ossp-uuid/uuid.h> does not match OSSP 
UUID library])])],
      [AC_CHECK_HEADERS(uuid.h,
        [AC_EGREP_HEADER([uuid_export], uuid.h, [],
          [AC_MSG_ERROR([header file <uuid.h> does not match OSSP UUID 
library])])],
-      [AC_MSG_ERROR([header file <ossp/uuid.h> or <uuid.h> is required 
for OSSP UUID])])])
+      [AC_MSG_ERROR([header file <ossp-uuid/uuid.h> or <uuid.h> is 
required for OSSP UUID])])])
  fi

  if test "$PORTNAME" = "win32" ; then



But during compilation output is like below:

make: Entering directory 
'/home/users/builder/rpm/BUILD/postgresql-9.4.0/contrib/uuid-ossp'
x86_64-pld-linux-gcc -O2 -fwrapv -pipe -Wformat -Werror=format-security 
-gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 
-Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 
-fPIC -march=x86-64 -gdwarf-4 -fno-debug-types-section 
-fvar-tracking-assignments -g2 -DNEED_REENTRANT_FUNCS 
-I/usr/include/ossp-uuid -fpic -I../../contrib/pgcrypto -I. -I. 
-I../../src/include -D_GNU_SOURCE -I/usr/include/libxml2   -c -o 
uuid-ossp.o uuid-ossp.c -MMD -MP -MF .deps/uuid-ossp.Po
uuid-ossp.c:53:2: error: #error UUID length mismatch
  #error UUID length mismatch
   ^
uuid-ossp.c:130:17: error: unknown type name 'uuid_rc_t'
  pguuid_complain(uuid_rc_t rc)
                  ^
uuid-ossp.c:161:8: error: unknown type name 'uuid_t'
  static uuid_t *
         ^
uuid-ossp.c: In function 'get_cached_uuid_t':
uuid-ossp.c:164:9: error: unknown type name 'uuid_t'
   static uuid_t *cached_uuid[2] = {NULL, NULL};
          ^
uuid-ossp.c:168:3: error: unknown type name 'uuid_rc_t'
    uuid_rc_t rc;
    ^
uuid-ossp.c:171:13: error: 'UUID_RC_OK' undeclared (first use in this 
function)
    if (rc != UUID_RC_OK)
              ^
uuid-ossp.c:171:13: note: each undeclared identifier is reported only 
once for each function it appears in
uuid-ossp.c: At top level:
uuid-ossp.c:181:22: error: unknown type name 'uuid_t'
  uuid_to_string(const uuid_t *uuid)
                       ^
uuid-ossp.c: In function 'uuid_to_string':
uuid-ossp.c:183:24: error: 'UUID_LEN_STR' undeclared (first use in this 
function)
   char    *buf = palloc(UUID_LEN_STR + 1);
                         ^
uuid-ossp.c:186:2: error: unknown type name 'uuid_rc_t'
   uuid_rc_t rc;
   ^
uuid-ossp.c:188:25: error: 'UUID_FMT_STR' undeclared (first use in this 
function)
   rc = uuid_export(uuid, UUID_FMT_STR, &ptr, &len);
                          ^
uuid-ossp.c:189:12: error: 'UUID_RC_OK' undeclared (first use in this 
function)
   if (rc != UUID_RC_OK)

[...]

../../src/Makefile.global:730: recipe for target 'uuid-ossp.o' failed
make: *** [uuid-ossp.o] Error 1
make: Leaving directory 
'/home/users/builder/rpm/BUILD/postgresql-9.4.0/contrib/uuid-ossp'
error: Bad exit status from /home/users/builder/tmp/rpm-tmp.90948 (%build)

Works with e2fs - do we need play with old ossp library? PostgreSQL 
doesn't like this (from documentation).

-- 
Andrzej


From glen at pld-linux.org  Wed Jan  7 12:50:07 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Wed, 07 Jan 2015 13:50:07 +0200
Subject: [packages/php-pecl-apcu] libtool fix
In-Reply-To: <20141117202140.GA2002@home.lan>
References: <19cb3b4600545e6eed9c87992a202bae70782e07_refs_heads_master@pld-linux.org>
 <20141117180106.GA1342@mail>
 <CAKY5yHxnQVWqzcwq7ydm9mJQ6yhJbG+jqFw1yLQ5xP2Wtd_+JA@mail.gmail.com>
 <201411171925.07738.arekm@maven.pl> <20141117192307.GA1649@mail>
 <20141117202140.GA2002@home.lan>
Message-ID: <54AD1D6F.9080408@pld-linux.org>

On 17.11.2014 22:21, Jan R?korajski wrote:
> Generic workaround:
>
> mv build-aux/snippet{,.save}
> libtoolize
> mv build-aux/snippet{.save,}
>
> But now I found a patch, which will be applied in libtool 2.4.4:
>
> https://lists.gnu.org/archive/html/libtool-patches/2014-10/msg00018.html
> Applied to libtool.
>
what's the state of this now?

seems php stuff still build fails

https://srcbuilder.pld-linux.org/th/queue.html#122751
https://srcbuilder.pld-linux.org/th/queue.html#122752

+ /usr/bin/make -Otarget -j5/bin/sh /tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/libtool --mode=compile x86_64-pld-linux-gcc -I. -I/tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5 -DPHP_ATOM_INC -I/tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/include -I/tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/main -I/tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5 -I/usr/include/php -I/usr/include/php/main -I/usr/include/php/TSRM -I/usr/include/php/Zend -I/usr/include/php/ext -I/usr/include/php/ext/date/lib -DHAVE_CONFIG_H -O2 -fwrapv -pipe -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC -march=x86-64 -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -c /tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/redis.c -o redis.lo  /bin/sh: /tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/libtool: No such file or directory Makefile:200: recipe for target 'redis.lo' failed make: *** [redis.lo] Error 127 make: *** Waiting for unfinished jobs....




-- 
glen



From qboosh at pld-linux.org  Wed Jan  7 17:09:16 2015
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 7 Jan 2015 17:09:16 +0100
Subject: [packages/texlive/TEXLIVE_20080816] - no clisp on x32 means no
 xindy there - removed unneeded file that crashes file(1) and prevents bui
In-Reply-To: <50829d18f3e79a29b561347b2edbe42dd652c394_refs_heads_TEXLIVE_20080816@pld-linux.org>
References: <68187e49806af43cc2f5fcfd57d33d7097e96b6e_refs_heads_TEXLIVE_20080816@pld-linux.org>
 <50829d18f3e79a29b561347b2edbe42dd652c394_refs_heads_TEXLIVE_20080816@pld-linux.org>
Message-ID: <20150107160916.GA19305@mail>

On Thu, Jan 01, 2015 at 08:49:05PM +0100, baggins wrote:
>     - removed unneeded file that crashes file(1) and prevents build

file(1) must be fixed then (regardless of this image is needed or not).
Does it crash everywhere or on x32 only?


-- 
Jakub Bogusz    http://qboosh.pl/


From qboosh at pld-linux.org  Wed Jan  7 17:34:02 2015
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 7 Jan 2015 17:34:02 +0100
Subject: [packages/rpm/arlib] convert cpu-os-macros to ar archive instead
 of untracked .tar.gz
In-Reply-To: <c37514ab0235ba8911996d7ea1056bba86f551e2_refs_heads_arlib@pld-linux.org>
References: <20150107155939.10810.60434@pld-linux.org>
 <c37514ab0235ba8911996d7ea1056bba86f551e2_refs_heads_arlib@pld-linux.org>
Message-ID: <20150107163402.GB19305@mail>

On Wed, Jan 07, 2015 at 04:59:44PM +0100, glen wrote:
> commit c37514ab0235ba8911996d7ea1056bba86f551e2
> Author: Elan Ruusam?e <glen at delfi.ee>
> Date:   Wed Jan 7 17:56:04 2015 +0200
> 
>     convert cpu-os-macros to ar archive instead of untracked .tar.gz
>     
>     archive macros in an ar archive instead since it's ascii rather than
>     binary, making it easier merge changes, deal with conflicts etc...
>     
>     idea from proyvind:
>     https://abf.io/openmandriva/rpm/commits/master/cpu-os-macros.a
[...]
> diff --git a/README.cpu-os-macros b/README.cpu-os-macros
> new file mode 100644
> index 0000000..5adcecc
> --- /dev/null
> +++ b/README.cpu-os-macros
> @@ -0,0 +1,12 @@
> +In order to more easily cope with merges and avoid issues with binary formats,
> +we're now using the ar format which will give us a pure ascii archive that'll
> +make it possible to track & merge individual changes like with other text files.
> +Unfortunately the format doesn't support paths..
> +
> +recommended way of making changes and updating archive:
> +rm -rf foo
> +cd foo
> +ar x ../cpu-os-macros.a
> +<perform your changes>
> +cd -
> +ar cDr cpu-os-macros.a foo/*macros

Isn't diff -Nur more readable (paths!) and easier to maintain?


-- 
Jakub Bogusz    http://qboosh.pl/


From glen at pld-linux.org  Wed Jan  7 18:12:00 2015
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Wed, 07 Jan 2015 19:12:00 +0200
Subject: [packages/rpm/arlib] convert cpu-os-macros to ar archive instead
 of untracked .tar.gz
In-Reply-To: <20150107163402.GB19305@mail>
References: <20150107155939.10810.60434@pld-linux.org>
 <c37514ab0235ba8911996d7ea1056bba86f551e2_refs_heads_arlib@pld-linux.org>
 <20150107163402.GB19305@mail>
Message-ID: <54AD68E0.7000708@pld-linux.org>

On 07.01.2015 18:34, Jakub Bogusz wrote:
>> >+++ b/README.cpu-os-macros
>> >@@ -0,0 +1,12 @@
>> >+In order to more easily cope with merges and avoid issues with binary formats,
>> >+we're now using the ar format which will give us a pure ascii archive that'll
>> >+make it possible to track & merge individual changes like with other text files.
>> >+Unfortunately the format doesn't support paths..
>> >+
>> >+recommended way of making changes and updating archive:
>> >+rm -rf foo
>> >+cd foo
>> >+ar x ../cpu-os-macros.a
>> >+<perform your changes>
>> >+cd -
>> >+ar cDr cpu-os-macros.a foo/*macros
> Isn't diff -Nur more readable (paths!) and easier to maintain?

maybe,

however, diff -Nur is probably ordered by filesystem, but foo/*macros is 
ordered by locale. as all files are lowercase it's consistent with C, 
en_US, or pl_PL or whatever some other friend uses (few locales like 
et_EE have problem with a-z excluding t-u-v, but that's minimal impact)

and ar is probably easier to create than patch (just redo whole 
archive), with patch have to update patch with a patch. neh...

-- 
glen



From baggins at pld-linux.org  Thu Jan  8 02:03:37 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Thu, 8 Jan 2015 10:03:37 +0900
Subject: [packages/texlive/TEXLIVE_20080816] - no clisp on x32 means no
 xindy there - removed unneeded file that crashes file(1) and prevents bui
In-Reply-To: <20150107160916.GA19305@mail>
References: <68187e49806af43cc2f5fcfd57d33d7097e96b6e_refs_heads_TEXLIVE_20080816@pld-linux.org>
 <50829d18f3e79a29b561347b2edbe42dd652c394_refs_heads_TEXLIVE_20080816@pld-linux.org>
 <20150107160916.GA19305@mail>
Message-ID: <20150108010336.GB9816@tachikoma.lan>

On Wed, 07 Jan 2015, Jakub Bogusz wrote:

> On Thu, Jan 01, 2015 at 08:49:05PM +0100, baggins wrote:
> >     - removed unneeded file that crashes file(1) and prevents build
> 
> file(1) must be fixed then (regardless of this image is needed or not).
> Does it crash everywhere or on x32 only?

Everywhere, I think. I tested it on x8664 when it failed on x32.

-- 
Jan R?korajski                                 | PLD/Linux
SysAdm                                         | http://www.pld-linux.org/
baggins<at>google.com
baggins<at>pld-linux.org


From qboosh at pld-linux.org  Thu Jan  8 21:06:04 2015
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 8 Jan 2015 21:06:04 +0100
Subject: [packages/libsndfile] - disable checking for unresolved symbols
 (false positives in library)
In-Reply-To: <f84c3b3b18f5df5bd4f79a53fec19f17393a0c86_refs_heads_master@pld-linux.org>
References: <f75f3f1162a1e44a9bf528cdb485c17f1ae3a324_refs_heads_master@pld-linux.org>
 <f84c3b3b18f5df5bd4f79a53fec19f17393a0c86_refs_heads_master@pld-linux.org>
Message-ID: <20150108200604.GA31441@mail>

On Sat, Jan 03, 2015 at 06:45:21PM +0100, baggins wrote:
> commit f84c3b3b18f5df5bd4f79a53fec19f17393a0c86
> Author: Jan R?korajski <baggins at pld-linux.org>
> Date:   Sat Jan 3 17:44:49 2015 +0000
> 
>     - disable checking for unresolved symbols (false positives in library)

What environment and syndroms?
Doesn't happen on my i686 or carmr x86_64.


-- 
Jakub Bogusz    http://qboosh.pl/


From baggins at pld-linux.org  Fri Jan  9 00:25:07 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Fri, 9 Jan 2015 08:25:07 +0900
Subject: [packages/libsndfile] - disable checking for unresolved symbols
 (false positives in library)
In-Reply-To: <20150108200604.GA31441@mail>
References: <f75f3f1162a1e44a9bf528cdb485c17f1ae3a324_refs_heads_master@pld-linux.org>
 <f84c3b3b18f5df5bd4f79a53fec19f17393a0c86_refs_heads_master@pld-linux.org>
 <20150108200604.GA31441@mail>
Message-ID: <20150108232505.GA21811@tachikoma.lan>

On Thu, 08 Jan 2015, Jakub Bogusz wrote:

> On Sat, Jan 03, 2015 at 06:45:21PM +0100, baggins wrote:
> > commit f84c3b3b18f5df5bd4f79a53fec19f17393a0c86
> > Author: Jan R?korajski <baggins at pld-linux.org>
> > Date:   Sat Jan 3 17:44:49 2015 +0000
> > 
> >     - disable checking for unresolved symbols (false positives in library)
> 
> What environment and syndroms?
> Doesn't happen on my i686 or carmr x86_64.

Missing symbols from properly linked libogg an libvorbis. Env is x32.
I will upload my basic rpm set to ftp soon and will provide a VM image
with it for tests.

-- 
Jan R?korajski                                 | PLD/Linux
SysAdm                                         | http://www.pld-linux.org/
baggins<at>google.com
baggins<at>pld-linux.org


From groups at sq9mev.info  Sat Jan 10 16:11:43 2015
From: groups at sq9mev.info (Bartek SQ9MEV)
Date: Sat, 10 Jan 2015 16:11:43 +0100
Subject: dhcpd enable_early_chroot bcond
Message-ID: <54B1412F.3020607@sq9mev.info>

Hi there,

attached patch adds --enable-early-chroot. Seems like this option is 
required by ocf:heartbeat:dhcpd resource agent (precisely -user and 
-group options).

BTW, PLD's dhcpd-4.2.5 is little outdated  (there are 4.2.7 current 
stable and 4.3.1 current), however PLD applies own patches, and i do not 
have enough time or knowledge to bump version quickly.

-- 
Bartek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: enable_early_chroot.patch
Type: text/x-patch
Size: 659 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20150110/7ea6bbd9/attachment.bin>

From glen at delfi.ee  Sat Jan 10 18:55:55 2015
From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Sat, 10 Jan 2015 19:55:55 +0200
Subject: exfat
Message-ID: <54B167AB.8060504@delfi.ee>

there are two packages on ftp:

exfat-utils-1.0.1-1.x86_64.rpm
fuse-exfat-1.0.1-3.x86_64.rpm

any ideas why the split? as i have to install both to use exfat mounts 
properly...
there's even no suggests to suggest the other package, should it be 
added? to which one of them?

http://git.pld-linux.org/?p=packages/fuse-exfat.git;a=summary
http://git.pld-linux.org/?p=packages/exfat-utils.git;a=summary

-- 
glen



From qboosh at pld-linux.org  Sat Jan 10 19:20:10 2015
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sat, 10 Jan 2015 19:20:10 +0100
Subject: exfat
In-Reply-To: <54B167AB.8060504@delfi.ee>
References: <54B167AB.8060504@delfi.ee>
Message-ID: <20150110182010.GA23530@mail>

On Sat, Jan 10, 2015 at 07:55:55PM +0200, Elan Ruusam?e wrote:
> there are two packages on ftp:
> 
> exfat-utils-1.0.1-1.x86_64.rpm
> fuse-exfat-1.0.1-3.x86_64.rpm
> 
> any ideas why the split?

Upstream decided to split them.

> as i have to install both to use exfat mounts 
> properly...

It depends how do you want to deal with exfat filesystems.
fuse-exfat is required to mount fs.
exfat-utils are needed just to create, repair, dump or change label of
fs.

> there's even no suggests to suggest the other package, should it be 
> added? to which one of them?

At most S: fuse-exfat in fuse-exfat...
Or just information about each other in both packages descriptions.


-- 
Jakub Bogusz    http://qboosh.pl/


From qboosh at pld-linux.org  Sat Jan 10 19:40:40 2015
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sat, 10 Jan 2015 19:40:40 +0100
Subject: [packages/libsndfile] - disable checking for unresolved symbols
 (false positives in library)
In-Reply-To: <20150108232505.GA21811@tachikoma.lan>
References: <f75f3f1162a1e44a9bf528cdb485c17f1ae3a324_refs_heads_master@pld-linux.org>
 <f84c3b3b18f5df5bd4f79a53fec19f17393a0c86_refs_heads_master@pld-linux.org>
 <20150108200604.GA31441@mail> <20150108232505.GA21811@tachikoma.lan>
Message-ID: <20150110184040.GB23530@mail>

On Fri, Jan 09, 2015 at 08:25:07AM +0900, Jan R?korajski wrote:
> On Thu, 08 Jan 2015, Jakub Bogusz wrote:
> 
> > On Sat, Jan 03, 2015 at 06:45:21PM +0100, baggins wrote:
> > > commit f84c3b3b18f5df5bd4f79a53fec19f17393a0c86
> > > Author: Jan R?korajski <baggins at pld-linux.org>
> > > Date:   Sat Jan 3 17:44:49 2015 +0000
> > > 
> > >     - disable checking for unresolved symbols (false positives in library)
> > 
> > What environment and syndroms?
> > Doesn't happen on my i686 or carmr x86_64.
> 
> Missing symbols from properly linked libogg an libvorbis. Env is x32.

Strange. Some objdump or linking issues specific to x32?

> I will upload my basic rpm set to ftp soon and will provide a VM image
> with it for tests.

Any chance for remote x32 carme(-like) system available for PLD developers?


-- 
Jakub Bogusz    http://qboosh.pl/


From baggins at pld-linux.org  Sun Jan 11 11:06:32 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 11 Jan 2015 19:06:32 +0900
Subject: [packages/libsndfile] - disable checking for unresolved symbols
 (false positives in library)
In-Reply-To: <20150110184040.GB23530@mail>
References: <f75f3f1162a1e44a9bf528cdb485c17f1ae3a324_refs_heads_master@pld-linux.org>
 <f84c3b3b18f5df5bd4f79a53fec19f17393a0c86_refs_heads_master@pld-linux.org>
 <20150108200604.GA31441@mail>
 <20150108232505.GA21811@tachikoma.lan>
 <20150110184040.GB23530@mail>
Message-ID: <20150111100630.GA1981@tachikoma.lan>

On Sat, 10 Jan 2015, Jakub Bogusz wrote:

> On Fri, Jan 09, 2015 at 08:25:07AM +0900, Jan R?korajski wrote:
> > On Thu, 08 Jan 2015, Jakub Bogusz wrote:
> > 
> > > On Sat, Jan 03, 2015 at 06:45:21PM +0100, baggins wrote:
> > > > commit f84c3b3b18f5df5bd4f79a53fec19f17393a0c86
> > > > Author: Jan R?korajski <baggins at pld-linux.org>
> > > > Date:   Sat Jan 3 17:44:49 2015 +0000
> > > > 
> > > >     - disable checking for unresolved symbols (false positives in library)
> > > 
> > > What environment and syndroms?
> > > Doesn't happen on my i686 or carmr x86_64.
> > 
> > Missing symbols from properly linked libogg an libvorbis. Env is x32.
> 
> Strange. Some objdump or linking issues specific to x32?

Looks like objdump, 'ldd -r' doesn't show anything.

> > I will upload my basic rpm set to ftp soon and will provide a VM image
> > with it for tests.
> 
> Any chance for remote x32 carme(-like) system available for PLD developers?

Don't know right now, but when we drop i486 there should be free builder
machine for it.

-- 
Jan R?korajski                                 | PLD/Linux
SysAdm                                         | http://www.pld-linux.org/
baggins<at>google.com
baggins<at>pld-linux.org


From mike at altlinux.org  Mon Jan 12 22:39:57 2015
From: mike at altlinux.org (Michael Shigorin)
Date: Tue, 13 Jan 2015 00:39:57 +0300
Subject: exfat
In-Reply-To: <20150110182010.GA23530@mail>
References: <54B167AB.8060504@delfi.ee> <20150110182010.GA23530@mail>
Message-ID: <20150112213957.GF31160@imap.altlinux.org>

On Sat, Jan 10, 2015 at 07:20:10PM +0100, Jakub Bogusz wrote:
> > exfat-utils-1.0.1-1.x86_64.rpm
> > fuse-exfat-1.0.1-3.x86_64.rpm
> At most S: fuse-exfat in fuse-exfat...

S: fuse-exfat in exfat-utils?

-- 
?---- WBR, Michael Shigorin / http://altlinux.org
??------ http://opennet.ru / http://anna-news.info


From qboosh at pld-linux.org  Tue Jan 13 06:29:27 2015
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 13 Jan 2015 06:29:27 +0100
Subject: exfat
In-Reply-To: <20150112213957.GF31160@imap.altlinux.org>
References: <54B167AB.8060504@delfi.ee> <20150110182010.GA23530@mail>
 <20150112213957.GF31160@imap.altlinux.org>
Message-ID: <20150113052927.GA14567@mail>

On Tue, Jan 13, 2015 at 12:39:57AM +0300, Michael Shigorin wrote:
> On Sat, Jan 10, 2015 at 07:20:10PM +0100, Jakub Bogusz wrote:
> > > exfat-utils-1.0.1-1.x86_64.rpm
> > > fuse-exfat-1.0.1-3.x86_64.rpm
> > At most S: fuse-exfat in fuse-exfat...
> 
> S: fuse-exfat in exfat-utils?

Oops. Yes, that's what I meant :)


-- 
Jakub Bogusz    http://qboosh.pl/


From glen at pld-linux.org  Tue Jan 13 17:30:18 2015
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Tue, 13 Jan 2015 18:30:18 +0200
Subject: rpm -Va BAD, key ID
Message-ID: <54B5481A.2060000@pld-linux.org>

rpm -Va emits such messages:

   error: rpmdb (h#123): Header V4 DSA signature: BAD, key ID e4f1bc2d

that's from repeated scratch installs, the key ID stays always the same 
(e4f1bc2d)


i've traced that something between rpm-5.4.14-5.x86_64 and 
rpm-5.4.15-6.x86_64 and have caused it

18:19:15 vagrant[load: 0.44]@pld64 ~$ cat /etc/vagrant_box_build_time
Fri Oct 10 00:22:52 CEST 2014

18:19:16 vagrant[load: 0.40]@pld64 ~$ rpm -q rpm
rpm-5.4.14-5.x86_64

18:19:20 vagrant[load: 0.40]@pld64 ~$ rpm -Va > /dev/null
18:19:54 vagrant[load: 0.45]@pld64 ~$ sudo poldek --up -u rpm
[cut]
18:20:43 vagrant[load: 0.31]@pld64 ~$ rpm -q rpm
rpm-5.4.15-6.x86_64
18:21:36 vagrant[load: 0.14]@pld64 ~$ rpm -Va > /dev/null
error: rpmdb (h#2): Header V4 DSA signature: BAD, key ID e4f1bc2d
error: rpmdb (h#3): Header V4 DSA signature: BAD, key ID e4f1bc2d
...
error: rpmdb (h#147): Header V4 DSA signature: BAD, key ID e4f1bc2d
error: rpmdb (h#148): Header V4 DSA signature: BAD, key ID e4f1bc2d

18:21:53 vagrant[load: 0.17]@pld64 ~$

downgrading back to 5.4.14 (from repackage spool) gives opinion that the 
db itself is not corrupted:

18:24:09 root[load: 0.14]@pld64 ~# rpm --version
rpm (RPM) 5.4.14
18:23:56 root[load: 0.08]@pld64 ~# rpm -Va >/dev/null
18:24:09 root[load: 0.14]@pld64 ~#

the same says db_verify:
18:25:53 root[load: 0.07]@pld64 lib/rpm# db5.2_verify A* Ba* C* 
Dirnames   F* G* I* N* O* P* R* S* T* V*
BDB5105 Verification of Arch succeeded.
BDB5105 Verification of Basenames succeeded.
BDB5105 Verification of Conflictname succeeded.
BDB5105 Verification of Dirnames succeeded.
BDB5105 Verification of Filedigests succeeded.
BDB5105 Verification of Filepaths succeeded.
BDB5105 Verification of Group succeeded.
BDB5105 Verification of Installtid succeeded.
BDB5105 Verification of Name succeeded.
BDB5105 Verification of Nvra succeeded.
BDB5105 Verification of Obsoletename succeeded.
BDB5105 Verification of Os succeeded.
BDB5105 Verification of Packagecolor succeeded.
BDB5105 Verification of Packages succeeded.
BDB5105 Verification of Providename succeeded.
BDB5105 Verification of Pubkeys succeeded.
BDB5105 Verification of Release succeeded.
BDB5105 Verification of Requirename succeeded.
BDB5105 Verification of Seqno succeeded.
BDB5105 Verification of Sha1header succeeded.
BDB5105 Verification of Sigmd5 succeeded.
BDB5105 Verification of Sourcepkgid succeeded.
BDB5105 Verification of Triggername succeeded.
BDB5105 Verification of Version succeeded.


also rpmdbchk  tool by proyvind says 0% damaged with 5.4.14 and  ~1% 
damaged with 5.4.14:

18:26:55 root[load: 0.20]@pld64 rpm/bin# /rpmdbchk --checkonly
checking /var/lib/rpm/Packages: 135/135 100%
0/135 (0.000000%) headers damaged

18:26:36 root[load: 0.10]@pld64 rpm/bin# /rpmdbchk --checkonly
checking /var/lib/rpm/Packages: 2/136 1%
1 (2): Header V4 DSA signature: BAD, key ID e4f1bc2d
checking /var/lib/rpm/Packages: 3/136 2%
...
checking /var/lib/rpm/Packages: 134/136 99%
checking /var/lib/rpm/Packages: 136/136 100%
128/136 (0.941176%) headers damaged

18:26:47 root[load: 0.22]@pld64 rpm/bin#


ps: the vagrant base boxes i've conducted the above tests are available from
ftp://ftp.pld-linux.org/people/glen/vm/th/

pld64-20141009.box - rpm-5.4.14-5.x86_64
pld64-20141205.box - rpm-5.4.15-6.x86_64

-- 
glen



From n3npq at me.com  Tue Jan 13 18:43:11 2015
From: n3npq at me.com (Jeffrey Johnson)
Date: Tue, 13 Jan 2015 12:43:11 -0500
Subject: rpm -Va BAD, key ID
In-Reply-To: <54B5481A.2060000@pld-linux.org>
References: <54B5481A.2060000@pld-linux.org>
Message-ID: <8AC8166E-D7AF-48FA-AB79-9B068CCA1E64@me.com>


On Jan 13, 2015, at 11:30 AM, Elan Ruusam?e wrote:

> rpm -Va emits such messages:
> 
>  error: rpmdb (h#123): Header V4 DSA signature: BAD, key ID e4f1bc2d
> 

What package is header #123? (try rpm -Vavv which should display package names near h#123).

> that's from repeated scratch installs, the key ID stays always the same (e4f1bc2d)
> 
> 
> i've traced that something between rpm-5.4.14-5.x86_64 and rpm-5.4.15-6.x86_64 and have caused it
> 

rpm-5.4.14 may not attempt to verify header signatures while verifying, I forget when enabled.

Removing and re-importing 0xe4f1bc2d is the 1st thing to try.

You can easily patch out the attempt to verify header signatures in 5.4.15.

Meanwhile more info is needed if you want a fix, including what public key (0xe4f1bc2d) is being used,
and whether the public key is imported or included in packages.

73 de Jeff



From glen at pld-linux.org  Tue Jan 13 21:01:05 2015
From: glen at pld-linux.org (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Tue, 13 Jan 2015 22:01:05 +0200
Subject: rpm -Va BAD, key ID
In-Reply-To: <8AC8166E-D7AF-48FA-AB79-9B068CCA1E64@me.com>
References: <54B5481A.2060000@pld-linux.org>
 <8AC8166E-D7AF-48FA-AB79-9B068CCA1E64@me.com>
Message-ID: <54B57981.2020300@pld-linux.org>

On 13.01.2015 19:43, Jeffrey Johnson wrote:
> On Jan 13, 2015, at 11:30 AM, Elan Ruusam?e wrote:
>
>> rpm -Va emits such messages:
>>
>>   error: rpmdb (h#123): Header V4 DSA signature: BAD, key ID e4f1bc2d
>>
> What package is header #123? (try rpm -Vavv which should display package names near h#123).
that #123 is pretty much every package in the system.
h#xxx starts from #2 and ends with #148. 149 packages in system, 1 fake 
gpg package.

rpm -Vavv of 5.4.14 and 5.4.14 can be obtained  from here:

http://carme.pld-linux.org/~glen/rpm-va.tar.xz (75K)
>> that's from repeated scratch installs, the key ID stays always the same (e4f1bc2d)
>>
>>
>> i've traced that something between rpm-5.4.14-5.x86_64 and rpm-5.4.15-6.x86_64 and have caused it
>>
> rpm-5.4.14 may not attempt to verify header signatures while verifying, I forget when enabled.
>
> Removing and re-importing 0xe4f1bc2d is the 1st thing to try.
>
> You can easily patch out the attempt to verify header signatures in 5.4.15.
>
> Meanwhile more info is needed if you want a fix, including what public key (0xe4f1bc2d) is being used,
> and whether the public key is imported or included in packages.
>
gpg-pubkey-e4f1bc2d-47b351f0 is key used to sign pld th packages:

$ rpm -qi gpg-pubkey-e4f1bc2d-47b351f0

Name        : gpg-pubkey                   Relocations: (not relocatable)
Version     : e4f1bc2d                          Vendor: (none)
Release     : 47b351f0                      Build Date: Fri Oct 10 01:19:35 2014
Install Date: Fri Oct 10 01:19:35 2014      Build Host: localhost
Group       : Public Keys                   Source RPM: (none)
Size        : 0                                License: pubkey
Signature   : (none)
Summary     : gpg(RSApub (PLD Linux Distribution 3.0 (Th)) <th-admin at pld-linux.org>)
Architecture: (none)
Description :
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: RPM 5.4.10 (BeeCrypt)

mQGiBEezUfARBACXCHHN8F35uES1o+FhB7op/804RVJw59Jv3UGDubv4x8SPHGNNb2WFLLMm
W5MUucB+VSS3Xm33U27HFfg9OaeJsSJu3b5RE+UnPTZihV5+vENdtsfIDJBOjgTcbEXYW75O
V9Qnxczx4fGUOfEU23a3q/yXXXnarjbTLRizBCJkBwCgrJvTzbDuECHrs74gm84E7unI26kD
/1Kd1Qm3QEsOkcuIW75zq6GiQE4S+jEEqKwyyVxENPN+o3+MRG3J/s3XV0hCnczueQZrEQu/
PNTm0t2d0rSlQg/Pm6Z46IpZ50UY2/CPIB3GaRT505Q4+gk15RulIQjR/4zUN/NB9P8ijo3p
4yAqhvPqDXhcigH94WH+NDsvC4+uA/90oyzRpnT1qSmReTwcmseU2mm/l6Uxl+LMtlBNTkrv
Ws9aBpFCK1j27ngIG4xdhDqNYMIwUv8C3FH6wh4nwa/o70gu4Hnr0Dezz+WZxHcg6VWyBuu0
NpBftCvwS1YLWQ3tRMnNhuok1Ulur9ocW//wby+5z7qj49AnzpxxrRXJ3rRBRFNBcHViIChQ
TEQgTGludXggRGlzdHJpYnV0aW9uIDMuMCAoVGgpKSA8dGgtYWRtaW5AcGxkLWxpbnV4Lm9y
Zz6IYAQTEQIAIAUCR7NR8AIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEK8/k7zk8bwt
hUsAoJ44g5TWhmvGqXUiDOIAjfw6QXSvAKCLWEANVGfXOihK7zxAMvXqZj2wepiNBEezUgYB
BADTsxN1pG5XtEcXwLayVtr1frEKNIE5ckWmKxx8040/ql+p9tzWtteRL5uAh5VbtfdQnFt4
gFoZJPsm1zMFsx9+LhV5nm5ZIowztde3vxyxCRuO90+PJy+N2DFHmIQMeuDzATN6O8VKUO2K
1yzAaMmZdPC56cEidSjg9M95v/814wARAQABtEFSU0FwdWIgKFBMRCBMaW51eCBEaXN0cmli
dXRpb24gMy4wIChUaCkpIDx0aC1hZG1pbkBwbGQtbGludXgub3JnPoi2BBMBAgAgBQJHs1IG
AhsDBgsJCAcDAgQVAggDBBYCAwECHgECF4AACgkQcy/f3urm+Lg8dwP7BdZCN5OTnwbwskRo
Ae4Hxs9t9hxW05maLJD5zyQTm+eL2o2uvIkzq67soB2aUVNPm0RCqnzh99BaqQSAGj4bpBcj
eFup2mhGy706QS6eaVl9cNigsfi3ehvAE5Qd5N5V12olY4Sik7q/F9MH+F/GAiPRdCpzLM2x
yBrlOB+zw5Y=
=ayIa
-----END PGP PUBLIC KEY BLOCK-----

the pubkey is available publicly from ftp:
ftp://ftp.pld-linux.org/dists/th/PLD-3.0-Th-GPG-key.asc


removing pubkey, made rpm -Va to succeed, importing it again, made it 
fail again:

21:55:00 root[load: 0.08]@pld64 ~# rpm -e gpg-pubkey-e4f1bc2d-47b351f0

21:55:52 root[load: 0.04]@pld64 ~# rpm -Va >/dev/null

21:56:12 root[load: 0.09]@pld64 ~# rpm -q rpm
rpm-5.4.15-7.x86_64

21:56:15 root[load: 0.09]@pld64 ~# rpm --import 
/etc/pki/rpm-gpg/PLD-3.0-Th-GPG-key.asc

21:56:21 root[load: 0.08]@pld64 ~# rpm -Va >/dev/null
error: rpmdb (h#2): Header V4 DSA signature: BAD, key ID e4f1bc2d
error: rpmdb (h#3): Header V4 DSA signature: BAD, key ID e4f1bc2d
...




-- 
glen



From n3npq at me.com  Wed Jan 14 11:08:28 2015
From: n3npq at me.com (Jeffrey Johnson)
Date: Wed, 14 Jan 2015 05:08:28 -0500
Subject: rpm -Va BAD, key ID
In-Reply-To: <54B57981.2020300@pld-linux.org>
References: <54B5481A.2060000@pld-linux.org>
 <8AC8166E-D7AF-48FA-AB79-9B068CCA1E64@me.com> <54B57981.2020300@pld-linux.org>
Message-ID: <9021F58E-BA20-4FFA-9FA4-5FAEE3B22A2D@me.com>


On Jan 13, 2015, at 3:01 PM, Elan Ruusam?e wrote:

> On 13.01.2015 19:43, Jeffrey Johnson wrote:
>> On Jan 13, 2015, at 11:30 AM, Elan Ruusam?e wrote:
>> 
>>> rpm -Va emits such messages:
>>> 
>>>  error: rpmdb (h#123): Header V4 DSA signature: BAD, key ID e4f1bc2d
>>> 
>> What package is header #123? (try rpm -Vavv which should display package names near h#123).
> that #123 is pretty much every package in the system.
> h#xxx starts from #2 and ends with #148. 149 packages in system, 1 fake gpg package.
> 
> rpm -Vavv of 5.4.14 and 5.4.14 can be obtained  from here:
> 
> http://carme.pld-linux.org/~glen/rpm-va.tar.xz (75K)
>>> that's from repeated scratch installs, the key ID stays always the same (e4f1bc2d)
>>> 
>>> 
>>> i've traced that something between rpm-5.4.14-5.x86_64 and rpm-5.4.15-6.x86_64 and have caused it
>>> 
>> rpm-5.4.14 may not attempt to verify header signatures while verifying, I forget when enabled.
>> 
>> Removing and re-importing 0xe4f1bc2d is the 1st thing to try.
>> 
>> You can easily patch out the attempt to verify header signatures in 5.4.15.
>> 
>> Meanwhile more info is needed if you want a fix, including what public key (0xe4f1bc2d) is being used,
>> and whether the public key is imported or included in packages.
>> 
> gpg-pubkey-e4f1bc2d-47b351f0 is key used to sign pld th packages:
> 
> $ rpm -qi gpg-pubkey-e4f1bc2d-47b351f0
> 
> Name        : gpg-pubkey                   Relocations: (not relocatable)
> Version     : e4f1bc2d                          Vendor: (none)
> Release     : 47b351f0                      Build Date: Fri Oct 10 01:19:35 2014
> Install Date: Fri Oct 10 01:19:35 2014      Build Host: localhost
> Group       : Public Keys                   Source RPM: (none)
> Size        : 0                                License: pubkey
> Signature   : (none)
> Summary     : gpg(RSApub (PLD Linux Distribution 3.0 (Th)) <th-admin at pld-linux.org>)
---------------------------^^^^ Presumably this is an RSA public key.

> Architecture: (none)
> Description :
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: RPM 5.4.10 (BeeCrypt)
-------------- ^^^^^^^^^^ exported by rpm-5.4.10

> 
> mQGiBEezUfARBACXCHHN8F35uES1o+FhB7op/804RVJw59Jv3UGDubv4x8SPHGNNb2WFLLMm
> W5MUucB+VSS3Xm33U27HFfg9OaeJsSJu3b5RE+UnPTZihV5+vENdtsfIDJBOjgTcbEXYW75O
> V9Qnxczx4fGUOfEU23a3q/yXXXnarjbTLRizBCJkBwCgrJvTzbDuECHrs74gm84E7unI26kD
> /1Kd1Qm3QEsOkcuIW75zq6GiQE4S+jEEqKwyyVxENPN+o3+MRG3J/s3XV0hCnczueQZrEQu/
> PNTm0t2d0rSlQg/Pm6Z46IpZ50UY2/CPIB3GaRT505Q4+gk15RulIQjR/4zUN/NB9P8ijo3p
> 4yAqhvPqDXhcigH94WH+NDsvC4+uA/90oyzRpnT1qSmReTwcmseU2mm/l6Uxl+LMtlBNTkrv
> Ws9aBpFCK1j27ngIG4xdhDqNYMIwUv8C3FH6wh4nwa/o70gu4Hnr0Dezz+WZxHcg6VWyBuu0
> NpBftCvwS1YLWQ3tRMnNhuok1Ulur9ocW//wby+5z7qj49AnzpxxrRXJ3rRBRFNBcHViIChQ
> TEQgTGludXggRGlzdHJpYnV0aW9uIDMuMCAoVGgpKSA8dGgtYWRtaW5AcGxkLWxpbnV4Lm9y
> Zz6IYAQTEQIAIAUCR7NR8AIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEK8/k7zk8bwt
> hUsAoJ44g5TWhmvGqXUiDOIAjfw6QXSvAKCLWEANVGfXOihK7zxAMvXqZj2wepiNBEezUgYB
> BADTsxN1pG5XtEcXwLayVtr1frEKNIE5ckWmKxx8040/ql+p9tzWtteRL5uAh5VbtfdQnFt4
> gFoZJPsm1zMFsx9+LhV5nm5ZIowztde3vxyxCRuO90+PJy+N2DFHmIQMeuDzATN6O8VKUO2K
> 1yzAaMmZdPC56cEidSjg9M95v/814wARAQABtEFSU0FwdWIgKFBMRCBMaW51eCBEaXN0cmli
> dXRpb24gMy4wIChUaCkpIDx0aC1hZG1pbkBwbGQtbGludXgub3JnPoi2BBMBAgAgBQJHs1IG
> AhsDBgsJCAcDAgQVAggDBBYCAwECHgECF4AACgkQcy/f3urm+Lg8dwP7BdZCN5OTnwbwskRo
> Ae4Hxs9t9hxW05maLJD5zyQTm+eL2o2uvIkzq67soB2aUVNPm0RCqnzh99BaqQSAGj4bpBcj
> eFup2mhGy706QS6eaVl9cNigsfi3ehvAE5Qd5N5V12olY4Sik7q/F9MH+F/GAiPRdCpzLM2x
> yBrlOB+zw5Y=
> =ayIa
> -----END PGP PUBLIC KEY BLOCK-----
> 
> the pubkey is available publicly from ftp:
> ftp://ftp.pld-linux.org/dists/th/PLD-3.0-Th-GPG-key.asc
> 

Try resigning a package with the same key and importing using rpm-5.4.15. Does that "fix"?

There were many fixes for RSA signatures in rpm-5.4.15.

These were fixes for known problems repeatedly tested with all five crypto implementations, not regressions.

The testing does not exclude a regression, but there are known incompatibilities between
rpm-5.4.15 and earlier versions of RPM with RSA signatures.

(aside)
Write a loop generating as many RSA pubkeys as you wish and sign packages
until you are confident of the RSA signatures implemented in rpm-5.4.15.

See tests/genpgp.sh for how to generate RSA key pairs

73 de Jeff

> 
> removing pubkey, made rpm -Va to succeed, importing it again, made it fail again:
> 
> 21:55:00 root[load: 0.08]@pld64 ~# rpm -e gpg-pubkey-e4f1bc2d-47b351f0
> 
> 21:55:52 root[load: 0.04]@pld64 ~# rpm -Va >/dev/null
> 
> 21:56:12 root[load: 0.09]@pld64 ~# rpm -q rpm
> rpm-5.4.15-7.x86_64
> 
> 21:56:15 root[load: 0.09]@pld64 ~# rpm --import /etc/pki/rpm-gpg/PLD-3.0-Th-GPG-key.asc
> 
> 21:56:21 root[load: 0.08]@pld64 ~# rpm -Va >/dev/null
> error: rpmdb (h#2): Header V4 DSA signature: BAD, key ID e4f1bc2d
> error: rpmdb (h#3): Header V4 DSA signature: BAD, key ID e4f1bc2d
> ...
> 
> 
> 
> 
> -- 
> 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 glen at pld-linux.org  Wed Jan 21 12:51:01 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Wed, 21 Jan 2015 13:51:01 +0200
Subject: [packages/php-pecl-apcu] libtool fix
In-Reply-To: <54AD1D6F.9080408@pld-linux.org>
References: <19cb3b4600545e6eed9c87992a202bae70782e07_refs_heads_master@pld-linux.org>
 <20141117180106.GA1342@mail>
 <CAKY5yHxnQVWqzcwq7ydm9mJQ6yhJbG+jqFw1yLQ5xP2Wtd_+JA@mail.gmail.com>
 <201411171925.07738.arekm@maven.pl> <20141117192307.GA1649@mail>
 <20141117202140.GA2002@home.lan> <54AD1D6F.9080408@pld-linux.org>
Message-ID: <54BF92A5.5090902@pld-linux.org>

can't build any php extension in current state


On 07.01.2015 13:50, Elan Ruusam?e wrote:
> On 17.11.2014 22:21, Jan R?korajski wrote:
>> Generic workaround:
>>
>> mv build-aux/snippet{,.save}
>> libtoolize
>> mv build-aux/snippet{.save,}
>>
>> But now I found a patch, which will be applied in libtool 2.4.4:
>>
>> https://lists.gnu.org/archive/html/libtool-patches/2014-10/msg00018.html
>> Applied to libtool.
>>
> what's the state of this now?
>
> seems php stuff still build fails
>
> https://srcbuilder.pld-linux.org/th/queue.html#122751
> https://srcbuilder.pld-linux.org/th/queue.html#122752
>
> + /usr/bin/make -Otarget -j5/bin/sh 
> /tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/libtool 
> --mode=compile x86_64-pld-linux-gcc -I. 
> -I/tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5 
> -DPHP_ATOM_INC 
> -I/tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/include 
> -I/tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/main 
> -I/tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5 
> -I/usr/include/php -I/usr/include/php/main -I/usr/include/php/TSRM 
> -I/usr/include/php/Zend -I/usr/include/php/ext 
> -I/usr/include/php/ext/date/lib -DHAVE_CONFIG_H -O2 -fwrapv -pipe 
> -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section 
> -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 
> -fstack-protector --param=ssp-buffer-size=4 -fPIC -march=x86-64 
> -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -c 
> /tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/redis.c 
> -o redis.lo  /bin/sh: 
> /tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/libtool: 
> No such file or directory Makefile:200: recipe for target 'redis.lo' 
> failed make: *** [redis.lo] Error 127 make: *** Waiting for unfinished 
> jobs....
>
>
>
>


-- 
glen



From qboosh at pld-linux.org  Wed Jan 21 16:41:14 2015
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 21 Jan 2015 16:41:14 +0100
Subject: ERRORS: libcfile.spec
In-Reply-To: <pld-builder.1421786742.674701.7592@nereid-builder>
References: <req-69fa0bd0-3e4d-4630-b63a-46e94e010539@pld.src.builder>
 <pld-builder.1421786742.674701.7592@nereid-builder>
Message-ID: <20150121154114.GA15633@mail>

On Tue, Jan 20, 2015 at 08:45:42PM +0000, PLD th-i686 builder wrote:
> Request by: qboosh at pld-linux.org
> 
> libcfile.spec (HEAD): FAILED
[...]
> + /usr/lib/rpm/compress-doc
> Compressing documentation in /tmp/B.09671fa6-1168-4f4d-b715-a3d5d0835091/BUILD/tmp/libcfile-20150101-root-builder/usr/share/doc/libcfile-20150101...
> ./AUTHORS ./ChangeLog ./README 
> Documentation compressed.
> + exit 0
> Segmentation fault
> ended at: Tue Jan 20 21:45:42 2015, done in 0:00:24.284600
> error: No files produced.

???
What happened here?
Rebuild from the same tag succeeded.


-- 
Jakub Bogusz    http://qboosh.pl/


From baggins at pld-linux.org  Wed Jan 21 17:32:41 2015
From: baggins at pld-linux.org (=?UTF-8?Q?Jan_R=C4=99korajski?=)
Date: Wed, 21 Jan 2015 17:32:41 +0100
Subject: [packages/php-pecl-apcu] libtool fix
In-Reply-To: <54BF92A5.5090902@pld-linux.org>
References: <19cb3b4600545e6eed9c87992a202bae70782e07_refs_heads_master@pld-linux.org>
 <20141117180106.GA1342@mail>
 <CAKY5yHxnQVWqzcwq7ydm9mJQ6yhJbG+jqFw1yLQ5xP2Wtd_+JA@mail.gmail.com>
 <201411171925.07738.arekm@maven.pl> <20141117192307.GA1649@mail>
 <20141117202140.GA2002@home.lan> <54AD1D6F.9080408@pld-linux.org>
 <54BF92A5.5090902@pld-linux.org>
Message-ID: <CAKY5yHyDhZN1c1oF7uMyTNKZD0nepRM+Tjxf_ZfLwKv8GDMV=g@mail.gmail.com>

You know what the fix is. To reitarate:

> It's just a matter of changing one symlink in %{_libdir}/php/build in
> php.spec (* all its branches) and rebuilding base php package(s)
> (without touching external modules).

There is no need to downgrade, please don't.

On Wed, Jan 21, 2015 at 12:51 PM, Elan Ruusam?e <glen at pld-linux.org> wrote:
> can't build any php extension in current state
>
> On 07.01.2015 13:50, Elan Ruusam?e wrote:
>>
>> On 17.11.2014 22:21, Jan R?korajski wrote:
>>>
>>> Generic workaround:
>>>
>>> mv build-aux/snippet{,.save}
>>> libtoolize
>>> mv build-aux/snippet{.save,}
>>>
>>> But now I found a patch, which will be applied in libtool 2.4.4:
>>>
>>> https://lists.gnu.org/archive/html/libtool-patches/2014-10/msg00018.html
>>> Applied to libtool.
>>>
>> what's the state of this now?
>>
>> seems php stuff still build fails
>>
>> https://srcbuilder.pld-linux.org/th/queue.html#122751
>> https://srcbuilder.pld-linux.org/th/queue.html#122752
>>
>> + /usr/bin/make -Otarget -j5/bin/sh
>> /tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/libtool
>> --mode=compile x86_64-pld-linux-gcc -I.
>> -I/tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5
>> -DPHP_ATOM_INC
>> -I/tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/include
>> -I/tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/main
>> -I/tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5
>> -I/usr/include/php -I/usr/include/php/main -I/usr/include/php/TSRM
>> -I/usr/include/php/Zend -I/usr/include/php/ext
>> -I/usr/include/php/ext/date/lib -DHAVE_CONFIG_H -O2 -fwrapv -pipe -Wformat
>> -Werror=format-security -gdwarf-4 -fno-debug-types-section
>> -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector
>> --param=ssp-buffer-size=4 -fPIC -march=x86-64 -gdwarf-4
>> -fno-debug-types-section -fvar-tracking-assignments -g2 -c
>> /tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/redis.c
>> -o redis.lo  /bin/sh:
>> /tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/libtool:
>> No such file or directory Makefile:200: recipe for target 'redis.lo' failed
>> make: *** [redis.lo] Error 127 make: *** Waiting for unfinished jobs....
>>
>>
>>
>>
>
>
> --
> glen
>
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en



-- 
Jan R?korajski | SysAdm | PLD/Linux | http://www.pld-linux.org/
baggins<at>pld-linux.org


From glen at pld-linux.org  Wed Jan 21 19:47:00 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Wed, 21 Jan 2015 20:47:00 +0200
Subject: [packages/php-pecl-apcu] libtool fix
In-Reply-To: <CAKY5yHyDhZN1c1oF7uMyTNKZD0nepRM+Tjxf_ZfLwKv8GDMV=g@mail.gmail.com>
References: <19cb3b4600545e6eed9c87992a202bae70782e07_refs_heads_master@pld-linux.org>
 <20141117180106.GA1342@mail>
 <CAKY5yHxnQVWqzcwq7ydm9mJQ6yhJbG+jqFw1yLQ5xP2Wtd_+JA@mail.gmail.com>
 <201411171925.07738.arekm@maven.pl> <20141117192307.GA1649@mail>
 <20141117202140.GA2002@home.lan> <54AD1D6F.9080408@pld-linux.org>
 <54BF92A5.5090902@pld-linux.org>
 <CAKY5yHyDhZN1c1oF7uMyTNKZD0nepRM+Tjxf_ZfLwKv8GDMV=g@mail.gmail.com>
Message-ID: <54BFF424.9060303@pld-linux.org>

On 21.01.2015 18:32, Jan R?korajski wrote:
> You know what the fix is. To reitarate:
no i don't. why you assume that?
>> It's just a matter of changing one symlink in %{_libdir}/php/build in
>> php.spec (* all its branches) and rebuilding base php package(s)
>> (without touching external modules).
will try this.

> There is no need to downgrade, please don't.

the hack you mentioned did not work for php:
you wrote that you found patch, and applied, but php build was still broken

so downgraded as it was known to work

>
> On Wed, Jan 21, 2015 at 12:51 PM, Elan Ruusam?e <glen at pld-linux.org> wrote:
>> can't build any php extension in current state
>>
>> On 07.01.2015 13:50, Elan Ruusam?e wrote:
>>> On 17.11.2014 22:21, Jan R?korajski wrote:
>>>> Generic workaround:
>>>>
>>>> mv build-aux/snippet{,.save}
>>>> libtoolize
>>>> mv build-aux/snippet{.save,}
>>>>
>>>> But now I found a patch, which will be applied in libtool 2.4.4:
>>>>
>>>> https://lists.gnu.org/archive/html/libtool-patches/2014-10/msg00018.html
>>>> Applied to libtool.
>>>>
>>> what's the state of this now?
>>>
>>> seems php stuff still build fails
>>>
>>> https://srcbuilder.pld-linux.org/th/queue.html#122751
>>> https://srcbuilder.pld-linux.org/th/queue.html#122752
>>>
>>> + /usr/bin/make -Otarget -j5/bin/sh
>>> /tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/libtool
>>> --mode=compile x86_64-pld-linux-gcc -I.
>>> -I/tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5
>>> -DPHP_ATOM_INC
>>> -I/tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/include
>>> -I/tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/main
>>> -I/tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5
>>> -I/usr/include/php -I/usr/include/php/main -I/usr/include/php/TSRM
>>> -I/usr/include/php/Zend -I/usr/include/php/ext
>>> -I/usr/include/php/ext/date/lib -DHAVE_CONFIG_H -O2 -fwrapv -pipe -Wformat
>>> -Werror=format-security -gdwarf-4 -fno-debug-types-section
>>> -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector
>>> --param=ssp-buffer-size=4 -fPIC -march=x86-64 -gdwarf-4
>>> -fno-debug-types-section -fvar-tracking-assignments -g2 -c
>>> /tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/redis.c
>>> -o redis.lo  /bin/sh:
>>> /tmp/B.e15908fc-b6f8-462a-9f31-0eee6a233949/BUILD/php55-redis-2.2.5/libtool:
>>> No such file or directory Makefile:200: recipe for target 'redis.lo' failed
>>> make: *** [redis.lo] Error 127 make: *** Waiting for unfinished jobs....
>>>



-- 
glen



From glen at pld-linux.org  Wed Jan 21 19:47:57 2015
From: glen at pld-linux.org (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Wed, 21 Jan 2015 20:47:57 +0200
Subject: ERRORS: libcfile.spec
In-Reply-To: <20150121154114.GA15633@mail>
References: <req-69fa0bd0-3e4d-4630-b63a-46e94e010539@pld.src.builder>
 <pld-builder.1421786742.674701.7592@nereid-builder>
 <20150121154114.GA15633@mail>
Message-ID: <54BFF45D.7050509@pld-linux.org>

On 21.01.2015 17:41, Jakub Bogusz wrote:
> On Tue, Jan 20, 2015 at 08:45:42PM +0000, PLD th-i686 builder wrote:
>> Request by: qboosh at pld-linux.org
>>
>> libcfile.spec (HEAD): FAILED
> [...]
>> + /usr/lib/rpm/compress-doc
>> Compressing documentation in /tmp/B.09671fa6-1168-4f4d-b715-a3d5d0835091/BUILD/tmp/libcfile-20150101-root-builder/usr/share/doc/libcfile-20150101...
>> ./AUTHORS ./ChangeLog ./README
>> Documentation compressed.
>> + exit 0
>> Segmentation fault
>> ended at: Tue Jan 20 21:45:42 2015, done in 0:00:24.284600
>> error: No files produced.
> ???
> What happened here?
> Rebuild from the same tag succeeded.
random guess: gcc built with wrong cpu flags? or it was only affecting i486?

-- 
glen



From glen at delfi.ee  Thu Jan 22 16:59:16 2015
From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Thu, 22 Jan 2015 17:59:16 +0200
Subject: poldek -u does poldek -i
Message-ID: <54C11E54.2030405@delfi.ee>

meh!? what i'm not seeing here?

[root at blodnatt ~]# rpm -q google-earth
google-earth-6.0.1.2032-0.3.x86_64

[root at blodnatt tmp]# poldek --clean-whole
[root at blodnatt tmp]# poldek --up -u google-earth --sn carme
Retrieving carme::packages.ndir.md...
Retrieving carme::packages.ndir.gz...
.............................. 100.0% [496.4K (219.0K/s)]
Retrieving carme::packages.ndir.dscr.gz...
.............................. 100.0% [40.9K (40.9K/s)]
Loading [pndir]carme...
633 packages read
Processing dependencies...
There are 1 package to install:
I google-earth-7.1.2.2041-0.1.x86_64
This operation will use 180.8MB of disk space.
Need to get 63.9MB of archives (63.9MB to download).

Retrieving carme::google-earth-7.1.2.2041-0.1.x86_64.rpm...
.............................. 100.0% [63.9M (1.1M/s)]
Executing etckeeper.sh --upgrade -vh --root / --define 
_check_dirname_deps 1...
Preparing... ########################################### [100%]
error: Install/Erase problems:
         file /usr/lib64/google-earth/drivers.ini from install of 
google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from package 
google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/resources/application.rcc from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/resources/balloons.rcc from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/resources/effects.rcc from install 
of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from package 
google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/resources/leftpanel-common.rcc 
from install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file 
from package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/resources/leftpanel-layer.rcc from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/resources/localshapes.rcc from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/resources/navcontrols.rcc from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/resources/notifications.rcc from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/resources/progress.rcc from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/resources/spin_icon.png from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/resources/statusbar.rcc from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/resources/terrainmgr.rcc from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/resources/tmcontrols.rcc from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/resources/toolbar.rcc from install 
of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from package 
google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/resources/tourcontrols.rcc from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/resources/webbrowser.rcc from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/shaders/stbillboard.arbvp1 from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/shaders/stbillboard.cfg from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/shaders/stbillboard.vs_2_0 from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/shaders/stbranch.arbvp1 from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/shaders/stbranch.cfg from install 
of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from package 
google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/shaders/stbranch.vs_2_0 from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/shaders/stfrond.arbvp1 from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/shaders/stfrond.cfg from install 
of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from package 
google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/shaders/stfrond.vs_2_0 from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/shaders/stleafcard.cfg from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/shaders/stleafmesh.arbvp1 from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/shaders/stleafmesh.cfg from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64
         file /usr/lib64/google-earth/shaders/stleafmesh.vs_2_0 from 
install of google-earth-7.1.2.2041-0.1.x86_64 conflicts with file from 
package google-earth-6.0.1.2032-0.3.x86_64

[root at blodnatt tmp]# rpm -q rpm
rpm-5.4.14-2.x86_64

-- 
glen



From glen at delfi.ee  Sat Jan 24 14:23:13 2015
From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Sat, 24 Jan 2015 15:23:13 +0200
Subject: mono on x86_64
Message-ID: <54C39CC1.4040600@delfi.ee>

/usr/bin/mono is symlink to /usr/bin/mono-sgen in mono-3.10.0-1.x86_64
and that dependency is not satisfied, i.e not pulled automatically

what's worse, is that mono-sgen is packaged into mono-devel:

$ ls -l /usr/bin/mono
lrwxrwxrwx 1 root root 9 jaan  24 15:20 /usr/bin/mono -> mono-sgen*

$ rpm -qf /usr/bin/mono-sgen
mono-devel-3.10.0-1.x86_64

-- 
glen



From glen at delfi.ee  Sat Jan 24 15:35:38 2015
From: glen at delfi.ee (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Sat, 24 Jan 2015 16:35:38 +0200
Subject: mono on x86_64
In-Reply-To: <54C39CC1.4040600@delfi.ee>
References: <54C39CC1.4040600@delfi.ee>
Message-ID: <54C3ADBA.2010808@delfi.ee>

another issue:

System.TypeInitializationException: An exception was thrown by the type 
initializer for Mono.Unix.Native.Syscall ---> 
System.DllNotFoundException: /usr/lib/libMonoPosixHelper.so

but the library is in:

$ rpm -qf /usr/lib64/libMonoPosixHelper.so
mono-3.10.0-1.x86_64

$ keepass
SendMessage (60817438, 0x101f, (nil), (nil))
SendMessage (0, 0x1203, (nil), 0x7fff860e17c0)
SendMessage (0, 0x1204, (nil), 0x7fff860e17c0)
SendMessage (0, 0x1203, 0x1, 0x7fff860e17c0)
SendMessage (0, 0x1204, 0x1, 0x7fff860e17c0)
SendMessage (0, 0x1203, 0x2, 0x7fff860e17c0)
SendMessage (0, 0x1204, 0x2, 0x7fff860e17c0)
SendMessage (0, 0x1203, 0x3, 0x7fff860e17c0)
SendMessage (0, 0x1204, 0x3, 0x7fff860e17c0)
SendMessage (0, 0x1203, 0x4, 0x7fff860e17c0)
SendMessage (0, 0x1204, 0x4, 0x7fff860e17c0)
SendMessage (60817438, 0x101f, (nil), (nil))
SendMessage (0, 0x1203, (nil), 0x7fff860e29c0)
SendMessage (0, 0x1204, (nil), 0x7fff860e29c0)
SendMessage (0, 0x1203, 0x1, 0x7fff860e29c0)
SendMessage (0, 0x1204, 0x1, 0x7fff860e29c0)
SendMessage (0, 0x1203, 0x2, 0x7fff860e29c0)
SendMessage (0, 0x1204, 0x2, 0x7fff860e29c0)
SendMessage (0, 0x1203, 0x3, 0x7fff860e29c0)
SendMessage (0, 0x1204, 0x3, 0x7fff860e29c0)
SendMessage (0, 0x1203, 0x4, 0x7fff860e29c0)
SendMessage (0, 0x1204, 0x4, 0x7fff860e29c0)
System.TypeInitializationException: An exception was thrown by the type 
initializer for Mono.Unix.Native.Syscall ---> 
System.DllNotFoundException: /usr/lib/libMonoPosixHelper.so
   at (wrapper managed-to-native) Mono.Unix.Native.Syscall:get_at_fdcwd ()
   at Mono.Unix.Native.Syscall..cctor () [0x00000] in <filename unknown>:0
   --- End of inner exception stack trace ---
   at System.Windows.Forms.XplatUIX11.UpdateMessageQueue 
(System.Windows.Forms.XEventQueue queue, Boolean allowIdle) [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.XplatUIX11.UpdateMessageQueue 
(System.Windows.Forms.XEventQueue queue) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.XplatUIX11.GetMessage (System.Object 
queue_id, System.Windows.Forms.MSG& msg, IntPtr handle, Int32 
wFilterMin, Int32 wFilterMax) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.XplatUI.GetMessage (System.Object queue_id, 
System.Windows.Forms.MSG& msg, IntPtr hWnd, Int32 wFilterMin, Int32 
wFilterMax) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.Application.RunLoop (Boolean Modal, 
System.Windows.Forms.ApplicationContext context) [0x00000] in <filename 
unknown>:0
   at System.Windows.Forms.Application.Run 
(System.Windows.Forms.ApplicationContext context) [0x00000] in <filename 
unknown>:0
   at System.Windows.Forms.Application.Run (System.Windows.Forms.Form 
mainForm) [0x00000] in <filename unknown>:0
   at KeePass.Program.Main (System.String[] args) [0x00000] in <filename 
unknown>:0

Unhandled Exception:
System.ArgumentException: A null reference or invalid value was found 
[GDI+ status: InvalidParameter]
   at System.Drawing.GDIPlus.CheckStatus (Status status) [0x00000] in 
<filename unknown>:0
   at System.Drawing.StringFormat.set_Alignment (StringAlignment value) 
[0x00000] in <filename unknown>:0
   at (wrapper remoting-invoke-with-check) 
System.Drawing.StringFormat:set_Alignment (System.Drawing.StringAlignment)
   at System.Windows.Forms.ColumnHeader.CalcColumnHeader () [0x00000] in 
<filename unknown>:0
   at (wrapper remoting-invoke-with-check) 
System.Windows.Forms.ColumnHeader:CalcColumnHeader ()
   at System.Windows.Forms.ListView.LayoutHeader () [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.ListView.LayoutDetails () [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.ListView.CalculateListView (ListViewAlignment 
align) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.ListView.Redraw (Boolean recalculate) 
[0x00000] in <filename unknown>:0
   at System.Windows.Forms.ListView.ListView_SizeChanged (System.Object 
sender, System.EventArgs e) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.OnSizeChanged (System.EventArgs e) 
[0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.UpdateBounds (Int32 x, Int32 y, Int32 
width, Int32 height, Int32 clientWidth, Int32 clientHeight) [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.Control.UpdateBounds (Int32 x, Int32 y, Int32 
width, Int32 height) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.SetBoundsCoreInternal (Int32 x, Int32 
y, Int32 width, Int32 height, BoundsSpecified specified) [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.Control.SetBoundsCore (Int32 x, Int32 y, 
Int32 width, Int32 height, BoundsSpecified specified) [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.Control.SetBoundsInternal (Int32 x, Int32 y, 
Int32 width, Int32 height, BoundsSpecified specified) [0x00000] in 
<filename unknown>:0
   at (wrapper remoting-invoke-with-check) 
System.Windows.Forms.Control:SetBoundsInternal 
(int,int,int,int,System.Windows.Forms.BoundsSpecified)
   at System.Windows.Forms.Layout.DefaultLayout.LayoutDockedChildren 
(System.Windows.Forms.Control parent, System.Windows.Forms.Control[] 
controls) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.Layout.DefaultLayout.Layout (System.Object 
container, System.Windows.Forms.LayoutEventArgs args) [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.Control.OnLayout 
(System.Windows.Forms.LayoutEventArgs levent) [0x00000] in <filename 
unknown>:0
   at System.Windows.Forms.ScrollableControl.OnLayout 
(System.Windows.Forms.LayoutEventArgs levent) [0x00000] in <filename 
unknown>:0
   at System.Windows.Forms.Control.PerformLayout 
(System.Windows.Forms.Control affectedControl, System.String 
affectedProperty) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.PerformLayout () [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.Control.ResumeLayout (Boolean performLayout) 
[0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.ResumeLayout () [0x00000] in 
<filename unknown>:0
   at (wrapper remoting-invoke-with-check) 
System.Windows.Forms.Control:ResumeLayout ()
   at System.Windows.Forms.SplitContainer.UpdateLayout () [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.SplitContainer.OnLayout 
(System.Windows.Forms.LayoutEventArgs e) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.PerformLayout 
(System.Windows.Forms.Control affectedControl, System.String 
affectedProperty) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.OnResizeInternal (System.EventArgs e) 
[0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.OnResize (System.EventArgs e) 
[0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.OnSizeChanged (System.EventArgs e) 
[0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.UpdateBounds (Int32 x, Int32 y, Int32 
width, Int32 height, Int32 clientWidth, Int32 clientHeight) [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.Control.UpdateBounds (Int32 x, Int32 y, Int32 
width, Int32 height) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.SetBoundsCoreInternal (Int32 x, Int32 
y, Int32 width, Int32 height, BoundsSpecified specified) [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.Control.SetBoundsCore (Int32 x, Int32 y, 
Int32 width, Int32 height, BoundsSpecified specified) [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.SplitContainer.SetBoundsCore (Int32 x, Int32 
y, Int32 width, Int32 height, BoundsSpecified specified) [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.Control.SetBoundsInternal (Int32 x, Int32 y, 
Int32 width, Int32 height, BoundsSpecified specified) [0x00000] in 
<filename unknown>:0
   at (wrapper remoting-invoke-with-check) 
System.Windows.Forms.Control:SetBoundsInternal 
(int,int,int,int,System.Windows.Forms.BoundsSpecified)
   at System.Windows.Forms.Layout.DefaultLayout.LayoutDockedChildren 
(System.Windows.Forms.Control parent, System.Windows.Forms.Control[] 
controls) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.Layout.DefaultLayout.Layout (System.Object 
container, System.Windows.Forms.LayoutEventArgs args) [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.Control.OnLayout 
(System.Windows.Forms.LayoutEventArgs levent) [0x00000] in <filename 
unknown>:0
   at System.Windows.Forms.ScrollableControl.OnLayout 
(System.Windows.Forms.LayoutEventArgs levent) [0x00000] in <filename 
unknown>:0
   at System.Windows.Forms.Control.PerformLayout 
(System.Windows.Forms.Control affectedControl, System.String 
affectedProperty) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.PerformLayout () [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.Control.ResumeLayout (Boolean performLayout) 
[0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.ResumeLayout () [0x00000] in 
<filename unknown>:0
   at (wrapper remoting-invoke-with-check) 
System.Windows.Forms.Control:ResumeLayout ()
   at System.Windows.Forms.SplitContainer.UpdateLayout () [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.SplitContainer.OnLayout 
(System.Windows.Forms.LayoutEventArgs e) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.PerformLayout 
(System.Windows.Forms.Control affectedControl, System.String 
affectedProperty) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.OnResizeInternal (System.EventArgs e) 
[0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.OnResize (System.EventArgs e) 
[0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.OnSizeChanged (System.EventArgs e) 
[0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.UpdateBounds (Int32 x, Int32 y, Int32 
width, Int32 height, Int32 clientWidth, Int32 clientHeight) [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.Control.UpdateBounds (Int32 x, Int32 y, Int32 
width, Int32 height) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.SetBoundsCoreInternal (Int32 x, Int32 
y, Int32 width, Int32 height, BoundsSpecified specified) [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.Control.SetBoundsCore (Int32 x, Int32 y, 
Int32 width, Int32 height, BoundsSpecified specified) [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.SplitContainer.SetBoundsCore (Int32 x, Int32 
y, Int32 width, Int32 height, BoundsSpecified specified) [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.Control.SetBoundsInternal (Int32 x, Int32 y, 
Int32 width, Int32 height, BoundsSpecified specified) [0x00000] in 
<filename unknown>:0
   at (wrapper remoting-invoke-with-check) 
System.Windows.Forms.Control:SetBoundsInternal 
(int,int,int,int,System.Windows.Forms.BoundsSpecified)
   at System.Windows.Forms.Layout.DefaultLayout.LayoutDockedChildren 
(System.Windows.Forms.Control parent, System.Windows.Forms.Control[] 
controls) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.Layout.DefaultLayout.Layout (System.Object 
container, System.Windows.Forms.LayoutEventArgs args) [0x00000] in 
<filename unknown>:0
   at System.Windows.Forms.Control.OnLayout 
(System.Windows.Forms.LayoutEventArgs levent) [0x00000] in <filename 
unknown>:0
   at System.Windows.Forms.ScrollableControl.OnLayout 
(System.Windows.Forms.LayoutEventArgs levent) [0x00000] in <filename 
unknown>:0
   at System.Windows.Forms.ContainerControl.OnLayout 
(System.Windows.Forms.LayoutEventArgs e) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.Form.OnLayout 
(System.Windows.Forms.LayoutEventArgs levent) [0x00000] in <filename 
unknown>:0
   at System.Windows.Forms.Control.PerformLayout 
(System.Windows.Forms.Control affectedControl, System.String 
affectedProperty) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.PerformLayout () [0x00000] in 
<filename unknown>:0
   at (wrapper remoting-invoke-with-check) 
System.Windows.Forms.Control:PerformLayout ()
   at System.Windows.Forms.Control.OnLayout 
(System.Windows.Forms.LayoutEventArgs levent) [0x00000] in <filename 
unknown>:0
   at System.Windows.Forms.ScrollableControl.OnLayout 
(System.Windows.Forms.LayoutEventArgs levent) [0x00000] in <filename 
unknown>:0
   at System.Windows.Forms.ToolStrip.OnLayout 
(System.Windows.Forms.LayoutEventArgs e) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.PerformLayout 
(System.Windows.Forms.Control affectedControl, System.String 
affectedProperty) [0x00000] in <filename unknown>:0
   at (wrapper remoting-invoke-with-check) 
System.Windows.Forms.Control:PerformLayout 
(System.Windows.Forms.Control,string)
   at System.Windows.Forms.Control+ControlCollection.Remove 
(System.Windows.Forms.Control value) [0x00000] in <filename unknown>:0
   at System.Windows.Forms.Control.Dispose (Boolean disposing) [0x00000] 
in <filename unknown>:0
   at System.Windows.Forms.ComboBox.Dispose (Boolean disposing) 
[0x00000] in <filename unknown>:0
   at System.ComponentModel.Component.Dispose () [0x00000] in <filename 
unknown>:0
   at (wrapper remoting-invoke-with-check) 
System.ComponentModel.Component:Dispose ()
   at System.Windows.Forms.ToolStripControlHost.Dispose (Boolean 
disposing) [0x00000] in <filename unknown>:0
   at System.ComponentModel.Component.Finalize () [0x00000] in <filename 
unknown>:0




From baggins at pld-linux.org  Sun Jan 25 15:26:05 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 25 Jan 2015 15:26:05 +0100
Subject: rpm -Va BAD, key ID
In-Reply-To: <9021F58E-BA20-4FFA-9FA4-5FAEE3B22A2D@me.com>
References: <54B5481A.2060000@pld-linux.org>
 <8AC8166E-D7AF-48FA-AB79-9B068CCA1E64@me.com>
 <54B57981.2020300@pld-linux.org>
 <9021F58E-BA20-4FFA-9FA4-5FAEE3B22A2D@me.com>
Message-ID: <20150125142605.GB2395@home.lan>

On Wed, 14 Jan 2015, Jeffrey Johnson wrote:

> 
> On Jan 13, 2015, at 3:01 PM, Elan Ruusam?e wrote:
> 
> > On 13.01.2015 19:43, Jeffrey Johnson wrote:
> >> On Jan 13, 2015, at 11:30 AM, Elan Ruusam?e wrote:
> >> 
> >>> rpm -Va emits such messages:
> >>> 
> >>>  error: rpmdb (h#123): Header V4 DSA signature: BAD, key ID e4f1bc2d
> >>> 
> >> What package is header #123? (try rpm -Vavv which should display package names near h#123).
> > that #123 is pretty much every package in the system.
> > h#xxx starts from #2 and ends with #148. 149 packages in system, 1 fake gpg package.
> > 
> > rpm -Vavv of 5.4.14 and 5.4.14 can be obtained  from here:
> > 
> > http://carme.pld-linux.org/~glen/rpm-va.tar.xz (75K)
> >>> that's from repeated scratch installs, the key ID stays always the same (e4f1bc2d)
> >>> 
> >>> 
> >>> i've traced that something between rpm-5.4.14-5.x86_64 and rpm-5.4.15-6.x86_64 and have caused it
> >>> 
> >> rpm-5.4.14 may not attempt to verify header signatures while verifying, I forget when enabled.
> >> 
> >> Removing and re-importing 0xe4f1bc2d is the 1st thing to try.
> >> 
> >> You can easily patch out the attempt to verify header signatures in 5.4.15.
> >> 
> >> Meanwhile more info is needed if you want a fix, including what public key (0xe4f1bc2d) is being used,
> >> and whether the public key is imported or included in packages.
> >> 
> > gpg-pubkey-e4f1bc2d-47b351f0 is key used to sign pld th packages:
> > 
> > $ rpm -qi gpg-pubkey-e4f1bc2d-47b351f0
> > 
> > Name        : gpg-pubkey                   Relocations: (not relocatable)
> > Version     : e4f1bc2d                          Vendor: (none)
> > Release     : 47b351f0                      Build Date: Fri Oct 10 01:19:35 2014
> > Install Date: Fri Oct 10 01:19:35 2014      Build Host: localhost
> > Group       : Public Keys                   Source RPM: (none)
> > Size        : 0                                License: pubkey
> > Signature   : (none)
> > Summary     : gpg(RSApub (PLD Linux Distribution 3.0 (Th)) <th-admin at pld-linux.org>)
> ---------------------------^^^^ Presumably this is an RSA public key.
> 
> > Architecture: (none)
> > Description :
> > -----BEGIN PGP PUBLIC KEY BLOCK-----
> > Version: RPM 5.4.10 (BeeCrypt)
> -------------- ^^^^^^^^^^ exported by rpm-5.4.10
[...]

> > 
> 
> Try resigning a package with the same key and importing using rpm-5.4.15. Does that "fix"?

No, packages signed with 5.4.15 also fail to verify with it.
The following command is used to sign packages:

rpm --resign --define '_signature gpg' --define '_gpg_name e4f1bc2d' files

So, that's not a problem of our setup, from my perspective it looks like
5.4.15 has broken RSA sig verification, can you look into it?

> There were many fixes for RSA signatures in rpm-5.4.15.
> 
> These were fixes for known problems repeatedly tested with all five crypto implementations, not regressions.
> 
> The testing does not exclude a regression, but there are known incompatibilities between
> rpm-5.4.15 and earlier versions of RPM with RSA signatures.

Can you elaborate what kind of incompatibilities we can expect?

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From n3npq at me.com  Sun Jan 25 15:38:15 2015
From: n3npq at me.com (Jeffrey Johnson)
Date: Sun, 25 Jan 2015 09:38:15 -0500
Subject: rpm -Va BAD, key ID
In-Reply-To: <20150125142605.GB2395@home.lan>
References: <54B5481A.2060000@pld-linux.org>
 <8AC8166E-D7AF-48FA-AB79-9B068CCA1E64@me.com> <54B57981.2020300@pld-linux.org>
 <9021F58E-BA20-4FFA-9FA4-5FAEE3B22A2D@me.com> <20150125142605.GB2395@home.lan>
Message-ID: <8F2FE702-B46A-41A8-9942-6C22BDC31AFA@me.com>


> On Jan 25, 2015, at 9:26 AM, Jan R?korajski <baggins at pld-linux.org> wrote:
> 
> 
>>> 
>> 
>> Try resigning a package with the same key and importing using rpm-5.4.15. Does that "fix"?
> 
> No, packages signed with 5.4.15 also fail to verify with it.
> The following command is used to sign packages:
> 
> rpm --resign --define '_signature gpg' --define '_gpg_name e4f1bc2d' files
> 
> So, that's not a problem of our setup, from my perspective it looks like
> 5.4.15 has broken RSA sig verification, can you look into it?
> 

I can try to reproduce the verification failure, but I haven?t the private key.

? meanwhile there are 5 crypto implementations in rpm, compile/use
any/all of BeeCrypt/NSS/OpenSSL/libtomcrypt/libgcrypt, see where
the problem lies.

>> There were many fixes for RSA signatures in rpm-5.4.15.
>> 
>> These were fixes for known problems repeatedly tested with all five crypto implementations, not regressions.
>> 
>> The testing does not exclude a regression, but there are known incompatibilities between
>> rpm-5.4.15 and earlier versions of RPM with RSA signatures.
> 
> Can you elaborate what kind of incompatibilities we can expect?
> 

Fingerprints were miscalculated for V4 RSA pubkeys, MPI lengths
were incorrect for RSA keys/signatures that happened to have 8 leasing
zero bits, bit counts in RSA private keys were added (which affects fingerprints),
for starters.

73 de Jeff

> -- 
> Jan R?korajski                    | PLD/Linux
> SysAdm | baggins<at>pld-linux.org <http://pld-linux.org/> | http://www.pld-linux.org/ <http://www.pld-linux.org/>
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org <mailto:pld-devel-en at lists.pld-linux.org>
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en <http://lists.pld-linux.org/mailman/listinfo/pld-devel-en>


From glen at pld-linux.org  Mon Jan 26 21:02:52 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Mon, 26 Jan 2015 22:02:52 +0200
Subject: xz kernel modules (Re: [packages/kernel] - updated config)
In-Reply-To: <20141213104657.GC2241@home.lan>
References: <e26ee53e41dbb757544e2857f019a4e7974f4712_refs_heads_master@pld-linux.org>
 <5fc1b244b3f356be6ea05dd183f0feba7e0c8276_refs_heads_master@pld-linux.org>
 <20141210195939.GA2256@home.lan> <548972B0.1020407@pld-linux.org>
 <20141213104657.GC2241@home.lan>
Message-ID: <54C69D6C.1020209@pld-linux.org>

On 13.12.2014 12:46, Jan R?korajski wrote:
> On Thu, 11 Dec 2014, Elan Ruusam?e wrote:
>
>> On 10.12.2014 21:59, Jan R?korajski wrote:
>>> What about switching to xz? That will require recent kmod, but we do it
>>> only for 3.18+ and if someone is running fresh kernel we can assume he
>>> has a fresh userspace.
>> i see you already switched. would be nice to see some du stats before
>> and after
> [root at home 3.17.2-1]# du -hs kernel*
> 54M	kernel.gz
> 46M	kernel.xz
>
> ~20% savings.
you compressed the files yourself?

because our rpm build automation does not strip the files:

[~/tmp/kernel-3.18.3-root-glen/lib] ? dus */
   1.  modules/  112.95 MiB
   2. firmware/    2.46 MiB
Total:             115.41 MiB


[~/tmp/kernel-3.18.3-root-glen/lib/modules/3.18.3-1/kernel] ? l 
fs/xfs/xfs.ko.xz
-rw-r--r-- 1 glen users 702K 26. jaan  21:42 fs/xfs/xfs.ko.xz
[~/tmp/kernel-3.18.3-root-glen/lib/modules/3.18.3-1/kernel] ? xz -d 
fs/xfs/xfs.ko.xz
[~/tmp/kernel-3.18.3-root-glen/lib/modules/3.18.3-1/kernel] ? file 
fs/xfs/xfs.ko
fs/xfs/xfs.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), 
BuildID[sha1]=63b5e04025bf63f7cd892e1f71785a0aa575fd28, not stripped


[~/tmp/kernel-3.18.3-root-glen/lib/modules/3.18.3-1/kernel] ? strip 
fs/xfs/xfs.ko
[~/tmp/kernel-3.18.3-root-glen/lib/modules/3.18.3-1/kernel] ? file 
fs/xfs/xfs.ko
fs/xfs/xfs.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), 
BuildID[sha1]=63b5e04025bf63f7cd892e1f71785a0aa575fd28, stripped

[~/tmp/kernel-3.18.3-root-glen/lib/modules/3.18.3-1/kernel] ? l 
fs/xfs/xfs.ko
-rw-r--r-- 1 glen users 723K 26. jaan  21:58 fs/xfs/xfs.ko

[~/tmp/kernel-3.18.3-root-glen/lib/modules/3.18.3-1/kernel] ? xz -9 
fs/xfs/xfs.ko
xz: Adjusted the number of threads from 4 to 3 to not exceed the memory 
usage limit of 4,773 MiB
[~/tmp/kernel-3.18.3-root-glen/lib/modules/3.18.3-1/kernel] ? l 
fs/xfs/xfs.ko.xz
-rw-r--r-- 1 glen users 212K 26. jaan  21:58 fs/xfs/xfs.ko.xz
[~/tmp/kernel-3.18.3-root-glen/lib/modules/3.18.3-1/kernel] ?

i checked build logs and no match for "Stripping kernel modules" [1]:
http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=1&ns=&cnt=50&off=0&name=kernel&id=87e395d9-22b0-4451-9554-774e0d2b1444
[1] 
https://github.com/pld-linux/rpm-build-macros/blob/auto/th/rpm-build-macros-1.706-1/rpm.macros#L578

apparently kernel compresses themselves and our build automation just 
searches for "*o" only:
https://github.com/pld-linux/rpm-build-macros/blob/auto/th/rpm-build-macros-1.706-1/rpm.macros#L574-L583

-- 
glen



From glen at pld-linux.org  Mon Jan 26 21:06:20 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Mon, 26 Jan 2015 22:06:20 +0200
Subject: xz kernel modules (Re: [packages/kernel] - updated config)
In-Reply-To: <54C69D6C.1020209@pld-linux.org>
References: <e26ee53e41dbb757544e2857f019a4e7974f4712_refs_heads_master@pld-linux.org>
 <5fc1b244b3f356be6ea05dd183f0feba7e0c8276_refs_heads_master@pld-linux.org>
 <20141210195939.GA2256@home.lan> <548972B0.1020407@pld-linux.org>
 <20141213104657.GC2241@home.lan> <54C69D6C.1020209@pld-linux.org>
Message-ID: <54C69E3C.80102@pld-linux.org>

On 26.01.2015 22:02, Elan Ruusam?e wrote:
> On 13.12.2014 12:46, Jan R?korajski wrote:
>> On Thu, 11 Dec 2014, Elan Ruusam?e wrote:
>>
>>> On 10.12.2014 21:59, Jan R?korajski wrote:
>>>> What about switching to xz? That will require recent kmod, but we 
>>>> do it
>>>> only for 3.18+ and if someone is running fresh kernel we can assume he
>>>> has a fresh userspace.
>>> i see you already switched. would be nice to see some du stats before
>>> and after
>> [root at home 3.17.2-1]# du -hs kernel*
>> 54M    kernel.gz
>> 46M    kernel.xz
>>
>> ~20% savings.
> you compressed the files yourself?
>
> because our rpm build automation does not strip the files:
>
> [~/tmp/kernel-3.18.3-root-glen/lib] ? dus */
>   1.  modules/  112.95 MiB
>   2. firmware/    2.46 MiB
> Total:             115.41 MiB
>
>
> [~/tmp/kernel-3.18.3-root-glen/lib/modules/3.18.3-1/kernel] ? l 
> fs/xfs/xfs.ko.xz
> -rw-r--r-- 1 glen users 702K 26. jaan  21:42 fs/xfs/xfs.ko.xz
> [~/tmp/kernel-3.18.3-root-glen/lib/modules/3.18.3-1/kernel] ? xz -d 
> fs/xfs/xfs.ko.xz
> [~/tmp/kernel-3.18.3-root-glen/lib/modules/3.18.3-1/kernel] ? file 
> fs/xfs/xfs.ko
> fs/xfs/xfs.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), 
> BuildID[sha1]=63b5e04025bf63f7cd892e1f71785a0aa575fd28, not stripped
>
>
> [~/tmp/kernel-3.18.3-root-glen/lib/modules/3.18.3-1/kernel] ? strip 
> fs/xfs/xfs.ko
> [~/tmp/kernel-3.18.3-root-glen/lib/modules/3.18.3-1/kernel] ? file 
> fs/xfs/xfs.ko
> fs/xfs/xfs.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), 
> BuildID[sha1]=63b5e04025bf63f7cd892e1f71785a0aa575fd28, stripped
>
> [~/tmp/kernel-3.18.3-root-glen/lib/modules/3.18.3-1/kernel] ? l 
> fs/xfs/xfs.ko
> -rw-r--r-- 1 glen users 723K 26. jaan  21:58 fs/xfs/xfs.ko
>
> [~/tmp/kernel-3.18.3-root-glen/lib/modules/3.18.3-1/kernel] ? xz -9 
> fs/xfs/xfs.ko
> xz: Adjusted the number of threads from 4 to 3 to not exceed the 
> memory usage limit of 4,773 MiB
> [~/tmp/kernel-3.18.3-root-glen/lib/modules/3.18.3-1/kernel] ? l 
> fs/xfs/xfs.ko.xz
> -rw-r--r-- 1 glen users 212K 26. jaan  21:58 fs/xfs/xfs.ko.xz
> [~/tmp/kernel-3.18.3-root-glen/lib/modules/3.18.3-1/kernel] ?
>
> i checked build logs and no match for "Stripping kernel modules" [1]:
> http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=1&ns=&cnt=50&off=0&name=kernel&id=87e395d9-22b0-4451-9554-774e0d2b1444 
>
> [1] 
> https://github.com/pld-linux/rpm-build-macros/blob/auto/th/rpm-build-macros-1.706-1/rpm.macros#L578
>
> apparently kernel compresses themselves and our build automation just 
> searches for "*o" only:
> https://github.com/pld-linux/rpm-build-macros/blob/auto/th/rpm-build-macros-1.706-1/rpm.macros#L574-L583 
>
>

our build automation does only *.o -> .gz:

https://github.com/pld-linux/rpm-build-macros/blob/auto/th/rpm-build-macros-1.706-1/rpm.macros.kernel#L96-L115

so, where should this be continued? make kernel.spec not to compress and 
update rpm-build-macros to use .xz?
or vice versa?

as stripping is done by rpm, and creating -debuginfo, would be wasteful 
to decompress, strip, compress again... (we do so with man pages btw)

-- 
glen



From glen at pld-linux.org  Mon Jan 26 21:14:50 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Mon, 26 Jan 2015 22:14:50 +0200
Subject: xz kernel modules (Re: [packages/kernel] - updated config)
In-Reply-To: <54C69E3C.80102@pld-linux.org>
References: <e26ee53e41dbb757544e2857f019a4e7974f4712_refs_heads_master@pld-linux.org>
 <5fc1b244b3f356be6ea05dd183f0feba7e0c8276_refs_heads_master@pld-linux.org>
 <20141210195939.GA2256@home.lan> <548972B0.1020407@pld-linux.org>
 <20141213104657.GC2241@home.lan> <54C69D6C.1020209@pld-linux.org>
 <54C69E3C.80102@pld-linux.org>
Message-ID: <54C6A03A.7050300@pld-linux.org>

On 26.01.2015 22:06, Elan Ruusam?e wrote:
> On 26.01.2015 22:02, Elan Ruusam?e wrote:
>> i checked build logs and no match for "Stripping kernel modules" [1]:
>> http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=1&ns=&cnt=50&off=0&name=kernel&id=87e395d9-22b0-4451-9554-774e0d2b1444 
>>
>> [1] 
>> https://github.com/pld-linux/rpm-build-macros/blob/auto/th/rpm-build-macros-1.706-1/rpm.macros#L578
>>
>> apparently kernel compresses themselves and our build automation just 
>> searches for "*o" only:
>> https://github.com/pld-linux/rpm-build-macros/blob/auto/th/rpm-build-macros-1.706-1/rpm.macros#L574-L583 
>>
>>
>
> our build automation does only *.o -> .gz:
>
> https://github.com/pld-linux/rpm-build-macros/blob/auto/th/rpm-build-macros-1.706-1/rpm.macros.kernel#L96-L115 
>
>
> so, where should this be continued? make kernel.spec not to compress 
> and update rpm-build-macros to use .xz?
> or vice versa?
>
> as stripping is done by rpm, and creating -debuginfo, would be 
> wasteful to decompress, strip, compress again... (we do so with man 
> pages btw)
>

i've done little bit of research and MODULE_COMPRESS does nothing else 
than invoke "gzip -n" after make install:

[~/rpm/packages/BUILD.x86_64-linux/kernel-3.18.3/linux-3.18] ? grep -r 
MODULE_COMPRESS_XZ .
./Makefile:# or CONFIG_MODULE_COMPRESS_XZ.
./Makefile:  ifdef CONFIG_MODULE_COMPRESS_XZ
./Makefile:  endif # CONFIG_MODULE_COMPRESS_XZ
./init/Kconfig:config MODULE_COMPRESS_XZ

so, i think we should turn it off and adjust rpm-build-macros to do xz 
compression.

ps: kernel /Makefile uses "gzip -n" and "xz":

# CONFIG_MODULE_COMPRESS, if defined, will cause module to be compressed
# after they are installed in agreement with CONFIG_MODULE_COMPRESS_GZIP
# or CONFIG_MODULE_COMPRESS_XZ.

mod_compress_cmd = true
ifdef CONFIG_MODULE_COMPRESS
   ifdef CONFIG_MODULE_COMPRESS_GZIP
     mod_compress_cmd = gzip -n
   endif # CONFIG_MODULE_COMPRESS_GZIP
   ifdef CONFIG_MODULE_COMPRESS_XZ
     mod_compress_cmd = xz
   endif # CONFIG_MODULE_COMPRESS_XZ
endif # CONFIG_MODULE_COMPRESS
export mod_compress_cmd

ps2: init/Kconfig says confirms that the CONFIG_MODULE_COMPRESS does 
nothing else than i already found (.c code is not affected by the option 
value):

config MODULE_COMPRESS
     bool "Compress modules on installation"
     depends on MODULES
     help
       This option compresses the kernel modules when 'make
       modules_install' is run.

       The modules will be compressed either using gzip or xz depend on the
       choice made in "Compression algorithm".

       module-init-tools has support for gzip format while kmod handle gzip
       and xz compressed modules.

       When a kernel module is installed from outside of the main kernel
       source and uses the Kbuild system for installing modules then that
       kernel module will also be compressed when it is installed.

       This option provides little benefit when the modules are to be 
used inside
       an initrd or initramfs, it generally is more efficient to 
compress the whole
       initrd or initramfs instead.

       This is fully compatible with signed modules while the signed 
module is
       compressed. module-init-tools or kmod handles decompression and 
provide to
       other layer the uncompressed but signed payload.

so we need to update run time kmod dependency as baggins updated only 
compile time dependency:
http://git.pld-linux.org/?p=packages/kernel.git;a=commitdiff;h=2910a805af715417c35d6061f5b56f8362158e89

-- 
glen



From glen at pld-linux.org  Mon Jan 26 21:40:35 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Mon, 26 Jan 2015 22:40:35 +0200
Subject: xz kernel modules (Re: [packages/kernel] - updated config)
In-Reply-To: <54C6A03A.7050300@pld-linux.org>
References: <e26ee53e41dbb757544e2857f019a4e7974f4712_refs_heads_master@pld-linux.org>
 <5fc1b244b3f356be6ea05dd183f0feba7e0c8276_refs_heads_master@pld-linux.org>
 <20141210195939.GA2256@home.lan> <548972B0.1020407@pld-linux.org>
 <20141213104657.GC2241@home.lan> <54C69D6C.1020209@pld-linux.org>
 <54C69E3C.80102@pld-linux.org> <54C6A03A.7050300@pld-linux.org>
Message-ID: <54C6A643.1000201@pld-linux.org>

On 26.01.2015 22:14, Elan Ruusam?e wrote:
>
> so we need to update run time kmod dependency as baggins updated only 
> compile time dependency:
> http://git.pld-linux.org/?p=packages/kernel.git;a=commitdiff;h=2910a805af715417c35d6061f5b56f8362158e89 

how this xz compressed modules is supposed to work in pld?

so appears kernel.spec already has "Requires:   kmod >= 12-2" from 
earlier times.
(our kmod.spec has --enable-xz from first submission, not clear which 
kmod version actually supports xz compressed modules)

but, kmod does not depend on xz at all runtime:
$ rpm -q kmod
kmod-19-1.i686
$ rpm -q kmod --requires|grep -c xz
0

kmod is known to build stuff statically, but there is no xz-static in BR 
of kmod.spec.

so... we're just playing on luck everybody have xz installed, or?

-- 
glen



From baggins at pld-linux.org  Tue Jan 27 09:04:28 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 27 Jan 2015 09:04:28 +0100
Subject: xz kernel modules (Re: [packages/kernel] - updated config)
In-Reply-To: <54C6A643.1000201@pld-linux.org>
References: <e26ee53e41dbb757544e2857f019a4e7974f4712_refs_heads_master@pld-linux.org>
 <5fc1b244b3f356be6ea05dd183f0feba7e0c8276_refs_heads_master@pld-linux.org>
 <20141210195939.GA2256@home.lan> <548972B0.1020407@pld-linux.org>
 <20141213104657.GC2241@home.lan> <54C69D6C.1020209@pld-linux.org>
 <54C69E3C.80102@pld-linux.org> <54C6A03A.7050300@pld-linux.org>
 <54C6A643.1000201@pld-linux.org>
Message-ID: <20150127080428.GA4215@home.lan>

On Mon, 26 Jan 2015, Elan Ruusam?e wrote:

> On 26.01.2015 22:14, Elan Ruusam?e wrote:
> >
> > so we need to update run time kmod dependency as baggins updated only 
> > compile time dependency:
> > http://git.pld-linux.org/?p=packages/kernel.git;a=commitdiff;h=2910a805af715417c35d6061f5b56f8362158e89 
> 
> how this xz compressed modules is supposed to work in pld?
> 
> so appears kernel.spec already has "Requires:   kmod >= 12-2" from 
> earlier times.
> (our kmod.spec has --enable-xz from first submission, not clear which 
> kmod version actually supports xz compressed modules)

All of them for proctical purposes.

> but, kmod does not depend on xz at all runtime:
> $ rpm -q kmod
> kmod-19-1.i686
> $ rpm -q kmod --requires|grep -c xz
> 0

xz libs come under lzma name.

$ rpm -ql xz-devel | grep lib
/usr/lib64/liblzma.la
/usr/lib64/liblzma.so
/usr/lib64/pkgconfig/liblzma.pc

$ rpm -q kmod --requires|grep -c lzma
2

> 
> kmod is known to build stuff statically, but there is no xz-static in BR 
> of kmod.spec.
> 
> so... we're just playing on luck everybody have xz installed, or?

Kmod is properly linked wuth xz/lzma:

BuildRequires:? xz-devel >= 1:4.99

$ ldd /sbin/kmod 
	linux-vdso.so.1 (0x00007fffc03de000)
	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fc2271b1000)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	libz.so.1 => /lib64/libz.so.1 (0x00000038b0800000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc226f94000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fc226bed000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fc2273d7000)

Thanks for fixing stripping/compression issue.

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From glen at pld-linux.org  Wed Jan 28 00:43:30 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Wed, 28 Jan 2015 01:43:30 +0200
Subject: build fails due file(1) again
Message-ID: <54C822A2.5050405@pld-linux.org>

this time it fails silently:

+ __spec_install_post_strip
+ set +x
  error: Bad exit status from /tmp/B.129c483e-b190-40b5-9a83-6875372ff3f0/BUILD/tmp/rpm-tmp.84448 (%install)

     RPM build errors:
Bad exit status from /tmp/B.129c483e-b190-40b5-9a83-6875372ff3f0/BUILD/tmp/rpm-tmp.84448 (%install)
  ended at: Wed Jan 28 00:34:51 2015, done in 0:03:11.238332
  error: No files produced.


when looking closely (running with -debug) set -x is invoked and it 
somehow bypasses "exit 1" from file:

Processing files: apache-mod_pagespeed-1.8.31.6-0.29.x86_64
error: magic_file(ms, 
/home/users/glen/tmp/apache-mod_pagespeed-1.8.31.6-root-glen/usr/src/examples/apache-mod_pagespeed-1.8.31
.6/images/Puzzle.jpg) failed: JPEG image data, Exif standard: [TIFF 
image data, big-endian, direntries=13, manufacturer=FUJIFIL
M, model=FinePix F30    , orientation=upper-left, 
orientation=upper-left, xresolution=196, yresolution=204, 
resolutionunit=2, s
oftware=QuickTime 7.1.6, datetime=2007:05:16 11:57:40, hostcomputer=Mac 
OS X 10.4.9, copyright=    ], baseline, precision 8, 10
23x766, frames 3, comment: "AppleMark", baseline, precision 8, 1023x766, 
frames 3name use count (30) exceeded
error: magic_file(ms, 
/home/users/glen/tmp/apache-mod_pagespeed-1.8.31.6-root-glen/usr/src/examples/apache-mod_pagespeed-1.8.31
.6/images/blocking_rewrite_test_dont_reuse_1.jpg) failed: JPEG image 
data, Exif standard: [TIFF image data, big-endian, direntr
ies=13, manufacturer=FUJIFILM, model=FinePix F30    , 
orientation=upper-left, orientation=upper-left, xresolution=196, yresolut
ion=204, resolutionunit=2, software=QuickTime 7.1.6, datetime=2007:05:16 
11:57:40, hostcomputer=Mac OS X 10.4.9, copyright=
], baseline, precision 8, 1023x766, frames 3, comment: "AppleMark", 
baseline, precision 8, 1023x766, frames 3name use count (30
) exceeded
error: magic_file(ms, 
/home/users/glen/tmp/apache-mod_pagespeed-1.8.31.6-root-glen/usr/src/examples/apache-mod_pagespeed-1.8.31
.6/images/blocking_rewrite_test_dont_reuse_2.jpg) failed: JPEG image 
data, Exif standard: [TIFF image data, big-endian, direntr
ies=13, manufacturer=FUJIFILM, model=FinePix F30    , 
orientation=upper-left, orientation=upper-left, xresolution=196, yresolut
ion=204, resolutionunit=2, software=QuickTime 7.1.6, datetime=2007:05:16 
11:57:40, hostcomputer=Mac OS X 10.4.9, copyright=    ], baseline, 
precision 8, 1023x766, frames 3, comment: "AppleMark", baseline, 
precision 8, 1023x766, frames 3name use count (30) exceeded
skipping /usr/src/examples/apache-mod_pagespeed-1.8.31.6 requires detection

$ file 
/home/users/glen/tmp/apache-mod_pagespeed-1.8.31.6-root-glen/usr/src/examples/apache-mod_pagespeed-1.8.31.6/images/Puzzle.jpg 

/home/users/glen/tmp/apache-mod_pagespeed-1.8.31.6-root-glen/usr/src/examples/apache-mod_pagespeed-1.8.31.6/images/Puzzle.jpg: 
ERROR: JPEG image data, Exif standard: [TIFF image data, big-endian, 
direntries=13, manufacturer=FUJIFILM, model=FinePix F30    , 
orientation=upper-left, orientation=upper-left, xresolution=196, 
yresolution=204, resolutionunit=2, software=QuickTime 7.1.6, 
datetime=2007:05:16 11:57:40, hostcomputer=Mac OS X 10.4.9, 
copyright=    ], baseline, precision 8, 1023x766, frames 3, comment: 
"AppleMark", baseline, precision 8, 1023x766, frames 3name use count 
(30) exceeded
$ echo $?
1
$ rpm -q file
file-5.22-1.x86_64

imho files in %{_examplesdir} shouldn't be scanned for strip at all...

should we also try to increase name use count to be bigger than 30?
http://mx.gw.com/pipermail/file/2014/001643.html

-- 
glen



From baggins at pld-linux.org  Sat Jan 31 12:35:28 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 31 Jan 2015 12:35:28 +0100
Subject: The future of i486 arch in Th
In-Reply-To: <20141215202445.GA26612@pldmachine.domain_not_set.invalid>
References: <20141215200158.GA2254@home.lan>
 <20141215202445.GA26612@pldmachine.domain_not_set.invalid>
Message-ID: <20150131113527.GA2442@home.lan>

On Mon, 15 Dec 2014, Witold Filipczyk wrote:

> On Mon, Dec 15, 2014 at 09:01:58PM +0100, Jan R?korajski wrote:
> > TL;DR Future of i486 is bleak, it's a strong candidate for removal.
> > 
> > Proposal: remove i486 from Th.
> > 
> > Rationale:
> > 
> > It's increasingly more problematic to get everything built on i486, some
> > packages explicitly say "no" to this arch, some require hacks and
> > strange workarounds, and other just silently fail in mysterious ways.
> > All this makes maintainability cost of i486 very high, and combined
> > with the size of userbase, overly high.
> > 
> > Some usage stats from the Sun Nov 16 - Sun Dec 14 period, from
> > ftp1.pld-linux.org:
> > 
> > # zgrep x86_64 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n | wc -l
> > 533
> > 
> > # zgrep i686 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n | wc -l
> > 730
> > 
> > # zgrep i486 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n | wc -l
> > 20
> > 
> > # zgrep i486 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n
> > [exact IPs removed to protect privacy]
> >       < 10		4 IPs
> >       < 50		4 IPs
> >       < 100		4 IPs
> >       < 1000		7 IPs
> >       > 1000		1 IP
> > 
> > As you can see there are 20 distinct users of i486, out of which
> > maybe 5 really use this arch.
> > 
> > Due to higher workload i486 arch requires compared to anything else and
> > symbolic userbase, I propose to drop it from Th.
> > 
> > Comments?
> > 
> > PS. we can use former i486 builder for x32 port if there will be takers.
> 
> Kernel build for non-PAE i686 is what I want.

Will be there today on i686, but only for head, so no vserver.

-- 
Jan R?korajski                    | PLD/Linux
SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/


From witekfl001 at gmail.com  Sat Jan 31 17:46:20 2015
From: witekfl001 at gmail.com (Witold Filipczyk)
Date: Sat, 31 Jan 2015 17:46:20 +0100
Subject: The future of i486 arch in Th
In-Reply-To: <20150131113527.GA2442@home.lan>
References: <20141215200158.GA2254@home.lan>
 <20141215202445.GA26612@pldmachine.domain_not_set.invalid>
 <20150131113527.GA2442@home.lan>
Message-ID: <20150131164620.GA1732@pldmachine.domain_not_set.invalid>

On Sat, Jan 31, 2015 at 12:35:28PM +0100, Jan R?korajski wrote:
> On Mon, 15 Dec 2014, Witold Filipczyk wrote:
> > 
> > Kernel build for non-PAE i686 is what I want.
> 
> Will be there today on i686, but only for head, so no vserver.

Thanks.