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 processes
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
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, review
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 3rd
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...
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 functionality
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
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 (I
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 anything
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=gentoor1=1.31r2=1.32
What's the above again? QA policy? How does user benefit from flipping a
coin wrt choosing a functionality? Sigh... :/
It
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, 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
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
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. But
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 make
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.
This
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 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
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 logic
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 favour
-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
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
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
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.
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 exactly is
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!):
Brian Harring wrote:
If y'all want to mirror it, might I suggest poking marienz for his
tailorization knowledge? Afaik, he had a bzr-svn push working, or at
least has investigated it.
From what I've heard, tailor has absolutely no knowledge of branches. So
if you use branches, might want to
So while on my way to FOSDEM I decided to do something useful with the
time and wrote a new manifest2 implementation. This has nothing to do
with the original prototype I posted a while ago, it's been written
completely from scratch.
Basically all functionality (creation, parsing, validation) is
so we've found some cases where a package installs objects that either need to
be ignored by some of the scanelf checks ...
first off, we have kernel binary objects that a package installs (the h*modem
packages do this), so they should not be subjected to the exec stack scans
next up is the
29 matches
Mail list logo
