From glen at pld-linux.org  Tue Dec  1 11:51:13 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Tue, 01 Dec 2015 12:51:13 +0200
Subject: ssh_config broken
Message-ID: <565D7BA1.7000609@pld-linux.org>

https://github.com/pld-linux/openssh/commit/00b8e87302dc268a8df8b6f9a2e107e515492249

such commit made ssh config truncated:

? tail /etc/ssh/ssh_config
# mode correctly we set this to yes.
         ForwardX11Trusted yes
         StrictHostKeyChecking no
         ServerAliveInterval 60
         ServerAliveCountMax 10
         TCPKeepAlive no
         # Allow DSA keys
#       PubkeyAcceptedKeyTypes +ssh-dss
#       HostkeyAlgorithms +ssh-dss
# Send locale-related environment variables, also pass some GIT vars
?

first: you (blues) shouldn't use vim to edit patches, at least use 
editdiff from patchutils!

secondly: how to avoid broken patch like this being ignored by build 
process?

-- 
glen



From blues at pld-linux.org  Tue Dec  1 14:41:24 2015
From: blues at pld-linux.org (=?ISO-8859-2?Q?Pawe=B3_Go=B3aszewski?=)
Date: Tue, 1 Dec 2015 14:41:24 +0100 (CET)
Subject: ssh_config broken
In-Reply-To: <565D7BA1.7000609@pld-linux.org>
References: <565D7BA1.7000609@pld-linux.org>
Message-ID: <alpine.DEB.2.20.1512011434050.27938@fgnss.gnfx.tqn.cy>

On Tue, 1 Dec 2015, Elan Ruusam?e wrote:
> https://github.com/pld-linux/openssh/commit/00b8e87302dc268a8df8b6f9a2e107e515492249
> 
> such commit made ssh config truncated:
> 
> ? tail /etc/ssh/ssh_config
> # mode correctly we set this to yes.
>         ForwardX11Trusted yes
>         StrictHostKeyChecking no
>         ServerAliveInterval 60
>         ServerAliveCountMax 10
>         TCPKeepAlive no
>         # Allow DSA keys
> #       PubkeyAcceptedKeyTypes +ssh-dss
> #       HostkeyAlgorithms +ssh-dss
> # Send locale-related environment variables, also pass some GIT vars
> ?
> 
> first: you (blues) shouldn't use vim to edit patches, at least use editdiff
> from patchutils!

:-O

My fault, forgot to change count :-/

Anyway - glen is right, rpm should reject that...

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

From hawk at pld-linux.org  Tue Dec  1 15:05:32 2015
From: hawk at pld-linux.org (Marcin Krol)
Date: Tue, 01 Dec 2015 15:05:32 +0100
Subject: ssh_config broken
In-Reply-To: <alpine.DEB.2.20.1512011434050.27938@fgnss.gnfx.tqn.cy>
References: <565D7BA1.7000609@pld-linux.org>
 <alpine.DEB.2.20.1512011434050.27938@fgnss.gnfx.tqn.cy>
Message-ID: <565DA92C.50301@pld-linux.org>

> Anyway - glen is right, rpm should reject that...

Perhaps we should go debian-like route and accept only patches that 
apply cleanly? Fuzziness can cause code to be inserted/deleted/modified 
in wrong places which can cause compile time errors, segfaults, broken 
configs etc. I encountered such issues many times and most of our 
patches apply with fuzzines or offsets.

M.


From jajcus at jajcus.net  Tue Dec  1 15:24:45 2015
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Tue, 1 Dec 2015 15:24:45 +0100
Subject: ssh_config broken
In-Reply-To: <565DA92C.50301@pld-linux.org>
References: <565D7BA1.7000609@pld-linux.org>
 <alpine.DEB.2.20.1512011434050.27938@fgnss.gnfx.tqn.cy>
 <565DA92C.50301@pld-linux.org>
Message-ID: <565DADAD.8040704@jajcus.net>

On 2015-12-01 15:05, Marcin Krol wrote:
>> Anyway - glen is right, rpm should reject that...
>
> Perhaps we should go debian-like route and accept only patches that
> apply cleanly? Fuzziness can cause code to be inserted/deleted/modified
> in wrong places which can cause compile time errors, segfaults, broken
> configs etc. I encountered such issues many times and most of our
> patches apply with fuzzines or offsets.

But this case was not about fuzzines or invalid patch. Patches are 
allowed to contain trailing data ? they might be part of an e-mail 
message. That is why blues' patch was accepted. The line ignored was 
technically outside of the patch.

Jacek


From glen at pld-linux.org  Tue Dec  1 15:42:15 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Tue, 01 Dec 2015 16:42:15 +0200
Subject: ssh_config broken
In-Reply-To: <alpine.DEB.2.20.1512011434050.27938@fgnss.gnfx.tqn.cy>
References: <565D7BA1.7000609@pld-linux.org>
 <alpine.DEB.2.20.1512011434050.27938@fgnss.gnfx.tqn.cy>
Message-ID: <565DB1C7.5040101@pld-linux.org>

On 01.12.2015 15:41, Pawe? Go?aszewski wrote:
> My fault, forgot to change count :-/
>
> Anyway - glen is right, rpm should reject that...
well. you did not adjust the patch range, so the patch scope stayed the 
same, effectively cut out last line from patch.

the same what jacek said in later thread.

i guess there's no way to fight against such specific failure except 
some automated function testing?

ps:
i do create pld vagrant images regularily [1] that had catched some sshd 
setup errors in the past [2]
but it's not built automatically, only when i hit "build".

[1] https://www.pld-linux.org/people/glen/vm-info
[2] 
http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2015-November/024554.html

-- 
glen



From jajcus at jajcus.net  Tue Dec  1 18:57:14 2015
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Tue, 01 Dec 2015 18:57:14 +0100
Subject: RFC: default python installlation directories
In-Reply-To: <CAKY5yHy9PDaEUTWeFPEgBtb3JxgauSADUwEPO=mtCdo2zEbqhQ@mail.gmail.com>
References: <5651B42C.4030209@jajcus.net> <20151122175208.GA4472@home.lan>
 <565617C9.5010402@jajcus.net> <20151129215813.GA4015@home.lan>
 <20151129223039.GB4015@home.lan> <565BF5CE.5010601@jajcus.net>
 <CAKY5yHy9PDaEUTWeFPEgBtb3JxgauSADUwEPO=mtCdo2zEbqhQ@mail.gmail.com>
Message-ID: <565DDF7A.5030408@jajcus.net>

On 2015-11-30 09:19, Jan R?korajski wrote:
> On Mon, Nov 30, 2015 at 8:07 AM, Jacek Konieczny <jajcus at jajcus.net> wrote:
>> On 2015-11-29 23:30, Jan R?korajski wrote:

>>> OSError: [Errno 13] Permission denied: '/usr/local/share/python2.7'

>> I will investigate this further in the evening.
> 
> A food for thought - what about dropping PLD specific hack with with
> lib<->share split?
> It constantly gives us grief with virtualenv.

I guess I have managed to fix that. Vanila upstream virtualenv seems to
work correctly now, at least when not using --system-site-packages.

I hope I have not introduced many new problems ;)

Jacek


From baggins at pld-linux.org  Tue Dec  1 19:33:36 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 1 Dec 2015 19:33:36 +0100
Subject: RFC: default python installlation directories
In-Reply-To: <565DDF7A.5030408@jajcus.net>
References: <5651B42C.4030209@jajcus.net> <20151122175208.GA4472@home.lan>
 <565617C9.5010402@jajcus.net> <20151129215813.GA4015@home.lan>
 <20151129223039.GB4015@home.lan> <565BF5CE.5010601@jajcus.net>
 <CAKY5yHy9PDaEUTWeFPEgBtb3JxgauSADUwEPO=mtCdo2zEbqhQ@mail.gmail.com>
 <565DDF7A.5030408@jajcus.net>
Message-ID: <20151201183335.GA4207@home.lan>

On Tue, 01 Dec 2015, Jacek Konieczny wrote:

> On 2015-11-30 09:19, Jan R?korajski wrote:
> > On Mon, Nov 30, 2015 at 8:07 AM, Jacek Konieczny <jajcus at jajcus.net> wrote:
> >> On 2015-11-29 23:30, Jan R?korajski wrote:
> 
> >>> OSError: [Errno 13] Permission denied: '/usr/local/share/python2.7'
> 
> >> I will investigate this further in the evening.
> > 
> > A food for thought - what about dropping PLD specific hack with with
> > lib<->share split?
> > It constantly gives us grief with virtualenv.
> 
> I guess I have managed to fix that. Vanila upstream virtualenv seems to
> work correctly now, at least when not using --system-site-packages.

Thank you!

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


From baggins at pld-linux.org  Tue Dec  1 19:57:26 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 1 Dec 2015 19:57:26 +0100
Subject: RFC: default python installlation directories
In-Reply-To: <565DDF7A.5030408@jajcus.net>
References: <5651B42C.4030209@jajcus.net> <20151122175208.GA4472@home.lan>
 <565617C9.5010402@jajcus.net> <20151129215813.GA4015@home.lan>
 <20151129223039.GB4015@home.lan> <565BF5CE.5010601@jajcus.net>
 <CAKY5yHy9PDaEUTWeFPEgBtb3JxgauSADUwEPO=mtCdo2zEbqhQ@mail.gmail.com>
 <565DDF7A.5030408@jajcus.net>
Message-ID: <20151201185725.GB4207@home.lan>

On Tue, 01 Dec 2015, Jacek Konieczny wrote:

> On 2015-11-30 09:19, Jan R?korajski wrote:
> > On Mon, Nov 30, 2015 at 8:07 AM, Jacek Konieczny <jajcus at jajcus.net> wrote:
> >> On 2015-11-29 23:30, Jan R?korajski wrote:
> 
> >>> OSError: [Errno 13] Permission denied: '/usr/local/share/python2.7'
> 
> >> I will investigate this further in the evening.
> > 
> > A food for thought - what about dropping PLD specific hack with with
> > lib<->share split?
> > It constantly gives us grief with virtualenv.
> 
> I guess I have managed to fix that. Vanila upstream virtualenv seems to
> work correctly now, at least when not using --system-site-packages.
> 
> I hope I have not introduced many new problems ;)

Well, icedove still doesn't build, this time with:

Creating Python environment
New python executable in /home/users/baggins/devel/PLD/rpm/BUILD/icedove-38.4.0/obj-x86_64/_virtualenv/bin/python2.7
Also creating executable in /home/users/baggins/devel/PLD/rpm/BUILD/icedove-38.4.0/obj-x86_64/_virtualenv/bin/python
Installing setuptools, pip, wheel...done.
running build_ext

checking Python environment is Mozilla virtualenv... Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named mozbuild.base
configure: error: Python environment does not appear to be sane.
------ config.log ------
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

Doesn't matter if I use mozilla virtualenv, our virtualenv or virtualenv-2.7.

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


From jajcus at jajcus.net  Tue Dec  1 21:57:26 2015
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Tue, 01 Dec 2015 21:57:26 +0100
Subject: RFC: default python installlation directories
In-Reply-To: <20151201185725.GB4207@home.lan>
References: <5651B42C.4030209@jajcus.net> <20151122175208.GA4472@home.lan>
 <565617C9.5010402@jajcus.net> <20151129215813.GA4015@home.lan>
 <20151129223039.GB4015@home.lan> <565BF5CE.5010601@jajcus.net>
 <CAKY5yHy9PDaEUTWeFPEgBtb3JxgauSADUwEPO=mtCdo2zEbqhQ@mail.gmail.com>
 <565DDF7A.5030408@jajcus.net> <20151201185725.GB4207@home.lan>
Message-ID: <565E09B6.4070805@jajcus.net>

On 2015-12-01 19:57, Jan R?korajski wrote:
> On Tue, 01 Dec 2015, Jacek Konieczny wrote:
> Well, icedove still doesn't build, this time with:
> 
> Creating Python environment
> New python executable in /home/users/baggins/devel/PLD/rpm/BUILD/icedove-38.4.0/obj-x86_64/_virtualenv/bin/python2.7
> Also creating executable in /home/users/baggins/devel/PLD/rpm/BUILD/icedove-38.4.0/obj-x86_64/_virtualenv/bin/python
> Installing setuptools, pip, wheel...done.
> running build_ext
> 
> checking Python environment is Mozilla virtualenv... Traceback (most recent call last):
>   File "<string>", line 1, in <module>
> ImportError: No module named mozbuild.base
> configure: error: Python environment does not appear to be sane.
> ------ config.log ------
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
> 
> Doesn't matter if I use mozilla virtualenv, our virtualenv or virtualenv-2.7.

I can see what is the problem now. I'll try to fix it tomorow.

Lets keep that lib/share split only for the site-packages under the /usr
prefix. We need it there. /usr/local and virtualenvs can have the Python
way.

Jacek


From glen at pld-linux.org  Tue Dec  1 23:19:15 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Wed, 02 Dec 2015 00:19:15 +0200
Subject: [packages/python] Prevent pyconfig.h conflicts on multiarch
 systems
In-Reply-To: <538a779a0e99cb53d7deb373f6b5ccbb991ecba7_refs_heads_master@pld-linux.org>
References: <dbafd771e9859b2cdd0028a3c1d8619c55cb7ae9_refs_heads_master@pld-linux.org>
 <538a779a0e99cb53d7deb373f6b5ccbb991ecba7_refs_heads_master@pld-linux.org>
Message-ID: <565E1CE3.2010902@pld-linux.org>

On 01.12.2015 19:49, jajcus wrote:
>      The hack is to have architecture-specific pyconfig-*.h files and a ghost
>      symlink updated with python-devel install. I hope this works.

a cleaner way is to install wrapper header file which based on 
preprocessor variables includes proper arch specific file
no triggers, no scriptlets, no ghosts.

and if the file is identical on both multilib packages, rpm will happily 
install it without complaining

so, it would be something like:

#if X86_64
#include "py-x86_64.h"
#elseif IX86
#include "py-ix86.h"
#else
#error unsupported arch
#endif

-- 
glen



From jajcus at jajcus.net  Wed Dec  2 08:48:02 2015
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 2 Dec 2015 08:48:02 +0100
Subject: [packages/python] Prevent pyconfig.h conflicts on multiarch
 systems
