# Joe Peterson (12 Apr 2012)
# Replaced by new package: media-sound/logitechmediaserver-bin
# - Upstream retired the old package/name
# Removal in 30 days - see bug 377825
media-sound/squeezeboxserver
I think a better solution, if we need to indicate this, is to have
bugzilla grab the status from devaway and display it next to the dev's
name in bug reports. Changing the user's name seems a bit cumbersome,
and I don't agree that people will know what "devaway" means - i.e.
they may not even goog
# Joe Peterson (03 Jun 2010)
# Masked for removal in 30 days:
# Fails to build with gcc 4.4 (see bug #290105)
# Requires non-open-source components that never worked well
# - e.g. voice, media
# - this (source) package never behaved quite like the binary
# Really should be replaced by Snowglobe
On 03/31/2010 02:28 PM, Sebastian Pipping wrote:
> I am worried that if people start using say Google Docs for
> collaborating on Gentoo content, everyone else is forced to use Google
> Docs to participate.
Gentoo could set policies that such shared resources should not be done
via google calender
On 03/31/2010 01:40 PM, Mike Frysinger wrote:
>> Those, like me, who have several google apps accounts (I have a personal
>> business one, a personal one, and a work one) can keep accounts separate
>> this way. Also, since it's the "gentoo.org" google apps account, the
>> email address looks the s
On 03/31/2010 02:18 AM, Mike Frysinger wrote:
> i'm already using ~/.forward which means mail still goes to mail.g.o and that
> server takes care of forwarding it to my private gmail.com account. then my
> mail client fetches it from gmail.com via the normal pop/imap methods. there
> is no nee
# Joe Peterson (13 Mar 2010)
# Old, unmainted standalone kernel modules for older kernels.
# Kernels 2.6.29-rc1 and newer include integrated btrfs.
# Bug #285357 reports version 0.17 (newest standalone) does not build.
# Last rited: to be removed in 30 days.
sys-fs/btrfs
-Joe
Denis Dupeyron wrote:
> I'd be ready to believe part of it was that he wanted to
> experiment. And experiments sometimes succeed, or sometimes they fail,
Well, experimentation is OK (and I would encourage it for many things),
but I'm not sure I'd agree that experimentally giving someone council
po
Mike Frysinger wrote:
> /usr isnt guaranteed to be mounted for all init.d scripts
Right... Well, then the best choice is probably /etc out of the list [Roy
pointed out] of the only OS-nonspecific dirs, unless we want to have a small
executable script in /bin or /sbin that spits out the version.
Mike Frysinger wrote:
> maybe, but since we arent going to use /libexec/ at this time, that means
> /etc
> is the next best place
How about /usr/share/openrc/version?
Since /usr/share is supposed to contain package-specific (but platform
independent) files that are *not* meant to be modified (u
Alec Warner wrote:
> Lets agree to disagree on the definition of "technical" then and
> instead agree that putting EAPI in the filename is a bad design
> decision ("technicalness" aside) and then have a beer!
Wow. That's a *great* idea! ;)
-Cheers, Joe
Alec Warner wrote:
>> No, it's entirely objective. GLEP 55 clearly shows how the filename
>> based options are objectively better than anything else.
>
> But the decision will not be based entirely on objective merits
> (although I will concede that EAPI in filename is the 'best' technical
> choic
Roy Bamford wrote:
> GLEP 55 still confuses the problem and the solution.
> Adding metadata to the filename is not required and is bad system
> design practice. Its also the first step on the slippery slope to
> adding more metadata in the future.
++
> Changing the .ebuild extension, to blind e
Ulrich Mueller wrote:
> Hyphens within PV are a Bad Thing, and we should really think about
> replacing the separator for "scm" by something else, like a period or
> an underscore. For example, the following two would be unique:
>
> ${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
> ${PORTDIR}/a
Ciaran McCreesh wrote:
> On Mon, 18 May 2009 16:07:20 +0100
> Steven J Long wrote:
>> I missed the clamour of developers complaining about this
>> oh-so-burdensome restriction that they've been dealing with for at
>> least 5 years.
>
> Why do you think I wrote the awful hack that is versionator?
Ciaran McCreesh wrote:
>> 3. "Extend versioning rules in an EAPI - for example, addition of the
>> scm suffix - GLEP54 [1] or allowing more sensible version formats like
>> 1-rc1, 1-alpha etc. to match upstream more closely."
>> Apart from GLEP54, I believe our versioning scheme works reasonably
>>
Thomas Anderson wrote:
>- Vote on GLEP 54
>This vote was called for by dertobi123. The vote was on whether to
>approve GLEP 54 conditional on whether GLEP 55 is passed. The reason
>for this is that GLEP 54 is unimplementable without the problems
>mentioned in GLE
Jorge Manuel B. S. Vicetto wrote:
> As others have commented, we should probably make this the last comment
> line in the header. Any suggestions for a specific identification string
> or do we simply use '# EAPI="X"' or use a she-bang '#!/<..> EAPI="X"' ?
Well, if a she-bang, should be the first
Denis Dupeyron wrote:
>> 1. EAPI-suffixed ebuilds (obviously)
>> 2. EAPI in the filename with one-time extension change
>> 3. Easily fetchable EAPI inside the ebuild and one-time extension change
>
> My preference goes to 3 with a .eb extension and EAPI on the first line.
I second this. :)
David Leverton wrote:
> For comparson, another alternative that some people have suggested is putting
> it in a specially formatted comment. This avoids the issue I mentioned
> because bash doesn't try to parse those at all, so the only rules are those
> that specify what format the comment sho
Ulrich Mueller wrote:
>> On Wed, 25 Feb 2009, Petteri Räty wrote:
>
>> Let's try something new. I would like to get opinions from as many
>> people as possible about GLEP 55 and alternatives listed here in order
>> to get some idea what the general developer pool thinks.
>
> I've already comm
Ciaran McCreesh wrote:
>> All good points. I cannot believe there exists no other way to solve
>> this technical issue other than resorting to such a non-Unix-like
>> idea. Obviously all of the software packages cited above endeavor to
>> avoid such nastiness.
>
> Then why don't you come up with
Ciaran McCreesh wrote:
> On Tue, 24 Feb 2009 09:24:48 -0700
> Joe Peterson wrote:
>> Right. Plus, if the linker *did* consult the filename, imagine what
>> would happen if someone renamed the file (even by accident) and
>> changed the version? The parser should not
Richard Freeman wrote:
> The dynamic linker doesn't need to consult the filename to figure out
> how to parse a shared object. It only consults the filename to figure
> out which shared object is needed. That is actually analogous to
> putting the package name/version in the ebuild filename.
Richard Freeman wrote:
> I still don't see why we need to be encoding metadata in filenames.
Correct. GLEP 55 tries to solve a technical implementation issue by
exposing meta data in the filename. Extremely bad form/design, IMHO.
> PERL doesn't care what a file extension is, python doesn't care
Donnie Berkholz wrote:
> On 15:35 Mon 01 Dec , Joe Peterson wrote:
>> However, what I see as perhaps a missing "piece" is more conceptual: the
>> important connection between the valuable info in the emerge logs (and their
>> somewhat transient default nature) an
Diego 'Flameeyes' Pettenò wrote:
> "Alec Warner" <[EMAIL PROTECTED]> writes:
>
>> Looks Good To Me, but I would prefix the JOBS variable with some sort
>> of namespace (EJOBS, GENTOO_JOBS, etc.) to avoid conflicts with other
>> systems that may use JOBS internally already (seems vaguely likely).
>
Gilles Dartiguelongue wrote:
> As others have said, there are already proper systems, documentation and
> linking through other docs. Not finding this is what I'd call lazyness
> or lack of google foo. Don't misunderstand me, some stuff can get ouf of
> the radar of everyone, it's ok, real people a
Peter Volkov wrote:
> Seems that we already have everything you dreamed about:
>
> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=1#doc_chap4
>
> Take a look at PORTAGE_ELOG_SYSTEM. It even can send that messages by
> mail :)
This is all cool, indeed! :)
I suspect, however
Marius Mauch wrote:
> By default, messages generated by elog, ewarn and eerror are recorded
> in /var/log/portage/elog/summary.log (emerge.log is just a
> transaction log, so best to ignore it here). einfo isn't recorded on
> purpose as it isn't intended for important information (that's the
> purp
I recently had a user write to me after banging his head against the
wall for a while, trying to get a package working. By the time he wrote
me, he had already figured it out, but he wanted to convey to me that
what finally helped was actually the emerge output (which stated exactly
how to get thi
Diego 'Flameeyes' Pettenò wrote:
> I have a very quick proposal: why don't we move the packages' homepage
> in metadata.xml (since it's usually unique for all the versions) and we
> get rid of the variable for the next EAPI version?
For that matter, whatever is decided, why not include "DESCRIPTIO
Josh Saddler wrote:
> It takes time and effort to produce one of our polished, professional
> documents. That's duplicating the time and effort that it takes to write
> a decent wiki article -- pointless duplication.
>
> One of the things I'm hearing from just about every other user and
> develope
Mark Loeser wrote:
> What are others feelings on this? What issues do you see with having a
> wiki? Do you see anyway to resolve the issue you see with us having a
> wiki?
+1! I have set up several wikis for work projects and used many others
to great benefit. Even those (on my work projects)
Christoph Mende wrote:
> Well, the desktop is usually called Xfce4, plus that'd match gnome2...
> and more or less kde4
In general, it makes sense to me to have an unversioned one if there is no
version dependency - i.e. if xfce.eclass would likely work for future ones
(like "xfce5"). I'm not sur
Ryan Hill wrote:
> On Tue, 04 Nov 2008 13:43:55 -0500
> Joe Peterson <[EMAIL PROTECTED]> wrote:
>
>> Christoph Mende wrote:
>>> Now the most logical name for an eclass like that
>>> would be xfce4.eclass, except that eclass already exists.
>> Sinc
Christoph Mende wrote:
> Now the most logical name for an eclass like that
> would be xfce4.eclass, except that eclass already exists.
Since the new eclass is not version specific, how about simply "xfce.eclass"?
-Joe
Petteri Räty wrote:
> The names of eclasses aren't shown to users and I think figuring out a
> new name is a minor inconvenience so I would just go with the safe route.
I disagree: we should use care in choosing names, since these names will be
around for a long time. Using an ugly name might not
Michael Hammer wrote:
> * Doug Goldstein <[EMAIL PROTECTED]> [081031 15:53]:
>> If no one opposes, I say we redact this USE flag asap.
>
> ++
I was also wondering why kerberos was on by default - I definitely
approve of nuking it.
-Joe
# Joe Peterson <[EMAIL PROTECTED]> (23 Sep 2008)
# Masked for removal in 30 days (see bug #238442)
# Depends on old media-sound/slimserver
# Will bring back in a form that works with media-sound/squeezecenter
media-plugins/slimserver-alienbbc
# Joe Peterson <[EMAIL PROTECTED]> (22 Sep 2008)
# Masked for removal in 30 days (see bug #238442)
# Replaced by package: media-sound/squeezecenter
media-sound/slimserver
-Joe
Jeroen Roovers wrote:
>> Sorry if this answer can be found elsewhere, but if one has a proxy
>> maintainer (i.e. not a Gentoo dev) for a package, can/should this
>> person be added to metadata.xml? Is there a special tag for this? I
>> can certainly see this being helpful (so that person automati
Christian Faulhammer wrote:
> everyone working on bugs, please add all people from metadata.xml to
> the assignee or cc field, I regularly have to search for bugs where a
> team and I maintain a package because only the team has been added.
> Second, please use full atoms (cat-egory/package) in th
Ciaran McCreesh wrote:
> Except it doesn't. A virtual ebuild:
>
> * installs nothing
> * does nothing
I'd say that virtual does indeed do something: it pulls in other packages.
> * should be treated as being very quickly installable
> * should be treated as having zero cost for installs
>
> The
Marius Mauch wrote:
> First, regarding the news item, I'd suggest that instead of telling
> users to modify world_sets manually to use `emerge --noreplace @system`.
++
> Second for the suggestions on how to handle the transition:
> - treating 'world' and '@world' differently is a no go from my PO
Marius Mauch wrote:
> Not sure if 'live' is really the best choice here, as many things also
> apply to e.g. automated daily/nightly snapshots/builds that might also
> be useful to support. Maybe 'unversioned' is more accurate.
I think the most important thing to convey with this property is that
Marius Mauch wrote:
> If it's only used to indicate that the package doesn't install any
> files I'd suggest to use 'empty' or 'nocontents' instead. 'virtual'
> somehow implies that it's only applicable to packages in the 'virtual'
> category, which isn't the case with the given definition (as you
Ciaran McCreesh wrote:
> Users don't need to see it.
I cannot quite agree on that point. Given that Gentoo is a distro that
appeals to the more technically-oriented users, I personally believe
that what we expose as ebuild syntax is actually exposed to many users
fairly profoundly.
Zac Medico wrote:
>> Then change the name. Call it "zero-install-cost".
>
> I'm inclined toward "virtual" since it's more brief and I think it
> might strike a chord with more people because of their familiarity
> with the "virtual" category and old-style PROVIDE virtuals. We'll
> have to see what
Zac Medico wrote:
> Do the name and definition of this PROPERTIES=live value seem good?
> Would anybody like to discuss any changes to the name, definition,
> or both?
++
-Joe
Steve Long wrote:
>> @system == system
>> ...but...
>> @world != world
>>
>> This, I would think, could cause confusion too - and we'd have to live
>> with and document this "quirk".
>>
> I don't see that as major from a user pov; as soon as you see @ you're in
> set territory, which is for finer-g
Duncan wrote:
> That's an interesting idea. I don't personally care either way, as long
> as @world continues to /not/ include system/@system, but having world
> (without the @) continue to include system /would/ be useful for backward
> compatibility. I think it'd be much better in terms of e
Jeremy Olexa wrote:
> Also, devs willing to maintain
> packages but then later retiring and leaving the packages in limbo.
> Maybe there should be some policy such as, when devs retire if no one
> else steps up to maintain the package, then it automatically gets
> moved to sunrise overlay and only
Zac Medico wrote:
> Please consider the introduction of a new "PROPERTIES" variable to
> the ebuild metadata cache that's distributed via the rsync mirrors
> and resides locally in the ${PORTDIR}/metadata/cache/ directory.
> This variable is intended to have identical syntax to the existing
> RESTR
Zac Medico wrote:
> To simplify things, how about if we just do a
> PROPERTIES=live-src-unpack for now, to indicate exclusive access to
> $DISTDIR during src_unpack? Thats a simple and portable baseline
> that will be quite useful even without anything finer grained.
No need for a convoluted and l
Zac Medico wrote:
> Personally I think people are far too concerned about the name of
> the variable. I only see a what I consider to be a trivial or
> negligible benefit in separating these things into two different
> variables. However, it it makes more people happy then I guess I'm
> for it.
Di
Zac Medico wrote:
>> What you're missing is that only a specific subset of variables is
>> cached in /usr/portage/metadata/cache. Now that you mention it, we
>> could introduce a new variable called EBUILD_FLAGS and start caching
>> it in new versions of portage. It wouldn't necessarily require an
Vaeth wrote:
> The main point in introducing the "live" USE flag should be IMHO to
> let the user decide whether the sources should be fetched. The fact
> that IUSE then marks live ebuilds in the way which you wanted is an
> additional side effect.
A tend to agree with Zac that USE flags should no
Peter Volkov wrote:
> This means that every ebuild which uses 'unpack ${A}' should have in
> DEPEND a program which is selected by filename extension of sources. So
> as I understood your initial suggestion was to make this happen
> automatically. And this is very logical as makes ebuilds cleaner a
Marius Mauch wrote:
> The eclass also contains it's own implementation of unpack (renamed to
> unpack2) and src_unpack so the logic which tools/packages are used for
> unpacking can be maintained in a single place instead of being
> splitted between the package manager and the tree.
Marius, these
Petteri Räty wrote:
> I am saying that it makes sense to approve both at the same time or have
> other official package managers approved before accepting the GLEP.
In addition, I'd want to see why the particular approach suggested in this
GELP is the "only" way (as some seem to claim). I have y
Marijn Schouten (hkBst) wrote:
> I suppose you mean git. Since it tracks content and not files, moves are
> trivial. Git actually finds your moves for you, after you've moved content
> around; such as when doing a bump.
Even better!
-Joe
--
gentoo-dev@lists.gentoo.org mailing list
Donnie Berkholz wrote:
> I meant moves were largely pointless, although categories are to a
> lesser extent. Tags would be a lot better, since nothing can be
> categorized perfectly into a single place.
Yes, I can see the benefit of a tag paradigm. I, myself, find it more
trouble than benefit t
Donnie Berkholz wrote:
> I actually object to having crap in dev-python, because things should be
> categorized functionally instead of by the language they're implemented
> in. 90% of the time you don't care about the language. But category
> moves are pretty much pointless, so I don't normally
Tony "Chainsaw" Vroon wrote:
> The time I can spend
> trawling upstream sites for new releases is limited.
Same here - I would never mind getting a 0-day bump request, since
someone else might have noticed before I did that a new version is
available.
> Just an idea:
> How about a metadata.xml ta
Duncan wrote:
> Jim Ramsay <[EMAIL PROTECTED]> posted
> [EMAIL PROTECTED], excerpted below, on Mon, 16
> Jun 2008 08:34:01 -0400:
>
>> Well, this is true and it isn't... In the case of:
>>
>> ewarn line one
>> eblank
>> ewarn line two
>>
>> Obviously it would be the same as ewarn. However,
Benedikt Morbach wrote:
> On Sun, Jun 15, 2008 at 12:02 PM, Peter Volkov <[EMAIL PROTECTED]> wrote:
>> But speaking about names of options - -A and -B are easier to remember
>> as -A stands for above and -B for below and grep users already knew
>> that.
>
> for grep -A means after and -B before ;)
Ryan Hill wrote:
> (...I would change the suffix to -live, just because i
> hate the term "SCM" :P)
++ on using "live" and not the "scm" acronym (no matter which idea is
selected), especially since there are various different acronyms for
config mgmt (scm, cm...), and scm's meaning is less obvious
Peter Volkov wrote:
> Well for me .ebuild-eapi is much more confusing.
>
> I still don't see why it's impossible to have eapi as a part of name but
> not in extension...
Although putting EAPI in the name and not the extension is *slightly*
preferable to using the extension, I still do not think t
Richard Freeman wrote:
> On the other hand, this is a big change from the present, and I'm not
> convinced that it will actually be a big improvement over some of the
> other EAPI ideas being floated around. However, it is a
> potentially-neat idea...
Rich, interesting thoughts! But yeah, I a
Bernd Steinhauser wrote:
> And that is, what this is about, making EAPI bumps as less painful as
> possible. The filename is the easiest solution for that.
In any design, there are "easy" short-cuts that can be taken. But
sometimes these short-cuts break paradigms that are fundamental. If you
w
Richard Freeman wrote:
> Some object to parsing out the EAPI without sourcing the ebuild (only
> bash can source bash). I disagree with this argument - every time you
> run a shell script it is sourced by something other than bash - the
> kernel has to figure out what script interpreter to use
Fernando J. Pereda wrote:
> On 10 Jun 2008, at 15:33, Joe Peterson wrote:
>
>> Luca Barbato wrote:
>>> Check if exists a line EAPI=*$, if does and the rest of the string
>>> matches an understood eapi, go on sourcing, otherwise ignore/mask
>>> it...
>
Rémi Cardona wrote:
> Ciaran McCreesh a écrit :
>> Kills the upgrade path completely. No good.
>
> Lemme sum this up in layman's terms :
>
> 1) EAPI _has_ to be known before sourcing an ebuild. There's no way to
> avoid that for various reasons, all 100% valid.
>
> 2) Putting the EAPI in the fi
Jan Kundrát wrote:
> If the user knows that keywords are set by the KEYWORDS variable, then
> she must be familiar with the EAPI. The meaning of the KEYWORDS variable
> is defined by the EAPI.
But that's not really what I find objectionable. There's no need to
make EAPI so special that it alters
Luca Barbato wrote:
> Check if exists a line EAPI=*$, if does and the rest of the string
> matches an understood eapi, go on sourcing, otherwise ignore/mask it...
And placing it out-of-band (like "# EAPI=...") avoids any sourcing
errors, makes parsing faster, etc.
-Joe
--
Rémi Cardona wrote:
> Ciaran McCreesh a écrit :
>> picard_facepalm.jpg
>
> I don't think any of us are completely thrilled by either proposals, but
> the EAPI-in-a-separate-file does have the potential for more
> flexibility, ie package-wide EAPI.
>
> And it does keep filenames simple enough.
Ciaran McCreesh wrote:
> On Mon, 9 Jun 2008 22:35:25 -0700
> Donnie Berkholz <[EMAIL PROTECTED]> wrote:
>> Did anyone already propose specifying this in metadata.xml?
>
> Yup. That's a no-go, since metadata.xml is quite rightly treated as
> being "not suitable for anything the package manager real
Tiziano Müller wrote:
>>> And then how do we deal with EAPI 3, where the syntax changes again?
>> Portage (or whatever PM) reads the EAPI, determines it is 3, and goes
>> from there. If you change the way you declare EAPI each time, yeah,
>> that's a problem, but I'm not sure why that would ne nec
Ciaran McCreesh wrote:
> And a file extension is far less obscurely complex than enforcing
> arbitrary syntax restrictions upon ebuilds.
I disagree. One is exposed to devs only as ebuild syntax; the other is
exposed in an inappropriate location to everyone looking at the portage
tree.
> No it ca
Ciaran McCreesh wrote:
> On Mon, 09 Jun 2008 20:15:56 -0600
> Joe Peterson <[EMAIL PROTECTED]> wrote:
>> Yes, if everyone is perfect and remembers to do things perfectly
>> right, there would never be issues in many things, but when you make
>> something more complica
Ciaran McCreesh wrote:
> On Mon, 09 Jun 2008 19:49:08 -0600
> Joe Peterson <[EMAIL PROTECTED]> wrote:
>> I'm not saying it's a lot harder. But it is more complex and less
>> elegant. Also, it is error-prone. If someone, by habit, looks for
>> all &
[EMAIL PROTECTED] wrote:
>> 1) Increase of [needless] complexity in filenames/extensions (and only one
>> example of the impact is that searching for ebuild files becomes less
>> straightforward), when things like SLOT, EAPI, etc., etc., seem to
>> naturally belong as part of the script conte
Donnie Berkholz wrote:
> On 11:12 Sun 08 Jun , Piotr Jaroszyński wrote:
>> looks like every nominee wants the council to be more technical so I
>> have a few technical questions for you:
>>
>> 1. GLEP54
>> 2. GLEP55
>
> I don't have any particular objections to these, besides the vague
> aest
Vlastimil Babka wrote:
> I'd like to nominate:
>
> zmedico (Zac Medico)
Seconded.
-Joe
--
gentoo-dev@lists.gentoo.org mailing list
William L. Thomson Jr. wrote:
> On Sat, 2008-06-07 at 00:42 +0200, Vlastimil Babka wrote:
>> There could be also switch to add newline
>> before the message but I can't think of a use for it myself.
>> The question is how to name the switch :) "-n" could be confusing as
>> "echo -n" has the oppo
William L. Thomson Jr. wrote:
> On Wed, 2008-06-04 at 20:52 -0400, William L. Thomson Jr. wrote:
>> I think a more ideal solution, less drastic to implement might be
>> allowing 2 arguments to be passed. So you could do like
>>
>> elog "" "A blank line precedes this one"
>> elog "A blank line foll
William L. Thomson Jr. wrote:
> Just a quick thought looking over a couple ebuilds. It seems most times
> anyone does a error, elog, einfo, or similar. They start and end with a
> few blank lines. Calls with no arguments.
>
> Is there any reason not to make that a default? Other than difficulty of
Joe Peterson wrote:
> Has anyone volunteered to take net-misc/ntp? I know there are alternatives
> (like OpenNTPD), but this one is the "official" one, so I'd hate to see it
> slip into substandard quality. Also, e.g. OpenNTPD is a subset and is less
> accura
Has anyone volunteered to take net-misc/ntp? I know there are alternatives
(like OpenNTPD), but this one is the "official" one, so I'd hate to see it
slip into substandard quality. Also, e.g. OpenNTPD is a subset and is less
accurate, so it is not a complete replacement. I will take it on if no
Roy Marples wrote:
> The point is to remove the hard newline, which you've kept in your examples.
Roy, yes, I realized that after I emailed - at first I thought it was
remaining as an option. :)
-Joe
--
gentoo-dev@lists.gentoo.org mailing list
Roy Marples wrote:
> config_eth0="1.2.3.4 netmask 255.255.255.0
> 5.6.7.8 netmask 255.255.0.0"
> routes_eth0="1.2.4.0 netmask 255.255.255.0 gw 1.2.3.6
> 5.6.7.9 gw 5.6.7.10
> default gw 1.2.3.1"
If one choose to separate by lines, will tabs or spaces be allowed in
subsequent lines? Like:
config_
Ciaran McCreesh wrote:
> On Thu, 10 Apr 2008 17:37:31 -0700
> "Robin H. Johnson" <[EMAIL PROTECTED]> wrote:
>> That's why I setup them up with the ability to rsync it, and they
>> never got back to me on that, nor used it ever.
>
> Hrm, curious. They seem interested and alive currently. Perhaps it
Robert Buchholz wrote:
> Oh, and great to have you on the team.
I totally welcome Kenneth - I use Gentoo amd64 on a server at work
(mostly using stable keywords, of course). It's awesome to have a
64-bit OS to take advantage of our Core2 Quad, and it's great to have
yet another person here to kee
Ferris McCormick wrote:
> It is my pleasure to announce that after some arm twisting, Raúl Porcel
> (armin76) has accepted the previously open position of sparc Operations
> Manager. This is no real change since that's what he's been doing for
> us anyway.
Congrats Raúl!!
-Joe
--
gentoo
Steve Long wrote:
> My apologies if I caused you any offense, Joe. I fully agree that choosing
> not to have children is just as mature as deciding to procreate, and more
> mature than simply drifting into parenthood.
No offense taken, and I agree about the "drifting into" thing. My
wife's brothe
On Thu, Jan 17, 2008 at 10:56:36AM +, Steve Long wrote:
> Ryan Hill wrote:
>> I agree, though year of birth might be interesting. Income and children
>> are a bit too private.
>>
> ++ in general although I do think parenthood (if responsible) is as relevant
> as age. A 28 year old with a 5 yea
Denis Dupeyron wrote:
> It's my pleasure to introduce Ingmar Vanhassel (ingmar) as a new
> Gentoo developer. He will be on the KDE team, as he already has
> extensive experience with the KDE4 overlay. Quoting his mentor in his
> new-dev bug:
> "He has rewritten large parts of the KDE4 eclasses, sin
Denis Dupeyron wrote:
> Jean-Noël currently lives in Paris, France, but he studied in
> Vancouver, Canada for some time. He is 26 and happily married. Apart
> from computers, he has a passion for games (video, role-playing and
> boardgames), music (progressive metal & rock), and outdoors
> (especia
Denis Dupeyron wrote:
> So please everybody, give a warm welcome to Richard.
Richard, big welcome!
-Joe
--
[EMAIL PROTECTED] mailing list
1 - 100 of 136 matches
Mail list logo
