From baggins at pld-linux.org  Fri May  2 11:13:40 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Fri, 2 May 2014 11:13:40 +0200
Subject: PHP 5.5 coming to Th
In-Reply-To: <535F4374.6040703@delfi.ee>
References: <535F4374.6040703@delfi.ee>
Message-ID: <20140502091340.GA1330@home.lan>

On Tue, 29 Apr 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

I need all of them rebuilt as php53-* for consistency (with proper
Obsoletes).

> 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.

IOW you've some problem to make a trigger that moves configuration to new
place? It really isn't that hard, see mailman.spec as an example.
Also what about obsoletes and update path for php-5.3 -> php53 packages?
Manual too? 

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


From glen at delfi.ee  Fri May  2 14:41:13 2014
From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Fri, 02 May 2014 15:41:13 +0300
Subject: PHP 5.5 coming to Th
In-Reply-To: <20140502091340.GA1330@home.lan>
References: <535F4374.6040703@delfi.ee> <20140502091340.GA1330@home.lan>
Message-ID: <53639269.2000005@delfi.ee>

On 02.05.2014 12:13, Jan R?korajski wrote:
> I need all of them rebuilt as php53-* for consistency (with proper
> Obsoletes).
are you sure this isn't the time to drop outdated cruft, like pecl 
extensions that aren't maintained for past 6-7 years?

-- 
glen



From baggins at pld-linux.org  Sun May  4 10:48:57 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sun, 4 May 2014 10:48:57 +0200
Subject: PHP 5.5 coming to Th
In-Reply-To: <53639269.2000005@delfi.ee>
References: <535F4374.6040703@delfi.ee> <20140502091340.GA1330@home.lan>
 <53639269.2000005@delfi.ee>
Message-ID: <20140504084857.GC1404@home.lan>

On Fri, 02 May 2014, Elan Ruusam?e wrote:

> On 02.05.2014 12:13, Jan R?korajski wrote:
> > I need all of them rebuilt as php53-* for consistency (with proper
> > Obsoletes).
> are you sure this isn't the time to drop outdated cruft, like pecl 
> extensions that aren't maintained for past 6-7 years?

Well, I'm not talking about current version, but of providing those as
they were for 5.3. Of course if there are problems building them
I won't be insisting.

And what about upgrade triggers?

-- 
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  Mon May  5 14:24:53 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Mon, 05 May 2014 15:24:53 +0300
Subject: /etc/cron.d to filesystem
Message-ID: <53678315.2080902@pld-linux.org>

rfc: move /etc/cron.d to filesystem package

rationale: simplify packaging where cron dependency could be optional

sample:
15:23:29 root[load: 0.00]@pld64 /vagrant# poldek -u util-vserver
Loading [pndir]okas...
Loading [pndir]th...
Loading [pndir]th...
22395 packages read
Processing dependencies...
util-vserver-0.30.216-1.pre3054.5.x86_64: required "/etc/cron.d" is 
provided by the following packages:
a) cronie-1.4.11-3.x86_64
b) fcron-3.1.2-2.x86_64
c) hc-cron-0.14-27.x86_64
Which one do you want to install ('Q' to abort)? [cronie-1.4.11-3.x86_64]

-- 
glen



From jajcus at jajcus.net  Mon May  5 15:21:38 2014
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Mon, 05 May 2014 15:21:38 +0200
Subject: /etc/cron.d to filesystem
In-Reply-To: <53678315.2080902@pld-linux.org>
References: <53678315.2080902@pld-linux.org>
Message-ID: <53679062.5000301@jajcus.net>

On 05/05/14 14:24, Elan Ruusam?e wrote:
> rfc: move /etc/cron.d to filesystem package

+1

Greets,
Jacek



From glen at pld-linux.org  Thu May  8 09:47:25 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Thu, 08 May 2014 10:47:25 +0300
Subject: [packages/ejabberd] - rel 3; run all command via daemon(), so
 limits gets applied correctly and we don't hit: File opera
In-Reply-To: <a778ff6ace9bd8175c2f263817492b937b2f63b9_refs_heads_master@pld-linux.org>
References: <f9539811d7bf79576970287e10c1cfc2bf34e7a8_refs_heads_master@pld-linux.org>
 <a778ff6ace9bd8175c2f263817492b937b2f63b9_refs_heads_master@pld-linux.org>
Message-ID: <536B368D.4080202@pld-linux.org>

On 07.05.2014 00:27, arekm wrote:
>   stop() {
>   	# Stop daemons.
>   	if [ -f /var/lock/subsys/ejabberd ]; then
> -		msg_stopping ejabberd ; busy
> -		/usr/sbin/ejabberdctl stop 2>/dev/null
> +		msg_stopping ejabberd
> +		daemon /usr/sbin/ejabberdctl stop
>   		RETVAL=$?
no, no... no!

daemon() is for starting processes
you can't use daemon() to stop processes, as it's internal logic expects 
process to START, but if your action STOPS the action will fail. i.e its 
checking for pid file to appear and proper pid written there.

if you need to exec stuff like daemon() does, use `run_command "title" 
command args` instead

# Usage:
# run_cmd Message command_to_run
# run_cmd -a Message command_to_run
# run_cmd --user "username" "Message" command_to_run

note: don't use anything complex there (create separate wrapper if need 
complex args), as quoting depends whether $RC_LOGGING is ON or OFF.

-- 
glen



From arekm at maven.pl  Thu May  8 09:57:02 2014
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Thu, 8 May 2014 09:57:02 +0200
Subject: [packages/ejabberd] - rel 3;
 run all command via daemon(), so limits gets applied correctly and we
 don't hit: File opera
In-Reply-To: <536B368D.4080202@pld-linux.org>
References: <f9539811d7bf79576970287e10c1cfc2bf34e7a8_refs_heads_master@pld-linux.org>
 <a778ff6ace9bd8175c2f263817492b937b2f63b9_refs_heads_master@pld-linux.org>
 <536B368D.4080202@pld-linux.org>
Message-ID: <201405080957.02393.arekm@maven.pl>

