From baggins at pld-linux.org  Mon Dec  1 07:35:08 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 1 Dec 2014 07:35:08 +0100
Subject: Th 2014 snapshot
In-Reply-To: <20141130212056.GB2127@home.lan>
References: <20141130212056.GB2127@home.lan>
Message-ID: <20141201063507.GA2132@home.lan>

On Sun, 30 Nov 2014, Jan R?korajski wrote:

> The current state of Th main/ready is going to become 2014 snapshot
> next weekend (6,7 Dec). If you know of any breakage or want a package
> updated, please report/fix/update it before end of the week.

Quick note, broken packages from th-test are _not_ going to make it,
for example:

error: [blcr.spec] kernel-extra-blcr-0.8.5-1 at 3.17.4_1.x86_64: req /lib/modules/3.17.4-1/extra not found
error: [notification-daemon.spec] notification-daemon-3.14.1-1.x86_64: req /usr/share/locale/quz/LC_MESSAGES not found

additionally blcr.spec is missing multi-kernel support.

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


From glen at pld-linux.org  Thu Dec  4 23:32:17 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Fri, 05 Dec 2014 00:32:17 +0200
Subject: rpm 5.4.15
Message-ID: <5480E0F1.2020705@pld-linux.org>

rpm 5.4.15 introduces new dep:

- libgcc

is it due build environment, or the dependency is intentional?

# poldek -u rpm -tv
Removed 22 duplicate packages from available set
Processing dependencies...
rpm-5.4.14-6.i686 obsoleted by rpm-5.4.15-3.i686
rpm-5.4.15-3.i686 marks rpm-base-5.4.15-3.i686 (cap rpm-base = 5.4.15-3)
  rpm-base-5.4.14-6.i686 obsoleted by rpm-base-5.4.15-3.i686
rpm-5.4.15-3.i686 marks rpm-lib-5.4.15-3.i686 (cap rpm-lib = 5.4.15-3)
  rpm-lib-5.4.14-6.i686 obsoleted by rpm-lib-5.4.15-3.i686
  rpm-lib-5.4.15-3.i686 marks libgcc-4.8.3-3.i686 (cap libgcc_s.so.1)
There are 4 packages to install (3 marked by dependencies), 3 to remove:
I rpm-5.4.15-3.i686
D libgcc-4.8.3-3.i686  rpm-base-5.4.15-3.i686  rpm-lib-5.4.15-3.i686
R rpm-5.4.14-6.i686  rpm-base-5.4.14-6.i686  rpm-lib-5.4.14-6.i686
This operation will use 383.9KB of disk space.
Need to get 2.2MB of archives (2.2MB to download).



-- 
glen



From baggins at pld-linux.org  Sat Dec  6 19:22:15 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 6 Dec 2014 19:22:15 +0100
Subject: Th 2014 snapshot released
Message-ID: <20141206182215.GA2190@home.lan>

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

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


From glen at pld-linux.org  Mon Dec  8 22:12:16 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Mon, 08 Dec 2014 23:12:16 +0200
Subject: [packages/grep] - move from GREP_OPTIONS environmental variable
 to alias due to its   obsolescence
In-Reply-To: <274761483d541b779ab9135532aecf8aadc550e8_refs_heads_master@pld-linux.org>
References: <23ca4364a0c6cf68fca3432a517ec04a28c22e22_refs_heads_master@pld-linux.org>
 <274761483d541b779ab9135532aecf8aadc550e8_refs_heads_master@pld-linux.org>
Message-ID: <54861430.3040103@pld-linux.org>

On 08.12.2014 22:44, adwol wrote:
> commit 274761483d541b779ab9135532aecf8aadc550e8
> Author: Adam Osuchowski <adwol at pld-linux.org>
> Date:   Mon Dec 8 21:41:18 2014 +0100
>
>      - move from GREP_OPTIONS environmental variable to alias due to its
>        obsolescence
a reference to such "obsolescence" ?


> -cat << EOF >$RPM_BUILD_ROOT/etc/env.d/GREP_OPTIONS
> -#GREP_OPTIONS="--binary-files=without-match --directories=skip --color=auto"
> +cat << EOF >$RPM_BUILD_ROOT/etc/shrc.d/grep.sh
> +alias grep='/bin/grep --binary-files=without-match --devices=skip --directories=skip --color=auto'
> +EOF
> +cat << EOF >$RPM_BUILD_ROOT/etc/shrc.d/grep.csh
> +alias grep '/bin/grep --binary-files=without-match --devices=skip --directories=skip --color=auto'
>   EOF
>

this definately is not the same thing as it was before! restore previous 
behaviour by *not* enforcing such options!

-- 
glen



From adwol at zonk.pl  Mon Dec  8 22:30:47 2014
From: adwol at zonk.pl (Adam Osuchowski)
Date: Mon, 8 Dec 2014 22:30:47 +0100
Subject: [packages/grep] - move from GREP_OPTIONS environmental
 variable to alias due to its   obsolescence
In-Reply-To: <54861430.3040103@pld-linux.org>
References: <23ca4364a0c6cf68fca3432a517ec04a28c22e22_refs_heads_master@pld-linux.org>
 <274761483d541b779ab9135532aecf8aadc550e8_refs_heads_master@pld-linux.org>
 <54861430.3040103@pld-linux.org>
Message-ID: <20141208213047.6b8b4567@zonk.pl>

Elan Ruusam?e wrote:
> a reference to such "obsolescence" ?

Did you try to run grep 2.21 with GREP_OPTIONS set even once?
Please try it and search sources for message you will see,
before asking such a question.

> this definately is not the same thing as it was before! restore previous 
> behaviour by *not* enforcing such options!

Any evidences, examples? It is very close to GREP_OPTIONS. The alternative
is to patch sources and disable this warning, but it is not good way
to solve this issue. Please stop yelling and suggest better solution.


From qboosh at pld-linux.org  Tue Dec  9 06:29:43 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 9 Dec 2014 06:29:43 +0100
Subject: [packages/grep] - move from GREP_OPTIONS environmental variable
 to alias due to its obsolescence
In-Reply-To: <20141208213047.6b8b4567@zonk.pl>
References: <23ca4364a0c6cf68fca3432a517ec04a28c22e22_refs_heads_master@pld-linux.org>
 <274761483d541b779ab9135532aecf8aadc550e8_refs_heads_master@pld-linux.org>
 <54861430.3040103@pld-linux.org> <20141208213047.6b8b4567@zonk.pl>
Message-ID: <20141209052943.GA24116@mail>

On Mon, Dec 08, 2014 at 10:30:47PM +0100, Adam Osuchowski wrote:
> Elan Ruusam?e wrote:
[...]
> > this definately is not the same thing as it was before! restore previous 
> > behaviour by *not* enforcing such options!
> 
> Any evidences, examples? It is very close to GREP_OPTIONS. The alternative
> is to patch sources and disable this warning, but it is not good way
> to solve this issue. Please stop yelling and suggest better solution.

GREP_OPTIONS were _disabled_ by default.
Now the alias is not.


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


From arekm at maven.pl  Tue Dec  9 09:09:02 2014
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Tue, 9 Dec 2014 09:09:02 +0100
Subject: cmake macros for dirs
Message-ID: <201412090909.02947.arekm@maven.pl>


Some time ago %cmake macro lost -DINCLUDE_INSTALL_DIR
http://git.pld-linux.org/gitweb.cgi?p=packages/rpm-build-macros.git;a=commitdiff;h=b6ce5bb6a311437b480b901de363d834770f1ab8

According to:
/usr/share/cmake/Modules/GNUInstallDirs.cmake
there are defines for almost every dir example

CMAKE_INSTALL_INCLUDEDIR and so on.

Any ideas why we don't set these in %cmake? That would make
us closer to what %configure gets passed.

According to cmake/kde people mixinx relative and absolute
paths is very bad idea. kf5 fails to build correctly due to that:

http://public.kitware.com/Bug/view.php?id=15258
http://public.kitware.com/pipermail/cmake-developers/2014-December/023877.html


diff --git a/rpm.macros b/rpm.macros
index ab6b88e..d40a5e2 100644
--- a/rpm.macros
+++ b/rpm.macros
@@ -264,7 +264,21 @@ CPPFLAGS="${CPPFLAGS:-%{rpmcppflags}}" \\\
 %{__cmake} \\\
        -DCMAKE_VERBOSE_MAKEFILE=ON \\\
        -DCMAKE_BUILD_TYPE=%{!?debug:PLD}%{?debug:Debug} \\\
+       -DCMAKE_INSTALL_BINDIR:PATH=%{_bindir} \\\
+       -DCMAKE_INSTALL_SBINDIR:PATH=%{_sbindir} \\\
+       -DCMAKE_INSTALL_LIBEXECDIR:PATH=%{_libexecdir} \\\
+       -DCMAKE_INSTALL_SYSCONFDIR:PATH=%{_sysconfdir} \\\
+       -DCMAKE_INSTALL_SHAREDSTATEDIRPATH=%{_sharedstatedir} \\\
+       -DCMAKE_INSTALL_LOCALSTATEDIRPATH=%{_localstatedir} \\\
        -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir} \\\
+       -DCMAKE_INSTALL_INCLUDEDIR:PATH=%{_includedir} \\\
+       -DCMAKE_INSTALL_OLDINCLUDEDIR:PATH=%{_includedir} \\\
+       -DCMAKE_INSTALL_DATAROOTDIR:PATH=%{_datadir} \\\
+       -DCMAKE_INSTALL_DATADIR:PATH=%{_datadir} \\\
+       -DCMAKE_INSTALL_INFODIR:PATH=%{_infodir} \\\
+       -DCMAKE_INSTALL_LOCALEDIR:PATH=%{_localedir} \\\
+       -DCMAKE_INSTALL_MANDIR:PATH=%{_mandir} \\\
+       -DCMAKE_INSTALL_DOCDIR:PATH=%{_docdir} \\\
        -DCMAKE_INSTALL_PREFIX:PATH=%{_prefix} \\\
        -DSYSCONF_INSTALL_DIR:PATH=%{_sysconfdir} \\\
        -DCMAKE_CXX_FLAGS_PLD="${CXXFLAGS:-%{rpmcxxflags} -DNDEBUG -DQT_NO_DEBUG}" \\\

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


