Re: [gentoo-dev] [PATCH 02/13] python-utils-r1.eclass: Reorder implementations to semi-ascending order

[Patrice Clement]

Sunday 06 Dec 2015 20:03:21, Michał Górny wrote :
> Reorder the Python implementations to ascending version order, with
> CPython listed first and other implementations in descending preference.
> 
> The previous ordering has been used for two reasons:
> 
> 1. There were packages which supported Python 3.x or PyPy partially but
> their documentation builds or test functions required CPython 2.x.
> The specific ordering caused python_export_best (the predecessor of
> python_setup) to use CPython 2.x for those tasks. This is now replaced
> by explicit implementation restrictions in python_setup.
> 
> 2. PyPy setup runs were usually slower than CPython, and CPython 3.x
> runs were often slower due to 2to3 calls. Combined with parallel build
> runs, this ordering caused slower builds to start earlier and sometimes
> resulted in more efficient use of threads. However, nowadays we no
> longer do parallel builds.
> 
> Therefore, it seems reasonable to finally reorder the implementations
> into a more intuitive order.
> ---
>  eclass/python-utils-r1.eclass | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> index 0bce6a9..3ea23a8 100644
> --- a/eclass/python-utils-r1.eclass
> +++ b/eclass/python-utils-r1.eclass
> @@ -41,10 +41,10 @@ inherit toolchain-funcs
>  # @DESCRIPTION:
>  # All supported Python implementations, most preferred last.
>  declare -g -r _PYTHON_ALL_IMPLS=(
> - jython2_5 jython2_7
> - pypy pypy3
> - python3_3 python3_4 python3_5
>   python2_7
> + python3_3 python3_4 python3_5
> + pypy pypy3
> + jython2_5 jython2_7
>  )
>  
>  # @FUNCTION: _python_impl_supported
> -- 
> 2.6.3
> 
> 

Michal,

While at it, please delete jython2_5 from this list since jython versions < 2.7 
are in
the process of being purged from Portage. 

See https://bugs.gentoo.org/show_bug.cgi?id=552452

Cheers,

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

Re: [gentoo-dev] RFC: automatically mailing people on pkgcheck problems with their packages

[Michał Górny]

Dnia 6 grudnia 2015 18:49:12 CET, "Andreas K. Huettel"  
napisał(a):
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>Am Sonntag, 6. Dezember 2015, 17:49:00 schrieb Michał Górny:
>> On Sun, 6 Dec 2015 11:09:48 -0500
>> 
>> Michael Orlitzky  wrote:
>> > On 12/06/2015 11:00 AM, Michał Górny wrote:
>> > >> Of course. Add the commit author, too: I want to know if I break
>> > >> someone else's package.
>> > > 
>> > > So far, can't do that since we don't know which commit exactly
>broke. I
>> > > don't want to do any heuristics that could blame the wrong
>person.
>> > 
>> > Is the testing performed per-push rather than per-commit? Either
>way, I
>> > would like to get a notification that something broke, even if it
>wasn't
>> > my commit at fault. Just change the word "blame" to "alert" so no
>one
>> > feels slandered.
>> 
>> It is done every 20 minutes, and takes around 7-10 minutes.
>
>How about just adding everyone who pushed in that timeframe?

It just occurred to me that I can run checks just for the one failing package, 
which should have much decreased run time. I'm going to see if bisecting would 
work there.

