From draenog at pld-linux.org  Tue Apr  1 10:23:15 2014
From: draenog at pld-linux.org (Kacper Kornet)
Date: Tue, 1 Apr 2014 10:23:15 +0200
Subject: dracut: ide vs ata modules
In-Reply-To: <5335DA11.8090906@pld-linux.org>
References: <20140328165836.GA19301@camk.edu.pl>
 <5335DA11.8090906@pld-linux.org>
Message-ID: <20140401082315.GA30822@camk.edu.pl>

On Fri, Mar 28, 2014 at 09:22:41PM +0100, Marcin Krol wrote:
> >I think the second option is the simplest one, so I would like to
> >implement it in  PLD, unless someone has preference.

> Personally I'm using dracut with host-only option enabled. It uses
> system wide module blacklist and includes only modules for supported
> hardware in initramfs, not all of them. I've not encountered (yet)
> machine on which host-only config would prefer IDE drivers over SATA
> ones but perhaps it depends on hardware used.

Try qemu. Even image generated by dracut -H contains both piix and
ata_piix. And unless someone has piix blacklisted in /etc/modprobe.d,
udev loads piix as the first one, and ata_piix only after it.

> If host-only config is not enough then best solution IMO is to patch
> dracut to prefer SATA drivers over IDE. It can be done by checking
> device class if more than one module is available.

I think dracut does something like:

udevadm trigger --type=subsystems --action=add
udevadm trigger --type=devices --action=add

and the module are loaded by rule:

DRIVER!="?*", ENV{MODALIAS}=="?*", RUN{builtin}="kmod load $env{MODALIAS}"

so the order is dictated by modprobe <alias>. Hence my idea is to change 
this order. Patching dracut/udev would be probably more complicated.

-- 
  Kacper


From draenog at pld-linux.org  Tue Apr  1 10:27:39 2014
From: draenog at pld-linux.org (Kacper Kornet)
Date: Tue, 1 Apr 2014 10:27:39 +0200
Subject: dracut: ide vs ata modules
In-Reply-To: <201403281850.09872.arekm@maven.pl>
References: <20140328165836.GA19301@camk.edu.pl>
 <201403281850.09872.arekm@maven.pl>
Message-ID: <20140401082739.GB30822@camk.edu.pl>

On Fri, Mar 28, 2014 at 06:50:09PM +0100, Arkadiusz Mi?kiewicz wrote:
> On Friday 28 of March 2014, Kacper Kornet wrote:
> > In PLD kernels there are both ide and ata drivers for the same controllers,
> > for example ata_piix and piix. Dependant on which one is loaded first
> > the disks are visible as /dev/sd* or /dev/hd*.

> > The kernel help says "Users of ATA hardware are encouraged to migrate to
> > the newer ATA subsystem ("Serial ATA (prod) and Parallel ATA
> > (experimental) drivers") which is more actively maintained."
> > Unfortunately as the dracut in the default configuration tries to load
> > all matching modules in the order presented by modprobe, the ide modules
> > are used in many cases.

> > I can see three solutions:

> > 1) Don't build the ide modules at all. It is the way Fedora went (they
> > have CONFIG_IDE not set except on powerpc). However arekm claims that
> > there are some ide modules not ported to ata.

> > 2) Change the order of modules presented by modprobe for a given alias.
> > That can be accomplished by a trivial patch to kernel Makefile.

> Fails to work with vanilla kernels where using vanilla kernel was supported 
> configuration in pld.

It still would be supported. For this kernels it would work without any
change. The only difference such people would observe is that disks
would could be visible as /dev/hd* or /dev/sd* dependant if they boot
from distribution kernel or the one build and installed without using rpm.

-- 
  Kacper


From hawk at pld-linux.org  Tue Apr  1 11:08:05 2014
From: hawk at pld-linux.org (Marcin Krol)
Date: Tue, 01 Apr 2014 11:08:05 +0200
Subject: dracut: ide vs ata modules
In-Reply-To: <20140401082315.GA30822@camk.edu.pl>
References: <20140328165836.GA19301@camk.edu.pl>
 <5335DA11.8090906@pld-linux.org> <20140401082315.GA30822@camk.edu.pl>
Message-ID: <533A81F5.5020609@pld-linux.org>

> Try qemu. Even image generated by dracut -H contains both piix and
> ata_piix. And unless someone has piix blacklisted in /etc/modprobe.d,
> udev loads piix as the first one, and ata_piix only after it.

Yeah, one have to blacklist IDE module(s) in such case. I think we are 
going a bit too far with this IDE vs PATA/SATA thing. We shouldn't make 
any patches to solve this "problem". Its a matter of proper (and very 
simple) system configuration not a bug in dracut, kmod or whatever. Its 
been like that for ages. If something can be done by just changing 
system configuration we shouldn't even consider making patch. Just my 3 
cents.

M.



From glen at pld-linux.org  Tue Apr  1 16:50:26 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Tue, 01 Apr 2014 17:50:26 +0300
Subject: mysql back to readline
Message-ID: <533AD232.1070500@pld-linux.org>

about  mysql >= 5.6.15-63.0.4
http://git.pld-linux.org/?p=packages/mysql.git;a=commitdiff;h=96b6cbc20ef2688e890a57a0c458f6b9a398c033

if you wish to restore spaces in history instead of \040, run this line 
oneliner:

