From baggins at pld-linux.org  Sat Dec  1 00:04:47 2012
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 1 Dec 2012 00:04:47 +0100
Subject: rpm-5.4.10-22.i686 loops forever when installing
 ntpd-4.2.6p5-5.i686.rpm
In-Reply-To: <C6A424EA-8C0E-4824-A6B8-9AF986EBD049@me.com>
References: <50846358.8090607@pld-linux.org>
 <20121130124153.GG29634@sith.mimuw.edu.pl>
 <A5007971-5A9D-4C3D-B7D4-EADF5462197F@me.com>
 <20121130195308.GB1688@home.lan>
 <B174647C-2983-493A-BD47-B76811FA4EC7@me.com>
 <20121130204713.GC1688@home.lan>
 <C6A424EA-8C0E-4824-A6B8-9AF986EBD049@me.com>
Message-ID: <20121130230447.GE1688@home.lan>

On Fri, 30 Nov 2012, Jeffrey Johnson wrote:

> 
> On Nov 30, 2012, at 3:47 PM, Jan R?korajski <baggins at pld-linux.org> wrote:
> 
> > BTW, did you look into the problem with triggers arguments?
> > 
> 
> Nope. I have yet to be convinced of what the root
> cause is: all you have been telling me is that
> 	RPM5 is buggy
> and I'm pretty sure the final solution has yet to be seen.

Build packages from attached spec. Install them both in one set.
According to trigger documentation (and it was always working) you should see:

triggerin:test-0.1-0.1
#: 2
1: 1
2: 1

But with RPM5 arg2 is 0. And I tell you again that RPM5 is buggy here.

-- 
Jan R?korajski                                 | PLD/Linux
SysAdm                                         | http://www.pld-linux.org/
baggins<at>mimuw.edu.pl
baggins<at>pld-linux.org
-------------- next part --------------
Summary:	source trigger test
Name:		test
Version:	0.1
Release:	0.1
License:	GPL
Group:		Applications/System
BuildArch:	noarch
BuildRoot:	%{tmpdir}/%{name}-%{version}-root-%(id -u -n)

%description
source trigger test

%package target
Summary:	target trigger test

%description target
target trigger test

%prep
%setup -qcT

%install
rm -rf $RPM_BUILD_ROOT

%triggerin -- test-target
echo triggerin:%{name}-%{version}-%{release}
echo "#: $#"
echo "1: $1"
echo "2: $2"

%triggerun -- test-target
echo triggerun:%{name}-%{version}-%{release}
echo "#: $#"
echo "1: $1"
echo "2: $2"

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(644,root,root,755)

%files target
%defattr(644,root,root,755)

From n3npq at mac.com  Sat Dec  1 01:33:14 2012
From: n3npq at mac.com (Jeffrey Johnson)
Date: Fri, 30 Nov 2012 19:33:14 -0500
Subject: rpm-5.4.10-22.i686 loops forever when installing
 ntpd-4.2.6p5-5.i686.rpm
In-Reply-To: <20121130230447.GE1688@home.lan>
References: <50846358.8090607@pld-linux.org>
 <20121130124153.GG29634@sith.mimuw.edu.pl>
 <A5007971-5A9D-4C3D-B7D4-EADF5462197F@me.com> <20121130195308.GB1688@home.lan>
 <B174647C-2983-493A-BD47-B76811FA4EC7@me.com> <20121130204713.GC1688@home.lan>
 <C6A424EA-8C0E-4824-A6B8-9AF986EBD049@me.com> <20121130230447.GE1688@home.lan>
Message-ID: <B4619AF9-AF48-4B38-AFFE-6DA53BE17A6A@mac.com>

Try each of the 2 order permutations.

FWIW the behavior of triggers from already installed packages when both
Packages are in the same transaction
Has _NEVER_ been documented anywhere I am aware of precisely.

I'll actually try the test.spec if my guess above isn't correct ;-)

73 de Jeff

Sent from my iPhone

On Nov 30, 2012, at 6:04 PM, Jan R?korajski <baggins at pld-linux.org> wrote:

> On Fri, 30 Nov 2012, Jeffrey Johnson wrote:
> 
>> 
>> On Nov 30, 2012, at 3:47 PM, Jan R?korajski <baggins at pld-linux.org> wrote:
>> 
>>> BTW, did you look into the problem with triggers arguments?
>> 
>> Nope. I have yet to be convinced of what the root
>> cause is: all you have been telling me is that
>>    RPM5 is buggy
>> and I'm pretty sure the final solution has yet to be seen.
> 
> Build packages from attached spec. Install them both in one set.
> According to trigger documentation (and it was always working) you should see:
> 
> triggerin:test-0.1-0.1
> #: 2
> 1: 1
> 2: 1
> 
> But with RPM5 arg2 is 0. And I tell you again that RPM5 is buggy here.
> 
> -- 
> Jan R?korajski                                 | PLD/Linux
> SysAdm                                         | http://www.pld-linux.org/
> baggins<at>mimuw.edu.pl
> baggins<at>pld-linux.org
> <test.spec>
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


From baggins at pld-linux.org  Sat Dec  1 10:47:57 2012
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 1 Dec 2012 10:47:57 +0100
Subject: rpm-5.4.10-22.i686 loops forever when installing
 ntpd-4.2.6p5-5.i686.rpm
In-Reply-To: <B4619AF9-AF48-4B38-AFFE-6DA53BE17A6A@mac.com>
References: <50846358.8090607@pld-linux.org>
 <20121130124153.GG29634@sith.mimuw.edu.pl>
 <A5007971-5A9D-4C3D-B7D4-EADF5462197F@me.com>
 <20121130195308.GB1688@home.lan>
 <B174647C-2983-493A-BD47-B76811FA4EC7@me.com>
 <20121130204713.GC1688@home.lan>
 <C6A424EA-8C0E-4824-A6B8-9AF986EBD049@me.com>
 <20121130230447.GE1688@home.lan>
 <B4619AF9-AF48-4B38-AFFE-6DA53BE17A6A@mac.com>
Message-ID: <20121201094757.GA1708@home.lan>

On Fri, 30 Nov 2012, Jeffrey Johnson wrote:

> Try each of the 2 order permutations.
> 
> FWIW the behavior of triggers from already installed packages when both
> Packages are in the same transaction
> Has _NEVER_ been documented anywhere I am aware of precisely.

As I understand the docs, it should work exacty the same regardles if
it's in one transaction or not.

Quote:

Recall that the $1 passed to regular scripts contains the number of
instances of the package which will be installed when the operation has
completed. $1 for triggers is exactly the same -- it is the number of
instances of the source (or triggered) package which will remain when
the trigger has completed. Similarly, $2 is the number of instances of
the target package which will remain.

> I'll actually try the test.spec if my guess above isn't correct ;-)

Both permutations are wrong, $1 and $2 should be 1 in both cases.

