On Wed, 11 Jun 2008 08:01:30 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Wed, 11 Jun 2008 07:49:44 +0200
> > Alexis Ballier <[EMAIL PROTECTED]> wrote:
> >> I thought tests were already supposed to pass whatever the EAPI is
>
kgcore.org/trac/pkgcore/ticket/197
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 11 Jun 2008 08:31:45 +0200
Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote:
> On 2008/06/11, Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> > You're missing the cases where the cache isn't usable.
>
> I was not talking about generating cache
code
> being wrong most of the times.
If you have bad code, yes. If you have good code, instead it's usually
gcc's fault. Things like gcc bug 31899 are common enough to be a
nuisance.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
a genuine bug being
> > shown.
>
> Not really.
Ok, if EAPI 2 turns on src_test except where explicitly overridden by
the ebuild, explain how EAPI 2 src_test failures are meaningless in the
same way that EAPI 0/1 src_test failures are.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
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.
>
On Wed, 11 Jun 2008 09:14:03 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> 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 wo
On Wed, 11 Jun 2008 09:18:07 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > Ok, if EAPI 2 turns on src_test except where explicitly overridden
> > by the ebuild, explain how EAPI 2 src_test failures are meaningless
> > in the same way that EAP
27;s not, but what's the problem to change
> extension once only for this change?
It means next time we want to introduce another backward incompatible
change, we have to go through the whole mess all over again.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 11 Jun 2008 06:55:45 -0400
Richard Freeman <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Wed, 11 Jun 2008 08:02:48 +0200
> > Luca Barbato <[EMAIL PROTECTED]> wrote:
> >>> Had you bothered to write even trivial test suites for EAPI 1,
>
an't understand why shifting 0.006 to equivalent to 0.6, then
> frankly, this discussion need not continue.
http://en.wikipedia.org/wiki/Straw_man
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ual 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.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 11 Jun 2008 15:05:47 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > EAPI 1 is entirely specified in terms of a diff against EAPI 0.
>
> That doesn't have a complete definition by itself.
It's more than enough to write unit
fidence in Paludis contributors' (including
myself) abilities to write perfect code the first time that I let
changes go through without testing to ensure that they work.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ing KDE, since that's
big and slow, and starting backwards since the x11- categories are nice
and pretty).
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ards since the x11-
> > categories are nice and pretty).
> >
> I did. Can't reproduce. Go away.
Then you should probably see a doctor. Also, you should really check
your results a lot more carefully -- perhaps there's also a bug in your
build tool that makes it not recognise
why they should be
allowed to continue keeping a package in the tree when they're
blatantly ignoring the EAPI process.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
iming support for a new EAPI has very messy consequences. If package
manager maintainers aren't going to do the responsible thing, the whole
point of EAPIs is lost.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Thu, 12 Jun 2008 10:12:47 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > Package manager maintainers refusing to do basic testing before
> > claiming support for a new EAPI has very messy consequences. If
> > package manager maintai
On Thu, 12 Jun 2008 10:24:14 +0200
"Denis Dupeyron" <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 10:16 AM, Ciaran McCreesh
> <[EMAIL PROTECTED]> wrote:
> > Are you seriously suggesting that the portage and pkgcore developers
> > think that they sho
major no-no' by refusing to do basic
testing, and the fact that you're trying so hard to make it look like
someone else's fault is pretty fricking sad.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
lways reinstall live things? Never? Or what?
* How are live ebuilds selected by the package manager?
* What's the filename for "live ebuild for SVN trunk/"? What about
"live ebuild for SVN branches/0.26/"?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
> TeX isnt a format that integrates with Gentoo. should just convert
> it to docbook and be done with this garbage.
And docbook does integrate with Gentoo? Please point me to other Gentoo
documentation that uses docbook.
Also, I've yet to be told how to get automatic, verified,
zer
n't see that getting very far... If a third party's genuinely
prepared to take over and do the work they're more than welcome to.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
it for some reason and no-one working on
PMS appears to have commit access to it...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ok
> > or guidexml. Perhaps you'd care to explain.
>
> You've mentioned this as a requirement. Is it something that happens
> so often that it's a significant burden if it isn't available?
Yes.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
red by spb's
> retirement.
What, going around removing authors' names is 'a legitimate status
update'?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
do basic automated
tests is completely beyond me.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
>
> foo-0.26.live?
Orders incorrectly when 0.26.1 has been released.
> What is inside the template is just concern of the ebuild writer. I
> suggest to use the same version as marked in the configure or other
> version value the release will get once upstream decides to release.
nit tests to cover
the rest of EAPI 1 functionality.
There is a big difference between obscure bugs and blatant
irresponsibility here.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 13 Jun 2008 10:43:39 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Thu, 12 Jun 2008 21:40:28 +0200
> > Luca Barbato <[EMAIL PROTECTED]> wrote:
> >>> * ordering for _pre is wrong.
> >> hm?
> >
> &
and PMS restricts profile use files to behaviour safely
supported by all EAPI 0 accepting Portage versions.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
3 (from a live
ebuild) would incorrectly order less than foo-1.2_p20080613 (from a
manual snapshot).
--
Ciaran McCreesh
signature.asc
Description: PGP signature
rather than
writing junk, as older Portage did) when inline comments are used.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ou
suggesting that we should instead ignore what EAPI-0-supporting Portage
does and does not handle and just document things the way we'd like
them to be?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 13 Jun 2008 15:40:46 +0530
"Nirbheek Chauhan" <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 13, 2008 at 2:52 PM, Ciaran McCreesh
> <[EMAIL PROTECTED]> wrote:
> >> And why don't y'all fix a bug like that?
> >
> > We do what PMS requi
ally we'll have to consider Portage to have bugs."
> PS: An example of something in PMS that is different from Portage:
> inline comments are disallowed. The only reason I can think for doing
> this is to not make Paludis change it's behaviour.
Did you check whether Portage
gt; time" or "The intersection of the capabilities of Portage and
> Paludis". It should follow the current portage's behaviour as closely
> as possible.
Do you really want to make it impossible to install Gentoo using the
most recent official release? Because that's what will happen if we do
what you're suggesting...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
verable and useful
in a relatively short timeframe, but extending it to upstream-revision
awareness isn't.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
- a way of doing this cheaply so resolution doesn't take half an hour
when you have kde-scm installed.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
merge it, etc)
> > installed?
>
> it would be gcc-4.4.0_pre1 but you'll have the revision inside the
> ebuild as var so you can get it easily. (e.g. the description shows
> it)
And when would gcc-4.4.0_pre2 become available?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
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
start, work
out use cases, package manager interactions, how if at all ebuilds will
need to be adapted and several examples. There's a big difference
between a few vague ideas and the foundations for an implementable
proposal.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
x27; and doing the right thing.
The answers to all of the above are highly non-trivial.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ernative proposal is deliberately simple enough
to avoid those issues, whilst leaving the possibility of a larger
solution that does have scm revision awareness open for the future.
Does this mean you don't have answers then?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sat, 14 Jun 2008 15:15:45 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> 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
> &
On Sat, 14 Jun 2008 15:25:53 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > * What generation looks like.
>
> Mostly implementation detail? Somebody seems to have ideas there and
> I like to heard ideas from others as well.
It's not a det
On Sat, 14 Jun 2008 15:29:00 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > Which of the issues I listed needs to be addressed for the scm
> > proposal?
>
> At least the upstream server load.
-scm doesn't attempt to use upstream to obt
t the changes...
This is an EAPI scope change, if anything. Although even then the
implications are a bit messy since you're talking the interaction of
two different EAPIs.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ns. That can be done later by building upon
GLEP 54.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
src_fetch_extra then pkg_scm_info.
At 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.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
I suspect CVS is in
this boat, if anyone's still using it...
For subversion and git, this has the added devious advantage of making
the revision / ID easily visible.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
rejected and the proportion
of patches from 'Portage people' or 'Pkgcore people' indicates a
problem?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
oo - became active
> developer. In this case you have to became active portage developer.
Most of the difficult bits of PMS have an awful lot to do with ebuilds
and very little to do with Portage. The Portage developer is more
interested in doing other things, and there's no reason to hold PMS up
until another person can be given the "Portage developer" label.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
stalled
appears to be the sensible behaviour there, not going off when the last
attempt at installing the package was.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
hing between a c/p and a c/p-v,
which is why you have to use the =. GLEP 54 does not change that.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ee the userrel team is active. Will you be looking at bug
228321 sometime soon please?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
#x27;t ever be.
And in amongst all of this, if you fight really really hard, you might,
after several months and a whole lot of people trying to kill you,
eventually get agreement upon some very minor technical point that's
necessary to start getting somewhere. Which is a shame, because Gentoo
could quite easily become a lot better than it is.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Thu, 19 Jun 2008 22:48:02 +
"Jorge Manuel B. S. Vicetto" <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> | On Fri, 20 Jun 2008 00:17:56 +0400
> | * have some insane paranoid conviction that Freenode staff are the
> | ones busy spying on everything t
vironment is a large part of Gentoo's problem. The focus needs
to be taken away from the 'community' (where community means a bunch of
Ubuntu users who make lots of noise on the forums) and put back into
delivering a decent distribution.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 20 Jun 2008 01:11:18 +0200
> Ciaran McCreesh wrote:
> > On Thu, 19 Jun 2008 23:42:51 +0100
> > Mike Auty <[EMAIL PROTECTED]> wrote:
> >
> >> And yet still you keep fighting? Why?
> >
> > Because unlike pretty much everyone else around
he chance
> to learn, improve and help out where they can", you want everybody to
> be 100% proficient.
No, I want people to be reasonably proficient, and to be honest and ask
when they're not.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
pm which slot
> has been used.
The only sensible thing you can do with multiple matches on := slots
(and ||=, if that route is taken) is to take the slot of the best
matching installed version, and require that ebuilds do that too. In
real world cases, this works just fine.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
if
you have to pass a version manually to a package, best_version is the
way to do it.
And no, that's not something that should be in the spec. The devmanual,
perhaps, although there's no kdebuild stuff in there just now.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
a bump.
Ever tried git on an ebuild repository? Ebuilds are sufficiently
similar to each other that it quite often gets this horribly wrong. And
to make matters worse, there's no way of overriding it when it does.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
understand?
Do you seriously consider not being able to add or change global scope
functions in future EAPIs to be a non-issue, or were you ignoring those
two bullet points?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
rrectly, or the death of
EXPORT_FUNCTIONS? All of these have been discussed as desirable future
extensions.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ot at the previous meeting.
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-libs/glibc/files/eblits/
I presume you're aware of that. People are already doing those other
things, and doing them badly, because there's currently no other option.
This isn't some hypothetical future r
On Mon, 14 Jul 2008 03:13:44 +0200
Jeroen Roovers <[EMAIL PROTECTED]> wrote:
> On Mon, 14 Jul 2008 00:43:06 +0100
> Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> > People are already doing those other things, and doing them badly,
> > because there's current
that indicate be a
> non-trivial increase in the number of files in the tree - files which
> would address the equal purpose of installing exactly one
> =cat/pkg-ver.
GLEP 55 does not change the EAPI process from a maintainer perspective,
except that it replaces "set EAPI=X in the ebuild" with "use .ebuild-X".
> In other words, disregarding its other real world deficiencies like an
> immediate goal, GLEP 55 fails to describe a keywording policy for
> architecture developers and it fails to describe a "build file"
> addition (bump) policy for package maintainers.
There *is* no change there.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
isted, the
> GLEP is not of much use.
So you're saying the GLEP's of no use until Portage supports them, but
Portage can't support them until you say yes to the GLEP...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
approve both at the same time or
> have other official package managers approved before accepting the
> GLEP.
Why? We know it's a not-too-distant future need. Might as well get it
out of the way now so there isn't more than an hour's worth of stuff
all needing to be approved at the
st might already have some items on it - so why
> not document them?
The GLEP already documents what needs it, in the broadest reasonable
terms. The problem with specifics is that everyone will then start
arguing about how exactly, say, per-cat/pkg eclasses would work, which
is irrelevant to the GL
.
For current EAPIs it's no worse than the existing situation, where
ebuilds have to guess that package managers use 'app-arch/unzip' to
unpack zip files.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
e.
>
> Wouldn't this also require having a variable like SRC_URI or
> AUTODEP_SRC_URI above inherit?
Yep. Although, you could do something like:
inherit normal-eclass-stuff
SRC_URI="blah"
inherit fancy-extra-eclass-stuff
--
Ciaran McCreesh
signature.asc
Description: PGP signature
c will be wrong. For example, packages that have
a .zip file in SRC_URI but that don't unpack that file (say, if they
install it into sharedir as-is instead) don't need a dep upon unzip.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
he package manager depend upon things like 7z for the two
packages in the tree that use it isn't sane.
One could argue that having package manager support for extracting 7z
is also not sane, of course, but that's something we're stuck with in
current EAPIs.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
it'll generate invalid output if SRC_URI is invalid (for
example, if SRC_URI has mismatched parens, the output will too), but I
can't think of any situation where breaking DEPEND if SRC_URI is
already broken is a problem.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
; do
UNPACK_DEPENDS=" ${UNPACK_DEPENDS} "
u="${UNPACK_DEPENDS}"
UNPACK_DEPENDS="${UNPACK_DEPENDS//?(+( )+([^ ])\?)+( )(+( ))+( )/ }"
[[ "$u" == "${UNPACK_DEPENDS}" ]] && break
done
Although... Allowing ( ) makes much more sense...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
lever things with icc
anyway. What about normal users?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 18 Jul 2008 15:34:53 -0400
Richard Freeman <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > The more interesting question, then, is whether users run any
> > non-trivial cpu-bound programs. We know the applied science types
> > do, but they tend to be t
On Sun, 20 Jul 2008 17:38:32 +0400
Peter Volkov <[EMAIL PROTECTED]> wrote:
> В Вск, 13/07/2008 в 23:52 +0100, Ciaran McCreesh пишет:
> > Which part of the 'Problem' section in the GLEP didn't you
> > understand? Do you seriously consider not being able to add
ions when libraries aren't slotted properly you have to
rebuild a few more things.
Rather a large difference in impact there...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
nothing wrong with
making the changes, it's not exactly the most productive use of limited
resources...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
these is a
ricer" category. Unfortunately, the misguided promotion of 'as-needed'
despite its massive design flaws has lead people to think that setting
LDFLAGS is in some way useful or cool. I expect next someone will try
to find a way to force 'ASFLAGS' onto everyone...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Fri, 1 Aug 2008 12:48:21 +0200
"Lukasz Damentko" <[EMAIL PROTECTED]> wrote:
> 2. I want Council to consider moving their meetings somewhere where
> third parties can't control who in Gentoo can attend and who can't.
So that would be "not on the Internet&q
Paludis behaves are similar to some of the flukes in how Portage
behaves.
Some things we can validate easily -- for example, we can check that
depend strings parse using a strictly PMS-enforcing parser. But for
weird quirks that make EAPI 0 so difficult to pin down, there's not
much that c
aking changes to Portage that
break existing packages that rely upon behaviour as defined by PMS,
under the assertion that "PMS is too much like a rulebook"...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ore anything
else...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
kind of a pragmatic fellow.
Please explain how deliberately and knowingly breaking existing ebuilds
without bothering to work out the consequences, and refusing to fix it
with the hope that no-one will notice is pragmatic.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 5 Aug 2008 09:50:51 -0700
"Alec Warner" <[EMAIL PROTECTED]> wrote:
> I'm a maintainer and I'll say right out that I won't fix things unless
> they make sense to me; regardless of what some council says.
Then I'd imagine devrel would have to ste
On Tue, 5 Aug 2008 23:37:36 +0530
"Nirbheek Chauhan" <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 5, 2008 at 11:04 PM, Ciaran McCreesh
> <[EMAIL PROTECTED]> wrote:
> > On Tue, 5 Aug 2008 09:50:51 -0700
> > "Alec Warner" <[EMAIL PROTECTED]> wr
t the very least, the two should be separate attributes. But the
locking probably shouldn't be an attribute at all -- the 'flock' shell
utility can be used instead to get much more fine-grained locking.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ply:
* that the install cost is effectively zero
* that the resolution cost is effectively zero
* that the package does not install any files
* that the package does not use any of the (normal?) ebuild phases, and
so does not require exclusive pkg_* execution or pkg_* system state
preservation.
--
doing locking using mkdir and either a fifo or just plain old sleep.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
e the name should be something like
'zero-resolution-cost' rather than 'virtual'. But since giving more
information to the package manager is trivial, we might as well do
so.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
seful even without anything finer grained.
exclusive-src-unpack is a better indication of what specifically it
means.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
different from the
implications of "x requires exclusive src_unpack execution". Permitted
package manager behaviour is different for the two properties.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
uggestions?
What's wrong with just discussing it until we agree? Why do you think a
compromise is necessary?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
should primarily be a fun-loving community
where everyone gets along, whilst others think Gentoo should primarily
be a first-rate distribution delivering a quality product.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
601 - 700 of 3510 matches
Mail list logo
