From kornet at camk.edu.pl  Tue Apr  3 19:34:10 2012
From: kornet at camk.edu.pl (Kacper Kornet)
Date: Tue, 3 Apr 2012 19:34:10 +0200
Subject: Git migration: next step
Message-ID: <20120403173410.GB12389@camk.edu.pl>


I think all necessary pieces of code for git migration are ready. The
test setup on carme has been working for some time. So if you want to
check how your favourite package would like after migration please see:

git://carme.pld-linux.org/packages/<pkg>

Also some documentation has been written:

http://www.pld-linux.org/dokuwiki/pld-gitolite
http://www.pld-linux.org/dokuwiki/howto-git

So there are following questions:

A. Should PLD move to git with the similar setup?

B. Is there anything more that should be done before D day?

C. When should the migration take place?


Assuming that the migration to git would take place it could go
according to the following plan:

1. Install package pld-gitolite and git-core-slug-watch on 
   git.pld-linux.org

2. Push converted repositories from gitolite setup on carme to
   git.pld-linux.org

3. Setup git-daemon and gitweb access

4. Import ssh keys of PLD developers

5. Import git versions of rpm-build-tools and pld-builder.new from 
   https://github.com/draenog/rpm-build-tools
   https://github.com/draenog/pld-builder.new

6. Setup mailing list for git commits

7. Switch off RW access to cvs.pld-linux.org/rpm/packages

8. Setup src-builder  

9. Update distfiles to version from branch git in cvs.pld-linux.org

10. Update packages which were changed in CVS between point 2. and 7.

11. Switch on RW access to git.pld-linux.org for all developers


-- 
  Kacper Kornet


From arekm at maven.pl  Tue Apr  3 20:04:27 2012
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Tue, 3 Apr 2012 20:04:27 +0200
Subject: Git migration: next step
In-Reply-To: <20120403173410.GB12389@camk.edu.pl>
References: <20120403173410.GB12389@camk.edu.pl>
Message-ID: <201204032004.27486.arekm@maven.pl>

On Tuesday 03 of April 2012, Kacper Kornet wrote:
> I think all necessary pieces of code for git migration are ready. The
> test setup on carme has been working for some time. So if you want to
> check how your favourite package would like after migration please see:
> 
> git://carme.pld-linux.org/packages/<pkg>
> 
> Also some documentation has been written:
> 
> http://www.pld-linux.org/dokuwiki/pld-gitolite

Is cvsadmin job for git described anywhere?

How I (as user) can change my ssh key?

"admin defined command" - 404

> http://www.pld-linux.org/dokuwiki/howto-git

Are auto- tags restricted for pld-builders only? (should be).

How workflow with DEVEL or APACHE_2_2 and such branches should look like? (aka 
are there any things different from cvs)

> So there are following questions:
> 
> A. Should PLD move to git with the similar setup?

I like trying new things and have nothing against git.

> B. Is there anything more that should be done before D day?

We have few scripts in CVSROOT (restricting access, cia bot notification, 
commit log notification, cdg, namecheck, filter tags,...). Are these scripts 
ported to git version of repository?

> C. When should the migration take place?

When you and someone else have bunch of free time to do all of it :-) I could 
find some time over one of the weekends but I want "big move" to happen first.

> Assuming that the migration to git would take place it could go
> according to the following plan:

> 2. Push converted repositories from gitolite setup on carme to
>    git.pld-linux.org

I would go for converting from current cvs from scratch (especially things are 
modified on cvs server side sometimes). How long such conversion takes?

> 3. Setup git-daemon and gitweb access

gitweb == or != cgit nowdays?

> 6. Setup mailing list for git commits

Will be the same as current list.

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


From przemo at firszt.eu  Thu Apr  5 10:00:34 2012
From: przemo at firszt.eu (Przemo Firszt)
Date: Thu, 5 Apr 2012 09:00:34 +0100
Subject: Git migration: next step
In-Reply-To: <20120403173410.GB12389@camk.edu.pl>
References: <20120403173410.GB12389@camk.edu.pl>
Message-ID: <a917fc6e77b1dd38bc61b98d3b2b148e.squirrel@webmail.firszt.eu>


Dnia 3 Kwietnia 2012, 6:34 pm, Wt, Kacper Kornet napisa?(a):
>
> I think all necessary pieces of code for git migration are ready. The
> test setup on carme has been working for some time. So if you want to
> check how your favourite package would like after migration please see:
>
> git://carme.pld-linux.org/packages/<pkg>
>
> Also some documentation has been written:
>
> http://www.pld-linux.org/dokuwiki/pld-gitolite
> http://www.pld-linux.org/dokuwiki/howto-git

Can we agree a naming convention? Something like:
"package-name: description" (it's similar to kernel patches)
i.e. "xorg-driver-input-wacom: up to 14.0.0" or
"xorg-driver-input-wacom: fix invalid BuildReq"?
Are we going to use "git tag" to mark a new version of the software or
version of the spec or both?
Is Signed-off-by required in patches?

[..]
> A. Should PLD move to git with the similar setup?
Yes
>
[..]
> C. When should the migration take place?
ASAP

[..]
>
> 6. Setup mailing list for git commits
I think there is no need for a separate list.

-- 
Regards,
Przemo Firszt



From mike at osdn.org.ua  Thu Apr  5 15:49:01 2012
From: mike at osdn.org.ua (Michael Shigorin)
Date: Thu, 5 Apr 2012 16:49:01 +0300
Subject: Git migration: next step
In-Reply-To: <a917fc6e77b1dd38bc61b98d3b2b148e.squirrel@webmail.firszt.eu>
References: <20120403173410.GB12389@camk.edu.pl>
 <a917fc6e77b1dd38bc61b98d3b2b148e.squirrel@webmail.firszt.eu>
Message-ID: <20120405134901.GT3300@osdn.org.ua>

On Thu, Apr 05, 2012 at 09:00:34AM +0100, Przemo Firszt wrote:
> Are we going to use "git tag" to mark a new version of the
> software or version of the spec or both?

JFYI, ALT Linux uses both -- with tags being convenient
to prepare the tarball for the build system.

See also gear* and girar* if anyone's interested (the discussions
and wiki are mostly in Russian but there are English manpages too).

-- 
 ---- WBR, Michael Shigorin <mike at altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/


From qboosh at pld-linux.org  Thu Apr  5 17:01:00 2012
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 5 Apr 2012 17:01:00 +0200
Subject: Git migration: next step
In-Reply-To: <a917fc6e77b1dd38bc61b98d3b2b148e.squirrel@webmail.firszt.eu>
References: <20120403173410.GB12389@camk.edu.pl>
 <a917fc6e77b1dd38bc61b98d3b2b148e.squirrel@webmail.firszt.eu>
Message-ID: <20120405150100.GA29713@mail>

