From glen at delfi.ee  Tue Jun  1 12:34:23 2010
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Tue, 1 Jun 2010 13:34:23 +0300
Subject: packages: varkon/varkon.spec - back to r. 1.18
In-Reply-To: <packages_varkon_varkon.spec.1.20@pld-linux.org>
References: <packages_varkon_varkon.spec.1.19@pld-linux.org>
	<packages_varkon_varkon.spec.1.20@pld-linux.org>
Message-ID: <201006011334.24027.glen@delfi.ee>

On Saturday 29 May 2010 22:59:58 chomar wrote:
> Author: chomar                       Date: Sat May 29 19:59:58 2010 GMT
> Module: packages                      Tag: HEAD
> ---- Log message:
> - back to r. 1.18
>
> ---- Files affected:
> packages/varkon:
>    varkon.spec (1.19 -> 1.20)
>
> ---- Diffs:
>
> ================================================================
> Index: packages/varkon/varkon.spec
> diff -u packages/varkon/varkon.spec:1.19 packages/varkon/varkon.spec:1.20
> --- packages/varkon/varkon.spec:1.19	Sat May 29 21:52:35 2010
> +++ packages/varkon/varkon.spec	Sat May 29 21:59:53 2010
> @@ -10,8 +10,8 @@
> 
> Source0:	http://dl.sourceforge.net/varkon/%{srcname}_sources_%{version}.tar
>.gz # Source0-md5:	1bbdf0c1b29393aa3bbaaccda43b21bc
>  Source1:	%{name}-run
> -Patch0:		%{name}-make-bin.patch
> -Patch1:		%{name}-h_addr-bin.patch
> +Patch0:		%{name}-make.patch
> +Patch1:		%{name}-h_addr.patch
>  URL:		http://www.tech.oru.se/cad/varkon/
>  BuildRequires:	OpenGL-GLU-devel
>  BuildRequires:	OpenGL-devel
> @@ -103,6 +103,9 @@
>  All persons listed below can be reached at <cvs_login>@pld-linux.org
>
>  $Log$
> +Revision 1.20  2010/05/29 19:59:53  chomar
> +- back to r. 1.18
> +
>  Revision 1.19  2010/05/29 19:52:35  chomar
>  - commit patch as binary file

do not commit as binary file, undos the sources before patching

diffs between binary files do not work in cvsweb.

-- 
glen


From glen at delfi.ee  Wed Jun  2 16:37:02 2010
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Wed, 2 Jun 2010 17:37:02 +0300
Subject: devel-hints-pl.txt thread
Message-ID: <201006021737.03050.glen@delfi.ee>

as seen by google translate:
http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2010-June/thread.html#start

it's not 1st of april to do those jokes, is it?
hint: the source:
http://translate.google.com/#pl|et|Pawel%20Golaszewski

-- 
glen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w631.png
Type: image/png
Size: 99939 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20100602/664da925/attachment.png>

From caleb at pld-linux.org  Wed Jun  2 16:54:03 2010
From: caleb at pld-linux.org (Caleb Maclennan)
Date: Wed, 2 Jun 2010 17:54:03 +0300
Subject: devel-hints-pl.txt thread
In-Reply-To: <201006021737.03050.glen@delfi.ee>
References: <201006021737.03050.glen@delfi.ee>
Message-ID: <AANLkTimwfEUcXRIaQnkVjYqnimWHd9WhOB8rm4_Md1b8@mail.gmail.com>

2010/6/2 Elan Ruusam?e <glen at delfi.ee>:
> it's not 1st of april to do those jokes, is it?
> hint: the source:
> http://translate.google.com/#pl|et|Pawel%20Golaszewski

Epic fail.

For icing on the cake note that this translation is used in ANY target
language. Apparently Elan Ruusam?e is the new Pawel Golaszewski
world-wide?


From blues at pld-linux.org  Fri Jun  4 09:43:49 2010
From: blues at pld-linux.org (Pawel Golaszewski)
Date: Fri, 4 Jun 2010 09:43:49 +0200 (CEST)
Subject: devel-hints-pl.txt thread
In-Reply-To: <201006021737.03050.glen@delfi.ee>
References: <201006021737.03050.glen@delfi.ee>
Message-ID: <alpine.LNX.2.00.1006040943350.7221@fgnss.gnfx.tqn.cy>

On Wed, 2 Jun 2010, Elan Ruusam?e wrote:
> as seen by google translate:
> http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2010-June/thread.html#start
> 
> it's not 1st of april to do those jokes, is it?
> hint: the source:
> http://translate.google.com/#pl|et|Pawel%20Golaszewski

ROTFL! :D

-- 
pozdr.  Pawe? Go?aszewski          jid:blues<at>jabber<dot>gda<dot>pl
--------------------------------------------------------------------------
If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby
Pro-Logic Surround Sound with Bass Boost and all the music is free.

From blues at pld-linux.org  Fri Jun  4 09:44:48 2010
From: blues at pld-linux.org (Pawel Golaszewski)
Date: Fri, 4 Jun 2010 09:44:48 +0200 (CEST)
Subject: devel-hints-pl.txt thread
In-Reply-To: <AANLkTimwfEUcXRIaQnkVjYqnimWHd9WhOB8rm4_Md1b8@mail.gmail.com>
References: <201006021737.03050.glen@delfi.ee>
	<AANLkTimwfEUcXRIaQnkVjYqnimWHd9WhOB8rm4_Md1b8@mail.gmail.com>
Message-ID: <alpine.LNX.2.00.1006040944290.7221@fgnss.gnfx.tqn.cy>

On Wed, 2 Jun 2010, Caleb Maclennan wrote:
> > it's not 1st of april to do those jokes, is it?
> > hint: the source:
> > http://translate.google.com/#pl|et|Pawel%20Golaszewski
> Epic fail.
> 
> For icing on the cake note that this translation is used in ANY target
> language. Apparently Elan Ruusam?e is the new Pawel Golaszewski
> world-wide?

My second identity. :D

-- 
pozdr.  Pawe? Go?aszewski          jid:blues<at>jabber<dot>gda<dot>pl
--------------------------------------------------------------------------
If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby
Pro-Logic Surround Sound with Bass Boost and all the music is free.

From glen at delfi.ee  Fri Jun  4 10:23:00 2010
From: glen at delfi.ee (Elan =?iso-8859-15?q?Ruusam=E4e?=)
Date: Fri, 4 Jun 2010 11:23:00 +0300
Subject: devel-hints-pl.txt thread
In-Reply-To: <alpine.LNX.2.00.1006040944290.7221@fgnss.gnfx.tqn.cy>
References: <201006021737.03050.glen@delfi.ee>
	<AANLkTimwfEUcXRIaQnkVjYqnimWHd9WhOB8rm4_Md1b8@mail.gmail.com>
	<alpine.LNX.2.00.1006040944290.7221@fgnss.gnfx.tqn.cy>
Message-ID: <201006041123.01029.glen@delfi.ee>

On Friday 04 June 2010 10:44:48 Pawel Golaszewski wrote:
> On Wed, 2 Jun 2010, Caleb Maclennan wrote:
> > > it's not 1st of april to do those jokes, is it?
> > > hint: the source:
> > > http://translate.google.com/#pl|et|Pawel%20Golaszewski
> >
> > Epic fail.
> >
> > For icing on the cake note that this translation is used in ANY target
> > language. Apparently Elan Ruusam?e is the new Pawel Golaszewski
> > world-wide?
>
> My second identity. :D

then it's time for me to reveal also my second identity!

http://translate.google.com/#et|pl|Elan%20Ruusam?e

-- 
glen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w632.png
Type: image/png
Size: 70314 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20100604/462ea513/attachment.png>

From qwiat at o2.pl  Fri Jun  4 18:16:00 2010
From: qwiat at o2.pl (Pawel Kwiatkowski)
Date: Fri, 04 Jun 2010 18:16:00 +0200
Subject: devel-hints-pl.txt thread
In-Reply-To: <201006021737.03050.glen@delfi.ee>
References: <201006021737.03050.glen@delfi.ee>
Message-ID: <1275668160.4107.3.camel@zetor>

Dnia 2010-06-02, ?ro o godzinie 17:37 +0300, Elan Ruusam?e pisze:
> as seen by google translate:
> http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2010-June/thread.html#start
> 
> it's not 1st of april to do those jokes, is it?
> hint: the source:
> http://translate.google.com/#pl|et|Pawel%20Golaszewski


Do You translate all pld-devel-pl threads pl->es?
BTW ROTFL!


-- 
Pawe? Kwiatkowski
e-mail/jid: qwiat(at)pld-linux(dot)org



From arekm at maven.pl  Sat Jun  5 19:15:12 2010
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Sat, 5 Jun 2010 19:15:12 +0200
Subject: HELP: New PLD Rescue CD
Message-ID: <201006051915.12684.arekm@maven.pl>


New PLD RescueCD is hopefuly to be produced at the end of this month but areq 
needs help with fixing packages. 

Current set of problems is at:

http://pld.areq.eu.org/th-i486h/problems/

Please help and commit fixes or email patches here.
-- 
Arkadiusz Mi?kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/


From caleb at pld-linux.org  Sat Jun  5 19:44:28 2010
From: caleb at pld-linux.org (Caleb Maclennan)
Date: Sat, 5 Jun 2010 20:44:28 +0300
Subject: HELP: New PLD Rescue CD
In-Reply-To: <201006051915.12684.arekm@maven.pl>
References: <201006051915.12684.arekm@maven.pl>
Message-ID: <AANLkTilG27nzYOc8UMTgejBRDP5bi1f0Bx7TThm-ptyY@mail.gmail.com>

2010/6/5 Arkadiusz Miskiewicz <arekm at maven.pl>:
> New PLD RescueCD is hopefuly to be produced at the end of this month but areq
> needs help with fixing packages.

Great timing. I was just now beating my head against a problem using
the old rescue cd wondering if it would ever be updated.

I would be happy to help iron out some of the issues, but it looks
like many of the issues are specific to the build environment for the
rescue cd and are not manifest building against TH. Can somebody point
me toward docs on how to setup a build env that matches so I can test?

Caleb


From arekm at maven.pl  Sat Jun  5 20:29:10 2010
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Sat, 5 Jun 2010 20:29:10 +0200
Subject: HELP: New PLD Rescue CD
In-Reply-To: <AANLkTilG27nzYOc8UMTgejBRDP5bi1f0Bx7TThm-ptyY@mail.gmail.com>
References: <201006051915.12684.arekm@maven.pl>
	<AANLkTilG27nzYOc8UMTgejBRDP5bi1f0Bx7TThm-ptyY@mail.gmail.com>
Message-ID: <201006052029.10434.arekm@maven.pl>

On Saturday 05 of June 2010, Caleb Maclennan wrote:

> I would be happy to help iron out some of the issues, but it looks
> like many of the issues are specific to the build environment for the
> rescue cd and are not manifest building against TH. Can somebody point
> me toward docs on how to setup a build env that matches so I can test?

You can get access to such environments on carme
(see http://www.pld-linux.org/Machines/carme)

Just put your ssh key into SSH-keys cvs module and mail me.

> Caleb


-- 
Arkadiusz Mi?kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/


From z at xatka.net  Sat Jun  5 21:18:56 2010
From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski)
Date: Sat, 5 Jun 2010 21:18:56 +0200
Subject: HELP: New PLD Rescue CD
In-Reply-To: <201006052029.10434.arekm@maven.pl>
References: <201006051915.12684.arekm@maven.pl>
	<AANLkTilG27nzYOc8UMTgejBRDP5bi1f0Bx7TThm-ptyY@mail.gmail.com>
	<201006052029.10434.arekm@maven.pl>
Message-ID: <20100605191856.GA10932@davabel.touk.pl>

On Sat, 05 Jun 2010, Arkadiusz Miskiewicz wrote:

> On Saturday 05 of June 2010, Caleb Maclennan wrote:
> 
> > I would be happy to help iron out some of the issues, but it looks
> > like many of the issues are specific to the build environment for the
> > rescue cd and are not manifest building against TH. Can somebody point
> > me toward docs on how to setup a build env that matches so I can test?
> 
> You can get access to such environments on carme
> (see http://www.pld-linux.org/Machines/carme)

Is it realy the same build environment? I can't reproduce htop build
problem there (missing /proc/stat).

-- 
Pawe?


From arekm at maven.pl  Sat Jun  5 21:26:54 2010
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Sat, 5 Jun 2010 21:26:54 +0200
Subject: HELP: New PLD Rescue CD
In-Reply-To: <20100605191856.GA10932@davabel.touk.pl>
References: <201006051915.12684.arekm@maven.pl>
	<201006052029.10434.arekm@maven.pl>
	<20100605191856.GA10932@davabel.touk.pl>
Message-ID: <201006052126.55324.arekm@maven.pl>

On Saturday 05 of June 2010, Pawe? Zuzelski wrote:
> On Sat, 05 Jun 2010, Arkadiusz Miskiewicz wrote:
> > On Saturday 05 of June 2010, Caleb Maclennan wrote:
> > > I would be happy to help iron out some of the issues, but it looks
> > > like many of the issues are specific to the build environment for the
> > > rescue cd and are not manifest building against TH. Can somebody point
> > > me toward docs on how to setup a build env that matches so I can test?
> > 
> > You can get access to such environments on carme
> > (see http://www.pld-linux.org/Machines/carme)
> 
> Is it realy the same build environment? I can't reproduce htop build
> problem there (missing /proc/stat).

No, it's only similar. rescuecd is build on some custom (close to th) env and 
no one (beside areq) has access to it.

Maybe simply that env doesn't have /proc mounted.

-- 
Arkadiusz Mi?kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/


From z at xatka.net  Sat Jun  5 21:34:42 2010
From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski)
Date: Sat, 5 Jun 2010 21:34:42 +0200
Subject: HELP: New PLD Rescue CD
In-Reply-To: <201006051915.12684.arekm@maven.pl>
References: <201006051915.12684.arekm@maven.pl>
Message-ID: <20100605193442.GB10932@davabel.touk.pl>

c-ares fixed

-- 
Pawe?


From glen at delfi.ee  Sun Jun  6 12:00:08 2010
From: glen at delfi.ee (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Sun, 6 Jun 2010 13:00:08 +0300
Subject: devel-hints-pl.txt thread
In-Reply-To: <1275668160.4107.3.camel@zetor>
References: <201006021737.03050.glen@delfi.ee> <1275668160.4107.3.camel@zetor>
Message-ID: <201006061300.10137.glen@pld-linux.org>

On Friday 04 June 2010 19:16:00 Pawel Kwiatkowski wrote:
> Dnia 2010-06-02, ?ro o godzinie 17:37 +0300, Elan Ruusam?e pisze:
> > as seen by google translate:
> > http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2010-June/threa
> >d.html#start
> >
> > it's not 1st of april to do those jokes, is it?
> > hint: the source:
> > http://translate.google.com/#pl|et|Pawel%20Golaszewski
>
> Do You translate all pld-devel-pl threads pl->es?
> BTW ROTFL!

es != et

-- 
glen


From wiget at pld-linux.org  Sun Jun  6 12:26:55 2010
From: wiget at pld-linux.org (Artur Frysiak)
Date: Sun, 6 Jun 2010 12:26:55 +0200
Subject: HELP: New PLD Rescue CD
In-Reply-To: <201006051915.12684.arekm@maven.pl>
References: <201006051915.12684.arekm@maven.pl>
Message-ID: <AANLkTilIJEky7e9g-BgQJmMaJvHCQmOMj_frCjGtvGJZ@mail.gmail.com>

On Sat, Jun 5, 2010 at 19:15, Arkadiusz Miskiewicz <arekm at maven.pl> wrote:
>
> New PLD RescueCD is hopefuly to be produced at the end of this month but areq
> needs help with fixing packages.
>
> Current set of problems is at:
>
> http://pld.areq.eu.org/th-i486h/problems/
>
> Please help and commit fixes or email patches here.

setserial fixed.
-- 
Artur Frysiak


From jan.palus at gmail.com  Sun Jun  6 16:20:00 2010
From: jan.palus at gmail.com (Jan Palus)
Date: Sun, 6 Jun 2010 16:20:00 +0200
Subject: HELP: New PLD Rescue CD
In-Reply-To: <201006051915.12684.arekm@maven.pl>
References: <201006051915.12684.arekm@maven.pl>
Message-ID: <20100606142000.GA5709@pomidor.echostar.pl>

On 05.06.2010 19:15, Arkadiusz Miskiewicz wrote:
> New PLD RescueCD is hopefuly to be produced at the end of this month but areq 
> needs help with fixing packages. 
> 
> Current set of problems is at:
> 
> http://pld.areq.eu.org/th-i486h/problems/
> 
> Please help and commit fixes or email patches here.

cdrdao - fixed, should probably be built --without gnome also


From z at xatka.net  Sun Jun  6 23:44:22 2010
From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski)
Date: Sun, 6 Jun 2010 23:44:22 +0200
Subject: Need help with zlib (Re: packages: ekg2/ekg2.spec - up to 20100606)
In-Reply-To: <packages_ekg2_ekg2.spec.1.113@pld-linux.org>
References: <packages_ekg2_ekg2.spec.1.112@pld-linux.org>
	<packages_ekg2_ekg2.spec.1.113@pld-linux.org>
Message-ID: <20100606214422.GB4429@davabel.touk.pl>

Hello,

after update to the newest SVN snapshot, ekg2 does not build on
32-bit Titanium. It builds on ti-x86_64 and on all th archs.

In file included from misc.c:10:
/usr/include/zlib.h:1583: error: conflicting types for 'gzseek64'
/usr/include/zlib.h:1567: note: previous declaration of 'gzseek64' was here
/usr/include/zlib.h:1584: error: conflicting types for 'gztell64'
/usr/include/zlib.h:1568: note: previous declaration of 'gztell64' was here
/usr/include/zlib.h:1585: error: conflicting types for 'gzoffset64'
/usr/include/zlib.h:1569: note: previous declaration of 'gzoffset64' was here
/usr/include/zlib.h:1586: error: conflicting types for 'adler32_combine64'
/usr/include/zlib.h:1570: note: previous declaration of 'adler32_combine64' was here
/usr/include/zlib.h:1587: error: conflicting types for 'crc32_combine64'
/usr/include/zlib.h:1571: note: previous declaration of 'crc32_combine64' was here

Full build logs are here:
i586:
http://buildlogs.pld-linux.org/index.php?dist=ti&arch=i586&ok=0&name=ekg2&id=0f211862-2f73-4922-808a-6d3f78c6748e
i686:
http://buildlogs.pld-linux.org/index.php?dist=ti&arch=i686&ok=0&name=ekg2&id=0f211862-2f73-4922-808a-6d3f78c6748e

Is it problem with ekg2 or with zlib? How to fix it? Can anyone
point me to example patch/solution in some other package?

Thanks in advance.

-- 
Pawe?


From z at xatka.net  Mon Jun  7 01:27:57 2010
From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski)
Date: Mon, 7 Jun 2010 01:27:57 +0200
Subject: rpm autodeps for python
Message-ID: <20100606232757.GC4429@davabel.touk.pl>

Hello,

I'm using such a oneliner for finding python deps.

I know that it is a bit hackish, but maybe it is possible to
use it to write autodeps script for python libs?

find -name '*.py' | grep -v ^./test | grep -v ^./example | xargs grep -E '(^import|^from .* import )' | cut -d: -f2 | sort | uniq | while read I; do strace python -c "$I" 2>&1 | grep pyc | cut -d'"' -f2 | xargs rpm -qf 2>/dev/null; done | sort | uniq

It search for all "import foo" and "from foo import bar" directives,
then it tries to execute this directive using python -c under
strace, and greps output of strace for anything that looks like
loaded python library.

-- 
Pozdrawiam,
Pawe? Zuzelski


From sparky at pld-linux.org  Mon Jun  7 01:32:54 2010
From: sparky at pld-linux.org (Przemyslaw Iskra)
Date: Mon, 7 Jun 2010 01:32:54 +0200
Subject: rpm autodeps for python
In-Reply-To: <20100606232757.GC4429@davabel.touk.pl>
References: <20100606232757.GC4429@davabel.touk.pl>
Message-ID: <20100606233254.GA23789@pld-linux.org>

On Mon, Jun 07, 2010 at 01:27:57AM +0200, Pawe? Zuzelski wrote:
> Hello,
> 
> I'm using such a oneliner for finding python deps.
> 
> I know that it is a bit hackish, but maybe it is possible to
> use it to write autodeps script for python libs?

How many false positives are reported ? If there is any, using it won't
be a good idea.

-- 
 ____  Sparky{PI] -- Przemyslaw _  ___  _  _  ........... LANG...Pl..Ca..Es..En