sed -i -e 's#\\040# #g' ~/.mysql_history

-- 
glen



From glen at pld-linux.org  Wed Apr  2 12:06:10 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Wed, 02 Apr 2014 13:06:10 +0300
Subject: qt-examples
Message-ID: <533BE112.8080802@pld-linux.org>

hi

qt(4)-examples to be noarch?
i.e remove binary components from there (.o, .obj)
remove generated Makefile and .prl

there's also compiled programs,
maybe these should go to -examples-progs?

opinions?

-- 
glen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qtdiff.diff.xz
Type: application/x-xz
Size: 5248 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20140402/a83ac4b5/attachment.xz>

From baggins at pld-linux.org  Fri Apr  4 14:45:29 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Fri, 4 Apr 2014 14:45:29 +0200
Subject: qt-examples
In-Reply-To: <533BE112.8080802@pld-linux.org>
References: <533BE112.8080802@pld-linux.org>
Message-ID: <20140404124529.GS29022@sith.mimuw.edu.pl>

On Wed, 02 Apr 2014, Elan Ruusam?e wrote:

> hi
> 
> qt(4)-examples to be noarch?
> i.e remove binary components from there (.o, .obj)
> remove generated Makefile and .prl
> 
> there's also compiled programs,
> maybe these should go to -examples-progs?
> 
> opinions?

Good idea, and, yes if we really want to keep compiled programs
then they should go to separate package.

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


From draenog at pld-linux.org  Sun Apr  6 23:35:21 2014
From: draenog at pld-linux.org (Kacper Kornet)
Date: Sun, 6 Apr 2014 23:35:21 +0200
Subject: [packages/git-core] drop now unccessary
 coreutils,diffutils,findutils requires
In-Reply-To: <7ad420b548cd9104438d74b97aaea673c03a37a8_refs_heads_master@pld-linux.org>
References: <d6fc50d0671819fb9a679781dbf1fd8ac09b6fdf_refs_heads_master@pld-linux.org>
 <7ad420b548cd9104438d74b97aaea673c03a37a8_refs_heads_master@pld-linux.org>
Message-ID: <20140406213521.GA8366@camk.edu.pl>

On Sun, Apr 06, 2014 at 09:38:33PM +0200, glen wrote:
> commit 7ad420b548cd9104438d74b97aaea673c03a37a8
> Author: Elan Ruusam?e <glen at delfi.ee>
> Date:   Sun Apr 6 22:38:02 2014 +0300

>     drop now unccessary coreutils,diffutils,findutils requires

Coreutils is still required. For example git-pull uses printf and in
mksh does not provide it as a builtin command. 

-- 
  Kacper


From glen at pld-linux.org  Fri Apr 11 14:17:36 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Fri, 11 Apr 2014 15:17:36 +0300
Subject: [projects/geninitrd] Handle rootflags= option. Leave support
 for (invalid) rootfsflags= option.
In-Reply-To: <144396dde6b302f400e1c2b9ec3fb30bd680e6a2_refs_heads_master@pld-linux.org>
References: <932f5d44cf6693a04c8a3066919929c739a67a04_refs_heads_master@pld-linux.org>
 <144396dde6b302f400e1c2b9ec3fb30bd680e6a2_refs_heads_master@pld-linux.org>
Message-ID: <5347DD60.9000802@pld-linux.org>

On 11.04.2014 11:00, arekm wrote:
> commit 144396dde6b302f400e1c2b9ec3fb30bd680e6a2
> Author: Arkadiusz Mi?kiewicz <arekm at maven.pl>
> Date:   Fri Apr 11 10:00:37 2014 +0200
>
>      Handle rootflags= option. Leave support for (invalid) rootfsflags= option.

invalid defined by what?

-- 
glen



From arekm at maven.pl  Fri Apr 11 14:24:51 2014
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Fri, 11 Apr 2014 14:24:51 +0200
Subject: [projects/geninitrd] Handle rootflags= option. Leave support for
 (invalid) rootfsflags= option.
In-Reply-To: <5347DD60.9000802@pld-linux.org>
References: <932f5d44cf6693a04c8a3066919929c739a67a04_refs_heads_master@pld-linux.org>
 <144396dde6b302f400e1c2b9ec3fb30bd680e6a2_refs_heads_master@pld-linux.org>
 <5347DD60.9000802@pld-linux.org>
Message-ID: <201404111424.52026.arekm@maven.pl>

On Friday 11 of April 2014, Elan Ruusam?e wrote:
> On 11.04.2014 11:00, arekm wrote:
> > commit 144396dde6b302f400e1c2b9ec3fb30bd680e6a2
> > Author: Arkadiusz Mi?kiewicz <arekm at maven.pl>
> > Date:   Fri Apr 11 10:00:37 2014 +0200
> > 
> >      Handle rootflags= option. Leave support for (invalid) rootfsflags=
> >      option.
> 
> invalid defined by what?

kernel-parameters.txt

-- 
Arkadiusz Mi?kiewicz, arekm / maven.pl


From glen at pld-linux.org  Fri Apr 11 16:18:17 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Fri, 11 Apr 2014 17:18:17 +0300
Subject: [projects/geninitrd] Handle rootflags= option. Leave support
 for (invalid) rootfsflags= option.
