Hi all,
I finally get to test the new 2006.0 LiveCD and the new installer (GUI
version). It certainly has many kinks to be ironed out, but it is a
great new start!
I am now waiting for the install on a vmware-workstation-5.5 while
reading what Google had to say about "VMWare Gentoo"...
A few qui
On Thu, 2 Mar 2006 00:19:47 +
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> Attached is the final draft. No substantial changes since last time,
> just wording cleanups and a few clarifications. You'll be able to see
> it here in an hour or three (check the dates!):
>
> http://www.gentoo.org/p
Alec Warner wrote:
>> The whole argument here is that bailing out with conflicting use flags
>> breaks some extensive compiles. So you suppose users will be sitting in
>> front of their monitor and stare on the screen waiting for a scary
>> warning?
>> No, they won't. And even if they were, how exa
On Friday 03 March 2006 18:14, Stuart Herbert wrote:
> If we're going to do this, then at least we should be implementing a
> consistent standard across all ebuilds. F.ex, when SSL and TLS
> conflict, we should have a standard saying that all ebuilds will
> consistenly favour one over the other.
The whole argument here is that bailing out with conflicting use flags
breaks some extensive compiles. So you suppose users will be sitting in
front of their monitor and stare on the screen waiting for a scary warning?
No, they won't. And even if they were, how exactly is that warning better
No
This is undocumented and unofficial, so feel free to utterly ignore it
and commit whatever the heck you want.
The 'doc' and 'examples' (yay for consistency!) USE flags are intended
for use where building documentation or examples would take a long
time, introduce new dependencies or otherwise be a
On Fri, 3 Mar 2006 23:14:41 + "Stuart Herbert"
<[EMAIL PROTECTED]> wrote:
| If we're going to do this, then at least we should be implementing a
| consistent standard across all ebuilds. F.ex, when SSL and TLS
| conflict, we should have a standard saying that all ebuilds will
| consistenly fav
Hi Grant,
On 3/3/06, Grant Goodyear <[EMAIL PROTECTED]> wrote:
> Yep. Having a USE flag enabled turns out not to be a guarantee. That
> said, package builds do become deterministic, so (for example) if one
> needs to know if msmtp was built with openssl or gnutls it is easy
> enough to pull the
Stuart Herbert wrote:
It prevents emerge from crashing out in the middle of what could be a
quite extensive build. Personally, I would rather rebuild one package
to get desired functionality _after_ the emerge completes than have to
fix the flags for that one package to be able to build everythi
3.3.2006, 23:32:36, Grant Goodyear wrote:
> Jakub Moc wrote:
>> Erm, how exactly will you find out that you need to recompile that package
>> after such extensive build? You'll spend a couple of hours debugging when
>> your server app stops working? Yay! :P
> I had assumed that in such a case th
> > It prevents emerge from crashing out in the middle of what could be a
> > quite extensive build. Personally, I would rather rebuild one package
> > to get desired functionality _after_ the emerge completes than have to
> > fix the flags for that one package to be able to build everything else.
On Fri, 3 Mar 2006 23:31:49 +0100
Jakub Moc <[EMAIL PROTECTED]> wrote:
> Yeah, that's a wonderful message. Let users choose, they are not
> idiots and such policy does more harm than good. Period.
You're completely missing the point here. The user has a choice, but if
his set of choices doesn't m
Stuart Herbert wrote:
> I agree. Adopting a policy like this is a low quality solution for
> servers. I've no opinion on how this affects desktops, but packages
> for servers need to be precise.A policy that says "if two USE
> flags deliver the same benefits, but conflict, pick one" is fine.
Jakub Moc wrote:
> Erm, how exactly will you find out that you need to recompile that package
> after such extensive build? You'll spend a couple of hours debugging when
> your server app stops working? Yay! :P
I had assumed that in such a case the ebuild would output a
scary-looking ewarn that no
3.3.2006, 23:25:13, Stephen Bennett wrote:
> On Fri, 3 Mar 2006 22:27:45 +0100
> Jakub Moc <[EMAIL PROTECTED]> wrote:
>> What kind of point does it get across, exactly?
> That you must choose one flag, or set of flags, to take precedence in such
> situations, but that how you choose is quite i
On Fri, 3 Mar 2006 22:27:45 +0100
Jakub Moc <[EMAIL PROTECTED]> wrote:
> What kind of point does it get across, exactly?
That you must choose one flag, or set of flags, to take precedence in
such situations, but that how you choose is quite immaterial. If there
is an obvious choice then use it,
3.3.2006, 22:54:25, Grant Goodyear wrote:
>>> http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?root=gentoo&r1=1.31&r2=1.32
>>>
>>> What's the above again? QA policy? How does user benefit from flipping a
>>> coin wrt choosing a functionality? Sigh..
3.3.2006, 22:51:39, Mike Frysinger wrote:
> On Friday 03 March 2006 15:47, Jakub Moc wrote:
>> Please, until something is clarified/some consent reached, avoid changing
>> the docs w/ funny stuff like "just flip a coin"...
> please, get a sense of humor, kthxbye
> -mike
Sorry, I don't find anyt
Sending this from the right address this time
-g2boojum-
Grant Goodyear wrote:
> Jakub Moc wrote:
>> Please, until something is clarified/some consent reached, avoid changing
>> the docs w/ funny stuff like "just flip a coin"...
>
> I don't believe the text is meant to be funny. It's meant
On Friday 03 March 2006 15:47, Jakub Moc wrote:
> Please, until something is clarified/some consent reached, avoid changing
> the docs w/ funny stuff like "just flip a coin"...
please, get a sense of humor, kthxbye
-mike
--
gentoo-dev@gentoo.org mailing list
On 3/3/06, Jakub Moc <[EMAIL PROTECTED]> wrote:
> > It gets the point across effectively. I don't see your problem.
>
> What kind of point does it get across, exactly? That flipping a coin or
> forcing your personal preference is a better solution than letting users
> decide what kind of functional
3.3.2006, 22:19:33, Stephen Bennett wrote:
> On Fri, 3 Mar 2006 21:47:22 +0100
> Jakub Moc <[EMAIL PROTECTED]> wrote:
>> Please, until something is clarified/some consent reached, avoid
>> changing the docs w/ funny stuff like "just flip a coin"...
>>
>> http://www.gentoo.org/cgi-bin/viewcvs.cg
On Fri, 3 Mar 2006 21:47:22 +0100
Jakub Moc <[EMAIL PROTECTED]> wrote:
> Please, until something is clarified/some consent reached, avoid
> changing the docs w/ funny stuff like "just flip a coin"...
>
> http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.
Mike Frysinger wrote:
> On Wednesday 01 March 2006 19:19, Ciaran McCreesh wrote:
>> Unless there are any huge flaws found, I'd like this to be voted on by
>> the council -- looks like it'll have to wait until April's meeting to
>> fit in with the two weeks rule.
>
> may push council meeting back t
3.3.2006, 6:31:17, Mark Loeser wrote:
> Mike Frysinger <[EMAIL PROTECTED]> said:
>> one thing i dont think we give enough emphasis to is that our tools arent
>> perfect ... sometimes we utilize QA violations to work around portage
>> limitations ... if you want to see some really sweet hacks, r
Mike Frysinger wrote:
On Wednesday 01 March 2006 19:19, Ciaran McCreesh wrote:
Unless there are any huge flaws found, I'd like this to be voted on by
the council -- looks like it'll have to wait until April's meeting to
fit in with the two weeks rule.
may push council meeting back to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey everybody :-)
It's time again to get some bug smashing done.
We hope to see you all in #gentoo-bugs tomorrow (saturday 2006/03/04).
Best Regards
Bjarke Istrup Pedersen
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using Gn
Stuart Herbert wrote:
> [...]
> Mark, in the discussions about the QA policy, your fallback
> justification always seems to be "Trust us". I think this week's
> events have put a big dent in the credibility of that argument, if not
> holed it below the water line. If the QA team followed process
28 matches
Mail list logo