On Thursday 08 of May 2014, Elan Ruusam?e wrote:
> On 07.05.2014 00:27, arekm wrote:
> >   stop() {
> >   
> >   	# Stop daemons.
> >   	if [ -f /var/lock/subsys/ejabberd ]; then
> > 
> > -		msg_stopping ejabberd ; busy
> > -		/usr/sbin/ejabberdctl stop 2>/dev/null
> > +		msg_stopping ejabberd
> > +		daemon /usr/sbin/ejabberdctl stop
> > 
> >   		RETVAL=$?
> 
> no, no... no!

Should be better now.

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


From draenog at pld-linux.org  Mon May 12 18:29:51 2014
From: draenog at pld-linux.org (Kacper Kornet)
Date: Mon, 12 May 2014 18:29:51 +0200
Subject: Rewound master in packages/dracut
Message-ID: <20140512162951.GA12296@camk.edu.pl>


Three unintentional commits has been removed from master in packages/dracut. So if
your master contains any of

d8f52b27f0fd6a7f54bec4b16a07535296f95fc9
a719eeb6fc868046af63ad199b918499c9220b1b
8343b8012bcd48d216804d90fcdf181663671ad9

please be careful with git pull and push.

-- 
  Kacper


From lukasz.krotowski at gmail.com  Tue May 13 01:33:11 2014
From: lukasz.krotowski at gmail.com (=?UTF-8?Q?=C5=81ukasz_Krotowski?=)
Date: Tue, 13 May 2014 01:33:11 +0200
Subject: Kernel panic with geninitrd and root=/dev/vgname/lvname
Message-ID: <CAEwbCw2HAC+ueBuycC_1fH+P3KQJ993ZMj3HAMCGDdAHWXESyQ@mail.gmail.com>

Hi,
our geninitrd in function initrd_gen_setrootdev() tries to fill
/proc/sys/kernel/real-root-dev based on /proc/partitions. But, when
booted with root=/dev/vgname/lvname:
- /proc/sys/kernel/real-root-dev is already filled with proper number
by initrd_gen_lvm(),
- /proc/partitions contains dm-X not vgname/lvname hence root device
is not found. And that causes panic.

My local fix is:
+ if [ "$(busybox cat /proc/sys/kernel/real-root-dev)" -eq 0 -a
"${ROOT##/dev/}" != "${ROOT}" ]; then
- if [ "${ROOT##/dev/}" != "${ROOT}" ]; then

Since I don't know how to change geninitrd I'm signaling this issue
here. FWIW I use geninitrd with --initrdfs=rom.
Cheers,
?ukasz


From baggins at pld-linux.org  Tue May 13 11:02:19 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 13 May 2014 11:02:19 +0200
Subject: /etc/cron.d to filesystem
In-Reply-To: <53678315.2080902@pld-linux.org>
References: <53678315.2080902@pld-linux.org>
Message-ID: <20140513090219.GC2180@home.lan>

On Mon, 05 May 2014, Elan Ruusam?e wrote:

> rfc: move /etc/cron.d to filesystem package
> 
> rationale: simplify packaging where cron dependency could be optional

If you first add appropriate R/S to all packages that (may) need cron.
The problem is a lot of packages that need cron have only indirect dep
via this dir AFAIR.

-- 
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 May 13 12:07:09 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 13 May 2014 12:07:09 +0200
Subject: (fwd) pld-linux Domains Registration
Message-ID: <20140513100709.GE2180@home.lan>

Do we care? Looks a bit fishy...

Irrelevant Received lines removed.
----- Forwarded message from Daniel <daniel at dy-web.org.cn> -----

Return-Path: <daniel at dy-web.org.cn>
[...]
X-Virus-Scanned: amavisd-new at mimuw.edu.pl
X-Spam-Flag: NO
X-Spam-Score: 2.421
X-Spam-Level: **
X-Spam-Status: No, score=2.421 tagged_above=2 required=5.1
	tests=[BAYES_00=-0.9, DEAR_SOMETHING=1.973, HTML_MESSAGE=0.001,
	RCVD_IN_BL_SPAMCOP_NET=1.347] autolearn=no
[...]
Received: by b.mx.pld-linux.org (Postfix)
	id 0CA341426B; Tue, 13 May 2014 11:51:39 +0200 (CEST)
Delivered-To: baggins at pld-linux.org
X-policyd-weight: passed - too many local DNS-errors in list.dsbl.org lookups
Received: from mx68.dns.com.cn (mx68.dns.com.cn [211.100.23.133])
	by b.mx.pld-linux.org (Postfix) with SMTP id 3EEE11425F
	for <baggins at pld-linux.org>; Tue, 13 May 2014 11:51:00 +0200 (CEST)
Received: (qmail 92277 invoked by uid 88); 13 May 2014 09:50:57 -0000
X-DNS-MID: mx68.dns.com.cn/1399974657/75/825475
X-DNS-FLAG: --SM--
Received: from unknown (HELO danielpc) (117.64.43.168)
	by mx68.dns.com.cn with SMTP; 13 May 2014 09:50:57 -0000
From: Daniel <daniel at dy-web.org.cn>
To: patrys <patrys at pld-linux.org>
Subject: pld-linux Domains Registration
Date: Tue, 13 May 2014 17:50:57 +0800
Message-Id: <DM__140513135112_55210761353 at smtp.dy-web.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_14051313515021000431425_002"
X-Priority: 1
X-Mailer: DreamMail 4.6.9.2

Dear Sir,
We are the department of Asian Domain Registration Service in China. I have something to confirm with you. We formally received an application on May 13, 2014 that a company which self-styled "Dun & Cand Co". were applying to register "pld-linux" as their Brand Name and Asian countries top-level domain names. through our firm.
Now we are handling this registration, and after our initial checking, we found the name were similar to your company's, so we need to check with you whether your company has authorized that company to register these names. so that we will handle this issue better. 
Thanks and Best Regards,

Daniel Yang || - Registration Dept. 
Tel:0086-551-6343-4624 || Fax:0086-551-6343-4924
Mail: daniel(at)dy-web(dot)org(dot)cn || Website: http://www(dot)dy-web(dot)org/ 

----- End forwarded message -----

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


From hawk at pld-linux.org  Tue May 13 13:26:31 2014
From: hawk at pld-linux.org (Marcin Krol)
Date: Tue, 13 May 2014 13:26:31 +0200
Subject: (fwd) pld-linux Domains Registration
In-Reply-To: <20140513100709.GE2180@home.lan>
References: <20140513100709.GE2180@home.lan>
Message-ID: <53720167.9090708@pld-linux.org>

> Do we care? Looks a bit fishy...

Common DNS related spam. I personally ignore these.

M.


From glen at pld-linux.org  Tue May 13 16:42:28 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Tue, 13 May 2014 17:42:28 +0300
Subject: [packages/openssh] add limits.h hack for ac in openbsd-compat
In-Reply-To: <621739ab2a22c5136a198a0a5e2dada6391f137f_refs_heads_master@pld-linux.org>
References: <a46537e77b7bf4bc5bb87d8e4123cab18fb33687_refs_heads_master@pld-linux.org>
 <621739ab2a22c5136a198a0a5e2dada6391f137f_refs_heads_master@pld-linux.org>
Message-ID: <53722F54.10004@pld-linux.org>

i would appreciate if somebody can do cleaner fix for this hack

On 13.05.2014 17:40, glen wrote:
> commit 621739ab2a22c5136a198a0a5e2dada6391f137f
> Author: Elan Ruusam?e <glen at delfi.ee>
> Date:   Tue May 13 17:39:52 2014 +0300
>
>      add limits.h hack for ac in openbsd-compat
>
>   limits.h.patch | 28 ++++++++++++++++++++++++++++
>   openssh.spec   |  2 ++
>   2 files changed, 30 insertions(+)
> ---
> diff --git a/openssh.spec b/openssh.spec
> index ac6ed1c..d1357c9 100644
> --- a/openssh.spec
> +++ b/openssh.spec
> @@ -67,6 +67,7 @@ Patch8:		ldap-helper-sigpipe.patch
>   Patch9:		%{name}-5.2p1-hpn13v6.diff
>   Patch10:	%{name}-include.patch
>   Patch11:	%{name}-chroot.patch
> +Patch12:	limits.h.patch
>   
>   Patch14:	%{name}-bind.patch
>   Patch15:	%{name}-disable_ldap.patch
> @@ -537,6 +538,7 @@ openldap-a.
>   %{?with_hpn:%patch9 -p1}
>   %patch10 -p1
>   %patch11 -p1
> +%patch12 -p1
>   
>   %patch14 -p1
>   %{!?with_ldap:%patch15 -p1}
> diff --git a/limits.h.patch b/limits.h.patch
> new file mode 100644
> index 0000000..5798141
> --- /dev/null
> +++ b/limits.h.patch
> @@ -0,0 +1,28 @@
> +--- openssh-6.6p1/openbsd-compat/fmt_scaled.c~	2014-05-13 17:23:35.999776940 +0300
> ++++ openssh-6.6p1/openbsd-compat/fmt_scaled.c	2014-05-13 17:23:40.989697403 +0300
> +@@ -49,6 +49,11 @@
> + #include <ctype.h>
> + #include <limits.h>
> +
> ++#if !defined(LLONG_MAX)
> ++#   define LLONG_MAX	9223372036854775807LL
> ++#   define LLONG_MIN	(-LLONG_MAX - 1LL)
> ++#endif
> ++
> + typedef enum {
> + 	NONE = 0, KILO = 1, MEGA = 2, GIGA = 3, TERA = 4, PETA = 5, EXA = 6
> + } unit_type;
> +--- openssh-6.6p1/openbsd-compat/strtonum.c~	2006-08-05 09:27:20.000000000 +0300
> ++++ openssh-6.6p1/openbsd-compat/strtonum.c	2014-05-13 17:31:27.715592099 +0300
> +@@ -26,6 +26,11 @@
> + #include <limits.h>
> + #include <errno.h>
> +
> ++#if !defined(LLONG_MAX)
> ++#   define LLONG_MAX   9223372036854775807LL
> ++#   define LLONG_MIN   (-LLONG_MAX - 1LL)
> ++#endif
> ++
> + #define INVALID 	1
> + #define TOOSMALL 	2
> + #define TOOLARGE 	3
> ================================================================
>
> ---- gitweb:
>
> http://git.pld-linux.org/gitweb.cgi/packages/openssh.git/commitdiff/621739ab2a22c5136a198a0a5e2dada6391f137f
>
> _______________________________________________
> pld-cvs-commit mailing list
> pld-cvs-commit at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit


-- 
glen



From qboosh at pld-linux.org  Tue May 13 17:16:04 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 13 May 2014 17:16:04 +0200
Subject: [packages/openssh] add limits.h hack for ac in openbsd-compat
In-Reply-To: <53722F54.10004@pld-linux.org>
References: <a46537e77b7bf4bc5bb87d8e4123cab18fb33687_refs_heads_master@pld-linux.org>
 <621739ab2a22c5136a198a0a5e2dada6391f137f_refs_heads_master@pld-linux.org>
 <53722F54.10004@pld-linux.org>
Message-ID: <20140513151604.GA4521@mail>

On Tue, May 13, 2014 at 05:42:28PM +0300, Elan Ruusam?e wrote:
> i would appreciate if somebody can do cleaner fix for this hack

> >+--- openssh-6.6p1/openbsd-compat/fmt_scaled.c~	2014-05-13 
> >17:23:35.999776940 +0300
> >++++ openssh-6.6p1/openbsd-compat/fmt_scaled.c	2014-05-13 
> >17:23:40.989697403 +0300
> >+@@ -49,6 +49,11 @@
> >+ #include <ctype.h>
> >+ #include <limits.h>
> >+
> >++#if !defined(LLONG_MAX)
> >++#   define LLONG_MAX	9223372036854775807LL
> >++#   define LLONG_MIN	(-LLONG_MAX - 1LL)
> >++#endif
> >++
> >+ typedef enum {
> >+ 	NONE = 0, KILO = 1, MEGA = 2, GIGA = 3, TERA = 4, PETA = 5, EXA = 6
> >+ } unit_type;

Have you tried -std=c99 (to CFLAGS)?

LLONG_ constants are available for:

#if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L


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


From glen at pld-linux.org  Tue May 13 17:42:51 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Tue, 13 May 2014 18:42:51 +0300
Subject: [packages/openssh] add limits.h hack for ac in openbsd-compat
In-Reply-To: <20140513151604.GA4521@mail>
References: <a46537e77b7bf4bc5bb87d8e4123cab18fb33687_refs_heads_master@pld-linux.org>
 <621739ab2a22c5136a198a0a5e2dada6391f137f_refs_heads_master@pld-linux.org>
 <53722F54.10004@pld-linux.org> <20140513151604.GA4521@mail>
Message-ID: <53723D7B.2040101@pld-linux.org>

On 13.05.2014 18:16, Jakub Bogusz wrote:
> On Tue, May 13, 2014 at 05:42:28PM +0300, Elan Ruusam?e wrote:
>> i would appreciate if somebody can do cleaner fix for this hack
>>> +--- openssh-6.6p1/openbsd-compat/fmt_scaled.c~	2014-05-13
>>> 17:23:35.999776940 +0300
>>> ++++ openssh-6.6p1/openbsd-compat/fmt_scaled.c	2014-05-13
>>> 17:23:40.989697403 +0300
>>> +@@ -49,6 +49,11 @@
>>> + #include <ctype.h>
>>> + #include <limits.h>
>>> +
>>> ++#if !defined(LLONG_MAX)
>>> ++#   define LLONG_MAX	9223372036854775807LL
>>> ++#   define LLONG_MIN	(-LLONG_MAX - 1LL)
>>> ++#endif
>>> ++
>>> + typedef enum {
>>> + 	NONE = 0, KILO = 1, MEGA = 2, GIGA = 3, TERA = 4, PETA = 5, EXA = 6
>>> + } unit_type;
> Have you tried -std=c99 (to CFLAGS)?
>
> LLONG_ constants are available for:
>
> #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
>
>

that will make it fail in other areas:

ccache amd64-pld-linux-gcc -O2 -gdwarf-2 -g2  -Wall -Wpointer-arith 
-Wuninitialized -Wsign-compare -Wformat-security -fno-strict-aliasing 
-D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset  -I. -I.. -I. -I./..  
-DCHROOT -std=c99 -DLDAP_DEPRECATED -I/usr/include  -I/usr/include  
-DHAVE_CONFIG_H -c bsd-closefrom.c
In file included from ../includes.h:171,
                  from bsd-asprintf.c:20:
../defines.h:374:1: warning: "NFDBITS" redefined
In file included from /usr/include/sys/types.h:216,
                  from ../includes.h:25,
                  from bsd-asprintf.c:20:
/usr/include/sys/select.h:88:1: warning: this is the location of the 
previous definition
In file included from ../includes.h:171,
                  from bsd-asprintf.c:20:
../defines.h:188: warning: redefinition of `u_int'
/usr/include/sys/types.h:37: warning: `u_int' previously declared here
../defines.h:288: warning: redefinition of `u_char'
/usr/include/sys/types.h:35: warning: `u_char' previously declared here
../defines.h:370: error: conflicting types for `fd_mask'
/usr/include/sys/select.h:85: error: previous declaration of `fd_mask'
In file included from ../openbsd-compat/openbsd-compat.h:258,
                  from ../includes.h:174,
                  from bsd-asprintf.c:20:
../openbsd-compat/fake-rfc2553.h:137: error: redefinition of `struct 
addrinfo'



-- 
glen



From qboosh at pld-linux.org  Tue May 13 18:02:02 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 13 May 2014 18:02:02 +0200
Subject: [packages/openssh] add limits.h hack for ac in openbsd-compat
In-Reply-To: <53723D7B.2040101@pld-linux.org>
References: <a46537e77b7bf4bc5bb87d8e4123cab18fb33687_refs_heads_master@pld-linux.org>
 <621739ab2a22c5136a198a0a5e2dada6391f137f_refs_heads_master@pld-linux.org>
 <53722F54.10004@pld-linux.org> <20140513151604.GA4521@mail>
 <53723D7B.2040101@pld-linux.org>
Message-ID: <20140513160202.GB4521@mail>

On Tue, May 13, 2014 at 06:42:51PM +0300, Elan Ruusam?e wrote:
> On 13.05.2014 18:16, Jakub Bogusz wrote:
> >On Tue, May 13, 2014 at 05:42:28PM +0300, Elan Ruusam?e wrote:
> >>i would appreciate if somebody can do cleaner fix for this hack
> >>>+--- openssh-6.6p1/openbsd-compat/fmt_scaled.c~	2014-05-13
> >>>17:23:35.999776940 +0300
> >>>++++ openssh-6.6p1/openbsd-compat/fmt_scaled.c	2014-05-13
> >>>17:23:40.989697403 +0300
> >>>+@@ -49,6 +49,11 @@
> >>>+ #include <ctype.h>
> >>>+ #include <limits.h>
> >>>+
> >>>++#if !defined(LLONG_MAX)
> >>>++#   define LLONG_MAX	9223372036854775807LL
> >>>++#   define LLONG_MIN	(-LLONG_MAX - 1LL)
> >>>++#endif
> >>>++
> >>>+ typedef enum {
> >>>+ 	NONE = 0, KILO = 1, MEGA = 2, GIGA = 3, TERA = 4, PETA = 5, EXA = 6
> >>>+ } unit_type;
> >Have you tried -std=c99 (to CFLAGS)?

Or maybe -std=gnu99?

> >LLONG_ constants are available for:
> >
> >#if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
> >
> >
> 
> that will make it fail in other areas:
> 
> ccache amd64-pld-linux-gcc -O2 -gdwarf-2 -g2  -Wall -Wpointer-arith 
> -Wuninitialized -Wsign-compare -Wformat-security -fno-strict-aliasing 
> -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset  -I. -I.. -I. -I./..  
> -DCHROOT -std=c99 -DLDAP_DEPRECATED -I/usr/include  -I/usr/include  
> -DHAVE_CONFIG_H -c bsd-closefrom.c
> In file included from ../includes.h:171,
>                  from bsd-asprintf.c:20:
> ../defines.h:374:1: warning: "NFDBITS" redefined
> In file included from /usr/include/sys/types.h:216,
>                  from ../includes.h:25,
>                  from bsd-asprintf.c:20:
> /usr/include/sys/select.h:88:1: warning: this is the location of the 
> previous definition
> In file included from ../includes.h:171,
>                  from bsd-asprintf.c:20:
> ../defines.h:188: warning: redefinition of `u_int'
> /usr/include/sys/types.h:37: warning: `u_int' previously declared here
> ../defines.h:288: warning: redefinition of `u_char'
> /usr/include/sys/types.h:35: warning: `u_char' previously declared here
> ../defines.h:370: error: conflicting types for `fd_mask'
> /usr/include/sys/select.h:85: error: previous declaration of `fd_mask'
> In file included from ../openbsd-compat/openbsd-compat.h:258,
>                  from ../includes.h:174,
>                  from bsd-asprintf.c:20:
> ../openbsd-compat/fake-rfc2553.h:137: error: redefinition of `struct 
> addrinfo'

Why there are redefinitions?


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


From ed at yen.ipipan.waw.pl  Tue May 13 20:28:11 2014
From: ed at yen.ipipan.waw.pl (=?utf-8?B?xYF1a2FzeiBNYcWba28=?=)
Date: Tue, 13 May 2014 20:28:11 +0200
Subject: Problem with latest chromium-browser-34.0.1847.116-1.i686
In-Reply-To: <535F4434.3050406@delfi.ee>
References: <4581258.PeMFaSSGuJ@laptok> <535F4434.3050406@delfi.ee>
Message-ID: <1800267.aIBXKMJgP0@laptok>

Dnia wtorek, 29 kwietnia 2014 09:18:28 Elan Ruusam?e pisze:
> 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:

I've given it a try today and it seems to work, although it is not stable - 
after a while (or just at the start up) it segfaults (that's what I get in 
logs):

May 13 20:23:56 laptok kernel: [13651.161915] Chrome_IOThread[11732]: segfault 
at 0 ip b094e710 sp a3fcb7b0 error 4 in libstdc++.so.6.0.19[b0906000+d7000]
May 13 20:23:58 laptok systemd-coredump[11902]: Process 11704 
(Chrome_IOThread) dumped core.

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



From glen at delfi.ee  Tue May 13 20:57:22 2014
From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Tue, 13 May 2014 21:57:22 +0300
Subject: php-gd deps
Message-ID: <53726B12.1090109@delfi.ee>

this is just "minor" update php 5.3.23 -> 5.3.28 and i'm forced dozen dependencies that are for desktop, not for servers.

any ideas, suggestion how to avoid this?



# poldek -u php-common
Processing dependencies...
php-common-5.3.27-3.i686 obsoleted by php-common-5.3.28-4.i686
   greedy upgrade php-cli-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved libphp_common-5.3.27.so)
    php-cli-5.3.27-3.i686 obsoleted by php-cli-5.3.28-4.i686
      greedy upgrade php-program-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved php-cli = 4:5.3.27-3)
       php-program-5.3.27-3.i686 obsoleted by php-program-5.3.28-4.i686
   greedy upgrade php-pcre-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved php-common = 4:5.3.27-3)
    php-pcre-5.3.27-3.i686 obsoleted by php-pcre-5.3.28-4.i686
      greedy upgrade php-spl-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved php-pcre = 4:5.3.27-3)
       php-spl-5.3.27-3.i686 obsoleted by php-spl-5.3.28-4.i686
         greedy upgrade php-pdo-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved php-spl = 4:5.3.27-3)
          php-pdo-5.3.27-3.i686 obsoleted by php-pdo-5.3.28-4.i686
            greedy upgrade php-pdo-sqlite-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved php-pdo = 4:5.3.27-3)
             php-pdo-sqlite-5.3.27-3.i686 obsoleted by php-pdo-sqlite-5.3.28-4.i686
         greedy upgrade php-simplexml-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved php-spl = 4:5.3.27-3)
          php-simplexml-5.3.27-3.i686 obsoleted by php-simplexml-5.3.28-4.i686
         greedy upgrade php-session-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved php-spl = 4:5.3.27-3)
          php-session-5.3.27-3.i686 obsoleted by php-session-5.3.28-4.i686
   greedy upgrade apache-mod_php-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved libphp_common-5.3.27.so)
    apache-mod_php-5.3.27-3.i686 obsoleted by apache-mod_php-5.3.28-4.i686
   greedy upgrade php-bcmath-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved php-common = 4:5.3.27-3)
    php-bcmath-5.3.27-3.i686 obsoleted by php-bcmath-5.3.28-4.i686
   greedy upgrade php-curl-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved php-common = 4:5.3.27-3)
    php-curl-5.3.27-3.i686 obsoleted by php-curl-5.3.28-4.i686
   greedy upgrade php-gd-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved php-common = 4:5.3.27-3)
    php-gd-5.3.27-3.i686 obsoleted by php-gd-5.3.28-4.i686
    php-gd-5.3.28-4.i686 marks harfbuzz-0.9.27-2.i686 (cap libharfbuzz.so.0)
     harfbuzz-0.9.27-2.i686 marks gobject-introspection-1.40.0-1.i686 (cap /usr/lib/girepository-1.0)
     harfbuzz-0.9.27-2.i686 marks cairo-1.12.16-7.i686 (cap cairo >= 1.8.0)
      cairo-1.12.16-7.i686 marks Mesa-libEGL-10.1.1-1.i686 (cap libEGL.so.1)
       Mesa-libEGL-10.1.1-1.i686 marks Mesa-libOpenVG-10.1.1-1.i686 (cap Mesa-libOpenVG = 10.1.1-1)
       Mesa-libEGL-10.1.1-1.i686 marks Mesa-libgbm-10.1.1-1.i686 (cap Mesa-libgbm = 10.1.1-1)
        Mesa-libgbm-10.1.1-1.i686 marks Mesa-libglapi-10.1.1-1.i686 (cap Mesa-libglapi = 10.1.1-1)
        Mesa-libgbm-10.1.1-1.i686 marks llvm-libs-3.3-1.i686 (cap libLLVM-3.3.so)
        Mesa-libgbm-10.1.1-1.i686 marks libdrm-2.4.53-1.i686 (cap libdrm.so.2)
         libdrm-2.4.53-1.i686 marks xorg-lib-libpciaccess-0.13.2-1.i686 (cap libpciaccess.so.0)
          xorg-lib-libpciaccess-0.13.2-1.i686 marks hwdata-0.263-1.noarch (cap hwdata >= 0.243-2)
        Mesa-libgbm-10.1.1-1.i686 marks wayland-1.4.0-1.i686 (cap libwayland-client.so.0)
        Mesa-libgbm-10.1.1-1.i686 marks libxcb-1.10-2.i686 (cap libxcb-dri2.so.0)
       Mesa-libEGL-10.1.1-1.i686 marks Mesa-libGL-10.1.1-1.i686 (cap OpenGL >= 1.2)
        Mesa-libGL-10.1.1-1.i686 marks xorg-lib-libX11-1.6.2-1.i686 (cap libX11-xcb.so.1)
        Mesa-libGL-10.1.1-1.i686 marks xorg-lib-libXdamage-1.1.4-1.i686 (cap libXdamage.so.1)
        Mesa-libGL-10.1.1-1.i686 marks xorg-lib-libXext-1.3.2-1.i686 (cap libXext.so.6)
        Mesa-libGL-10.1.1-1.i686 marks xorg-lib-libXfixes-5.0.1-1.i686 (cap libXfixes.so.3)
        Mesa-libGL-10.1.1-1.i686 marks xorg-lib-libXxf86vm-1.1.3-1.i686 (cap libXxf86vm.so.1)
        Mesa-libGL-10.1.1-1.i686 marks xorg-lib-libxshmfence-1.1-1.i686 (cap libxshmfence.so.1)
      cairo-1.12.16-7.i686 marks xorg-lib-libXrender-0.9.8-1.i686 (cap libXrender.so.1)
      cairo-1.12.16-7.i686 marks pixman-0.32.4-1.i686 (cap libpixman-1.so.0)
      cairo-1.12.16-7.i686 marks libpng-1.6.10-1.i686 (cap libpng16.so.16)
       libpng-1.5.15-1.i686 obsoleted by libpng-1.6.10-1.i686
         greedy upgrade freetype-2.5.0.1-1.i686 to 2.5.3-1.i686 (unresolved libpng15.so.15)
          freetype-2.5.0.1-1.i686 obsoleted by freetype-2.5.3-1.i686
     harfbuzz-0.9.27-2.i686 marks graphite2-1.2.4-1.i686 (cap libgraphite2.so.3)
   greedy upgrade php-ldap-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved php-common = 4:5.3.27-3)
    php-ldap-5.3.27-3.i686 obsoleted by php-ldap-5.3.28-4.i686
   greedy upgrade php-mbstring-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved php-common = 4:5.3.27-3)
    php-mbstring-5.3.27-3.i686 obsoleted by php-mbstring-5.3.28-4.i686
   greedy upgrade php-xml-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved php-common = 4:5.3.27-3)
    php-xml-5.3.27-3.i686 obsoleted by php-xml-5.3.28-4.i686
   greedy upgrade php-zlib-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved php-common = 4:5.3.27-3)
    php-zlib-5.3.27-3.i686 obsoleted by php-zlib-5.3.28-4.i686
