On Sun, 2005-04-03 at 03:02, Eric Spakman wrote:
> There is no rule for it and we are currently "mis-using" CVS all over
> the place :-)
Eric,
This should only be true in our devel/ and bin/ cvs modules.
We may be able to correct any problems when SF moves to SVN and opens
the new FRS SandBox.
> On Sun, 2005-04-03 at 06:48, Eric Wolzak wrote:
> > Hello Mike, the situation didn't change much what the time and energy
> > spent on
> > my job. But I now do some more computing in my spare time again :)
Eric,
Good to hear. :-)
> > The main problem with bering is the old Library, that isn'
On Sun, 2005-04-03 at 10:44, K.-P. KirchdÃrfer wrote:
> any chance you enable the FAQ section?
K.-P.,
Are you referring to the SF DocManager? If so, all of our DocManager
documents are in CVS. I monitor them for changes, and no one has touched
them in over a year.
http://cvs.sourceforge.net/viewc
Hi Mike;
any chance you enable the FAQ section?
I see there is a wiki planned, but until it's up a few very important
doc's for LEAF are missing.
kp
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundred
--- Forwarded message follows ---
Subject:Re: Bering Lead?
From: Mike Noyes <[EMAIL PROTECTED]>
To: Eric Wolzak <[EMAIL PROTECTED]>
Date sent: Sun, 03 Apr 2005 08:16:10 -0700
Eric,
Please post your reply to our leaf-devel
Hi Paul,
I understand your concerns, but the biggest problem with a toolchain
is that some configure and Makefiles in sources have hardcoded paths
in it to system libraries (or use libtool). Even with a toolchain it
is possible that sources can't be compiled or are "polluted" with
"leaking" librar
Hello Paul,
There is no rule for it and we are currently "mis-using" CVS all over
the place :-)
But I think putting init.d, default and action files directly in CVS
instead of a patch is much better, we do that for most packages. Take
a look at the different setups in CVS, you can use names li
Hello Paul,
The reason for this is that we have the possibility someday to chroot
in the bt_staging_dir. Once everything is build you have a fairly
complete distro and by chrooting or adding a kernel to it should be
possible to boot it and use it as a compile environment (after some
tweaking).
Sigh, I forgot, I already asked this question in Feburary, I just didn't
like the answer then so I forgot it...
K.-P. Kirchdörfer wrote:
> The long term idea by Arne or Martin has been to chroot into staging
> and run our own distro from there.
> I've asked myself, but then with all the problems
Hello Paul,
You can add the action.x files and the *_start file to
/var/lib/lrpkg/upnpd.list. The /etc/shorewall and
/etc/shorewall/start.d/ directories are owned by the shorewall
package so the other files in this directory should be saved by the
shorewall package itself. Look at the weblet p
In the upnpd package, I create several new files that are part of the
package and are LEAF environment specific. At first, I was keeping them
in a patch file, but that seems like I'm mis-using cvs. I think it
would be best to actually keep them as individual source files right in
CVS so peopl
I certainly understand why we copy the toolchain, libraries, and include
files into bt_staging_dir, but it seems somewhat bogus that we're doing
so for end-binaries (i.e. things that nothing else is ever going to
depend upon)...
Is there a reason for this? It seems that there was a change in t
12 matches
Mail list logo
