gmane.linux.gentoo.devel

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

Kacper Kowalik — 2012-05-23T11:26:34

I wrote a simple, stupid script just a moment ago. Please don't show it
to anybody who knows how to write in Python :D

It shows all missing inherits, not just the ones causing failures, but
it could prolly be adjusted to do that instead.

Cheers,
Kacper

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

Pacho Ramos — 2012-05-23T11:00:01

El mié, 23-05-2012 a las 10:31 +0100, Markos Chandras escribió:

But we still have no idea what kind of commands provided by eutils and
eclasses inheritted by it are now missing, epatch usage was fixes,
enewgroup/user will probably be done but... other missing commands could
still appear in the tree :|

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

Markos Chandras — 2012-05-23T09:31:15

It is far too late to do that. What is done is done. Let try and fix
what is still broken

Regards,
Markos

dev-libs/libusb -> virtual/libusb, please, check your overlays

Samuli Suominen — 2012-05-23T08:43:19

Whole gentoo-x86 is using the virtuals now. Please check your overlays 
to avoid dev-libs/libusb from creeping back in to the tree.

http://qa-reports.gentoo.org/output/genrdeps/dindex/dev-libs/libusb
http://qa-reports.gentoo.org/output/genrdeps/rindex/dev-libs/libusb

If you have packages in overlays using dev-libs/libusb please fix them 
now to avoid them creeping into Portage.

There is a repoman bug open but still without a patch:

http://bugs.gentoo.org/417123

This is important now because of the dev-libs/libusb-compat stabilization:

http://bugs.gentoo.org/417135

Otherwise you'd be introducing conflicting dependencies for /stable/ users.

Futhermore some of the virtual/libusb dependencies in tree are missing 
usage of correct SLOT, and should be fixed, that involves checking the 
package sources (of course). If you want to help with this, please do.

Thanks,
Samuli

Help required with getting new media-gfx/graphviz in tree.

Samuli Suominen — 2012-05-23T08:27:45

We are behind with graphviz and 2.28.x series has been out for quite a 
while.

However working on the ebuild will require quite a work and then 
backtracking the bugs that come after it as a result (believe me, there 
will be ones)

It seems graphics< at > is currently a bit understaffed and I really don't 
see anyone working on this anytime soon without sending this mail.

Thanks ahead

- Samuli

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

Petteri Räty — 2012-05-23T08:28:13


Even more important is the next chapter:

"When removing a function or changing the API of an eclass, make sure
that it doesn't break any ebuilds in the tree, and post a notice to
gentoo-dev at least 30 days in advance, preferably with a patch included."

This qualifies as changing the API of an eclass. This chapter comes from
a council decision:

http://www.gentoo.org/proj/en/council/meeting-logs/20111108-summary.txt

Regards,
Petteri

Re: anybody interested in writing a Perl ebuild?

Grant — 2012-05-23T08:14:52

Thanks, I gave that a try and it did a bunch of stuff but when I try
to emerge Net-Braintree I get:

!!! A file is not listed in the Manifest:
'/var/lib/layman/moonrise/perl-gcpan/DateTime-Format-RFC3339/DateTime-Format-RFC3339-1.0.5.ebuild'
!!! A file is not listed in the Manifest:
'/var/lib/layman/moonrise/perl-gcpan/DateTime-Format-Atom/DateTime-Format-Atom-1.0.2.ebuild'

I noticed that g-cpan put all of the ebuilds it generated in:

/var/lib/layman/moonrise/perl-gcpan

Is that the right place for them?

- Grant

Re: Re: Remove eclass/ChangeLog

Samuli Suominen — 2012-05-23T08:02:58

absolutely because inconsitency renderess the file useless

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

Pacho Ramos — 2012-05-23T08:04:26

El mié, 23-05-2012 a las 06:39 +1000, Michael escribió:

The autotools.eclass change should probably be reverted until things are
properly checked I think (and I will do it tomorrow if nobody disagrees)

Re: anybody interested in writing a Perl ebuild?

Robin H. Johnson — 2012-05-23T07:49:36

Use g-cpan.

g-cpan -g Net::Braintree

