[gentoo-portage-dev] [PATCH 2/3] depgraph: fix _validate_blockers to revert state from previous calls

2017-04-18 Thread Zac Medico
Since the _solve_non_slot_operator_slot_conflicts method can
remove packages from the graph, it's possible that some of the
state changes made by previous _validate_blockers calls are
no longer valid. Therefore, revert state when appropriate.
---
 pym/_emerge/depgraph.py | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
index 8a614c4..3232816 100644
--- a/pym/_emerge/depgraph.py
+++ b/pym/_emerge/depgraph.py
@@ -6901,6 +6901,12 @@ class depgraph(object):
self._dynamic_config._blocker_uninstalls = digraph()

self._dynamic_config.digraph.difference_update(previous_uninstall_tasks)
 
+   # Revert state from previous calls.
+   self._dynamic_config._blocker_parents.update(
+   self._dynamic_config._irrelevant_blockers)
+   self._dynamic_config._irrelevant_blockers.clear()
+   self._dynamic_config._unsolvable_blockers.clear()
+
for blocker in 
self._dynamic_config._blocker_parents.leaf_nodes():
self._spinner_update()
root_config = self._frozen_config.roots[blocker.root]
-- 
2.10.2




[gentoo-portage-dev] [PATCH 3/3] depgraph._in_blocker_conflict: call _validate_blockers if needed (bug 615982)

2017-04-18 Thread Zac Medico
Sometimes _complete_graph calls _slot_operator_update_probe, which
sometimes calls _in_blocker_conflict. This case occurs infrequently,
so call _validate_blockers only if needed.

