[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-11-06 23:59 UTC

[Robin H. Johnson]

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2016-11-06 23:59 UTC.

Removals:
dev-haskell/base64-conduit 20161031-16:17 mgorny   2baddf7
dev-java/jmf-bin   20161106-14:52 monsieurpa2fe593
dev-libs/dbxml 20161031-16:19 mgorny   da253ea
dev-perl/google-api-adwords-perl   20161105-05:05 kentnl   7434d6b
kde-base/baloo 20161106-11:46 johu dfbe8e6
kde-base/kdeplasma-addons  20161103-08:25 johu 4f1d0d7
kde-base/kfilemetadata 20161106-11:17 johu 6123e26
kde-base/khotkeys  20161103-18:51 johu 04985ea
kde-base/kinfocenter   20161103-19:13 johu f890534
kde-base/kmenuedit 20161103-18:30 johu c74362d
kde-base/ksysguard 20161104-11:48 johu 141e694
kde-base/kwin  20161106-12:17 johu a3f30b0
kde-base/kwrited   20161103-10:34 johu 832d64a
kde-base/powerdevil20161103-09:56 johu 4bc4523
kde-base/systemsettings20161106-10:37 johu 7d60189
kde-misc/kde-gtk-config20161103-09:37 johu 1ce9e46
kde-misc/kscreen   20161105-12:08 johu 14a91c7
kde-misc/milou 20161103-09:11 johu a610c35
net-im/silc-server 20161031-15:51 mgorny   ee55966
net-libs/socket++  20161031-16:21 mgorny   875e067
sci-mathematics/agda-executable20161031-16:05 mgorny   6e639e3
x11-libs/libkscreen20161105-12:26 johu 5aa27ae

Additions:
app-arch/gnome-autoar  20161101-15:18 eva  c915b78
app-backup/bup 20161104-06:05 radhermite478f1f
app-emulation/hyperd   20161106-17:16 mrueg7df9115
app-emulation/runv 20161106-17:04 mruegb902488
app-vim/editorconfig-vim   20161104-22:38 chutzpah 8c3b908
dev-go/go-bindata  20161105-13:31 mrueg1f78efc
dev-go/go-bindata-assetfs  20161105-13:34 mrueg8b593d2
dev-java/animal-sniffer-annotations20161105-21:53 chewi096a349
dev-java/error-prone-annotations   20161105-22:03 chewi3c54c5e
dev-java/j2objc-annotations20161105-22:10 chewi72281d9
dev-libs/icu-layoutex  20161106-15:43 polynomial-c ea7d02f
dev-libs/icu-le-hb 20161106-13:17 polynomial-c 0827ad3
dev-perl/Glib-Object-Introspection 20161025-07:46 soap dc0f3e4
dev-perl/Google-Ads-AdWords-Client 20161105-05:02 kentnl   b6bd6f4
dev-perl/JSON-Parse20161105-07:45 kentnl   7820060
dev-python/flask-babelex   20161106-10:59 dev-zero cc3811a
dev-python/flask-sphinx-themes 20161106-10:57 dev-zero 010105e
dev-python/geoalchemy2 20161106-11:10 dev-zero 0c69eda
dev-python/safety  20161031-22:40 mrueg153e3aa
dev-python/shapely 20161106-11:06 dev-zero 39530ef
dev-ruby/public_suffix 20161105-06:33 graaff   c468e85
dev-util/lldb  20161017-08:24 mgorny   ab09f94
kde-misc/plasma-applet-network-monitor 20161102-21:49 johu 2b1ab0e
kde-misc/plasma-applet-weather-widget  20161102-21:54 johu 9419756
media-video/orion  20161102-19:00 voyageur 20b5ba3
sys-apps/ripgrep   20161031-07:11 radhermit23a0534
sys-kernel/bliss-initramfs 20161105-18:43 fearedbliss  0547d4e

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
dev-java/jmf-bin,removed,monsieurp,20161106-14:52,a2fe593
kde-base/kwin,removed,johu,20161106-12:17,a3f30b0
kde-base/baloo,removed,johu,20161106-11:46,dfbe8e6
kde-base/kfilemetadata,removed,johu,20161106-11:17,6123e26
kde-base/systemsettings,removed,johu,20161106-10:37,7d60189
x11-libs/libkscreen,removed,johu,20161105-12:26,5aa27ae
kde-misc/kscreen,removed,johu,20161105-12:08,14a91c7
dev-perl/google-api-adwords-perl,removed,kentnl,20161105-05:05,7434d6b
kde-base/ksysguard,removed,johu,20161104-11:48,141e694
kde-base/kinfocenter,removed,johu,20161103-19:13,f890534
kde-base/khotkeys,removed,johu,20161103-18:51,04985ea
kde-base/kmenuedit,removed,johu,20161103-18:30,c74362d
kde-base/kwrited,removed,johu,20161103-10:34,832d64a
kde-base/powerdevil,removed,johu,20161103-09:56,4bc4523
kde-misc/kde-gtk-config,removed,johu,20161103-09:37,1ce9e46
kde-misc/milou,removed,johu,20161103-09:11,a610c35
kde-base/kdeplasma-addons,removed,johu,20161103-08:25,4f1d0d7
net-libs/socket++,removed,mgorny,20161031-16

[gentoo-portage-dev] [PATCH v3] parse_metadata_use: apply English language preference (bug 599060)

[Zac Medico]

Descriptions may exist for multiple languages, so prefer English
language descriptions for use.local.desc content.

X-Gentoo-Bug: 599060
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=599060
---
 pym/portage/xml/metadata.py | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

[PATCH v3] sort languages by preference

diff --git a/pym/portage/xml/metadata.py b/pym/portage/xml/metadata.py
index 4940bfb..39aa738 100644
--- a/pym/portage/xml/metadata.py
+++ b/pym/portage/xml/metadata.py
@@ -61,7 +61,7 @@ except (ImportError, SystemError, RuntimeError, Exception):
 import re
 import xml.etree.ElementTree
 from portage import _encodings, _unicode_encode
-from portage.util import unique_everseen
+from portage.util import cmp_sort_key, unique_everseen
 
 if sys.hexversion >= 0x300:
# pylint: disable=W0622
@@ -430,6 +430,19 @@ class MetaDataXML(object):
maint_str = " ".join(maintainers)
return maint_str
 
+# lang with higher value is preferred
+_lang_pref = {
+   ""  :  0,
+   "en":  1,
+}
+
+
+def _cmp_lang(a, b):
+   a_score = _lang_pref.get(a.get("lang", ""), -1)
+   b_score = _lang_pref.get(b.get("lang", ""), -1)
+
+   return a_score - b_score
+
 
 def parse_metadata_use(xml_tree):
"""
@@ -443,6 +456,9 @@ def parse_metadata_use(xml_tree):
if not usetags:
return uselist
 
+   # Sort by language preference in descending order.
+   usetags.sort(key=cmp_sort_key(_cmp_lang), reverse=True)
+
# It's possible to have multiple 'use' elements.
for usetag in usetags:
flags = usetag.findall("flag")
@@ -455,6 +471,16 @@ def parse_metadata_use(xml_tree):
if pkg_flag is not None:
flag_restrict = flag.get("restrict")
 
+   # Descriptions may exist for multiple 
languages, so
+   # ignore all except the first description found 
for a
+   # particular value of restrict (see bug 599060).
+   try:
+   uselist[pkg_flag][flag_restrict]
+   except KeyError:
+   pass
+   else:
+   continue
+
# emulate the Element.itertext() method from 
python-2.7
inner_text = []
stack = []
-- 
2.7.4

Re: [gentoo-dev] New portage git sync behavior

[Zac Medico]

On 09/20/2016 08:02 PM, Mike Gilbert wrote:
> Portage 2.3.1 changes the default behavior for git repositories to
> sync with a depth of 1. If you are using a development tree with
> emerge --sync, you may want to override this in repos.conf by setting
> sync-depth = 0.
> 
> If you have accidentally converted your development tree into a
> shallow repository, you can undo the damage by running git fetch
> --unshallow.
> 

I've proposed to revert the change in behavior because we've had too
many problems with it:

https://archives.gentoo.org/gentoo-portage-dev/message/e0314d5c748ec4098605c20d9b42b2a9
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] [PATCH v2] parse_metadata_use: prefer first language found (bug 599060)

[Zac Medico]

On 11/06/2016 12:52 PM, Michał Górny wrote:
> On Sun,  6 Nov 2016 12:37:22 -0800
> Zac Medico  wrote:
> 
>> Descriptions may exist for multiple languages, so ignore all except
>> the first description found for a particular value of restrict, so
>> that use.local.desc content is consistent.
>>
>> X-Gentoo-Bug: 599060
>> X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=599060
>> ---
>>  pym/portage/xml/metadata.py | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> [PATCH v2] fix to handle multiple values of restrict
>>
>> diff --git a/pym/portage/xml/metadata.py b/pym/portage/xml/metadata.py
>> index 4940bfb..1bc1c78 100644
>> --- a/pym/portage/xml/metadata.py
>> +++ b/pym/portage/xml/metadata.py
>> @@ -455,6 +455,16 @@ def parse_metadata_use(xml_tree):
>>  if pkg_flag is not None:
>>  flag_restrict = flag.get("restrict")
>>  
>> +# Descriptions may exist for multiple 
>> languages, so
>> +# ignore all except the first description found 
>> for a
>> +# particular value of restrict (see bug 599060).
>> +try:
>> +uselist[pkg_flag][flag_restrict]
>> +except KeyError:
>> +pass
>> +else:
>> +continue
>> +
>>  # emulate the Element.itertext() method from 
>> python-2.7
>>  inner_text = []
>>  stack = []
> 
> This really doesn't fix the bug at hand. We should always prefer
> English descriptions, either through lang="en" or lang="".

I'll update the patch to enforce this by using lang to order the "use"
elements according to our preference.
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] [PATCH v2] parse_metadata_use: prefer first language found (bug 599060)

[Michał Górny]

On Sun,  6 Nov 2016 12:37:22 -0800
Zac Medico  wrote:

> Descriptions may exist for multiple languages, so ignore all except
> the first description found for a particular value of restrict, so
> that use.local.desc content is consistent.
> 
> X-Gentoo-Bug: 599060
> X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=599060
> ---
>  pym/portage/xml/metadata.py | 10 ++
>  1 file changed, 10 insertions(+)
> 
> [PATCH v2] fix to handle multiple values of restrict
> 
> diff --git a/pym/portage/xml/metadata.py b/pym/portage/xml/metadata.py
> index 4940bfb..1bc1c78 100644
> --- a/pym/portage/xml/metadata.py
> +++ b/pym/portage/xml/metadata.py
> @@ -455,6 +455,16 @@ def parse_metadata_use(xml_tree):
>   if pkg_flag is not None:
>   flag_restrict = flag.get("restrict")
>  
> + # Descriptions may exist for multiple 
> languages, so
> + # ignore all except the first description found 
> for a
> + # particular value of restrict (see bug 599060).
> + try:
> + uselist[pkg_flag][flag_restrict]
> + except KeyError:
> + pass
> + else:
> + continue
> +
>   # emulate the Element.itertext() method from 
> python-2.7
>   inner_text = []
>   stack = []

This really doesn't fix the bug at hand. We should always prefer
English descriptions, either through lang="en" or lang="".

-- 
Best regards,
Michał Górny



pgplpQgZxt5pz.pgp
Description: OpenPGP digital signature

[gentoo-portage-dev] [PATCH v2] parse_metadata_use: prefer first language found (bug 599060)

[Zac Medico]

Descriptions may exist for multiple languages, so ignore all except
the first description found for a particular value of restrict, so
that use.local.desc content is consistent.

X-Gentoo-Bug: 599060
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=599060
---
 pym/portage/xml/metadata.py | 10 ++
 1 file changed, 10 insertions(+)

[PATCH v2] fix to handle multiple values of restrict

diff --git a/pym/portage/xml/metadata.py b/pym/portage/xml/metadata.py
index 4940bfb..1bc1c78 100644
--- a/pym/portage/xml/metadata.py
+++ b/pym/portage/xml/metadata.py
@@ -455,6 +455,16 @@ def parse_metadata_use(xml_tree):
if pkg_flag is not None:
flag_restrict = flag.get("restrict")
 
+   # Descriptions may exist for multiple 
languages, so
+   # ignore all except the first description found 
for a
+   # particular value of restrict (see bug 599060).
+   try:
+   uselist[pkg_flag][flag_restrict]
+   except KeyError:
+   pass
+   else:
+   continue
+
# emulate the Element.itertext() method from 
python-2.7
inner_text = []
stack = []
-- 
2.7.4

[gentoo-portage-dev] [PATCH] parse_metadata_use: prefer first language found (bug 599060)

[Zac Medico]

Descriptions may exist for multiple languages, so ignore all except
the first description found, so that use.local.desc content is
consistent.

X-Gentoo-Bug: 599060
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=599060
---
 pym/portage/xml/metadata.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/pym/portage/xml/metadata.py b/pym/portage/xml/metadata.py
index 4940bfb..ae9d193 100644
--- a/pym/portage/xml/metadata.py
+++ b/pym/portage/xml/metadata.py
@@ -452,7 +452,9 @@ def parse_metadata_use(xml_tree):
 
for flag in flags:
pkg_flag = flag.get("name")
-   if pkg_flag is not None:
+   # Descriptions may exist for multiple languages, so 
ignore
+   # all except the first description found (see bug 
599060).
+   if pkg_flag is not None and pkg_flag not in uselist:
flag_restrict = flag.get("restrict")
 
# emulate the Element.itertext() method from 
python-2.7
-- 
2.7.4

Re: [gentoo-portage-dev] [PATCH] sync: call git prune before shallow fetch (bug 599008)

[Zac Medico]

On 11/06/2016 10:46 AM, Zac Medico wrote:
> On 11/06/2016 01:59 AM, Michał Górny wrote:
>> On Sat, 5 Nov 2016 15:56:20 -0700
>> Zac Medico  wrote:
>>
>>> On 11/05/2016 03:22 PM, Michał Górny wrote:
 On Sat, 5 Nov 2016 15:11:10 -0700
 Zac Medico  wrote:
   
> On 11/05/2016 02:50 PM, Michał Górny wrote:  
>> On Sat,  5 Nov 2016 13:43:15 -0700
>> Zac Medico  wrote:
>> 
>>> This is necessary in order to avoid "There are too many unreachable
>>> loose objects" warnings from automatic git gc calls.
>>>
>>> X-Gentoo-Bug: 599008
>>> X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=599008
>>> ---
>>>  pym/portage/sync/modules/git/git.py | 6 ++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/pym/portage/sync/modules/git/git.py 
>>> b/pym/portage/sync/modules/git/git.py
>>> index f288733..c90cf88 100644
>>> --- a/pym/portage/sync/modules/git/git.py
>>> +++ b/pym/portage/sync/modules/git/git.py
>>> @@ -101,6 +101,12 @@ class GitSync(NewBase):
>>> writemsg_level(msg + "\n", 
>>> level=logging.ERROR, noiselevel=-1)
>>> return (e.returncode, False)
>>>  
>>> +   # For shallow fetch, unreachable objects must 
>>> be pruned
>>> +   # manually, since otherwise automatic git gc 
>>> calls will
>>> +   # eventually warn about them (see bug 599008).
>>> +   subprocess.call(['git', 'prune'],
>>> +   
>>> cwd=portage._unicode_encode(self.repo.location))
>>> +
>>> git_cmd_opts += " --depth %d" % 
>>> self.repo.sync_depth
>>> git_cmd = "%s fetch %s%s" % (self.bin_command,
>>> remote_branch.partition('/')[0], 
>>> git_cmd_opts)
>>
>> Does it have a performance impact?
>
> Yes, it takes about 20 seconds on my laptop. I suppose we could make
> this an optional thing, so that those people can do it manually if they
> want.  

 So we have improvement from at most few seconds for normal 'git pull'
 to around a minute for shallow pull?  
>>>
>>> Well we've got a least 3 resources to consider:
>>>
>>> 1) network bandwidth
>>> 2) disk usage
>>> 3) sync time
>>>
>>> For me, sync time doesn't really matter that much, but I suppose it
>>> might for some people.
>>
>> For a common user, network bandwidth is not a problem with git (except
>> maybe for the huge initial clone). Especially when syncing frequently,
>> the gain from subsequent --depth=1 is negligible. When syncing rarely,
>> you probably prefer snapshots anyway.
>>
>> I doubt this could be of benefit even to dial-up users; that is,
>> that more time would be saved on fetching than lost on all the ops
>> needed to make things continue to work. The additional data won't
>> affect the data plan users much probably either.
>>
>> Especially that Gentoo is all about fetching distfiles that are huge
>> compared to the git updates for the repository.
>>
>> As for the disk usage, again, the difference should be negligible.
>> The major difference is done on initial fetch. Of course, regularly
>> pruning the repository will reduce its size. But then, pruning it will
>> non-shallow fetches would probably achieve a similar effect thanks to
>> delta compression.
>>
>> That leaves the sync time. Which is becoming worse than rsync.
> 
> Maybe this will be a reasonable default:
> 
> * add a separate clone-depth setting which defaults to 1
> * set the default sync-depth setting to 0 (unlimited)
> 
> If the user enables shallow fetch by setting sync-depth to something
> other than 0, they I think we should call whatever commands are
> necessary to keep the repository healthy (including `git prune` if
> necessary).

I think we should just revert all of the bug 552814 (shallow git fetch)
stuff for now:

https://archives.gentoo.org/gentoo-portage-dev/message/e0314d5c748ec4098605c20d9b42b2a9
-- 
Thanks,
Zac

[gentoo-portage-dev] Vote to revert all changes related to shallow git fetch from bug 552814

[Zac Medico]

Given the performance issues introduced by `git update-index` and `git
prune`, shallow fetch doesn't seem to be a practical default at this time.

In order to prepare a release that will be eligible for stabilization, I
propose that we revert all of the changes related to bug 552814:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=84413bb1dd9df322568ce25efc5b7854a43d03c7
https://gitweb.gentoo.org/proj/portage.git/commit/?id=55aef9bf297ef8cbf29921acb454449d01313818
https://gitweb.gentoo.org/proj/portage.git/commit/?id=f5d258656de3db54af06fbca9b8da5217d3802f4
https://gitweb.gentoo.org/proj/portage.git/commit/?id=f77fcd6b0b4ebb49ca62f5767cd5c931127c3dbb
https://gitweb.gentoo.org/proj/portage.git/commit/?id=d075422a8902617833ec945d94beb0bb334d44c9

-- 
Thanks,
Zac

Re: [gentoo-portage-dev] [PATCH] sync: call git prune before shallow fetch (bug 599008)

[Zac Medico]

On 11/06/2016 01:59 AM, Michał Górny wrote:
> On Sat, 5 Nov 2016 15:56:20 -0700
> Zac Medico  wrote:
> 
>> On 11/05/2016 03:22 PM, Michał Górny wrote:
>>> On Sat, 5 Nov 2016 15:11:10 -0700
>>> Zac Medico  wrote:
>>>   
 On 11/05/2016 02:50 PM, Michał Górny wrote:  
> On Sat,  5 Nov 2016 13:43:15 -0700
> Zac Medico  wrote:
> 
>> This is necessary in order to avoid "There are too many unreachable
>> loose objects" warnings from automatic git gc calls.
>>
>> X-Gentoo-Bug: 599008
>> X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=599008
>> ---
>>  pym/portage/sync/modules/git/git.py | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/pym/portage/sync/modules/git/git.py 
>> b/pym/portage/sync/modules/git/git.py
>> index f288733..c90cf88 100644
>> --- a/pym/portage/sync/modules/git/git.py
>> +++ b/pym/portage/sync/modules/git/git.py
>> @@ -101,6 +101,12 @@ class GitSync(NewBase):
>>  writemsg_level(msg + "\n", 
>> level=logging.ERROR, noiselevel=-1)
>>  return (e.returncode, False)
>>  
>> +# For shallow fetch, unreachable objects must 
>> be pruned
>> +# manually, since otherwise automatic git gc 
>> calls will
>> +# eventually warn about them (see bug 599008).
>> +subprocess.call(['git', 'prune'],
>> +
>> cwd=portage._unicode_encode(self.repo.location))
>> +
>>  git_cmd_opts += " --depth %d" % 
>> self.repo.sync_depth
>>  git_cmd = "%s fetch %s%s" % (self.bin_command,
>>  remote_branch.partition('/')[0], 
>> git_cmd_opts)
>
> Does it have a performance impact?

 Yes, it takes about 20 seconds on my laptop. I suppose we could make
 this an optional thing, so that those people can do it manually if they
 want.  
>>>
>>> So we have improvement from at most few seconds for normal 'git pull'
>>> to around a minute for shallow pull?  
>>
>> Well we've got a least 3 resources to consider:
>>
>> 1) network bandwidth
>> 2) disk usage
>> 3) sync time
>>
>> For me, sync time doesn't really matter that much, but I suppose it
>> might for some people.
> 
> For a common user, network bandwidth is not a problem with git (except
> maybe for the huge initial clone). Especially when syncing frequently,
> the gain from subsequent --depth=1 is negligible. When syncing rarely,
> you probably prefer snapshots anyway.
> 
> I doubt this could be of benefit even to dial-up users; that is,
> that more time would be saved on fetching than lost on all the ops
> needed to make things continue to work. The additional data won't
> affect the data plan users much probably either.
> 
> Especially that Gentoo is all about fetching distfiles that are huge
> compared to the git updates for the repository.
> 
> As for the disk usage, again, the difference should be negligible.
> The major difference is done on initial fetch. Of course, regularly
> pruning the repository will reduce its size. But then, pruning it will
> non-shallow fetches would probably achieve a similar effect thanks to
> delta compression.
> 
> That leaves the sync time. Which is becoming worse than rsync.

Maybe this will be a reasonable default:

* add a separate clone-depth setting which defaults to 1
* set the default sync-depth setting to 0 (unlimited)

If the user enables shallow fetch by setting sync-depth to something
other than 0, they I think we should call whatever commands are
necessary to keep the repository healthy (including `git prune` if
necessary).
-- 
Thanks,
Zac

Re: [gentoo-dev] Use --with-sysroot configure switch when cross-compiling

[Gerhard Bräunlich]

OK. No problem. Tanks.

Re: [gentoo-portage-dev] portage-2.3.2 stable request?

[Brian Dolbec]

On Sat, 5 Nov 2016 13:56:44 +0100
Manuel Rüger  wrote:

> On 05.11.2016 00:15, Zac Medico wrote:
> > On 11/04/2016 03:55 PM, Zac Medico wrote:  
> >> On 11/04/2016 03:47 PM, Brian Dolbec wrote:  
> >>> On Fri, 4 Nov 2016 13:53:02 -0700
> >>> Zac Medico  wrote:
> >>>  
>  On 11/04/2016 01:43 PM, Michał Górny wrote:  
> > On Fri, 4 Nov 2016 13:19:39 -0700
> > Zac Medico  wrote:
> > 
> >> On 11/04/2016 01:14 PM, Brian Dolbec wrote:
> >>> On Thu, 3 Nov 2016 15:55:23 -0700
> >>> Zac Medico  wrote:
> >>>   
>  In about a week, portage-2.3.2 will be eligible for a stable
>  request.
> 
>  The only potential problem that I've noticed is the complaint
>  about changes from bug 552814 causing issues for people using
>  git sync with overlay filesystems, but setting sync-depth = 0
>  gives those users a workaround. There's also bug 597838,
>  about the sync-depth setting being ineffective, but I only
>  know of a couple of people that have been able to reproduce
>  that.
> 
>  So, do we want to do a stable request portage-2.3.2 when the
>  time comes?  
> >>>
> >>> I'm not sure.  Do we -r1 it adding a patch or two and ask it
> >>> be stabled?   
> >>
> >> There are just 4 commits since 2.3.2, and they all look good.
> >> Maybe we should just cut a 2.3.3 release and wait another 30
> >> days (we also need to stabilize app-crypt/gkeys since it's
> >> needed by emerge-webrsync now).
> >
> > Wouldn't it be better to have a really working version of gkeys
> > before it's stabilized? Like one that could be used without
> > having to create custom configuration files and/or run it as
> > root?
> 
>  Well, gkeys stabilization is not really mandatory, since
>  emerge-webrsync has a --insecure option.  
> >>>
> >>> Why don't I/we work on whatever changes are needed to merge the
> >>> meta-manifest code to both portage and gkeys.  I'll push out
> >>> another release.  I also had some initial code that added gkeys
> >>> use to verify the pkg Manifest file, but I don't know if that is
> >>> needed still, the meta-manifest system will need to run a verify
> >>> at the end of the sync.
> >>>
> >>> We'll have to poke Robin some more to get some new infra keys
> >>> setup.
> >>>
> >>> If I have to, maybe I'll create some ansible scripts to run the
> >>> dev seeds update on vulture, transfer it to my system to push
> >>> --sign to api.g.o or break down and get Kristian to help me get
> >>> key forwarding better setup so I can do it from vulture.  
> >>
> >> Sounds good, but I think we should cut a portage 2.3.3 release
> >> before we make any more changes. Maybe do a release branch that
> >> includes everything except the emerge-webrsync change.  
> > 
> > Let's just revert the emerge-webrsync patch, so we can tag a 2.3.3
> > release on the master branch.
> >   
> 
> Will repoman be released with the same tag as well or is the portage
> and repoman version not going to be syncronized?
> 
> Cheers,
> 
> Manuel
> 

they are semi-independent, so will only be synchronized when API
changes force it to be.

-- 
Brian Dolbec 

Re: [gentoo-dev] RFC: Future EAPI version operator changes

[Jan Chren (rindeal)]

First of all thank you for the research and wish you a good luck in
making the changes happen.


## Reordering to PACKAGE OP VERSION

 [ ] [:]

is more sane than

 [:] [ ]

even though it's not so "hierarchically correct".

Thus instead of writing

dev-foo/bar:4===4.1

one would write

dev-foo/bar==4.1*:4=

which is nicely readable.

But in case the box brackets notation gets incorporated (as in Exheres),

 [:] [[ ]]

is the way to go.


## Version ranges

dev-foo/bar:0[(>=2 && <4) || (>=6 && <10)][baz?]

looks the most promising to me as it allows to include and exclude any
number of ranges.


## Things not included

### Comments/annotations

Currently, there is no way to put inline comments to *DEPEND, IUSE,
..., thus the only supported way is to put the comments above the
specification and somehow tell the reader what part of the
specification is the comment about. For 3-4 deps it's acceptable, for
20+ it's insane and thus no one does it, losing valuable information
about the reasoning by doing so.

Mu current workaround is:

DEPEND_A=(
   # comment
   "cat/pkg..."
   "|| ("
  # comment
  "cat/foo"
  "cat/bar"
   ")"
)
DEPEND="${DEPEND_A[*]}"


### Logical operators for groups

 OR

Currently there is no way to specify:

foo||bar? (
  cat/pkg
)

and one has to copy a lot:

foo? (
  cat/pkg
)
bar? (
  cat/pkg
)

 AND

AND can be specified via nested groups:

foo? (
  bar? (
cat/pkg
  )
)

but this syntax is verbose and not explicit.

foo&? (
  cat/pkg
)

would be much more readable.

[gentoo-dev] RFC: Future EAPI version operator changes

[Michał Górny]

Hi, everyone.

Following my previous RFC wrt version operator problems, I'd like to
start the second part of the discussion: how to improve version
operators in a Future EAPI?

I've collected various ideas on operator changes on a wiki page [1].
I've tried to stay open-minded and cover every possibility, even though
I doubt some of them would be even considered.

I should warn you that some of the solutions are interlinked to each
other, and you probably need to look through the whole page first
before starting to construct an opinion. For example, specific
solutions to most of the problems depend on whether we enable version
ranges and in which form.

I think we should start by loosely discussing the various ideas
on the wiki page. Feel free to also point out any missing ideas
or remarks that would be useful there.

So, what are your comments?

[1]:https://wiki.gentoo.org/wiki/Future_EAPI/Version_syntax_changes

-- 
Best regards,
Michał Górny



pgpRbMVwWCcu1.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Use --with-sysroot configure switch when cross-compiling

[James Le Cuirot]

On Sun, 6 Nov 2016 11:19:02 +0100
Gerhard Bräunlich  wrote:

> Dear gentoo devs
> In August I reported the following bug:
> https://bugs.gentoo.org/show_bug.cgi?id=590404
> James Le Cuirot suggested to automatically use the --with-sysroot 
> configure switch when cross-compiling (
> checking for its presence in --help like for --docdir).
> 
> I proposed a patch in the above bug report for phase-helpers.sh. However 
> as the current version of phase-helpers.sh calls "
> ___eapi_econf_passes_", I suppose that we should add a corresponding 
> ___eapi_econf_passes_--with-sysroot function in eapi.sh.
> There I am not sure which EAPIs are allowed to be modified.
> 
> What do you think?

Sorry for not replying to the bug report recently, I'm battling on many
fronts. That function would not make sense unless --with-sysroot is
introduced into PMS. We could do that but many existing ebuilds would
fail to cross-compile and with hundreds of ebuilds still sitting at
EAPI 0, we could be waiting a long time for fixes. I noted that while
PMS does say which options you must pass, it doesn't say that you
cannot pass additional ones. I've tested it a lot and I've never seen
--with-sysroot break any ebuilds, while it fixes very many, so I
believe it would be safe to pass this option on all EAPIs. We would
probably only pass it when SYSROOT!=/ anyway so it wouldn't affect many
users. This is more or less what you did in your own patch. We are
discussing exactly what influence SYSROOT should have on Portage in
bug #573306 so that we can cement this into EAPI 7 but I believe we can
still rely on SYSROOT in earlier EAPIs when it's set to the same value
as ROOT.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpXfUlKrVVUH.pgp
Description: OpenPGP digital signature

[gentoo-dev] Use --with-sysroot configure switch when cross-compiling

[Gerhard Bräunlich]

Dear gentoo devs
In August I reported the following bug:
https://bugs.gentoo.org/show_bug.cgi?id=590404
James Le Cuirot suggested to automatically use the --with-sysroot 
configure switch when cross-compiling (

checking for its presence in --help like for --docdir).

I proposed a patch in the above bug report for phase-helpers.sh. However 
as the current version of phase-helpers.sh calls "
___eapi_econf_passes_", I suppose that we should add a corresponding 
___eapi_econf_passes_--with-sysroot function in eapi.sh.

There I am not sure which EAPIs are allowed to be modified.

What do you think?

Re: [gentoo-portage-dev] [PATCH] sync: call git prune before shallow fetch (bug 599008)

[Michał Górny]

On Sat, 5 Nov 2016 15:56:20 -0700
Zac Medico  wrote:

> On 11/05/2016 03:22 PM, Michał Górny wrote:
> > On Sat, 5 Nov 2016 15:11:10 -0700
> > Zac Medico  wrote:
> >   
> >> On 11/05/2016 02:50 PM, Michał Górny wrote:  
> >>> On Sat,  5 Nov 2016 13:43:15 -0700
> >>> Zac Medico  wrote:
> >>> 
>  This is necessary in order to avoid "There are too many unreachable
>  loose objects" warnings from automatic git gc calls.
> 
>  X-Gentoo-Bug: 599008
>  X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=599008
>  ---
>   pym/portage/sync/modules/git/git.py | 6 ++
>   1 file changed, 6 insertions(+)
> 
>  diff --git a/pym/portage/sync/modules/git/git.py 
>  b/pym/portage/sync/modules/git/git.py
>  index f288733..c90cf88 100644
>  --- a/pym/portage/sync/modules/git/git.py
>  +++ b/pym/portage/sync/modules/git/git.py
>  @@ -101,6 +101,12 @@ class GitSync(NewBase):
>   writemsg_level(msg + "\n", 
>  level=logging.ERROR, noiselevel=-1)
>   return (e.returncode, False)
>   
>  +# For shallow fetch, unreachable objects must 
>  be pruned
>  +# manually, since otherwise automatic git gc 
>  calls will
>  +# eventually warn about them (see bug 599008).
>  +subprocess.call(['git', 'prune'],
>  +
>  cwd=portage._unicode_encode(self.repo.location))
>  +
>   git_cmd_opts += " --depth %d" % 
>  self.repo.sync_depth
>   git_cmd = "%s fetch %s%s" % (self.bin_command,
>   remote_branch.partition('/')[0], 
>  git_cmd_opts)
> >>>
> >>> Does it have a performance impact?
> >>
> >> Yes, it takes about 20 seconds on my laptop. I suppose we could make
> >> this an optional thing, so that those people can do it manually if they
> >> want.  
> > 
> > So we have improvement from at most few seconds for normal 'git pull'
> > to around a minute for shallow pull?  
> 
> Well we've got a least 3 resources to consider:
> 
> 1) network bandwidth
> 2) disk usage
> 3) sync time
> 
> For me, sync time doesn't really matter that much, but I suppose it
> might for some people.

For a common user, network bandwidth is not a problem with git (except
maybe for the huge initial clone). Especially when syncing frequently,
the gain from subsequent --depth=1 is negligible. When syncing rarely,
you probably prefer snapshots anyway.

I doubt this could be of benefit even to dial-up users; that is,
that more time would be saved on fetching than lost on all the ops
needed to make things continue to work. The additional data won't
affect the data plan users much probably either.

Especially that Gentoo is all about fetching distfiles that are huge
compared to the git updates for the repository.

As for the disk usage, again, the difference should be negligible.
The major difference is done on initial fetch. Of course, regularly
pruning the repository will reduce its size. But then, pruning it will
non-shallow fetches would probably achieve a similar effect thanks to
delta compression.

That leaves the sync time. Which is becoming worse than rsync.

-- 
Best regards,
Michał Górny



pgpxVXUiCYwdc.pgp
Description: OpenPGP digital signature