In-Reply-To: <565E1CE3.2010902@pld-linux.org>
References: <dbafd771e9859b2cdd0028a3c1d8619c55cb7ae9_refs_heads_master@pld-linux.org>
 <538a779a0e99cb53d7deb373f6b5ccbb991ecba7_refs_heads_master@pld-linux.org>
 <565E1CE3.2010902@pld-linux.org>
Message-ID: <565EA232.5060705@jajcus.net>

On 2015-12-01 23:19, Elan Ruusam?e wrote:
> On 01.12.2015 19:49, jajcus wrote:
>>      The hack is to have architecture-specific pyconfig-*.h files and
>> a ghost
>>      symlink updated with python-devel install. I hope this works.
>
> a cleaner way is to install wrapper header file which based on
> preprocessor variables includes proper arch specific file
> no triggers, no scriptlets, no ghosts.

?and new compatibility problems with all the Python world,

> and if the file is identical on both multilib packages, rpm will happily
> install it without complaining
>
> so, it would be something like:
>
> #if X86_64
> #include "py-x86_64.h"
> #elseif IX86
> #include "py-ix86.h"
> #else
> #error unsupported arch
> #endif

How would you convince python library to parse this file correctly? 
Another PLD-specific Python patch, which would cause many standard 
Python packages to fail?

My solution is not pretty, but doesn't change a thing from the Python 
perspective.

Jacek