Fixes: a83bb83909c5 ("depgraph: trigger slot operator rebuilds via 
_complete_graph (bug 614390)")
X-Gentoo-bug: 615982
X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=615982
---
 pym/_emerge/depgraph.py | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
index 3232816..e1119af 100644
--- a/pym/_emerge/depgraph.py
+++ b/pym/_emerge/depgraph.py
@@ -2176,9 +2176,9 @@ class depgraph(object):
only works after the _validate_blockers method has been called.
"""
 
-   if self._dynamic_config._blocked_pkgs is None:
-   raise AssertionError(
-   '_in_blocker_conflict called before 
_validate_blockers')
+   if (self._dynamic_config._blocked_pkgs is None
+   and not self._validate_blockers()):
+   raise self._unknown_internal_error()
 
if pkg in self._dynamic_config._blocked_pkgs:
return True
@@ -6728,7 +6728,14 @@ class depgraph(object):
packages within the graph.  If necessary, create hard deps to 
ensure
correct merge order such that mutually blocking packages are 
never
installed simultaneously. Also add runtime blockers from all 
installed
-   packages if any of them haven't been added already (bug 
128809)."""
+   packages if any of them haven't been added already (bug 128809).
+
+   Normally, this method is called only after the graph is 
complete, and
+   after _solve_non_slot_operator_slot_conflicts has had an 
opportunity
+   to solve slot conflicts (possibly removing some blockers). It 
can also
+   be called earlier, in order to get a preview of the blocker 
data, but
+   then it needs to be called again after the graph is complete.
+   """
 
# The _in_blocker_conflict method needs to assert that this 
method
# has been called before it, by checking that it is not None.
-- 
2.10.2




[gentoo-portage-dev] [PATCH 1/3] digraph: add update and clear methods

2017-04-18 Thread Zac Medico
Also, optimize the add method to avoid creating a lot of
duplicate priorities when called by the update method.
---
 pym/portage/tests/util/test_digraph.py |  4 +++-
 pym/portage/util/digraph.py| 26 --
 2 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/pym/portage/tests/util/test_digraph.py 
b/pym/portage/tests/util/test_digraph.py
index f519536..01e075c 100644
--- a/pym/portage/tests/util/test_digraph.py
+++ b/pym/portage/tests/util/test_digraph.py
@@ -88,7 +88,9 @@ class DigraphTest(TestCase):
g.add("D", "A", 2)
 
f = g.clone()
-   for x in g, f:
+   h = digraph()
+   h.update(f)
+   for x in g, f, h:
self.assertEqual(bool(x), True)
self.assertEqual(x.contains("A"), True)
self.assertEqual(x.firstzero(), None)
diff --git a/pym/portage/util/digraph.py b/pym/portage/util/digraph.py
index 99b24fa..ba0e81c 100644
--- a/pym/portage/util/digraph.py
+++ b/pym/portage/util/digraph.py
@@ -44,8 +44,10 @@ class digraph(object):
priorities = []
self.nodes[node][1][parent] = priorities
self.nodes[parent][0][node] = priorities
-   priorities.append(priority)
-   priorities.sort()
+
+   if not priorities or priorities[-1] is not priority:
+   priorities.append(priority)
+   priorities.sort()
 
def discard(self, node):
"""
@@ -73,6 +75,26 @@ class digraph(object):
del self.nodes[node]
self.order.remove(node)
 
+   def update(self, other):
+   """
+   Add all nodes and edges from another digraph instance.
+   """
+   for node in other.order:
+   children, parents, node = other.nodes[node]
+   if parents:
+   for parent, priorities in parents.items():
+   for priority in priorities:
+   self.add(node, parent, 
priority=priority)
+   else:
+   self.add(node, None)
+
+   def clear(self):
+   """
+   Remove all nodes and edges.
+   """
+   self.nodes.clear()
+   del self.order[:]
+
def difference_update(self, t):
"""
Remove all given nodes from node_set. This is more efficient
-- 
2.10.2




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

2017-04-18 Thread Michał Górny
Dnia 18 kwietnia 2017 23:31:31 CEST, James Le Cuirot  
napisał(a):
>On Tue, 18 Apr 2017 08:08:44 +0200
>Michał Górny  wrote:
>
>> On pon, 2017-04-17 at 22:53 +0100, James Le Cuirot wrote:
>> > diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
>> > index 41488d2446c2..de72f15563db 100644
>> > --- a/eclass/cdrom.eclass
>> > +++ b/eclass/cdrom.eclass
>> > @@ -79,12 +79,13 @@ cdrom_get_cds() {
>> >export CDROM_ROOT=${CD_ROOT_1:-${CD_ROOT}}
>> >einfo "Found CD #${CDROM_CURRENT_CD} root at ${CDROM_ROOT}"
>> >export CDROM_SET=-1
>> > -  for f in ${CDROM_CHECK_1//:/ } ; do
>> > +  IFS=:  
>> 
>> 'local', please.
>
>This line disappears later in the series but I've amended it for the
>history anyway.
>
>> > @@ -181,28 +182,24 @@ _cdrom_locate_file_on_cd() {
>> >local showedmsg=0 showjolietmsg=0
>> >  
>> >while [[ -z ${CDROM_ROOT} ]] ; do
>> > -  local i=0
>> > -  local -a cdset=(${*//:/ })
>> > +  local i=0 cdset
>> > +  IFS=: read -a cdset <<< "${*}"  
>> 
>> -r to avoid handling escapes; -d '' to avoid finishing on newline.
>
>Good call.
>
>> > @@ -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?

-- 
Best regards,
Michał Górny (by phone)
-- 
Best regards,
Michał Górny (by phone)



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

2017-04-18 Thread James Le Cuirot
On Tue, 18 Apr 2017 08:08:44 +0200
Michał Górny  wrote:

> On pon, 2017-04-17 at 22:53 +0100, James Le Cuirot wrote:
> > diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
> > index 41488d2446c2..de72f15563db 100644
> > --- a/eclass/cdrom.eclass
> > +++ b/eclass/cdrom.eclass
> > @@ -79,12 +79,13 @@ cdrom_get_cds() {
> > export CDROM_ROOT=${CD_ROOT_1:-${CD_ROOT}}
> > einfo "Found CD #${CDROM_CURRENT_CD} root at ${CDROM_ROOT}"
> > export CDROM_SET=-1
> > -   for f in ${CDROM_CHECK_1//:/ } ; do
> > +   IFS=:  
> 
> 'local', please.

This line disappears later in the series but I've amended it for the
history anyway.

> > @@ -181,28 +182,24 @@ _cdrom_locate_file_on_cd() {
> > local showedmsg=0 showjolietmsg=0
> >  
> > while [[ -z ${CDROM_ROOT} ]] ; do
> > -   local i=0
> > -   local -a cdset=(${*//:/ })
> > +   local i=0 cdset
> > +   IFS=: read -a cdset <<< "${*}"  
> 
> -r to avoid handling escapes; -d '' to avoid finishing on newline.

Good call.

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

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpkMgCgMuOu9.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] cdrom.eclass: Near rewrite

2017-04-18 Thread James Le Cuirot
On Tue, 18 Apr 2017 07:51:58 +0200
Ulrich Mueller  wrote:

> > On Mon, 17 Apr 2017, James Le Cuirot wrote:  
> 
> > If you've been wondering why I've been quiet of late (you have,
> > right?!) then this is partly why. I'm not sure why I spent so long
> > on an eclass that hardly anyone uses but it's utilised by many of my
> > old favourite games.  
> 
> Wouldn't this be a good time to rethink the whole concept? By all our
> standards, ebuilds shouldn't be interactive. AFAICS, cdrom.eclass is
> the last remnant in the tree using PROPERTIES="interactive".

mgorny makes good points, it is indeed not quite that simple.

I didn't actually notice the --accept-properties=-interactive feature
until just now, that's pretty cool.

Although I agree it should be avoided, there may be other uses for it
in future. I'd still like to go ahead with my lgogdownloader plan
(probably via a new src_fetch) and that may need it for entering
credentials on rare occasions though there are other possibilities.

> Maybe the eclass could be replaced by a utility that extracts the ISO
> image and places it into DISTDIR, so that ebuilds could use regular
> non-interactive unpacking? The additional disk space used shouldn't be
> an argument any more with today's large disks.

Don't assume everyone has such huge disks. ;) My main system isn't bad
but that doesn't mean I want to waste the space on something like this.
Many have written optical media off but I still have two big flight
cases full of discs of various kinds nearby.

No one is forced to use this stuff and it is possible to use it in a
non-interactive manner similar to how you suggest. You can copy the
files from the disc(s) and point CD_ROOT to this location in a
per-package env file.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpDGHji1Ztv1.pgp
Description: OpenPGP digital signature


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

2017-04-18 Thread Tomas Mozes
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?


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

2017-04-18 Thread Tomas Mozes
On Tue, Apr 18, 2017 at 3:12 PM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

> Tomas Mozes wrote:
>
> [snip]
>
> > As mentioned by others, bugs on packages.gentoo.org will not affect your
> > portage tree. I've just installed gcc 5.4.0-r3 on amd64, so try syncing
> > your portage tree. Don't you have it in your package.mask?
>
> As said, I synced the tree twice this morning (4 hours ago) and the
> KEYWORDS
> in the ebuild do not declare amd64 as stable although it was committed to
> GIT already yesterday. And this is no wonder, because the stable branch of
> the GIT mirror is still not up-to-date:
> https://github.com/gentoo-mirror/gentoo/tree/stable/sys-devel/gcc
>
> gcc-4.5.0-r3 is declared unstable and is not masked.
>
> Cheers,
> Jörg
>
>
>
According to git
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e2be964b72fce0cdb7c16a378b4fa3fa1d37ee38
- the KEYWORDS have amd64 and x86. The github mirror shows the same
https://raw.githubusercontent.com/gentoo-mirror/gentoo/stable/sys-devel/gcc/gcc-5.4.0-r3.ebuild.
Syncing the tree shows the same.

And as such, on a stable system:

# emerge -p gcc
[ebuild  NS] sys-devel/gcc-5.4.0-r3:5.4.0::gentoo [4.9.4:4.9.4::gentoo]
USE="cxx fortran (multilib) nptl openmp sanitize vtv (-altivec) (-awt)
-cilk -debug -doc (-fixed-point) -gcj -go -graphite (-hardened) (-jit)
(-libssp) -mpx -nls -nopie -nossp -objc -objc++ -objc-gc -regression-test
-vanilla" 0 KiB

The git message says it's stable, the bug report also, the mirrors too, so
yes, it is stable now. Maybe check another rsync mirror.


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

2017-04-18 Thread Jörg Schaible
James Le Cuirot wrote:

> On Tue, 18 Apr 2017 15:12:13 +0200
> Jörg Schaible  wrote:
> 
>> As said, I synced the tree twice this morning (4 hours ago) and the
>> KEYWORDS in the ebuild do not declare amd64 as stable although it was
>> committed to GIT already yesterday. And this is no wonder, because
>> the stable branch of the GIT mirror is still not up-to-date:
>> https://github.com/gentoo-mirror/gentoo/tree/stable/sys-devel/gcc
> 
> It's been held up by this outstanding issue:
> https://qa-reports.gentoo.org/output/gentoo-ci/58d678e2a/output.html#dev-db/psqlodbc
> 

Thanks for the info. Always good to know, why something does not behave as 
expected.

Cheers,
Jörg




Re: [gentoo-dev] [PATCH 7/7] chromium.eclass: Remove no-longer necessary gnome2_icon_savelist call

2017-04-18 Thread Mike Gilbert
On Mon, Apr 17, 2017 at 7:07 AM, Michał Górny  wrote:
> ---
>  eclass/chromium.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/chromium.eclass b/eclass/chromium.eclass
> index 5f8c53cabf35..fcc02dd6e028 100644
> --- a/eclass/chromium.eclass
> +++ b/eclass/chromium.eclass
> @@ -120,7 +120,7 @@ chromium_remove_language_paks() {
>  }
>
>  chromium_pkg_preinst() {
> -   gnome2_icon_savelist
> +   :
>  }
>
>  chromium_pkg_postinst() {
> --
> 2.12.2

I last-rited this eclass back in February, so you can skip this patch.



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

2017-04-18 Thread Aaron W. Swenson
On 2017-04-18 14:27, James Le Cuirot wrote:
> On Tue, 18 Apr 2017 15:12:13 +0200
> Jörg Schaible  wrote:
> 
> > As said, I synced the tree twice this morning (4 hours ago) and the
> > KEYWORDS in the ebuild do not declare amd64 as stable although it was
> > committed to GIT already yesterday. And this is no wonder, because
> > the stable branch of the GIT mirror is still not up-to-date:
> > https://github.com/gentoo-mirror/gentoo/tree/stable/sys-devel/gcc
> 
> It's been held up by this outstanding issue:
> https://qa-reports.gentoo.org/output/gentoo-ci/58d678e2a/output.html#dev-db/psqlodbc

Oh, that’s ridiculous.

I’ve just dropped the particular ebuild that used pgsql-9.1 now.


signature.asc
Description: Digital signature


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

2017-04-18 Thread James Le Cuirot
On Tue, 18 Apr 2017 15:12:13 +0200
Jörg Schaible  wrote:

> As said, I synced the tree twice this morning (4 hours ago) and the
> KEYWORDS in the ebuild do not declare amd64 as stable although it was
> committed to GIT already yesterday. And this is no wonder, because
> the stable branch of the GIT mirror is still not up-to-date:
> https://github.com/gentoo-mirror/gentoo/tree/stable/sys-devel/gcc

It's been held up by this outstanding issue:
https://qa-reports.gentoo.org/output/gentoo-ci/58d678e2a/output.html#dev-db/psqlodbc

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer



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

2017-04-18 Thread Jörg Schaible
Tomas Mozes wrote:

[snip]

> As mentioned by others, bugs on packages.gentoo.org will not affect your
> portage tree. I've just installed gcc 5.4.0-r3 on amd64, so try syncing
> your portage tree. Don't you have it in your package.mask?

As said, I synced the tree twice this morning (4 hours ago) and the KEYWORDS 
in the ebuild do not declare amd64 as stable although it was committed to 
GIT already yesterday. And this is no wonder, because the stable branch of 
the GIT mirror is still not up-to-date:
https://github.com/gentoo-mirror/gentoo/tree/stable/sys-devel/gcc

gcc-4.5.0-r3 is declared unstable and is not masked.

Cheers,
Jörg




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

2017-04-18 Thread Tomas Mozes
On Tue, Apr 18, 2017 at 11:16 AM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

> Hi Tomas,
>
> 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
> >>
> >>
> >>
> > On which platform do you have it unstable? The packages problem is
> > probably related to:
> > https://bugs.gentoo.org/show_bug.cgi?id=612178
>
> Amd64.
>
> Yes, it might be the same problem. The ebuild for gcc-4.5.0-r3 on my
> machine
> lists amd64 as unstable after synching the tree while the ebuild available
> over packages.gentoo.org has a stable version in KEYWORDS.
>
> Even if some GIT mirrors might be out of sync, it does not explain why
> https://packages.gentoo.org/packages/sys-devel/gcc lists the same version
> more than once.
>
> Cheers,
> Jörg
>
>
>
As mentioned by others, bugs on packages.gentoo.org will not affect your
portage tree. I've just installed gcc 5.4.0-r3 on amd64, so try syncing
your portage tree. Don't you have it in your package.mask?


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

2017-04-18 Thread M. J. Everitt
On 18/04/17 10:44, Mart Raudsepp wrote:
> Ühel kenal päeval, T, 18.04.2017 kell 11:16, kirjutas Jörg Schaible:
>> Hi Tomas,
>>
>> 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?showm
 sg=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



>>> On which platform do you have it unstable? The packages problem is
>>> probably related to:
>>> https://bugs.gentoo.org/show_bug.cgi?id=612178
>> Amd64.
>>
>> Yes, it might be the same problem. The ebuild for gcc-4.5.0-r3 on my
>> machine 
>> lists amd64 as unstable after synching the tree while the ebuild
>> available 
>> over packages.gentoo.org has a stable version in KEYWORDS.
>>
>> Even if some GIT mirrors might be out of sync, it does not explain
>> why 
>> https://packages.gentoo.org/packages/sys-devel/gcc lists the same
>> version 
>> more than once.
> This is a packages.gentoo.org Ruby on Rails webapp bug, and has
> absolutely nothing to do with some package being stable on an
> architecture or not. Don't let that disturb you.
>
>
> Mart
>
+1

CONFIRMED but fix unknown at present. Gcc is /not/ the only package that
is affected by the Ruby-on-Rails bug.

RESOLVED:DUPLICATE :]



signature.asc
Description: OpenPGP digital signature


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

2017-04-18 Thread Mart Raudsepp
Ühel kenal päeval, T, 18.04.2017 kell 11:16, kirjutas Jörg Schaible:
> Hi Tomas,
> 
> 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?showm
> > > sg=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
> > > 
> > > 
> > > 
> > 
> > On which platform do you have it unstable? The packages problem is
> > probably related to:
> > https://bugs.gentoo.org/show_bug.cgi?id=612178
> 
> Amd64.
> 
> Yes, it might be the same problem. The ebuild for gcc-4.5.0-r3 on my
> machine 
> lists amd64 as unstable after synching the tree while the ebuild
> available 
> over packages.gentoo.org has a stable version in KEYWORDS.
> 
> Even if some GIT mirrors might be out of sync, it does not explain
> why 
> https://packages.gentoo.org/packages/sys-devel/gcc lists the same
> version 
> more than once.

This is a packages.gentoo.org Ruby on Rails webapp bug, and has
absolutely nothing to do with some package being stable on an
architecture or not. Don't let that disturb you.


Mart



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

2017-04-18 Thread Jörg Schaible
Hi Tomas,

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
>>
>>
>>
> On which platform do you have it unstable? The packages problem is
> probably related to:
> https://bugs.gentoo.org/show_bug.cgi?id=612178

Amd64.

Yes, it might be the same problem. The ebuild for gcc-4.5.0-r3 on my machine 
lists amd64 as unstable after synching the tree while the ebuild available 
over packages.gentoo.org has a stable version in KEYWORDS.

Even if some GIT mirrors might be out of sync, it does not explain why 
https://packages.gentoo.org/packages/sys-devel/gcc lists the same version 
more than once.

Cheers,
Jörg




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

2017-04-18 Thread Tomas Mozes
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
>
>
>
On which platform do you have it unstable? The packages problem is probably
related to:
https://bugs.gentoo.org/show_bug.cgi?id=612178


[gentoo-dev] stable gcc 5.4.0 ??

2017-04-18 Thread Jörg Schaible
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




Re: [gentoo-dev] chromium-59.0.3053.3 will require >=sys-apps/sandbox-2.11 (currently hard masked)

2017-04-18 Thread Mart Raudsepp
Ühel kenal päeval, N, 13.04.2017 kell 16:01, kirjutas Mike Gilbert:
> On Thu, Apr 13, 2017 at 3:29 PM, Paweł Hajdan, Jr.
>  wrote:
> > The latest dev channel release of chromium (59.0.3053.3) will
> > require
> > > =sys-apps/sandbox-2.11 to build.
> > 
> > I'm sending this announcement because this version of sandbox is
> > currently hard masked. So is the chromium version, but with its
> > fast
> > release cycle we can expect it hitting ~arch in few weeks, and
> > stable in
> > the next few weeks. I'd like to make sure we'd be able to push
> > sandbox
> > to stable at the same pace, or find some alternative solution.
> > 
> > For curious folks, new sandbox fixes a hang which occurs with
> > tcmalloc.
> > See https://crbug.com/586444 . The new chromium adds a code
> > generator
> > needed for build (inside the network stack). I didn't find an easy
> > way
> > to disable tcmalloc just for that code generator, and after finding
> > above bug new sandbox seemed like the best choice.
> > 
> > See
> >  > um?id=f2345c0af633116a69051239ab10d858d5aea69a>
> > for the commit which introduced this, and feel free to share your
> > suggestions.
> 
> The sandbox blocker could be moved behind a use-conditional:
> 
> tcmalloc? ( ! 
> If vapier or the QA team don't drop the sandbox mask, we can
> package.mask the tcmalloc USE flag as an interim workaround.

Yeah, I would say unmasking is not possible until
https://bugs.gentoo.org/show_bug.cgi?id=615906 is solved.
Due to that bug, unmasking would mean firefox/thunderbird/etc can't be
upgraded anymore, while chromium could be with optional tcmalloc
support that could be disabled.
Interestingly the XUL sandbox failure is triggered by it hitting ptrace
paths now due to custom allocator, while you apparently need new
sandbox due to a custom allocator choice apparently...

Mart



Re: [gentoo-dev] [PATCH] cdrom.eclass: Near rewrite

2017-04-18 Thread Michał Górny
On wto, 2017-04-18 at 07:51 +0200, Ulrich Mueller wrote:
> > > > > > On Mon, 17 Apr 2017, James Le Cuirot wrote:
> > If you've been wondering why I've been quiet of late (you have,
> > right?!) then this is partly why. I'm not sure why I spent so long
> > on an eclass that hardly anyone uses but it's utilised by many of my
> > old favourite games.
> 
> Wouldn't this be a good time to rethink the whole concept? By all our
> standards, ebuilds shouldn't be interactive. AFAICS, cdrom.eclass is
> the last remnant in the tree using PROPERTIES="interactive".
> 
> Maybe the eclass could be replaced by a utility that extracts the ISO
> image and places it into DISTDIR, so that ebuilds could use regular
> non-interactive unpacking? The additional disk space used shouldn't be
> an argument any more with today's large disks.
> 

I think the eclass supports multiple different CD variants (releases),
including poorly made copies, copy-protected media... I don't think you
can create a file with stable checksum out of them in any sane way.

-- 
Best regards,
Michał Górny


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


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

2017-04-18 Thread Michał Górny
On pon, 2017-04-17 at 22:53 +0100, James Le Cuirot wrote:
> 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. Globbing is used here instead.
> 
> The : character has always been used to delimit paths given to
> cdrom_get_cds, which makes sense because : generally isn't allowed on
> CDs, while whitespace is. Despite that, whitespace was not being
> handled properly and neither were wildcard characters. Now all special
> characters are automatically escaped.
> ---
>  eclass/cdrom.eclass | 48 ++--
>  1 file changed, 34 insertions(+), 14 deletions(-)
> 
> diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
> index 41488d2446c2..de72f15563db 100644
> --- a/eclass/cdrom.eclass
> +++ b/eclass/cdrom.eclass
> @@ -79,12 +79,13 @@ cdrom_get_cds() {
>   export CDROM_ROOT=${CD_ROOT_1:-${CD_ROOT}}
>   einfo "Found CD #${CDROM_CURRENT_CD} root at ${CDROM_ROOT}"
>   export CDROM_SET=-1
> - for f in ${CDROM_CHECK_1//:/ } ; do
> + IFS=:

'local', please.

> + for f in ${CDROM_CHECK_1} ; do
> + unset IFS
>   ((++CDROM_SET))
> - [[ -e ${CDROM_ROOT}/${f} ]] && break
> + export CDROM_MATCH=$(_cdrom_glob_match "${CDROM_ROOT}" 
> "${f}")
> + [[ -n ${CDROM_MATCH} ]] && return
>   done
> - export CDROM_MATCH=${f}
> - return
>   fi
>  
>   # User didn't help us out so lets make sure they know they can
> @@ -181,28 +182,24 @@ _cdrom_locate_file_on_cd() {
>   local showedmsg=0 showjolietmsg=0
>  
>   while [[ -z ${CDROM_ROOT} ]] ; do
> - local i=0
> - local -a cdset=(${*//:/ })
> + local i=0 cdset
> + IFS=: read -a cdset <<< "${*}"

-r to avoid handling escapes; -d '' to avoid finishing on newline.

> +
>   if [[ -n ${CDROM_SET} ]] ; then
> - cdset=(${cdset[${CDROM_SET}]})
> + cdset=( "${cdset[${CDROM_SET}]}" )
>   fi
>  
>   while [[ -n ${cdset[${i}]} ]] ; do
> - local dir=$(dirname ${cdset[${i}]})
> - local file=$(basename ${cdset[${i}]})
> -
>   local point= node= fs= foo=
>   while read point node fs foo ; do
>   [[ " cd9660 iso9660 udf " != *" ${fs} "* ]] && \
>   ! [[ ${fs} == "subfs" && ",${opts}," == 
> *",fs=cdfss,"* ]] \
>   && continue
>   point=${point//\040/ }
> - [[ ! -d ${point}/${dir} ]] && continue
> - [[ -z $(find "${point}/${dir}" -maxdepth 1 
> -iname "${file}") ]] \
> - && continue
> + export CDROM_MATCH=$(_cdrom_glob_match 
> "${point}" "${cdset[${i}]}")
> + [[ -z ${CDROM_MATCH} ]] && continue
>   export CDROM_ROOT=${point}
>   export CDROM_SET=${i}
> - export CDROM_MATCH=${cdset[${i}]}
>   return
>   done <<< "$(get_mounts)"
>  
> @@ -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.

> + (
> + cd "$1" 2>/dev/null || return
> + shopt -s extglob nocaseglob nullglob || die
> + eval "ARRAY=( ${p} )"
> + echo ${ARRAY[0]}
> + )
> +}
> +
>  fi

-- 
Best regards,
Michał Górny


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