From baggins at pld-linux.org  Tue Feb  3 12:19:44 2015
From: baggins at pld-linux.org (=?UTF-8?Q?Jan_R=C4=99korajski?=)
Date: Tue, 3 Feb 2015 12:19:44 +0100
Subject: [packages/nvidiabl] wtf you just disable dkms completely!?, added
 it back. not tested with your "kernel" framework!
In-Reply-To: <5f8872fe0e5cf21b91f24ceaff593d920cd588bd_refs_heads_master@pld-linux.org>
References: <f994bcd65a872e8b04e4d91650d622e205483477_refs_heads_master@pld-linux.org>
 <5f8872fe0e5cf21b91f24ceaff593d920cd588bd_refs_heads_master@pld-linux.org>
Message-ID: <CAKY5yHx0xNNO+D+WUYn7k8KxWZNkBDRC5V8fdZby0vidri05cg@mail.gmail.com>

If you're adding userspace bcond, you also have to add kernel bcond,
See template spec for how it works, and it worked this way forever,
it's not "my kernel".

On Tue, Feb 3, 2015 at 10:16 AM, glen <glen at pld-linux.org> wrote:
> commit 5f8872fe0e5cf21b91f24ceaff593d920cd588bd
> Author: Elan Ruusam?e <glen at delfi.ee>
> Date:   Tue Feb 3 11:16:46 2015 +0200
>
>     wtf you just disable dkms completely!?, added it back. not tested with your "kernel" framework!
>
>  nvidiabl.spec | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> ---
> diff --git a/nvidiabl.spec b/nvidiabl.spec
> index f69953b..eb3f9a2 100644
> --- a/nvidiabl.spec
> +++ b/nvidiabl.spec
> @@ -1,7 +1,12 @@
>  #
>  # Conditional build:
>  %bcond_without verbose         # verbose build (V=1)
> -%bcond_with    dkms            # build dkms package
> +%bcond_without userspace       # don't build userspace programs
> +%bcond_without dkms            # build dkms package
> +
> +%if %{without userspace}
> +%undefine      with_dkms
> +%endif
>
>  # nothing to be placed to debuginfo package
>  %define                _enable_debug_packages  0
> ================================================================
>
> ---- gitweb:
>
> http://git.pld-linux.org/gitweb.cgi/packages/nvidiabl.git/commitdiff/5f8872fe0e5cf21b91f24ceaff593d920cd588bd
>
> _______________________________________________
> pld-cvs-commit mailing list
> pld-cvs-commit at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit



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


From gotar at polanet.pl  Sat Feb  7 14:52:49 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Sat, 7 Feb 2015 14:52:49 +0100
Subject: MIT kerberos vs heimdal
Message-ID: <20150207135249.GA4232@polanet.pl>

Anyone knows/remembers why did we choose heimdal over MIT? I assume
there were some reasons behind this decision (besides "let's do this in
a different way"), however I'm not sure if they are still valid (e.g.
missing features might have been added, someone might have taken over
abandoned maintaining etc.)

The only note I could find is krb5.spec header, so I'm worried that
current state is drived by inertia only, as every mainstream I
peek uses MIT. Heimdal OTOH requires some patching like:

http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2012-October/155947.html
http://comments.gmane.org/gmane.linux.redhat.sssd.devel/7886

I need my KDC to interact with non-PLD MIT-based Linux systems (fortunatelly
without any samba) and I prefer to have MIT password policies (LDAP
integration to use ppolicy requires non-reliable scripting anyway).

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


From arekm at maven.pl  Sat Feb  7 16:42:17 2015
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Sat, 7 Feb 2015 16:42:17 +0100
Subject: MIT kerberos vs heimdal
In-Reply-To: <20150207135249.GA4232@polanet.pl>
References: <20150207135249.GA4232@polanet.pl>
Message-ID: <201502071642.17345.arekm@maven.pl>

On Saturday 07 of February 2015, Tomasz Pala wrote:
> Anyone knows/remembers why did we choose heimdal over MIT? 

IPv6 support I guess.

-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )


From gotar at polanet.pl  Sat Feb  7 17:37:31 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Sat, 7 Feb 2015 17:37:31 +0100
Subject: MIT kerberos vs heimdal
In-Reply-To: <201502071642.17345.arekm@maven.pl>
References: <20150207135249.GA4232@polanet.pl>
 <201502071642.17345.arekm@maven.pl>
Message-ID: <20150207163731.GA11165@polanet.pl>

On Sat, Feb 07, 2015 at 16:42:17 +0100, Arkadiusz Mi?kiewicz wrote:

>> Anyone knows/remembers why did we choose heimdal over MIT? 
> 
> IPv6 support I guess.

According to http://k5wiki.kerberos.org/wiki/IPv6 and

http://web.mit.edu/kerberos/krb5-1.12/doc/mitK5features.html

supported since 1.9. This was an issue 12 years ago

http://kerberos.mit.narkive.com/4KSSxTp8/ipv6-support-in-mit-kerberos

- if so, shouldn't we reconsider? Last heimdal 1.5.2 was released
3 years ago, while krb5 1.13 is 3.8 months old.

https://www.freebsd.org/doc/handbook/kerberos5.html

"The Heimdal Kerberos implementation was explicitly developed outside of
the US to avoid export regulations."

http://www.h5l.org/

"Heimdal is an implementation of Kerberos 5 (and some more stuff)
largely written in Sweden (which was important when we started writing
it, less so now)."

It seems heimdal is obsoleted. MIT is definitely not.

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


From baggins at pld-linux.org  Sat Feb  7 17:38:39 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 7 Feb 2015 17:38:39 +0100
Subject: MIT kerberos vs heimdal
In-Reply-To: <201502071642.17345.arekm@maven.pl>
References: <20150207135249.GA4232@polanet.pl>
 <201502071642.17345.arekm@maven.pl>
Message-ID: <20150207163839.GA2507@home.lan>

On Sat, 07 Feb 2015, Arkadiusz Mi?kiewicz wrote:

> On Saturday 07 of February 2015, Tomasz Pala wrote:
> > Anyone knows/remembers why did we choose heimdal over MIT? 
> 
> IPv6 support I guess.

That was old reason, last time I checked MIT did not have LDAP
and Samba support. Also no Samba flavor ever built with MIT,
and that's crucial now Samba is a real AD server. Just read README.dc
from Fedora's samba package, it's so pathetic it still makes me
laugh my ass off.
That were the reasons we switched to Heimdal.

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


From gotar at polanet.pl  Sat Feb  7 18:15:24 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Sat, 7 Feb 2015 18:15:24 +0100
Subject: MIT kerberos vs heimdal
In-Reply-To: <20150207163839.GA2507@home.lan>
References: <20150207135249.GA4232@polanet.pl>
 <201502071642.17345.arekm@maven.pl>
 <20150207163839.GA2507@home.lan>
Message-ID: <20150207171524.GA9465@polanet.pl>

On Sat, Feb 07, 2015 at 17:38:39 +0100, Jan R?korajski wrote:

> That was old reason, last time I checked MIT did not have LDAP
> and Samba support. Also no Samba flavor ever built with MIT,

It still doesn't have smbk5pwd if that is what you meant, but honestly I don't
understand what is this all about (I don't use AD). Well, more than
written here: https://lists.debian.org/debian-edu/2010/05/msg00019.html
But there is LDAP backend:
http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_ldap.html

Oh, and I've just found this thread:
http://www.openldap.org/lists/openldap-technical/201402/msg00197.html
pointing to https://github.com/opinsys/smbkrb5pwd

> and that's crucial now Samba is a real AD server. Just read README.dc
> from Fedora's samba package, it's so pathetic it still makes me
> laugh my ass off.
>
> That were the reasons we switched to Heimdal.

How can I set default and user password policy using Heimdal without
LDAP (I won't put passwords into public directory designed for
authorization not authentication)? I need plain authentication service,
no LDAP and no SASL involved.

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


From baggins at pld-linux.org  Sat Feb  7 18:44:48 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 7 Feb 2015 18:44:48 +0100
Subject: MIT kerberos vs heimdal
In-Reply-To: <20150207171524.GA9465@polanet.pl>
References: <20150207135249.GA4232@polanet.pl>
 <201502071642.17345.arekm@maven.pl>
 <20150207163839.GA2507@home.lan> <20150207171524.GA9465@polanet.pl>
Message-ID: <20150207174432.GB2507@home.lan>

On Sat, 07 Feb 2015, Tomasz Pala wrote:

> On Sat, Feb 07, 2015 at 17:38:39 +0100, Jan R?korajski wrote:
> 
> > That was old reason, last time I checked MIT did not have LDAP
> > and Samba support. Also no Samba flavor ever built with MIT,
> 
> It still doesn't have smbk5pwd if that is what you meant, but honestly I don't
> understand what is this all about (I don't use AD). Well, more than
> written here: https://lists.debian.org/debian-edu/2010/05/msg00019.html
> But there is LDAP backend:
> http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_ldap.html
> 
> Oh, and I've just found this thread:
> http://www.openldap.org/lists/openldap-technical/201402/msg00197.html
> pointing to https://github.com/opinsys/smbkrb5pwd

Wow, 10 years after Heimdal? And it still looks like it needs some hackery.
But that's not the point, you missed the most important issue (system
MIT makes samba4 useless):

> > and that's crucial now Samba is a real AD server. Just read README.dc
> > from Fedora's samba package, it's so pathetic it still makes me
> > laugh my ass off.
> >
> > That were the reasons we switched to Heimdal.


> How can I set default and user password policy using Heimdal without
> LDAP (I won't put passwords into public directory designed for
> authorization not authentication)? I need plain authentication service,
> no LDAP and no SASL involved.

Never used standalone KDC, always had LDAP backend. Try this:
http://kerberos.996246.n3.nabble.com/Password-Quality-Checking-td10147.html
I assume you read this:
http://www.h5l.org/manual/HEAD/info/heimdal/Password-changing.html

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


From gotar at polanet.pl  Sat Feb  7 23:21:26 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Sat, 7 Feb 2015 23:21:26 +0100
Subject: MIT kerberos vs heimdal
In-Reply-To: <20150207174432.GB2507@home.lan>
References: <20150207135249.GA4232@polanet.pl>
 <201502071642.17345.arekm@maven.pl>
 <20150207163839.GA2507@home.lan> <20150207171524.GA9465@polanet.pl>
 <20150207174432.GB2507@home.lan>
Message-ID: <20150207222126.GA11482@polanet.pl>

On Sat, Feb 07, 2015 at 18:44:48 +0100, Jan R?korajski wrote:

>> Oh, and I've just found this thread:
>> http://www.openldap.org/lists/openldap-technical/201402/msg00197.html
>> pointing to https://github.com/opinsys/smbkrb5pwd
> 
> Wow, 10 years after Heimdal?

Kerberos was designed for authentication, not directory services, so you
shouldn't 'wow' this feature - blame samba for being such a lame AD
replacement. I see no point in keeping credentials in LDAP, this is
IMHO against both LDAP (permit reading everything by default, needs some
fancy ACLs to restrict public information) and KDC (credentials should
not leave ticket granting system in ANY way). Or blame AD for being such
a misdesign, dunno - KDC and LDAP should not ever talk to each other
(with one obvious exception - authenticating user for LDAP access itself).
Or ...why don't you blame OpenLDAP for missing MIT-updater? It's weird,
that every LDAP-related solution is flawned - you can't have HTTP digest
auth with LDAP, because LDAP userPassword would need to be plaintext?
Wrong, apache could store the same data as htdigest stores and fetch
them using his own user (with ACLs protecting this attribute the same
way as userPassword is, and some overlay to update when main user
password changes). After all, there is squild-ldap auth helper (https
proxy is relatively new solution, doing basic http auth without SSL is
not an option). Authenticating user upon successful LDAP bind is
ridiculous (ok, there is authorization using search, still lame).
Seems to me that entire LDAP business is a kludge...

Nevermind, there is smbkrb5pwd '10 years after Heimdal' so we might get
back to MIT '3 years after last Heimdal release', don't we?

> And it still looks like it needs some hackery.

Elaborate please - I've seen many documents on integrating heimdal with
LDAP and it was all one big hackery, what's the difference with above?

> But that's not the point, you missed the most important issue (system
> MIT makes samba4 useless):

Elaborate please - I see all the parts in the same places in both
systems. What exactly is missing?

>> > and that's crucial now Samba is a real AD server. Just read README.dc
>> > from Fedora's samba package, it's so pathetic it still makes me
>> > laugh my ass off.
>> >
>> > That were the reasons we switched to Heimdal.

Wasn't that the reason THEY have created FreeIPA for AD?

>> How can I set default and user password policy using Heimdal without
>> LDAP (I won't put passwords into public directory designed for
>> authorization not authentication)? I need plain authentication service,
>> no LDAP and no SASL involved.
> 
> Never used standalone KDC, always had LDAP backend. Try this:
> http://kerberos.996246.n3.nabble.com/Password-Quality-Checking-td10147.html

That's not a solution - is is only password strength check, not a policy;
at least password reuse and account lockout is required.

> I assume you read this:
> http://www.h5l.org/manual/HEAD/info/heimdal/Password-changing.html

Yes, ...that's why I've started digging on MIT. Or going towards LDAP
(for ppolicy), but it seems it's too hackish as well.

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