php-common-5.3.28-4.i686 marks pcre-8.35-1.i686 (cap pcre >= 8.35)
  pcre-8.34-2.i686 obsoleted by pcre-8.35-1.i686
There are 43 packages to install (42 marked by dependencies), 20 to remove:
I php-common-5.3.28-4.i686
D Mesa-libEGL-10.1.1-1.i686  Mesa-libGL-10.1.1-1.i686
D Mesa-libOpenVG-10.1.1-1.i686  Mesa-libgbm-10.1.1-1.i686
D Mesa-libglapi-10.1.1-1.i686  apache-mod_php-5.3.28-4.i686
D cairo-1.12.16-7.i686  freetype-2.5.3-1.i686
D gobject-introspection-1.40.0-1.i686  graphite2-1.2.4-1.i686
D harfbuzz-0.9.27-2.i686  hwdata-0.263-1.noarch  libdrm-2.4.53-1.i686
D libpng-1.6.10-1.i686  libxcb-1.10-2.i686  llvm-libs-3.3-1.i686
D pcre-8.35-1.i686  php-bcmath-5.3.28-4.i686  php-cli-5.3.28-4.i686
D php-curl-5.3.28-4.i686  php-gd-5.3.28-4.i686  php-ldap-5.3.28-4.i686
D php-mbstring-5.3.28-4.i686  php-pcre-5.3.28-4.i686
D php-pdo-5.3.28-4.i686  php-pdo-sqlite-5.3.28-4.i686
D php-program-5.3.28-4.i686  php-session-5.3.28-4.i686
D php-simplexml-5.3.28-4.i686  php-spl-5.3.28-4.i686
D php-xml-5.3.28-4.i686  php-zlib-5.3.28-4.i686  pixman-0.32.4-1.i686
D wayland-1.4.0-1.i686  xorg-lib-libX11-1.6.2-1.i686
D xorg-lib-libXdamage-1.1.4-1.i686  xorg-lib-libXext-1.3.2-1.i686
D xorg-lib-libXfixes-5.0.1-1.i686  xorg-lib-libXrender-0.9.8-1.i686
D xorg-lib-libXxf86vm-1.1.3-1.i686  xorg-lib-libpciaccess-0.13.2-1.i686
D xorg-lib-libxshmfence-1.1-1.i686
R apache-mod_php-5.3.27-3.i686  freetype-2.5.0.1-1.i686
R libpng-1.5.15-1.i686  pcre-8.34-2.i686  php-bcmath-5.3.27-3.i686
R php-cli-5.3.27-3.i686  php-common-5.3.27-3.i686  php-curl-5.3.27-3.i686
R php-gd-5.3.27-3.i686  php-ldap-5.3.27-3.i686
R php-mbstring-5.3.27-3.i686  php-pcre-5.3.27-3.i686
R php-pdo-5.3.27-3.i686  php-pdo-sqlite-5.3.27-3.i686
R php-program-5.3.27-3.i686  php-session-5.3.27-3.i686
R php-simplexml-5.3.27-3.i686  php-spl-5.3.27-3.i686
R php-xml-5.3.27-3.i686  php-zlib-5.3.27-3.i686
This operation will use 48.8MB of disk space.
Need to get 15.2MB of archives (15.1MB to download).


-- 
glen



From glen at pld-linux.org  Tue May 13 21:08:03 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Tue, 13 May 2014 22:08:03 +0300
Subject: /etc/cron.d to filesystem
In-Reply-To: <20140513090219.GC2180@home.lan>
References: <53678315.2080902@pld-linux.org> <20140513090219.GC2180@home.lan>
Message-ID: <53726D93.1030309@pld-linux.org>

