From qboosh at pld-linux.org  Sun Mar  1 10:05:50 2015
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sun, 1 Mar 2015 10:05:50 +0100
Subject: [packages/ocaml-findlib] - fixed files for opt build - don't
 strip non-opt builds - rel 6
In-Reply-To: <cb6783e55a83ff07b15427e772da6a6f720490a8_refs_heads_master@pld-linux.org>
References: <0014a6069b84133ddebee5467eb8aa26ebbb390b_refs_heads_master@pld-linux.org>
 <cb6783e55a83ff07b15427e772da6a6f720490a8_refs_heads_master@pld-linux.org>
Message-ID: <20150301090550.GA1662@mail>

On Sun, Mar 01, 2015 at 02:13:20AM +0100, baggins wrote:
> commit cb6783e55a83ff07b15427e772da6a6f720490a8
> Author: Jan R?korajski <baggins at pld-linux.org>
> Date:   Sun Mar 1 02:12:54 2015 +0100
> 
>     - fixed files for opt build
>     - don't strip non-opt builds
>     - rel 6
> 
>  ocaml-findlib.spec | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> ---
> diff --git a/ocaml-findlib.spec b/ocaml-findlib.spec
> index c9d835a..39c079c 100644
> --- a/ocaml-findlib.spec
> +++ b/ocaml-findlib.spec
> @@ -4,6 +4,7 @@
>  
>  %ifarch x32
>  %undefine	with_opt
> +%define		no_install_post_strip	1
>  %endif

I'd suggest ocaml_opt bcond, so it could be common for ocaml- and
not-only-ocaml specs (there is already ocaml_opt bcond in some library
with ocaml binding).

What is the issue with stripping?
Does it affect files of some type (extension?), or the same files
depending on build type?
In the first case _noautostrip (unconditional) is the solution.


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


From baggins at pld-linux.org  Sun Mar  1 11:20:31 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 1 Mar 2015 11:20:31 +0100
Subject: [packages/ocaml-findlib] - fixed files for opt build - don't
 strip non-opt builds - rel 6
In-Reply-To: <20150301090550.GA1662@mail>
References: <0014a6069b84133ddebee5467eb8aa26ebbb390b_refs_heads_master@pld-linux.org>
 <cb6783e55a83ff07b15427e772da6a6f720490a8_refs_heads_master@pld-linux.org>
 <20150301090550.GA1662@mail>
Message-ID: <20150301102030.GA2640@home.lan>

On Sun, 01 Mar 2015, Jakub Bogusz wrote:

> On Sun, Mar 01, 2015 at 02:13:20AM +0100, baggins wrote:
> > commit cb6783e55a83ff07b15427e772da6a6f720490a8
> > Author: Jan R?korajski <baggins at pld-linux.org>
> > Date:   Sun Mar 1 02:12:54 2015 +0100
> > 
> >     - fixed files for opt build
> >     - don't strip non-opt builds
> >     - rel 6
> > 
> >  ocaml-findlib.spec | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > ---
> > diff --git a/ocaml-findlib.spec b/ocaml-findlib.spec
> > index c9d835a..39c079c 100644
> > --- a/ocaml-findlib.spec
> > +++ b/ocaml-findlib.spec
> > @@ -4,6 +4,7 @@
> >  
> >  %ifarch x32
> >  %undefine	with_opt
> > +%define		no_install_post_strip	1
> >  %endif
> 
> I'd suggest ocaml_opt bcond, so it could be common for ocaml- and
> not-only-ocaml specs (there is already ocaml_opt bcond in some library
> with ocaml binding).

Feel free to change the template and all ocaml* specs...

> What is the issue with stripping?
> Does it affect files of some type (extension?), or the same files
> depending on build type?
> In the first case _noautostrip (unconditional) is the solution.

Stripping breaks ocamlfind build on system without opt (or just without opt).
It stops recognizing some options.

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


