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
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 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
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 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 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
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 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
> > >
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
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
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
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
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
- 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
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
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
ted,
> unfortunately.
What exactly is it about the toolchain supplied with Gentoo that causes
you problems?
--
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
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
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
(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
late already, but maybe one
of them can accept...
--
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
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
. 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
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
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
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
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
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
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
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 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
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
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
* could be reworked as one or more eselect
modules?
--
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
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
even virtual/system (with the
> compiler removed from that virtual).
--
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
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
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 :)
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 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
ed in metadata, and let
the herd maintainers re-assign amongst themselves if appropriate.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
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
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
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
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
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
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
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
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
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
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
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
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
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
to give a warning
> message telling users not to enable -z now even if portage states
> otherwise. Ideally, binutils would also be patched to support -z
> nonow, and -Wl,-z,nonow would be appended to LDFLAGS, but that's
> something for later concern.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Sat, 13 May 2006 23:04:10 -0700
Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> Kevin F. Quinn (Gentoo) wrote:
>
> Oh, OK, let's argue semantics. It's suggested by a hardened user on a
> bug the hardened team is CC'd on, but the team didn't say anythin
kes the effort is working out which are
relevant).
Duncan - perhaps it would be useful if you could raise a separate bug
about the QA message and Xorg, and attach the diff you apply to
x-modular.eclass.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Sat, 13 May 2006 11:32:49 +0200
Simon Strandman <[EMAIL PROTECTED]> wrote:
> Kevin F. Quinn (Gentoo) skrev:
> > On Fri, 12 May 2006 10:49:22 +0200
> > Simon Strandman <[EMAIL PROTECTED]> wrote:
> >
> >> I installed modular X on my server running hard
ular X (which is a big enough job as it is) so we've left it as it
is for the moment. We'll probably start looking at it again once it
becomes stable (also upstream have a pending task to resolve the issue
properly, but don't hold your breath).
P.S. there's a hardened mailing list that is relevant.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Fri, 5 May 2006 16:38:57 +0200
Carsten Lohrke <[EMAIL PROTECTED]> wrote:
> On Friday 05 May 2006 15:23, Kevin F. Quinn (Gentoo) wrote:
> > I disagree. Your argument is for not using ~arch at all, rather
> > than an argument against keeping control of what you have from
&
On Fri, 5 May 2006 13:20:09 +0200
Carsten Lohrke <[EMAIL PROTECTED]> wrote:
> On Friday 05 May 2006 08:32, Kevin F. Quinn (Gentoo) wrote:
> > If you use specific versions in the package.keywords file (i.e. do
> > "=category/package-version-revision ~arch" instead
n/devrel/handbook/handbook.xml?part=1&chap=2
In the first instance, do the work on bugzilla. Look for open bugs for
existing packages, and post fixes/patches there. For packages not
currently in portage, raise a new bug.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
t looking for package versions
that have been superseded.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Fri, 28 Apr 2006 21:29:58 +0200
George Shapovalov <[EMAIL PROTECTED]> wrote:
> Friday, 28. April 2006 21:20, Kevin F. Quinn (Gentoo) wrote:
> > 3) A herd does not have an email address - it's not a person or
> > group of people so an email address is nonsensical.
>
f looking at it; herds are a mechanism for locating
maintainers for packages.
Seems simple enough when written out like that - flame me if I have
it wrong :)
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Thu, 27 Apr 2006 10:27:12 -0400
Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-04-27 at 09:22 +0200, Kevin F. Quinn (Gentoo) wrote:
> > I must admit I've assumed that the herd entry in metadata.xml is a
> > reasonable fall-back if the maintainer entry is
w how many people think herds are not
maintainers - if only a few people think this then I suggest it would
be better to accept the common interpretation of herd as a group of
people who can maintain a package.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
f resource to build
(3) cause extra deps
(2) and (3) are usually co-incident.
IMHO, of course ;)
Whatever we decide USE=doc means, it should be documented as such in
use.desc
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Sat, 25 Mar 2006 12:37:45 +
Duncan Coutts <[EMAIL PROTECTED]> wrote:
> On Sat, 2006-03-25 at 13:32 +0100, Kevin F. Quinn (Gentoo) wrote:
> > On Sat, 25 Mar 2006 11:46:58 +
> > Duncan Coutts <[EMAIL PROTECTED]> wrote:
> >
> > > On Sat, 2006-03
On Sat, 25 Mar 2006 11:46:58 +
Duncan Coutts <[EMAIL PROTECTED]> wrote:
> On Sat, 2006-03-25 at 12:42 +0100, Kevin F. Quinn (Gentoo) wrote:
>
> > This is a valid issue, as ghc is only supplied upstream for linux
> > (some older versions available in mingw32).
>
&g
vcs.org/RcsComparisons. Of the
alternatives to Bazaar-NG, Mercurial (at
http://www.selenic.com/mercurial/) looks most interesting, not least
because it claims fast local and network performance, which bazaar-ng
doesn't.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
filter the illegal bytes out of its input, or replace them with
a marker (replacement character) - instead it leaves the non-conformant
bytes alone.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
ally
in the case of the hardened compiler). This occurs also with the
vanilla compiler - which is a bug although very few people
(if any) come across it as the only supported way to use the
stack protector at the moment is by using the hardened compiler.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
the same way the application does.
http://www.microsoft.com/mspress/books/sampchap/5612b.asp
describes a number of risks of accepting UTF-8, including the above.
So far I haven't found anything that could be considered a general
security risk, but that doesn't prove much :)
--
Kevin F. Quinn
signature.asc
Description: PGP signature
to browse the bug to check whether the resolution is valid or not
- if there's a decent comment along with the resolution this becomes
unnecessary in the majority of cases.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
tion of a herd for these packages would be a question for the
maintainers of those packages :)
--
Kevin F. Quinn
signature.asc
Description: PGP signature
On Thu, 9 Feb 2006 22:48:32 +0100
Grobian <[EMAIL PROTECTED]> wrote:
> Please find attached GLEP 47: "Creating 'safe' environment variables".
Could you add a definition of 'safe' to the GLEP? It's not clear what
this means at the moment.
--
Kev
ack-protector is only a problem if gcc-4.0 is built without
the ssp-stubs - from 4.1 onwards that'll be upstream as well.
Having said that, I don't think we need -fno-stack-protector in default
DEBUG_FLAGS anyway, as it doesn't inhibit debug (unlike -Wl,pie).
--
Kevin F. Quinn
signature.asc
Description: PGP signature
quot;
It's enough to do LDFLAGS="-nopie" to get debuggable executables, which
might be better as it'd keep code closer to the non-debug code.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
sibility is gnat-gpl-3.4.5.2005, but I'm not sure that it's
worth it.
--
Kevin F. Quinn
--
Kevin F. Quinn
signature.asc
Description: PGP signature
.bdf`.pcf && \
/usr/X11R6/bin/bdftopcf ${font} > ${pcf} && \
gzip ${pcf} &
[[ ${n} -eq 0 ]] && wait && n=${MAX_PARALLEL}
((n=${n}-1))
done
wait
--
Kevin F. Quinn
--
Kevin F. Quinn
signature.asc
Description: PGP signature
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
-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
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
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
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
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 20/10/2005 21:16:47, Dan Armak ([EMAIL PROTECTED]) wrote:
> On Thursday 20 October 2005 20:58, Matthijs van der Vleuten wrote:
> > On 10/20/05, Dan Armak <[EMAIL PROTECTED]> wrote:
> > > To solve this issue it would have to be an on-by-default flag, i.e.
> > > 'noxserver'. I know some people are
On 20/10/2005 21:16:47, Dan Armak ([EMAIL PROTECTED]) wrote:
> On Thursday 20 October 2005 20:58, Matthijs van der Vleuten wrote:
> > On 10/20/05, Dan Armak <[EMAIL PROTECTED]> wrote:
> > > To solve this issue it would have to be an on-by-default flag, i.e.
> > > 'noxserver'. I know some people are
On 11/10/2005 9:18:41, Dave Nebinger ([EMAIL PROTECTED]) wrote:
> This is probably the fifth time at least that I've been bitten by this...
https://bugs.gentoo.org/show_bug.cgi?id=11359
[NEW FEATURE] pkg_postinst/pkg_preinst ewarn/einfo logging
--
gentoo-dev@gentoo.org mailing list
On 20/9/2005 7:37:19, Georgi Georgiev ([EMAIL PROTECTED]) wrote:
> maillog: 20/09/2005-07:21:08(+0200): Christian Parpart types
> > On Monday 19 September 2005 15:22, warnera6 wrote:
> > > Mark Loeser wrote:
> > > > Paul de Vrieze wrote:
> > > >> I think that dev-util is a very specific category co
On 17/9/2005 11:34:56, Brian Harring ([EMAIL PROTECTED]) wrote:
> On Sat, Sep 17, 2005 at 11:28:03AM +0200, Kevin F. Quinn wrote:
> > The 30-day could be calculated from the $Header: of ebuilds that have
> > no UNSTABLE, or where it's empty.
>
> Doesn't work for N a
On 17/9/2005 13:33:30, Christian Parpart ([EMAIL PROTECTED]) wrote:
> On Saturday 17 September 2005 11:36, Kevin F. Quinn wrote:
> > On 17/9/2005 0:20:57, Mark Loeser ([EMAIL PROTECTED]) wrote:
> >
> > C++ herd is a good idea, especially with that number of packages.
> &g
On 17/9/2005 0:20:57, Mark Loeser ([EMAIL PROTECTED]) wrote:
C++ herd is a good idea, especially with that number of packages.
> I would also like to see many of them, if not all, moved to the dev-cpp
> category:
Is this bit really necessary?
--
gentoo-dev@gentoo.org mailing list
How about if the maintainer wants wider testing, i.e. wants to move
it out of package.mask and into ~arch but isn't confident it's ready
yet for arch, adding a string variable to ebuilds indicating why the
maintainer considers the package unstable, eg:
UNSTABLE="#100435, #100345, unconfirmed break
On 7/9/2005 3:10:12, Stuart Longland ([EMAIL PROTECTED]) wrote:
> Ciaran McCreesh wrote:
> > On Mon, 5 Sep 2005 9:44:41 +0200 "Kevin F. Quinn" <[EMAIL PROTECTED]>
> > wrote:
> > | On 5/9/2005 1:29:57, Ciaran McCreesh ([EMAIL PROTECTED]) wrote:
> > |
101 - 200 of 218 matches
Mail list logo