On 13.05.2014 12:02, Jan R?korajski wrote:
> On Mon, 05 May 2014, Elan Ruusam?e wrote:
>
>> rfc: move /etc/cron.d to filesystem package
>>
>> rationale: simplify packaging where cron dependency could be optional
> If you first add appropriate R/S to all packages that (may) need cron.
> The problem is a lot of packages that need cron have only indirect dep
> via this dir AFAIR.

with or without huge Conflicts list?

and existsing systems aren't affected on upgrade, crondaemon is already 
present.
on fresh installations, you will notice that stuff doesn't work (ideally 
you should test whether installed stuff works :)

so imho the C is pointless, just extra work to collect the NEVRs

-- 
glen



From baggins at pld-linux.org  Tue May 13 21:27:07 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 13 May 2014 21:27:07 +0200
Subject: /etc/cron.d to filesystem
In-Reply-To: <53726D93.1030309@pld-linux.org>
References: <53678315.2080902@pld-linux.org> <20140513090219.GC2180@home.lan>
 <53726D93.1030309@pld-linux.org>
Message-ID: <20140513192707.GA4973@home.lan>

On Tue, 13 May 2014, Elan Ruusam?e wrote:

> On 13.05.2014 12:02, Jan R?korajski wrote:
> > On Mon, 05 May 2014, Elan Ruusam?e wrote:
> >
> >> rfc: move /etc/cron.d to filesystem package
> >>
> >> rationale: simplify packaging where cron dependency could be optional
> > If you first add appropriate R/S to all packages that (may) need cron.
> > The problem is a lot of packages that need cron have only indirect dep
> > via this dir AFAIR.
> 
> with or without huge Conflicts list?
> 
> and existsing systems aren't affected on upgrade, crondaemon is already 
> present.
> on fresh installations, you will notice that stuff doesn't work (ideally 
> you should test whether installed stuff works :)
> 
> so imho the C is pointless, just extra work to collect the NEVRs

Eh? What huge Conflicts list are you talking about?
I'm talking about missing "Requires/Suggests: crondaemon" in
packages that (may) require cron.

-- 
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 May 13 21:57:07 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Tue, 13 May 2014 22:57:07 +0300
Subject: php-gd deps
In-Reply-To: <53726B12.1090109@delfi.ee>
References: <53726B12.1090109@delfi.ee>
Message-ID: <53727913.9020508@pld-linux.org>

On 13.05.2014 21:57, Elan Ruusam?e wrote:
> this is just "minor" update php 5.3.23 -> 5.3.28 and i'm forced dozen 
> dependencies that are for desktop, not for servers.
>
> any ideas, suggestion how to avoid this?
mesa went away when splitting gobject packages
http://git.pld-linux.org/?p=packages/harfbuzz.git;a=commitdiff;h=0844366e17b3b5e005e38bca07f8b8701c478067

but cairo still present because hb-view links with libcairo.so.2

move that to gobject package?
or create -progs package?

what about the runtime cairo dependency?


> # poldek -u php-common
> Processing dependencies...
> php-common-5.3.27-3.i686 obsoleted by php-common-5.3.28-4.i686
>   greedy upgrade php-cli-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved 
> libphp_common-5.3.27.so)
>    php-cli-5.3.27-3.i686 obsoleted by php-cli-5.3.28-4.i686
>      greedy upgrade php-program-5.3.27-3.i686 to 5.3.28-4.i686 
> (unresolved php-cli = 4:5.3.27-3)
>       php-program-5.3.27-3.i686 obsoleted by php-program-5.3.28-4.i686
>   greedy upgrade php-pcre-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved 
> php-common = 4:5.3.27-3)
>    php-pcre-5.3.27-3.i686 obsoleted by php-pcre-5.3.28-4.i686
>      greedy upgrade php-spl-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved 
> php-pcre = 4:5.3.27-3)
>       php-spl-5.3.27-3.i686 obsoleted by php-spl-5.3.28-4.i686
>         greedy upgrade php-pdo-5.3.27-3.i686 to 5.3.28-4.i686 
> (unresolved php-spl = 4:5.3.27-3)
>          php-pdo-5.3.27-3.i686 obsoleted by php-pdo-5.3.28-4.i686
>            greedy upgrade php-pdo-sqlite-5.3.27-3.i686 to 
> 5.3.28-4.i686 (unresolved php-pdo = 4:5.3.27-3)
>             php-pdo-sqlite-5.3.27-3.i686 obsoleted by 
> php-pdo-sqlite-5.3.28-4.i686
>         greedy upgrade php-simplexml-5.3.27-3.i686 to 5.3.28-4.i686 
> (unresolved php-spl = 4:5.3.27-3)
>          php-simplexml-5.3.27-3.i686 obsoleted by 
> php-simplexml-5.3.28-4.i686
>         greedy upgrade php-session-5.3.27-3.i686 to 5.3.28-4.i686 
> (unresolved php-spl = 4:5.3.27-3)
>          php-session-5.3.27-3.i686 obsoleted by php-session-5.3.28-4.i686
>   greedy upgrade apache-mod_php-5.3.27-3.i686 to 5.3.28-4.i686 
> (unresolved libphp_common-5.3.27.so)
>    apache-mod_php-5.3.27-3.i686 obsoleted by apache-mod_php-5.3.28-4.i686
>   greedy upgrade php-bcmath-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved 
> php-common = 4:5.3.27-3)
>    php-bcmath-5.3.27-3.i686 obsoleted by php-bcmath-5.3.28-4.i686
>   greedy upgrade php-curl-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved 
> php-common = 4:5.3.27-3)
>    php-curl-5.3.27-3.i686 obsoleted by php-curl-5.3.28-4.i686
>   greedy upgrade php-gd-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved 
> php-common = 4:5.3.27-3)
>    php-gd-5.3.27-3.i686 obsoleted by php-gd-5.3.28-4.i686
>    php-gd-5.3.28-4.i686 marks harfbuzz-0.9.27-2.i686 (cap 
> libharfbuzz.so.0)
>     harfbuzz-0.9.27-2.i686 marks gobject-introspection-1.40.0-1.i686 
> (cap /usr/lib/girepository-1.0)
>     harfbuzz-0.9.27-2.i686 marks cairo-1.12.16-7.i686 (cap cairo >= 
> 1.8.0)
>      cairo-1.12.16-7.i686 marks Mesa-libEGL-10.1.1-1.i686 (cap 
> libEGL.so.1)
>       Mesa-libEGL-10.1.1-1.i686 marks Mesa-libOpenVG-10.1.1-1.i686 
> (cap Mesa-libOpenVG = 10.1.1-1)
>       Mesa-libEGL-10.1.1-1.i686 marks Mesa-libgbm-10.1.1-1.i686 (cap 
> Mesa-libgbm = 10.1.1-1)
>        Mesa-libgbm-10.1.1-1.i686 marks Mesa-libglapi-10.1.1-1.i686 
> (cap Mesa-libglapi = 10.1.1-1)
>        Mesa-libgbm-10.1.1-1.i686 marks llvm-libs-3.3-1.i686 (cap 
> libLLVM-3.3.so)
>        Mesa-libgbm-10.1.1-1.i686 marks libdrm-2.4.53-1.i686 (cap 
> libdrm.so.2)
>         libdrm-2.4.53-1.i686 marks xorg-lib-libpciaccess-0.13.2-1.i686 
> (cap libpciaccess.so.0)
>          xorg-lib-libpciaccess-0.13.2-1.i686 marks 
> hwdata-0.263-1.noarch (cap hwdata >= 0.243-2)
>        Mesa-libgbm-10.1.1-1.i686 marks wayland-1.4.0-1.i686 (cap 
> libwayland-client.so.0)
>        Mesa-libgbm-10.1.1-1.i686 marks libxcb-1.10-2.i686 (cap 
> libxcb-dri2.so.0)
>       Mesa-libEGL-10.1.1-1.i686 marks Mesa-libGL-10.1.1-1.i686 (cap 
> OpenGL >= 1.2)
>        Mesa-libGL-10.1.1-1.i686 marks xorg-lib-libX11-1.6.2-1.i686 
> (cap libX11-xcb.so.1)
>        Mesa-libGL-10.1.1-1.i686 marks xorg-lib-libXdamage-1.1.4-1.i686 
> (cap libXdamage.so.1)
>        Mesa-libGL-10.1.1-1.i686 marks xorg-lib-libXext-1.3.2-1.i686 
> (cap libXext.so.6)
>        Mesa-libGL-10.1.1-1.i686 marks xorg-lib-libXfixes-5.0.1-1.i686 
> (cap libXfixes.so.3)
>        Mesa-libGL-10.1.1-1.i686 marks xorg-lib-libXxf86vm-1.1.3-1.i686 
> (cap libXxf86vm.so.1)
>        Mesa-libGL-10.1.1-1.i686 marks xorg-lib-libxshmfence-1.1-1.i686 
> (cap libxshmfence.so.1)
>      cairo-1.12.16-7.i686 marks xorg-lib-libXrender-0.9.8-1.i686 (cap 
> libXrender.so.1)
>      cairo-1.12.16-7.i686 marks pixman-0.32.4-1.i686 (cap 
> libpixman-1.so.0)
>      cairo-1.12.16-7.i686 marks libpng-1.6.10-1.i686 (cap libpng16.so.16)
>       libpng-1.5.15-1.i686 obsoleted by libpng-1.6.10-1.i686
>         greedy upgrade freetype-2.5.0.1-1.i686 to 2.5.3-1.i686 
> (unresolved libpng15.so.15)
>          freetype-2.5.0.1-1.i686 obsoleted by freetype-2.5.3-1.i686
>     harfbuzz-0.9.27-2.i686 marks graphite2-1.2.4-1.i686 (cap 
> libgraphite2.so.3)
>   greedy upgrade php-ldap-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved 
> php-common = 4:5.3.27-3)
>    php-ldap-5.3.27-3.i686 obsoleted by php-ldap-5.3.28-4.i686
>   greedy upgrade php-mbstring-5.3.27-3.i686 to 5.3.28-4.i686 
> (unresolved php-common = 4:5.3.27-3)
>    php-mbstring-5.3.27-3.i686 obsoleted by php-mbstring-5.3.28-4.i686
>   greedy upgrade php-xml-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved 
> php-common = 4:5.3.27-3)
>    php-xml-5.3.27-3.i686 obsoleted by php-xml-5.3.28-4.i686
>   greedy upgrade php-zlib-5.3.27-3.i686 to 5.3.28-4.i686 (unresolved 
> php-common = 4:5.3.27-3)
>    php-zlib-5.3.27-3.i686 obsoleted by php-zlib-5.3.28-4.i686
> php-common-5.3.28-4.i686 marks pcre-8.35-1.i686 (cap pcre >= 8.35)
>  pcre-8.34-2.i686 obsoleted by pcre-8.35-1.i686
> There are 43 packages to install (42 marked by dependencies), 20 to 
> remove:
> I php-common-5.3.28-4.i686
> D Mesa-libEGL-10.1.1-1.i686  Mesa-libGL-10.1.1-1.i686
> D Mesa-libOpenVG-10.1.1-1.i686  Mesa-libgbm-10.1.1-1.i686
> D Mesa-libglapi-10.1.1-1.i686  apache-mod_php-5.3.28-4.i686
> D cairo-1.12.16-7.i686  freetype-2.5.3-1.i686
> D gobject-introspection-1.40.0-1.i686  graphite2-1.2.4-1.i686
> D harfbuzz-0.9.27-2.i686  hwdata-0.263-1.noarch libdrm-2.4.53-1.i686
> D libpng-1.6.10-1.i686  libxcb-1.10-2.i686  llvm-libs-3.3-1.i686
> D pcre-8.35-1.i686  php-bcmath-5.3.28-4.i686 php-cli-5.3.28-4.i686
> D php-curl-5.3.28-4.i686  php-gd-5.3.28-4.i686 php-ldap-5.3.28-4.i686
> D php-mbstring-5.3.28-4.i686  php-pcre-5.3.28-4.i686
> D php-pdo-5.3.28-4.i686  php-pdo-sqlite-5.3.28-4.i686
> D php-program-5.3.28-4.i686  php-session-5.3.28-4.i686
> D php-simplexml-5.3.28-4.i686  php-spl-5.3.28-4.i686
> D php-xml-5.3.28-4.i686  php-zlib-5.3.28-4.i686 pixman-0.32.4-1.i686
> D wayland-1.4.0-1.i686  xorg-lib-libX11-1.6.2-1.i686
> D xorg-lib-libXdamage-1.1.4-1.i686  xorg-lib-libXext-1.3.2-1.i686
> D xorg-lib-libXfixes-5.0.1-1.i686 xorg-lib-libXrender-0.9.8-1.i686
> D xorg-lib-libXxf86vm-1.1.3-1.i686 xorg-lib-libpciaccess-0.13.2-1.i686
> D xorg-lib-libxshmfence-1.1-1.i686
> R apache-mod_php-5.3.27-3.i686  freetype-2.5.0.1-1.i686
> R libpng-1.5.15-1.i686  pcre-8.34-2.i686  php-bcmath-5.3.27-3.i686
> R php-cli-5.3.27-3.i686  php-common-5.3.27-3.i686 php-curl-5.3.27-3.i686
> R php-gd-5.3.27-3.i686  php-ldap-5.3.27-3.i686
> R php-mbstring-5.3.27-3.i686  php-pcre-5.3.27-3.i686
> R php-pdo-5.3.27-3.i686  php-pdo-sqlite-5.3.27-3.i686
> R php-program-5.3.27-3.i686  php-session-5.3.27-3.i686
> R php-simplexml-5.3.27-3.i686  php-spl-5.3.27-3.i686
> R php-xml-5.3.27-3.i686  php-zlib-5.3.27-3.i686
> This operation will use 48.8MB of disk space.
> Need to get 15.2MB of archives (15.1MB to download).
>
>