It will generate packages for the module and all needed deps
(DateTime-Format-RFC3339, DateTime-Format-Atom,
Module-Install-TestTarget, Hash-Inflator, local-lib, URI-Query).

anybody interested in writing a Perl ebuild?

Grant — 2012-05-23T07:31:59

Hello, is anyone interested in writing a Perl ebuild for this payment module:

http://search.cpan.org/dist/Net-Braintree/

Thanks,
Grant

P.S. Braintree is a stellar payment company:

https://www.braintreepayments.com/developers

Re: Remove eclass/ChangeLog (was: Re: [gentoo-commits] gentoo-x86 commit in eclass: autotools.eclass)

Ryan Hill — 2012-05-23T02:36:39

On Sun, 20 May 2012 15:33:11 +0300
Samuli Suominen <ssuominen< at >gentoo.org> wrote:


One person doesn't do entries.  OMG let's remove it!

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

Michael — 2012-05-22T20:39:10

Since eutils inherits multilib and user, the breakage extends beyond epatch.
For example, I just saw bug #417153, where a user reported failed calls 
to enew{user,group}.

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

Zac Medico — 2012-05-22T20:04:37

Done already:

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

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

Pacho Ramos — 2012-05-22T18:22:15

El lun, 21-05-2012 a las 12:25 -0700, Zac Medico escribió:

Should we (I) open a bug report requesting that or this is enough as
report? Thanks :)

Re: Do we need games group and all that game prefixes?

Michał Górny — 2012-05-22T14:40:59

I've opened a bug for this:

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

Re: RFC: Add new remote-id types in metadata.dtd

Michael Weber — 2012-05-22T14:16:02

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Can we bump our gentoo-x86/skel.metadata.xml and
app-vim/gentoo-syntax:/usr/share/vim/vimfiles/plugin/newmetadata.vim
files to display some upstream+remote-id lines to make these tags more
prominent?

<upstream>
   <maintainer status="active">
   <email></email>
   <name></name>
   </maintainer>
   <changelog></changelog>
   <doc lang="en"></doc>
   <bugs-to></bugs-to>
   <remote-id type=""></remote-id>
</upstream>


On 04/19/2012 05:31 PM, Corentin Chary wrote:


- -- 
- --
Gentoo Dev
http://xmw.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk+7n6IACgkQknrdDGLu8JB0bwEAlh9AilEx700DVEwQYD2KJxtc
nLrzXyCrZZLZLE6cpX8BAJIj05i+LN8ZLJOH3bAtcSp41YG4EarviiKTdEpy2Yon
=CQje
-----END PGP SIGNATURE-----

Re: Git migration (2012) (Was: Re: Remove eclass/ChangeLog)

Dirkjan Ochtman — 2012-05-22T09:46:14

ISTM things like bug 333697 (partial checkout support) and 333699
(git-cvsserver, so that holdouts can still commit through CVS?)
shouldn't block the migration... they're just nice-to-haves.

Cheers,

Dirkjan

Git migration (2012) (Was: Re: Remove eclass/ChangeLog)

Pacho Ramos — 2012-05-22T09:35:48

El mar, 22-05-2012 a las 11:22 +0200, Fabio Erculiani escribió:

Regarding migration to git, I think some people where working on it, but
there were some pending problems preventing the migration:
https://bugs.gentoo.org/show_bug.cgi?id=333531

there, you can see the blockers, the problem is that most of them are
stalled :|, if you (or anybody) could take care of them...

Re: Remove eclass/ChangeLog

Fabio Erculiani — 2012-05-22T09:22:40

and how about getting rid of echangelog and just have it autogenerated as well?
Or even better, how about giving up with cvs once for all?

Re: Remove eclass/ChangeLog

Michael Weber — 2012-05-22T09:01:37

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/20/2012 03:55 PM, Andreas K. Huettel wrote:

+1 and consider profiles/**/package.mask, too.

- -- 
- --
Gentoo Dev
http://xmw.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk+7VfAACgkQknrdDGLu8JAClQD/SVh+bstPurUReBipvCeGPYfE
ZIGHcSs8Wt7HH0dy/YcA/iB2TRcd3BlcVy4O6v5wmf52s4UtCNnpYOL+RpD3O/in
=uZ6k
-----END PGP SIGNATURE-----