What is proposed in glep-55 seems to aim to solve both issues at the
same time (it isn't stated) by switching file extension every time the
eapi is changed. This is slightly against the principle of the least
surprise and apparently is disliked by enough people to lead the
situation to
On Mon, Feb 23, 2009 at 09:38:06AM +0100, Tiziano M??ller wrote:
What is proposed in glep-55 seems to aim to solve both issues at the
same time (it isn't stated) by switching file extension every time the
eapi is changed. This is slightly against the principle of the least
surprise and
Tiziano Müller wrote:
What is proposed in glep-55 seems to aim to solve both issues at the
same time (it isn't stated) by switching file extension every time the
eapi is changed. This is slightly against the principle of the least
surprise and apparently is disliked by enough people to
Am Montag, den 23.02.2009, 22:25 +1300 schrieb Alistair Bush:
Tiziano Müller wrote:
What is proposed in glep-55 seems to aim to solve both issues at the
same time (it isn't stated) by switching file extension every time the
eapi is changed. This is slightly against the principle of the
On Mon, Feb 23, 2009 at 7:02 PM, Tiziano Müller dev-z...@gentoo.org wrote:
Am Montag, den 23.02.2009, 22:25 +1300 schrieb Alistair Bush:
Tiziano Müller wrote:
What is proposed in glep-55 seems to aim to solve both issues at the
same time (it isn't stated) by switching file extension every
On Mon, Feb 23, 2009 at 07:28:00PM +0900, Douglas Anderson wrote:
On Mon, Feb 23, 2009 at 7:02 PM, Tiziano Müller dev-z...@gentoo.org wrote:
Am Montag, den 23.02.2009, 22:25 +1300 schrieb Alistair Bush:
Tiziano Müller wrote:
What is proposed in glep-55 seems to aim to solve both issues
Tiziano Müller wrote:
What is proposed in glep-55 seems to aim to solve both issues at the
same time (it isn't stated) by switching file extension every time the
eapi is changed. This is slightly against the principle of the least
surprise and apparently is disliked by enough people to lead
On Mon, Feb 23, 2009 at 02:21:33PM +0100, Luca Barbato wrote:
Tiziano M??ller wrote:
What is proposed in glep-55 seems to aim to solve both issues at the same
time (it isn't stated) by switching file extension every time the eapi is
changed. This is slightly against the principle of the
Brian Harring ferri...@gmail.com posted 20090223085232.ga6...@hrair,
excerpted below, on Mon, 23 Feb 2009 00:52:32 -0800:
On Mon, Feb 23, 2009 at 09:38:06AM +0100, Tiziano M??ller wrote:
[quoting...]
What is proposed in glep-55 seems to aim to solve both issues at the
same time (it isn't
On Mon, 23 Feb 2009 04:26:49 -0800
Brian Harring ferri...@gmail.com wrote:
There also is the angle that deploying g55 requires waiting at least
a full stage release (~year, at least by the old standards) to ensure
people aren't screwed by the repository changing formats
(unversioned!) under
See the patch.
--
cd /local/pub more beer /dev/mouth
--- generation1-deprecation.orig2009-02-23 14:50:37.920591164 +0100
+++ generation1-deprecation 2009-02-23 14:51:25.180617090 +0100
@@ -21,9 +21,9 @@
emerge -av --depclean virtual/jdk:1.4
-If don't need virtual/jdk:1.4 any
On Mon, 23 Feb 2009 03:15:03 +0100
Luca Barbato lu_z...@gentoo.org wrote:
Let's try to start with a common workflow for the user:
- an user with an ancient version of portage syncs
- it requires a package
- it looks at the cache ($portdir/metadata/cache/)
- picks the best entry from the ones
On Mon, Feb 23, 2009 at 01:50:10PM +, Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 04:26:49 -0800
Brian Harring ferri...@gmail.com wrote:
There also is the angle that deploying g55 requires waiting at least
a full stage release (~year, at least by the old standards) to ensure
people
On Mon, 23 Feb 2009 06:15:25 -0800
Brian Harring ferri...@gmail.com wrote:
No it doesn't. It's transparent to users using an older package
manager.
Would be useful if someone pulled older portage versions and checked
exactly what they do in this case- explode, behave, etc (manifest
Douglas Anderson wrote:
No one wants to be working with ebuild-29 or something like that in a
few years and trying to figure out which feature came in which EAPI.
Instead of bumping EAPI for each little change, save them up and bump
no more than once a year or less, each bump bringing in some
On Mon, 23 Feb 2009 09:28:06 -0500
Richard Freeman ri...@gentoo.org wrote:
I got the impression that if anything there is a desire to allow
EAPIs to change more offen, and not less. And these changes could
become more dramatic.
But we're still only talking maybe three new EAPIs a year.
Also
Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 03:15:03 +0100
Luca Barbato lu_z...@gentoo.org wrote:
Let's try to start with a common workflow for the user:
- an user with an ancient version of portage syncs
- it requires a package
- it looks at the cache ($portdir/metadata/cache/)
- picks the best
On Mon, 23 Feb 2009 15:46:24 +0100
Luca Barbato lu_z...@gentoo.org wrote:
Apparently we do not have any issue...
...assuming the metadata cache is valid. That isn't always the case.
When it isn't?
Every now and again (probably after someone changes eutils...), rsync
mirrors end up
Richard Freeman wrote:
I still don't see why we need to be encoding metadata in filenames. PERL
doesn't care what a file extension is, python doesn't care, bzip2
doesn't care, tar doesn't care, gzip doesn't care, and even ld-linux.so
doesn't care. I'm sure that in at least some of these cases
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mounir Lamouri wrote:
Hi,
I was writing a trivial version bump for net-voip/gnugk-2.2.8 (bug
#258518) but upstream added a file named p2pnat_license.txt (see
http://dpaste.com/123376/) This file looks to authorize gnugk project
(and users) to
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Plus, I don't really grasp the whole we have to source the whole
ebuild to know the EAPI version argument. It's one variable, in one
line. Can't a simple parser get that and go from there?
Not true. This is entirely
On Mon, Feb 23, 2009 at 10:44 AM, Marijn Schouten (hkBst)
hk...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mounir Lamouri wrote:
Hi,
I was writing a trivial version bump for net-voip/gnugk-2.2.8 (bug
#258518) but upstream added a file named p2pnat_license.txt (see
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Plus, I don't really grasp the whole we have to source the whole
ebuild to know the EAPI version argument. It's one variable, in one
line. Can't a simple parser get that and go from there?
The problem is that its
On Mon, 23 Feb 2009 17:06:17 +0100
Peter Alfredsen loki_...@gentoo.org wrote:
To be honest I see no good reason for allowing manipulation of it, but
I'm sure other people will tell me why adding this requirement at this
point is wrong
There's not really a good reason to allow manipulating it
On Mon, 23 Feb 2009 15:53:20 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Plus, I don't really grasp the whole we have to source the whole
ebuild to know the EAPI version argument. It's one variable, in
On Mon, 23 Feb 2009 17:13:16 +0100
Alexis Ballier aball...@gentoo.org wrote:
Which begs the question: is it really worth allowing it?
If we only allow constant assignments (which is an implicit
restriction in the file extension version) then this can be parsed
easily with grep/tr/awk/etc and
On Mon, 23 Feb 2009 16:19:56 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Mon, 23 Feb 2009 17:13:16 +0100
Alexis Ballier aball...@gentoo.org wrote:
Which begs the question: is it really worth allowing it?
If we only allow constant assignments (which is an implicit
On Mon, 23 Feb 2009 17:48:27 +0100
Alexis Ballier aball...@gentoo.org wrote:
...and then we have to do the whole thing again every time something
new crops up.
Please give an example because I fail to see how.
New version suffix rules. New bash versions. New package naming rules.
Partially
On Mon, Feb 23, 2009 at 7:53 AM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Plus, I don't really grasp the whole we have to source the whole
ebuild to know the EAPI version argument. It's one variable, in one
On Mon, 23 Feb 2009 11:02:17 -0800
Alec Warner anta...@gentoo.org wrote:
In foo.eclass:
EAPI=3
This is not legal, the devmanual[1] explicitly states that it is not
legal to set EAPI in an eclass.
That's purely a QA thing, and it only applies to repositories that
follow Gentoo's QA
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Richard Freeman wrote:
I still don't see why we need to be encoding metadata in filenames.
PERL doesn't care what a file extension is, python doesn't care,
bzip2 doesn't care, tar doesn't care, gzip doesn't care, and
Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 17:48:27 +0100
Alexis Ballier aball...@gentoo.org wrote:
...and then we have to do the whole thing again every time something
new crops up.
Please give an example because I fail to see how.
New version suffix rules. New bash versions. New package
On Mon, 23 Feb 2009 21:30:04 +0200
Petteri Räty betelge...@gentoo.org wrote:
And we'd be starting on the next batch of oh, we need to wait
another year. Had GLEP 55's necessity been accepted a year ago,
we'd have a whole bunch of requested features implemented by now.
I doubt Portage
Hi,
Ulrich Mueller u...@gentoo.org:
On Fri, 20 Feb 2009, Christian Faulhammer wrote:
$ time (bzr diff --old lp:bzr-gentoo-overlay \
--new /media/disk/bzr-overlay/|diffstat)
real0m50.088s
This is prohibitive. Drop it completely, or enable it only if some
environment
Hi,
René 'Necoro' Neumann li...@necoro.eu:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jorge Manuel B. S. Vicetto schrieb:
Hi.
Christian Faulhammer wrote:
Hi,
a user maintained a Bazaar overlay for some time now and introduced
some changes to bzr eclass, I would like to
Ryan Hill wrote:
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Richard Freeman wrote:
I still don't see why we need to be encoding metadata in filenames.
PERL doesn't care what a file extension is, python doesn't care,
bzip2 doesn't care, tar doesn't care, gzip
On Mon, 23 Feb 2009 21:51:11 +0100
Luca Barbato lu_z...@gentoo.org wrote:
2. (with myeclass.eclass containing EAPI=2)
-
EAPI=1
inherit myeclass
Invalid
QA violation, but legal and a pain in the ass.
3. (with myeclass.eclass containing EAPI=2)
-
EAPI=5
inherit myeclass
On Mon, 23 Feb 2009 20:54:38 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Mon, 23 Feb 2009 21:51:11 +0100
Luca Barbato lu_z...@gentoo.org wrote:
2. (with myeclass.eclass containing EAPI=2)
-
EAPI=1
inherit myeclass
Invalid
QA violation, but legal and a
On Mon, 23 Feb 2009 16:15:25 -0600
Ryan Hill dirtye...@gentoo.org wrote:
Can we ban eclasses from setting EAPI? Is there any case where it
would be sane?
It's already banned from a QA perspective, but from a package manager
perspective people have done it in the past and possibly still do do
On Mon, 23 Feb 2009 16:15:25 -0600
Ryan Hill dirtye...@gentoo.org wrote:
On Mon, 23 Feb 2009 20:54:38 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Mon, 23 Feb 2009 21:51:11 +0100
Luca Barbato lu_z...@gentoo.org wrote:
2. (with myeclass.eclass containing EAPI=2)
server15
custom-cflags 10
logrotate 9
gsm 9
semantic-desktop 9
webkit8
html 7
multislot 7
nautilus 7
Markus Meier mae...@gentoo.org writes:
semantic-desktop: Semantic desktop allows for storage of digital
information and its metadata to allow the user to express his personal
mental models, making all in formation become intuitively accessible
I find this description pretty content-free and
Ryan Hill wrote:
Richard Freeman wrote:
I'm
actually hard pressed to think of any unix-based software that uses
the filename to store a mandatory file format versioning specifier
of some kind.
$ ls /usr/lib
I was referring to a file FORMAT versioning scheme - not a file CONTENT
versioning
On Mon, 23 Feb 2009 18:47:07 -0500
Richard Freeman ri...@gentoo.org wrote:
It seems like we could be up to ebuild-kde4-3.2 in six months.
Why on earth do people think that? Of all the crazy being thrown
around, this is the only one wearing a tutu.
--
Ciaran McCreesh
signature.asc
Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 18:47:07 -0500
Richard Freeman ri...@gentoo.org wrote:
It seems like we could be up to ebuild-kde4-3.2 in six months.
Why on earth do people think that? Of all the crazy being thrown
around, this is the only one wearing a tutu.
I suppose I'm
On Mon, 23 Feb 2009 19:17:19 -0500
Richard Freeman ri...@gentoo.org wrote:
It just seems like it isn't the best solution. You can get the same
effect by just sticking something in a comment line a few lines into
the ebuild in a fixed position.
No you can't. It doesn't work with existing
Alistair Bush ali_b...@gentoo.org wrote:
Tiziano Müller wrote:
Instead of switching file extension every time the eapi is changed
you could also increment it only when a new EAPI breaks sourcing
the ebuild compared to the requirements of the prior EAPI.
(This way you'd in fact split EAPI
Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 19:17:19 -0500
Richard Freeman ri...@gentoo.org wrote:
It just seems like it isn't the best solution. You can get the same
effect by just sticking something in a comment line a few lines into
the ebuild in a fixed position.
No you can't. It doesn't
On Tue, Feb 24, 2009 at 4:52 AM, Josh Sled js...@asynchronous.org wrote:
(Also, I note in passing the existing kde-base/pykde4 use.local.desc has
a tyop of Nemomuk.)
Oh, sweet irony :)
--
~Nirbheek Chauhan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Josh Sled wrote:
Markus Meier mae...@gentoo.org writes:
semantic-desktop: Semantic desktop allows for storage of digital
information and its metadata to allow the user to express his personal
mental models, making all in formation become
On Tuesday 24 of February 2009 00:22:39 Josh Sled wrote:
To that end, please allow me to suggest:
Cross-KDE support for file metadata indexing via nepomuk and soprano.
If you don't want to couple the message to those particular packages,
then maybe just reference the NEPOMUK project instead.
On Sunday 22 February 2009 18:03:23 Dawid Węgliński wrote:
On Sunday 22 of February 2009 23:39:11 Mike Frysinger wrote:
On Sunday 22 February 2009 17:30:09 Dawid Węgliński wrote:
On Sunday 22 of February 2009 00:27:10 Mike Frysinger wrote:
looks like bash-4.0 has broken semicolon
I was looking to do a workaround on a per compiler basis.
I'm looking at toolchain-funcs.eclass, and specifically
${gcc-fullversion}. I've got a broken ebuild (dhcdbd) which requires
-U_FORTIFY_SOURCE to compile correctly with GCC 4.3.3. But reading
tells me that I should not use this eclass to
Luca Barbato wrote:
Ciaran McCreesh wrote:
Because your proposal addresses none of the underlying problems which
GLEP 55 was created to solve.
let's get some numbers to have an idea of the dimension of the problem.
domino portage # wc -l /dev/shm/eapi_files.list
2854 /dev/shm/eapi_files.list
On Tuesday 24 February 2009 00:57:25 Andrew D Kirch wrote:
I was looking to do a workaround on a per compiler basis.
I'm looking at toolchain-funcs.eclass, and specifically
${gcc-fullversion}. I've got a broken ebuild (dhcdbd) which requires
-U_FORTIFY_SOURCE to compile correctly with GCC
55 matches
Mail list logo