[root at sith RPMS]# rpm -Uvh test-0.1-0.1.noarch.rpm 
Preparing...                ########################################### [100%]
   1:test                   ########################################### [100%]
[root at sith RPMS]# rpm -Uvh test-target-0.1-0.1.noarch.rpm 
Preparing...                ########################################### [100%]
   1:test-target            ########################################### [100%]
triggerin:test-0.1-0.1
#: 2
1: 1
2: 0

[root at sith RPMS]# rpm -Uvh test-target-0.1-0.1.noarch.rpm 
Preparing...                ########################################### [100%]
   1:test-target            ########################################### [100%]
[root at sith RPMS]# rpm -Uvh test-0.1-0.1.noarch.rpm 
Preparing...                ########################################### [100%]
   1:test                   ########################################### [100%]
triggerin:test-0.1-0.1
#: 2
1: 0
2: 1


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


From n3npq at me.com  Sat Dec  1 12:23:27 2012
From: n3npq at me.com (Jeffrey Johnson)
Date: Sat, 01 Dec 2012 06:23:27 -0500
Subject: rpm-5.4.10-22.i686 loops forever when installing
 ntpd-4.2.6p5-5.i686.rpm
In-Reply-To: <20121201094757.GA1708@home.lan>
References: <50846358.8090607@pld-linux.org>
 <20121130124153.GG29634@sith.mimuw.edu.pl>
 <A5007971-5A9D-4C3D-B7D4-EADF5462197F@me.com> <20121130195308.GB1688@home.lan>
 <B174647C-2983-493A-BD47-B76811FA4EC7@me.com> <20121130204713.GC1688@home.lan>
 <C6A424EA-8C0E-4824-A6B8-9AF986EBD049@me.com> <20121130230447.GE1688@home.lan>
 <B4619AF9-AF48-4B38-AFFE-6DA53BE17A6A@mac.com>
 <20121201094757.GA1708@home.lan>
Message-ID: <988166DB-48A8-4697-9617-9AB634930ECF@me.com>


On Dec 1, 2012, at 4:47 AM, Jan R?korajski <baggins at pld-linux.org> wrote:

> On Fri, 30 Nov 2012, Jeffrey Johnson wrote:
> 
>> Try each of the 2 order permutations.
>> 
>> FWIW the behavior of triggers from already installed packages when both
>> Packages are in the same transaction
>> Has _NEVER_ been documented anywhere I am aware of precisely.
> 
> As I understand the docs, it should work exacty the same regardles if
> it's in one transaction or not.
> 

Your understanding isn't what is implemented.

The Triggername index in an rpmdb is used to find
what triggers fire in other packages.

There is no attempt to find triggers in the "added set",
i.e. in other packages in the same transaction. Should
a trigger be run from a package that isn't yet installed?

> 
> 
> Recall that the $1 passed to regular scripts contains the number of
> instances of the package which will be installed when the operation has
> completed. $1 for triggers is exactly the same -- it is the number of
> instances of the source (or triggered) package which will remain when
> the trigger has completed. Similarly, $2 is the number of instances of
> the target package which will remain.
> 
>> I'll actually try the test.spec if my guess above isn't correct ;-)
> 
> Both permutations are wrong, $1 and $2 should be 1 in both cases.
> 
> [root at sith RPMS]# rpm -Uvh test-0.1-0.1.noarch.rpm 
> Preparing...                ########################################### [100%]
>   1:test                   ########################################### [100%]
> [root at sith RPMS]# rpm -Uvh test-target-0.1-0.1.noarch.rpm 
> Preparing...                ########################################### [100%]
>   1:test-target            ########################################### [100%]
> triggerin:test-0.1-0.1
> #: 2
> 1: 1
> 2: 0
> 
> [root at sith RPMS]# rpm -Uvh test-target-0.1-0.1.noarch.rpm 
> Preparing...                ########################################### [100%]
>   1:test-target            ########################################### [100%]
> [root at sith RPMS]# rpm -Uvh test-0.1-0.1.noarch.rpm 
> Preparing...                ########################################### [100%]
>   1:test                   ########################################### [100%]
> triggerin:test-0.1-0.1
> #: 2
> 1: 0
> 2: 1
> 

OK I will look this weekend.

73 de Jeff
> 
> -- 
> Jan R?korajski                                 | PLD/Linux
> SysAdm                                         | http://www.pld-linux.org/
> baggins<at>mimuw.edu.pl
> baggins<at>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 jajcus at jajcus.net  Sat Dec  1 15:48:21 2012
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Sat, 1 Dec 2012 15:48:21 +0100
Subject: Why vim depends on vim-rt
In-Reply-To: <20121130202631.GA25853@camk.edu.pl>
References: <20121130202631.GA25853@camk.edu.pl>
Message-ID: <20121201144821.GA3706@lolek.nigdzie>

On Fri, Nov 30, 2012 at 09:26:31PM +0100, Kacper Kornet wrote:
> But I've been just surprised that it is actually required by vim? Does
> someone know the reason? For test I installed vim without vim-rt and it
> seems to work. But maybe I'm missing something.

I guess this requirement was added before we had 'Suggests' in RPM, as
this was then the only way for 'suggesting' important packages.

Greets,
        Jacek


From n3npq at me.com  Sat Dec  1 16:55:14 2012
From: n3npq at me.com (Jeffrey Johnson)
Date: Sat, 01 Dec 2012 10:55:14 -0500
Subject: rpm-5.4.10-22.i686 loops forever when installing
 ntpd-4.2.6p5-5.i686.rpm
In-Reply-To: <988166DB-48A8-4697-9617-9AB634930ECF@me.com>
References: <50846358.8090607@pld-linux.org>
 <20121130124153.GG29634@sith.mimuw.edu.pl>
 <A5007971-5A9D-4C3D-B7D4-EADF5462197F@me.com> <20121130195308.GB1688@home.lan>
 <B174647C-2983-493A-BD47-B76811FA4EC7@me.com> <20121130204713.GC1688@home.lan>
 <C6A424EA-8C0E-4824-A6B8-9AF986EBD049@me.com> <20121130230447.GE1688@home.lan>
 <B4619AF9-AF48-4B38-AFFE-6DA53BE17A6A@mac.com>
 <20121201094757.GA1708@home.lan> <988166DB-48A8-4697-9617-9AB634930ECF@me.com>
Message-ID: <E283065D-F1FD-4F7B-847F-08F220EC2BFA@me.com>


On Dec 1, 2012, at 6:23 AM, Jeffrey Johnson <n3npq at me.com> wrote:

