Hi folks
I have multiple LEAF systems on the same hardware booting from the same
medium. This requires the use of different initrd files, I call the
secondary file initrd2.lrp. In the backup menu this is displayed
correctly whereas in the /var/lib/lrpkg directory the corresponding
files are still
Hi Erich,
The question is, how useful is it to backup initrd? Life could be
made very easy when the option to backup initrd is removed. There are
different initrd packages which makes booting of of most systems
possible (floppy, usb, cdrom and hd) and if anything is missing a new
initrd can
Hi Eric
Eric Spakman wrote:
Hi Erich,
The question is, how useful is it to backup initrd? Life could be
made very easy when the option to backup initrd is removed. There are
different initrd packages which makes booting of of most systems
possible (floppy, usb, cdrom and hd) and if
Hi Erich,
The question is, how useful is it to backup initrd? Life could be
made very easy when the option to backup initrd is removed. There are
different initrd packages which makes booting of of most systems
possible (floppy, usb, cdrom and hd) and if anything is missing a new
initrd
Hi Eric
Eric Spakman wrote:
Hi Erich,
The question is, how useful is it to backup initrd? Life could be
made very easy when the option to backup initrd is removed. There are
different initrd packages which makes booting of of most systems
possible (floppy, usb, cdrom and hd) and if
Hello Erich,
That's what I meant ;-)
If that option is removed, the initrd can also made smaller, because
the code needed to backup (mkfs.minix) can be removed.
I believe this would be the best solution. I have no problem custom
tailoring my initrd, but for the average user it might be
Eric Spakman wrote:
There currently aren't any release tags unfortuanatly. But everything in
CVS is exactly 2.4.1, so if you build buildenv you would have version
2.4.1.
Just to clarify - the main reason that there releases aren't tagged in
CVS was not simply because of oversight, but because
Martin
Martin Hejl wrote:
Eric Spakman wrote:
There currently aren't any release tags unfortuanatly. But everything in
CVS is exactly 2.4.1, so if you build buildenv you would have version
2.4.1.
Just to clarify - the main reason that there releases aren't tagged in
CVS was not simply
Hi Erich,
Thanks for the clarification. The release tags would not hurt though.
Sure.
When making a checkout from CVS, remember to use a SF developer account
- synching between the real CVS server and the backup server (which is
used for anonymous access) still doesn't seem to work (I infer
Martin Hejl wrote:
Hi Erich,
Thanks for the clarification. The release tags would not hurt though.
Sure.
When making a checkout from CVS, remember to use a SF developer account
- synching between the real CVS server and the backup server (which is
used for anonymous access) still
Subject was: Re: [leaf-devel] Glitch in initrd backup when using
alternative initrdfile
On Fri, 2006-05-05 at 02:58, Eric Spakman wrote:
How does one to go about building the buildenv for a specific release,
e.g. does CVS have release tags? For example, if I wanted to have a
buildenv which
Hi Mike,
The Bering-uClibc team will make a snapshot of the current tree and put
the sources in a tarball in the File release area.
Eric,
Please reconsider this decision. Tagging the release in cvs is easier.
http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_4.html#SEC48
If this is easier to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Hejl wrote:
Eric Spakman wrote:
There currently aren't any release tags unfortuanatly. But everything in
CVS is exactly 2.4.1, so if you build buildenv you would have version
2.4.1.
Just to clarify - the main reason that there releases
Hi Mike,
Mike Noyes wrote:
Subject was: Re: [leaf-devel] Glitch in initrd backup when using
alternative initrdfile
On Fri, 2006-05-05 at 02:58, Eric Spakman wrote:
How does one to go about building the buildenv for a specific release,
e.g. does CVS have release tags? For example, if I
On Fri, 2006-05-05 at 09:10, Martin Hejl wrote:
Mike Noyes wrote:
Tagging the release in cvs is easier.
http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_4.html#SEC48
Adding the tag is not the problem.
Martin,
Agreed, and this is probably causing me confusion.
Updating buildtool
Martin
Martin Hejl wrote:
..
Adding the tag is not the problem. Updating buildtool to use the
tag/branch is. That's why creating a snapshot of a buildenv base (all
the sources downloaded, but nothing compiled yet) is much easier for us
than tagging the release, creating a maintenance branch (up
Hi Mike;
Am Freitag, 5. Mai 2006 19:24 schrieb Mike Noyes:
On Fri, 2006-05-05 at 09:10, Martin Hejl wrote:
Mike Noyes wrote:
Tagging the release in cvs is easier.
http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_4.html#SEC48
Adding the tag is not the problem.
Martin,
Hi Erich,
I assume the code within buildtool to access a certain file is pretty
central. How difficult is it for this piece of code to use an
environment variable specifying a TAG (defaulting to HEAD).
It is, but that doesn't solve the problem. The idea behind buildtool is
that it can use
Hi again,
Martin Hejl wrote:
* Check out src/bering-uclibc/buildtool for the release branch of 2.4.1
* check out src/bering-uclibc/apps for the release branch of 2.4.1
* modify cvs-sourceforge use the file target for server
cvs-sourceforge and make it point to the cvs checkout of
Hi Charles,
This might be one benefit to subversion.
It might be (I don't know, I've not used subversion so far). But the
problem I see for buildtool is not so much that it's too hard to fetch a
file for a specific branch, but rather that buildtool currently isn't
fetching anything other than
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Hejl wrote:
Hi Erich,
I assume the code within buildtool to access a certain file is pretty
central. How difficult is it for this piece of code to use an
environment variable specifying a TAG (defaulting to HEAD).
It is, but that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin Hejl wrote:
Hi Charles,
This might be one benefit to subversion.
It might be (I don't know, I've not used subversion so far). But the
problem I see for buildtool is not so much that it's too hard to fetch a
file for a specific branch,
Hi Charles,
This is where subversion's branching would really shine. You would
simply change the repository URL in the main config file and 'head'
would point to the latest version of that branch, which is probably what
you'd want (ie: security updates/bug fixes included).
Ah, ok, I get it.
Hi Charles,
You don't understand how subversion works.
I never claimed otherwise ;-)
It's like a file-system and
making a tag or branch is like copying a directory. Everything
underneath is copied too.
Well, to me, the way things are stored in the backend are pretty much
meaningless
On Fri, 2006-05-05 at 13:17, Martin Hejl wrote:
Ideally, building from a local working-copy of the repository will be
fairly easy (it sounds like this is getting tested RealSoonNow). This
would separate download problems from actually building the source
(possibly important for those with
25 matches
Mail list logo