>
>- -- 
>Andreas K. Huettel
>Gentoo Linux developer (council, perl, libreoffice)
>dilfri...@gentoo.org
>http://www.akhuettel.de/
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v2
>
>iQIcBAEBCgAGBQJWZHUYAAoJEHRrah2soMK+WwEQAM3kIuB898xKOXhYRkCWxZKP
>UeXyqHWfUOuSoFwmNKwfOiHV7bJfAOMgKI6dymqFRjOU32gOMe2hSeR4W5E7ytT3
>ykTjDO1zf+YmZ4Pn4xeXUa4f/SwqeD9exNl3O8+9wbMSd1CfQj1RL1YRQPjuDfsY
>zZFbk7WBrkHVlIyUpiwE/3/CF4fCzg2FIDQdQv78p8MvEAEUz2JFolyaCAJzroje
>TaAweY2oFC9e2aMfg2dtW2m85q/B1ZtYZzNVvCM+5iDRwbVZyNzttvb31GbQwRLO
>yz5SJQqTk0TpoFXomq7hK0xb/leRnbbwjOC02sebMxP6Dw3ya33zeXG64gzEkYUB
>7FrLo3U7jTWx+vepACJPOfULqtBP0u0YtFOzPdEHJbtv1qzGRXeSMctMvaS3XnBl
>NFceqTxt19qiRu3zN3cpjuf/C0FhthAplooQfRD8quy7KLgM8gO8fuX6g706qXUJ
>1QS2UXAyVVrHUDpU0fPM73Uts4RivaYyjSyiy1+neGPOVQ6TpkaSPgh2bjlsb7d8
>gmM5s8Y8RmXi8LOGEr1w8cuiCTaFVlRgNQB3WAYpLQ/m/kDNakIAFlX4KhVZdBYh
>n15BMUGJRfz1r/XYUXd89iwesjye0YGtww2TVWSpLkeZDInua+JhRy/30HaPuJ6O
>LHJon3GqAM8fmjcZOa7N
>=0QHR
>-END PGP SIGNATURE-

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[gentoo-dev] New license: CROSSOVER-3

[Richard Yao]

Earlier this year, I spoke with Codeweavers' CEO, Jeremy White, about
changing their license terms so that we could remove RESTRICT=fetch from
app-emulation/crossover-bin. Robin Johnson and I also discussed it then.

The main issue was the requirement that users delete the software after
the trial period and Jeremy agreed to make a change to the crossover
license when Crossover 15.0.0 was released. This just happened and the
change occurred as discussed.

I have attached the new license and its diff. There are only two changes:

1. They now claim to bundle copies of libxml2 and libxslt under
BSD-style licenses.
2. The section on deleting the software has been deleted as per our
discussion.

Does anyone have any objections to committing the new license?
--- /usr/portage/licenses/CROSSOVER-2   2015-08-09 16:34:52.0 -0400
+++ CROSSOVER-3 2015-12-08 12:15:42.749265174 -0500
@@ -52,6 +52,7 @@
   www.icculus.org.
 
   We also use or include static copies of the following projects:
+libxml2, libxslt- BSD-style
 xml-dom, xml-namespacesupport,  - Artistic or GPL license
 xml-regexp, xml-sax
 
@@ -119,10 +120,7 @@
 
   If the Software was given to you for purposes of evaluation, then this
   License will terminate at the end of the specified evaluation period,
-  typically 30 days.
-
-  Upon termination you must destroy the Software, related documentation and
-  all copies thereof.
+  typically 15 days.
 
5. Export Law Assurance. You agree and certify that neither the Software nor
   any other technical data received from VENDOR, nor the direct product
CrossOver Linux License Grant

YOU REALLY WANT TO READ THIS, ESPECIALLY THE PART ABOUT
THE MANDATORY CAR WASH FOR CODEWEAVERS EMPLOYEES...

If you don't like this license grant:

   a. Let us know, we'd appreciate the feedback.

   b. Stop right now, and ask for a refund. We'll cheerfully do so.


The main thing we want you to know:
 This is a license for one user. The license is not necessarily for a
specific user, or a specific computer, but it is for one person at a
time. If you need to support more than one person, please contact us
for volume pricing and site licensing.  We do offer educational
discounts.

< Start of Formal License Grant >---

   1. License. The software accompanying this License (hereinafter "Software"),
  regardless of the media on which it is distributed, are licensed to you
  by CodeWeavers ("VENDOR"). You own the medium on which the Software is
  recorded, but VENDOR and VENDOR's Licensors (referred to collectively as
  "VENDOR") retain title to the Software and related documentation. You
  may:

 a. run the Software on any computer, so long as no more than one
person per license is ever using the Software at any one time.

 b. transfer all your license rights in the Software, the backup copy