From qboosh at pld-linux.org  Tue Dec  9 16:01:07 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 9 Dec 2014 16:01:07 +0100
Subject: cmake macros for dirs
In-Reply-To: <201412090909.02947.arekm@maven.pl>
References: <201412090909.02947.arekm@maven.pl>
Message-ID: <20141209150107.GA1541@mail>

On Tue, Dec 09, 2014 at 09:09:02AM +0100, Arkadiusz Mi?kiewicz wrote:
> 
> Some time ago %cmake macro lost -DINCLUDE_INSTALL_DIR
> http://git.pld-linux.org/gitweb.cgi?p=packages/rpm-build-macros.git;a=commitdiff;h=b6ce5bb6a311437b480b901de363d834770f1ab8

INCLUDE_INSTALL_DIR != CMAKE_INCLUDE_INSTALL_DIR
See comment inside for explanation.

> According to:
> /usr/share/cmake/Modules/GNUInstallDirs.cmake
> there are defines for almost every dir example
> 
> CMAKE_INSTALL_INCLUDEDIR and so on.
> 
> Any ideas why we don't set these in %cmake? That would make
> us closer to what %configure gets passed.

AFAIR there was no GNUInstallDirs.cmake at the time of adjusting %cmake
macro.

For standardized variable names it's OK to have them defined.
The only problem for cmake is that most of these macros have relative
default values which causes some developers to (mis)think they're always
relative - thus probably some packages would require fixing.


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


From arekm at maven.pl  Wed Dec 10 12:46:26 2014
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Wed, 10 Dec 2014 12:46:26 +0100
Subject: [packages/grep] - move from GREP_OPTIONS environmental variable
 to alias due to its obsolescence
In-Reply-To: <54861430.3040103@pld-linux.org>
References: <23ca4364a0c6cf68fca3432a517ec04a28c22e22_refs_heads_master@pld-linux.org>
 <274761483d541b779ab9135532aecf8aadc550e8_refs_heads_master@pld-linux.org>
 <54861430.3040103@pld-linux.org>
Message-ID: <201412101246.26382.arekm@maven.pl>

On Monday 08 of December 2014, Elan Ruusam?e wrote:
> On 08.12.2014 22:44, adwol wrote:
> > commit 274761483d541b779ab9135532aecf8aadc550e8
> > Author: Adam Osuchowski <adwol at pld-linux.org>
> > Date:   Mon Dec 8 21:41:18 2014 +0100
> > 
> >      - move from GREP_OPTIONS environmental variable to alias due to its
> >      
> >        obsolescence
> 
> a reference to such "obsolescence" ?
> 
> > -cat << EOF >$RPM_BUILD_ROOT/etc/env.d/GREP_OPTIONS
> > -#GREP_OPTIONS="--binary-files=without-match --directories=skip
> > --color=auto" +cat << EOF >$RPM_BUILD_ROOT/etc/shrc.d/grep.sh
> > +alias grep='/bin/grep --binary-files=without-match --devices=skip
> > --directories=skip --color=auto' +EOF
> > +cat << EOF >$RPM_BUILD_ROOT/etc/shrc.d/grep.csh
> > +alias grep '/bin/grep --binary-files=without-match --devices=skip
> > --directories=skip --color=auto'
> > 
> >   EOF
> 
> this definately is not the same thing as it was before! restore previous
> behaviour by *not* enforcing such options!

Maybe something like that would be better?

# cat /etc/shrc.d/grep.sh
if [ -r /etc/env.d/GREP_OPTIONS ]; then
        unset GREP_OPTIONS
        . /etc/env.d/GREP_OPTIONS
        if [ -n "$GREP_OPTIONS" ]; then
                alias grep="/bin/grep $GREP_OPTIONS"
                unset GREP_OPTIONS
        fi
fi

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


From jajcus at jajcus.net  Wed Dec 10 13:50:37 2014
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 10 Dec 2014 13:50:37 +0100
Subject: [packages/grep] - move from GREP_OPTIONS environmental variable
 to alias due to its obsolescence
In-Reply-To: <201412101246.26382.arekm@maven.pl>
References: <23ca4364a0c6cf68fca3432a517ec04a28c22e22_refs_heads_master@pld-linux.org>
 <274761483d541b779ab9135532aecf8aadc550e8_refs_heads_master@pld-linux.org>
 <54861430.3040103@pld-linux.org> <201412101246.26382.arekm@maven.pl>
Message-ID: <5488419D.7050801@jajcus.net>

On 10/12/14 12:46, Arkadiusz Mi?kiewicz wrote:
> 
> Maybe something like that would be better?
> 
> # cat /etc/shrc.d/grep.sh
> if [ -r /etc/env.d/GREP_OPTIONS ]; then
>         unset GREP_OPTIONS
>         . /etc/env.d/GREP_OPTIONS
>         if [ -n "$GREP_OPTIONS" ]; then
>                 alias grep="/bin/grep $GREP_OPTIONS"
>                 unset GREP_OPTIONS
>         fi
> fi
> 


Why?

If anybody needs custom options to any shell command he can prepare an
alias that suits him and his shell most.

Implementing any such non-standard behaviour in the distribution is a
very bad idea. Not only we make the shell load ages to initialize
features most users don't even know about, but we may find great
fuck-ups years later, like this one:

http://seclists.org/fulldisclosure/2014/Nov/74

Jacek


From glen at pld-linux.org  Wed Dec 10 14:00:58 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Wed, 10 Dec 2014 15:00:58 +0200
Subject: [packages/grep] - move from GREP_OPTIONS environmental variable
 to alias due to its obsolescence
In-Reply-To: <5488419D.7050801@jajcus.net>
References: <23ca4364a0c6cf68fca3432a517ec04a28c22e22_refs_heads_master@pld-linux.org>
 <274761483d541b779ab9135532aecf8aadc550e8_refs_heads_master@pld-linux.org>
 <54861430.3040103@pld-linux.org> <201412101246.26382.arekm@maven.pl>
 <5488419D.7050801@jajcus.net>
Message-ID: <5488440A.4020406@pld-linux.org>

On 10.12.2014 14:50, Jacek Konieczny wrote:
> If anybody needs custom options to any shell command he can prepare an
> alias that suits him and his shell most.
so as original changeset author is not making any movements (adwol), 
let's remove the aliases completely.