>> 
>> Both permutations are wrong, $1 and $2 should be 1 in both cases.
>> 
>> [root at sith RPMS]# rpm -Uvh test-0.1-0.1.noarch.rpm 
>> Preparing...                ########################################### [100%]
>>  1:test                   ########################################### [100%]
>> [root at sith RPMS]# rpm -Uvh test-target-0.1-0.1.noarch.rpm 
>> Preparing...                ########################################### [100%]
>>  1:test-target            ########################################### [100%]
>> triggerin:test-0.1-0.1
>> #: 2
>> 1: 1
>> 2: 0
>> 
>> [root at sith RPMS]# rpm -Uvh test-target-0.1-0.1.noarch.rpm 
>> Preparing...                ########################################### [100%]
>>  1:test-target            ########################################### [100%]
>> [root at sith RPMS]# rpm -Uvh test-0.1-0.1.noarch.rpm 
>> Preparing...                ########################################### [100%]
>>  1:test                   ########################################### [100%]
>> triggerin:test-0.1-0.1
>> #: 2
>> 1: 0
>> 2: 1
>> 
> 
> OK I will look this weekend.
> 


(aside)
Good: The behavior is symmetric when permuted.

The documentation states that $1/$2 are the number of pkg instances
after the script is run. This isn't precise enough a definition
when there is an ACID transaction with a 2phase commit/discard
(as in rpm5).

The definition of "installed" is the same (in rpm-5.4.10) as
	Is the database transaction committed?

The commit depends on whether scripts/triggers
(with the $1/$2 counts) succeed. In addition,
the status of all scripts run during install
is added to the header before being saved in an
rpmdb.

This leads to a chicken <=> egg behavior, where the
header cannot be committed until the scripts are run
and the script arguments can't be computed until the
header is committed in the rpmdb.

(aside)
There is the further issue of what degree of isolation
(and visibility) of concurrent transactions. The code
as written has full degree 2 isolation; if the header
is added to the rpmdb sooner, and pending/uncommitted
data is made visible, then the counts would be as you expect.

Until saved (and the ACID transaction is committed), the
0 being seen above is consistent with interpreting
	installed == header registered/committed
(see the PSM_POST case in lib/psm.c,
where the rpmtxnCommit() call is done as part of PSM_RPMDB_ADD).

I'm inclined atm to prefer the above actual behavior to "fudging" an
extra +1 for "legacy compatible" behavior; I'm sure we disagree here.

Short answer: patch in an extra +1 (there will be two code paths in need
of patching, check for symmetry as above) if you wish "legacy compatible" behavior.

hth

73 de Jeff


From n3npq at me.com  Sat Dec  1 17:03:54 2012
From: n3npq at me.com (Jeffrey Johnson)
Date: Sat, 01 Dec 2012 11:03:54 -0500
Subject: rpm-5.4.10-22.i686 loops forever when installing
 ntpd-4.2.6p5-5.i686.rpm
In-Reply-To: <E283065D-F1FD-4F7B-847F-08F220EC2BFA@me.com>
References: <50846358.8090607@pld-linux.org>
 <20121130124153.GG29634@sith.mimuw.edu.pl>
 <A5007971-5A9D-4C3D-B7D4-EADF5462197F@me.com> <20121130195308.GB1688@home.lan>
 <B174647C-2983-493A-BD47-B76811FA4EC7@me.com> <20121130204713.GC1688@home.lan>
 <C6A424EA-8C0E-4824-A6B8-9AF986EBD049@me.com> <20121130230447.GE1688@home.lan>
 <B4619AF9-AF48-4B38-AFFE-6DA53BE17A6A@mac.com>
 <20121201094757.GA1708@home.lan> <988166DB-48A8-4697-9617-9AB634930ECF@me.com>
 <E283065D-F1FD-4F7B-847F-08F220EC2BFA@me.com>
Message-ID: <E6B27B9A-260C-450A-B8C3-F7F154B8F439@me.com>


On Dec 1, 2012, at 10:55 AM, Jeffrey Johnson <n3npq at me.com> wrote:

> 
> I'm inclined atm to prefer the above actual behavior to "fudging" an
> extra +1 for "legacy compatible" behavior; I'm sure we disagree here.
> 
> Short answer: patch in an extra +1 (there will be two code paths in need
> of patching, check for symmetry as above) if you wish "legacy compatible" behavior.
> 

This is likely all that is needed (untested):

cvs diff psm.c
Index: psm.c
===================================================================
RCS file: /v/rpm/cvs/rpm/lib/psm.c,v
retrieving revision 2.399.2.5
diff -p -u -w -r2.399.2.5 psm.c
--- psm.c	19 Apr 2012 17:26:06 -0000	2.399.2.5
+++ psm.c	1 Dec 2012 16:02:48 -0000
@@ -2755,7 +2755,7 @@ assert(psm->te != NULL);
 	    psm->scriptTag = RPMTAG_POSTIN;
 	    psm->progTag = RPMTAG_POSTINPROG;
 	    psm->sense = RPMSENSE_TRIGGERIN;
-	    psm->countCorrection = 0;
+	    psm->countCorrection = 1;
 
 	    if (!(rpmtsFlags(ts) & RPMTRANS_FLAG_NOPOST)) {
 		rc = (rpmRC) rpmpsmNext(psm, PSM_SCRIPT);



From baggins at pld-linux.org  Sat Dec  1 23:12:48 2012
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 1 Dec 2012 23:12:48 +0100
Subject: rpm-5.4.10-22.i686 loops forever when installing
 ntpd-4.2.6p5-5.i686.rpm
In-Reply-To: <E283065D-F1FD-4F7B-847F-08F220EC2BFA@me.com>
References: <A5007971-5A9D-4C3D-B7D4-EADF5462197F@me.com>
 <20121130195308.GB1688@home.lan>
 <B174647C-2983-493A-BD47-B76811FA4EC7@me.com>
 <20121130204713.GC1688@home.lan>
 <C6A424EA-8C0E-4824-A6B8-9AF986EBD049@me.com>
 <20121130230447.GE1688@home.lan>
 <B4619AF9-AF48-4B38-AFFE-6DA53BE17A6A@mac.com>
 <20121201094757.GA1708@home.lan>
 <988166DB-48A8-4697-9617-9AB634930ECF@me.com>
 <E283065D-F1FD-4F7B-847F-08F220EC2BFA@me.com>
Message-ID: <20121201221248.GB1708@home.lan>

On Sat, 01 Dec 2012, Jeffrey Johnson wrote:

> (aside)
> Good: The behavior is symmetric when permuted.
> 
> The documentation states that $1/$2 are the number of pkg instances
> after the script is run. This isn't precise enough a definition
> when there is an ACID transaction with a 2phase commit/discard
> (as in rpm5).
> 
> The definition of "installed" is the same (in rpm-5.4.10) as
> 	Is the database transaction committed?
> 
> The commit depends on whether scripts/triggers
> (with the $1/$2 counts) succeed. In addition,
> the status of all scripts run during install
> is added to the header before being saved in an
> rpmdb.
> 
> This leads to a chicken <=> egg behavior, where the
> header cannot be committed until the scripts are run
> and the script arguments can't be computed until the
> header is committed in the rpmdb.
> 
> (aside)
> There is the further issue of what degree of isolation
> (and visibility) of concurrent transactions. The code
> as written has full degree 2 isolation; if the header
> is added to the rpmdb sooner, and pending/uncommitted
> data is made visible, then the counts would be as you expect.
> 
> Until saved (and the ACID transaction is committed), the
> 0 being seen above is consistent with interpreting
> 	installed == header registered/committed
> (see the PSM_POST case in lib/psm.c,
> where the rpmtxnCommit() call is done as part of PSM_RPMDB_ADD).
> 
> I'm inclined atm to prefer the above actual behavior to "fudging" an
> extra +1 for "legacy compatible" behavior; I'm sure we disagree here.
> 
> Short answer: patch in an extra +1 (there will be two code paths in need
> of patching, check for symmetry as above) if you wish "legacy compatible" behavior.

Thank you for explanation and the patch, I tested it and it does bring back
"legacy compatible" behavior. We do need that.

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


From glen at pld-linux.org  Sun Dec  2 00:01:12 2012
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Sun, 02 Dec 2012 01:01:12 +0200
Subject: Why vim depends on vim-rt
In-Reply-To: <20121201144821.GA3706@lolek.nigdzie>
References: <20121130202631.GA25853@camk.edu.pl>
 <20121201144821.GA3706@lolek.nigdzie>
Message-ID: <50BA8C38.3000004@pld-linux.org>

On 12/01/2012 04:48 PM, Jacek Konieczny wrote:
> On Fri, Nov 30, 2012 at 09:26:31PM +0100, Kacper Kornet wrote:
>> But I've been just surprised that it is actually required by vim? Does
>> someone know the reason? For test I installed vim without vim-rt and it
>> seems to work. But maybe I'm missing something.
> I guess this requirement was added before we had 'Suggests' in RPM, as
> this was then the only way for 'suggesting' important packages.
>

indeed, i tracked it down to "new spec" commit:
https://github.com/pld-linux/vim/commit/84c81deac1cf3fd51061cdce146053df71d64297

-- 
glen



From glen at pld-linux.org  Sun Dec  2 11:46:32 2012
From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=C3=A4e?=)
Date: Sun, 02 Dec 2012 12:46:32 +0200
Subject: messed up deps in th
In-Reply-To: <50A790C3.8010105@pld-linux.org>
References: <50A78AA7.8050308@pld-linux.org> <2207558.rsn8WFU00Z@localhost>
 <50A790C3.8010105@pld-linux.org>
