[gentoo-dev] Re: [PATCH] flag-o-matic.eclass: bugfix for get-flag()

[Ryan Hill]

On Sun, 15 May 2016 21:35:41 +0200
rindeal  wrote:

> apart from the tests, the patch now looks like this:

Please posts the tests too.

-- 


pgpudg4Ys0VCN.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] ebuild-writing/variables: better describe ROOT

[Mike Gilbert]

On Sat, May 14, 2016 at 5:35 PM, Göktürk Yüksek  wrote:
> Mike Gilbert:
>> The current description of ROOT makes no sense and just confuses
>> people. The new description is paraphrased from PMS. ---
>> ebuild-writing/variables/text.xml | 5 +++-- 1 file changed, 3
>> insertions(+), 2 deletions(-)
>>
>> diff --git a/ebuild-writing/variables/text.xml
>> b/ebuild-writing/variables/text.xml index ef15347..6ba6379 100644
>> --- a/ebuild-writing/variables/text.xml +++
>> b/ebuild-writing/variables/text.xml @@ -100,8 +100,9 @@ them. 
>> ROOT  -  Path to the root directory. When
>> not using ${D}, -  always prepend ${ROOT} to the
>> path. +  The absolute path to the root directory into which the
>> package is to be merged. +  Use this when refering to installed
>> files in pkg_* functions. +  Never use this in
>> src_* functions.   
>>
>
> Sorry for the late reply. There is actually a bug for this issue [0].
> I'll rebase the patch attached to the bug on top of yours if you have
> no technical objections to the content.
>
> [0] https://bugs.gentoo.org/show_bug.cgi?id=144332

The expanded explanation seems useful indeed.

Re: [gentoo-dev] [PATCH v2 2/4] ebuild-writing/misc-files/metadata: rewrite the section per GLEP 67 #572144

[Göktürk Yüksek]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Michał Górny:
> On Sat, 14 May 2016 20:57:48 -0400 Göktürk Yüksek
>  wrote:
> 
>> @@ -244,12 +221,7 @@ optional: without this attribute must also
>> exist. That tag without the restrict attribute will serve as the
>> default. The format of the restrict attribute is that of the
>> DEPEND flag, except that "<" and -">" need to be
>> specified by < and >. - -For
>> example, in the sys-libs/db package, -
>> restrict=">=sys-libs/db-3.2.9-r5"  on the -
>> maintainer tag shows that I'm currently
>> maintaining all -versions greater then 3.2.9-r5. +">"
>> need to be specified by "<" and ">".   
>> 
> 
> I'm sorry for coming late to the party but could you mention that
> it must be an EAPI 0 package dependency? There were more than a
> few packages where people put slot- or USE-dependencies there.
> 

The purpose of this change was to remove the example inside the table
since I've added a complete example with restrict under the metadata
examples section.

PATCH 3/4 accomplishes what you ask:
+the restrict attribute serves as the default. The format of the
+restrict attribute is that of a EAPI=0 package dependency
+specification. Due to the limitations of XML, the "<" and

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJXOS8RAAoJEIT4AuXAiM4z21sH+wWVlhYAZpGTIaBJydWWnynI
zuF1CmHxb4dlLh9zbwMcMuRavbxYbKsI3P0D2p4h1kNI6a9jZzAAvHF99eTC6o54
+PjwgxroxtTHKrp147Jmubrj+u70EWvj2JGxIprRkS5A0ZW+zE24n37IA/8AtwEL
XV24dB1HSs98WkfJbnhYmS6nxyQHz0fiFRM4o1syxtHyu9bS1zXE+fEevqeTOo4i
PlqJCgyepvyPdcYeDHVOz7b9MqXy19+GTPFxHzfoHMBWB4/X/6umYE+1n9CRIjeX
THhiCZ/6uXVvXJgUcaoLlWE984wbgEzt9j4zp2CJqG0FgyndtCuW9QZrY8gWW4I=
=kmMC
-END PGP SIGNATURE-

[gentoo-dev] NEW: split portage/repoman releases now in the tree

[Brian Dolbec]

portage-2.3.0_rc1 and repoman-2.3.0_rc1 are now in the tree.

portage-2.3.0_rc1 is essentially the portage 2.2.28 release with only a
few small patches applied.  It mostly just installs less code, namely
the repoman code.

So, now servers and other systems that do not require repo Q/A ability
will no longer get repoman installed anyway.

repoman-2.3.0_rc1 is the stage2 rewrite code. The checks are now
modular, and using the portage plugin system. The system is not yet
fully plug and play. Those changes will take place in the stage3
re-writes.

The two packages will remain in the same portage git repo, although the
repoman code has been moved into it's own pkg directory.  It is too
tied into portage api's to be on it's own just yet.  An that
is not likely to happen until we get a stable portage API.  This new
system does allow for semi-independant releases for both repoman and
portage.  When important API's change, it will require both to be
release at the same time.  So you can look forward to seeing the minor
version number to get more frequent bumps than it has this last decade.

Currently, the portage ebuild does not RDEPEND on the repoman ebuild.
You will have to explicitly emerge it for it to be installed. It has
been suggested to add a use flag enabled RDEPEND (default on) for the
dev profile.  I will also be adding that to the portage- release
for all profiles in the coming days.

NOTES:  Repoman now depends on lxml for it's xml parsing and error
checking along with now using metadata.xsd.  It now will report a lot
more errors than the previous buggy code everyone has been using.

I want to thank the following people for their help and contributions
to make these releases:

Zac Medico 
Alexander Bernsten 
Dirkjan Ochtman  for the base xml re-write code
Michal Gorny  for the metadata.xsd changes
Göktürk Yüksek  for the metadata.xml test ebuilds
patches.
Mike Gilbert  for all the testing on the rewite code,
and a number of gen-b0rk repo test ebuilds.

Coacher for the recent testing, bug reports and patches.
And anyone else I missed ;)

So, please report any issues with either the ebuilds or installs, bugs,
etc... you know the drill ;)