On Thu, Apr 05, 2012 at 09:00:34AM +0100, Przemo Firszt wrote:
> 
> Dnia 3 Kwietnia 2012, 6:34 pm, Wt, Kacper Kornet napisa?(a):
> >
> > I think all necessary pieces of code for git migration are ready. The
> > test setup on carme has been working for some time. So if you want to
> > check how your favourite package would like after migration please see:
> >
> > git://carme.pld-linux.org/packages/<pkg>
> >
> > Also some documentation has been written:
> >
> > http://www.pld-linux.org/dokuwiki/pld-gitolite
> > http://www.pld-linux.org/dokuwiki/howto-git
> 
> Can we agree a naming convention? Something like:
> "package-name: description" (it's similar to kernel patches)
> i.e. "xorg-driver-input-wacom: up to 14.0.0" or
> "xorg-driver-input-wacom: fix invalid BuildReq"?

I don't find "package-name: " prefix useful, as there (AFAIK) will be
one package per repository.

> Are we going to use "git tag" to mark a new version of the software or
> version of the spec or both?

NVR tags should be done automatically like in CVS.

> Is Signed-off-by required in patches?

No sense IMO if committer is the author.

> [..]
> >
> > 6. Setup mailing list for git commits
> I think there is no need for a separate list.

Agreed, single [cvs-]commit list should suffice.


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


From kornet at camk.edu.pl  Thu Apr  5 18:40:30 2012
From: kornet at camk.edu.pl (Kacper Kornet)
Date: Thu, 5 Apr 2012 18:40:30 +0200
Subject: Git migration: next step
In-Reply-To: <201204032004.27486.arekm@maven.pl>
References: <20120403173410.GB12389@camk.edu.pl>
 <201204032004.27486.arekm@maven.pl>
Message-ID: <20120405164029.GC3959@camk.edu.pl>

On Tue, Apr 03, 2012 at 08:04:27PM +0200, Arkadiusz Mi?kiewicz wrote:
> On Tuesday 03 of April 2012, Kacper Kornet wrote:
> Is cvsadmin job for git described anywhere?

http://sitaramc.github.com/gitolite/admin.html

But I will prepare small description on our wiki.

> How I (as user) can change my ssh key?

In the current setup no. You have to send your public key to the admin. 
But it is possible to enable ordinary users to change their keys.

> "admin defined command" - 404

Fixed. 

> > http://www.pld-linux.org/dokuwiki/howto-git

> Are auto- tags restricted for pld-builders only? (should be).

Yes, only builder of the given PLD flavour can write them. None (even
builders) can remove or rewrite them.

> How workflow with DEVEL or APACHE_2_2 and such branches should look like? (aka 
> are there any things different from cvs)

If you use builder script everything should be the same. The difference
is that in git branches and tags are in separate name spaces so it is
possible to have concurrently a branch DEVEL, and a tag DEVEL pointing
to different commits.

> > B. Is there anything more that should be done before D day?

> We have few scripts in CVSROOT (restricting access, cia bot notification, 
> commit log notification, cdg, namecheck, filter tags,...). Are these scripts 
> ported to git version of repository?

ciabot - implemented
cdg - for now I would leave it in CVS
sending notifications to distfiles and pld-cvs - implemented
filter_tas.sh - seems to be not used currently

> > Assuming that the migration to git would take place it could go
> > according to the following plan:

> > 2. Push converted repositories from gitolite setup on carme to
> >    git.pld-linux.org

> I would go for converting from current cvs from scratch (especially things are 
> modified on cvs server side sometimes).

It is taken into account. The conversion is based on *,v file rsynced
from cvs.pld-linux.org

> How long such conversion takes?

My estimate is about 12-18h on carme.

> > 3. Setup git-daemon and gitweb access

> gitweb == or != cgit nowdays?

Yes. Gitweb is a perl code developed together with git. Cgit is written
in C and developed separately.

-- 
  Kacper Kornet


From kornet at camk.edu.pl  Thu Apr  5 18:55:03 2012
From: kornet at camk.edu.pl (Kacper Kornet)
Date: Thu, 5 Apr 2012 18:55:03 +0200
Subject: Git migration: next step
In-Reply-To: <1621863.F4a6jZT1E6@localhost>
References: <20120403173410.GB12389@camk.edu.pl> <1621863.F4a6jZT1E6@localhost>
Message-ID: <20120405165503.GD3959@camk.edu.pl>

On Tue, Apr 03, 2012 at 08:32:43PM +0200, Pawe? Sikora wrote:
> On Tuesday 03 of April 2012 19:34:10 Kacper Kornet wrote:

> > So there are following questions:
> > B. Is there anything more that should be done before D day?

> do we need an extra 'Changed files:' section in git changelog?

It is only in commits that are result of ocnversion from CVS. I was
asked to add the information on which CVS revisions the git commit is
based.

-- 
  Kacper Kornet


From glen at pld-linux.org  Thu Apr  5 20:18:42 2012
From: glen at pld-linux.org (=?ISO-8859-2?Q?Elan_Ruusam=E4e?=)
Date: Thu, 05 Apr 2012 21:18:42 +0300
Subject: Git migration: next step
In-Reply-To: <20120405150100.GA29713@mail>
References: <20120403173410.GB12389@camk.edu.pl>
 <a917fc6e77b1dd38bc61b98d3b2b148e.squirrel@webmail.firszt.eu>
 <20120405150100.GA29713@mail>
Message-ID: <4F7DE202.1020807@pld-linux.org>

On 05/04/12 18:01, Jakub Bogusz wrote:
>> >  Are we going to use "git tag" to mark a new version of the software or
>> >  version of the spec or both?
> NVR tags should be done automatically like in CVS.
>
i would expect here a bit change with the tag transforming

as "." was illegal in cvs, but valid in git, i would not do the 
transformation if possible, and thus git autotags would be

auto-<dist>-N-V-R,

i.e: auto-th-rpm-4.5-65

how it is done now and how was planned?

-- 
glen



From arekm at maven.pl  Thu Apr  5 21:27:50 2012
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Thu, 5 Apr 2012 21:27:50 +0200
Subject: ftp move is comming
In-Reply-To: <201203262211.54451.arekm@maven.pl>
References: <201203262211.54451.arekm@maven.pl>
Message-ID: <201204052127.51134.arekm@maven.pl>

On Monday 26 of March 2012, Arkadiusz Mi?kiewicz wrote:
> ftp move is comming soon

It happened. Current TODO list:

http://ep09.pld-linux.org/~pldth/main.txt
http://ep09.pld-linux.org/~pldth/main-i686.txt
http://ep09.pld-linux.org/~pldth/main-i486.txt

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


From glen at delfi.ee  Sun Apr  8 13:31:13 2012
From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Sun, 08 Apr 2012 14:31:13 +0300
Subject: Fwd: DISK FULL
In-Reply-To: <E1SGgxF-0001UZ-0X@ep09.pld-linux.org>
References: <E1SGgxF-0001UZ-0X@ep09.pld-linux.org>
Message-ID: <4F817701.1010107@delfi.ee>

AAAA!

14:30:42 pldth[load: 8.11]@ep09-pld SRPMS/RPMS$ date
Sun Apr  8 14:30:44 EEST 2012
14:30:44 pldth[load: 8.11]@ep09-pld SRPMS/RPMS$ df ~
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda4      xfs    80G   80G   32K 100% /home


-------- Original Message --------
Subject: 	Cron $HOME/pld-builder.new/bin/maintainer.sh
Date: 	Sun, 08 Apr 2012 03:30:09 +0200
From: 	builderth at ep09.pld-linux.org (Cron Daemon)
To: 	builderth at ep09.pld-linux.org



Traceback (most recent call last):
   File "PLD_Builder/maintainer.py", line 71, in<module>
     handle_src()
   File "PLD_Builder/maintainer.py", line 37, in handle_src
     send_rpmqa()
   File "PLD_Builder/maintainer.py", line 31, in send_rpmqa
     ftp.add(log)
   File "/home/pld/builderth/pld-builder.new/PLD_Builder/ftp.py", line 62, in add
     queue.add(f, type)
   File "/home/pld/builderth/pld-builder.new/PLD_Builder/ftp.py", line 35, in add
     shutil.copy(file, path.ftp_queue_dir + '/' + id)
   File "/usr/share/python2.7/shutil.py", line 116, in copy
   File "/usr/share/python2.7/shutil.py", line 83, in copyfile
   File "/usr/share/python2.7/shutil.py", line 51, in copyfileobj
IOError: [Errno 28] No space left on device




From glen at delfi.ee  Sun Apr  8 13:35:58 2012
From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Sun, 08 Apr 2012 14:35:58 +0300
Subject: Fwd: DISK FULL
In-Reply-To: <4F817701.1010107@delfi.ee>
References: <E1SGgxF-0001UZ-0X@ep09.pld-linux.org> <4F817701.1010107@delfi.ee>
Message-ID: <4F81781E.3090906@delfi.ee>

making free space is not an option, something just eats it up!

14:35:03 root[load: 8.53]@ep09-pld ~/tmp# df .
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda4      xfs    80G   80G   14M 100% /home
14:35:04 root[load: 8.53]@ep09-pld ~/tmp# df .
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda4      xfs    80G   80G  8.0M 100% /home
14:35:07 root[load: 8.49]@ep09-pld ~/tmp# df .
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda4      xfs    80G   80G  7.4M 100% /home
14:35:09 root[load: 8.49]@ep09-pld ~/tmp# df .
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda4      xfs    80G   80G  6.9M 100% /home


On 08/04/12 14:31, Elan Ruusam?e wrote:
> AAAA!
>
> 14:30:42 pldth[load: 8.11]@ep09-pld SRPMS/RPMS$ date
> Sun Apr  8 14:30:44 EEST 2012
> 14:30:44 pldth[load: 8.11]@ep09-pld SRPMS/RPMS$ df ~
> Filesystem     Type  Size  Used Avail Use% Mounted on
> /dev/sda4      xfs    80G   80G   32K 100% /home
>
>
> -------- Original Message --------
> Subject:     Cron $HOME/pld-builder.new/bin/maintainer.sh
> Date:     Sun, 08 Apr 2012 03:30:09 +0200
> From:     builderth at ep09.pld-linux.org (Cron Daemon)
> To:     builderth at ep09.pld-linux.org
>
>
>
> Traceback (most recent call last):
>   File "PLD_Builder/maintainer.py", line 71, in<module>
>     handle_src()
>   File "PLD_Builder/maintainer.py", line 37, in handle_src
>     send_rpmqa()
>   File "PLD_Builder/maintainer.py", line 31, in send_rpmqa
>     ftp.add(log)
>   File "/home/pld/builderth/pld-builder.new/PLD_Builder/ftp.py", line 
> 62, in add
>     queue.add(f, type)
>   File "/home/pld/builderth/pld-builder.new/PLD_Builder/ftp.py", line 
> 35, in add
>     shutil.copy(file, path.ftp_queue_dir + '/' + id)
>   File "/usr/share/python2.7/shutil.py", line 116, in copy
>   File "/usr/share/python2.7/shutil.py", line 83, in copyfile
>   File "/usr/share/python2.7/shutil.py", line 51, in copyfileobj
> IOError: [Errno 28] No space left on device
>
>
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


-- 
glen



From shadzik at gmail.com  Sun Apr  8 13:37:57 2012
From: shadzik at gmail.com (=?UTF-8?B?QmFydG9zeiDFmndpxIV0ZWs=?=)
Date: Sun, 8 Apr 2012 13:37:57 +0200
Subject: DISK FULL
In-Reply-To: <4F81781E.3090906@delfi.ee>
References: <E1SGgxF-0001UZ-0X@ep09.pld-linux.org> <4F817701.1010107@delfi.ee>
 <4F81781E.3090906@delfi.ee>
Message-ID: <8232571058175283511@unknownmsgid>

Get a life.

Sent from my iPhone

On 8 kwi 2012, at 13:36, "Elan Ruusam?e" <glen at delfi.ee> wrote:

> making free space is not an option, something just eats it up!
>
> 14:35:03 root[load: 8.53]@ep09-pld ~/tmp# df .
> Filesystem     Type  Size  Used Avail Use% Mounted on
> /dev/sda4      xfs    80G   80G   14M 100% /home
> 14:35:04 root[load: 8.53]@ep09-pld ~/tmp# df .
> Filesystem     Type  Size  Used Avail Use% Mounted on
> /dev/sda4      xfs    80G   80G  8.0M 100% /home
> 14:35:07 root[load: 8.49]@ep09-pld ~/tmp# df .
> Filesystem     Type  Size  Used Avail Use% Mounted on
> /dev/sda4      xfs    80G   80G  7.4M 100% /home
> 14:35:09 root[load: 8.49]@ep09-pld ~/tmp# df .
> Filesystem     Type  Size  Used Avail Use% Mounted on
> /dev/sda4      xfs    80G   80G  6.9M 100% /home
>
>
> On 08/04/12 14:31, Elan Ruusam?e wrote:
>> AAAA!
>>
>> 14:30:42 pldth[load: 8.11]@ep09-pld SRPMS/RPMS$ date
>> Sun Apr  8 14:30:44 EEST 2012
>> 14:30:44 pldth[load: 8.11]@ep09-pld SRPMS/RPMS$ df ~
>> Filesystem     Type  Size  Used Avail Use% Mounted on
>> /dev/sda4      xfs    80G   80G   32K 100% /home
>>
>>
>> -------- Original Message --------
>> Subject:     Cron $HOME/pld-builder.new/bin/maintainer.sh
>> Date:     Sun, 08 Apr 2012 03:30:09 +0200
>> From:     builderth at ep09.pld-linux.org (Cron Daemon)
>> To:     builderth at ep09.pld-linux.org
>>
>>
>>
>> Traceback (most recent call last):
>>  File "PLD_Builder/maintainer.py", line 71, in<module>
>>    handle_src()
>>  File "PLD_Builder/maintainer.py", line 37, in handle_src
>>    send_rpmqa()
>>  File "PLD_Builder/maintainer.py", line 31, in send_rpmqa
>>    ftp.add(log)
>>  File "/home/pld/builderth/pld-builder.new/PLD_Builder/ftp.py", line 62, in add
>>    queue.add(f, type)
>>  File "/home/pld/builderth/pld-builder.new/PLD_Builder/ftp.py", line 35, in add
>>    shutil.copy(file, path.ftp_queue_dir + '/' + id)
>>  File "/usr/share/python2.7/shutil.py", line 116, in copy
>>  File "/usr/share/python2.7/shutil.py", line 83, in copyfile
>>  File "/usr/share/python2.7/shutil.py", line 51, in copyfileobj
>> IOError: [Errno 28] No space left on device
>>
>>
>> _______________________________________________
>> pld-devel-en mailing list
>> pld-devel-en at lists.pld-linux.org
>> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
>
>
> --
> glen
>
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6350 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20120408/06b8bd38/attachment.p7s>

From glen at delfi.ee  Sun Apr  8 13:39:58 2012
From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Sun, 08 Apr 2012 14:39:58 +0300
Subject: Fwd: DISK FULL
In-Reply-To: <4F81781E.3090906@delfi.ee>
References: <E1SGgxF-0001UZ-0X@ep09.pld-linux.org> <4F817701.1010107@delfi.ee>
 <4F81781E.3090906@delfi.ee>
Message-ID: <4F81790E.9020505@delfi.ee>

this is sick

14:38:07 root[load: 22.02]@ep09-pld ~# lsof /home/|sort +6 -n|grep Mailbox
procmail  12613   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12629   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12637   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12653   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12672   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12684   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12692   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12700   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12716   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12724   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12732   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12756   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12764   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12781   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12789   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12807   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12833   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12841   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12857   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12865   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12881   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12889   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12897   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12905   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12921   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12929   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12938   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12946   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12954   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12963   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12971   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12979   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  12995   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13011   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13019   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13027   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13035   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13051   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13059   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13080   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13092   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13101   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13109   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13134   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13142   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13167   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13183   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13191   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13199   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13207   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13215   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13223   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13231   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13239   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13247   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13255   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13263   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13271   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13279   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13287   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13295   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13303   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13312   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13321   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13349   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13357   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13365   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13373   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13381   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13389   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13397   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13405   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13421   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13429   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13437   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13445   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13453   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13461   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13469   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13477   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13485   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13493   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13501   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13509   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13517   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13525   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13533   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13541   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
procmail  13549   plddist    6w   REG    8,4 24964947968 270630442 
/home/pld/admins/dist/Mailbox
14:38:14 root[load: 22.42]@ep09-pld ~#

14:38:34 root[load: 19.53]@ep09-pld ~# ps axwuf|grep exim
root     13668  0.0  0.0 119544   868 pts/9    S+   14:37   0:00  
|                   \_ grep --color=auto exim
exim     29354  0.0  0.1  88256  4576 ?        S    13:59   0:00  |   \_ 
/usr/lib/sendmail -FCronDaemon -i -odi -oem -oi -t -f root
exim      1823  0.0  0.1  88248  4620 ?        SNs  Mar19   0:04 
/usr/bin/exim -bd -q5m
root     12278  0.1  0.1  88376  4696 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -q
root     12611  0.0  0.1  88516  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRD-0003HO-Ej
plddist  12612  0.0  0.0  88516  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRD-0003HO-Ej
plddist  12614  0.0  0.0  88516  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRD-0003HO-Ej
root     12627  0.0  0.1  88520  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRD-0003He-Oa
plddist  12628  0.0  0.0  88520  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRD-0003He-Oa
plddist  12630  0.0  0.0  88520  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRD-0003He-Oa
root     12635  0.0  0.1  88516  5284 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRD-0003Hm-T8
plddist  12636  0.0  0.0  88516  2160 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRD-0003Hm-T8
plddist  12638  0.0  0.0  88516  1628 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRD-0003Hm-T8
root     12651  0.0  0.1  88516  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRE-0003I2-6S
plddist  12652  0.0  0.0  88516  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRE-0003I2-6S
plddist  12654  0.0  0.0  88516  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRE-0003I2-6S
root     12680  0.0  0.1  88524  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRE-0003IT-Le
plddist  12683  0.0  0.0  88524  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRE-0003IT-Le
plddist  12685  0.0  0.0  88524  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRE-0003IT-Le
root     12690  0.0  0.1  88524  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRE-0003If-Rn
plddist  12691  0.0  0.0  88524  2172 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRE-0003If-Rn
plddist  12693  0.0  0.0  88524  1640 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRE-0003If-Rn
root     12762  0.0  0.1  88528  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRG-0003Jp-7E
plddist  12763  0.0  0.0  88528  2172 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRG-0003Jp-7E
plddist  12765  0.0  0.0  88528  1640 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRG-0003Jp-7E
root     12787  0.0  0.1  88520  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRG-0003KE-Ir
plddist  12788  0.0  0.0  88520  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRG-0003KE-Ir
plddist  12790  0.0  0.0  88520  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRG-0003KE-Ir
root     12804  0.0  0.1  88520  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRG-0003KV-Ta
plddist  12806  0.0  0.0  88520  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRG-0003KV-Ta
plddist  12808  0.0  0.0  88520  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRG-0003KV-Ta
root     12831  0.0  0.1  88516  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRH-0003Kw-As
plddist  12832  0.0  0.0  88516  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRH-0003Kw-As
plddist  12834  0.0  0.0  88516  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRH-0003Kw-As
root     12839  0.0  0.1  88516  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRH-0003L4-HE
plddist  12840  0.0  0.0  88516  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRH-0003L4-HE
plddist  12842  0.0  0.0  88516  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRH-0003L4-HE
root     12855  0.0  0.1  88516  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRH-0003LK-Rb
plddist  12856  0.0  0.0  88516  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRH-0003LK-Rb
plddist  12858  0.0  0.0  88516  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRH-0003LK-Rb
root     12863  0.0  0.1  88528  5296 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRI-0003LS-19
plddist  12864  0.0  0.0  88528  2172 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRI-0003LS-19
plddist  12866  0.0  0.0  88528  1640 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRI-0003LS-19
root     12887  0.0  0.1  88528  5296 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRI-0003Lq-GY
plddist  12888  0.0  0.0  88528  2172 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRI-0003Lq-GY
plddist  12890  0.0  0.0  88528  1640 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRI-0003Lq-GY
root     12895  0.0  0.1  88528  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRI-0003Ly-Li
plddist  12896  0.0  0.0  88528  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRI-0003Ly-Li
plddist  12898  0.0  0.0  88528  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRI-0003Ly-Li
root     12927  0.0  0.1  88528  5296 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRJ-0003MU-8l
plddist  12928  0.0  0.0  88528  2172 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRJ-0003MU-8l
plddist  12930  0.0  0.0  88528  1640 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRJ-0003MU-8l
root     12936  0.0  0.1  88520  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRJ-0003Md-Ed
plddist  12937  0.0  0.0  88520  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRJ-0003Md-Ed
plddist  12939  0.0  0.0  88520  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRJ-0003Md-Ed
root     12944  0.0  0.1  88520  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRJ-0003Ml-Ih
plddist  12945  0.0  0.0  88520  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRJ-0003Ml-Ih
plddist  12947  0.0  0.0  88520  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRJ-0003Ml-Ih
root     12952  0.0  0.1  88528  5296 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRJ-0003Mt-MV
plddist  12953  0.0  0.0  88528  2176 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRJ-0003Mt-MV
plddist  12955  0.0  0.0  88528  1644 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRJ-0003Mt-MV
root     12961  0.0  0.1  88520  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRJ-0003N2-R2
plddist  12962  0.0  0.0  88520  2172 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRJ-0003N2-R2
plddist  12964  0.0  0.0  88520  1640 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRJ-0003N2-R2
root     12969  0.0  0.1  88524  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRJ-0003NA-V6
plddist  12970  0.0  0.0  88524  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRJ-0003NA-V6
plddist  12972  0.0  0.0  88524  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRJ-0003NA-V6
root     12977  0.0  0.1  88528  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRK-0003NI-2i
plddist  12978  0.0  0.0  88528  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRK-0003NI-2i
plddist  12980  0.0  0.0  88528  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRK-0003NI-2i
root     13009  0.0  0.1  88524  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRK-0003No-Os
plddist  13010  0.0  0.0  88524  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRK-0003No-Os
plddist  13012  0.0  0.0  88524  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRK-0003No-Os
root     13025  0.0  0.1  88528  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRL-0003O4-3R
plddist  13026  0.0  0.0  88528  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRL-0003O4-3R
plddist  13028  0.0  0.0  88528  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRL-0003O4-3R
root     13033  0.0  0.1  88520  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRL-0003OC-7G
plddist  13034  0.0  0.0  88520  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRL-0003OC-7G
plddist  13036  0.0  0.0  88520  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRL-0003OC-7G
root     13057  0.0  0.1  88528  5296 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRL-0003Oa-LF
plddist  13058  0.0  0.0  88528  2176 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRL-0003Oa-LF
plddist  13060  0.0  0.0  88528  1644 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRL-0003Oa-LF
root     13077  0.0  0.1  88520  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRL-0003Ou-Uq
plddist  13079  0.0  0.0  88520  2172 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRL-0003Ou-Uq
plddist  13081  0.0  0.0  88520  1640 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRL-0003Ou-Uq
root     13090  0.0  0.1  88516  5284 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRM-0003P7-5l
plddist  13091  0.0  0.0  88516  2160 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRM-0003P7-5l
plddist  13093  0.0  0.0  88516  1628 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRM-0003P7-5l
root     13099  0.0  0.1  88520  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRM-0003PG-AY
plddist  13100  0.0  0.0  88520  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRM-0003PG-AY
plddist  13102  0.0  0.0  88520  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRM-0003PG-AY
root     13107  0.0  0.1  88520  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRM-0003PO-Go
plddist  13108  0.0  0.0  88520  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRM-0003PO-Go
plddist  13110  0.0  0.0  88520  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRM-0003PO-Go
root     13132  0.0  0.1  88524  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRN-0003Pm-0Y
plddist  13133  0.0  0.0  88524  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRN-0003Pm-0Y
plddist  13135  0.0  0.0  88524  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRN-0003Pm-0Y
root     13165  0.0  0.1  88528  5296 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRN-0003QK-Lf
plddist  13166  0.0  0.0  88528  2172 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRN-0003QK-Lf
plddist  13168  0.0  0.0  88528  1640 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRN-0003QK-Lf
root     13181  0.0  0.1  88524  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRN-0003Qa-TA
plddist  13182  0.0  0.0  88524  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRN-0003Qa-TA
plddist  13184  0.0  0.0  88524  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRN-0003Qa-TA
root     13189  0.0  0.1  88520  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRO-0003Qi-0i
plddist  13190  0.0  0.0  88520  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRO-0003Qi-0i
plddist  13192  0.0  0.0  88520  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRO-0003Qi-0i
root     13205  0.0  0.1  88528  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRO-0003Qy-Ba
plddist  13206  0.0  0.0  88528  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRO-0003Qy-Ba
plddist  13208  0.0  0.0  88528  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRO-0003Qy-Ba
root     13221  0.0  0.1  88516  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRO-0003RE-NQ
plddist  13222  0.0  0.0  88516  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRO-0003RE-NQ
plddist  13224  0.0  0.0  88516  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRO-0003RE-NQ
root     13229  0.0  0.1  88520  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRO-0003RM-TL
plddist  13230  0.0  0.0  88520  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRO-0003RM-TL
plddist  13232  0.0  0.0  88520  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRO-0003RM-TL
root     13237  0.0  0.1  88528  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRP-0003RU-2N
plddist  13238  0.0  0.0  88528  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRP-0003RU-2N
plddist  13240  0.0  0.0  88528  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRP-0003RU-2N
root     13245  0.0  0.1  88528  5296 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRP-0003Rc-83
plddist  13246  0.0  0.0  88528  2176 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRP-0003Rc-83
plddist  13248  0.0  0.0  88528  1644 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRP-0003Rc-83
root     13253  0.1  0.1  88520  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRP-0003Rk-CJ
plddist  13254  0.0  0.0  88520  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRP-0003Rk-CJ
plddist  13256  0.0  0.0  88520  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRP-0003Rk-CJ
root     13261  0.0  0.1  88528  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRP-0003Rs-KR
plddist  13262  0.0  0.0  88528  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRP-0003Rs-KR
plddist  13264  0.0  0.0  88528  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRP-0003Rs-KR
root     13269  0.0  0.1  88520  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRP-0003S0-Oz
plddist  13270  0.0  0.0  88520  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRP-0003S0-Oz
plddist  13272  0.0  0.0  88520  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRP-0003S0-Oz
root     13277  0.0  0.1  88528  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRP-0003S8-Ty
plddist  13278  0.0  0.0  88528  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRP-0003S8-Ty
plddist  13280  0.0  0.0  88528  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRP-0003S8-Ty
root     13285  0.0  0.1  88528  5296 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRQ-0003SG-4m
plddist  13286  0.0  0.0  88528  2172 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRQ-0003SG-4m
plddist  13288  0.0  0.0  88528  1640 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRQ-0003SG-4m
root     13293  0.0  0.1  88528  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRQ-0003SO-CJ
plddist  13294  0.0  0.0  88528  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRQ-0003SO-CJ
plddist  13296  0.0  0.0  88528  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRQ-0003SO-CJ
root     13310  0.1  0.1  88528  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRQ-0003Sf-Kg
plddist  13311  0.0  0.0  88528  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRQ-0003Sf-Kg
plddist  13313  0.0  0.0  88528  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRQ-0003Sf-Kg
root     13347  0.0  0.1  88516  5284 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRR-0003TF-89
plddist  13348  0.0  0.0  88516  2160 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRR-0003TF-89
plddist  13350  0.0  0.0  88516  1628 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRR-0003TF-89
root     13355  0.0  0.1  88528  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRR-0003TO-C6
plddist  13356  0.0  0.0  88528  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRR-0003TO-C6
plddist  13358  0.0  0.0  88528  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRR-0003TO-C6
root     13363  0.0  0.1  88524  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRR-0003TW-G7
plddist  13364  0.0  0.0  88524  2172 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRR-0003TW-G7
plddist  13366  0.0  0.0  88524  1640 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRR-0003TW-G7
root     13371  0.0  0.1  88528  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRR-0003Te-K7
plddist  13372  0.0  0.0  88528  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRR-0003Te-K7
plddist  13374  0.0  0.0  88528  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRR-0003Te-K7
root     13379  0.0  0.1  88528  5296 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRR-0003Tm-Ns
plddist  13380  0.0  0.0  88528  2176 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRR-0003Tm-Ns
plddist  13382  0.0  0.0  88528  1644 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRR-0003Tm-Ns
root     13387  0.0  0.1  88520  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRR-0003Tu-S7
plddist  13388  0.0  0.0  88520  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRR-0003Tu-S7
plddist  13390  0.0  0.0  88520  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRR-0003Tu-S7
root     13395  0.0  0.1  88524  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRR-0003U2-W3
plddist  13396  0.0  0.0  88524  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRR-0003U2-W3
plddist  13398  0.0  0.0  88524  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRR-0003U2-W3
root     13419  0.0  0.1  88528  5296 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRS-0003UQ-Bo
plddist  13420  0.0  0.0  88528  2172 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRS-0003UQ-Bo
plddist  13422  0.0  0.0  88528  1640 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRS-0003UQ-Bo
root     13427  0.0  0.1  88520  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRS-0003UY-Fk
plddist  13428  0.0  0.0  88520  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRS-0003UY-Fk
plddist  13430  0.0  0.0  88520  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRS-0003UY-Fk
root     13443  0.0  0.1  88528  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRS-0003Uo-Mw
plddist  13444  0.0  0.0  88528  2172 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRS-0003Uo-Mw
plddist  13446  0.0  0.0  88528  1640 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRS-0003Uo-Mw
root     13451  0.0  0.1  88520  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRS-0003Uw-Qy
plddist  13452  0.0  0.0  88520  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRS-0003Uw-Qy
plddist  13454  0.0  0.0  88520  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRS-0003Uw-Qy
root     13459  0.0  0.1  88520  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRS-0003V4-Ut
plddist  13460  0.0  0.0  88520  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRS-0003V4-Ut
plddist  13462  0.0  0.0  88520  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRS-0003V4-Ut
root     13467  0.0  0.1  88524  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRT-0003VC-2S
plddist  13468  0.0  0.0  88524  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRT-0003VC-2S
plddist  13470  0.0  0.0  88524  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRT-0003VC-2S
root     13475  0.0  0.1  88520  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRT-0003VK-6C
plddist  13476  0.0  0.0  88520  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRT-0003VK-6C
plddist  13478  0.0  0.0  88520  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRT-0003VK-6C
root     13483  0.0  0.1  88520  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRT-0003VS-BZ
plddist  13484  0.0  0.0  88520  2172 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRT-0003VS-BZ
plddist  13486  0.0  0.0  88520  1640 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRT-0003VS-BZ
root     13491  0.0  0.1  88528  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRT-0003Va-FZ
plddist  13492  0.0  0.0  88528  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRT-0003Va-FZ
plddist  13494  0.0  0.0  88528  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRT-0003Va-FZ
root     13499  0.0  0.1  88528  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRT-0003Vi-MM
plddist  13500  0.0  0.0  88528  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRT-0003Vi-MM
plddist  13502  0.0  0.0  88528  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRT-0003Vi-MM
root     13507  0.0  0.1  88528  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRT-0003Vq-S6
plddist  13508  0.0  0.0  88528  2168 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRT-0003Vq-S6
plddist  13510  0.0  0.0  88528  1636 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRT-0003Vq-S6
root     13515  0.0  0.1  88520  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRU-0003Vy-0o
plddist  13516  0.0  0.0  88520  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRU-0003Vy-0o
plddist  13518  0.0  0.0  88520  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRU-0003Vy-0o
root     13523  0.0  0.1  88528  5296 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRU-0003W6-4r
plddist  13524  0.0  0.0  88528  2176 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRU-0003W6-4r
plddist  13526  0.0  0.0  88528  1644 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRU-0003W6-4r
root     13531  0.0  0.1  88516  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRU-0003WE-Ap
plddist  13532  0.0  0.0  88516  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRU-0003WE-Ap
plddist  13534  0.0  0.0  88516  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRU-0003WE-Ap
root     13539  0.0  0.1  88520  5292 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRU-0003WM-G2
plddist  13540  0.0  0.0  88520  2172 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRU-0003WM-G2
plddist  13542  0.0  0.0  88520  1640 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRU-0003WM-G2
root     13547  0.0  0.1  88520  5288 ?        SNs  14:37   0:00 
/usr/bin/exim -Mc 1SGqRU-0003WU-LJ
plddist  13548  0.0  0.0  88520  2164 ?        SN   14:37   0:00  \_ 
/usr/bin/exim -Mc 1SGqRU-0003WU-LJ
plddist  13550  0.0  0.0  88520  1632 ?        SN   14:37   0:00      \_ 
/usr/bin/exim -Mc 1SGqRU-0003WU-LJ
14:38:38 root[load: 18.13]@ep09-pld ~#

stopping exim, until somebody repairs this


On 08/04/12 14:35, Elan Ruusam?e wrote:
> making free space is not an option, something just eats it up!
>
> 14:35:03 root[load: 8.53]@ep09-pld ~/tmp# df .
> Filesystem     Type  Size  Used Avail Use% Mounted on
> /dev/sda4      xfs    80G   80G   14M 100% /home
> 14:35:04 root[load: 8.53]@ep09-pld ~/tmp# df .
> Filesystem     Type  Size  Used Avail Use% Mounted on
> /dev/sda4      xfs    80G   80G  8.0M 100% /home
> 14:35:07 root[load: 8.49]@ep09-pld ~/tmp# df .
> Filesystem     Type  Size  Used Avail Use% Mounted on
> /dev/sda4      xfs    80G   80G  7.4M 100% /home
> 14:35:09 root[load: 8.49]@ep09-pld ~/tmp# df .
> Filesystem     Type  Size  Used Avail Use% Mounted on
> /dev/sda4      xfs    80G   80G  6.9M 100% /home
>
>
> On 08/04/12 14:31, Elan Ruusam?e wrote:
>> AAAA!
>>
>> 14:30:42 pldth[load: 8.11]@ep09-pld SRPMS/RPMS$ date
>> Sun Apr  8 14:30:44 EEST 2012
>> 14:30:44 pldth[load: 8.11]@ep09-pld SRPMS/RPMS$ df ~
>> Filesystem     Type  Size  Used Avail Use% Mounted on
>> /dev/sda4      xfs    80G   80G   32K 100% /home
>>
>>
>> -------- Original Message --------
>> Subject:     Cron $HOME/pld-builder.new/bin/maintainer.sh
>> Date:     Sun, 08 Apr 2012 03:30:09 +0200
>> From:     builderth at ep09.pld-linux.org (Cron Daemon)
>> To:     builderth at ep09.pld-linux.org
>>
>>
>>
>> Traceback (most recent call last):
>>   File "PLD_Builder/maintainer.py", line 71, in<module>
>>     handle_src()
>>   File "PLD_Builder/maintainer.py", line 37, in handle_src
>>     send_rpmqa()
>>   File "PLD_Builder/maintainer.py", line 31, in send_rpmqa
>>     ftp.add(log)
>>   File "/home/pld/builderth/pld-builder.new/PLD_Builder/ftp.py", line 
>> 62, in add
>>     queue.add(f, type)
>>   File "/home/pld/builderth/pld-builder.new/PLD_Builder/ftp.py", line 
>> 35, in add
>>     shutil.copy(file, path.ftp_queue_dir + '/' + id)
>>   File "/usr/share/python2.7/shutil.py", line 116, in copy
>>   File "/usr/share/python2.7/shutil.py", line 83, in copyfile
>>   File "/usr/share/python2.7/shutil.py", line 51, in copyfileobj
>> IOError: [Errno 28] No space left on device
>>
>>
>> _______________________________________________
>> pld-devel-en mailing list
>> pld-devel-en at lists.pld-linux.org
>> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
>
>


-- 
glen



From glen at delfi.ee  Sun Apr  8 20:36:09 2012
From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Sun, 08 Apr 2012 21:36:09 +0300
Subject: Fwd: DISK FULL
In-Reply-To: <4F81790E.9020505@delfi.ee>
References: <E1SGgxF-0001UZ-0X@ep09.pld-linux.org> <4F817701.1010107@delfi.ee>
 <4F81781E.3090906@delfi.ee> <4F81790E.9020505@delfi.ee>
Message-ID: <4F81DA99.20503@delfi.ee>

On 08/04/12 14:39, Elan Ruusam?e wrote:
>
> stopping exim, until somebody repairs this
it's back now

caused by one small mail:
2012-04-03 11:51:12 1SF0OO-0000pw-Md <= hawk at limanowa.net H=limanowa.net 
[78.47.218.187] P=esmtp S=642 id=20120403095317.E938C23F300 at limanowa.net
2012-04-03 11:51:13 1SF0OO-0000pw-Md => plddist 
<plddist at ep09.pld-linux.org> R=procmail T=procmail_pipe
2012-04-03 11:51:13 1SF0OO-0000pw-Md Completed

plddist at ep09.pld-linux.org procmail rule no longer invoked

-- 
glen



From hawk at pld-linux.org  Mon Apr  9 02:57:53 2012
From: hawk at pld-linux.org (Marcin Krol)
Date: Mon, 09 Apr 2012 02:57:53 +0200
Subject: Fwd: DISK FULL
In-Reply-To: <4F81DA99.20503@delfi.ee>
References: <E1SGgxF-0001UZ-0X@ep09.pld-linux.org> <4F817701.1010107@delfi.ee>
 <4F81781E.3090906@delfi.ee> <4F81790E.9020505@delfi.ee>
 <4F81DA99.20503@delfi.ee>
Message-ID: <4F823411.9010204@pld-linux.org>

> it's back now
>
> caused by one small mail:

Seems like you'll need to fix distfiles mail handling. It was mail 
generated by packages/fetchsrc_request.

M.

P.S. And I must agree with shadzik here. Get a life.


From arekm at maven.pl  Mon Apr  9 08:28:00 2012
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Mon, 9 Apr 2012 08:28:00 +0200
Subject: Fwd: DISK FULL
In-Reply-To: <4F823411.9010204@pld-linux.org>
References: <E1SGgxF-0001UZ-0X@ep09.pld-linux.org> <4F81DA99.20503@delfi.ee>
 <4F823411.9010204@pld-linux.org>
Message-ID: <201204090828.00689.arekm@maven.pl>

On Monday 09 of April 2012, Marcin Krol wrote:
> > it's back now
> 
> > caused by one small mail:
> Seems like you'll need to fix distfiles mail handling. It was mail
> generated by packages/fetchsrc_request.

Are you sure it was it? Because fetchsrc_request in cvs uses different email 
for 9 years.

> M.

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


From hawk at pld-linux.org  Mon Apr  9 14:30:55 2012
From: hawk at pld-linux.org (Marcin Krol)
Date: Mon, 09 Apr 2012 14:30:55 +0200
Subject: Fwd: DISK FULL
In-Reply-To: <201204090828.00689.arekm@maven.pl>
References: <E1SGgxF-0001UZ-0X@ep09.pld-linux.org> <4F81DA99.20503@delfi.ee>
 <4F823411.9010204@pld-linux.org> <201204090828.00689.arekm@maven.pl>
Message-ID: <4F82D67F.5090008@pld-linux.org>

> Are you sure it was it? Because fetchsrc_request in cvs uses different email
> for 9 years.

Yes, I'm sure. I've sent this request from my very very old devel 
account. Didn't checked what destination mail was defined in it though.

M.


From przemo at firszt.eu  Tue Apr 10 10:41:47 2012
From: przemo at firszt.eu (Przemo Firszt)
Date: Tue, 10 Apr 2012 09:41:47 +0100
Subject: Git migration: next step
In-Reply-To: <20120405150100.GA29713@mail>
References: <20120403173410.GB12389@camk.edu.pl>
 <a917fc6e77b1dd38bc61b98d3b2b148e.squirrel@webmail.firszt.eu>
 <20120405150100.GA29713@mail>
Message-ID: <b173e363fe9fe6614ed7c9baf88e2468.squirrel@webmail.firszt.eu>


Dnia 5 Kwietnia 2012, 4:01 pm, Cz, Jakub Bogusz napisa?(a):
> On Thu, Apr 05, 2012 at 09:00:34AM +0100, Przemo Firszt wrote:
>>
[..]
>> Can we agree a naming convention? Something like:
>> "package-name: description" (it's similar to kernel patches)
>> i.e. "xorg-driver-input-wacom: up to 14.0.0" or
>> "xorg-driver-input-wacom: fix invalid BuildReq"?
>
> I don't find "package-name: " prefix useful, as there (AFAIK) will be
> one package per repository.
[..]
In the repository it's useless, but on the list, I think, it's quite
important: compare [1] and [2]. The subject of [1] is useless on the list.

The only problem I see is that some of the package name are quite long.

My idea: if the patch is going through the list it should contain package
name. If it's going to do directly to the repo there is no need for the
name.

[1] http://article.gmane.org/gmane.linux.pld.devel.english/7717/
[2] http://article.gmane.org/gmane.linux.pld.devel.english/7729/
-- 
Regards,
Przemo Firszt



From qboosh at pld-linux.org  Tue Apr 10 16:37:37 2012
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 10 Apr 2012 16:37:37 +0200
Subject: Git migration: next step
In-Reply-To: <b173e363fe9fe6614ed7c9baf88e2468.squirrel@webmail.firszt.eu>
References: <20120403173410.GB12389@camk.edu.pl>
 <a917fc6e77b1dd38bc61b98d3b2b148e.squirrel@webmail.firszt.eu>
 <20120405150100.GA29713@mail>
 <b173e363fe9fe6614ed7c9baf88e2468.squirrel@webmail.firszt.eu>
Message-ID: <20120410143737.GA15597@mail>

On Tue, Apr 10, 2012 at 09:41:47AM +0100, Przemo Firszt wrote:
> 
> Dnia 5 Kwietnia 2012, 4:01 pm, Cz, Jakub Bogusz napisa?(a):
> > On Thu, Apr 05, 2012 at 09:00:34AM +0100, Przemo Firszt wrote:
> >>
> [..]
> >> Can we agree a naming convention? Something like:
> >> "package-name: description" (it's similar to kernel patches)
> >> i.e. "xorg-driver-input-wacom: up to 14.0.0" or
> >> "xorg-driver-input-wacom: fix invalid BuildReq"?
> >
> > I don't find "package-name: " prefix useful, as there (AFAIK) will be
> > one package per repository.
> [..]
> In the repository it's useless, but on the list, I think, it's quite
> important: compare [1] and [2]. The subject of [1] is useless on the list.

Ah, you mean commit names in patches sent to the list, not committed.
Then package name is useful of course.

As of commit logs sent to the list - package (repo) name should be added
by commit log generator.


BTW - how changelog entries are made of git commit messages (wrt. "short"
and "long" part, to be concrete)?
I forgot about this difference between cvs and git.


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


From kornet at camk.edu.pl  Tue Apr 10 21:46:33 2012
From: kornet at camk.edu.pl (Kacper Kornet)
Date: Tue, 10 Apr 2012 21:46:33 +0200
Subject: Git migration: next step
In-Reply-To: <20120410143737.GA15597@mail>
References: <20120403173410.GB12389@camk.edu.pl>
 <a917fc6e77b1dd38bc61b98d3b2b148e.squirrel@webmail.firszt.eu>
 <20120405150100.GA29713@mail>
 <b173e363fe9fe6614ed7c9baf88e2468.squirrel@webmail.firszt.eu>
 <20120410143737.GA15597@mail>
Message-ID: <20120410194633.GA15441@camk.edu.pl>

On Tue, Apr 10, 2012 at 04:37:37PM +0200, Jakub Bogusz wrote:
> As of commit logs sent to the list - package (repo) name should be added
> by commit log generator.

If you mean mails sent after any push to the git central repository,
then it is the case. In the current setup subject line looks like:

Subject: packages/gitolite branch master updated. 4f3a4706b3e9be236adb5ef822d4d679033203f6

> BTW - how changelog entries are made of git commit messages (wrt. "short"
> and "long" part, to be concrete)?

Do you as about output of  rpm -q --changelog? It includes topic of git
commit message - part of the message up to the first blank line.

-- 
  Kacper Kornet


From mateusz-lists at ant.gliwice.pl  Mon Apr 16 12:34:55 2012
From: mateusz-lists at ant.gliwice.pl (Mateusz Korniak)
Date: Mon, 16 Apr 2012 12:34:55 +0200
Subject: mounting fe00 on /newroot failed (rootfs on LVM2 Th boot failure)
Message-ID: <201204161234.55672.mateusz-lists@ant.gliwice.pl>

On Monday 16 of April 2012, Arkadiusz Mi?kiewicz wrote:
> On Monday 16 of April 2012, Arkadiusz Mi?kiewicz wrote:
> > On Sunday 15 of April 2012, Lukasz Glebicki wrote:
> > > Naj?atwiej by?o by przekona? gruba aby korzysta? z /dev/grupa/wolumen
> > > lub /dev/dm-1, ale zawsze je zamienia.
> > > 
> > > pozdrawiam
> > 
> > Wrzu? jeszcze linuxrc z ?rodka geninitrd.
> 
> W og?le najlepiej by?o by przenie?? dyskusj? na pld-devel-en jako, ?e glen
> mo?e tu pom?c w usprawnieniu tego kodu.

OK.
Here goes my linuxrc too [1].
To state problem again in english:
Boot fails:
mounting fe00 on /newroot failed 
on new Th chroot installed system:
rootfs is on
  ACTIVE            '/dev/vg_single_disk/root' [4.87 GiB] inherit
on simple PV:
  PV /dev/hdb5   VG vg_single_disk   lvm2 [4.88 GiB / 4.00 MiB free]
  Total: 1 [4.88 GiB] / in use: 1 [4.88 GiB] / in no VG: 0 [0   ]

kernel-3.3.1-2.i686

During initrd generation I have [2], during failing boot [3]
Booted using lilo:
root=/dev/vg_single_disk/root


[2]
cat /proc/partitions
major minor  #blocks  name

   3        0   78150744 hda
   3        1     216846 hda1
   3        2   20482875 hda2
   3        3      72292 hda3
   3        4          1 hda4
   3        5     136521 hda5
   3        6    9775521 hda6
   3        7   46941898 hda7
   3        8     522081 hda8
   3       64   78150744 hdb
   3       65     128488 hdb1
   3       66      64260 hdb2
   3       67   10241437 hdb3
   3       68          1 hdb4
   3       69    5116671 hdb5
   3       70    9775521 hdb6
   3       71    9775521 hdb7
   3       72    9775521 hdb8
   3       73   33270583 hdb9
 254        0    5107712 dm-0
   9        6    9775360 md6

[3]:
http://dug.im/3f52a



[1]:
#!/bin/sh
# initrd generated by:
# $Revision: 12530 $ $Date:: 2012-03-30 14:41:13 +0000 #$

[ -f /proc/cmdline ] || mount -t proc none /proc
# builtin defaults from geninitrd
ROOT=/dev/vg_single_disk/root
ROOTFS=ext4
read CMDLINE < /proc/cmdline

for arg in $CMDLINE; do
if [ "${arg}" = "debuginitrd" ]; then
DEBUGINITRD=yes
fi
if [ "${arg##debuginitrd=}" != "${arg}" ]; then
DEBUGINITRD=${arg##debuginitrd=}
fi
if [ "${arg##root=}" != "${arg}" ]; then
ROOT=${arg##root=}
fi
if [ "${arg##rootfsflags=}" != "${arg}" ]; then
ROOTFSFLAGS=${arg##rootfsflags=}
fi
if [ "${arg##init=}" != "${arg}" ]; then
INIT=${arg##init=}
fi
done

# make debugshell() invoke subshell if $DEBUGINITRD=sh
if [ "$DEBUGINITRD" = "sh" ]; then
debugshell() {
echo "debug shell disabled by /etc/sysconfig/system: RUN_SULOGIN_ON_ERR 
setting"
}
else
debugshell() {
:
}
fi

if [ "$DEBUGINITRD" ]; then
set -x
fi
insmod /lib/modules/3.3.1-2/kernel/drivers/usb/usb-common.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/usb/core/usbcore.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/usb/host/ehci-hcd.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/mmc/core/mmc_core.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/pcmcia/pcmcia_core.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/pcmcia/pcmcia.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/ssb/ssb.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/usb/host/ohci-hcd.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/hid/hid.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/hid/usbhid/usbhid.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/ide/ide-core.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/ide/atiixp.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/ide/ide-gd_mod.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/md/dm-mod.ko 
insmod /lib/modules/3.3.1-2/kernel/lib/crc16.ko 
insmod /lib/modules/3.3.1-2/kernel/fs/mbcache.ko 
insmod /lib/modules/3.3.1-2/kernel/fs/jbd2/jbd2.ko 
insmod /lib/modules/3.3.1-2/kernel/fs/ext4/ext4.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/usb/host/uhci-hcd.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/i2c/i2c-core.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/hwmon/hwmon.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/i2c/algos/i2c-algo-bit.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/char/agp/agpgart.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/gpu/drm/drm.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/gpu/drm/ttm/ttm.ko 
insmod /lib/modules/3.3.1-2/kernel/drivers/gpu/drm/drm_kms_helper.ko 
echo -n /lib/firmware/firmware.sh > /proc/sys/kernel/hotplug
mount -t sysfs none /sys
insmod /lib/modules/3.3.1-2/kernel/drivers/gpu/drm/radeon/radeon.ko 
: 'Creating /dev'
if ! mount -t devtmpfs -o mode=0755,nosuid devtmpfs /dev > /dev/null 2>&1; 
then
mount -o mode=0755,nosuid -t tmpfs tmpfs /dev
mknod /dev/console c 5 1
mknod /dev/null c 1 3
mknod /dev/zero c 1 5
mknod /dev/random c 1 8
mknod /dev/snapshot c 10 231
mknod /dev/urandom c 1 9
mknod /dev/ptmx c 5 2
mknod /dev/kmsg c 1 11
fi
mkdir /dev/pts
mkdir /dev/shm
: 'Making device nodes'
cat /proc/partitions | (
# ignore first two lines: header, empty line
read b; read b

while read major minor blocks dev rest; do
node=/dev/$dev
mkdir -p ${node%/*}
[ -e $node ] || mknod $node b $major $minor
done
)
# if built with blkid change ROOT=LABEL=something into ROOT=/dev/somethingelse 
-
# parsed by blkid
if [ "${ROOT##LABEL=}" != "${ROOT}" -o "${ROOT##UUID=}" != "${ROOT}" ]; then
ROOT="$(/bin/blkid -t $ROOT -o device -l)"
fi
cat /etc/lvm.conf > /tmp/lvm.conf
ROOTDEV=/dev/vg_single_disk/root
LVM_ROOTVG="vg_single_disk"
LVM_SUSPENDVG=""
# parse rootdev from kernel commandline if it begins with /
case "$ROOT" in
/*)

# rewrite:
        # /dev/mapper/sys-rootfs -> /dev/sys/rootfs
# /dev/mapper/blodnatt-blah--bleh -> /dev/blodnatt/blah-bleh
# /dev/mapper/vg--meaw-root -> /dev/vg-meaw/root
case "$ROOT" in
/dev/mapper/*-*)
# change "--" to / (as "/" is impossible in LV name)
local dev=$(awk -vdev="${ROOT#/dev/mapper/}" 'BEGIN{gsub(/--/, "/", dev); 
print dev}')
local VG=$(awk -vdev="$dev" 'BEGIN{split(dev, v, "-"); gsub("/", "-", v[1]); 
print v[1]}')
local LV=$(awk -vdev="$dev" 'BEGIN{split(dev, v, "-"); gsub("/", "-", v[2]); 
print v[2]}')
ROOT=/dev/$VG/$LV
;;
esac

if [ "$ROOT" != "$ROOTDEV" ]; then
ROOTDEV=$ROOT

echo "LVM: Using 'root=$ROOTDEV' from kernel commandline"
local tmp=${ROOTDEV#/dev/}
if [ "$tmp" != "$ROOTDEV" ]; then
LVM_ROOTVG=${tmp%/*}
echo "LVM: Using Volume Group '$LVM_ROOTVG' for rootfs"
fi
fi
;;
esac

# skip duplicate VG
if [ "$LVM_SUSPENDVG" = "$LVM_ROOTVG" ]; then
LVM_VGVOLUMES="$LVM_ROOTVG"
else
LVM_VGVOLUMES="$LVM_SUSPENDVG $LVM_ROOTVG"
fi

# disable noise from LVM accessing devices that aren't ready.
read printk < /proc/sys/kernel/printk
if [ ! "$DEBUGINITRD" ]; then
echo 0 > /proc/sys/kernel/printk
fi

export LVM_SYSTEM_DIR=/tmp
: 'Scanning for Volume Groups'
lvm.static vgscan --mknodes --ignorelockingfailure 2>/dev/null

: 'Activating Volume Groups'
for vol in $LVM_VGVOLUMES; do
lvm.static vgchange --ignorelockingfailure -a y $vol 2>/dev/null
done

echo "$printk" > /proc/sys/kernel/printk

# Find out major/minor
attrs="$(lvm.static lvdisplay --ignorelockingfailure -c $ROOTDEV 2>/dev/null)"
if [ "$attrs" ]; then
majmin="${attrs#*$ROOTDEV*:*:*:*:*:*:*:*:*:*:*:*}"
if [ "$majmin" != "$attrs" ]; then
major="${majmin%:*}"
minor="${majmin#*:}"
fi
fi

if [ "$major" -a "$minor" ]; then
# Pass it to kernel
echo $((256 * $major + $minor)) > /proc/sys/kernel/real-root-dev
fi

unset LVM_SYSTEM_DIR
if [ "${ROOT##/dev/}" != "${ROOT}" ]; then
rootnr="$(busybox awk -v rootnode="${ROOT##/dev/}" '$4 == rootnode { print 256 
* $1 + $2 }' /proc/partitions)"
# fallback to ls
if [ -z "$rootnr" ]; then
rootnr="$(busybox ls -lL ${ROOT} | busybox awk '{if (/^b/) { print 256 * $3 + 
$4; }}')"
fi
if [ -n "$rootnr" ]; then
echo "$rootnr" > /proc/sys/kernel/real-root-dev
fi
fi
ifs=$IFS
IFS="
"
for i in $(export -p); do
i=${i#declare -x } # ksh/bash
i=${i#export } # busybox

case "$i" in
*=*)
: ;;
*)
continue ;;
esac

i=${i%%=*}

[ -z "$i" ] && continue

case "$i" in
ROOT|PATH|HOME|TERM)
:
;;
*)
unset $i
;;
esac
done
IFS=$ifs
                busybox cat /proc/partitions
                busybox ls -la /dev/vg_single_disk/root
                busybox ls -la /dev/mapper/vg_single_disk-root
device=
eval "$(busybox awk -v c="$ROOT" '
BEGIN {
num_pattern_short = "[0-9a-f][0-9a-f][0-9a-f]";
num_pattern = "[0-9a-f]" num_pattern_short;
dev_pattern = "[hms][a-z][a-z]([0-9])+";
partition = "";
min = -1; maj = -1;

sub("^0x", "", c);
if (c ~ "^" num_pattern_short "$") sub("^", "0", c);
if (c ~ "^" num_pattern  "$") {
maj = sprintf("%d",substr(c,1,2));
min = sprintf("%d",substr(c,3));
}
if (c ~ "^\/dev\/" dev_pattern "$") sub("^/dev/","", c);
if (c ~ "^" dev_pattern "$") partition = c;
}

partition && $4 == partition { maj = $1; min = $2; }
$1 == maj && $2 == min { partition = $4; }

END {
if (maj >= 0 && min >= 0) {
printf("maj=%s; min=%s;\n", maj, min);
}
if (partition) {
printf("device=/dev/%s;\n", partition);
}
}
' /proc/partitions)"

if [ -z "$device" ]; then
device=$ROOT
fi

if [ "$device" -a ! -b $device ]; then
mknod $device b $maj $min
fi

[ -n "$ROOTFSFLAGS" ] && ROOTFSFLAGS="-o $ROOTFSFLAGS"

mount -t $ROOTFS -r $device $ROOTFSFLAGS /newroot || echo "Mount of rootfs 
failed."
init=$INIT
if [ -z "$init" -o ! -x "/newroot$init" ]; then
init=/sbin/init
fi
: Last shell before umounting all and giving control over to real init.
debugshell
umount /dev
umount /sys
umount /proc
[ ! -e /newroot/dev/console ] && mknod -m 660 /newroot/dev/console c 5 1
exec switch_root /newroot $init ${1:+"$@"}

echo "Error! initramfs should not reach this place."
echo "It probably means you've got old version of busybox, with broken"
echo "initramfs support. Trying to boot anyway, but won't promise anything."

exec chroot /newroot $init ${1:+"$@"}

echo "Failed to chroot!"
debugshell



-- 
Mateusz Korniak
"(...) mam brata - powa?ny, domator, liczykrupa, hipokryta, pobo?ni?,
 	kr?tko m?wi?c - podpora spo?ecze?stwa."
				Nikos Kazantzakis - "Grek Zorba"

-- 
Mateusz Korniak


From glen at delfi.ee  Mon Apr 16 14:45:55 2012
From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Mon, 16 Apr 2012 15:45:55 +0300
Subject: mounting fe00 on /newroot failed (rootfs on LVM2 Th boot failure)
In-Reply-To: <201204161234.55672.mateusz-lists@ant.gliwice.pl>
References: <201204161234.55672.mateusz-lists@ant.gliwice.pl>
Message-ID: <4F8C1483.8040408@delfi.ee>

On 16.04.2012 13:34, Mateusz Korniak wrote:
> OK.
> Here goes my linuxrc too [1].
> To state problem again in english:
> Boot fails:
> mounting fe00 on /newroot failed

Committed revision 12546.

please test!

-- 
glen



From mateusz-lists at ant.gliwice.pl  Mon Apr 16 16:59:03 2012
From: mateusz-lists at ant.gliwice.pl (Mateusz Korniak)
Date: Mon, 16 Apr 2012 16:59:03 +0200
Subject: mounting fe00 on /newroot failed (rootfs on LVM2 Th boot failure)
In-Reply-To: <4F8C1483.8040408@delfi.ee>
References: <201204161234.55672.mateusz-lists@ant.gliwice.pl>
 <4F8C1483.8040408@delfi.ee>
Message-ID: <201204161659.04523.mateusz-lists@ant.gliwice.pl>

On Monday 16 of April 2012, Elan Ruusam?e wrote:
> On 16.04.2012 13:34, Mateusz Korniak wrote:
> > OK.
> > Here goes my linuxrc too [1].
> > To state problem again in english:
> > Boot fails:
> > mounting fe00 on /newroot failed
> 
> Committed revision 12546.


Results pretty same :( to me:

http://dug.im/57f73


-- 
Mateusz Korniak


From glen at delfi.ee  Mon Apr 16 17:53:05 2012
From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Mon, 16 Apr 2012 18:53:05 +0300
Subject: mounting fe00 on /newroot failed (rootfs on LVM2 Th boot failure)
In-Reply-To: <201204161659.04523.mateusz-lists@ant.gliwice.pl>
References: <201204161234.55672.mateusz-lists@ant.gliwice.pl>
 <4F8C1483.8040408@delfi.ee> <201204161659.04523.mateusz-lists@ant.gliwice.pl>
Message-ID: <4F8C4061.2010401@delfi.ee>

On 16.04.2012 17:59, Mateusz Korniak wrote:
> On Monday 16 of April 2012, Elan Ruusam?e wrote:
>> On 16.04.2012 13:34, Mateusz Korniak wrote:
>>> OK.
>>> Here goes my linuxrc too [1].
>>> To state problem again in english:
>>> Boot fails:
>>> mounting fe00 on /newroot failed
>> Committed revision 12546.
>
> Results pretty same :( to me:
>
> http://dug.im/57f73
>

post geninitrd -v output from that geninitrd version

-- 
glen



From lukaszgl at post.pl  Mon Apr 16 17:53:42 2012
From: lukaszgl at post.pl (Lukasz Glebicki)
Date: Mon, 16 Apr 2012 17:53:42 +0200
Subject: geninitrd nie wie co to 0ede
In-Reply-To: <201204161107.41170.arekm@maven.pl>
References: <1519053.oxBM3I6JaW@inhell> <201204161100.18238.arekm@maven.pl>
 <201204161107.41170.arekm@maven.pl>
Message-ID: <3218803.x5sMmNUzDq@inhell>

On Monday 16 of April 2012 11:07:41 Arkadiusz Mi?kiewicz wrote:
> On Monday 16 of April 2012, Arkadiusz Mi?kiewicz wrote:
> > On Sunday 15 of April 2012, Lukasz Glebicki wrote:
> > > Naj?atwiej by?o by przekona? gruba aby korzysta? z /dev/grupa/wolumen
> > > lub
> > > /dev/dm-1, ale zawsze je zamienia.
> > > 
> > > pozdrawiam
> > 
> > Wrzu? jeszcze linuxrc z ?rodka geninitrd.
> 
> W og?le najlepiej by?o by przenie?? dyskusj? na pld-devel-en jako, ?e glen
> mo?e tu pom?c w usprawnieniu tego kodu.

Here is the linuxrc code:

http://pastebin.com/9sMdy2XC

The problem is that I have root partition on LVM which stands on mdadm mirror 
array.

After latest changes, geninitrd doesn't generate proper inframfs image.

Grub config contains root=0edc and initrd fails on mounting 0edc.

System hangs on:
http://dug.im/015c5

I have to change 0edc to /dev/datavg/rootlv in grub.conf to boot property.

After analizing of system logs I see that root=0edc was working fine.

My geninitrd: http://pastebin.com/EHYD5Fy8

-- 
?ukasz G??bicki  mail/rot13:yhxnfmty at cbfg.cy  PLD/Linux Team
gg:246267    Linux Registered User #318551   blekot:{irc,skype}

From glen at delfi.ee  Mon Apr 16 18:24:31 2012
From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Mon, 16 Apr 2012 19:24:31 +0300
Subject: geninitrd nie wie co to 0ede
In-Reply-To: <3218803.x5sMmNUzDq@inhell>
References: <1519053.oxBM3I6JaW@inhell> <201204161100.18238.arekm@maven.pl>
 <201204161107.41170.arekm@maven.pl> <3218803.x5sMmNUzDq@inhell>
Message-ID: <4F8C47BF.7030502@delfi.ee>

On 16.04.2012 18:53, Lukasz Glebicki wrote:
> Grub config contains root=0edc and initrd fails on mounting 0edc.
>
> System hangs on:
> http://dug.im/015c5

that root=0edc makes no sense...

14, 197 device is what in your real system?

ls -l /dev| grep 14,|grep 197

also the screenshot does not seem to match any pld geninitrd image, at 
least i don't see where /proc/partitions contents could be dumped into 
console
and your linuxrc you showed,. doesn't have sulogin enabled, so you could 
had typed yourself it (by booting with debuginitrd=sh kernel commandline)

and not clear how /run could not be mounted there, as well why 
/proc/partitions is missing

first try geninitrd svn trunk (at least r12546)

if that still fails, attach geninitrd -v ... output

>  I have to change 0edc to /dev/datavg/rootlv in grub.conf to boot property.


why you have cryptic "0edc" anyway, i could understand lilo what 
enforces it, but why in grub?

and root= argument itself is optional, if you don't plan to use root 
which was present at geninitrd generation time (the root= value is 
"burned in" to initrd at generation time)

-- 
glen



From lukaszgl at post.pl  Mon Apr 16 19:22:02 2012
From: lukaszgl at post.pl (Lukasz Glebicki)
Date: Mon, 16 Apr 2012 19:22:02 +0200
Subject: geninitrd nie wie co to 0ede
In-Reply-To: <4F8C47BF.7030502@delfi.ee>
References: <1519053.oxBM3I6JaW@inhell> <3218803.x5sMmNUzDq@inhell>
 <4F8C47BF.7030502@delfi.ee>
Message-ID: <1419226.7o9D9avHfi@inhell>

On Monday 16 of April 2012 19:24:31 Elan Ruusam?e wrote:

> that root=0edc makes no sense...

> 14, 197 device is what in your real system?
> 
> ls -l /dev| grep 14,|grep 197

No. There is not such a device. The better is that it was working before 
problems.

It looks like I'm using 0edc since I have added new disk, which doesn't 
belongs to array.

Feb 15 18:40:42 inhell kernel: [    0.000000] Command line: root=0edc  
ramdisk_size=6144 resume=/dev/datavg/swaplv

lilo.conf contains proper definition of root (/dev/datavg/rootlv)

> 
> also the screenshot does not seem to match any pld geninitrd image, at
> least i don't see where /proc/partitions contents could be dumped into
> console
> and your linuxrc you showed,. doesn't have sulogin enabled, so you could
> had typed yourself it (by booting with debuginitrd=sh kernel commandline)

I have added cat /proc/partitions to see what devices are during initrd.
> 
> and not clear how /run could not be mounted there, as well why
> /proc/partitions is missing
> 
> first try geninitrd svn trunk (at least r12546)
> 
> if that still fails, attach geninitrd -v ... output

http://pastebin.com/McA1ZKzg

> why you have cryptic "0edc" anyway, i could understand lilo what
> enforces it, but why in grub?

rc-boot or grubby.

http://pastebin.com/1bPfU9RR

After kernel reinstall (see logs above) i have proper lilo.conf and buggy 
menu.lst, which are modified after kernel reinstallation:

[root at inhell ~]# ls -l /boot/grub/menu.lst /etc/lilo.conf
-rw------- 2 root root 465 04-16 19:15 /boot/grub/menu.lst
-rw------- 1 root root 513 04-16 19:15 /etc/lilo.conf



-- 
?ukasz G??bicki  mail/rot13:yhxnfmty at cbfg.cy  PLD/Linux Team
gg:246267    Linux Registered User #318551   blekot:{irc,skype}


From glen at delfi.ee  Mon Apr 16 19:41:09 2012
From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Mon, 16 Apr 2012 20:41:09 +0300
Subject: geninitrd nie wie co to 0ede
In-Reply-To: <1419226.7o9D9avHfi@inhell>
References: <1519053.oxBM3I6JaW@inhell> <3218803.x5sMmNUzDq@inhell>
 <4F8C47BF.7030502@delfi.ee> <1419226.7o9D9avHfi@inhell>
Message-ID: <4F8C59B5.9010505@delfi.ee>

On 04/16/12 20:22, Lukasz Glebicki wrote:
> On Monday 16 of April 2012 19:24:31 Elan Ruusam?e wrote:
>
>> >  that root=0edc makes no sense...
>> >  14, 197 device is what in your real system?
>> >  
>> >  ls -l /dev| grep 14,|grep 197
> No. There is not such a device. The better is that it was working before
> problems.
>
> It looks like I'm using 0edc since I have added new disk, which doesn't
> belongs to array.
>
> Feb 15 18:40:42 inhell kernel: [    0.000000] Command line: root=0edc
> ramdisk_size=6144 resume=/dev/datavg/swaplv
afaik, earlier root= which was not parsed properly, was just ignored, 
like you hadn't specified it at all (and burned in default was used)

i'm pretty sure you could boot that same kernel/initrd (successfully) 
also with:

root=i_hate_mondays ramdisk_size=6144 resume=/dev/datavg/swaplv



-- 
glen



From glen at pld-linux.org  Mon Apr 16 19:49:48 2012
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Mon, 16 Apr 2012 20:49:48 +0300
Subject: geninitrd nie wie co to 0ede
In-Reply-To: <1419226.7o9D9avHfi@inhell>
References: <1519053.oxBM3I6JaW@inhell> <3218803.x5sMmNUzDq@inhell>
 <4F8C47BF.7030502@delfi.ee> <1419226.7o9D9avHfi@inhell>
Message-ID: <4F8C5BBC.1040508@pld-linux.org>

On 04/16/12 20:22, Lukasz Glebicki wrote:
>> >  why you have cryptic "0edc" anyway, i could understand lilo what
>> >  enforces it, but why in grub?
> rc-boot or grubby.
>
> http://pastebin.com/1bPfU9RR
duh, that's heavy

grubby probes all boot loaders, lilo, grub, etc. so if you use grub, 
remove lilo from system so grubby won't  try to poke it

also if you have grubby present, you don't need rc-boot at all, each new 
kernel is added to bootloader by it

that grub probe looks suspicious too, it's from rc-boot?

what i suggest:
- remove lilo
- remove rc-boot
- keep grubby
- setup grub in boot sector
# grub-install '(hd0)'
or
# grub-install /dev/md0
devices.lst might need to be adjusted here
- put root=/dev/datavg/rootlv to menu.lst of grub

next time kernel is installed, grubby will copy commandline from default 
entry from menu.lst

otherwise, i don't know how to fix root=0edc parsing (i find no logic 
behind it how to translate it to device node), needs lilo sources 
peeking, did not found anything in first place from google. perhaps that 
lilo you're using is just buggy?

-- 
glen



From lukaszgl at post.pl  Mon Apr 16 19:58:55 2012
From: lukaszgl at post.pl (Lukasz Glebicki)
Date: Mon, 16 Apr 2012 19:58:55 +0200
Subject: geninitrd nie wie co to 0ede
In-Reply-To: <4F8C59B5.9010505@delfi.ee>
References: <1519053.oxBM3I6JaW@inhell> <1419226.7o9D9avHfi@inhell>
 <4F8C59B5.9010505@delfi.ee>
Message-ID: <2698616.vOsSRulYni@inhell>

On Monday 16 of April 2012 20:41:09 Elan Ruusam?e wrote:

> afaik, earlier root= which was not parsed properly, was just ignored,
> like you hadn't specified it at all (and burned in default was used)
> 
> i'm pretty sure you could boot that same kernel/initrd (successfully)
> also with:
> 
> root=i_hate_mondays ramdisk_size=6144 resume=/dev/datavg/swaplv

So why I have to replace 0edc to /dev/datavg/rootlv to boot ?

http://dug.im/44f7d

This is screenshot from latest geninitrd taken from trunk.

I'm using this configuration since:
Linux version 2.6.31.7-1 (builder at ymir-builder) (gcc version 4.4.2 20091026 
(release) (PLD-Linux) ) #1 SMP Wed Dec 9 10:09:49 CET 2009
Dec 16 18:15:23 inhell kernel: [    0.000000] Command line: auto 
BOOT_IMAGE=pld ro root=803 resume2=swap:/dev/sda2 silent 
video=vesafb:1024x768-32 at 100


egrep -o "root=[0-Z]{3,4}" /var/log/kernel |uniq -c
Look at this grep:

  1190 root=803
      4 root=fe04
     68 root=fe01
    130 root=1901
     60 root=1902
    110 root=1904
     84 root=1905
    126 root=1907
     22 root=1908
     52 root=1909
     28 root=fe01
     48 root=1909
     40 root=190a
      2 root=0701
     38 root=0edc
     18 root=0702
     91 root=0703
     61 root=0edc



-- 
?ukasz G??bicki  mail/rot13:yhxnfmty at cbfg.cy  PLD/Linux Team
gg:246267    Linux Registered User #318551   blekot:{irc,skype}


From glen at pld-linux.org  Mon Apr 16 20:00:03 2012
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Mon, 16 Apr 2012 21:00:03 +0300
Subject: geninitrd nie wie co to 0ede
In-Reply-To: <4F8C5BBC.1040508@pld-linux.org>
References: <1519053.oxBM3I6JaW@inhell> <3218803.x5sMmNUzDq@inhell>
 <4F8C47BF.7030502@delfi.ee> <1419226.7o9D9avHfi@inhell>
 <4F8C5BBC.1040508@pld-linux.org>
Message-ID: <4F8C5E23.6020000@pld-linux.org>

On 04/16/12 20:49, Elan Ruusam?e wrote:
> otherwise, i don't know how to fix root=0edc parsing (i find no logic 
> behind it how to translate it to device node), needs lilo sources 
> peeking, did not found anything in first place from google. perhaps 
> that lilo you're using is just buggy?
>

quick looking at lilo-23.2 sources, you could have better luck if you 
specify your root as:

root=/dev/mapper/datavg-rootlv
or just:
root=current

and you *can* say exact root= parameter you want with append=:
append="root=/dev/mapper/datavg-rootlv"

the last bit is from README

-- glen


From glen at pld-linux.org  Mon Apr 16 20:04:55 2012
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Mon, 16 Apr 2012 21:04:55 +0300
Subject: geninitrd nie wie co to 0ede
In-Reply-To: <2698616.vOsSRulYni@inhell>
References: <1519053.oxBM3I6JaW@inhell> <1419226.7o9D9avHfi@inhell>
 <4F8C59B5.9010505@delfi.ee> <2698616.vOsSRulYni@inhell>
Message-ID: <4F8C5F47.9010009@pld-linux.org>

On 04/16/12 20:58, Lukasz Glebicki wrote:
> On Monday 16 of April 2012 20:41:09 Elan Ruusam?e wrote:
>
>> afaik, earlier root= which was not parsed properly, was just ignored,
>> like you hadn't specified it at all (and burned in default was used)
>>
>> i'm pretty sure you could boot that same kernel/initrd (successfully)
>> also with:
>>
>> root=i_hate_mondays ramdisk_size=6144 resume=/dev/datavg/swaplv
> So why I have to replace 0edc to /dev/datavg/rootlv to boot ?
because as i said earlier mails:
  recent geninitrd changes do not ignore invalid root=xxx param

> http://dug.im/44f7d
>
> This is screenshot from latest geninitrd taken from trunk.
>
> I'm using this configuration since:
> Linux version 2.6.31.7-1 (builder at ymir-builder) (gcc version 4.4.2 20091026
> (release) (PLD-Linux) ) #1 SMP Wed Dec 9 10:09:49 CET 2009
> Dec 16 18:15:23 inhell kernel: [    0.000000] Command line: auto
> BOOT_IMAGE=pld ro root=803 resume2=swap:/dev/sda2 silent
> video=vesafb:1024x768-32 at 100
>
>
> egrep -o "root=[0-Z]{3,4}" /var/log/kernel |uniq -c
> Look at this grep:
>
>    1190 root=803
>        4 root=fe04
>       68 root=fe01
>      130 root=1901
>       60 root=1902
>      110 root=1904
>       84 root=1905
>      126 root=1907
>       22 root=1908
>       52 root=1909
>       28 root=fe01
>       48 root=1909
>       40 root=190a
>        2 root=0701
>       38 root=0edc
>       18 root=0702
>       91 root=0703
>       61 root=0edc
this just shows how random values lilo passes there

-- 
glen



From lukaszgl at post.pl  Mon Apr 16 20:10:09 2012
From: lukaszgl at post.pl (Lukasz Glebicki)
Date: Mon, 16 Apr 2012 20:10:09 +0200
Subject: geninitrd nie wie co to 0ede
In-Reply-To: <4F8C5F47.9010009@pld-linux.org>
References: <1519053.oxBM3I6JaW@inhell> <2698616.vOsSRulYni@inhell>
 <4F8C5F47.9010009@pld-linux.org>
Message-ID: <12593021.82RrSbOiK7@inhell>

On Monday 16 of April 2012 21:04:55 Elan Ruusam?e wrote:
 
> because as i said earlier mails:
>   recent geninitrd changes do not ignore invalid root=xxx param

This claryfy the situation why now it doesn't work.

> 
> this just shows how random values lilo passes there

It's grub not lilo.

So I'll do cleaning written in your previous mail.

-- 
?ukasz G??bicki  mail/rot13:yhxnfmty at cbfg.cy  PLD/Linux Team
gg:246267    Linux Registered User #318551   blekot:{irc,skype}


From mateusz-lists at ant.gliwice.pl  Tue Apr 17 10:05:31 2012
From: mateusz-lists at ant.gliwice.pl (Mateusz Korniak)
Date: Tue, 17 Apr 2012 10:05:31 +0200
Subject: mounting fe00 on /newroot failed (rootfs on LVM2 Th boot failure)
Message-ID: <201204171005.31700.mateusz-lists@ant.gliwice.pl>

On Monday 16 of April 2012, Elan Ruusam?e wrote:
> On 16.04.2012 17:59, Mateusz Korniak wrote:
> > On Monday 16 of April 2012, Elan Ruusam?e wrote:
> > http://dug.im/57f73
> 
First of all, booting via lilo without root= specified  works, so it's no 
longer problem for me. I thought it's mandatory for lilo until you enlighted 
me. Big thanks !

> post geninitrd -v output from that geninitrd version
I can only supply with most recent (and untested if boots) version:( :

$ svn up
Updating '.':
U    geninitrd
U    functions
Updated to revision 12549.

$ sudo ./geninitrd /boot/initrd-3.3.1-2.gz 3.3.1-2 -v -f 
geninitrd: # $Revision: 12549 $ $Date:: 2012-04-16 20:14:37 +0200 #$ 
(geninitrd)
geninitrd: Using _lib: lib
geninitrd: Using initrd_dir: /usr/lib/initrd
geninitrd: find_tool: found /usr/lib/initrd/busybox
geninitrd: # $Revision: 12458 $ $Date:: 2012-01-05 19:43:32 +0000 #$ (mod-ide)
geninitrd: # $Revision: 12444 $ $Date:: 2011-12-07 19:32:09 +0000 #$ (mod-
luks)
geninitrd: find_tool: did not find any of: /usr/lib/initrd/cryptsetup 
/sbin/cryptsetup-initrd
geninitrd: # $Revision: 12169 $ $Date:: 2011-02-19 13:59:40 +0000 #$ (mod-
multipath)
geninitrd: # $Revision: 12169 $ $Date:: 2011-02-19 13:59:40 +0000 #$ (mod-
dmraid)
geninitrd: find_tool: did not find any of: /usr/lib/initrd/dmraid 
/sbin/dmraid-initrd
geninitrd: # $Revision: 12504 $ $Date:: 2012-03-19 19:34:11 +0000 #$ (mod-lvm)                                                                                                                                                              
geninitrd: find_tool: found /usr/lib/initrd/lvm                                                                                                                                                                                             
geninitrd: # $Revision: 12377 $ $Date:: 2011-10-15 13:49:57 +0000 #$ (mod-md)                                                                                                                                                               
geninitrd: find_tool: found /usr/lib/initrd/mdassemble                                                                                                                                                                                      
geninitrd: find_tool: found /sbin/mdadm                                                                                                                                                                                                     
geninitrd: # $Revision: 12169 $ $Date:: 2011-02-19 13:59:40 +0000 #$ (mod-
blkid)                                                                                                                                                            
geninitrd: find_tool: found /usr/lib/initrd/blkid                                                                                                                                                                                           
geninitrd: # $Revision: 12502 $ $Date:: 2012-03-18 19:25:59 +0000 #$ (mod-
udev)                                                                                                                                                             
geninitrd: find_tool: found /usr/lib/initrd/udevd                                                                                                                                                                                           
geninitrd: find_tool: found /usr/lib/initrd/udevadm                                                                                                                                                                                         
geninitrd: # $Revision: 12169 $ $Date:: 2011-02-19 13:59:40 +0000 #$ (mod-
tuxonice)                                                                                                                                                         
geninitrd: # $Revision: 12500 $ $Date:: 2012-03-18 16:32:24 +0000 #$ (mod-
suspend)                                                                                                                                                          
geninitrd: find_tool: did not find any of: /usr/lib/initrd/resume 
/usr/lib/suspend/resume /usr/sbin/resume                                                                                                                                  
geninitrd: # $Revision: 12169 $ $Date:: 2011-02-19 13:59:40 +0000 #$ (mod-
fbsplash)                                                                                                                                                         
geninitrd: find_tool: did not find any of: /usr/sbin/splash_geninitramfs 
/usr/bin/splash_geninitramfs                                                                                                                                       
geninitrd: # $Revision: 12169 $ $Date:: 2011-02-19 13:59:40 +0000 #$ (mod-
condecor)                                                                                                                                                         
geninitrd: find_tool: did not find any of: /usr/sbin/splash_geninitramfs 
/usr/bin/splash_geninitramfs                                                                                                                                       
geninitrd: # $Revision: 12169 $ $Date:: 2011-02-19 13:59:40 +0000 #$ (mod-
bootsplash)                                                                                                                                                       
geninitrd: find_tool: did not find any of: /bin/splash.bin                                                                                                                                                                                  
geninitrd: # $Revision: 12327 $ $Date:: 2011-08-19 19:40:53 +0000 #$ (mod-
uvesafb)                                                                                                                                                          
geninitrd: find_tool: did not find any of: /usr/lib/initrd/v86d /sbin/v86d                                                                                                                                                                  
geninitrd: # $Revision: 12169 $ $Date:: 2011-02-19 13:59:40 +0000 #$ (mod-nfs)                                                                                                                                                              
geninitrd: # $Revision: 12415 $ $Date:: 2011-11-27 14:03:41 +0000 #$ (mod-
sata)                                                                                                                                                             
geninitrd: # $Revision: 12458 $ $Date:: 2012-01-05 19:43:32 +0000 #$ (mod-
scsi)                                                                                                                                                             
geninitrd: # $Revision: 12512 $ $Date:: 2012-03-24 18:27:54 +0000 #$ (mod-
usbkbd)                                                                                                                                                           
geninitrd: Using modprobe -c to get modules config                                                                                                                                                                                          
geninitrd: Finding USB keyboard modules                                                                                                                                                                                                     
geninitrd: Found USB Keyboard: LITEON Technology USB Multimedia Keyboard                                                                                                                                                                    
geninitrd: Finding SATA modules (class=0x0106)
geninitrd: Using /dev/vg_single_disk/root as device for rootfs
geninitrd: Finding modules for device path /dev/vg_single_disk/root
geninitrd: LVM: /dev/vg_single_disk/root is LVM node
geninitrd: LVM VG for /dev/vg_single_disk/root: vg_single_disk
geninitrd: LVM PV for vg_single_disk: /dev/hdb5
geninitrd: Finding modules for device path /dev/hdb5
geninitrd: Finding IDE modules using ide_hostadapter
geninitrd: Finding IDE modules using PCI ID database
geninitrd: LVM v2 enabled
geninitrd: Building initrd...
geninitrd: + cp /usr/lib/initrd/busybox /tmp/initrd.ZPYQ5l/bin/busybox
geninitrd: Loading module [usb-common]
geninitrd: Loading module [usbcore]
geninitrd: Loading module [ehci-hcd]
geninitrd: Loading module [mmc_core]
geninitrd: Loading module [pcmcia_core]
geninitrd: Loading module [pcmcia]
geninitrd: Loading module [ssb]
geninitrd: Loading module [ohci-hcd]
geninitrd: Loading module [hid]
geninitrd: Loading module [usbhid]
geninitrd: Loading module [ide-core]
geninitrd: Loading module [atiixp]
geninitrd: Loading module [ide-gd_mod]
geninitrd: Loading module [dm-mod]
geninitrd: Loading module [crc16]
geninitrd: Loading module [mbcache]
geninitrd: Loading module [jbd2]
geninitrd: Loading module [ext4]
geninitrd: Loading module [uhci-hcd]
geninitrd: Loading module [i2c-core]
geninitrd: Loading module [hwmon]
geninitrd: Loading module [i2c-algo-bit]
geninitrd: Loading module [agpgart]
geninitrd: Loading module [drm]
geninitrd: Loading module [ttm]
geninitrd: Loading module [drm_kms_helper]
geninitrd: Loading module [radeon]
geninitrd: Adding Firmwares (radeon/R520_cp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/R520_cp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/R520_cp.bin
geninitrd: Adding Firmwares (radeon/RS600_cp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RS600_cp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RS600_cp.bin
geninitrd: Adding Firmwares (radeon/RS690_cp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RS690_cp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RS690_cp.bin
geninitrd: Adding Firmwares (radeon/R420_cp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/R420_cp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/R420_cp.bin
geninitrd: Adding Firmwares (radeon/R300_cp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/R300_cp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/R300_cp.bin
geninitrd: Adding Firmwares (radeon/R200_cp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/R200_cp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/R200_cp.bin
geninitrd: Adding Firmwares (radeon/R100_cp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/R100_cp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/R100_cp.bin
geninitrd: Adding Firmwares (radeon/RV710_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV710_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV710_me.bin
geninitrd: Adding Firmwares (radeon/RV710_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV710_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV710_pfp.bin
geninitrd: Adding Firmwares (radeon/RV730_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV730_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV730_me.bin
geninitrd: Adding Firmwares (radeon/RV730_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV730_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV730_pfp.bin
geninitrd: Adding Firmwares (radeon/RV770_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV770_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV770_me.bin
geninitrd: Adding Firmwares (radeon/RV770_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV770_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV770_pfp.bin
geninitrd: Adding Firmwares (radeon/RS780_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RS780_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RS780_me.bin
geninitrd: Adding Firmwares (radeon/RS780_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RS780_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RS780_pfp.bin
geninitrd: Adding Firmwares (radeon/RV670_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV670_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV670_me.bin
geninitrd: Adding Firmwares (radeon/RV670_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV670_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV670_pfp.bin
geninitrd: Adding Firmwares (radeon/RV635_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV635_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV635_me.bin
geninitrd: Adding Firmwares (radeon/RV635_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV635_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV635_pfp.bin
geninitrd: Adding Firmwares (radeon/RV620_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV620_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV620_me.bin
geninitrd: Adding Firmwares (radeon/RV620_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV620_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV620_pfp.bin
geninitrd: Adding Firmwares (radeon/RV630_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV630_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV630_me.bin
geninitrd: Adding Firmwares (radeon/RV630_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV630_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV630_pfp.bin
geninitrd: Adding Firmwares (radeon/RV610_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV610_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV610_me.bin
geninitrd: Adding Firmwares (radeon/RV610_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV610_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV610_pfp.bin
geninitrd: Adding Firmwares (radeon/R600_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/R600_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/R600_me.bin
geninitrd: Adding Firmwares (radeon/R600_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/R600_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/R600_pfp.bin
geninitrd: Adding Firmwares (radeon/R520_cp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/R520_cp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/R520_cp.bin
geninitrd: Adding Firmwares (radeon/RS600_cp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RS600_cp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RS600_cp.bin
geninitrd: Adding Firmwares (radeon/RS690_cp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RS690_cp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RS690_cp.bin
geninitrd: Adding Firmwares (radeon/R420_cp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/R420_cp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/R420_cp.bin
geninitrd: Adding Firmwares (radeon/R300_cp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/R300_cp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/R300_cp.bin
geninitrd: Adding Firmwares (radeon/R200_cp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/R200_cp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/R200_cp.bin
geninitrd: Adding Firmwares (radeon/R100_cp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/R100_cp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/R100_cp.bin
geninitrd: Adding Firmwares (radeon/SUMO2_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/SUMO2_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/SUMO2_me.bin
geninitrd: Adding Firmwares (radeon/SUMO2_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/SUMO2_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/SUMO2_pfp.bin
geninitrd: Adding Firmwares (radeon/SUMO_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/SUMO_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/SUMO_me.bin
geninitrd: Adding Firmwares (radeon/SUMO_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/SUMO_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/SUMO_pfp.bin
geninitrd: Adding Firmwares (radeon/SUMO_rlc.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/SUMO_rlc.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/SUMO_rlc.bin
geninitrd: Adding Firmwares (radeon/PALM_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/PALM_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/PALM_me.bin
geninitrd: Adding Firmwares (radeon/PALM_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/PALM_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/PALM_pfp.bin
geninitrd: Adding Firmwares (radeon/CYPRESS_rlc.bin) to initrd for module 
radeon
geninitrd: + cp /lib/firmware/radeon/CYPRESS_rlc.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/CYPRESS_rlc.bin
geninitrd: Adding Firmwares (radeon/CYPRESS_me.bin) to initrd for module 
radeon
geninitrd: + cp /lib/firmware/radeon/CYPRESS_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/CYPRESS_me.bin
geninitrd: Adding Firmwares (radeon/CYPRESS_pfp.bin) to initrd for module 
radeon
geninitrd: + cp /lib/firmware/radeon/CYPRESS_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/CYPRESS_pfp.bin
geninitrd: Adding Firmwares (radeon/JUNIPER_rlc.bin) to initrd for module 
radeon
geninitrd: + cp /lib/firmware/radeon/JUNIPER_rlc.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/JUNIPER_rlc.bin
geninitrd: Adding Firmwares (radeon/JUNIPER_me.bin) to initrd for module 
radeon
geninitrd: + cp /lib/firmware/radeon/JUNIPER_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/JUNIPER_me.bin
geninitrd: Adding Firmwares (radeon/JUNIPER_pfp.bin) to initrd for module 
radeon
geninitrd: + cp /lib/firmware/radeon/JUNIPER_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/JUNIPER_pfp.bin
geninitrd: Adding Firmwares (radeon/REDWOOD_rlc.bin) to initrd for module 
radeon
geninitrd: + cp /lib/firmware/radeon/REDWOOD_rlc.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/REDWOOD_rlc.bin
geninitrd: Adding Firmwares (radeon/REDWOOD_me.bin) to initrd for module 
radeon
geninitrd: + cp /lib/firmware/radeon/REDWOOD_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/REDWOOD_me.bin
geninitrd: Adding Firmwares (radeon/REDWOOD_pfp.bin) to initrd for module 
radeon
geninitrd: + cp /lib/firmware/radeon/REDWOOD_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/REDWOOD_pfp.bin
geninitrd: Adding Firmwares (radeon/CEDAR_rlc.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/CEDAR_rlc.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/CEDAR_rlc.bin
geninitrd: Adding Firmwares (radeon/CEDAR_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/CEDAR_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/CEDAR_me.bin
geninitrd: Adding Firmwares (radeon/CEDAR_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/CEDAR_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/CEDAR_pfp.bin
geninitrd: Adding Firmwares (radeon/R700_rlc.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/R700_rlc.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/R700_rlc.bin
geninitrd: Adding Firmwares (radeon/R600_rlc.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/R600_rlc.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/R600_rlc.bin
geninitrd: Adding Firmwares (radeon/RV710_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV710_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV710_me.bin
geninitrd: Adding Firmwares (radeon/RV710_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV710_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV710_pfp.bin
geninitrd: Adding Firmwares (radeon/RV730_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV730_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV730_me.bin
geninitrd: Adding Firmwares (radeon/RV730_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV730_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV730_pfp.bin
geninitrd: Adding Firmwares (radeon/RV770_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV770_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV770_me.bin
geninitrd: Adding Firmwares (radeon/RV770_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV770_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV770_pfp.bin
geninitrd: Adding Firmwares (radeon/RS780_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RS780_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RS780_me.bin
geninitrd: Adding Firmwares (radeon/RS780_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RS780_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RS780_pfp.bin
geninitrd: Adding Firmwares (radeon/RV670_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV670_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV670_me.bin
geninitrd: Adding Firmwares (radeon/RV670_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV670_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV670_pfp.bin
geninitrd: Adding Firmwares (radeon/RV635_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV635_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV635_me.bin
geninitrd: Adding Firmwares (radeon/RV635_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV635_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV635_pfp.bin
geninitrd: Adding Firmwares (radeon/RV620_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV620_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV620_me.bin
geninitrd: Adding Firmwares (radeon/RV620_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV620_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV620_pfp.bin
geninitrd: Adding Firmwares (radeon/RV630_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV630_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV630_me.bin
geninitrd: Adding Firmwares (radeon/RV630_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV630_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV630_pfp.bin
geninitrd: Adding Firmwares (radeon/RV610_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV610_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV610_me.bin
geninitrd: Adding Firmwares (radeon/RV610_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/RV610_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/RV610_pfp.bin
geninitrd: Adding Firmwares (radeon/R600_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/R600_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/R600_me.bin
geninitrd: Adding Firmwares (radeon/R600_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/3.3.1-2/radeon/R600_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/R600_pfp.bin
geninitrd: Adding Firmwares (radeon/CAYMAN_rlc.bin) to initrd for module 
radeon
geninitrd: + cp /lib/firmware/radeon/CAYMAN_rlc.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/CAYMAN_rlc.bin
geninitrd: Adding Firmwares (radeon/CAYMAN_mc.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/CAYMAN_mc.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/CAYMAN_mc.bin
geninitrd: Adding Firmwares (radeon/CAYMAN_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/CAYMAN_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/CAYMAN_me.bin
geninitrd: Adding Firmwares (radeon/CAYMAN_pfp.bin) to initrd for module 
radeon
geninitrd: + cp /lib/firmware/radeon/CAYMAN_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/CAYMAN_pfp.bin
geninitrd: Adding Firmwares (radeon/CAICOS_mc.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/CAICOS_mc.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/CAICOS_mc.bin
geninitrd: Adding Firmwares (radeon/CAICOS_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/CAICOS_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/CAICOS_me.bin
geninitrd: Adding Firmwares (radeon/CAICOS_pfp.bin) to initrd for module 
radeon
geninitrd: + cp /lib/firmware/radeon/CAICOS_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/CAICOS_pfp.bin
geninitrd: Adding Firmwares (radeon/TURKS_mc.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/TURKS_mc.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/TURKS_mc.bin
geninitrd: Adding Firmwares (radeon/TURKS_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/TURKS_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/TURKS_me.bin
geninitrd: Adding Firmwares (radeon/TURKS_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/TURKS_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/TURKS_pfp.bin
geninitrd: Adding Firmwares (radeon/BTC_rlc.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/BTC_rlc.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/BTC_rlc.bin
geninitrd: Adding Firmwares (radeon/BARTS_mc.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/BARTS_mc.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/BARTS_mc.bin
geninitrd: Adding Firmwares (radeon/BARTS_me.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/BARTS_me.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/BARTS_me.bin
geninitrd: Adding Firmwares (radeon/BARTS_pfp.bin) to initrd for module radeon
geninitrd: + cp /lib/firmware/radeon/BARTS_pfp.bin 
/tmp/initrd.ZPYQ5l/lib/firmware/radeon/BARTS_pfp.bin
geninitrd: Adding BLKID support to initrd
geninitrd: + cp /usr/lib/initrd/blkid /tmp/initrd.ZPYQ5l/bin/blkid
geninitrd: Adding LVM support to initrd
geninitrd: + cp /usr/lib/initrd/lvm /tmp/initrd.ZPYQ5l/bin/lvm.static
geninitrd: Adding rootfs finding based on kernel cmdline root= option support.
geninitrd: Current /proc/partitions:
> major minor  #blocks  name
> 
>    3        0   78150744 hda
>    3        1     216846 hda1
>    3        2   20482875 hda2
>    3        3      72292 hda3
>    3        4          1 hda4
>    3        5     136521 hda5
>    3        6    9775521 hda6
>    3        7   46941898 hda7
>    3        8     522081 hda8
>    3       64   78150744 hdb
>    3       65     128488 hdb1
>    3       66      64260 hdb2
>    3       67   10241437 hdb3
>    3       68          1 hdb4
>    3       69    5116671 hdb5
>    3       70    9775521 hdb6
>    3       71    9775521 hdb7
>    3       72    9775521 hdb8
>    3       73   33270583 hdb9
>  254        0    5107712 dm-0
>    9        6    9775360 md6
geninitrd: + mkdir -p /tmp/initrd.ZPYQ5l/dev/vg_single_disk
geninitrd: + cp /dev/vg_single_disk/root 
/tmp/initrd.ZPYQ5l/dev/vg_single_disk/root
geninitrd: Current /linuxrc:
> #!/bin/sh
> # initrd generated by:
> # $Revision: 12549 $ $Date:: 2012-04-16 20:14:37 +0200 #$
> 
> [ -f /proc/cmdline ] || mount -t proc none /proc
> # builtin defaults from geninitrd
> ROOT=/dev/vg_single_disk/root
> ROOTFS=ext4
> read CMDLINE < /proc/cmdline
> 
> for arg in $CMDLINE; do
> if [ "${arg}" = "debuginitrd" ]; then
> DEBUGINITRD=yes
> fi
> if [ "${arg##debuginitrd=}" != "${arg}" ]; then
> DEBUGINITRD=${arg##debuginitrd=}
> fi
> if [ "${arg##root=}" != "${arg}" ]; then
> ROOT=${arg##root=}
> fi
> if [ "${arg##rootfsflags=}" != "${arg}" ]; then
> ROOTFSFLAGS=${arg##rootfsflags=}
> fi
> if [ "${arg##init=}" != "${arg}" ]; then
> INIT=${arg##init=}
> fi
> done
> 
> # make debugshell() invoke subshell if $DEBUGINITRD=sh
> if [ "$DEBUGINITRD" = "sh" ]; then
> debugshell() {
> echo "debug shell disabled by /etc/sysconfig/system: RUN_SULOGIN_ON_ERR 
setting"
> }
> else
> debugshell() {
> :
> }
> fi
> 
> if [ "$DEBUGINITRD" ]; then
> set -x
> fi
> insmod /lib/modules/3.3.1-2/kernel/drivers/usb/usb-common.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/usb/core/usbcore.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/usb/host/ehci-hcd.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/mmc/core/mmc_core.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/pcmcia/pcmcia_core.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/pcmcia/pcmcia.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/ssb/ssb.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/usb/host/ohci-hcd.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/hid/hid.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/hid/usbhid/usbhid.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/ide/ide-core.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/ide/atiixp.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/ide/ide-gd_mod.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/md/dm-mod.ko 
> insmod /lib/modules/3.3.1-2/kernel/lib/crc16.ko 
> insmod /lib/modules/3.3.1-2/kernel/fs/mbcache.ko 
> insmod /lib/modules/3.3.1-2/kernel/fs/jbd2/jbd2.ko 
> insmod /lib/modules/3.3.1-2/kernel/fs/ext4/ext4.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/usb/host/uhci-hcd.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/i2c/i2c-core.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/hwmon/hwmon.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/i2c/algos/i2c-algo-bit.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/char/agp/agpgart.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/gpu/drm/drm.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/gpu/drm/ttm/ttm.ko 
> insmod /lib/modules/3.3.1-2/kernel/drivers/gpu/drm/drm_kms_helper.ko 
> echo -n /lib/firmware/firmware.sh > /proc/sys/kernel/hotplug
> mount -t sysfs none /sys
> insmod /lib/modules/3.3.1-2/kernel/drivers/gpu/drm/radeon/radeon.ko 
> : 'Creating /dev'
> if ! mount -t devtmpfs -o mode=0755,nosuid devtmpfs /dev > /dev/null 2>&1; 
then
> mount -o mode=0755,nosuid -t tmpfs tmpfs /dev
> mknod /dev/console c 5 1
> mknod /dev/null c 1 3
> mknod /dev/zero c 1 5
> mknod /dev/random c 1 8
> mknod /dev/snapshot c 10 231
> mknod /dev/urandom c 1 9
> mknod /dev/ptmx c 5 2
> mknod /dev/kmsg c 1 11
> fi
> mkdir /dev/pts
> mkdir /dev/shm
> : 'Making device nodes'
> cat /proc/partitions | (
> # ignore first two lines: header, empty line
> read b; read b
> 
> while read major minor blocks dev rest; do
> node=/dev/$dev
> mkdir -p ${node%/*}
> [ -e $node ] || mknod $node b $major $minor
> done
> )
> # if built with blkid change ROOT=LABEL=something into 
ROOT=/dev/somethingelse -
> # parsed by blkid
> if [ "${ROOT##LABEL=}" != "${ROOT}" -o "${ROOT##UUID=}" != "${ROOT}" ]; then
> ROOT="$(/bin/blkid -t $ROOT -o device -l)"
> fi
> cat /etc/lvm.conf > /tmp/lvm.conf
> ROOTDEV=/dev/vg_single_disk/root
> LVM_ROOTVG="vg_single_disk"
> LVM_SUSPENDVG=""
> # parse rootdev from kernel commandline if it begins with /
> case "$ROOT" in
> /*)
> 
> # rewrite:
>       # /dev/mapper/sys-rootfs -> /dev/sys/rootfs
> # /dev/mapper/blodnatt-blah--bleh -> /dev/blodnatt/blah-bleh
> # /dev/mapper/vg--meaw-root -> /dev/vg-meaw/root
> case "$ROOT" in
> /dev/mapper/*-*)
> # change "--" to / (as "/" is impossible in LV name)
> local dev=$(awk -vdev="${ROOT#/dev/mapper/}" 'BEGIN{gsub(/--/, "/", dev); 
print dev}')
> local VG=$(awk -vdev="$dev" 'BEGIN{split(dev, v, "-"); gsub("/", "-", v[1]); 
print v[1]}')
> local LV=$(awk -vdev="$dev" 'BEGIN{split(dev, v, "-"); gsub("/", "-", v[2]); 
print v[2]}')
> ROOT=/dev/$VG/$LV
> ;;
> esac
> 
> if [ "$ROOT" != "$ROOTDEV" ]; then
> ROOTDEV=$ROOT
> 
> echo "LVM: Using 'root=$ROOTDEV' from kernel commandline"
> local tmp=${ROOTDEV#/dev/}
> if [ "$tmp" != "$ROOTDEV" ]; then
> LVM_ROOTVG=${tmp%/*}
> echo "LVM: Using Volume Group '$LVM_ROOTVG' for rootfs"
> fi
> fi
> ;;
> esac
> 
> # skip duplicate VG
> if [ "$LVM_SUSPENDVG" = "$LVM_ROOTVG" ]; then
> LVM_VGVOLUMES="$LVM_ROOTVG"
> else
> LVM_VGVOLUMES="$LVM_SUSPENDVG $LVM_ROOTVG"
> fi
> 
> # disable noise from LVM accessing devices that aren't ready.
> read printk < /proc/sys/kernel/printk
> if [ ! "$DEBUGINITRD" ]; then
> echo 0 > /proc/sys/kernel/printk
> fi
> 
> export LVM_SYSTEM_DIR=/tmp
> : 'Scanning for Volume Groups'
> lvm.static vgscan --mknodes --ignorelockingfailure 2>/dev/null
> 
> : 'Activating Volume Groups'
> for vol in $LVM_VGVOLUMES; do
> lvm.static vgchange --ignorelockingfailure -a y $vol 2>/dev/null
> done
> 
> echo "$printk" > /proc/sys/kernel/printk
> 
> # Find out major/minor
> attrs="$(lvm.static lvdisplay --ignorelockingfailure -c $ROOTDEV 
2>/dev/null)"
> if [ "$attrs" ]; then
> majmin="${attrs#*$ROOTDEV*:*:*:*:*:*:*:*:*:*:*:*}"
> if [ "$majmin" != "$attrs" ]; then
> major="${majmin%:*}"
> minor="${majmin#*:}"
> fi
> fi
> 
> if [ "$major" -a "$minor" ]; then
> # Pass it to kernel
> echo $((256 * $major + $minor)) > /proc/sys/kernel/real-root-dev
> fi
> 
> unset LVM_SYSTEM_DIR
> if [ "${ROOT##/dev/}" != "${ROOT}" ]; then
> rootnr="$(busybox awk -v rootnode="${ROOT##/dev/}" '$4 == rootnode { print 
256 * $1 + $2 }' /proc/partitions)"
> # fallback to ls
> if [ -z "$rootnr" ]; then
> rootnr="$(busybox ls -lL ${ROOT} | busybox awk '{if (/^b/) { print 256 * $3 
+ $4; }}')"
> fi
> if [ -n "$rootnr" ]; then
> echo "$rootnr" > /proc/sys/kernel/real-root-dev
> fi
> fi
> ifs=$IFS
> IFS="
> "
> for i in $(export -p); do
> i=${i#declare -x } # ksh/bash
> i=${i#export } # busybox
> 
> case "$i" in
> *=*)
> : ;;
> *)
> continue ;;
> esac
> 
> i=${i%%=*}
> 
> [ -z "$i" ] && continue
> 
> case "$i" in
> ROOT|PATH|HOME|TERM)
> :
> ;;
> *)
> unset $i
> ;;
> esac
> done
> IFS=$ifs
> device=
> eval "$(busybox awk -v root="$ROOT" '
> BEGIN {
> num_pattern_short = "[0-9a-f][0-9a-f][0-9a-f]";
> num_pattern = "[0-9a-f]" num_pattern_short;
> dev_pattern = "[hms][a-z][a-z]([0-9])+";
> partition = "";
> min = -1; maj = -1;
> 
> # see if we have /dev/hdX or hdX, we can just take partition name
> if (root ~ "^\/dev\/" dev_pattern "$" || root ~ "^" dev_pattern "$") {
> partition = root
> sub("^/dev/", "", partition);
>
> } else {
> # unify values first
> if (root ~ "^" num_pattern_short "$")  {
> # change "303" => "0x0303"
> root = "0x0" root
> } else if (root ~ "^" num_pattern "$")  {
> # change "0303" => "0x0303"
> root = "0x" root
> }
>
> maj = sprintf("%d", "0x" substr(root, 3, 2));
> min = sprintf("%d", "0x" substr(root, 5, 2));
> }
> }
>
> partition && $4 == partition { maj = $1; min = $2; }
> $1 == maj && $2 == min { partition = $4; }
>
> END {
> if (maj >= 0 && min >= 0) {
> printf("maj=%s; min=%s;
", maj, min);
> }
> if (partition) {
> printf("device=/dev/%s;
", partition);
> }
> }
> ' /proc/partitions)"
>
> if [ -z "$device" ]; then
> device=$ROOT
> fi
>
> if [ "$device" -a ! -b $device ]; then
> mknod $device b $maj $min
> fi
>
> [ -n "$ROOTFSFLAGS" ] && ROOTFSFLAGS="-o $ROOTFSFLAGS"
>
> mount -t $ROOTFS -r $device $ROOTFSFLAGS /newroot || echo "Mount of rootfs 
failed."
> init=$INIT
> if [ -z "$init" -o ! -x "/newroot$init" ]; then
> init=/sbin/init
> fi
> : Last shell before umounting all and giving control over to real init.
> debugshell
> umount /dev
> umount /sys
> umount /proc
> [ ! -e /newroot/dev/console ] && mknod -m 660 /newroot/dev/console c 5 1
> exec switch_root /newroot $init ${1:+"$@"}
>
> echo "Error! initramfs should not reach this place."
> echo "It probably means you've got old version of busybox, with broken"
> echo "initramfs support. Trying to boot anyway, but won't promise anything."
>
> exec chroot /newroot $init ${1:+"$@"}
>
> echo "Failed to chroot!"
> debugshell
geninitrd: image size: 6144 KiB (/tmp/initrd.ZPYQ5l)
geninitrd: Creating initramfs image /tmp/initrd.img-IjKYHH
geninitrd: finding compressor: lzo gzip xz lzma bzip2 (via yes)
geninitrd: Compressing /boot/initrd-3.3.1-2.gz with gzip





-- 
Mateusz Korniak
"(...) mam brata - powa?ny, domator, liczykrupa, hipokryta, pobo?ni?,
 	kr?tko m?wi?c - podpora spo?ecze?stwa."
				Nikos Kazantzakis - "Grek Zorba"

-- 
Mateusz Korniak


From lordblick at gmail.com  Tue Apr 17 21:37:20 2012
From: lordblick at gmail.com (Lord Blick)
Date: Tue, 17 Apr 2012 21:37:20 +0200
Subject: geninitrd nie wie co to 0ede
In-Reply-To: <12593021.82RrSbOiK7@inhell>
References: <1519053.oxBM3I6JaW@inhell> <2698616.vOsSRulYni@inhell>
 <4F8C5F47.9010009@pld-linux.org> <12593021.82RrSbOiK7@inhell>
Message-ID: <4F8DC670.9020309@gmail.com>

W odpowiedzi na wiadomo?? z dnia 16.04.2012 20:10, od Lukasz Glebicki:
> It's grub not lilo.
But kernel booting parameters are the same. From time to time in
different kernel versions device's minor and major numbers are changing,
so numeric root at kernel parameters is praying for troubles.
-- 
Best Regards,
Lord Blick



From qboosh at pld-linux.org  Wed Apr 18 19:55:10 2012
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 18 Apr 2012 19:55:10 +0200
Subject: packages: babl/babl.spec - ver. 0.1.8 (nfy - builds without vala
 0.16 and w...
In-Reply-To: <packages_babl_babl.spec.1.16@pld-linux.org>
References: <packages_babl_babl.spec.1.15@pld-linux.org>
 <packages_babl_babl.spec.1.16@pld-linux.org>
Message-ID: <20120418175509.GA4332@mail>

On Wed, Apr 18, 2012 at 02:06:26AM +0200, wrobell wrote:
>  BuildRequires:	autoconf >= 2.54
>  BuildRequires:	automake >= 1:1.11
> +BuildRequires:	elfutils-devel

Where did this come from?


BTW, maybe someone would volunteer to report a bug in introspection
info generation for babl using gobject-introspection 1.32.x?
(g-ir-scanner generates such Babl-0.1.gir that triggers an assertion
error in g-ir-compiler)


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


From wrobell at pld-linux.org  Wed Apr 18 20:18:15 2012
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Wed, 18 Apr 2012 19:18:15 +0100
Subject: packages: babl/babl.spec - ver. 0.1.8 (nfy - builds without vala
 0.16 and w...
In-Reply-To: <20120418175509.GA4332@mail>
References: <packages_babl_babl.spec.1.15@pld-linux.org>
 <packages_babl_babl.spec.1.16@pld-linux.org>
 <20120418175509.GA4332@mail>
Message-ID: <CA+92fu-3SV8Uqy1gTK--=yCXicfi9qzjLhrLO15bFLYRH=oLzw@mail.gmail.com>

On Wed, Apr 18, 2012 at 6:55 PM, Jakub Bogusz <qboosh at pld-linux.org> wrote:
> On Wed, Apr 18, 2012 at 02:06:26AM +0200, wrobell wrote:
>> ?BuildRequires: ? ? ? autoconf >= 2.54
>> ?BuildRequires: ? ? ? automake >= 1:1.11
>> +BuildRequires: ? ? ? elfutils-devel
>
> Where did this come from?

libtool: link: gcc -o
/home/users/wrobell/rpm/BUILD/babl-0.1.10/babl/tmp-introspectUAe1Xd/.libs/Babl-0.1
/home/users/wrobell/rpm/BUILD/babl-0.1.10/babl/tmp-introspectUAe1Xd/Babl-0.1.o
-pthread -Wl,--export-dynamic -Wl,--export-dynamic  -L.
./.libs/libbabl-0.1.so -lm /usr/lib64/libgio-2.0.so -lz -lresolv
/usr/lib64/libgobject-2.0.so /usr/lib64/libffi.so
/usr/lib64/libgthread-2.0.so /usr/lib64/libgmodule-2.0.so -ldl
/usr/lib64/libglib-2.0.so /usr/lib64/libpcre.so -lpthread -lrt -lelf
-pthread
/usr/bin/ld: cannot find -lelf

Try:

$ grep -r elf /usr/lib64/*.la

Not sure where to add the dependency... glib2-devel?

Regards,

w


Best regards,

w


From megabajt at pld-linux.org  Wed Apr 18 20:27:24 2012
From: megabajt at pld-linux.org (Marcin Banasiak)
Date: Wed, 18 Apr 2012 20:27:24 +0200
Subject: packages: babl/babl.spec - ver. 0.1.8 (nfy - builds without vala
 0.16 and w...
In-Reply-To: <20120418175509.GA4332@mail>
References: <packages_babl_babl.spec.1.15@pld-linux.org>
 <packages_babl_babl.spec.1.16@pld-linux.org>
 <20120418175509.GA4332@mail>
Message-ID: <CAJgtVYCiFoR2fB1mVnA=hjodxrHMsVx=A9izL4XkE_8z9LFu-A@mail.gmail.com>

2012/4/18 Jakub Bogusz <qboosh at pld-linux.org>:
> BTW, maybe someone would volunteer to report a bug in introspection
> info generation for babl using gobject-introspection 1.32.x?
> (g-ir-scanner generates such Babl-0.1.gir that triggers an assertion
> error in g-ir-compiler)

It's already reported:

https://bugzilla.gnome.org/show_bug.cgi?id=673422

-- 
Marcin Banasiak


From qboosh at pld-linux.org  Thu Apr 19 17:11:12 2012
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 19 Apr 2012 17:11:12 +0200
Subject: packages: babl/babl.spec - ver. 0.1.8 (nfy - builds without vala
 0.16 and w...
In-Reply-To: <CA+92fu-3SV8Uqy1gTK--=yCXicfi9qzjLhrLO15bFLYRH=oLzw@mail.gmail.com>
References: <packages_babl_babl.spec.1.15@pld-linux.org>
 <packages_babl_babl.spec.1.16@pld-linux.org> <20120418175509.GA4332@mail>
 <CA+92fu-3SV8Uqy1gTK--=yCXicfi9qzjLhrLO15bFLYRH=oLzw@mail.gmail.com>
Message-ID: <20120419151112.GA8580@mail>

On Wed, Apr 18, 2012 at 07:18:15PM +0100, Artur Wroblewski wrote:
> On Wed, Apr 18, 2012 at 6:55 PM, Jakub Bogusz <qboosh at pld-linux.org> wrote:
> > On Wed, Apr 18, 2012 at 02:06:26AM +0200, wrobell wrote:
> >> ?BuildRequires: ? ? ? autoconf >= 2.54
> >> ?BuildRequires: ? ? ? automake >= 1:1.11
> >> +BuildRequires: ? ? ? elfutils-devel
> >
> > Where did this come from?
> 
> libtool: link: gcc -o
> /home/users/wrobell/rpm/BUILD/babl-0.1.10/babl/tmp-introspectUAe1Xd/.libs/Babl-0.1
> /home/users/wrobell/rpm/BUILD/babl-0.1.10/babl/tmp-introspectUAe1Xd/Babl-0.1.o
> -pthread -Wl,--export-dynamic -Wl,--export-dynamic  -L.
> ./.libs/libbabl-0.1.so -lm /usr/lib64/libgio-2.0.so -lz -lresolv
> /usr/lib64/libgobject-2.0.so /usr/lib64/libffi.so
> /usr/lib64/libgthread-2.0.so /usr/lib64/libgmodule-2.0.so -ldl
> /usr/lib64/libglib-2.0.so /usr/lib64/libpcre.so -lpthread -lrt -lelf
> -pthread
> /usr/bin/ld: cannot find -lelf
> 
> Try:
> 
> $ grep -r elf /usr/lib64/*.la
> 
> Not sure where to add the dependency... glib2-devel?

It came from glib2, but it's unnecessary. Only gresource tool should be
linked with -lelf; I've added a patch to avoid adding -lelf to global
LIBS in glib2 build.


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


From wrobell at pld-linux.org  Thu Apr 19 21:32:35 2012
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Thu, 19 Apr 2012 20:32:35 +0100
Subject: gimp 2.8.0 rc1, gimp plugins
Message-ID: <CA+92fu9eqMfVK2MNDn24AEY47c-Eyb8dP1hEAWvazMSC2yNbnw@mail.gmail.com>

hi,

i would like to move gimp 2.8.0 rc1 from DEVEL to HEAD.

any argument against?

btw. we have some quite old gimp plugins on ftp, i.e. build in 2010, 2009. shall
they be removed, rebuilt?

regards,

w


From shadzik at gmail.com  Thu Apr 19 22:27:18 2012
From: shadzik at gmail.com (=?UTF-8?B?QmFydG9zeiDFmndpxIV0ZWs=?=)
Date: Thu, 19 Apr 2012 22:27:18 +0200
Subject: gimp 2.8.0 rc1, gimp plugins
In-Reply-To: <CA+92fu9eqMfVK2MNDn24AEY47c-Eyb8dP1hEAWvazMSC2yNbnw@mail.gmail.com>
References: <CA+92fu9eqMfVK2MNDn24AEY47c-Eyb8dP1hEAWvazMSC2yNbnw@mail.gmail.com>
Message-ID: <CADfyV2PeTNXG=Z7wWG-4Gcpwd-Cz4D6QbzwBwFYaMHNJ3NxGFw@mail.gmail.com>

W dniu 19 kwietnia 2012 21:32 u?ytkownik Artur Wroblewski
<wrobell at pld-linux.org> napisa?:
> hi,
>
> i would like to move gimp 2.8.0 rc1 from DEVEL to HEAD.
>
> any argument against?

Yes. New gegl and babl break API/ABI compatibility with earlier
versions. Gimp 2.8 RC1 needs them. Also as statet on gimp.org, they
need to fix some bugs and are looking for more bugs. That's always a
release stoper.

But I'm sure noone else will find these arguments critical and we will
soon see more and more Alpha, Beta and RC version on HEAD and main
ftp.

-- 
"I'm living proof if you do one thing right in your career, you can
coast for a long time. A LOOOOONG time." -Guy Kawasaki


From caleb at pld-linux.org  Thu Apr 19 22:44:01 2012
From: caleb at pld-linux.org (Caleb Maclennan)
Date: Thu, 19 Apr 2012 23:44:01 +0300
Subject: gimp 2.8.0 rc1, gimp plugins
In-Reply-To: <CA+92fu9eqMfVK2MNDn24AEY47c-Eyb8dP1hEAWvazMSC2yNbnw@mail.gmail.com>
References: <CA+92fu9eqMfVK2MNDn24AEY47c-Eyb8dP1hEAWvazMSC2yNbnw@mail.gmail.com>
Message-ID: <CAP9w9P6RfZJaVDLO1eOMdsu-Pk6W+9N5aAdBvF1RTo_MkG8GPQ@mail.gmail.com>

2012/4/19 Artur Wroblewski <wrobell at pld-linux.org>:
> hi,
>
> i would like to move gimp 2.8.0 rc1 from DEVEL to HEAD.
>
> any argument against?
>
> btw. we have some quite old gimp plugins on ftp, i.e. build in 2010, 2009. shall
> they be removed, rebuilt?
>
> regards,
>
> w

Yes. That is an RC for a major release version and there aren't any
show-stopper bugs or comparability issues in the previous release that
would force us to skip ahead to get the bugs ironed out. At this point
I'm having a heck of a time keeping stable systems using TH which is
supposed to be STABLE. Adding more backwards incompatible libraries to
the dependency mess is going to make that worse, not better.

Caleb


From wrobell at pld-linux.org  Fri Apr 20 00:54:43 2012
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Thu, 19 Apr 2012 23:54:43 +0100
Subject: gimp 2.8.0 rc1, gimp plugins
In-Reply-To: <CADfyV2PeTNXG=Z7wWG-4Gcpwd-Cz4D6QbzwBwFYaMHNJ3NxGFw@mail.gmail.com>
References: <CA+92fu9eqMfVK2MNDn24AEY47c-Eyb8dP1hEAWvazMSC2yNbnw@mail.gmail.com>
 <CADfyV2PeTNXG=Z7wWG-4Gcpwd-Cz4D6QbzwBwFYaMHNJ3NxGFw@mail.gmail.com>
Message-ID: <CA+92fu_hrX3rO=ky=XBGAnPB5_bWsepsFzcUQ6D46uhxO=tf9w@mail.gmail.com>

2012/4/19 Bartosz ?wi?tek <shadzik at gmail.com>:
> W dniu 19 kwietnia 2012 21:32 u?ytkownik Artur Wroblewski
> <wrobell at pld-linux.org> napisa?:
>> hi,
>>
>> i would like to move gimp 2.8.0 rc1 from DEVEL to HEAD.
>>
>> any argument against?
>
> Yes. New gegl and babl break API/ABI compatibility with earlier
> versions. Gimp 2.8 RC1 needs them. Also as statet on gimp.org, they
> need to fix some bugs and are looking for more bugs. That's always a
> release stoper.

> But I'm sure noone else will find these arguments critical and we will
> soon see more and more Alpha, Beta and RC version on HEAD and main
> ftp.

I was asking to put it on HEAD. _Not_ to put it on ftp.

Regards,

w


From wrobell at pld-linux.org  Fri Apr 20 01:03:47 2012
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Fri, 20 Apr 2012 00:03:47 +0100
Subject: gimp 2.8.0 rc1, gimp plugins
In-Reply-To: <CAP9w9P6RfZJaVDLO1eOMdsu-Pk6W+9N5aAdBvF1RTo_MkG8GPQ@mail.gmail.com>
References: <CA+92fu9eqMfVK2MNDn24AEY47c-Eyb8dP1hEAWvazMSC2yNbnw@mail.gmail.com>
 <CAP9w9P6RfZJaVDLO1eOMdsu-Pk6W+9N5aAdBvF1RTo_MkG8GPQ@mail.gmail.com>
Message-ID: <CA+92fu-fHAi2FfBDLiAMK3oXDxSpNXNuWp9-2_oz7qO_n0b9_w@mail.gmail.com>

On Thu, Apr 19, 2012 at 9:44 PM, Caleb Maclennan <caleb at pld-linux.org> wrote:
> 2012/4/19 Artur Wroblewski <wrobell at pld-linux.org>:
>> hi,
>>
>> i would like to move gimp 2.8.0 rc1 from DEVEL to HEAD.
>>
>> any argument against?
>>
>> btw. we have some quite old gimp plugins on ftp, i.e. build in 2010, 2009. shall
>> they be removed, rebuilt?
>>
>> regards,
>>
>> w
>
> Yes. That is an RC for a major release version and there aren't any
> show-stopper bugs or comparability issues in the previous release that
> would force us to skip ahead to get the bugs ironed out. At this point
> I'm having a heck of a time keeping stable systems using TH which is
> supposed to be STABLE. Adding more backwards incompatible libraries to
> the dependency mess is going to make that worse, not better.

Ac is stable release for which we have appropriate branch and Th
is in constant development mode, isn't it?

I am asking because I am bit lost with above arguments - do we
have some new rules for Th? When they changed? :P

To repeat myself "cvs head != Th ftp". If you send it to the builders,
then it is your fault.

Let me rephrase - is anyone planning any work related to Gimp 2.6
on CVS HEAD in near future? If not, then I will do the merge from
DEVEL (but please let non-IRC people know if any rules changed
regarding Th and what's the plan).

Regards,

w


From shadzik at gmail.com  Fri Apr 20 07:14:41 2012
From: shadzik at gmail.com (=?UTF-8?B?QmFydG9zeiDFmndpxIV0ZWs=?=)
Date: Fri, 20 Apr 2012 07:14:41 +0200
Subject: gimp 2.8.0 rc1, gimp plugins
In-Reply-To: <CA+92fu-fHAi2FfBDLiAMK3oXDxSpNXNuWp9-2_oz7qO_n0b9_w@mail.gmail.com>
References: <CA+92fu9eqMfVK2MNDn24AEY47c-Eyb8dP1hEAWvazMSC2yNbnw@mail.gmail.com>
 <CAP9w9P6RfZJaVDLO1eOMdsu-Pk6W+9N5aAdBvF1RTo_MkG8GPQ@mail.gmail.com>
 <CA+92fu-fHAi2FfBDLiAMK3oXDxSpNXNuWp9-2_oz7qO_n0b9_w@mail.gmail.com>
Message-ID: <CADfyV2Ngr+AdQ1XYfad7Pn5MWfbJbsJa4YtGAt3CSjoTCh4+CA@mail.gmail.com>

W dniu 20 kwietnia 2012 01:03 u?ytkownik Artur Wroblewski
<wrobell at pld-linux.org> napisa?:
> On Thu, Apr 19, 2012 at 9:44 PM, Caleb Maclennan <caleb at pld-linux.org> wrote:
>> 2012/4/19 Artur Wroblewski <wrobell at pld-linux.org>:
>>> hi,
>>>
>>> i would like to move gimp 2.8.0 rc1 from DEVEL to HEAD.
>>>
>>> any argument against?
>>>
>>> btw. we have some quite old gimp plugins on ftp, i.e. build in 2010, 2009. shall
>>> they be removed, rebuilt?
>>>
>>> regards,
>>>
>>> w
>>
>> Yes. That is an RC for a major release version and there aren't any
>> show-stopper bugs or comparability issues in the previous release that
>> would force us to skip ahead to get the bugs ironed out. At this point
>> I'm having a heck of a time keeping stable systems using TH which is
>> supposed to be STABLE. Adding more backwards incompatible libraries to
>> the dependency mess is going to make that worse, not better.
>
> Ac is stable release for which we have appropriate branch and Th
> is in constant development mode, isn't it?
>
> I am asking because I am bit lost with above arguments - do we
> have some new rules for Th? When they changed? :P

You tell us. AFAIK official rules state that no Betas and RCs are
allowed on HEAD and exceptions need to be discussed. I can't remember
to have read any new rules lately that differ from what I just said,
so if you know something more, please share it with us.

>
> To repeat myself "cvs head != Th ftp". If you send it to the builders,
> then it is your fault.

In general CVS != FTP, but as we all know the first step to get a
package to main FTP is to put it on CVS HEAD. Putting there unstable
versions is very confusing.

>
> Let me rephrase - is anyone planning any work related to Gimp 2.6
> on CVS HEAD in near future? If not, then I will do the merge from
> DEVEL (but please let non-IRC people know if any rules changed
> regarding Th and what's the plan).

That's not an argument. Noone's gonna know if for some reason Gimp 2.6
will need to be patched, fixed, rebuilt or our chief only knows what
else. What's the problem with having an _unstable_ version on DEVEL
anyway?
What is so importand in this version to you so desperately need to put
it on HEAD?


-- 
"I'm living proof if you do one thing right in your career, you can
coast for a long time. A LOOOOONG time." -Guy Kawasaki


From wrobell at pld-linux.org  Fri Apr 20 10:01:01 2012
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Fri, 20 Apr 2012 09:01:01 +0100
Subject: gimp 2.8.0 rc1, gimp plugins
In-Reply-To: <CADfyV2Ngr+AdQ1XYfad7Pn5MWfbJbsJa4YtGAt3CSjoTCh4+CA@mail.gmail.com>
References: <CA+92fu9eqMfVK2MNDn24AEY47c-Eyb8dP1hEAWvazMSC2yNbnw@mail.gmail.com>
 <CAP9w9P6RfZJaVDLO1eOMdsu-Pk6W+9N5aAdBvF1RTo_MkG8GPQ@mail.gmail.com>
 <CA+92fu-fHAi2FfBDLiAMK3oXDxSpNXNuWp9-2_oz7qO_n0b9_w@mail.gmail.com>
 <CADfyV2Ngr+AdQ1XYfad7Pn5MWfbJbsJa4YtGAt3CSjoTCh4+CA@mail.gmail.com>
Message-ID: <CA+92fu-NawHA3TzT4uH_yO+XCcy4k_cha91LTvAfSi3O3rkb9Q@mail.gmail.com>

2012/4/20 Bartosz ?wi?tek <shadzik at gmail.com>:
> W dniu 20 kwietnia 2012 01:03 u?ytkownik Artur Wroblewski
> <wrobell at pld-linux.org> napisa?:
>> On Thu, Apr 19, 2012 at 9:44 PM, Caleb Maclennan <caleb at pld-linux.org> wrote:
>>> 2012/4/19 Artur Wroblewski <wrobell at pld-linux.org>:
>>>> hi,
>>>>
>>>> i would like to move gimp 2.8.0 rc1 from DEVEL to HEAD.
>>>>
>>>> any argument against?
>>>>
>>>> btw. we have some quite old gimp plugins on ftp, i.e. build in 2010, 2009. shall
>>>> they be removed, rebuilt?
>>>>
>>>> regards,
>>>>
>>>> w
>>>
>>> Yes. That is an RC for a major release version and there aren't any
>>> show-stopper bugs or comparability issues in the previous release that
>>> would force us to skip ahead to get the bugs ironed out. At this point
>>> I'm having a heck of a time keeping stable systems using TH which is
>>> supposed to be STABLE. Adding more backwards incompatible libraries to
>>> the dependency mess is going to make that worse, not better.
>>
>> Ac is stable release for which we have appropriate branch and Th
>> is in constant development mode, isn't it?
>>
>> I am asking because I am bit lost with above arguments - do we
>> have some new rules for Th? When they changed? :P
>
> You tell us. AFAIK official rules state that no Betas and RCs are
> allowed on HEAD and exceptions need to be discussed. I can't remember
> to have read any new rules lately that differ from what I just said,
> so if you know something more, please share it with us.

I do not remember discussing such rule. But I remember that
if a package on HEAD has non-integral release number (i.e. 0.1)
then it means that the work is still in progress.

>>
>> To repeat myself "cvs head != Th ftp". If you send it to the builders,
>> then it is your fault.
>
> In general CVS != FTP, but as we all know the first step to get a
> package to main FTP is to put it on CVS HEAD. Putting there unstable
> versions is very confusing.

The release number is not confusing, IMHO.

>> Let me rephrase - is anyone planning any work related to Gimp 2.6
>> on CVS HEAD in near future? If not, then I will do the merge from
>> DEVEL (but please let non-IRC people know if any rules changed
>> regarding Th and what's the plan).
>
> That's not an argument. Noone's gonna know if for some reason Gimp 2.6
> will need to be patched, fixed, rebuilt or our chief only knows what
> else. What's the problem with having an _unstable_ version on DEVEL
> anyway?
> What is so importand in this version to you so desperately need to put
> it on HEAD?

The gegl and babl are stable now and they are on HEAD. IMHO, it is time to
_start_ (as in CVS) migrating to gimp 2.8... until you know that there is
something wrong with 2.6 and will need fixing soon (I assume no as there
are ftp related arguments only so far)?

Regards,

w


From gotar at polanet.pl  Fri Apr 20 10:07:44 2012
From: gotar at polanet.pl (Tomasz Pala)
Date: Fri, 20 Apr 2012 10:07:44 +0200
Subject: gimp 2.8.0 rc1, gimp plugins
In-Reply-To: <CA+92fu-NawHA3TzT4uH_yO+XCcy4k_cha91LTvAfSi3O3rkb9Q@mail.gmail.com>
References: <CA+92fu9eqMfVK2MNDn24AEY47c-Eyb8dP1hEAWvazMSC2yNbnw@mail.gmail.com>
 <CAP9w9P6RfZJaVDLO1eOMdsu-Pk6W+9N5aAdBvF1RTo_MkG8GPQ@mail.gmail.com>
 <CA+92fu-fHAi2FfBDLiAMK3oXDxSpNXNuWp9-2_oz7qO_n0b9_w@mail.gmail.com>
 <CADfyV2Ngr+AdQ1XYfad7Pn5MWfbJbsJa4YtGAt3CSjoTCh4+CA@mail.gmail.com>
 <CA+92fu-NawHA3TzT4uH_yO+XCcy4k_cha91LTvAfSi3O3rkb9Q@mail.gmail.com>
Message-ID: <20120420080743.GA23315@polanet.pl>

On Fri, Apr 20, 2012 at 09:01:01 +0100, Artur Wroblewski wrote:

>> You tell us. AFAIK official rules state that no Betas and RCs are
>> allowed on HEAD and exceptions need to be discussed. I can't remember
>> to have read any new rules lately that differ from what I just said,
>> so if you know something more, please share it with us.
> 
> I do not remember discussing such rule. But I remember that

It's old as PLD (HEAD should be rebuildable).

> if a package on HEAD has non-integral release number (i.e. 0.1)
> then it means that the work is still in progress.

WIP means some PLD developer does the work, not software maintainer. And
that it's to be finished soon (or the package was never finished).

> The gegl and babl are stable now and they are on HEAD. IMHO, it is time to
> _start_ (as in CVS) migrating to gimp 2.8... until you know that there is
> something wrong with 2.6 and will need fixing soon (I assume no as there

Starting something with unpredictable or long timeline should be done on DEVEL.

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


From baggins at pld-linux.org  Fri Apr 20 10:10:09 2012
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Fri, 20 Apr 2012 10:10:09 +0200
Subject: gimp 2.8.0 rc1, gimp plugins
In-Reply-To: <CA+92fu9eqMfVK2MNDn24AEY47c-Eyb8dP1hEAWvazMSC2yNbnw@mail.gmail.com>
References: <CA+92fu9eqMfVK2MNDn24AEY47c-Eyb8dP1hEAWvazMSC2yNbnw@mail.gmail.com>
Message-ID: <20120420081009.GC2629@sith.mimuw.edu.pl>

On Thu, 19 Apr 2012, Artur Wroblewski wrote:

> hi,
> 
> i would like to move gimp 2.8.0 rc1 from DEVEL to HEAD.
> 
> any argument against?

Just move 2.6 to GIMP_2_6 branch, keep fractional release on head and
yell if someone tries to send it to builders.

> btw. we have some quite old gimp plugins on ftp, i.e. build in 2010, 2009. shall
> they be removed, rebuilt?

Updated and rebuilt if possible, removed iff they don't work with 2.8
and can't be fixed.

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


From caleb at pld-linux.org  Fri Apr 20 14:55:03 2012
From: caleb at pld-linux.org (Caleb Maclennan)
Date: Fri, 20 Apr 2012 15:55:03 +0300
Subject: gimp 2.8.0 rc1, gimp plugins
In-Reply-To: <CA+92fu-fHAi2FfBDLiAMK3oXDxSpNXNuWp9-2_oz7qO_n0b9_w@mail.gmail.com>
References: <CA+92fu9eqMfVK2MNDn24AEY47c-Eyb8dP1hEAWvazMSC2yNbnw@mail.gmail.com>
 <CAP9w9P6RfZJaVDLO1eOMdsu-Pk6W+9N5aAdBvF1RTo_MkG8GPQ@mail.gmail.com>
 <CA+92fu-fHAi2FfBDLiAMK3oXDxSpNXNuWp9-2_oz7qO_n0b9_w@mail.gmail.com>
Message-ID: <CAP9w9P5wc4opcA7kobzHRiogWu-Wkh0WZSWPZJ4dF+QPbjO1Yw@mail.gmail.com>

> Ac is stable release for which we have appropriate branch and Th
> is in constant development mode, isn't it?

This is one area where PLD's release system is actually pretty wonky.
Other than a few emebeded or very static applications, AC is simply
too old to use for most stable systems. This puts the pressure on TH
-- as in reality, most folks use PLD for it's rolling constant
development branch. Anything that breaks that breaks production
systems.

> I am asking because I am bit lost with above arguments - do we
> have some new rules for Th? When they changed? :P

As far as I know, nothing has changed. This has been my understanding
of the status quo since I started using PLD nearly a decade ago.

> To repeat myself "cvs head != Th ftp". If you send it to the builders,
> then it is your fault.

I understand the difference beteween HEAD and FTP servers. The thing
is, by introducing unstable packages to HEAD, you make life
complicated for some of us. I for one compile a lot  of software using
builder from CVS HEAD. Sometimes if there are holdups on TH, stuff
will actually be ahead of TH in my personal repos.

When something gets introduced to HEAD that is a complete mis-match
with what is currently in TH, it makes building software harder.

Let's turn this question around. Since you're the one asking to do
something non-standard, what is your rational? What do you gain by
putting an RC  version in HEAD? If you are compiling it anyway, why
can't you just use the DEVEL tag until the package goes stable and
people should start testing it to go into TH?

Caleb


From qboosh at pld-linux.org  Fri Apr 20 16:40:23 2012
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Fri, 20 Apr 2012 16:40:23 +0200
Subject: packages: authconfig/authconfig.spec - fix python packaging,
 now things exe...
In-Reply-To: <packages_authconfig_authconfig.spec.1.50@pld-linux.org>
References: <packages_authconfig_authconfig.spec.1.49@pld-linux.org>
 <packages_authconfig_authconfig.spec.1.50@pld-linux.org>
Message-ID: <20120420144023.GA12673@mail>

On Fri, Apr 20, 2012 at 08:46:09AM +0200, glen wrote:
> -%{__rm} $RPM_BUILD_ROOT%{_datadir}/%{name}/authconfig-tui.py
> -ln -s authconfig.py $RPM_BUILD_ROOT%{_datadir}/%{name}/authconfig-tui.py
> +%py_comp $RPM_BUILD_ROOT%{_datadir}/%{name}
> +# libraries, no sources needed
> +%{__rm} -v $RPM_BUILD_ROOT%{_datadir}/%{name}/{authinfo,dnsclient,msgarea,shvfile}.py
> +# invoked directly, not as library
> +%{__rm} -v $RPM_BUILD_ROOT%{_datadir}/%{name}/authconfig*.py[co]

When Python script is named as *.py, python interpreter byte-compiles it
and tries to save the result (as .pyc or .pyo, depending on -O flag).
So when such script is packaged in %{_libdir}/*, %{_datadir}/* or so,
*.py[co] should be packaged too (or they will be created at runtime,
when the script is run by root).

In case if %{_bindir} or %{_sbindir} - no script should be named *.py
there (actually there are some, but they should be fixed).


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


From glen at delfi.ee  Fri Apr 20 17:40:53 2012
From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Fri, 20 Apr 2012 18:40:53 +0300
Subject: packages: authconfig/authconfig.spec - fix python packaging,
 now things exe...
In-Reply-To: <20120420144023.GA12673@mail>
References: <packages_authconfig_authconfig.spec.1.49@pld-linux.org>
 <packages_authconfig_authconfig.spec.1.50@pld-linux.org>
 <20120420144023.GA12673@mail>
Message-ID: <4F918385.1090308@delfi.ee>

On 20.04.2012 17:40, Jakub Bogusz wrote:
> On Fri, Apr 20, 2012 at 08:46:09AM +0200, glen wrote:
>> -%{__rm} $RPM_BUILD_ROOT%{_datadir}/%{name}/authconfig-tui.py
>> -ln -s authconfig.py $RPM_BUILD_ROOT%{_datadir}/%{name}/authconfig-tui.py
>> +%py_comp $RPM_BUILD_ROOT%{_datadir}/%{name}
>> +# libraries, no sources needed
>> +%{__rm} -v $RPM_BUILD_ROOT%{_datadir}/%{name}/{authinfo,dnsclient,msgarea,shvfile}.py
>> +# invoked directly, not as library
>> +%{__rm} -v $RPM_BUILD_ROOT%{_datadir}/%{name}/authconfig*.py[co]
> When Python script is named as *.py, python interpreter byte-compiles it
> and tries to save the result (as .pyc or .pyo, depending on -O flag).
> So when such script is packaged in %{_libdir}/*, %{_datadir}/* or so,
> *.py[co] should be packaged too (or they will be created at runtime,
> when the script is run by root).

it doesn't behave here so:

here it creates .pyc only for imported modules, if invoked via 
#!/shebang, no .pyc is created for the script itself:

18:39:43 glen[load: 0.00]@haarber share/authconfig$ l
total 344K
-rw-r--r-- 1 root root 139K 20. apr   09:44 authconfig.glade
-rwxr-xr-x 1 root root  26K 20. apr   09:44 authconfig-gtk.py*
-rwxr-xr-x 1 root root  42K 20. apr   09:44 authconfig.py*
lrwxrwxrwx 1 root root   13 20. apr   09:45 authconfig-tui.py -> 
authconfig.py*
-rw-r--r-- 1 root root  98K 20. apr   09:44 authinfo.pyc
-rw-r--r-- 1 root root  12K 20. apr   09:44 dnsclient.pyc
-rw-r--r-- 1 root root 9.8K 20. apr   09:44 msgarea.pyc
-rw-r--r-- 1 root root 4.3K 20. apr   09:44 shvfile.pyc

and i invoked authconfig as root and as regular user

as there's nobody specifycing -0, should .pyc still be added? (in case 
of private moduledir)

> In case if %{_bindir} or %{_sbindir} - no script should be named *.py
> there (actually there are some, but they should be fixed).
>
any explanation why (not that i have against)

-- 
glen



From jajcus at jajcus.net  Fri Apr 20 18:47:37 2012
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Fri, 20 Apr 2012 18:47:37 +0200
Subject: packages: authconfig/authconfig.spec - fix python packaging, now
 things exe...
In-Reply-To: <4F918385.1090308@delfi.ee>
References: <packages_authconfig_authconfig.spec.1.49@pld-linux.org>
 <packages_authconfig_authconfig.spec.1.50@pld-linux.org>
 <20120420144023.GA12673@mail> <4F918385.1090308@delfi.ee>
Message-ID: <20120420164737.GA5747@lolek.nigdzie>

On Fri, Apr 20, 2012 at 06:40:53PM +0300, Elan Ruusam?e wrote:
> it doesn't behave here so:
> 
> here it creates .pyc only for imported modules, if invoked via 
> #!/shebang, no .pyc is created for the script itself:
[...]
> > In case if %{_bindir} or %{_sbindir} - no script should be named *.py
> > there (actually there are some, but they should be fixed).
> >
> any explanation why (not that i have against)

The problem is, that if script name is "something.py", then
if any other python script in the same directory does 
'import something' (on purpose or because of a name collision) the
script will be compiled to pyc.

There should be no *.py files in %{_bindir}. If a script is supposed to
be importable, then it should be stored in %{py_sitescriptdir}, and only
a wrapper script should be kept in %{_bindir}.

The wrapper can be something like that:

#!/usr/bin/python
import something
somethig.run()

or

#!/bin/sh
exec /usr/bin/python -m something "$@"

Whatever the module expects.

Greets,
        Jacek


From wrobell at pld-linux.org  Fri Apr 20 20:48:40 2012
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Fri, 20 Apr 2012 19:48:40 +0100
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
Message-ID: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>

On Fri, Apr 20, 2012 at 1:55 PM, Caleb Maclennan <caleb at pld-linux.org> wrote:
>> Ac is stable release for which we have appropriate branch and Th
>> is in constant development mode, isn't it?
>
> This is one area where PLD's release system is actually pretty wonky.
> Other than a few emebeded or very static applications, AC is simply
> too old to use for most stable systems. This puts the pressure on TH
> -- as in reality, most folks use PLD for it's rolling constant
> development branch. Anything that breaks that breaks production
> systems.

it seems this discussion would not happen if not the problem summarized above.

well... if you need more stable line, then why not to create one with
appropriate
branch in CVS? of course, the problem is that somebody needs to maintain that,
which I believe is full time job and lack of resources causes the stable branch
to freeze. therefore, imho, it is not good idea to link CVS HEAD with stable
line - and that was the result of similar discussions in the past if i
reckon well.

if you need more reassurance, then what about introducing TH-STABLE tag and
sending packages to builders only when they are tagged with above?

[...]

regards,

w


From caleb at pld-linux.org  Fri Apr 20 20:57:54 2012
From: caleb at pld-linux.org (Caleb Maclennan)
Date: Fri, 20 Apr 2012 21:57:54 +0300
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
Message-ID: <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>

> well... if you need more stable line, then why not to create one with
> appropriate
> branch in CVS? of course, the problem is that somebody needs to maintain that,
> which I believe is full time job and lack of resources causes the stable branch
> to freeze. therefore, imho, it is not good idea to link CVS HEAD with stable
> line - and that was the result of similar discussions in the past if i
> reckon well.
>
> if you need more reassurance, then what about introducing TH-STABLE tag and
> sending packages to builders only when they are tagged with above?

A tag scheme like that could of course work. Again I would ask ask
how, other than different tag names, this is different from the status
quo. Please answer this: what do you see as the advantage to having an
RC release tagged HEAD instead of DEVEL? How does merging DEVEL into
HEAD before it's going to be a candidate for FTP make life any
different for you? What's the motivation? I honestly don't understand
what you're trying to accomplish and thus I feel like you're
presenting a solution to something that isn't a problem and thereby
introducing a problem. Does that make sense?

Caleb


From shadzik at gmail.com  Fri Apr 20 21:07:48 2012
From: shadzik at gmail.com (=?UTF-8?B?QmFydG9zeiDFmndpxIV0ZWs=?=)
Date: Fri, 20 Apr 2012 21:07:48 +0200
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
Message-ID: <CADfyV2MrXkbzL=N47eY5bGJChMdA+BPi6mh=a-jjeq7qyGp6iw@mail.gmail.com>

W dniu 20 kwietnia 2012 20:57 u?ytkownik Caleb Maclennan
<caleb at pld-linux.org> napisa?:
>> well... if you need more stable line, then why not to create one with
>> appropriate
>> branch in CVS? of course, the problem is that somebody needs to maintain that,
>> which I believe is full time job and lack of resources causes the stable branch
>> to freeze. therefore, imho, it is not good idea to link CVS HEAD with stable
>> line - and that was the result of similar discussions in the past if i
>> reckon well.
>>
>> if you need more reassurance, then what about introducing TH-STABLE tag and
>> sending packages to builders only when they are tagged with above?
>
> A tag scheme like that could of course work. Again I would ask ask
> how, other than different tag names, this is different from the status
> quo. Please answer this: what do you see as the advantage to having an
> RC release tagged HEAD instead of DEVEL? How does merging DEVEL into
> HEAD before it's going to be a candidate for FTP make life any
> different for you? What's the motivation? I honestly don't understand
> what you're trying to accomplish and thus I feel like you're
> presenting a solution to something that isn't a problem and thereby
> introducing a problem. Does that make sense?

Caleb, "stop trolling"*! You're asking very inconvenient questions :)


*that's the no. 1 answer to all inconvenient questions.

P.S.
just to make sure we understand each other, I'm on your side, but I
feel that arguing will not change anything, you can have the best
reasoning (and you do) but they won't understand anyway and will
ignore you if you don't agree with them.

-- 
"I'm living proof if you do one thing right in your career, you can
coast for a long time. A LOOOOONG time." -Guy Kawasaki


From zawadaa at gmail.com  Fri Apr 20 21:28:44 2012
From: zawadaa at gmail.com (Andrzej Zawadzki)
Date: Fri, 20 Apr 2012 21:28:44 +0200
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
Message-ID: <4F91B8EC.8030807@gmail.com>

On 20.04.2012 20:57, Caleb Maclennan wrote:
>> well... if you need more stable line, then why not to create one with
>> appropriate
>> branch in CVS? of course, the problem is that somebody needs to maintain that,
>> which I believe is full time job and lack of resources causes the stable branch
>> to freeze. therefore, imho, it is not good idea to link CVS HEAD with stable
>> line - and that was the result of similar discussions in the past if i
>> reckon well.
>>
>> if you need more reassurance, then what about introducing TH-STABLE tag and
>> sending packages to builders only when they are tagged with above?
> A tag scheme like that could of course work. Again I would ask ask
> how, other than different tag names, this is different from the status
> quo. Please answer this: what do you see as the advantage to having an
> RC release tagged HEAD instead of DEVEL? How does merging DEVEL into
> HEAD before it's going to be a candidate for FTP make life any
> different for you? What's the motivation? I honestly don't understand
> what you're trying to accomplish and thus I feel like you're
> presenting a solution to something that isn't a problem and thereby
> introducing a problem. Does that make sense?
True, I don't understand this problem either...

-- 
Andrzej


From shadzik at gmail.com  Fri Apr 20 21:38:02 2012
From: shadzik at gmail.com (=?UTF-8?B?QmFydG9zeiDFmndpxIV0ZWs=?=)
Date: Fri, 20 Apr 2012 21:38:02 +0200
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <4F91B8EC.8030807@gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <4F91B8EC.8030807@gmail.com>
Message-ID: <CADfyV2PjKsP7=odNzPqKr_tVP+LXD5Q-BBfvsSJDmgz2U+T3oQ@mail.gmail.com>

W dniu 20 kwietnia 2012 21:28 u?ytkownik Andrzej Zawadzki
<zawadaa at gmail.com> napisa?:
> On 20.04.2012 20:57, Caleb Maclennan wrote:
>>>
>>> well... if you need more stable line, then why not to create one with
>>> appropriate
>>> branch in CVS? of course, the problem is that somebody needs to maintain
>>> that,
>>> which I believe is full time job and lack of resources causes the stable
>>> branch
>>> to freeze. therefore, imho, it is not good idea to link CVS HEAD with
>>> stable
>>> line - and that was the result of similar discussions in the past if i
>>> reckon well.
>>>
>>> if you need more reassurance, then what about introducing TH-STABLE tag
>>> and
>>> sending packages to builders only when they are tagged with above?
>>
>> A tag scheme like that could of course work. Again I would ask ask
>> how, other than different tag names, this is different from the status
>> quo. Please answer this: what do you see as the advantage to having an
>> RC release tagged HEAD instead of DEVEL? How does merging DEVEL into
>> HEAD before it's going to be a candidate for FTP make life any
>> different for you? What's the motivation? I honestly don't understand
>> what you're trying to accomplish and thus I feel like you're
>> presenting a solution to something that isn't a problem and thereby
>> introducing a problem. Does that make sense?
>
> True, I don't understand this problem either...

Let me please quote our chief of everything... "you don't have to".

-- 
"I'm living proof if you do one thing right in your career, you can
coast for a long time. A LOOOOONG time." -Guy Kawasaki


From zawadaa at gmail.com  Fri Apr 20 22:17:46 2012
From: zawadaa at gmail.com (Andrzej Zawadzki)
Date: Fri, 20 Apr 2012 22:17:46 +0200
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <CADfyV2PjKsP7=odNzPqKr_tVP+LXD5Q-BBfvsSJDmgz2U+T3oQ@mail.gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <4F91B8EC.8030807@gmail.com>
 <CADfyV2PjKsP7=odNzPqKr_tVP+LXD5Q-BBfvsSJDmgz2U+T3oQ@mail.gmail.com>
Message-ID: <4F91C46A.7060507@gmail.com>

On 20.04.2012 21:38, Bartosz ?wi?tek wrote:
> W dniu 20 kwietnia 2012 21:28 u?ytkownik Andrzej Zawadzki
> <zawadaa at gmail.com>  napisa?:
>> On 20.04.2012 20:57, Caleb Maclennan wrote:
>>>> well... if you need more stable line, then why not to create one with
>>>> appropriate
>>>> branch in CVS? of course, the problem is that somebody needs to maintain
>>>> that,
>>>> which I believe is full time job and lack of resources causes the stable
>>>> branch
>>>> to freeze. therefore, imho, it is not good idea to link CVS HEAD with
>>>> stable
>>>> line - and that was the result of similar discussions in the past if i
>>>> reckon well.
>>>>
>>>> if you need more reassurance, then what about introducing TH-STABLE tag
>>>> and
>>>> sending packages to builders only when they are tagged with above?
>>> A tag scheme like that could of course work. Again I would ask ask
>>> how, other than different tag names, this is different from the status
>>> quo. Please answer this: what do you see as the advantage to having an
>>> RC release tagged HEAD instead of DEVEL? How does merging DEVEL into
>>> HEAD before it's going to be a candidate for FTP make life any
>>> different for you? What's the motivation? I honestly don't understand
>>> what you're trying to accomplish and thus I feel like you're
>>> presenting a solution to something that isn't a problem and thereby
>>> introducing a problem. Does that make sense?
>> True, I don't understand this problem either...
> Let me please quote our chief of everything... "you don't have to".
Smartass? ;-)
Bartoszu you need to be more consistent :-P
http://permalink.gmane.org/gmane.linux.pld.devel.polish/34668
Last sentence...

-- 
Andrzej


From wrobell at pld-linux.org  Fri Apr 20 22:26:56 2012
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Fri, 20 Apr 2012 21:26:56 +0100
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
Message-ID: <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>

On Fri, Apr 20, 2012 at 7:57 PM, Caleb Maclennan <caleb at pld-linux.org> wrote:
>> well... if you need more stable line, then why not to create one with
>> appropriate
>> branch in CVS? of course, the problem is that somebody needs to maintain that,
>> which I believe is full time job and lack of resources causes the stable branch
>> to freeze. therefore, imho, it is not good idea to link CVS HEAD with stable
>> line - and that was the result of similar discussions in the past if i
>> reckon well.
>>
>> if you need more reassurance, then what about introducing TH-STABLE tag and
>> sending packages to builders only when they are tagged with above?
>
> A tag scheme like that could of course work. Again I would ask ask
> how, other than different tag names, this is different from the status
> quo.

it is very simple. "th-stable", "ac-stable" or whatever... provide
meaningful, self documenting names to things.

you want to discuss strategy on CVS HEAD, then... well... you have
few things to consider

- in the past Ra or Ac could be on CVS HEAD, which one it should be back then?
- now it could be Th... but why not Ti?
- what about future if some other distro lines happen?

again, meaningful tag names do not cause above problems.

[...]

w


From caleb at pld-linux.org  Fri Apr 20 22:28:52 2012
From: caleb at pld-linux.org (Caleb Maclennan)
Date: Fri, 20 Apr 2012 23:28:52 +0300
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <CADfyV2MrXkbzL=N47eY5bGJChMdA+BPi6mh=a-jjeq7qyGp6iw@mail.gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <CADfyV2MrXkbzL=N47eY5bGJChMdA+BPi6mh=a-jjeq7qyGp6iw@mail.gmail.com>
Message-ID: <CAP9w9P5K6AiW0jB+v+AA2z7xvo9Xw_6E8-rFm_URQ5OSFU49Zg@mail.gmail.com>

> Caleb, "stop trolling"*! You're asking very inconvenient questions :)

Wink wink.

I'm not actually trying to troll or be inconvenient. I'm also not
interested in pointing fingers.

I am a system administrator having a hard time keeping up with all the
broken systems. I think a contributing factor to that is PLD's current
lack of a clear set of release/use/development patterns. I'd like to
see these develop not deteriorate. If we're going to all keep making
use of this thing, our practices as commiters need to at least
gradually grow in both innovation and maintainability.

When things come along that appear to be steps in the opposite of
these directions, I think we should bring them up as something to
solve.

So I'm listening. How does this proposed CVS tagging of RC as HEAD
further these ends? What's the gain? How can we all help?

Caleb


From shadzik at gmail.com  Fri Apr 20 22:50:53 2012
From: shadzik at gmail.com (=?UTF-8?B?QmFydG9zeiDFmndpxIV0ZWs=?=)
Date: Fri, 20 Apr 2012 22:50:53 +0200
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
Message-ID: <CADfyV2PEm-TZYBHn3E65hTVJgz5HrNJQ9hGEOkch1tOgQKaybg@mail.gmail.com>

W dniu 20 kwietnia 2012 22:26 u?ytkownik Artur Wroblewski
<wrobell at pld-linux.org> napisa?:
> On Fri, Apr 20, 2012 at 7:57 PM, Caleb Maclennan <caleb at pld-linux.org> wrote:
>>> well... if you need more stable line, then why not to create one with
>>> appropriate
>>> branch in CVS? of course, the problem is that somebody needs to maintain that,
>>> which I believe is full time job and lack of resources causes the stable branch
>>> to freeze. therefore, imho, it is not good idea to link CVS HEAD with stable
>>> line - and that was the result of similar discussions in the past if i
>>> reckon well.
>>>
>>> if you need more reassurance, then what about introducing TH-STABLE tag and
>>> sending packages to builders only when they are tagged with above?
>>
>> A tag scheme like that could of course work. Again I would ask ask
>> how, other than different tag names, this is different from the status
>> quo.
>
> it is very simple. "th-stable", "ac-stable" or whatever... provide
> meaningful, self documenting names to things.
>
> you want to discuss strategy on CVS HEAD, then... well... you have
> few things to consider

I really really am confused now. You're pretending your side of the
story is how it's always been done in PLD. It's really not. HEAD was
always reserved for stable package releases.

>
> - in the past Ra or Ac could be on CVS HEAD, which one it should be back then?

Now Th is on HEAD, rolling development, doesn't mean on HEAD can be
anything. Try to understand, there're some people here who actually
care if the OS that they use is stable.

> - now it could be Th... but why not Ti?

It is. Th is on HEAD and that's a fact. Why not Ti? Because Ti is now
TLD and totally separated from PLD (thanks to one individual who
couldn't stand sharing ep09 with Ti, even though it's not his
machine).

> - what about future if some other distro lines happen?

Unofficial distro lines were always banished to other branches.

>
> again, meaningful tag names do not cause above problems.

So, what causes your problem with using DEVEL for your unstable Gimp
release? You seem to think that everyone else needs good arguments to
keep the things like they are now. The fact is that you need good
reasoning to put unstable releases on a branch considered stable.



-- 
"I'm living proof if you do one thing right in your career, you can
coast for a long time. A LOOOOONG time." -Guy Kawasaki


From caleb at pld-linux.org  Fri Apr 20 22:54:25 2012
From: caleb at pld-linux.org (Caleb Maclennan)
Date: Fri, 20 Apr 2012 23:54:25 +0300
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
Message-ID: <CAP9w9P5tzznR4_OiB+4X-DZYf=0QVnjsM8_CRq0c29V7MquQCg@mail.gmail.com>

2012/4/20 Artur Wroblewski <wrobell at pld-linux.org>:
> it is very simple. "th-stable", "ac-stable" or whatever... provide
> meaningful, self documenting names to things.

Hey guys, how does this compute? My version control experience is
mostly subversion with a bit of git lately. CVS is still black magic
to me. Would a change like this (Tagging stable stuff that's headed to
ftp somewhere instead of pulling HEAD?)

Also to throw this out there, how does all this figure into the git
migration? Are we barking up a tree that is about to be felled anyway?

Artur ... I'm still not clear on what you GAIN by using HEAD instead
of DEVEL? In spite of the name, isn't HEAD basically functioning as
th-stable (plus some mess)?

Caleb


From wrobell at pld-linux.org  Fri Apr 20 23:07:14 2012
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Fri, 20 Apr 2012 22:07:14 +0100
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <CADfyV2PEm-TZYBHn3E65hTVJgz5HrNJQ9hGEOkch1tOgQKaybg@mail.gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
 <CADfyV2PEm-TZYBHn3E65hTVJgz5HrNJQ9hGEOkch1tOgQKaybg@mail.gmail.com>
Message-ID: <CA+92fu9uhDS8Pcyo3Nh-ymOJEML=v8A934LTdW8wwA10dRmUHg@mail.gmail.com>

2012/4/20 Bartosz ?wi?tek <shadzik at gmail.com>:
> W dniu 20 kwietnia 2012 22:26 u?ytkownik Artur Wroblewski
> <wrobell at pld-linux.org> napisa?:
>> On Fri, Apr 20, 2012 at 7:57 PM, Caleb Maclennan <caleb at pld-linux.org> wrote:
>>>> well... if you need more stable line, then why not to create one with
>>>> appropriate
>>>> branch in CVS? of course, the problem is that somebody needs to maintain that,
>>>> which I believe is full time job and lack of resources causes the stable branch
>>>> to freeze. therefore, imho, it is not good idea to link CVS HEAD with stable
>>>> line - and that was the result of similar discussions in the past if i
>>>> reckon well.
>>>>
>>>> if you need more reassurance, then what about introducing TH-STABLE tag and
>>>> sending packages to builders only when they are tagged with above?
>>>
>>> A tag scheme like that could of course work. Again I would ask ask
>>> how, other than different tag names, this is different from the status
>>> quo.
>>
>> it is very simple. "th-stable", "ac-stable" or whatever... provide
>> meaningful, self documenting names to things.
>>
>> you want to discuss strategy on CVS HEAD, then... well... you have
>> few things to consider
>
> I really really am confused now. You're pretending your side of the
> story is how it's always been done in PLD. It's really not. HEAD was
> always reserved for stable package releases.

right... especially in Ra and Ac times...

[...]

w


From gotar at polanet.pl  Sat Apr 21 11:14:48 2012
From: gotar at polanet.pl (Tomasz Pala)
Date: Sat, 21 Apr 2012 11:14:48 +0200
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <CA+92fu9uhDS8Pcyo3Nh-ymOJEML=v8A934LTdW8wwA10dRmUHg@mail.gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
 <CADfyV2PEm-TZYBHn3E65hTVJgz5HrNJQ9hGEOkch1tOgQKaybg@mail.gmail.com>
 <CA+92fu9uhDS8Pcyo3Nh-ymOJEML=v8A934LTdW8wwA10dRmUHg@mail.gmail.com>
Message-ID: <20120421091448.GA30730@polanet.pl>

On Fri, Apr 20, 2012 at 22:07:14 +0100, Artur Wroblewski wrote:

>> I really really am confused now. You're pretending your side of the
>> story is how it's always been done in PLD. It's really not. HEAD was
>> always reserved for stable package releases.
> 
> right... especially in Ra and Ac times...

Ra and Ac was detached from HEAD when they were released (i.e. frozen).
Th is not.
You keep avoiding one simple answer: why don't you want to use DEVEL?
This is the tag designated _exactly_ for this purpose.

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


From gotar at polanet.pl  Sat Apr 21 11:19:05 2012
From: gotar at polanet.pl (Tomasz Pala)
Date: Sat, 21 Apr 2012 11:19:05 +0200
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <CAP9w9P5tzznR4_OiB+4X-DZYf=0QVnjsM8_CRq0c29V7MquQCg@mail.gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
 <CAP9w9P5tzznR4_OiB+4X-DZYf=0QVnjsM8_CRq0c29V7MquQCg@mail.gmail.com>
Message-ID: <20120421091904.GB30730@polanet.pl>

On Fri, Apr 20, 2012 at 23:54:25 +0300, Caleb Maclennan wrote:

> Artur ... I'm still not clear on what you GAIN by using HEAD instead
> of DEVEL? In spite of the name, isn't HEAD basically functioning as
> th-stable (plus some mess)?

I assume he gains only one thing - he can commit what he wants to have
and made everyone else fixing related stuff. Such 'solution' was the
right of release manager so far.

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


From wrobell at pld-linux.org  Sat Apr 21 11:39:31 2012
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Sat, 21 Apr 2012 10:39:31 +0100
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <20120421091448.GA30730@polanet.pl>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
 <CADfyV2PEm-TZYBHn3E65hTVJgz5HrNJQ9hGEOkch1tOgQKaybg@mail.gmail.com>
 <CA+92fu9uhDS8Pcyo3Nh-ymOJEML=v8A934LTdW8wwA10dRmUHg@mail.gmail.com>
 <20120421091448.GA30730@polanet.pl>
Message-ID: <CA+92fu9OJcYsDWSVHwp2pT8gbbhcRydaCLX7Vsx+PN3WzNNWRg@mail.gmail.com>

On Sat, Apr 21, 2012 at 10:14 AM, Tomasz Pala <gotar at polanet.pl> wrote:
> On Fri, Apr 20, 2012 at 22:07:14 +0100, Artur Wroblewski wrote:
>
>>> I really really am confused now. You're pretending your side of the
>>> story is how it's always been done in PLD. It's really not. HEAD was
>>> always reserved for stable package releases.
>>
>> right... especially in Ra and Ac times...
>
> Ra and Ac was detached from HEAD when they were released (i.e. frozen).
> Th is not.
> You keep avoiding one simple answer: why don't you want to use DEVEL?
> This is the tag designated _exactly_ for this purpose.

1. DEVEL is for unstable versions - we are talking about RC.

2. the release announcement contains the following statement

    The changes in GIMP 2.8rc1 since 2.7.5 are mostly not
user-visible. We merely
    updated the code to work with newer versions of GEGL and babl, fixed GFig
    rendering issues and used all the translation updates we got to the point.

3.  it does not look like there are major issues with 2.8rc1.

4. on top of that, i have tested it with my workflows before sending
the very first
email proposing the merge on HEAD.

5. babl and gegl are on HEAD anyway.

therefore, imho, it is worth _starting_ upgrading (but if you send it
to builders, then
it is your stupidity).

i was quite often putting rc versions on HEAD (depending on a project progress).
it was not a problem until now. it seems like some people want some more strict
rules about th development - iron them out and propose them on this
list. if not,
then we are wasting each other time.

regards,

w


From wolf.pld at gmail.com  Sat Apr 21 11:52:26 2012
From: wolf.pld at gmail.com (Bartosz Taudul)
Date: Sat, 21 Apr 2012 11:52:26 +0200
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <CA+92fu9OJcYsDWSVHwp2pT8gbbhcRydaCLX7Vsx+PN3WzNNWRg@mail.gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
 <CADfyV2PEm-TZYBHn3E65hTVJgz5HrNJQ9hGEOkch1tOgQKaybg@mail.gmail.com>
 <CA+92fu9uhDS8Pcyo3Nh-ymOJEML=v8A934LTdW8wwA10dRmUHg@mail.gmail.com>
 <20120421091448.GA30730@polanet.pl>
 <CA+92fu9OJcYsDWSVHwp2pT8gbbhcRydaCLX7Vsx+PN3WzNNWRg@mail.gmail.com>
Message-ID: <CAAz5wPhuPd_c6E3Wj=xYi+LKoj_OnrciNA_qj=jOGjBF7ao6mQ@mail.gmail.com>

On Sat, Apr 21, 2012 at 11:39 AM, Artur Wroblewski
<wrobell at pld-linux.org> wrote:
> 1. DEVEL is for unstable versions - we are talking about RC.
If this Release Candidate is stable, then why is it a Release
Candidate and not the final version? Please tell us.

> 2. the release announcement contains the following statement
>
> ? ?The changes in GIMP 2.8rc1 since 2.7.5 are mostly not
> user-visible. We merely
> ? ?updated the code to work with newer versions of GEGL and babl, fixed GFig
> ? ?rendering issues and used all the translation updates we got to the point.
Oh, so we might as well have 2.7.5 on HEAD? Why not 2.7.1?

> 3. ?it does not look like there are major issues with 2.8rc1.
http://lkml.indiana.edu/hypermail/linux/kernel/0110.1/0932.html

I am sure 2.4.11 also didn't look like it would have any major issues.

> 4. on top of that, i have tested it with my workflows
Oh wow. Please go away and be back when you test MY workflow and
ensure it works flawlessly.

> therefore, imho, it is worth _starting_ upgrading
Then do it on DEVEL and merge to HEAD when the stable version is
released and stop trolling already.

wolf


From baggins at pld-linux.org  Sat Apr 21 11:56:08 2012
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 21 Apr 2012 11:56:08 +0200
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <20120421091904.GB30730@polanet.pl>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
 <CAP9w9P5tzznR4_OiB+4X-DZYf=0QVnjsM8_CRq0c29V7MquQCg@mail.gmail.com>
 <20120421091904.GB30730@polanet.pl>
Message-ID: <20120421095608.GA1465@home.lan>

On Sat, 21 Apr 2012, Tomasz Pala wrote:

> On Fri, Apr 20, 2012 at 23:54:25 +0300, Caleb Maclennan wrote:
> 
> > Artur ... I'm still not clear on what you GAIN by using HEAD instead
> > of DEVEL? In spite of the name, isn't HEAD basically functioning as
> > th-stable (plus some mess)?
> 
> I assume he gains only one thing - he can commit what he wants to have
> and made everyone else fixing related stuff. Such 'solution' was the
> right of release manager so far.

Please stop playing stupid. What related stuff?
We are talking about *gimp* here, a bitmap graphics *program*,
not a critical lib, not even _a_ lib, there is only just a few
plugins for it.

poldek:/all-avail> what-requires libgimp*-2.0.so.0()(64bit)
11 package(s) found:
gimp-2.6.12-3.x86_64
gimp-aa-2.6.12-3.x86_64
gimp-libs-2.6.12-3.x86_64
gimp-plugin-dds-2.0.7-1.x86_64
gimp-plugin-gtkam-0.1.17-2.x86_64
gimp-plugin-gutenprint-5.2.7-5.x86_64
gimp-plugin-lqr-0.6.1-1.x86_64
gimp-plugin-ufraw-0.18-4.x86_64
gimp-svg-2.6.12-3.x86_64
sane-frontends-1.0.14-1.x86_64
xsane-0.998-5.x86_64

I don't see a problem with 2.8rc1 on HEAD, especially when gimp.org
officially stated EOL on 2.6 line.

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


From shadzik at gmail.com  Sat Apr 21 12:05:01 2012
From: shadzik at gmail.com (=?UTF-8?B?QmFydG9zeiDFmndpxIV0ZWs=?=)
Date: Sat, 21 Apr 2012 12:05:01 +0200
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <CA+92fu9OJcYsDWSVHwp2pT8gbbhcRydaCLX7Vsx+PN3WzNNWRg@mail.gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
 <CADfyV2PEm-TZYBHn3E65hTVJgz5HrNJQ9hGEOkch1tOgQKaybg@mail.gmail.com>
 <CA+92fu9uhDS8Pcyo3Nh-ymOJEML=v8A934LTdW8wwA10dRmUHg@mail.gmail.com>
 <20120421091448.GA30730@polanet.pl>
 <CA+92fu9OJcYsDWSVHwp2pT8gbbhcRydaCLX7Vsx+PN3WzNNWRg@mail.gmail.com>
Message-ID: <CADfyV2M781_C1CgppD6sQXKztMHQNdAWw-fOCc_3gqVc9HEaog@mail.gmail.com>

W dniu 21 kwietnia 2012 11:39 u?ytkownik Artur Wroblewski
<wrobell at pld-linux.org> napisa?:
> On Sat, Apr 21, 2012 at 10:14 AM, Tomasz Pala <gotar at polanet.pl> wrote:
>> On Fri, Apr 20, 2012 at 22:07:14 +0100, Artur Wroblewski wrote:
>>
>>>> I really really am confused now. You're pretending your side of the
>>>> story is how it's always been done in PLD. It's really not. HEAD was
>>>> always reserved for stable package releases.
>>>
>>> right... especially in Ra and Ac times...
>>
>> Ra and Ac was detached from HEAD when they were released (i.e. frozen).
>> Th is not.
>> You keep avoiding one simple answer: why don't you want to use DEVEL?
>> This is the tag designated _exactly_ for this purpose.
>
> 1. DEVEL is for unstable versions - we are talking about RC.

And RC is stable? ;)

>
> 2. the release announcement contains the following statement
>
> ? ?The changes in GIMP 2.8rc1 since 2.7.5 are mostly not
> user-visible. We merely
> ? ?updated the code to work with newer versions of GEGL and babl, fixed GFig
> ? ?rendering issues and used all the translation updates we got to the point.
>
> 3. ?it does not look like there are major issues with 2.8rc1.

Justin Bieber looks like a girl. You see, looks can be deceiving.

>
> 4. on top of that, i have tested it with my workflows before sending
> the very first
> email proposing the merge on HEAD.

Ok, no comment.

>
> 5. babl and gegl are on HEAD anyway.
>
> therefore, imho, it is worth _starting_ upgrading (but if you send it
> to builders, then
> it is your stupidity).
>
> i was quite often putting rc versions on HEAD (depending on a project progress).

Then you were quite often bending the rules, weren't you?


-- 
"I'm living proof if you do one thing right in your career, you can
coast for a long time. A LOOOOONG time." -Guy Kawasaki


From shadzik at gmail.com  Sat Apr 21 12:06:30 2012
From: shadzik at gmail.com (=?UTF-8?B?QmFydG9zeiDFmndpxIV0ZWs=?=)
Date: Sat, 21 Apr 2012 12:06:30 +0200
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <20120421095608.GA1465@home.lan>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
 <CAP9w9P5tzznR4_OiB+4X-DZYf=0QVnjsM8_CRq0c29V7MquQCg@mail.gmail.com>
 <20120421091904.GB30730@polanet.pl>
 <20120421095608.GA1465@home.lan>
Message-ID: <CADfyV2MECFcWLkaD0C5oQuZMpsXo7vtthziYAthQht5_pGqcdw@mail.gmail.com>

W dniu 21 kwietnia 2012 11:56 u?ytkownik Jan R?korajski
<baggins at pld-linux.org> napisa?:
> On Sat, 21 Apr 2012, Tomasz Pala wrote:
>
>> On Fri, Apr 20, 2012 at 23:54:25 +0300, Caleb Maclennan wrote:
>>
>> > Artur ... I'm still not clear on what you GAIN by using HEAD instead
>> > of DEVEL? In spite of the name, isn't HEAD basically functioning as
>> > th-stable (plus some mess)?
>>
>> I assume he gains only one thing - he can commit what he wants to have
>> and made everyone else fixing related stuff. Such 'solution' was the
>> right of release manager so far.
>
> Please stop playing stupid. What related stuff?
> We are talking about *gimp* here, a bitmap graphics *program*,
> not a critical lib, not even _a_ lib, there is only just a few
> plugins for it.

It may seem unbelievable to you, but there are people who use
*uncritical* *programs* for living. How absurd is that! Right?

-- 
"I'm living proof if you do one thing right in your career, you can
coast for a long time. A LOOOOONG time." -Guy Kawasaki


From wolf.pld at gmail.com  Sat Apr 21 12:11:01 2012
From: wolf.pld at gmail.com (Bartosz Taudul)
Date: Sat, 21 Apr 2012 12:11:01 +0200
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <CADfyV2MECFcWLkaD0C5oQuZMpsXo7vtthziYAthQht5_pGqcdw@mail.gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
 <CAP9w9P5tzznR4_OiB+4X-DZYf=0QVnjsM8_CRq0c29V7MquQCg@mail.gmail.com>
 <20120421091904.GB30730@polanet.pl>
 <20120421095608.GA1465@home.lan>
 <CADfyV2MECFcWLkaD0C5oQuZMpsXo7vtthziYAthQht5_pGqcdw@mail.gmail.com>
Message-ID: <CAAz5wPipAgyD1-aqP+rMn6M4yb_mBNAPWyTW=aH7FBtR3mA+9w@mail.gmail.com>

2012/4/21 Bartosz ?wi?tek <shadzik at gmail.com>:
> It may seem unbelievable to you, but there are people who use
> *uncritical* *programs* for living. How absurd is that! Right?
I am thinking about doing some changes to apache. Or maybe mysql. No,
python would be the best one to modify. Think "breaks everything"
changes. I'm sure it's OK with you guys, as *I* don't need these
*programs*. These are not even libraries, just programs. So no problem
there, right baggins?

wolf


From shadzik at gmail.com  Sat Apr 21 12:15:31 2012
From: shadzik at gmail.com (=?UTF-8?B?QmFydG9zeiDFmndpxIV0ZWs=?=)
Date: Sat, 21 Apr 2012 12:15:31 +0200
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <CAAz5wPipAgyD1-aqP+rMn6M4yb_mBNAPWyTW=aH7FBtR3mA+9w@mail.gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
 <CAP9w9P5tzznR4_OiB+4X-DZYf=0QVnjsM8_CRq0c29V7MquQCg@mail.gmail.com>
 <20120421091904.GB30730@polanet.pl>
 <20120421095608.GA1465@home.lan>
 <CADfyV2MECFcWLkaD0C5oQuZMpsXo7vtthziYAthQht5_pGqcdw@mail.gmail.com>
 <CAAz5wPipAgyD1-aqP+rMn6M4yb_mBNAPWyTW=aH7FBtR3mA+9w@mail.gmail.com>
Message-ID: <CADfyV2O1XZNjHPB6uOtJ-MmLntm5RUfUmBmwsEn0bjJm2nvb8w@mail.gmail.com>

W dniu 21 kwietnia 2012 12:11 u?ytkownik Bartosz Taudul
<wolf.pld at gmail.com> napisa?:
> 2012/4/21 Bartosz ?wi?tek <shadzik at gmail.com>:
>> It may seem unbelievable to you, but there are people who use
>> *uncritical* *programs* for living. How absurd is that! Right?
> I am thinking about doing some changes to apache. Or maybe mysql. No,
> python would be the best one to modify. Think "breaks everything"
> changes. I'm sure it's OK with you guys, as *I* don't need these
> *programs*. These are not even libraries, just programs. So no problem
> there, right baggins?

Or maybe cups. Cups is just a *program*, a worthless *printing*
program. Who uses printers these days anyway? ;)
"Stable is boring"?.

-- 
"I'm living proof if you do one thing right in your career, you can
coast for a long time. A LOOOOONG time." -Guy Kawasaki


From wrobell at pld-linux.org  Sat Apr 21 13:14:46 2012
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Sat, 21 Apr 2012 12:14:46 +0100
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <CADfyV2O1XZNjHPB6uOtJ-MmLntm5RUfUmBmwsEn0bjJm2nvb8w@mail.gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
 <CAP9w9P5tzznR4_OiB+4X-DZYf=0QVnjsM8_CRq0c29V7MquQCg@mail.gmail.com>
 <20120421091904.GB30730@polanet.pl>
 <20120421095608.GA1465@home.lan>
 <CADfyV2MECFcWLkaD0C5oQuZMpsXo7vtthziYAthQht5_pGqcdw@mail.gmail.com>
 <CAAz5wPipAgyD1-aqP+rMn6M4yb_mBNAPWyTW=aH7FBtR3mA+9w@mail.gmail.com>
 <CADfyV2O1XZNjHPB6uOtJ-MmLntm5RUfUmBmwsEn0bjJm2nvb8w@mail.gmail.com>
Message-ID: <CA+92fu_Hcy4fg0RuHtdn_hH0mUU8GyEEDqB0YSNpTDkYiaBroA@mail.gmail.com>

2012/4/21 Bartosz ?wi?tek <shadzik at gmail.com>:
[...]
> "Stable is boring"?.

well, why you have switched from the Ac and jumped on
the development distro line? you know, Ac was supposed
to be the stable version with multiple releases until it got
abandoned by people like you.

i have proposed TH-STABLE tag. not enough for you? then create
new stable line. it is simple like that.

regards,

w


From shadzik at gmail.com  Sat Apr 21 13:18:32 2012
From: shadzik at gmail.com (=?UTF-8?B?QmFydG9zeiDFmndpxIV0ZWs=?=)
Date: Sat, 21 Apr 2012 13:18:32 +0200
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <CA+92fu_Hcy4fg0RuHtdn_hH0mUU8GyEEDqB0YSNpTDkYiaBroA@mail.gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
 <CAP9w9P5tzznR4_OiB+4X-DZYf=0QVnjsM8_CRq0c29V7MquQCg@mail.gmail.com>
 <20120421091904.GB30730@polanet.pl>
 <20120421095608.GA1465@home.lan>
 <CADfyV2MECFcWLkaD0C5oQuZMpsXo7vtthziYAthQht5_pGqcdw@mail.gmail.com>
 <CAAz5wPipAgyD1-aqP+rMn6M4yb_mBNAPWyTW=aH7FBtR3mA+9w@mail.gmail.com>
 <CADfyV2O1XZNjHPB6uOtJ-MmLntm5RUfUmBmwsEn0bjJm2nvb8w@mail.gmail.com>
 <CA+92fu_Hcy4fg0RuHtdn_hH0mUU8GyEEDqB0YSNpTDkYiaBroA@mail.gmail.com>
Message-ID: <CADfyV2NPxJcrAwe+aL3Z8A8q1+c52OhV5TAYLmOV_0u0W3MTGA@mail.gmail.com>

W dniu 21 kwietnia 2012 13:14 u?ytkownik Artur Wroblewski
<wrobell at pld-linux.org> napisa?:
> 2012/4/21 Bartosz ?wi?tek <shadzik at gmail.com>:
> [...]
>> "Stable is boring"?.
>
> well, why you have switched from the Ac and jumped on
> the development distro line? you know, Ac was supposed
> to be the stable version with multiple releases until it got
> abandoned by people like you.
>
> i have proposed TH-STABLE tag. not enough for you? then create
> new stable line. it is simple like that.

No. HEAD is your proposed TH-STABLE, and DEVEL is for alphas, betas and RCs ;)
It's as simple as that.


-- 
"I'm living proof if you do one thing right in your career, you can
coast for a long time. A LOOOOONG time." -Guy Kawasaki


From wrobell at pld-linux.org  Sat Apr 21 13:29:53 2012
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Sat, 21 Apr 2012 12:29:53 +0100
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <CADfyV2NPxJcrAwe+aL3Z8A8q1+c52OhV5TAYLmOV_0u0W3MTGA@mail.gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
 <CAP9w9P5tzznR4_OiB+4X-DZYf=0QVnjsM8_CRq0c29V7MquQCg@mail.gmail.com>
 <20120421091904.GB30730@polanet.pl>
 <20120421095608.GA1465@home.lan>
 <CADfyV2MECFcWLkaD0C5oQuZMpsXo7vtthziYAthQht5_pGqcdw@mail.gmail.com>
 <CAAz5wPipAgyD1-aqP+rMn6M4yb_mBNAPWyTW=aH7FBtR3mA+9w@mail.gmail.com>
 <CADfyV2O1XZNjHPB6uOtJ-MmLntm5RUfUmBmwsEn0bjJm2nvb8w@mail.gmail.com>
 <CA+92fu_Hcy4fg0RuHtdn_hH0mUU8GyEEDqB0YSNpTDkYiaBroA@mail.gmail.com>
 <CADfyV2NPxJcrAwe+aL3Z8A8q1+c52OhV5TAYLmOV_0u0W3MTGA@mail.gmail.com>
Message-ID: <CA+92fu-64d-m-r7utJi1_S_+7W+uHJLfCNGFzt0KBVfu-895Wg@mail.gmail.com>

2012/4/21 Bartosz ?wi?tek <shadzik at gmail.com>:
> W dniu 21 kwietnia 2012 13:14 u?ytkownik Artur Wroblewski
> <wrobell at pld-linux.org> napisa?:
>> 2012/4/21 Bartosz ?wi?tek <shadzik at gmail.com>:
>> [...]
>>> "Stable is boring"(tm).
>>
>> well, why you have switched from the Ac and jumped on
>> the development distro line? you know, Ac was supposed
>> to be the stable version with multiple releases until it got
>> abandoned by people like you.
>>
>> i have proposed TH-STABLE tag. not enough for you? then create
>> new stable line. it is simple like that.
>
> No. HEAD is your proposed TH-STABLE, and DEVEL is for alphas, betas and RCs ;)
> It's as simple as that.

there is no direct mapping between th ready or th test and CVS HEAD. check
by yourself.

regards,

w


From gotar at polanet.pl  Sat Apr 21 21:59:51 2012
From: gotar at polanet.pl (Tomasz Pala)
Date: Sat, 21 Apr 2012 21:59:51 +0200
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <CA+92fu9OJcYsDWSVHwp2pT8gbbhcRydaCLX7Vsx+PN3WzNNWRg@mail.gmail.com>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
 <CADfyV2PEm-TZYBHn3E65hTVJgz5HrNJQ9hGEOkch1tOgQKaybg@mail.gmail.com>
 <CA+92fu9uhDS8Pcyo3Nh-ymOJEML=v8A934LTdW8wwA10dRmUHg@mail.gmail.com>
 <20120421091448.GA30730@polanet.pl>
 <CA+92fu9OJcYsDWSVHwp2pT8gbbhcRydaCLX7Vsx+PN3WzNNWRg@mail.gmail.com>
Message-ID: <20120421195951.GA8400@polanet.pl>

On Sat, Apr 21, 2012 at 10:39:31 +0100, Artur Wroblewski wrote:

>> Ra and Ac was detached from HEAD when they were released (i.e. frozen).
>> Th is not.
>> You keep avoiding one simple answer: why don't you want to use DEVEL?
>> This is the tag designated _exactly_ for this purpose.
> 
> 1. DEVEL is for unstable versions - we are talking about RC.

HEAD is for stable versions - we are talking about RC.

> 2. the release announcement contains the following statement
> 
>     The changes in GIMP 2.8rc1 since 2.7.5 are mostly not user-visible. We merely

Yes, since 2.7.5, not 2.6.

> 3.  it does not look like there are major issues with 2.8rc1.

I think that this decision should be made by authors, not us. Stop
fixing the world please.

> 4. on top of that, i have tested it with my workflows before sending
> the very first email proposing the merge on HEAD.

As above - leave the decision for the authors. Just for the sake - let
people blame them in case of anything.

> 5. babl and gegl are on HEAD anyway.

They shouldn't. But since PLD is in 'always broken' state - why do you
ask anyway?

> therefore, imho, it is worth _starting_ upgrading

That's what DEVEL was made for.

> (but if you send it to builders, then it is your stupidity).

And if such 'stupidity' is required due to any other reason (like new
libpng), who's going to be responsible?

> i was quite often putting rc versions on HEAD (depending on a project progress).
> it was not a problem until now. it seems like some people want some more strict
> rules about th development - iron them out and propose them on this
> list. if not, then we are wasting each other time.

That might explain PLD deterioration.

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


From gotar at polanet.pl  Sat Apr 21 22:10:44 2012
From: gotar at polanet.pl (Tomasz Pala)
Date: Sat, 21 Apr 2012 22:10:44 +0200
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <20120421095608.GA1465@home.lan>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
 <CAP9w9P5tzznR4_OiB+4X-DZYf=0QVnjsM8_CRq0c29V7MquQCg@mail.gmail.com>
 <20120421091904.GB30730@polanet.pl>
 <20120421095608.GA1465@home.lan>
Message-ID: <20120421201044.GB8400@polanet.pl>

On Sat, Apr 21, 2012 at 11:56:08 +0200, Jan R?korajski wrote:

>> I assume he gains only one thing - he can commit what he wants to have
>> and made everyone else fixing related stuff. Such 'solution' was the
>> right of release manager so far.
> 
> Please stop playing stupid.

Please stop screwing the rules.

> What related stuff?

Plugins mentioned in initial mail?

> We are talking about *gimp* here, a bitmap graphics *program*,
> not a critical lib, not even _a_ lib, there is only just a few
> plugins for it.

Sure, we might remove them. It's only just a few packages after all,
isn't it? Nobody uses them. They've appeared in our CVS by some magic.

> I don't see a problem with 2.8rc1 on HEAD,

I see a problem with disobedience for shit. All the thread passed
without a single argument, any rationale or profit. If that is the way
PLD is supposed to be developed, we are indeed wasting our time for
nothing.

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


From mike at osdn.org.ua  Sat Apr 21 23:02:48 2012
From: mike at osdn.org.ua (Michael Shigorin)
Date: Sun, 22 Apr 2012 00:02:48 +0300
Subject: th stable (Re: gimp 2.8.0 rc1, gimp plugins)
In-Reply-To: <20120421195951.GA8400@polanet.pl>
References: <CA+92fu_a+hKpDqaacnkS7H+WWULR2TYwqrmceiLQ0VoKOcXaag@mail.gmail.com>
 <CAP9w9P4gY7RQfAXQivOiYVE70Teje=F-HTDKLvAsPK4CODJwZw@mail.gmail.com>
 <CA+92fu-5cacnuyRTqfvMHQ9DwjDS=oVciv9wc2K6fOo5XUwD3w@mail.gmail.com>
 <CADfyV2PEm-TZYBHn3E65hTVJgz5HrNJQ9hGEOkch1tOgQKaybg@mail.gmail.com>
 <CA+92fu9uhDS8Pcyo3Nh-ymOJEML=v8A934LTdW8wwA10dRmUHg@mail.gmail.com>
 <20120421091448.GA30730@polanet.pl>
 <CA+92fu9OJcYsDWSVHwp2pT8gbbhcRydaCLX7Vsx+PN3WzNNWRg@mail.gmail.com>
 <20120421195951.GA8400@polanet.pl>
Message-ID: <20120421210248.GO7507@osdn.org.ua>

On Sat, Apr 21, 2012 at 09:59:51PM +0200, Tomasz Pala wrote:
> That might explain PLD deterioration.

To whom it may concern (but in Russian):
http://lists.altlinux.org/pipermail/devel/2012-April/193673.html
http://lists.altlinux.org/pipermail/devel/2012-April/193855.html

Igor is thinking -- and working hard -- on repository quality
and automation for quite a few years already.  Hope that some
thoughts expressed or collected by him are useful to PLD either.

PS: as we say here, "it's the season of lacking vitamins". :)

-- 
 ---- WBR, Michael Shigorin <mike at altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/


From wrobell at pld-linux.org  Sun Apr 22 02:39:03 2012
From: wrobell at pld-linux.org (Artur Wroblewski)
Date: Sun, 22 Apr 2012 01:39:03 +0100
Subject: packages: authconfig/authconfig.spec - fix python packaging, now
 things exe...
In-Reply-To: <20120420164737.GA5747@lolek.nigdzie>
References: <packages_authconfig_authconfig.spec.1.49@pld-linux.org>
 <packages_authconfig_authconfig.spec.1.50@pld-linux.org>
 <20120420144023.GA12673@mail> <4F918385.1090308@delfi.ee>
 <20120420164737.GA5747@lolek.nigdzie>
Message-ID: <CA+92fu9SyoT+hiTf3tg39tUuEyU78B4ksAUih4FJv8hJ+fr6Rw@mail.gmail.com>

On Fri, Apr 20, 2012 at 5:47 PM, Jacek Konieczny <jajcus at jajcus.net> wrote:
> On Fri, Apr 20, 2012 at 06:40:53PM +0300, Elan Ruusam?e wrote:
>> it doesn't behave here so:
>>
>> here it creates .pyc only for imported modules, if invoked via
>> #!/shebang, no .pyc is created for the script itself:
> [...]
>> > In case if %{_bindir} or %{_sbindir} - no script should be named *.py
>> > there (actually there are some, but they should be fixed).
>> >
>> any explanation why (not that i have against)
>
> The problem is, that if script name is "something.py", then
> if any other python script in the same directory does
> 'import something' (on purpose or because of a name collision) the
> script will be compiled to pyc.
>
> There should be no *.py files in %{_bindir}. If a script is supposed to
> be importable, then it should be stored in %{py_sitescriptdir}, and only
> a wrapper script should be kept in %{_bindir}.
>
> The wrapper can be something like that:
>
> #!/usr/bin/python
> import something
> somethig.run()
>
> or
>
> #!/bin/sh
> exec /usr/bin/python -m something "$@"
>
> Whatever the module expects.

python3.spec simply creates aliases in /etc/shrc.d.

regards,

w