Message-ID: <3883b51b577e432a16a9b96482d9c14d@delfi.ee>

On 2012-11-17 15:27, Elan Ruusam?e wrote:
> On 11/17/2012 03:14 PM, Pawe? Sikora wrote:
>> https://bugs.launchpad.net/pld-linux/+bug/1071000
>>
>
> well, imho first case can be easily fixed by removing unversioned
> provides: coreutils-su

and besides, it's broken with rpm4.5 as well:


12:42:30 root[load: 0.24]@glen local/bin# poldek --up -u SysVinit-tools
...
Processing dependencies...
SysVinit-tools-2.88-7.x86_64 obsoleted by SysVinit-tools-2.88-9.x86_64
   greedy upgrade SysVinit-2.88-7.x86_64 to 2.88-9.x86_64 (unresolved 
SysVinit-tools = 2.88-7)
    SysVinit-2.88-7.x86_64 obsoleted by SysVinit-2.88-9.x86_64
SysVinit-tools-2.88-9.x86_64 marks util-linux-2.22.1-1.x86_64 (cap 
util-linux >= 2.22)
  coreutils-8.16-1.x86_64 obsoleted by util-linux-2.22.1-1.x86_64
  util-linux-2.21.2-3.x86_64 obsoleted by util-linux-2.22.1-1.x86_64
error: fileutils is required by installed 
procps-3.2.8-1.20111124.1.x86_64, give up
12:43:45 root[load: 0.15]@glen local/bin# rpm -q poldek rpm
poldek-0.30-1.rc5.14.x86_64
rpm-4.5-69.x86_64
12:43:51 root[load: 0.14]@glen local/bin#

some other POV's:

12:45:16 root[load: 0.11]@glen local/bin# poldek -u util-linux -tv
...
Processing dependencies...
coreutils-8.16-1.x86_64 obsoleted by util-linux-2.22.1-1.x86_64
util-linux-2.21.2-3.x86_64 obsoleted by util-linux-2.22.1-1.x86_64
error: fileutils is required by installed 
procps-3.2.8-1.20111124.1.x86_64, give up

12:45:16 root[load: 0.11]@glen local/bin# poldek -u util-linux -tv
...
Processing dependencies...
coreutils-8.16-1.x86_64 obsoleted by coreutils-8.20-1.x86_64
coreutils-8.20-1.x86_64 marks glibc-2.16.0-4.x86_64 (cap 
/usr/share/locale/hr/LC_TIME)
  glibc-2.16.0-1.x86_64 obsoleted by glibc-2.16.0-4.x86_64
    greedy upgrade glibc-libcrypt-2.16.0-1.x86_64 to 2.16.0-4.x86_64 
(unresolved glibc = 6:2.16.0-1)
     glibc-libcrypt-2.16.0-1.x86_64 obsoleted by 
glibc-libcrypt-2.16.0-4.x86_64
       greedy upgrade glibc-devel-2.16.0-1.x86_64 to 2.16.0-4.x86_64 
(unresolved glibc-libcrypt(x86_64) = 6:2.16.0-1)
        glibc-devel-2.16.0-1.x86_64 obsoleted by 
glibc-devel-2.16.0-4.x86_64
        glibc-devel-2.16.0-4.x86_64 marks 
glibc-devel-utils-2.16.0-4.x86_64 (cap glibc-devel-utils = 6:2.16.0-4)
         glibc-devel-utils-2.16.0-1.x86_64 obsoleted by 
glibc-devel-utils-2.16.0-4.x86_64
        glibc-devel-2.16.0-4.x86_64 marks glibc-headers-2.16.0-4.x86_64 
(cap glibc-headers(64bit) = 6:2.16.0-4)
         glibc-headers-2.16.0-1.x86_64 obsoleted by 
glibc-headers-2.16.0-4.x86_64
    greedy upgrade glibc-misc-2.16.0-1.x86_64 to 2.16.0-4.x86_64 
(unresolved glibc = 6:2.16.0-1)
     glibc-misc-2.16.0-1.x86_64 obsoleted by glibc-misc-2.16.0-4.x86_64
    greedy upgrade iconv-2.16.0-1.x86_64 to 2.16.0-4.x86_64 (unresolved 
glibc = 6:2.16.0-1)
     iconv-2.16.0-1.x86_64 obsoleted by iconv-2.16.0-4.x86_64
    greedy upgrade localedb-src-2.16.0-1.x86_64 to 2.16.0-4.x86_64 
(unresolved glibc = 6:2.16.0-1)
     localedb-src-2.16.0-1.x86_64 obsoleted by 