In-Reply-To: <201404111424.52026.arekm@maven.pl>
References: <932f5d44cf6693a04c8a3066919929c739a67a04_refs_heads_master@pld-linux.org>
 <144396dde6b302f400e1c2b9ec3fb30bd680e6a2_refs_heads_master@pld-linux.org>
 <5347DD60.9000802@pld-linux.org> <201404111424.52026.arekm@maven.pl>
Message-ID: <5347F9A9.7050209@pld-linux.org>

On 11.04.2014 15:24, Arkadiusz Mi?kiewicz wrote:
> On Friday 11 of April 2014, Elan Ruusam?e wrote:
>> On 11.04.2014 11:00, arekm wrote:
>>> commit 144396dde6b302f400e1c2b9ec3fb30bd680e6a2
>>> Author: Arkadiusz Mi?kiewicz <arekm at maven.pl>
>>> Date:   Fri Apr 11 10:00:37 2014 +0200
>>>
>>>       Handle rootflags= option. Leave support for (invalid) rootfsflags=
>>>       option.
>> invalid defined by what?
> kernel-parameters.txt
>

so are other geninitrd owned parameters, what's the catch?


-- 
glen



From glen at pld-linux.org  Mon Apr 21 10:07:22 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Mon, 21 Apr 2014 11:07:22 +0300
Subject: PHP 5.6.0beta1 released
Message-ID: <5354D1BA.6000203@pld-linux.org>

http://docs.php.net/manual/en/migration56.new-features.php

how you see php future in pld-th?

i see now that we should merge 5.5 -> php, 5.3 -> php53, so we would 
have php52, php53, php (5.2, 5.3, 5.5) versions
and when 5.6 is released, php.spec would be 5.6

the reason for still keeping php name would be that i version control my 
/etc, so php dir rename is annoying as have to manually migrate vcs data 
from one
dir to another to preserve history.

and for most of people who just want to upgrade to "latest" switching 
package names is annoying as you have to install all packages with 
different name and migrate configs

-- 
glen



From glen at pld-linux.org  Mon Apr 21 10:09:33 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Mon, 21 Apr 2014 11:09:33 +0300
Subject: Recommended Ciphersuite
Message-ID: <5354D23D.6070602@pld-linux.org>

https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Ciphersuite

should we update our apache (and other browser) ciphers list based on that?

-- 
glen



From aredridel at nbtsc.org  Mon Apr 21 18:38:17 2014
From: aredridel at nbtsc.org (Aria Stewart)
Date: Mon, 21 Apr 2014 12:38:17 -0400
Subject: PHP 5.6.0beta1 released
In-Reply-To: <5354D1BA.6000203@pld-linux.org>
References: <5354D1BA.6000203@pld-linux.org>
Message-ID: <A67CA5CC-36D3-48BB-9E96-90327E8ABC90@nbtsc.org>


On Apr 21, 02014, at 4:07, Elan Ruusam?e <glen at pld-linux.org> wrote:

> http://docs.php.net/manual/en/migration56.new-features.php
> 
> how you see php future in pld-th?

The package rename is super annoying; and considering that PHP already works so hard on backward compatibility, I?d love to see them all use the same package name.

Perhaps when upgrading we can rope in a php-compat-config, though, to tweak parameters in backward compatible ways. Fresh installs wouldn?t include it? Maybe?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </mailman/pipermail/pld-devel-en/attachments/20140421/1e0a699b/attachment.sig>

From arekm at maven.pl  Mon Apr 21 18:44:51 2014
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Mon, 21 Apr 2014 18:44:51 +0200
Subject: PHP 5.6.0beta1 released
In-Reply-To: <A67CA5CC-36D3-48BB-9E96-90327E8ABC90@nbtsc.org>
References: <5354D1BA.6000203@pld-linux.org>
 <A67CA5CC-36D3-48BB-9E96-90327E8ABC90@nbtsc.org>
Message-ID: <201404211844.51816.arekm@maven.pl>

On Monday 21 of April 2014, Aria Stewart wrote:

> and considering that PHP already
> works so hard on backward compatibility, 

Heh, nice joke. But after >= 5.4 things improved a bit. Still far from 
perfect.

-- 
Arkadiusz Mi?kiewicz, arekm / maven.pl


From aredridel at nbtsc.org  Mon Apr 21 18:51:56 2014
From: aredridel at nbtsc.org (Aria Stewart)
Date: Mon, 21 Apr 2014 12:51:56 -0400
Subject: PHP 5.6.0beta1 released
In-Reply-To: <201404211844.51816.arekm@maven.pl>
References: <5354D1BA.6000203@pld-linux.org>
 <A67CA5CC-36D3-48BB-9E96-90327E8ABC90@nbtsc.org>
 <201404211844.51816.arekm@maven.pl>
Message-ID: <4DE75CC0-EB7A-4422-BE02-C35BDA115BDF@nbtsc.org>


On Apr 21, 02014, at 12:44, Arkadiusz Mi?kiewicz <arekm at maven.pl> wrote:

> On Monday 21 of April 2014, Aria Stewart wrote:
> 
>> and considering that PHP already
>> works so hard on backward compatibility, 
> 
> Heh, nice joke. But after >= 5.4 things improved a bit. Still far from 
> perfect.

Everything that has ever caused me problems is just change in defaults in .ini.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </mailman/pipermail/pld-devel-en/attachments/20140421/0c03d1d8/attachment.sig>

