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
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_
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
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
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
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
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:
> 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
Vlastimil Babka wrote:
> I'd like to nominate:
>
> zmedico (Zac Medico)
Seconded.
-Joe
--
gentoo-dev@lists.gentoo.org mailing list
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
[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
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 &
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:
> 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
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:
> 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
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.
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
--
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
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
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...
>
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
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:
> 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
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
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
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 ;)
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,
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
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
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
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
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
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
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
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
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
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:
> 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:
> 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
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
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
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
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
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
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.
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
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:
> 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
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
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
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
# 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
# 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
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
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
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
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:
> 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
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)
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
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
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
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
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
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
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).
>
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
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
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.
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
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
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
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
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. :)
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
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
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
>>
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?
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
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
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
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
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
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.
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
# 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
Michael Cummings wrote:
>>http://pluto.jhuapl.edu/
>
> Two thoughts come to mind of course. First and foremost is the quote
> from 2010 (Arthur C. Clarke, movie adaption), "All these worlds belong
> to you except Europa." Strike one (there's a photo of Europa from the
> fly-by).
Whew, it's lu
Davide, many thanks! Good to be here!
-Joe
Davide Cendron wrote:
> Il Thursday 31 May 2007 18:22:41 Petteri Räty ha scritto:
>> It's my usual pleasure to announce some new blood coming in to replace
>> some of the old going away. Joe is joining us from Lafayette, CO, USA to
>> help with
Welcome Ali! And no, I don't think I will challenge you in chess any
time soon. :)
-Joe
Petteri Räty wrote:
> It's my usual pleasure to introduce to you Ali "hawking" Polatel who
> will be joining us to help with the netmon stuff. Ali hails us from
> Turkey. He is currently a physics e
This sounds promising. One problem I see, however, is that this would
require announcements to get posted to *both* lists and for people to
remember this rule. Posting only to "-dev", of course, makes sense, but
posting only to "-dev-announce" would cause strangeness (as all devs who
want more ma
Donnie Berkholz wrote:
> On Thu, 12 Jul 2007 18:41:33 -0700
> Daniel Ostrow <[EMAIL PROTECTED]> wrote:
>> 1). Create 1 (ONE) new list, which, for the purposes of this
>> discussion I will call it gentoo-dev-info (the name matters not). The
>> requirement for subscription for all devs would shift fr
Kumba wrote:
> George Prowse wrote:
>> So that would mean that welcoming new developers would be on the
>> -project list?
>
> My thinking, I think they would fit better over there, since it is somewhat
> non-technical. However, machine-generated notices of dev arrival or dev
> departure could
Duncan wrote:
> Philip Webb <[EMAIL PROTECTED]> posted:
>> To this user since 2003, who plans to install Gentoo in the new machine
>> which I am presently designing, this sounds like a very welcome
>> development. I shall continue to subscribe to -dev , but not to
>> -project. Should I also subscri
Duncan wrote:
> The idea is this. For non-tech posts, X-post the /first/ post, the
> announcement of the idea (for new devs, nominations, etc, to both dev and
> dev-announce), so those only paying attention to dev know about it. Set
> the followup to project (not dev). Those who wish to discu
Piotr Jaroszyński wrote:
> We need to update docs or harass zmedico to force PDEPEND to be pulled as
> soon
> as possible but not before the pkg that pulls it.
There is another problem with PDEPEND that I've run into: if you are
doing an emerge that fails some time after the package containing t
Welcome, Jason!
-Joe
Christian Heim wrote:
> It's my pleasure to introduce to you Jason Smathers (also known as jsin on
> IRC), our latest addition joining the net-ftp herd.
>
> Jason is joining us from Avon (that's supposed to be in Indiana) where he's
> his own boss as a freelance en
And welcome to you too!
-Joe
Christian Heim wrote:
>
> It's my pleasure to introduce to you Christian Hoffmann (also known as hoffie
> on IRC), our latest addition joining the PHP herd.
>
> Christian is joining us from Bamberg (which is about 60km north of Nuremberg,
> which happens t
Ulrich Mueller wrote:
>> On Sun, 19 Aug 2007, Christian Faulhammer wrote:
>> Christian Heim <[EMAIL PROTECTED]>:
>>> Christian is joining us [...]
>
> This finally makes Christian the most common first name of Gentoo devs:
That settles it... No more "Cup o' Joe", "Any old Joe", etc. It's "C
Christian Heim wrote:
> - media-sound/slimserver (twp)
> - media-sound/softsqueeze (twp)
I'll take these!
-Joe
--
[EMAIL PROTECTED] mailing list
1 - 100 of 136 matches
Mail list logo
