From august84 at autocom.pl  Mon May  2 21:52:13 2011
From: august84 at autocom.pl (=?UTF-8?B?QW5kcnplaiBBdWd1c3R5xYRza2k=?=)
Date: Mon, 02 May 2011 21:52:13 +0200
Subject: fglrx
In-Reply-To: <BANLkTimx-heX0+ZFowEjD-y8O9ba4vNYVQ@mail.gmail.com>
References: <BANLkTimx-heX0+ZFowEjD-y8O9ba4vNYVQ@mail.gmail.com>
Message-ID: <4DBF0B6D.5030404@autocom.pl>

W dniu 30.04.2011 18:11, Zsolt Udvari pisze:
> Hi all!
[..]
> +- build fixed; real rel 1 for old xserver
[..]
> And what about newer xserver?
> 
> Zsolt

Revision 1.234  2011/05/02 19:33:40  august84
- up to 11.4
- works with current xorg-xserver-server(videodrv-abi)=10.0

Package in STBR line :)

-- 
Andrzej Augusty?ski


From udvzsolt at gmail.com  Tue May  3 11:37:23 2011
From: udvzsolt at gmail.com (Zsolt Udvari)
Date: Tue, 3 May 2011 11:37:23 +0200
Subject: fglrx
In-Reply-To: <4DBF0B6D.5030404@autocom.pl>
References: <BANLkTimx-heX0+ZFowEjD-y8O9ba4vNYVQ@mail.gmail.com>
	<4DBF0B6D.5030404@autocom.pl>
Message-ID: <BANLkTimWhQrLRHtV=zaMUr0XeKrzk2VSNg@mail.gmail.com>

Oooh, thank you! Works for me well again with newer xorg-xserver-server :)

2011/5/2 Andrzej Augusty?ski <august84 at autocom.pl>:
> W dniu 30.04.2011 18:11, Zsolt Udvari pisze:
>> Hi all!
> [..]
>> +- build fixed; real rel 1 for old xserver
> [..]
>> And what about newer xserver?
>>
>> Zsolt
>
> Revision 1.234 ?2011/05/02 19:33:40 ?august84
> - up to 11.4
> - works with current xorg-xserver-server(videodrv-abi)=10.0
>
> Package in STBR line :)
>
> --
> Andrzej Augusty?ski
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
>


From kornet at camk.edu.pl  Tue May  3 17:07:47 2011
From: kornet at camk.edu.pl (Kacper Kornet)
Date: Tue, 3 May 2011 17:07:47 +0200
Subject: ssh: send/accept GIT_* env vars
Message-ID: <20110503150747.GA32311@camk.edu.pl>

What is the reason that GIT_ variables are copied by ssh to remote
session? I mean the following line in our default /etc/ssh/ssh_config.

AcceptEnv LANG LC_* LANGUAGE TZ GIT_*

I have just discovered that it break at least one feature in gitolite.

-- 
  Kacper


From marcin.rybak at gmail.com  Wed May  4 09:11:37 2011
From: marcin.rybak at gmail.com (Marcin Rybak)
Date: Wed, 4 May 2011 09:11:37 +0200
Subject: ssh: send/accept GIT_* env vars
In-Reply-To: <20110503150747.GA32311@camk.edu.pl>
References: <20110503150747.GA32311@camk.edu.pl>
Message-ID: <BANLkTi=3vH2jX6kH=Qdqojge9_5i4ko_bg@mail.gmail.com>

2011/5/3 Kacper Kornet <kornet at camk.edu.pl>

> What is the reason that GIT_ variables are copied by ssh to remote
> session? I mean the following line in our default /etc/ssh/ssh_config.
>
> AcceptEnv LANG LC_* LANGUAGE TZ GIT_*
>
> I have just discovered that it break at least one feature in gitolite.
>
> you mean SendEnv not AcceptEnv?

why it is problem for you to set it up with ~/.ssh/config ?

---
Marcin Rybak
http://marcinrybak.com


From kornet at camk.edu.pl  Wed May  4 11:22:50 2011
From: kornet at camk.edu.pl (Kacper Kornet)
Date: Wed, 4 May 2011 11:22:50 +0200
Subject: ssh: send/accept GIT_* env vars
In-Reply-To: <BANLkTi=3vH2jX6kH=Qdqojge9_5i4ko_bg@mail.gmail.com>
References: <20110503150747.GA32311@camk.edu.pl>
	<BANLkTi=3vH2jX6kH=Qdqojge9_5i4ko_bg@mail.gmail.com>
Message-ID: <20110504092249.GA4276@camk.edu.pl>

On Wed, May 04, 2011 at 09:11:37AM +0200, Marcin Rybak wrote:
> 2011/5/3 Kacper Kornet <kornet at camk.edu.pl>

> > What is the reason that GIT_ variables are copied by ssh to remote
> > session? I mean the following line in our default /etc/ssh/ssh_config.

> > AcceptEnv LANG LC_* LANGUAGE TZ GIT_*

> > I have just discovered that it break at least one feature in gitolite.

> you mean SendEnv not AcceptEnv?

I mean SendEnv GIT_* in /etc/ssh/ssh_config and AcceptEnv GIT_* in
/etc/ssh/sshd_config

> why it is problem for you to set it up with ~/.ssh/config ?

My question is, do we really need/want to have it in default configuration?

-- 
  Kacper


From blues at pld-linux.org  Wed May  4 11:30:06 2011
From: blues at pld-linux.org (Pawel Golaszewski)
Date: Wed, 4 May 2011 11:30:06 +0200 (CEST)
Subject: ssh: send/accept GIT_* env vars
In-Reply-To: <20110504092249.GA4276@camk.edu.pl>
References: <20110503150747.GA32311@camk.edu.pl>
	<BANLkTi=3vH2jX6kH=Qdqojge9_5i4ko_bg@mail.gmail.com>
	<20110504092249.GA4276@camk.edu.pl>
Message-ID: <alpine.LNX.2.00.1105041129140.9023@fgnss.gnfx.tqn.cy>

On Wed, 4 May 2011, Kacper Kornet wrote:
> > > What is the reason that GIT_ variables are copied by ssh to remote 
> > > session? I mean the following line in our default 
> > > /etc/ssh/ssh_config.
> 
> > > AcceptEnv LANG LC_* LANGUAGE TZ GIT_*
> 
> > > I have just discovered that it break at least one feature in 
> > > gitolite.
> > you mean SendEnv not AcceptEnv?
> I mean SendEnv GIT_* in /etc/ssh/ssh_config and AcceptEnv GIT_* in 
> /etc/ssh/sshd_config
> > why it is problem for you to set it up with ~/.ssh/config ?
> My question is, do we really need/want to have it in default 
> configuration?

no.
it's private glen's config in global stuff...

-- 
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 wolf.pld at gmail.com  Wed May  4 11:32:15 2011
From: wolf.pld at gmail.com (Bartosz Taudul)
Date: Wed, 4 May 2011 11:32:15 +0200
Subject: ssh: send/accept GIT_* env vars
In-Reply-To: <alpine.LNX.2.00.1105041129140.9023@fgnss.gnfx.tqn.cy>
References: <20110503150747.GA32311@camk.edu.pl>
	<BANLkTi=3vH2jX6kH=Qdqojge9_5i4ko_bg@mail.gmail.com>
	<20110504092249.GA4276@camk.edu.pl>
	<alpine.LNX.2.00.1105041129140.9023@fgnss.gnfx.tqn.cy>
Message-ID: <BANLkTi=DDmwYNLbmm=9dCA5VtkL8drOsKQ@mail.gmail.com>

2011/5/4 Pawel Golaszewski <blues at pld-linux.org>:
> it's private glen's config in global stuff...
Shadzik, stop pretending you are blues!

wolf


From arekm at maven.pl  Wed May  4 11:37:16 2011
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Wed, 4 May 2011 11:37:16 +0200
Subject: ssh: send/accept GIT_* env vars
In-Reply-To: <20110503150747.GA32311@camk.edu.pl>
References: <20110503150747.GA32311@camk.edu.pl>
Message-ID: <201105041137.16583.arekm@maven.pl>

On Tuesday 03 of May 2011, Kacper Kornet wrote:
> What is the reason that GIT_ variables are copied by ssh to remote
> session? I mean the following line in our default /etc/ssh/ssh_config.
> 
> AcceptEnv LANG LC_* LANGUAGE TZ GIT_*

To avoid a need to set all that on each remote system.

> I have just discovered that it break at least one feature in gitolite.

And the bug is where?

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


From kornet at camk.edu.pl  Wed May  4 11:47:14 2011
From: kornet at camk.edu.pl (Kacper Kornet)
Date: Wed, 4 May 2011 11:47:14 +0200
Subject: ssh: send/accept GIT_* env vars
In-Reply-To: <201105041137.16583.arekm@maven.pl>
References: <20110503150747.GA32311@camk.edu.pl>
	<201105041137.16583.arekm@maven.pl>
Message-ID: <20110504094714.GB4276@camk.edu.pl>

On Wed, May 04, 2011 at 11:37:16AM +0200, Arkadiusz Miskiewicz wrote:
> On Tuesday 03 of May 2011, Kacper Kornet wrote:
> > What is the reason that GIT_ variables are copied by ssh to remote
> > session? I mean the following line in our default /etc/ssh/ssh_config.

> > AcceptEnv LANG LC_* LANGUAGE TZ GIT_*

> To avoid a need to set all that on each remote system.

> > I have just discovered that it break at least one feature in gitolite.

> And the bug is where?

The creation of wildcard repositories
http://sitaramc.github.com/gitolite/doc/wildcard-repositories.html

does not work. I can patch gitolite for it. But there is a small chance
the patch would be accepted upstream.

-- 
  Kacper


From arekm at maven.pl  Wed May  4 11:51:44 2011
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Wed, 4 May 2011 11:51:44 +0200
Subject: ssh: send/accept GIT_* env vars
In-Reply-To: <20110504094714.GB4276@camk.edu.pl>
References: <20110503150747.GA32311@camk.edu.pl>
	<201105041137.16583.arekm@maven.pl>
	<20110504094714.GB4276@camk.edu.pl>
Message-ID: <201105041151.44634.arekm@maven.pl>

On Wednesday 04 of May 2011, Kacper Kornet wrote:
> On Wed, May 04, 2011 at 11:37:16AM +0200, Arkadiusz Miskiewicz wrote:
> > On Tuesday 03 of May 2011, Kacper Kornet wrote:
> > > What is the reason that GIT_ variables are copied by ssh to remote
> > > session? I mean the following line in our default /etc/ssh/ssh_config.
> > > 
> > > AcceptEnv LANG LC_* LANGUAGE TZ GIT_*
> > 
> > To avoid a need to set all that on each remote system.
> > 
> > > I have just discovered that it break at least one feature in gitolite.
> > 
> > And the bug is where?
> 
> The creation of wildcard repositories
> http://sitaramc.github.com/gitolite/doc/wildcard-repositories.html
> 
> does not work. I can patch gitolite for it. But there is a small chance
> the patch would be accepted upstream.

How so? gitolite doesn't accept patches that fix bugs?

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


From kornet at camk.edu.pl  Wed May  4 12:46:11 2011
From: kornet at camk.edu.pl (Kacper Kornet)
Date: Wed, 4 May 2011 12:46:11 +0200
Subject: ssh: send/accept GIT_* env vars
In-Reply-To: <201105041151.44634.arekm@maven.pl>
References: <20110503150747.GA32311@camk.edu.pl>
	<201105041137.16583.arekm@maven.pl>
	<20110504094714.GB4276@camk.edu.pl>
	<201105041151.44634.arekm@maven.pl>
Message-ID: <20110504104611.GA16956@camk.edu.pl>

On Wed, May 04, 2011 at 11:51:44AM +0200, Arkadiusz Miskiewicz wrote:
> On Wednesday 04 of May 2011, Kacper Kornet wrote:
> > On Wed, May 04, 2011 at 11:37:16AM +0200, Arkadiusz Miskiewicz wrote:
> > > On Tuesday 03 of May 2011, Kacper Kornet wrote:
> > > > What is the reason that GIT_ variables are copied by ssh to remote
> > > > session? I mean the following line in our default /etc/ssh/ssh_config.

> > > > AcceptEnv LANG LC_* LANGUAGE TZ GIT_*

> > > To avoid a need to set all that on each remote system.

> > > > I have just discovered that it break at least one feature in gitolite.

> > > And the bug is where?

> > The creation of wildcard repositories
> > http://sitaramc.github.com/gitolite/doc/wildcard-repositories.html

> > does not work. I can patch gitolite for it. But there is a small chance
> > the patch would be accepted upstream.

> How so? gitolite doesn't accept patches that fix bugs?

See gitolite-mkdir.patch in PLD cvs. I have submitted it to the author
of gitolte, and I have got answer:

> It is my understanding that a standard git install comes with a hooks
> template directory.  You'll have to tell me how and why you ended up
> with an empty hooks template directory.
> 
> As a general rule, I don't accept patches for odd-ball or non-standard
> configurations.  You would not believe some of the things people
> expect gitolite to solve for them :-)

And I have a feeling that PLD ssh configuration would be said to be:
"odd-ball or non-standard".

-- 
  Kacper


From kornet at camk.edu.pl  Wed May  4 15:18:15 2011
From: kornet at camk.edu.pl (Kacper Kornet)
Date: Wed, 4 May 2011 15:18:15 +0200
Subject: ssh: send/accept GIT_* env vars
In-Reply-To: <201105041151.44634.arekm@maven.pl>
References: <20110503150747.GA32311@camk.edu.pl>
	<201105041137.16583.arekm@maven.pl>
	<20110504094714.GB4276@camk.edu.pl>
	<201105041151.44634.arekm@maven.pl>
Message-ID: <20110504131815.GA18641@camk.edu.pl>

On Wed, May 04, 2011 at 11:51:44AM +0200, Arkadiusz Miskiewicz wrote:
> On Wednesday 04 of May 2011, Kacper Kornet wrote:
> > On Wed, May 04, 2011 at 11:37:16AM +0200, Arkadiusz Miskiewicz wrote:
> > > On Tuesday 03 of May 2011, Kacper Kornet wrote:
> > > > What is the reason that GIT_ variables are copied by ssh to remote
> > > > session? I mean the following line in our default /etc/ssh/ssh_config.

> > > > AcceptEnv LANG LC_* LANGUAGE TZ GIT_*

> > > To avoid a need to set all that on each remote system.

> > > > I have just discovered that it break at least one feature in gitolite.

> > > And the bug is where?

> > The creation of wildcard repositories
> > http://sitaramc.github.com/gitolite/doc/wildcard-repositories.html

> > does not work. I can patch gitolite for it. But there is a small chance
> > the patch would be accepted upstream.

> How so? gitolite doesn't accept patches that fix bugs?

So the gitolite author's answet to the patch is:

> You seem to have a very unusual environment.  I'd need to understand
> in more detail why and what this is before I would take this patch.

So if someone (glen?) can give good a good reason why the GIT_*
variables are propagated in PLD it would be great.

-- 
  Kacper


From wiget at pld-linux.org  Wed May  4 15:25:07 2011
From: wiget at pld-linux.org (Artur Frysiak)
Date: Wed, 4 May 2011 15:25:07 +0200
Subject: ssh: send/accept GIT_* env vars
In-Reply-To: <20110504131815.GA18641@camk.edu.pl>
References: <20110503150747.GA32311@camk.edu.pl>
	<201105041137.16583.arekm@maven.pl>
	<20110504094714.GB4276@camk.edu.pl>
	<201105041151.44634.arekm@maven.pl>
	<20110504131815.GA18641@camk.edu.pl>
Message-ID: <BANLkTino+T4TZPseU+NFWmcfQ-FE6BBSvw@mail.gmail.com>

On Wed, May 4, 2011 at 15:18, Kacper Kornet <kornet at camk.edu.pl> wrote:
> On Wed, May 04, 2011 at 11:51:44AM +0200, Arkadiusz Miskiewicz wrote:
>> On Wednesday 04 of May 2011, Kacper Kornet wrote:
>> > On Wed, May 04, 2011 at 11:37:16AM +0200, Arkadiusz Miskiewicz wrote:
>> > > On Tuesday 03 of May 2011, Kacper Kornet wrote:
>> > > > What is the reason that GIT_ variables are copied by ssh to remote
>> > > > session? I mean the following line in our default /etc/ssh/ssh_config.
>
>> > > > AcceptEnv LANG LC_* LANGUAGE TZ GIT_*
>
>> > > To avoid a need to set all that on each remote system.
>
>> > > > I have just discovered that it break at least one feature in gitolite.
>
>> > > And the bug is where?
>
>> > The creation of wildcard repositories
>> > http://sitaramc.github.com/gitolite/doc/wildcard-repositories.html
>
>> > does not work. I can patch gitolite for it. But there is a small chance
>> > the patch would be accepted upstream.
>
>> How so? gitolite doesn't accept patches that fix bugs?
>
> So the gitolite author's answet to the patch is:
>
>> You seem to have a very unusual environment. ?I'd need to understand
>> in more detail why and what this is before I would take this patch.
>
> So if someone (glen?) can give good a good reason why the GIT_*
> variables are propagated in PLD it would be great.

Kacper, can you provide more information? Which GIT_* variable is a
problem for gitolite?
-- 
Artur Frysiak


From kornet at camk.edu.pl  Wed May  4 15:31:45 2011
From: kornet at camk.edu.pl (Kacper Kornet)
Date: Wed, 4 May 2011 15:31:45 +0200
Subject: ssh: send/accept GIT_* env vars
In-Reply-To: <BANLkTino+T4TZPseU+NFWmcfQ-FE6BBSvw@mail.gmail.com>
References: <20110503150747.GA32311@camk.edu.pl>
	<201105041137.16583.arekm@maven.pl>
	<20110504094714.GB4276@camk.edu.pl>
	<201105041151.44634.arekm@maven.pl>
	<20110504131815.GA18641@camk.edu.pl>
	<BANLkTino+T4TZPseU+NFWmcfQ-FE6BBSvw@mail.gmail.com>
Message-ID: <20110504133145.GA18585@camk.edu.pl>

On Wed, May 04, 2011 at 03:25:07PM +0200, Artur Frysiak wrote:
> On Wed, May 4, 2011 at 15:18, Kacper Kornet <kornet at camk.edu.pl> wrote:
> > On Wed, May 04, 2011 at 11:51:44AM +0200, Arkadiusz Miskiewicz wrote:
> >> On Wednesday 04 of May 2011, Kacper Kornet wrote:
> >> > On Wed, May 04, 2011 at 11:37:16AM +0200, Arkadiusz Miskiewicz wrote:
> >> > > On Tuesday 03 of May 2011, Kacper Kornet wrote:
> >> > > > What is the reason that GIT_ variables are copied by ssh to remote
> >> > > > session? I mean the following line in our default /etc/ssh/ssh_config.

> >> > > > AcceptEnv LANG LC_* LANGUAGE TZ GIT_*

> >> > > To avoid a need to set all that on each remote system.

> >> > > > I have just discovered that it break at least one feature in gitolite.

> >> > > And the bug is where?

> >> > The creation of wildcard repositories
> >> > http://sitaramc.github.com/gitolite/doc/wildcard-repositories.html

> >> > does not work. I can patch gitolite for it. But there is a small chance
> >> > the patch would be accepted upstream.

> >> How so? gitolite doesn't accept patches that fix bugs?

> > So the gitolite author's answet to the patch is:

> >> You seem to have a very unusual environment. ?I'd need to understand
> >> in more detail why and what this is before I would take this patch.

> > So if someone (glen?) can give good a good reason why the GIT_*
> > variables are propagated in PLD it would be great.

> Kacper, can you provide more information? Which GIT_* variable is a
> problem for gitolite?

It is GIT_DIR. The problem is that git clone sets GIT_DIR variable.
Therefore remote git init fails during creation of wildcard repository
in this case.
-- 
  Kacper


From wiget at pld-linux.org  Wed May  4 15:51:18 2011
From: wiget at pld-linux.org (Artur Frysiak)
Date: Wed, 4 May 2011 15:51:18 +0200
Subject: ssh: send/accept GIT_* env vars
In-Reply-To: <20110504133145.GA18585@camk.edu.pl>
References: <20110503150747.GA32311@camk.edu.pl>
	<201105041137.16583.arekm@maven.pl>
	<20110504094714.GB4276@camk.edu.pl>
	<201105041151.44634.arekm@maven.pl>
	<20110504131815.GA18641@camk.edu.pl>
	<BANLkTino+T4TZPseU+NFWmcfQ-FE6BBSvw@mail.gmail.com>
	<20110504133145.GA18585@camk.edu.pl>