localedb-src-2.16.0-4.x86_64
  glibc-2.16.0-4.x86_64 marks ldconfig-2.16.0-4.x86_64 (cap ldconfig = 
6:2.16.0-4)
   ldconfig-2.16.0-1.x86_64 obsoleted by ldconfig-2.16.0-4.x86_64
coreutils-8.20-1.x86_64 marks util-linux-2.22.1-1.x86_64 (cap 
util-linux >= 2.22)
  util-linux-2.21.2-3.x86_64 obsoleted by util-linux-2.22.1-1.x86_64
  util-linux-2.22.1-1.x86_64 marks libblkid-2.22.1-1.x86_64 (cap 
libblkid = 2.22.1-1)
   libblkid-2.21.2-3.x86_64 obsoleted by libblkid-2.22.1-1.x86_64
   libblkid-2.22.1-1.x86_64 marks libuuid-2.22.1-1.x86_64 (cap libuuid = 
2.22.1-1)
    libuuid-2.21.2-3.x86_64 obsoleted by libuuid-2.22.1-1.x86_64
  util-linux-2.22.1-1.x86_64 marks libmount-2.22.1-1.x86_64 (cap 
libmount.so.1()(64bit))
  util-linux-2.22.1-1.x86_64 marks SysVinit-tools-2.88-9.x86_64 (cap 
SysVinit-tools >= 2.88-9)
   SysVinit-tools-2.88-7.x86_64 obsoleted by 
SysVinit-tools-2.88-9.x86_64
     greedy upgrade SysVinit-2.88-7.x86_64 to 2.88-9.x86_64 (unresolved 
SysVinit-tools = 2.88-7)
      SysVinit-2.88-7.x86_64 obsoleted by SysVinit-2.88-9.x86_64
There are 16 packages to install (15 marked by dependencies), 15 to 
remove:
I coreutils-8.20-1.x86_64
D SysVinit-2.88-9.x86_64  SysVinit-tools-2.88-9.x86_64  
glibc-2.16.0-4.x86_64  glibc-devel-2.16.0-4.x86_64
D glibc-devel-utils-2.16.0-4.x86_64  glibc-headers-2.16.0-4.x86_64  
glibc-libcrypt-2.16.0-4.x86_64
D glibc-misc-2.16.0-4.x86_64  iconv-2.16.0-4.x86_64  
ldconfig-2.16.0-4.x86_64  libblkid-2.22.1-1.x86_64
D libmount-2.22.1-1.x86_64  libuuid-2.22.1-1.x86_64  
localedb-src-2.16.0-4.x86_64  util-linux-2.22.1-1.x86_64
R SysVinit-2.88-7.x86_64  SysVinit-tools-2.88-7.x86_64  
coreutils-8.16-1.x86_64  glibc-2.16.0-1.x86_64
R glibc-devel-2.16.0-1.x86_64  glibc-devel-utils-2.16.0-1.x86_64  
glibc-headers-2.16.0-1.x86_64
R glibc-libcrypt-2.16.0-1.x86_64  glibc-misc-2.16.0-1.x86_64  
iconv-2.16.0-1.x86_64  ldconfig-2.16.0-1.x86_64
R libblkid-2.21.2-3.x86_64  libuuid-2.21.2-3.x86_64  
localedb-src-2.16.0-1.x86_64  util-linux-2.21.2-3.x86_64
This operation will use 2.7MB of disk space.
Need to get 13.2MB of archives (13.2MB to download).

-- 
glen


From glen at pld-linux.org  Fri Dec  7 23:48:55 2012
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Sat, 08 Dec 2012 00:48:55 +0200
Subject: license formatting
Message-ID: <50C27257.9000507@pld-linux.org>

hi

https://spdx.org/licenses/

perhaps we should use identifiers what that page uses.

if yes, then i'll do mass update of all specs master branches, update 
adapter and rpmlint with the licenses list.

ps: i have already baggin's "yes" :)

-- 
glen



From qboosh at pld-linux.org  Sat Dec  8 19:19:55 2012
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sat, 8 Dec 2012 19:19:55 +0100
Subject: [packages/libvirt] + BR:leveldb-devel, libnl1-devel,
 libatomic_ops - BR:libnl-devel  moved file cpu_map.xml to daemon
In-Reply-To: <29b6137ec4289c04d9bbf64a82aa53f3596f5ab9_refs_heads_master@pld-linux.org>
References: <b3dba96d9596cfcaf481baf0b5bc0175931dc8ec_refs_heads_master@pld-linux.org>
 <29b6137ec4289c04d9bbf64a82aa53f3596f5ab9_refs_heads_master@pld-linux.org>
Message-ID: <20121208181955.GA11973@mail>

On Sat, Dec 08, 2012 at 11:58:13AM +0100, gzohop wrote:
> commit 29b6137ec4289c04d9bbf64a82aa53f3596f5ab9
> Author: Grzegorz Pycia / PLD <gzohop at carme-pld-i686.pld-linux.org>
> Date:   Sat Dec 8 11:56:05 2012 +0100
> 
>     + BR:leveldb-devel,libnl1-devel,libatomic_ops
>     - BR:libnl-devel

leveldb and libatomic_ops are ceph (RDB) dependencies, not libvirt's.

$ rpm -qR ceph-devel | grep -E 'leveldb|libatomic_ops'
leveldb-devel
libatomic_ops

libvirt 1.0.0 builds with libnl 3.2+ just fine, doesn't need libnl 1.1
fallback.


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


From gzohop at gmail.com  Sat Dec  8 20:20:10 2012
From: gzohop at gmail.com (Grzesiek)
Date: Sat, 08 Dec 2012 20:20:10 +0100
Subject: [packages/libvirt] + BR:leveldb-devel, libnl1-devel, libatomic_ops
 - BR:libnl-devel  moved file cpu_map.xml to daemon
In-Reply-To: <20121208181955.GA11973@mail>
References: <b3dba96d9596cfcaf481baf0b5bc0175931dc8ec_refs_heads_master@pld-linux.org>
 <29b6137ec4289c04d9bbf64a82aa53f3596f5ab9_refs_heads_master@pld-linux.org>
 <20121208181955.GA11973@mail>
Message-ID: <50C392EA.1090505@gmail.com>

W dniu 08.12.2012 19:19, Jakub Bogusz pisze:
> On Sat, Dec 08, 2012 at 11:58:13AM +0100, gzohop wrote:
>> commit 29b6137ec4289c04d9bbf64a82aa53f3596f5ab9
>> Author: Grzegorz Pycia / PLD <gzohop at carme-pld-i686.pld-linux.org>
>> Date:   Sat Dec 8 11:56:05 2012 +0100
>>
>>      + BR:leveldb-devel,libnl1-devel,libatomic_ops
>>      - BR:libnl-devel
> leveldb and libatomic_ops are ceph (RDB) dependencies, not libvirt's.
>
> $ rpm -qR ceph-devel | grep -E 'leveldb|libatomic_ops'
> leveldb-devel
> libatomic_ops
>
ceph-devel-0.53-2 does not require leveldb-devel or libatomic_ops, and 
this is the ceph available in th repos.
What is the proper solution?
Should libvirt require ceph-devel-0.54-1 to ensure that it can be build 
properly?

