Roy Marples wrote:
Saying that, the project is almost complete - the only reason it never
hit portage was the it destroyed config parts that it did not know
about. After SOC finished, my student has been mute to my emails :/
Thanks
Roy
Maybe we should restrict people we approve to work
On Fri, 16 Feb 2007 21:40:03 -0700
Daniel Robbins [EMAIL PROTECTED] wrote:
Oh, and a bit of history - at one point, I used djb's supervise as
part of the initscripts so that we could do stuff similarly to
upstart. When the initscripts were rewritten, we went to bash and had
the intention of
On Friday 16 February 2007, William Hubbs wrote:
I saw that we have a request for an ebuild for upstart.
I am looking it over and looking at the sample jobs that can be
downloaded from the site.
I think this would be an intresting idea, and I'm curious what others on
this list would think
On Friday 16 February 2007, Daniel Robbins wrote:
OK, I did not understand how it was supposed to work. Is there
documentation anywhere that explains how it works and why?
other than the comment in /etc/conf.d/clock, nope ... the init script will
warn you at boot if you still havent set it
Petteri Räty wrote:
Roy Marples wrote:
Saying that, the project is almost complete - the only reason it never
hit portage was the it destroyed config parts that it did not know
about. After SOC finished, my student has been mute to my emails :/
Thanks
Roy
Maybe we should
Ciaran McCreesh wrote:
* devmanual. Not converting it over to a new shiny XML thing or
whatever, but just extending and reworking the parts that need it.
Last year's SoC FAQ said that the actual work would have to be coding,
not writing documentation.
--
Kind Regards,
Simon Stelling
William Hubbs wrote:
All,
I saw that we have a request for an ebuild for upstart.
I had requests for other highly experimental yet to be tested programs...
I think this would be an intresting idea, and I'm curious what others on
this list would think about it.
As long as it won't
On Sat, Feb 17, 2007 at 12:19:04PM +, Dimitry Bradt wrote:
Petteri Räty wrote:
Maybe we should restrict people we approve to work on projects to
existing Gentoo developers or to people with a history of contributions
to bugzilla or overlays. This would at least increase the change that
As per summary, I've just masked mikachan-font for removal. Don't panic! I'm
not removing the mikachan font from portage. This package installs, depending
on version, either a TTF font (TrueType Fonts files) or a TTC font (TrueType
Collection); the latter is not compatible with some software,
now that the 2.6 headers have entered a sane state and are *quite* nice to
work with, i have no inclination whatsoever to touch unsanitized headers
(keep your puns to yourself :p)
so here's the question i pose: what to do ?
people file bug reports saying package FOO fails to build with
Mike Frysinger wrote:
now that the 2.6 headers have entered a sane state and are *quite* nice to
I'm looking forward to see the cvs log of the removal of 2.4
lu
--
Luca Barbato
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@gentoo.org mailing list
Mike,
I think you have a good plan. Retiring the 2.4 headers sounds like the
right thing to do. Building glibc against 2.6 and enabling backwards
compatibility with older kernels should not be problematic. It all
sounds good from a maintainability and stability perspective.
Nothing should break
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
If we mask and force various profile specific USE flags
appropriately, it will give repoman the information it needs to stop
producing bogus warnings about unsatisfied conditional dependencies
that are actually irrelevant. An additional
Hi guys.
I am quite confused by the following:
aldar ~ # emerge -puD world --tree
These are the packages that would be merged, in reverse order:
Calculating world dependencies... done!
[nomerge ] dev-ada/cbind-6.0
[nomerge ] virtual/gnat-4.1
[ebuild UD] dev-lang/gnat-gcc-4.1.1
On Sat, 17 Feb 2007 12:30:31 +0100
George Shapovalov [EMAIL PROTECTED] wrote:
Hi guys.
I am quite confused by the following:
aldar ~ # emerge -puD world --tree
These are the packages that would be merged, in reverse order:
Calculating world dependencies... done!
[nomerge ]
If you haven't noticed, I just added a new 'preserve-libs' feature for
bug 62207 that moves shared object that are still used but would be
removed on an update into the new package instance (so on a update from
expat-1 to expat-2 the user would still have libexpat.so.0, owned by
expat-2). The
On Sat, 17 Feb 2007 13:42:49 +0100
George Shapovalov [EMAIL PROTECTED] wrote:
Ok, found it.
Thanks Marius! (for the debug hint)
It was indeed forcing gnat-gcc-4.1.1 by asis-gcc-4.1.1 which has
=dev-lang/gnat-4.1.1 (this is an extension to compiler and has to
match it 1 for 1, forgot to
Marius Mauch wrote:
So everyone who has valid objections to the _general idea_ of this
implementation (preserving old libraries to avoid some runtime linker
errors) speak up now.
For how long are these libraries preserved? This might have a security
impact in cases like the recent
On Saturday 17 February 2007, Simon Stelling wrote:
Using preserve-libs it would leave the old lib around,
making it possible for programs to link against the wrong version and
ending up being vulnerable.
generally, this is incorrect
the only way you could link against it is if you were to
On Sat, 17 Feb 2007 14:55:26 +0100
Simon Stelling [EMAIL PROTECTED] wrote:
Marius Mauch wrote:
So everyone who has valid objections to the _general idea_ of this
implementation (preserving old libraries to avoid some runtime
linker errors) speak up now.
For how long are these libraries
Realize you didn't want comments upon the implementation, but tough
cookies, already reviewed it; suckers in svn mainline anyways, thus
it's fair game.
Modified: main/trunk/pym/portage/dbapi/vartree.py
===
---
On Sat, Feb 17, 2007 at 09:39:58AM -0500, Mike Frysinger wrote:
On Saturday 17 February 2007, Brian Harring wrote:
Security impact is from a pkg potentially dragging along old libs; if
you've got a stable pkg that gets an update once every blue moon, it
can hold onto the lib for a *long*
On Saturday 17 February 2007, Brian Harring wrote:
On Sat, Feb 17, 2007 at 09:39:58AM -0500, Mike Frysinger wrote:
On Saturday 17 February 2007, Brian Harring wrote:
Security impact is from a pkg potentially dragging along old libs; if
you've got a stable pkg that gets an update once
On Sat, Feb 17, 2007 at 10:09:35AM -0500, Mike Frysinger wrote:
On Saturday 17 February 2007, Brian Harring wrote:
On Sat, Feb 17, 2007 at 09:39:58AM -0500, Mike Frysinger wrote:
On Saturday 17 February 2007, Brian Harring wrote:
Security impact is from a pkg potentially dragging along
On Saturday 17 February 2007, Brian Harring wrote:
On Sat, Feb 17, 2007 at 10:09:35AM -0500, Mike Frysinger wrote:
On Saturday 17 February 2007, Brian Harring wrote:
(assuming the code knows the appropriate linker args)
there is no such thing ... it's always -lfoo
The point is that it
25 matches
Mail list logo