Message-ID: <BANLkTinE2qqorL06wwq1YxiUhQ7dcjdUNA@mail.gmail.com>

2011/5/4 Kacper Kornet <kornet at camk.edu.pl>:
> On Wed, May 04, 2011 at 03:25:07PM +0200, Artur Frysiak wrote:
>> Kacper, can you provide more information? Which GIT_* variable is a
>> problem for gitolite?
>
> It is GIT_DIR. The problem is that git clone sets GIT_DIR variable.
> Therefore remote git init fails during creation of wildcard repository
> in this case.

I think Send/AcceptEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL instead of GIT_* should be
enough. I see no use case for setting other GIT_*  for "remote" host.

-- 
Artur Frysiak


From marcin.rybak at gmail.com  Wed May  4 15:58:49 2011
From: marcin.rybak at gmail.com (Marcin Rybak)
Date: Wed, 4 May 2011 15:58:49 +0200
Subject: ssh: send/accept GIT_* env vars
In-Reply-To: <BANLkTinE2qqorL06wwq1YxiUhQ7dcjdUNA@mail.gmail.com>
References: <20110503150747.GA32311@camk.edu.pl>
	<201105041137.16583.arekm@maven.pl>
	<20110504094714.GB4276@camk.edu.pl> <201105041151.44634.arekm@maven.pl>
	<20110504131815.GA18641@camk.edu.pl>
	<BANLkTino+T4TZPseU+NFWmcfQ-FE6BBSvw@mail.gmail.com>
	<20110504133145.GA18585@camk.edu.pl>
	<BANLkTinE2qqorL06wwq1YxiUhQ7dcjdUNA@mail.gmail.com>
Message-ID: <BANLkTinVAb7U_JmA5KUg8RT813U+pPUGog@mail.gmail.com>

2011/5/4 Artur Frysiak <wiget at pld-linux.org>

> 2011/5/4 Kacper Kornet <kornet at camk.edu.pl>:
> > On Wed, May 04, 2011 at 03:25:07PM +0200, Artur Frysiak wrote:
> >> Kacper, can you provide more information? Which GIT_* variable is a
> >> problem for gitolite?
> >
> > It is GIT_DIR. The problem is that git clone sets GIT_DIR variable.
> > Therefore remote git init fails during creation of wildcard repository
> > in this case.
>
> I think Send/AcceptEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
> GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL instead of GIT_* should be
> enough. I see no use case for setting other GIT_*  for "remote" host.
>
> +1. but maybe glen as author of this:
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/openssh/openssh-config.patch.diff?r1=1.5;r2=1.6;f=h

has sth to add?
---
Marcin Rybak
http://marcinrybak.com


From kornet at camk.edu.pl  Wed May  4 16:13:27 2011
From: kornet at camk.edu.pl (Kacper Kornet)
Date: Wed, 4 May 2011 16:13:27 +0200
Subject: ssh: send/accept GIT_* env vars
In-Reply-To: <BANLkTinE2qqorL06wwq1YxiUhQ7dcjdUNA@mail.gmail.com>
References: <20110503150747.GA32311@camk.edu.pl>
	<201105041137.16583.arekm@maven.pl>
	<20110504094714.GB4276@camk.edu.pl>
	<201105041151.44634.arekm@maven.pl>
	<20110504131815.GA18641@camk.edu.pl>
	<BANLkTino+T4TZPseU+NFWmcfQ-FE6BBSvw@mail.gmail.com>
	<20110504133145.GA18585@camk.edu.pl>
	<BANLkTinE2qqorL06wwq1YxiUhQ7dcjdUNA@mail.gmail.com>
Message-ID: <20110504141326.GD18585@camk.edu.pl>

On Wed, May 04, 2011 at 03:51:18PM +0200, Artur Frysiak wrote:
> 2011/5/4 Kacper Kornet <kornet at camk.edu.pl>:
> > On Wed, May 04, 2011 at 03:25:07PM +0200, Artur Frysiak wrote:
> >> Kacper, can you provide more information? Which GIT_* variable is a
> >> problem for gitolite?

> > It is GIT_DIR. The problem is that git clone sets GIT_DIR variable.
> > Therefore remote git init fails during creation of wildcard repository
> > in this case.

> I think Send/AcceptEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
> GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL instead of GIT_* should be
> enough. I see no use case for setting other GIT_*  for "remote" host.

I'm not sure even about these variables. If I have some configuration in
remote .gitconfig, I would be surprised that it is overwritten by my
local environment.

-- 
  Kacper


From glen at pld-linux.org  Thu May  5 14:26:46 2011
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Thu, 05 May 2011 15:26:46 +0300
Subject: ssh: send/accept GIT_* env vars
In-Reply-To: <20110504131815.GA18641@camk.edu.pl>
References: <20110503150747.GA32311@camk.edu.pl>	<201105041137.16583.arekm@maven.pl>	<20110504094714.GB4276@camk.edu.pl>	<201105041151.44634.arekm@maven.pl>
	<20110504131815.GA18641@camk.edu.pl>
Message-ID: <4DC29786.6070809@pld-linux.org>

On 04.05.2011 16:18, Kacper Kornet wrote:
>
> So if someone (glen?) can give good a good reason why the GIT_*
> variables are propagated in PLD it would be great.
>

arekm already answered:

>  To avoid a need to set all that on each remote system.


On 04.05.2011 16:51, Artur Frysiak wrote:
> I think Send/AcceptEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
> GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL instead of GIT_* should be
> enough. I see no use case for setting other GIT_*  for "remote" host.
i'm fine with that (setting up author/commiter id was the goal)
even perhaps: GIT_AUTHOR_* GIT_COMMITTER_* to support future extensions

-- 
glen



From wrobell at pld-linux.org  Thu May  5 16:53:08 2011
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Thu, 5 May 2011 15:53:08 +0100
Subject: ssh: send/accept GIT_* env vars
In-Reply-To: <4DC29786.6070809@pld-linux.org>
References: <20110503150747.GA32311@camk.edu.pl>
	<201105041137.16583.arekm@maven.pl>
	<20110504094714.GB4276@camk.edu.pl>
	<201105041151.44634.arekm@maven.pl>
	<20110504131815.GA18641@camk.edu.pl>
	<4DC29786.6070809@pld-linux.org>
Message-ID: <20110505145308.GA16714@oc2731761535.ibm.com>

On Thu, May 05, 2011 at 03:26:46PM +0300, Elan Ruusam?e wrote:
> On 04.05.2011 16:18, Kacper Kornet wrote:
> >
> >So if someone (glen?) can give good a good reason why the GIT_*
> >variables are propagated in PLD it would be great.
> >
> 
> arekm already answered:
> 
> > To avoid a need to set all that on each remote system.
> 
> 
> On 04.05.2011 16:51, Artur Frysiak wrote:
> >I think Send/AcceptEnv GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL
> >GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL instead of GIT_* should be
> >enough. I see no use case for setting other GIT_*  for "remote" host.
> i'm fine with that (setting up author/commiter id was the goal)
> even perhaps: GIT_AUTHOR_* GIT_COMMITTER_* to support future extensions

so what's next? svn, qmail? i mean... why it is distro wide
and not in your local configuration?

what about ssh'ing to different (i.e. corporate) environment?

regards,

w



From gotar at polanet.pl  Thu May  5 18:08:32 2011
From: gotar at polanet.pl (Tomasz Pala)
Date: Thu, 5 May 2011 18:08:32 +0200
Subject: ssh: send/accept GIT_* env vars
In-Reply-To: <20110505145308.GA16714@oc2731761535.ibm.com>
References: <20110503150747.GA32311@camk.edu.pl>
	<201105041137.16583.arekm@maven.pl>
	<20110504094714.GB4276@camk.edu.pl>
	<201105041151.44634.arekm@maven.pl>
	<20110504131815.GA18641@camk.edu.pl>
	<4DC29786.6070809@pld-linux.org>
	<20110505145308.GA16714@oc2731761535.ibm.com>
Message-ID: <20110505160831.GA15622@polanet.pl>

On Thu, May 05, 2011 at 15:53:08 +0100, Artur Wroblewski wrote:

>> i'm fine with that (setting up author/commiter id was the goal)
>> even perhaps: GIT_AUTHOR_* GIT_COMMITTER_* to support future extensions
> 
> so what's next? svn, qmail? i mean... why it is distro wide
> and not in your local configuration?

+1

I'd like to have the same MAILCHECK RPS1 SAVEHIST WORDCHARS ZDOTDIR
HISTSIZE HISTFILESIZE ETC_DIR HOME_ETC GREP_OPTIONS LESS LESSOPEN and
maybe a bunch of other app-specific environment, but this is my personal
setting - just like the GIT_ stuff. Either we add everything that makes
a sense, or remove everything not session/terminal-related.

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


From udvzsolt at gmail.com  Sat May 14 07:56:12 2011
From: udvzsolt at gmail.com (Zsolt Udvari)
Date: Sat, 14 May 2011 07:56:12 +0200
Subject: Fwd: epoch bumping
In-Reply-To: <BANLkTimbo_GeD_EL+s+T2BsF2W+_HoBF2g@mail.gmail.com>
References: <4DCCEF27.5040108@pld-linux.org>
	<BANLkTimbo_GeD_EL+s+T2BsF2W+_HoBF2g@mail.gmail.com>
Message-ID: <BANLkTinsZzdS3zv09H+h_fv_-5RFjfiZvA@mail.gmail.com>

Maybe it failed to send. I send again. Sorry for duplicity.


---------- Forwarded message ----------
From: Zsolt Udvari <udvzsolt at gmail.com>
Date: 2011/5/13
Subject: Re: epoch bumping
To: Elan Ruusam?e <glen at pld-linux.org>
M?solatot kap: pld-devel-en at pld-linux.org, uzsolt at pld-linux.org


I've found bug report:
http://sourceforge.net/tracker/?func=detail&aid=3300722&group_id=130831&atid=719134
and some other, but I think it will fix in next release, this takes
only some days (see changelog), so imho make patches is unnecessary
work.
It was my mistake, I used test my packages before send request, but
now not, sorry.