/____) ___  ___  _ _ || Iskra  |  | _ \| |  | : WWW........ppcrcd.pld-linux.org
\____\| -_)'___| ||^'||//\\// <   |  _/| |  | : JID......sparky<at>jabberes.org
(____/||   (_-_|_||  ||\\ ||   |_ |_|  |_| _| : Mail....sparky<at>pld-linux.org


From z at xatka.net  Mon Jun  7 01:46:39 2010
From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski)
Date: Mon, 7 Jun 2010 01:46:39 +0200
Subject: rpm autodeps for python
In-Reply-To: <20100606233254.GA23789@pld-linux.org>
References: <20100606232757.GC4429@davabel.touk.pl>
	<20100606233254.GA23789@pld-linux.org>
Message-ID: <20100606234639.GD4429@davabel.touk.pl>

On Mon, 07 Jun 2010, Przemyslaw Iskra wrote:

> On Mon, Jun 07, 2010 at 01:27:57AM +0200, Pawe? Zuzelski wrote:
> > Hello,
> > 
> > I'm using such a oneliner for finding python deps.
> > 
> > I know that it is a bit hackish, but maybe it is possible to
> > use it to write autodeps script for python libs?
> 
> How many false positives are reported ? If there is any, using it won't
> be a good idea.

Didn't observe any yet. But it needs more testing.

Also, the problem is, it is able to find only installed packages.

-- 
Pawe?


From jajcus at jajcus.net  Mon Jun  7 08:36:02 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Mon, 7 Jun 2010 08:36:02 +0200
Subject: rpm autodeps for python
In-Reply-To: <20100606232757.GC4429@davabel.touk.pl>
References: <20100606232757.GC4429@davabel.touk.pl>
Message-ID: <20100607063602.GB32171@jajo.eggsoft>

On Mon, Jun 07, 2010 at 01:27:57AM +0200, Pawe? Zuzelski wrote:
> I'm using such a oneliner for finding python deps.
> 
> I know that it is a bit hackish, but maybe it is possible to
> use it to write autodeps script for python libs?

Much better idea would be to use the dependency information already
provided by the egg-info files. 

Greets,
        Jacek


From arekm at maven.pl  Mon Jun  7 10:38:14 2010
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Mon, 7 Jun 2010 10:38:14 +0200
Subject: HELP: New PLD Rescue CD
In-Reply-To: <201006051915.12684.arekm@maven.pl>
References: <201006051915.12684.arekm@maven.pl>
Message-ID: <201006071038.14511.arekm@maven.pl>

On Saturday 05 of June 2010, Arkadiusz Miskiewicz wrote:
> New PLD RescueCD is hopefuly to be produced at the end of this month but
> areq needs help with fixing packages.
> 
> Current set of problems is at:
> 
> http://pld.areq.eu.org/th-i486h/problems/

List/logs updated.

-- 
Arkadiusz Mi?kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/


From caleb at pld-linux.org  Mon Jun  7 11:16:22 2010
From: caleb at pld-linux.org (Caleb Maclennan)
Date: Mon, 7 Jun 2010 12:16:22 +0300
Subject: packages: perl-Clutter-GStreamer/perl-Clutter-GStreamer.spec - 
	release 5
In-Reply-To: <packages_perl_Clutter_GStreamer_perl_Clutter_GStreamer.spec.1.4@pld-linux.org>
References: <packages_perl_Clutter_GStreamer_perl_Clutter_GStreamer.spec.1.3@pld-linux.org>
	<packages_perl_Clutter_GStreamer_perl_Clutter_GStreamer.spec.1.4@pld-linux.org>
Message-ID: <AANLkTilwunSDDfYwijXDiQMx9OXIbkQyRbvoJsIMKaQ_@mail.gmail.com>

2010/6/6 arekm <arekm at pld-linux.org>
>
> Author: arekm ? ? ? ? ? ? ? ? ? ? ? ?Date: Sun Jun ?6 15:36:42 2010 GMT
> Module: packages ? ? ? ? ? ? ? ? ? ? ?Tag: HEAD
> ---- Log message:
> - release 5
>
> ---- Files affected:
> packages/perl-Clutter-GStreamer:
> ? perl-Clutter-GStreamer.spec (1.3 -> 1.4)

Why did the rel get bumped on this package?

Is the %define rel that I used to indicate the upstream release number
we are downloading the wrong way to do this? Our package release is 1,
but the upstream package we need to download is release 4.

If it get's bumped this needs to be done with our release number, not
the upstream number! Should that variable be called something else? I
saw this done in other packages and so assumed it was the right
scheme.

Caleb


From arekm at maven.pl  Mon Jun  7 11:32:12 2010
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Mon, 7 Jun 2010 11:32:12 +0200
Subject: packages: perl-Clutter-GStreamer/perl-Clutter-GStreamer.spec -
	release 5
In-Reply-To: <AANLkTilwunSDDfYwijXDiQMx9OXIbkQyRbvoJsIMKaQ_@mail.gmail.com>
References: <packages_perl_Clutter_GStreamer_perl_Clutter_GStreamer.spec.1.3@pld-linux.org>
	<packages_perl_Clutter_GStreamer_perl_Clutter_GStreamer.spec.1.4@pld-linux.org>
	<AANLkTilwunSDDfYwijXDiQMx9OXIbkQyRbvoJsIMKaQ_@mail.gmail.com>
Message-ID: <201006071132.12732.arekm@maven.pl>

On Monday 07 of June 2010, Caleb Maclennan wrote:
> 2010/6/6 arekm <arekm at pld-linux.org>
> 
> > Author: arekm                        Date: Sun Jun  6 15:36:42 2010 GMT
> > Module: packages                      Tag: HEAD
> > ---- Log message:
> > - release 5
> > 
> > ---- Files affected:
> > packages/perl-Clutter-GStreamer:
> >   perl-Clutter-GStreamer.spec (1.3 -> 1.4)
> 
> Why did the rel get bumped on this package?

packages/relup.sh thinks that rel is release and bumped this one.

I've changed macro name from rel to subver to avoid this problem in future.

> I
> saw this done in other packages and so assumed it was the right
> scheme.

The %rel macro appeared only to make automatic release bump an easy thing (see 
packages/relup.sh) in case when Release: contains many macros, conditions and 
such stuff.

> Caleb

-- 
Arkadiusz Mi?kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/


From caleb at pld-linux.org  Mon Jun  7 14:50:26 2010
From: caleb at pld-linux.org (Caleb Maclennan)
Date: Mon, 7 Jun 2010 15:50:26 +0300
Subject: PLD-doc: devel-hints-en.txt - notes on Release tag and %rel macro
In-Reply-To: <PLD_doc_devel_hints_en.txt.1.51@pld-linux.org>
References: <PLD_doc_devel_hints_en.txt.1.50@pld-linux.org> 
	<PLD_doc_devel_hints_en.txt.1.51@pld-linux.org>
Message-ID: <AANLkTinAwVo0OJfiuObPrlg7A9h91GgvVGAMry5sO8h6@mail.gmail.com>

2010/6/7 pawelz <pawelz at pld-linux.org>:
> + ? Fractional release (0.1, 0.5, 3.14 etc) means package is not yet ready to
> + ? be sent to builders. If you think that package is ready to be build,
> + ? increase release to the next integer.

How does this information apply to packages such as open-iscsi which
has a release of 0.%{subver}.%{rel} where subver is from the upstream
project and rel is the pld release incrementor. The reason I ask is
this 0.x.y number looks like a fraction release to me, but it is built
and in the TH tree. How should I have incremented this to indicate
that it isn't ready to be built again yet? Should the rel also be a
fraction? Why the 0. before the subver?

Caleb


From arekm at maven.pl  Mon Jun  7 14:59:12 2010
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Mon, 7 Jun 2010 14:59:12 +0200
Subject: PLD-doc: devel-hints-en.txt - notes on Release tag and %rel macro
In-Reply-To: <AANLkTinAwVo0OJfiuObPrlg7A9h91GgvVGAMry5sO8h6@mail.gmail.com>
References: <PLD_doc_devel_hints_en.txt.1.50@pld-linux.org>
	<PLD_doc_devel_hints_en.txt.1.51@pld-linux.org>
	<AANLkTinAwVo0OJfiuObPrlg7A9h91GgvVGAMry5sO8h6@mail.gmail.com>
Message-ID: <201006071459.13226.arekm@maven.pl>

On Monday 07 of June 2010, Caleb Maclennan wrote:
> 2010/6/7 pawelz <pawelz at pld-linux.org>:
> > +   Fractional release (0.1, 0.5, 3.14 etc) means package is not yet
> > ready to +   be sent to builders. If you think that package is ready to
> > be build, +   increase release to the next integer.
> 
> How does this information apply to packages such as open-iscsi which
> has a release of 0.%{subver}.%{rel} where subver is from the upstream
> project and rel is the pld release incrementor. The reason I ask is
> this 0.x.y number looks like a fraction release to me, but it is built
> and in the TH tree. How should I have incremented this to indicate
> that it isn't ready to be built again yet? Should the rel also be a
> fraction? Why the 0. before the subver?

Usually such scheme (0.%{snap}.%{rel}) is used for snapshots. Then if final 
version of package comes you can simply do Release: 1. We avoid putting 
snapshot indicator into version because for example final 1.0 < than snapshot 
1.0.200100515.

In our versioning this is 1.0-1 final and 1.0-0.20100515.1 for snapshot.

Not sure what open-iscsi subver means in upstream package (is this snapshot 
versioning or part of real version number) but the same schema as described 
above was used for it.

> Caleb

-- 
Arkadiusz Mi?kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/


From adamg at pld-linux.org  Mon Jun  7 15:01:52 2010
From: adamg at pld-linux.org (Adam Golebiowski)
Date: Mon, 7 Jun 2010 15:01:52 +0200
Subject: Need help with zlib (Re: packages: ekg2/ekg2.spec - up to
	20100606)
In-Reply-To: <20100606214422.GB4429@davabel.touk.pl>
References: <packages_ekg2_ekg2.spec.1.112@pld-linux.org>
	<packages_ekg2_ekg2.spec.1.113@pld-linux.org>
	<20100606214422.GB4429@davabel.touk.pl>
Message-ID: <20100607130152.GA21600@agmk.net>

On Sun, Jun 06, 2010 at 11:44:22PM +0200, Pawe? Zuzelski wrote:
> Is it problem with ekg2 or with zlib? How to fix it? Can anyone
> point me to example patch/solution in some other package?

Upgrade to zlib-1.2.5-3 (with qboosh's proper fix to my 'fix'). 


-- 
adamg


From sparky at pld-linux.org  Mon Jun  7 15:09:43 2010
From: sparky at pld-linux.org (Przemyslaw Iskra)
Date: Mon, 7 Jun 2010 15:09:43 +0200
Subject: PLD-doc: devel-hints-en.txt - notes on Release tag and %rel macro
In-Reply-To: <201006071459.13226.arekm@maven.pl>
References: <PLD_doc_devel_hints_en.txt.1.50@pld-linux.org>
	<PLD_doc_devel_hints_en.txt.1.51@pld-linux.org>
	<AANLkTinAwVo0OJfiuObPrlg7A9h91GgvVGAMry5sO8h6@mail.gmail.com>
	<201006071459.13226.arekm@maven.pl>
Message-ID: <20100607130943.GA25187@pld-linux.org>

On Mon, Jun 07, 2010 at 02:59:12PM +0200, Arkadiusz Miskiewicz wrote:
> On Monday 07 of June 2010, Caleb Maclennan wrote:
> > 2010/6/7 pawelz <pawelz at pld-linux.org>:

> > How does this information apply to packages such as open-iscsi which
> > has a release of 0.%{subver}.%{rel} where subver is from the upstream
> > project and rel is the pld release incrementor. The reason I ask is
> > this 0.x.y number looks like a fraction release to me, but it is built
> > and in the TH tree. How should I have incremented this to indicate
> > that it isn't ready to be built again yet? Should the rel also be a
> > fraction? Why the 0. before the subver?
> 
> Usually such scheme (0.%{snap}.%{rel}) is used for snapshots. Then if final 
> version of package comes you can simply do Release: 1. We avoid putting 
> snapshot indicator into version because for example final 1.0 < than snapshot 
> 1.0.200100515.
> 
> In our versioning this is 1.0-1 final and 1.0-0.20100515.1 for snapshot.

If you want to use fractional release in package with subver just define
rel to that release, it would look like: 1.0-0.20100515.0.1

Another use for the first number in "snapshot release" it to serve as
auxilary epoch. E.g. if some project uses alpha, beta, gamma, delta as
their subver names you will have to increase it for "delta" release to
maintain proper seniority.

[sparky at quad ~]$ rpmvercmp 1.0-0.gamma.1 1.0-0.delta.1
1.0-0.gamma.1 > 1.0-0.delta.1
[sparky at quad ~]$ rpmvercmp 1.0-0.gamma.1 1.0-1.delta.1
1.0-0.gamma.1 < 1.0-1.delta.1
 

-- 
 ____  Sparky{PI] -- Przemyslaw _  ___  _  _  ........... LANG...Pl..Ca..Es..En
/____) ___  ___  _ _ || Iskra  |  | _ \| |  | : WWW........ppcrcd.pld-linux.org
\____\| -_)'___| ||^'||//\\// <   |  _/| |  | : JID......sparky<at>jabberes.org
(____/||   (_-_|_||  ||\\ ||   |_ |_|  |_| _| : Mail....sparky<at>pld-linux.org


From glen at pld-linux.org  Mon Jun  7 15:51:15 2010
From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Mon, 7 Jun 2010 16:51:15 +0300
Subject: PLD-doc: devel-hints-en.txt - notes on Release tag and %rel macro
In-Reply-To: <AANLkTinAwVo0OJfiuObPrlg7A9h91GgvVGAMry5sO8h6@mail.gmail.com>
References: <PLD_doc_devel_hints_en.txt.1.50@pld-linux.org>
	<PLD_doc_devel_hints_en.txt.1.51@pld-linux.org>
	<AANLkTinAwVo0OJfiuObPrlg7A9h91GgvVGAMry5sO8h6@mail.gmail.com>
Message-ID: <201006071651.15732.glen@pld-linux.org>

On Monday 07 June 2010 15:50:26 Caleb Maclennan wrote:
> How does this information apply to packages such as open-iscsi which
> has a release of 0.%{subver}.%{rel}

in such packages the fractional vs non-fractional is accounted from %{rel} 
macro, not the real Release tag. (also older %{_rel} is supported))

-- 
glen


From jajcus at jajcus.net  Tue Jun  8 08:14:54 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Tue, 8 Jun 2010 08:14:54 +0200
Subject: 'Couldn't read /proc/self/stat' strikes back
	[builder-th-i486@pld-linux.org: ERRORS: icedtea6.spec]
Message-ID: <20100608061454.GA7687@jajo.eggsoft>

Hi,

Icedtea6 build failed again on the i486 builder?

Any idea why it fails? How did we manage to do previous builds?

Greets,
        Jacek

> icedtea6.spec (HEAD): FAILED
> 
> --- icedtea6.spec:HEAD:
> Build-Time: user:1139.25s sys:71.92s real:1616.11s (faults io:6699 non-io:13223771)

[...]
>   inflated: sun/rmi/rmic/iiop/ContextElement.class
> Importing classes from component JAXP_DIST
> ( cd  /home/users/builder/rpm/BUILD/icedtea6-1.8/openjdk-ecj/build/linux-i586/classes && /home/users/builder/rpm/BUILD/icedtea6-1.8/bootstrap/jdk1.6.0/bin/jar xfv /home/users/builder/rpm/BUILD/icedtea6-1.8/openjdk-ecj/build/linux-i586/jaxp/dist/lib/classes.jar  )
> Couldn't read /proc/self/stat
> Abort 
> make[4]: *** [/home/users/builder/rpm/BUILD/icedtea6-1.8/openjdk-ecj/build/linux-i586/tmp/java/components_imported] Error 134
> make[4]: Leaving directory `/home/users/builder/rpm/BUILD/icedtea6-1.8/openjdk-ecj/jdk/make/java/redist'
> make[3]: *** [all] Error 1
> make[3]: Leaving directory `/home/users/builder/rpm/BUILD/icedtea6-1.8/openjdk-ecj/jdk/make/java'
> make[2]: *** [all] Error 1
> make[2]: Leaving directory `/home/users/builder/rpm/BUILD/icedtea6-1.8/openjdk-ecj/jdk/make'
> make[1]: *** [jdk-build] Error 2
> make[1]: Leaving directory `/home/users/builder/rpm/BUILD/icedtea6-1.8/openjdk-ecj'
> make: *** [stamps/icedtea-ecj.stamp] Error 2
> error: Bad exit status from /tmp/B.3496fe/rpm-tmp.45584 (%build)



From arekm at maven.pl  Tue Jun  8 08:19:49 2010
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Tue, 8 Jun 2010 08:19:49 +0200
Subject: 'Couldn't read /proc/self/stat' strikes back
	[builder-th-i486@pld-linux.org: ERRORS: icedtea6.spec]
In-Reply-To: <20100608061454.GA7687@jajo.eggsoft>
References: <20100608061454.GA7687@jajo.eggsoft>
Message-ID: <201006080819.50174.arekm@maven.pl>

On Tuesday 08 of June 2010, Jacek Konieczny wrote:
> Hi,
> 
> Icedtea6 build failed again on the i486 builder?
> 
> Any idea why it fails?

x86_64 kernel and 64bit values inside? No idea, just guessing.

> How did we manage to do previous builds?

--without bootstrap worked

> 
> Greets,
>         Jacek

-- 
Arkadiusz Mi?kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/


From ankry at green.mif.pg.gda.pl  Wed Jun  9 03:33:10 2010
From: ankry at green.mif.pg.gda.pl (ankry at green.mif.pg.gda.pl)
Date: Wed, 9 Jun 2010 03:33:10 +0200 (CEST)
Subject: packages: perl-Clutter-GStreamer/perl-Clutter-GStreamer.spec -
In-Reply-To: <AANLkTilwunSDDfYwijXDiQMx9OXIbkQyRbvoJsIMKaQ_@mail.gmail.com>
Message-ID: <201006090133.o591XAqA010022@green.mif.pg.gda.pl>

Caleb Maclennan wrote:
> 
> 2010/6/6 arekm <arekm at pld-linux.org>
> >
> > Author: arekm ? ? ? ? ? ? ? ? ? ? ? ?Date: Sun Jun ?6 15:36:42 2010 GMT
> > Module: packages ? ? ? ? ? ? ? ? ? ? ?Tag: HEAD
> > ---- Log message:
> > - release 5
> >
> > ---- Files affected:
> > packages/perl-Clutter-GStreamer:
> > ? perl-Clutter-GStreamer.spec (1.3 -> 1.4)
> 
> Why did the rel get bumped on this package?
> 
> Is the %define rel that I used to indicate the upstream release number
> we are downloading the wrong way to do this? Our package release is 1,
> but the upstream package we need to download is release 4.
> 
> If it get's bumped this needs to be done with our release number, not
> the upstream number! Should that variable be called something else? I
> saw this done in other packages and so assumed it was the right
> scheme.

RPM's Release is and have to be our internal number, not the upstream one.
Any "release" that is external to us have to go to the "Version" field in
some way.

-- 
=======================================================================
  Andrzej M. Krzysztofowicz                  ankry at mif.pg.gda.pl


From radek at pld-linux.org  Wed Jun  9 04:29:14 2010
From: radek at pld-linux.org (=?UTF-8?B?UmFkb3PFgmF3IFppZWxpxYRza2k=?=)
Date: Tue, 8 Jun 2010 21:29:14 -0500
Subject: packages: perl-Clutter-GStreamer/perl-Clutter-GStreamer.spec -
In-Reply-To: <201006090133.o591XAqA010022@green.mif.pg.gda.pl>
References: <AANLkTilwunSDDfYwijXDiQMx9OXIbkQyRbvoJsIMKaQ_@mail.gmail.com>
	<201006090133.o591XAqA010022@green.mif.pg.gda.pl>
Message-ID: <AANLkTikX-IdmZ62nUUrwGYjVNKtMAM7c1tgE2ed9-ONm@mail.gmail.com>

2010/6/8  <ankry at green.mif.pg.gda.pl>:
> RPM's Release is and have to be our internal number, not the upstream one.
> Any "release" that is external to us have to go to the "Version" field in
> some way.

Well, that's not how we've been doing things so far.  betaX, alphaX,
rcX, snapshots, whatever -- it all usually goes to Release.

And I don't see a way of doing this without frequent Epoch bumps.


From ankry at green.mif.pg.gda.pl  Wed Jun  9 20:38:59 2010
From: ankry at green.mif.pg.gda.pl (ankry at green.mif.pg.gda.pl)
Date: Wed, 9 Jun 2010 20:38:59 +0200 (CEST)
Subject: packages: perl-Clutter-GStreamer/perl-Clutter-GStreamer.spec -
In-Reply-To: <AANLkTikX-IdmZ62nUUrwGYjVNKtMAM7c1tgE2ed9-ONm@mail.gmail.com>
Message-ID: <201006091838.o59IcxDJ013094@green.mif.pg.gda.pl>

=?UTF-8?B?UmFkb3PFgmF3IFppZWxpxYRza2k=?= wrote:
> 
> 2010/6/8  <ankry at green.mif.pg.gda.pl>:
> > RPM's Release is and have to be our internal number, not the upstream one.
> > Any "release" that is external to us have to go to the "Version" field in
> > some way.
> 
> Well, that's not how we've been doing things so far.  betaX, alphaX,
> rcX, snapshots, whatever -- it all usually goes to Release.

Yes, but it is for 0.X.Y Release format.
And Y is the part still under our controll.
 
> And I don't see a way of doing this without frequent Epoch bumps.

What would be nice to avoid. Especially as rpm does not like multiple
packages with same Version-Release. Even if Epoch is bumped.

-- 
=======================================================================
  Andrzej M. Krzysztofowicz                  ankry at mif.pg.gda.pl


From glen at delfi.ee  Thu Jun 10 10:01:00 2010
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Thu, 10 Jun 2010 11:01:00 +0300
Subject: packages: perl-Clutter-GStreamer/perl-Clutter-GStreamer.spec -
In-Reply-To: <201006091838.o59IcxDJ013094@green.mif.pg.gda.pl>
References: <201006091838.o59IcxDJ013094@green.mif.pg.gda.pl>
Message-ID: <201006101101.00545.glen@delfi.ee>

On Wednesday 09 June 2010 21:38:59 ankry at green.mif.pg.gda.pl wrote:
> > And I don't see a way of doing this without frequent Epoch bumps.
>
> What would be nice to avoid. Especially as rpm does not like multiple
> packages with same Version-Release. Even if Epoch is bumped.

here you probably refer to pld cvs infrastructure, where packages autotag are 
composed of VERSION-RELEASE (note that epoch is not accounted)

   Existing Tags:
        auto-th-glibc-2_12-4            (revision: 1.873)
        auto-th-glibc-2_12-3            (revision: 1.872)
        auto-th-glibc-2_12-2            (revision: 1.871)
        auto-ti-glibc-2_11_1-5          (revision: 1.869)
        auto-th-glibc-2_12-1            (revision: 1.870)


-- 
glen


From glen at delfi.ee  Thu Jun 10 15:11:24 2010
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Thu, 10 Jun 2010 16:11:24 +0300
Subject: packages (rpm-4_5): rpm/rpm.spec - added arm support - TODO added
In-Reply-To: <packages_rpm_rpm.spec.1.837.2.42.2.49.2.92@pld-linux.org>
References: <packages_rpm_rpm.spec.1.837.2.42.2.49.2.91@pld-linux.org>
	<packages_rpm_rpm.spec.1.837.2.42.2.49.2.92@pld-linux.org>
Message-ID: <201006101611.24962.glen@delfi.ee>

On Thursday 10 June 2010 13:46:57 tommat wrote:
> ?%ifarch sparc64
> ?sparc64-[^-]*-[Ll]inux(-gnu)?
> -sparcv8-[^-]*-[Ll]inux(-gnu)?
> -sparcv9-[^-]*-[Ll]inux(-gnu)?
> ?%endif
> -%ifarch sparcv9
> -sparcv8-[^-]*-[Ll]inux(-gnu)?
> +%ifarch sparcv9 sparc64
> ?sparcv9-[^-]*-[Ll]inux(-gnu)?
> ?%endif
> ?%ifarch sparc sparcv9 sparc64
> ?sparc-[^-]*-[Ll]inux(-gnu)?
> ?%endif

why did you remove those sparc entries?

at least if you intended to remove them, you should say so in commit message 
too

-- 
glen


From tommat at pimpek.one.pl  Fri Jun 11 14:45:39 2010
From: tommat at pimpek.one.pl (Tomasz Mateja)
Date: Fri, 11 Jun 2010 14:45:39 +0200
Subject: packages (rpm-4_5): rpm/rpm.spec - added arm support - TODO added
In-Reply-To: <201006101611.24962.glen@delfi.ee>
References: <packages_rpm_rpm.spec.1.837.2.42.2.49.2.91@pld-linux.org>	<packages_rpm_rpm.spec.1.837.2.42.2.49.2.92@pld-linux.org>
	<201006101611.24962.glen@delfi.ee>
Message-ID: <4C122FF3.3010705@pimpek.one.pl>

On 06/10/2010 03:11 PM, Elan Ruusam?e wrote:
> On Thursday 10 June 2010 13:46:57 tommat wrote:
>>   %ifarch sparc64
>>   sparc64-[^-]*-[Ll]inux(-gnu)?
>> -sparcv8-[^-]*-[Ll]inux(-gnu)?
>> -sparcv9-[^-]*-[Ll]inux(-gnu)?
>>   %endif
>> -%ifarch sparcv9
>> -sparcv8-[^-]*-[Ll]inux(-gnu)?
>> +%ifarch sparcv9 sparc64
>>   sparcv9-[^-]*-[Ll]inux(-gnu)?
>>   %endif
>>   %ifarch sparc sparcv9 sparc64
>>   sparc-[^-]*-[Ll]inux(-gnu)?
>>   %endif
>
> why did you remove those sparc entries?
>
> at least if you intended to remove them, you should say so in commit message
> too
>
Yes, forgot mentioned about removing sparcv8 which is even nowhere 
supported as an arch, sorry.

BTW. I'm tired trying to do something on sparcs so I have Ultra60 
2x450MHz 1,7G RAM, 2x36G plus some spare parts to put in good hands.
(I can consider keyboard+mouse+21"CRT monitor also :-) )

Best Regards
-- 
T.





From jajcus at jajcus.net  Sat Jun 12 14:42:22 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Sat, 12 Jun 2010 14:42:22 +0200
Subject: packages: google-chrome/google-chrome.spec - do NOT add this
	bogs dep
In-Reply-To: <packages_google_chrome_google_chrome.spec.1.21@pld-linux.org>
References: <packages_google_chrome_google_chrome.spec.1.20@pld-linux.org>
	<packages_google_chrome_google_chrome.spec.1.21@pld-linux.org>
Message-ID: <20100612124221.GA8072@lolek.nigdzie>

On Sat, Jun 12, 2010 at 02:29:05PM +0200, glen wrote:
> Author: glen                         Date: Sat Jun 12 12:29:05 2010 GMT
> Module: packages                      Tag: HEAD
> ---- Log message:
> - do NOT add this bogs dep

>  Requires:	browser-plugins >= 2.0
> -Requires:	libjpeg6
>  Requires:	nspr

Could you both, discuss your reasons on the list first
instead of just commit-fighting, please?

If you two cannot agree on this single line let us help you decide what
is right.

Greets,
        Jacek


From patrys at pld-linux.org  Sat Jun 12 15:13:04 2010
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Sat, 12 Jun 2010 15:13:04 +0200
Subject: packages: google-chrome/google-chrome.spec - do NOT add this bogs
	dep
In-Reply-To: <AANLkTimmodd5-c7ltrauofYSvtFST8HCNUA_to5c5B1F@mail.gmail.com>
References: <packages_google_chrome_google_chrome.spec.1.20@pld-linux.org>
	<packages_google_chrome_google_chrome.spec.1.21@pld-linux.org>
	<20100612124221.GA8072@lolek.nigdzie>
	<AANLkTimmodd5-c7ltrauofYSvtFST8HCNUA_to5c5B1F@mail.gmail.com>
Message-ID: <AANLkTimrMJbewZ_T0fztUZrEfVnpYqNUIPezk6edCoin@mail.gmail.com>

2010/6/12 Bartosz ?wi?tek <shadzik at gmail.com>:
> Removing this R: breaks the readability of the error and causes
> unnecessary confusion.
>
> I'm afraid glen removes this R: only to get his own comfort using this
> browser on deprecated Ac systems - which are officially not maintained
> by the PLD team.
>
> Removing this R: is (in my eyes) breaking the package on purpose!!

What you want is BR: %{_libdir}/libjpeg.so.62 so rpm generates the
*proper* Requires.

-- 
Patryk Zawadzki


From arekm at maven.pl  Sat Jun 12 16:43:33 2010
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Sat, 12 Jun 2010 16:43:33 +0200
Subject: packages: google-chrome/google-chrome.spec - do NOT add this bogs
	dep
In-Reply-To: <AANLkTimrMJbewZ_T0fztUZrEfVnpYqNUIPezk6edCoin@mail.gmail.com>
References: <packages_google_chrome_google_chrome.spec.1.20@pld-linux.org>
	<AANLkTimmodd5-c7ltrauofYSvtFST8HCNUA_to5c5B1F@mail.gmail.com>
	<AANLkTimrMJbewZ_T0fztUZrEfVnpYqNUIPezk6edCoin@mail.gmail.com>
Message-ID: <201006121643.33556.arekm@maven.pl>

On Saturday 12 of June 2010, Patryk Zawadzki wrote:
> 2010/6/12 Bartosz ?wi?tek <shadzik at gmail.com>:
> > Removing this R: breaks the readability of the error and causes
> > unnecessary confusion.
> > 
> > I'm afraid glen removes this R: only to get his own comfort using this
> > browser on deprecated Ac systems - which are officially not maintained
> > by the PLD team.
> > 
> > Removing this R: is (in my eyes) breaking the package on purpose!!
> 
> What you want is BR: %{_libdir}/libjpeg.so.62 so rpm generates the
> *proper* Requires.

rpm generates proper requires without such BR. They are figting over package 
name requires, not a real one.


-- 
Arkadiusz Mi?kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/


From patrys at pld-linux.org  Sat Jun 12 16:56:47 2010
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Sat, 12 Jun 2010 16:56:47 +0200
Subject: packages: google-chrome/google-chrome.spec - do NOT add this bogs
	dep
In-Reply-To: <201006121643.33556.arekm@maven.pl>
References: <packages_google_chrome_google_chrome.spec.1.20@pld-linux.org>
	<AANLkTimmodd5-c7ltrauofYSvtFST8HCNUA_to5c5B1F@mail.gmail.com>
	<AANLkTimrMJbewZ_T0fztUZrEfVnpYqNUIPezk6edCoin@mail.gmail.com>
	<201006121643.33556.arekm@maven.pl>
Message-ID: <AANLkTikFAgIa0gVJP8waS2KEj5cSydDQSFRgyzKUnh8_@mail.gmail.com>

On Sat, Jun 12, 2010 at 4:43 PM, Arkadiusz Miskiewicz <arekm at maven.pl> wrote:
> On Saturday 12 of June 2010, Patryk Zawadzki wrote:
>> What you want is BR: %{_libdir}/libjpeg.so.62 so rpm generates the
>> *proper* Requires.
> rpm generates proper requires without such BR. They are figting over package
> name requires, not a real one.

I thought the whole thread was about rpm not picking the R: if the .so
file was not around when packaging. Otherwise it would be silly to add
an additional R, wouldn't it?

-- 
Patryk Zawadzki


From arekm at maven.pl  Sun Jun 13 07:31:06 2010
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Sun, 13 Jun 2010 07:31:06 +0200
Subject: do we have any mono people?
Message-ID: <201006130731.06655.arekm@maven.pl>


There is mono-moonlight.spec waiting for someone to finish, so if you are 
interested then play with it...

-- 
Arkadiusz Mi?kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/


From jajcus at jajcus.net  Sun Jun 13 09:24:38 2010
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Sun, 13 Jun 2010 09:24:38 +0200
Subject: packages: google-chrome/google-chrome.spec - do NOT add this
	bogs dep
In-Reply-To: <AANLkTimmodd5-c7ltrauofYSvtFST8HCNUA_to5c5B1F@mail.gmail.com>
References: <packages_google_chrome_google_chrome.spec.1.20@pld-linux.org>
	<packages_google_chrome_google_chrome.spec.1.21@pld-linux.org>
	<20100612124221.GA8072@lolek.nigdzie>
	<AANLkTimmodd5-c7ltrauofYSvtFST8HCNUA_to5c5B1F@mail.gmail.com>
Message-ID: <20100613072438.GA3813@lolek.nigdzie>

On Sat, Jun 12, 2010 at 02:51:30PM +0200, Bartosz ?wi?tek wrote:
> The main reason I've added this is the lack of libjpeg.so.62 in common
> PLD systems (th, titanium). This lib is provided by libjpeg6.spec -

Not only. Also by packages built from older libjpeg.spec, which could be
installed together with current libjpeg. And probably by some
third-party packages containing this library. None of these is available
in the Th or Ti package repository.

R: libjpeg.so.62, generated automatically by RPM is precise. 
'R: libjpeg6' will work only for one of the cases described above and
gives no extra information. 

IMHO glen is right ? this dependency is not needed and should be
dropped. 'R: libjpeg.so.62' is enough.

Greets,
        Jacek


From kamil.listy at klecza.pl  Sun Jun 13 16:47:24 2010
From: kamil.listy at klecza.pl (Kamil Dziedzic)
Date: Sun, 13 Jun 2010 16:47:24 +0200
Subject: packages/builder: download only new sources
Message-ID: <201006131647.32674.kamil.listy@klecza.pl>

Could somebody look a this and check if this doesn't break anything?

http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/builder?r1=1.620&r2=1.620.2.5

Modification:
- when --try-upgrade (-u) is requested check for new version
  before geting sources, so only new sources will be downloaded

-- 
Regards, Kamil Dziedzic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </mailman/pipermail/pld-devel-en/attachments/20100613/ea091e30/attachment.sig>

From glen at delfi.ee  Mon Jun 14 12:49:18 2010
From: glen at delfi.ee (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Mon, 14 Jun 2010 13:49:18 +0300
Subject: packages: google-chrome/google-chrome.spec - do NOT add this bogs
	dep
In-Reply-To: <20100613072438.GA3813@lolek.nigdzie>
References: <packages_google_chrome_google_chrome.spec.1.20@pld-linux.org>
	<AANLkTimmodd5-c7ltrauofYSvtFST8HCNUA_to5c5B1F@mail.gmail.com>
	<20100613072438.GA3813@lolek.nigdzie>
Message-ID: <201006141349.18798.glen@delfi.ee>

On Sunday 13 June 2010 10:24:38 Jacek Konieczny wrote:
> R: libjpeg.so.62, generated automatically by RPM is precise.
> 'R: libjpeg6' will work only for one of the cases described above and
> gives no extra information.
>
> IMHO glen is right ? this dependency is not needed and should be
> dropped. 'R: libjpeg.so.62' is enough.

yes, this is the reason why i removed that implicit Requires line. as the 
dependency is autogenerated by rpm build.

shadzik listed it with no reason why he added that requires (nothing in commit 
log other than word added). and yet added it back with no described reason 
again. so i assumed he did not read earlier commits, just added again. and 
assumed he added it initially due lack of knowledge. for example in same 
spec, nss/nspr dependency needs to be listed in requires line, as we disable 
soname generation on those libs.

and i'm removing BR libjpeg6-devel as it is stupid as R: libjpeg6, soname -> 
package name dep generation is disabled on th/ti, so there's no point of that 
at all.

if shadzik wants he can add the R: libjpeg6 back if the it is described in 
commit/spec why the implicit package name.

besides, why send this binary package to distro builders and ftp anyway, what 
we support is chromium-browser built from source.

-- 
glen


From glen at pld-linux.org  Mon Jun 14 12:53:22 2010
From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Mon, 14 Jun 2010 13:53:22 +0300
Subject: packages: google-chrome/google-chrome.spec - do NOT add this bogs
	dep
In-Reply-To: <AANLkTimmodd5-c7ltrauofYSvtFST8HCNUA_to5c5B1F@mail.gmail.com>
References: <packages_google_chrome_google_chrome.spec.1.20@pld-linux.org>
	<20100612124221.GA8072@lolek.nigdzie>
	<AANLkTimmodd5-c7ltrauofYSvtFST8HCNUA_to5c5B1F@mail.gmail.com>
Message-ID: <201006141353.22444.glen@pld-linux.org>

On Saturday 12 June 2010 15:51:30 Bartosz ?wi?tek wrote:
> I'm afraid glen removes this R: only to get his own comfort using this
> browser on deprecated Ac systems - which are officially not maintained
> by the PLD team.

your assumption is void. or "bullshit" to use words you know.

and what is this? "officially not maintained by the PLD team"?

if anything is "unofficial", then it is "ti" branch. Ac has not been declared 
EOL or unmaintained "officially".

-- 
glen


From glen at pld-linux.org  Mon Jun 14 13:00:44 2010
From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Mon, 14 Jun 2010 14:00:44 +0300
Subject: packages: google-chrome/google-chrome.spec - do NOT add this bogs
	dep
In-Reply-To: <AANLkTimrMJbewZ_T0fztUZrEfVnpYqNUIPezk6edCoin@mail.gmail.com>
References: <packages_google_chrome_google_chrome.spec.1.20@pld-linux.org>
	<AANLkTimmodd5-c7ltrauofYSvtFST8HCNUA_to5c5B1F@mail.gmail.com>
	<AANLkTimrMJbewZ_T0fztUZrEfVnpYqNUIPezk6edCoin@mail.gmail.com>
Message-ID: <201006141400.44888.glen@pld-linux.org>

On Saturday 12 June 2010 16:13:04 Patryk Zawadzki wrote:
> 2010/6/12 Bartosz ?wi?tek <shadzik at gmail.com>:
> > Removing this R: breaks the readability of the error and causes
> > unnecessary confusion.
> >
> > I'm afraid glen removes this R: only to get his own comfort using this
> > browser on deprecated Ac systems - which are officially not maintained
> > by the PLD team.
> >
> > Removing this R: is (in my eyes) breaking the package on purpose!!
>
> What you want is BR: %{_libdir}/libjpeg.so.62 so rpm generates the
> *proper* Requires.

name based dep generation is disabled in th/ti.

soname dep is sufficent, which is already autogenerated.

-- 
glen


From glen at pld-linux.org  Mon Jun 14 13:02:12 2010
From: glen at pld-linux.org (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Mon, 14 Jun 2010 14:02:12 +0300
Subject: packages: google-chrome/google-chrome.spec - do NOT add this bogs
	dep
In-Reply-To: <AANLkTimpz14MJ_cHMNTsz1UYdTt4_AvgwZT27w39nfW1@mail.gmail.com>
References: <packages_google_chrome_google_chrome.spec.1.20@pld-linux.org>
	<AANLkTimrMJbewZ_T0fztUZrEfVnpYqNUIPezk6edCoin@mail.gmail.com>
	<AANLkTimpz14MJ_cHMNTsz1UYdTt4_AvgwZT27w39nfW1@mail.gmail.com>
Message-ID: <201006141402.12376.glen@pld-linux.org>

On Saturday 12 June 2010 16:24:01 Bartosz ?wi?tek wrote:
> I agree that both solutions are not optimal - but in the end, it's a
> binary package - what do we ?expect? And the motto here is: better be
> verbose than sorry.

so, follow that moto yourself too, if you had commited that R with comment WHY 
you added it, there would had not been any "commit war".

-- 
glen


From caleb at pld-linux.org  Tue Jun 15 12:29:08 2010
From: caleb at pld-linux.org (Caleb Maclennan)
Date: Tue, 15 Jun 2010 13:29:08 +0300
Subject: Arch / Locale packaging issue.
Message-ID: <AANLkTimIYrH-jlB8Vl6IowMK3mEZZ7Ivu6GQcOOOSU81@mail.gmail.com>

I'm having some trouble packaging trac-0.12.

The current spec compiles, but the languages files are not generated
properly. If I remove BuildArch: noarch, everything builds and runs
fine but it doesn't seem that trac should be architecture specific
just because of some locale files. What is the correct way to get them
to build and package properly? I played with the %find_lang macro a
little bit but I couldn't figure out how to make it handle python
site-packages properly.

Thanks,
Caleb


From glen at delfi.ee  Tue Jun 15 16:17:23 2010
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Tue, 15 Jun 2010 17:17:23 +0300
Subject: Arch / Locale packaging issue.
In-Reply-To: <AANLkTimIYrH-jlB8Vl6IowMK3mEZZ7Ivu6GQcOOOSU81@mail.gmail.com>
References: <AANLkTimIYrH-jlB8Vl6IowMK3mEZZ7Ivu6GQcOOOSU81@mail.gmail.com>
Message-ID: <201006151717.23864.glen@pld-linux.org>

On Tuesday 15 June 2010 13:29:08 Caleb Maclennan wrote:
> I'm having some trouble packaging trac-0.12.
>
> The current spec compiles, but the languages files are not generated
> properly. If I remove BuildArch: noarch, everything builds and runs
> fine but

i don't see any lang files with disabled bulldarch: noarch either.

-- 
glen


From caleb at pld-linux.org  Tue Jun 15 16:24:09 2010
From: caleb at pld-linux.org (Caleb Maclennan)
Date: Tue, 15 Jun 2010 17:24:09 +0300
Subject: Arch / Locale packaging issue.
In-Reply-To: <201006151717.23864.glen@pld-linux.org>
References: <AANLkTimIYrH-jlB8Vl6IowMK3mEZZ7Ivu6GQcOOOSU81@mail.gmail.com> 
	<201006151717.23864.glen@pld-linux.org>
Message-ID: <AANLkTikMHkaJgIXx6YCbZevvKq6OfgKHkWJ_3ZY_0lrU@mail.gmail.com>

2010/6/15 Elan Ruusam?e <glen at delfi.ee>:
> i don't see any lang files with disabled bulldarch: noarch either.

Try building on i686. I don't get them on x86_64.

Also it's possible that python-Babel >= 0.9.5 is a BR.

Caleb


From glen at delfi.ee  Tue Jun 15 16:23:25 2010
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Tue, 15 Jun 2010 17:23:25 +0300
Subject: Arch / Locale packaging issue.
In-Reply-To: <201006151717.23864.glen@pld-linux.org>
References: <AANLkTimIYrH-jlB8Vl6IowMK3mEZZ7Ivu6GQcOOOSU81@mail.gmail.com>
	<201006151717.23864.glen@pld-linux.org>
Message-ID: <201006151723.25257.glen@pld-linux.org>

On Tuesday 15 June 2010 17:17:23 Elan Ruusam?e wrote:
> On Tuesday 15 June 2010 13:29:08 Caleb Maclennan wrote:
> > I'm having some trouble packaging trac-0.12.
> >
> > The current spec compiles, but the languages files are not generated
> > properly. If I remove BuildArch: noarch, everything builds and runs
> > fine but
>
> i don't see any lang files with disabled bulldarch: noarch either.

the *.mo is not present which it should install:

setup.py

    package_data = {
        '': ['templates/*'],
        'trac': ['htdocs/*.*', 'htdocs/README', 'htdocs/js/*.*',
                 'htdocs/js/messages/*.*', 'htdocs/css/*.*',
                 'htdocs/guide/*', 'locale/*/LC_MESSAGES/messages.mo'],

so first is needed to produce .po -> .mo 

which are in trac/locale dir:

Trac-0.12 $ find -name '*.po'| head -n1
./trac/locale/sl/LC_MESSAGES/messages-js.po

-- 
glen


From glen at delfi.ee  Tue Jun 15 18:30:25 2010
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Tue, 15 Jun 2010 19:30:25 +0300
Subject: Arch / Locale packaging issue.
In-Reply-To: <AANLkTikMHkaJgIXx6YCbZevvKq6OfgKHkWJ_3ZY_0lrU@mail.gmail.com>
References: <AANLkTimIYrH-jlB8Vl6IowMK3mEZZ7Ivu6GQcOOOSU81@mail.gmail.com>
	<201006151717.23864.glen@pld-linux.org>
	<AANLkTikMHkaJgIXx6YCbZevvKq6OfgKHkWJ_3ZY_0lrU@mail.gmail.com>
Message-ID: <201006151930.25650.glen@pld-linux.org>

On Tuesday 15 June 2010 17:24:09 Caleb Maclennan wrote:
> 2010/6/15 Elan Ruusam?e <glen at delfi.ee>:
> > i don't see any lang files with disabled bulldarch: noarch either.
>
> Try building on i686. I don't get them on x86_64.
>
> Also it's possible that python-Babel >= 0.9.5 is a BR.

yet it was missing python-genshi dep

-- 
glen


From caleb at pld-linux.org  Tue Jun 15 19:34:36 2010
From: caleb at pld-linux.org (Caleb Maclennan)
Date: Tue, 15 Jun 2010 20:34:36 +0300
Subject: Arch / Locale packaging issue.
In-Reply-To: <201006151930.25650.glen@pld-linux.org>
References: <AANLkTimIYrH-jlB8Vl6IowMK3mEZZ7Ivu6GQcOOOSU81@mail.gmail.com> 
	<201006151717.23864.glen@pld-linux.org>
	<AANLkTikMHkaJgIXx6YCbZevvKq6OfgKHkWJ_3ZY_0lrU@mail.gmail.com> 
	<201006151930.25650.glen@pld-linux.org>
Message-ID: <AANLkTimdPig3yzlr_LWo3uvOrehtLQvlzXvqYLar-7iD@mail.gmail.com>

2010/6/15 Elan Ruusam?e <glen at delfi.ee>:
> yet it was missing python-genshi dep

Thanks for sorting that and the rest of the lang file mess out.


From glen at delfi.ee  Wed Jun 16 12:36:01 2010
From: glen at delfi.ee (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Wed, 16 Jun 2010 13:36:01 +0300
Subject: packages/builder: download only new sources
In-Reply-To: <201006131647.32674.kamil.listy@klecza.pl>
References: <201006131647.32674.kamil.listy@klecza.pl>
Message-ID: <201006161336.01109.glen@pld-linux.org>

On Sunday 13 June 2010 17:47:24 Kamil Dziedzic wrote:
> Could somebody look a this and check if this doesn't break anything?
>
> http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/builder?r1=1.620&r2=1.620.
>2.5
>
> Modification:
> - when --try-upgrade (-u) is requested check for new version
>   before geting sources, so only new sources will be downloaded

seems working. commit to HEAD


glen at carme-pld ~/rpm/packages $ ./builder -bb -u ffmpeg
builder: SMP make flags are set to -j16
# $Revision: 1.193 $, $Date: 2010/05/26 07:56:10 $

No conditional flags passed

from available:
--with   :       nonfree
--without:       autoreqdep imlib2

Available branches: AC-branch RA-branch
New version found, updating spec file from 0.5.2 to version 0.6
--2010-06-16 13:35:20--  
http://ffmpeg.mplayerhq.hu/releases/ffmpeg-0.6.tar.bz2
Resolving ffmpeg.mplayerhq.hu (ffmpeg.mplayerhq.hu)... 213.144.138.186
Connecting to ffmpeg.mplayerhq.hu (ffmpeg.mplayerhq.hu)|213.144.138.186|:80... 
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://ffmpeg.org/releases/ffmpeg-0.6.tar.bz2 [following]
--2010-06-16 13:35:21--  http://ffmpeg.org/releases/ffmpeg-0.6.tar.bz2
Resolving ffmpeg.org (ffmpeg.org)... 213.144.138.186
Reusing existing connection to ffmpeg.mplayerhq.hu:80.
HTTP request sent, awaiting response... 200 OK
Length: 3720372 (3.5M) [application/x-bzip]
Saving to: ?ffmpeg-0.6.tar.bz2?


-- 
glen


From kamil.listy at klecza.pl  Wed Jun 16 20:02:11 2010
From: kamil.listy at klecza.pl (Kamil Dziedzic)
Date: Wed, 16 Jun 2010 20:02:11 +0200
Subject: packages/builder: download only new sources
In-Reply-To: <201006161336.01109.glen@pld-linux.org>
References: <201006131647.32674.kamil.listy@klecza.pl>
	<201006161336.01109.glen@pld-linux.org>
Message-ID: <201006162002.18276.kamil.listy@klecza.pl>

Elan Ruusam?e wrote:
> seems working. commit to HEAD

Thanks, commited.

-- 
Regards, Kamil Dziedzic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </mailman/pipermail/pld-devel-en/attachments/20100616/aff574dd/attachment.sig>

From areq at pld-linux.org  Sat Jun 19 00:20:24 2010
From: areq at pld-linux.org (Areq)
Date: Sat, 19 Jun 2010 00:20:24 +0200
Subject: HELP: New PLD Rescue CD
In-Reply-To: <201006051915.12684.arekm@maven.pl>
References: <201006051915.12684.arekm@maven.pl>
Message-ID: <4vrn16p8uv1i2bbvcapcehv1bja154sm0c@4ax.com>

On Sat, 5 Jun 2010 19:15:12 +0200, you wrote:

>
>New PLD RescueCD is hopefuly to be produced at the end of this month but areq 
>needs help with fixing packages. 
>Please help and commit fixes or email patches here.

on i486 only few still needs fixes:
 
http://pld.areq.eu.org/th-i486h/problems/

Cheers,
-- 
Arkadiusz Patyk [areq<>pld-linux:org] [http://rescuecd.pld-linux.org/]
[IRC:areq GG:1383 jid:arek<>patyk:net]


From adamg at pld-linux.org  Sat Jun 19 09:51:27 2010
From: adamg at pld-linux.org (Adam Golebiowski)
Date: Sat, 19 Jun 2010 09:51:27 +0200
Subject: HELP: New PLD Rescue CD
In-Reply-To: <4vrn16p8uv1i2bbvcapcehv1bja154sm0c@4ax.com>
References: <201006051915.12684.arekm@maven.pl>
	<4vrn16p8uv1i2bbvcapcehv1bja154sm0c@4ax.com>
Message-ID: <20100619075127.GA5873@agmk.net>

On Sat, Jun 19, 2010 at 12:20:24AM +0200, Areq wrote:
> On Sat, 5 Jun 2010 19:15:12 +0200, you wrote:
> 
> >
> >New PLD RescueCD is hopefuly to be produced at the end of this month but areq 
> >needs help with fixing packages. 
> >Please help and commit fixes or email patches here.
> 
> on i486 only few still needs fixes:
>  
> http://pld.areq.eu.org/th-i486h/problems/

ckermit fixed

-- 
adamg


From sparky at pld-linux.org  Sat Jun 19 16:12:39 2010
From: sparky at pld-linux.org (Przemyslaw Iskra)
Date: Sat, 19 Jun 2010 16:12:39 +0200
Subject: HELP: New PLD Rescue CD
In-Reply-To: <4vrn16p8uv1i2bbvcapcehv1bja154sm0c@4ax.com>
References: <201006051915.12684.arekm@maven.pl>
	<4vrn16p8uv1i2bbvcapcehv1bja154sm0c@4ax.com>
Message-ID: <20100619141239.GA15303@pld-linux.org>

On Sat, Jun 19, 2010 at 12:20:24AM +0200, Areq wrote:
> on i486 only few still needs fixes:
>  
> http://pld.areq.eu.org/th-i486h/problems/

I dusted off whole ettercap build system and introduced few minor fixes.
Whould be nice if someone checked whether it works the same way it used
to.

Anyway, builds now.


-- 
 ____  Sparky{PI] -- Przemyslaw _  ___  _  _  ........... LANG...Pl..Ca..Es..En
/____) ___  ___  _ _ || Iskra  |  | _ \| |  | : WWW........ppcrcd.pld-linux.org
\____\| -_)'___| ||^'||//\\// <   |  _/| |  | : JID......sparky<at>jabberes.org
(____/||   (_-_|_||  ||\\ ||   |_ |_|  |_| _| : Mail....sparky<at>pld-linux.org


From ankry at green.mif.pg.gda.pl  Tue Jun 22 10:27:28 2010
From: ankry at green.mif.pg.gda.pl (ankry at green.mif.pg.gda.pl)
Date: Tue, 22 Jun 2010 10:27:28 +0200 (CEST)
Subject: CVSROOT: acl - restrict cdg access
In-Reply-To: <CVSROOT_acl.1.62@pld-linux.org>
Message-ID: <201006220827.o5M8RSX2021001@green.mif.pg.gda.pl>

Just noticed.

glen wrote:
> Index: CVSROOT/acl
> diff -u CVSROOT/acl:1.61 CVSROOT/acl:1.62
> --- CVSROOT/acl:1.61	Mon Feb 15 07:56:49 2010
> +++ CVSROOT/acl	Thu Jun 17 15:55:24 2010
> @@ -28,6 +28,10 @@
>  ^PLDWWW/	^(tumash)$	allow
>  ^.*		^(tumash)$	deny
>  
> +# CDG members only
> +^cdg/	^(adamg|adasi|adgor|ankry|arekm|areq|averne|baggins|baseciq|blues|cieciwa|djrzulf|djurban|dzimi|glen|gotar|grzegol|havner|hawk|jajcus|krzak|marcus|matkor|mkierus|mmazur|orzech|pascalek|qboosh|trojan|undefine|wolf)$ allow
> +^cdg/	.*		deny
> +
>  # accounts for svn/pld-doc only
>  .*	^(kermit|rennis|shufla|lop|darkstar)$	deny
>  # accounts for svn/bmp-plugins only

>From cdg/regulations:

: *** Voting.
: 
: Voting proposal may be filled by any PLD developer (not necessary member
: of CDG), proposal than lays in CVS for at least 24h, during which it
: should be dicussed and changed, if needed.

How a non-cdg member could do it now?

-- 
=======================================================================
  Andrzej M. Krzysztofowicz                  ankry at mif.pg.gda.pl


From z at xatka.net  Thu Jun 24 13:25:22 2010
From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski)
Date: Thu, 24 Jun 2010 13:25:22 +0200
Subject: rpm.groups - Libraries/Ruby
Message-ID: <20100624112522.GD4544@pzz.touk.pl>

Proposition:
  let's add new groups for ruby packages:
      Libraries/Ruby
	  Development/Languages/Ruby

Any comments?

-- 
Regards,
Pawe? Zuzelski


From wolf.pld at gmail.com  Thu Jun 24 13:31:50 2010
From: wolf.pld at gmail.com (Bartosz Taudul)
Date: Thu, 24 Jun 2010 13:31:50 +0200
Subject: rpm.groups - Libraries/Ruby
In-Reply-To: <20100624112522.GD4544@pzz.touk.pl>
References: <20100624112522.GD4544@pzz.touk.pl>
Message-ID: <AANLkTikcj4zHVOOH0yjHL5_DnHrPQdO506KIum21FrBu@mail.gmail.com>

2010/6/24 Pawe? Zuzelski <z at xatka.net>:
> Any comments?
Why do we care about RPM groups?

wolf


From n3npq at mac.com  Thu Jun 24 15:12:24 2010
From: n3npq at mac.com (Jeff Johnson)
Date: Thu, 24 Jun 2010 09:12:24 -0400
Subject: rpm.groups - Libraries/Ruby
In-Reply-To: <AANLkTikcj4zHVOOH0yjHL5_DnHrPQdO506KIum21FrBu@mail.gmail.com>
References: <20100624112522.GD4544@pzz.touk.pl>
	<AANLkTikcj4zHVOOH0yjHL5_DnHrPQdO506KIum21FrBu@mail.gmail.com>
Message-ID: <CB7813FD-2C2C-41BD-A5A7-B0898810A9CD@mac.com>


On Jun 24, 2010, at 7:31 AM, Bartosz Taudul wrote:

> 2010/6/24 Pawe? Zuzelski <z at xatka.net>:
>> Any comments?
> Why do we care about RPM groups?
> 

What else would we discuss if RPMTAG_GROUP did not exist?

Did Poland do well in South Africa?

73 de Jeff

From z at xatka.net  Thu Jun 24 15:36:37 2010
From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski)
Date: Thu, 24 Jun 2010 15:36:37 +0200
Subject: rpm.groups - Libraries/Ruby
In-Reply-To: <CB7813FD-2C2C-41BD-A5A7-B0898810A9CD@mac.com>
References: <20100624112522.GD4544@pzz.touk.pl>
	<AANLkTikcj4zHVOOH0yjHL5_DnHrPQdO506KIum21FrBu@mail.gmail.com>
	<CB7813FD-2C2C-41BD-A5A7-B0898810A9CD@mac.com>
Message-ID: <20100624133637.GE4544@pzz.touk.pl>

On Thu, 24 Jun 2010, Jeff Johnson wrote:
> What else would we discuss if RPMTAG_GROUP did not exist?

Sorry, I don't get it.

> Did Poland do well in South Africa?

Not so bad, we have not lost any game yet.

-- 
Regards,
Pawe? Zuzelski


From wolf.pld at gmail.com  Thu Jun 24 15:42:16 2010
From: wolf.pld at gmail.com (Bartosz Taudul)
Date: Thu, 24 Jun 2010 15:42:16 +0200
Subject: rpm.groups - Libraries/Ruby
In-Reply-To: <CB7813FD-2C2C-41BD-A5A7-B0898810A9CD@mac.com>
References: <20100624112522.GD4544@pzz.touk.pl>
	<AANLkTikcj4zHVOOH0yjHL5_DnHrPQdO506KIum21FrBu@mail.gmail.com>
	<CB7813FD-2C2C-41BD-A5A7-B0898810A9CD@mac.com>
Message-ID: <AANLkTinl14S2UomjwECKqtEhcVpgwe9hoIaMx8iw4r37@mail.gmail.com>

2010/6/24 Jeff Johnson <n3npq at mac.com>:
>> Why do we care about RPM groups?
> What else would we discuss if RPMTAG_GROUP did not exist?
I was referring to the general shit state of the group hierarchy in
PLD. Basically 90% of the stuff is in Applications or
X11/Applications, which makes the groups completly useless. There was
some movement to make them more useful, but that was in 2004 and
hadn't been talked about since then.

New group hierarchy proposition can be found at
http://cvs.pld-linux.org/cgi-bin/cvsweb/PLD-doc/nowe-grupy?rev=HEAD.
Jeff, it would be interesting to hear what do you think about
replacement of groups with tags, as that might make more sense.
Prototype graphical package manager which sorts packages by groups can
be downloaded from http://team.pld-linux.org/~wolf/pacman/, but it's
not all that useful.
Prototype tool for managing package groups can be downloaded from
http://team.pld-linux.org/~wolf/rgmt.7z, but it works only with the
old SPECS/SOURCES structure and will break on some spec files. But,
since it displays the groups from all the spec files, it can show how
much chaos and typos is there, since nobody really cares.

tl;dr: RPM groups in PLD suck.

wolf


From n3npq at mac.com  Thu Jun 24 15:42:23 2010
From: n3npq at mac.com (Jeff Johnson)
Date: Thu, 24 Jun 2010 09:42:23 -0400
Subject: rpm.groups - Libraries/Ruby
In-Reply-To: <20100624133637.GE4544@pzz.touk.pl>
References: <20100624112522.GD4544@pzz.touk.pl>
	<AANLkTikcj4zHVOOH0yjHL5_DnHrPQdO506KIum21FrBu@mail.gmail.com>
	<CB7813FD-2C2C-41BD-A5A7-B0898810A9CD@mac.com>
	<20100624133637.GE4544@pzz.touk.pl>
Message-ID: <A892BF07-8A4A-4163-ABDB-8999891F3F3F@mac.com>


On Jun 24, 2010, at 9:36 AM, Pawe? Zuzelski wrote:

> On Thu, 24 Jun 2010, Jeff Johnson wrote:
>> What else would we discuss if RPMTAG_GROUP did not exist?
> 
> Sorry, I don't get it.
> 

Translation from obscure jbj-speak:
	RPMTAG_GROUP is utterly broken as a "package" metadata
	item because there is No One True Taxonomy!
	Nor can One True Taxonomy be devised manually
	(but debtag facets are the most interesting approach)

>> Did Poland do well in South Africa?
> 
> Not so bad, we have not lost any game yet.
> 

Lots of ties eh? ;-)

73 de Jeff

From n3npq at mac.com  Thu Jun 24 16:06:06 2010
From: n3npq at mac.com (Jeff Johnson)
Date: Thu, 24 Jun 2010 10:06:06 -0400
Subject: rpm.groups - Libraries/Ruby
In-Reply-To: <AANLkTinl14S2UomjwECKqtEhcVpgwe9hoIaMx8iw4r37@mail.gmail.com>
References: <20100624112522.GD4544@pzz.touk.pl>
	<AANLkTikcj4zHVOOH0yjHL5_DnHrPQdO506KIum21FrBu@mail.gmail.com>
	<CB7813FD-2C2C-41BD-A5A7-B0898810A9CD@mac.com>
	<AANLkTinl14S2UomjwECKqtEhcVpgwe9hoIaMx8iw4r37@mail.gmail.com>
Message-ID: <5D7AC507-CA04-4C59-90BD-2624A55CA229@mac.com>


On Jun 24, 2010, at 9:42 AM, Bartosz Taudul wrote:

> 2010/6/24 Jeff Johnson <n3npq at mac.com>:
>>> Why do we care about RPM groups?
>> What else would we discuss if RPMTAG_GROUP did not exist?
> I was referring to the general shit state of the group hierarchy in
> PLD. Basically 90% of the stuff is in Applications or
> X11/Applications, which makes the groups completly useless. There was
> some movement to make them more useful, but that was in 2004 and
> hadn't been talked about since then.
> 
> New group hierarchy proposition can be found at
> http://cvs.pld-linux.org/cgi-bin/cvsweb/PLD-doc/nowe-grupy?rev=HEAD.
> Jeff, it would be interesting to hear what do you think about
> replacement of groups with tags, as that might make more sense.

Well all I've ever been able to figure (the proposals for Newer!
Better! Bestest! Group: values come out approx. monthly regular
as clockwork) is to get RPMTAG_GROUP out of *.rpm metadata
entirely (which was achieved years ago with specspo just noone uses).

Even if you stabilize the msgid's like "Library/Ruby", you've
got the msgstr's to deal with for i18n encoding display purposes.

No way that all of that process can ever succeed if/when compiled
into *.rpm metadata. As soon as you achieve anything, the entire "process"
restarts itself again and again and again ...

But detaching RPMTAG_GROUP from *.rpm packages is quite doable (see
specspo for "doable" even if you think spescpo is crap -- specspo is crap imho),
in order to support multiple hierarchies with well defined markup
(hopefully _NOT_ PO as in specspo), with encodings and ...
> Prototype graphical package manager which sorts packages by groups can
> be downloaded from http://team.pld-linux.org/~wolf/pacman/, but it's
> not all that useful.

... per-application "sorts" and criteria should be attempted.

(aside re "useful")
Typically RPMTAG_GROUP is implicitly used as a hierarchical "attribute" name
space. The "hierarchical" permits sorting, and the "attribute" permits
tagging of subsets of a very large universe of "packaging".

What's tricky is that the values in the name space aren't reliable.
There's _LOTS_ that could be implemented in installers like RPM et al
with a "set membership" attribute if the data values in the name space
were reliable. For one slightly different, but related to RPMTAG_GROUP
as an "attribute" attached to packages, see the recent addition of
RPMTAG_COLLECTION on the <rpm-maint at rm.org> mailing list

(Note: I don't believe the Tresys patchset as posted/adopted will ever work
in any version of RPM, but the RPMTAG_COLLECTION attribute framework for
"set membership" is savable if the data is populated with methodolgy and discipline.)

> Prototype tool for managing package groups can be downloaded from
> http://team.pld-linux.org/~wolf/rgmt.7z, but it works only with the
> old SPECS/SOURCES structure and will break on some spec files. But,
> since it displays the groups from all the spec files, it can show how
> much chaos and typos is there, since nobody really cares.
> 
> tl;dr: RPM groups in PLD suck.
> 

GROUPS in RPM suck, that's no PLD fault.

73 de Jeff


From wrobell at pld-linux.org  Thu Jun 24 16:11:52 2010
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Thu, 24 Jun 2010 15:11:52 +0100
Subject: rpm.groups - Libraries/Ruby
In-Reply-To: <A892BF07-8A4A-4163-ABDB-8999891F3F3F@mac.com>
References: <20100624112522.GD4544@pzz.touk.pl>
	<AANLkTikcj4zHVOOH0yjHL5_DnHrPQdO506KIum21FrBu@mail.gmail.com>
	<CB7813FD-2C2C-41BD-A5A7-B0898810A9CD@mac.com>
	<20100624133637.GE4544@pzz.touk.pl>
	<A892BF07-8A4A-4163-ABDB-8999891F3F3F@mac.com>
Message-ID: <AANLkTimDSp6bL-eIH6xeeFWo7MvyVUTgVhHO_pe037jU@mail.gmail.com>

2010/6/24 Jeff Johnson <n3npq at mac.com>:
>
> On Jun 24, 2010, at 9:36 AM, Pawe? Zuzelski wrote:
>
>> On Thu, 24 Jun 2010, Jeff Johnson wrote:
[...]
>>> Did Poland do well in South Africa?
>>
>> Not so bad, we have not lost any game yet.
>>
>
> Lots of ties eh? ;-)

No ties, it is just impossible for us to loose. :)

Best regards,

w


From n3npq at mac.com  Thu Jun 24 16:14:35 2010
From: n3npq at mac.com (Jeff Johnson)
Date: Thu, 24 Jun 2010 10:14:35 -0400
Subject: rpm.groups - Libraries/Ruby
In-Reply-To: <AANLkTimDSp6bL-eIH6xeeFWo7MvyVUTgVhHO_pe037jU@mail.gmail.com>
References: <20100624112522.GD4544@pzz.touk.pl>
	<AANLkTikcj4zHVOOH0yjHL5_DnHrPQdO506KIum21FrBu@mail.gmail.com>
	<CB7813FD-2C2C-41BD-A5A7-B0898810A9CD@mac.com>
	<20100624133637.GE4544@pzz.touk.pl>
	<A892BF07-8A4A-4163-ABDB-8999891F3F3F@mac.com>
	<AANLkTimDSp6bL-eIH6xeeFWo7MvyVUTgVhHO_pe037jU@mail.gmail.com>
Message-ID: <283765BD-8585-4F1D-9721-AD232480042E@mac.com>


On Jun 24, 2010, at 10:11 AM, Artur Wroblewski wrote:

> 2010/6/24 Jeff Johnson <n3npq at mac.com>:
>> 
>> On Jun 24, 2010, at 9:36 AM, Pawe? Zuzelski wrote:
>> 
>>> On Thu, 24 Jun 2010, Jeff Johnson wrote:
> [...]
>>>> Did Poland do well in South Africa?
>>> 
>>> Not so bad, we have not lost any game yet.
>>> 
>> 
>> Lots of ties eh? ;-)
> 
> No ties, it is just impossible for us to loose. :)
> 