-- 
glen



From glen at pld-linux.org  Tue May 13 23:01:50 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Wed, 14 May 2014 00:01:50 +0300
Subject: Kernel panic with geninitrd and root=/dev/vgname/lvname
In-Reply-To: <CAEwbCw2HAC+ueBuycC_1fH+P3KQJ993ZMj3HAMCGDdAHWXESyQ@mail.gmail.com>
References: <CAEwbCw2HAC+ueBuycC_1fH+P3KQJ993ZMj3HAMCGDdAHWXESyQ@mail.gmail.com>
Message-ID: <5372883E.7020405@pld-linux.org>

On 13.05.2014 02:33, ?ukasz Krotowski wrote:
> Hi,
> our geninitrd in function initrd_gen_setrootdev() tries to fill
> /proc/sys/kernel/real-root-dev based on /proc/partitions. But, when
> booted with root=/dev/vgname/lvname:
> - /proc/sys/kernel/real-root-dev is already filled with proper number
> by initrd_gen_lvm(),
> - /proc/partitions contains dm-X not vgname/lvname hence root device
> is not found. And that causes panic.
>
> My local fix is:
> + if [ "$(busybox cat /proc/sys/kernel/real-root-dev)" -eq 0 -a
> "${ROOT##/dev/}" != "${ROOT}" ]; then
> - if [ "${ROOT##/dev/}" != "${ROOT}" ]; then
>
> Since I don't know how to change geninitrd I'm signaling this issue
> here. FWIW I use geninitrd with --initrdfs=rom.

seems the bug doesn't exist with --initrdfs=initramfs

and the problem is that busybox 1.21 -> 1.22 ls -l format has changed, 
so the unreliable fallback to ls -l, reading minor-major of 254,0 it 
gets 0,0

-- 
glen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ls.png
Type: image/png
Size: 3872 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20140514/1bbcb589/attachment.png>

From glen at pld-linux.org  Tue May 13 23:05:55 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Wed, 14 May 2014 00:05:55 +0300
Subject: Kernel panic with geninitrd and root=/dev/vgname/lvname
In-Reply-To: <5372883E.7020405@pld-linux.org>
References: <CAEwbCw2HAC+ueBuycC_1fH+P3KQJ993ZMj3HAMCGDdAHWXESyQ@mail.gmail.com>
 <5372883E.7020405@pld-linux.org>
Message-ID: <53728933.4000301@pld-linux.org>

On 14.05.2014 00:01, Elan Ruusam?e wrote:
> On 13.05.2014 02:33, ?ukasz Krotowski wrote:
>> Hi,
>> our geninitrd in function initrd_gen_setrootdev() tries to fill
>> /proc/sys/kernel/real-root-dev based on /proc/partitions. But, when
>> booted with root=/dev/vgname/lvname:
>> - /proc/sys/kernel/real-root-dev is already filled with proper number
>> by initrd_gen_lvm(),
>> - /proc/partitions contains dm-X not vgname/lvname hence root device
>> is not found. And that causes panic.
>>
>> My local fix is:
>> + if [ "$(busybox cat /proc/sys/kernel/real-root-dev)" -eq 0 -a
>> "${ROOT##/dev/}" != "${ROOT}" ]; then
>> - if [ "${ROOT##/dev/}" != "${ROOT}" ]; then
>>
>> Since I don't know how to change geninitrd I'm signaling this issue
>> here. FWIW I use geninitrd with --initrdfs=rom.
>
> seems the bug doesn't exist with --initrdfs=initramfs
>
> and the problem is that busybox 1.21 -> 1.22 ls -l format has changed, 
> so the unreliable fallback to ls -l, reading minor-major of 254,0 it 
> gets 0,0
the same in copy-paste format:

21:42:59 root[load: 0.38]@pld /root# ./busybox-1.21.1 ls -l /dev/sys/rootfs
lrwxrwxrwx 1 7 /dev/sys/rootfs -> ../dm-0

21:43:04 root[load: 0.35]@pld /root# ./busybox-1.22.1 ls -l /dev/sys/rootfs
lrwxrwxrwx 1 root root 7 May 13 21:33 /dev/sys/rootfs -> ../dm-0




-- 
glen



From glen at pld-linux.org  Wed May 14 13:43:23 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Wed, 14 May 2014 14:43:23 +0300
Subject: php and LFS
Message-ID: <537356DB.9060008@pld-linux.org>

seems our 32bit php is built without largefile support.

? php53 -r 
'var_dump(stat("/usr/share/pear/PEAR/Installer/Role/Common.php"));'
PHP Warning: stat(): stat failed for 
/usr/share/pear/PEAR/Installer/Role/Common.php in Command line code on 
line 1
bool(false)

? php55 -r 
'var_dump(stat("/usr/share/pear/PEAR/Installer/Role/Common.php"));'
PHP Warning: stat(): stat failed for 
/usr/share/pear/PEAR/Installer/Role/Common.php in Command line code on 
line 1
bool(false)

? ls -ldi /usr/share/pear/PEAR/Installer/Role/Common.php
4306713209 -rw-r--r-- 1 root root 6299 Aug 26 2012 
/usr/share/pear/PEAR/Installer/Role/Common.php

but, i do see -D_GNU_SOURCE -D_LARGEFILE64_SOURCE in build logs... ideas?

-- 
glen



From qboosh at pld-linux.org  Wed May 14 15:47:04 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 14 May 2014 15:47:04 +0200
Subject: php and LFS
In-Reply-To: <537356DB.9060008@pld-linux.org>
References: <537356DB.9060008@pld-linux.org>
Message-ID: <20140514134704.GA13665@mail>

On Wed, May 14, 2014 at 02:43:23PM +0300, Elan Ruusam?e wrote:
> seems our 32bit php is built without largefile support.
> 
> ??? php53 -r 
> 'var_dump(stat("/usr/share/pear/PEAR/Installer/Role/Common.php"));'
> PHP Warning: stat(): stat failed for 
> /usr/share/pear/PEAR/Installer/Role/Common.php in Command line code on 
> line 1
> bool(false)
> 
> ??? php55 -r 
> 'var_dump(stat("/usr/share/pear/PEAR/Installer/Role/Common.php"));'
> PHP Warning: stat(): stat failed for 
> /usr/share/pear/PEAR/Installer/Role/Common.php in Command line code on 
> line 1
> bool(false)
> 
> ??? ls -ldi /usr/share/pear/PEAR/Installer/Role/Common.php
> 4306713209 -rw-r--r-- 1 root root 6299 Aug 26 2012 
> /usr/share/pear/PEAR/Installer/Role/Common.php
> 
> but, i do see -D_GNU_SOURCE -D_LARGEFILE64_SOURCE in build logs... ideas?

_LARGEFILE64_SOURCE enables 64-bit file API, but with separate names.
To get them available under base names, _FILE_OFFSET_BITS=64 must be
used.


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


From glen at pld-linux.org  Wed May 14 20:20:48 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Wed, 14 May 2014 21:20:48 +0300
Subject: php and LFS
In-Reply-To: <20140514134704.GA13665@mail>
References: <537356DB.9060008@pld-linux.org> <20140514134704.GA13665@mail>
Message-ID: <5373B400.6030909@pld-linux.org>

On 14.05.2014 16:47, Jakub Bogusz wrote:
> On Wed, May 14, 2014 at 02:43:23PM +0300, Elan Ruusam?e wrote:
>> seems our 32bit php is built without largefile support.
>>
>> ??? php53 -r
>> 'var_dump(stat("/usr/share/pear/PEAR/Installer/Role/Common.php"));'
>> PHP Warning: stat(): stat failed for
>> /usr/share/pear/PEAR/Installer/Role/Common.php in Command line code on
>> line 1
>> bool(false)
>>
>> ??? php55 -r
>> 'var_dump(stat("/usr/share/pear/PEAR/Installer/Role/Common.php"));'
>> PHP Warning: stat(): stat failed for
>> /usr/share/pear/PEAR/Installer/Role/Common.php in Command line code on
>> line 1
>> bool(false)
>>
>> ??? ls -ldi /usr/share/pear/PEAR/Installer/Role/Common.php
>> 4306713209 -rw-r--r-- 1 root root 6299 Aug 26 2012
>> /usr/share/pear/PEAR/Installer/Role/Common.php
>>
>> but, i do see -D_GNU_SOURCE -D_LARGEFILE64_SOURCE in build logs... ideas?
> _LARGEFILE64_SOURCE enables 64-bit file API, but with separate names.
> To get them available under base names, _FILE_OFFSET_BITS=64 must be
> used.


is it safe to add it to CFLAGS?

i found this ticket https://bugs.php.net/bug.php?id=45942

-- 
glen



From glen at pld-linux.org  Wed May 14 20:47:42 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Wed, 14 May 2014 21:47:42 +0300
Subject: php and LFS
In-Reply-To: <5373B400.6030909@pld-linux.org>
References: <537356DB.9060008@pld-linux.org> <20140514134704.GA13665@mail>
 <5373B400.6030909@pld-linux.org>
Message-ID: <5373BA4E.5070304@pld-linux.org>

On 14.05.2014 21:20, Elan Ruusam?e wrote:
> On 14.05.2014 16:47, Jakub Bogusz wrote:
>> On Wed, May 14, 2014 at 02:43:23PM +0300, Elan Ruusam?e wrote:
>>> but, i do see -D_GNU_SOURCE -D_LARGEFILE64_SOURCE in build logs... 
>>> ideas?
>> _LARGEFILE64_SOURCE enables 64-bit file API, but with separate names.
>> To get them available under base names, _FILE_OFFSET_BITS=64 must be
>> used.
>
>
> is it safe to add it to CFLAGS?
>
> i found this ticket https://bugs.php.net/bug.php?id=45942
>
and this one
https://bugs.php.net/bug.php?id=45040

also the LFS flags found from log came from apr config:
/usr/bin/apr-1-config:CPPFLAGS="-DLINUX -D_REENTRANT -D_GNU_SOURCE 
-D_LARGEFILE64_SOURCE"

php itself has PHP_SYS_LFS macro in acinclude.m4, but it's never 
referenced in php-src
https://github.com/php/php-src/blob/php-5.5.12/acinclude.m4#L1568-L1612

the getconf class, that it would use are:

$ getconf LFS_CFLAGS
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
$  getconf LFS_LDFLAGS

$  getconf LFS_LIBS

$

if we rebuild with "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64", will that:
1) decrease performance of php as said in bug 45942
2) would require rebuild all php extensions? or funny things will happen?

-- 
glen



From qboosh at pld-linux.org  Thu May 15 19:08:10 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 15 May 2014 19:08:10 +0200
Subject: php and LFS
In-Reply-To: <5373BA4E.5070304@pld-linux.org>
References: <537356DB.9060008@pld-linux.org> <20140514134704.GA13665@mail>
 <5373B400.6030909@pld-linux.org> <5373BA4E.5070304@pld-linux.org>
Message-ID: <20140515170810.GA18719@mail>