From baggins at pld-linux.org  Tue Apr 22 11:15:03 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 22 Apr 2014 11:15:03 +0200
Subject: PHP 5.6.0beta1 released
In-Reply-To: <5354D1BA.6000203@pld-linux.org>
References: <5354D1BA.6000203@pld-linux.org>
Message-ID: <20140422091503.GB2853@sith.mimuw.edu.pl>

On Mon, 21 Apr 2014, Elan Ruusam?e wrote:

> http://docs.php.net/manual/en/migration56.new-features.php
> 
> how you see php future in pld-th?
> 
> i see now that we should merge 5.5 -> php, 5.3 -> php53, so we would 
> have php52, php53, php (5.2, 5.3, 5.5) versions
> and when 5.6 is released, php.spec would be 5.6
> 
> the reason for still keeping php name would be that i version control my 
> /etc, so php dir rename is annoying as have to manually migrate vcs data 
> from one
> dir to another to preserve history.
> 
> and for most of people who just want to upgrade to "latest" switching 
> package names is annoying as you have to install all packages with 
> different name and migrate configs

Makes sense to me. I'm just not sure if we should still keep 5.2, AFAIK
there are no problems upgrading 5.2 -> 5.3 (no big incompatible changes?).
So I would leave 5.3 and 5.5, and maybe even drop 5.5 when 5.6 comes out.
But I leave the decision to you as I'm not PHP expert.

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


From baggins at pld-linux.org  Tue Apr 22 11:32:01 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 22 Apr 2014 11:32:01 +0200
Subject: Recommended Ciphersuite
In-Reply-To: <5354D23D.6070602@pld-linux.org>
References: <5354D23D.6070602@pld-linux.org>
Message-ID: <20140422093201.GC2853@sith.mimuw.edu.pl>

On Mon, 21 Apr 2014, Elan Ruusam?e wrote:

> https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Ciphersuite
> 
> should we update our apache (and other browser) ciphers list based on that?

Our current ciphers list is:

ALL:!ADH:!EXP:!LOW:!SSLv2:RC4+RSA:+HIGH:+MEDIUM

instead of putting there random list of ciphers we can achieve the same
effect just by disabling the weak ones, like this:

ALL:!ADH:!EXPORT!LOW:!SSLv2:!DES:!3DES:!aNULL:!eNULL:!MD5:!PSK:!SEED:+HIGH:+MEDIUM

Looks better IMO.

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


From glen at pld-linux.org  Tue Apr 22 14:34:12 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Tue, 22 Apr 2014 15:34:12 +0300
Subject: PHP 5.6.0beta1 released
In-Reply-To: <20140422091503.GB2853@sith.mimuw.edu.pl>
References: <5354D1BA.6000203@pld-linux.org>
 <20140422091503.GB2853@sith.mimuw.edu.pl>
Message-ID: <535661C4.8030906@pld-linux.org>

On 22.04.2014 12:15, Jan R?korajski wrote:
> Makes sense to me. I'm just not sure if we should still keep 5.2, AFAIK
> there are no problems upgrading 5.2 -> 5.3 (no big incompatible changes?).
imho 5.2 -> 5.3 are BIG changes, some code just breaks with fatal error
5.3 -> 5.4 are removed features
5.4 -> 5.5 no removed features
5.6 -> some deprecated features
> So I would leave 5.3 and 5.5, and maybe even drop 5.5 when 5.6 comes out.
> But I leave the decision to you as I'm not PHP expert.
but you're fine with naming convention?

php.spec = 5.5
php53.spec = 5.3
php52.psec = 5.2

i.e: switch "main" php to 5.5 now and keep 5.3 in php53 packages for 
some time

-- 
glen



From baggins at pld-linux.org  Tue Apr 22 14:36:54 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 22 Apr 2014 14:36:54 +0200
Subject: PHP 5.6.0beta1 released
In-Reply-To: <535661C4.8030906@pld-linux.org>
References: <5354D1BA.6000203@pld-linux.org>
 <20140422091503.GB2853@sith.mimuw.edu.pl>
 <535661C4.8030906@pld-linux.org>
Message-ID: <20140422123654.GD2853@sith.mimuw.edu.pl>

On Tue, 22 Apr 2014, Elan Ruusam?e wrote:

> On 22.04.2014 12:15, Jan R?korajski wrote:
> > Makes sense to me. I'm just not sure if we should still keep 5.2, AFAIK
> > there are no problems upgrading 5.2 -> 5.3 (no big incompatible changes?).
> imho 5.2 -> 5.3 are BIG changes, some code just breaks with fatal error

OK, maybe I was lucky ;)

> 5.3 -> 5.4 are removed features
> 5.4 -> 5.5 no removed features
> 5.6 -> some deprecated features
> > So I would leave 5.3 and 5.5, and maybe even drop 5.5 when 5.6 comes out.
> > But I leave the decision to you as I'm not PHP expert.
> but you're fine with naming convention?
> 
> php.spec = 5.5
> php53.spec = 5.3
> php52.psec = 5.2
> 
> i.e: switch "main" php to 5.5 now and keep 5.3 in php53 packages for 
> some time

Yeah, I'm fine with the naming.

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


