gmane.linux.gentoo.devel

Re: Portage Git migration - clean cut or git-cvsserver

Alec Warner — 2012-05-25T11:07:28

This thread has had many suggestions about how things might be laid
out. For instance I think it would be against our social contract to
host the master git tree on github as someone suggested earlier in the
thread. My intent was mostly to keep the contract in mind when coming
up with such solutions.

Re: anybody interested in writing a Perl ebuild?

Kent Fredric — 2012-05-25T09:22:10

Using that category solves many issues in advance, ie: if you
generated an ebuild locally, and then we provided a maintained copy,
portage would just switch from one to the other seamlessly where
needed without you having to modify all ebuilds that depend on it.

ie:

if a package was installed in perl-gcpan/ instead ( which used to be
the case iirc ), you then have:

  perl-gcpan/foo : DEPENDS dev-perl/bar
  perl-gcpan/baz : DEPENDS perl-gcpan/foo

And if you want to cede development of "foo" to an overlay/gentoo,
you'd have to change perl-gcpan/baz to point to perl-gcpan/foo
instead.

With the packages all in dev-perl, no such changes are required.


It should be reasonably safe, but If you want to be sure, I advise
enabling tests.

---[ /etc/portage/package.env ]---
dev-perl/* perlmod.conf
-----------------------------------------

---[ /etc/portage/env/perlmod.conf ]---
FEATURES="${FEATURES} test"
----------------------------------------------

And this will at least give you the same level of assurance as you
would get if you were installing the packages with a CPAN client.

We do our best to make the overlay stable somewhat, but it will always
be somewhat less important than the main tree


I've it on my mental TODO list, just a lot of other things I'm behind
schedule in updating atm.

Re: anybody interested in writing a Perl ebuild?

Grant — 2012-05-25T08:52:41

I switched local-lib from the g-cpan one to the perl-experimental one
and all is well as far as installation all the way through
Net-Braintree.  Thank you very much for sticking with me on this guys.

May I ask why you force the g-cpan category to dev-perl?

To what extent is running ebuilds from perl-experimental a safe endeavor?

Should Net-Braintree or any of the ebuilds I had g-cpan trouble with
be eligible for inclusion in the main tree or perl-experimental?

Thanks again,
Grant

Re: anybody interested in writing a Perl ebuild?

Kent Fredric — 2012-05-25T06:49:58


For local-lib, you're best trying using the copy in the
perl-experimental overlay.  If that doesn't work either, then why the
sandbox violation is occurring needs looked at.

Re: Portage Git migration - clean cut or git-cvsserver

Kent Fredric — 2012-05-25T06:47:44

Though in the case of github, gentoo is not "depending upon it".
Github could die in a ball of fire, and it wouldn't change the core
development, it would only change the development for the people who
elected to use github.

Anyone can use any git platform that competes with github, be it
bitbucket, gitorious, or a private git server they created.

Github is just a convenient go-to service for many.

Re: anybody interested in writing a Perl ebuild?

Grant — 2012-05-25T06:16:09

That did it, but there's more trouble.  g-cpan strikes again?

 * Using ExtUtils::MakeMaker
 * perl Makefile.PL PREFIX=/usr INSTALLDIRS=vendor INSTALLMAN3DIR=none
DESTDIR=/var/tmp/portage/dev-perl/local-lib-1.008004/image/
ACCESS DENIED  open_wr:      /usr/lib64/perl5/5.12.4/CPAN/Config.pm
Cannot open >/usr/lib64/perl5/5.12.4/CPAN/Config.pm at
/usr/lib64/perl5/5.12.4/CPAN/HandleConfig.pm line 470
CPAN::HandleConfig::_configpmtest('/usr/lib64/perl5/5.12.4/CPAN',
'/usr/lib64/perl5/5.12.4/CPAN/Config.pm') called at
/usr/lib64/perl5/5.12.4/CPAN/HandleConfig.pm line 551
CPAN::HandleConfig::load('CPAN::HandleConfig') called at
/usr/lib64/perl5/5.12.4/CPAN/Shell.pm line 1517
CPAN::Shell::optprint('CPAN::Shell', 'load_module', 'CPAN:
File::HomeDir loaded ok (v0.98)\x{a}') called at
/usr/lib64/perl5/5.12.4/CPAN.pm line 1101
CPAN::has_inst('CPAN=HASH(0x1e0d4114e8)', 'File::HomeDir', undef)
called at /usr/lib64/perl5/5.12.4/CPAN.pm line 982
CPAN::has_usable('CPAN=HASH(0x1e0d4114e8)', 'File::HomeDir') called
at /usr/lib64/perl5/5.12.4/CPAN/HandleConfig.pm line 506
CPAN::HandleConfig::home() called at
/usr/lib64/perl5/5.12.4/CPAN/HandleConfig.pm line 478
CPAN::HandleConfig::require_myconfig_or_config('CPAN::HandleConfig')
called at Makefile.PL line 212
 * ERROR: dev-perl/local-lib-1.008004 failed (configure phase):
 *   Unable to build!
 *
 * Call stack:
 *     ebuild.sh, line   85:  Called src_configure
 *   environment, line 2220:  Called perl-module_src_configure
 *   environment, line 1936:  Called perl-module_src_prep
 *   environment, line 2008:  Called die
 * The specific snippet of code:
 *               perl Makefile.PL "$< at >" <<< "${pm_echovar}" || die
"Unable to build!";
 *
 * If you need support, post the output of 'emerge --info
=dev-perl/local-lib-1.008004',
 * the complete build log and the output of 'emerge -pqv
=dev-perl/local-lib-1.008004'.
 * This ebuild is from an overlay named 'x-portage': '/usr/local/portage/'
 * The complete build log is located at
'/var/log/portage/dev-perl:local-lib-1.008004:20120525-061124.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/dev-perl/local-lib-1.008004/temp/environment'.
 * S: '/var/tmp/portage/dev-perl/local-lib-1.008004/work/local-lib-1.008004'
--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE "/var/log/sandbox/sandbox-10934.log"

VERSION 1.0
FORMAT: F - Function called
FORMAT: S - Access Status
FORMAT: P - Path as passed to function
FORMAT: A - Absolute Path (not canonical)
FORMAT: R - Canonical Path
FORMAT: C - Command Line

F: open_wr
S: deny
P: /usr/lib64/perl5/5.12.4/CPAN/Config.pm
A: /usr/lib64/perl5/5.12.4/CPAN/Config.pm
R: /usr/lib64/perl5/5.12.4/CPAN/Config.pm
C: perl Makefile.PL PREFIX=/usr INSTALLDIRS=vendor INSTALLMAN3DIR=none
DESTDIR=/var/tmp/portage/dev-perl/local-lib-1.008004/image/
--------------------------------------------------------------------------------


- Grant

Re: Portage Git migration - clean cut or git-cvsserver

Ulrich Mueller — 2012-05-25T06:12:09




Actually, Alec's question is not so far-fetched. The Gentoo Social
Contract says that Gentoo will never depend upon a piece of software
unless it is open source.

Ulrich

Re: comprehensive eclass checking in repoman

Ryan Hill — 2012-05-25T03:50:51

On Thu, 24 May 2012 21:47:23 -0600
Ryan Hill <dirtyepic< at >gentoo.org> wrote:


Oh and even if there isn't, big +1 from me.

Re: comprehensive eclass checking in repoman

Ryan Hill — 2012-05-25T03:47:23

On Thu, 24 May 2012 15:47:09 -0400
Mike Frysinger <vapier< at >gentoo.org> wrote:


Is there any sane way to handle sub-eclasses?  eg. foo-base inherits
foo-functions.

I have some crazy ideas on how to do eclass versioning I may one day threaten
the world with if they ever let me out of my padded cell.

Re: autotools.eclass no longer inherits eutils; check your ebuilds!

Ryan Hill — 2012-05-25T03:30:43

On Thu, 24 May 2012 14:02:05 +0100
Ciaran McCreesh <ciaran.mccreesh< at >googlemail.com> wrote:


Like I said, technically it is.  And that's terrible.  Let's ignore it. :D

Re: Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

Maxim Kammerer — 2012-05-25T01:40:44

I have to ask: was the pronoun capitalization intentional?


IIRC, it was about git-svn specifically, although I think you are
right: developers will use git and GitHub because they fulfill a need,
regardless of policies.

Re: Portage Git migration - clean cut or git-cvsserver

Kent Fredric — 2012-05-25T01:32:08

Your confusion begets more confusion:

Whether or not Github is open-source seems orthogonal to whether or
not we use it, as github is a website, a service, and there are a few
such websites, of which, github appears to be the defacto most-popular
one.

Re: Portage Git migration - clean cut or git-cvsserver

Alec Warner — 2012-05-25T01:21:37

So I'm a bit confused. Is GitHub open source?

Re: Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

Rich Freeman — 2012-05-25T00:58:45

++

There is no policy that every commit in cvs needs to be referenced to
a bug, and I doubt we're going to change that.  So, if I call up
another dev on the phone and tell them they have a typo in an ebuild,
and they fix it and commit it, nothing has gone wrong.  That isn't the
most efficient way to work usually, but there is no policy against it.
 In general users should file bugs and not contact devs directly, but
if somebody has a private arrangement otherwise, no harm no foul.

Github is just another overlay.  If in the course of working on the
next kde release the kde team makes 385 changes to their overlay, we
don't make them log and close 385 bugs on b.g.o before they merge in
the files from the overlay.

So, if a team wants to use non-official tools, by all means go ahead.
The QA standards apply to anything hitting the main tree, and must be
followed at that point in time.  We should keep our tools working
well, but if in some case there is a better way of working, or a small
team has some other preference, well, have at it!

Rich

Re: Re: comprehensive eclass checking in repoman

Mike Frysinger — 2012-05-25T00:14:42

that happens now when you emerge eclass-manpages, but i suspect no one cares.  
if you run the script by hand on your eclass, it'll tell you the same thing.
-mike

Re: comprehensive eclass checking in repoman

Steven J Long — 2012-05-24T22:16:23




I think it's an excellent idea to give this kind of QA early, to avoid 
issues like recent eutils inheritance changes in the future; it's not a 
hammer so much as a helpful reminder, that improves things for everyone. 

You could maybe tighten the false-negative side by scanning all functions 
defined in an eclass, and warning if they're undocumented.

Steve.

Re: Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

Dan Douglas — 2012-05-24T22:01:43

This discussion was sort of in the context of proxy-maintainers. A pull 
request isn't equivalent to a bump request or entirely overlapping with most 
bugs that go through bugzilla. A pull request is  just "here take my code", or 
is useful for code revewing just because it integrates with the git workflow. I 
suppose you would  have to define the sorts of things that should go through 
Bugzilla. I can't imagine it being reasonable to use github for most types of 
bump requests.


This reminds me of Linus' old Google talk on Git in which He said something 
along the lines of: "Many companies using Git internally don't know they're 
using git - they're using it whether they like it or not". There are ALREADY 
Gentoo projects using github and even pull requests. It doesn't really matter 
because everything more or less comes back to one point in the end. It's the 
repo that's the history of the project, not bugzilla. I've "filed" more bugs 
over IRC and had them fixed in the tree within 60 seconds than I have gone 
through bugzilla formalisms. FWIW, I think having the entire tree in one big 
repo is a bad idea to begin with.

But ok it's a good point. Github isn't a good central point of contact. People 
have to use their discression. It's just uncommon these days for a project as 
big as Gentoo to have ultra-centralized corporate-style procedures where 
everything happens exclusively though official channels. And anyway you couldn't 
"enforce" that sort of thing if you tried.

Re: Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

Alexey Shvetsov — 2012-05-24T21:27:50

Kent Fredric писал 2012-05-25 01:20:

You can rebase signed commit untill you dont push it to master
But yes i'm not sure how it works with signed commits

Re: Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

Kent Fredric — 2012-05-24T21:20:07

Something that still confuses me about commit signing that I haven't
seen answered: How does a signed commit work with rebasing? I don't
see any flag to allow rebase to sign commits rebased, and rebasing
*does* change the commit fundementally in ways I'd expect to void any
signature.

Sure, you may not want rebasing in the master, but I sure as hell want
to use it in a branch. People who maintain a long-parallel-merge
history instead of rebasing their branches are on my personal shitlist
=p.

Re: Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

Kent Fredric — 2012-05-24T21:16:48


+1


+/-1 : Not sure, for new people, it should definitely be the go-to way
to do things.

But people who are regular contributors ( which we want to encourage )
will feel slowed down if they have to open a bug report for every
change.

And I can see github facilitating "proxy maintainers" much better.

If a proxy maintainer has another gentoo person who all their changes
get proxied through, the proxy maintainer and the gentoo dev could
both have forks on github, and the proxy maintainer could send their
pull requests to their proxy to vet and merge, somewhat like Linus'es
Generals model.

Re: Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

Alexey Shvetsov — 2012-05-24T21:14:05

In gentoo git tree all git commits will be signed by commiter gpg keys 
(and this will be requerd!)

Aaron W. Swenson писал 2012-05-25 00:00: