Re: [gentoo-dev] Re: stable gcc 5.4.0 ??

[Tomas Mozes]

On Wed, Apr 19, 2017 at 8:25 PM, Walter Dnes  wrote:

> > It is stable. Even there are open bugs, arches started stabilizing it.
>
>   Is gcc-5.4.0 built "--with-default-libstdcxx-abi=gcc4-compatible"?
> On the Pale Moon linux sub-forum, there were crashing issues with the
> contributed Ubuntu build when Ubuntu switched to gcc 5.  The maintainer
> of the Ubuntu Pale Moon build had to drop back to gcc 4.9 to fix the
> crashes.
>
>   At home, for personal use, I build Pale Moon with a manually built
> version of gcc 5.4.0.  Pale Moon has been rock solid for me on Gentoo
> and on a refurbished Lenovo T400 running Puppy Linux.  The option
> "--with-default-libstdcxx-abi=gcc4-compatible" may be the reason it
> works for me.
>
>   This may be valid for other applications, too.  I think the problem is
> that you need the entire system to be one of...
>
> "--with-default-libstdcxx-abi=new" or
>
> "--with-default-libstdcxx-abi=gcc4-compatible"
>
>   Mixing together does not seem to work.
>
> --
> Walter Dnes 
> I don't run "desktop environments"; I run useful applications
>
>
The default is new:
https://www.gentoo.org/support/news-items/2015-10-22-gcc-5-new-c++11-abi.html

Re: [gentoo-dev] [PATCH 01/14] cdrom.eclass: Detect case-insensitively and handle special characters

[James Le Cuirot]

On Wed, 19 Apr 2017 05:14:34 +0200
Michał Górny  wrote:

> >> > @@ -243,4 +240,27 @@ _cdrom_locate_file_on_cd() {
> >> >  done
> >> >  }
> >> >  
> >> > +# @FUNCTION: _cdrom_glob_match
> >> > +# @USAGE:  
> >> > +# @INTERNAL
> >> > +# @DESCRIPTION:
> >> > +# Locates the given path ($2) within the given root directory ($1)
> >> > +# case-insensitively and returns the first actual matching path.  
> >This  
> >> > +# eclass previously used "find -iname" but it only checked the  
> >file  
> >> > +# case-insensitively and not the directories. There is "find  
> >-ipath" but  
> >> > +# this does not intelligently skip non-matching paths, making it
> >> > +# slow. Case-insensitive matching can only be applied to patterns  
> >so  
> >> > +# extended globbing is used to turn regular strings into patterns.  
> >All  
> >> > +# special characters are escaped so don't worry about breaking  
> >this. The  
> >> > +# first person to make this work without an eval wins a cookie.
> >> > +_cdrom_glob_match() {
> >> > +local p=\?\($(sed -e 's:[^A-Za-z0-9/]:\\\0:g' -e 's:/:)/?(:g' 
> >> > <<<  
> >"$2" || die)\)
> >> 
> >> Explanatory comment needed, i.e. what gets converted into what, and  
> >why.
> >
> >I'll add this:
> >
> ># The following line turns this:
> >#  foo*foo/bar bar/baz/file.zip
> >#
> ># Into this:
> >#  ?(foo\*foo)/?(bar\ bar)/?(baz)/?(file\.zip)
> >#
> ># This turns every path component into an escaped extended glob
> ># pattern to allow case-insensitive matching. Globs cannot span
> ># directories so each component becomes an individual pattern.  
> 
> Why do you escape pattern chars? Wasn't the variable supposed to be a
> pattern in the first place?

If you mean in the eclass before I changed it then no. In the non
CD_ROOT case, the basename was passed to "find -iname" but this was not
documented. In the CD_ROOT case, the whole thing was passed to
[[ -e ]] so patterns wouldn't have worked here.

You wouldn't want to use a pattern anyway as you're trying to uniquely
identify the disc using a very specific filename. Conversely, I relaxed
case-sensitivity because this can vary depending on whether we're
dealing with the original disc, a copy of some kind, or an existing
installation that may come from Windows.

The Curse of Monkey Island turned out to be a great example. Both discs
have some files in common like COMI.LA0, however, when mounted with the
default options, it appears upper-cased on the first disc but
lower-cased on the second. Why? The second disc doesn't use Joliet as
all the filenames have the old 8.3 format. Linux normalises these to
lower-case. The first disc does use Joliet because of a single file,
"Curse of Monkey Island - Manual.pdf" so all the other 8.3 filename are
left as upper-case by Linux.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpeNIjKYyVV0.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] News item: changed default bedup configuration file in >=app-backup/burp-2.0.0

[Amadeusz Żołnowski]

Gokturk Yuksek  writes:
> Overall, my impression is that people handle conf file changes in
> pkg_postinst() with REPLACING_VERSIONS rather than news items.

+1. And it could be automated for the user, couldn't be?

Cheers,
-- Amadeusz Żołnowski


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: stable gcc 5.4.0 ??

[Walter Dnes]

