[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/pyfltk/, dev-python/pyfltk/files/

[Michał Górny]

On Sun,  8 Nov 2015 06:57:38 + (UTC)
"Jeroen Roovers"  wrote:

> commit: b39f2acde24b95c4be5ed1e83c3a0d71fc58ab11
> Author: Jeroen Roovers  gentoo  org>
> AuthorDate: Sun Nov  8 06:53:39 2015 +
> Commit: Jeroen Roovers  gentoo  org>
> CommitDate: Sun Nov  8 06:53:39 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b39f2acd
> 
> dev-python/pyfltk: Old.
> 
> Package-Manager: portage-2.2.24
> 
>  dev-python/pyfltk/Manifest |  1 -
>  .../files/pyfltk-1.3.0-format-security.patch   | 74 
> --
>  .../files/pyfltk-1.3.0-linux-3.x-detection.patch   | 15 -
>  dev-python/pyfltk/pyfltk-1.3.0-r2.ebuild   | 50 ---
>  4 files changed, 140 deletions(-)

And you just removed the last version supporting python2.7.
As a result, matplotlib and pygene can't be installed at all:

https://qa-reports.gentoo.org/output/gentoo-ci/cb08652/1.html#l184
https://qa-reports.gentoo.org/output/gentoo-ci/cb08652/1.html#l424

There are probably even more silent breakages (which will cause Portage
to randomly kill python2.7 in more and more packages via package.use).

Please *BE MORE CAREFUL* when removing stuff. Reverted now.

-- 
Best regards,
Michał Górny



pgp65ekFpMDpu.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] pre-GLEP review: Maintainership structure

[Michał Górny]

On Sat, 7 Nov 2015 20:45:37 -0500
Michael Orlitzky  wrote:

> On 11/03/2015 05:15 PM, Michał Górny wrote:
> > 
> > Please review, comment and answer the questions in TODOs ;-).
> > 
> > [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Maintainership_structure
> >   
> 
> Much more sane than what we have now, thank you.
> 
> My only question is about the name of the "subproject" element. If you
> haven't read the GLEP, can you tell me whether Foo is a subproject of
> Bar or vice-versa?
> 
>   
> Foo
> f...@gentoo.org
> 
>   
> 
>   
> Bar
> b...@gentoo.org
>   

I don't see a problem with that. We have a  object that has
 and  elements -- sub-objects. Otherwise, it'd be
 or .

This could be made a little more clear if we wrapped all subprojects
around  element. But then, we should also wrap members
around , and maintainers around  ;-) for
consistency. And the last one would actually break backwards
compatibility, though it'd be consistent with how we do ...

> Putting the name aside, I expected the mapping to go in the other
> direction by analogy with relational databases.

Relational databases have technical limitation of having one value for
key which does not apply here. That's why most ORMs actually focus on
the opposite direction than the database itself.

> This is also misleading with the current name:
> 
>   
> 
> That looks like the subproject inherits the members of the parent
> project, right? But it's the other way around:
> 
>   * optional inherit-members="" attribute whose non-empty value
> indicates that subproject members are to be considered members of
> the parent project as well.
> 
> If everyone likes and wants to keep the name _sub_project, I think
> _inherit_ is the wrong word to use, since children inherit from parents.

What do you suggest instead?

-- 
Best regards,
Michał Górny



pgpKc_R1450aM.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] pre-GLEP review: Maintainership structure

[Michael Orlitzky]