From gotar at polanet.pl  Sat Feb  7 23:38:44 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Sat, 7 Feb 2015 23:38:44 +0100
Subject: MIT kerberos vs heimdal
In-Reply-To: <20150207222126.GA11482@polanet.pl>
References: <20150207135249.GA4232@polanet.pl>
 <201502071642.17345.arekm@maven.pl>
 <20150207163839.GA2507@home.lan> <20150207171524.GA9465@polanet.pl>
 <20150207174432.GB2507@home.lan>
 <20150207222126.GA11482@polanet.pl>
Message-ID: <20150207223844.GB11482@polanet.pl>

Whatever, let's assume some require heimdal, some MIT. What's the
problem in having them both on ftp? Client libraries should be
compatible (i.e. heimdal client works with MIT server, that's the point
of having a 'protocol'). Incompatible parts are kadmin and probably
the rest of server stuff - heimdal package is divided accordingly
already, krb5 have libkadm5{clnt,srv}_mit and libgssapi_krb5 (suffixed),
the only conflicting library I see is libkrb5.so itself, but has
different SOVER.

What would happen with your heimdal server if we changed heimdal-devel
to krb5-devel and rebuild everything? Shouldn't this keep working?

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


From baggins at pld-linux.org  Sun Feb  8 11:36:42 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 8 Feb 2015 11:36:42 +0100
Subject: MIT kerberos vs heimdal
In-Reply-To: <20150207222126.GA11482@polanet.pl>
References: <20150207135249.GA4232@polanet.pl>
 <201502071642.17345.arekm@maven.pl>
 <20150207163839.GA2507@home.lan> <20150207171524.GA9465@polanet.pl>
 <20150207174432.GB2507@home.lan>
 <20150207222126.GA11482@polanet.pl>
Message-ID: <20150208103641.GC2507@home.lan>

On Sat, 07 Feb 2015, Tomasz Pala wrote:

> On Sat, Feb 07, 2015 at 18:44:48 +0100, Jan R?korajski wrote:
> 
> >> Oh, and I've just found this thread:
> >> http://www.openldap.org/lists/openldap-technical/201402/msg00197.html
> >> pointing to https://github.com/opinsys/smbkrb5pwd
> > 
> > Wow, 10 years after Heimdal?
> 
> Kerberos was designed for authentication, not directory services, so you
> shouldn't 'wow' this feature - blame samba for being such a lame AD
> replacement. I see no point in keeping credentials in LDAP, this is
> IMHO against both LDAP (permit reading everything by default, needs some
> fancy ACLs to restrict public information) and KDC (credentials should
> not leave ticket granting system in ANY way). Or blame AD for being such
> a misdesign, dunno - KDC and LDAP should not ever talk to each other
> (with one obvious exception - authenticating user for LDAP access itself).
> Or ...why don't you blame OpenLDAP for missing MIT-updater? It's weird,
> that every LDAP-related solution is flawned - you can't have HTTP digest
> auth with LDAP, because LDAP userPassword would need to be plaintext?
> Wrong, apache could store the same data as htdigest stores and fetch
> them using his own user (with ACLs protecting this attribute the same
> way as userPassword is, and some overlay to update when main user
> password changes). After all, there is squild-ldap auth helper (https
> proxy is relatively new solution, doing basic http auth without SSL is
> not an option). Authenticating user upon successful LDAP bind is
> ridiculous (ok, there is authorization using search, still lame).
> Seems to me that entire LDAP business is a kludge...
> 
> Nevermind, there is smbkrb5pwd '10 years after Heimdal' so we might get
> back to MIT '3 years after last Heimdal release', don't we?

Don't forget about LDAP backend. You don't like it, MIT folks were
making the same arguments as you just now (separate auth and acct),
but they got real and finally added that backend.

> > And it still looks like it needs some hackery.
> 
> Elaborate please - I've seen many documents on integrating heimdal with
> LDAP and it was all one big hackery, what's the difference with above?

The links you sent looked like some proud story about hacking the world
of MIT krb5 to work with ldap/samba. Maybe I misread it.

> > But that's not the point, you missed the most important issue (system
> > MIT makes samba4 useless):
> 
> Elaborate please - I see all the parts in the same places in both
> systems. What exactly is missing?

APIs and ABIs in Heimdal and MIT are different. Samba uses Heimdal to do
AD DC kerberos. It does not build with MIT. Fedora distributes samba4
without Kerberos, makeing it effectively a samba3 PDC. The whole point
of samba4 is it being full fledged MS AD DC. Is that explanation clear enough?

> >> > and that's crucial now Samba is a real AD server. Just read README.dc
> >> > from Fedora's samba package, it's so pathetic it still makes me
> >> > laugh my ass off.
> >> >
> >> > That were the reasons we switched to Heimdal.
> 
> Wasn't that the reason THEY have created FreeIPA for AD?

Who are THEY?

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


From baggins at pld-linux.org  Sun Feb  8 11:41:41 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 8 Feb 2015 11:41:41 +0100
Subject: MIT kerberos vs heimdal
In-Reply-To: <20150207223844.GB11482@polanet.pl>
References: <20150207135249.GA4232@polanet.pl>
 <201502071642.17345.arekm@maven.pl>
 <20150207163839.GA2507@home.lan> <20150207171524.GA9465@polanet.pl>
 <20150207174432.GB2507@home.lan>
 <20150207222126.GA11482@polanet.pl>
 <20150207223844.GB11482@polanet.pl>
Message-ID: <20150208104141.GD2507@home.lan>

On Sat, 07 Feb 2015, Tomasz Pala wrote:

> Whatever, let's assume some require heimdal, some MIT. What's the
> problem in having them both on ftp? Client libraries should be
> compatible (i.e. heimdal client works with MIT server, that's the point
> of having a 'protocol'). Incompatible parts are kadmin and probably
> the rest of server stuff - heimdal package is divided accordingly
> already, krb5 have libkadm5{clnt,srv}_mit and libgssapi_krb5 (suffixed),
> the only conflicting library I see is libkrb5.so itself, but has
> different SOVER.

You are mistaking protocol, API and ABI.
Protocol is the same, Heimdal has no problems at all taking to MIT and
vice versa. But if you try to run program linked with one in presence of
a library from other, things may go nasty.

> What would happen with your heimdal server if we changed heimdal-devel
> to krb5-devel and rebuild everything? Shouldn't this keep working?

No. As I said, ABI is different, just look at 'heimdal' patches in repo,
MIT has some fancy functions Heimdal doesn't.

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