From draenog at pld-linux.org  Tue Apr 22 17:25:06 2014
From: draenog at pld-linux.org (Kacper Kornet)
Date: Tue, 22 Apr 2014 17:25:06 +0200
Subject: PHP 5.6.0beta1 released
In-Reply-To: <5354D1BA.6000203@pld-linux.org>
References: <5354D1BA.6000203@pld-linux.org>
Message-ID: <20140422152506.GB3707@camk.edu.pl>

On Mon, Apr 21, 2014 at 11:07:22AM +0300, Elan Ruusam?e wrote:
> http://docs.php.net/manual/en/migration56.new-features.php

> how you see php future in pld-th?

> i see now that we should merge 5.5 -> php, 5.3 -> php53, so we would
> have php52, php53, php (5.2, 5.3, 5.5) versions
> and when 5.6 is released, php.spec would be 5.6

Another question is about the layout of branches in our git repo. My
suggestion is:

1) Branch PHP_5_3 is created that points to current master

2) Branch master is removed

3) On git.pld-linux HEAD in php is set to point to PHP_5_5 - this way
   fresh clones of php will checkout PHP_5_5

4) In future new branch PHP_5_6 will be forked from PHP_5_5 

Alternatively:

2') Branch master is reset to point to current PHP_5_5

3') Branch PHP_5_5 is removed

4') In future PHP_5_5 will be forked again from then current master and
    master will become PHP_5_6

-- 
  Kacper


From adwol at zonk.pl  Wed Apr 23 22:33:07 2014
From: adwol at zonk.pl (Adam Osuchowski)
Date: Wed, 23 Apr 2014 22:33:07 +0200
Subject: Recommended Ciphersuite
In-Reply-To: <20140422093201.GC2853@sith.mimuw.edu.pl>
References: <5354D23D.6070602@pld-linux.org>
 <20140422093201.GC2853@sith.mimuw.edu.pl>
Message-ID: <20140423203307.6b8b4567@zonk.pl>

Jan R?korajski wrote:
> Our current ciphers list is:
> 
> ALL:!ADH:!EXP:!LOW:!SSLv2:RC4+RSA:+HIGH:+MEDIUM
> 
> instead of putting there random list of ciphers we can achieve the same
> effect just by disabling the weak ones, like this:
> 
> ALL:!ADH:!EXPORT!LOW:!SSLv2:!DES:!3DES:!aNULL:!eNULL:!MD5:!PSK:!SEED:+HIGH:+MEDIUM
> 
> Looks better IMO.

Maybe looks better but that Mozilla ciphersuites list fixes specific order
of prioritization. Better ciphers (in their opinion) are scored higher
(e.g. AES128 is preferred to AES256), whereas your general ciphers
specification string fixes only set of ciphers and leaves detailed
ordering decision to SSL/TLS software (mainly openssl library).