Send the Polish team down to the Gulf of Mexico when they're through
playing around with the football in South Africa please. I hear
there's an oily mess to clean up ...

73 de Jeff



From n3npq at mac.com  Thu Jun 24 16:59:22 2010
From: n3npq at mac.com (Jeff Johnson)
Date: Thu, 24 Jun 2010 10:59:22 -0400
Subject: rpm.groups - Libraries/Ruby
In-Reply-To: <AANLkTinl14S2UomjwECKqtEhcVpgwe9hoIaMx8iw4r37@mail.gmail.com>
References: <20100624112522.GD4544@pzz.touk.pl>
	<AANLkTikcj4zHVOOH0yjHL5_DnHrPQdO506KIum21FrBu@mail.gmail.com>
	<CB7813FD-2C2C-41BD-A5A7-B0898810A9CD@mac.com>
	<AANLkTinl14S2UomjwECKqtEhcVpgwe9hoIaMx8iw4r37@mail.gmail.com>
Message-ID: <906D34EB-5925-4F82-B787-84B1E679C096@mac.com>


On Jun 24, 2010, at 9:42 AM, Bartosz Taudul wrote:

> 2010/6/24 Jeff Johnson <n3npq at mac.com>:
>>> Why do we care about RPM groups?
>> What else would we discuss if RPMTAG_GROUP did not exist?
> I was referring to the general shit state of the group hierarchy in
> PLD. Basically 90% of the stuff is in Applications or
> X11/Applications, which makes the groups completly useless. There was
> some movement to make them more useful, but that was in 2004 and
> hadn't been talked about since then.
> 
> New group hierarchy proposition can be found at
> http://cvs.pld-linux.org/cgi-bin/cvsweb/PLD-doc/nowe-grupy?rev=HEAD.