From glen at delfi.ee  Wed Dec  2 13:03:45 2015
From: glen at delfi.ee (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Wed, 02 Dec 2015 14:03:45 +0200
Subject: [packages/python] Prevent pyconfig.h conflicts on multiarch
 systems
In-Reply-To: <565EA232.5060705@jajcus.net>
References: <dbafd771e9859b2cdd0028a3c1d8619c55cb7ae9_refs_heads_master@pld-linux.org>
 <538a779a0e99cb53d7deb373f6b5ccbb991ecba7_refs_heads_master@pld-linux.org>
 <565E1CE3.2010902@pld-linux.org> <565EA232.5060705@jajcus.net>
Message-ID: <565EDE21.1010206@delfi.ee>

On 02.12.2015 09:48, Jacek Konieczny wrote:
> On 2015-12-01 23:19, Elan Ruusam?e wrote:
>> On 01.12.2015 19:49, jajcus wrote:
>>>      The hack is to have architecture-specific pyconfig-*.h files and
>>> a ghost
>>>      symlink updated with python-devel install. I hope this works.
>>
>> a cleaner way is to install wrapper header file which based on
>> preprocessor variables includes proper arch specific file
>> no triggers, no scriptlets, no ghosts.
>
> ?and new compatibility problems with all the Python world,
>
>> and if the file is identical on both multilib packages, rpm will happily
>> install it without complaining
>>
>> so, it would be something like:
>>
>> #if X86_64
>> #include "py-x86_64.h"
>> #elseif IX86
>> #include "py-ix86.h"
>> #else
>> #error unsupported arch
>> #endif
>
> How would you convince python library to parse this file correctly? 
> Another PLD-specific Python patch, which would cause many standard 
> Python packages to fail?
>
> My solution is not pretty, but doesn't change a thing from the Python 
> perspective.

ee, what patch?

i'm speaking of installing "config.h" from static source111, and python 
original rename as config-ARCH.h when packaging.
and the preprocessor macros are generic, from compiler

and my solution doesn't also change a thing from python perspecitve, 
just config.h -> config-ARCH.h redirection is done on file cpp level, 
not symlink.
solution done at packaging time, not at package install time.

also my solution would make rpm -V work properly.

ps: such solution is commonly done in fedora where they do handle 
multilib more thoughtfully than us

-- 
glen



From glen at pld-linux.org  Wed Dec  2 13:05:07 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Wed, 02 Dec 2015 14:05:07 +0200
Subject: java packaging
Message-ID: <565EDE73.8050208@pld-linux.org>

error: Install/Erase problems:
         file /usr/bin/javaws from install of 
oracle-java8-jre-X11-1.8.0.66-1.x86_64 conflicts with file from package 
icedtea-web-1.6-1.x86_64


just dumping info here, i don't expect anything.
just maybe someone thinks javaws should be moved to some subpackage in 
oracle-java8.spec

-- 
glen



From glen at delfi.ee  Wed Dec  2 13:11:52 2015
From: glen at delfi.ee (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Wed, 02 Dec 2015 14:11:52 +0200
Subject: [packages/python] Prevent pyconfig.h conflicts on multiarch
 systems
In-Reply-To: <565EDE21.1010206@delfi.ee>
References: <dbafd771e9859b2cdd0028a3c1d8619c55cb7ae9_refs_heads_master@pld-linux.org>
 <538a779a0e99cb53d7deb373f6b5ccbb991ecba7_refs_heads_master@pld-linux.org>
 <565E1CE3.2010902@pld-linux.org> <565EA232.5060705@jajcus.net>
 <565EDE21.1010206@delfi.ee>
Message-ID: <565EE008.7000808@delfi.ee>

On 02.12.2015 14:03, Elan Ruusam?e wrote:
>
> i'm speaking of installing "config.h" from static source111, and 
> python original rename as config-ARCH.h when packaging. 

so you get the idea, it was in our linux-libc-headers too before 
upstream started to do that themselves:

https://github.com/pld-linux/linux-libc-headers/blob/bd829e04c6c7fb524bd7d012bf9bc67d474b0825/linux-libc-headers.spec

-- 
glen



From jajcus at jajcus.net  Wed Dec  2 14:56:28 2015
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 2 Dec 2015 14:56:28 +0100
Subject: [packages/python] Prevent pyconfig.h conflicts on multiarch
 systems
In-Reply-To: <565EDE21.1010206@delfi.ee>
References: <dbafd771e9859b2cdd0028a3c1d8619c55cb7ae9_refs_heads_master@pld-linux.org>
 <538a779a0e99cb53d7deb373f6b5ccbb991ecba7_refs_heads_master@pld-linux.org>
 <565E1CE3.2010902@pld-linux.org> <565EA232.5060705@jajcus.net>
 <565EDE21.1010206@delfi.ee>
Message-ID: <565EF88C.4040802@jajcus.net>

On 2015-12-02 13:03, Elan Ruusam?e wrote:
>> How would you convince python library to parse this file correctly?
>> Another PLD-specific Python patch, which would cause many standard
>> Python packages to fail?
>>
>> My solution is not pretty, but doesn't change a thing from the Python
>> perspective.
>
> ee, what patch?

At least for this:
https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L422

There might be other Python code parsing this header, as it is 
considered a part of standard Python interface.

> i'm speaking of installing "config.h" from static source111, and python
> original rename as config-ARCH.h when packaging.
> and the preprocessor macros are generic, from compiler

But this file is not only used by the C compiler. If it would be the 
case, then we would ship the file in the -devel package and not the 
-libs packages and there would be no problem.

Jacek


From qboosh at pld-linux.org  Wed Dec  2 15:35:18 2015
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 2 Dec 2015 15:35:18 +0100
Subject: [packages/python] Prevent pyconfig.h conflicts on multiarch
 systems
In-Reply-To: <565EF88C.4040802@jajcus.net>
References: <dbafd771e9859b2cdd0028a3c1d8619c55cb7ae9_refs_heads_master@pld-linux.org>
 <538a779a0e99cb53d7deb373f6b5ccbb991ecba7_refs_heads_master@pld-linux.org>
 <565E1CE3.2010902@pld-linux.org> <565EA232.5060705@jajcus.net>
 <565EDE21.1010206@delfi.ee> <565EF88C.4040802@jajcus.net>
Message-ID: <20151202143518.GA13541@mail>

On Wed, Dec 02, 2015 at 02:56:28PM +0100, Jacek Konieczny wrote:
> On 2015-12-02 13:03, Elan Ruusam?e wrote:
> >>How would you convince python library to parse this file correctly?
> >>Another PLD-specific Python patch, which would cause many standard
> >>Python packages to fail?
> >>
> >>My solution is not pretty, but doesn't change a thing from the Python
> >>perspective.
> >
> >ee, what patch?
> 
> At least for this:
> https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L422
> 
> There might be other Python code parsing this header, as it is 
> considered a part of standard Python interface.
> 
> >i'm speaking of installing "config.h" from static source111, and python
> >original rename as config-ARCH.h when packaging.
> >and the preprocessor macros are generic, from compiler
> 
> But this file is not only used by the C compiler. If it would be the 
> case, then we would ship the file in the -devel package and not the 
> -libs packages and there would be no problem.

get_config_h_filename() should return the ABI-specific file for multilib
installs to work correctly.


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


From glen at pld-linux.org  Wed Dec  2 15:39:33 2015
From: glen at pld-linux.org (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Wed, 02 Dec 2015 16:39:33 +0200
Subject: [packages/python] Prevent pyconfig.h conflicts on multiarch
 systems
In-Reply-To: <565EF88C.4040802@jajcus.net>
References: <dbafd771e9859b2cdd0028a3c1d8619c55cb7ae9_refs_heads_master@pld-linux.org>
 <538a779a0e99cb53d7deb373f6b5ccbb991ecba7_refs_heads_master@pld-linux.org>
 <565E1CE3.2010902@pld-linux.org> <565EA232.5060705@jajcus.net>
 <565EDE21.1010206@delfi.ee> <565EF88C.4040802@jajcus.net>
Message-ID: <565F02A5.4040702@pld-linux.org>

On 02.12.2015 15:56, Jacek Konieczny wrote:
>>
>> ee, what patch?
>
> At least for this:
> https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L422
>
> There might be other Python code parsing this header, as it is 
> considered a part of standard Python interface. 

uh. what a mess!

python sucks then! :D
ruby at least provides such header export in native language (ruby array)

-- 
glen



From jajcus at jajcus.net  Wed Dec  2 15:54:39 2015
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 2 Dec 2015 15:54:39 +0100
Subject: [packages/python] Prevent pyconfig.h conflicts on multiarch
 systems
In-Reply-To: <20151202143518.GA13541@mail>
References: <dbafd771e9859b2cdd0028a3c1d8619c55cb7ae9_refs_heads_master@pld-linux.org>
 <538a779a0e99cb53d7deb373f6b5ccbb991ecba7_refs_heads_master@pld-linux.org>
 <565E1CE3.2010902@pld-linux.org> <565EA232.5060705@jajcus.net>
 <565EDE21.1010206@delfi.ee> <565EF88C.4040802@jajcus.net>
 <20151202143518.GA13541@mail>
Message-ID: <565F062F.6010306@jajcus.net>

On 2015-12-02 15:35, Jakub Bogusz wrote:
> On Wed, Dec 02, 2015 at 02:56:28PM +0100, Jacek Konieczny wrote:

>> At least for this:
>> https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L422
>>

>
> get_config_h_filename() should return the ABI-specific file for multilib
> installs to work correctly.

But then virtualenv will probably fail to copy the right file to the 
right place when making the virtual environment. I will check this, though.

Jacek


From qboosh at pld-linux.org  Wed Dec  2 16:33:42 2015
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 2 Dec 2015 16:33:42 +0100
Subject: pythonegg() vs manual dependencies
Message-ID: <20151202153342.GA14020@mail>

Currently many packages, for which pythonegg()/python3egg() dependencies
are generated, have the same set of dependencies (or outdated version of it)
specified manually in .spec by package name.

Manually specified dependencies duplicating autodetected ones could be
dropped now, but what should be specified as rpm-pythonprov version to
ensure functional pythonegg/python3egg depdencies detector?


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


From jajcus at jajcus.net  Wed Dec  2 17:32:03 2015
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 02 Dec 2015 17:32:03 +0100
Subject: pythonegg() vs manual dependencies
In-Reply-To: <20151202153342.GA14020@mail>
References: <20151202153342.GA14020@mail>
Message-ID: <565F1D03.1090907@jajcus.net>

On 2015-12-02 16:33, Jakub Bogusz wrote:
> Currently many packages, for which pythonegg()/python3egg() dependencies
> are generated, have the same set of dependencies (or outdated version of it)
> specified manually in .spec by package name.

We can do that.

> Manually specified dependencies duplicating autodetected ones could be
> dropped now, but what should be specified as rpm-pythonprov version to
> ensure functional pythonegg/python3egg depdencies detector?

rpm-pythonprov-5.4.15-31 seems to work properly now, but versions before
my optimizations were also ok. The broken RPM never got into th-main AFAIK.

Jacek


From jajcus at jajcus.net  Wed Dec  2 17:37:23 2015
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 02 Dec 2015 17:37:23 +0100
Subject: [packages/python] Prevent pyconfig.h conflicts on multiarch
 systems
In-Reply-To: <565F062F.6010306@jajcus.net>
References: <dbafd771e9859b2cdd0028a3c1d8619c55cb7ae9_refs_heads_master@pld-linux.org>
 <538a779a0e99cb53d7deb373f6b5ccbb991ecba7_refs_heads_master@pld-linux.org>
 <565E1CE3.2010902@pld-linux.org> <565EA232.5060705@jajcus.net>
 <565EDE21.1010206@delfi.ee> <565EF88C.4040802@jajcus.net>
 <20151202143518.GA13541@mail> <565F062F.6010306@jajcus.net>
Message-ID: <565F1E43.60704@jajcus.net>

On 2015-12-02 15:54, Jacek Konieczny wrote:
> On 2015-12-02 15:35, Jakub Bogusz wrote:
>> On Wed, Dec 02, 2015 at 02:56:28PM +0100, Jacek Konieczny wrote:
> 
>>> At least for this:
>>> https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L422
>>>
> 
>>
>> get_config_h_filename() should return the ABI-specific file for multilib
>> installs to work correctly.
> 
> But then virtualenv will probably fail to copy the right file to the
> right place when making the virtual environment. I will check this, though.

It seems virtualenv symlinks whole python include directory and would
not mind different pyconfig*.h files. So patching
get_config_h_filename() and making pyconfig.h include platform-dependent
header could work.

Now I have questions:
1. how should we call thee platform-dependent header files?
2. What set of #if/#ifdef should i use in pyconfig.h to include proper
file on a platform?

Jacek


From jajcus at jajcus.net  Wed Dec  2 18:48:48 2015
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 02 Dec 2015 18:48:48 +0100
Subject: RFC: default python installlation directories
In-Reply-To: <20151201185725.GB4207@home.lan>
References: <5651B42C.4030209@jajcus.net> <20151122175208.GA4472@home.lan>
 <565617C9.5010402@jajcus.net> <20151129215813.GA4015@home.lan>
 <20151129223039.GB4015@home.lan> <565BF5CE.5010601@jajcus.net>
 <CAKY5yHy9PDaEUTWeFPEgBtb3JxgauSADUwEPO=mtCdo2zEbqhQ@mail.gmail.com>
 <565DDF7A.5030408@jajcus.net> <20151201185725.GB4207@home.lan>
Message-ID: <565F2F00.2090204@jajcus.net>

On 2015-12-01 19:57, Jan R?korajski wrote:
> Well, icedove still doesn't build, this time with:
[...]
> checking Python environment is Mozilla virtualenv... Traceback (most recent call last):
>   File "<string>", line 1, in <module>
> ImportError: No module named mozbuild.base
> configure: error: Python environment does not appear to be sane.

Try python-2.7.10-6.1 and rpm-build-macros-1.713

Jacek


From baggins at pld-linux.org  Wed Dec  2 19:59:40 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Wed, 2 Dec 2015 19:59:40 +0100
Subject: RFC: default python installlation directories
In-Reply-To: <565F2F00.2090204@jajcus.net>
References: <5651B42C.4030209@jajcus.net> <20151122175208.GA4472@home.lan>
 <565617C9.5010402@jajcus.net> <20151129215813.GA4015@home.lan>
 <20151129223039.GB4015@home.lan> <565BF5CE.5010601@jajcus.net>
 <CAKY5yHy9PDaEUTWeFPEgBtb3JxgauSADUwEPO=mtCdo2zEbqhQ@mail.gmail.com>
 <565DDF7A.5030408@jajcus.net> <20151201185725.GB4207@home.lan>
 <565F2F00.2090204@jajcus.net>
Message-ID: <20151202185940.GA4058@home.lan>

On Wed, 02 Dec 2015, Jacek Konieczny wrote:

> On 2015-12-01 19:57, Jan R?korajski wrote:
> > Well, icedove still doesn't build, this time with:
> [...]
> > checking Python environment is Mozilla virtualenv... Traceback (most recent call last):
> >   File "<string>", line 1, in <module>
> > ImportError: No module named mozbuild.base
> > configure: error: Python environment does not appear to be sane.
> 
> Try python-2.7.10-6.1 and rpm-build-macros-1.713

Looks good on my machine, I sent a test build to make sure.

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


From jajcus at jajcus.net  Wed Dec  2 21:49:55 2015
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 02 Dec 2015 21:49:55 +0100
Subject: [packages/python] Prevent pyconfig.h conflicts on multiarch
 systems
In-Reply-To: <565E1CE3.2010902@pld-linux.org>
References: <dbafd771e9859b2cdd0028a3c1d8619c55cb7ae9_refs_heads_master@pld-linux.org>
 <538a779a0e99cb53d7deb373f6b5ccbb991ecba7_refs_heads_master@pld-linux.org>
 <565E1CE3.2010902@pld-linux.org>
Message-ID: <565F5973.20607@jajcus.net>

On 2015-12-01 23:19, Elan Ruusam?e wrote:
> On 01.12.2015 19:49, jajcus wrote:
>>      The hack is to have architecture-specific pyconfig-*.h files and
>> a ghost
>>      symlink updated with python-devel install. I hope this works.
> 
> a cleaner way is to install wrapper header file which based on
> preprocessor variables includes proper arch specific file
> no triggers, no scriptlets, no ghosts.

Is it better now?

Jacek



From arekm at maven.pl  Fri Dec  4 08:33:24 2015
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Fri, 4 Dec 2015 08:33:24 +0100
Subject: parallel installation of various php versions (libphp.so)
Message-ID: <201512040833.25009.arekm@maven.pl>


Hi.

I need to install different php versions on single server but what I need is 
different libphp.so modules at parallel.

Currently all php packages provide libphp-X.Y.so which do not conflict but 
also provide libphp.so symlink (and apache config) which do conflict.

One solution to the problem is using alternatives.spec to manage libphp.so 
symlink and possibly config.

The other is to split apache-mod_phpXY into apache-mod_phpXY (which will 
contain libphp.so symlink and apache config + R apache-mod_phpXY-base) and 
apache-mod_phpXY-base (which will contain libphp-X.Y.so without any 
symlink/config). Not sure how triggers/apache reloads will behave in this case 
though.

Second case looks simpler to me.

Ideas?

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


From mike at altlinux.org  Fri Dec  4 11:44:48 2015
From: mike at altlinux.org (Michael Shigorin)
Date: Fri, 4 Dec 2015 13:44:48 +0300
Subject: parallel installation of various php versions (libphp.so)
In-Reply-To: <201512040833.25009.arekm@maven.pl>
References: <201512040833.25009.arekm@maven.pl>
Message-ID: <20151204104448.GH31459@imap.altlinux.org>

On Fri, Dec 04, 2015 at 08:33:24AM +0100, Arkadiusz Mi?kiewicz wrote:
> I need to install different php versions on single server but
> what I need is different libphp.so modules at parallel.

There was some kind of a scheme developed in ALT Linux,
you might want to have a look (developed during 4/5 days,
handles incompatible "minor" branch config files as well).

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


From glen at pld-linux.org  Fri Dec  4 13:30:44 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Fri, 04 Dec 2015 14:30:44 +0200
Subject: parallel installation of various php versions (libphp.so)
In-Reply-To: <201512040833.25009.arekm@maven.pl>
References: <201512040833.25009.arekm@maven.pl>
Message-ID: <56618774.1040407@pld-linux.org>

On 04.12.2015 09:33, Arkadiusz Mi?kiewicz wrote:
> Hi.
>
> I need to install different php versions on single server but what I need is
> different libphp.so modules at parallel.

i would avoid another extra "base" package at any cost.

so my choices would be (in no particular order):
- drop the symlink at all. use mod_phpXY.so in configs
- use alternatives system to route mod_phpXY.so, mod_php.conf
- use triggers to setup mod_php.so only once, so upgrades wouldn't 
overwrite and files wouldn't conflict

-- 
glen



From arekm at maven.pl  Sun Dec  6 09:53:54 2015
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Sun, 6 Dec 2015 09:53:54 +0100
Subject: aclocal: error: cannot open echo 'm4_define([m4_require_silent_probe], [-])' |
Message-ID: <201512060953.54943.arekm@maven.pl>


Has anyone see such error? Trying to figure out what causes it. It happens with
various packages, some work, some do not.

+ aclocal
aclocal: error: cannot open echo 'm4_define([m4_require_silent_probe], [-])' | autom4te --language Autoconf-without-aclocal-m4  - /usr/share/aclocal-1.15/internal/ac-config-macro-dirs.m4 '/usr/share/aclocal/lib-ld.m4' 
'/usr/share/aclocal/lib-link.m4' '/usr/share/aclocal/lib-prefix.m4' '/usr/share/aclocal/libtool.m4' '/usr/share/aclocal/ltargz.m4' '/usr/share/aclocal/ltdl.m4' '/usr/share/aclocal/ltoptions.m4' '/usr/share/aclocal/ltsugar.m4' 
'/usr/share/aclocal/ltversion.m4' '/usr/share/aclocal/lt~obsolete.m4' '/usr/share/aclocal/pkg.m4' '/usr/share/aclocal-1.15/amversion.m4' '/usr/share/aclocal-1.15/auxdir.m4' '/usr/share/aclocal-1.15/cond.m4' 
'/usr/share/aclocal-1.15/depend.m4' '/usr/share/aclocal-1.15/depout.m4' '/usr/share/aclocal-1.15/init.m4' '/usr/share/aclocal-1.15/install-sh.m4' '/usr/share/aclocal-1.15/lead-dot.m4' '/usr/share/aclocal-1.15/make.m4' 
'/usr/share/aclocal-1.15/missing.m4' '/usr/share/aclocal-1.15/options.m4' '/usr/share/aclocal-1.15/prog-cc-c-o.m4' '/usr/share/aclocal-1.15/runlog.m4' '/usr/share/aclocal-1.15/sanity.m4' '/usr/share/aclocal-1.15/silent.m4' 
'/usr/share/aclocal-1.15/strip.m4' '/usr/share/aclocal-1.15/substnot.m4' '/usr/share/aclocal-1.15/tar.m4' 'acinclude.m4' --trace='AC_DEFUN:$f::$n::${::}%' --trace='AC_DEFUN_ONCE:$f::$n::${::}%' --trace='AU_DEFUN:$f::$n::${::}%' --
trace='_AM_AUTOCONF_VERSION:$f::$n::${::}%' --trace='AC_CONFIG_MACRO_DIR_TRACE:$f::$n::${::}%' --trace='AC_CONFIG_MACRO_DIR:$f::$n::${::}%' --trace='_AM_CONFIG_MACRO_DIRS:$f::$n::${::}%' --
trace='AM_PROG_CC_C_O:$f::$n' --trace='_AM_IF_OPTION:$f::$n' --trace='AC_LTDL_SYMBOL_USCORE:$f::$n' --trace='AC_LIBTOOL_SYS_LIB_STRIP:$f::$n' --trace='GINAC_HAVE_RUSAGE:$f::$n' --
trace='GINAC_EXCOMPILER:$f::$n' --trace='AM_MAKE_INCLUDE:$f::$n' --trace='AM_SUBST_NOTMAKE:$f::$n' --trace='AM_PROG_INSTALL_SH:$f::$n' --trace='AC_LIBTOOL_CXX:$f::$n' --trace='AC_ENABLE_SHARED:$f::$n' --
trace='LT_SYS_MODULE_EXT:$f::$n' --trace='_AC_PROG_LIBTOOL:$f::$n' --trace='_LT_COMPILER_BOILERPLATE:$f::$n' --trace='_LT_AC_LANG_RC_CONFIG:$f::$n' --trace='AC_DEPLIBS_CHECK_METHOD:$f::$n' --
trace='GINAC_ERROR:$f::$n' --trace='LTDL_CONVENIENCE:$f::$n' --trace='LTOPTIONS_VERSION:$f::$n' --trace='PKG_CHECK_EXISTS:$f::$n' --trace='AC_LIB_PROG_LD:$f::$n' --trace='AC_LIB_LINKFLAGS_BODY:$f::$n' --
trace='AC_:$f::$n' --trace='AC_PROG_LD_RELOAD_FLAG:$f::$n' --trace='_AM_PROG_TAR:$f::$n' --trace='LT_INIT:$f::$n' --trace='AC_LIBTOOL_SYS_DYNAMIC_LINKER:$f::$n' --trace='LT_AC_PROG_GCJ:$f::$n' --
trace='AC_LIBTOOL_LANG_RC_CONFIG:$f::$n' --trace='AC_LIBTOOL_GCJ:$f::$n' --trace='AC_LIBTOOL_LANG_CXX_CONFIG:$f::$n' --trace='AC_LIBTOOL_PICMODE:$f::$n' --trace='PKG_CHECK_VAR:$f::$n' --
trace='AC_LIBTOOL_POSTDEP_PREDEP:$f::$n' --trace='LT_PROG_GCJ:$f::$n' --trace='LTVERSION_VERSION:$f::$n' --trace='_LT_AC_CHECK_DLFCN:$f::$n' --trace='AC_LIBTOOL_SYS_OLD_ARCHIVE:$f::$n' --
trace='LT_PATH_NM:$f::$n' --trace='AC_LIB_LINKFLAGS:$f::$n' --trace='_AM_SUBST_NOTMAKE:$f::$n' --trace='_LT_DLL_DEF_P:$f::$n' --trace='AC_ENABLE_STATIC:$f::$n' --trace='AC_WITH_LTDL:$f::$n' --
trace='AC_LIBTOOL_CONFIG:$f::$n' --trace='AM_INIT_AUTOMAKE:$f::$n' --trace='_AC_AM_CONFIG_HEADER_HOOK:$f::$n' --trace='_LT_PREPARE_SED_QUOTE_VARS:$f::$n' --trace='_AM_SET_OPTIONS:$f::$n' --
trace='LT_PATH_LD:$f::$n' --trace='AC_PROG_LD:$f::$n' --trace='PKG_INSTALLDIR:$f::$n' --trace='AC_LIBTOOL_LINKER_OPTION:$f::$n' --trace='AC_LIBTOOL_DLOPEN:$f::$n' --trace='AM_PROG_LD:$f::$n' --
trace='_LT_LINKER_BOILERPLATE:$f::$n' --trace='AC_LIBTOOL_F77:$f::$n' --trace='AC_LIBTOOL_SETUP:$f::$n' --trace='AC_LTDL_SYSSEARCHPATH:$f::$n' --trace='AC_LIBTOOL_PROG_LD_SHLIBS:$f::$n' --
trace='LT_SYS_DLOPEN_DEPLIBS:$f::$n' --trace='LT_CONFIG_LTDL_DIR:$f::$n' --trace='AC_LIBTOOL_LANG_GCJ_CONFIG:$f::$n' --trace='GINAC_STD_CXX_HEADERS:$f::$n' --trace='_LT_AC_LANG_CXX:$f::$n' --
trace='AM_OUTPUT_DEPENDENCY_COMMANDS:$f::$n' --trace='_LT_AC_SHELL_INIT:$f::$n' --trace='AC_LIB_APPENDTOVAR:$f::$n' --trace='_LT_PROG_CXX:$f::$n' --trace='AC_LIBTOOL_RC:$f::$n' --trace='AC_PROG_NM:$f::
$n' --trace='_LT_COMPILER_OPTION:$f::$n' --trace='AC_LIBTOOL_COMPILER_OPTION:$f::$n' --trace='AC_LIBTOOL_SYS_MAX_CMD_LEN:$f::$n' --trace='LT_PROG_GO:$f::$n' --trace='AC_LTDL_OBJDIR:$f::$n' --
trace='AC_LIBTOOL_PROG_COMPILER_PIC:$f::$n' --trace='LT_SUPPORTED_TAG:$f::$n' --trace='AC_LIB_PREFIX:$f::$n' --trace='AC_LIB_LINKFLAGS_FROM_LIBS:$f::$n' --trace='AM_PROG_NM:$f::$n' --
trace='AM_ENABLE_SHARED:$f::$n' --trace='AC_LIBLTDL_CONVENIENCE:$f::$n' --trace='_LT_AC_LANG_CXX_CONFIG:$f::$n' --trace='LT_AC_PROG_EGREP:$f::$n' --trace='AC_LIBTOOL_OBJDIR:$f::$n' --
trace='AC_LIBTOOL_SYS_HARD_LINK_LOCKS:$f::$n' --trace='AC_LTDL_SHLIBEXT:$f::$n' --trace='AC_LIB_FROMPACKAGE:$f::$n' --trace='_LT_AC_LANG_GCJ_CONFIG:$f::$n' --trace='AC_LTDL_ENABLE_INSTALL:$f::$n' --
trace='LT_SYS_DLOPEN_SELF:$f::$n' --trace='AC_PROG_LIBTOOL:$f::$n' --trace='PKG_NOARCH_INSTALLDIR:$f::$n' --trace='AM_DEP_TRACK:$f::$n' --trace='_LT_AC_SYS_COMPILER:$f::$n' --trace='_LT_LINKER_OPTION:$f::
$n' --trace='AM_ENABLE_STATIC:$f::$n' --trace='AC_LIB_PREPARE_PREFIX:$f::$n' --trace='_LT_WITH_SYSROOT:$f::$n' --trace='AC_LIBTOOL_PROG_CC_C_O:$f::$n' --trace='AC_LIBTOOL_WIN32_DLL:$f::$n' --
trace='AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE:$f::$n' --trace='_AM_OUTPUT_DEPENDENCY_COMMANDS:$f::$n' --trace='_LT_AC_TAGCONFIG:$f::$n' --trace='LT_FUNC_ARGZ:$f::$n' --trace='LT_SYS_MODULE_PATH:$f::
$n' --trace='_AM_PROG_CC_C_O:$f::$n' --trace='AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH:$f::$n' --trace='AM_SET_CURRENT_AUTOMAKE_VERSION:$f::$n' --trace='_LT_AC_FILE_LTDLL_C:$f::$n' --
trace='_LT_AC_PROG_ECHO_BACKSLASH:$f::$n' --trace='AM_RUN_LOG:$f::$n' --trace='LT_AC_PROG_RC:$f::$n' --trace='AC_LIBTOOL_LANG_F77_CONFIG:$f::$n' --trace='_LT_CC_BASENAME:$f::$n' --trace='LT_LIB_DLLOAD:
$f::$n' --trace='AC_PROG_LD_GNU:$f::$n' --trace='GINAC_WARNING:$f::$n' --trace='AC_LTDL_SHLIBPATH:$f::$n' --trace='AM_DISABLE_STATIC:$f::$n' --trace='_LT_AC_SYS_LIBPATH_AIX:$f::$n' --
trace='LT_FUNC_DLSYM_USCORE:$f::$n' --trace='AM_MISSING_PROG:$f::$n' --trace='AM_AUTOMAKE_VERSION:$f::$n' --trace='_LT_PROG_LTMAIN:$f::$n' --trace='AM_PROG_INSTALL_STRIP:$f::$n' --
trace='AC_ENABLE_FAST_INSTALL:$f::$n' --trace='_AM_DEPENDENCIES:$f::$n' --trace='AC_LIBLTDL_INSTALLABLE:$f::$n' --trace='PKG_PROG_PKG_CONFIG:$f::$n' --trace='AC_CHECK_LIBM:$f::$n' --trace='_LT_LIBOBJ:$f::$n' 
--trace='AM_DISABLE_SHARED:$f::$n' --trace='AC_LIBTOOL_FC:$f::$n' --trace='_AM_SET_OPTION:$f::$n' --trace='LT_LANG:$f::$n' --trace='_LT_AC_PROG_CXXCPP:$f::$n' --trace='AC_LIB_PROG_LD_GNU:$f::$n' --
trace='_AM_MANGLE_OPTION:$f::$n' --trace='AC_PATH_MAGIC:$f::$n' --trace='_PKG_SHORT_ERRORS_SUPPORTED:$f::$n' --trace='LTDL_INSTALLABLE:$f::$n' --trace='AC_LIB_LTDL:$f::$n' --
trace='AC_LIBTOOL_LANG_C_CONFIG:$f::$n' --trace='_LT_AC_LANG_GCJ:$f::$n' --trace='AM_SANITY_CHECK:$f::$n' --trace='AC_DISABLE_FAST_INSTALL:$f::$n' --trace='_LT_PROG_FC:$f::$n' --trace='AM_AUX_DIR_EXPAND:
$f::$n' --trace='AM_SET_DEPDIR:$f::$n' --trace='LTOBSOLETE_VERSION:$f::$n' --trace='AC_LIB_ARG_WITH:$f::$n' --trace='GINAC_READLINE:$f::$n' --trace='GINAC_CHECK_ERRORS:$f::$n' --
trace='_LT_PROG_ECHO_BACKSLASH:$f::$n' --trace='LT_LIB_M:$f::$n' --trace='AC_DISABLE_STATIC:$f::$n' --trace='AM_PROG_LIBTOOL:$f::$n' --trace='_LT_REQUIRED_DARWIN_CHECKS:$f::$n' --
trace='AC_LIB_PREPARE_MULTILIB:$f::$n' --trace='GINAC_TERMCAP:$f::$n' --trace='_LT_AC_LANG_F77:$f::$n' --trace='AC_LIB_RPATH:$f::$n' --trace='_LT_PROG_F77:$f::$n' --trace='AC_DISABLE_SHARED:$f::$n' --
trace='PKG_CHECK_MODULES_STATIC:$f::$n' --trace='LT_SYS_DLSEARCH_PATH:$f::$n' --trace='AC_LTDL_SYS_DLOPEN_DEPLIBS:$f::$n' --trace='AC_LTDL_PREOPEN:$f::$n' --trace='LT_SYS_SYMBOL_USCORE:$f::$n' --
trace='AC_LTDL_DLSYM_USCORE:$f::$n' --trace='LT_WITH_LTDL:$f::$n' --trace='PKG_CHECK_MODULES:$f::$n' --trace='LTDL_INIT:$f::$n' --trace='AC_LIB_WITH_FINAL_PREFIX:$f::$n' --trace='_LT_AC_TRY_DLOPEN_SELF:$f::
$n' --trace='AM_SILENT_RULES:$f::$n' --trace='LT_OUTPUT:$f::$n' --trace='AC_LIBTOOL_DLOPEN_SELF:$f::$n' --trace='_LT_AC_TAGVAR:$f::$n' --trace='LTSUGAR_VERSION:$f::$n' --
trace='AC_LIBTOOL_PROG_COMPILER_NO_RTTI:$f::$n' --trace='LT_CMD_MAX_LEN:$f::$n' --trace='_LT_AC_LOCK:$f::$n' --trace='AC_PATH_TOOL_PREFIX:$f::$n' --trace='_LT_AC_LANG_F77_CONFIG:$f::$n' --
trace='AM_MISSING_HAS_RUN:$f::$n' --trace='AM_CONDITIONAL:$f::$n' --trace='AM_SET_LEADING_DOT:$f::$n' --trace='AC_PROG_EGREP:$f::$n' --trace='_LT_PATH_TOOL_PREFIX:$f::$n' --trace='AC_LIB_HAVE_LINKFLAGS:
$f::$n' --trace='AC_LTDL_DLLIB:$f::$n' --trace='LT_PROG_RC:$f::$n' --trace='LT_AC_PROG_SED:$f::$n' --trace='_LTDL_SETUP:$f::$n' --trace='_LT_AC_LANG_C_CONFIG:$f::$n' configure.ac |:
error: B??dny status wyj?cia z /home/users/arekm/tmp/rpm-tmp.13409 (%build)


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


From baggins at pld-linux.org  Sun Dec  6 14:44:08 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 6 Dec 2015 14:44:08 +0100
Subject: Th 2015 snapshot released
Message-ID: <20151206134408.GA4020@home.lan>

Th 2015 snapshot has been released, see the announcment
on http://www.pld-linux.org/ for details.

I did this without usual prior notice because th-test contains many
major changes that would make any last minute additions very
problematic.

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


From arekm at maven.pl  Sun Dec  6 22:38:03 2015
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Sun, 6 Dec 2015 22:38:03 +0100
Subject: aclocal: error: cannot open echo
 'm4_define([m4_require_silent_probe], [-])' |
In-Reply-To: <201512060953.54943.arekm@maven.pl>
References: <201512060953.54943.arekm@maven.pl>
Message-ID: <201512062238.04541.arekm@maven.pl>

On Sunday 06 of December 2015, Arkadiusz Mi?kiewicz wrote:
> Has anyone see such error? Trying to figure out what causes it. It happens
> with various packages, some work, some do not.

Reproducer

#!/usr/bin/perl

BEGIN {
        push ( @INC,"/usr/share/automake");
}

use strict;

use Automake::XFile;

my $configure_ac;
my $traces = "echo 'zupa'";
my $tracefh = new Automake::XFile ("$traces");


$ LC_ALL=C perl a1.pl
a1.pl: error: cannot open echo 'zupa': No such file or directory

so no idea how it is supposed to work in aclocal which does:

  my $early_m4_code .= "m4_define([m4_require_silent_probe], [-])";

  my $traces = ($ENV{AUTOM4TE} || 'autom4te');
  $traces .= " --language Autoconf-without-aclocal-m4 ";
  $traces = "echo '$early_m4_code' | $traces - ";
  ...
  verb "running $traces $configure_ac";

  my $tracefh = new Automake::XFile ("$traces $configure_ac |");


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


From glen at pld-linux.org  Mon Dec  7 09:31:57 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Mon, 07 Dec 2015 10:31:57 +0200
Subject: mod_python failure
Message-ID: <566543FD.10407@pld-linux.org>

any ideas what could cause this?

Fri Dec  4 14:47:15 2015 openssl-1.0.2e-1.x86_64
Mon Dec  7 10:18:44 2015 apache-base-2.4.17-3.x86_64
Mon Dec  7 10:19:28 2015 apache-mod_python-3.5.0-16.x86_64

root at trac /etc/cron.d# service httpd restart
Checking Apache 2.4 Web Server 
configuration...........................................................................................................................[ 
DONE ]
Stopping Apache 2.4 Web Server 
service.................................................................................................................................[ 
FAIL ]
Starting Apache 2.4 Web Server 
service.................................................................................................................................[ 
BUSY ]
[Mon Dec 07 10:28:10.367456 2015] [suexec:notice] [pid 32119] AH01232: 
suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[ DONE ]
[Mon Dec 07 10:28:10.404405 2015] [:notice] [pid 32120] mod_python: 
Creating 8 session mutexes based on 150 max processes and 0 max threads.
[Mon Dec 07 10:28:10.404482 2015] [:notice] [pid 32120] mod_python: 
using mutex_directory /tmp
[Mon Dec 07 10:28:10.404522 2015] [:error] [pid 32120] (28)No space left 
on device: mod_python: Failed to create global mutex 0 of 8 
(/tmp/mpmtx321200).
[Mon Dec 07 10:28:10.404565 2015] [:emerg] [pid 32120] AH00020: 
Configuration Failed, exiting

10:28:10 [load: 1.09 27.25% nproc: 4]
root at trac /etc/cron.d# df /tmp
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/root      xfs   2.0G  674M  1.4G  34% /

10:28:12 [load: 1.24 31.00% nproc: 4]
root at trac /etc/cron.d# ls -ld /tmp
drwxrwxrwt 6 root root 85  7. dets  10:19 /tmp/

10:28:13 [load: 1.24 31.00% nproc: 4]
root at trac /etc/cron.d# l /tmp/mpmtx321200
ls: cannot access /tmp/mpmtx321200: No such file or directory


-- 
glen



From glen at pld-linux.org  Mon Dec  7 09:35:23 2015
From: glen at pld-linux.org (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Mon, 07 Dec 2015 10:35:23 +0200
Subject: mod_python failure
In-Reply-To: <566543FD.10407@pld-linux.org>
References: <566543FD.10407@pld-linux.org>
Message-ID: <566544CB.8000205@pld-linux.org>

nvm,

http://modpython.org/pipermail/mod_python/2005-April/017857.html

found that i had too many ipcs left in the system. nuked them


On 07.12.2015 10:31, Elan Ruusam?e wrote:
> any ideas what could cause this?
>
> Fri Dec  4 14:47:15 2015 openssl-1.0.2e-1.x86_64
> Mon Dec  7 10:18:44 2015 apache-base-2.4.17-3.x86_64
> Mon Dec  7 10:19:28 2015 apache-mod_python-3.5.0-16.x86_64
>
> root at trac /etc/cron.d# service httpd restart
> Checking Apache 2.4 Web Server 
> configuration...........................................................................................................................[ 
> DONE ]
> Stopping Apache 2.4 Web Server 
> service.................................................................................................................................[ 
> FAIL ]
> Starting Apache 2.4 Web Server 
> service.................................................................................................................................[ 
> BUSY ]
> [Mon Dec 07 10:28:10.367456 2015] [suexec:notice] [pid 32119] AH01232: 
> suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
> [ DONE ]
> [Mon Dec 07 10:28:10.404405 2015] [:notice] [pid 32120] mod_python: 
> Creating 8 session mutexes based on 150 max processes and 0 max threads.
> [Mon Dec 07 10:28:10.404482 2015] [:notice] [pid 32120] mod_python: 
> using mutex_directory /tmp
> [Mon Dec 07 10:28:10.404522 2015] [:error] [pid 32120] (28)No space 
> left on device: mod_python: Failed to create global mutex 0 of 8 
> (/tmp/mpmtx321200).
> [Mon Dec 07 10:28:10.404565 2015] [:emerg] [pid 32120] AH00020: 
> Configuration Failed, exiting
>
> 10:28:10 [load: 1.09 27.25% nproc: 4]
> root at trac /etc/cron.d# df /tmp
> Filesystem     Type  Size  Used Avail Use% Mounted on
> /dev/root      xfs   2.0G  674M  1.4G  34% /
>
> 10:28:12 [load: 1.24 31.00% nproc: 4]
> root at trac /etc/cron.d# ls -ld /tmp
> drwxrwxrwt 6 root root 85  7. dets  10:19 /tmp/
>
> 10:28:13 [load: 1.24 31.00% nproc: 4]
> root at trac /etc/cron.d# l /tmp/mpmtx321200
> ls: cannot access /tmp/mpmtx321200: No such file or directory
>
>


-- 
glen



From arekm at maven.pl  Tue Dec  8 18:54:58 2015
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Tue, 8 Dec 2015 18:54:58 +0100
Subject: aclocal: error: cannot open echo
 'm4_define([m4_require_silent_probe], [-])' |
In-Reply-To: <201512062238.04541.arekm@maven.pl>
References: <201512060953.54943.arekm@maven.pl>
 <201512062238.04541.arekm@maven.pl>
Message-ID: <201512081854.58381.arekm@maven.pl>

On Sunday 06 of December 2015, Arkadiusz Mi?kiewicz wrote:
> On Sunday 06 of December 2015, Arkadiusz Mi?kiewicz wrote:
> > Has anyone see such error? Trying to figure out what causes it. It
> > happens with various packages, some work, some do not.
> 
> Reproducer
> 
> #!/usr/bin/perl
> 
> BEGIN {
>         push ( @INC,"/usr/share/automake");
> }
> 
> use strict;
> 
> use Automake::XFile;
> 
> my $configure_ac;
> my $traces = "echo 'zupa'";

Tt should be "echo 'zupa' | "


Anyway it had to be some interesting corruption. perl-base reinstall fixed it.

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


From arekm at maven.pl  Wed Dec  9 18:55:20 2015
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Wed, 9 Dec 2015 18:55:20 +0100
Subject: aclocal: error: cannot open echo
 'm4_define([m4_require_silent_probe], [-])' |
In-Reply-To: <201512081854.58381.arekm@maven.pl>
References: <201512060953.54943.arekm@maven.pl>
 <201512062238.04541.arekm@maven.pl> <201512081854.58381.arekm@maven.pl>
Message-ID: <201512091855.20444.arekm@maven.pl>

On Tuesday 08 of December 2015, Arkadiusz Mi?kiewicz wrote:
> On Sunday 06 of December 2015, Arkadiusz Mi?kiewicz wrote:
> > On Sunday 06 of December 2015, Arkadiusz Mi?kiewicz wrote:
> > > Has anyone see such error? Trying to figure out what causes it. It
> > > happens with various packages, some work, some do not.
> > 
> > Reproducer
> > 
> > #!/usr/bin/perl
> > 
> > BEGIN {
> > 
> >         push ( @INC,"/usr/share/automake");
> > 
> > }
> > 
> > use strict;
> > 
> > use Automake::XFile;
> > 
> > my $configure_ac;
> > my $traces = "echo 'zupa'";
> 
> Tt should be "echo 'zupa' | "
> 
> 
> Anyway it had to be some interesting corruption. perl-base reinstall fixed
> it.

Guilty part found - prelink 20130503 cron job was doing that.

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


From gotar at polanet.pl  Thu Dec 10 07:18:58 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Thu, 10 Dec 2015 07:18:58 +0100
Subject: Skrypty startowe mldonkey
In-Reply-To: <6543411.naJ65lm1OS@dlaptok>
References: <6543411.naJ65lm1OS@dlaptok>
Message-ID: <20151210061857.GA22398@polanet.pl>

On Tue, Dec 08, 2015 at 10:58:37 +0100, ?ukasz Ma?ko wrote:

> daemon --fork --user $USER "cd ~$USER && exec $MLDONKEY_PATH > ${LOG:-/dev/null} 2>&1"
> 
> No i wyk?ada si? to tak:
> 
> $ sudo service mldonkey start
> Uruchamianie us?ugi mldonkey..................................... [ PROBLEMY ]
> setsid: nie uda?o si? uruchomi? cd: Nie ma takiego pliku ani katalogu
> MLDonkey could not be started! Check logfile: /var/log/mldonkey.log
> 
> Poprawi?em na:
> daemon --fork --user $USER --chdir ~$USER "exec $MLDONKEY_PATH > ${LOG:-/dev/null} 2>&1"
> 
> ale to dalej jest ?le:
> $ sudo service mldonkey start
> Uruchamianie us?ugi mldonkey..................................... [  ZAJ?TY  
> ]/etc/rc.d/init.d/mldonkey: cd: /~mldonkey: No such file or directory
>                                                                   [ PROBLEMY ]
> setsid: nie uda?o si? uruchomi? exec: Nie ma takiego pliku ani katalogu
> MLDonkey could not be started! Check logfile: /var/log/mldonkey.log

Have you tested your changes from 2015-10-08 glen? Fix this or I'm going
to revert everything if that happens to be the reason (and it looks like
it is to me). We ought to keep rc-scripts in a working state and do not
'improve' this obsolete project!

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


From glen at pld-linux.org  Thu Dec 10 11:27:42 2015
From: glen at pld-linux.org (=?ISO-8859-2?Q?Elan_Ruusam=E4e?=)
Date: Thu, 10 Dec 2015 12:27:42 +0200
Subject: Skrypty startowe mldonkey
In-Reply-To: <20151210061857.GA22398@polanet.pl>
References: <6543411.naJ65lm1OS@dlaptok> <20151210061857.GA22398@polanet.pl>
Message-ID: <5669539E.8020704@pld-linux.org>

On 10.12.2015 08:18, Tomasz Pala wrote:
> Have you tested your changes from 2015-10-08 glen? Fix this or I'm going
> to revert everything if that happens to be the reason (and it looks like
> it is to me). We ought to keep rc-scripts in a working state and do not
> 'improve' this obsolete project!

yes, works for me. the package was in testing for several months, nobody 
reported anything.

and to fix something, you first need to report the bug! so it's 
illogical to start threating and attacking someone personally in first 
bugreport!

-- 
glen



From glen at pld-linux.org  Thu Dec 10 11:43:21 2015
From: glen at pld-linux.org (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Thu, 10 Dec 2015 12:43:21 +0200
Subject: Skrypty startowe mldonkey
In-Reply-To: <5669539E.8020704@pld-linux.org>
References: <6543411.naJ65lm1OS@dlaptok> <20151210061857.GA22398@polanet.pl>
 <5669539E.8020704@pld-linux.org>
Message-ID: <56695749.30103@pld-linux.org>

On 10.12.2015 12:27, Elan Ruusam?e wrote:
>
> yes, works for me. the package was in testing for several months, 
> nobody reported anything. 

and i do recall to you, pld is volunteer project. we all work on the 
project on free time.

 > Fix this or I'm going to revert everything

and just reverting someone's work, is like pissing in someones face and 
throwing shit also over for his efforts what he did initially trying to 
improve things.

instead you should try to collaborate, try to fix things yourself first.

 > We ought to keep rc-scripts in a working state and do not 'improve' 
this obsolete project!

and there is no policy what goes in, what goes out, how things are 
tested, all goes by each developer's best judgement.
rc-scripts is to me no more obsolete than the whole pld project itself. 
systemd is overkill and not usable with vservers. and no other init 
system is globally supported in pld.

-- 
glen



From ed at yen.ipipan.waw.pl  Thu Dec 10 12:06:03 2015
From: ed at yen.ipipan.waw.pl (=?utf-8?B?xYF1a2FzeiBNYcWba28=?=)
Date: Thu, 10 Dec 2015 12:06:03 +0100
Subject: Skrypty startowe mldonkey
In-Reply-To: <56695749.30103@pld-linux.org>
References: <6543411.naJ65lm1OS@dlaptok> <5669539E.8020704@pld-linux.org>
 <56695749.30103@pld-linux.org>
Message-ID: <1536165.Iyu6Sma7b0@dlaptok>

Dnia czwartek, 10 grudnia 2015 12:43:21 Elan Ruusam?e pisze:
[...]
> instead you should try to collaborate, try to fix things yourself first.

Sometimes it is hard to guess, why a certain modification was intoduced. 
Anyway, it is not the point here. And, on the othe side, the developer which 
introduces changes, may not know all the cases, where certain functions are 
used (like in this case). Therefore, we must discuss it.

Ii have noticed, that after recent modifications i rc-scripts, some services 
do not start any more. My example was mldonkey, in which the original line 
starting the service was:

daemon --fork --user $USER "cd ~$USER && exec $MLDONKEY_PATH > 
${LOG:-/dev/null} 2>&1"

The "cd..." part should be easy to fix since now we have the --chdir parameter 
to the daemon call. "Should be" but is not, for the daemon function does not 
properly expand exprssions like ~mldonkey (by default, it is 
/home/services/mldonkey). But - OK, I can put the whole path by hand.

The most important problem here is the "exec" part in the command. And it 
cannot be fixed just like this, for exec is a shell command. Unfortunately, 
mlnetd has no switch, which makes it fork into background (it was removed for 
some reasons). And therefore the script hangs here. It's probably the same in 
other cases reported today (svscan from daemontools and git-daemon from git-
core-daemon-standalone).

> and there is no policy what goes in, what goes out, how things are
> tested, all goes by each developer's best judgement.
> rc-scripts is to me no more obsolete than the whole pld project itself.
> systemd is overkill and not usable with vservers. and no other init
> system is globally supported in pld.

I agree, that in some cases SysVInit is needed. I need it. Therefore I'm 
trying to find out, why some things stopped working. But I don't want to start 
fixing things if I don't understand the reasons, for which some changes were 
made (for "fixing" may turn into "spoiling").
-- 
?ukasz Ma?ko                                                            _o)
Lukasz.Masko(at)ipipan.waw.pl                                           /\\
Registered Linux User #61028                                           _\_V
Ubuntu: staroafryka?skie s?owo oznaczaj?ce "Nie umiem zainstalowa? Debiana"



From glen at pld-linux.org  Thu Dec 10 12:24:08 2015
From: glen at pld-linux.org (=?ISO-8859-2?Q?Elan_Ruusam=E4e?=)
Date: Thu, 10 Dec 2015 13:24:08 +0200
Subject: Skrypty startowe mldonkey
In-Reply-To: <20151210061857.GA22398@polanet.pl>
References: <6543411.naJ65lm1OS@dlaptok> <20151210061857.GA22398@polanet.pl>
Message-ID: <566960D8.2040804@pld-linux.org>

On 10.12.2015 08:18, Tomasz Pala wrote:
> >Poprawi?em na:
> >daemon --fork --user $USER --chdir ~$USER "exec $MLDONKEY_PATH > ${LOG:-/dev/null} 2>&1"

committed a fix that should solve it

please test as i'm not allowed to run this kind of software.
it will take time until i get to network where i can run it.

-- 
glen



From ed at yen.ipipan.waw.pl  Thu Dec 10 13:00:31 2015
From: ed at yen.ipipan.waw.pl (=?utf-8?B?xYF1a2FzeiBNYcWba28=?=)
Date: Thu, 10 Dec 2015 13:00:31 +0100
Subject: Skrypty startowe mldonkey
In-Reply-To: <566960D8.2040804@pld-linux.org>
References: <6543411.naJ65lm1OS@dlaptok> <20151210061857.GA22398@polanet.pl>
 <566960D8.2040804@pld-linux.org>
Message-ID: <1924555.3H7dPjeCXL@dlaptok>

Dnia czwartek, 10 grudnia 2015 13:24:08 Elan Ruusam?e pisze:
> On 10.12.2015 08:18, Tomasz Pala wrote:
> > >Poprawi?em na:
> > >daemon --fork --user $USER --chdir ~$USER "exec $MLDONKEY_PATH >
> > >${LOG:-/dev/null} 2>&1"
> committed a fix that should solve it
> 
> please test as i'm not allowed to run this kind of software.
> it will take time until i get to network where i can run it.

Thanks. I'll check it as soon as I have it built.
-- 
?ukasz Ma?ko                                                            _o)
Lukasz.Masko(at)ipipan.waw.pl                                           /\\
Registered Linux User #61028                                           _\_V
Ubuntu: staroafryka?skie s?owo oznaczaj?ce "Nie umiem zainstalowa? Debiana"



From ed at yen.ipipan.waw.pl  Thu Dec 10 13:04:43 2015
From: ed at yen.ipipan.waw.pl (=?utf-8?B?xYF1a2FzeiBNYcWba28=?=)
Date: Thu, 10 Dec 2015 13:04:43 +0100
Subject: Skrypty startowe mldonkey
In-Reply-To: <1924555.3H7dPjeCXL@dlaptok>
References: <6543411.naJ65lm1OS@dlaptok> <566960D8.2040804@pld-linux.org>
 <1924555.3H7dPjeCXL@dlaptok>
Message-ID: <5040748.ebTuGvgYsh@dlaptok>

Dnia czwartek, 10 grudnia 2015 13:00:31 ?ukasz Ma?ko pisze:
[...]
> > please test as i'm not allowed to run this kind of software.
> > it will take time until i get to network where i can run it.
> 
> Thanks. I'll check it as soon as I have it built.
Is this m4, rc-script or something else problem?:

$ ../builder -bb rc-scripts.spec 
builder: SMP make flags are set to -j8
56ed992ce627492bb1550eacc0716cca081cb7b2
Already on 'master'
Your branch is up-to-date with 'origin/master'.
Already up-to-date.

No conditional flags passed

from available:
--with   :
--without:       static

Available branches: AC-branch BUSYBOX RA-branch dev master rpm3 upstart_native
rc-scripts-0.4.15.tar.gz having proper md5sum already exists
Budowanie dla platform: i686-linux
Wykonywanie(%prep): /bin/sh -e /tmp/rpm-tmp.68366
+ umask 022
+ cd /home/users/ed/rpm/BUILD
+ cd /home/users/ed/rpm/BUILD
+ rm -rf rc-scripts-0.4.15
+ /usr/bin/gzip -dc /home/users/ed/rpm/packages/rc-scripts/rc-
scripts-0.4.15.tar.gz
+ /bin/tar -xf -
+ STATUS=0 
+ '[' 0 -ne 0 ']'
+ cd rc-scripts-0.4.15
+ /bin/id -u
+ '[' 500 '=' 0 ']'
+ /bin/id -u
+ '[' 500 '=' 0 ']'
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ echo 'Patch #0 (rc-scripts-git.patch):'
Patch #0 (rc-scripts-git.patch):
+ '[' -f /home/users/ed/rpm/packages/rc-scripts/rc-scripts-git.patch ']'
+ /bin/cat /home/users/ed/rpm/packages/rc-scripts/rc-scripts-git.patch
+ /usr/bin/patch -s -p1
+ sed -i -e 's#^GLIB_LIBS=.*#GLIB_LIBS="/usr/lib/libglib-2.0.a -lrt -
lpthread"#' configure.ac
+ exit 0
Wykonywanie(%build): /bin/sh -e /tmp/rpm-tmp.68366
TMP=/tmp
HOME=/home/users/ed
PATH=/bin:/usr/bin:/usr/sbin:/sbin:/usr/X11R6/bin
TMPDIR=/tmp
+ umask 022
+ cd /home/users/ed/rpm/BUILD
+ cd rc-scripts-0.4.15
+ aclocal
aclocal: error: cannot close echo 'm4_define([m4_require_silent_probe], [-])' 
| autom4te --language Autoconf-without-aclocal-m4  - 
/usr/share/aclocal-1.15/internal/ac-config-macro-dirs.m4 
'/usr/share/aclocal-1.15/amversion.m4' '/usr/share/aclocal-1.15/auxdir.m4' 
'/usr/share/aclocal-1.15/cond.m4' '/usr/share/aclocal-1.15/depend.m4' 
'/usr/share/aclocal-1.15/depout.m4' '/usr/share/aclocal-1.15/init.m4' 
'/usr/share/aclocal-1.15/install-sh.m4' '/usr/share/aclocal-1.15/lead-dot.m4' 
'/usr/share/aclocal-1.15/make.m4' '/usr/share/aclocal-1.15/missing.m4' 
'/usr/share/aclocal-1.15/options.m4' '/usr/share/aclocal-1.15/prog-cc-c-o.m4' 
'/usr/share/aclocal-1.15/runlog.m4' '/usr/share/aclocal-1.15/sanity.m4' 
'/usr/share/aclocal-1.15/silent.m4' '/usr/share/aclocal-1.15/strip.m4' 
'/usr/share/aclocal-1.15/substnot.m4' '/usr/share/aclocal-1.15/tar.m4' 
'acinclude.m4' --trace='AC_DEFUN:$f::$n::${::}%' --trace='AC_DEFUN_ONCE:$f::
$n::${::}%' --trace='AU_DEFUN:$f::$n::${::}%' --trace='_AM_AUTOCONF_VERSION:
$f::$n::${::}%' --trace='AC_CONFIG_MACRO_DIR_TRACE:$f::$n::${::}%' --
trace='AC_CONFIG_MACRO_DIR:$f::$n::${::}%' --trace='_AM_CONFIG_MACRO_DIRS:$f::
$n::${::}%' --trace='AM_SANITY_CHECK:$f::$n' --trace='AM_INIT_AUTOMAKE:$f::$n' 
--trace='AM_AUX_DIR_EXPAND:$f::$n' --trace='AM_MAKE_INCLUDE:$f::$n' --
trace='AM_SILENT_RULES:$f::$n' --trace='AM_PROG_INSTALL_STRIP:$f::$n' --
trace='DPKG_C_GCC_ATTRIBUTE:$f::$n' --trace='AM_MISSING_HAS_RUN:$f::$n' --
trace='AM_MISSING_PROG:$f::$n' --trace='_AM_IF_OPTION:$f::$n' --
trace='AM_OUTPUT_DEPENDENCY_COMMANDS:$f::$n' --trace='DPKG_CHECK_DEFINE:$f::
$n' --trace='_AM_SET_OPTIONS:$f::$n' --trace='_AM_PROG_CC_C_O:$f::$n' --
trace='AM_PROG_CC_C_O:$f::$n' --trace='AM_SUBST_NOTMAKE:$f::$n' --
trace='AM_AUTOMAKE_VERSION:$f::$n' --trace='_AM_MANGLE_OPTION:$f::$n' --
trace='DPKG_CACHED_TRY_COMPILE:$f::$n' --trace='_AM_PROG_TAR:$f::$n' --
trace='_AM_SUBST_NOTMAKE:$f::$n' --trace='_AM_OUTPUT_DEPENDENCY_COMMANDS:$f::
$n' --trace='AM_DEP_TRACK:$f::$n' --trace='AM_SET_CURRENT_AUTOMAKE_VERSION:
$f::$n' --trace='AM_SET_LEADING_DOT:$f::$n' --trace='AM_RUN_LOG:$f::$n' --
trace='_AM_DEPENDENCIES:$f::$n' --trace='_AM_SET_OPTION:$f::$n' --
trace='_AC_AM_CONFIG_HEADER_HOOK:$f::$n' --trace='AM_PROG_INSTALL_SH:$f::$n' 
--trace='AM_CONDITIONAL:$f::$n' --trace='DPKG_C_GCC_TRY_WARNS:$f::$n' --
trace='AM_SET_DEPDIR:$f::$n' configure.ac |: No child processes
error: B??dny status wyj?cia z /tmp/rpm-tmp.68366 (%build)


B??dy budowania RPM-a:
    B??dny status wyj?cia z /tmp/rpm-tmp.68366 (%build)
Command exited with non-zero status 1
real 2.67
user 2.51
sys 0.05
Error: package build failed. (no more info)

-- 
?ukasz Ma?ko                                                            _o)
Lukasz.Masko(at)ipipan.waw.pl                                           /\\
Registered Linux User #61028                                           _\_V
Ubuntu: staroafryka?skie s?owo oznaczaj?ce "Nie umiem zainstalowa? Debiana"



From arekm at maven.pl  Thu Dec 10 13:33:40 2015
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Thu, 10 Dec 2015 13:33:40 +0100
Subject: Skrypty startowe mldonkey
In-Reply-To: <5040748.ebTuGvgYsh@dlaptok>
References: <6543411.naJ65lm1OS@dlaptok> <1924555.3H7dPjeCXL@dlaptok>
 <5040748.ebTuGvgYsh@dlaptok>
Message-ID: <201512101333.40524.arekm@maven.pl>

On Thursday 10 of December 2015, ?ukasz Ma?ko wrote:
> Dnia czwartek, 10 grudnia 2015 13:00:31 ?ukasz Ma?ko pisze:
> [...]
> 
> > > please test as i'm not allowed to run this kind of software.
> > > it will take time until i get to network where i can run it.
> > 
> > Thanks. I'll check it as soon as I have it built.
> 
> Is this m4, rc-script or something else problem?:

rpm -e prelink
then reinstall perl-base

prelink breaks perl

> 'acinclude.m4' --trace='AC_DEFUN:$f::$n::${::}%'
> --trace='AC_DEFUN_ONCE:$f:: $n::${::}%' --trace='AU_DEFUN:$f::$n::${::}%'
> --trace='_AM_AUTOCONF_VERSION: $f::$n::${::}%'
> --trace='AC_CONFIG_MACRO_DIR_TRACE:$f::$n::${::}%' --
> trace='AC_CONFIG_MACRO_DIR:$f::$n::${::}%'
> --trace='_AM_CONFIG_MACRO_DIRS:$f:: $n::${::}%'
> --trace='AM_SANITY_CHECK:$f::$n' --trace='AM_INIT_AUTOMAKE:$f::$n'
> --trace='AM_AUX_DIR_EXPAND:$f::$n' --trace='AM_MAKE_INCLUDE:$f::$n' --
> trace='AM_SILENT_RULES:$f::$n' --trace='AM_PROG_INSTALL_STRIP:$f::$n' --
> trace='DPKG_C_GCC_ATTRIBUTE:$f::$n' --trace='AM_MISSING_HAS_RUN:$f::$n' --
> trace='AM_MISSING_PROG:$f::$n' --trace='_AM_IF_OPTION:$f::$n' --
> trace='AM_OUTPUT_DEPENDENCY_COMMANDS:$f::$n'
> --trace='DPKG_CHECK_DEFINE:$f:: $n' --trace='_AM_SET_OPTIONS:$f::$n'
> --trace='_AM_PROG_CC_C_O:$f::$n' -- trace='AM_PROG_CC_C_O:$f::$n'
> --trace='AM_SUBST_NOTMAKE:$f::$n' -- trace='AM_AUTOMAKE_VERSION:$f::$n'
> --trace='_AM_MANGLE_OPTION:$f::$n' --
> trace='DPKG_CACHED_TRY_COMPILE:$f::$n' --trace='_AM_PROG_TAR:$f::$n' --
> trace='_AM_SUBST_NOTMAKE:$f::$n'
> --trace='_AM_OUTPUT_DEPENDENCY_COMMANDS:$f:: $n'
> --trace='AM_DEP_TRACK:$f::$n' --trace='AM_SET_CURRENT_AUTOMAKE_VERSION:
> $f::$n' --trace='AM_SET_LEADING_DOT:$f::$n' --trace='AM_RUN_LOG:$f::$n' --
> trace='_AM_DEPENDENCIES:$f::$n' --trace='_AM_SET_OPTION:$f::$n' --
> trace='_AC_AM_CONFIG_HEADER_HOOK:$f::$n'
> --trace='AM_PROG_INSTALL_SH:$f::$n' --trace='AM_CONDITIONAL:$f::$n'
> --trace='DPKG_C_GCC_TRY_WARNS:$f::$n' -- trace='AM_SET_DEPDIR:$f::$n'
> configure.ac |: No child processes
> error: B??dny status wyj?cia z /tmp/rpm-tmp.68366 (%build)


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


From ed at yen.ipipan.waw.pl  Thu Dec 10 13:55:02 2015
From: ed at yen.ipipan.waw.pl (=?utf-8?B?xYF1a2FzeiBNYcWba28=?=)
Date: Thu, 10 Dec 2015 13:55:02 +0100
Subject: Skrypty startowe mldonkey
In-Reply-To: <201512101333.40524.arekm@maven.pl>
References: <6543411.naJ65lm1OS@dlaptok> <5040748.ebTuGvgYsh@dlaptok>
 <201512101333.40524.arekm@maven.pl>
Message-ID: <22310776.8MRbPb5FWq@dlaptok>

Dnia czwartek, 10 grudnia 2015 13:33:40 Arkadiusz Mi?kiewicz pisze:
> On Thursday 10 of December 2015, ?ukasz Ma?ko wrote:
> > Dnia czwartek, 10 grudnia 2015 13:00:31 ?ukasz Ma?ko pisze:
> > [...]
> > 
> > > > please test as i'm not allowed to run this kind of software.
> > > > it will take time until i get to network where i can run it.
> > > 
> > > Thanks. I'll check it as soon as I have it built.
> > 
> > Is this m4, rc-script or something else problem?:
> rpm -e prelink
> then reinstall perl-base
> 
> prelink breaks perl

Thanks! This also fixec my problms with teeboth in buiding scripts.
-- 
?ukasz Ma?ko                                                            _o)
Lukasz.Masko(at)ipipan.waw.pl                                           /\\
Registered Linux User #61028                                           _\_V
Ubuntu: staroafryka?skie s?owo oznaczaj?ce "Nie umiem zainstalowa? Debiana"



From gotar at polanet.pl  Thu Dec 10 19:24:23 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Thu, 10 Dec 2015 19:24:23 +0100
Subject: Skrypty startowe mldonkey
In-Reply-To: <5669539E.8020704@pld-linux.org>
References: <6543411.naJ65lm1OS@dlaptok> <20151210061857.GA22398@polanet.pl>
 <5669539E.8020704@pld-linux.org>
Message-ID: <20151210182423.GA17742@polanet.pl>

On Thu, Dec 10, 2015 at 12:27:42 +0200, Elan Ruusam?e wrote:

>> Have you tested your changes from 2015-10-08 glen? Fix this or I'm going
>> to revert everything if that happens to be the reason (and it looks like
>> it is to me). We ought to keep rc-scripts in a working state and do not
>> 'improve' this obsolete project!
> 
> yes, works for me.

It's not enough. And your commit messages are way too less verbose.

> the package was in testing for several months, nobody 
> reported anything.

Several<=two?

> and to fix something, you first need to report the bug! so it's 
> illogical to start threating and attacking someone personally in first 
> bugreport!

It is when the faulty package should be in frozen state. And this is the
case. In simple words: do not touch this, except for fixing obvious bugs.

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


From gotar at polanet.pl  Thu Dec 10 19:34:03 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Thu, 10 Dec 2015 19:34:03 +0100
Subject: Skrypty startowe mldonkey
In-Reply-To: <56695749.30103@pld-linux.org>
References: <6543411.naJ65lm1OS@dlaptok> <20151210061857.GA22398@polanet.pl>
 <5669539E.8020704@pld-linux.org> <56695749.30103@pld-linux.org>
Message-ID: <20151210183402.GA21070@polanet.pl>

On Thu, Dec 10, 2015 at 12:43:21 +0200, Elan Ruusam?e wrote:

>> yes, works for me. the package was in testing for several months, 
>> nobody reported anything. 
> 
> and i do recall to you, pld is volunteer project. we all work on the 
> project on free time.

So please refrain from working on things that don't need to be worked on.

>  > Fix this or I'm going to revert everything
> 
> and just reverting someone's work, is like pissing in someones face and 
> throwing shit also over for his efforts what he did initially trying to 
> improve things.

I see no reasoning in commit messages.

"daemon: makepid implies fork"

why?!

"daemon: rewrite $@ to modify command"
"this simplifies and avoids shell syntax. but until initlog, sigh"

I see you've mangled the /bin/sh invocations - I'm not conviced it has
the same effect as it was before. Such change should not happen during
feature-freeze just because of some "simplifiness".

> instead you should try to collaborate, try to fix things yourself first.

I expect stable packages to remain stable. Nothing less, nothing more.

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


From gotar at polanet.pl  Thu Dec 10 19:37:45 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Thu, 10 Dec 2015 19:37:45 +0100
Subject: Skrypty startowe mldonkey
In-Reply-To: <1536165.Iyu6Sma7b0@dlaptok>
References: <6543411.naJ65lm1OS@dlaptok> <5669539E.8020704@pld-linux.org>
 <56695749.30103@pld-linux.org> <1536165.Iyu6Sma7b0@dlaptok>
Message-ID: <20151210183745.GB21070@polanet.pl>

On Thu, Dec 10, 2015 at 12:06:03 +0100, ?ukasz Ma?ko wrote:

>> rc-scripts is to me no more obsolete than the whole pld project itself.
>> systemd is overkill and not usable with vservers. and no other init
>> system is globally supported in pld.
> 
> I agree, that in some cases SysVInit is needed. I need it. Therefore I'm 

That is EXACTLY why there should be no pointless/cosmetic changes.

> trying to find out, why some things stopped working. But I don't want to start 
> fixing things if I don't understand the reasons, for which some changes were 
> made (for "fixing" may turn into "spoiling").

If ain't broken, don't fix it - there were no real reasons.

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


From gotar at polanet.pl  Thu Dec 10 19:45:58 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Thu, 10 Dec 2015 19:45:58 +0100
Subject: Skrypty startowe mldonkey
In-Reply-To: <566960D8.2040804@pld-linux.org>
References: <6543411.naJ65lm1OS@dlaptok> <20151210061857.GA22398@polanet.pl>
 <566960D8.2040804@pld-linux.org>
Message-ID: <20151210184558.GC21070@polanet.pl>

On Thu, Dec 10, 2015 at 13:24:08 +0200, Elan Ruusam?e wrote:

>> >Poprawi?em na:
>> >daemon --fork --user $USER --chdir ~$USER "exec $MLDONKEY_PATH > ${LOG:-/dev/null} 2>&1"
> 
> committed a fix that should solve it

If it doesn't fix out-of-distro init scripts, it doesn't solve the
issue.
Keep the compatibility, until there's an important reason for not doing so!

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


From glen at pld-linux.org  Thu Dec 10 21:37:57 2015
From: glen at pld-linux.org (=?ISO-8859-2?Q?Elan_Ruusam=E4e?=)
Date: Thu, 10 Dec 2015 22:37:57 +0200
Subject: Skrypty startowe mldonkey
In-Reply-To: <20151210061857.GA22398@polanet.pl>
References: <6543411.naJ65lm1OS@dlaptok> <20151210061857.GA22398@polanet.pl>
Message-ID: <5669E2A5.9090202@pld-linux.org>

applied patch from rc-scripts mailing list dated 2015-11-26, thus three 
weeks old!

if you're so smart and so caring, why didn't you apply it yourself. 
don't put pressure on me alone!
and if you had something to complain, why you didn't complain when the 
commits were made?! package was sent builders week later.

and show me *your* super awesome commits.

i've had enough of this, if you have bug to report, 
http://bugs.pld-linux.org is the address where to submit them.


From gotar at polanet.pl  Fri Dec 11 09:32:00 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Fri, 11 Dec 2015 09:32:00 +0100
Subject: Skrypty startowe mldonkey
In-Reply-To: <5669E2A5.9090202@pld-linux.org>
References: <6543411.naJ65lm1OS@dlaptok> <20151210061857.GA22398@polanet.pl>
 <5669E2A5.9090202@pld-linux.org>
Message-ID: <20151211083159.GA5653@polanet.pl>

On Thu, Dec 10, 2015 at 22:37:57 +0200, Elan Ruusam?e wrote:

> applied patch from rc-scripts mailing list dated 2015-11-26, thus three 
> weeks old!

So, you're saying there actually was not only a bug report, but the
patch itself and you did ignore it? Nice...

> if you're so smart and so caring, why didn't you apply it yourself. 

I'm not messing with rc-scripts so I don't read it's mailing list. If
you do, you should. Still not getting it?

> don't put pressure on me alone!

Please, try to understand - consider rc-scripts as STABLE release. No
new features, no improvements. Let it work like it did before. Commit
changes that are easy understandable, plain and simple, that CAN be
reviewed without knowing shell quirks. rc-scripts is used by less and
less people, so with PLD userbase each day it will be harder to find
such devious bugs.

> and if you had something to complain, why you didn't complain when the 
> commits were made?! package was sent builders week later.
> 
> and show me *your* super awesome commits.

Sure, here you are:

http://git.pld-linux.org/gitweb.cgi?p=projects/rc-scripts.git;a=commitdiff;h=00f5d898da7b7f0090519a6d727a6eb3d1e6dfb0

     introduced in rev. 8719 that neither pdksh nor mksh handled properly,
     not to mention bash - such process backgrounding caused, when called
     from functions/run_cmd (i.e. during service network start), I/O wait
     for STDOUT of 'background' job despite >/dev/null redirects; this
     effectively leads to 2 seconds delay for each interface at system
     startup, cumulating to minutes of pointless waiting on heavy networked
     machines! There is alternate workaround: { { sleep 2; } & } >/dev/null
     that works as expected under pdksh or mksh, but requires additional &
     for zsh and doesn't fix bash behaviour, so please do not touch _THIS_
     solution without comprehensive research! -- Aug 29th, 2012, /me
     Note: this happens due to $() capture, so plain ifup isn't enough.

   -               ( sleep 2; /sbin/arping -q -U -c 1 -I ${DEVICE} ${IP4ADDR%/*} ) > /dev/null 2>&1 < /dev/null &
   +               { ( sleep 2; /sbin/arping -q -U -c 1 -I ${DEVICE} ${IP4ADDR%/*} ) & } > /dev/null 2>&1

This is a comment quality required for this kind of changes. Not '2 seconds faster ifup'.
And a change itself - it makes ifup being much faster. And what did you do?

"rewrite $@ to modify command"
- that's obvious, but why? I would be against messing with positional/argument variables
  directly (only shift is a common practice)

"use runuser instead of su"
- why? did you upgrade util-linux R? No, you didn't... And this should be in a separate commit...

"this simplifies and avoids shell syntax. but until initlog, sigh"
- the hell, simplifies - and what's about that initlog?

> i've had enough of this, if you have bug to report, 
> http://bugs.pld-linux.org is the address where to submit them.

I don't need to fill a bug report, when I can revert bogus commits. I've
typed two suspected and they didn't introduce any bug solutions that
can't be removed.

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


From ed at yen.ipipan.waw.pl  Fri Dec 11 12:12:52 2015
From: ed at yen.ipipan.waw.pl (=?utf-8?B?xYF1a2FzeiBNYcWba28=?=)
Date: Fri, 11 Dec 2015 12:12:52 +0100
Subject: Skrypty startowe mldonkey
In-Reply-To: <1924555.3H7dPjeCXL@dlaptok>
References: <6543411.naJ65lm1OS@dlaptok> <566960D8.2040804@pld-linux.org>
 <1924555.3H7dPjeCXL@dlaptok>
Message-ID: <7044919.NkogCEsknS@dlaptok>

Dnia czwartek, 10 grudnia 2015 13:00:31 ?ukasz Ma?ko pisze:
> Dnia czwartek, 10 grudnia 2015 13:24:08 Elan Ruusam?e pisze:
> > On 10.12.2015 08:18, Tomasz Pala wrote:
> > > >Poprawi?em na:
> > > >daemon --fork --user $USER --chdir ~$USER "exec $MLDONKEY_PATH >
> > > >${LOG:-/dev/null} 2>&1"
> > 
> > committed a fix that should solve it
> > 
> > please test as i'm not allowed to run this kind of software.
> > it will take time until i get to network where i can run it.
> 
> Thanks. I'll check it as soon as I have it built.

If this was the patch you've applied:

diff -u lib/functions /lib/rc-scripts/functions
--- lib/functions       2015-12-10 13:55:28.721673231 +0100
+++ /lib/rc-scripts/functions   2015-12-10 21:43:31.000000000 +0100
@@ -690,13 +690,12 @@
                        --exec "$prog" \
                        -- "$@"
        else
-
-               if [ "$makepid" ] && [ "$pidfile" ]; then
-                       export PIDFILE="$pidfile"
-                       set -- /lib/rc-scripts/makepid "$@"
-               fi
-
                if [ "$fork" = "1" ]; then
+                       export PIDFILE="/dev/null"
+                       if [ "$makepid" ] && [ "$pidfile" ]; then
+                               export PIDFILE="$pidfile"
+                       fi
+                       set -- /lib/rc-scripts/makepid "$@"
                        set -- /usr/bin/setsid "$@"
                fi
                if [ -n "$user" -a "$user" != "root" ]; then

then - unfortunately - it does not work. The starting script does not stop 
here now, but mldonkey (in my case) is not stared any way :-(
-- 
?ukasz Ma?ko                                                            _o)
Lukasz.Masko(at)ipipan.waw.pl                                           /\\
Registered Linux User #61028                                           _\_V
Ubuntu: staroafryka?skie s?owo oznaczaj?ce "Nie umiem zainstalowa? Debiana"



From mmazur at kernel.pl  Fri Dec 11 13:44:03 2015
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Fri, 11 Dec 2015 13:44:03 +0100
Subject: Skrypty startowe mldonkey
In-Reply-To: <20151210061857.GA22398@polanet.pl>
References: <6543411.naJ65lm1OS@dlaptok> <20151210061857.GA22398@polanet.pl>
Message-ID: <201512111344.03593.mmazur@kernel.pl>

On Thu of December 10 2015, Tomasz Pala wrote:

>  We ought to keep rc-scripts in a working state

Yes.

>  and do not
> 'improve' this obsolete project!
(?)
> Please, try to understand - consider rc-scripts as STABLE release. No
> new features, no improvements.

No.
Six different people have made changes to rc-scripts in this year alone, me 
and you included. I needed new features and bugfixes in the networking code, 
so I made them. What you think about whether I (or anyone else) should or 
should not touch rc-scripts to add or fix stuff is irrelevant. Somebody needs 
it, somebody does it.

Regarding issues and bugs that happen: don't know where you work, princess, 
but where I do everybody regularly makes mistakes and introduces problems by 
accident when making changes. Standard procedure is to *not* be a dick while 
pointing out other peoples' mistakes.

Now, I understand that it's tradition to be a dick to other people in PLD, so, 
for old times' sake, why not, seems you're fond of traditions.

But it's also tradition that the guy that does most of the work on a given 
package in a given period of time is considered de facto maintainer. And for 
rc-scripts that seems to be glen for a long while now. Most of his changes do 
not eat anybody's babies. If he introduces issues, describe where the bug is 
(at least to the extent that your communication? skills allow), hey, maybe fix 
it yourself if you understand the problem well.

But no, you don't get to just threaten reversing everything like that.

And if this takes longer to fix cause you're being a dick about it and glen 
gets discouraged from working on it for a while, that's all on you and your? 
traditionalism.


--mmazur


From gotar at polanet.pl  Fri Dec 11 14:58:29 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Fri, 11 Dec 2015 14:58:29 +0100
Subject: Skrypty startowe mldonkey
In-Reply-To: <201512111344.03593.mmazur@kernel.pl>
References: <6543411.naJ65lm1OS@dlaptok> <20151210061857.GA22398@polanet.pl>
 <201512111344.03593.mmazur@kernel.pl>
Message-ID: <20151211135829.GA2461@polanet.pl>

On Fri, Dec 11, 2015 at 13:44:03 +0100, Mariusz Mazur wrote:

> Somebody needs it, somebody does it.

When sb needs to break compatibility he is allowed to do so? Seriously?

> Regarding issues and bugs that happen: don't know where you work, princess, 
> but where I do everybody regularly makes mistakes and introduces problems by 
> accident when making changes. Standard procedure is to *not* be a dick while 
> pointing out other peoples' mistakes.

These changes are CLEARLY breaking compatibility - I don't blame anyone
for making technical mistakes, but for intentional change. If that
wasn't intentional, well... I don't want to point out incompetence, so
please don't make me.

> Now, I understand that it's tradition to be a dick to other people in PLD, so, 
> for old times' sake, why not, seems you're fond of traditions.

That tradition had a reason. Flameless issues simply got ignored (fix it
yourself, I don't care) and that caused what you call 'tradition'.

In older days I would simply revert these changes as breaking compat
with some rude comment - consider my current behaviour as less dicky.

> not eat anybody's babies. If he introduces issues, describe where the bug is 
> (at least to the extent that your communication??? skills allow),

Both commits I've pointed out are simply bogus. That's it.

> hey, maybe fix it yourself if you understand the problem well.

If I knew the INTENTIONS of these changes, I might be able to help. But
I see none - all my fixing would be reverting them. I gave the author a
chance to explain or fix. Instead he has 'fixed' mldonkey...

I know why su was replaced by runuser and that's all. WHY does:

"daemon: makepid implies fork"?

I've just checked once again - no, there's no explanation. How can I fix
the code that is not valid and was ...pointless? (don't know).

> But no, you don't get to just threaten reversing everything like that.

I don't like:

1. putting "makepid implies fork" in daemon() and nesting 'if [ "$makepid" ] '
within 'if [ "$fork" = "1" ]' in _daemon_exec() - this is splitted logic
that should be avoided whenever possible; now it LOOKS like it's broken
(is it?) and eventually someone will fix that,
2. extracting entire _daemon_exec() from _daemon() - the former one
handles variables which are parset by latter one (and passed via $@).
Rationale "this will ease understanding it's logic and avoid bugs" is,
well, funny?
3. rewriting $@ which is error prone like, by analogy - accessing array
by hardcoded index and not a (hash) key.

This style of coding has it's name: bad coding practice. And we didn't
have to wait too long to expose bugs.

> And if this takes longer to fix cause you're being a dick about it and glen 
> gets discouraged from working on it for a while, that's all on you and your??? 
> traditionalism.

I can't fix this code other way that rolling back to the previous one,
which was FINE. So tell me please, what was wrong before? What was he
going to acomplish? THEN I might be able to help with proper solution.
Until that moment all I can do is being a dick as you named.

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


From gotar at polanet.pl  Fri Dec 11 15:06:19 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Fri, 11 Dec 2015 15:06:19 +0100
Subject: Skrypty startowe mldonkey
In-Reply-To: <201512111344.03593.mmazur@kernel.pl>
References: <6543411.naJ65lm1OS@dlaptok> <20151210061857.GA22398@polanet.pl>
 <201512111344.03593.mmazur@kernel.pl>
Message-ID: <20151211140619.GB2461@polanet.pl>

On Fri, Dec 11, 2015 at 13:44:03 +0100, Mariusz Mazur wrote:

>> Please, try to understand - consider rc-scripts as STABLE release. No
>> new features, no improvements.
> 
> No.
> Six different people have made changes to rc-scripts in this year alone, me 
> and you included. I needed new features and bugfixes in the networking code, 

One more thing: as I already wrote before, "Commit
changes that are easy understandable, plain and simple, that CAN be
reviewed without knowing shell quirks." - especially for one of the most
important functions like daemon(), otherwise it's going to bite
you in the ass, sooner or later. Sooner this time. It's not perl golf.

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


From baggins at pld-linux.org  Sun Dec 13 11:34:14 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 13 Dec 2015 11:34:14 +0100
Subject: Packages scheduled for removal
Message-ID: <20151213103414.GB4786@home.lan>

The following packages do not build and thus are scheduled for remval,
it will happen next week (please fix if you think we should keep them):

sysdig (ooold version in repo)
telnet-ssl
vlock (now in kbd-vlock)
callweaver (dead project)
ekg  (dead project)

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


From glen at delfi.ee  Mon Dec 14 09:56:52 2015
From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Mon, 14 Dec 2015 10:56:52 +0200
Subject: [PATCH] daemon: always treat command as a shell command
In-Reply-To: <1449941617-17249-1-git-send-email-krzysiek@podlesie.net>
References: <1449941617-17249-1-git-send-email-krzysiek@podlesie.net>
Message-ID: <566E8454.9070007@delfi.ee>

On 12.12.2015 19:33, Krzysztof Mazur wrote:
> Before the commit 04a486e0827d935351288c255d03dc71aeb7c727
> ("daemon: move $prog build to RC_LOGGING=yes part, ssd does not use it")
> all commands with --fork or --user options were executed as shell commands,
> due to using sh -c in implementation of both options. This implementation
> specific behavior has been used by some scripts, for instance
> fancontrol:
>
> 	daemon --fork 'fancontrol >/dev/null'
>
> That commit broke it for RC_LOGGING=no and later changes broke it also
> for RC_LOGGING=yes.

the package was fixed in git already by that time:

http://git.pld-linux.org/?p=packages/lm_sensors.git;a=summary

lm_sensors-3.4.0-2 
<http://git.pld-linux.org/?p=packages/lm_sensors.git;a=shortlog;h=refs/tags/auto/th/lm_sensors-3.4.0-2>


-- 
glen



From mmazur at kernel.pl  Mon Dec 14 11:08:30 2015
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Mon, 14 Dec 2015 11:08:30 +0100
Subject: Skrypty startowe mldonkey
In-Reply-To: <20151211135829.GA2461@polanet.pl>
References: <6543411.naJ65lm1OS@dlaptok> <201512111344.03593.mmazur@kernel.pl>
 <20151211135829.GA2461@polanet.pl>
Message-ID: <201512141108.30567.mmazur@kernel.pl>

(Sorry for the delay, weekend is mostly computer-less.)

On Fri of December 11 2015, Tomasz Pala wrote:

> > On Fri, Dec 11, 2015 at 13:44:03 +0100, Mariusz Mazur wrote:
> > Somebody needs it, somebody does it.
> 
> When sb needs to break compatibility he is allowed to do so? Seriously?

The way I see it there are usually are two options in cases like this:
1. Evolution of core scripts/libraries is acceptable even if it has wide-
reaching consequences because we always have the option of mass commits to all 
affected packages to make sure everything keeps working.
2. However the above does not hold true for cases were compatibility with 
external apps is important. Here even a mass commit is not able to fix enough 
of the problem.

The way I see it sysv init scripts will be primarily used for dealing with 
legacy software, which means compatibility with most/all of external packages 
is important and should not be broken. It should even be explicitly pursued.

At the same time glen obviously has ongoing use cases, otherwise he wouldn't 
have a reason to look at rc-scripts (I believe he mentioned vserver).

I think that the prefered solution here would be to:
1. Explicitly set a goal for all of the common sysv functions (like 'daemon') 
to be as widely compatible as possible and only make changes to them to 
increase said compatibility.
2. For our developers' purposes have our own set of functions we're free to 
not care about external/legacy software compatibility ('daemon2' or 
'pld_extreme_daemon' or something) and can keep on evolving them for whatever 
it is we need at a given time.

Does anybody have an issue with such an approach?


--mmazur


From atler at pld-linux.org  Thu Dec 17 21:34:25 2015
From: atler at pld-linux.org (Jan Palus)
Date: Thu, 17 Dec 2015 21:34:25 +0100
Subject: RFC: default python installlation directories
In-Reply-To: <5651B42C.4030209@jajcus.net>
References: <5651B42C.4030209@jajcus.net>
Message-ID: <20151217203425.GA20865@cukinia.lan>

Regarding migration to new %py_* macros -- is there a way to define
setup.py options instead of "action" options? For example how to
correctly migrate following invocation:

%{__python} setup.py \
       --no-compile-schemas \
       --no-update-icon-cache \
       install \
       --optimize=2 \
       --root=$RPM_BUILD_ROOT

to be more specific -- how to pass --no-* options?


From jajcus at jajcus.net  Fri Dec 18 10:07:01 2015
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Fri, 18 Dec 2015 10:07:01 +0100
Subject: RFC: default python installlation directories
In-Reply-To: <20151217203425.GA20865@cukinia.lan>
References: <5651B42C.4030209@jajcus.net> <20151217203425.GA20865@cukinia.lan>
Message-ID: <5673CCB5.4040801@jajcus.net>

On 2015-12-17 21:34, Jan Palus wrote:
> Regarding migration to new %py_* macros -- is there a way to define
> setup.py options instead of "action" options? For example how to
> correctly migrate following invocation:
>
> %{__python} setup.py \
>         --no-compile-schemas \
>         --no-update-icon-cache \
>         install \
>         --optimize=2 \
>         --root=$RPM_BUILD_ROOT
>
> to be more specific -- how to pass --no-* options?

There is probably no way ? in such rare cases you need to expand the 
%py_build and/or %py_install macro by hand and put the needed options there.

BTW those '--no-compile-schemas' and '--no-update-icon-cache' are not 
standard distutils/setuptools options. We cannot handle anything called 
'setup.py' with our %py_* macros, like our '%configure' macro usually 
doesn't work with 'configure' scripts made by hand and not with autoconf.

Jacek


From glen at pld-linux.org  Fri Dec 18 13:03:30 2015
From: glen at pld-linux.org (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Fri, 18 Dec 2015 14:03:30 +0200
Subject: RFC: default python installlation directories
In-Reply-To: <5673CCB5.4040801@jajcus.net>
References: <5651B42C.4030209@jajcus.net> <20151217203425.GA20865@cukinia.lan>
 <5673CCB5.4040801@jajcus.net>
Message-ID: <5673F612.3010300@pld-linux.org>

On 18.12.2015 11:07, Jacek Konieczny wrote:
> On 2015-12-17 21:34, Jan Palus wrote:
>> Regarding migration to new %py_* macros -- is there a way to define
>> setup.py options instead of "action" options? For example how to
>> correctly migrate following invocation:
>>
>> %{__python} setup.py \
>>         --no-compile-schemas \
>>         --no-update-icon-cache \
>>         install \
>>         --optimize=2 \
>>         --root=$RPM_BUILD_ROOT
>>
>> to be more specific -- how to pass --no-* options?
>
> There is probably no way ? in such rare cases you need to expand the 
> %py_build and/or %py_install macro by hand and put the needed options 
> there.
>
> BTW those '--no-compile-schemas' and '--no-update-icon-cache' are not 
> standard distutils/setuptools options. We cannot handle anything 
> called 'setup.py' with our %py_* macros, like our '%configure' macro 
> usually doesn't work with 'configure' scripts made by hand and not 
> with autoconf.

perhaps add macro which is to be defined in .spec:

%define py_install_options --no-compile-schemas --no-update-icon-cache

%py_install


-- 
glen



From jajcus at jajcus.net  Fri Dec 18 13:30:38 2015
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Fri, 18 Dec 2015 13:30:38 +0100
Subject: RFC: default python installlation directories
In-Reply-To: <5673F612.3010300@pld-linux.org>
References: <5651B42C.4030209@jajcus.net> <20151217203425.GA20865@cukinia.lan>
 <5673CCB5.4040801@jajcus.net> <5673F612.3010300@pld-linux.org>
Message-ID: <5673FC6E.2020704@jajcus.net>

On 2015-12-18 13:03, Elan Ruusam?e wrote:
>
> perhaps add macro which is to be defined in .spec:
>
> %define py_install_options --no-compile-schemas --no-update-icon-cache
>
> %py_install

For a single spec?

Jacek


From glen at pld-linux.org  Fri Dec 18 15:39:08 2015
From: glen at pld-linux.org (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Fri, 18 Dec 2015 16:39:08 +0200
Subject: RFC: default python installlation directories
In-Reply-To: <5673FC6E.2020704@jajcus.net>
References: <5651B42C.4030209@jajcus.net> <20151217203425.GA20865@cukinia.lan>
 <5673CCB5.4040801@jajcus.net> <5673F612.3010300@pld-linux.org>
 <5673FC6E.2020704@jajcus.net>
Message-ID: <56741A8C.7000707@pld-linux.org>

On 18.12.2015 14:30, Jacek Konieczny wrote:
> On 2015-12-18 13:03, Elan Ruusam?e wrote:
>>
>> perhaps add macro which is to be defined in .spec:
>>
>> %define py_install_options --no-compile-schemas --no-update-icon-cache
>>
>> %py_install
>
> For a single spec?

do you rather see it's better if he does not use the macro at all, 
rewrite pure lines?

and nobody knows how many usecases it's really needed (or wants to grep 
existing .spec's).
do you want to patch their setup.py, want to write how to what to patch 
and how?

-- 
glen



From baggins at pld-linux.org  Fri Dec 18 21:27:22 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Fri, 18 Dec 2015 21:27:22 +0100
Subject: Packages scheduled for removal
In-Reply-To: <20151213103414.GB4786@home.lan>
References: <20151213103414.GB4786@home.lan>
Message-ID: <20151218202722.GA4052@home.lan>

On Sun, 13 Dec 2015, Jan R?korajski wrote:

> The following packages do not build and thus are scheduled for remval,
> it will happen next week (please fix if you think we should keep them):
> 
> sysdig (ooold version in repo)
> telnet-ssl
> vlock (now in kbd-vlock)
> callweaver (dead project)
> ekg  (dead project)

Some additions to the list (serious build problems, ooold packages):

framewave
ocfs2-tools

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


From glen at pld-linux.org  Thu Dec 31 11:58:54 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Thu, 31 Dec 2015 12:58:54 +0200
Subject: distribute
Message-ID: <56850A6E.2040806@pld-linux.org>

shouldn't python3-distribute be just dropped from th?

python3-pygments-2.0.2-5.noarch: required "python3-setuptools" is 
provided by the following packages:
a) python3-distribute-0.7.3-3.noarch
b) python3-setuptools-18.6.1-3.noarch
Which one do you want to install ('Q' to abort)? 
[python3-distribute-0.7.3-3.noarch]

-- 
glen



From jajcus at jajcus.net  Thu Dec 31 12:46:58 2015
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Thu, 31 Dec 2015 12:46:58 +0100
Subject: distribute
In-Reply-To: <56850A6E.2040806@pld-linux.org>
References: <56850A6E.2040806@pld-linux.org>
Message-ID: <568515B2.4020309@jajcus.net>

On 2015-12-31 11:58, Elan Ruusam?e wrote:
> shouldn't python3-distribute be just dropped from th?

The egg-info provided by python-distribute may be still required by some 
old Python software. Our python-distribute packages do not contain much 
more.

> python3-pygments-2.0.2-5.noarch: required "python3-setuptools" is
> provided by the following packages:
> a) python3-distribute-0.7.3-3.noarch
> b) python3-setuptools-18.6.1-3.noarch

This is an error. python3-distribute must not provide 
python3-setuptools. I would fix it immediately by our GIT server stopped 
accepting my office SSH key.

Jacek


From draenog at pld-linux.org  Thu Dec 31 15:32:06 2015
From: draenog at pld-linux.org (Kacper Kornet)
Date: Thu, 31 Dec 2015 14:32:06 +0000
Subject: distribute
In-Reply-To: <568515B2.4020309@jajcus.net>
References: <56850A6E.2040806@pld-linux.org>
	<568515B2.4020309@jajcus.net>
Message-ID: <20151231143206.0257b6db@platypus>

On Thu, 31 Dec 2015 12:46:58 +0100
Jacek Konieczny <jajcus at jajcus.net> wrote:
> 
> > python3-pygments-2.0.2-5.noarch: required "python3-setuptools" is
> > provided by the following packages:
> > a) python3-distribute-0.7.3-3.noarch
> > b) python3-setuptools-18.6.1-3.noarch  
> 
> This is an error. python3-distribute must not provide 
> python3-setuptools. I would fix it immediately by our GIT server
> stopped accepting my office SSH key.

Please, try once more. I have enabled back DSA keys for some time.

Kacper




From jajcus at jajcus.net  Thu Dec 31 15:58:23 2015
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Thu, 31 Dec 2015 15:58:23 +0100
Subject: SSH to git.pld-linux.org (was: Re: distribute)
In-Reply-To: <20151231143206.0257b6db@platypus>
References: <56850A6E.2040806@pld-linux.org> <568515B2.4020309@jajcus.net>
 <20151231143206.0257b6db@platypus>
Message-ID: <5685428F.5090304@jajcus.net>

On 2015-12-31 15:32, Kacper Kornet wrote:
> On Thu, 31 Dec 2015 12:46:58 +0100
> Jacek Konieczny <jajcus at jajcus.net> wrote:

>> python3-setuptools. I would fix it immediately by our GIT server
>> stopped accepting my office SSH key.
>
> Please, try once more. I have enabled back DSA keys for some time.

Now it is even worse:
$ ssh git at git.pld-linux.org
ssh: connect to host git.pld-linux.org port 22: Connection refused

And I think I have used RSA keys from this host recently, but that 
stopped to work. And the last time I tried the 'sskm' thing to update my 
keys, it didn't work.

Jacek


From draenog at pld-linux.org  Thu Dec 31 18:15:45 2015
From: draenog at pld-linux.org (Kacper Kornet)
Date: Thu, 31 Dec 2015 17:15:45 +0000
Subject: SSH to git.pld-linux.org (was: Re: distribute)
In-Reply-To: <5685428F.5090304@jajcus.net>
References: <56850A6E.2040806@pld-linux.org> <568515B2.4020309@jajcus.net>
 <20151231143206.0257b6db@platypus> <5685428F.5090304@jajcus.net>
Message-ID: <20151231171545.4d6605cf@platypus>

On Thu, 31 Dec 2015 15:58:23 +0100
Jacek Konieczny <jajcus at jajcus.net> wrote:

> On 2015-12-31 15:32, Kacper Kornet wrote:
> > On Thu, 31 Dec 2015 12:46:58 +0100
> > Jacek Konieczny <jajcus at jajcus.net> wrote:  
> 
> >> python3-setuptools. I would fix it immediately by our GIT server
> >> stopped accepting my office SSH key.  
> >
> > Please, try once more. I have enabled back DSA keys for some time.  
> 
> Now it is even worse:
> $ ssh git at git.pld-linux.org
> ssh: connect to host git.pld-linux.org port 22: Connection refused

I'm sorry. Should work now.

> 
> And I think I have used RSA keys from this host recently, but that 
> stopped to work.

Can you provide fingerprint of the key that failed?

> And the last time I tried the 'sskm' thing to update
> my keys, it didn't work.

Indeed, I see some errors in logs. I will investigate.

Kacper


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