On 25/11/2005 11:46:54, Marius Mauch ([EMAIL PROTECTED]) wrote:
> Except that no{man,info,doc} are on the to-die list anyway.
When you say 'to-die' do you mean completely removed, or do you
mean replaced with {man,info,doc} (i.e. removing inverted logic)?
--
gentoo-dev@gentoo.org mailing list
On 26/11/2005 13:55:25, Ned Ludd ([EMAIL PROTECTED]) wrote:
> On Sat, 2005-11-26 at 19:30 +0100, Bruno wrote:
>
> > What's the advantage of splitting out the debug info to some extra
> > location instead of leaving it in the original binary (maybe smaller
> > foot-print in memory while the debug
devs to know about, and existing devs to have for a reference.
Agreed.
As far as normal Gentoo is concerned, I think policy should be to fix
textrels at least where it is simple to do so and upstream are happy to
have the issues fixed, and we should be most insistent for shared
libraries that are act
source code just means appending a few lines depending on the type of
assembler used.
As far as ebuilds are concerned, if you add it to LDFLAGS you will need
to re-check the application every time you bump the ebuild, and it's
difficult to find new occurrences of nested functions for examp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 14 Dec 2005 09:19:56 +0100
Harald van Dijk <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 14, 2005 at 08:51:42AM +0100, Kevin F. Quinn wrote:
> > On Wed, 14 Dec 2005 07:59:23 +0100
> > Harald van Dijk <[EMAIL PROTECTED]&g
headers - in particular look at the
PT_LOAD sections) and 'readelf -s' (which shows all segments).
If any one can point me to code in the kernel or loader that maps debug
symbol sections I'm sure many would be interested.
--
Kevin F. Quinn
--
gentoo-dev@gentoo.org mailing list
e point (either by inclusion or rejection).
Again, not the case with paludis as it is currently being proposed.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
ingle manifest for the whole eclass
directory. If GLEP33 ever gets implemented, this issue is obvious as
each subdirectory would have its own manifest.
Obviously the best way to add this sort of thing is to add support to
repoman, which has been mentioned before for profiles at least, for QA.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
LC_* during build time.
> Those bugs should be detected and fixed.
I disagree. LINGUAS is a Gentoo-specific thing, so is only relevant to
ebuilds. If a package uses LC_* to determine the user's locale
preferences, I see no problem with that.
> What do you think? LC_ALL=C in portage or not?
I vote not.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
t least. (A creates a package for B. B would like the Italian
> version. A does not know any Italian. There is a build error. Because
> the system forced LC_* to be set to Italian, A has no idea what the
> errors mean.)
Fair enough.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
ted when the locale is et_EE are fatal is just luck.
On the subject of timing elsewhere in the thread, I don't see there's
any hurry, as things have been as they are for a long time. However
that's a decision for the people who plan out portage releases.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Is there any reason you need package.env in portage proper
> as opposed to bashrc?
I remember portage people asserting before that package.env tricks from
bashrc don't work completely, in that it needs to be in place for
portage.py before the bashrc script is sourced. Is this no longer a
problem?
--
Kevin F. Quinn
signature.asc
Description: PGP signature
nstalls the server, the other installs just the client
programs.
>
> Other packages to possably beneift
> udhcp
> mldonkey
> samhain
> bacula
> boxbackup
>
> Interestingly, many packages have a server USE flag but not a client
> one - maybe make both a global USE
e teams to be competing with each
> > other).
This is about delegation, which is fine - however I don't think it's a
good idea to have two conflicting official positions. With regards
Gentoo-wide policy
> >
> > What are the alternatives? If a project's activities are not
> > automatically "official", then who gets to decide, and how is that
> > decision made? How can that decision be made fairly, without
> > contradicting the metastructure, and without giving rise to any
> > accusations of 'cabals'?
> >
> > Best regards,
> > Stu
--
Kevin F. Quinn
signature.asc
Description: PGP signature
ag does what it says on the tin - you have to inspect the
> ebuild code you're querying.
>
> Prior history shows deps of db vs gdbm where if both or neither then
> db was used, otherwise the flagged db was used.
>
> Problems problems - soltutions that work with existing installs or do
> we just bite the bullet and do
>
> ! use client && ! use server && die "must select either client or
> server"
>
> Which kinda defeats the purpose of a clean install.
>
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Sat, 10 Jun 2006 05:44:41 -0400
Mike Frysinger <[EMAIL PROTECTED]> wrote:
> On Saturday 10 June 2006 04:32, Kevin F. Quinn wrote:
> > I do think we should avoid built_with_use where we can, as it causes
> > emerge to abort.
>
> no it doesnt ... the ebuild maintai
oup of herd maintainers to take the package on. With
maintainer-* on CC the benefits accrued so far from having a bunch of
people helping to iron out early QA problems would remain, and at the
same time the group of people most likely to pick up the package would
also be aware of it.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
dreds of emails)?
This reflects back on the primary objection to sunrise on gentoo.org.
Your question is essentially, "who will take responsibility for it and
put it in the tree?". Sunrise might help in getting ebuilds to a decent
standard, and it might help some users to contribut
uld be a good idea to include key system elements (e.g.
kernel, toolchain, baselayout - perhaps the sys-* categories) in the ban
for sunrise. Anything hacking around with such critical components
should be in their own specific overlay. This is key to the
objections; that sunrise is system-wide, not local to a particular area.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
ed in metadata, and let
the herd maintainers re-assign amongst themselves if appropriate.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Thu, 15 Jun 2006 11:57:21 +0200
Jakub Moc <[EMAIL PROTECTED]> wrote:
> Mike Frysinger wrote:
> > On Thursday 15 June 2006 02:33, Kevin F. Quinn wrote:
> >> We could require that a herd mail alias be maintained for every
> >> herd, with the same name as t
ess, you're one of the two lead complainants about
> Project Sunrise. You've raised a number of points about Sunrise that
> need debating; you were right to do so, and I don't think anyone feels
> that they shouldn't have been raised.
>
> If you're not going to participate in a debate about those concerns
> without throwing your toys out of the pram, it undermines the
> complaint that you're making. That's plain enough to see by looking
> at the reaction elsewhere in these threads to some of the postings
> from the Sunrise project team, where they've behaved like that.
>
> Best regards,
> Stu
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Thu, 15 Jun 2006 15:22:31 -0400
Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> I would much
> rather see something like sunrise (but not necessarily sunrise
> itself) used to put packages which are no longer maintained, but were
> once in the tree.
sunset.overlays.g.o :)
esn't
find out about the missing dependency until the package is actually
merged, rather than at the beginning of an 'emerge world'.
Perhaps details should be taken off-list, if we're to think about this
seriously.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
ting RDEPEND to "" indicates that the stuff in DEPEND isn't needed
to run the package, and can safely be pruned later. If RDEPEND is not
set, it is defaulted to $DEPEND by portage.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
even virtual/system (with the
> compiler removed from that virtual).
--
Kevin F. Quinn
signature.asc
Description: PGP signature
cit-system-dependency
obviously USE flag settings affect what's pulled in by system as does
the profile.
So I think if we're to allow essential system dependencies to be
omitted, we should be very explicit; i.e. publish a strict list.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
.1
Whether any of these actually trigger real problems or not I don't
know; but then probaly neither do the upstream developers...
--
Kevin F. Quinn
signature.asc
Description: PGP signature
* could be reworked as one or more eselect
modules?
--
Kevin F. Quinn
signature.asc
Description: PGP signature
he kernel tree to build against
(KBUILD_OUTPUT) and thus build for different kernel configurations as
appropriate (the default being the build system kernel, which makes
things simple for the common case where the target is the build system).
In summary, I agree that $KV should disappear from portage
s specifically
version 3 include:
1) Target package depends on build system (assuming 'qt' is interpreted
as 'qt3' if only that is installed, rather than pulling in qt4 if not
already present).
2) What 'qt' means changes as new releases are made - if/when qt5
becomes available, it means introducing a qt4 use flag and back-fitting
to existing ebuilds that used 'qt' but don't build against qt5.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Tue, 20 Jun 2006 16:14:08 -0700
Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> Mike Owen wrote:
> > From this user's perspective, simple is better. qt3 and qt4 as use
> > flags are completely and utterly obvious as to what they mean, and
> > there is no confusion about them. Adding a plain qt fla
On Wed, 21 Jun 2006 02:39:29 -0400 (EDT)
"Michael Sterrett -Mr. Bones.-" <[EMAIL PROTECTED]> wrote:
> On Wed, 21 Jun 2006, Kevin F. Quinn wrote:
>
> > Am I making sense? This looks a lot like the gtk/gtk2 flags, but
> > inverted; according to use.desc, gtk bu
On Tue, 20 Jun 2006 23:25:42 -0700
Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> Kevin F. Quinn wrote:
> > On Tue, 20 Jun 2006 16:14:08 -0700
> > Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> >
> > [...]
Thanks for the clarification
> The goal is to avoi
old 2.0-portage, the
> syncing and caching had become really long.
If you want to sync just part of the tree, look into setting '--exclude'
or '--exclude-from' options via PORTAGE_RSYNC_EXTRA_OPTS in make.conf.
See rsync(1) and make.conf(5). Never tried it myself, but it shoul
o file mirror?
Only if they distribute binaries, in which case source should be
provided sufficient to build those binaries.
> Do my senses run wilde? Your just my imagination?
> Do I understand this right?
If you're not sure whether something you do is compliant with the
relevant license
release media (clearly
and obviously places) describing how people can request a copy of the
source disc from you if they wish.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Wed, 28 Jun 2006 21:20:00 +0200
Maurice van der Pot <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 28, 2006 at 07:54:12PM +0200, Kevin F. Quinn wrote:
> > You don't have to do this
> > for binary files copied from a Gentoo Live CD, as in that case
> > you're
On Fri, 30 Jun 2006 20:53:42 + (UTC)
"Duncan" <[EMAIL PROTECTED]> wrote:
> "Kevin F. Quinn" <[EMAIL PROTECTED]> posted
> > a) Accompany it with the complete corresponding machine-readable
> > source code, which must be distributed und
. Bochs is the only real emulator.
For the record, Qemu is much more than virtualisation; indeed
virtualisation is just a small part of what Qemu can do. Emulation is
the main thing that Qemu does, for many targets on many hosts.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
ainless, provided all the
relevant maintainers agree - indeed, a package can belong to more than
one herd. However changing a package's category is much more
disruptive and should be avoided.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
. Or if we want to be clever, setup a source-request
email alias which releng can farm out to nearby volunteers as
appropriate using email acknowledgement to ensure requests are serviced.
Point being, there are numerous ways we can comply, and no excuse for
not complying from now on.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
late already, but maybe one
of them can accept...
--
Kevin F. Quinn
signature.asc
Description: PGP signature
(combination of ARCH and -march or equivalent
CFLAGS). The suggested code already does the worst-case fall-back, as
it responds 'no' if the compiler doesn't support -dM or doesn't define
the relevant macro.
echo | $(tc-getCC) ${CFLAGS} -dM -E - 2>/dev/null | grep -q ${d
On Thu, 6 Jul 2006 14:44:22 +0200
"Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote:
> On Thursday 06 July 2006 14:35, Kevin F. Quinn wrote:
> > This could easily be done by configure
> > scripts; perhaps it would be a good idea to look into wri
een their processor
(which they've already set via -march in CFLAGS) and the various bits
that their processor has.
There are relatively few packages affected (<1%), so I think it's worth
a try. In the end it may be that a few packages need to deal with
stuff manually like with the current USE flags, but they'd be local USE
flags at that point.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
-libs/evas
x11-libs/libast
x11-misc/rss-glx
x11-terms/eterm
x11-themes/polymer
x11-wm/afterstep
x11-wm/metisse
--
Kevin F. Quinn
signature.asc
Description: PGP signature
ted,
> unfortunately.
What exactly is it about the toolchain supplied with Gentoo that causes
you problems?
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Thu, 6 Jul 2006 22:13:11 +0200
"Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote:
> Note: -march=i586 -mmmx for Pentium (classic) MMX is a good idea most
> of the times, as it's not an i686 but at the same time it has MMX
> support.
There's -ma
1.1+
>
> I don't know how much gcc-spec-env.patch can be trusted, and even if
> it is 100% safe, such patches don't belong in anything that would be
> called "vanilla". (I have commented on that patch long before this
> thread started, so don't think I'm just
- which could be the default behaviour if CPU_SUBMODEL is not
set. That way we have the best of both worlds; people who are happy to
let the system determine the configure options from the compiler
architecture can do so, those who want to control things in more detail
can do that as well.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
s closed or resolved; typically some
700-800 new bugs a week and 300-400 closed/resolved a week - however the
total number of open bugs over the same period has increased by just
372 bugs from 9947 to 10319 (total new + reopened - closed = 3791).
--
Kevin F. Quinn
signature.asc
Description: PGP signature
notice it wants cdrecord-prodvd for dvd writing - will it not
use the newer app-cdr/cdrtools to support DVDs (perhaps with the -n
option to not check the tool version)? Presumably the newer cdrtools
is backwards-compatible with the cdrecord-prodvd command line options?
--
Kevin F. Quinn
ike the aforementioned one, which should result in
> that particular ebuild getting fixed, instead of the bug being marked
> INVALID.
As I said above, don't take the "INVALID" marking personally. The fact
is that from the perspective of the relevant devs, the resolution of the
bug was to advise the user to upgrade gcc, which meant no change
required to the tree. See
https://bugs.gentoo.org/page.cgi?id=fields.html - as far as devs are
concerned, "The problem described is not a bug" so INVALID is the
correct resolution marking.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
a good
idea in general. The profile currently says that for x86, gcc
must be ">=sys-devel/gcc-3.3.4-r1" - if you do
# emerge >=sys-devel/gcc-3.3.4-r1
on a current tree you'll get a much higher version. Still, it's up to
releng if they wish to change it.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
s what vdr means on its own). If you do this,
make sure there's a maintainer tag.
However (c) seems to be the most sensible approach.
>
>
> What do you think of that?
>
> Zzam
>
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Mon, 10 Jul 2006 19:23:54 +0200
"Molle Bestefich" <[EMAIL PROTECTED]> wrote:
> Kevin F. Quinn wrote:
> > > > The expectation here is that when a new version of gcc is
> > > > stabilized, that users will upgrade to that in a reasonable
> > >
e'd be seeing a lot of bugs
related to that - and we're not seeing them.
> I'd think that most users hadn't even run into this problem (yet),
> because many source code maintainers strive to be able to compile with
> as old a version of GCC as possible..
That's u
On Tue, 18 Jul 2006 21:40:07 +0100
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> On Tue, 18 Jul 2006 21:18:22 +0200 "Kevin F. Quinn"
> <[EMAIL PROTECTED]> wrote:
> | > Uh, as far as I recall, you've yet to come up with any technical
> | > explanation
On Wed, 19 Jul 2006 17:15:38 +0100
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn"
> <[EMAIL PROTECTED]> wrote:
> | Things that package moves cause:
> | 1) Dependencies throughout the tree have to be updated
>
On Thu, 20 Jul 2006 00:37:47 -0700
Brian Harring <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 20, 2006 at 09:05:03AM +0200, Kevin F. Quinn wrote:
> > On Wed, 19 Jul 2006 17:15:38 +0100
> > Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed,
On Thu, 20 Jul 2006 13:24:55 -0700
Brian Harring <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 20, 2006 at 08:41:46PM +0200, Kevin F. Quinn wrote:
> > On Thu, 20 Jul 2006 00:37:47 -0700
> > Brian Harring <[EMAIL PROTECTED]> wrote:
> >
> > > On Thu, Jul 20
breaking
it means testing lots of stuff.
> Has to walk the entire tree... so if N category per pkg is going to
> be proposed, need to preserve the fast lookup that's there now.
I don't think the above ideas cause any substantial change to the
amount of processing required.
An advantage to this approach is that package moves just become aliases
- existing stuff doesn't break yet you get the new categorisation as
well.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Sat, 22 Jul 2006 21:42:07 +0100
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> On Sat, 22 Jul 2006 18:04:10 +0200 "Kevin F. Quinn"
> <[EMAIL PROTECTED]> wrote:
> | If it were to be implemented with symlinks (implying one entry is
> | "real" and the
On Sat, 22 Jul 2006 13:35:08 -0700
Brian Harring <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 22, 2006 at 06:04:10PM +0200, Kevin F. Quinn wrote:
> > On Fri, 21 Jul 2006 01:05:20 -0700
> > Brian Harring <[EMAIL PROTECTED]> wrote:
> >
> > > > >Unfortu
On Sun, 23 Jul 2006 12:19:28 +0100
Stuart Herbert <[EMAIL PROTECTED]> wrote:
> Kevin F. Quinn wrote:
> > An advantage to this approach is that package moves just become
> > aliases
> > - existing stuff doesn't break yet you get the new categorisation as
On Mon, 24 Jul 2006 06:23:59 -0700
Brian Harring <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 24, 2006 at 02:47:46PM +0200, Kevin F. Quinn wrote:
> > On Sun, 23 Jul 2006 12:19:28 +0100
> > Stuart Herbert <[EMAIL PROTECTED]> wrote:
> > > Just adding an alias
&g
e benefits. This may not happen often,
> but every single time is one time too much. This is can be really
> demotivating, which is probably the worst thing about it.
I think as long as Sunrise steers clear of core system packages,
essentially focusing on "leaf" packages, the sorts of problem you
encountered with BMG can be avoided. Certainly I would expect Sunrise
not to be providing alternate versions of stuff already in the tree,
and not to be modifying eclasses that exist in the tree - this sort of
change is for managed dev overlays.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
lead becomes a pita for everyone else on the
project, the rest of the project can oust the lead by majority
decision (hopefully a rare occurrence).
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Thu, 03 Aug 2006 19:48:01 -0400
Alec Warner <[EMAIL PROTECTED]> wrote:
> To briefly go over requirements you need to be able to:
>
> Speak English;
Why? Surely read & write is enough.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
tests switched on. If the tests are known to fail then the ebuild can
either RESTRICT=test, or just return successfully from src_test()
where the test report is useful even if some tests fail.
Thoughts?
--
Kevin F. Quinn
signature.asc
Description: PGP signature
uld know how many fail. It's not insignificant.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Sat, 5 Aug 2006 02:39:16 +0200
Danny van Dyk <[EMAIL PROTECTED]> wrote:
> Am Samstag, 5. August 2006 02:11 schrieb Kevin F. Quinn:
> > At the very least, ebuild maintainers and ATs should be running with
> > tests switched on. If the tests are known to fail then the
hope.
IMO devs should be working with "collision-protect sandbox strict
stricter test userpriv" but let's not get too excited ;)
--
Kevin F. Quinn
signature.asc
Description: PGP signature
libc versions where the
test failures are not understood. Clearly if something in glibc is not
behaving properly, the effects can be nasty.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
ng run (perhaps the
test data is huge), this can only be done with USE flags.
Basically, if you set FEATURES="test", add "test" also to your USE
flags. USE="test" should never be used for anything other than
supporting FEATURES="test".
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Sat, 5 Aug 2006 14:35:49 -0400
Mike Frysinger <[EMAIL PROTECTED]> wrote:
> On Saturday 05 August 2006 06:57, Kevin F. Quinn wrote:
> > On Sat, 5 Aug 2006 11:49:53 +0200
> > Danny van Dyk <[EMAIL PROTECTED]> wrote:
> > > Please re-read the list of pack
ot;alpha +beta gamma"
meaning beta is default-on?
Could do the same thing in per-package use.mask (although "mask"
becomes a misnomer at that point).
--
Kevin F. Quinn
signature.asc
Description: PGP signature
der /usr/ (which is also
where the compiler stuff for ends up). Conceptually at least
(although no doubt problematic in practice) on x86_64 one could use a
x86(_32) cross-compiler to build stuff to ROOT=/usr/${CTARGET}. Again
in concept a /${CTARGET}/{bin,include,lib...} would exists for
essential boot stuff, althought that's a bit academic.
Just a thought for the pot ;)
--
Kevin F. Quinn
signature.asc
Description: PGP signature
about trust, it's about knowing what the CFLAGS/FEATURES
were. That way if someone else reports a failure, you can compare the
reports and see what differences might be triggering the fault.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
pointed to
> for older links. If variation off the norm was needed or used for an
> individual package, that could be noted in the comments along with
> the link to the standard info.
I think the info changes frequently enough that it's easier, and more
likely to be correct, if it&#x
On Fri, 11 Aug 2006 00:51:56 +0200
Jeroen Roovers <[EMAIL PROTECTED]> wrote:
> On Thu, 10 Aug 2006 23:58:46 +0200
> "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote:
>
> > The problem with attachments is that processing the report takes
> > longer
> > -
On Fri, 11 Aug 2006 13:40:23 +0200
Jeroen Roovers <[EMAIL PROTECTED]> wrote:
> On Fri, 11 Aug 2006 12:52:30 +0200
> "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote:
>
> > In general it depends what you're doing. Personally I find inline
> > emerge --
t; and set as a dependency of the stabilisation bug."
>
> I absolutely agree with this. I assume now that you agree with me that
> debugging info, including `emerge info`, should *never* be inlined in,
> or even attached to, stabilisation bugs.
Yes.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
g `emerge info` at
the time of the report makes sense even for successful tests.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
lready get).
Perhaps the Foundation would be happier with a regular three- or
six-month update, with the occasional ad-hoc update as need arises.
Whatever, the point is that each project knows best how often it
ought to communicate stuff.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
the team. The lack of formality means that if the
team doesn't explicitly object to something you propose (e.g. what you
propose doesn't affect what the rest of the team do, or if it does
they don't care), you can just go ahead. Your summary implies explicit
consent from the team would be needed, which I don't think would be a
good idea.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
hat unmerging a set should only unmerge elements
of the set that are not part of any other installed set (including
world). So behaviour is less like 'emerge $(cat )' and more like
emerge sets/ where /set/set-V.ebuild is like a meta-ebuild.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
If we were to hold up the
release of everything until all bugs are fixed, we'd never release
anything.
You have the power to sort out this problem on your own system. Just
build the relevant packages with gcc-3.4.6 instead of gcc-4.1.1 (see
gcc-config for switching your selected compiler).
--
Kevin F. Quinn
signature.asc
Description: PGP signature
ss as mainainer, but do not
have either a proper herd, or a specific gentoo.org dev listed as
maintainer.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Sun, 03 Sep 2006 13:57:10 +0200
Stefan Schweizer <[EMAIL PROTECTED]> wrote:
> Kevin F. Quinn wrote:
> > I don't think it's a good idea for devs to be putting stuff into the
> > tree without taking responsibility for it.
> sure I can put myself in there
ke this.
What I'm conerned about is packages that have no Gentoo maintainer,
something that should obviously never happen for packages in the
official tree.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
d before. You can't expect
sys-devel/gcc to take responsibility for every package in the tree in
all configurations.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Sun, 03 Sep 2006 17:54:33 -0600
Ryan Hill <[EMAIL PROTECTED]> wrote:
> Kevin F. Quinn wrote:
> > If you don't care whether a package is stable or not, just let the
> > arch team go ahead and do what they need to do to stabilise when
> > they wish to. The role o
If something is in an overlay,
presumably the contributor has write access to that overlay, and should
be the assignee of the bug.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
pell again and end up with a
confused dep tree.
Also, to my understanding, having configure automagically build support
for hspell if it's available on the system is not the way we're
supposed to handle such dependencies.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
LICENSES and
DENY_LICENSES (with wildcard support).
--
Kevin F. Quinn
signature.asc
Description: PGP signature
be more specific. What are the "unnecessary"
projects, and why?
> - Project status reports once a month for every project
We've discussed this before. Project status reports make sense if
they're going to be read. Personally I think each project should
organise its own status reporting schedule.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Wed, 4 Oct 2006 14:18:54 +0100
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> On Wed, 4 Oct 2006 15:02:17 +0200 "Kevin F. Quinn"
> <[EMAIL PROTECTED]> wrote:
> | Yuck. Devs should be free to add whatever packages they like,
> | provided they're willing
essary: again, be more specific. What are the "unnecessary"
> > projects, and why?
>
> Projects that aren't needed to further Gentoo and are not helpful to
> users or developers.
Again, by "specific" I meant which projects, by name, do you think meet
those criteria. Explain why you consider those projects to be a
hindrance to users or developers.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
1 - 100 of 218 matches
Mail list logo
