# Hans de Graaff (16 Jan 2010)
# Not supported anymore by upstream since several ruby-gnome2
# releases. Will be removed in 30 days.
dev-ruby/ruby-libgda
Support for ruby-libgda already got removed by upstream with the 0.16
release which was released at the end of 2006.
signature.asc
Descript
On Friday 15 January 2010 20:55:18 Sebastian Pipping wrote:
> On 01/16/10 02:45, Mike Frysinger wrote:
> > the better idea
> > though would be to split your stuff along the proper lines.
> >
> > cache files = /var/cache/layman/
>
> as i said: it's not a "normal" cache.
you said but didnt explain
Mike Frysinger posted on Fri, 15 Jan 2010 20:45:49 -0500 as excerpted:
> On Friday 15 January 2010 20:24:38 Sebastian Pipping wrote:
>> On 01/16/10 00:33, Jorge Manuel B. S. Vicetto wrote:
>> > - From the alternatives, /var/lib/layman doesn't sound right. If
>> > /var/cache/layman doesn't work, wh
On 01/16/10 02:45, Mike Frysinger wrote:
> if you want to keep all of layman's stuff together, then about your only
> option is to create your own tree at like /var/layman/.
anybody objecting to /var/layman ?
> the better idea
> though would be to split your stuff along the proper lines.
>
>
On Friday 15 January 2010 20:24:38 Sebastian Pipping wrote:
> On 01/16/10 00:33, Jorge Manuel B. S. Vicetto wrote:
> > - From the alternatives, /var/lib/layman doesn't sound right. If
> > /var/cache/layman doesn't work, what about /var/spool/layman instead?
>
> Okay, how about
>
> /var/spool/la
On 01/16/10 00:33, Jorge Manuel B. S. Vicetto wrote:
> - From the alternatives, /var/lib/layman doesn't sound right. If
> /var/cache/layman doesn't work, what about /var/spool/layman instead?
Okay, how about
/var/spool/layman
then? Any objections?
Sebastian
> On Fri, 15 Jan 2010, Jorge Manuel B S Vicetto wrote:
> - From the alternatives, /var/lib/layman doesn't sound right.
The FHS (which we don't always obey, but in cases like this it's
useful as a guideline) says about /var/lib: "This hierarchy holds
state information pertaining to an applicat
2010/1/15 Dawid Węgliński :
> On Friday 15 January 2010 20:44:43 Alex Legler wrote:
>> > /var/lib/layman
>> >
>> > do well?
>>
>> +1
>>
> -1, /usr/local/layman?
/usr/local/ is a location the system should avoid. Somewhere in /var/
seems to be the logical place.
Cheers,
--
Ben de Groot
Gentoo L
On Saturday 16 January 2010 00:33:15 Jorge Manuel B. S. Vicetto wrote:
> On 15-01-2010 21:25, Dawid Węgliński wrote:
> > On Friday 15 January 2010 20:44:43 Alex Legler wrote:
> >>> /var/lib/layman
> >>>
> >>> do well?
> >>
> >> +1
> >
> > -1, /usr/local/layman?
>
> Wouldn't that break the rule t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15-01-2010 21:25, Dawid Węgliński wrote:
> On Friday 15 January 2010 20:44:43 Alex Legler wrote:
>>> /var/lib/layman
>>>
>>> do well?
>>
>> +1
>>
> -1, /usr/local/layman?
Wouldn't that break the rule that /usr/local is reserved for users / admins
On Friday 15 January 2010 20:44:43 Alex Legler wrote:
> > /var/lib/layman
> >
> > do well?
>
> +1
>
-1, /usr/local/layman?
--
Cheers
Dawid Węgliński
On Fri, 15 Jan 2010 20:36:20 +0100, Sebastian Pipping
wrote:
> Would
>
> /var/lib/layman
>
> do well?
+1
--
Alex Legler | Gentoo Security / Ruby
a...@gentoo.org | a...@jabber.ccc.de
signature.asc
Description: PGP signature
On Fri, 15 Jan 2010 20:36:20 +0100, Sebastian Pipping
wrote:
> Hello!
>
>
> By default layman currently stores overlays into
>
> /usr/local/portage/layman
>
> (was /usr/portage/local/layman before that).
> As of bug 253725 [1] that's not without problems.
I don't think it should be changed
Hello!
By default layman currently stores overlays into
/usr/local/portage/layman
(was /usr/portage/local/layman before that).
As of bug 253725 [1] that's not without problems.
I would like to get it right with the next switch.
Would
/var/lib/layman
do well? /var/cache/layman seems inad
# Markos Chandras (15 Jan 2010)
# Qt3 only application. Bug #299746. Will be removed in 30 days
app-i18n/qimhangul
--
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
signature.asc
Description: This is a digitally signed message part.
I think we have a bigger problem with packages that have a maintainer,
at least nominally, but said maintainer does not actually maintain the
package anymore.
--
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
__
On Tue, 12 Jan 2010 21:35:45 +0100
Ben de Groot wrote:
> 2010/1/12 Markos Chandras :
> > If you feel like it, become a proxy-maintainer and poke a developer
> > to put your ebuilds on tree. Have you ever heard of that ? :)
>
> Proxy-maintainership should be given a MUCH higher profile in Gentoo,
Hi,
Mike Frysinger :
> btw, latest python.eclass requires bash-3.2+ due to parsing errors in
> the regex checks:
> $ bash-3.1 -c '[[ a =~ ^(a|b)$ ]]'
> bash-3.1: -c: line 0: syntax error in conditional expression:
> unexpected token `(' bash-3.1: -c: line 0: syntax error near `^(a'
>
> we could q
On 1/15/10, Nirbheek Chauhan wrote:
> > "git commit " and "git status " still do full tree lstat().
> > I can try to make a patch or two to reduce lstat() in such cases.
> >
>
>
> That would definitely compliment the --stat option to git diff et al,
> making git more usable on repos with a hug
On 15-01-2010 00:34:08 -0500, Mike Frysinger wrote:
> On Tuesday 16 December 2008 18:46:44 Jeremy Olexa wrote:
> > Exhibit A:
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/python.eclass?r1=1.4
> > 8&r2=1.49
> >
> > This causes me pain on my hosts that don't have >=bash-3.1[0] for
> >
On Thursday 14 January 2010 18:25:35 Petteri Räty wrote:
> On 01/15/2010 12:54 AM, Robin H. Johnson wrote:
> > That top item is the largest blocker. The actual conversion time is down
> > to 9 hours, but with more than that again in setting it up. I'd like to
> > get the conversion time down to UND
21 matches
Mail list logo