This tree is as good as any other I've seen, certainly far far
better than synaptic/aptitude choices.

Have you considered:

Setting up a process to map specific packages into your taxonomy

    Something like a de.licio.us tagging framework to do the mapping
    subjectively with "community" (whatever that means) involvement
    would be one relatively painless process. Any "voting" metric
    (with all the usual voting "fraud" control issues) would work
    as well as de.licio.us

    The other approach used in debtags is to attempt a RDF semantic
    abstraction in order to truly (and "objectively") hammer out
    a usable taxonomy. Its "objectively" that is admirable (and
    interesting to me wrto RPMTAG_GROUP), all the other issues of
    RDF and smantic and classification and ... that are part of the
    methodolgy make my head hurt *a lot*.

Setting up representations of the tree markup in JSON/XML/YAML/HTML/DocBook/...

    The package taxonomy that easily and automagically transforms to the largest
    number of output usage cases is going to "win" in the end. Its not
    just installers that need to present "package" data in useful forms.

And -- if you show me some reasonable markup for your Group: hierarchical tree --
I'll happily patch up RPM to use your markup rather than specspo with
    rpm -qa --qf '%{GROUP}\n'
The patch for other markup isn't anywhere near as hard as getting "consensus" regarding
how a package hierarchical namespace SHOULD look.