On Wed, May 14, 2014 at 09:47:42PM +0300, Elan Ruusam?e wrote:
> On 14.05.2014 21:20, Elan Ruusam?e wrote:
> >On 14.05.2014 16:47, Jakub Bogusz wrote:
> >>On Wed, May 14, 2014 at 02:43:23PM +0300, Elan Ruusam?e wrote:
> >>>but, i do see -D_GNU_SOURCE -D_LARGEFILE64_SOURCE in build logs... 
> >>>ideas?
> >>_LARGEFILE64_SOURCE enables 64-bit file API, but with separate names.
> >>To get them available under base names, _FILE_OFFSET_BITS=64 must be
> >>used.
> >
> >
> >is it safe to add it to CFLAGS?
> >
> >i found this ticket https://bugs.php.net/bug.php?id=45942
> >
> and this one
> https://bugs.php.net/bug.php?id=45040
> 
> also the LFS flags found from log came from apr config:
> /usr/bin/apr-1-config:CPPFLAGS="-DLINUX -D_REENTRANT -D_GNU_SOURCE 
> -D_LARGEFILE64_SOURCE"
> 
> php itself has PHP_SYS_LFS macro in acinclude.m4, but it's never 
> referenced in php-src
> https://github.com/php/php-src/blob/php-5.5.12/acinclude.m4#L1568-L1612
> 
> the getconf class, that it would use are:
> 
> $ getconf LFS_CFLAGS
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> $  getconf LFS_LDFLAGS
> 
> $  getconf LFS_LIBS
> 
> $
> 
> if we rebuild with "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64", will that:
> 1) decrease performance of php as said in bug 45942

What complete flags were used? In this report I see
CFLAGS="-D_FILE_OFFSET_BITS=64" ./configure ...
which could disable any compiler optimization which configure uses by
default (if custom PHP configure code doesn't set any if there are no
-Ox options in CFLAGS).

> 2) would require rebuild all php extensions? or funny things will happen?

Depends if off_t, struct stat or so are used in ABI.

Also note that the flag itself is (probably) sufficient to get 64-bit
inode support, but not for complete 64-bit file offsets/lengths support.
For the latter, you can find some patch here:
https://bugs.php.net/bug.php?id=27792
in particular:
https://bugs.php.net/patch-display.php?bug_id=27792&patch=php551LFS.patch&revision=latest

(partially ugly, like returning sizes as doubles, but it seems to be PHP
limitation(?))


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


From glen at pld-linux.org  Thu May 15 19:49:47 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Thu, 15 May 2014 20:49:47 +0300
Subject: php and LFS
In-Reply-To: <20140515170810.GA18719@mail>
References: <537356DB.9060008@pld-linux.org> <20140514134704.GA13665@mail>
 <5373B400.6030909@pld-linux.org> <5373BA4E.5070304@pld-linux.org>
 <20140515170810.GA18719@mail>
Message-ID: <5374FE3B.7000608@pld-linux.org>

On 15.05.2014 20:08, Jakub Bogusz wrote:
> Also note that the flag itself is (probably) sufficient to get 64-bit
> inode support, but not for complete 64-bit file offsets/lengths support.
intention was to fix using php on inode64 mounted filesystem.
php itself overflowing in every corner is fine (not going to fix it in 
pld and carry around the patch forever)
besides you don't usually need to manipulate inode numbers in php, and 
comparing overflowed number with other overflowed number gets to the 
expected result (is this same file or not)

i'll enabling -D_FILE_OFFSET_BITS=64 now, as it fixed stat() calls 
failures, and pear list works now

$ ls -li /usr/share/pear/PEAR/Installer/Role/Common.php
4306713209 -rw-r--r-- 1 root root 6299 Aug 26  2012 
/usr/share/pear/PEAR/Installer/Role/Common.php
$ php53 -r '$st=stat("/usr/share/pear/PEAR/Installer/Role/Common.php"); 
var_dump($st["ino"]);'
int(11745913)

$ pear list
INSTALLED PACKAGES, CHANNEL PEAR.PHP.NET:
=========================================
PACKAGE          VERSION STATE
Archive_Tar      1.3.10  stable
Console_Getopt   1.3.1   stable
PEAR             1.9.4   stable
PHP_Archive      0.11.4  alpha
Structures_Graph 1.0.4   stable
XML_Util         1.2.1   stable


-- 
glen



From glen at pld-linux.org  Thu May 15 19:51:11 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Thu, 15 May 2014 20:51:11 +0300
Subject: php and LFS
In-Reply-To: <5374FE3B.7000608@pld-linux.org>
References: <537356DB.9060008@pld-linux.org> <20140514134704.GA13665@mail>
 <5373B400.6030909@pld-linux.org> <5373BA4E.5070304@pld-linux.org>
 <20140515170810.GA18719@mail> <5374FE3B.7000608@pld-linux.org>
Message-ID: <5374FE8F.9050006@pld-linux.org>

On 15.05.2014 20:49, Elan Ruusam?e wrote:
> i'll enabling -D_FILE_OFFSET_BITS=64 now, as it fixed stat() calls 
> failures, and pear list works now 
and it's safe to do so unconditionally (including 64bit arches)?

-- 
glen



From glen at pld-linux.org  Thu May 15 23:20:09 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Fri, 16 May 2014 00:20:09 +0300
Subject: /etc/cron.d to filesystem
In-Reply-To: <53678315.2080902@pld-linux.org>
References: <53678315.2080902@pld-linux.org>
Message-ID: <53752F89.5080203@pld-linux.org>

On 05.05.2014 15:24, Elan Ruusam?e wrote:
> rfc: move /etc/cron.d to filesystem package 
what the permission should be?

i would not use any other user than root:root, but our cronie has:

drwxr-x--- 2 root crontab 73 Feb 22 00:49 /etc/cron.d/

and others (in th):

poldek:/all-avail> search -pf /etc/cron.d
Searching packages..........................................done.
3 package(s) found:
cronie-1.4.11-3.i686
fcron-3.1.2-2.i686
hc-cron-0.14-27.i686
poldek:/all-avail>

fcron:
drwxr-x---    2 root    crontab             0 Jan 29 01:22 /etc/cron.d

hc-cron:
drwxr-x---    2 root    root                0 Sep 25  2008 /etc/cron.d


-- 
glen



From baggins at pld-linux.org  Mon May 19 10:26:23 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 19 May 2014 10:26:23 +0200
Subject: /etc/cron.d to filesystem
In-Reply-To: <53752F89.5080203@pld-linux.org>
References: <53678315.2080902@pld-linux.org> <53752F89.5080203@pld-linux.org>
Message-ID: <20140519082621.GC1374@home.lan>

On Fri, 16 May 2014, Elan Ruusam?e wrote:

> On 05.05.2014 15:24, Elan Ruusam?e wrote:
> > rfc: move /etc/cron.d to filesystem package 
> what the permission should be?
> 
> i would not use any other user than root:root, but our cronie has:
> 
> drwxr-x--- 2 root crontab 73 Feb 22 00:49 /etc/cron.d/

If you make this directory 750:root:root cronie's crontab will stop working.
It must be either 750:root:crontab or 755:root:root. I'd leave it with
crontab group and move this group to setup.

-- 
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  Mon May 19 10:32:35 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 19 May 2014 10:32:35 +0200
Subject: php and LFS
In-Reply-To: <5374FE8F.9050006@pld-linux.org>
References: <537356DB.9060008@pld-linux.org> <20140514134704.GA13665@mail>
 <5373B400.6030909@pld-linux.org> <5373BA4E.5070304@pld-linux.org>
 <20140515170810.GA18719@mail> <5374FE3B.7000608@pld-linux.org>
 <5374FE8F.9050006@pld-linux.org>
Message-ID: <20140519083235.GD1374@home.lan>

On Thu, 15 May 2014, Elan Ruusam?e wrote:

> On 15.05.2014 20:49, Elan Ruusam?e wrote:
> > i'll enabling -D_FILE_OFFSET_BITS=64 now, as it fixed stat() calls 
> > failures, and pear list works now 
> and it's safe to do so unconditionally (including 64bit arches)?

AFAIR on 64bit archs it's a no-op, so it's safe.
BTW I got a bit confused, -D_FILE_OFFSET_BITS=64 alone does not affect
performance?

-- 
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  Mon May 19 10:44:24 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Mon, 19 May 2014 11:44:24 +0300
Subject: /etc/cron.d to filesystem
In-Reply-To: <20140519082621.GC1374@home.lan>
References: <53678315.2080902@pld-linux.org> <53752F89.5080203@pld-linux.org>
 <20140519082621.GC1374@home.lan>
Message-ID: <5379C468.1020607@pld-linux.org>

On 19.05.2014 11:26, Jan R?korajski wrote:
> On Fri, 16 May 2014, Elan Ruusam?e wrote:
>
>> On 05.05.2014 15:24, Elan Ruusam?e wrote:
>>> rfc: move /etc/cron.d to filesystem package
>> what the permission should be?
>>
>> i would not use any other user than root:root, but our cronie has:
>>
>> drwxr-x--- 2 root crontab 73 Feb 22 00:49 /etc/cron.d/
> If you make this directory 750:root:root cronie's crontab will stop working.
> It must be either 750:root:crontab or 755:root:root. I'd leave it with
> crontab group and move this group to setup.
>
then the dir should go to setup as well? read comments top of 
filesystem.spec
or we add another exception?

-- 
glen



From baggins at pld-linux.org  Mon May 19 10:50:00 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 19 May 2014 10:50:00 +0200
Subject: /etc/cron.d to filesystem
In-Reply-To: <5379C468.1020607@pld-linux.org>
References: <53678315.2080902@pld-linux.org> <53752F89.5080203@pld-linux.org>
 <20140519082621.GC1374@home.lan> <5379C468.1020607@pld-linux.org>
Message-ID: <20140519085000.GF1374@home.lan>

On Mon, 19 May 2014, Elan Ruusam?e wrote:

> On 19.05.2014 11:26, Jan R?korajski wrote:
> > On Fri, 16 May 2014, Elan Ruusam?e wrote:
> >
> >> On 05.05.2014 15:24, Elan Ruusam?e wrote:
> >>> rfc: move /etc/cron.d to filesystem package
> >> what the permission should be?
> >>
> >> i would not use any other user than root:root, but our cronie has:
> >>
> >> drwxr-x--- 2 root crontab 73 Feb 22 00:49 /etc/cron.d/
> > If you make this directory 750:root:root cronie's crontab will stop working.
> > It must be either 750:root:crontab or 755:root:root. I'd leave it with
> > crontab group and move this group to setup.
> >
> then the dir should go to setup as well? read comments top of 
> filesystem.spec
> or we add another exception?

No exceptions, it should go to setup package in this case.

-- 
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  Mon May 19 11:01:46 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Mon, 19 May 2014 12:01:46 +0300
Subject: /etc/cron.d to filesystem
In-Reply-To: <20140519085000.GF1374@home.lan>
References: <53678315.2080902@pld-linux.org> <53752F89.5080203@pld-linux.org>
 <20140519082621.GC1374@home.lan> <5379C468.1020607@pld-linux.org>
 <20140519085000.GF1374@home.lan>
Message-ID: <5379C87A.2030402@pld-linux.org>

On 19.05.2014 11:50, Jan R?korajski wrote:
> On Mon, 19 May 2014, Elan Ruusam?e wrote:
>
>> On 19.05.2014 11:26, Jan R?korajski wrote:
>>> On Fri, 16 May 2014, Elan Ruusam?e wrote:
>>>
>>>> On 05.05.2014 15:24, Elan Ruusam?e wrote:
>>>>> rfc: move /etc/cron.d to filesystem package
>>>> what the permission should be?
>>>>
>>>> i would not use any other user than root:root, but our cronie has:
>>>>
>>>> drwxr-x--- 2 root crontab 73 Feb 22 00:49 /etc/cron.d/
>>> If you make this directory 750:root:root cronie's crontab will stop working.
>>> It must be either 750:root:crontab or 755:root:root. I'd leave it with
>>> crontab group and move this group to setup.
>>>
>> then the dir should go to setup as well? read comments top of
>> filesystem.spec
>> or we add another exception?
> No exceptions, it should go to setup package in this case.
>

and move the other exceptions too?

-- 
glen