From glen at pld-linux.org  Sun Mar  1 13:00:15 2015
From: glen at pld-linux.org (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Sun, 01 Mar 2015 14:00:15 +0200
Subject: [packages/sqlite3] drop pointless year macro
In-Reply-To: <20150228223010.6b8b4567@zonk.pl>
References: <cd683928bc30d8dd3569bf05b63d470b878093c3_refs_heads_master@pld-linux.org>
 <9ff1c54dc27e48a465cfd09860bd031e6923c26a_refs_heads_master@pld-linux.org>
 <20150228223010.6b8b4567@zonk.pl>
Message-ID: <54F2FF4F.9070806@pld-linux.org>

On 01.03.2015 00:30, Adam Osuchowski wrote:
> glen wrote:
>> commit 9ff1c54dc27e48a465cfd09860bd031e6923c26a
>> Author: Elan Ruusam?e <glen at delfi.ee>
>> Date:   Thu Feb 26 22:08:01 2015 +0200
>>
>>      drop pointless year macro
>>
>>   sqlite3.spec | 7 +++----
>>   1 file changed, 3 insertions(+), 4 deletions(-)
>> ---
>> diff --git a/sqlite3.spec b/sqlite3.spec
>> index 0e3842c..63fe775 100644
>> --- a/sqlite3.spec
>> +++ b/sqlite3.spec
>> @@ -20,12 +20,9 @@
>>   %undefine	with_tests
>>   %endif
>>   
>> -%define		version_year	2015
>>   #define		version_num %(echo %{version} |  awk -F. '{printf("%d%02d%02d%02d", $1, $2, $3, $4)}')
>>   %define		version_num	3080803
>> -%define		_ulibdir	/usr/lib
>>   %define		tclver		8.6
>
> No, it isn't pointless! The values of url and other tags should be universal
> as much as possible. In case of version updating, the year in url may change
> and nobody wants to wonder if any part of any tag should be updated in
> connection with it. Macros is designed for such cases and clearly points
> what should to pay attention to.
>
> If %version_year is pointless, the %version_num is pointless too and should
> be removed alike. Please keep coherent.
>
> Think logically about changes you apply before you do it and don't
> determine and change anything basing on your private judgements and point
> of view only. Your are not the one-man oracle! Once again, your behaviour,
> manners and collaborative skills leave a lot to be desired.

wow. where all that anger came from?!

year macro is pointless, as it's used only once in the spec.
version num is not pointless, it's used more than one place in spec

and no, macros should not be overused,
in fact macros should be only in last path component, so you could copy 
paste the url for base path to browse files in the same dir.
you don't go and use %{name} macro in domain portion of the URL, or 
%description!
Source0:    http://www.%{name}.org/%{year}/%{name}-src-%{vnum}.zip

and your judgement is private as well, year is not that often changed 
component it needs macro.
i can say same to you, think logically when you add another macro!
and specs should not be universal, especially %files in public dir like 
%{_bindir}!
having verbose file allows grep the specs for existing files. with 
macros it's not possible.

-- 
glen



From glen at pld-linux.org  Sun Mar  1 14:43:12 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Sun, 01 Mar 2015 15:43:12 +0200
Subject: [packages/ocaml-findlib] - fixed files for opt build - don't
 strip non-opt builds - rel 6
In-Reply-To: <20150301102030.GA2640@home.lan>
References: <0014a6069b84133ddebee5467eb8aa26ebbb390b_refs_heads_master@pld-linux.org>
 <cb6783e55a83ff07b15427e772da6a6f720490a8_refs_heads_master@pld-linux.org>
 <20150301090550.GA1662@mail> <20150301102030.GA2640@home.lan>
Message-ID: <54F31770.4050102@pld-linux.org>

On 01.03.2015 12:20, Jan R?korajski wrote:
>> >I'd suggest ocaml_opt bcond, so it could be common for ocaml- and
>> >not-only-ocaml specs (there is already ocaml_opt bcond in some library
>> >with ocaml binding).
> Feel free to change the template and all ocaml* specs...
>

| # Conditional build:
| %bcond_without  ocaml_opt       # build opt


would be nice to enhance that bcond desc, what is the "opt" meaning.
description "build opt" is as "useful" explanation as no description at all.

-- 
glen



From glen at pld-linux.org  Mon Mar  2 19:56:17 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Mon, 02 Mar 2015 20:56:17 +0200
Subject: lib64 on i686
Message-ID: <54F4B251.100@pld-linux.org>

this must be reverted:

$ rpm -qf /lib64
FHS-2.3-37.i686

-- 
glen



From glen at pld-linux.org  Mon Mar  2 20:04:07 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Mon, 02 Mar 2015 21:04:07 +0200
Subject: [packages/redis] - up to 2.8.19
In-Reply-To: <7ca0dec62d6e4d5da8f90e516367bf529279785f_refs_heads_master@pld-linux.org>
References: <0ba44e90ba757791b00257feaef0e43db675960b_refs_heads_master@pld-linux.org>
 <7ca0dec62d6e4d5da8f90e516367bf529279785f_refs_heads_master@pld-linux.org>
Message-ID: <54F4B427.6070609@pld-linux.org>

On 02.03.2015 12:12, arekm wrote:
> +# Fix link
> +ln -sf %{name}-server $RPM_BUILD_ROOT%{_bindir}/%{name}-sentinel
> +
>   # Install misc other
>   install -p %{SOURCE2} $RPM_BUILD_ROOT/etc/rc.d/init.d/%{name}
>   cp -p %{SOURCE1} $RPM_BUILD_ROOT/etc/logrotate.d/%{name}
> @@ -157,6 +160,7 @@ fi
>   %defattr(644,root,root,755)
>   %config(noreplace) %{_sysconfdir}/%{name}.conf
>   %attr(754,root,root)/etc/rc.d/init.d/%{name}
> +%attr(755,root,root) %{_bindir}/redis-sentinel
>   %attr(755,root,root) %{_sbindir}/redis-server
imho you broke the link, files are in different dirs so relative link is 
broken link

aside: why rpm doesn't complain about this. should complain with a 
possibility to whitelist by pattern or globally.

-- 
glen



From qboosh at pld-linux.org  Mon Mar  2 20:56:47 2015
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Mon, 2 Mar 2015 20:56:47 +0100
Subject: lib64 on i686
In-Reply-To: <54F4B251.100@pld-linux.org>
References: <54F4B251.100@pld-linux.org>
Message-ID: <20150302195647.GA25405@mail>

On Mon, Mar 02, 2015 at 08:56:17PM +0200, Elan Ruusam?e wrote:
> this must be reverted:
> 
> $ rpm -qf /lib64
> FHS-2.3-37.i686

Uh, %with macro misuse. Fixed.


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


From gglater62 at gmail.com  Tue Mar  3 10:37:37 2015
From: gglater62 at gmail.com (Witold Filipczyk)
Date: Tue, 3 Mar 2015 10:37:37 +0100
Subject: lib64 on i686
In-Reply-To: <20150302195647.GA25405@mail>
References: <54F4B251.100@pld-linux.org>
 <20150302195647.GA25405@mail>
Message-ID: <20150303093737.GA2405@pldmachine.domain_not_set.invalid>

On Mon, Mar 02, 2015 at 08:56:47PM +0100, Jakub Bogusz wrote:
> On Mon, Mar 02, 2015 at 08:56:17PM +0200, Elan Ruusam?e wrote:
> > this must be reverted:
> > 
> > $ rpm -qf /lib64
> > FHS-2.3-37.i686
> 
> Uh, %with macro misuse. Fixed.

The same issue is in the filesysytem.spec


From glen at pld-linux.org  Tue Mar  3 20:25:09 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Tue, 03 Mar 2015 21:25:09 +0200
Subject: [packages/wl] - that's binary driver, no version for x32
In-Reply-To: <a613bf11d39b72e3f27ced6983bfc3b1bcd7ed89_refs_heads_master@pld-linux.org>
References: <14b68eb328e482d157c263c2a1f45773fe8365f6_refs_heads_master@pld-linux.org>
 <a613bf11d39b72e3f27ced6983bfc3b1bcd7ed89_refs_heads_master@pld-linux.org>
Message-ID: <54F60A95.20200@pld-linux.org>

On 03.03.2015 00:38, baggins wrote:
> commit a613bf11d39b72e3f27ced6983bfc3b1bcd7ed89
> Author: Jan R?korajski <baggins at pld-linux.org>
> Date:   Mon Mar 2 22:38:21 2015 +0000
>
>      - that's binary driver, no version for x32
>
>   wl.spec | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> ---
> diff --git a/wl.spec b/wl.spec
> index a2174b7..f188344 100644
> --- a/wl.spec
> +++ b/wl.spec
> @@ -32,7 +32,7 @@ Patch1:		gcc-4.9.patch
>   URL:		http://www.broadcom.com/support/802.11/linux_sta.php
>   BuildRequires:	rpmbuild(macros) >= 1.701
>   %{?with_kernel:%{expand:%buildrequires_kernel kernel%%{_alt_kernel}-module-build >= 3:2.6.20.2}}
> -ExclusiveArch:	%{ix86} %{x8664} x32
> +ExclusiveArch:	%{ix86} %{x8664}
>   BuildRoot:	%{tmpdir}/%{name}-%{version}-root-%(id -u -n)
>

i'm confused now. you said x32 kernel is exactly same as x86-64 kernel,
just to avoid shuffling poldek sources it's also built for x32 tree...

-- 
glen



From baggins at pld-linux.org  Tue Mar  3 21:31:50 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 3 Mar 2015 21:31:50 +0100
Subject: [packages/wl] - that's binary driver, no version for x32
In-Reply-To: <54F60A95.20200@pld-linux.org>
References: <14b68eb328e482d157c263c2a1f45773fe8365f6_refs_heads_master@pld-linux.org>
 <a613bf11d39b72e3f27ced6983bfc3b1bcd7ed89_refs_heads_master@pld-linux.org>
 <54F60A95.20200@pld-linux.org>
Message-ID: <20150303203149.GA31785@home.lan>

On Tue, 03 Mar 2015, Elan Ruusam?e wrote:

> On 03.03.2015 00:38, baggins wrote:
> > commit a613bf11d39b72e3f27ced6983bfc3b1bcd7ed89
> > Author: Jan R?korajski <baggins at pld-linux.org>
> > Date:   Mon Mar 2 22:38:21 2015 +0000
> >
> >      - that's binary driver, no version for x32
> >
> >   wl.spec | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > ---
> > diff --git a/wl.spec b/wl.spec
> > index a2174b7..f188344 100644
> > --- a/wl.spec
> > +++ b/wl.spec
> > @@ -32,7 +32,7 @@ Patch1:		gcc-4.9.patch
> >   URL:		http://www.broadcom.com/support/802.11/linux_sta.php
> >   BuildRequires:	rpmbuild(macros) >= 1.701
> >   %{?with_kernel:%{expand:%buildrequires_kernel kernel%%{_alt_kernel}-module-build >= 3:2.6.20.2}}
> > -ExclusiveArch:	%{ix86} %{x8664} x32
> > +ExclusiveArch:	%{ix86} %{x8664}
> >   BuildRoot:	%{tmpdir}/%{name}-%{version}-root-%(id -u -n)
> >
> 
> i'm confused now. you said x32 kernel is exactly same as x86-64 kernel,
> just to avoid shuffling poldek sources it's also built for x32 tree...

Not enough sleep. Of course internal makefile must be fixed to choose
x86-64 binary blob.

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


From n3npq at me.com  Wed Mar  4 15:05:26 2015
From: n3npq at me.com (Jeffrey Johnson)
Date: Wed, 04 Mar 2015 09:05:26 -0500
Subject: [packages/redis] - up to 2.8.19
In-Reply-To: <54F4B427.6070609@pld-linux.org>
References: <0ba44e90ba757791b00257feaef0e43db675960b_refs_heads_master@pld-linux.org>
 <7ca0dec62d6e4d5da8f90e516367bf529279785f_refs_heads_master@pld-linux.org>
 <54F4B427.6070609@pld-linux.org>
Message-ID: <89B991B4-8F4D-4F1A-8E88-9A3851E9CF4D@me.com>


On Mar 2, 2015, at 2:04 PM, Elan Ruusam?e wrote:

> 
> aside: why rpm doesn't complain about this. should complain with a possibility to whitelist by pattern or globally.
> 

rpm cannot dictate Fascist packaging policies: if you want
to split symlinks and their end points into different builds
and packages, there is no way to detect the flaw.

But personally I'd agree with your expectation, just its
not possible to implement without guessing what was
intended.

73 de Jeff



From qboosh at pld-linux.org  Wed Mar  4 16:32:03 2015
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 4 Mar 2015 16:32:03 +0100
Subject: lib64 on i686
In-Reply-To: <20150303093737.GA2405@pldmachine.domain_not_set.invalid>
References: <54F4B251.100@pld-linux.org> <20150302195647.GA25405@mail>
 <20150303093737.GA2405@pldmachine.domain_not_set.invalid>
Message-ID: <20150304153203.GA16461@mail>

On Tue, Mar 03, 2015 at 10:37:37AM +0100, Witold Filipczyk wrote:
> On Mon, Mar 02, 2015 at 08:56:47PM +0100, Jakub Bogusz wrote:
> > On Mon, Mar 02, 2015 at 08:56:17PM +0200, Elan Ruusam?e wrote:
> > > this must be reverted:
> > > 
> > > $ rpm -qf /lib64
> > > FHS-2.3-37.i686
> > 
> > Uh, %with macro misuse. Fixed.
> 
> The same issue is in the filesysytem.spec

Fixed.


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


From baggins at pld-linux.org  Mon Mar 16 08:45:21 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 16 Mar 2015 08:45:21 +0100
Subject: [packages/kernel] add firmware bcond to disable packaging
 firmware in main package (use linux-firmware package)
In-Reply-To: <54DDD0B7.9050507@pld-linux.org>
References: <a0cda32d5c80f88dbd5015d11dc61e9b52a7bee7_refs_heads_master@pld-linux.org>
 <6133b03ba349175a5dd4e5aaacea9a73c2a95115_refs_heads_master@pld-linux.org>
 <CAKY5yHwwfXhQ91ja83JjLN9LFxWR-CxR+hQqrbtX9Rf+08wtNA@mail.gmail.com>
 <54DDD0B7.9050507@pld-linux.org>
Message-ID: <20150316074520.GA29146@home.lan>

On Fri, 13 Feb 2015, Elan Ruusam?e wrote:

> On 13.02.2015 12:10, Jan R?korajski wrote:
> > Add Req linux-firmware when building with internal firmware disabled.
> >
> > On Fri, Feb 13, 2015 at 10:40 AM, glen <glen at pld-linux.org> wrote:
> >> commit 6133b03ba349175a5dd4e5aaacea9a73c2a95115
> >> Author: Elan Ruusam?e <glen at delfi.ee>
> >> Date:   Tue Feb 3 00:03:10 2015 +0200
> >>
> >>      add firmware bcond to disable packaging firmware in main package (use linux-firmware package)
> on a slightly related topic:
> 
> kernel makefile supports two way of installing firmwares:
> 1. install what is needed based on enabled modules
> 2. install any firmware present in sources
> 
> how pld make install is invoked, it does "2", but imho should do "1".

It's not _that_ smart, what I see in Makefile is "install firmware for
modules" and "install all firmware", I don't know if built-in drivers
always pull firmware inline. Besides, the gain would probably be small,
did you test it?

> 
> also, what is the difference with firmware from kernel sources and the 
> externally built one.
> i have not found definitive answer to this.

linux-firmware is more complete due to licensing:

"""
This repository contains all these firmware images which have been
extracted from older drivers, as well various new firmware images which
we were never permitted to include in a GPL'd work, but which we _have_
been permitted to redistribute under separate cover.
"""

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


From jajcus at jajcus.net  Mon Mar 16 09:56:19 2015
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Mon, 16 Mar 2015 09:56:19 +0100
Subject: Time to get rid of Upstart
Message-ID: <55069AB3.8060005@jajcus.net>

Hi,

Long time ago I have added Upstart support to PLD Linux rc-scripts and 
various services. It was many hours of my time wasted and not that are 
just useless scary hacks in the scripts. I will be happy to waste a bit 
more of my time to get rid of this.

Upstart itself is not maintained any more in PLD, or even upstream. And 
the hacks only complicate the rc-scripts even more than it is needed.

The plan is:
? remove all upstart-specific code from rc-scripts and add 'Conflicts: 
upstart' there
? remove 'upstart_controlled', etc. from init scripts
? remove '-upstart' subpackages and add 'Obsoletes: %{name}-upstart', 
'Conflicts: upstart' to the corresponding packages

Then the 'upstart' package should be dropped from Th too.

What do you think?

Greets,
Jacek


From j.rekorajski at gmail.com  Mon Mar 16 12:52:04 2015
From: j.rekorajski at gmail.com (=?UTF-8?Q?Jan_R=C4=99korajski?=)
Date: Mon, 16 Mar 2015 12:52:04 +0100
Subject: Time to get rid of Upstart
In-Reply-To: <55069AB3.8060005@jajcus.net>
References: <55069AB3.8060005@jajcus.net>
Message-ID: <CAKY5yHxkRqQEsnoUB7NRVBD1ONzwZ6xSmE1CPmZLS5kCJeHSYg@mail.gmail.com>

On Mon, Mar 16, 2015 at 9:56 AM, Jacek Konieczny <jajcus at jajcus.net> wrote:
> Hi,
>
> Long time ago I have added Upstart support to PLD Linux rc-scripts and
> various services. It was many hours of my time wasted and not that are just
> useless scary hacks in the scripts. I will be happy to waste a bit more of
> my time to get rid of this.
>
> Upstart itself is not maintained any more in PLD, or even upstream. And the
> hacks only complicate the rc-scripts even more than it is needed.
>
> The plan is:
> ? remove all upstart-specific code from rc-scripts and add 'Conflicts:
> upstart' there
> ? remove 'upstart_controlled', etc. from init scripts
> ? remove '-upstart' subpackages and add 'Obsoletes: %{name}-upstart',
> 'Conflicts: upstart' to the corresponding packages
>
> Then the 'upstart' package should be dropped from Th too.
>
> What do you think?

Looks good to me.

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


From gotar at polanet.pl  Mon Mar 16 13:13:20 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Mon, 16 Mar 2015 13:13:20 +0100
Subject: Time to get rid of Upstart
In-Reply-To: <55069AB3.8060005@jajcus.net>
References: <55069AB3.8060005@jajcus.net>
Message-ID: <20150316121320.GA30978@polanet.pl>

On Mon, Mar 16, 2015 at 09:56:19 +0100, Jacek Konieczny wrote:

> Upstart itself is not maintained any more in PLD, or even upstream. And 
> the hacks only complicate the rc-scripts even more than it is needed.
[...]
> What do you think?

Where it is worth it, feel free to clean it. But value your time, where
possible you can e.g. replace functions with empty stubs in order to
skip fixing every single init-script and rebuilding packages that do not
require this otherwise. Let these scripts die natually with entire SysV.

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


From gotar at polanet.pl  Mon Mar 16 13:19:31 2015
From: gotar at polanet.pl (Tomasz Pala)
Date: Mon, 16 Mar 2015 13:19:31 +0100
Subject: Time to get rid of Upstart
In-Reply-To: <55069AB3.8060005@jajcus.net>
References: <55069AB3.8060005@jajcus.net>
Message-ID: <20150316121931.GA5628@polanet.pl>

On Mon, Mar 16, 2015 at 09:56:19 +0100, Jacek Konieczny wrote:

> ??? remove '-upstart' subpackages and add 'Obsoletes: %{name}-upstart', 
> 'Conflicts: upstart' to the corresponding packages

Wouldn't that be easier for newly cleaned-up upstart package to:

Conflicts: <list of every pkg-upstart>
Requires: SysV/systemd

?

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


From jajcus at jajcus.net  Mon Mar 16 14:29:06 2015
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Mon, 16 Mar 2015 14:29:06 +0100
Subject: Time to get rid of Upstart
In-Reply-To: <20150316121931.GA5628@polanet.pl>
References: <55069AB3.8060005@jajcus.net> <20150316121931.GA5628@polanet.pl>
Message-ID: <5506DAA2.6060803@jajcus.net>

On 2015-03-16 13:19, Tomasz Pala wrote:
> On Mon, Mar 16, 2015 at 09:56:19 +0100, Jacek Konieczny wrote:
>
>> ??? remove '-upstart' subpackages and add 'Obsoletes: %{name}-upstart',
>> 'Conflicts: upstart' to the corresponding packages
>
> Wouldn't that be easier for newly cleaned-up upstart package to:
>
> Conflicts: <list of every pkg-upstart>
> Requires: SysV/systemd

If anybody still uses Upstart, then he probably has his own upstart jobs
defined. In such case automatic replacement is not a good idea.

What I propose will just get rid of upstart packages for most of PLD
users ? those, who don't use it. For the few who might be using Poldek
will report conflicts, which should be manually resolved. This seems
safer and cleaner (no fake 'upstart' package or bogus 'obsoletes'
somewhere else) to me.

Greets,
	Jacek


From baggins at pld-linux.org  Tue Mar 17 02:24:01 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 17 Mar 2015 02:24:01 +0100
Subject: ImageMagick 6.9.0.10 broke ruby-RMagick
Message-ID: <20150317012401.GA3402@home.lan>

It looks like ImageMagick 6.9.0.10 exception semaphore changes broke
ruby-RMagick. Any help appreciated in fixing the problem.

Commenting out rm_magick_error() contents in rmutil.c:790 or removing
SetErrorHandler() from rmmain.c:1619 works around the issue, but it
would be better if we could find the undrelying cause.

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


From arekm at maven.pl  Thu Mar 19 09:39:10 2015
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Thu, 19 Mar 2015 09:39:10 +0100
Subject: ANN: carme x32 available
Message-ID: <201503190939.10261.arekm@maven.pl>


Hello.

Carme got x32 environment, so

ssh your_account at carme-x32.pld-linux.org

for PLD/Linux Th x32 env.
-- 
Arkadiusz Mi?kiewicz, arekm / ( maven.pl | pld-linux.org )


From glen at pld-linux.org  Fri Mar 20 09:18:26 2015
From: glen at pld-linux.org (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Fri, 20 Mar 2015 10:18:26 +0200
Subject: [packages/ocaml-ctypes] - complete list of archs with opt support
In-Reply-To: <83a1bfa7435378c280f8ceadb461e5bee7d35146_refs_heads_master@pld-linux.org>
References: <adbf4531ff8a235e941e8fb3eef0393fefa23479_refs_heads_master@pld-linux.org>
 <83a1bfa7435378c280f8ceadb461e5bee7d35146_refs_heads_master@pld-linux.org>
Message-ID: <550BD7D2.9090304@pld-linux.org>

On 13.03.2015 23:34, qboosh wrote:
> +# archs with ocaml_opt support (keep in sync with ocaml.spec)
> +ExclusiveArch:	%{ix86} %{x8664} arm aarch64 ppc sparc sparcv9
so, what about adding %ocaml_arches macro and using that?

similarily there's need for %java_arches and probably %ghc_arches


-- 
glen



From qboosh at pld-linux.org  Sat Mar 21 15:49:19 2015
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sat, 21 Mar 2015 15:49:19 +0100
Subject: [packages/ocaml-ctypes] - complete list of archs with opt support
In-Reply-To: <550BD7D2.9090304@pld-linux.org>
References: <adbf4531ff8a235e941e8fb3eef0393fefa23479_refs_heads_master@pld-linux.org>
 <83a1bfa7435378c280f8ceadb461e5bee7d35146_refs_heads_master@pld-linux.org>
 <550BD7D2.9090304@pld-linux.org>
Message-ID: <20150321144919.GA32288@mail>

On Fri, Mar 20, 2015 at 10:18:26AM +0200, Elan Ruusam?e wrote:
> On 13.03.2015 23:34, qboosh wrote:
> >+# archs with ocaml_opt support (keep in sync with ocaml.spec)
> >+ExclusiveArch:	%{ix86} %{x8664} arm aarch64 ppc sparc sparcv9
> so, what about adding %ocaml_arches macro and using that?

Maybe. %ocaml_opt_archs (arches?) in this case.
ocaml itself supports more, this list refers to ocaml with native code
generation.

> similarily there's need for %java_arches and probably %ghc_arches

+ %mono_archs


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


From glen at pld-linux.org  Sat Mar 21 16:41:47 2015
From: glen at pld-linux.org (=?windows-1252?Q?Elan_Ruusam=E4e?=)
Date: Sat, 21 Mar 2015 17:41:47 +0200
Subject: [packages/ocaml-ctypes] - complete list of archs with opt support
In-Reply-To: <20150321144919.GA32288@mail>
References: <adbf4531ff8a235e941e8fb3eef0393fefa23479_refs_heads_master@pld-linux.org>
 <83a1bfa7435378c280f8ceadb461e5bee7d35146_refs_heads_master@pld-linux.org>
 <550BD7D2.9090304@pld-linux.org> <20150321144919.GA32288@mail>
Message-ID: <550D913B.70504@pld-linux.org>

On 21.03.2015 16:49, Jakub Bogusz wrote:
> On Fri, Mar 20, 2015 at 10:18:26AM +0200, Elan Ruusam?e wrote:
>> On 13.03.2015 23:34, qboosh wrote:
>>> +# archs with ocaml_opt support (keep in sync with ocaml.spec)
>>> +ExclusiveArch:	%{ix86} %{x8664} arm aarch64 ppc sparc sparcv9
>> so, what about adding %ocaml_arches macro and using that?
> Maybe. %ocaml_opt_archs (arches?) in this case.
> ocaml itself supports more, this list refers to ocaml with native code
> generation.
>
>> similarily there's need for %java_arches and probably %ghc_arches
> + %mono_archs
>
>

i wonder where to keep these? in rpm-build-macros?
or let each package provide itself the macro (mono-devel contains 
/etc/rpm/macros.mono for example)

-- 
glen



From glen at pld-linux.org  Tue Mar 24 20:53:58 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Tue, 24 Mar 2015 21:53:58 +0200
Subject: noarch main package, arch subpackage?
Message-ID: <5511C0D6.9080307@pld-linux.org>

it's possible to create noarch subpackage with rpm5,
but what if the main package (%files) ought to be noarch but some 
subpackage to be arch package?

example:
https://github.com/pld-linux/gnome-themes-standard/blob/auto/th/gnome-themes-standard-3.14.2.3-1/gnome-themes-standard.spec#L96-L118

here gnome-themes-standard and gnome-themes-standard-accessibility are 
noarch, but only gtk2-theme-engine-adwaita subpackage contains arch 
specific files...


-- 
glen



From n3npq at me.com  Tue Mar 24 21:58:06 2015
From: n3npq at me.com (Jeffrey Johnson)
Date: Tue, 24 Mar 2015 16:58:06 -0400
Subject: noarch main package, arch subpackage?
In-Reply-To: <5511C0D6.9080307@pld-linux.org>
References: <5511C0D6.9080307@pld-linux.org>
Message-ID: <0B451FC5-F03E-4550-8B0C-401608F2978C@me.com>


On Mar 24, 2015, at 3:53 PM, Elan Ruusam?e wrote:

> it's possible to create noarch subpackage with rpm5,
> but what if the main package (%files) ought to be noarch but some subpackage to be arch package?
> 
> example:
> https://github.com/pld-linux/gnome-themes-standard/blob/auto/th/gnome-themes-standard-3.14.2.3-1/gnome-themes-standard.spec#L96-L118
> 
> here gnome-themes-standard and gnome-themes-standard-accessibility are noarch, but only gtk2-theme-engine-adwaita subpackage contains arch specific files...
> 

Try-and-see ... my guess is that you can have per-arch or noarch subpackages
however you wish (but its been like 8-10y since I wrote the code, -ENOCLUE).

You can always have a per-arch main package that has no files (and no %files
means that there will be no binary package produced) and then add another
subpackage that specifies noarch that contains the content that was originally
contained in the main package. You likely have to rename the main package,
and that new name will appear in the *.src.rpm propagated into the subpackages.

hth

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



From glen at pld-linux.org  Wed Mar 25 08:24:51 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Wed, 25 Mar 2015 09:24:51 +0200
Subject: noarch main package, arch subpackage?
In-Reply-To: <0B451FC5-F03E-4550-8B0C-401608F2978C@me.com>
References: <5511C0D6.9080307@pld-linux.org>
 <0B451FC5-F03E-4550-8B0C-401608F2978C@me.com>
Message-ID: <551262C3.3010302@pld-linux.org>

On 24.03.2015 22:58, Jeffrey Johnson wrote:
> On Mar 24, 2015, at 3:53 PM, Elan Ruusam?e wrote:
>
>> it's possible to create noarch subpackage with rpm5,
>> but what if the main package (%files) ought to be noarch but some subpackage to be arch package?
>>
>> example:
>> https://github.com/pld-linux/gnome-themes-standard/blob/auto/th/gnome-themes-standard-3.14.2.3-1/gnome-themes-standard.spec#L96-L118
>>
>> here gnome-themes-standard and gnome-themes-standard-accessibility are noarch, but only gtk2-theme-engine-adwaita subpackage contains arch specific files...
>>
> Try-and-see ... my guess is that you can have per-arch or noarch subpackages
> however you wish (but its been like 8-10y since I wrote the code, -ENOCLUE).
well, i tried as:
BuildArch: noarch in main pacakge
and BuildArch: %{target} in subpackage

but that obviously throw error that subpackages can be only noarch.

[~/relup/gnome-themes-standard (master)?] ? \rpmbuild -bb *.spec
error: line 56: Only "noarch" sub-packages are supported: BuildArch:    
x86_64-linux
error: Package has no %description: gtk2-theme-engine-adwaita.noarch

it's already know that rpm5 behaves that way:
https://github.com/jordansissel/fpm/issues/667
afaik rpm.org permits other values than just "noarch" to "BuildArch:" value.

> You can always have a per-arch main package that has no files (and no %files
> means that there will be no binary package produced) and then add another
> subpackage that specifies noarch that contains the content that was originally
> contained in the main package. You likely have to rename the main package,
> and that new name will appear in the *.src.rpm propagated into the subpackages.
yes, that is the current only possible way. but i do not want to rename 
src.rpm, nor to rename main package...



-- 
glen



From mmazur at kernel.pl  Wed Mar 25 09:53:16 2015
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Wed, 25 Mar 2015 09:53:16 +0100
Subject: Restarting systemd instances on package upgrades
Message-ID: <201503250953.16577.mmazur@kernel.pl>

Let's take openvpn as an example. With old-style init.d scripts, a package 
upgrade meant a service restart openvpn, which rebooted all tunnels. Openvpn 
with systemd init scripts runs multiple openvpn at tunnelX.service instances.

What's the magic rpm macro to run that reboots all of those on package 
upgrade?

--mmazur


From baggins at pld-linux.org  Wed Mar 25 11:09:47 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Wed, 25 Mar 2015 11:09:47 +0100
Subject: Restarting systemd instances on package upgrades
In-Reply-To: <201503250953.16577.mmazur@kernel.pl>
References: <201503250953.16577.mmazur@kernel.pl>
Message-ID: <20150325100947.GA2813@home.lan>

On Wed, 25 Mar 2015, Mariusz Mazur wrote:

> Let's take openvpn as an example. With old-style init.d scripts, a package 
> upgrade meant a service restart openvpn, which rebooted all tunnels. Openvpn 
> with systemd init scripts runs multiple openvpn at tunnelX.service instances.
> 
> What's the magic rpm macro to run that reboots all of those on package 
> upgrade?

There is a How To in sysconfig file:

# On systems running systemd after updating the list below you have to
# restart systemd to regenerate openvpn at TUNNEL.service services
# (systemctl --system daemon-reload), stop and start openvpn.target when
# removing elements from list or restart openvpn.target when only adding
# elements (systemctl stop openvpn.target / systemctl restart
# openvpn.target).

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


From n3npq at me.com  Wed Mar 25 12:06:03 2015
From: n3npq at me.com (Jeffrey Johnson)
Date: Wed, 25 Mar 2015 07:06:03 -0400
Subject: noarch main package, arch subpackage?
In-Reply-To: <551262C3.3010302@pld-linux.org>
References: <5511C0D6.9080307@pld-linux.org>
 <0B451FC5-F03E-4550-8B0C-401608F2978C@me.com> <551262C3.3010302@pld-linux.org>
Message-ID: <02BE2B45-F45C-4066-9DB5-84740D4C27A4@me.com>


> On Mar 25, 2015, at 3:24 AM, Elan Ruusam?e <glen at pld-linux.org> wrote:
> 
> 
> afaik rpm.org <http://rpm.org/> permits other values than just "noarch" to "BuildArch:" value.
> 

Um ? no.

73 de Jeff



From glen at pld-linux.org  Thu Mar 26 13:30:56 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Thu, 26 Mar 2015 14:30:56 +0200
Subject: [projects/geninitrd] Prefer suspend/resume binary over
 initrd/resume. Install previously found binary instead hardcoded o
In-Reply-To: <ace0a232791812ed503f131a5653c251b9fe1099_refs_heads_master@pld-linux.org>
References: <72a1b0ef99c458e8edd6a7a728e073e7328a0327_refs_heads_master@pld-linux.org>
 <ace0a232791812ed503f131a5653c251b9fe1099_refs_heads_master@pld-linux.org>
Message-ID: <5513FC00.40800@pld-linux.org>

On 26.03.2015 14:26, arekm wrote:
> commit ace0a232791812ed503f131a5653c251b9fe1099
> Author: Arkadiusz Mi?kiewicz <arekm at maven.pl>
> Date:   Thu Mar 26 13:26:16 2015 +0100
>
>      Prefer suspend/resume binary over initrd/resume. Install previously found binary instead hardcoded one.
>
>   mod-suspend.sh | 8 ++------
>   1 file changed, 2 insertions(+), 6 deletions(-)
> ---
> diff --git a/mod-suspend.sh b/mod-suspend.sh
> index 48efd57..d905bd0 100644
> --- a/mod-suspend.sh
> +++ b/mod-suspend.sh
> @@ -13,7 +13,7 @@ setup_mod_suspend() {
>   		warn "Tuxonice and mainline suspend are exclusive!"
>   	fi
>   
> -	resume=$(find_tool $initrd_dir/resume /usr/${_lib}/suspend/resume /usr/sbin/resume)
> +	resume=$(find_tool /usr/${_lib}/suspend/resume $initrd_dir/resume /usr/sbin/resume)

_lib is no longer reliable

1366 if [ -d /libx32 -a -d /usr/libx32 ]; then
1367     _lib=libx32
1368 elif [ -d /lib64 -a -d /usr/lib64 ]; then
1369     _lib=lib64
1370 else
1371     _lib=lib
1372 fi
1373

as lines 1366 and 1368 *both* are valid on x86_64 AND x32 system...

i guess you should write there all $lib combinations (lib, lib64, 
libx32) unless can improve the _lib check.

-- 
glen



From arekm at maven.pl  Thu Mar 26 13:35:06 2015
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Thu, 26 Mar 2015 13:35:06 +0100
Subject: [projects/geninitrd] Prefer suspend/resume binary over
 initrd/resume. Install previously found binary instead hardcoded o
In-Reply-To: <5513FC00.40800@pld-linux.org>
References: <72a1b0ef99c458e8edd6a7a728e073e7328a0327_refs_heads_master@pld-linux.org>
 <ace0a232791812ed503f131a5653c251b9fe1099_refs_heads_master@pld-linux.org>
 <5513FC00.40800@pld-linux.org>
Message-ID: <201503261335.06569.arekm@maven.pl>

On Thursday 26 of March 2015, Elan Ruusam?e wrote:
> On 26.03.2015 14:26, arekm wrote:
> > commit ace0a232791812ed503f131a5653c251b9fe1099
> > Author: Arkadiusz Mi?kiewicz <arekm at maven.pl>
> > Date:   Thu Mar 26 13:26:16 2015 +0100
> > 
> >      Prefer suspend/resume binary over initrd/resume. Install previously
> >      found binary instead hardcoded one.
> >   
> >   mod-suspend.sh | 8 ++------
> >   1 file changed, 2 insertions(+), 6 deletions(-)
> > 
> > ---
> > diff --git a/mod-suspend.sh b/mod-suspend.sh
> > index 48efd57..d905bd0 100644
> > --- a/mod-suspend.sh
> > +++ b/mod-suspend.sh
> > @@ -13,7 +13,7 @@ setup_mod_suspend() {
> > 
> >   		warn "Tuxonice and mainline suspend are exclusive!"
> >   	
> >   	fi
> > 
> > -	resume=$(find_tool $initrd_dir/resume /usr/${_lib}/suspend/resume
> > /usr/sbin/resume) +	resume=$(find_tool /usr/${_lib}/suspend/resume
> > $initrd_dir/resume /usr/sbin/resume)
> 
> _lib is no longer reliable
> 
> 1366 if [ -d /libx32 -a -d /usr/libx32 ]; then
> 1367     _lib=libx32
> 1368 elif [ -d /lib64 -a -d /usr/lib64 ]; then
> 1369     _lib=lib64
> 1370 else
> 1371     _lib=lib
> 1372 fi
> 1373
> 
> as lines 1366 and 1368 *both* are valid on x86_64 AND x32 system...

Well, for now above checking needs to be reverted to never break x8664 
systems.

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


From glen at pld-linux.org  Thu Mar 26 14:23:42 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Thu, 26 Mar 2015 15:23:42 +0200
Subject: [projects/geninitrd] Prefer suspend/resume binary over
 initrd/resume. Install previously found binary instead hardcoded o
In-Reply-To: <201503261335.06569.arekm@maven.pl>
References: <72a1b0ef99c458e8edd6a7a728e073e7328a0327_refs_heads_master@pld-linux.org>
 <ace0a232791812ed503f131a5653c251b9fe1099_refs_heads_master@pld-linux.org>
 <5513FC00.40800@pld-linux.org> <201503261335.06569.arekm@maven.pl>
Message-ID: <5514085E.9000108@pld-linux.org>

On 26.03.2015 14:35, Arkadiusz Mi?kiewicz wrote:
> Well, for now above checking needs to be reverted to never break x8664
> systems.
it's does not seem to be used for anything important than suspend and 
multipath and uclibc binaries

[~/rpm/packages/geninitrd/geninitrd (master)?] ? rgrep -r _lib . 
--exclude=ChangeLog
./mod-suspend.sh:16:    resume=$(find_tool $initrd_dir/resume 
/usr/${_lib}/suspend/resume /usr/sbin/resume)
./mod-suspend.sh:61:    if [ -x /usr/${_lib}/suspend/resume ]; then
./mod-suspend.sh:62:            inst_exec /usr/${_lib}/suspend/resume 
/bin/resume
./mod-multipath.sh:115: local scsi_id=$(find_tool /$_lib/udev/scsi_id 
/lib/udev/scsi_id /sbin/scsi_id)
./mod-multipath.sh:118: if [ -d /$_lib/multipath ]; then
./mod-multipath.sh:119:         inst_d /$_lib/multipath
./mod-multipath.sh:120:         inst_exec /$_lib/multipath/* 
/$_lib/multipath
./geninitrd:556:        if [ -f $DESTDIR/$_lib/libc.so.0 ]; then
./geninitrd:557:                lib=$DESTDIR/$_lib/libc.so.0
./geninitrd:563:                        verbose "+ ln -s /$_lib 
$DESTDIR$libdir"
./geninitrd:564:                        ln -s /$_lib $DESTDIR$libdir
./geninitrd:1367:       _lib=libx32
./geninitrd:1369:       _lib=lib64
./geninitrd:1371:       _lib=lib
./geninitrd:1378:debug "Using _lib: $_lib"
[~/rpm/packages/geninitrd/geninitrd (master)?] ?

-- 
glen



From baggins at pld-linux.org  Mon Mar 30 21:08:23 2015
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 30 Mar 2015 21:08:23 +0200
Subject: open-vm-tools
Message-ID: <20150330190822.GA2916@home.lan>

I'm dropping open-vm-tools from kernels > 3.18.

This package is completely foobar, it's designed to build on some
random kernels (it still needs patches for 3.10 for example),
most likely RH specific.

Unless someone volunteers to keep it up to date it is going to rot.

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


From adamg at pld-linux.org  Tue Mar 31 16:04:26 2015
From: adamg at pld-linux.org (Adam Golebiowski)
Date: Tue, 31 Mar 2015 16:04:26 +0200
Subject: [packages/php-pecl-http] - R += pecl-propro and pecl-raphf
In-Reply-To: <a87ebfded9a4fa457a80f1e3f1632afcff329df6_refs_heads_master@pld-linux.org>
References: <66ed567bf73502d3c2f1fff0254087f0dc592a8a_refs_heads_master@pld-linux.org>
 <a87ebfded9a4fa457a80f1e3f1632afcff329df6_refs_heads_master@pld-linux.org>
Message-ID: <20150331140426.GA22593@adamg.eu>

[adamg at adamg ~]$ php -r ''
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php56/http.so' - /usr/lib/php56/http.so: undefined symbol: php_persistent_handle_abandon in Unknown on line 0
[adamg at adamg ~]$ sudo mv /etc/php56/conf.d/{,z_}httpd.ini
[adamg at adamg ~]$ php -r ''
[adamg at adamg ~]$

Not only we need these two, but we need them to load before http.so.

Thinking about adopting apache-style prefixing with numbers:
- 00-29 - core php modules
- 30-99 - extra (pecl / non-pecl)

With defaults for example 20 and 50. 

Comments ?

On Tue, Mar 31, 2015 at 03:09:34PM +0200, adamg wrote:
> commit a87ebfded9a4fa457a80f1e3f1632afcff329df6
> Author: Adam Go??biowski <adamg at pld-linux.org>
> Date:   Tue Mar 31 15:08:21 2015 +0200
> 
>     - R += pecl-propro and pecl-raphf
> 
>  php-pecl-http.spec | 2 ++
>  1 file changed, 2 insertions(+)
> ---
> diff --git a/php-pecl-http.spec b/php-pecl-http.spec
> index ecbb456..8674b73 100644
> --- a/php-pecl-http.spec
> +++ b/php-pecl-http.spec
> @@ -22,6 +22,8 @@ BuildRequires:	zlib-devel >= 1.2.0.4
>  %{?requires_php_extension}
>  Requires:	%{php_name}-hash
>  Requires:	%{php_name}-iconv
> +Requires:	%{php_name}-pecl-propro
> +Requires:	%{php_name}-pecl-raphf
>  Requires:	%{php_name}-session
>  Provides:	php(%{modname}) = %{version}
>  Obsoletes:	php-pecl-http < 1.7.6-4
> ================================================================
> 
> ---- gitweb:
> 
> http://git.pld-linux.org/gitweb.cgi/packages/php-pecl-http.git/commitdiff/a87ebfded9a4fa457a80f1e3f1632afcff329df6
> 
> _______________________________________________
> pld-cvs-commit mailing list
> pld-cvs-commit at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit


From glen at pld-linux.org  Tue Mar 31 16:35:45 2015
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Tue, 31 Mar 2015 17:35:45 +0300
Subject: [packages/php-pecl-http] - R += pecl-propro and pecl-raphf
In-Reply-To: <20150331140426.GA22593@adamg.eu>
References: <66ed567bf73502d3c2f1fff0254087f0dc592a8a_refs_heads_master@pld-linux.org>
 <a87ebfded9a4fa457a80f1e3f1632afcff329df6_refs_heads_master@pld-linux.org>
 <20150331140426.GA22593@adamg.eu>
Message-ID: <551AB0C1.40708@pld-linux.org>

On 31.03.2015 17:04, Adam Golebiowski wrote:
> [adamg at adamg ~]$ php -r ''
> PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php56/http.so' - /usr/lib/php56/http.so: undefined symbol: php_persistent_handle_abandon in Unknown on line 0
> [adamg at adamg ~]$ sudo mv /etc/php56/conf.d/{,z_}httpd.ini
> [adamg at adamg ~]$ php -r ''
> [adamg at adamg ~]$
>
> Not only we need these two, but we need them to load before http.so.
>
> Thinking about adopting apache-style prefixing with numbers:
> - 00-29 - core php modules
> - 30-99 - extra (pecl / non-pecl)

i've tried to postpone introducing numbering to ini files as long as 
possible. because the numbering sucks(!).

maybe rename your ini file so that LC_ALL=C locale would sort it last:

like:
http.ini -> http.ini (no changes)
propro.ini -> http_propro.ini
raphf.ini -> http_raphf.ini

ideally php-core should be smart itself (somehow) to be able to load 
modules in different order based on dependencies.
possible solution would be to open shared library with lazy loading to 
get dependency structure and then do the real open (with RTDL_NOW) after 
dependency sort.
this is just theory, haven't tried.

> With defaults for example 20 and 50.
>
> Comments ?
>
> On Tue, Mar 31, 2015 at 03:09:34PM +0200, adamg wrote:
>> commit a87ebfded9a4fa457a80f1e3f1632afcff329df6
>> Author: Adam Go??biowski <adamg at pld-linux.org>
>> Date:   Tue Mar 31 15:08:21 2015 +0200
>>
>>      - R += pecl-propro and pecl-raphf
>>
>>   php-pecl-http.spec | 2 ++
>>   1 file changed, 2 insertions(+)
>> ---
>> diff --git a/php-pecl-http.spec b/php-pecl-http.spec
>> index ecbb456..8674b73 100644
>> --- a/php-pecl-http.spec
>> +++ b/php-pecl-http.spec
>> @@ -22,6 +22,8 @@ BuildRequires:	zlib-devel >= 1.2.0.4
>>   %{?requires_php_extension}
>>   Requires:	%{php_name}-hash
>>   Requires:	%{php_name}-iconv
>> +Requires:	%{php_name}-pecl-propro
>> +Requires:	%{php_name}-pecl-raphf
>>   Requires:	%{php_name}-session
>>   Provides:	php(%{modname}) = %{version}
>>   Obsoletes:	php-pecl-http < 1.7.6-4
>> ================================================================
>>
>> ---- gitweb:
>>
>> http://git.pld-linux.org/gitweb.cgi/packages/php-pecl-http.git/commitdiff/a87ebfded9a4fa457a80f1e3f1632afcff329df6
>>
>> _______________________________________________
>> pld-cvs-commit mailing list
>> pld-cvs-commit at lists.pld-linux.org
>> http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en


-- 
glen



From adamg at pld-linux.org  Tue Mar 31 17:34:16 2015
From: adamg at pld-linux.org (Adam Golebiowski)
Date: Tue, 31 Mar 2015 17:34:16 +0200
Subject: [packages/php-pecl-http] - R += pecl-propro and pecl-raphf
In-Reply-To: <551AB0C1.40708@pld-linux.org>
References: <66ed567bf73502d3c2f1fff0254087f0dc592a8a_refs_heads_master@pld-linux.org>
 <a87ebfded9a4fa457a80f1e3f1632afcff329df6_refs_heads_master@pld-linux.org>
 <20150331140426.GA22593@adamg.eu> <551AB0C1.40708@pld-linux.org>
Message-ID: <20150331153416.GA30151@adamg.eu>

On Tue, Mar 31, 2015 at 05:35:45PM +0300, Elan Ruusam?e wrote:
> On 31.03.2015 17:04, Adam Golebiowski wrote:
> > [adamg at adamg ~]$ php -r ''
> > PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php56/http.so' - /usr/lib/php56/http.so: undefined symbol: php_persistent_handle_abandon in Unknown on line 0
> > [adamg at adamg ~]$ sudo mv /etc/php56/conf.d/{,z_}httpd.ini
> > [adamg at adamg ~]$ php -r ''
> > [adamg at adamg ~]$
> >
> > Not only we need these two, but we need them to load before http.so.
> >
> > Thinking about adopting apache-style prefixing with numbers:
> > - 00-29 - core php modules
> > - 30-99 - extra (pecl / non-pecl)
> 
> i've tried to postpone introducing numbering to ini files as long as 
> possible. because the numbering sucks(!).

but it's easy and solves the problem. 

> maybe rename your ini file so that LC_ALL=C locale would sort it last:
> 
> like:
> http.ini -> http.ini (no changes)
> propro.ini -> http_propro.ini
> raphf.ini -> http_raphf.ini

until we add some `boo' extension that depends on raphf, and that's just
another version of prefixing. 

> ideally php-core should be smart itself (somehow) to be able to load 
> modules in different order based on dependencies.
> possible solution would be to open shared library with lazy loading to 
> get dependency structure and then do the real open (with RTDL_NOW) after 
> dependency sort.
> this is just theory, haven't tried.

nice, but a bit overcomplicated.
and we would end up maintaining yet another patch.

-- 
adamg