> libvirt 1.0.0 builds with libnl 3.2+ just fine, doesn't need libnl 1.1
> fallback.
>
It does not on carme:

checking for LIBNL... no
configure: error: libnl-devel >= 1.1 is required for macvtap support

On the other hand libvirt requires libpcap-devel which requires libnl1, 
should libpcap-devel rquire-libnl1-devel?


From qboosh at pld-linux.org  Sat Dec  8 22:02:00 2012
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sat, 8 Dec 2012 22:02:00 +0100
Subject: [packages/libvirt] + BR:leveldb-devel, libnl1-devel,
 libatomic_ops - BR:libnl-devel  moved file cpu_map.xml to daemon
In-Reply-To: <50C392EA.1090505@gmail.com>
References: <b3dba96d9596cfcaf481baf0b5bc0175931dc8ec_refs_heads_master@pld-linux.org>
 <29b6137ec4289c04d9bbf64a82aa53f3596f5ab9_refs_heads_master@pld-linux.org>
 <20121208181955.GA11973@mail> <50C392EA.1090505@gmail.com>
Message-ID: <20121208210200.GA13074@mail>

On Sat, Dec 08, 2012 at 08:20:10PM +0100, Grzesiek wrote:
> W dniu 08.12.2012 19:19, Jakub Bogusz pisze:
> >On Sat, Dec 08, 2012 at 11:58:13AM +0100, gzohop wrote:
> >>commit 29b6137ec4289c04d9bbf64a82aa53f3596f5ab9
> >>Author: Grzegorz Pycia / PLD <gzohop at carme-pld-i686.pld-linux.org>
> >>Date:   Sat Dec 8 11:56:05 2012 +0100
> >>
> >>     + BR:leveldb-devel,libnl1-devel,libatomic_ops
> >>     - BR:libnl-devel
> >leveldb and libatomic_ops are ceph (RDB) dependencies, not libvirt's.
> >
> >$ rpm -qR ceph-devel | grep -E 'leveldb|libatomic_ops'
> >leveldb-devel
> >libatomic_ops
> >
> ceph-devel-0.53-2 does not require leveldb-devel or libatomic_ops, and 
> this is the ceph available in th repos.
> What is the proper solution?

ceph is fixed in git after 0.53-2, before 0.54.

> Should libvirt require ceph-devel-0.54-1 to ensure that it can be build 
> properly?

Not necessary IMO, 0.53-[12] can be assumed as broken packaging.
ceph rebuild is needed.

> >libvirt 1.0.0 builds with libnl 3.2+ just fine, doesn't need libnl 1.1
> >fallback.
> >
> It does not on carme:
> 
> checking for LIBNL... no
> configure: error: libnl-devel >= 1.1 is required for macvtap support

Confirmed. It appears that libvirt uses the same libnl that netcf.
So netcf dependency needs to be bumped to 0.2.x (0.2.0?), when it
switched from libnl 1.1 to 3.x.

> On the other hand libvirt requires libpcap-devel which requires libnl1, 
> should libpcap-devel rquire-libnl1-devel?

Currently no - it's internal dependency, not exposed in headers or
pcap-config (although it should be, if static libpcap was really
supported).


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


From baggins at pld-linux.org  Wed Dec 12 08:57:56 2012
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Wed, 12 Dec 2012 08:57:56 +0100
Subject: Th: rpm5 BDB downgrade
Message-ID: <20121212075755.GA1595@home.lan>

* lang=en

Hi,
Due to incompatibilities between BDB 5.2 and 5.3 and problems they cause
for rpm5 (DB_BUFFER_SMALL errors causing sometimes partial upgrades), I
am forced to downgrade rpm's BDB to 5.2 which is well tested and
interoperating properly.

rpm, poldek and util-vserver packages that are currently in th-test use
BDB 5.2.  BDB upgrade/downgrade has been tested and is working properly.

* lang=pl

Witam,
Z powodu niekompatybilno?ci pomi?dzy BDB 5.2 a 5.3 i problem?w kt?re to
powodowa?o z rpm-em (b??dy DB_BUFFER_SMALL skutkuj?ce czasem
niekomplentymi upgradami), jestem zmuszony do cofni?cia rpm-owej bazy do
BDB 5.2, kt?re jest dobrze wytestowane i znane z poprawnego
wsp??dzia?ania z rpm-em.

Pakiety rpm, poldek i util-vserver, kt?re le?? w th-test u?ywaj? ju? BDB
5.2.  upgrade/downgrade BDB zosta? wytestowany i dzia?a poprawnie.

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


From draenog at pld-linux.org  Wed Dec 12 17:28:46 2012
From: draenog at pld-linux.org (Kacper Kornet)
Date: Wed, 12 Dec 2012 17:28:46 +0100
Subject: New version of git-core-slug (slug.py)
Message-ID: <20121212162845.GA8177@camk.edu.pl>


* lang=en

There is a new version of git-core-slug on ftp. The new feature is a new
pull subcommand:

  slug.py pull <pattern>

It is a faster equivalent of running git pull --rebase for all packages
matching pattern. It can be even more speed up by adding option --noall.
Then the rebase will be attempted only in updated repositories.

* lang=pl

Na ftp pojawi?a si? nowa wersja git-core-slug. G??wna nowo?? to komenda
pull:

  slug.py pull <wzorzec>

Jest to w za?o?eniu szybszy odpowiednik wykonania git pull --rebase dla
wszystkich pakiet?w pasuj?cych do wzorca. W celu dodatkowego
przyspieszenia mo?na u?y? opcji --noall. Wtedy git-rebase b?dzie
wykonany tylko dla pakiet?w dla kt?rych co? nowego si? ?ci?gn??o.

-- 
  Kacper


From qboosh at pld-linux.org  Sat Dec 15 14:31:10 2012
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sat, 15 Dec 2012 14:31:10 +0100
Subject: pld git -> github problems
Message-ID: <20121215133110.GA11650@mail>

When creating new repo:

$ slug.py init postgresql-module-pldebugger
Enter passphrase for key '/home/comp/.ssh/id_rsa':
Initialized empty Git repository in
/cvs/root/gitolite/repositories/packages/postgresql-module-pldebugger.git/
Traceback (most recent call last):
  File "/home/services/git/bin/pldgithub.py", line 6, in <module>
      import requests
      ImportError: No module named 'requests'
Problem with creating gihub mirror for packages/postgresql-module-pldebugger at /home/services/git/adc/bin/create line 27.
Initialized empty Git repository in /home/comp/rpm/packages/postgresql-module-pldebugger/.git/


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