If your markup includes some additional means for general "attribute"
tagging of packages, all the better. I have several usage cases in RPM
that are blocked solely by lack of "consensus" on how "attributes"
should be attached to packages (the RPMTAG_COLLECTION patch on
<rpm-maint at rpm.org> is just one of many usage cases).

hth

73 de Jeff
    



From wolf.pld at gmail.com  Thu Jun 24 17:22:08 2010
From: wolf.pld at gmail.com (Bartosz Taudul)
Date: Thu, 24 Jun 2010 17:22:08 +0200
Subject: rpm.groups - Libraries/Ruby
In-Reply-To: <906D34EB-5925-4F82-B787-84B1E679C096@mac.com>
References: <20100624112522.GD4544@pzz.touk.pl>
	<AANLkTikcj4zHVOOH0yjHL5_DnHrPQdO506KIum21FrBu@mail.gmail.com>
	<CB7813FD-2C2C-41BD-A5A7-B0898810A9CD@mac.com>
	<AANLkTinl14S2UomjwECKqtEhcVpgwe9hoIaMx8iw4r37@mail.gmail.com>
	<906D34EB-5925-4F82-B787-84B1E679C096@mac.com>
Message-ID: <AANLkTikGmHPQa7JjRUaSDcKo9aiNctqkve2CTYi5gz23@mail.gmail.com>

>> New group hierarchy proposition can be found at
>> http://cvs.pld-linux.org/cgi-bin/cvsweb/PLD-doc/nowe-grupy?rev=HEAD.
> This tree is as good as any other I've seen, certainly far far
> better than synaptic/aptitude choices.
It was based on sourceforge trove software map.

> Have you considered:
>
> Setting up a process to map specific packages into your taxonomy
>
> ? ?Something like a de.licio.us tagging framework to do the mapping
> ? ?subjectively with "community" (whatever that means) involvement
> ? ?would be one relatively painless process.
Translation: noone would do it. Not worth the effort.

wolf


From n3npq at mac.com  Thu Jun 24 17:43:11 2010
From: n3npq at mac.com (Jeff Johnson)
Date: Thu, 24 Jun 2010 11:43:11 -0400
Subject: rpm.groups - Libraries/Ruby
In-Reply-To: <AANLkTikGmHPQa7JjRUaSDcKo9aiNctqkve2CTYi5gz23@mail.gmail.com>
References: <20100624112522.GD4544@pzz.touk.pl>
	<AANLkTikcj4zHVOOH0yjHL5_DnHrPQdO506KIum21FrBu@mail.gmail.com>
	<CB7813FD-2C2C-41BD-A5A7-B0898810A9CD@mac.com>
	<AANLkTinl14S2UomjwECKqtEhcVpgwe9hoIaMx8iw4r37@mail.gmail.com>
	<906D34EB-5925-4F82-B787-84B1E679C096@mac.com>
	<AANLkTikGmHPQa7JjRUaSDcKo9aiNctqkve2CTYi5gz23@mail.gmail.com>
Message-ID: <E4DEBF7E-DF2F-437C-BDC8-1169766F836F@mac.com>


On Jun 24, 2010, at 11:22 AM, Bartosz Taudul wrote:

>>> New group hierarchy proposition can be found at
>>> http://cvs.pld-linux.org/cgi-bin/cvsweb/PLD-doc/nowe-grupy?rev=HEAD.
>> This tree is as good as any other I've seen, certainly far far
>> better than synaptic/aptitude choices.
> It was based on sourceforge trove software map.
> 
>> Have you considered:
>> 
>> Setting up a process to map specific packages into your taxonomy
>> 
>>    Something like a de.licio.us tagging framework to do the mapping
>>    subjectively with "community" (whatever that means) involvement
>>    would be one relatively painless process.
> Translation: noone would do it. Not worth the effort.

If you're saying
	Noone has time for bookmarking at http://de.licio.us any more.
I absolutely agree.

(aside)
In fact bookmarking (and Google keyword searches)
Just Don't Work Well, but that's a whole different and quite complex
discussion. I kinda like de.licio.us because I can track through
a bookmark tag to see what _ELSE_ a person interested enough
to add a de.licio.us bookmark that blipped my radar might
be interested in. I can't do that with Google keyword searches.

But de.licio.us (and more generally Ajax) are a pathway to automated collection
of "voting" metrics for "attributes" attached to "packages" indepnedently
(and persistently) after a package has been built. The ultimate
design flaw with RPMTAG_GROUP (and other tags in RPM metadata) is
that static content delivery isn't very useful in 2010, the
"process" to embed tags in packaging reliably is just too cumbersome these days.