of the Software, the related documentation and a copy of this
License to another party, provided the other party reads and agrees
to accept the terms and conditions of this License.


   2. Free Software. The Software contained in this product includes some
  components of Free Software, including software from the Wine Project,
  and the MojoSetup setup software.

  The Wine project is licensed under terms of the GNU Lesser General Public
  License, which is included below as Appendix A. The best source for the
  Wine source code is the main Wine web page at http://www.winehq.org.

  Japanese fonts are included under the Wada Laboratory public domain
  license found at
  http://sourceforge.jp/projects/ume-font/wiki/UmeFontLicence

  MojoSetup and its dependent projects are all licensed under BSD
  style licenses.  The best place for that code is also
  www.icculus.org.

  We also use or include static copies of the following projects:
libxml2, libxslt- BSD-style
xml-dom, xml-namespacesupport,  - Artistic or GPL license
xml-regexp, xml-sax

  We also use the htmltextview.py library by Gustavor Carneiro, which
  is licensed under the LGPL.  The source code was available to us at:
http://people.gnome.org/~gjc/htmltextview.py

  Portions of this software are copyright © 2009. The FreeType
  Project (www.freetype.org).  All rights reserved.

  In each case, we use them unmodified and strongly recommend that
  anyone wishing source code for these projects find and visit the
  respective project home page.

  We are deeply grateful to the authors of all of these software projects
  for allowing us to use their software.

  We include source code with each CD purchase of CrossOver. Current
  source code for Free Software contained within CrossOver products is 

[gentoo-dev] Last-rites: app-arch/ppmd

[Michael Palimaka]

# Michael Palimaka 

Re: [gentoo-dev] RFC: automatically mailing people on pkgcheck problems with their packages

[Daniel Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/06/2015 06:36 AM, Michał Górny wrote:
> Hello,
> 
> As you have seen multiple times, I'm running a minimalistic CI
> service for Gentoo that checks the repository for major issues
> using pkgcheck. So far it's automation is limited to sending a mail
> to dedicated gentoo-automated-test...@lists.gentoo.org mailing list
> on breakage changes. From there, I compare the results to recent
> git log and mail the developers at fault, pointing out the bad
> commit.
> 
> A few developers have already subscribed to the mailing list to
> check if they haven't caused any new breakages and fix them
> quickly. For others, it's pretty much just me caring to check,
> which also means that when I'm not around things are left broken.
> 
> Automating the blaming process has been suggested multiple times 
> already but I so far considered it not worth the effort. Mostly
> because many of the issues are indirect, and trying to
> automatically figure them out from combination of the pkgcheck
> report and recent commits would be hard, and could cause false
> positives. For example, some of the depgraph breakages happen
> because of package.mask changes -- figuring that out automatically
> wouldn't be easy, and the script could blame an irrelevant commit
> in the package.
> 
> However, it was suggested recently that I could make it mail the
> maintainers of the affected packages. Even though most often it's 
> not them who are at fault, it was suggested that they'd prefer to
> know that their packages are broken.
> 
> So what do you think? Would it be fine to mail the package
> maintainers whenever their packages break? Would it be a problem if
> I just CC-ed all the maintainers on the gentoo-automated-testing
> mails? Please note that the breakages are catched per-package, and
> the script wouldn't be able to respect restrict="" or hand-written
> maintainer descriptions ;-).
> 

Sounds fine to me. It's annoying when I come across something that
breaks my deptree, and I don't want my packages to break things,
either. No complaints here, as long as it's clear what the screw-up is.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWZytdAAoJEAEkDpRQOeFwx10P/1/AaiYBvw67kiFCnQSQ/K89
aHdkwI9KCmVSriBv3lRUMYhR9u48NdwwNPj1X+qlYP9hkFLgE2YEnnDeeegr4EtS
YgqTDuxwrWFzPRX/s8n199drlt5Y71S7B3LBDnOWRZcVOQlqjoLqdPN/FLmfi/Gh
57jCBcCn1nUx9SchidDXLa3xW9Yy0D3UPavIYKknmakVtMTnSx0qfsq2pIc15dp8
k2/m40a2UEitdn8sJKVJpqILs5l/1hGPJhtDkcRtYaHnVq7hVb9ibV7jKC2F/sZh
TgdWhc4VmghpCCZ4ZCXESQa8C3ISCIHp6m1OU9OHYPYfLabQRdHmi9GIgdt0Jyex
UJQzIhEeEatjkYIUwdFJsPYVJ93dOI/Ekymt4UjZR9Ww+LX/HilrH4AXZTTJsX9e
C5bvTnFy0OmSP1/t0IRZ63DWgrphxTZuviP3l8g9fLBZOY9bebeqixtGFpnw9ua+
WYHavsm3ExknYEcSYJi6wLKqYnkM5mK3eK0z85mZ6ONcRsydvBo2lbhzrRpNG8xk
uGrTFHirRVMTmJNWCd0e9pJ26xD7OvKTWMIxp+R+J4xHNe9j20keVFtHevkDJBWG
Qj/lzmFANczg7gW+X0CLKdrlzSI+KB0HMOeJO4+FIn/vgJtUOucrndhEM+jtqL1O
iBRPvpMGZDKFtIjSUii2
=PbDc
-END PGP SIGNATURE-

[gentoo-dev] [PATCH] readme.gentoo.eclass EAPI 6 support

[Ulrich Mueller]

AFAICS there are no particular EAPI 6 features this eclass could make
use of, so we can simply add 6 to the case pattern.

Ulrich


--- a/eclass/readme.gentoo.eclass
+++ b/eclass/readme.gentoo.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2014 Gentoo Foundation
+# Copyright 1999-2015 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Id$
 
@@ -24,7 +24,7 @@ case "${EAPI:-0}" in
0|1|2|3)
die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
;;
-   4|5)
+   4|5|6)
# EAPI>=4 is required for REPLACING_VERSIONS preventing us
# from needing to export another pkg_preinst phase to save 
has_version
# result. Also relies on EAPI >=4 default src_install phase.


pgp4jA_zGQnXv.pgp
Description: PGP signature

[gentoo-portage-dev] [PATCH] depgraph._too_deep: fix logic when deep is True (bug 566024)

[Zac Medico]

Since commit cc8724b80ec7da713baed3d3a88c0bb99fc368b7, the _too_deep
method erroneously returned True when deep was True. When deep is True
and depth is an int, the method is intended to return False, therefore
fix it to do so. This fixes the dep.want_update assignment from commit
cc8724b80ec7 to behave correctly, which solves bug 566024 because it
corrects behavior of the _slot_operator_trigger_reinstalls method.

Fixes: cc8724b80ec7 ("depgraph._want_update_pkg: handle _UNREACHABLE_DEPTH (bug 
554928)")
X-Gentoo-Bug: 566024
X-Gentoo-Bug-url: https://bugs.gentoo.org/show_bug.cgi?id=566024
---
 pym/_emerge/depgraph.py | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
index fa83ae8..2169b00 100644
--- a/pym/_emerge/depgraph.py
+++ b/pym/_emerge/depgraph.py
@@ -5407,8 +5407,14 @@ class depgraph(object):
@return: True if the package is deeper than the max allowed 
depth
"""
deep = self._dynamic_config.myparams.get("deep", 0)
-   return depth is self._UNREACHABLE_DEPTH or (
-   isinstance(deep, int) and isinstance(depth, int) and 
depth > deep)
+   if depth is self._UNREACHABLE_DEPTH:
+   return True
+   elif deep is True:
+   return False
+   else:
+   # All non-integer cases are handled above,
+   # so both values must be int type.
+   return depth > deep
 
def _depth_increment(self, depth, n=1):
"""
-- 
2.4.10

Re: [gentoo-dev] [PATCH] readme.gentoo.eclass EAPI 6 support

[Michał Górny]

On Tue, 8 Dec 2015 23:53:26 +0100
Ulrich Mueller  wrote:

> AFAICS there are no particular EAPI 6 features this eclass could make
> use of, so we can simply add 6 to the case pattern.

We could use EAPI 6 as an opportunity to fix the API and stop overriding
src_install() randomly.