From draenog at pld-linux.org  Sat Dec 15 15:15:27 2012
From: draenog at pld-linux.org (Kacper Kornet)
Date: Sat, 15 Dec 2012 15:15:27 +0100
Subject: pld git -> github problems
In-Reply-To: <20121215133110.GA11650@mail>
References: <20121215133110.GA11650@mail>
Message-ID: <20121215141527.GA27656@camk.edu.pl>

On Sat, Dec 15, 2012 at 02:31:10PM +0100, Jakub Bogusz wrote:
> When creating new repo:

> $ slug.py init postgresql-module-pldebugger
> Enter passphrase for key '/home/comp/.ssh/id_rsa':
> Initialized empty Git repository in
> /cvs/root/gitolite/repositories/packages/postgresql-module-pldebugger.git/
> Traceback (most recent call last):
>   File "/home/services/git/bin/pldgithub.py", line 6, in <module>
>       import requests
>       ImportError: No module named 'requests'
> Problem with creating gihub mirror for packages/postgresql-module-pldebugger at /home/services/git/adc/bin/create line 27.
> Initialized empty Git repository in /home/comp/rpm/packages/postgresql-module-pldebugger/.git/

Fixed. There is/was a missing Requires in pld-gitolite. Is there some way
to generate python dependencies automatically?

-- 
  Kacper


From n3npq at me.com  Sat Dec 15 21:49:54 2012
From: n3npq at me.com (Jeffrey Johnson)
Date: Sat, 15 Dec 2012 15:49:54 -0500
Subject: pld git -> github problems
In-Reply-To: <20121215141527.GA27656@camk.edu.pl>
References: <20121215133110.GA11650@mail> <20121215141527.GA27656@camk.edu.pl>
Message-ID: <8335F3D4-E920-4F3A-96CB-226815B12C77@me.com>


On Dec 15, 2012, at 9:15 AM, Kacper Kornet <draenog at pld-linux.org> wrote:

> 
> Fixed. There is/was a missing Requires in pld-gitolite. Is there some way
> to generate python dependencies automatically?
> 

Only the python version is generated automagically: all
the python dependency automatic generation is quite feeble.

73 de Jeff



From draenog at pld-linux.org  Sun Dec 16 15:00:59 2012
From: draenog at pld-linux.org (Kacper Kornet)
Date: Sun, 16 Dec 2012 15:00:59 +0100
Subject: pld git -> github problems
In-Reply-To: <20121215141527.GA27656@camk.edu.pl>
References: <20121215133110.GA11650@mail> <20121215141527.GA27656@camk.edu.pl>
Message-ID: <20121216140059.GA26933@camk.edu.pl>

On Sat, Dec 15, 2012 at 03:15:27PM +0100, Kacper Kornet wrote:
> On Sat, Dec 15, 2012 at 02:31:10PM +0100, Jakub Bogusz wrote:
> > When creating new repo:

> > $ slug.py init postgresql-module-pldebugger
> > Enter passphrase for key '/home/comp/.ssh/id_rsa':
> > Initialized empty Git repository in
> > /cvs/root/gitolite/repositories/packages/postgresql-module-pldebugger.git/
> > Traceback (most recent call last):
> >   File "/home/services/git/bin/pldgithub.py", line 6, in <module>
> >       import requests
> >       ImportError: No module named 'requests'
> > Problem with creating gihub mirror for packages/postgresql-module-pldebugger at /home/services/git/adc/bin/create line 27.
> > Initialized empty Git repository in /home/comp/rpm/packages/postgresql-module-pldebugger/.git/

> Fixed. There is/was a missing Requires in pld-gitolite. 

Small correction. The necessary Requires was present. The problem has
been caused by the lack of generated Requires for python(abi) for
python3 packages generated by rpm-4.5. 

So if someone upgrades from python3-3.2 to python3-3.3 the dependant
python packages has to be upgraded by hand.

-- 
 Kacper


From lordblick at gmail.com  Fri Dec 21 02:35:09 2012
From: lordblick at gmail.com (Daniel Dawid Majewski al. LordBlick)
Date: Fri, 21 Dec 2012 02:35:09 +0100
Subject: mixxx.spec buildfix
Message-ID: <50D3BCCD.9030609@gmail.com>

Please commit.
Any tests and comments appreciated...
-- 
Best Regards,
Daniel Dawid Majewski
Specialist of electronic and digital circuits
LordBlick at gmail.com
jabber:light-i/pld-users.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-add-lost-BRs-and-skin-files-cleanup.patch
Type: text/x-patch
Size: 1177 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20121221/df85b914/attachment.bin>

From draenog at pld-linux.org  Fri Dec 21 03:27:34 2012
From: draenog at pld-linux.org (Kacper Kornet)
Date: Fri, 21 Dec 2012 03:27:34 +0100
Subject: mixxx.spec buildfix
In-Reply-To: <50D3BCCD.9030609@gmail.com>
References: <50D3BCCD.9030609@gmail.com>
Message-ID: <20121221022733.GO8628@camk.edu.pl>

On Fri, Dec 21, 2012 at 02:35:09AM +0100, Daniel Dawid Majewski al. LordBlick wrote:
> @@ -105,9 +107,6 @@ rm -rf $RPM_BUILD_ROOT
>  %dir %{_datadir}/mixxx/translations
>  %{_datadir}/mixxx/skins/cross.*
>  %doc %{_datadir}/mixxx/skins/*.xsl
> -# This is the default skin
> -%{_datadir}/mixxx/skins/Outline1024x600-Netbook
> -# %{_datadir}/mixxx/skins/outlineNetbook
>  %{_datadir}/mixxx/schema.xml
>  %{_datadir}/mixxx/keyboard
>  %{_datadir}/mixxx/midi

Does it run without any skin installed?

> @@ -120,4 +119,4 @@ rm -rf $RPM_BUILD_ROOT
>  
>  %files skins-core
>  %defattr(644,root,root,755)
> -%{_datadir}/mixxx/skins/*
> +%{_datadir}/mixxx/skins/*/*

