mån 2010-01-18 klockan 06:27 +0100 skrev Ulrich Mueller:
> > On Mon, 18 Jan 2010, Sebastian Pipping wrote:
>
> > isn't a package tree somehow having "system-wide implications"?
> > i'm not really sure about /var/db - doesn't seem to be in FHS.
> > is a package tree a database?
>
> This depend
> On Sun, 17 Jan 2010, Petteri Räty wrote:
> With GLEP 42 and proper logging of e* messages I think we shouldn't
> annoy users any more with ebeep or epause
Agreed.
> so attached is a patch only defines these functions for EAPIs 0, 1
> and 2. Anyone have a reason to keep these around for EAP
On Mon, Jan 18, 2010 at 09:05:58AM +0100, Peter Hjalmarsson wrote:
> I sometimes think the main problem is the tree itself. Portage really
> should had a directory of its own, but maybe with anoher structure,
> like /var/portage, /var/portage/tree (the current
> PORTDIR), /var/portage/distfiles (i.
Alex Alexander dixit (2010-01-18, 11:07):
> On Mon, Jan 18, 2010 at 09:05:58AM +0100, Peter Hjalmarsson wrote:
> > I sometimes think the main problem is the tree itself. Portage really
> > should had a directory of its own, but maybe with anoher structure,
> > like /var/portage, /var/portage/tree
Alex Alexander wrote:
> On Mon, Jan 18, 2010 at 09:05:58AM +0100, Peter Hjalmarsson wrote:
>> I sometimes think the main problem is the tree itself. Portage really
>> should had a directory of its own, but maybe with anoher structure,
>> like /var/portage, /var/portage/tree (the current
>> PORTDIR
Hi. I'm going to add xtable-addons package to the tree. This is
patch-o-matic replacement which allows to extend iptables without
touching iptables source itself. Currently package contains 24 modules
which I'd like to have USE configurable with USE_EXPAND'ed variable:
XTABLES_ADDONS_MODULES
Curr
On Sun, Jan 17, 2010 at 11:09:07AM +, Ciaran McCreesh wrote:
> 2010/1/17 Christian Faulhammer :
> > Ciaran McCreesh :
> > As much as you love to have the new and shiny VDB2, it is far off.
> > Prototyping and drafting implementations would be great to have some
> > base where we can discuss on
mån 2010-01-18 klockan 12:40 +0100 skrev Michael Haubenwallner:
> Alex Alexander wrote:
> > On Mon, Jan 18, 2010 at 09:05:58AM +0100, Peter Hjalmarsson wrote:
> >> I sometimes think the main problem is the tree itself. Portage really
> >> should had a directory of its own, but maybe with anoher str
2010/1/18 Brian Harring :
> Propose something, or shut up frankly.
I propose we don't do anything until someone comes up with a decent
cache proposal.
> If all you're going to contribute is "it's half baked" claims, you're
> wasting folks time. You've had a couple of months of time to
> counterp
Hello,
I want to drop maintenance for some of the packages that I have acquired
over the years. Some of them are still co-maintained, some are now
unmaintained.
=== Freevo ===
Freevo is split up in different Python components. They are all
maintained by a herd, but a dedicated maintainer is n
The proper replacement for such interactive notifications when called in
pkg_setup is pkg_pretend, which will (hopefully) be available in EAPI 4.
Thus I'd keep them around until then.
Cheers,
Tiziano
Am Sonntag, den 17.01.2010, 22:38 +0200 schrieb Petteri Räty:
> With GLEP 42 and proper logging o
On Mon, Jan 18, 2010 at 05:56:08PM +0100, Robert Buchholz wrote:
> These packages are now without a maintainer:
>
> app-misc/g15macro
> app-misc/g15message
> dev-libs/libg15render
> app-misc/g15stats # already maintainer-needed
I use the above, and will take them.
> media-plugins/audacious-g15-s
On Mon, 2010-01-18 at 20:29 +, Robin H. Johnson wrote:
> I use the above, and will take them.
Please do feel free to take g15daemon & friends as well, I've not been
able to provide them with the attention they deserve.
> > media-plugins/audacious-g15-spectrum
I'd rather just get this upstrea
On 01/18/2010 03:02 PM, Tiziano Müller wrote:
> The proper replacement for such interactive notifications when called in
> pkg_setup is pkg_pretend, which will (hopefully) be available in EAPI 4.
> Thus I'd keep them around until then.
>
> Cheers,
> Tiziano
>
ebeep or epause don't make your ebui
On 01/18/2010 10:07 AM, Ulrich Mueller wrote:
>> On Sun, 17 Jan 2010, Petteri Räty wrote:
>
>> With GLEP 42 and proper logging of e* messages I think we shouldn't
>> annoy users any more with ebeep or epause
>
> Agreed.
>
>> so attached is a patch only defines these functions for EAPIs 0, 1
On 01/16/10 19:52, Peter Hjalmarsson wrote:
> That is for the overlays, yeah?
> But hov about the cache_*.xml files?
>
> I think what he meant was that should layman really only has one
> directory? One for cache (downloaded/downloadable lists of overlays?
> in /var/cache/layman/?), one for the ma
Le 17/01/2010 12:26, Tomáš Chvátal a écrit :
> Howdy guys,
> please review the attached file and suggest updates to in.
> I was asked for this thing going stable due to its being dependency of
> new nvidia-drivers.
>
> Also this thing is probably blocker for the bug on eselect-opengl i just
> open
On 01/18/10 01:38, Sebastian Pipping wrote:
> On 01/17/10 21:31, Thilo Bangert wrote:
>> /var/layman i dislike due to this sentence in the FHS:
>>
>>"Applications must generally not add directories to the top level of
>> /var. Such directories should only be added if they have some system-wide
On Monday 18 January 2010 19:05:23 Sebastian Pipping wrote:
> /var/empty <-- net-misc/openssh
this isnt exactly openssh specific. a few other packages use it as well for
their users because it's guaranteed to be empty.
-mike
signature.asc
Description: This is a digitally signed message part
On Mon, Jan 18, 2010 at 10:53:53PM +, Tony Chainsaw Vroon wrote:
> On Mon, 2010-01-18 at 20:29 +, Robin H. Johnson wrote:
> > I use the above, and will take them.
>
> Please do feel free to take g15daemon & friends as well, I've not been
> able to provide them with the attention they deser
On Mon, Jan 18, 2010 at 10:56 AM, Robert Buchholz wrote:
> Hello,
>
> I want to drop maintenance for some of the packages that I have acquired
> over the years. Some of them are still co-maintained, some are now
> unmaintained.
>
> === Freevo ===
>
> Freevo is split up in different Python componen
21 matches
Mail list logo
