On Thu, 2002-07-11 at 16:12, Manfred Schuler wrote:
> I had a quick look at the enforce scripts.
Manfred,
Thanks for taking a look. :-)
Note: the enforce scripts were written by Jacob Moorman, and copied from
the sitedocs cvsroot. I modified the directory and permissions files for
our repository.
Mike Noyes schrieb:
>
> On Thu, 2002-07-11 at 14:21, Manfred Schuler wrote:
> > Mike Noyes schrieb:
> > > On Thu, 2002-07-11 at 07:51, Mike Noyes wrote:
> > > > Manfred,
> > > > I looked at this example again, and I think the sequence below is an
> > > > accepatble solution for it.
> > >
> > >
On Thursday 11 July 2002 14:36, Charles Steinkuehler wrote:
> > weblet runs script to gather all package conf files
>
> (/var/lib/lrpkg/*.conf files) to generate the configuration display
> component in weblet (to replace the hard coded one in the Dev Demo
> now)
We can add an init.d script to d
On Thu, 2002-07-11 at 14:21, Manfred Schuler wrote:
> Mike Noyes schrieb:
> > On Thu, 2002-07-11 at 07:51, Mike Noyes wrote:
> > > Manfred,
> > > I looked at this example again, and I think the sequence below is an
> > > accepatble solution for it.
> >
> > Here is a small but significant addition
> My message may have been a bit confusing. This is the weblet
"Richard" and this is for some changes I'm making to the weblet. The
only thing that needs to be generated on startup is the collection of
what packages are there, both all the genearal packages and any weblet
addons.
The packages a
Mike Noyes schrieb:
>
> On Thu, 2002-07-11 at 07:51, Mike Noyes wrote:
> > Manfred,
> > I looked at this example again, and I think the sequence below is an
> > accepatble solution for it.
>
> Here is a small but significant addition to this sequence. It will allow
> retrieval of the tree in i
On Thu, 2002-07-11 at 13:17, Manfred Schuler wrote:
> Comments inline
Manfred,
Thanks for the analysis. I'm glad I don't appear to be causing problems
in our repository.
> Mike Noyes schrieb:
> > [ 547717 ] CVS repository clean-up: leaf
> >
>https://sourceforge.net/tracker/index.php?func=detail
On Wed, 10 Jul 2002, Eric Spakman wrote:
[...]
> > Re: the value of uClibc...
> >
> > I think it is good that someone is doing this, but it is also good to be
> > clear that the gain in code size comes at a potential narrowing of
> > applicability due to incompatibility with glibc. For closed
Comments inline
Mike Noyes schrieb:
>
> On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote:
> > It is meant as a principle when working on large projects:
> > _NEVER_ change anything that is correctly checked in
>
> Manfred,
> Incorrectly checked in files/directories are candidates for SF
> I am looking at implementing the following sequence of events in a
redesign fo the weblet:
> (this is the weblet as we are now defining it, a web application that
is seperate from the underlying sh-httpd server)
> -
> system starts boot
Handled by syslinux...
> all pack
Thanks for the feedback!
From: Erich Titl [mailto:[EMAIL PROTECTED]]
Sent: Thu 7/11/2002 11:37 AM
>It will be great to have that much autoconfiguration in the 'weblet'.
>Do you think it would be a big overhead to run this 'real time' e.g. when
>the dashboard is requested. That way even
Question:
I am looking at implementing the following sequence of events in a redesign fo the
weblet:
(this is the weblet as we are now defining it, a web application that is seperate from
the underlying sh-httpd server)
-
system starts boot
all packages finish
Mike Noyes schrieb:
>
> On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote:
> > Mike,
> >
> > I did _NOT_ at all want to criticize the staff at SF.
> > I know about them only what I see on the list, so I'm
> > not in a position to judge how they do their job.
>
> Manfred,
> I apologize for the
On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote:
> It is meant as a principle when working on large projects:
> _NEVER_ change anything that is correctly checked in
Manfred,
Incorrectly checked in files/directories are candidates for SF staff cvs
repository clean-up support requests (SR)
On Thu, 2002-07-11 at 07:51, Mike Noyes wrote:
> Manfred,
> I looked at this example again, and I think the sequence below is an
> accepatble solution for it.
Here is a small but significant addition to this sequence. It will allow
retrieval of the tree in its 1.0 state.
$ cvs -q tag R_1_0
> $ c
On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote:
> I think I didn't express clearly what I mean.
>
> It is meant as a principle when working on large projects:
> _NEVER_ change anything that is correctly checked in
>
> I will give you an example of what I mean:
>
> In version 1.0 of pa
On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote:
> Mike,
>
> I did _NOT_ at all want to criticize the staff at SF.
> I know about them only what I see on the list, so I'm
> not in a position to judge how they do their job.
Manfred,
I apologize for the tone of my last message. It was inappropr
Mike,
I did _NOT_ at all want to criticize the staff at SF.
I know about them only what I see on the list, so I'm
not in a position to judge how they do their job.
I think I didn't express clearly what I mean.
It is meant as a principle when working on large projects:
_NEVER_ change any
On Thu, 2002-07-11 at 03:56, Manfred Schuler wrote:
> Mike Noyes schrieb:
> > If we had shell access to the repository, we would hand edit the
> > structure change. SF doesn't allow us shell access to the cvs server, so
> > we need to open SF support requests to make changes like this.
> >
> > re
Mike Noyes schrieb:
[snip]
> > What happens when I decide that /usr/sbin/ntp_setup actually belongs
> > /usr/bin/ntp_setup? Or, /usr/sbin/ntp_setup becomes /usr/bin/setup_ntp?
> >
> > Clearly, cvs cannot know my intent, in this regard. When committing a
> > directory change, under this scena
20 matches
Mail list logo