That I think is wrong as %{_datadir}/mixxx/skins/* would have no owner.

-- 
  Kacper


From glen at pld-linux.org  Fri Dec 28 17:04:09 2012
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Fri, 28 Dec 2012 18:04:09 +0200
Subject: BR: pkgconfig(foo)
Message-ID: <50DDC2F9.4000802@pld-linux.org>

hi

what's the opinion of using (for example) "BR: 
pkgconfig(gsettings-desktop-schemas)" instead of
"BR gsettings-desktop-schemas-devel"

i find it pretty convinient to fill deps this way, as mostly 
configure.ac requires those pkg-config names, not exact (rpm)packages

as for example, a build requires -only- *icon-theme.pc, but the .pc 
could be in main package (gnome-icon-theme) or -devel package 
(mate-icon-theme-devel), filling pkgconfig dep gets exactly there what 
is wanted, not as filling package name into dep

the pkgconfig deps are even versioned properly (code versions, not rpm 
versions), so can fill versioned dependencies without thinking which 
epoch is accurate.

-- 
glen



From qboosh at pld-linux.org  Fri Dec 28 17:54:30 2012
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Fri, 28 Dec 2012 17:54:30 +0100
Subject: BR: pkgconfig(foo)
In-Reply-To: <50DDC2F9.4000802@pld-linux.org>
References: <50DDC2F9.4000802@pld-linux.org>
Message-ID: <20121228165430.GA15628@mail>

On Fri, Dec 28, 2012 at 06:04:09PM +0200, Elan Ruusam?e wrote:
> hi
> 
> what's the opinion of using (for example) "BR: 
> pkgconfig(gsettings-desktop-schemas)" instead of
> "BR gsettings-desktop-schemas-devel"
> 
> i find it pretty convinient to fill deps this way, as mostly 
> configure.ac requires those pkg-config names, not exact (rpm)packages
> 
> as for example, a build requires -only- *icon-theme.pc, but the .pc 
> could be in main package (gnome-icon-theme) or -devel package 
> (mate-icon-theme-devel), filling pkgconfig dep gets exactly there what 
> is wanted, not as filling package name into dep
> 
> the pkgconfig deps are even versioned properly (code versions, not rpm 
> versions), so can fill versioned dependencies without thinking which 
> epoch is accurate.

But it's less convenient for developers, to map individual BRs to
"human"/RPM package names.
I'd use pkgconfig() BRs only in uncertain cases (when .pc file was moved
between packages, when .pc file was added to package at some unknown
moment, when .pc version doesn't match rpm version), beside package
name.


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


From glen at pld-linux.org  Fri Dec 28 18:05:51 2012
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Fri, 28 Dec 2012 19:05:51 +0200
Subject: BR: pkgconfig(foo)
In-Reply-To: <20121228165430.GA15628@mail>
References: <50DDC2F9.4000802@pld-linux.org> <20121228165430.GA15628@mail>
Message-ID: <50DDD16F.8030404@pld-linux.org>

On 28.12.2012 18:54, Jakub Bogusz wrote:
> But it's less convenient for developers, to map individual BRs to
> "human"/RPM package names.
is there good way to map pkgconfig name to rpm name?
good start would be if .pc file path would be printed then could rpm -qf it

from manual doesn't seem there's command available, so it's just walk 
trough /usr/lib/pkgconfig, /usr/share/pkgconfig, 
/usr/local/lib/pkgconfig and /usr/local/share/pkgconfig $PKG_CONFIG_PATH 
and rpm -qf on first match? (last match?)

my idea was to add to adapter rule to convert pkgconfig BR to package names.

-- 
glen



From n3npq at me.com  Fri Dec 28 18:15:51 2012
From: n3npq at me.com (Jeffrey Johnson)
Date: Fri, 28 Dec 2012 12:15:51 -0500
Subject: BR: pkgconfig(foo)
In-Reply-To: <50DDC2F9.4000802@pld-linux.org>
References: <50DDC2F9.4000802@pld-linux.org>
Message-ID: <A6BFADF2-1394-4E79-9AA7-882E4DB809F5@me.com>


On Dec 28, 2012, at 11:04 AM, Elan Ruusam?e wrote:

> hi
> 
> what's the opinion of using (for example) "BR: pkgconfig(gsettings-desktop-schemas)" instead of
> "BR gsettings-desktop-schemas-devel"
> 
> i find it pretty convinient to fill deps this way, as mostly configure.ac requires those pkg-config names, not exact (rpm)packages
> 
> as for example, a build requires -only- *icon-theme.pc, but the .pc could be in main package (gnome-icon-theme) or -devel package (mate-icon-theme-devel), filling pkgconfig dep gets exactly there what is wanted, not as filling package name into dep
> 
> the pkgconfig deps are even versioned properly (code versions, not rpm versions), so can fill versioned dependencies without thinking which epoch is accurate.
> 

If you want a reliable mapping, then there needs to be
a well-defined semantic based on some reliable mechanism defined
for the pkgconfig(?) dependency name space.

You have already mentioned 2 mappings, one based on RPMTAG_PROVIDENAME,
the other based on RPMTAG_FILEPATHS (there are several tags here).

There are additional issues with multiple mappings: the mapping is not 1-to-1.

A mapping is quite doable if the semantic is well-defined.

73 de Jeff



From qboosh at pld-linux.org  Fri Dec 28 20:58:20 2012
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Fri, 28 Dec 2012 20:58:20 +0100
Subject: license formatting
In-Reply-To: <50C27257.9000507@pld-linux.org>
References: <50C27257.9000507@pld-linux.org>
Message-ID: <20121228195820.GC11851@stranger.qboosh.pl>

On Sat, Dec 08, 2012 at 12:48:55AM +0200, Elan Ruusam?e wrote:
> hi
> 
> https://spdx.org/licenses/
> 
> perhaps we should use identifiers what that page uses.
> 
> if yes, then i'll do mass update of all specs master branches, update 
> adapter and rpmlint with the licenses list.

"License" is meant to be rather human-readable.
We could adapt some abbreviations from this list, but I'd stick to " v"
version separator instead of dash.


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


From n3npq at me.com  Fri Dec 28 22:29:06 2012
From: n3npq at me.com (Jeffrey Johnson)
Date: Fri, 28 Dec 2012 16:29:06 -0500
Subject: license formatting
In-Reply-To: <20121228195820.GC11851@stranger.qboosh.pl>
References: <50C27257.9000507@pld-linux.org>
 <20121228195820.GC11851@stranger.qboosh.pl>
Message-ID: <6056D2C7-0D13-4F3B-B497-351217845E7C@me.com>


On Dec 28, 2012, at 2:58 PM, Jakub Bogusz wrote:

> On Sat, Dec 08, 2012 at 12:48:55AM +0200, Elan Ruusam?e wrote:
>> hi
>> 
>> https://spdx.org/licenses/
>> 
>> perhaps we should use identifiers what that page uses.
>> 
>> if yes, then i'll do mass update of all specs master branches, update 
>> adapter and rpmlint with the licenses list.
> 
> "License" is meant to be rather human-readable.

Yes. But the humans who are most interested in License: tags
are auditors and lawyers with a strict interpretation of what words
are used because of the underlying semantic intent represented
by acronyms used as tokens (i.e. theses aren't words that humans
communicate with).

> We could adapt some abbreviations from this list, but I'd stick to " v"
> version separator instead of dash.
> 

If PLD undertakes identifying a precise mapping from a set of tokens
like { "GPL", "BSD", "MIT", ?} to URI's where the full human readable
text of the license is to be found, then I will add a patch to rpmbuild to
force license tokens to conform (with AND"/"&&" and "OR"/"||" and parenthetical
nesting etc) to automate the entire license compatibility matrix.

Fedora has already undertaken limiting what tokens go into License: data,
and is a reasonably complete implementation available for use.

I'm quite sure there is no linux distro on the planet that is strictly conformant
with License: obligations.

JMHO: any wagers? ;-)

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