Zsolt

2011/5/13 Elan Ruusam?e <glen at pld-linux.org>:
> 08:54:26 +CIA-10> uzsolt * packages/taskcoach/taskcoach.spec:
> 08:54:26 +CIA-10> - back to 1.2.16 (1.2.17 segfaults)
> 08:54:26 +CIA-10> - epoch 1
>
> is it that so neccessary to downgrade and bump epoch? like other options are
> out of question?
> like fix the code not to segfault, search bugtracker, create reverse patch
>
> and the package it's not that essential to distro to function...
>
> and besides 1.2.17 was not even moved to main from test area (7 days between
> two version commits),
> should had sufficent to just remove newly built package
>
> --
> glen
>
>


From arekm at maven.pl  Tue May 17 08:41:33 2011
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Tue, 17 May 2011 08:41:33 +0200
Subject: Th, libmysqlclient rebuild help needed
Message-ID: <201105170841.33706.arekm@maven.pl>


Hello,

Current ready cannot be moved to main due to missing packages, linked with 
libmysqlclient mainly. 

So I'm looking for a people that could help fixing and rebuilding packages 
from this list:
http://ep09.pld-linux.org/~pldth/main-ready-test.txt
(look for libmysqlclient there)

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


From marcin.rybak at gmail.com  Tue May 17 16:14:01 2011
From: marcin.rybak at gmail.com (Marcin Rybak)
Date: Tue, 17 May 2011 16:14:01 +0200
Subject: Future direction of official PLD website (Was: A couple questions
	about the website)
In-Reply-To: <AANLkTinU1HzUt6iTnf=a3ACFrjQGMJTAtCBhhrtEheOS@mail.gmail.com>
References: <AANLkTim=EkyytgOYVNmrv56-OScZ_Pyc3Jb=nd0RnCzk@mail.gmail.com>
	<AANLkTinU1HzUt6iTnf=a3ACFrjQGMJTAtCBhhrtEheOS@mail.gmail.com>
Message-ID: <BANLkTimpwwpk37u81AZJP22x=hUzSpgb7g@mail.gmail.com>

2011/2/3 Marcin Rybak <marcin.rybak at gmail.com>

> 2010/11/20 Caleb Maclennan <caleb at pld-linux.org>
>
>>  2010/11/11 Elan Ruusam?e <glen at pld-linux.org>:
>>  > i'd finish the data migration and replace the moinmoun install
>>
>
> just to continue the idea of migration, someone done a nice migration
> script
> http://www.dokuwiki.org/tips:moinmoin2doku
>
>
are we going to do sth with this? PLD website is outdated... and I strongly
agree with people saying that this distro died, if sb look at our site - may
really think so.

I think that we should add as an example part of our build logs and
security.pld-linux.org as a widget or sth, just to make it more web 2.0 :)
---
Marcin Rybak
http://marcinrybak.com


From wrobell at pld-linux.org  Thu May 19 18:34:18 2011
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Thu, 19 May 2011 17:34:18 +0100
Subject: python3.2+ compiled files
In-Reply-To: <20110402181118.GA22787@stranger.qboosh.pl>
References: <20110402181118.GA22787@stranger.qboosh.pl>
Message-ID: <BANLkTiniGJizGxC_sjyww4ZW5KyUHY_=+g@mail.gmail.com>

On Sat, Apr 2, 2011 at 7:11 PM, Jakub Bogusz <qboosh at pld-linux.org> wrote:
[...]
> So we have to decide how to package python distribution (and possibly
> all python3 modules, if distutils use __pycache__ too) - there are
> two solutions:
>
> - package all modules in source form together with __pycache__
> ?subdirectories
>
> - stick to "old way" - manually py_comp/py_ocomp all python files,
> ?package *.py[co] without using __pycache__ subdirectories

Looking at PEP 3147 and looking around on the net it seems that
some people should be happy that sourceless module distribution
is still supported at all [1][2]. The Python devs even do not care so much
about missing pyc/pyo files in __pycache__ dir [3].

It seems that we need to follow the crowd and include .py files as default. :/

Regards,

w

[1] http://www.python.org/dev/peps/pep-3147/#case-4-legacy-pyc-files-and-source-less-imports
[2] http://sayspy.blogspot.com/2010/05/maintaining-backwards-compatibility.html
[3] http://mail.python.org/pipermail/python-dev/2011-February/108110.html


From wrobell at pld-linux.org  Thu May 19 19:08:31 2011
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Thu, 19 May 2011 18:08:31 +0100
Subject: python3.2+ compiled files
In-Reply-To: <BANLkTiniGJizGxC_sjyww4ZW5KyUHY_=+g@mail.gmail.com>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<BANLkTiniGJizGxC_sjyww4ZW5KyUHY_=+g@mail.gmail.com>
Message-ID: <BANLkTin_BbHcXHasE6RTCM0STKUgiqswdA@mail.gmail.com>

There is also

   http://web.archiveorange.com/archive/v/jA6s9GD0sh2vKRhR2zat

to study.

We could also think about zipping of the modules later...

Anyway, if no one objects then I will finish packaging of Python 3.2
during the weekend using source files and __pycache__.

Is that OK?

Regards,

w


From qboosh at pld-linux.org  Thu May 19 19:44:00 2011
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 19 May 2011 19:44:00 +0200
Subject: python3.2+ compiled files
In-Reply-To: <BANLkTin_BbHcXHasE6RTCM0STKUgiqswdA@mail.gmail.com>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<BANLkTiniGJizGxC_sjyww4ZW5KyUHY_=+g@mail.gmail.com>
	<BANLkTin_BbHcXHasE6RTCM0STKUgiqswdA@mail.gmail.com>
Message-ID: <20110519174400.GB13359@stranger.qboosh.pl>

On Thu, May 19, 2011 at 06:08:31PM +0100, Artur Wroblewski wrote:
> There is also
> 
>    http://web.archiveorange.com/archive/v/jA6s9GD0sh2vKRhR2zat
> 
> to study.
> 
> We could also think about zipping of the modules later...
> 
> Anyway, if no one objects then I will finish packaging of Python 3.2
> during the weekend using source files and __pycache__.
> 
> Is that OK?

IMO we must leave with it unless upstream changes something again...


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


From jajcus at jajcus.net  Fri May 20 12:34:44 2011
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Fri, 20 May 2011 12:34:44 +0200
Subject: python3.2+ compiled files
In-Reply-To: <BANLkTin_BbHcXHasE6RTCM0STKUgiqswdA@mail.gmail.com>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<BANLkTiniGJizGxC_sjyww4ZW5KyUHY_=+g@mail.gmail.com>
	<BANLkTin_BbHcXHasE6RTCM0STKUgiqswdA@mail.gmail.com>
Message-ID: <20110520103444.GA5790@jajo.eggsoft>

On Thu, May 19, 2011 at 06:08:31PM +0100, Artur Wroblewski wrote:
> There is also
> 
>    http://web.archiveorange.com/archive/v/jA6s9GD0sh2vKRhR2zat
> 
> to study.
> 
> We could also think about zipping of the modules later...
> 
> Anyway, if no one objects then I will finish packaging of Python 3.2
> during the weekend using source files and __pycache__.
> 
> Is that OK?

I guess this is a must, anyway?

The problem is that will probably require fixing lots of python-*.spec
files which have:

...../*.py[co]

in their files. That will have to be changed to *.py and __pycache__
added. Maybe we should have some automation for packaging (or not
packaging) __pycache__ and its contents? So it doesn't have to be listed
explicitly for every python package. I am thinking about something like
%find_lang ? e.g. %find_pybytcode, or '%py_listmodules modul1e module2'

Greets,
        Jacek


From glen at pld-linux.org  Fri May 20 15:00:33 2011
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Fri, 20 May 2011 16:00:33 +0300
Subject: processes ulimit weirdness
Message-ID: <4DD665F1.3000105@pld-linux.org>

such weirdness, in th x86_64 host, i686 th guest:
sudo-1.7.6-1.i686
pam-1.1.3-3.i686
bash-4.2-2.i686

# bash -c 'ulimit -u'
unlimited

# sudo -u glen bash -c 'ulimit -u'
unlimited

# sudo -u glen sudo bash -c 'ulimit -u'
0
#

on same host, th-x86_64 guest:
sudo-1.7.6-1.x86_64
pam-1.1.3-3.x86_64
bash-4.2-1.x86_64

# bash -c 'ulimit -u'
unlimited
# sudo -u glen bash -c 'ulimit -u'
unlimited
# sudo -u glen sudo bash -c 'ulimit -u'
unlimited
#


on same host, ac-x86_64 guest:
sudo-1.7.3-1.amd64
pam-0.80.1-19.amd64
bash-3.2.48-1.amd64
# bash -c 'ulimit -u'
unlimited

# sudo -u glen bash -c 'ulimit -u'
unlimited

# sudo -u glen sudo bash -c 'ulimit -u'
unlimited
#

the same with ksh, pam limits config is empty (everything commented out)

so far seems problem with 32bit guests on x86_64 hosts, and sudo 1.7.6
anyone else experienced this, or can check their status now?


-- 
glen



From qboosh at pld-linux.org  Fri May 20 16:31:23 2011
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Fri, 20 May 2011 16:31:23 +0200
Subject: python3.2+ compiled files
In-Reply-To: <20110520103444.GA5790@jajo.eggsoft>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<BANLkTiniGJizGxC_sjyww4ZW5KyUHY_=+g@mail.gmail.com>
	<BANLkTin_BbHcXHasE6RTCM0STKUgiqswdA@mail.gmail.com>
	<20110520103444.GA5790@jajo.eggsoft>
Message-ID: <20110520143123.GC13359@stranger.qboosh.pl>

On Fri, May 20, 2011 at 12:34:44PM +0200, Jacek Konieczny wrote:
> On Thu, May 19, 2011 at 06:08:31PM +0100, Artur Wroblewski wrote:
> > There is also
> > 
> >    http://web.archiveorange.com/archive/v/jA6s9GD0sh2vKRhR2zat
> > 
> > to study.
> > 
> > We could also think about zipping of the modules later...
> > 
> > Anyway, if no one objects then I will finish packaging of Python 3.2
> > during the weekend using source files and __pycache__.
> > 
> > Is that OK?
> 
> I guess this is a must, anyway...
> 
> The problem is that will probably require fixing lots of python-*.spec
> files which have:
> 
> ...../*.py[co]
> 
> in their files. That will have to be changed to *.py and __pycache__
> added. Maybe we should have some automation for packaging (or not
> packaging) __pycache__ and its contents? So it doesn't have to be listed
> explicitly for every python package. I am thinking about something like
> %find_lang - e.g. %find_pybytcode, or '%py_listmodules modul1e module2'

Actually it refers only to python3-* packages, not all python-*.spec.


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


From wrobell at pld-linux.org  Sat May 21 13:22:04 2011
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Sat, 21 May 2011 12:22:04 +0100
Subject: python3.2+ compiled files
In-Reply-To: <20110520103444.GA5790@jajo.eggsoft>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<BANLkTiniGJizGxC_sjyww4ZW5KyUHY_=+g@mail.gmail.com>
	<BANLkTin_BbHcXHasE6RTCM0STKUgiqswdA@mail.gmail.com>
	<20110520103444.GA5790@jajo.eggsoft>
Message-ID: <BANLkTikvwLHLS7bKW6ttemeBy5gzKGHMfA@mail.gmail.com>

On Fri, May 20, 2011 at 11:34 AM, Jacek Konieczny <jajcus at jajcus.net> wrote:
> Maybe we should have some automation for packaging (or not
> packaging) __pycache__ and its contents? So it doesn't have to be listed
> explicitly for every python package. I am thinking about something like
> %find_lang ? e.g. %find_pybytcode, or '%py_listmodules modul1e module2'

%find_pymod mod1 mod2... ?

it has to find egg files (on the same level as mod1 and mod2 exist), *.py,
*.so and directories (it will get __pycache__ then too).

Do I miss anything?

regards,

w


From jajcus at jajcus.net  Sat May 21 14:12:51 2011
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Sat, 21 May 2011 14:12:51 +0200
Subject: python3.2+ compiled files
In-Reply-To: <BANLkTikvwLHLS7bKW6ttemeBy5gzKGHMfA@mail.gmail.com>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<BANLkTiniGJizGxC_sjyww4ZW5KyUHY_=+g@mail.gmail.com>
	<BANLkTin_BbHcXHasE6RTCM0STKUgiqswdA@mail.gmail.com>
	<20110520103444.GA5790@jajo.eggsoft>
	<BANLkTikvwLHLS7bKW6ttemeBy5gzKGHMfA@mail.gmail.com>
Message-ID: <20110521121251.GA4106@lolek.nigdzie>

On Sat, May 21, 2011 at 12:22:04PM +0100, Artur Wroblewski wrote:
> On Fri, May 20, 2011 at 11:34 AM, Jacek Konieczny <jajcus at jajcus.net> wrote:
> > Maybe we should have some automation for packaging (or not
> > packaging) __pycache__ and its contents? So it doesn't have to be listed
> > explicitly for every python package. I am thinking about something like
> > %find_lang ? e.g. %find_pybytcode, or '%py_listmodules modul1e module2'
> 
> %find_pymod mod1 mod2... ?
> 
> it has to find egg files (on the same level as mod1 and mod2 exist), *.py,
> *.so and directories (it will get __pycache__ then too).
> 
> Do I miss anything?

I don't think we want any directory found packaged. All python
modules/packages should be explicitely listed and only files
belonging to them for sure should be included. Only this way we can
notice things that should not go to %py_sitedir or new modules/packages
that we may want to package separately.

There is a problem with egg-info files then - they may not match exactly 
the python module/package name.

Greets,
        Jacek


From wrobell at pld-linux.org  Sun May 22 04:13:21 2011
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Sun, 22 May 2011 03:13:21 +0100
Subject: python3.2+ compiled files
In-Reply-To: <BANLkTin_BbHcXHasE6RTCM0STKUgiqswdA@mail.gmail.com>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<BANLkTiniGJizGxC_sjyww4ZW5KyUHY_=+g@mail.gmail.com>
	<BANLkTin_BbHcXHasE6RTCM0STKUgiqswdA@mail.gmail.com>
Message-ID: <BANLkTi=JWau08b6uj3A9ONGsprYXRZic-w@mail.gmail.com>

On Thu, May 19, 2011 at 6:08 PM, Artur Wroblewski <wrobell at pld-linux.org> wrote:
[...]

> Anyway, if no one objects then I will finish packaging of Python 3.2
> during the weekend using source files and __pycache__.

Done.

I have upgraded few packages, too. Some of them are not done
in nice way (i.e. python3 vs. python2), but that has to wait few days,
sorry.

Best regards,

w


From wrobell at pld-linux.org  Sun May 22 04:21:27 2011
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Sun, 22 May 2011 03:21:27 +0100
Subject: python3.2+ compiled files
In-Reply-To: <20110521121251.GA4106@lolek.nigdzie>
References: <20110402181118.GA22787@stranger.qboosh.pl>
	<BANLkTiniGJizGxC_sjyww4ZW5KyUHY_=+g@mail.gmail.com>
	<BANLkTin_BbHcXHasE6RTCM0STKUgiqswdA@mail.gmail.com>
	<20110520103444.GA5790@jajo.eggsoft>
	<BANLkTikvwLHLS7bKW6ttemeBy5gzKGHMfA@mail.gmail.com>
	<20110521121251.GA4106@lolek.nigdzie>
Message-ID: <BANLkTikGdxZQmq7b2Fe66PviQutwVabDcg@mail.gmail.com>

On Sat, May 21, 2011 at 1:12 PM, Jacek Konieczny <jajcus at jajcus.net> wrote:
> On Sat, May 21, 2011 at 12:22:04PM +0100, Artur Wroblewski wrote:
>> On Fri, May 20, 2011 at 11:34 AM, Jacek Konieczny <jajcus at jajcus.net> wrote:
>> > Maybe we should have some automation for packaging (or not
>> > packaging) __pycache__ and its contents? So it doesn't have to be listed
>> > explicitly for every python package. I am thinking about something like
>> > %find_lang ? e.g. %find_pybytcode, or '%py_listmodules modul1e module2'
>>
>> %find_pymod mod1 mod2... ?
>>
>> it has to find egg files (on the same level as mod1 and mod2 exist), *.py,
>> *.so and directories (it will get __pycache__ then too).
>>
>> Do I miss anything?
>
> I don't think we want any directory found packaged. All python
> modules/packages should be explicitely listed and only files
> belonging to them for sure should be included. Only this way we can
> notice things that should not go to %py_sitedir or new modules/packages
> that we may want to package separately.

IMO

    %find_pymod mod1 mod2

should include (by listing each file, wildcards below
just for my convenience)

%dir %{py_sitedir}/mod1
%dir %{py_sitedir}/mod1/submod1
%{py_sitedir}/mod1/*.py
%{py_sitedir}/mod1/__pycache__
%attr(...) %{py_sitedir}/mod1/*.so

%{py_sitedir}/mod1/submod1/*.py
%{py_sitedir}/mod1/submod1/__pycache__
%attr(...) %{py_sitedir}/mod1/submod1/*.so

but would skip

%{py_sitedir}/mod1/submod1/*.txt
%{py_sitedir}/mod1/submod1/test{,s}
%{py_sitedir}/mod1/adir   # this directory contains no __init__.py
%{py_sitedir}/mod1/adir/somedata.file.txt

> There is a problem with egg-info files then - they may not match exactly
> the python module/package name.

If I reckon well, we never skipped any egg files.

Regards,

w


From glen at delfi.ee  Sun May 22 14:27:58 2011
From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=C3=A4e?=)
Date: Sun, 22 May 2011 15:27:58 +0300
Subject: processes ulimit weirdness
In-Reply-To: <4DD665F1.3000105@pld-linux.org>
References: <4DD665F1.3000105@pld-linux.org>
Message-ID: <6b15d3970f82ade75b9c8c14596fdcb5@delfi.ee>

 On Fri, 20 May 2011 16:00:33 +0300, Elan Ruusam?e wrote:
> such weirdness, in th x86_64 host, i686 th guest:
> sudo-1.7.6-1.i686
> pam-1.1.3-3.i686
> bash-4.2-2.i686
>
> # bash -c 'ulimit -u'
> unlimited
>
> # sudo -u glen bash -c 'ulimit -u'
> unlimited
>
> # sudo -u glen sudo bash -c 'ulimit -u'
> 0
> #

 so far seems downgrade of sudo helped, one from th-archives
 sudo-1.7.4p6-1.i686 = OK
 sudo-1.7.5-1.i686 = FAIL
 sudo-1.7.6-1.i686 = FAIL


 so this is expected one i call OK:
 # q sudo pam bash
 sudo-1.7.4p6-1.i686
 pam-1.1.3-3.i686
 bash-4.2-2.i686

 # bash -c 'ulimit -u'
 unlimited

 # sudo -u glen bash -c 'ulimit -u'
 unlimited

 # sudo -u glen sudo bash -c 'ulimit -u'
 unlimited

-- 
 glen


From glen at pld-linux.org  Mon May 23 10:53:55 2011
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Mon, 23 May 2011 11:53:55 +0300
Subject: packages: gocr/gocr.spec - upgraded to 0.49
In-Reply-To: <packages_gocr_gocr.spec.1.47@pld-linux.org>
References: <packages_gocr_gocr.spec.1.46@pld-linux.org>
	<packages_gocr_gocr.spec.1.47@pld-linux.org>
Message-ID: <4DDA20A3.7040303@pld-linux.org>

On 14.05.2011 02:16, gotar wrote:
> Author: gotar                        Date: Fri May 13 23:16:30 2011 GMT
> Module: packages                      Tag: HEAD
> ---- Log message:
> - upgraded to 0.49
>
> ---- Files affected:
> packages/gocr:
>     gocr.spec (1.46 ->  1.47)
>
> ---- Diffs:
>
> ================================================================
> Index: packages/gocr/gocr.spec
> diff -u packages/gocr/gocr.spec:1.46 packages/gocr/gocr.spec:1.47
> --- packages/gocr/gocr.spec:1.46	Sun Nov 15 14:47:06 2009
> +++ packages/gocr/gocr.spec	Sat May 14 01:16:25 2011
> @@ -2,12 +2,12 @@
>   Summary:	GNU OCR
>   Summary(pl.UTF-8):	Program GNU do OCR
>   Name:		gocr
> -Version:	0.48
> +Version:	0.49
>   Release:	1
>   License:	GPL v2+
>   Group:		Applications/Graphics
> -Source0:	http://dl.sourceforge.net/jocr/%{name}-%{version}.tar.gz
> -# Source0-md5:	9882ba9a93fcb18ab704a10da80c228c
> +Source0:	http://www-e.uni-magdeburg.de/jschulen/ocr/%{name}-%{version}.tar.gz
> +# Source0-md5:	4e527bc4bdd97c2be15fdd818857507f
>   Source1:	%{name}.desktop
>   Source2:	%{name}.png
>   Patch0:		%{name}-lib64.patch
> @@ -38,7 +38,7 @@
>   Summary:	Tcl/Tk frontend for gocr
>   Summary(pl.UTF-8):	Frontend Tcl/Tk do gocr
>   Group:		X11/Applications/Graphics
> -Requires:	%{name} = %{version}-%{release}
> +Requires:	%{name}

we have kind of policy that internal deps should be strict.

why you disabled it (without any changelog or comment to describe reasons)


-- 
glen



From wolf.pld at gmail.com  Mon May 23 11:54:49 2011
From: wolf.pld at gmail.com (Bartosz Taudul)
Date: Mon, 23 May 2011 11:54:49 +0200
Subject: packages: gocr/gocr.spec - upgraded to 0.49
In-Reply-To: <4DDA20A3.7040303@pld-linux.org>
References: <packages_gocr_gocr.spec.1.46@pld-linux.org>
	<packages_gocr_gocr.spec.1.47@pld-linux.org>
	<4DDA20A3.7040303@pld-linux.org>
Message-ID: <BANLkTi=8tEk3zaDtPxdGsuhJmm4ap1bANA@mail.gmail.com>

2011/5/23 Elan Ruusam?e <glen at pld-linux.org>:
> we have kind of policy that internal deps should be strict.
We also have policy that only tested changes go into CVS. Do you want
to talk about what you did with legacy nvidia drivers yesterday?

wolf


From gotar at pld-linux.org  Mon May 23 12:01:46 2011
From: gotar at pld-linux.org (gotar)
Date: Mon, 23 May 2011 12:01:46 +0200
Subject: packages: gocr/gocr.spec - upgraded to 0.49
In-Reply-To: <4DDA20A3.7040303@pld-linux.org>
References: <packages_gocr_gocr.spec.1.46@pld-linux.org>
	<packages_gocr_gocr.spec.1.47@pld-linux.org>
	<4DDA20A3.7040303@pld-linux.org>
Message-ID: <20110523100146.GA10043@polanet.pl>

On Mon, May 23, 2011 at 11:53:55 +0300, Elan Ruusam?e wrote:

> we have kind of policy that internal deps should be strict.

Which applies to libraries, not applications (which could be build from
different specs as well).

> why you disabled it (without any changelog or comment to describe reasons)

Because it was simply dumb (probably made by copy&paste).

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


From glen at pld-linux.org  Mon May 23 13:00:28 2011
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Mon, 23 May 2011 14:00:28 +0300
Subject: packages: gocr/gocr.spec - upgraded to 0.49
In-Reply-To: <BANLkTi=8tEk3zaDtPxdGsuhJmm4ap1bANA@mail.gmail.com>
References: <packages_gocr_gocr.spec.1.46@pld-linux.org>	<packages_gocr_gocr.spec.1.47@pld-linux.org>	<4DDA20A3.7040303@pld-linux.org>
	<BANLkTi=8tEk3zaDtPxdGsuhJmm4ap1bANA@mail.gmail.com>
Message-ID: <4DDA3E4C.10502@pld-linux.org>

On 23.05.2011 12:54, Bartosz Taudul wrote:
> 2011/5/23 Elan Ruusam?e<glen at pld-linux.org>:
>> we have kind of policy that internal deps should be strict.
> We also have policy that only tested changes go into CVS. Do you want
> to talk about what you did with legacy nvidia drivers yesterday?

and what's the problem there?

i should had omitted "not tested" and you then didn't even notice?

none of the legacy drivers are in th because 1.10 xorg in th, so any 
commit is better than before

-- 
glen



From wolf.pld at gmail.com  Mon May 23 13:05:48 2011
From: wolf.pld at gmail.com (Bartosz Taudul)
Date: Mon, 23 May 2011 13:05:48 +0200
Subject: packages: gocr/gocr.spec - upgraded to 0.49
In-Reply-To: <4DDA3E4C.10502@pld-linux.org>
References: <packages_gocr_gocr.spec.1.46@pld-linux.org>
	<packages_gocr_gocr.spec.1.47@pld-linux.org>
	<4DDA20A3.7040303@pld-linux.org>
	<BANLkTi=8tEk3zaDtPxdGsuhJmm4ap1bANA@mail.gmail.com>
	<4DDA3E4C.10502@pld-linux.org>
Message-ID: <BANLkTikjZEiKBnQUJFRtC7_uVFO-2Zd=wA@mail.gmail.com>

2011/5/23 Elan Ruusam?e <glen at pld-linux.org>:
> and what's the problem there?
No problem at all...

> none of the legacy drivers are in th because 1.10 xorg in th, so any commit
> is better than before
By using that logic I may break any package and say that the broken
version is not on the ftp, so where's the problem?

wolf


From glen at pld-linux.org  Mon May 23 13:08:31 2011
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Mon, 23 May 2011 14:08:31 +0300
Subject: packages: gocr/gocr.spec - upgraded to 0.49
In-Reply-To: <BANLkTikjZEiKBnQUJFRtC7_uVFO-2Zd=wA@mail.gmail.com>
References: <packages_gocr_gocr.spec.1.46@pld-linux.org>	<packages_gocr_gocr.spec.1.47@pld-linux.org>	<4DDA20A3.7040303@pld-linux.org>	<BANLkTi=8tEk3zaDtPxdGsuhJmm4ap1bANA@mail.gmail.com>	<4DDA3E4C.10502@pld-linux.org>
	<BANLkTikjZEiKBnQUJFRtC7_uVFO-2Zd=wA@mail.gmail.com>
Message-ID: <4DDA402F.5070400@pld-linux.org>

On 23.05.2011 14:05, Bartosz Taudul wrote:
> 2011/5/23 Elan Ruusam?e<glen at pld-linux.org>:
>> and what's the problem there?
> No problem at all...
>
>> none of the legacy drivers are in th because 1.10 xorg in th, so any commit
>> is better than before
> By using that logic I may break any package and say that the broken
> version is not on the ftp, so where's the problem?

you said there's problem. and next you said there is none

on HEAD was not-working-driver,
i commited driver that works according to driver's changelog.

-- 
glen



From marcin.rybak at gmail.com  Mon May 23 18:00:17 2011
From: marcin.rybak at gmail.com (Marcin Rybak)
Date: Mon, 23 May 2011 18:00:17 +0200
Subject: packages (V5-DEVEL): rsyslog/rsyslog.spec - up to 5.8.1
In-Reply-To: <packages_rsyslog_rsyslog.spec.1.41.4.9@pld-linux.org>
References: <packages_rsyslog_rsyslog.spec.1.41.4.8@pld-linux.org>
	<packages_rsyslog_rsyslog.spec.1.41.4.9@pld-linux.org>
Message-ID: <BANLkTimqEVaDyuTe=1VzDj44S6BoQX5BSA@mail.gmail.com>

2011/5/23 marti <marti at pld-linux.org>

> Author: marti                        Date: Mon May 23 15:23:28 2011 GMT
> Module: packages                      Tag: V5-DEVEL
> ---- Log message:
> - up to 5.8.1
>

Are there any circumstances that this does not go to HEAD?
---
Marcin Rybak
http://marcinrybak.com


From lisu87 at gmail.com  Mon May 23 19:52:07 2011
From: lisu87 at gmail.com (=?UTF-8?B?TWljaGHFgiBMaXNvd3NraQ==?=)
Date: Mon, 23 May 2011 19:52:07 +0200
Subject: packages (V5-DEVEL): rsyslog/rsyslog.spec - up to 5.8.1
In-Reply-To: <BANLkTimqEVaDyuTe=1VzDj44S6BoQX5BSA@mail.gmail.com>
References: <packages_rsyslog_rsyslog.spec.1.41.4.8@pld-linux.org>	<packages_rsyslog_rsyslog.spec.1.41.4.9@pld-linux.org>
	<BANLkTimqEVaDyuTe=1VzDj44S6BoQX5BSA@mail.gmail.com>
Message-ID: <4DDA9EC7.6050806@gmail.com>

W dniu 23.05.2011 18:00, Marcin Rybak pisze:
> 2011/5/23 marti<marti at pld-linux.org>
>
>> Author: marti                        Date: Mon May 23 15:23:28 2011 GMT
>> Module: packages                      Tag: V5-DEVEL
>> ---- Log message:
>> - up to 5.8.1
>>
> Are there any circumstances that this does not go to HEAD?

It should. v5-devel now became v5-stable so all you need to do is to 
merge V5-DEVEL with HEAD.


From marcin.rybak at gmail.com  Mon May 23 20:29:57 2011
From: marcin.rybak at gmail.com (Marcin Rybak)
Date: Mon, 23 May 2011 20:29:57 +0200
Subject: packages (V5-DEVEL): rsyslog/rsyslog.spec - up to 5.8.1
In-Reply-To: <4DDA9EC7.6050806@gmail.com>
References: <packages_rsyslog_rsyslog.spec.1.41.4.8@pld-linux.org>
	<packages_rsyslog_rsyslog.spec.1.41.4.9@pld-linux.org>
	<BANLkTimqEVaDyuTe=1VzDj44S6BoQX5BSA@mail.gmail.com>
	<4DDA9EC7.6050806@gmail.com>
Message-ID: <BANLkTimK1UFn+3W8-QbP344dxwYWOD_tYw@mail.gmail.com>

W dniu 23 maja 2011 19:52 u?ytkownik Micha? Lisowski <lisu87 at gmail.com>napisa?:

> W dniu 23.05.2011 18:00, Marcin Rybak pisze:
>
>  2011/5/23 marti<marti at pld-linux.org>
>>
>>  Author: marti                        Date: Mon May 23 15:23:28 2011 GMT
>>> Module: packages                      Tag: V5-DEVEL
>>> ---- Log message:
>>> - up to 5.8.1
>>>
>>>  Are there any circumstances that this does not go to HEAD?
>>
>
> It should. v5-devel now became v5-stable so all you need to do is to merge
> V5-DEVEL with HEAD.
>

thx
---
Marcin Rybak
http://marcinrybak.com


From glen at pld-linux.org  Tue May 24 12:33:01 2011
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Tue, 24 May 2011 13:33:01 +0300
Subject: processes ulimit weirdness [solved]
In-Reply-To: <6b15d3970f82ade75b9c8c14596fdcb5@delfi.ee>
References: <4DD665F1.3000105@pld-linux.org>
	<6b15d3970f82ade75b9c8c14596fdcb5@delfi.ee>
Message-ID: <4DDB895D.9000602@pld-linux.org>

On 22.05.2011 15:27, Elan Ruusam?e wrote:
> so far seems downgrade of sudo helped, one from th-archives
> sudo-1.7.4p6-1.i686 = OK
> sudo-1.7.5-1.i686 = FAIL
> sudo-1.7.6-1.i686 = FAIL

the actual fix was to upgrade away from buggy kernel

broken:
2.6.36.2-1
util-vserver-0.30.216-1.pre2955.3.x86_64

better:
2.6.37.6-2
util-vserver-0.30.216-1.pre2955.3.x86_64

# sudo -u glen sudo bash -c 'ulimit -u'
unlimited
# rpm -q sudo
sudo-1.7.6-1.i686

supposedly fixed by this:
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/kernel/kernel.spec.diff?r1=1.874;r2=1.875;f=h

-- 
glen



From kornet at camk.edu.pl  Fri May 27 13:17:26 2011
From: kornet at camk.edu.pl (Kacper Kornet)
Date: Fri, 27 May 2011 13:17:26 +0200
Subject: CVS problem: php-pecl-idn
Message-ID: <20110527111726.GA13165@camk.edu.pl>

ERROR: A CVS repository cannot contain both packages/php-pecl-idn/php-pecl-idn.spec,v and
packages/php-pecl-idn/Attic/php-pecl-idn.spec,v

-- 
  Kacper Kornet


From glen at pld-linux.org  Fri May 27 15:35:04 2011
From: glen at pld-linux.org (glen)
Date: Fri, 27 May 2011 16:35:04 +0300
Subject: CVS problem: php-pecl-idn
In-Reply-To: <20110527111726.GA13165@camk.edu.pl>
References: <20110527111726.GA13165@camk.edu.pl>
Message-ID: <4DDFA888.5020106@pld-linux.org>

On 27.05.2011 14:17, Kacper Kornet wrote:
> ERROR: A CVS repository cannot contain both packages/php-pecl-idn/php-pecl-idn.spec,v and
> packages/php-pecl-idn/Attic/php-pecl-idn.spec,v
corrected, but in what part that made trouble?



-- 
glen



From gotar at polanet.pl  Mon May 30 19:39:30 2011
From: gotar at polanet.pl (Tomasz Pala)
Date: Mon, 30 May 2011 19:39:30 +0200
Subject: *.la files in xorg* packages
Message-ID: <20110530173930.GA8544@polanet.pl>

While updating my system I've noticed that xorg* packages still got
*.la files, while they all got *.pc as well.
Are there any other (not discussed before) reasons not to remove them?
Having *.pc was the main rule allowing to do this.

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


From arekm at maven.pl  Mon May 30 19:45:53 2011
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Mon, 30 May 2011 19:45:53 +0200
Subject: *.la files in xorg* packages
In-Reply-To: <20110530173930.GA8544@polanet.pl>
References: <20110530173930.GA8544@polanet.pl>
Message-ID: <201105301945.53253.arekm@maven.pl>

On Monday 30 of May 2011, Tomasz Pala wrote:
> While updating my system I've noticed that xorg* packages still got
> *.la files, while they all got *.pc as well.
> Are there any other (not discussed before) reasons not to remove them?
> Having *.pc was the main rule allowing to do this.

No one was brave enough to rebuild all dependencies on ftp.pld- which would be 
required if la were dropped.

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


From gotar at polanet.pl  Mon May 30 19:53:52 2011
From: gotar at polanet.pl (Tomasz Pala)
Date: Mon, 30 May 2011 19:53:52 +0200
Subject: *.la files in xorg* packages
In-Reply-To: <201105301945.53253.arekm@maven.pl>
References: <20110530173930.GA8544@polanet.pl>
	<201105301945.53253.arekm@maven.pl>
Message-ID: <20110530175352.GA9578@polanet.pl>

On Mon, May 30, 2011 at 19:45:53 +0200, Arkadiusz Miskiewicz wrote:

>> While updating my system I've noticed that xorg* packages still got
>> *.la files, while they all got *.pc as well.
>> Are there any other (not discussed before) reasons not to remove them?
>> Having *.pc was the main rule allowing to do this.
> 
> No one was brave enough to rebuild all dependencies on ftp.pld- which would be 
> required if la were dropped.

Is such list sufficient?

~: ipoldek --skip-installed rsearch -r /usr/lib/libXi.la/
avifile-devel-0.7.45-16.i686
gdk-pixbuf-devel-0.22.0-19.i686
gtk+-devel-1.2.10-21.i686
gtkglarea1-devel-1.2.3-9.i686
imlib-devel-1.9.15-14.i686
libglade-devel-0.17-23.i686
libgstroke-devel-0.5.1-4.i686
plib-devel-1.8.5-2.i686

i.e. only these 8 packages would need rebuilding after fixing
xorg-lib-libXi, or something more is usually polluted?

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


From n3npq at mac.com  Mon May 30 19:55:21 2011
From: n3npq at mac.com (Jeff Johnson)
Date: Mon, 30 May 2011 13:55:21 -0400
Subject: *.la files in xorg* packages
In-Reply-To: <201105301945.53253.arekm@maven.pl>
References: <20110530173930.GA8544@polanet.pl>
	<201105301945.53253.arekm@maven.pl>
Message-ID: <555D6FC0-341B-49D8-A1A6-BF9D3F5AA119@mac.com>


On May 30, 2011, at 1:45 PM, Arkadiusz Miskiewicz wrote:

> On Monday 30 of May 2011, Tomasz Pala wrote:
>> While updating my system I've noticed that xorg* packages still got
>> *.la files, while they all got *.pc as well.
>> Are there any other (not discussed before) reasons not to remove them?
>> Having *.pc was the main rule allowing to do this.
> 
> No one was brave enough to rebuild all dependencies on ftp.pld- which would be 
> required if la were dropped.
> 

Is it merely a matter of "bravery" or is there still a need for *.la?

I'm asking the engineering, not the advocacy, question here:
	Are *.la files useful?

I already know my non-linux answer: Yes.

73 de Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4645 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20110530/f2f6b638/attachment.p7s>

From gotar at polanet.pl  Mon May 30 20:04:29 2011
From: gotar at polanet.pl (Tomasz Pala)
Date: Mon, 30 May 2011 20:04:29 +0200
Subject: *.la files in xorg* packages
In-Reply-To: <555D6FC0-341B-49D8-A1A6-BF9D3F5AA119@mac.com>
References: <20110530173930.GA8544@polanet.pl>
	<201105301945.53253.arekm@maven.pl>
	<555D6FC0-341B-49D8-A1A6-BF9D3F5AA119@mac.com>
Message-ID: <20110530180429.GA10466@polanet.pl>

On Mon, May 30, 2011 at 13:55:21 -0400, Jeff Johnson wrote:

> Is it merely a matter of "bravery" or is there still a need for *.la?
> 
> I'm asking the engineering, not the advocacy, question here:
> 	Are *.la files useful?

Yes, they are - for static building. As long as we support this feature
we must cope with it (or ship 'broken' static subpackages).

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


From arekm at maven.pl  Mon May 30 20:05:30 2011
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Mon, 30 May 2011 20:05:30 +0200
Subject: *.la files in xorg* packages
In-Reply-To: <555D6FC0-341B-49D8-A1A6-BF9D3F5AA119@mac.com>
References: <20110530173930.GA8544@polanet.pl>
	<201105301945.53253.arekm@maven.pl>
	<555D6FC0-341B-49D8-A1A6-BF9D3F5AA119@mac.com>
Message-ID: <201105302005.30763.arekm@maven.pl>

On Monday 30 of May 2011, Jeff Johnson wrote:
> On May 30, 2011, at 1:45 PM, Arkadiusz Miskiewicz wrote:
> > On Monday 30 of May 2011, Tomasz Pala wrote:
> >> While updating my system I've noticed that xorg* packages still got
> >> *.la files, while they all got *.pc as well.
> >> Are there any other (not discussed before) reasons not to remove them?
> >> Having *.pc was the main rule allowing to do this.
> > 
> > No one was brave enough to rebuild all dependencies on ftp.pld- which
> > would be required if la were dropped.
> 
> Is it merely a matter of "bravery" or is there still a need for *.la?
> 
> I'm asking the engineering, not the advocacy, question here:
> 	Are *.la files useful?

Not useful for dynamic linking, only for static linking sometimes (when pc 
files are not used).

> 73 de Jeff

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


From n3npq at mac.com  Mon May 30 20:27:50 2011
From: n3npq at mac.com (Jeff Johnson)
Date: Mon, 30 May 2011 14:27:50 -0400
Subject: *.la files in xorg* packages
In-Reply-To: <201105302005.30763.arekm@maven.pl>
References: <20110530173930.GA8544@polanet.pl>
	<201105301945.53253.arekm@maven.pl>
	<555D6FC0-341B-49D8-A1A6-BF9D3F5AA119@mac.com>
	<201105302005.30763.arekm@maven.pl>
Message-ID: <4696BC7B-1697-4B64-81B8-2CAF1513A91A@mac.com>


On May 30, 2011, at 2:05 PM, Arkadiusz Miskiewicz wrote:

> On Monday 30 of May 2011, Jeff Johnson wrote:
>> On May 30, 2011, at 1:45 PM, Arkadiusz Miskiewicz wrote:
>>> On Monday 30 of May 2011, Tomasz Pala wrote:
>>>> While updating my system I've noticed that xorg* packages still got
>>>> *.la files, while they all got *.pc as well.
>>>> Are there any other (not discussed before) reasons not to remove them?
>>>> Having *.pc was the main rule allowing to do this.
>>> 
>>> No one was brave enough to rebuild all dependencies on ftp.pld- which
>>> would be required if la were dropped.
>> 
>> Is it merely a matter of "bravery" or is there still a need for *.la?
>> 
>> I'm asking the engineering, not the advocacy, question here:
>> 	Are *.la files useful?
> 
> Not useful for dynamic linking, only for static linking sometimes (when pc 
> files are not used).
> 

Thanks (ant to Thomasz) for sane opinions. Re-vositing statically linked RPM
is most definitely one of my todo++ items (and means *.la for all rpm prereq's).

Does PLD attempt to reduce build/install prereq's by doing static linking?

E.g some real world examples I've had to deal w in last 10 days:

I'm working from serentos (RHEL6 clone) bolting on Fedorable devel
packaging, to establish a sane "development" platform.

There are two easy to express "dependency hell" snarls that might
be solved (there are other solutions) by static linking:

1) ossp-uuid -> PHP -> a_whole_lotta_stuff (this started as build prereq and
quickly becomes a hugely painful wrestling match)

2) bitbake -> help2man,tex2html -> a_whole_lotta_ancient_tetex
bitbake is the OpenEmbedded and Poky/Yacto "rpmbuild" without using rpmbuild
that I'm trying to cross-compile for arm5tel images.

(aside)
The ulterior motive in asking is that I'm considering writing the
dependency analysis tool(s) that try to identify the point at which
the transition ... -> a_whole_lotta_stuff might be recognized
automatically. I'm quite sure there's enough sanity in PLD that the
tool(s) aren't critically needed. But _SOME_ objective measurement
is most definitely needed in Fedorable and Mandriva to help unsnarl
prerequsites and identify objectively where a_whole_lotta_stuff
starts to become annoyingly painful with *.rpm packaging.

73 de Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4645 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20110530/687aa2c3/attachment.p7s>

From gotar at polanet.pl  Tue May 31 15:01:31 2011
From: gotar at polanet.pl (Tomasz Pala)
Date: Tue, 31 May 2011 15:01:31 +0200
Subject: *.la files in xorg* packages
In-Reply-To: <20110530175352.GA9578@polanet.pl>
References: <20110530173930.GA8544@polanet.pl>
	<201105301945.53253.arekm@maven.pl>
	<20110530175352.GA9578@polanet.pl>
Message-ID: <20110531130131.GA13374@polanet.pl>

On Mon, May 30, 2011 at 19:53:52 +0200, Tomasz Pala wrote:

>> No one was brave enough to rebuild all dependencies on ftp.pld- which would be 
>> required if la were dropped.

So basically every *.la file that can be safely removed (packages with
*.pc) and is not required by any package we got might be removed without
any rebuilds? I mean - if some outer la file was polluted it would be
seen in rpm requires list, right?

And the full list doesn't look scarry either:

~: ipoldek --skip-installed rsearch -r //usr/lib/libx.\*\.la/i
57 package(s) found:
Glide_V3-DRI-devel-3.10.0-0.20010309.14.i686
WSoundServer-devel-0.4.1-5.i686
WindowMaker-devel-0.92.0-12.i686
Xbae-devel-4.60.4-3.i686
XmHTML-devel-1.1.7-9.i686
aalib-devel-1.4-0.rc5.14.i686
avifile-devel-0.7.45-16.i686
corona-devel-1.0.2-4.i686
dbus-qt3-devel-0.8.1-2.i686
dclib-devel-0.3.23-1.i686
gd-devel-2.0.35-6.i686
gdk-pixbuf-devel-0.22.0-19.i686
gdome2-cpp_smart-devel-0.2.6-4.i686
giblib-devel-1.2.4-2.i686
giflib-devel-4.1.6-1.i686
glfw-devel-2.5.0-4.i686
glitz-devel-0.5.6-3.i686
gtk+-devel-1.2.10-21.i686
gtkglarea1-devel-1.2.3-9.i686
guile-cairo-devel-1.4.0-4.i686
imlib-devel-1.9.15-14.i686
lesstif-devel-0.95.2-1.i686
libast-devel-0.7-2.i686
libcaptury-devel-0.3.0-2.i686
libcm-devel-0.1.1-2.i686
libcompizconfig-devel-0.8.4-2.i686
libcroco-devel-0.6.2-1.i686
libdockapp-devel-0.6.2-1.i686
libextractor-devel-0.5.22-2.i686
libglade-devel-0.17-23.i686
libgstroke-devel-0.5.1-4.i686
libipoddevice-devel-0.5.3-4.i686
libmatchbox-devel-1.9-5.i686
liboglappth-devel-0.98-1.i686
libplot-devel-4.3-7.i686
libplotter-devel-4.3-7.i686
libsvg-cairo-devel-0.1.6-8.i686
libxsettings-client-devel-0.17-2.i686
mediastreamer-devel-2.3.0-3.i686
mjpegtools-devel-1.9.0-5.i686
ogle-devel-0.9.2-9.i686
ots-devel-0.4.2-3.i686
plib-devel-1.8.5-2.i686
plt-devel-4.2.4-2.i686
pxlib-devel-0.6.3-2.i686
quesoglc-devel-0.7.2-1.i686
startup-notification-devel-0.10-1.i686
wv-devel-1.2.4-6.i686
xbsql-devel-0.11-4.i686
xcb-util-devel-0.3.6-1.i686
xorg-lib-libWindowsWM-devel-1.0.1-2.i686
xorg-lib-libXfontcache-devel-1.0.5-2.i686
xorg-lib-libXprintAppUtil-devel-1.0.1-5.i686
xorg-lib-libXprintUtil-devel-1.0.1-5.i686
xorg-lib-liboldX-devel-1.0.1-4.i686
xorg-lib-libxkbui-devel-1.0.2-5.i686
xosd-devel-2.2.12-7.i686

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


From arekm at maven.pl  Tue May 31 15:12:11 2011
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Tue, 31 May 2011 15:12:11 +0200
Subject: *.la files in xorg* packages
In-Reply-To: <20110531130131.GA13374@polanet.pl>
References: <20110530173930.GA8544@polanet.pl>
	<20110530175352.GA9578@polanet.pl>
	<20110531130131.GA13374@polanet.pl>
Message-ID: <201105311512.11281.arekm@maven.pl>

On Tuesday 31 of May 2011, Tomasz Pala wrote:
> On Mon, May 30, 2011 at 19:53:52 +0200, Tomasz Pala wrote:
> >> No one was brave enough to rebuild all dependencies on ftp.pld- which
> >> would be required if la were dropped.
> 
> So basically every *.la file that can be safely removed (packages with
> *.pc) and is not required by any package we got might be removed without
> any rebuilds? I mean - if some outer la file was polluted it would be
> seen in rpm requires list, right?

In theory. I guess there are cases when it will be in .la but not in requires.

> And the full list doesn't look scarry either:

There are few which don't build at the moment at all, so...

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


From gotar at polanet.pl  Tue May 31 18:10:29 2011
From: gotar at polanet.pl (Tomasz Pala)
Date: Tue, 31 May 2011 18:10:29 +0200
Subject: *.la files in xorg* packages
In-Reply-To: <201105311512.11281.arekm@maven.pl>
References: <20110530173930.GA8544@polanet.pl>
	<20110530175352.GA9578@polanet.pl>
	<20110531130131.GA13374@polanet.pl>
	<201105311512.11281.arekm@maven.pl>
Message-ID: <20110531161029.GA27767@polanet.pl>

On Tue, May 31, 2011 at 15:12:11 +0200, Arkadiusz Miskiewicz wrote:

>> So basically every *.la file that can be safely removed (packages with
>> *.pc) and is not required by any package we got might be removed without
>> any rebuilds? I mean - if some outer la file was polluted it would be
>> seen in rpm requires list, right?
> 
> In theory. I guess there are cases when it will be in .la but not in requires.

Such will come out eventually.

>> And the full list doesn't look scarry either:
> 
> There are few which don't build at the moment at all, so...

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


From gotar at polanet.pl  Tue May 31 19:22:23 2011
From: gotar at polanet.pl (Tomasz Pala)
Date: Tue, 31 May 2011 19:22:23 +0200
Subject: *.la files in xorg* packages
In-Reply-To: <201105301945.53253.arekm@maven.pl>
References: <20110530173930.GA8544@polanet.pl>
	<201105301945.53253.arekm@maven.pl>
Message-ID: <20110531172223.GA30509@polanet.pl>

On Mon, May 30, 2011 at 19:45:53 +0200, Arkadiusz Miskiewicz wrote:

> No one was brave enough to rebuild all dependencies on ftp.pld- which would be 
> required if la were dropped.

I did some initial changes, especially rebuilded libxkbui with stripped
libxkbfile - or tried to, because BR: xorg-lib-libxkbfile-devel >= 1.0.7-2
was apparently ignored...

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


From qboosh at pld-linux.org  Tue May 31 22:03:35 2011
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 31 May 2011 22:03:35 +0200
Subject: *.la files in xorg* packages
In-Reply-To: <201105311512.11281.arekm@maven.pl>
References: <20110530173930.GA8544@polanet.pl>
	<20110530175352.GA9578@polanet.pl>
	<20110531130131.GA13374@polanet.pl>
	<201105311512.11281.arekm@maven.pl>
Message-ID: <20110531200335.GA10896@stranger.qboosh.pl>

On Tue, May 31, 2011 at 03:12:11PM +0200, Arkadiusz Miskiewicz wrote:
> On Tuesday 31 of May 2011, Tomasz Pala wrote:
> > On Mon, May 30, 2011 at 19:53:52 +0200, Tomasz Pala wrote:
> > >> No one was brave enough to rebuild all dependencies on ftp.pld- which
> > >> would be required if la were dropped.
> > 
> > So basically every *.la file that can be safely removed (packages with
> > *.pc) and is not required by any package we got might be removed without
> > any rebuilds? I mean - if some outer la file was polluted it would be
> > seen in rpm requires list, right?
> 
> In theory. I guess there are cases when it will be in .la but not in requires.

Is libtool(...) dependency generation enabled again in Th?
I saw it's been disabled some time ago... unfortunately.
It should be enabled even when the policy is to drop most of the *.la
files - it will allow to catch packages needing rebuild.

The same for pkgconfig(...) dependencies - it shouldn't be disabled.


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