From baggins at pld-linux.org  Mon May 19 12:56:51 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 19 May 2014 12:56:51 +0200
Subject: /etc/cron.d to filesystem
In-Reply-To: <5379C87A.2030402@pld-linux.org>
References: <53678315.2080902@pld-linux.org> <53752F89.5080203@pld-linux.org>
 <20140519082621.GC1374@home.lan> <5379C468.1020607@pld-linux.org>
 <20140519085000.GF1374@home.lan> <5379C87A.2030402@pld-linux.org>
Message-ID: <20140519105651.GH1374@home.lan>

On Mon, 19 May 2014, Elan Ruusam?e wrote:

> On 19.05.2014 11:50, Jan R?korajski wrote:
> > On Mon, 19 May 2014, Elan Ruusam?e wrote:
> >
> >> On 19.05.2014 11:26, Jan R?korajski wrote:
> >>> On Fri, 16 May 2014, Elan Ruusam?e wrote:
> >>>
> >>>> On 05.05.2014 15:24, Elan Ruusam?e wrote:
> >>>>> rfc: move /etc/cron.d to filesystem package
> >>>> what the permission should be?
> >>>>
> >>>> i would not use any other user than root:root, but our cronie has:
> >>>>
> >>>> drwxr-x--- 2 root crontab 73 Feb 22 00:49 /etc/cron.d/
> >>> If you make this directory 750:root:root cronie's crontab will stop working.
> >>> It must be either 750:root:crontab or 755:root:root. I'd leave it with
> >>> crontab group and move this group to setup.
> >>>
> >> then the dir should go to setup as well? read comments top of
> >> filesystem.spec
> >> or we add another exception?
> > No exceptions, it should go to setup package in this case.
> >
> 
> and move the other exceptions too?

I don't see dirs not owned by root in filesystem.spec.

-- 
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  Mon May 19 13:12:06 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Mon, 19 May 2014 14:12:06 +0300
Subject: /etc/cron.d to filesystem
In-Reply-To: <20140519105651.GH1374@home.lan>
References: <53678315.2080902@pld-linux.org> <53752F89.5080203@pld-linux.org>
 <20140519082621.GC1374@home.lan> <5379C468.1020607@pld-linux.org>
 <20140519085000.GF1374@home.lan> <5379C87A.2030402@pld-linux.org>
 <20140519105651.GH1374@home.lan>
Message-ID: <5379E706.10004@pld-linux.org>

On 19.05.2014 13:56, Jan R?korajski wrote:
>> >
>> >and move the other exceptions too?
> I don't see dirs not owned by root in filesystem.spec.

look closer! trace gid_logs macro

-- 
glen



From glen at delfi.ee  Mon May 19 20:39:20 2014
From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Mon, 19 May 2014 21:39:20 +0300
Subject: /dev/null permissions
Message-ID: <537A4FD8.7070108@delfi.ee>

something funny is happening on one of my machine

/dev/null permissions get reset to 660 (which is common for root umask 7 
i'm using)
i have not found pattern in how or when it gets changed
i have stopped crond and still /dev/null premissions get reset to 660 
opposed to sane 666 permission

i've added auditd rule to track this, but unfortunately it's not giving 
any useful information how the permissions get reset to 660

my /etc/audit/audit.rules:
-D
-b 320
-w /dev/null -p a


any ideas:
1) wtf causes this?
2) how to try to audit system to figure it out?

i'm thinking something running as root is "fixing" it's own permissions 
via fchmod which is "accidentally" linked to /dev/fd/2 => /dev/null
i've tried to mv /dev/null /dev/null1; mknod /dev/null, but that did not 
stop the activities in that system


-- 
glen



From baggins at pld-linux.org  Mon May 19 21:11:55 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 19 May 2014 21:11:55 +0200
Subject: /etc/cron.d to filesystem
In-Reply-To: <5379E706.10004@pld-linux.org>
References: <53678315.2080902@pld-linux.org> <53752F89.5080203@pld-linux.org>
 <20140519082621.GC1374@home.lan> <5379C468.1020607@pld-linux.org>
 <20140519085000.GF1374@home.lan> <5379C87A.2030402@pld-linux.org>
 <20140519105651.GH1374@home.lan> <5379E706.10004@pld-linux.org>
Message-ID: <20140519191155.GA1392@home.lan>

On Mon, 19 May 2014, Elan Ruusam?e wrote:

> On 19.05.2014 13:56, Jan R?korajski wrote:
> >> >
> >> >and move the other exceptions too?
> > I don't see dirs not owned by root in filesystem.spec.
> 
> look closer! trace gid_logs macro

Found it, after looking into system and filesystem packages, I think we
should make an excteption after all. system contains only minimal set of
files and no foreign dirs, and filesystem is the place for it.

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


From lukaszgl at post.pl  Tue May 20 10:40:29 2014
From: lukaszgl at post.pl (Lukasz Glebicki)
Date: Tue, 20 May 2014 10:40:29 +0200
Subject: Chromium html5 (h264) video
Message-ID: <3141855.pX5KEMkciQ@inhell>

Hi,

Is there any  way to watch video in h.264 format in newest Chromium or 
permanently switch it off?

Test case: http://www.quirksmode.org/html5/tests/video.html

As a workaround, I set a browser user agent to Opera and flash player is used 
on YT.

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


From glen at delfi.ee  Tue May 20 13:29:07 2014
From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Tue, 20 May 2014 14:29:07 +0300
Subject: Chromium html5 (h264) video
In-Reply-To: <3141855.pX5KEMkciQ@inhell>
References: <3141855.pX5KEMkciQ@inhell>
Message-ID: <537B3C83.3040002@delfi.ee>

On 20.05.2014 11:40, Lukasz Glebicki wrote:
> Hi,
>
> Is there any  way to watch video in h.264 format in newest Chromium or
> permanently switch it off?

i've noticed too it's broken. but feel free to patch our chromium build 
to fix!

> Test case: http://www.quirksmode.org/html5/tests/video.html
>
> As a workaround, I set a browser user agent to Opera and flash player is used
> on YT.
i use google chrome package as workaround and hope next branch build 
will just work :(
>
> Regards,


-- 
glen



From glen at pld-linux.org  Wed May 21 22:52:31 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Wed, 21 May 2014 23:52:31 +0300
Subject: php and LFS
In-Reply-To: <20140519083235.GD1374@home.lan>
References: <537356DB.9060008@pld-linux.org> <20140514134704.GA13665@mail>
 <5373B400.6030909@pld-linux.org> <5373BA4E.5070304@pld-linux.org>
 <20140515170810.GA18719@mail> <5374FE3B.7000608@pld-linux.org>
 <5374FE8F.9050006@pld-linux.org> <20140519083235.GD1374@home.lan>
Message-ID: <537D120F.3030105@pld-linux.org>

On 19.05.2014 11:32, Jan R?korajski wrote:
> On Thu, 15 May 2014, Elan Ruusam?e wrote:
>
>> On 15.05.2014 20:49, Elan Ruusam?e wrote:
>>> i'll enabling -D_FILE_OFFSET_BITS=64 now, as it fixed stat() calls
>>> failures, and pear list works now
>> and it's safe to do so unconditionally (including 64bit arches)?
> AFAIR on 64bit archs it's a no-op, so it's safe.
> BTW I got a bit confused, -D_FILE_OFFSET_BITS=64 alone does not affect
> performance?
>
so...
- appears it's not safe change
- it's not NOOP on x64_64

bulding with -D_FILE_OFFSET_BITS=64 [1] made pear fail on all three 
arches (x86_64, i686, i486)

did not get any clear indication why it failed, just exited with 255 
error, nothing useful when stracing.
to debug, run "builder -bp php-pear-Archive_Tar" (or any other pear 
package that uses pear to unpack)

i've built two versions of php on same machine, with [2] and without [3] 
the define. both directories contain poldek indexes and build.log

[1] 
http://git.pld-linux.org/?p=packages/php.git;a=commitdiff;h=a0106ed918ffc6ff961caa33a8e27003bcfc3133
[2] http://carme.pld-linux.org/~glen/th/x86_64/_FILE_OFFSET_BITS/on/
[3] http://carme.pld-linux.org/~glen/th/x86_64/_FILE_OFFSET_BITS/off/

you need php53-{program,xml,pcre,zlib} packages for pear to work

perhaps the problem is that it the flag not be used alone? perhaps zlib 
or libxml should be built with same cflags? i don't know.

-- 
glen



From glen at pld-linux.org  Wed May 21 23:00:16 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Thu, 22 May 2014 00:00:16 +0300
Subject: php and LFS
In-Reply-To: <537D120F.3030105@pld-linux.org>
References: <537356DB.9060008@pld-linux.org> <20140514134704.GA13665@mail>
 <5373B400.6030909@pld-linux.org> <5373BA4E.5070304@pld-linux.org>
 <20140515170810.GA18719@mail> <5374FE3B.7000608@pld-linux.org>
 <5374FE8F.9050006@pld-linux.org> <20140519083235.GD1374@home.lan>
 <537D120F.3030105@pld-linux.org>
Message-ID: <537D13E0.2080400@pld-linux.org>

On 21.05.2014 23:52, Elan Ruusam?e wrote:
> perhaps the problem is that it the flag not be used alone? perhaps 
> zlib or libxml should be built with same cflags? i don't know. 
i'm almost sure it's zlib related, because:

$ rm -rf root
$ pear  install --packagingroot=`pwd`/root --offline --nodeps 
ConsoleTools-1.6.1.tgz
$ pear  install --packagingroot=`pwd`/root --offline --nodeps 
ConsoleTools-1.6.1.tar
warning: channel://components.ez.no/ConsoleTools-1.6.1 requires package 
"channel://components.ez.no/Base" (version >= 1.8)
install ok: channel://components.ez.no/ConsoleTools-1.6.1
$

-- 
glen



From glen at delfi.ee  Thu May 22 12:20:39 2014
From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Thu, 22 May 2014 13:20:39 +0300
Subject: /dev/null permissions
In-Reply-To: <537A4FD8.7070108@delfi.ee>
References: <537A4FD8.7070108@delfi.ee>
Message-ID: <537DCF77.8040709@delfi.ee>

this has "escalated" to one of my vservers.
which is weird as i thought vservers can't alter permissions of device 
nodes.

crw-rw---- 1 root root 1, 3 Jul  8  2008 /dev/null

i'm suspecting bash being the cause of the poison, as it was recently 
updated there

# rpm -q bash --blink
bash-4.3.11-1.i686.rpm
         <= bash-4.3.0-1.i686.rpm


On 19.05.2014 21:39, Elan Ruusam?e wrote:
> something funny is happening on one of my machine
>
> /dev/null permissions get reset to 660 (which is common for root umask 
> 7 i'm using)
> i have not found pattern in how or when it gets changed
> i have stopped crond and still /dev/null premissions get reset to 660 
> opposed to sane 666 permission
>
> i've added auditd rule to track this, but unfortunately it's not 
> giving any useful information how the permissions get reset to 660
>
> my /etc/audit/audit.rules:
> -D
> -b 320
> -w /dev/null -p a
>
>
> any ideas:
> 1) wtf causes this?
> 2) how to try to audit system to figure it out?
>
> i'm thinking something running as root is "fixing" it's own 
> permissions via fchmod which is "accidentally" linked to /dev/fd/2 => 
> /dev/null
> i've tried to mv /dev/null /dev/null1; mknod /dev/null, but that did 
> not stop the activities in that system
>
>


-- 
glen



From qboosh at pld-linux.org  Thu May 22 19:43:33 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 22 May 2014 19:43:33 +0200
Subject: [packages/gcc] - up to 4.8.3
In-Reply-To: <5dcd2eaf8f2540888ad85c6f5e6d59dc92972353_refs_heads_master@pld-linux.org>
References: <d5c21f86ac9799e413aa1c2fccf771ced955e056_refs_heads_master@pld-linux.org>
 <5dcd2eaf8f2540888ad85c6f5e6d59dc92972353_refs_heads_master@pld-linux.org>
Message-ID: <20140522174333.GA17265@mail>

On Thu, May 22, 2014 at 03:24:06PM +0200, arekm wrote:
> commit 5dcd2eaf8f2540888ad85c6f5e6d59dc92972353
> Author: Arkadiusz Mi?kiewicz <arekm at maven.pl>
> Date:   Thu May 22 15:24:00 2014 +0200
> 
>     - up to 4.8.3
> 
>  gcc.spec | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)

Maybe let's switch off gcc_libffi and use libffi.spec now?
(or we can postpone the switch to gcc 4.9)


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