The code for de.licio.us (and Ajax and REST-ful in general) is
there for the stealing is all I meant to point out.

But go look at any site that is advertising RPM "packages". Here's
are several URL's (from a thread on centos-devel mailing list) I had to visit
this week:

	http://packages.debian.org/lenny/php5
	http://www.freshports.org/

All of those "package" presentations are ugly, useless, uninformative
and otherwise as pointless as RPMTAG_GROUP is in RPM installers.

This URL I particularly have issue with (not with the site per se)
	http://pkg.org.ua/
Note the organization using "vendor" as a toplevel "attribute" for "package"
choosing.

If "vendor" is the only "attribute" that is presented to lusers, well,
FL/OSS software is just doomed.

And it wouldn't be that hard to change the "package" presentation using, say, a
more reasonable and intelligent hierarchical tree like what you pointed me to.

hth

73 de Jeff


From marcin.rybak at gmail.com  Fri Jun 25 22:22:35 2010
From: marcin.rybak at gmail.com (Marcin Rybak)
Date: Fri, 25 Jun 2010 13:22:35 -0700 (PDT)
Subject: Marcin Rybak wants to connect on LinkedIn
Message-ID: <2138666580.1322725.1277497355051.JavaMail.app@ech3-cdn05.prod>

LinkedIn
------------

   
I'd like to add you to my professional network on LinkedIn.

- Marcin Rybak

Marcin Rybak
IT Infrastructure Administrator at Kubas, Kos, Gaertner - Adwokaci Sp. P. 
Krak?w Area, Poland

Confirm that you know Marcin Rybak
https://www.linkedin.com/e/-wb9u7p-gavgxvs9-5g/isd/1416854584/GfPiC7X_/


 
------
(c) 2010, LinkedIn Corporation

From adamg at pld-linux.org  Mon Jun 28 13:33:34 2010
From: adamg at pld-linux.org (Adam Golebiowski)
Date: Mon, 28 Jun 2010 13:33:34 +0200
Subject: dependency tracking between php modules
Message-ID: <20100628113334.GA7361@agmk.net>

Hi,

There's a problem with dependency tracking between php modules, both
internal and external (e.g. pecl's packages).

You can easily test the situation - with a recent environment
(where session support is separated) install php-pecl-http and try to run
php interpreter (/usr/bin/php), it will complain about missing
ps_globals_id symbol:

"PHP Warning:  PHP Startup: Unable to load dynamic library
'/usr/lib/php/http.so' - /usr/lib/php/http.so: undefined symbol:
ps_globals_id in Unknown on line 0"

A workaround is to rename http.ini to be called after session.ini, but
this does not solve real problem. We already use this kind of workaround
to solve dependency between core php modules - see packages/php/php.spec
(generate_inifiles) for details. 

Since it's not a common situation, I thought about using SysVinit's
style and apply following scheme:
00-09 - core php stuff (spl, pcre)
10-49 - standard php modules (e.g. pdo)
50-99 - additional php modules (e.g. pecl packages)

This shouldn't break anything, and it would be sufficient to apply this
to php.spec only to solve issue with php-pecl-http (00_pcre.ini,
01_spl.ini, 10_session.ini, http.ini).

Any objections?

-- 
adamg


From pld at nius.waw.pl  Tue Jun 29 18:30:50 2010
From: pld at nius.waw.pl (Marcin Kurzyna)
Date: Tue, 29 Jun 2010 18:30:50 +0200
Subject: dependency tracking between php modules
In-Reply-To: <20100628113334.GA7361@agmk.net>
References: <20100628113334.GA7361@agmk.net>
Message-ID: <201006291830.51263.pld@nius.waw.pl>

On Monday 28 of June 2010 13:33:34 Adam Golebiowski wrote:

> You can easily test the situation - with a recent environment
> (where session support is separated) install php-pecl-http and try to run
> php interpreter (/usr/bin/php), it will complain about missing
> ps_globals_id symbol:

Same is with php-pecl-memcached which requires session loaded as it provides 
own session implementation (complains about missing symbols).

> Any objections?

please do. 

mk



From sparky at pld-linux.org  Tue Jun 29 19:28:55 2010
From: sparky at pld-linux.org (Przemyslaw Iskra)
Date: Tue, 29 Jun 2010 19:28:55 +0200
Subject: packages: lensfun/lensfun.spec - package api manual - rel. 1
In-Reply-To: <packages_lensfun_lensfun.spec.1.5@pld-linux.org>
References: <packages_lensfun_lensfun.spec.1.4@pld-linux.org>
	<packages_lensfun_lensfun.spec.1.5@pld-linux.org>
Message-ID: <20100629172855.GA9789@pld-linux.org>

On Tue, Jun 29, 2010 at 04:28:17PM +0200, draenog wrote:

> @@ -87,6 +84,8 @@
>  
>  %{__make} install \
>  	DESTDIR=$RPM_BUILD_ROOT
> +%{__gzip} -9 $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}/{README,cc-by-sa-3.0.txt}
> +rm $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}/{gpl-3.0.txt,lgpl-3.0.txt}
>  
>  %clean
>  rm -rf $RPM_BUILD_ROOT
> @@ -96,7 +95,9 @@
>  
>  %files
>  %defattr(644,root,root,755)
> -%doc README docs/cc-by-sa-3.0.txt
> +%{_docdir}/%{name}-%{version}/README.gz
> +%{_docdir}/%{name}-%{version}/cc-by-sa-3.0.txt.gz
> +%dir %{_docdir}/%{name}-%{version}
>  %attr(755,root,root) %{_libdir}/liblensfun.so.*.*.*
>  %{_datadir}/lensfun
>  

Please, give us a good reason why you've done this manually.

-- 
 ____  Sparky{PI] -- Przemyslaw _  ___  _  _  ......... LANG...Pl,Ca,Es,En
/____) ___  ___  _ _ || Iskra  |  | _ \| |  | : WWW...ppcrcd.pld-linux.org
\____\| -_)'___| ||^'||//\\// <   |  _/| |  | : WWW2..............rsget.pl
(____/||   (_-_|_||  ||\\ ||   |_ |_|  |_| _| : Mail..sparky at pld-linux.org


From wolf.pld at gmail.com  Tue Jun 29 19:56:04 2010
From: wolf.pld at gmail.com (Bartosz Taudul)
Date: Tue, 29 Jun 2010 19:56:04 +0200
Subject: packages: lensfun/lensfun.spec - package api manual - rel. 1
In-Reply-To: <20100629172855.GA9789@pld-linux.org>
References: <packages_lensfun_lensfun.spec.1.4@pld-linux.org>
	<packages_lensfun_lensfun.spec.1.5@pld-linux.org>
	<20100629172855.GA9789@pld-linux.org>
Message-ID: <AANLkTinDsFDbthl8UV7XQrS8x_vjDHNKdSIcf9WqAvd6@mail.gmail.com>

On Tue, Jun 29, 2010 at 7:28 PM, Przemyslaw Iskra <sparky at pld-linux.org> wrote:
> Please, give us a good reason why you've done this manually.
>> +%{_docdir}/%{name}-%{version}/cc-by-sa-3.0.txt.gz
And why this is even packed.

wolf


From kornet at gatekeeper.camk.edu.pl  Tue Jun 29 20:09:55 2010
From: kornet at gatekeeper.camk.edu.pl (Kacper Kornet)
Date: Tue, 29 Jun 2010 20:09:55 +0200
Subject: packages: lensfun/lensfun.spec - package api manual - rel. 1
In-Reply-To: <20100629172855.GA9789@pld-linux.org>
References: <packages_lensfun_lensfun.spec.1.4@pld-linux.org>
	<packages_lensfun_lensfun.spec.1.5@pld-linux.org>
	<20100629172855.GA9789@pld-linux.org>
Message-ID: <20100629180955.GA23642@gatekeeper.camk.edu.pl>

On Tue, Jun 29, 2010 at 07:28:55PM +0200, Przemyslaw Iskra wrote:
> On Tue, Jun 29, 2010 at 04:28:17PM +0200, draenog wrote:

> > @@ -87,6 +84,8 @@

> >  %{__make} install \
> >  	DESTDIR=$RPM_BUILD_ROOT
> > +%{__gzip} -9 $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}/{README,cc-by-sa-3.0.txt}
> > +rm $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}/{gpl-3.0.txt,lgpl-3.0.txt}

> >  %clean
> >  rm -rf $RPM_BUILD_ROOT
> > @@ -96,7 +95,9 @@

> >  %files
> >  %defattr(644,root,root,755)
> > -%doc README docs/cc-by-sa-3.0.txt
> > +%{_docdir}/%{name}-%{version}/README.gz
> > +%{_docdir}/%{name}-%{version}/cc-by-sa-3.0.txt.gz
> > +%dir %{_docdir}/%{name}-%{version}
> >  %attr(755,root,root) %{_libdir}/liblensfun.so.*.*.*
> >  %{_datadir}/lensfun


> Please, give us a good reason why you've done this manually.

Because I wanted to package %{_docdir}/%{name}-%{version}/manual and it
is generated in source directory in place which depens on architecture
of builder machine not of built packege. For example locally it is put
always in ./out/posix.x86_64/release/docs/manual, while I build i686
packages.

-- 
  Kacper 


From kornet at gatekeeper.camk.edu.pl  Tue Jun 29 20:19:27 2010
From: kornet at gatekeeper.camk.edu.pl (Kacper Kornet)
Date: Tue, 29 Jun 2010 20:19:27 +0200
Subject: packages: lensfun/lensfun.spec - package api manual - rel. 1
In-Reply-To: <AANLkTinDsFDbthl8UV7XQrS8x_vjDHNKdSIcf9WqAvd6@mail.gmail.com>
References: <packages_lensfun_lensfun.spec.1.4@pld-linux.org>
	<packages_lensfun_lensfun.spec.1.5@pld-linux.org>
	<20100629172855.GA9789@pld-linux.org>
	<AANLkTinDsFDbthl8UV7XQrS8x_vjDHNKdSIcf9WqAvd6@mail.gmail.com>
Message-ID: <20100629181927.GB23642@gatekeeper.camk.edu.pl>

On Tue, Jun 29, 2010 at 07:56:04PM +0200, Bartosz Taudul wrote:
> On Tue, Jun 29, 2010 at 7:28 PM, Przemyslaw Iskra <sparky at pld-linux.org> wrote:
> > Please, give us a good reason why you've done this manually.
> >> +%{_docdir}/%{name}-%{version}/cc-by-sa-3.0.txt.gz
> And why this is even packed.

Because I could not find this license in
/usr/share/doc/common-licenses-1.2

-- 
  Kacper


From z at xatka.net  Tue Jun 29 20:23:01 2010
From: z at xatka.net (=?iso-8859-2?Q?Pawe=B3?= Zuzelski)
Date: Tue, 29 Jun 2010 20:23:01 +0200
Subject: packages: lensfun/lensfun.spec - package api manual - rel. 1
In-Reply-To: <20100629181927.GB23642@gatekeeper.camk.edu.pl>
References: <packages_lensfun_lensfun.spec.1.4@pld-linux.org>
	<packages_lensfun_lensfun.spec.1.5@pld-linux.org>
	<20100629172855.GA9789@pld-linux.org>
	<AANLkTinDsFDbthl8UV7XQrS8x_vjDHNKdSIcf9WqAvd6@mail.gmail.com>
	<20100629181927.GB23642@gatekeeper.camk.edu.pl>
Message-ID: <20100629182301.GA6139@davabel.xatka.net>

On Tue, 29 Jun 2010, Kacper Kornet wrote:

> On Tue, Jun 29, 2010 at 07:56:04PM +0200, Bartosz Taudul wrote:
> > On Tue, Jun 29, 2010 at 7:28 PM, Przemyslaw Iskra <sparky at pld-linux.org> wrote:
> > > Please, give us a good reason why you've done this manually.
> > >> +%{_docdir}/%{name}-%{version}/cc-by-sa-3.0.txt.gz
> > And why this is even packed.
> 
> Because I could not find this license in
> /usr/share/doc/common-licenses-1.2

Why not add it to common licenses?

-- 
Regards,
Pawe?


From radek at pld-linux.org  Wed Jun 30 06:36:55 2010
From: radek at pld-linux.org (=?utf-8?Q?Rados=C5=82aw_Zieli=C5=84ski?=)
Date: Tue, 29 Jun 2010 23:36:55 -0500
Subject: [rc-scripts] LVM + LUKS = fail
Message-ID: <20100630043655.GA3106@bzium>

I have a LVM volume group, created over three logical partitions:

  # fdisk -l /dev/sda | grep LVM
  /dev/sda5            2676        8754    48829536   8e  Linux LVM
  /dev/sda6            8755       14833    48829536   8e  Linux LVM
  /dev/sda7           14834       19457    37142248+  8e  Linux LVM

It contains a single LVM volume:

  # lvscan
    ACTIVE            '/dev/vg/home' [60.00 GiB] inherit

The volume has been formatted for LUKS using cryptsetup, and an ext4
partition has been created:

  # service cryptsetup start
  Starting disk encryption...........................................[ BUSY ]Enter passphrase for /dev/vg/home: 
                                                                     [ DONE ]
  # tail -n1 /etc/crypttab 
  home  /dev/vg/home  none
  # grep mapper.home /etc/fstab
  /dev/mapper/home  /nhome    ext4  defaults    1 2
  # mount /nhome
  # mount | grep nhome
  /dev/mapper/home on /nhome type ext4 (rw)

So far, so good.  But rc-scripts try to start the encryption first, and
scan for the LVM volumes later, so it fails at boot time.

Question: what is the correct way of solving it?

(Current workaround: rc.local, but I'd prefer to get rid of it.)

-- 
radek