From glen at delfi.ee  Tue Feb 10 21:46:44 2015
From: glen at delfi.ee (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Tue, 10 Feb 2015 22:46:44 +0200
Subject: rpm -Va BAD, key ID
In-Reply-To: <54B5481A.2060000@pld-linux.org>
References: <54B5481A.2060000@pld-linux.org>
Message-ID: <54DA6E34.5010400@delfi.ee>

On 13.01.2015 18:30, Elan Ruusam?e wrote:
> rpm -Va emits such messages:
>
>   error: rpmdb (h#123): Header V4 DSA signature: BAD, key ID e4f1bc2d 
so, what's our fix for pld? this regression is ugly!

if not going to fix this, at least put assert(1!=0) so end users won't 
be confused like rpm db is corrupted,
as if you are going to do rpm repair with that rpm 5.4.15, things will 
get very worse.

-- 
glen



From n3npq at me.com  Tue Feb 10 23:40:02 2015
From: n3npq at me.com (Jeffrey Johnson)
Date: Tue, 10 Feb 2015 17:40:02 -0500
Subject: rpm -Va BAD, key ID
In-Reply-To: <54DA6E34.5010400@delfi.ee>
References: <54B5481A.2060000@pld-linux.org> <54DA6E34.5010400@delfi.ee>
Message-ID: <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com>


> On Feb 10, 2015, at 3:46 PM, Elan Ruusam?e <glen at delfi.ee> wrote:
> 
> On 13.01.2015 18:30, Elan Ruusam?e wrote:
>> rpm -Va emits such messages:
>> 
>>  error: rpmdb (h#123): Header V4 DSA signature: BAD, key ID e4f1bc2d 
> so, what's our fix for pld? this regression is ugly!
> 

So disable header signature verification in lib/verify.c. The behavior is relatively
new and has been disabled before.

> if not going to fix this, at least put assert(1!=0) so end users won't be confused like rpm db is corrupted,

I can?t fix what I cannot reproduce.

For starters, that is an RSA. not a DSA key, when looked up on key servers.

> as if you are going to do rpm repair with that rpm 5.4.15, things will get very worse.
> 

So disable signature checking on retrieved headers using rpm -Va in lib/verify.c and be happy.

73 de Jeff
> -- 
> glen
> 
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en



From glen at pld-linux.org  Wed Feb 11 11:10:30 2015
From: glen at pld-linux.org (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Wed, 11 Feb 2015 12:10:30 +0200
Subject: rpm -Va BAD, key ID
In-Reply-To: <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com>
References: <54B5481A.2060000@pld-linux.org> <54DA6E34.5010400@delfi.ee>
 <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com>
Message-ID: <54DB2A96.3000200@pld-linux.org>

On 11.02.2015 00:40, Jeffrey Johnson wrote:
> I can?t fix what I cannot reproduce.
as i see it, you do not want to reproduce it. i gave you links to vm's, 
did you even download them?

-- 
glen



From glen at pld-linux.org  Wed Feb 11 11:13:10 2015
From: glen at pld-linux.org (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Wed, 11 Feb 2015 12:13:10 +0200
Subject: rpm -Va BAD, key ID
In-Reply-To: <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com>
References: <54B5481A.2060000@pld-linux.org> <54DA6E34.5010400@delfi.ee>
 <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com>
Message-ID: <54DB2B36.6070805@pld-linux.org>

On 11.02.2015 00:40, Jeffrey Johnson wrote:
>> >On Feb 10, 2015, at 3:46 PM, Elan Ruusam?e<glen at delfi.ee>  wrote:
>> >
>> >On 13.01.2015 18:30, Elan Ruusam?e wrote:
>>> >>rpm -Va emits such messages:
>>> >>
>>> >>  error: rpmdb (h#123): Header V4 DSA signature: BAD, key ID e4f1bc2d
>> >so, what's our fix for pld? this regression is ugly!
>> >
> So disable header signature verification in lib/verify.c. The behavior is relatively
> new and has been disabled before.
>

i do not see what to disable, there are no functional changes since 
5.4.14 to the file you point out

--- ../BUILD.x86_64-linux/rpm-5.4.14/lib/verify.c    2015-02-11 
12:09:16.006002736 +0200
+++ ../BUILD.x86_64-linux/rpm-5.4.15/lib/verify.c    2015-02-11 
12:07:41.927799212 +0200
@@ -182,7 +182,7 @@
  /** \ingroup rpmcli
   * Verify file attributes (including file digest).
   * @param vf        file data to verify
- * #param spew        should verify results be printed?
+ * @param spew        should verify results be printed?
   * @return        0 on success (or not installed), 1 on error
   */
  static int rpmvfVerify(rpmvf vf, int spew)
@@ -597,7 +597,6 @@
          continue;

      /* If not verifying %ghost, skip ghost files. */
-    /* XXX the broken!!! logic disables %ghost queries always. */
      if (FF_ISSET(qva->qva_fflags, GHOST) && FF_ISSET(fflags, GHOST))
          continue;

(END)


-- 
glen



From n3npq at me.com  Wed Feb 11 14:23:49 2015
From: n3npq at me.com (Jeffrey Johnson)
Date: Wed, 11 Feb 2015 08:23:49 -0500
Subject: rpm -Va BAD, key ID
In-Reply-To: <54DB2A96.3000200@pld-linux.org>
References: <54B5481A.2060000@pld-linux.org> <54DA6E34.5010400@delfi.ee>
 <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com> <54DB2A96.3000200@pld-linux.org>
Message-ID: <AFE8CE89-8BAF-4B4F-8110-384AD1D11F3B@me.com>


On Feb 11, 2015, at 5:10 AM, Elan Ruusam?e wrote:

> On 11.02.2015 00:40, Jeffrey Johnson wrote:
>> I can?t fix what I cannot reproduce.
> as i see it, you do not want to reproduce it. i gave you links to vm's, did you even download them?
> 

You gave me a link to the pubkey

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

and the rpm -Vavv output

> 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 is insufficient information to diagnose your problem.

DIsable the header signature checking with rpm -Va by removing the lines below in lib/verify.c



73 de Jeff

===========================================
    /* Verify header digest/signature. */
    if (qva->qva_flags & (VERIFY_DIGEST | VERIFY_SIGNATURE))
    {
        const char * horigin = headerGetOrigin(h);
        const char * msg = NULL;
        size_t uhlen = 0;
        void * uh = headerUnload(h, &uhlen);
        int lvl = headerCheck(rpmtsDig(ts), uh, uhlen, &msg) == RPMRC_FAIL
                ? RPMLOG_ERR : RPMLOG_DEBUG;
        rpmlog(lvl, "%s: %s\n",
                (horigin ? horigin : "verify"), (msg ? msg : ""));
        rpmtsCleanDig(ts);
        uh = _free(uh);
        msg = _free(msg);
    }



From n3npq at me.com  Wed Feb 11 14:45:46 2015
From: n3npq at me.com (Jeffrey Johnson)
Date: Wed, 11 Feb 2015 08:45:46 -0500
Subject: rpm -Va BAD, key ID
In-Reply-To: <54DB2A96.3000200@pld-linux.org>
References: <54B5481A.2060000@pld-linux.org> <54DA6E34.5010400@delfi.ee>
 <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com> <54DB2A96.3000200@pld-linux.org>
Message-ID: <752FEE39-CE78-42FB-9867-E5D7B8B849AF@me.com>


On Feb 11, 2015, at 5:10 AM, Elan Ruusam?e wrote:

> On 11.02.2015 00:40, Jeffrey Johnson wrote:
>> I can?t fix what I cannot reproduce.
> as i see it, you do not want to reproduce it. i gave you links to vm's, did you even download them?
> 

And you gave me this

> 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

with no further instructions.

I am not able to run your vm's here,  nor can I meaningfully
diagnose a problem that I cannot map back to sources
in my development environment.

73 de Jeff

From glen at delfi.ee  Wed Feb 11 14:59:10 2015
From: glen at delfi.ee (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Wed, 11 Feb 2015 15:59:10 +0200
Subject: rpm -Va BAD, key ID
In-Reply-To: <752FEE39-CE78-42FB-9867-E5D7B8B849AF@me.com>
References: <54B5481A.2060000@pld-linux.org> <54DA6E34.5010400@delfi.ee>
 <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com>
 <54DB2A96.3000200@pld-linux.org>
 <752FEE39-CE78-42FB-9867-E5D7B8B849AF@me.com>
Message-ID: <54DB602E.2070600@delfi.ee>

On 11.02.2015 15:45, Jeffrey Johnson wrote:
> On Feb 11, 2015, at 5:10 AM, Elan Ruusam?e wrote:
>
>> On 11.02.2015 00:40, Jeffrey Johnson wrote:
>>> I can?t fix what I cannot reproduce.
>> as i see it, you do not want to reproduce it. i gave you links to vm's, did you even download them?
>>
> And you gave me this
>
>> 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
> with no further instructions.
>
> I am not able to run your vm's here,  nor can I meaningfully
> diagnose a problem that I cannot map back to sources
> in my development environment.

https://www.google.ee/search?q=vagrant

if for some reason vagrant or virtualbox is out of question,
you can covert to qemu format these. more info:
https://www.pld-linux.org/people/glen/vm-info

-- 
glen



From n3npq at me.com  Wed Feb 11 15:06:21 2015
From: n3npq at me.com (Jeffrey Johnson)
Date: Wed, 11 Feb 2015 09:06:21 -0500
Subject: rpm -Va BAD, key ID
In-Reply-To: <54DB602E.2070600@delfi.ee>
References: <54B5481A.2060000@pld-linux.org> <54DA6E34.5010400@delfi.ee>
 <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com> <54DB2A96.3000200@pld-linux.org>
 <752FEE39-CE78-42FB-9867-E5D7B8B849AF@me.com> <54DB602E.2070600@delfi.ee>
Message-ID: <66476968-555F-470C-97D1-C15854D4EC95@me.com>


On Feb 11, 2015, at 8:59 AM, Elan Ruusam?e wrote:

> On 11.02.2015 15:45, Jeffrey Johnson wrote:
>> On Feb 11, 2015, at 5:10 AM, Elan Ruusam?e wrote:
>> 
>>> On 11.02.2015 00:40, Jeffrey Johnson wrote:
>>>> I can?t fix what I cannot reproduce.
>>> as i see it, you do not want to reproduce it. i gave you links to vm's, did you even download them?
>>> 
>> And you gave me this
>> 
>>> 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
>> with no further instructions.
>> 
>> I am not able to run your vm's here,  nor can I meaningfully
>> diagnose a problem that I cannot map back to sources
>> in my development environment.
> 
> https://www.google.ee/search?q=vagrant
> 
> if for some reason vagrant or virtualbox is out of question,
> you can covert to qemu format these. more info:
> https://www.pld-linux.org/people/glen/vm-info
> 

I know what both vagrant and qemu are.

I run VMFusion on Mac OS X in my development environment.

Meanwhile -- as a developer -- I need to to be able to build from source
and diagnose/repair the problem. I cannot do that from a pile of vm bits in
either vagrant nor qemu format.

I do not doubt what you are seeing. I have suggested a workaround (removing
the header signature check) in order to start identifying where the problem lies.

Have you tried removing the header signature check?

Does the problem go away or not?

73 de Jeff
> -- 
> glen
> 
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en



From glen at pld-linux.org  Wed Feb 11 18:48:30 2015
From: glen at pld-linux.org (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Wed, 11 Feb 2015 19:48:30 +0200
Subject: rpm -Va BAD, key ID
In-Reply-To: <AFE8CE89-8BAF-4B4F-8110-384AD1D11F3B@me.com>
References: <54B5481A.2060000@pld-linux.org> <54DA6E34.5010400@delfi.ee>
 <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com>
 <54DB2A96.3000200@pld-linux.org>
 <AFE8CE89-8BAF-4B4F-8110-384AD1D11F3B@me.com>
Message-ID: <54DB95EE.7040503@pld-linux.org>

On 11.02.2015 15:23, Jeffrey Johnson wrote:
> DIsable the header signature checking with rpm -Va by removing the lines below in lib/verify.c
>
>
>
> 73 de Jeff
>
> ===========================================
>      /* Verify header digest/signature. */
>      if (qva->qva_flags & (VERIFY_DIGEST | VERIFY_SIGNATURE))
>      {
>          const char * horigin = headerGetOrigin(h);
>          const char * msg = NULL;
>          size_t uhlen = 0;
>          void * uh = headerUnload(h, &uhlen);
>          int lvl = headerCheck(rpmtsDig(ts), uh, uhlen, &msg) == RPMRC_FAIL
>                  ? RPMLOG_ERR : RPMLOG_DEBUG;
>          rpmlog(lvl, "%s: %s\n",
>                  (horigin ? horigin : "verify"), (msg ? msg : ""));
>          rpmtsCleanDig(ts);
>          uh = _free(uh);
>          msg = _free(msg);
>      }

applied this patch:
http://git.pld-linux.org/?p=packages/rpm.git;a=commitdiff;h=8b6cca9fe5a04dd48c84e7fd65fbfd177acaa1b3

now "rpm -Va >/dev/null" is silent:

# rpm -q rpm
rpm-5.4.15-10.1.x86_64
# rpm -Va >/dev/null
#

i found something weird, if i do rpm -V pkgname, the header verification 
error is not printed, but rpm -Va shows the error for every package 
(besides gpg-pubkey) in the system.

# for a in `rpm -qa`; do rpm -V $a; done >/dev/null
#

and:

# rpm -Va >/dev/null 2>out
# head -n 3 out
error: rpmdb (h#3): Header V4 DSA signature: BAD, key ID e4f1bc2d
error: rpmdb (h#4): Header V4 DSA signature: BAD, key ID e4f1bc2d
error: rpmdb (h#5): Header V4 DSA signature: BAD, key ID e4f1bc2d
# tail -n 3 out
error: rpmdb (h#255): Header V4 DSA signature: BAD, key ID e4f1bc2d
error: rpmdb (h#256): Header V4 DSA signature: BAD, key ID e4f1bc2d
error: rpmdb (h#257): Header V4 DSA signature: BAD, key ID e4f1bc2d
# rpm -qa|wc -l
186
# wc -l out
177 out

-- 
glen



From glen at pld-linux.org  Wed Feb 11 18:51:36 2015
From: glen at pld-linux.org (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Wed, 11 Feb 2015 19:51:36 +0200
Subject: rpm -Va BAD, key ID
In-Reply-To: <66476968-555F-470C-97D1-C15854D4EC95@me.com>
References: <54B5481A.2060000@pld-linux.org> <54DA6E34.5010400@delfi.ee>
 <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com>
 <54DB2A96.3000200@pld-linux.org>
 <752FEE39-CE78-42FB-9867-E5D7B8B849AF@me.com> <54DB602E.2070600@delfi.ee>
 <66476968-555F-470C-97D1-C15854D4EC95@me.com>
Message-ID: <54DB96A8.5050202@pld-linux.org>

On 11.02.2015 16:06, Jeffrey Johnson wrote:
> Meanwhile -- as a developer -- I need to to be able to build from source
> and diagnose/repair the problem. I cannot do that from a pile of vm bits in
> either vagrant nor qemu format.
yes you can. you can boot to vm, install development tools there and 
rebuild pld's rpm.

which probably something like:
login with root/pld
poldek -u rpm-build-tools
builder --init-rpm-dir
builder -bb rpm
poldek -u more-missing-deps
repeat builder command

-- 
glen



From n3npq at me.com  Wed Feb 11 18:58:12 2015
From: n3npq at me.com (Jeffrey Johnson)
Date: Wed, 11 Feb 2015 12:58:12 -0500
Subject: rpm -Va BAD, key ID
In-Reply-To: <54DB95EE.7040503@pld-linux.org>
References: <54B5481A.2060000@pld-linux.org> <54DA6E34.5010400@delfi.ee>
 <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com> <54DB2A96.3000200@pld-linux.org>
 <AFE8CE89-8BAF-4B4F-8110-384AD1D11F3B@me.com> <54DB95EE.7040503@pld-linux.org>
Message-ID: <F0876DA7-3DAB-4728-99CE-307A4954E161@me.com>


On Feb 11, 2015, at 12:48 PM, Elan Ruusam?e wrote:

> On 11.02.2015 15:23, Jeffrey Johnson wrote:
>> DIsable the header signature checking with rpm -Va by removing the lines below in lib/verify.c
>> 
>> 
>> 
>> 73 de Jeff
>> 
>> ===========================================
>>     /* Verify header digest/signature. */
>>     if (qva->qva_flags & (VERIFY_DIGEST | VERIFY_SIGNATURE))
>>     {
>>         const char * horigin = headerGetOrigin(h);
>>         const char * msg = NULL;
>>         size_t uhlen = 0;
>>         void * uh = headerUnload(h, &uhlen);
>>         int lvl = headerCheck(rpmtsDig(ts), uh, uhlen, &msg) == RPMRC_FAIL
>>                 ? RPMLOG_ERR : RPMLOG_DEBUG;
>>         rpmlog(lvl, "%s: %s\n",
>>                 (horigin ? horigin : "verify"), (msg ? msg : ""));
>>         rpmtsCleanDig(ts);
>>         uh = _free(uh);
>>         msg = _free(msg);
>>     }
> 
> applied this patch:
> http://git.pld-linux.org/?p=packages/rpm.git;a=commitdiff;h=8b6cca9fe5a04dd48c84e7fd65fbfd177acaa1b3
> 
> now "rpm -Va >/dev/null" is silent:
> 

Good: that's progress and identifies the code path where the problem lies.

> # rpm -q rpm
> rpm-5.4.15-10.1.x86_64
> # rpm -Va >/dev/null
> #
> 
> i found something weird, if i do rpm -V pkgname, the header verification error is not printed, but rpm -Va shows the error for every package (besides gpg-pubkey) in the system.
> 


Shows WHAT error? I'm missing something here: either rpm -Va is silent (as above) or its not (as you say here)?
Which is it?

Are you compiling rpm with OPENMP? The --verify code paths are multi-threaded.

> # for a in `rpm -qa`; do rpm -V $a; done >/dev/null
> #
> 
> and:
> 
> # rpm -Va >/dev/null 2>out
> # head -n 3 out
> error: rpmdb (h#3): Header V4 DSA signature: BAD, key ID e4f1bc2d
> error: rpmdb (h#4): Header V4 DSA signature: BAD, key ID e4f1bc2d
> error: rpmdb (h#5): Header V4 DSA signature: BAD, key ID e4f1bc2d
> # tail -n 3 out
> error: rpmdb (h#255): Header V4 DSA signature: BAD, key ID e4f1bc2d
> error: rpmdb (h#256): Header V4 DSA signature: BAD, key ID e4f1bc2d
> error: rpmdb (h#257): Header V4 DSA signature: BAD, key ID e4f1bc2d
> # rpm -qa|wc -l
> 186
> # wc -l out
> 177 out
> 

There's no need to count duplicated errors.

73 de Jeff

> -- 
> glen
> 
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en



From n3npq at me.com  Wed Feb 11 19:27:03 2015
From: n3npq at me.com (Jeffrey Johnson)
Date: Wed, 11 Feb 2015 13:27:03 -0500
Subject: rpm -Va BAD, key ID
In-Reply-To: <54DB96A8.5050202@pld-linux.org>
References: <54B5481A.2060000@pld-linux.org> <54DA6E34.5010400@delfi.ee>
 <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com> <54DB2A96.3000200@pld-linux.org>
 <752FEE39-CE78-42FB-9867-E5D7B8B849AF@me.com> <54DB602E.2070600@delfi.ee>
 <66476968-555F-470C-97D1-C15854D4EC95@me.com> <54DB96A8.5050202@pld-linux.org>
Message-ID: <C6799D57-BEB8-4899-9FCD-30A295C8D7D4@me.com>


On Feb 11, 2015, at 12:51 PM, Elan Ruusam?e wrote:

> On 11.02.2015 16:06, Jeffrey Johnson wrote:
>> Meanwhile -- as a developer -- I need to to be able to build from source
>> and diagnose/repair the problem. I cannot do that from a pile of vm bits in
>> either vagrant nor qemu format.
> yes you can. you can boot to vm, install development tools there and rebuild pld's rpm.
> 
> which probably something like:
> login with root/pld
> poldek -u rpm-build-tools
> builder --init-rpm-dir
> builder -bb rpm
> poldek -u more-missing-deps
> repeat builder command
> 

Sure I can do all of the above: its several days work to get there and is essentially
the same as switching my development platform to a different linux distro.

My build starts with a cvs checkout, and invokes ./devtool with a set of options
so that I can bore into a reproducible problem with "make -C tests test".

I can't do distro-of-the-day linux development. If there is a "regression" in rpm-5.4.15 as you
claim, it will be all platforms, not just PLD.


73 de Jeff



From glen at pld-linux.org  Thu Feb 12 10:44:58 2015
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Thu, 12 Feb 2015 11:44:58 +0200
Subject: rpm -Va BAD, key ID
In-Reply-To: <F0876DA7-3DAB-4728-99CE-307A4954E161@me.com>
References: <54B5481A.2060000@pld-linux.org> <54DA6E34.5010400@delfi.ee>
 <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com>
 <54DB2A96.3000200@pld-linux.org>
 <AFE8CE89-8BAF-4B4F-8110-384AD1D11F3B@me.com>
 <54DB95EE.7040503@pld-linux.org>
 <F0876DA7-3DAB-4728-99CE-307A4954E161@me.com>
Message-ID: <54DC761A.7090401@pld-linux.org>

On 11.02.2015 19:58, Jeffrey Johnson wrote:
>> i found something weird, if i do rpm -V pkgname, the header verification error is not printed, but rpm -Va shows the error for every package (besides gpg-pubkey) in the system.
>> >
> Shows WHAT error? I'm missing something here: either rpm -Va is silent (as above) or its not (as you say here)?
> Which is it?
i forgot "ps:", as the line starting with "i found something weird" 
started new output with old version where problem was not patched out.

basically "rpm -Va |wc -l" says header errors, while "foreach $packages; 
rpm -Va $package; done | wc -l" says nothing, thus rpm -V $pkgname does 
not emit header errors.

>
> Are you compiling rpm with OPENMP? The --verify code paths are multi-threaded.
>
>> ># for a in `rpm -qa`; do rpm -V $a; done >/dev/null
>> >#
>> >
>> >and:
>> >
>> ># rpm -Va >/dev/null 2>out
>> ># head -n 3 out
>> >error: rpmdb (h#3): Header V4 DSA signature: BAD, key ID e4f1bc2d
>> >error: rpmdb (h#4): Header V4 DSA signature: BAD, key ID e4f1bc2d
>> >error: rpmdb (h#5): Header V4 DSA signature: BAD, key ID e4f1bc2d
>> ># tail -n 3 out
>> >error: rpmdb (h#255): Header V4 DSA signature: BAD, key ID e4f1bc2d
>> >error: rpmdb (h#256): Header V4 DSA signature: BAD, key ID e4f1bc2d
>> >error: rpmdb (h#257): Header V4 DSA signature: BAD, key ID e4f1bc2d
>> ># rpm -qa|wc -l
>> >186
>> ># wc -l out
>> >177 out


-- 
glen



From glen at pld-linux.org  Thu Feb 12 10:46:10 2015
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Thu, 12 Feb 2015 11:46:10 +0200
Subject: rpm -Va BAD, key ID
In-Reply-To: <C6799D57-BEB8-4899-9FCD-30A295C8D7D4@me.com>
References: <54B5481A.2060000@pld-linux.org> <54DA6E34.5010400@delfi.ee>
 <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com>
 <54DB2A96.3000200@pld-linux.org>
 <752FEE39-CE78-42FB-9867-E5D7B8B849AF@me.com> <54DB602E.2070600@delfi.ee>
 <66476968-555F-470C-97D1-C15854D4EC95@me.com>
 <54DB96A8.5050202@pld-linux.org>
 <C6799D57-BEB8-4899-9FCD-30A295C8D7D4@me.com>
Message-ID: <54DC7662.4050809@pld-linux.org>

On 11.02.2015 20:27, Jeffrey Johnson wrote:
> I can't do distro-of-the-day linux development. If there is a "regression" in rpm-5.4.15 as you
> claim, it will be all platforms, not just PLD.

in that case, you have our rpms and the pubkey we use to sign. if not, 
then can give them again. just ask.

-- 
glen



From glen at pld-linux.org  Thu Feb 12 10:50:40 2015
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Thu, 12 Feb 2015 11:50:40 +0200
Subject: rpm -Va BAD, key ID
In-Reply-To: <F0876DA7-3DAB-4728-99CE-307A4954E161@me.com>
References: <54B5481A.2060000@pld-linux.org> <54DA6E34.5010400@delfi.ee>
 <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com>
 <54DB2A96.3000200@pld-linux.org>
 <AFE8CE89-8BAF-4B4F-8110-384AD1D11F3B@me.com>
 <54DB95EE.7040503@pld-linux.org>
 <F0876DA7-3DAB-4728-99CE-307A4954E161@me.com>
Message-ID: <54DC7770.2040900@pld-linux.org>

On 11.02.2015 19:58, Jeffrey Johnson wrote:
> Are you compiling rpm with OPENMP? The --verify code paths are multi-threaded.
how to check?

i see nothing in our .spec matching /openmp/i except one patch:

$ git ls-files|xargs grep -i openmp
openmp.patch:+librpmio_la_LDFLAGS = -release 
$(LT_CURRENT).$(LT_REVISION) $(OPENMP_CFLAGS)
openmp.patch:+dbsql_LDFLAGS     = @LDFLAGS_STATIC@ $(LDFLAGS) 
$(OPENMP_CFLAGS)
rpm.spec:Patch24:       openmp.patch
$

repo for our rpm spec is here:
https://github.com/pld-linux/rpm


-- 
glen



From n3npq at me.com  Thu Feb 12 18:55:17 2015
From: n3npq at me.com (Jeffrey Johnson)
Date: Thu, 12 Feb 2015 12:55:17 -0500
Subject: rpm -Va BAD, key ID
In-Reply-To: <54DC761A.7090401@pld-linux.org>
References: <54B5481A.2060000@pld-linux.org> <54DA6E34.5010400@delfi.ee>
 <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com> <54DB2A96.3000200@pld-linux.org>
 <AFE8CE89-8BAF-4B4F-8110-384AD1D11F3B@me.com> <54DB95EE.7040503@pld-linux.org>
 <F0876DA7-3DAB-4728-99CE-307A4954E161@me.com> <54DC761A.7090401@pld-linux.org>
Message-ID: <34056059-6B2B-4F1A-95FC-29A375509E68@me.com>


On Feb 12, 2015, at 4:44 AM, Elan Ruusam?e wrote:

> On 11.02.2015 19:58, Jeffrey Johnson wrote:
>>> i found something weird, if i do rpm -V pkgname, the header verification error is not printed, but rpm -Va shows the error for every package (besides gpg-pubkey) in the system.
>>> >
>> Shows WHAT error? I'm missing something here: either rpm -Va is silent (as above) or its not (as you say here)?
>> Which is it?
> i forgot "ps:", as the line starting with "i found something weird" started new output with old version where problem was not patched out.
> 
> basically "rpm -Va |wc -l" says header errors, while "foreach $packages; rpm -Va $package; done | wc -l" says nothing, thus rpm -V $pkgname does not emit header errors.
> 

OK. So you have a workaround (by disabling header signature verification) for -Va for the moment.
and also have an alternative means to verify header signatures using a shell loop.

You should also convince yourself that header signatures are verified when installing a package:

	rpm -Uvv somepackage*.rpm

and examine the output.

The output will look similar to this:

D:   PUB: 59625668 0E9642C7 V4 ECDSA
D: ========== ECDSA pubkey id 59625668 0e9642c7 (package)
D: devtool-sanity/devtool-sanity-1.0-1.noarch.rpm: Header V4 ECDSA/SHA256 signature: OK, key ID 0e9642c7

Verifying that header signatures are verified while installing SHOULD also confirm that the flaw
is with rpm -Va, not with RSA.

>> 
>> Are you compiling rpm with OPENMP? The --verify code paths are multi-threaded.
>> 

OPENMP is used if available when building. The top level Makefile will have this:

$ grep OPENMP Makefile
OPENMP_CFLAGS = -fopenmp
OPENMP_CXXFLAGS = -fopenmp
AM_CFLAGS = $(OPENMP_CFLAGS)

73 de Jeff

From glen at pld-linux.org  Fri Feb 13 09:17:18 2015
From: glen at pld-linux.org (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Fri, 13 Feb 2015 10:17:18 +0200
Subject: rpm -Va BAD, key ID
In-Reply-To: <34056059-6B2B-4F1A-95FC-29A375509E68@me.com>
References: <54B5481A.2060000@pld-linux.org> <54DA6E34.5010400@delfi.ee>
 <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com>
 <54DB2A96.3000200@pld-linux.org>
 <AFE8CE89-8BAF-4B4F-8110-384AD1D11F3B@me.com>
 <54DB95EE.7040503@pld-linux.org>
 <F0876DA7-3DAB-4728-99CE-307A4954E161@me.com>
 <54DC761A.7090401@pld-linux.org>
 <34056059-6B2B-4F1A-95FC-29A375509E68@me.com>
Message-ID: <54DDB30E.9030606@pld-linux.org>

On 12.02.2015 19:55, Jeffrey Johnson wrote:
> OK. So you have a workaround (by disabling header signature verification) for -Va for the moment.
> and also have an alternative means to verify header signatures using a shell loop.
i'm surprised that rpm -Va and rpm -V $pkgname use different codepath. 
so you're saying that (with my current package patch) header 
verification is disabled for both? (as no header verification errors are 
printed).

> You should also convince yourself that header signatures are verified when installing a package:
>
> 	rpm -Uvv somepackage*.rpm
but rpm -Uhv $pkg.rpm does not emit header errors. or the extra -v is 
needed to see them? and does my patch that i applied disables it or you 
are talking about current state of pld package (where the patch is applied)?

-- 
glen



From j.rekorajski at gmail.com  Fri Feb 13 11:10:38 2015
From: j.rekorajski at gmail.com (=?UTF-8?Q?Jan_R=C4=99korajski?=)
Date: Fri, 13 Feb 2015 11:10:38 +0100
Subject: [packages/kernel] add firmware bcond to disable packaging
 firmware in main package (use linux-firmware package)
In-Reply-To: <6133b03ba349175a5dd4e5aaacea9a73c2a95115_refs_heads_master@pld-linux.org>
References: <a0cda32d5c80f88dbd5015d11dc61e9b52a7bee7_refs_heads_master@pld-linux.org>
 <6133b03ba349175a5dd4e5aaacea9a73c2a95115_refs_heads_master@pld-linux.org>
Message-ID: <CAKY5yHwwfXhQ91ja83JjLN9LFxWR-CxR+hQqrbtX9Rf+08wtNA@mail.gmail.com>

Add Req linux-firmware when building with internal firmware disabled.

On Fri, Feb 13, 2015 at 10:40 AM, glen <glen at pld-linux.org> wrote:
> commit 6133b03ba349175a5dd4e5aaacea9a73c2a95115
> Author: Elan Ruusam?e <glen at delfi.ee>
> Date:   Tue Feb 3 00:03:10 2015 +0200
>
>     add firmware bcond to disable packaging firmware in main package (use linux-firmware package)
>
>  kernel.spec | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> ---
> diff --git a/kernel.spec b/kernel.spec
> index d118708..b70c0d3 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -18,6 +18,7 @@
>  %bcond_without source          # don't build kernel-source package
>  %bcond_without doc                     # don't build kernel-doc package
>  %bcond_without pcmcia          # don't build pcmcia
> +%bcond_without firmware        # don't build firmware into main package
>
>  %bcond_with    verbose         # verbose build (V=1)
>
> @@ -952,7 +953,7 @@ cd -
>
>  %install
>  rm -rf $RPM_BUILD_ROOT
> -%{__make} %{MakeOpts} -j1 %{!?with_verbose:-s} modules_install firmware_install \
> +%{__make} %{MakeOpts} -j1 %{!?with_verbose:-s} modules_install %{?with_firmware:firmware_install} \
>         -C %{objdir} \
>         %{?with_verbose:V=1} \
>         DEPMOD=%{DepMod} \
> @@ -1248,7 +1249,9 @@ fi
>  /boot/config-%{kernel_release}
>  %ghost %{initrd_dir}/initrd-%{kernel_release}.gz
>  %ghost %{initrd_dir}/initramfs-%{kernel_release}.img
> +%if %{with firmware}
>  /lib/firmware/%{kernel_release}
> +%endif
>
>  %dir /lib/modules/%{kernel_release}
>  %dir /lib/modules/%{kernel_release}/kernel
> ================================================================
>
> ---- gitweb:
>
> http://git.pld-linux.org/gitweb.cgi/packages/kernel.git/commitdiff/6133b03ba349175a5dd4e5aaacea9a73c2a95115
>
> _______________________________________________
> pld-cvs-commit mailing list
> pld-cvs-commit at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit



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


From glen at pld-linux.org  Fri Feb 13 11:23:51 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Fri, 13 Feb 2015 12:23:51 +0200
Subject: [packages/kernel] add firmware bcond to disable packaging firmware
 in main package (use linux-firmware package)
In-Reply-To: <CAKY5yHwwfXhQ91ja83JjLN9LFxWR-CxR+hQqrbtX9Rf+08wtNA@mail.gmail.com>
References: <a0cda32d5c80f88dbd5015d11dc61e9b52a7bee7_refs_heads_master@pld-linux.org>
 <6133b03ba349175a5dd4e5aaacea9a73c2a95115_refs_heads_master@pld-linux.org>
 <CAKY5yHwwfXhQ91ja83JjLN9LFxWR-CxR+hQqrbtX9Rf+08wtNA@mail.gmail.com>
Message-ID: <54DDD0B7.9050507@pld-linux.org>

On 13.02.2015 12:10, Jan R?korajski wrote:
> Add Req linux-firmware when building with internal firmware disabled.
>
> On Fri, Feb 13, 2015 at 10:40 AM, glen <glen at pld-linux.org> wrote:
>> commit 6133b03ba349175a5dd4e5aaacea9a73c2a95115
>> Author: Elan Ruusam?e <glen at delfi.ee>
>> Date:   Tue Feb 3 00:03:10 2015 +0200
>>
>>      add firmware bcond to disable packaging firmware in main package (use linux-firmware package)
on a slightly related topic:

kernel makefile supports two way of installing firmwares:
1. install what is needed based on enabled modules
2. install any firmware present in sources

how pld make install is invoked, it does "2", but imho should do "1".

also, what is the difference with firmware from kernel sources and the 
externally built one.
i have not found definitive answer to this.

-- 
glen



From n3npq at me.com  Fri Feb 13 16:06:36 2015
From: n3npq at me.com (Jeffrey Johnson)
Date: Fri, 13 Feb 2015 10:06:36 -0500
Subject: rpm -Va BAD, key ID
In-Reply-To: <54DDB30E.9030606@pld-linux.org>
References: <54B5481A.2060000@pld-linux.org> <54DA6E34.5010400@delfi.ee>
 <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com> <54DB2A96.3000200@pld-linux.org>
 <AFE8CE89-8BAF-4B4F-8110-384AD1D11F3B@me.com> <54DB95EE.7040503@pld-linux.org>
 <F0876DA7-3DAB-4728-99CE-307A4954E161@me.com> <54DC761A.7090401@pld-linux.org>
 <34056059-6B2B-4F1A-95FC-29A375509E68@me.com> <54DDB30E.9030606@pld-linux.org>
Message-ID: <6FF2CF8E-9285-4164-9810-F2F2EE43CB22@me.com>


> On Feb 13, 2015, at 3:17 AM, Elan Ruusam?e <glen at pld-linux.org> wrote:
> 
> On 12.02.2015 19:55, Jeffrey Johnson wrote:
>> OK. So you have a workaround (by disabling header signature verification) for -Va for the moment.
>> and also have an alternative means to verify header signatures using a shell loop.
> i'm surprised that rpm -Va and rpm -V $pkgname use different codepath. so you're saying that (with my current package patch) header verification is disabled for both? (as no header verification errors are printed).
> 

They (rpm -Va and rpm -V) don?t use different code paths: there is hidden state associated
with pubkey retrieval to minimize network/rpmdb access.

Yes the patch disables header signature verification for both rpm -V and rpm -Va.

>> You should also convince yourself that header signatures are verified when installing a package:
>> 
>> 	rpm -Uvv somepackage*.rpm
> but rpm -Uhv $pkg.rpm does not emit header errors. or the extra -v is needed to see them?

The extra -v is needed to see the 3 lines I gave you, ?nosignatures/?nodigests disables
verification. You know this ;-)

> and does my patch that i applied disables it or you are talking about current state of pld package (where the patch is applied)?
> 

I gave you a means to verify that RSA for your existing Th pubkey isn?t broken (as
you have been claiming).

Every installed package has had the header signature verified. The patch I gave you
disables verification as a work around until I can find a reproducer for whatever the
issue is and ?fix?.

73 de Jeff
> -- 
> glen
> 
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en



From n3npq at me.com  Sat Feb 14 19:21:45 2015
From: n3npq at me.com (Jeffrey Johnson)
Date: Sat, 14 Feb 2015 13:21:45 -0500
Subject: rpm -Va BAD, key ID
In-Reply-To: <6FF2CF8E-9285-4164-9810-F2F2EE43CB22@me.com>
References: <54B5481A.2060000@pld-linux.org> <54DA6E34.5010400@delfi.ee>
 <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com> <54DB2A96.3000200@pld-linux.org>
 <AFE8CE89-8BAF-4B4F-8110-384AD1D11F3B@me.com> <54DB95EE.7040503@pld-linux.org>
 <F0876DA7-3DAB-4728-99CE-307A4954E161@me.com> <54DC761A.7090401@pld-linux.org>
 <34056059-6B2B-4F1A-95FC-29A375509E68@me.com> <54DDB30E.9030606@pld-linux.org>
 <6FF2CF8E-9285-4164-9810-F2F2EE43CB22@me.com>
Message-ID: <47741DA9-3583-484D-A60B-506080B3B512@me.com>


On Feb 13, 2015, at 10:06 AM, Jeffrey Johnson wrote:

> 
>> On Feb 13, 2015, at 3:17 AM, Elan Ruusam?e <glen at pld-linux.org> wrote:
>> 
>> On 12.02.2015 19:55, Jeffrey Johnson wrote:
>>> OK. So you have a workaround (by disabling header signature verification) for -Va for the moment.
>>> and also have an alternative means to verify header signatures using a shell loop.
>> i'm surprised that rpm -Va and rpm -V $pkgname use different codepath. so you're saying that (with my current package patch) header verification is disabled for both? (as no header verification errors are printed).
>> 
> 
> They (rpm -Va and rpm -V) don?t use different code paths: there is hidden state associated
> with pubkey retrieval to minimize network/rpmdb access.
> 

Try a patch similar (this is from cvs, not from rpm-5.4.15) to the attached (I've forgotten where
the patch came from, perhaps PLD or ROSA).

The issue is/was resetting stateful variables when more than one pubkey is present. Which
explains why an RSA key was identified as DSA, and also explains why "rpm -V pkg" works,
but "rpm -Va" doesn't.

73 de Jeff

Index: rpmhkp.c
===================================================================
RCS file: /v/rpm/cvs/rpm/rpmio/rpmhkp.c,v
retrieving revision 2.20.2.9
diff -p -u -w -r2.20.2.9 rpmhkp.c
--- rpmhkp.c	11 Oct 2014 12:56:41 -0000	2.20.2.9
+++ rpmhkp.c	14 Feb 2015 18:15:36 -0000
@@ -916,14 +916,6 @@ te = t = tbuf;
 
 HKPDEBUG((stderr, "--> %s(%p,%s)\n", __FUNCTION__, hkp, keyname));
 
-    /* Reset temporary variables*/
-    hkp->pubx = -1;
-    hkp->uidx = -1;
-    hkp->subx = -1;
-    hkp->sigx = -1;
-    hkp->tvalid = 0;
-    hkp->uvalidx = -1;
-
     /* Do a lazy lookup before validating. */
     if (hkp == NULL && keyname && *keyname) {
 	if ((hkp = rpmhkpLookup(keyname)) == NULL) {
@@ -934,6 +926,14 @@ HKPDEBUG((stderr, "--> %s(%p,%s)\n", __F
     if ((hkp = rpmhkpLink(hkp)) == NULL)
 	return rc;
 
+    /* Reset temporary variables*/
+    hkp->pubx = -1;
+    hkp->uidx = -1;
+    hkp->subx = -1;
+    hkp->sigx = -1;
+    hkp->tvalid = 0;
+    hkp->uvalidx = -1;
+
     SUM.certs++;
 assert(hkp->pkts);
 




From baggins at pld-linux.org  Sun Feb 15 10:35:48 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 15 Feb 2015 10:35:48 +0100
Subject: rpm -Va BAD, key ID
In-Reply-To: <47741DA9-3583-484D-A60B-506080B3B512@me.com>
References: <0E59164E-2E62-4DFD-A0BA-7EDA1F47E240@me.com>
 <54DB2A96.3000200@pld-linux.org>
 <AFE8CE89-8BAF-4B4F-8110-384AD1D11F3B@me.com>
 <54DB95EE.7040503@pld-linux.org>
 <F0876DA7-3DAB-4728-99CE-307A4954E161@me.com>
 <54DC761A.7090401@pld-linux.org>
 <34056059-6B2B-4F1A-95FC-29A375509E68@me.com>
 <54DDB30E.9030606@pld-linux.org>
 <6FF2CF8E-9285-4164-9810-F2F2EE43CB22@me.com>
 <47741DA9-3583-484D-A60B-506080B3B512@me.com>
Message-ID: <20150215093548.GA2543@home.lan>

On Sat, 14 Feb 2015, Jeffrey Johnson wrote:

> 
> On Feb 13, 2015, at 10:06 AM, Jeffrey Johnson wrote:
> 
> > 
> >> On Feb 13, 2015, at 3:17 AM, Elan Ruusam?e <glen at pld-linux.org> wrote:
> >> 
> >> On 12.02.2015 19:55, Jeffrey Johnson wrote:
> >>> OK. So you have a workaround (by disabling header signature verification) for -Va for the moment.
> >>> and also have an alternative means to verify header signatures using a shell loop.
> >> i'm surprised that rpm -Va and rpm -V $pkgname use different codepath. so you're saying that (with my current package patch) header verification is disabled for both? (as no header verification errors are printed).
> >> 
> > 
> > They (rpm -Va and rpm -V) don?t use different code paths: there is hidden state associated
> > with pubkey retrieval to minimize network/rpmdb access.
> > 
> 
> Try a patch similar (this is from cvs, not from rpm-5.4.15) to the attached (I've forgotten where
> the patch came from, perhaps PLD or ROSA).
> 
> The issue is/was resetting stateful variables when more than one pubkey is present. Which
> explains why an RSA key was identified as DSA, and also explains why "rpm -V pkg" works,
> but "rpm -Va" doesn't.

We have similar patch already applied (from Mandriva), this doesn't fix
anything. Also disabling openmp doesn't fix anything.

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


From baggins at pld-linux.org  Sun Feb 15 11:00:40 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 15 Feb 2015 11:00:40 +0100
Subject: rpm -Va BAD, key ID
In-Reply-To: <20150215093548.GA2543@home.lan>
References: <54DB2A96.3000200@pld-linux.org>
 <AFE8CE89-8BAF-4B4F-8110-384AD1D11F3B@me.com>
 <54DB95EE.7040503@pld-linux.org>
 <F0876DA7-3DAB-4728-99CE-307A4954E161@me.com>
 <54DC761A.7090401@pld-linux.org>
 <34056059-6B2B-4F1A-95FC-29A375509E68@me.com>
 <54DDB30E.9030606@pld-linux.org>
 <6FF2CF8E-9285-4164-9810-F2F2EE43CB22@me.com>
 <47741DA9-3583-484D-A60B-506080B3B512@me.com>
 <20150215093548.GA2543@home.lan>
Message-ID: <20150215100039.GB2543@home.lan>

On Sun, 15 Feb 2015, Jan R?korajski wrote:

> On Sat, 14 Feb 2015, Jeffrey Johnson wrote:
> 
> > 
> > On Feb 13, 2015, at 10:06 AM, Jeffrey Johnson wrote:
> > 
> > > 
> > >> On Feb 13, 2015, at 3:17 AM, Elan Ruusam?e <glen at pld-linux.org> wrote:
> > >> 
> > >> On 12.02.2015 19:55, Jeffrey Johnson wrote:
> > >>> OK. So you have a workaround (by disabling header signature verification) for -Va for the moment.
> > >>> and also have an alternative means to verify header signatures using a shell loop.
> > >> i'm surprised that rpm -Va and rpm -V $pkgname use different codepath. so you're saying that (with my current package patch) header verification is disabled for both? (as no header verification errors are printed).
> > >> 
> > > 
> > > They (rpm -Va and rpm -V) don?t use different code paths: there is hidden state associated
> > > with pubkey retrieval to minimize network/rpmdb access.
> > > 
> > 
> > Try a patch similar (this is from cvs, not from rpm-5.4.15) to the attached (I've forgotten where
> > the patch came from, perhaps PLD or ROSA).
> > 
> > The issue is/was resetting stateful variables when more than one pubkey is present. Which
> > explains why an RSA key was identified as DSA, and also explains why "rpm -V pkg" works,
> > but "rpm -Va" doesn't.
> 
> We have similar patch already applied (from Mandriva), this doesn't fix
> anything. Also disabling openmp doesn't fix anything.

Debug run for a random package. No key verification disabling hacks applied.
It looks like you're loosing DSA key somewhere.

# rpm -Vvv issue
D: pool fd:	created size 392 limit -1 flags 0
D: pool iob:	created size 48 limit -1 flags 0
D: pool mire:	created size 136 limit -1 flags 0
D: pool lua:	created size 64 limit -1 flags 0
D: pool ts:	created size 1200 limit -1 flags 0
D: pool gi:	created size 176 limit -1 flags 0
D: pool db:	created size 328 limit -1 flags 0
D: pool dbi:	created size 472 limit -1 flags 0
D: rpmdb: cpus 4 physmem 7956Mb
D: opening  db environment /var/lib/rpm/Packages thread:lock:log:mpool:txn
D: opening  db index       /var/lib/rpm/Packages thread:rdonly:auto_commit mode=0x0
D: opening  db index       /var/lib/rpm/Nvra thread:rdonly:auto_commit mode=0x0
D: pool mi:	created size 152 limit -1 flags 0
D: pool h:	created size 360 limit -1 flags 0
D: pool fi:	created size 560 limit -1 flags 0
D: pool dig:	created size 424 limit -1 flags 0
D: pool ctx:	created size 112 limit -1 flags 0
D: pool bf:	created size 56 limit -1 flags 0
D: pool hkp:	created size 128 limit -1 flags 0
D: opening  db index       /var/lib/rpm/Pubkeys thread:rdonly:auto_commit mode=0x0
D:   PUB: AF3F93BC E4F1BC2D V4 DSA
D:   SIG: AF3F93BC E4F1BC2D V4 DSA-SHA1 POSITIVE
D:   PUB: 732FDFDE EAE6F8B8 V4 RSA
D:   SIG: 732FDFDE EAE6F8B8 V4 RSA-SHA1 POSITIVE
D:   UID: RSApub (PLD Linux Distribution 3.0 (Th)) <th-admin at pld-linux.org>
D: pool u:	created size 288 limit -1 flags 0

<
a very long wait here, +10 for trying to connect to
non-working keyservers, a.k.a. hkp://keys.rpm5.org

Disabling keyserver lookup only removes the delay,
key veryfication still fails.
>

D: ========== DSA pubkey id af3f93bc e4f1bc2d (h#4283454898[0])
error: rpmdb (h#4283454157): Header V4 DSA signature: BAD, key ID e4f1bc2d
........  c /etc/issue
........  c /etc/issue.net
D: pool tsi:	created size 48 limit -1 flags 0
D: pool te:	created size 368 limit -1 flags 0
D: pool ds:	created size 232 limit -1 flags 0
D: pool al:	created size 64 limit -1 flags 0
D: ========== +++ issue-3.0-6.noarch noarch/linux 0x0
D: pool ps:	created size 40 limit -1 flags 0
D: opening  db index       /var/lib/rpm/Providename thread:rdonly:auto_commit mode=0x0
D:  Requires: pld-release = 3.0                             YES (db provides)
D:  Requires: rpmlib(PayloadIsLzma) <= 4.4.6-1              YES (rpmlib provides)
D: Conflicts: issue-alpha < 3.0-1                           NO  
D: Conflicts: issue-fancy < 3.0-1                           NO  
D: Conflicts: issue-logo < 3.0-1                            NO  
D: Conflicts: issue-nice < 3.0-1                            NO  
D: Conflicts: issue-pure < 3.0-1                            NO  
D: opening  db index       /var/lib/rpm/Filepaths thread:rdonly:auto_commit mode=0x0
D:      Dirs: /etc                                          YES (db files)
D: opening  db index       /var/lib/rpm/Conflictname thread:rdonly:auto_commit mode=0x0
D: Conflicts: issue < 3.0-1                                 NO  
D: closed   db index       /var/lib/rpm/Filepaths
D: closed   db index       /var/lib/rpm/Nvra
D: closed   db index       /var/lib/rpm/Pubkeys
D: closed   db index       /var/lib/rpm/Conflictname
D: closed   db index       /var/lib/rpm/Providename
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm/Packages
D: pool gi:	reused 0, alloc'd 1, free'd 1 items.
D: pool mi:	reused 11, alloc'd 3, free'd 3 items.
D: pool tsi:	reused 11, alloc'd 1, free'd 1 items.
D: pool ts:	reused 0, alloc'd 1, free'd 1 items.
D: pool te:	reused 0, alloc'd 1, free'd 1 items.
D: pool ps:	reused 0, alloc'd 1, free'd 1 items.
D: pool al:	reused 0, alloc'd 1, free'd 1 items.
D: pool ds:	reused 24, alloc'd 14, free'd 14 items.
D: pool fi:	reused 0, alloc'd 2, free'd 2 items.
D: pool db:	reused 0, alloc'd 1, free'd 1 items.
D: pool dbi:	reused 0, alloc'd 6, free'd 6 items.
D: pool h:	reused 3, alloc'd 3, free'd 3 items.
D: pool lua:	reused 0, alloc'd 1, free'd 1 items.
D: pool hkp:	reused 0, alloc'd 2, free'd 2 items.
D: pool mire:	reused 1, alloc'd 3, free'd 3 items.
D: pool bf:	reused 0, alloc'd 3, free'd 3 items.
D: pool ctx:	reused 7, alloc'd 2, free'd 2 items.
D: pool iob:	reused 1, alloc'd 1, free'd 1 items.
D: pool dig:	reused 1, alloc'd 2, free'd 2 items.
D: pool u:	reused 0, alloc'd 1, free'd 1 items.
D: pool fd:	reused 28, alloc'd 2, free'd 2 items.
D: exit code: 0


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


From n3npq at me.com  Sun Feb 15 19:10:45 2015
From: n3npq at me.com (Jeffrey Johnson)
Date: Sun, 15 Feb 2015 13:10:45 -0500
Subject: rpm -Va BAD, key ID
In-Reply-To: <20150215100039.GB2543@home.lan>
References: <54DB2A96.3000200@pld-linux.org>
 <AFE8CE89-8BAF-4B4F-8110-384AD1D11F3B@me.com> <54DB95EE.7040503@pld-linux.org>
 <F0876DA7-3DAB-4728-99CE-307A4954E161@me.com> <54DC761A.7090401@pld-linux.org>
 <34056059-6B2B-4F1A-95FC-29A375509E68@me.com> <54DDB30E.9030606@pld-linux.org>
 <6FF2CF8E-9285-4164-9810-F2F2EE43CB22@me.com>
 <47741DA9-3583-484D-A60B-506080B3B512@me.com> <20150215093548.GA2543@home.lan>
 <20150215100039.GB2543@home.lan>
Message-ID: <1CEA3561-34B8-417C-9D93-91C1ABB01AA8@me.com>


On Feb 15, 2015, at 5:00 AM, Jan R?korajski wrote:

> On Sun, 15 Feb 2015, Jan R?korajski wrote:
> 
>> On Sat, 14 Feb 2015, Jeffrey Johnson wrote:
>> 
>>> 
>>> On Feb 13, 2015, at 10:06 AM, Jeffrey Johnson wrote:
>>> 
>>>> 
>>>>> On Feb 13, 2015, at 3:17 AM, Elan Ruusam?e <glen at pld-linux.org> wrote:
>>>>> 
>>>>> On 12.02.2015 19:55, Jeffrey Johnson wrote:
>>>>>> OK. So you have a workaround (by disabling header signature verification) for -Va for the moment.
>>>>>> and also have an alternative means to verify header signatures using a shell loop.
>>>>> i'm surprised that rpm -Va and rpm -V $pkgname use different codepath. so you're saying that (with my current package patch) header verification is disabled for both? (as no header verification errors are printed).
>>>>> 
>>>> 
>>>> They (rpm -Va and rpm -V) don?t use different code paths: there is hidden state associated
>>>> with pubkey retrieval to minimize network/rpmdb access.
>>>> 
>>> 
>>> Try a patch similar (this is from cvs, not from rpm-5.4.15) to the attached (I've forgotten where
>>> the patch came from, perhaps PLD or ROSA).
>>> 
>>> The issue is/was resetting stateful variables when more than one pubkey is present. Which
>>> explains why an RSA key was identified as DSA, and also explains why "rpm -V pkg" works,
>>> but "rpm -Va" doesn't.
>> 
>> We have similar patch already applied (from Mandriva), this doesn't fix
>> anything. Also disabling openmp doesn't fix anything.
> 
> Debug run for a random package. No key verification disabling hacks applied.
> It looks like you're loosing DSA key somewhere.
> 
> # rpm -Vvv issue
> D: pool fd:	created size 392 limit -1 flags 0
> D: pool iob:	created size 48 limit -1 flags 0
> D: pool mire:	created size 136 limit -1 flags 0
> D: pool lua:	created size 64 limit -1 flags 0
> D: pool ts:	created size 1200 limit -1 flags 0
> D: pool gi:	created size 176 limit -1 flags 0
> D: pool db:	created size 328 limit -1 flags 0
> D: pool dbi:	created size 472 limit -1 flags 0
> D: rpmdb: cpus 4 physmem 7956Mb
> D: opening  db environment /var/lib/rpm/Packages thread:lock:log:mpool:txn
> D: opening  db index       /var/lib/rpm/Packages thread:rdonly:auto_commit mode=0x0
> D: opening  db index       /var/lib/rpm/Nvra thread:rdonly:auto_commit mode=0x0
> D: pool mi:	created size 152 limit -1 flags 0
> D: pool h:	created size 360 limit -1 flags 0
> D: pool fi:	created size 560 limit -1 flags 0
> D: pool dig:	created size 424 limit -1 flags 0
> D: pool ctx:	created size 112 limit -1 flags 0
> D: pool bf:	created size 56 limit -1 flags 0
> D: pool hkp:	created size 128 limit -1 flags 0
> D: opening  db index       /var/lib/rpm/Pubkeys thread:rdonly:auto_commit mode=0x0
> D:   PUB: AF3F93BC E4F1BC2D V4 DSA
> D:   SIG: AF3F93BC E4F1BC2D V4 DSA-SHA1 POSITIVE
> D:   PUB: 732FDFDE EAE6F8B8 V4 RSA
> D:   SIG: 732FDFDE EAE6F8B8 V4 RSA-SHA1 POSITIVE
> D:   UID: RSApub (PLD Linux Distribution 3.0 (Th)) <th-admin at pld-linux.org>

I am confused by the UID here: is this a RSA or a DSA key? It looks like a DSA key
signed by  itself as well as a RSA positive certification and UID binding signature.

I've been looking for RSA issues: I'm even more surprised at a regression with DSA.

But I'm not too surprised that more complicated key structures may be causing issues.
Originally rpm saved only the 1st packet of a pubkey containing the key material. In order
to attach/deisplay a UID, the binding signature is verified, and the entire pubkey, with all certifications,
is now saved in an rpmdb. This is another change in rpm-5.4.15

Try using gnupg to edit the 0xE4F1BC2D pubkey, and strip out everything but the self
signed positive certification, and export/import into an rpmdb. See if that verifies.

There should be no network hkp access if you have imported the needed pubkeys correctly.

> D: pool u:	created size 288 limit -1 flags 0
> 
> <
> a very long wait here, +10 for trying to connect to
> non-working keyservers, a.k.a. hkp://keys.rpm5.org
> 

So some pubkey needed for verification is not imported because HKP is attempting a lookup.

Yes you need to configure a better key server than keys.rpm5.org if expecting reasonable response service.

> Disabling keyserver lookup only removes the delay,
> key veryfication still fails.
>> 
> 
> D: ========== DSA pubkey id af3f93bc e4f1bc2d (h#4283454898[0])
> error: rpmdb (h#4283454157): Header V4 DSA signature: BAD, key ID e4f1bc2d
> ........  c /etc/issue
> ........  c /etc/issue.net
> D: pool tsi:	created size 48 limit -1 flags 0
> D: pool te:	created size 368 limit -1 flags 0
> D: pool ds:	created size 232 limit -1 flags 0
> D: pool al:	created size 64 limit -1 flags 0
> D: ========== +++ issue-3.0-6.noarch noarch/linux 0x0
> D: pool ps:	created size 40 limit -1 flags 0
> D: opening  db index       /var/lib/rpm/Providename thread:rdonly:auto_commit mode=0x0
> D:  Requires: pld-release = 3.0                             YES (db provides)
> D:  Requires: rpmlib(PayloadIsLzma) <= 4.4.6-1              YES (rpmlib provides)
> D: Conflicts: issue-alpha < 3.0-1                           NO  
> D: Conflicts: issue-fancy < 3.0-1                           NO  
> D: Conflicts: issue-logo < 3.0-1                            NO  
> D: Conflicts: issue-nice < 3.0-1                            NO  
> D: Conflicts: issue-pure < 3.0-1                            NO  
> D: opening  db index       /var/lib/rpm/Filepaths thread:rdonly:auto_commit mode=0x0
> D:      Dirs: /etc                                          YES (db files)
> D: opening  db index       /var/lib/rpm/Conflictname thread:rdonly:auto_commit mode=0x0
> D: Conflicts: issue < 3.0-1                                 NO  
> D: closed   db index       /var/lib/rpm/Filepaths
> D: closed   db index       /var/lib/rpm/Nvra
> D: closed   db index       /var/lib/rpm/Pubkeys
> D: closed   db index       /var/lib/rpm/Conflictname
> D: closed   db index       /var/lib/rpm/Providename
> D: closed   db index       /var/lib/rpm/Packages
> D: closed   db environment /var/lib/rpm/Packages
> D: pool gi:	reused 0, alloc'd 1, free'd 1 items.
> D: pool mi:	reused 11, alloc'd 3, free'd 3 items.
> D: pool tsi:	reused 11, alloc'd 1, free'd 1 items.
> D: pool ts:	reused 0, alloc'd 1, free'd 1 items.
> D: pool te:	reused 0, alloc'd 1, free'd 1 items.
> D: pool ps:	reused 0, alloc'd 1, free'd 1 items.
> D: pool al:	reused 0, alloc'd 1, free'd 1 items.
> D: pool ds:	reused 24, alloc'd 14, free'd 14 items.
> D: pool fi:	reused 0, alloc'd 2, free'd 2 items.
> D: pool db:	reused 0, alloc'd 1, free'd 1 items.
> D: pool dbi:	reused 0, alloc'd 6, free'd 6 items.
> D: pool h:	reused 3, alloc'd 3, free'd 3 items.
> D: pool lua:	reused 0, alloc'd 1, free'd 1 items.
> D: pool hkp:	reused 0, alloc'd 2, free'd 2 items.
> D: pool mire:	reused 1, alloc'd 3, free'd 3 items.
> D: pool bf:	reused 0, alloc'd 3, free'd 3 items.
> D: pool ctx:	reused 7, alloc'd 2, free'd 2 items.
> D: pool iob:	reused 1, alloc'd 1, free'd 1 items.
> D: pool dig:	reused 1, alloc'd 2, free'd 2 items.
> D: pool u:	reused 0, alloc'd 1, free'd 1 items.
> D: pool fd:	reused 28, alloc'd 2, free'd 2 items.
> D: exit code: 0
> 
> 
> -- 
> Jan R?korajski                    | PLD/Linux
> SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/
> _______________________________________________
> 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  Tue Feb 17 10:50:58 2015
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Tue, 17 Feb 2015 11:50:58 +0200
Subject: [packages/npapi-vlc] - pl, cleanup, completed BRs
In-Reply-To: <0e3ceb102018307862c8e36e97e6417e535622a2_refs_heads_master@pld-linux.org>
References: <b92e7c048537097ebbc07bb1ba56d2401fa9452c_refs_heads_master@pld-linux.org>
 <0e3ceb102018307862c8e36e97e6417e535622a2_refs_heads_master@pld-linux.org>
Message-ID: <54E30F02.7000309@pld-linux.org>

On 16.02.2015 22:13, qboosh wrote:
> --- a/npapi-vlc.spec
> +++ b/npapi-vlc.spec
> @@ -1,17 +1,25 @@
> +# TODO: rename to browser-plugin-vlc?

+1

at least the binary package (src.rpm may stay as upstream name)

-- 
glen



From gotar at polanet.pl  Fri Feb 20 00:00:43 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Fri, 20 Feb 2015 00:00:43 +0100
Subject: MIT kerberos vs heimdal
In-Reply-To: <20150208104141.GD2507@home.lan>
References: <20150207135249.GA4232@polanet.pl>
 <201502071642.17345.arekm@maven.pl>
 <20150207163839.GA2507@home.lan> <20150207171524.GA9465@polanet.pl>
 <20150207174432.GB2507@home.lan>
 <20150207222126.GA11482@polanet.pl>
 <20150207223844.GB11482@polanet.pl>
 <20150208104141.GD2507@home.lan>
Message-ID: <20150219230043.GA2750@polanet.pl>

On Sun, Feb 08, 2015 at 11:41:41 +0100, Jan R?korajski wrote:

>> problem in having them both on ftp? Client libraries should be
>> compatible (i.e. heimdal client works with MIT server, that's the point
>> of having a 'protocol'). Incompatible parts are kadmin and probably
>> the rest of server stuff - heimdal package is divided accordingly
>> already, krb5 have libkadm5{clnt,srv}_mit and libgssapi_krb5 (suffixed),
>> the only conflicting library I see is libkrb5.so itself, but has
>> different SOVER.
> 
> You are mistaking protocol, API and ABI.
> Protocol is the same, Heimdal has no problems at all taking to MIT and
> vice versa. But if you try to run program linked with one in presence of
> a library from other, things may go nasty.

I am aware of problems that might pop up when you mix multiple
ABI-incompatible libraries in single code executed. However I did a
quick research and fortunately the MIT krb5 library has all the symbols
versioned with _MIT suffix:

objdump -TC /usr/lib64/libkrb5.so.3.3 | grep -v krb5_3_MIT  | grep -v UND
readelf -Ws /usr/lib64/libkrb5.so.3.3 | grep -v _MIT\$ | grep -v UND

while heimdal implementation uses it's own HEIMDAL_ prefix:

objdump -TC /lib/libkrb5.so.26.0.0 | grep -v HEIMDAL_KRB5_2.0  | grep -v UND
readelf -Ws /lib/libkrb5.so.26.0.0 | grep -v HEIMDAL_KRB5_2.0\$ | grep -v UND

So (correct me if I'm wrong) one could safely use binary linked with MIT
library and any other library that in turn is linked with heimdal one.

>> What would happen with your heimdal server if we changed heimdal-devel
>> to krb5-devel and rebuild everything? Shouldn't this keep working?
> 
> No. As I said, ABI is different, just look at 'heimdal' patches in repo,
> MIT has some fancy functions Heimdal doesn't.

IMHO in this case you cannot say that ABI is different - in terms of ELF
these are completely different libraries, like libpng and libjpeg.

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


From gotar at polanet.pl  Fri Feb 20 01:57:59 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Fri, 20 Feb 2015 01:57:59 +0100
Subject: MIT kerberos vs heimdal
In-Reply-To: <20150208103641.GC2507@home.lan>
References: <20150207135249.GA4232@polanet.pl>
 <201502071642.17345.arekm@maven.pl>
 <20150207163839.GA2507@home.lan> <20150207171524.GA9465@polanet.pl>
 <20150207174432.GB2507@home.lan>
 <20150207222126.GA11482@polanet.pl>
 <20150208103641.GC2507@home.lan>
Message-ID: <20150220005759.GA22493@polanet.pl>

On Sun, Feb 08, 2015 at 11:36:42 +0100, Jan R?korajski wrote:

>> > But that's not the point, you missed the most important issue (system
>> > MIT makes samba4 useless):
> 
> APIs and ABIs in Heimdal and MIT are different. Samba uses Heimdal to do
> AD DC kerberos. It does not build with MIT. Fedora distributes samba4
> without Kerberos, makeing it effectively a samba3 PDC. The whole point
> of samba4 is it being full fledged MS AD DC. Is that explanation clear enough?

OK, I see now. So let's do some logic:

samba	R: heimdal-libs-server	fine; note nothing else requires this lib!

openldap-overlay-smbk5pwd, python-samba, samba, samba-libs
	R: heimdal-libs-common	fine; also, nothing else requires these!

samba-libs are required by other samba subpackages (incl. libsmbclient) only

- so all we need to crosscheck is libsmbclient vs heimdal-libs:

poldek:/all-avail> desc -B libsmbclient-4.1.14-1.x86_64 

Package:        libsmbclient-4.1.14-1.x86_64
Required(by):   cifs-utils, fusesmb, gmerlin-avdecoder, gmplayer,
gnome-control-center, gnome-vfs2-libs, gvfs-smb, kde4-kdebase-runtime,
mencoder, mpd, mpd, mplayer, mpv, mpv-client-libs,
perl-Filesys-SmbClient, [*samba*], vlc, xbmc, xine-input-smb

Which one of those require heimdal-libs as well?

cifs-utils, gnome-control-center, gnome-vfs2-libs

These 3 might (should?) to be compiled using heimdal-libs.
I've also checked what requires heimdal-devel, gnome-vfs2-devel, samba-devel 
and libsmbclient-devel and haven't seen any clashes.


My point is - assuming I haven't forgot about anything (considering my last mail
about versioned symbols) we could safely:

1. compile samba against heimdal to have AD (as an exception!),
2. compile everything else against MIT,
2a. except the things that require KRB+SMB itself as a precaution (i.e.
    the three packages mentioned earlier) (???)


Rationale:

1. there might be situations where:

binary	-> MIT KRB
	-> lib1	-> MIT KRB
	-> lib2 -> lib*smb* -> heimdal KRB

but this would be valid since all KRB symbols are versioned and there
should be no path for any kerberos struct passing between lib1 and lib2
(only between binary and lib1).

2. every possible lib2 that uses both SMB _and_ KRB uses heimdal
(currently gnome-vfs2-libs only).


In other words: if we want samba-server using heimdal, it does NOT mean
we need to build everything else using heimdal; client-server protocol
effectively separates different API and ABI, symbol versioning separates
ABI pulled in within single code executed.

>> >> > and that's crucial now Samba is a real AD server. Just read README.dc
>> >> > from Fedora's samba package, it's so pathetic it still makes me
>> >> > laugh my ass off.
>> >> >
>> >> > That were the reasons we switched to Heimdal.
>> 
>> Wasn't that the reason THEY have created FreeIPA for AD?
> 
> Who are THEY?

Fedora guys. As a solution for such heroic (or brain damaged) hackery
required for setting up AD services you've mentioned they've ended up in
FreeIPA. Isn't that better than our approach? Honestly I won't be
capable of setting AD on PLD if I need to (well, mostly because I don't
have any windows system to do step-by-step environment debugging) - MIT
or heimdal, no difference, won't work and pld-doc doesn't help.

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


From gotar at polanet.pl  Fri Feb 20 04:09:07 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Fri, 20 Feb 2015 04:09:07 +0100
Subject: MIT kerberos vs heimdal
In-Reply-To: <20150220005759.GA22493@polanet.pl>
References: <20150207135249.GA4232@polanet.pl>
 <201502071642.17345.arekm@maven.pl>
 <20150207163839.GA2507@home.lan> <20150207171524.GA9465@polanet.pl>
 <20150207174432.GB2507@home.lan>
 <20150207222126.GA11482@polanet.pl>
 <20150208103641.GC2507@home.lan>
 <20150220005759.GA22493@polanet.pl>
Message-ID: <20150220030907.GA28392@polanet.pl>

On Fri, Feb 20, 2015 at 01:57:59 +0100, Tomasz Pala wrote:

> My point is - assuming I haven't forgot about anything (considering my last mail
> about versioned symbols) we could safely:
> 
> 1. compile samba against heimdal to have AD (as an exception!),
> 2. compile everything else against MIT,
> 2a. except the things that require KRB+SMB itself as a precaution (i.e.
>     the three packages mentioned earlier) (???)
> 
> 
> Rationale:
> 
> 1. there might be situations where:
> 
> binary	-> MIT KRB
> 	-> lib1	-> MIT KRB
> 	-> lib2 -> lib*smb* -> heimdal KRB
> 
> but this would be valid since all KRB symbols are versioned and there
> should be no path for any kerberos struct passing between lib1 and lib2
> (only between binary and lib1).
> 
> 2. every possible lib2 that uses both SMB _and_ KRB uses heimdal
> (currently gnome-vfs2-libs only).
> 
> 
> In other words: if we want samba-server using heimdal, it does NOT mean
> we need to build everything else using heimdal; client-server protocol
> effectively separates different API and ABI, symbol versioning separates
> ABI pulled in within single code executed.

It is even easier than I thought... According to
http://fedoraproject.org/wiki/Features/Samba4

"Samba 4 AD DC functionality relies heavily on Heimdal Kerberos
implementation. Samba 4 includes the embedded Heimdal, if your system
misses it, like we have in Fedora. When embedded Heimdal is in use, all
Samba 4 code is compiled against this Kerberos implementation, including
client side libraries and tools, and traditional file serving smbd
daemon we know as 'samba' package in Fedora."

we simply need to get rid of heimdal-devel and made samba use embedded
code. This all seems like another 'use system library no matter what'
PLD-like fuckup.

The next two paragraphs describe the problem I've tried to analyze:

"Heimdal and MIT Kerberos [...] have slightly different meaning to Kerberos
credential cache files format where Kerberos-aware applications store
their Kerberos keys. While this is not an issue for client-server
communication over a network (a Heimdal client does talk the same
Kerberos V protocol that MIT Kerberos server understands and vice
versa), interoperability of the client or server code using the same
credential cache files on the same system is much less supported for
advanced features like S4U2Proxy and S4U2Self.

It is generally not advisable to load two different API implementations
into the same address space either. When the rest of the system
libraries is compiled against MIT Kerberos, use of them within Samba 4
code brings in MIT Kerberos as well. This happens, for example, when
linking against OpenLDAP client libraries and using SASL
authentication."

...so what? There is no ABI conflict, one would have to deliberately mix them.

And just like I've thought, it's samba that needs to be fixed:

http://sambaxp.org/fileadmin/user_upload/SambaXP2014-DATA/wed/track2/Andreas_Schneider-TheroadtoMITKerberossupport.pdf

https://wiki.samba.org/index.php/MIT_Build

"In the merged build the build system attempts to hide Heimdal symbols
with use of various linker tricks. The merged build also uses
system-supplied libraries which are dynamically linked against the
system-provided Kerberos implementation, in our case MIT Kerberos. The
behavior of the system and the embedded Heimdal libraries is not always
consistent and breaks down in some cases.

[...] the MIT kerberos implementation stores information about it in the
ccache in the form of hints that Heimdal seem not to understand"

I don't know how did they manage to get the symbols bleeding (it was
written in 2012), but apparently there is a problem with shared
credential caches. To be honest, while using (embedded!) heimdal for AD
in samba makes sense, I don't really care for someone to have any
proxy-schmoxy-credentials-passing working at the cost of having ENTIRE
DISTRO compiled against obsoleted heimdal. PLD is not windows-centric to
sacrifice anything for AD.

For now I don't use any proxy-thingy, so it doesn't bother me if things
stay like they are, as long as heimdal-client won't break on MIT server.
However I do need MIT kerberos server working - and it's definitely not
'obsoleted' thing to put it into on FTP.

So the question is: how can I STB krb5 safely, i.e. not breaking your
heimdal-related stuff?

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


From baggins at pld-linux.org  Sat Feb 21 11:17:47 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 21 Feb 2015 11:17:47 +0100
Subject: i486 removal from Th
Message-ID: <20150221101747.GA2589@home.lan>

Hi,
I will remove i486 from Th on 28 February 2015.

>From pld-linux.org:
"""
Growing number of packages that either do not build for i486 or are
severly crippled (like IcedTea or programs requiring atomic operations)
with loss of users of this architecture caused us to finally abandon it.
"""

Simply saying - supporting i486 is a lot of pain with no gain now.

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


From qboosh at pld-linux.org  Sat Feb 21 11:45:16 2015
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sat, 21 Feb 2015 11:45:16 +0100
Subject: i486 removal from Th
In-Reply-To: <20150221101747.GA2589@home.lan>
References: <20150221101747.GA2589@home.lan>
Message-ID: <20150221104516.GA23502@mail>

On Sat, Feb 21, 2015 at 11:17:47AM +0100, Jan R?korajski wrote:
> Hi,
> I will remove i486 from Th on 28 February 2015.
> 
> From pld-linux.org:
> """
> Growing number of packages that either do not build for i486 or are
> severly crippled (like IcedTea or programs requiring atomic operations)
> with loss of users of this architecture caused us to finally abandon it.
> """

To be fair it should be said explicitly, that for Th this also means drop
of support for i586 class CPUs and some "degraded" i686 chips lacking cmov
instructions support (there were such VIA chips in mid 200x years,
probably rare to find now).


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


From gotar at polanet.pl  Sat Feb 21 17:31:17 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Sat, 21 Feb 2015 17:31:17 +0100
Subject: i486 removal from Th
In-Reply-To: <20150221101747.GA2589@home.lan>
References: <20150221101747.GA2589@home.lan>
Message-ID: <20150221163117.GA12738@polanet.pl>

On Sat, Feb 21, 2015 at 11:17:47 +0100, Jan R?korajski wrote:

> I will remove i486 from Th on 28 February 2015.

FTP contents would be moved to obsoleted or unmaintained?

And what's the status of x32? Can I STB there somehow, or is this test
just some internal thing? I might want to use this arch in a half a year
or so, so asking to be up to date.

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


From baggins at pld-linux.org  Sat Feb 21 19:00:57 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 21 Feb 2015 19:00:57 +0100
Subject: i486 removal from Th
In-Reply-To: <20150221163117.GA12738@polanet.pl>
References: <20150221101747.GA2589@home.lan>
 <20150221163117.GA12738@polanet.pl>
Message-ID: <20150221180057.GB2589@home.lan>

On Sat, 21 Feb 2015, Tomasz Pala wrote:

> On Sat, Feb 21, 2015 at 11:17:47 +0100, Jan R?korajski wrote:
> 
> > I will remove i486 from Th on 28 February 2015.
> 
> FTP contents would be moved to obsoleted or unmaintained?

Removed, Th snapshots will be left for anyone who wants to use it.

> And what's the status of x32? Can I STB there somehow, or is this test
> just some internal thing? I might want to use this arch in a half a year
> or so, so asking to be up to date.

I don't have a builder yet, planing to reuse i486 one.
But, there is one big showstopper for x32, that is broken poldek, it
just segfaults probably to memory leakage. For brave souls who want to
tackle the problem there is VirtualBox appliance available at:

http://carme.pld-linux.org/~baggins/PLDx32.ova

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


From baggins at pld-linux.org  Sat Feb 21 19:03:44 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 21 Feb 2015 19:03:44 +0100
Subject: i486 removal from Th
In-Reply-To: <20150221104516.GA23502@mail>
References: <20150221101747.GA2589@home.lan>
 <20150221104516.GA23502@mail>
Message-ID: <20150221180344.GC2589@home.lan>

On Sat, 21 Feb 2015, Jakub Bogusz wrote:

> On Sat, Feb 21, 2015 at 11:17:47AM +0100, Jan R?korajski wrote:
> > Hi,
> > I will remove i486 from Th on 28 February 2015.
> > 
> > From pld-linux.org:
> > """
> > Growing number of packages that either do not build for i486 or are
> > severly crippled (like IcedTea or programs requiring atomic operations)
> > with loss of users of this architecture caused us to finally abandon it.
> > """
> 
> To be fair it should be said explicitly, that for Th this also means drop
> of support for i586 class CPUs and some "degraded" i686 chips lacking cmov
> instructions support (there were such VIA chips in mid 200x years,
> probably rare to find now).

Thanks, added this to main page.

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


From megabajt at pld-linux.org  Sun Feb 22 02:37:34 2015
From: megabajt at pld-linux.org (Marcin Banasiak)
Date: Sun, 22 Feb 2015 02:37:34 +0100
Subject: i486 removal from Th
In-Reply-To: <20150221180057.GB2589@home.lan>
References: <20150221101747.GA2589@home.lan>
 <20150221163117.GA12738@polanet.pl>
 <20150221180057.GB2589@home.lan>
Message-ID: <CAJgtVYDRDg5e+m4dbRLxcJzkUnmQtVh2qRgtH5gD2HHCrV3dRw@mail.gmail.com>

2015-02-21 19:00 GMT+01:00 Jan R?korajski <baggins at pld-linux.org>:
> On Sat, 21 Feb 2015, Tomasz Pala wrote:
>
>> On Sat, Feb 21, 2015 at 11:17:47 +0100, Jan R?korajski wrote:
>>
>> > I will remove i486 from Th on 28 February 2015.
>>
>> FTP contents would be moved to obsoleted or unmaintained?
>
> Removed, Th snapshots will be left for anyone who wants to use it.
>
>> And what's the status of x32? Can I STB there somehow, or is this test
>> just some internal thing? I might want to use this arch in a half a year
>> or so, so asking to be up to date.
>
> I don't have a builder yet, planing to reuse i486 one.
> But, there is one big showstopper for x32, that is broken poldek,

Already fixed.

-- 
Marcin Banasiak


From baggins at pld-linux.org  Sun Feb 22 10:03:52 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 22 Feb 2015 10:03:52 +0100
Subject: i486 removal from Th
In-Reply-To: <CAJgtVYDRDg5e+m4dbRLxcJzkUnmQtVh2qRgtH5gD2HHCrV3dRw@mail.gmail.com>
References: <20150221101747.GA2589@home.lan>
 <20150221163117.GA12738@polanet.pl>
 <20150221180057.GB2589@home.lan>
 <CAJgtVYDRDg5e+m4dbRLxcJzkUnmQtVh2qRgtH5gD2HHCrV3dRw@mail.gmail.com>
Message-ID: <20150222090352.GA2587@home.lan>

On Sun, 22 Feb 2015, Marcin Banasiak wrote:

> 2015-02-21 19:00 GMT+01:00 Jan R?korajski <baggins at pld-linux.org>:
> > On Sat, 21 Feb 2015, Tomasz Pala wrote:
> >
> >> On Sat, Feb 21, 2015 at 11:17:47 +0100, Jan R?korajski wrote:
> >>
> >> > I will remove i486 from Th on 28 February 2015.
> >>
> >> FTP contents would be moved to obsoleted or unmaintained?
> >
> > Removed, Th snapshots will be left for anyone who wants to use it.
> >
> >> And what's the status of x32? Can I STB there somehow, or is this test
> >> just some internal thing? I might want to use this arch in a half a year
> >> or so, so asking to be up to date.
> >
> > I don't have a builder yet, planing to reuse i486 one.
> > But, there is one big showstopper for x32, that is broken poldek,
> 
> Already fixed.

Thank you! That was fast!
And to think I spent few hours with debugger on this :/

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


From glen at pld-linux.org  Sun Feb 22 22:13:54 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Sun, 22 Feb 2015 23:13:54 +0200
Subject: poldek: error: Mesa-libOpenVG-devel: no such package
Message-ID: <54EA4692.8040707@pld-linux.org>

qt5-qtbase doesn't build due that, and it's not even bconded.

-- 
glen



From baggins at pld-linux.org  Sun Feb 22 22:38:14 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 22 Feb 2015 22:38:14 +0100
Subject: poldek: error: Mesa-libOpenVG-devel: no such package
In-Reply-To: <54EA4692.8040707@pld-linux.org>
References: <54EA4692.8040707@pld-linux.org>
Message-ID: <20150222213813.GA1881@home.lan>

On Sun, 22 Feb 2015, Elan Ruusam?e wrote:

> qt5-qtbase doesn't build due that, and it's not even bconded.

It's unsupported in current Mesa.
You could just copy-paste the bcond from qt4, what I just did.

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


From mike at altlinux.org  Sun Feb 22 23:47:03 2015
From: mike at altlinux.org (Michael Shigorin)
Date: Mon, 23 Feb 2015 01:47:03 +0300
Subject: i486 removal from Th
In-Reply-To: <20150221104516.GA23502@mail>
References: <20150221101747.GA2589@home.lan> <20150221104516.GA23502@mail>
Message-ID: <20150222224703.GQ1226@imap.altlinux.org>

On Sat, Feb 21, 2015 at 11:45:16AM +0100, Jakub Bogusz wrote:
> To be fair it should be said explicitly, that for Th this also
> means drop of support for i586 class CPUs and some "degraded"
> i686 chips lacking cmov instructions support (there were such
> VIA chips in mid 200x years, probably rare to find now).

I've got an (untested) patch by a colleague that should emulate
CMOV on i586, could dust off the archives if there's anyone
interested out there.  It might also have been included in
kernel-image-led-tc package.

Optimizing for i586 (nee Pentium) is very wrong for pretty much
any other x86 processor due to significant pipeline differences
AFAIH...

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


From baggins at pld-linux.org  Mon Feb 23 00:49:57 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 23 Feb 2015 00:49:57 +0100
Subject: poldek: error: Mesa-libOpenVG-devel: no such package
In-Reply-To: <20150222213813.GA1881@home.lan>
References: <54EA4692.8040707@pld-linux.org> <20150222213813.GA1881@home.lan>
Message-ID: <20150222234957.GB1881@home.lan>

On Sun, 22 Feb 2015, Jan R?korajski wrote:

> On Sun, 22 Feb 2015, Elan Ruusam?e wrote:
> 
> > qt5-qtbase doesn't build due that, and it's not even bconded.
> 
> It's unsupported in current Mesa.
> You could just copy-paste the bcond from qt4, what I just did.

error: File not found: /tmp/B.5e7d07cd-c142-43fa-b100-ce185430a849/BUILD/tmp/qt5-qtbase-5.3.2-root-builder/usr/include/qt5/QtSolutions

So, qt5 as such builds. You can get back to fixing your changes to the
spec :)

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


From baggins at pld-linux.org  Mon Feb 23 20:55:03 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 23 Feb 2015 20:55:03 +0100
Subject: x32 arch in Th
Message-ID: <20150223195502.GA3210@home.lan>

It landed. It's available for playing, you can send build requests
to th-x32. There are no buildlogs yet, they will be visible soon.

Oh, and if you send generic request for all archs and it fails
on x32 you can ignore it for now.

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


From baggins at pld-linux.org  Tue Feb 24 09:11:32 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 24 Feb 2015 09:11:32 +0100
Subject: xorg drivers obsolescence
Message-ID: <20150224081131.GA5908@home.lan>

The following drivers will be removed soon during xserver updrade to
version 1.17:

xorg-driver-video-chips
xorg-driver-video-cirrus
xorg-driver-video-geode
xorg-driver-video-mach64
xorg-driver-video-neomagic
xorg-driver-video-r128
xorg-driver-video-rendition
xorg-driver-video-s3virge
xorg-driver-video-savage
xorg-driver-video-siliconmotion
xorg-driver-video-sis
xorg-driver-video-tdfx
xorg-driver-video-xgixp

They are unmaintained and/or do not support KMS and, obviously, do not
buid with current xserver.

If you care for any of them please fix it.

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


From adwol at zonk.pl  Sat Feb 28 23:30:10 2015
From: adwol at zonk.pl (Adam Osuchowski)
Date: Sat, 28 Feb 2015 23:30:10 +0100
Subject: [packages/sqlite3] drop pointless year macro
In-Reply-To: <9ff1c54dc27e48a465cfd09860bd031e6923c26a_refs_heads_master@pld-linux.org>
References: <cd683928bc30d8dd3569bf05b63d470b878093c3_refs_heads_master@pld-linux.org>
 <9ff1c54dc27e48a465cfd09860bd031e6923c26a_refs_heads_master@pld-linux.org>
Message-ID: <20150228223010.6b8b4567@zonk.pl>

glen wrote:
> commit 9ff1c54dc27e48a465cfd09860bd031e6923c26a
> Author: Elan Ruusam?e <glen at delfi.ee>
> Date:   Thu Feb 26 22:08:01 2015 +0200
> 
>     drop pointless year macro
> 
>  sqlite3.spec | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> ---
> diff --git a/sqlite3.spec b/sqlite3.spec
> index 0e3842c..63fe775 100644
> --- a/sqlite3.spec
> +++ b/sqlite3.spec
> @@ -20,12 +20,9 @@
>  %undefine	with_tests
>  %endif
>  
> -%define		version_year	2015
>  #define		version_num %(echo %{version} |  awk -F. '{printf("%d%02d%02d%02d", $1, $2, $3, $4)}')
>  %define		version_num	3080803
> -%define		_ulibdir	/usr/lib
>  %define		tclver		8.6


No, it isn't pointless! The values of url and other tags should be universal
as much as possible. In case of version updating, the year in url may change
and nobody wants to wonder if any part of any tag should be updated in
connection with it. Macros is designed for such cases and clearly points
what should to pay attention to.

If %version_year is pointless, the %version_num is pointless too and should
be removed alike. Please keep coherent.

Think logically about changes you apply before you do it and don't
determine and change anything basing on your private judgements and point
of view only. Your are not the one-man oracle! Once again, your behaviour,
manners and collaborative skills leave a lot to be desired.