From glen at delfi.ee  Thu May 22 23:42:52 2014
From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Fri, 23 May 2014 00:42:52 +0300
Subject: /dev/null permissions - "solved"
In-Reply-To: <537DCF77.8040709@delfi.ee>
References: <537A4FD8.7070108@delfi.ee> <537DCF77.8040709@delfi.ee>
Message-ID: <537E6F5C.1010508@delfi.ee>

FUCK YOU ORACLE & PHP!

each time i run php with pdo-oci installed (compiled with 
oracle-instantclient 12.1.0.1.0) while having umask 007, /dev/null gets 
fucked up to 0660 permission.

... it's like punishment for running php as root!

root at rotten-fruit# chmod 777 /dev/null; ls -l /dev/null; umask 7; php -n 
-m; ls -l /dev/null
crwxrwxrwx 1 root root 1, 3 mai   13 12:28 /dev/null
[PHP Modules]
Core
date
ereg
libxml
Reflection
standard

[Zend Modules]

crwxrwxrwx 1 root root 1, 3 mai   13 12:28 /dev/null


root at rotten-fruit# chmod 777 /dev/null; ls -l /dev/null; umask 7; php -n 
-dextension=spl.so -dextension=pdo.so -dextension=pdo_oci.so -m; ls -l 
/dev/null

crwxrwxrwx 1 root root 1, 3 mai   13 12:28 /dev/null

[PHP Modules]
Core
date
ereg
libxml
PDO
PDO_OCI
Reflection
SPL
standard

[Zend Modules]

crwxrwx--- 1 root root 1, 3 mai   13 12:28 /dev/null



On 22.05.2014 13:20, Elan Ruusam?e wrote:
> this has "escalated" to one of my vservers.
> which is weird as i thought vservers can't alter permissions of device 
> nodes.
>
> crw-rw---- 1 root root 1, 3 Jul  8  2008 /dev/null
>
> i'm suspecting bash being the cause of the poison, as it was recently 
> updated there
>
> # rpm -q bash --blink
> bash-4.3.11-1.i686.rpm
>         <= bash-4.3.0-1.i686.rpm
>
>
> On 19.05.2014 21:39, Elan Ruusam?e wrote:
>> something funny is happening on one of my machine
>>
>> /dev/null permissions get reset to 660 (which is common for root 
>> umask 7 i'm using)
>> i have not found pattern in how or when it gets changed
>> i have stopped crond and still /dev/null premissions get reset to 660 
>> opposed to sane 666 permission
>>
>> i've added auditd rule to track this, but unfortunately it's not 
>> giving any useful information how the permissions get reset to 660
>>
>> my /etc/audit/audit.rules:
>> -D
>> -b 320
>> -w /dev/null -p a
>>
>>
>> any ideas:
>> 1) wtf causes this?
>> 2) how to try to audit system to figure it out?
>>
>> i'm thinking something running as root is "fixing" it's own 
>> permissions via fchmod which is "accidentally" linked to /dev/fd/2 => 
>> /dev/null
>> i've tried to mv /dev/null /dev/null1; mknod /dev/null, but that did 
>> not stop the activities in that system
>>
>>
>
>


-- 
glen



From glen at delfi.ee  Thu May 22 23:55:15 2014
From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Fri, 23 May 2014 00:55:15 +0300
Subject: /dev/null permissions - solved!
In-Reply-To: <537E6F5C.1010508@delfi.ee>
References: <537A4FD8.7070108@delfi.ee> <537DCF77.8040709@delfi.ee>
 <537E6F5C.1010508@delfi.ee>
Message-ID: <537E7243.1040602@delfi.ee>

ok, those two subjects aren't only ones to blame, seems "my 
configuration" has caused this.
more particularily, a sqlnet.ora parameter:

LOG_FILE_CLIENT = /dev/null

which i took from 
http://archimedeseureka.blogspot.com/2011/08/disabling-logging-for-oracle-instant.html

On 23.05.2014 00:42, Elan Ruusam?e wrote:
> FUCK YOU ORACLE & PHP!
>
> each time i run php with pdo-oci installed (compiled with 
> oracle-instantclient 12.1.0.1.0) while having umask 007, /dev/null 
> gets fucked up to 0660 permission.
>
> ... it's like punishment for running php as root!
>
> root at rotten-fruit# chmod 777 /dev/null; ls -l /dev/null; umask 7; php 
> -n -m; ls -l /dev/null
> crwxrwxrwx 1 root root 1, 3 mai   13 12:28 /dev/null
> [PHP Modules]
> Core
> date
> ereg
> libxml
> Reflection
> standard
>
> [Zend Modules]
>
> crwxrwxrwx 1 root root 1, 3 mai   13 12:28 /dev/null
>
>
> root at rotten-fruit# chmod 777 /dev/null; ls -l /dev/null; umask 7; php 
> -n -dextension=spl.so -dextension=pdo.so -dextension=pdo_oci.so -m; ls 
> -l /dev/null
>
> crwxrwxrwx 1 root root 1, 3 mai   13 12:28 /dev/null
>
> [PHP Modules]
> Core
> date
> ereg
> libxml
> PDO
> PDO_OCI
> Reflection
> SPL
> standard
>
> [Zend Modules]
>
> crwxrwx--- 1 root root 1, 3 mai   13 12:28 /dev/null
>
>
>
> On 22.05.2014 13:20, Elan Ruusam?e wrote:
>> this has "escalated" to one of my vservers.
>> which is weird as i thought vservers can't alter permissions of 
>> device nodes.
>>
>> crw-rw---- 1 root root 1, 3 Jul  8  2008 /dev/null
>>
>> i'm suspecting bash being the cause of the poison, as it was recently 
>> updated there
>>
>> # rpm -q bash --blink
>> bash-4.3.11-1.i686.rpm
>>         <= bash-4.3.0-1.i686.rpm
>>
>>
>> On 19.05.2014 21:39, Elan Ruusam?e wrote:
>>> something funny is happening on one of my machine
>>>
>>> /dev/null permissions get reset to 660 (which is common for root 
>>> umask 7 i'm using)
>>> i have not found pattern in how or when it gets changed
>>> i have stopped crond and still /dev/null premissions get reset to 
>>> 660 opposed to sane 666 permission
>>>
>>> i've added auditd rule to track this, but unfortunately it's not 
>>> giving any useful information how the permissions get reset to 660
>>>
>>> my /etc/audit/audit.rules:
>>> -D
>>> -b 320
>>> -w /dev/null -p a
>>>
>>>
>>> any ideas:
>>> 1) wtf causes this?
>>> 2) how to try to audit system to figure it out?
>>>
>>> i'm thinking something running as root is "fixing" it's own 
>>> permissions via fchmod which is "accidentally" linked to /dev/fd/2 
>>> => /dev/null
>>> i've tried to mv /dev/null /dev/null1; mknod /dev/null, but that did 
>>> not stop the activities in that system
>>>
>>>
>>
>>
>
>


-- 
glen



From aredridel at nbtsc.org  Fri May 23 01:22:17 2014
From: aredridel at nbtsc.org (Aria Stewart)
Date: Thu, 22 May 2014 19:22:17 -0400
Subject: /dev/null permissions - solved!
In-Reply-To: <537E7243.1040602@delfi.ee>
References: <537A4FD8.7070108@delfi.ee> <537DCF77.8040709@delfi.ee>
 <537E6F5C.1010508@delfi.ee> <537E7243.1040602@delfi.ee>
Message-ID: <6AA2669A-67F1-430A-8F05-E4EEB301D0E3@nbtsc.org>


On May 22, 02014, at 17:55, Elan Ruusam?e <glen at delfi.ee> wrote:

> ok, those two subjects aren't only ones to blame, seems "my configuration" has caused this.
> more particularily, a sqlnet.ora parameter:
> 
> LOG_FILE_CLIENT = /dev/null
> 
> which i took from http://archimedeseureka.blogspot.com/2011/08/disabling-logging-for-oracle-instant.html


?Enterprise software? = ?We added a configuration so we can blame the customer if it breaks?.

Glad you found it!


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </mailman/pipermail/pld-devel-en/attachments/20140522/71b704f5/attachment.sig>

From glen at pld-linux.org  Mon May 26 21:08:00 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Mon, 26 May 2014 22:08:00 +0300
Subject: enable/disable for cmake
Message-ID: <53839110.6000504@pld-linux.org>

for autotools we have macros for --enable, --disable, --with --without
http://git.pld-linux.org/?p=packages/rpm-build-macros.git;a=blob;f=rpm.macros;h=fb44ba49b4492d80ddf696d04c427b16f9661d96;hb=b89253d0468b9a528a89c47bfc36e7274666310f#l339

would be nice to have same for cmake as well
how to name them?

for cmake it's simplier: need only one macro, as there's only need for 
-DFOO=ON|OFF

-- 
glen



From qboosh at pld-linux.org  Tue May 27 16:39:40 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 27 May 2014 16:39:40 +0200
Subject: enable/disable for cmake
In-Reply-To: <53839110.6000504@pld-linux.org>
References: <53839110.6000504@pld-linux.org>
Message-ID: <20140527143940.GB3826@mail>

On Mon, May 26, 2014 at 10:08:00PM +0300, Elan Ruusam?e wrote:
> for autotools we have macros for --enable, --disable, --with --without
> http://git.pld-linux.org/?p=packages/rpm-build-macros.git;a=blob;f=rpm.macros;h=fb44ba49b4492d80ddf696d04c427b16f9661d96;hb=b89253d0468b9a528a89c47bfc36e7274666310f#l339
> 
> would be nice to have same for cmake as well
> how to name them?
> 
> for cmake it's simplier: need only one macro, as there's only need for 
> -DFOO=ON|OFF

Is there any advantage?
I don't find %{__cmake_on foo FOO} more readable than %{?with_foo:-DFOO=ON}.

I'm already confused sometimes, which argument to __with_without is
bcond name and which is option... __with_unless, __without_if and
__with_without_not are even less straight.


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


From glen at pld-linux.org  Wed May 28 10:20:53 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Wed, 28 May 2014 11:20:53 +0300
Subject: enable/disable for cmake
In-Reply-To: <20140527143940.GB3826@mail>
References: <53839110.6000504@pld-linux.org> <20140527143940.GB3826@mail>
Message-ID: <53859C65.1080707@pld-linux.org>

On 27.05.2014 17:39, Jakub Bogusz wrote:
> On Mon, May 26, 2014 at 10:08:00PM +0300, Elan Ruusam?e wrote:
>> for autotools we have macros for --enable, --disable, --with --without
>> http://git.pld-linux.org/?p=packages/rpm-build-macros.git;a=blob;f=rpm.macros;h=fb44ba49b4492d80ddf696d04c427b16f9661d96;hb=b89253d0468b9a528a89c47bfc36e7274666310f#l339
>>
>> would be nice to have same for cmake as well
>> how to name them?
>>
>> for cmake it's simplier: need only one macro, as there's only need for
>> -DFOO=ON|OFF
> Is there any advantage?
> I don't find %{__cmake_on foo FOO} more readable than %{?with_foo:-DFOO=ON}.
but what if you need to set OFF as well?

is this readable?
     -DWITH_UTEMPTER=O%{!?with_utempter:FF}%{?with_utempter:N} \

it's definately more typing!

> I'm already confused sometimes, which argument to __with_without is
> bcond name and which is option... __with_unless, __without_if and
> __with_without_not are even less straight.
but as said, for cmake imho only one macro needed:

%{__cmake_bool foo}

i don't see point having separate macros for OFF and ON,
we should always set value not depend on project default.


-- 
glen



From glen at pld-linux.org  Wed May 28 10:23:46 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Wed, 28 May 2014 11:23:46 +0300
Subject: [packages/rsync] - updated ac version, more verbose files in
 system dirs
In-Reply-To: <ee3bf8817a1d60c84f7efaf92a8dfc62572b44f5_refs_heads_master@pld-linux.org>
References: <81cacf5def368ae9ce62830dc09e25b57043181d_refs_heads_master@pld-linux.org>
 <ee3bf8817a1d60c84f7efaf92a8dfc62572b44f5_refs_heads_master@pld-linux.org>
Message-ID: <53859D12.5000805@pld-linux.org>

On 28.05.2014 00:31, qboosh wrote:
> +%config(noreplace,missingok) %verify(not md5 mtime size) /etc/env.d/CVSIGNORE
now it came visible, does this env var really belong to rsync package?

-- 
glen