> It is stable. Even there are open bugs, arches started stabilizing it.

  Is gcc-5.4.0 built "--with-default-libstdcxx-abi=gcc4-compatible"?
On the Pale Moon linux sub-forum, there were crashing issues with the
contributed Ubuntu build when Ubuntu switched to gcc 5.  The maintainer
of the Ubuntu Pale Moon build had to drop back to gcc 4.9 to fix the
crashes.

  At home, for personal use, I build Pale Moon with a manually built
version of gcc 5.4.0.  Pale Moon has been rock solid for me on Gentoo
and on a refurbished Lenovo T400 running Puppy Linux.  The option
"--with-default-libstdcxx-abi=gcc4-compatible" may be the reason it
works for me.

  This may be valid for other applications, too.  I think the problem is
that you need the entire system to be one of...

"--with-default-libstdcxx-abi=new" or

"--with-default-libstdcxx-abi=gcc4-compatible"

  Mixing together does not seem to work.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-portage-dev] [PATCH] dosym: protect Prefix hack from double EPREFIX

[Michał Górny]

On śro, 2017-04-19 at 18:06 +0200, Ulrich Mueller wrote:
> > > > > > On Wed, 19 Apr 2017, Michał Górny wrote:
> > Add an additional conditional to the dosym Prefix hack to ensure that
> > the symlink is not using double Prefix when the ebuild uses ${EPREFIX}
> > explicitly. This ensures that Portage on Prefix systems is both
> > compatible with the ebuilds relying on the hack, and using dosym
> > in the PMS-defined manner.
> 
>  
>  
> >  destdir=${2%/*}
> >  [[ ! -d ${ED}${destdir} ]] && dodir "${destdir}"
> > -# when absolute, prefix with offset for Gentoo Prefix
> >  target="${1}"
> > -[[ ${target:0:1} == "/" ]] && target="${EPREFIX}${target}"
> > +# DEPRECATED HACK: when absolute, prefix with offset for Gentoo Prefix
> > +# (but only if ${EPREFIX} is not there already)
> 
> Maybe add a date (like 2018-04-30) to the comment after which the code
> can be removed?

I'd rather not force any specific dates, considering the main condition
is to fix the ebuilds relying on it. Maybe a bug number instead?

> 
> > +if [[ ${target:0:1} == "/" && ${target} != "${EPREFIX}"* ]]; then
> 
> I think you want an additional slash in the second condition, in order
> to prevent /foo/barbaz from matching if EPREFIX is equal to /foo/bar:
> 
> if [[ ${target:0:1} == "/" && ${target}/ != "${EPREFIX}"/* ]]; then

Makes sense, I'll do that.

> 
> > +   target="${EPREFIX}${target}"
> > +fi
> >  ln -snf "${target}" "${ED}${2}"
> >  
> >  ret=$?
> 
> Ulrich

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-portage-dev] [PATCH] dosym: protect Prefix hack from double EPREFIX

[Ulrich Mueller]

> On Wed, 19 Apr 2017, Ulrich Mueller wrote:

>> +if [[ ${target:0:1} == "/" && ${target} != "${EPREFIX}"* ]]; then

> I think you want an additional slash in the second condition, in order
> to prevent /foo/barbaz from matching if EPREFIX is equal to /foo/bar:

> if [[ ${target:0:1} == "/" && ${target}/ != "${EPREFIX}"/* ]]; then

>> +target="${EPREFIX}${target}"

One more point, maybe output a QA warning here?

>> +fi
>> ln -snf "${target}" "${ED}${2}"
>> 
>> ret=$?

Ulrich


pgpnbu32eKtEv.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] dosym: protect Prefix hack from double EPREFIX

[Ulrich Mueller]

> On Wed, 19 Apr 2017, Michał Górny wrote:

> Add an additional conditional to the dosym Prefix hack to ensure that
> the symlink is not using double Prefix when the ebuild uses ${EPREFIX}
> explicitly. This ensures that Portage on Prefix systems is both
> compatible with the ebuilds relying on the hack, and using dosym
> in the PMS-defined manner.
 
 
>  destdir=${2%/*}
>  [[ ! -d ${ED}${destdir} ]] && dodir "${destdir}"
> -# when absolute, prefix with offset for Gentoo Prefix
>  target="${1}"
> -[[ ${target:0:1} == "/" ]] && target="${EPREFIX}${target}"
> +# DEPRECATED HACK: when absolute, prefix with offset for Gentoo Prefix
> +# (but only if ${EPREFIX} is not there already)

Maybe add a date (like 2018-04-30) to the comment after which the code
can be removed?

> +if [[ ${target:0:1} == "/" && ${target} != "${EPREFIX}"* ]]; then

I think you want an additional slash in the second condition, in order
to prevent /foo/barbaz from matching if EPREFIX is equal to /foo/bar:

if [[ ${target:0:1} == "/" && ${target}/ != "${EPREFIX}"/* ]]; then

> + target="${EPREFIX}${target}"
> +fi
>  ln -snf "${target}" "${ED}${2}"
>  
>  ret=$?

Ulrich


pgpkQoluwZQnU.pgp
Description: PGP signature

[gentoo-dev] News item: changed default bedup configuration file in >=app-backup/burp-2.0.0

[Marek Szuba]

-- 
MS
Title: app-backup/burp: default config file for bedup
Author: Marek Szuba 
Posted: 2017-04-24
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: app-backup/burp

Starting with version 2.0.54, the default configuration file of the
burp-aware deduplication tool bedup will change from

  /etc/burp/burp-server.conf

to

  /etc/burp/burp.conf .

The latter is the value used by upstream and with burp2 bedup being
a part of the main executable rather than a standalone tool,
maintaining old Gentoo behaviour would needlessly complicate the code.

If you want to keep using burp-server.conf with bedup, you can specify
it on the command line:

  bedup -c /etc/burp/burp-server.conf



signature.asc
Description: OpenPGP digital signature

[gentoo-portage-dev] [PATCH] dosym: protect Prefix hack from double EPREFIX

[Michał Górny]

Add an additional conditional to the dosym Prefix hack to ensure that
the symlink is not using double Prefix when the ebuild uses ${EPREFIX}
explicitly. This ensures that Portage on Prefix systems is both
compatible with the ebuilds relying on the hack, and using dosym
in the PMS-defined manner.
---
 bin/ebuild-helpers/dosym | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/bin/ebuild-helpers/dosym b/bin/ebuild-helpers/dosym
index 0bc8cc7be..5741da346 100755
--- a/bin/ebuild-helpers/dosym
+++ b/bin/ebuild-helpers/dosym
@@ -1,5 +1,5 @@
 #!/bin/bash
-# Copyright 1999-2012 Gentoo Foundation
+# Copyright 1999-2017 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 source "${PORTAGE_BIN_PATH}"/isolated-functions.sh || exit 1
@@ -21,9 +21,12 @@ fi
 
 destdir=${2%/*}
 [[ ! -d ${ED}${destdir} ]] && dodir "${destdir}"
-# when absolute, prefix with offset for Gentoo Prefix
 target="${1}"
-[[ ${target:0:1} == "/" ]] && target="${EPREFIX}${target}"
+# DEPRECATED HACK: when absolute, prefix with offset for Gentoo Prefix
+# (but only if ${EPREFIX} is not there already)
+if [[ ${target:0:1} == "/" && ${target} != "${EPREFIX}"* ]]; then
+   target="${EPREFIX}${target}"
+fi
 ln -snf "${target}" "${ED}${2}"
 
 ret=$?
-- 
2.12.2

Re: [gentoo-dev] Re: stable gcc 5.4.0 ??

[Tomas Mozes]

On Wed, Apr 19, 2017 at 9:31 AM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

> Tomas Mozes wrote:
>
> > On Tue, Apr 18, 2017 at 10:15 AM, Jörg Schaible <
> > joerg.schai...@bpm-inspire.com> wrote:
> >
> >> Hi,
> >>
> >> according the logs, gcc 4.5.0-r3 is stable for amd64:
> >> https://gitweb.gentoo.org/repo/gentoo.git/log/sys-devel/gcc?showmsg=1
> >>
> >> However, after synching the tree, this version is still unstable for me.
> >> Looking at the packages overview, it becomes even more weird, because
> >> there seem to be two 4.5.0-r3 versions, one stable for amd64 and one
> >> unstable: https://packages.gentoo.org/packages/sys-devel/gcc
> >>
> >> Can someone shed some light on this?
> >>
> >> Cheers,
> >> Jörg
> >>
> >>
> >>
> > You did mean 5.4.0-r3, right?
>
> Right. And James found the reason why was not in the stable branch.
>
> Cheers,
> Jörg
>
>
>
It is stable. Even there are open bugs, arches started stabilizing it.

What do you get when you run:
# emerge -pv =sys-devel/gcc-5.4.0-r3

[gentoo-dev] Re: stable gcc 5.4.0 ??

[Jörg Schaible]

Tomas Mozes wrote:

> On Tue, Apr 18, 2017 at 10:15 AM, Jörg Schaible <
> joerg.schai...@bpm-inspire.com> wrote:
> 
>> Hi,
>>
>> according the logs, gcc 4.5.0-r3 is stable for amd64:
>> https://gitweb.gentoo.org/repo/gentoo.git/log/sys-devel/gcc?showmsg=1
>>
>> However, after synching the tree, this version is still unstable for me.
>> Looking at the packages overview, it becomes even more weird, because
>> there seem to be two 4.5.0-r3 versions, one stable for amd64 and one
>> unstable: https://packages.gentoo.org/packages/sys-devel/gcc
>>
>> Can someone shed some light on this?
>>
>> Cheers,
>> Jörg
>>
>>
>>
> You did mean 5.4.0-r3, right?

Right. And James found the reason why was not in the stable branch.

Cheers,
Jörg