Ciaran McCreesh wrote:
On Thu, 26 Feb 2009 20:34:07 +0100
Luca Barbato wrote:
I'm still waiting for you to answer this:
Be specific. Explain how this works when, say, 0.34.4 is current, you
have a 0.34.5_live and 0.34.5 comes out.
being live working as substitute for 0.34.5_preN (
them.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
much had been said probably
because glep-54 has impact to a lesser number of people and thus is less
interesting than the all encompassing glep-55.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Thomas Anderson wrote:
On Wed, Feb 25, 2009 at 04:56:04PM +0100, Luca Barbato wrote:
Yes, it will warn noisily. This is unacceptable, since stable users
will have months and months of noise when new rules come along.
"unacceptable"...
as in "it's ugly to see"...
tting the eapi before sourcing.
real1m10.636s
user0m16.941s
sys 0m0.368s
cold cache, no metadata available
real6m23.106s
user3m32.141s
sys 1m50.855s
with eapitool
real6m26.564s
user3m31.853s
sys 1m50.511s
I'd rather see more people backing their ideas
Ciaran McCreesh wrote:
On Wed, 25 Feb 2009 04:04:46 +0100
Luca Barbato wrote:
given that the simplest thing is hacking ebuild.sh and extract eapi
with a simple C program (you can use pcre or ragel if you want)
exactly before the ebuild source:
That you're bringing ebuild.sh into this
Ciaran McCreesh wrote:
On Tue, 24 Feb 2009 18:16:54 +0100
Luca Barbato wrote:
You're doubling the number of files that have to be read for an
operation that's almost purely i/o bound. On top of that, you're
introducing a whole bunch of disk seeks in what's otherwise a nice
Ryan Hill wrote:
some other random ideas i've seen tossed around:
- #!/bin/env eapi-parser
- split EAPI into EAPI and some separate counter which would only be
incremented on uncompatible changes to the ebuild format
- change .ebuild to .eb
- waffles (sorry, lunchtime)
Yummy!
--
e cache in such format will make portage ignore any
future change.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
that years ago, except it was "well you can't change
global scope behaviour for EAPIs, but just how much more flexibility
than that is needed?".
Given that the fixed header gives you ALL the flexibility. You may give
provision to consider the next bytes as any kind of serializa
Ciaran McCreesh wrote:
On Tue, 24 Feb 2009 17:04:28 +0100
Luca Barbato wrote:
Ciaran McCreesh wrote:
On Tue, 24 Feb 2009 08:08:23 +0100
Uh, your benchmarks are nonsense.
Provide your nonsensical ones.
You're doubling the number of files that have to be read for an
operation that
all things that have been discussed at length
previously. Please either come up with a legitimate technical
objection, or admit that you've seen the light.
the glep doesn't show any of those nor reference to it, as I said
before, do your homework and probably more people will be happier w
Alistair Bush wrote:
Luca Barbato wrote:
Alistair Bush wrote:
I just don't think those numbers tell us anything and that should be
obvious from anyone who has read GLEP 55[1], we ain't really attempting
to solve a problem that exists within the tree currently (well the bash
issue
t extract the eapi, being it in a fixed place, and then do the parse.
- Extracting such information could have different costs depending on
where to place it.
- I started to check if the proposal about having the fixed position as
the end of the filename is really much more viable than havin
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
ow how things like inherit will affect the environment.
And without knowing the EAPI, you don't know which version of inherit to
call.
It it isn't invalid already...
(i hope i have this right. feel free to call me names if i don't)
Names!
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 03:15:03 +0100
Luca Barbato 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 fro
stage sourcing done.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
tion doesn't make it worth the effort and
disruption it would lead.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
examples
Your comments?
I like the idea, not sure if dodoc could take an -r or just accept
automatically directories.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Second step, shortcomings.
Luca Barbato wrote:
main problem:
- have the possibility to track upstream w/out having to take a manual
snapshot of their sources, but having portage automatically fetch them
from their tree.
This issue isn't and shouldn't something that touches di
I hope that is what the various proponents meant with their proposals
and that's clear enough.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
I put in my devspace got in.
If there weren't people quite vocal against -scm the council wouldn't
have been involved.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Ciaran McCreesh wrote:
On Fri, 13 Feb 2009 23:35:34 +0100
Luca Barbato wrote:
Hence -scm...
that cannot do as well for more than a single target w/out using use
flags.
Because it isn't supposed to. Versions and topics are not the same
thing, and treating topics as versions lea
Ciaran McCreesh wrote:
On Fri, 13 Feb 2009 23:17:03 +0100
Luca Barbato wrote:
Ciaran McCreesh wrote:
No, but something can represent the most commonly used models. We
can't do -scm packages for upstreams that do utterly crazy stuff
anyway, so we'll stick to the reasonably sane on
r such task. I checked with zmedico and PROPERTIES
support conditionals so that is the _bare_ minimum to archive the use
case "I want to track a/any number of non version branch of a/any target
source controlled tree from upstream"
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
I moved the discussion on -dev since it should be the right place to
discuss this.
Ciaran McCreesh wrote:
On Fri, 13 Feb 2009 20:33:31 +0100
Luca Barbato wrote:
Ciaran McCreesh wrote:
On Fri, 13 Feb 2009 18:20:34 +0100
Luca Barbato wrote:
Live template provide correct ordering since
erent subthread before
noticing this post:
The simplest method I can think of is:
${PORTDIR}/tags/games/puzzles/ksudoku -> ../../../kde-base/ksudoku
Sounds nice and has the added value to be possible to opt out and to
not hinder who do not care about it.
lu
--
Luca Barbato
Gentoo Counci
-base contains everything comes from the main kde distribution.
What about both ways using symlinks: kde-games/ksudoku -> games-puzzle/ksudoku ?
No symlinks and no aliases please.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
new files in the project, or look at the diffs), or as I
said in 'e)', use some tricks with /etc/portage/bashrc.
That looks interesting.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
, not the
other way around
- you aren't helping me
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
/var/lib/gentoo, so I'd see all
gentoo-related files as
/var/lib/gentoo/eselect
/var/lib/gentoo/enews
/var/lib/gentoo/herdstat/
/var/lib/gentoo/module-rebuild
/var/lib/gentoo/portage
What do you think about?
Looks quite wrong. I'd do /var/lib/gentoo/enews -> /var/lib/enews btw
lu
On 4-12-2008 21:29, Diego 'Flameeyes' Pettenò wrote:
One has to consider people might be using -l for parallel building too,
I'd have it in a separate variable as well, IFF another build system is
as nice as make towards parallel build.
lu
Since I'm planning to revamp the qemu ebuilds and provide a more
flexible way to pick which targets get built since most of the
interesting one are already supported by tcg thus building with gcc4
just fine, I'd merge back softmmu and user and export the available
targets this way.
lu
ny problems with it.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
...
Nothing that couldn't be done using an eclass and a nicer syntax IMHO...
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Zac Medico wrote:
The intention is for PROPERTIES=live to have a relatively pure and
simple meaning.
Ok.
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Andrew D Kirch wrote:
[...patches...]
Common practice is to work with upstream (if alive) and have the patches
merged asap. Nothing _that_ strange IMHO.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
that something like
RESTRICT=constant-sources would be better.
Like I've said before, that particular convention is pretty
worthless in my eyes. I'd much prefer RESTRICT=live-sources if we
want to use a longer name.
Looks fine to me.
--
Luca Barbato
Gentoo Council Member
Gentoo/linux
Christian Birchinger wrote:
But no matter how wrong i think it is, i usualy respect the
upstreams wishes.
If upstream is wrong I think we should help them...
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
ntconfig directly.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
orba/orbit.
gconf is still problematic nonetheless.
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Adam Stylinski wrote:
The intel C Compiler (icc)
icc, xlc, llvm, sunstudio could be interesting fields of discovery.
Which are the pitfalls of using icc?
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing
Łukasz Damentko wrote:
Dear Gentoo Community,
Here are your verified and long-awaited results.
Gentoo Council for term 2008/2009 will be:
Donnie Berkholz (dberkholz)
Mark Loeser (Halcy0n)
Diego Petteno (Flameeyes)
Petteri Raty (Betelgeuse)
Luca Barbato (lu_zero)
Markus Ullmann (Jokey)
Tobias
Tiziano Müller wrote:
What do you think of them?
Both seem good, I'm looking forward to see them completed =)
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
would rather like to have less bugs in their mailbox.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
le have a subprofile with compiler/linker specifics and
move there non sharable stuff and keep base leaner?
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
expect any action from us (the GDP), please
file a bug. We don't read every thread on the -dev ML.
I bugged the releng =)
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
David Leverton wrote:
On Thursday 19 June 2008 10:36:12 Luca Barbato wrote:
1 getting static libraries (pkg-config replaces this use)
Not for library consumers that use libtool but not pkgconfig.
2 load plugins using libtool support
Why only plugins? What's to stop an application
David Leverton wrote:
On Thursday 19 June 2008 08:51:15 Luca Barbato wrote:
We could either pick a week and do a major ebuild update to remove .la
files when unnecessary or just append a notice about revdep rebuild.
How do you decide when they're unnecessary?
.la are used for :
1 ge
o long; are we going to wait forever ? It's probably better
to unmask it or revert the change at this point.
We could either pick a week and do a major ebuild update to remove .la
files when unnecessary or just append a notice about revdep rebuild.
lu
--
Luca Barbato
Gentoo Council Membe
istro. Trollix may be a
good place to start...
Oh look, speaking of agendas
...are you issuing a press release for exherbo?
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Chris Gianelloni wrote:
On Fri, 2008-06-13 at 12:22 +0200, Luca Barbato wrote:
David Leverton wrote:
On Friday 13 June 2008 11:10:46 Nirbheek Chauhan wrote:
Interesting to note, however, that Paludis doesn't accept inline
comments, and this behaviour predates PMS.
There's a reason f
nm and crew, be it a "beta" tag, an obscure feature some
developers may like for tracking live sources (and the user should not
use), possible fut{ure,ile} changes in the ebuild format.
lu - putting in perspective
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
Ryan Hill wrote:
On Sat, 14 Jun 2008 22:16:36 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
Bernd Steinhauser wrote:
Wow, impressive.
Actually, you can't be serious...
I am.
GLEP 54 for quite some time now and it works very well.
adds nothing to - and sets usage as is.
I
late and saving those post install in the vdb should suffice.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Fernando J. Pereda wrote:
On 14 Jun 2008, at 22:18, Luca Barbato wrote:
mainline glibc usually requires you to fix it or the rest of the world...
What?
I experienced that the hard way -_-
(btw they are single packages, emerge =python- works as should)
So what was your proposal all
Fernando J. Pereda wrote:
On 14 Jun 2008, at 20:02, Luca Barbato wrote:
Fernando J. Pereda wrote:
On 14 Jun 2008, at 19:36, Luca Barbato wrote:
Bernd Steinhauser wrote:
With your approach, we would have to fix the version after every
4.1.x release. That sounds awful, tbh. So:
No that
And that includes the ordering.
No.
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Fernando J. Pereda wrote:
On 14 Jun 2008, at 19:36, Luca Barbato wrote:
Bernd Steinhauser wrote:
With your approach, we would have to fix the version after every
4.1.x release. That sounds awful, tbh. So:
No that enforce people update the deps or at least gives one more
reason to do. Keep
I have got a feeling, that you didn't have to deal with live packages
that much yet. (No offense.)
Beside e17 and ffmpeg you mean?
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Ryan Hill wrote:
On Sat, 14 Jun 2008 17:55:27 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
Ryan Hill wrote:
So every user will have a different _preN version which would vary
depending on how often they rebuild the package and that has
absolutely no correlation with the revision num
user option, if the pkg_scm_info value hasn't changed and it's a
reinstall, skip reinstalling.
* At user option, and not by default, do the fetch / info stage
*before* showing the "this is what we'll install" list.
Sounds quite interesting.
--
Luca Barbato
Gentoo Council
Fernando J. Pereda wrote:
nope it would resolve as foo_pre1 -> meaningless.
So your proposal is unable to handle that case, right?
You are forced to put a version, that's all.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
ge
has been released)
correct, you can keep tracking 4.1.1, have interim snapshot pushed in
portage to ~ if you are confident about them.
4.1 branch = 4.1.2.live (before 4.1.2 has been released)
4.1 branch = 4.1.3.live (before 4.1.3 has been released)
same reasoning.
lu
--
Luca Barbato
eed to fill a
bugreport.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
ble, I think my proposal nicer and
giving some value for the effort of implementing it, -scm adds a some
work to do with undefined features at best.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
of the bleeding edge you
acknowledge that you are experimenting.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Ciaran McCreesh wrote:
On Sat, 14 Jun 2008 14:27:22 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
Many of them applies as well to the alternative proposal, I wonder
how you could say we, council, had to vote the other proposal given
such (and other) issues were open.
No they don'
ternative tests that allow testing for dropped
keywords or for the existence of keywords just for "live" ebuilds.
Agreed.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Santiago M. Mola wrote:
On Sat, Jun 14, 2008 at 10:19 AM, Luca Barbato <[EMAIL PROTECTED]> wrote:
Ryan Hill wrote:
I'm guessing the dev would need to change 0.26.live to 0.26.1.live when
0.26 was released. I already need to do this with my live ebuilds. Of
course, with some p
ssues were open.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Ciaran McCreesh wrote:
On Sat, 14 Jun 2008 12:04:45 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
It will be available once you trigger again the generation or if
you put a normal ebuild with such name.
And what triggers said generation?
I already replied in this thread, I gue
Ciaran McCreesh wrote:
On Sat, 14 Jun 2008 11:53:51 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
Ciaran McCreesh wrote:
On Sat, 14 Jun 2008 10:19:32 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
I'm confused. If I have a gcc-4.4.0.live ebuild which checks out
rev. 136737, a
Ciaran McCreesh wrote:
On Sat, 14 Jun 2008 10:19:32 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
I'm confused. If I have a gcc-4.4.0.live ebuild which checks out
rev. 136737, after the merge do I have gcc-4.4.0_pre136737
or gcc-4.4.0_pre1 (and gcc-4.4.0_pre2 next time I me
the CPV vs. atom issue.
Hmm, give me more informations about your concern.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
in mind that even trunk changes enough that you need to
update the ebuild thus makes sense use a next supposed version.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
, is how such a scheme would
work for non integer based revnos- git for example, which is reliant
on a hash (just the hash, afaik).
The revision has to be stored inside the generated ebuild so all you
need to have is:
- a way to know the revision you are checking out
- a way to store such
Tiziano Müller wrote:
Luca Barbato wrote:
Tiziano Müller wrote:
@lu_zero: I don't think we can get away without having the pm know what a
live-ebuild exactly is and when to re-install it.
a live ebuild is a template, every time it has to be evaluated it acts
as a normal ebuild wit
f allowing them in PMS or not, therefore PMS doesn't allow
them. There's no evil conspiracy here, just pure logic.
Care to share the logic and wise reasoning ?
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
preN is the highest preN present, if present.
(Just in case you were thinking of letting the pm auto-masking/unmasking
foo_p${value+1}: this would be hackish and ugly).
Uh?
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gento
Ciaran McCreesh wrote:
On Thu, 12 Jun 2008 21:40:28 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
* ordering for _pre is wrong.
hm?
foo-0.26-live would become foo-0.26_pre1, which would be < 0.26. This
is clearly wrong.
No, it is correct and what you want. Upstream is aiming for 0
recommendations at best.
You are right.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
d party and possibly have a regression/conformance test built
in (such a small tree with dummy ebuilds and eclasses) to allow
automated validation. Stronger and well defined versioning should help
as well.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.or
Ciaran McCreesh wrote:
On Thu, 12 Jun 2008 11:05:01 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
Just for fun I took some of the ideas about alternative management of
the issue and specified the features it makes it worth changing
(better management and automated snapshot generation fr
(better
management and automated snapshot generation from the live ebuild).
http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst
I'd like to see some comment on it (I put it in glep form just now so it
isn't exactly perfect)
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gento
rtage and pkgcore developers are
complaining about eapi definition and PMS management.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
noring the EAPI process.
The eapi process is something not defined so they cannot do much about
it, same for the portage people.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
iving substance to your claims.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
e a large
field to cover but you also do not know the bounds of it.
It really doesn't matter how it is specified. You have an implementation
of it and should make sure, that this implementation works.
Seems to works well enough for people using it.
lu
--
Luca Barbato
Gentoo Council Membe
ople release a package manager that claims to support a certain EAPI
but doesn't. If pkgcore had any actual users we'd have to consider
banning EAPI 1 in the tree and releasing EAPI 2 as being identical to
EAPI 1 just to work around this.
Apparently those users do not see the problem, you
Bernd Steinhauser wrote:
Luca Barbato schrieb:
Ciaran McCreesh wrote:
The point is to make pkgcore a better package manager by getting the
developers to do some basic testing. We're not talking some obscure,
weird bug here. We're talking a really obvious, major screwup that a
coupl
for them and let people do the automated
test for them.
- having that mandated by the eapi doesn't have sense since it doesn't
change anything by itself.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
No, you aren't talking, you are babbling about undefined flaws that
nobody can evaluate, for which you aren't providing a way to reproduce
it and possibly doesn't exist.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
ge
Ciaran McCreesh wrote:
http://en.wikipedia.org/wiki/Straw_man
http://en.wikipedia.org/wiki/Quote_mining
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
s got them used by the people that cares already.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Ciaran McCreesh wrote:
On Wed, 11 Jun 2008 08:57:35 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
Ciaran McCreesh wrote:
You assume that users have working, properly configured compilers.
It's fairly well established that a lot of them don't, particularly
on Gentoo.
"if
Ciaran McCreesh wrote:
You assume that users have working, properly configured compilers. It's
fairly well established that a lot of them don't, particularly on
Gentoo.
"if your code sucks isn't our fault." - gcc upstream
--
Luca Barbato
Gentoo Council Member
Gen
more importantly, it still means that people *know* that a failing
src_test is to be investigated. Currently they instead have to guess
whether it's a lazy developer issue or a genuine bug being shown.
Not really.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.
Ciaran McCreesh wrote:
On Wed, 11 Jun 2008 07:53:21 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
A whole bunch of science packages have upstreams that say "If you're
building from source, run 'make check' and if it fails don't carry
on".
Their rationa
301 - 400 of 757 matches
Mail list logo