[I believe we should go off-line if you're interested in continuing this
discussion, since it has very little to do with plan9port at this point.
I'll reply to the portion that has relevance on the list here, and will
reply to the rest of your email privately]
On Mon, 2008-11-03 at 01:15 +0100, En
On Mon, 2008-11-03 at 01:15 +0100, Enrico Weigelt wrote:
> * Roman Shaposhnik <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> > >Besides the fact that I'm not making binary packages at all,
> > >splitted / small sources make packaging a lot easier.
> >
> > So let me get this straight: you're trying to s
* Roman Shaposhnik <[EMAIL PROTECTED]> wrote:
Hi,
> >Besides the fact that I'm not making binary packages at all,
> >splitted / small sources make packaging a lot easier.
>
> So let me get this straight: you're trying to solve a problem
> that you don't have, right?
No, I got a problem to be s
On Nov 1, 2008, at 12:05 PM, Enrico Weigelt wrote:
I really fail to see what is your problem here. There's no
rule that source code repository has to correspond 1-1
to the binary package. In fact, it is quite common
to use a single repository for producing a number of
different binary packages.
* Roman V. Shaposhnik <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-10-30 at 19:07 +0100, Enrico Weigelt wrote:
> > Hi folks,
> >
> >
> > I'd like to vote against feeding up p9p with more things,
> > instead split it up into smaller pieces. Modern distros tend
> > to have quite convenient package ma
On Thu, 2008-10-30 at 19:07 +0100, Enrico Weigelt wrote:
> Hi folks,
>
>
> I'd like to vote against feeding up p9p with more things,
> instead split it up into smaller pieces. Modern distros tend
> to have quite convenient package management systems ;-p
I really fail to see what is your problem
Hi folks,
I'd like to vote against feeding up p9p with more things,
instead split it up into smaller pieces. Modern distros tend
to have quite convenient package management systems ;-p
I've did a few steps in this direction (but due lack of time
not finished yet :().
cu
--
-
> Thus, I was thinking that perhaps if you could
> lay the ground rules for how new things could
> be added to your canonical plan9port tree these
> little annoyances could be dealt with.
The ground rules are: you make it work with as
few changes as possible from the Plan 9 original,
and then you
On Sat, 2008-10-18 at 10:20 -0700, Russ Cox wrote:
> > Hence the question -- would you be in favor
> > of continue adding things as needed. And
> > if so, what kind of of groundwork would
> > you expect from the contributors?
>
> Usually it is as simple as adding it to your own tree,
> adapting th
> Hence the question -- would you be in favor
> of continue adding things as needed. And
> if so, what kind of of groundwork would
> you expect from the contributors?
Usually it is as simple as adding it to your own tree,
adapting the mkfile, and making it build.
U9fs is somewhat special since it
Hi Russ!
First of all -- thanks a lot for answering.
On Mon, 2008-10-06 at 09:24 -0700, Russ Cox wrote:
> > somehow it dawned on me that plan9port lacks
> > an application to serve a local filesystem
> > over 9P. Is this on purpose? Am I missing
> > something fundamental that would allow
> > for
On Tue, Oct 7, 2008 at 12:24 AM, Russ Cox <[EMAIL PROTECTED]> wrote:
>Roman Shaposhnik wrote:
>> somehow it dawned on me that plan9port lacks
>> an application to serve a local filesystem
>> over 9P. Is this on purpose?
>
> I pull things in as they are needed.
> I have not needed to serve 9P.
Thi
> somehow it dawned on me that plan9port lacks
> an application to serve a local filesystem
> over 9P. Is this on purpose? Am I missing
> something fundamental that would allow
> for a moral equivalent of exportfs?
I pull things in as they are needed.
I have not needed to serve 9P.
Adding u9fs sou
13 matches
Mail list logo