Try to diff outputs of `openssl ciphers -v' for Mozilla developed string
and this general one. Order will be definitely different. So, they are
not identical, what does not mean that any of them is better at all.


From ed at yen.ipipan.waw.pl  Thu Apr 24 22:19:34 2014
From: ed at yen.ipipan.waw.pl (=?utf-8?B?xYF1a2FzeiBNYcWba28=?=)
Date: Thu, 24 Apr 2014 22:19:34 +0200
Subject: Problem with latest chromium-browser-34.0.1847.116-1.i686
Message-ID: <4581258.PeMFaSSGuJ@laptok>

$ strace -f chromium-browser
stat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/home/users", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/home/users/ed", {st_mode=S_IFDIR|0700, st_size=12288, ...}) = 0
stat64("/home/users/ed/.pki", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
stat64("/home/users/ed/.pki/nssdb", {st_mode=S_IFDIR|0700, st_size=4096, ...}) 
= 0
statfs64("/home/users/ed/.pki/nssdb", 84, {f_type="EXT2_SUPER_MAGIC", 
f_bsize=4096, f_blocks=7774625, f_bfree=2409788, f_bavail=2013184, 
f_files=3973536, f_ffree=3893093, f_fsid={1644750531, 229891316}, 
f_namelen=255, f_frsize=4096, f_flags=1056}) = 0
readlink("/proc/self/exe", "/usr/lib/chromium-browser/chromi"..., 4096) = 42
open("/usr/lib/chromium-browser/icudtl.dat", O_RDONLY|O_LARGEFILE) = -1 ENOENT 
(No such file or directory)
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(31685, 31685, SIGABRT)           = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=31685, si_uid=500} ---
+++ killed by SIGABRT (core dumped) +++
Przerwane (zrzut pami?ci)

There is no such file as /usr/lib/chromium-browser/icudtl.dat
-- 
?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 draenog at pld-linux.org  Fri Apr 25 20:33:24 2014
From: draenog at pld-linux.org (Kacper Kornet)
Date: Fri, 25 Apr 2014 20:33:24 +0200
Subject: Reset of master branch in php
Message-ID: <20140425183324.GA2828@camk.edu.pl>

The master branch in php package has been reset to point to the PHP_5_5.
The old master is now called PHP_5_3. Therefore please be careful with
the pulls in this packages. Probably the best idead is to perform 
git-fetch and then reset your master branch by git-reset to
origin/master.

-- 
  Kacper


From glen at pld-linux.org  Sat Apr 26 10:46:40 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Sat, 26 Apr 2014 11:46:40 +0300
Subject: xfs: structure needs cleaning
Message-ID: <535B7270.6040305@pld-linux.org>

seems we are still vulnreable to that bug

http://xfs.org/index.php/XFS_FAQ#Q:_I.27m_getting_.22Internal_error_xfs_sb_read_verify.22_errors_when_I_try_to_run_xfs_growfs_under_kernels_v3.10_through_v3.12


# lvextend --size=+10G /dev/blodnatt/home
   Extending logical volume home to 62.00 GiB
   Logical volume home successfully resized

# xfs_growfs ~
meta-data=/dev/mapper/blodnatt-home isize=256    agcount=11, 
agsize=1310720 blks
          =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=13631488, imaxpct=25
          =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=2560, version=2
          =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0
xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Structure needs cleaning
data blocks changed from 13631488 to 16252928

# df ~
Filesystem                Type  Size  Used Avail Use% Mounted on
/dev/mapper/blodnatt-home xfs    62G   52G   11G  84% /home

# uname -r
3.10.28-1

# poldek --up -u xfsprogs
xfsprogs-3.1.11-4.x86_64: equal version installed, skipped


-- 
glen



From arekm at maven.pl  Sat Apr 26 10:54:26 2014
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Sat, 26 Apr 2014 10:54:26 +0200
Subject: xfs: structure needs cleaning
In-Reply-To: <535B7270.6040305@pld-linux.org>
References: <535B7270.6040305@pld-linux.org>
Message-ID: <201404261054.27068.arekm@maven.pl>

On Saturday 26 of April 2014, Elan Ruusam?e wrote:
> seems we are still vulnreable to that bug
> 
> http://xfs.org/index.php/XFS_FAQ#Q:_I.27m_getting_.22Internal_error_xfs_sb_
> read_verify.22_errors_when_I_try_to_run_xfs_growfs_under_kernels_v3.10_thro
> ugh_v3.12\


> # xfs_growfs ~
[...]

> xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Structure needs cleaning
> data blocks changed from 13631488 to 16252928

Our xfs_repair will fix it. kernels don't have patches backported.

-- 
Arkadiusz Mi?kiewicz, arekm / maven.pl


From glen at pld-linux.org  Sat Apr 26 11:56:39 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Sat, 26 Apr 2014 12:56:39 +0300
Subject: xfs: structure needs cleaning
In-Reply-To: <201404261054.27068.arekm@maven.pl>
References: <535B7270.6040305@pld-linux.org>
 <201404261054.27068.arekm@maven.pl>
Message-ID: <535B82D7.8010608@pld-linux.org>

On 26.04.2014 11:54, Arkadiusz Mi?kiewicz wrote:
> On Saturday 26 of April 2014, Elan Ruusam?e wrote:
>> seems we are still vulnreable to that bug
>>
>> http://xfs.org/index.php/XFS_FAQ#Q:_I.27m_getting_.22Internal_error_xfs_sb_
>> read_verify.22_errors_when_I_try_to_run_xfs_growfs_under_kernels_v3.10_thro
>> ugh_v3.12\
>
>> # xfs_growfs ~
> [...]
>
>> xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Structure needs cleaning
>> data blocks changed from 13631488 to 16252928
> Our xfs_repair will fix it. kernels don't have patches backported.
>
have you actually tested it?

i'm currently in no mood running xfs repair on that partition :)

-- 
glen



From arekm at maven.pl  Sat Apr 26 12:03:37 2014
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Sat, 26 Apr 2014 12:03:37 +0200
Subject: xfs: structure needs cleaning
In-Reply-To: <535B82D7.8010608@pld-linux.org>
References: <535B7270.6040305@pld-linux.org>
 <201404261054.27068.arekm@maven.pl> <535B82D7.8010608@pld-linux.org>
Message-ID: <201404261203.37602.arekm@maven.pl>

On Saturday 26 of April 2014, Elan Ruusam?e wrote:
> On 26.04.2014 11:54, Arkadiusz Mi?kiewicz wrote:
> > On Saturday 26 of April 2014, Elan Ruusam?e wrote:
> >> seems we are still vulnreable to that bug
> >> 
> >> http://xfs.org/index.php/XFS_FAQ#Q:_I.27m_getting_.22Internal_error_xfs_
> >> sb_
> >> read_verify.22_errors_when_I_try_to_run_xfs_growfs_under_kernels_v3.10_
> >> thro ugh_v3.12\
> >> 
> >> # xfs_growfs ~
> > 
> > [...]
> > 
> >> xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Structure needs cleaning
> >> data blocks changed from 13631488 to 16252928
> > 
> > Our xfs_repair will fix it. kernels don't have patches backported.
> 
> have you actually tested it?
> 
> i'm currently in no mood running xfs repair on that partition :)

No since I never had this problem. I've backported the patch that upstream 
mentioned for xfs_repair.


-- 
Arkadiusz Mi?kiewicz, arekm / maven.pl


From glen at delfi.ee  Tue Apr 29 08:18:28 2014
From: glen at delfi.ee (=?ISO-8859-2?Q?Elan_Ruusam=E4e?=)
Date: Tue, 29 Apr 2014 09:18:28 +0300
Subject: Problem with latest chromium-browser-34.0.1847.116-1.i686
In-Reply-To: <4581258.PeMFaSSGuJ@laptok>
References: <4581258.PeMFaSSGuJ@laptok>
Message-ID: <535F4434.3050406@delfi.ee>

On 24.04.2014 23:19, ?ukasz Ma?ko wrote:
> There is no such file as /usr/lib/chromium-browser/icudtl.dat
this is fixed now in chromium-browser-34.0.1847.132

and it worked fine, until today i noticed it segfaults on startup:

$ chromium-browser
Segmentation fault (core dumped)

[115269.823022] Chrome_IOThread[17739]: segfault at 0 ip 
00007f89b248d333 sp 00007f899ad760d0 error 4 in 
libstdc++.so.6.0.19[7f89b2430000+e6000]

main window appears, and then boom!

haven't tested yet with clean profile

-- 
glen



From glen at delfi.ee  Tue Apr 29 08:15:16 2014
From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Tue, 29 Apr 2014 09:15:16 +0300
Subject: PHP 5.5 coming to Th
Message-ID: <535F4374.6040703@delfi.ee>

PHP 5.5 is coming to be main php version updating current main PHP 5.3

there will be php53 and php52 packages for old php versions.
if you need pecl version for php53 extension, then speak up

if you were already using php55 packages, you need to install main php 
version again, manually (don't forget to migrate configs from /etc/php55 
to /etc/php), there will be no "obsoletes" in php-5.5 packages so this 
upgrade won't be done automatically and break your system.

additionally, the following extensions will be dropped, unless somebody 
fixes them,
there's no upstream new version and unlikely then somebody to use them 
in real world

for apc, there's new opcache supported by upstream: php-opcache package, 
formerly ZendOptimizer
if you need acp_store/fetch methods, then for that there's new extension 
apcu (php-pecl-apcu)

  * php-bytekit-0.1.1-2.src.rpm (php-bytekit.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-bytekit.git;f=php-bytekit.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-bytekit&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-bytekit&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-bytekit&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * cups-filters-1.0.47-1.src.rpm (cups-filters.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/cups-filters.git;f=cups-filters.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=cups-filters&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=cups-filters&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=cups-filters&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-dbus-0.1.2-1.src.rpm (php-dbus.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-dbus.git;f=php-dbus.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-dbus&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-dbus&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-dbus&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-eaccelerator-0.9.6.1-29.src.rpm (php-eaccelerator.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-eaccelerator.git;f=php-eaccelerator.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-eaccelerator&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-eaccelerator&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-eaccelerator&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * gdal-1.10.1-5.src.rpm (gdal.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/gdal.git;f=gdal.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_DEPS_INSTALL*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=gdal&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_DEPS_INSTALL*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=gdal&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_DEPS_INSTALL*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=gdal&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-gtk2-2.0.2-6.src.rpm (php-gtk2.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-gtk2.git;f=php-gtk2.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-gtk2&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-gtk2&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-gtk2&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * ice-3.4.2-6.src.rpm (ice.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/ice.git;f=ice.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=ice&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=ice&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=ice&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * libkolab-0.5.0-1.src.rpm (libkolab.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/libkolab.git;f=libkolab.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_FILES*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=libkolab&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:OK*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=1&name=libkolab&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:OK*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=1&name=libkolab&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-pecl-APC-3.1.13-3.src.rpm (php-pecl-APC.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-pecl-APC.git;f=php-pecl-APC.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-pecl-APC&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-pecl-APC&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-pecl-APC&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-pecl-adodb-5.0.4-4.src.rpm (php-pecl-adodb.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-pecl-adodb.git;f=php-pecl-adodb.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-pecl-adodb&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-pecl-adodb&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-pecl-adodb&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-pecl-archive-0.2-16.src.rpm (php-pecl-archive.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-pecl-archive.git;f=php-pecl-archive.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-pecl-archive&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-pecl-archive&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-pecl-archive&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-pecl-bcompiler-1.0.2-4.src.rpm (php-pecl-bcompiler.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-pecl-bcompiler.git;f=php-pecl-bcompiler.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-pecl-bcompiler&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-pecl-bcompiler&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-pecl-bcompiler&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-pecl-crack-0.4-8.src.rpm (php-pecl-crack.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-pecl-crack.git;f=php-pecl-crack.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-pecl-crack&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-pecl-crack&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-pecl-crack&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-pecl-funcall-0.3.0-0.alpha.2.src.rpm (php-pecl-funcall.spec -r
    HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-pecl-funcall.git;f=php-pecl-funcall.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-pecl-funcall&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-pecl-funcall&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-pecl-funcall&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-pecl-mdbtools-1.0.0-11.src.rpm (php-pecl-mdbtools.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-pecl-mdbtools.git;f=php-pecl-mdbtools.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-pecl-mdbtools&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-pecl-mdbtools&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-pecl-mdbtools&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-pecl-memtrack-0.2.1-4.src.rpm (php-pecl-memtrack.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-pecl-memtrack.git;f=php-pecl-memtrack.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-pecl-memtrack&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-pecl-memtrack&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-pecl-memtrack&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-pecl-mnogosearch-1.0.0-6.src.rpm (php-pecl-mnogosearch.spec -r
    HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-pecl-mnogosearch.git;f=php-pecl-mnogosearch.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-pecl-mnogosearch&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-pecl-mnogosearch&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-pecl-mnogosearch&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-pecl-paradox-1.4.3-6.src.rpm (php-pecl-paradox.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-pecl-paradox.git;f=php-pecl-paradox.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-pecl-paradox&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-pecl-paradox&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-pecl-paradox&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-pecl-parsekit-1.3.0-6.src.rpm (php-pecl-parsekit.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-pecl-parsekit.git;f=php-pecl-parsekit.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-pecl-parsekit&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-pecl-parsekit&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-pecl-parsekit&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-pecl-pdflib-2.1.9-3.src.rpm (php-pecl-pdflib.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-pecl-pdflib.git;f=php-pecl-pdflib.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-pecl-pdflib&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-pecl-pdflib&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-pecl-pdflib&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-pecl-sasl-0.1.0-13.src.rpm (php-pecl-sasl.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-pecl-sasl.git;f=php-pecl-sasl.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-pecl-sasl&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-pecl-sasl&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-pecl-sasl&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-pecl-session_mysql-1.10-9.src.rpm (php-pecl-session_mysql.spec
    -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-pecl-session_mysql.git;f=php-pecl-session_mysql.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-pecl-session_mysql&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-pecl-session_mysql&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-pecl-session_mysql&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-pecl-tcpwrap-1.1.3-6.src.rpm (php-pecl-tcpwrap.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-pecl-tcpwrap.git;f=php-pecl-tcpwrap.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-pecl-tcpwrap&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-pecl-tcpwrap&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-pecl-tcpwrap&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-redis-2.1.3-4.src.rpm (php-redis.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-redis.git;f=php-redis.spec;h=HEAD;a=shortlog>)[*th-x86_64:OK*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=1&name=php-redis&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-redis&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-redis&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * php-rrdtool-1.2-7.src.rpm (php-rrdtool.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/php-rrdtool.git;f=php-rrdtool.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=php-rrdtool&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=php-rrdtool&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=php-rrdtool&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]
  * ossp-uuid-1.6.2-15.src.rpm (ossp-uuid.spec -r HEAD
    <http://git.pld-linux.org/gitweb.cgi?p=packages/ossp-uuid.git;f=ossp-uuid.spec;h=HEAD;a=shortlog>)[*th-x86_64:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&name=ossp-uuid&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i486:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i486&ok=0&name=ossp-uuid&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>*th-i686:FAIL_BUILD*
    <http://buildlogs.pld-linux.org//index.php?dist=th&arch=i686&ok=0&name=ossp-uuid&id=a370d466-09aa-42f8-9483-2b4804246e9b&action=tail>]


ps: reply to pld-devel-en at lists.pld-linux.org

-- 
glen



From arekm at maven.pl  Tue Apr 29 08:30:48 2014
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Tue, 29 Apr 2014 08:30:48 +0200
Subject: PHP 5.5 coming to Th
In-Reply-To: <535F4374.6040703@delfi.ee>
References: <535F4374.6040703@delfi.ee>
Message-ID: <201404290830.49005.arekm@maven.pl>

On Tuesday 29 of April 2014, Elan Ruusam?e wrote:
> PHP 5.5 is coming to be main php version updating current main PHP 5.3
> 
> there will be php53 and php52 packages for old php versions.
> if you need pecl version for php53 extension, then speak up

For me only these:

php-pecl-memcache-3.0.6-7.x86_64
php-pecl-imagick-3.0.1-4.x86_64

> if you were already using php55 packages, you need to install main php
> version again, manually (don't forget to migrate configs from /etc/php55
> to /etc/php), there will be no "obsoletes" in php-5.5 packages so this
> upgrade won't be done automatically and break your system.

That sucks as hell, especially php 5.6 is right around the corner. Leave 5.5 
as is (php55-5.5.x) and wait for 5.6? 

-- 
Arkadiusz Mi?kiewicz, arekm / maven.pl


From glen at delfi.ee  Tue Apr 29 08:46:55 2014
From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Tue, 29 Apr 2014 09:46:55 +0300
Subject: PHP 5.5 coming to Th
In-Reply-To: <201404290830.49005.arekm@maven.pl>
References: <535F4374.6040703@delfi.ee> <201404290830.49005.arekm@maven.pl>
Message-ID: <535F4ADF.9060300@delfi.ee>

On 29.04.2014 09:30, Arkadiusz Mi?kiewicz wrote:
>> if you were already using php55 packages, you need to install main php
>> >version again, manually (don't forget to migrate configs from /etc/php55
>> >to /etc/php), there will be no "obsoletes" in php-5.5 packages so this
>> >upgrade won't be done automatically and break your system.
> That sucks as hell, especially php 5.6 is right around the corner. Leave 5.5
> as is (php55-5.5.x) and wait for 5.6?
yes, you can just do nothing,  right until you need to install new 
extension, or some SONAME rebuild happens.

were you really using php55 packages in production?

-- 
glen



From arekm at maven.pl  Tue Apr 29 08:49:51 2014
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Tue, 29 Apr 2014 08:49:51 +0200
Subject: PHP 5.5 coming to Th
In-Reply-To: <535F4ADF.9060300@delfi.ee>
References: <535F4374.6040703@delfi.ee> <201404290830.49005.arekm@maven.pl>
 <535F4ADF.9060300@delfi.ee>
Message-ID: <201404290849.51451.arekm@maven.pl>

On Tuesday 29 of April 2014, Elan Ruusam?e wrote:

> were you really using php55 packages in production?

I'm using php55- packages on new servers.

-- 
Arkadiusz Mi?kiewicz, arekm / maven.pl