On 11/03/2015 05:15 PM, Michał Górny wrote:
> 
> Please review, comment and answer the questions in TODOs ;-).
> 
> [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Maintainership_structure
> 

Much more sane than what we have now, thank you.

My only question is about the name of the "subproject" element. If you
haven't read the GLEP, can you tell me whether Foo is a subproject of
Bar or vice-versa?

  
Foo
f...@gentoo.org

  

  
Bar
b...@gentoo.org
  

Putting the name aside, I expected the mapping to go in the other
direction by analogy with relational databases.

This is also misleading with the current name:

  

That looks like the subproject inherits the members of the parent
project, right? But it's the other way around:

  * optional inherit-members="" attribute whose non-empty value
indicates that subproject members are to be considered members of
the parent project as well.

If everyone likes and wants to keep the name _sub_project, I think
_inherit_ is the wrong word to use, since children inherit from parents.

Re: [gentoo-dev] ChangeLog - Infra Response

[Markos Chandras]

On 11/05/2015 12:39 PM, Ulrich Mueller wrote:
>> On Thu, 5 Nov 2015, Alexis Ballier wrote:
> 
>> On Mon, 2 Nov 2015 20:18:07 +
>> "Robin H. Johnson"  wrote:
> 
>>> On Mon, Nov 02, 2015 at 08:05:56AM +0100, Ulrich Mueller wrote:
 What would be the problem with renaming? IMHO it would be nicer to
 keep the ChangeLog name for the autogenerated files and rename the
 ones from CVS. We already have files renamed to ChangeLog-
 when they became to large, so we could just use ChangeLog-2015 to
 stay within that scheme.
> 
>>> If we rename the old ChangeLog files from CVS to ChangeLog-2015, then
>>> we'll have both 'ChangeLog-2015' and 'ChangeLog' (generated from Git)
>>> containing 2015 entries. Worse, what happens when we hit 2016? Do we
>>> merge the old files?
> 
>> It's not perfectly clean but I don't see any problem here:
>> ChangeLog-2015 : all ChangeLog from CVS
>> ChangeLog: autogenerated from git
> 
>> if/when there is a need to split git changelogs, autogenerated
>> changelogs will start from say, Jan. 1st 2016, and previous changes
>> will now be static. Merging CVS2015 and git2015 changelogs is just a
>> matter of running a script. Or just skip splitting them for 2016, and
>> start splitting in 2017, so that ChangeLog-2015 is CVS ones,
>> ChangeLog-2016 is git logs from Aug. 8. 2015 to Dec. 31 2016.
> 
>> IMHO this is still better than having ChangeLog stopping in 2015 and
>> ChangeLog.git starting from this date: Having ChangeLog-2015 from CVS
>> still carries partial information on the timeline.
> 
> +1
> 
> You said it better than I could have.
> 
> Ulrich
> 
yeah, +1 on that too. I am not too bothered with the name to be honest.
However, using 'ChangeLog' for git logs sounds like something most of us
and users are familiar with already so that should work.

-- 
Regards,
Markos Chandras

Re: [gentoo-dev] Re: ChangeLog

[Robin H. Johnson]

On Fri, Nov 06, 2015 at 08:25:53PM -0800, Raymond Jennings wrote:
> Isn't the whole anongit.gentoo.org concept designed to allow anonymous,
> read-only git to scale indefinitely in the future?
> 
> Are there any plans in the works on how to utilize this domain name?
What do you mean plans?

It works, and has worked for a long time already (even prior to the main
repo conversion).

$ git clone git://anongit.gentoo.org/repo/gentoo.git
...

Go and look on the gitweb/cgit, and you'll see every public repo has a
anongit URL available. Private repos are not available by anongit, for
self-evident reasons.

Anongit is backed by multiple hosts already, with GeoDNS to hopefully
direct you to the nearest mirror (note that we're down to just one US
host presently, but Europe does still have two).

anongit.gentoo.org. 3600IN  CNAME   anongit.geodns.gentoo.org.
; GeoDNS targeting...
anongit.geodns.gentoo.org. 3600 IN  CNAME 
anongit-v4v6.geodns-americas.gentoo.org.
anongit.geodns.gentoo.org. 3600 IN  CNAME 
anongit-v4v6.geodns-europe.gentoo.org.
...

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85


signature.asc
Description: Digital signature

Re: [gentoo-dev] Globally masking the sssd USE-flag on sudo and enabling it on supported architectures only

[Markos Chandras]

On 11/04/2015 05:37 PM, Markos Chandras wrote:
> On 11/04/2015 11:34 AM, lejonet wrote:
>> Hi gentoo-dev,
>>
>> I recently had a bout with sudo and sssd, and found that the problem was that
>> sudo wasn't sssd aware and the reason we don't have a USE-flag for that is 
>> due
>> to some lingering bugs.
>>
>> To partially solve this I propose that we mask the sssd USE-flag,
>> globally and only unmask it on supported architectures that we have already
>> confirmed it working on (like amd64 and x86).
>> This prevents us from having to withdraw keywords on a rather important
>> package on minor arches on which sssd and sudo haven't been tested yet.
>>
>> Dropping keywords on sudo seems unnecessary and very disruptive but allowing
>> sssd bugs to linger isn't a great solution either[1], as in this particular
>> issue, a sudo bug is depending on the lingering sssd bug.[2]
>>
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=540540
>> [2] https://bugs.gentoo.org/show_bug.cgi?id=525674
>>
> 
> fwiw, it sounds good to me
> 

so are you going to do it or should I?

-- 
Regards,
Markos Chandras