Don't forget, please contribute more test case ebuilds to the gen-b0rk
repo.  The better the test ebuild coverage we have, the better our Q/A
tools (like repoman) will be and the less often things will be released
broken.

Thank you
-- 
Brian Dolbec 

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 15/05/16 23:55, Duncan wrote:
> Daniel Campbell posted on Sun, 15 May 2016 04:04:57 -0700 as excerpted:
>
>> If the dev in question hasn't done that before, then it's entirely
>> possible they *thought* they tested, or tested it *before* making some
>> other edit and absent-mindedly committed.
> Again, legacy CVS thought pattern.  In git, commit != push, and it's the 
> push that's critical.
>
> Commit all you want without testing.  Just test (and fix if necessary) 
> before you push those commits up to the gentoo master repo. =:^)
>
> (Of course, rebasing to fold the broken commit and its fix into one 
> before pushing doesn't hurt, either.)
>
Surely it should be possible to fire some QA scripts on pre-commit on
the central gentoo repos (ie. at the push target end)?!
Or am I being a bit optimistic ..



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-05-15 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-05-15 23:59 UTC.

Removals:
dev-python/pysfml20160509-00:14 mr_bones_  b1c9622
media-libs/csfml 20160509-00:13 mr_bones_  27a2254
media-libs/libmnote  20160511-10:01 kensington 826a634

Additions:
app-backup/untangle-https-backup 20160515-19:39 mjod0efbfc
app-emacs/go-mode20160508-09:06 idella494ea431
app-i18n/skktools20160513-12:42 hattya 7bbe4ab
app-i18n/yaskkserv   20160513-13:22 hattya c1008b2
app-vim/ackvim   20160512-13:07 monsieurp  8c61c07
app-vim/pydiction20160512-12:59 monsieurp  f25308c
app-vim/rainbow_parentheses  20160512-10:00 monsieurp  44f2c0f
dev-haskell/colour   20160510-21:25 slyfox ef7f313
dev-haskell/crypto-api-tests 20160510-21:12 slyfox acfd6ee
dev-haskell/fgl-arbitrary20160510-21:35 slyfox eb73057
dev-haskell/graphviz 20160510-21:35 slyfox cbde8a2
dev-haskell/pretty-hex   20160510-21:06 slyfox 2c04e44
dev-haskell/raw-strings-qq   20160510-21:41 slyfox f8b1f48
dev-haskell/wl-pprint-text   20160510-21:25 slyfox 1e4d07f
dev-libs/sway20160512-05:36 idella4505d988
dev-libs/wlc 20160511-14:31 idella42d0c342
dev-python/paho-mqtt 20160512-11:47 wraeth 27352e6
dev-python/rebulk20160511-04:51 idella4e6cc592
dev-python/rfc3987   20160513-14:17 aballier   09721f2
dev-python/uvloop20160511-17:06 idella4e517b3c
dev-ros/gennodejs20160511-08:12 aballier   522d239
dev-ros/tf2_eigen20160512-10:49 aballier   e6037d3
dev-util/artifactory-bin 20160511-23:07 wizardedit 2896d62
dev-util/gertty  20160509-15:51 prometheanfire d70b026
kde-frameworks/kwayland  20160515-16:46 johu   4d49ff8

--
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:
media-libs/libmnote,removed,kensington,20160511-10:01,826a634
dev-python/pysfml,removed,mr_bones_,20160509-00:14,b1c9622
media-libs/csfml,removed,mr_bones_,20160509-00:13,27a2254
Added Packages:
app-backup/untangle-https-backup,added,mjo,20160515-19:39,d0efbfc
kde-frameworks/kwayland,added,johu,20160515-16:46,4d49ff8
dev-python/uvloop,added,idella4,20160511-17:06,e517b3c
dev-python/rfc3987,added,aballier,20160513-14:17,09721f2
app-i18n/yaskkserv,added,hattya,20160513-13:22,c1008b2
app-i18n/skktools,added,hattya,20160513-12:42,7bbe4ab
dev-libs/sway,added,idella4,20160512-05:36,505d988
app-emacs/go-mode,added,idella4,20160508-09:06,94ea431
app-vim/ackvim,added,monsieurp,20160512-13:07,8c61c07
app-vim/pydiction,added,monsieurp,20160512-12:59,f25308c
dev-python/paho-mqtt,added,wraeth,20160512-11:47,27352e6
dev-python/rebulk,added,idella4,20160511-04:51,e6cc592
dev-ros/tf2_eigen,added,aballier,20160512-10:49,e6037d3
app-vim/rainbow_parentheses,added,monsieurp,20160512-10:00,44f2c0f
dev-libs/wlc,added,idella4,20160511-14:31,2d0c342
dev-util/artifactory-bin,added,wizardedit,20160511-23:07,2896d62
dev-haskell/raw-strings-qq,added,slyfox,20160510-21:41,f8b1f48
dev-haskell/graphviz,added,slyfox,20160510-21:35,cbde8a2
dev-haskell/fgl-arbitrary,added,slyfox,20160510-21:35,eb73057
dev-haskell/wl-pprint-text,added,slyfox,20160510-21:25,1e4d07f
dev-haskell/colour,added,slyfox,20160510-21:25,ef7f313
dev-haskell/crypto-api-tests,added,slyfox,20160510-21:12,acfd6ee
dev-haskell/pretty-hex,added,slyfox,20160510-21:06,2c04e44
dev-ros/gennodejs,added,aballier,20160511-08:12,522d239
dev-util/gertty,added,prometheanfire,20160509-15:51,d70b026

Done.

Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: bugfix for get-flag()

[Ulrich Mueller]

> On Sun, 15 May 2016, rindeal  wrote:

[Looks like your mailer is broken. All the tabs in your patch have
been mangled and appear as spaces.]

> +   # reverse loop
> +   set -- ${!var}
> +   local i=${#}
> +   while [[ ${i} > 0 ]] ; do
> +   local arg="${!i}"

Using the positional parameters looks needlessly complicated here.
Why not use an array, like this (untested):

local -a flags=(${!var})
for (( i=${#flags[@]}-1; i>=0; i-- )); do

Below you can use ${flags[i]} instead of ${arg} then.

Ulrich


pgpANfbJC5E4o.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Rich Freeman]

On Sun, May 15, 2016 at 6:46 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> Committing without testing, as long as you don't push, is fine, even
> meritorious.  It's the push that uploads those commits to the gentoo
> reference repo, however, and testing should *definitely* be done before
> pushing, with more commits /before/ the push to fix what the tests found
> to be broken, should they be necessary.
>

Of course.  In fact, this is often the type of workflow you'd tend to
employ in a CI setup.  I believe that pull requests submitted on
github get automatically tinderboxed, though I have no idea whether
that provides any benefits to something like an eclass (if the CI
script just tests the ebuilds being modified it obviously would not).
Maybe in a perfect world we'd actually have a CI testing package
category with dummy packages that do nothing but run tests to cover
this sort of thing.

Even so, I would imagine that in most organizations CI is intended
more as a sanity check than a substitute for testing your own work.
Certainly where I work the expectation is that somebody would have at
least compiled and run something before putting it into some kind of
QA workflow, even with CI.

-- 
Rich

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Daniel Campbell]

On 05/15/2016 03:55 PM, Duncan wrote:
> Daniel Campbell posted on Sun, 15 May 2016 04:04:57 -0700 as excerpted:
> 
>> If the dev in question hasn't done that before, then it's entirely
>> possible they *thought* they tested, or tested it *before* making some
>> other edit and absent-mindedly committed.
> 
> Again, legacy CVS thought pattern.  In git, commit != push, and it's the 
> push that's critical.
> 
> Commit all you want without testing.  Just test (and fix if necessary) 
> before you push those commits up to the gentoo master repo. =:^)
> 
> (Of course, rebasing to fold the broken commit and its fix into one 
> before pushing doesn't hurt, either.)
> 
Sorry. I've actually been using git for years, but since I got started
with Gentoo on CVS and I try to be careful with my commits to the gentoo
repo, I conflated them. You're right, the push is what matters the most.

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



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Duncan]

Daniel Campbell posted on Sun, 15 May 2016 04:04:57 -0700 as excerpted:

> If the dev in question hasn't done that before, then it's entirely
> possible they *thought* they tested, or tested it *before* making some
> other edit and absent-mindedly committed.

Again, legacy CVS thought pattern.  In git, commit != push, and it's the 
push that's critical.

Commit all you want without testing.  Just test (and fix if necessary) 
before you push those commits up to the gentoo master repo. =:^)

(Of course, rebasing to fold the broken commit and its fix into one 
before pushing doesn't hurt, either.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Duncan]

Daniel Campbell posted on Sun, 15 May 2016 04:16:30 -0700 as excerpted:

> On 05/15/2016 03:29 AM, Michał Górny wrote:

>> However, is it that much of
>> an effort to test eclass changes using ebuilds *before* committing it?
>> It wasn't that hard even in times of CVS (esp. that we're talking about
>> separate directories), and it is even easier in times of git.
>> 
> One can't coddle someone who's breaking the tree, especially
> when we expect people to test before committing.

Orthogonal to the general discussion, but could be critical for some...

Both the above comments reflect legacy CVS thought patterns in regard to 
commits.  In git, commit != push , and here it's the push, not the 
commit, that's critical and that testing needs done before.

Committing without testing, as long as you don't push, is fine, even 
meritorious.  It's the push that uploads those commits to the gentoo 
reference repo, however, and testing should *definitely* be done before 
pushing, with more commits /before/ the push to fix what the tests found 
to be broken, should they be necessary.

(Tho in keeping with the principle of ultimately atomic commits that 
don't break bisections, if a commit is found to be broken and is then 
fixed by another commit, a rebase to combine the two into one should be 
considered, thus avoiding breakage of bisections ending up with a commit 
between the break and its fix.  Not that bisection is particularly 
practical in the gentoo repo context anyway, but that's a separate 
discussion, and good habits here will carry over to repos where bisection 
is actually practical and critically important.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: bugfix for get-flag()

[rindeal]

> On Sun, 15 May 2016 21:35:41 +0200
> rindeal  wrote:
>
>> > Dnia 15 maja 2016 15:31:29 CEST, Jan Chren  
>> > napisał(a):
>> >>+  local f="${!i}"
>> >>+  if [ "${f#-${findflag#-}}" != "${f}" ] ; then
>> >
>> > I know the original code sucked as well but could you replace this with 
>> > more readable [[ ${f} == -${findflag#-}* ]] or alike (note: not tested).
>>
>> This is just as buggy as my original implementation, I've reworked it
>> and thanks to the tests I hope it's now correct.
>
> It is still unreadable. The point is, we use bash here, so please use
> bash features (i.e. == with wildcards) to do comparison rather than
> limited shell-style stripping of variables.

The thing is that "== with wildcards" cannot be used, because a) it's
too greedy and b) the wildcards in ${pattern} won't expand.

>
>> >>+  printf "%s\n" "${f#-${findflag}=}"
>> >
>> > It may be a good idea to add a short explanation why you can't use echo 
>> > here, as a comment.
>>
>> I've just copied what was there before, `echo` in bash is notoriously
>> wild, but with this simple string I guess it's ok, so done.
>
> I meant you should add a comment that you can't use echo because flags
> like '-n' or '-e' would confuse it :-P.

Ok, I've fixed it and added tests for such edge cases.

Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: bugfix for get-flag()

[Michał Górny]

On Sun, 15 May 2016 21:35:41 +0200
rindeal  wrote:

> > Dnia 15 maja 2016 15:31:29 CEST, Jan Chren  
> > napisał(a):  
> >>+  local f="${!i}"
> >>+  if [ "${f#-${findflag#-}}" != "${f}" ] ; then  
> >
> > I know the original code sucked as well but could you replace this with 
> > more readable [[ ${f} == -${findflag#-}* ]] or alike (note: not tested).  
> 
> This is just as buggy as my original implementation, I've reworked it
> and thanks to the tests I hope it's now correct.

It is still unreadable. The point is, we use bash here, so please use
bash features (i.e. == with wildcards) to do comparison rather than
limited shell-style stripping of variables.

> >>+  printf "%s\n" "${f#-${findflag}=}"  
> >
> > It may be a good idea to add a short explanation why you can't use echo 
> > here, as a comment.  
> 
> I've just copied what was there before, `echo` in bash is notoriously
> wild, but with this simple string I guess it's ok, so done.

I meant you should add a comment that you can't use echo because flags
like '-n' or '-e' would confuse it :-P.

-- 
Best regards,
Michał Górny



pgplBHfgT7mV0.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: bugfix for get-flag()

[rindeal]

> Dnia 15 maja 2016 15:31:29 CEST, Jan Chren  napisał(a):
>>- fix case:
>>  - `CFLAGS='-O1 -O2'`
>>  - `get-flag '-O*'`
>>  - before `-O1`
>>  - now `-O2`
>>- fix case:
>>  - `CFLAGS='-W1,-O1'`
>>  - `get-flag '-O*'`
>>  - before `-W1,O1`
>>  - now return 1
>>
>>`get-flag march` == "i686" syntax still works.
>
> Could you add appropriate test cases, in the tests subdirectory?

Done

>
>>---
>> eclass/flag-o-matic.eclass | 13 +
>> 1 file changed, 9 insertions(+), 4 deletions(-)
>>
>>diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
>>index e0b19e9..f670320 100644
>>--- a/eclass/flag-o-matic.eclass
>>+++ b/eclass/flag-o-matic.eclass
>>@@ -535,7 +535,7 @@ strip-unsupported-flags() {
>> # @DESCRIPTION:
>> # Find and echo the value for a particular flag.  Accepts shell globs.
>> get-flag() {
>>-  local f var findflag="$1"
>>+  local var findflag="${1}"
>>
>>   # this code looks a little flaky but seems to work for
>>   # everything we want ...
>>@@ -543,11 +543,16 @@ get-flag() {
>>   # `get-flag -march` == "-march=i686"
>>   # `get-flag march` == "i686"
>>   for var in $(all-flag-vars) ; do
>>-  for f in ${!var} ; do
>>-  if [ "${f/${findflag}}" != "${f}" ] ; then
>>-  printf "%s\n" "${f/-${findflag}=}"
>>+  # reverse loop
>>+  set -- ${!var}
>>+  local i=$#
>
> You are using $ with and without braces inconsistently. Please stick to one 
> form.

Done

>
>>+  while [ $i -gt 0 ] ; do
>
> Please use [[ ]] for conditionals. It has some nice bash magic that makes 
> them whitespace-safe.

Although always a number, but done

>
>>+  local f="${!i}"
>>+  if [ "${f#-${findflag#-}}" != "${f}" ] ; then
>
> I know the original code sucked as well but could you replace this with more 
> readable [[ ${f} == -${findflag#-}* ]] or alike (note: not tested).

This is just as buggy as my original implementation, I've reworked it
and thanks to the tests I hope it's now correct.

>
>>+  printf "%s\n" "${f#-${findflag}=}"
>
> It may be a good idea to add a short explanation why you can't use echo here, 
> as a comment.

I've just copied what was there before, `echo` in bash is notoriously
wild, but with this simple string I guess it's ok, so done.

>
>>   return 0
>>   fi
>>+  ((i--))
>>   done
>>   done
>>   return 1
>
>

apart from the tests, the patch now looks like this:

 eclass/flag-o-matic.eclass | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
index e0b19e9..a8a792e 100644
--- a/eclass/flag-o-matic.eclass
+++ b/eclass/flag-o-matic.eclass
@@ -535,7 +535,7 @@ strip-unsupported-flags() {
 # @DESCRIPTION:
 # Find and echo the value for a particular flag.  Accepts shell globs.
 get-flag() {
-   local f var findflag="$1"
+   local var pattern="${1}"

# this code looks a little flaky but seems to work for
# everything we want ...
@@ -543,11 +543,21 @@ get-flag() {
# `get-flag -march` == "-march=i686"
# `get-flag march` == "i686"
for var in $(all-flag-vars) ; do
-   for f in ${!var} ; do
-   if [ "${f/${findflag}}" != "${f}" ] ; then
-   printf "%s\n" "${f/-${findflag}=}"
+   # reverse loop
+   set -- ${!var}
+   local i=${#}
+   while [[ ${i} > 0 ]] ; do
+   local arg="${!i}"
+   local needle="-${pattern#-}" # force dash on
+   local haystack="${arg%%=*}" # we're comparing flags, not values
+   if [[ ${haystack##${needle}} == '' ]] ; then
+   local ret
+   # preserve only value if only flag name was provided
+   ret="${arg#-${pattern}=}"
+   echo "${ret}"
return 0
fi
+   ((i--))
done
done
return 1
--
2.7.3

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Sonntag, 15. Mai 2016, 11:53:27 schrieb Ryan Hill:
> 
> I thought his response was pretty tame actually.  If you break the tree
> because you couldn't be bothered to do the barest minimum of testing you
> absolutely deserve to be called out on it.
> 

+1

- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1

iQJ8BAEBCgBmBQJXOMNKXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDMjhGQ0IwRjdCRUQxMzdBQUNCMDJEODlB
NDRDRjM3M0U3RUU5OUU0AAoJEKRM83Pn7pnk+j8P/0EpX59Qy0s6K9kuSvZTkzki
w/P3jDKqfcFSkyZQFBHRXGKkyME/9uvCDxjvUzNlSGaw5Ukvl1CWzFN5Z1sxzLVU
wcu5nMaumt26egFmTliGwIWLXT7dbaqIyprCUPCF2HMbvsSBWKJ0Us+36Saz0NA3
G69ZBuO7Ig8t+yS5pcXkUUy6yqbDL2zaStIDxM5V5N0joVwetKt6CIXWiBMprRGP
L64VPi3FkVuuf4a04HMLzBl27kNRPiCvNMPZlf8Sp5b0ve4C6MapUvJ5BHSX64Hy
CtXEMPHrLtfFPE7fAW7EQlXKSRbpgkw3SIRI+TgpeMbwLaYkPkqf3NH5J3z1Gph+
CIhceVFq5gXexsbo4O3+deRXXSYraEZhZfYJKrXpiwEVVBTEpdtPrugOQoPMRo4H
pAlG8dQA456IqXGS4nur4sRljQg8rhfPnx5/vD6AnD+9gCM0qF9V/GinIBDvXOZd
QPzcaJn14MBS7xvN/jcy3Lf/ZJvjUMqb4MGKvCxvhNUFDIXHWRvqv5br3eMw6JSB
78wmN4kTcfFeQ9ywCChSKZDRZTziLVWifAORSJduGuyP/NthzPFMT3OrYS1Mze8v
JIHB+9HsmCG5RwXuP/DMAb0t0dg6Lbg8qKBtRvsO72/bsVfU50AtDDFXGowaK386
A24gQh9cIvtqRo8lU+nY
=vysH
-END PGP SIGNATURE-

[gentoo-dev] Re: [PATCH] distutils-r1.eclass: Do not apply patches if DISTUTILS_OPTIONAL is used

[Mike Gilbert]

On Sun, May 15, 2016 at 5:30 AM, Michał Górny  wrote:
> Do not apply PATCHES and user patches (either via the EAPI 6 default or
> pre-EAPI 5 code) when DISTUTILS_OPTIONAL is being used. In this case,
> distutils functions are usually called conditionally, in a subdirectory,
> while both PATCHES and user patches are usually intended to be applied
> top-level.
>
> There is no ebuild relying on distutils-r1_src_prepare applying patches
> with DISTUTILS_OPTIONAL. In fact, there are ebuilds which work around
> this behavior.

Sounds ok.

Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: bugfix for get-flag()

[Michał Górny]

Dnia 15 maja 2016 15:31:29 CEST, Jan Chren  napisał(a):
>- fix case:
>  - `CFLAGS='-O1 -O2'`
>  - `get-flag '-O*'`
>  - before `-O1`
>  - now `-O2`
>- fix case:
>  - `CFLAGS='-W1,-O1'`
>  - `get-flag '-O*'`
>  - before `-W1,O1`
>  - now return 1
>
>`get-flag march` == "i686" syntax still works.

Could you add appropriate test cases, in the tests subdirectory?

>---
> eclass/flag-o-matic.eclass | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
>diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
>index e0b19e9..f670320 100644
>--- a/eclass/flag-o-matic.eclass
>+++ b/eclass/flag-o-matic.eclass
>@@ -535,7 +535,7 @@ strip-unsupported-flags() {
> # @DESCRIPTION:
> # Find and echo the value for a particular flag.  Accepts shell globs.
> get-flag() {
>-  local f var findflag="$1"
>+  local var findflag="${1}"
> 
>   # this code looks a little flaky but seems to work for
>   # everything we want ...
>@@ -543,11 +543,16 @@ get-flag() {
>   # `get-flag -march` == "-march=i686"
>   # `get-flag march` == "i686"
>   for var in $(all-flag-vars) ; do
>-  for f in ${!var} ; do
>-  if [ "${f/${findflag}}" != "${f}" ] ; then
>-  printf "%s\n" "${f/-${findflag}=}"
>+  # reverse loop
>+  set -- ${!var}
>+  local i=$#

You are using $ with and without braces inconsistently. Please stick to one 
form.

>+  while [ $i -gt 0 ] ; do

Please use [[ ]] for conditionals. It has some nice bash magic that makes them 
whitespace-safe.

>+  local f="${!i}"
>+  if [ "${f#-${findflag#-}}" != "${f}" ] ; then

I know the original code sucked as well but could you replace this with more 
readable [[ ${f} == -${findflag#-}* ]] or alike (note: not tested).

>+  printf "%s\n" "${f#-${findflag}=}"

It may be a good idea to add a short explanation why you can't use echo here, 
as a comment.

>   return 0
>   fi
>+  ((i--))
>   done
>   done
>   return 1


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

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Brian Dolbec]

On Sun, 15 May 2016 04:18:39 -0700
Daniel Campbell  wrote:

> On 05/15/2016 02:15 AM, Brian Dolbec wrote:
> > On Sun, 15 May 2016 11:05:21 +0200
> > Jeroen Roovers  wrote:
> >   
> >> On Sat, 7 May 2016 23:25:58 +0200
> >> Michał Górny  wrote:
> >>  
> >>> Do you seriously expect this code to work? How about testing? Or
> >>> reading diffs before committing?
> >>
> >>
> >> Somebody could have a go at implementing this:
> >>
> >> https://bugs.gentoo.org/show_bug.cgi?id=390651
> >>
> >> It's been brewing for half a decade. Maybe it's time. :)
> >>
> >>
> >> Regards,
> >>  jer
> >>  
> > 
> > With the new repoman code structure, yes, it would be a lot easier
> > to implement.
> > 
> > Also with the gen-b0rk test repo, that will be a good testing ground
> > for eclass changes too.  It just needs more devs to make test
> > ebuilds to get it fully populated ;)
> >   
> What sort of test ebuilds are you looking for? There are a few
> packages I'd like to see get into Gentoo but I don't want to break
> anything. :P
> 

Have a look at the gen-b0rk repo, See how the ebuilds are done, follow
those examples.  There are lots more errors that repoman looks for that
are not yet covered by test ebuilds.

There are a few more in other areas of code, but here is the biggest
list of errors/warnings that repoman can test for.

https://gitweb.gentoo.org/proj/portage.git/tree/repoman/pym/repoman/qa_data.py?h=repoman

-- 
Brian Dolbec 



pgpRMqKiMf0hB.pgp
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] flag-o-matic.eclass: bugfix for get-flag()

[Jan Chren]

- fix case:
  - `CFLAGS='-O1 -O2'`
  - `get-flag '-O*'`
  - before `-O1`
  - now `-O2`
- fix case:
  - `CFLAGS='-W1,-O1'`
  - `get-flag '-O*'`
  - before `-W1,O1`
  - now return 1

`get-flag march` == "i686" syntax still works.
---
 eclass/flag-o-matic.eclass | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
index e0b19e9..f670320 100644
--- a/eclass/flag-o-matic.eclass
+++ b/eclass/flag-o-matic.eclass
@@ -535,7 +535,7 @@ strip-unsupported-flags() {
 # @DESCRIPTION:
 # Find and echo the value for a particular flag.  Accepts shell globs.
 get-flag() {
-   local f var findflag="$1"
+   local var findflag="${1}"
 
# this code looks a little flaky but seems to work for
# everything we want ...
@@ -543,11 +543,16 @@ get-flag() {
# `get-flag -march` == "-march=i686"
# `get-flag march` == "i686"
for var in $(all-flag-vars) ; do
-   for f in ${!var} ; do
-   if [ "${f/${findflag}}" != "${f}" ] ; then
-   printf "%s\n" "${f/-${findflag}=}"
+   # reverse loop
+   set -- ${!var}
+   local i=$#
+   while [ $i -gt 0 ] ; do
+   local f="${!i}"
+   if [ "${f#-${findflag#-}}" != "${f}" ] ; then
+   printf "%s\n" "${f#-${findflag}=}"
return 0
fi
+   ((i--))
done
done
return 1
-- 
2.7.3

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Daniel Campbell]

On 05/15/2016 02:15 AM, Brian Dolbec wrote:
> On Sun, 15 May 2016 11:05:21 +0200
> Jeroen Roovers  wrote:
> 
>> On Sat, 7 May 2016 23:25:58 +0200
>> Michał Górny  wrote:
>>
>>> Do you seriously expect this code to work? How about testing? Or
>>> reading diffs before committing?  
>>
>>
>> Somebody could have a go at implementing this:
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=390651
>>
>> It's been brewing for half a decade. Maybe it's time. :)
>>
>>
>> Regards,
>>  jer
>>
> 
> With the new repoman code structure, yes, it would be a lot easier to
> implement.
> 
> Also with the gen-b0rk test repo, that will be a good testing ground
> for eclass changes too.  It just needs more devs to make test ebuilds
> to get it fully populated ;)
> 
What sort of test ebuilds are you looking for? There are a few packages
I'd like to see get into Gentoo but I don't want to break anything. :P

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



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Daniel Campbell]

On 05/15/2016 03:29 AM, Michał Górny wrote:
> On Sun, 15 May 2016 08:40:39 +0900
> Aaron Bauman  wrote:
> 
>> On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote:
>>> On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman  wrote:  
 On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:  
> On Sat, 7 May 2016 23:25:58 +0200
>
> Michał Górny  wrote:  
>> Do you seriously expect this code to work? How about testing? Or
>> reading diffs before committing?  

 Absolutely nothing wrong was said here.  Obviously the code was not tested
 and Michal pointed that out very plainly.  
>>>
>>> It is actually possible to communicate both plainly and politely at
>>> the same time.  This does not require sacrificing any commitment to
>>> quality at all.  Really the only downside is having more of an
>>> appearance of professionalism.  
>>
>> Please enlighten me as to what was impolite here?  The strong language of 
>> "seriously" or definitively stating that the individual did not perform the 
>> necessary QA actions before committing?  Both of which are completely called 
>> for and appropriate.  No vulgarity, insults, or demeaning words were used.  
>> How would you have responded professionally?
> 
> Since the anti-productivity of this thread is getting impressively high
> even for Gentoo standards, I'd like to point out a few things.
> 
> It was impolite. It was supposed to be. Not offensive but impolite. It
> ain't cool to get responses like this but it ain't cool to break stuff
> like this either.
> 
> For those who don't have a broader view, it wasn't a single commit but
> a followup to a commit adding EAPI=6 support to the eclass -- clearly
> untested. I didn't bother complaining about the first one since issues
> would clearly pop up if someone actually tried to use the eclass
> in EAPI=6. However, the second commit actually introduced a syntax
> error that broke all the ebuilds, including stable and caused metadata
> generation failure. This is real bad.
> 
> Of course, it could have been worse. It looks like no ebuilds with
> EAPI=6 'support' were committed following the eclass. Which is a good
> sign that some testing eventually occurred. However, is it that much of
> an effort to test eclass changes using ebuilds *before* committing it?
> It wasn't that hard even in times of CVS (esp. that we're talking about
> separate directories), and it is even easier in times of git.
> 
> I don't really see the benefit of whole of this discussion. He
> committed a bad thing, I shouted at him, end of story. If you want to
> take it to comrel, just do it. However, discussing whether it was right
> or wrong is really unproductive here.
> 
I felt it was a bit strong, but you make a good case. There certainly is
a balance. One can't coddle someone who's breaking the tree, especially
when we expect people to test before committing. Since it was an eclass,
wasn't that supposed to be discussed on here first, too? Still, we're
going to make mistakes and dressing someone down won't fix it.

When I was adding multilib support to media-sound/apulse I recall you
strongly telling me that I screwed up and it shouldn't have been done
the way I originally committed. There wasn't a nudge in the right
direction, though. I imagine it was clear that I hadn't done multilib
scripts before. If I had been more sensitive or less willing to fix it,
what would have happened? You or someone else may have reverted it
and/or reported to QA and started a ruckus.

I mean, I don't hold a grudge or anything. I'm glad you told me it
wasn't right, because if I'm contributing to Gentoo I want it to be done
well. I learned something from it. But a dev being told that they're
screwing up without also being specific (or at least a hint) about a way
to fix it or *why* it's wrong doesn't help them fix their screw up and
ensure it doesn't happen again.

That sort of criticism, which may be warranted in terms of "they screwed
the tree up due to something stupid!", isn't productive if the dev
doesn't know how to fix it.

This particular screw-up is different since it was simpler, but less
trivial screw ups do happen and without _constructive_ criticism, devs
(and Gentoo, by extension) won't get better.

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



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Daniel Campbell]

On 05/15/2016 02:53 AM, Ryan Hill wrote:
> On Sun, 15 May 2016 08:40:39 +0900
> Aaron Bauman  wrote:
> 
>> On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote:
>>> On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman  wrote:  
 On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:  
> On Sat, 7 May 2016 23:25:58 +0200
>
> Michał Górny  wrote:  
>> Do you seriously expect this code to work? How about testing? Or
>> reading diffs before committing?  

 Absolutely nothing wrong was said here.  Obviously the code was not tested
 and Michal pointed that out very plainly.  
>>>
>>> It is actually possible to communicate both plainly and politely at
>>> the same time.  This does not require sacrificing any commitment to
>>> quality at all.  Really the only downside is having more of an
>>> appearance of professionalism.  
>>
>> Please enlighten me as to what was impolite here?  The strong language of 
>> "seriously" or definitively stating that the individual did not perform the 
>> necessary QA actions before committing?  Both of which are completely called 
>> for and appropriate.  No vulgarity, insults, or demeaning words were used.  
>> How would you have responded professionally?
> 
> I thought his response was pretty tame actually.  If you break the tree
> because you couldn't be bothered to do the barest minimum of testing you
> absolutely deserve to be called out on it.
> 
> But if you guys just want to hug it out that's cool too.
> 
I think that depends on history. If the dev in question hasn't done that
before, then it's entirely possible they *thought* they tested, or
tested it *before* making some other edit and absent-mindedly committed.
That's a screw-up, and devs should be notified. Ideally, they should be
told *what* they screwed up and *how* to ensure it doesn't happen again.

Admonishing them as if they were a child is not going to engender
motivation to continue participation. We're all devs because we want to
make Gentoo better (I hope, anyway), and part of that means we'll have
to help each other out sometimes.

There's more to it than coddling vs tearing someone down.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Daniel Campbell]

On 05/14/2016 01:23 PM, Rich Freeman wrote:
> On Sat, May 14, 2016 at 3:21 PM, M. J. Everitt  wrote:
>> On 14/05/16 18:52, Rich Freeman wrote:
>>> On Sat, May 14, 2016 at 1:07 PM, landis blackwell
>>>  wrote:
 No fun allowed

>>> Are you saying that you don't want people to have fun developing
>>> Gentoo?  Or are you trying to say that it is impossible to have fun
>>> developing Gentoo without insulting strangers?  I don't think anybody
>>> minds two friends teasing each other.
>>>
>> I think my gut feeling would go "there's a time and a place..." .. and
>> err on the g-dev ML probably not being it .. unless everyone else is in
>> on the 'joke' ..
>>
> 
> Sure, and just to be clear I don't think we should be bothered by
> informality and joking around.  If you have a good relationship with
> somebody and poking at each other is just how you relate, you can get
> away with it.  We shouldn't have to walk on eggshells, but it just
> seems like we get a lot of flames in general going around and IMO at
> least it seems like it makes the distro a bit less fun.
> 
> Of course we shouldn't lower our standards for quality, and I suspect
> that most of the people who do commit mistakes to the tree would
> probably agree, at least when they're sober.  :)
> 

I agree. Some of us have reputations for being hard to work with or
being misunderstood, and it would go a long way for us to try to be
honest and -- for lack of a better word -- nicer. I've not personally
experienced much of that, but I can understand why someone wouldn't want
to work with (on a volunteer basis, of course) someone calling them
stupid or incompetent.

Mistakes happen and I gladly fix anything I've screwed up. I could have
taken some of the criticism personally due to the tone, however, if I
hadn't been 'seasoned' by the Internet to expect the worst.

That said, I like that those of us who are close can joke. We're all
volunteers, so why not have fun *while* we build what we think is the
ideal distro? I don't think quality and fun are mutually exclusive.

"at least when they're sober" -- I had a hearty laugh at that one. :)

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



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Michał Górny]

On Sun, 15 May 2016 08:40:39 +0900
Aaron Bauman  wrote:

> On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote:
> > On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman  wrote:  
> > > On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:  
> > >> On Sat, 7 May 2016 23:25:58 +0200
> > >> 
> > >> Michał Górny  wrote:  
> > >> > Do you seriously expect this code to work? How about testing? Or
> > >> > reading diffs before committing?  
> > > 
> > > Absolutely nothing wrong was said here.  Obviously the code was not tested
> > > and Michal pointed that out very plainly.  
> > 
> > It is actually possible to communicate both plainly and politely at
> > the same time.  This does not require sacrificing any commitment to
> > quality at all.  Really the only downside is having more of an
> > appearance of professionalism.  
> 
> Please enlighten me as to what was impolite here?  The strong language of 
> "seriously" or definitively stating that the individual did not perform the 
> necessary QA actions before committing?  Both of which are completely called 
> for and appropriate.  No vulgarity, insults, or demeaning words were used.  
> How would you have responded professionally?

Since the anti-productivity of this thread is getting impressively high
even for Gentoo standards, I'd like to point out a few things.

It was impolite. It was supposed to be. Not offensive but impolite. It
ain't cool to get responses like this but it ain't cool to break stuff
like this either.

For those who don't have a broader view, it wasn't a single commit but
a followup to a commit adding EAPI=6 support to the eclass -- clearly
untested. I didn't bother complaining about the first one since issues
would clearly pop up if someone actually tried to use the eclass
in EAPI=6. However, the second commit actually introduced a syntax
error that broke all the ebuilds, including stable and caused metadata
generation failure. This is real bad.

Of course, it could have been worse. It looks like no ebuilds with
EAPI=6 'support' were committed following the eclass. Which is a good
sign that some testing eventually occurred. However, is it that much of
an effort to test eclass changes using ebuilds *before* committing it?
It wasn't that hard even in times of CVS (esp. that we're talking about
separate directories), and it is even easier in times of git.

I don't really see the benefit of whole of this discussion. He
committed a bad thing, I shouted at him, end of story. If you want to
take it to comrel, just do it. However, discussing whether it was right
or wrong is really unproductive here.

-- 
Best regards,
Michał Górny



pgpJldPE9ttEf.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Ryan Hill]

On Sun, 15 May 2016 08:40:39 +0900
Aaron Bauman  wrote:

> On Saturday, May 14, 2016 9:54:11 AM JST Rich Freeman wrote:
> > On Sat, May 14, 2016 at 7:55 AM, Aaron Bauman  wrote:  
> > > On Friday, May 13, 2016 4:52:09 PM JST Ian Delaney wrote:  
> > >> On Sat, 7 May 2016 23:25:58 +0200
> > >> 
> > >> Michał Górny  wrote:  
> > >> > Do you seriously expect this code to work? How about testing? Or
> > >> > reading diffs before committing?  
> > > 
> > > Absolutely nothing wrong was said here.  Obviously the code was not tested
> > > and Michal pointed that out very plainly.  
> > 
> > It is actually possible to communicate both plainly and politely at
> > the same time.  This does not require sacrificing any commitment to
> > quality at all.  Really the only downside is having more of an
> > appearance of professionalism.  
> 
> Please enlighten me as to what was impolite here?  The strong language of 
> "seriously" or definitively stating that the individual did not perform the 
> necessary QA actions before committing?  Both of which are completely called 
> for and appropriate.  No vulgarity, insults, or demeaning words were used.  
> How would you have responded professionally?

I thought his response was pretty tame actually.  If you break the tree
because you couldn't be bothered to do the barest minimum of testing you
absolutely deserve to be called out on it.

But if you guys just want to hug it out that's cool too.

-- 


pgp6v204Sg7ZU.pgp
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] distutils-r1.eclass: Do not apply patches if DISTUTILS_OPTIONAL is used

[Michał Górny]

Do not apply PATCHES and user patches (either via the EAPI 6 default or
pre-EAPI 5 code) when DISTUTILS_OPTIONAL is being used. In this case,
distutils functions are usually called conditionally, in a subdirectory,
while both PATCHES and user patches are usually intended to be applied
top-level.

There is no ebuild relying on distutils-r1_src_prepare applying patches
with DISTUTILS_OPTIONAL. In fact, there are ebuilds which work around
this behavior.
---
 eclass/distutils-r1.eclass | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index e8de5ad..afd29ed 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -315,11 +315,13 @@ _distutils-r1_disable_ez_setup() {
 distutils-r1_python_prepare_all() {
debug-print-function ${FUNCNAME} "${@}"
 
-   if [[ ${EAPI} != [45] ]]; then
-   default
-   else
-   [[ ${PATCHES} ]] && epatch "${PATCHES[@]}"
-   epatch_user
+   if [[ ! ${DISTUTILS_OPTIONAL} ]]; then
+   if [[ ${EAPI} != [45] ]]; then
+   default
+   else
+   [[ ${PATCHES} ]] && epatch "${PATCHES[@]}"
+   epatch_user
+   fi
fi
 
# by default, use in-source build if python_prepare() is used
-- 
2.8.2

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Brian Dolbec]

On Sun, 15 May 2016 11:05:21 +0200
Jeroen Roovers  wrote:

> On Sat, 7 May 2016 23:25:58 +0200
> Michał Górny  wrote:
> 
> > Do you seriously expect this code to work? How about testing? Or
> > reading diffs before committing?  
> 
> 
> Somebody could have a go at implementing this:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=390651
> 
> It's been brewing for half a decade. Maybe it's time. :)
> 
> 
> Regards,
>  jer
> 

With the new repoman code structure, yes, it would be a lot easier to
implement.

Also with the gen-b0rk test repo, that will be a good testing ground
for eclass changes too.  It just needs more devs to make test ebuilds
to get it fully populated ;)

-- 
Brian Dolbec 

[gentoo-dev] Last-rites: sci-libs/torch

[David Seifert]

# David Seifert  (15 May 2016)
# Masked for removal. Deprecated, relies on ancient CUDA APIs,
# does not build with current CUDA releases. See bug #583068.
sci-libs/torch

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Jeroen Roovers]

On Sat, 7 May 2016 23:25:58 +0200
Michał Górny  wrote:

> Do you seriously expect this code to work? How about testing? Or
> reading diffs before committing?


Somebody could have a go at implementing this:

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

It's been brewing for half a decade. Maybe it's time. :)


Regards,
 jer

Re: [gentoo-dev] [PATCH v2 2/4] ebuild-writing/misc-files/metadata: rewrite the section per GLEP 67 #572144

[Michał Górny]

On Sat, 14 May 2016 20:57:48 -0400
Göktürk Yüksek  wrote:

> @@ -244,12 +221,7 @@ optional:
>  without this attribute must also exist. That tag without the restrict 
>  attribute will serve as the default. The format of the restrict 
> attribute 
>  is that of the DEPEND flag, except that "<" and 
> -">" need to be specified by < and >.
> -
> -For example, in the sys-libs/db package, 
> -restrict=">=sys-libs/db-3.2.9-r5"  on the
> -maintainer tag shows that I'm currently maintaining all
> -versions greater then 3.2.9-r5.
> +">" need to be specified by "<" and ">".
>
>  
>  

I'm sorry for coming late to the party but could you mention that it
must be an EAPI 0 package dependency? There were more than a few
packages where people put slot- or USE-dependencies there.

-- 
Best regards,
Michał Górny



pgpdrcEhILP4Q.pgp
Description: OpenPGP digital signature