-- 
Best regards,
Michał Górny



pgpIP2mLbM7e8.pgp
Description: OpenPGP digital signature

[gentoo-dev] moving gcc-5.3 to unstable

[Mike Frysinger]

all the blocking issues raised have been addressed w/gcc-5.3,
so i'll be moving it into ~arch this weekend
-mike


signature.asc
Description: Digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/gegl/

[Michał Górny]

On Tue,  8 Dec 2015 21:54:44 + (UTC)
"Sebastian Pipping"  wrote:

> commit: a1ea06b430e14f68b5b7bf1947a681215157c034
> Author: Sebastian Pipping  gentoo  org>
> AuthorDate: Tue Dec  8 21:49:31 2015 +
> Commit: Sebastian Pipping  gentoo  org>
> CommitDate: Tue Dec  8 21:54:00 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a1ea06b4
> 
> media-libs/gegl: Fix ffmpeg/libav dependency (bug #567638)
> 
> Package-Manager: portage-2.2.26
> 
>  media-libs/gegl/gegl-0.3.4.ebuild | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/media-libs/gegl/gegl-0.3.4.ebuild 
> b/media-libs/gegl/gegl-0.3.4.ebuild
> index 764b6c9..c2b9409 100644
> --- a/media-libs/gegl/gegl-0.3.4.ebuild
> +++ b/media-libs/gegl/gegl-0.3.4.ebuild
> @@ -18,7 +18,7 @@ if [[ ${PV} == ** ]]; then
>   SRC_URI=""
>  else
>   SRC_URI="http://download.gimp.org/pub/${PN}/${PV:0:3}/${P}.tar.bz2;
> - KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~sparc ~x86 
> ~amd64-fbsd ~amd64-linux ~arm-linux ~x86-linux ~ppc-macos ~x64-macos 
> ~x86-macos ~x64-solaris ~x86-solaris"
> + KEYWORDS="~alpha ~amd64 ~arm ~hppa ~mips ~ppc ~ppc64 ~x86 ~amd64-fbsd 
> ~amd64-linux ~arm-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos 
> ~x64-solaris ~x86-solaris"

...which change is put silently under 'dependency fix' with no explicit
warning, and effectively breaks ~ia64 reverse dependencies:

https://qa-reports.gentoo.org/output/gentoo-ci/42f623e/output.html#media-gfx/gimp

-- 
Best regards,
Michał Górny



pgphiAi8PBHep.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-emulation/xen-tools/

[Michał Górny]

On Wed,  9 Dec 2015 05:31:28 + (UTC)
"Ian Delaney"  wrote:

> commit: cec1b419cc9c56d2573a858a6c6e727f97d924a4
> Author: Ian Delaney  gentoo  org>
> AuthorDate: Wed Dec  9 05:28:39 2015 +
> Commit: Ian Delaney  gentoo  org>
> CommitDate: Wed Dec  9 05:31:16 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cec1b419
> 
> clean vulnerable vns. wrt #566842 #566844
> 
> Package-Manager: portage-2.2.24
> 
>  app-emulation/xen-tools/Manifest  |   1 -
>  app-emulation/xen-tools/xen-tools-4.5.2-r1.ebuild | 466 
> --
>  app-emulation/xen-tools/xen-tools-4.6.0-r3.ebuild | 457 -
>  3 files changed, 924 deletions(-)

It's the third time you break a number of reverse dependencies by
fiddling around xen. This time you removed all the stable ebuilds,
effectively breaking stable amd64:

https://qa-reports.gentoo.org/output/gentoo-ci/fd9a751/output.html#app-emulation/ganeti
https://qa-reports.gentoo.org/output/gentoo-ci/fd9a751/output.html#app-emulation/libvirt
https://qa-reports.gentoo.org/output/gentoo-ci/fd9a751/output.html#app-emulation/xen-pvgrub
https://qa-reports.gentoo.org/output/gentoo-ci/fd9a751/output.html#sys-cluster/nova

-- 
Best regards,
Michał Górny



pgpfvgD1p_Qwb.pgp
Description: OpenPGP digital signature