i totally dislike such alias being enabled by default. i have my own, 
and this one will ovewrite mine (because it's after entry in shrc.d)

as for alias itself, no need to specify full path, alias grep="grep 
--color=always" works fine, is not recursive, it's recursive if you use 
function, and there you can use \grep:

grep() {
   \grep --color=always "$@"
}

above works for bash, others can use "builtin" or "command" prefix.

-- 
glen



From arekm at maven.pl  Wed Dec 10 14:14:41 2014
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Wed, 10 Dec 2014 14:14:41 +0100
Subject: [packages/grep] - move from GREP_OPTIONS environmental variable
 to alias due to its obsolescence
In-Reply-To: <5488419D.7050801@jajcus.net>
References: <23ca4364a0c6cf68fca3432a517ec04a28c22e22_refs_heads_master@pld-linux.org>
 <201412101246.26382.arekm@maven.pl> <5488419D.7050801@jajcus.net>
Message-ID: <201412101414.41206.arekm@maven.pl>

On Wednesday 10 of December 2014, Jacek Konieczny wrote:
> On 10/12/14 12:46, Arkadiusz Mi?kiewicz wrote:
> > Maybe something like that would be better?
> > 
> > # cat /etc/shrc.d/grep.sh
> > if [ -r /etc/env.d/GREP_OPTIONS ]; then
> > 
> >         unset GREP_OPTIONS
> >         . /etc/env.d/GREP_OPTIONS
> >         if [ -n "$GREP_OPTIONS" ]; then
> >         
> >                 alias grep="/bin/grep $GREP_OPTIONS"
> >                 unset GREP_OPTIONS
> >         
> >         fi
> > 
> > fi
> 
> Why?

For backward compat with what we had so far.

> If anybody needs custom options to any shell command he can prepare an
> alias that suits him and his shell most.
> 
> Implementing any such non-standard behaviour in the distribution is a
> very bad idea. Not only we make the shell load ages to initialize
> features most users don't even know about, but we may find great
> fuck-ups years later, like this one:
> 
> http://seclists.org/fulldisclosure/2014/Nov/74

Fine with me. Rel 3.

> Jacek

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


From jajcus at jajcus.net  Wed Dec 10 14:38:20 2014
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 10 Dec 2014 14:38:20 +0100
Subject: [packages/grep] - move from GREP_OPTIONS environmental variable
 to alias due to its obsolescence
In-Reply-To: <201412101414.41206.arekm@maven.pl>
References: <23ca4364a0c6cf68fca3432a517ec04a28c22e22_refs_heads_master@pld-linux.org>
 <201412101246.26382.arekm@maven.pl> <5488419D.7050801@jajcus.net>
 <201412101414.41206.arekm@maven.pl>
Message-ID: <54884CCC.4050202@jajcus.net>

On 10/12/14 14:14, Arkadiusz Mi?kiewicz wrote:
> On Wednesday 10 of December 2014, Jacek Konieczny wrote:
>> On 10/12/14 12:46, Arkadiusz Mi?kiewicz wrote:
>>> Maybe something like that would be better?
>>>
>>> # cat /etc/shrc.d/grep.sh
>>> if [ -r /etc/env.d/GREP_OPTIONS ]; then
>>>
>>>         unset GREP_OPTIONS
>>>         . /etc/env.d/GREP_OPTIONS
>>>         if [ -n "$GREP_OPTIONS" ]; then
>>>         
>>>                 alias grep="/bin/grep $GREP_OPTIONS"
>>>                 unset GREP_OPTIONS
>>>         
>>>         fi
>>>
>>> fi
>>
>> Why?
> 
> For backward compat with what we had so far.

Such a shell script for any interactive shell started, just because one
or two PLD users have uncommented the /etc/env.d/GREP_OPTIONS we might
have wrongly introduced long time ago?

I don't think it is worth it.

Keeping backward compatibility for any strange feature we might have
once thought it was a good idea would only make more and more mess in
our distribution. I would say: let's break compatibility whenever we can
get things simpler/safer/more functional this way and the compatibility
cost is not too big. If the system won't boot because of the change,
then it might be a good idea to introduce backward-compatibility hack.
This is not such a case.

Jacek



From adwol at zonk.pl  Wed Dec 10 20:38:39 2014
From: adwol at zonk.pl (Adam Osuchowski)
Date: Wed, 10 Dec 2014 20:38:39 +0100
Subject: [packages/grep] - move from GREP_OPTIONS environmental
 variable to alias due to its obsolescence
In-Reply-To: <5488440A.4020406@pld-linux.org>
References: <23ca4364a0c6cf68fca3432a517ec04a28c22e22_refs_heads_master@pld-linux.org>
 <274761483d541b779ab9135532aecf8aadc550e8_refs_heads_master@pld-linux.org>
 <54861430.3040103@pld-linux.org> <201412101246.26382.arekm@maven.pl>
 <5488419D.7050801@jajcus.net> <5488440A.4020406@pld-linux.org>
Message-ID: <20141210193839.6b8b4567@zonk.pl>

Elan Ruusam?e wrote:
> i totally dislike such alias being enabled by default. i have my own, and 
> this one will ovewrite mine (because it's after entry in shrc.d)

Really? Since when ~/.bashrc, ~/.zshrc, etc. is interpreted _before_
/etc/shrc.d? If you don't like system aliases unalias them or redefine
in startup scripts.


From baggins at pld-linux.org  Wed Dec 10 20:59:40 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Wed, 10 Dec 2014 20:59:40 +0100
Subject: [packages/kernel] - updated config
In-Reply-To: <5fc1b244b3f356be6ea05dd183f0feba7e0c8276_refs_heads_master@pld-linux.org>
References: <e26ee53e41dbb757544e2857f019a4e7974f4712_refs_heads_master@pld-linux.org>
 <5fc1b244b3f356be6ea05dd183f0feba7e0c8276_refs_heads_master@pld-linux.org>
Message-ID: <20141210195939.GA2256@home.lan>

On Wed, 10 Dec 2014, arekm wrote:

> commit 5fc1b244b3f356be6ea05dd183f0feba7e0c8276
> Author: Arkadiusz Mi?kiewicz <arekm at maven.pl>
> Date:   Wed Dec 10 20:49:52 2014 +0100
> 
>     - updated config
> 
>  kernel-multiarch.config | 193 +++++++++++++++++++++++++++++++++++-------------
>  1 file changed, 141 insertions(+), 52 deletions(-)
> ---
> diff --git a/kernel-multiarch.config b/kernel-multiarch.config
> index 6b2be85..cdc3ce1 100644
> --- a/kernel-multiarch.config
> +++ b/kernel-multiarch.config
...
> @@ -8219,6 +8286,9 @@ MODVERSIONS all=n
>  MODULE_SRCVERSION_ALL all=n
>  MODULE_SIG all=n
>  #- Do not forget to sign required modules with scripts/sign-file
> +MODULE_COMPRESS all=y
> +MODULE_COMPRESS_GZIP all=y
> +MODULE_COMPRESS_XZ all=n
>  STOP_MACHINE all=y
>  #- file block/Kconfig goes here
>  #- file kernel/Kconfig.locks goes here

What about switching to xz? That will require recent kmod, but we do it
only for 3.18+ and if someone is running fresh kernel we can assume he
has a fresh userspace.

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


From arekm at maven.pl  Wed Dec 10 21:04:43 2014
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Wed, 10 Dec 2014 21:04:43 +0100
Subject: [packages/kernel] - updated config
In-Reply-To: <20141210195939.GA2256@home.lan>
References: <e26ee53e41dbb757544e2857f019a4e7974f4712_refs_heads_master@pld-linux.org>
 <5fc1b244b3f356be6ea05dd183f0feba7e0c8276_refs_heads_master@pld-linux.org>
 <20141210195939.GA2256@home.lan>
Message-ID: <201412102104.43093.arekm@maven.pl>

On Wednesday 10 of December 2014, Jan R?korajski wrote:

> > +MODULE_COMPRESS all=y
> > +MODULE_COMPRESS_GZIP all=y
> > +MODULE_COMPRESS_XZ all=n
> > 
> >  STOP_MACHINE all=y
> >  #- file block/Kconfig goes here
> >  #- file kernel/Kconfig.locks goes here
> 
> What about switching to xz? That will require recent kmod, but we do it
> only for 3.18+ and if someone is running fresh kernel we can assume he
> has a fresh userspace.

And recent geninitrd (if geninitrd is used). 

I actually use xz on my laptop (git based kernel), so I'm fine with using xz 
by default.

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


From adwol at zonk.pl  Wed Dec 10 21:10:29 2014
From: adwol at zonk.pl (Adam Osuchowski)
Date: Wed, 10 Dec 2014 21:10:29 +0100
Subject: [packages/grep] - move from GREP_OPTIONS environmental
 variable to alias due to its obsolescence
In-Reply-To: <54884CCC.4050202@jajcus.net>
References: <23ca4364a0c6cf68fca3432a517ec04a28c22e22_refs_heads_master@pld-linux.org>
 <201412101246.26382.arekm@maven.pl> <5488419D.7050801@jajcus.net>
 <201412101414.41206.arekm@maven.pl> <54884CCC.4050202@jajcus.net>
Message-ID: <20141210201029.327b23c6@zonk.pl>

Jacek Konieczny wrote:
> Such a shell script for any interactive shell started, just because one
> or two PLD users have uncommented the /etc/env.d/GREP_OPTIONS we might
> have wrongly introduced long time ago?

There are no difference between putting grep's options into alias and
into $GREP_OPTIONS since grep automatically interprets this variable.
They both have same security and other impacts. If grep developers hadn't
decided to obsolete support for this variable, it would remain in PLD's
/etc/env.d for long time without anybody care.

> I don't think it is worth it.

Surely, nothing is worth for someone who doesn't use it...

> Keeping backward compatibility for any strange feature we might have
> once thought it was a good idea would only make more and more mess in
> our distribution. I would say: let's break compatibility whenever we can
> get things simpler/safer/more functional this way and the compatibility
> cost is not too big. If the system won't boot because of the change,
> then it might be a good idea to introduce backward-compatibility hack.
> This is not such a case.

Ok, so why there are still other aliases defined in /etc/shrc.d? For example:

$ grep alias /etc/shrc.d/*.sh
[...]
/etc/shrc.d/colorls.sh:alias ls="ls --color=$COLOR_MODE"
/etc/shrc.d/pinfo.sh:   alias info="pinfo"
/etc/shrc.d/pinfo.sh:   alias man="pinfo -m"
/etc/shrc.d/which.sh:alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'
[...]

They also make more mess, they also get things more complicated and less
secure and they also could be the cause of quarrel. Why such ls is good
and grep is bad? Let's break compatibility and remove them all. These,
who want to use them, will define them in their own shell configs.


From groups at sq9mev.info  Thu Dec 11 00:24:26 2014
From: groups at sq9mev.info (Bartek SQ9MEV)
Date: Thu, 11 Dec 2014 00:24:26 +0100
Subject: xen-4.4.1-2.x86_64 - buggy xenstored and xendomains init scripts
Message-ID: <5488D62A.7080405@sq9mev.info>

Hi there,

i've noticed 2 separate bugs using xen-4.4.1-2.x86_64 with SysVinit.

1st one is in xenstored init script - /local/domain/0/domid" is not set
when henstored is started from initscript, however it is set when
started from systemd (fixed in 25eb178).

Attached xenstored.patch fixes this behaviour.

2nd one is in xendomains, when using xl toolstack - it's described here:
http://comments.gmane.org/gmane.linux.debian.devel.bugs.general/1201592

It's probabyly because check_config_name() returns empty string.
Debian sid uses slightly modified regexp in check_config_name, using 
that regexp works for me, however i'm not familiar with other 
toolstacks, so not sure if it's ok with other toolstacks.
Attached xendomains.patch contains Debian regexp.

-- 
Bartek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xenstored.patch
Type: text/x-patch
Size: 322 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20141211/336feb70/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xendomains.patch
Type: text/x-patch
Size: 473 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20141211/336feb70/attachment-0001.bin>

From groups at sq9mev.info  Thu Dec 11 00:52:29 2014
From: groups at sq9mev.info (Bartek SQ9MEV)
Date: Thu, 11 Dec 2014 00:52:29 +0100
Subject: targetcli-fb - creating lvm backstore with newer kernels fails
 (patches included)
Message-ID: <5488DCBD.2070609@sq9mev.info>

Hi there,

current (as of PLD git) targetcli-fb does not allow to create lvm 
backstore when used with newer kernels, probably due to:
https://lkml.org/lkml/2014/6/9/199

It works with newer targetcli-fb, at least attached patches which bump 
targetcli and dependencies work for me.

PS
If anyone is to accept this patches, please check them twice, i've made 
this changes some time ago with just one hand, had dislocated shoulder 
and were using painkillers ;).

-- 
Bartek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: targetcli.diff
Type: text/x-patch
Size: 878 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20141211/7bc554aa/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python-rtslib-fb.diff
Type: text/x-patch
Size: 687 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20141211/7bc554aa/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python-configshell-fb.diff
Type: text/x-patch
Size: 692 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20141211/7bc554aa/attachment-0002.bin>

From glen at delfi.ee  Thu Dec 11 11:25:30 2014
From: glen at delfi.ee (=?ISO-8859-2?Q?Elan_Ruusam=E4e?=)
Date: Thu, 11 Dec 2014 12:25:30 +0200
Subject: [packages/grep] - move from GREP_OPTIONS environmental variable
 to alias due to its obsolescence
In-Reply-To: <20141210193839.6b8b4567@zonk.pl>
References: <23ca4364a0c6cf68fca3432a517ec04a28c22e22_refs_heads_master@pld-linux.org>
 <274761483d541b779ab9135532aecf8aadc550e8_refs_heads_master@pld-linux.org>
 <54861430.3040103@pld-linux.org> <201412101246.26382.arekm@maven.pl>
 <5488419D.7050801@jajcus.net> <5488440A.4020406@pld-linux.org>
 <20141210193839.6b8b4567@zonk.pl>
Message-ID: <5489711A.5010206@delfi.ee>

On 10.12.2014 21:38, Adam Osuchowski wrote:
> Elan Ruusam?e wrote:
>> i totally dislike such alias being enabled by default. i have my own, and
>> this one will ovewrite mine (because it's after entry in shrc.d)
> Really? Since when ~/.bashrc, ~/.zshrc, etc. is interpreted _before_
> /etc/shrc.d? If you don't like system aliases unalias them or redefine
> in startup scripts.
i never said ~/.*rc

-- 
glen



From glen at pld-linux.org  Thu Dec 11 11:27:12 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Thu, 11 Dec 2014 12:27:12 +0200
Subject: [packages/grep] - move from GREP_OPTIONS environmental variable
 to alias due to its obsolescence
In-Reply-To: <20141210201029.327b23c6@zonk.pl>
References: <23ca4364a0c6cf68fca3432a517ec04a28c22e22_refs_heads_master@pld-linux.org>
 <201412101246.26382.arekm@maven.pl> <5488419D.7050801@jajcus.net>
 <201412101414.41206.arekm@maven.pl> <54884CCC.4050202@jajcus.net>
 <20141210201029.327b23c6@zonk.pl>
Message-ID: <54897180.7000409@pld-linux.org>

On 10.12.2014 22:10, Adam Osuchowski wrote:
> Ok, so why there are still other aliases defined in /etc/shrc.d? For example:
>
> $ grep alias/etc/shrc.d/*.sh
> [...]
> /etc/shrc.d/which.sh:alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'
> [...]

"which" needs to be alias to handle shell builtins (--read-alias option)

-- 
glen



From glen at pld-linux.org  Thu Dec 11 11:32:16 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Thu, 11 Dec 2014 12:32:16 +0200
Subject: [packages/kernel] - updated config
In-Reply-To: <20141210195939.GA2256@home.lan>
References: <e26ee53e41dbb757544e2857f019a4e7974f4712_refs_heads_master@pld-linux.org>
 <5fc1b244b3f356be6ea05dd183f0feba7e0c8276_refs_heads_master@pld-linux.org>
 <20141210195939.GA2256@home.lan>
Message-ID: <548972B0.1020407@pld-linux.org>

On 10.12.2014 21:59, Jan R?korajski wrote:
> What about switching to xz? That will require recent kmod, but we do it
> only for 3.18+ and if someone is running fresh kernel we can assume he
> has a fresh userspace.
i see you already switched. would be nice to see some du stats before 
and after

-- 
glen



From groups at sq9mev.info  Fri Dec 12 12:17:26 2014
From: groups at sq9mev.info (Bartek SQ9MEV)
Date: Fri, 12 Dec 2014 12:17:26 +0100
Subject: crmsh-2.1.0-1.x86_64, python-modules - missing Requires
Message-ID: <548ACEC6.50907@sq9mev.info>

Hi there,

After installatoin crmsh-2.1.0-1.x86_64, when invoking crm i got:

# crm
Fatal error:
     No module named lxml
     No module named modules

There's missing python-lxml requirement, attached patch fixes this.

With python-lxml installed, i got another error:

# crm
Fatal error:
     No module named pdb
     No module named modules

I've installed python-devel-tools (contains pdb.py), and crmsh works

Full trace:
# python
Python 2.7.8 (default, Jul 18 2014, 10:11:56)
[GCC 4.8.3 20140522 (release)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> from crmsh import main
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/usr/lib64/python2.7/site-packages/crmsh/main.py", line 33, in 
<module>
     import ui_root
   File "/usr/lib64/python2.7/site-packages/crmsh/ui_root.py", line 36, 
in <module>
     import ui_cib
   File "/usr/lib64/python2.7/site-packages/crmsh/ui_cib.py", line 22, 
in <module>
     import xmlutil
   File "/usr/lib64/python2.7/site-packages/crmsh/xmlutil.py", line 20, 
in <module>
     from lxml import etree, doctestcompare
   File "/usr/lib64/python2.7/site-packages/lxml/doctestcompare.py", 
line 41, in <module>
   File "/usr/share/python2.7/doctest.py", line 99, in <module>
ImportError: No module named pdb
 >>>

/usr/share/python2.7/doctest.pyc belongs to 
python-modules-2.7.8-1.x86_64, so i think python-modules should include 
/usr/share/python2.7/pdb.pyc or python-modules should require 
python-devel-tools, or python-lxml should require python-devel-tools.

Any toughts?

-- 
Bartek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crmsh_lxml.patch
Type: text/x-patch
Size: 630 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20141212/7aff27a4/attachment.bin>

From baggins at pld-linux.org  Sat Dec 13 11:46:57 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 13 Dec 2014 11:46:57 +0100
Subject: [packages/kernel] - updated config
In-Reply-To: <548972B0.1020407@pld-linux.org>
References: <e26ee53e41dbb757544e2857f019a4e7974f4712_refs_heads_master@pld-linux.org>
 <5fc1b244b3f356be6ea05dd183f0feba7e0c8276_refs_heads_master@pld-linux.org>
 <20141210195939.GA2256@home.lan> <548972B0.1020407@pld-linux.org>
Message-ID: <20141213104657.GC2241@home.lan>

On Thu, 11 Dec 2014, Elan Ruusam?e wrote:

> On 10.12.2014 21:59, Jan R?korajski wrote:
> > What about switching to xz? That will require recent kmod, but we do it
> > only for 3.18+ and if someone is running fresh kernel we can assume he
> > has a fresh userspace.
> i see you already switched. would be nice to see some du stats before 
> and after

[root at home 3.17.2-1]# du -hs kernel*
54M	kernel.gz
46M	kernel.xz

~20% savings.

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


From baggins at pld-linux.org  Sat Dec 13 11:48:28 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 13 Dec 2014 11:48:28 +0100
Subject: xen-4.4.1-2.x86_64 - buggy xenstored and xendomains init scripts
In-Reply-To: <5488D62A.7080405@sq9mev.info>
References: <5488D62A.7080405@sq9mev.info>
Message-ID: <20141213104827.GD2241@home.lan>

On Thu, 11 Dec 2014, Bartek SQ9MEV wrote:

> Hi there,
> 
> i've noticed 2 separate bugs using xen-4.4.1-2.x86_64 with SysVinit.
> 
> 1st one is in xenstored init script - /local/domain/0/domid" is not set
> when henstored is started from initscript, however it is set when
> started from systemd (fixed in 25eb178).
> 
> Attached xenstored.patch fixes this behaviour.
> 
> 2nd one is in xendomains, when using xl toolstack - it's described here:
> http://comments.gmane.org/gmane.linux.debian.devel.bugs.general/1201592
> 
> It's probabyly because check_config_name() returns empty string.
> Debian sid uses slightly modified regexp in check_config_name, using 
> that regexp works for me, however i'm not familiar with other 
> toolstacks, so not sure if it's ok with other toolstacks.
> Attached xendomains.patch contains Debian regexp.

Applied, thanks.

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


From baggins at pld-linux.org  Sat Dec 13 12:15:20 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 13 Dec 2014 12:15:20 +0100
Subject: crmsh-2.1.0-1.x86_64, python-modules - missing Requires
In-Reply-To: <548ACEC6.50907@sq9mev.info>
References: <548ACEC6.50907@sq9mev.info>
Message-ID: <20141213111519.GE2241@home.lan>

On Fri, 12 Dec 2014, Bartek SQ9MEV wrote:

> Hi there,
> 
> After installatoin crmsh-2.1.0-1.x86_64, when invoking crm i got:
> 
> # crm
> Fatal error:
>      No module named lxml
>      No module named modules
> 
> There's missing python-lxml requirement, attached patch fixes this.

Added and updated crmsh to 2.1.1, thanks.

> With python-lxml installed, i got another error:
> 
> # crm
> Fatal error:
>      No module named pdb
>      No module named modules
> 
> I've installed python-devel-tools (contains pdb.py), and crmsh works
> 
> Full trace:
> # python
> Python 2.7.8 (default, Jul 18 2014, 10:11:56)
> [GCC 4.8.3 20140522 (release)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> from crmsh import main
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "/usr/lib64/python2.7/site-packages/crmsh/main.py", line 33, in 
> <module>
>      import ui_root
>    File "/usr/lib64/python2.7/site-packages/crmsh/ui_root.py", line 36, 
> in <module>
>      import ui_cib
>    File "/usr/lib64/python2.7/site-packages/crmsh/ui_cib.py", line 22, 
> in <module>
>      import xmlutil
>    File "/usr/lib64/python2.7/site-packages/crmsh/xmlutil.py", line 20, 
> in <module>
>      from lxml import etree, doctestcompare
>    File "/usr/lib64/python2.7/site-packages/lxml/doctestcompare.py", 
> line 41, in <module>
>    File "/usr/share/python2.7/doctest.py", line 99, in <module>
> ImportError: No module named pdb
>  >>>
> 
> /usr/share/python2.7/doctest.pyc belongs to 
> python-modules-2.7.8-1.x86_64, so i think python-modules should include 
> /usr/share/python2.7/pdb.pyc or python-modules should require 
> python-devel-tools, or python-lxml should require python-devel-tools.
> 
> Any toughts?

I see pdb is also imported by other modules in python-modules package,
so it only makes sense to move pdb to modules. Done, thanks for catching
this.

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


From baggins at pld-linux.org  Sat Dec 13 20:03:16 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Sat, 13 Dec 2014 20:03:16 +0100
Subject: targetcli-fb - creating lvm backstore with newer kernels fails
 (patches included)
In-Reply-To: <5488DCBD.2070609@sq9mev.info>
References: <5488DCBD.2070609@sq9mev.info>
Message-ID: <20141213190315.GF2241@home.lan>

On Thu, 11 Dec 2014, Bartek SQ9MEV wrote:

> Hi there,
> 
> current (as of PLD git) targetcli-fb does not allow to create lvm 
> backstore when used with newer kernels, probably due to:
> https://lkml.org/lkml/2014/6/9/199
> 
> It works with newer targetcli-fb, at least attached patches which bump 
> targetcli and dependencies work for me.

Updated to new versions, thanks. New packages should be in th-test soon.

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


From baggins at pld-linux.org  Mon Dec 15 21:01:58 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 15 Dec 2014 21:01:58 +0100
Subject: The future of i486 arch in Th
Message-ID: <20141215200158.GA2254@home.lan>

TL;DR Future of i486 is bleak, it's a strong candidate for removal.

Proposal: remove i486 from Th.

Rationale:

It's increasingly more problematic to get everything built on i486, some
packages explicitly say "no" to this arch, some require hacks and
strange workarounds, and other just silently fail in mysterious ways.
All this makes maintainability cost of i486 very high, and combined
with the size of userbase, overly high.

Some usage stats from the Sun Nov 16 - Sun Dec 14 period, from
ftp1.pld-linux.org:

# zgrep x86_64 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n | wc -l
533

# zgrep i686 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n | wc -l
730

# zgrep i486 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n | wc -l
20

# zgrep i486 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n
[exact IPs removed to protect privacy]
      < 10		4 IPs
      < 50		4 IPs
      < 100		4 IPs
      < 1000		7 IPs
      > 1000		1 IP

As you can see there are 20 distinct users of i486, out of which
maybe 5 really use this arch.

Due to higher workload i486 arch requires compared to anything else and
symbolic userbase, I propose to drop it from Th.

Comments?

PS. we can use former i486 builder for x32 port if there will be takers.

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


From gzohop at gmail.com  Mon Dec 15 21:15:29 2014
From: gzohop at gmail.com (Grzesiek)
Date: Mon, 15 Dec 2014 21:15:29 +0100
Subject: The future of i486 arch in Th
In-Reply-To: <20141215200158.GA2254@home.lan>
References: <20141215200158.GA2254@home.lan>
Message-ID: <548F4161.6000800@gmail.com>

W dniu 15.12.2014 o 21:01, Jan R?korajski pisze:
> TL;DR Future of i486 is bleak, it's a strong candidate for removal.
>
> Proposal: remove i486 from Th.
>
> Rationale:
>
> It's increasingly more problematic to get everything built on i486, some
> packages explicitly say "no" to this arch, some require hacks and
> strange workarounds, and other just silently fail in mysterious ways.
> All this makes maintainability cost of i486 very high, and combined
> with the size of userbase, overly high.
>
> Some usage stats from the Sun Nov 16 - Sun Dec 14 period, from
> ftp1.pld-linux.org:
>
> # zgrep x86_64 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n | wc -l
> 533
>
> # zgrep i686 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n | wc -l
> 730
>
> # zgrep i486 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n | wc -l
> 20
>
> # zgrep i486 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n
> [exact IPs removed to protect privacy]
>        < 10		4 IPs
>        < 50		4 IPs
>        < 100		4 IPs
>        < 1000		7 IPs
>        > 1000		1 IP
>
> As you can see there are 20 distinct users of i486, out of which
> maybe 5 really use this arch.
>
> Due to higher workload i486 arch requires compared to anything else and
> symbolic userbase, I propose to drop it from Th.
>
> Comments?
>
> PS. we can use former i486 builder for x32 port if there will be takers.
>
I think it's good idea, th2014 can be last snapshot with i486 :)
Some projects this days even start to abandon i686 or mainly focus only 
on x86_64, so I don't see need for i486 in Th.
Are there any users of i486 reading the list?



From gglater62 at gmail.com  Mon Dec 15 21:24:45 2014
From: gglater62 at gmail.com (Witold Filipczyk)
Date: Mon, 15 Dec 2014 21:24:45 +0100
Subject: The future of i486 arch in Th
In-Reply-To: <20141215200158.GA2254@home.lan>
References: <20141215200158.GA2254@home.lan>
Message-ID: <20141215202445.GA26612@pldmachine.domain_not_set.invalid>

On Mon, Dec 15, 2014 at 09:01:58PM +0100, Jan R?korajski wrote:
> TL;DR Future of i486 is bleak, it's a strong candidate for removal.
> 
> Proposal: remove i486 from Th.
> 
> Rationale:
> 
> It's increasingly more problematic to get everything built on i486, some
> packages explicitly say "no" to this arch, some require hacks and
> strange workarounds, and other just silently fail in mysterious ways.
> All this makes maintainability cost of i486 very high, and combined
> with the size of userbase, overly high.
> 
> Some usage stats from the Sun Nov 16 - Sun Dec 14 period, from
> ftp1.pld-linux.org:
> 
> # zgrep x86_64 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n | wc -l
> 533
> 
> # zgrep i686 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n | wc -l
> 730
> 
> # zgrep i486 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n | wc -l
> 20
> 
> # zgrep i486 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n
> [exact IPs removed to protect privacy]
>       < 10		4 IPs
>       < 50		4 IPs
>       < 100		4 IPs
>       < 1000		7 IPs
>       > 1000		1 IP
> 
> As you can see there are 20 distinct users of i486, out of which
> maybe 5 really use this arch.
> 
> Due to higher workload i486 arch requires compared to anything else and
> symbolic userbase, I propose to drop it from Th.
> 
> Comments?
> 
> PS. we can use former i486 builder for x32 port if there will be takers.

Kernel build for non-PAE i686 is what I want.


From n3npq at me.com  Mon Dec 15 21:39:16 2014
From: n3npq at me.com (Jeffrey Johnson)
Date: Mon, 15 Dec 2014 15:39:16 -0500
Subject: The future of i486 arch in Th
In-Reply-To: <20141215200158.GA2254@home.lan>
References: <20141215200158.GA2254@home.lan>
Message-ID: <111215C9-D811-4CDE-AC48-B2D8F7C47064@me.com>

I'm more interested in the lowest common denominator Intel architecture.

Specifically:
	Can RPM assume sse2 instructions and optimize digests/crypto to use sse2?

73 de Jeff

On Dec 15, 2014, at 3:01 PM, Jan R?korajski wrote:

> TL;DR Future of i486 is bleak, it's a strong candidate for removal.
> 
> Proposal: remove i486 from Th.
> 
> Rationale:
> 
> It's increasingly more problematic to get everything built on i486, some
> packages explicitly say "no" to this arch, some require hacks and
> strange workarounds, and other just silently fail in mysterious ways.
> All this makes maintainability cost of i486 very high, and combined
> with the size of userbase, overly high.
> 
> Some usage stats from the Sun Nov 16 - Sun Dec 14 period, from
> ftp1.pld-linux.org:
> 
> # zgrep x86_64 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n | wc -l
> 533
> 
> # zgrep i686 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n | wc -l
> 730
> 
> # zgrep i486 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n | wc -l
> 20
> 
> # zgrep i486 /var/log/archive/xferlog*gz  | grep -v <builder-ip> | grep poldek | awk '{ print $7 }' | sort | uniq -c | sort -n
> [exact IPs removed to protect privacy]
>      < 10		4 IPs
>      < 50		4 IPs
>      < 100		4 IPs
>      < 1000		7 IPs
>> 1000		1 IP
> 
> As you can see there are 20 distinct users of i486, out of which
> maybe 5 really use this arch.
> 
> Due to higher workload i486 arch requires compared to anything else and
> symbolic userbase, I propose to drop it from Th.
> 
> Comments?
> 
> PS. we can use former i486 builder for x32 port if there will be takers.
> 
> -- 
> Jan R?korajski                    | PLD/Linux
> SysAdm | baggins<at>pld-linux.org | http://www.pld-linux.org/
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en



From baggins at pld-linux.org  Mon Dec 15 21:48:03 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Mon, 15 Dec 2014 21:48:03 +0100
Subject: The future of i486 arch in Th
In-Reply-To: <111215C9-D811-4CDE-AC48-B2D8F7C47064@me.com>
References: <20141215200158.GA2254@home.lan>
 <111215C9-D811-4CDE-AC48-B2D8F7C47064@me.com>
Message-ID: <20141215204803.GB2254@home.lan>

On Mon, 15 Dec 2014, Jeffrey Johnson wrote:

> I'm more interested in the lowest common denominator Intel architecture.
> 
> Specifically:
> 	Can RPM assume sse2 instructions and optimize digests/crypto to use sse2?

No 32bit AMD CPU has this. So, no, you can't do it unconditionally.
We're not going to require SSE2 for i686 arch.

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


From n3npq at me.com  Mon Dec 15 22:06:01 2014
From: n3npq at me.com (Jeffrey Johnson)
Date: Mon, 15 Dec 2014 16:06:01 -0500
Subject: The future of i486 arch in Th
In-Reply-To: <20141215204803.GB2254@home.lan>
References: <20141215200158.GA2254@home.lan>
 <111215C9-D811-4CDE-AC48-B2D8F7C47064@me.com> <20141215204803.GB2254@home.lan>
Message-ID: <2E25521D-FD41-4793-B379-A08484609FD3@me.com>


On Dec 15, 2014, at 3:48 PM, Jan R?korajski wrote:

> On Mon, 15 Dec 2014, Jeffrey Johnson wrote:
> 
>> I'm more interested in the lowest common denominator Intel architecture.
>> 
>> Specifically:
>> 	Can RPM assume sse2 instructions and optimize digests/crypto to use sse2?
> 
> No 32bit AMD CPU has this. So, no, you can't do it unconditionally.
> We're not going to require SSE2 for i686 arch.
> 

C'est dommage.

OK, the more complicated (and compiler dependent) implementation using
	__attribute__(( __target__ ("sse2") ))
with internal LibTomCrypt/BeeCrypt will be attempted instead.

I'm tired of watching RPM progress bars that move slower than necessary because
of missing functionality on dead/legacy architectures.

73 de Jeff



From jajcus at jajcus.net  Tue Dec 16 09:03:41 2014
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Tue, 16 Dec 2014 09:03:41 +0100
Subject: The future of i486 arch in Th
In-Reply-To: <20141215200158.GA2254@home.lan>
References: <20141215200158.GA2254@home.lan>
Message-ID: <548FE75D.5070006@jajcus.net>

On 15/12/14 21:01, Jan R?korajski wrote:
> TL;DR Future of i486 is bleak, it's a strong candidate for removal.
> 
> Proposal: remove i486 from Th.

+1

Compiling IcedTea (Java) for i486 has been always problematic and took much
longer than compiling it for other archs (hours of difference).

Greets,
	Jacek


From draenog at pld-linux.org  Wed Dec 17 09:07:54 2014
From: draenog at pld-linux.org (Kacper Kornet)
Date: Wed, 17 Dec 2014 09:07:54 +0100
Subject: [packages/mksh] - behave as proper sh when invoked as /bin/sh,
 wothout fancy, incompatible hacks - rel 2
In-Reply-To: <e8ed3f0e4ba55966f3aa461d8deb6617f32d106e_refs_heads_master@pld-linux.org>
References: <625811d2341ef34a9d6c85ecf2c7a9828efd36fd_refs_heads_master@pld-linux.org>
 <e8ed3f0e4ba55966f3aa461d8deb6617f32d106e_refs_heads_master@pld-linux.org>
Message-ID: <20141217080754.GA17715@camk.edu.pl>

On Tue, Dec 16, 2014 at 11:29:05PM +0100, baggins wrote:
> commit e8ed3f0e4ba55966f3aa461d8deb6617f32d106e
> Author: Jan R?korajski <baggins at pld-linux.org>
> Date:   Tue Dec 16 23:30:41 2014 +0100

>     - behave as proper sh when invoked as /bin/sh, wothout fancy, incompatible hacks
>     - rel 2

This change breaks our rc-scripts:

$ rpm -q mksh
mksh-50d-1.x86_64
$ /bin/sh -c "echo -en '\n'" 

$ rpm -q mksh
mksh-50d-2.x86_64
$ /bin/sh -c "echo -en '\n'"
-en \n

There was a small discussion about it some time ago:
https://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2011-May/153795.html


-- 
  Kacper


From glen at pld-linux.org  Wed Dec 17 11:15:09 2014
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Wed, 17 Dec 2014 12:15:09 +0200
Subject: [packages/mksh] - behave as proper sh when invoked as /bin/sh,
 wothout fancy, incompatible hacks - rel 2
In-Reply-To: <20141217080754.GA17715@camk.edu.pl>
References: <625811d2341ef34a9d6c85ecf2c7a9828efd36fd_refs_heads_master@pld-linux.org>
 <e8ed3f0e4ba55966f3aa461d8deb6617f32d106e_refs_heads_master@pld-linux.org>
 <20141217080754.GA17715@camk.edu.pl>
Message-ID: <549157AD.2060303@pld-linux.org>

On 17.12.2014 10:07, Kacper Kornet wrote:
>>      - behave as proper sh when invoked as /bin/sh, wothout fancy, incompatible hacks
>>      - rel 2
> This change breaks our rc-scripts:
>
> $ rpm -q mksh
> mksh-50d-1.x86_64
> $ /bin/sh -c "echo -en '\n'"
>
> $ rpm -q mksh
> mksh-50d-2.x86_64
> $ /bin/sh -c "echo -en '\n'"
> -en \n
>
> There was a small discussion about it some time ago:
> https://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2011-May/153795.html

so, our rc-scripts is not using portable shell. what would be portable 
(posix) version of above code that behaves as rc-scripts intended?

printf?


-- 
glen



From draenog at pld-linux.org  Wed Dec 17 12:02:44 2014
From: draenog at pld-linux.org (Kacper Kornet)
Date: Wed, 17 Dec 2014 12:02:44 +0100
Subject: [packages/mksh] - behave as proper sh when invoked as /bin/sh,
 wothout fancy, incompatible hacks - rel 2
In-Reply-To: <549157AD.2060303@pld-linux.org>
References: <625811d2341ef34a9d6c85ecf2c7a9828efd36fd_refs_heads_master@pld-linux.org>
 <e8ed3f0e4ba55966f3aa461d8deb6617f32d106e_refs_heads_master@pld-linux.org>
 <20141217080754.GA17715@camk.edu.pl>
 <549157AD.2060303@pld-linux.org>
Message-ID: <20141217110243.GA7901@camk.edu.pl>

On Wed, Dec 17, 2014 at 12:15:09PM +0200, Elan Ruusam?e wrote:
> On 17.12.2014 10:07, Kacper Kornet wrote:
> >>     - behave as proper sh when invoked as /bin/sh, wothout fancy, incompatible hacks
> >>     - rel 2
> >This change breaks our rc-scripts:

> >$ rpm -q mksh
> >mksh-50d-1.x86_64
> >$ /bin/sh -c "echo -en '\n'"

> >$ rpm -q mksh
> >mksh-50d-2.x86_64
> >$ /bin/sh -c "echo -en '\n'"
> >-en \n

> >There was a small discussion about it some time ago:
> >https://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2011-May/153795.html

> so, our rc-scripts is not using portable shell. what would be
> portable (posix) version of above code that behaves as rc-scripts
> intended?

> printf?

However there is no builtin printf. So every call to it would cost a
fork. Although man mksh says about printf:

    This is not normally part of mksh; however, distributors may have added
    this as builtin as a speed hack.  Do not use in new code.

-- 
  Kacper


From baggins at pld-linux.org  Wed Dec 17 16:06:23 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Wed, 17 Dec 2014 16:06:23 +0100
Subject: [packages/mksh] - behave as proper sh when invoked as /bin/sh,
 wothout fancy, incompatible hacks - rel 2
In-Reply-To: <20141217080754.GA17715@camk.edu.pl>
References: <625811d2341ef34a9d6c85ecf2c7a9828efd36fd_refs_heads_master@pld-linux.org>
 <e8ed3f0e4ba55966f3aa461d8deb6617f32d106e_refs_heads_master@pld-linux.org>
 <20141217080754.GA17715@camk.edu.pl>
Message-ID: <20141217082717.GA1671@tachikoma.lan>

On Wed, 17 Dec 2014, Kacper Kornet wrote:

> On Tue, Dec 16, 2014 at 11:29:05PM +0100, baggins wrote:
> > commit e8ed3f0e4ba55966f3aa461d8deb6617f32d106e
> > Author: Jan R?korajski <baggins at pld-linux.org>
> > Date:   Tue Dec 16 23:30:41 2014 +0100
> 
> >     - behave as proper sh when invoked as /bin/sh, wothout fancy, incompatible hacks
> >     - rel 2
> 
> This change breaks our rc-scripts:
> 
> $ rpm -q mksh
> mksh-50d-1.x86_64
> $ /bin/sh -c "echo -en '\n'" 
> 
> $ rpm -q mksh
> mksh-50d-2.x86_64
> $ /bin/sh -c "echo -en '\n'"
> -en \n
> 
> There was a small discussion about it some time ago:
> https://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2011-May/153795.html

Yea, I fell for it. And disabled {} expansion.
This 'echo' behavior is broken, totally. It prevents glibc to build for
x32, some scripts there use '\\n\ and '\n' in echo and expect it to pass
- every shel just passes it as-is without -e to echo, but not mksh.

I'm more and more leaning to just flush down the drain all those fancy,
crappy ksh reinventions and just go with bash as /bin/sh. The main
reason to use pdksh (and later mksh) as /bin/sh was it's speed when used
in rc-scripts, AFAIK bash caught up and we're moving towards systemd
which doesn't need shell.

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


From glen at pld-linux.org  Wed Dec 17 16:51:29 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Wed, 17 Dec 2014 17:51:29 +0200
Subject: polling remote systems (vagrant)
Message-ID: <5491A681.6040601@pld-linux.org>

vagrant has system for polling remote system for updates. this is done 
in background without user knowledge

16:36:10  glen> so. vagrant has some "checkpoint"
16:36:26  glen> which pulls remote system for information
16:36:29  glen> in background
16:36:31  glen> should it be disabled?
16:36:49  glen> 
https://github.com/hashicorp/ruby-checkpoint/blob/master/lib/checkpoint.rb#L77-L87
16:40:08  glen> so i think whether to disable it globally (easy)
16:40:21  glen> or just disable it's automatic check in the background 
(needs code changes and still need to add ruby-checkpoint package)

-- 
glen



From glen at pld-linux.org  Wed Dec 17 16:57:29 2014
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Wed, 17 Dec 2014 17:57:29 +0200
Subject: sudo timestamp
Message-ID: <5491A7E9.5000707@pld-linux.org>

so, each time i reboot machine, sudo complains about timestamp:

$ sudo bash -l
sudo: ignoring time stamp from the future
[sudo] password for glen:

any ideas what's that? because our sudo is supposed to use /var/db/sudo 
... and that dir is not cleaned with reboot

sudo-1.8.10p3-1.x86_64

-- 
glen



From draenog at pld-linux.org  Wed Dec 17 17:47:05 2014
From: draenog at pld-linux.org (Kacper Kornet)
Date: Wed, 17 Dec 2014 17:47:05 +0100
Subject: [packages/mksh] - behave as proper sh when invoked as /bin/sh,
 wothout fancy, incompatible hacks - rel 2
In-Reply-To: <20141217082717.GA1671@tachikoma.lan>
References: <625811d2341ef34a9d6c85ecf2c7a9828efd36fd_refs_heads_master@pld-linux.org>
 <e8ed3f0e4ba55966f3aa461d8deb6617f32d106e_refs_heads_master@pld-linux.org>
 <20141217080754.GA17715@camk.edu.pl>
 <20141217082717.GA1671@tachikoma.lan>
Message-ID: <20141217164705.GA8544@camk.edu.pl>

On Wed, Dec 17, 2014 at 04:06:23PM +0100, Jan R?korajski wrote:
> On Wed, 17 Dec 2014, Kacper Kornet wrote:

> > On Tue, Dec 16, 2014 at 11:29:05PM +0100, baggins wrote:
> > > commit e8ed3f0e4ba55966f3aa461d8deb6617f32d106e
> > > Author: Jan R?korajski <baggins at pld-linux.org>
> > > Date:   Tue Dec 16 23:30:41 2014 +0100

> > >     - behave as proper sh when invoked as /bin/sh, wothout fancy, incompatible hacks
> > >     - rel 2

> > This change breaks our rc-scripts:

> > $ rpm -q mksh
> > mksh-50d-1.x86_64
> > $ /bin/sh -c "echo -en '\n'" 

> > $ rpm -q mksh
> > mksh-50d-2.x86_64
> > $ /bin/sh -c "echo -en '\n'"
> > -en \n

> > There was a small discussion about it some time ago:
> > https://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2011-May/153795.html

> Yea, I fell for it. And disabled {} expansion.
> This 'echo' behavior is broken, totally. It prevents glibc to build for
> x32, some scripts there use '\\n\ and '\n' in echo and expect it to pass
> - every shel just passes it as-is without -e to echo, but not mksh.

Not the only one. Debian has the same problem as they use dash as
/bin/sh:

https://sourceware.org/bugzilla/show_bug.cgi?id=16704

It looks like the glibc developers are aware of the problem. In the
meantime maybe patch this script to use bash instead of sh.

-- 
  Kacper


From qboosh at pld-linux.org  Wed Dec 17 21:01:17 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 17 Dec 2014 21:01:17 +0100
Subject: [packages/mksh] - behave as proper sh when invoked as /bin/sh,
 wothout fancy, incompatible hacks - rel 2
In-Reply-To: <20141217082717.GA1671@tachikoma.lan>
References: <625811d2341ef34a9d6c85ecf2c7a9828efd36fd_refs_heads_master@pld-linux.org>
 <e8ed3f0e4ba55966f3aa461d8deb6617f32d106e_refs_heads_master@pld-linux.org>
 <20141217080754.GA17715@camk.edu.pl> <20141217082717.GA1671@tachikoma.lan>
Message-ID: <20141217200117.GA18669@mail>

On Wed, Dec 17, 2014 at 04:06:23PM +0100, Jan R?korajski wrote:
> On Wed, 17 Dec 2014, Kacper Kornet wrote:
> 
> > On Tue, Dec 16, 2014 at 11:29:05PM +0100, baggins wrote:
> > > commit e8ed3f0e4ba55966f3aa461d8deb6617f32d106e
> > > Author: Jan R?korajski <baggins at pld-linux.org>
> > > Date:   Tue Dec 16 23:30:41 2014 +0100
> > 
> > >     - behave as proper sh when invoked as /bin/sh, wothout fancy, incompatible hacks
> > >     - rel 2
> > 
> > This change breaks our rc-scripts:
> > 
> > $ rpm -q mksh
> > mksh-50d-1.x86_64
> > $ /bin/sh -c "echo -en '\n'" 
> > 
> > $ rpm -q mksh
> > mksh-50d-2.x86_64
> > $ /bin/sh -c "echo -en '\n'"
> > -en \n
> > 
> > There was a small discussion about it some time ago:
> > https://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2011-May/153795.html
> 
> Yea, I fell for it. And disabled {} expansion.
> This 'echo' behavior is broken, totally. It prevents glibc to build for
> x32, some scripts there use '\\n\ and '\n' in echo and expect it to pass
> - every shel just passes it as-is without -e to echo, but not mksh.

If "any" means bash or BSD sh...?

Standard POSIX sh doesn't support any options and always interprets
escapes (though I don't know such shell in practice).
BSD sh supports -e and -n (but not "-ne", which is GNU-specific).
pdksh/mksh support -n and ignore -e (always interpreting escapes)
dash (and probably old ash) supports -n but not -e ("-e" is echoed,
  escapes are always interpreted)

Really portable? printf; echo only without options and escapes.

When you mean /bin/bash, write /bin/bash, not /bin/sh.


BTW: "local" (used in our scripts) is non-POSIX too (but supported by
ksh, ash and BSD).


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


From ed at yen.ipipan.waw.pl  Wed Dec 17 21:25:15 2014
From: ed at yen.ipipan.waw.pl (=?utf-8?B?xYF1a2FzeiBNYcWba28=?=)
Date: Wed, 17 Dec 2014 21:25:15 +0100
Subject: sudo timestamp
In-Reply-To: <5491A7E9.5000707@pld-linux.org>
References: <5491A7E9.5000707@pld-linux.org>
Message-ID: <2604992.8deGSaLf66@laptok>

Dnia ?roda, 17 grudnia 2014 17:57:29 Elan Ruusam?e pisze:
> so, each time i reboot machine, sudo complains about timestamp:
> 
> $ sudo bash -l
> sudo: ignoring time stamp from the future
> [sudo] password for glen:
> 
> any ideas what's that? because our sudo is supposed to use /var/db/sudo
> ... and that dir is not cleaned with reboot
> 
> sudo-1.8.10p3-1.x86_64

Maybe this is stupid, but... a you sure that you have the system time set 
correctly? 
-- 
?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 gzohop at gmail.com  Wed Dec 17 22:12:46 2014
From: gzohop at gmail.com (Grzesiek)
Date: Wed, 17 Dec 2014 22:12:46 +0100
Subject: sudo timestamp
In-Reply-To: <2604992.8deGSaLf66@laptok>
References: <5491A7E9.5000707@pld-linux.org> <2604992.8deGSaLf66@laptok>
Message-ID: <5491F1CE.6090501@gmail.com>

W dniu 17.12.2014 o 21:25, ?ukasz Ma?ko pisze:
> Dnia ?roda, 17 grudnia 2014 17:57:29 Elan Ruusam?e pisze:
>> so, each time i reboot machine, sudo complains about timestamp:
>>
>> $ sudo bash -l
>> sudo: ignoring time stamp from the future
>> [sudo] password for glen:
>>
>> any ideas what's that? because our sudo is supposed to use /var/db/sudo
>> ... and that dir is not cleaned with reboot
>>
>> sudo-1.8.10p3-1.x86_64
> Maybe this is stupid, but... a you sure that you have the system time set
> correctly?

Or maybe hardware clock does not get set, and is always out of sync and 
just the system clock gets NTP sync witch is lost after reboot?


From jajcus at jajcus.net  Tue Dec 23 14:17:10 2014
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Tue, 23 Dec 2014 14:17:10 +0100
Subject: PLD New Rescue th2014-1.4 released
In-Reply-To: <20141206182215.GA2190@home.lan>
References: <20141206182215.GA2190@home.lan>
Message-ID: <54996B56.5000304@jajcus.net>

Hi,

I have just prepared new PLD New Rescue images, based on the new Th snaphot.

https://github.com/Jajcus/pld-new-rescue/releases/tag/th2014-1.4

Let me know if it works for you, so I can mark it a final release.

Greets,
Jacek


From gzohop at gmail.com  Wed Dec 24 11:23:14 2014
From: gzohop at gmail.com (Grzesiek)
Date: Wed, 24 Dec 2014 11:23:14 +0100
Subject: PLD New Rescue th2014-1.4 released
In-Reply-To: <54996B56.5000304@jajcus.net>
References: <20141206182215.GA2190@home.lan> <54996B56.5000304@jajcus.net>
Message-ID: <549A9412.4070205@gmail.com>

W dniu 23.12.2014 o 14:17, Jacek Konieczny pisze:
> Hi,
>
> I have just prepared new PLD New Rescue images, based on the new Th snaphot.
>
> https://github.com/Jajcus/pld-new-rescue/releases/tag/th2014-1.4
>
> Let me know if it works for you, so I can mark it a final release.
>

U mnie dzia?aj? obydwie wersje 32 i 64 bit.
A mo?na do standardowej listy paczek doda? deboostrap?


From jajcus at jajcus.net  Wed Dec 24 12:11:52 2014
From: jajcus at jajcus.net (Jacek Konieczny)
Date: Wed, 24 Dec 2014 12:11:52 +0100
Subject: PLD New Rescue th2014-1.4 released
In-Reply-To: <549A9412.4070205@gmail.com>
References: <20141206182215.GA2190@home.lan> <54996B56.5000304@jajcus.net>
 <549A9412.4070205@gmail.com>
Message-ID: <549A9F78.7060504@jajcus.net>

On 24/12/14 11:23, Grzesiek wrote:
> U mnie dzia?aj? obydwie wersje 32 i 64 bit.

Dzi?ki :)

> A mo?na do standardowej listy paczek doda? deboostrap?

Dodane. Ale z nowym buildem poczekam a? wi?cej si? tego nazbiera.

Pozdrawiam
Jacek


From qboosh at pld-linux.org  Thu Dec 25 13:13:33 2014
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 25 Dec 2014 13:13:33 +0100
Subject: [packages/gtk+2] - gtk+2 needs deprecated GdkPixdata type
In-Reply-To: <717b6d6475d7efb7ccb09bf372951ac9b5e6fad5_refs_heads_master@pld-linux.org>
References: <2b011defca10749bce051a92ff9fa6facc68de27_refs_heads_master@pld-linux.org>
 <717b6d6475d7efb7ccb09bf372951ac9b5e6fad5_refs_heads_master@pld-linux.org>
Message-ID: <20141225121333.GA30913@mail>

On Thu, Dec 25, 2014 at 12:55:15PM +0100, baggins wrote:
> commit 717b6d6475d7efb7ccb09bf372951ac9b5e6fad5
> Author: Jan R?korajski <baggins at pld-linux.org>
> Date:   Thu Dec 25 11:57:38 2014 +0000
> 
>     - gtk+2 needs deprecated GdkPixdata type

> -%{__make}
> +
> +%{__make} CC="%{__cc}"

What is this for?
No comment inside spec or changelog...


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


From baggins at pld-linux.org  Thu Dec 25 17:54:47 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Thu, 25 Dec 2014 17:54:47 +0100
Subject: [packages/gtk+2] - gtk+2 needs deprecated GdkPixdata type
In-Reply-To: <20141225121333.GA30913@mail>
References: <2b011defca10749bce051a92ff9fa6facc68de27_refs_heads_master@pld-linux.org>
 <717b6d6475d7efb7ccb09bf372951ac9b5e6fad5_refs_heads_master@pld-linux.org>
 <20141225121333.GA30913@mail>
Message-ID: <20141225165447.GC1756@tachikoma.lan>

On Thu, 25 Dec 2014, Jakub Bogusz wrote:

> On Thu, Dec 25, 2014 at 12:55:15PM +0100, baggins wrote:
> > commit 717b6d6475d7efb7ccb09bf372951ac9b5e6fad5
> > Author: Jan R?korajski <baggins at pld-linux.org>
> > Date:   Thu Dec 25 11:57:38 2014 +0000
> > 
> >     - gtk+2 needs deprecated GdkPixdata type
> 
> > -%{__make}
> > +
> > +%{__make} CC="%{__cc}"
> 
> What is this for?
> No comment inside spec or changelog...

It's for gobject-introspection scanner to use our CC, this POS can't get
it from Makefile env :(

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


From zawadaa at gmail.com  Mon Dec 29 00:31:13 2014
From: zawadaa at gmail.com (Andrzej Zawadzki)
Date: Mon, 29 Dec 2014 00:31:13 +0100
Subject: PostgreSQL and uuid-ossp
Message-ID: <54A092C1.1030502@gmail.com>

Hi!

I need help: what configure option should I use according to: 
www.postgresql.org/docs/9.4/static/uuid-ossp.html


With --with-uuid=ossp

configure: WARNING: uuid.h: accepted by the compiler, rejected by the 
preprocessor!
configure: WARNING: uuid.h: proceeding with the compiler's result
checking for uuid.h... yes
configure: error: header file <uuid.h> does not match OSSP UUID library

With  --with-uuid=e2fs works fine.


-- 
Andrzej Zawadzki


From gotar at polanet.pl  Tue Dec 30 20:02:36 2014
From: gotar at polanet.pl (Tomasz Pala)
Date: Tue, 30 Dec 2014 20:02:36 +0100
Subject: The future of i486 arch in Th
In-Reply-To: <20141215204803.GB2254@home.lan>
References: <20141215200158.GA2254@home.lan>
 <111215C9-D811-4CDE-AC48-B2D8F7C47064@me.com>
 <20141215204803.GB2254@home.lan>
Message-ID: <20141230190236.GA9205@polanet.pl>

+1 to abandoning i486 in current state (keeping last packages on FTP).

On Mon, Dec 15, 2014 at 21:48:03 +0100, Jan R?korajski wrote:

>> Specifically:
>> 	Can RPM assume sse2 instructions and optimize digests/crypto to use sse2?
> 
> No 32bit AMD CPU has this. So, no, you can't do it unconditionally.

Do you think there is anyone using these CPUs under PLD now? I've got
such systems, but haven't powered them up since years... I guess current
i686 users (like me) have other reasons to keep 32-bit system than 32-bit CPU
(like binary/legacy software).

> We're not going to require SSE2 for i686 arch.

So how about replacing i486 with i786?

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


From baggins at pld-linux.org  Tue Dec 30 20:22:01 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 30 Dec 2014 20:22:01 +0100
Subject: The future of i486 arch in Th
In-Reply-To: <20141230190236.GA9205@polanet.pl>
References: <20141215200158.GA2254@home.lan>
 <111215C9-D811-4CDE-AC48-B2D8F7C47064@me.com>
 <20141215204803.GB2254@home.lan> <20141230190236.GA9205@polanet.pl>
Message-ID: <20141230192200.GF2275@home.lan>

On Tue, 30 Dec 2014, Tomasz Pala wrote:

> +1 to abandoning i486 in current state (keeping last packages on FTP).
> 
> On Mon, Dec 15, 2014 at 21:48:03 +0100, Jan R?korajski wrote:
> 
> >> Specifically:
> >> 	Can RPM assume sse2 instructions and optimize digests/crypto to use sse2?
> > 
> > No 32bit AMD CPU has this. So, no, you can't do it unconditionally.
> 
> Do you think there is anyone using these CPUs under PLD now? I've got
> such systems, but haven't powered them up since years... I guess current
> i686 users (like me) have other reasons to keep 32-bit system than 32-bit CPU
> (like binary/legacy software).

If we have i686 arch we need to support i686 CPUs, not a random subset.

> > We're not going to require SSE2 for i686 arch.
> 
> So how about replacing i486 with i786?

Creating such artificial entity would be a waste of resources.

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


From baggins at pld-linux.org  Tue Dec 30 20:23:08 2014
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 30 Dec 2014 20:23:08 +0100
Subject: PostgreSQL and uuid-ossp
In-Reply-To: <54A092C1.1030502@gmail.com>
References: <54A092C1.1030502@gmail.com>
Message-ID: <20141230192307.GG2275@home.lan>

On Mon, 29 Dec 2014, Andrzej Zawadzki wrote:

> Hi!
> 
> I need help: what configure option should I use according to: 
> www.postgresql.org/docs/9.4/static/uuid-ossp.html
> 
> 
> With --with-uuid=ossp
> 
> configure: WARNING: uuid.h: accepted by the compiler, rejected by the 
> preprocessor!
> configure: WARNING: uuid.h: proceeding with the compiler's result
> checking for uuid.h... yes
> configure: error: header file <uuid.h> does not match OSSP UUID library

Can you check config.log why it thinks uuid.h from ossp-uuid is not from
ossp-uuid?

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


From gotar at polanet.pl  Tue Dec 30 22:33:11 2014
From: gotar at polanet.pl (Tomasz Pala)
Date: Tue, 30 Dec 2014 22:33:11 +0100
Subject: The future of i486 arch in Th
In-Reply-To: <20141230192200.GF2275@home.lan>
References: <20141215200158.GA2254@home.lan>
 <111215C9-D811-4CDE-AC48-B2D8F7C47064@me.com>
 <20141215204803.GB2254@home.lan> <20141230190236.GA9205@polanet.pl>
 <20141230192200.GF2275@home.lan>
Message-ID: <20141230213311.GA22900@polanet.pl>

On Tue, Dec 30, 2014 at 20:22:01 +0100, Jan R?korajski wrote:

> If we have i686 arch we need to support i686 CPUs, not a random subset.

We don't "need" to do anything. SSE2 is 13 years old now (and available
for 11 years in AMD), I haven't seen unsupported CPUs in years.

Hardware produced in that time is already dead (capacitors on mainboard
were dead after 2-3 years of running in heat produced by power hungry
CPUs and graphic cards). I've got more fully-functional i586- hardware
in my drawer than early-2000 crapware.
Pre-SSE2 hardware is worth less than energy it consumes, supporting this
is unrational - unless you prefer proper terminology over pragmatic
approach.

>> So how about replacing i486 with i786?
> 
> Creating such artificial entity would be a waste of resources.

Running i686 without modern extensions is a waste of resources.
Creating x32 is a waste of resources (this won't ever be generic purpose arch).
Let's drop i686 as well and call this i686+, i686_with_SSE2 or whatever
you like if i686 name is bogus for SSE2 superset and
i786 is not appropriate (e.g. pentium4 in gcc way).

2012: https://bbs.archlinux.org/viewtopic.php?pid=1153414

Or let's keep ancient. After all there might be 2 or 3 PLD users not
subscribed to pld-devel, one of them might still use 32-bit AMD.

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