On Sat, Aug 15, 2015 at 10:09 PM, Raymond Jennings shent...@gmail.com wrote:
On Fri, Aug 14, 2015 at 6:16 PM, Ian Stakenvicius a...@gentoo.org wrote:
Finally, the gentoo developer quiz -should- still contain questions
about ancient stuff. There are still EAPI0 and EAPI2 ebuilds in the
tree
On 8/16/15 3:29 PM, Rich Freeman wrote:
They are deprecated already:
https://gitweb.gentoo.org/repo/gentoo.git/tree/metadata/layout.conf
Deprecated means stop adding them, and move away from them. Repoman
will give you a warning about them.
Is anything blocking deprecating EAPI4 in the
On Sun, Aug 16, 2015 at 9:47 AM, Paweł Hajdan, Jr.
phajdan...@gentoo.org wrote:
On 8/16/15 3:29 PM, Rich Freeman wrote:
They are deprecated already:
https://gitweb.gentoo.org/repo/gentoo.git/tree/metadata/layout.conf
Deprecated means stop adding them, and move away from them. Repoman
will
What's the best way to get rid of deprecated ebuilds?
Do we just wait for their maintainers to migrate them or should they be
sought out and flagged? I'm pondering searching for EAPI 0 ebuilds and
filing bug reports on them.
On Sun, Aug 16, 2015 at 6:57 AM, Rich Freeman ri...@gentoo.org wrote:
On Sun, 16 Aug 2015 09:52:06 -0700
Raymond Jennings shent...@gmail.com wrote:
What's the best way to get rid of deprecated ebuilds?
Do we just wait for their maintainers to migrate them or should they
be sought out and flagged? I'm pondering searching for EAPI 0
ebuilds and filing bug
On Fri, Aug 14, 2015 at 6:16 PM, Ian Stakenvicius a...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 14/08/15 06:43 PM, Johannes Huber wrote:
Am 08/15/15 um 00:19 schrieb Andrew Savchenko:
Hi,
While I have no objections about EAPI 4 deprecation (except
On Sat, 15 Aug 2015, Paweł Hajdan, wrote:
Nothing seems to prevent doing the mass conversion first,
deprecating EAPI 4, and then having a second, slower pass to make
sure the ebuilds are using EAPI 5 as they should be. One way might
be to add a TODO comment during mass conversion, which then
Dnia 2015-08-15, o godz. 09:06:48
Ulrich Mueller u...@gentoo.org napisał(a):
On Sat, 15 Aug 2015, Paweł Hajdan, wrote:
Nothing seems to prevent doing the mass conversion first,
deprecating EAPI 4, and then having a second, slower pass to make
sure the ebuilds are using EAPI 5 as they
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/14/2015 03:05 PM, Johannes Huber wrote:
Hello Gentoos Penguins,
if we want to attract more contributors we should consider to have
one supported EAPI (latest). EAPI 4 is the last not marked as
deprecated ( EAPI 5). The move in ebuilds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am 08/15/15 um 07:35 schrieb Michał Górny:
This is a cheap hack, not a conversion. Proper conversion to a new
EAPI is about using the new EAPI features. Not marking it 'done',
and pretending there's nothing more to do.
Yeah you are right.
On Sat, 15 Aug 2015 08:12:42 +0200 Paweł Hajdan, Jr. wrote:
On 8/15/15 3:16 AM, Ian Stakenvicius wrote:
Secondly, though, conversion to EAPI5 is not actually trivial, there
are a couple of things, 'usex' related for instance, that also need
to be taken care of. If it was just a matter of
On 8/15/15 3:16 AM, Ian Stakenvicius wrote:
Secondly, though, conversion to EAPI5 is not actually trivial, there
are a couple of things, 'usex' related for instance, that also need
to be taken care of. If it was just a matter of running a sed -e
's/^EAPI=4/EAPI=5/' on all in-tree ebuilds this
On 8/15/15 7:35 AM, Michał Górny wrote:
Dnia 2015-08-15, o godz. 00:05:57
Johannes Huber j...@gentoo.org napisał(a):
if we want to attract more contributors we should consider to have one
supported EAPI (latest). EAPI 4 is the last not marked as deprecated
( EAPI 5). The move in ebuilds from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 15/08/15 02:48 AM, Andrew Savchenko wrote:
On Sat, 15 Aug 2015 08:12:42 +0200 Paweł Hajdan, Jr. wrote:
On 8/15/15 3:16 AM, Ian Stakenvicius wrote:
Secondly, though, conversion to EAPI5 is not actually
trivial, there are a couple of things,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello Gentoos Penguins,
if we want to attract more contributors we should consider to have one
supported EAPI (latest). EAPI 4 is the last not marked as deprecated
( EAPI 5). The move in ebuilds from EAPI 4 to EAPI 5 is very simple
replacing the
Hi,
On Sat, 15 Aug 2015 00:05:57 +0200 Johannes Huber wrote:
if we want to attract more contributors we should consider to have one
supported EAPI (latest). EAPI 4 is the last not marked as deprecated
( EAPI 5). The move in ebuilds from EAPI 4 to EAPI 5 is very simple
replacing the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am 08/15/15 um 00:19 schrieb Andrew Savchenko:
Hi,
While I have no objections about EAPI 4 deprecation (except
concerns mentioned above), I see no strong need for this also. Just
declare EAPI 5 as recommended. Having legacy support for EAPI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 14/08/15 06:43 PM, Johannes Huber wrote:
Am 08/15/15 um 00:19 schrieb Andrew Savchenko:
Hi,
While I have no objections about EAPI 4 deprecation (except
concerns mentioned above), I see no strong need for this also.
Just declare EAPI 5
Dnia 2015-08-15, o godz. 00:05:57
Johannes Huber j...@gentoo.org napisał(a):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello Gentoos Penguins,
if we want to attract more contributors we should consider to have one
supported EAPI (latest). EAPI 4 is the last not marked as deprecated
Hi,
this is actually a fork of the HDEPEND thread (sorry for having
diverged that much there).
As I wrote in the other thread, the problem with PDEPEND is that there
are two (or more) semantics:
- PDEPENDs used as suggestions but yet being considered in the
depgraph and actually installed.
On 09/02/2012 04:45 PM, Fabio Erculiani wrote:
Hi,
this is actually a fork of the HDEPEND thread (sorry for having
diverged that much there).
As I wrote in the other thread, the problem with PDEPEND is that there
are two (or more) semantics:
- PDEPENDs used as suggestions but yet being
On Sun, Sep 2, 2012 at 4:57 PM, hasufell hasuf...@gentoo.org wrote:
Why not introduce a global useflag such as suggested-deps which
complies with GLEP 62 meaning it will be in IUSE_RUNTIME.
How do you manage to fix the PDEPEND identity disorder problem then?
Teaching devs to move to GLEP 62
On Sun, 2 Sep 2012 16:45:12 +0200
Fabio Erculiani lx...@gentoo.org wrote:
Hi,
this is actually a fork of the HDEPEND thread (sorry for having
diverged that much there).
As I wrote in the other thread, the problem with PDEPEND is that there
are two (or more) semantics:
- PDEPENDs used as
On Sun, 2 Sep 2012 17:09:22 +0200
Fabio Erculiani lx...@gentoo.org wrote:
On Sun, Sep 2, 2012 at 4:57 PM, hasufell hasuf...@gentoo.org wrote:
Why not introduce a global useflag such as suggested-deps which
complies with GLEP 62 meaning it will be in IUSE_RUNTIME.
How do you manage
On Sun, Sep 2, 2012 at 5:23 PM, Michał Górny mgo...@gentoo.org wrote:
On Sun, 2 Sep 2012 17:09:22 +0200
Fabio Erculiani lx...@gentoo.org wrote:
On Sun, Sep 2, 2012 at 4:57 PM, hasufell hasuf...@gentoo.org wrote:
Why not introduce a global useflag such as suggested-deps which
complies
On Sun, 2 Sep 2012 17:51:00 +0200
Fabio Erculiani lx...@gentoo.org wrote:
On Sun, Sep 2, 2012 at 5:23 PM, Michał Górny mgo...@gentoo.org
wrote:
On Sun, 2 Sep 2012 17:09:22 +0200
Fabio Erculiani lx...@gentoo.org wrote:
On Sun, Sep 2, 2012 at 4:57 PM, hasufell hasuf...@gentoo.org
wrote:
On Sun, 2 Sep 2012 17:23:40 +0200
Michał Górny mgo...@gentoo.org wrote:
An effective SDEPEND implementation is definitely nowhere close
to simple. Nor is presenting those dependencies to users.
Indeed it's not, but we *do* have a reference implementation and lots
of practical experience with
On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
and we have worked out all the difficulties.
Please elaborate. What difficulties? What did you implement other than
plain SDEPEND? With what features? Lots of detail missing.
Having said that, if we're going
On Sun, 2 Sep 2012 20:46:19 +0200
Fabio Erculiani lx...@gentoo.org wrote:
On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
and we have worked out all the difficulties.
Please elaborate. What difficulties? What did you implement other than
plain SDEPEND?
On Sun, 2 Sep 2012 19:08:33 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Sun, 2 Sep 2012 17:23:40 +0200
Michał Górny mgo...@gentoo.org wrote:
An effective SDEPEND implementation is definitely nowhere close
to simple. Nor is presenting those dependencies to users.
Indeed
On Sun, 2 Sep 2012 21:07:30 +0200
Michał Górny mgo...@gentoo.org wrote:
On Sun, 2 Sep 2012 19:08:33 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Sun, 2 Sep 2012 17:23:40 +0200
Michał Górny mgo...@gentoo.org wrote:
An effective SDEPEND implementation is definitely nowhere
On Sun, Sep 2, 2012 at 9:04 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Sun, 2 Sep 2012 20:46:19 +0200
Fabio Erculiani lx...@gentoo.org wrote:
On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
and we have worked out all the difficulties.
On Sun, 2 Sep 2012 20:10:38 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Sun, 2 Sep 2012 21:07:30 +0200
Michał Górny mgo...@gentoo.org wrote:
On Sun, 2 Sep 2012 19:08:33 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Sun, 2 Sep 2012 17:23:40 +0200
On Sun, 2 Sep 2012 21:38:26 +0200
Fabio Erculiani lx...@gentoo.org wrote:
On Sun, Sep 2, 2012 at 9:04 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Sun, 2 Sep 2012 20:46:19 +0200
Fabio Erculiani lx...@gentoo.org wrote:
On Sun, Sep 2, 2012 at 8:08 PM, Ciaran McCreesh
s/with/on/
--
Fabio Erculiani
В Втр, 15/12/2009 в 19:59 +0100, Fabian Groffen пишет:
Should an ebuild using an EAPI that has offset-prefix support make the
use of that support mandatory or optional?
I think no. Without real testing that package works in prefix there is
no need to bother and create illusion that it does.
On 16-12-2009 09:29:07 +0300, Peter Volkov wrote:
В Втр, 15/12/2009 в 19:59 +0100, Fabian Groffen пишет:
Should an ebuild using an EAPI that has offset-prefix support make the
use of that support mandatory or optional?
I think no. Without real testing that package works in prefix there
On Tue, 15 Dec 2009 19:59:44 +0100, Fabian Groffen grob...@gentoo.org
wrote:
With the current route where EAPI=3 will simply be EAPI=2 +
offset-prefix support, and EAPI=4 will be EAPI=3 + some other stuff, the
following question arose:
Should an ebuild using an EAPI that has offset-prefix
With the current route where EAPI=3 will simply be EAPI=2 +
offset-prefix support, and EAPI=4 will be EAPI=3 + some other stuff, the
following question arose:
Should an ebuild using an EAPI that has offset-prefix support make the
use of that support mandatory or optional?
In other words, one
On Tue, 15 Dec 2009, Fabian Groffen wrote:
With the current route where EAPI=3 will simply be EAPI=2 +
offset-prefix support,
That's not entirely right, as EAPI 3 will also include mtime
preservation.
Should an ebuild using an EAPI that has offset-prefix support make the
use of that
Hi everyone,
As you all know, it's somewhat annoying when a version bump in a
package such as xorg-server triggers a need to rebuild reverse
dependencies, and it would be really great if we could automate this.
We already have something that's very close to a solution in EAPI 3,
called the
2009-07-05 13:36:24 David Leverton napisał(a):
On Sunday 05 July 2009 03:33:54 Arfrever Frehtes Taifersar Arahesis wrote:
I would like to suggest that values of IUSE_* variables (whose names end
with values of USE_EXPAND variable), after prefixing with lower-cased names
of appropriate
On Sunday 05 July 2009 03:33:54 Arfrever Frehtes Taifersar Arahesis wrote:
I would like to suggest that values of IUSE_* variables (whose names end
with values of USE_EXPAND variable), after prefixing with lower-cased names
of appropriate variables included in USE_EXPAND, should be
On Sun, 5 Jul 2009 04:33:54 +0200
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote:
I would like to suggest that values of IUSE_* variables (whose names
end with values of USE_EXPAND variable), after prefixing with
lower-cased names of appropriate variables included in USE_EXPAND,
I would like to suggest that values of IUSE_* variables (whose names end with
values of USE_EXPAND variable), after prefixing with lower-cased names of
appropriate variables included in USE_EXPAND, should be automatically added
to IUSE variable.
Example:
IUSE=abc
IUSE_LINGUAS=en fr +la pl ru
On Tue, 2009-03-31 at 18:48 +, Ferris McCormick wrote:
On Tue, 2009-03-31 at 19:21 +0200, Christian Faulhammer wrote:
Hi everyone,
with EAPI 3 confusion about what is in which EAPI may increase,
although appendix E of the PMS is quite helpful here. Anyway,
something handy to put
On Wednesday 01 April 2009 11:37:58 Michael Haubenwallner wrote:
On Tue, 2009-03-31 at 18:48 +, Ferris McCormick wrote:
On Tue, 2009-03-31 at 19:21 +0200, Christian Faulhammer wrote:
Hi everyone,
with EAPI 3 confusion about what is in which EAPI may increase,
although appendix E
On Tue, 31 Mar 2009, Christian Faulhammer wrote:
Have a look at URL:http://v-li.de/temp/eapi_cheatsheet.pdf,
print it, fold it and tell me if you like or not (and especially
what exactly).
The Gentoo store should have a coffee mug with this. ;-)
Ulrich
Hi everyone,
with EAPI 3 confusion about what is in which EAPI may increase,
although appendix E of the PMS is quite helpful here. Anyway,
something handy to put on your desk is my little EAPI leaflet which
gives you all important (in my eyes) information in one leaf. Have a
look at
On 00:39 Fri 05 Sep , Zac Medico wrote:
David Leverton wrote:
2008/9/5 Zac Medico [EMAIL PROTECTED]:
Both approaches are essentially equivalent but it's a little simpler
for ebuild writer if they don't have to customize the output file name.
But is it so much simpler as to justify
2008/9/4 Zac Medico [EMAIL PROTECTED]:
* The 'unpack' helper function recognizes ;sf=tbz2 and ;sf=tgz
extensions, for interoperability with gitweb.
* SRC_URI supports a syntax extension which allows customization
of output file names by using a - operator.
Is it useful to have both of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Leverton wrote:
2008/9/4 Zac Medico [EMAIL PROTECTED]:
* The 'unpack' helper function recognizes ;sf=tbz2 and ;sf=tgz
extensions, for interoperability with gitweb.
* SRC_URI supports a syntax extension which allows customization
of
2008/9/5 Zac Medico [EMAIL PROTECTED]:
Both approaches are essentially equivalent but it's a little simpler
for ebuild writer if they don't have to customize the output file name.
But is it so much simpler as to justify adding a special
gitweb-specific hack to the package managers?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Leverton wrote:
2008/9/5 Zac Medico [EMAIL PROTECTED]:
Both approaches are essentially equivalent but it's a little simpler
for ebuild writer if they don't have to customize the output file name.
But is it so much simpler as to justify
On Fri, Sep 05, 2008 at 12:39:16AM -0700, Zac Medico wrote:
David Leverton wrote:
2008/9/5 Zac Medico [EMAIL PROTECTED]:
Both approaches are essentially equivalent but it's a little simpler
for ebuild writer if they don't have to customize the output file name.
But is it so much
On Fri, Sep 5, 2008 at 12:39 AM, Zac Medico [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Leverton wrote:
2008/9/5 Zac Medico [EMAIL PROTECTED]:
Both approaches are essentially equivalent but it's a little simpler
for ebuild writer if they don't have to
On Friday 05 September 2008, Fernando J. Pereda wrote:
On Fri, Sep 05, 2008 at 12:39:16AM -0700, Zac Medico wrote:
David Leverton wrote:
2008/9/5 Zac Medico [EMAIL PROTECTED]:
Both approaches are essentially equivalent but it's a little
simpler for ebuild writer if they don't have to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Buchholz wrote:
How is using the eclass better for bandwidth usage? It won't allow for
mirroring, and all users would have to checkout the repository from one
place. Furthermore, you cannot have (signed) Manifests that allow
integrity
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Buchholz wrote:
How is using the eclass better for bandwidth usage? It won't allow for
mirroring, and all users would have to checkout the repository from one
place. Furthermore, you cannot have (signed) Manifests that allow
integrity
On Friday 05 September 2008, Mike Auty wrote:
From what I understand of the idea, the eclass will just change the
SRC_URI field from the first case (sf=tgz) to the second case (-).
Eclasses have to be sourced before the SRC_URI is determined because
they can already add (and presumably alter)
Alec Warner kirjoitti:
On Fri, Sep 5, 2008 at 12:39 AM, Zac Medico [EMAIL PROTECTED] wrote:
David Leverton wrote:
2008/9/5 Zac Medico [EMAIL PROTECTED]:
Both approaches are essentially equivalent but it's a little simpler
for ebuild writer if they don't have to customize the output file name.
On Friday 05 September 2008 00:58:05 Zac Medico wrote:
* Default phase function implementations for older EAPIs are
accessible via functions having names that start with 'eapi',
followed by the EAPI value.
Based on the lack of use cases or further responses to [1] I would suggest
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
Please review and discuss the following features which are proposed
for inclusion EAPI 2. As mentioned in my previous email [1], in
planning for this EAPI bump, we should strike a balance somewhere
in-between everything that we'd like to
On 08/26/05 Kristian Benoit wrote:
On the EAPI subject Brian just brought back, I had this idea that we
could use the same approch XML took with HTML.
The ebuild could define which EAPI to use, but instead beiing a
version, the EAPI would be an ebuild API definition. The equivalent to
the
On the EAPI subject Brian just brought back, I had this idea that we
could use the same approch XML took with HTML.
The ebuild could define which EAPI to use, but instead beiing a version,
the EAPI would be an ebuild API definition. The equivalent to the XML's
dtd. The ebuild could point to a
On Fri, Aug 26, 2005 at 03:49:35PM -0400, Kristian Benoit wrote:
On the EAPI subject Brian just brought back, I had this idea that we
could use the same approch XML took with HTML.
The ebuild could define which EAPI to use, but instead beiing a version,
the EAPI would be an ebuild API
On Fri, 26 Aug 2005 15:32:42 -0500 Brian Harring [EMAIL PROTECTED]
wrote:
| A) what does xml bring to the table explicitly that is needed?
A cool three letter acronym. Portage is currently lacking in this
department. How are we expected to sell it to enterprise users if it
doesn't use XML?
--
Maybe I'm incorrect, but I believe Kristian was not saying use XML,
but using xml as a comparasison (I know there is a better word.. but
its escaping me... that comparassion thing on the SAT's). He's not
saying to use xml, but in order to extend portage, extend it much like
xml extends html, with
Brian Harring [EMAIL PROTECTED] wrote:
On Fri, Aug 26, 2005 at 03:49:35PM -0400, Kristian Benoit wrote:
[snip]
the EAPI would be an ebuild API definition. The equivalent to the XML's
dtd. The ebuild could point to a directory named
$PORTDIR/eapi/eapi-name/ which would contain a python
On Fri, Aug 26, 2005 at 03:02:13PM -0700, Drake Wyrm wrote:
Brian Harring [EMAIL PROTECTED] wrote:
B) EAPI is pretty much bash env template switching
[snip]
Perhaps the EAPI handling could be implemented using eclasses, rather
than something in the deep, dark, python-based internals.
70 matches
Mail list logo
