Can't get buildtool to work..

[Adam Niedzwiedzki]

Resend, I couldn't attach the zip'd logfile (it can be gotten from
http://www.genis-x.net/buildtoollog.zip)

Hi guys,

I've been pulling my hair out trying to get buildtool to work, I have no
idea where do go from here, but here is what I'm doing.

I did a fresh install of debian using debian-40r0-i386-netinst.iso
Then just the following as root
apt-get install gcc-3.4
apt-get install make
apt-get install patch
apt-get install cvs
apt-get install bzip2
apt-get install libconfig-general-perl
apt-get install cvs

Then a simple adduser leaf
Login as user leaf via ssh

Then
cvs -d :pserver:anonymous@...:/cvsroot/leaf login cvs
-z3 -d :pserver:anonymous@...:/cvsroot/leaf \
  co src/bering-uclibc/buildtool

updated /home/leaf/src/bering-uclibc/buildtool/make/MasterInclude.mk
change HOSTCC=gcc-3.4

then went
/home/leaf/src/bering-uclibc/buildtool/buildtool.pl build buildenv

Things hum along nicely until it all goes belly up (I've tried so many
different things it seems to die at this part everytime) I've manually
checked everything in /home/leaf/src/bering-uclibc/buildtool/source/buildenv
(tar -tzvf and tar -tjvf etc) and all checks out.

I have attached my buildtool log..

Anyone have any ideas how to fix this?

It's like it's not following
/home/leaf/src/bering-uclibc/buildtool/source/buildenv/buildtool.mk at all
it handles binuntils fine then totally skips gcc and goes on with uClibc
it's just doesn't make any sense..

Cheers
Ad


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Martin Hejl]

Adam Niedzwiedzki wrote:
> Resend, I couldn't attach the zip'd logfile (it can be gotten from
> http://www.genis-x.net/buildtoollog.zip)
tried it on Centos 5, and it works fine without any problems (well, I
temporarily had to replace gcc 4.1 with gcc 3.x, but that's a known
issue, and I think it's also documented).
Not that it working on Centos helps you a great deal, but it suggests
it's something debian related.

> It's like it's not following
> /home/leaf/src/bering-uclibc/buildtool/source/buildenv/buildtool.mk at all
> it handles binuntils fine then totally skips gcc and goes on with uClibc
Not quite. It's doing the stuff that's part of "./buildtool.pl source"
for uclibc - and that causes the host gcc to be invoked, which can't be
found, hence make quits.

What does "which gcc" say on your box (as user leaf)? It seems to me
like there's no gcc in the path of user leaf on your box.

Martin



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Erich Titl]

Hi Folks

Has anyone attempted to build the eql_enslave program? I have not been
able to find it in the packages.

If not, I will just go forward and build it.

Thanks

Erich

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Adam Niedzwiedzki]

Hi Martin,

Tried all that :(

leaf@debian:~/src/bering-uclibc/buildtool$ which gcc
/usr/bin/gcc
leaf@debian:~/src/bering-uclibc/buildtool$ gcc --version
gcc (GCC) 3.4.6 (Debian 3.4.6-5)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

gcc is mapped correctly, but buildtool still dies

-----Original Message-----
From: leaf-devel-bounces@...
[mailto:leaf-devel-bounces@...] On Behalf Of Martin Hejl
Sent: Wednesday, 1 August 2007 2:59 AM
To: leaf-devel@...
Subject: Re: [leaf-devel] Can't get buildtool to work..



Adam Niedzwiedzki wrote:
> Resend, I couldn't attach the zip'd logfile (it can be gotten from
> http://www.genis-x.net/buildtoollog.zip)
tried it on Centos 5, and it works fine without any problems (well, I
temporarily had to replace gcc 4.1 with gcc 3.x, but that's a known
issue, and I think it's also documented).
Not that it working on Centos helps you a great deal, but it suggests
it's something debian related.

> It's like it's not following
> /home/leaf/src/bering-uclibc/buildtool/source/buildenv/buildtool.mk at all
> it handles binuntils fine then totally skips gcc and goes on with uClibc
Not quite. It's doing the stuff that's part of "./buildtool.pl source"
for uclibc - and that causes the host gcc to be invoked, which can't be
found, hence make quits.

What does "which gcc" say on your box (as user leaf)? It seems to me
like there's no gcc in the path of user leaf on your box.

Martin



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Erich Titl]

Hi everybody

I built eql_enslave for a 2.4.34/uClibc based LEAF and wrapped it in a
package called eqltools (well eqltool would have been sufficient, but I
only learnt later that eql_emancipate was never written :-( )

Now the question, I am apparently a bit too dense to understand the CVS
setup for bering-uClibc.

What _exactly_ do I have to do to to contribute it correctly. I have had
limited success with the r1000 module I contributed.

Also I have an updated version of the r1000 module, also for
2.4.34/uClibc based LEAF. It is tested by one user and appears to
perform better than the previous one. I would like to update it in the
_correct_ place.

Also it would be nice if the community could profit from this kind of
contribution, as r1000.o did not show up anyplace in the current images.

Thanks for info

Erich

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[KP Kirchdoerfer-2]

On Thursday 02 August 2007 08:33:04 Adam Niedzwiedzki wrote:

> Hi Martin,
>
> Tried all that :(
>
> leaf@debian:~/src/bering-uclibc/buildtool$ which gcc
> /usr/bin/gcc
> leaf@debian:~/src/bering-uclibc/buildtool$ gcc --version
> gcc (GCC) 3.4.6 (Debian 3.4.6-5)
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> gcc is mapped correctly, but buildtool still dies
>
> -----Original Message-----
> From: leaf-devel-bounces@...
> [mailto:leaf-devel-bounces@...] On Behalf Of Martin Hejl
> Sent: Wednesday, 1 August 2007 2:59 AM
> To: leaf-devel@...
> Subject: Re: [leaf-devel] Can't get buildtool to work..
>
> Adam Niedzwiedzki wrote:
> > Resend, I couldn't attach the zip'd logfile (it can be gotten from
> > http://www.genis-x.net/buildtoollog.zip)
>
> tried it on Centos 5, and it works fine without any problems (well, I
> temporarily had to replace gcc 4.1 with gcc 3.x, but that's a known
> issue, and I think it's also documented).
> Not that it working on Centos helps you a great deal, but it suggests
> it's something debian related.
>
> > It's like it's not following
> > /home/leaf/src/bering-uclibc/buildtool/source/buildenv/buildtool.mk at
> > all it handles binuntils fine then totally skips gcc and goes on with
> > uClibc
>
> Not quite. It's doing the stuff that's part of "./buildtool.pl source"
> for uclibc - and that causes the host gcc to be invoked, which can't be
> found, hence make quits.
>
> What does "which gcc" say on your box (as user leaf)? It seems to me
> like there's no gcc in the path of user leaf on your box.
>
> Martin
>

Hi;

Martin's question helped me to get it up and running in a VM with Debian 4
iso-image.

My previous fault has been that I didn't install gcc, but only gcc-3.3.3. So I
had no link any gcc.

I removed gcc-3.3.3 - installed gcc, and added gcc-3.3.3 again. Removed the
old buildtool directories. Then I've finally been able to build the buildenv.

So I suggest you may start from scratch again. It is working :)

kp

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Martin Hejl]

Hi Erich,

> Now the question, I am apparently a bit too dense to understand the CVS
> setup for bering-uClibc.
>
> What _exactly_ do I have to do to to contribute it correctly. I have had
> limited success with the r1000 module I contributed.
Sorry for the late reply.

For the sources, it's quite simple, as long as you stay away from CVS
import. You may skip the first step if you already have a checkout that
contains src/bering-uclibc/contrib - just make sure you run
"cvs update -d" to make sure it's fully up to date.

For binaries (modules or lrp files), the approach is the same, just for
a different directory - for lrp files, it's
bin/packages/uclibc-0.9/28/contrib - but I don't know where modules
would go - you'll have to ask Eric on how that should be handled.

* cvs -z3 -d:ext:developername@...:/cvsroot/leaf \
   co src/bering-uclibc/contrib
* cd src/bering-uclibc/contrib
* mkdir yourNewPackageDir
* cvs add yourNewPackageDir
* cp yourfiles yourNewPackageDir/
* check that only the files you want to add to cvs ended up in
  yourNewPackageDir/ (no backup files created by editors, for example)
* cvs add yourNewPackageDir/*
* cvs commit yourNewPackageDir
* to check if everything was checked in, run
   "cvs update yourNewPackageDir" - if there are files prefixed with "?"
   in the output of the command, those didn't get checked in

Note - "cvs add" doesn't work recursively, so if "yourfiles" contains
directories, their contents have to be added separately.
In general, be careful not to add directories by mistake - directories
added by mistake have to be removed by SF staff, we have no way of
removing them ourselves.

That's it - a little more typing than using "cvs import", but this way,
you can be sure things end up in the right place (and there's less
chance of accidentally checking in temporary files).

I hope that helps,

Martin


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Erich Titl]

Hi Martin

Martin Hejl schrieb:
> Hi Erich,
>
...

> Sorry for the late reply.

Ahhh... no sweat

>
> For the sources, it's quite simple, as long as you stay away from CVS
> import. You may skip the first step if you already have a checkout that
> contains src/bering-uclibc/contrib - just make sure you run
> "cvs update -d" to make sure it's fully up to date.
>
> For binaries (modules or lrp files), the approach is the same, just for
> a different directory - for lrp files, it's
> bin/packages/uclibc-0.9/28/contrib - but I don't know where modules
> would go - you'll have to ask Eric on how that should be handled.
>
> * cvs -z3 -d:ext:developername@...:/cvsroot/leaf \
>    co src/bering-uclibc/contrib
> * cd src/bering-uclibc/contrib
> * mkdir yourNewPackageDir
> * cvs add yourNewPackageDir
> * cp yourfiles yourNewPackageDir/
> * check that only the files you want to add to cvs ended up in
>   yourNewPackageDir/ (no backup files created by editors, for example)
> * cvs add yourNewPackageDir/*
> * cvs commit yourNewPackageDir
> * to check if everything was checked in, run
>    "cvs update yourNewPackageDir" - if there are files prefixed with "?"
>    in the output of the command, those didn't get checked in

Thank you, the biggest problem was to find the correct place for a
module, in this case the r1000 thing. I don't know if a module sent to
contrib gets included into the lib/modules tree/tarball. I don't mind
maintaining it myself, it might just make life easier for everyone if I
don't have to send it to the people that have this hardware but do not
get involved in the compile business.

>
> Note - "cvs add" doesn't work recursively, so if "yourfiles" contains
> directories, their contents have to be added separately.
> In general, be careful not to add directories by mistake - directories
> added by mistake have to be removed by SF staff, we have no way of
> removing them ourselves.

Yes I ran into this one. I was running CVS myself for a number of years
and having admin access makes life a lot easier.

>
> That's it - a little more typing than using "cvs import", but this way,
> you can be sure things end up in the right place (and there's less
> chance of accidentally checking in temporary files).

Indeed. would you guys be thinking about a hierarchically flat CVS which
holds a complete tree of the development environment? Having read lately
about trouble getting the buildenv set up convinces me that a flat CVS
could lower maintenance effort. I understand the idea of keeping the
various sources apart, but the latest development in the GPL appears to
make it mandatory to keep sources of everything anyway, so we cannot
rely on external repositories. I believe it would also be easier to
handle comprehensive versioning as everything may depend on a certain
version of the development environment.

Thanks

Erich


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Martin Hejl]

Hi Erich,

> Thank you, the biggest problem was to find the correct place for a
> module, in this case the r1000 thing. I don't know if a module sent to
> contrib gets included into the lib/modules tree/tarball.
Not as far as I know. Eric might be able to help with that.

> would you guys be thinking about a hierarchically flat CVS which
> holds a complete tree of the development environment?
I'm not sure what exactly you're suggesting - do you mean we should
check in the whole /stuff/sourceforge/src/bering-uclibc/buildtool tree
(including source, build and staging) from a box that has build
everything available? If so, I don't understand what is "hierarchically
flat" about that - but we'd surely burn a lot of disk-space on the SF
servers...
Or do you suggest we'd check in the
/stuff/sourceforge/src/bering-uclibc/buildtool/source tree (with
everything unpacked)? That has been suggested in the past (or something
along those lines), since it would make it easier to see what changed
between releases. But I like the "upstream tarball + patches" approach,
since it makes it easier to remove a patch, once it's no longer needed.
Besides, that would not fix most of the problems people have (since most
of the time, they're due to incompabilities between the source being
compiled, and the toolchain on the host computer).

> Having read lately
> about trouble getting the buildenv set up convinces me that a flat CVS
> could lower maintenance effort.
Possibly - at the price of adding support issues in other places (if I
understand your suggestion correctly).
The problems we're having with buildtool (at least the latest ones) have
little to do with keeping the sources apart, and much more to do with
changes in the tool-chain (ubuntu ships a different gcc,libs,kernel
headers than RHEL than debian and so on).
But maybe I'm misunderstanding your suggestion - please clarify if you
think that might be the case.

> I understand the idea of keeping the
> various sources apart, but the latest development in the GPL appears to
> make it mandatory to keep sources of everything anyway, so we cannot
> rely on external repositories.
We don't, as far as I can tell - apart from a few sources, like the
kernel and gcc (I agree that we should probably keep those in cvs as
well). In short, we already keep the sources of everything (minus kernel
and gcc) already.

> I believe it would also be easier to
> handle comprehensive versioning as everything may depend on a certain
> version of the development environment.
Not so far (but it is a possibility this may happen) - so far, we try
our best to make sure that a checkout of the buildenv for a given
timestamp works with a checkout of everything else for a given timestamp
- so basically, that versioning is already in place.

Again, maybe I'm misunderstanding what you're suggesting - but if I'm
not, it would make life harder for the people who actually use the
buildenv to develop new packages regularly (since an update to cvs might
break something the next time they do "cvs update"), while it would
surely help those who just want an up to date buildenv quickly, to
compile something.

There has been work on getting a vmware (or something similar) image
that provides a buildenv - would that help? I guess it's not finished
yet, as always, due to the lack of extra time available.

There's even been work on setting up a self-contained uclibc-only vmware
image (would be cool for those troublesome sources that insist on
linking against the host libs, no matter what you do), but that has died
half way, due to lack of time. And basically, I don't think that's the
way to go, since we should work on fixing the sources, to make them be
able to handle a cross compile.

In short - a lot has been tried to make the process of getting a working
buildenv easier - but so far, it all died half way, before the point
where it could be given to the people who are having a hard time setting
up a build environment. And all that comes down to lack of manpower - if
there were a handful of people working on just that task, it would be
doable. But as long there's only a handful of developers on the whole
project, I don't see it happen (unless somebody who really wants that
fixed picks up the ball and does it).

Just my thoughts - I'm not speaking for anybody but myself.

Martin



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Erich Titl]

Hi Martin

Thanks for your reply.

Martin Hejl schrieb:
> Hi Erich,
>
...

> I'm not sure what exactly you're suggesting - do you mean we should
> check in the whole /stuff/sourceforge/src/bering-uclibc/buildtool tree
> (including source, build and staging) from a box that has build
> everything available? If so, I don't understand what is "hierarchically
> flat" about that

Sorry, my wording is misleading, single tree would be the term, I believe.

- but we'd surely burn a lot of disk-space on the SF
> servers...

We would indeed, but hardly more than we do right now.

> Or do you suggest we'd check in the
> /stuff/sourceforge/src/bering-uclibc/buildtool/source tree (with
> everything unpacked)? That has been suggested in the past (or something
> along those lines), since it would make it easier to see what changed
> between releases. But I like the "upstream tarball + patches" approach,
> since it makes it easier to remove a patch, once it's no longer needed.
> Besides, that would not fix most of the problems people have (since most
> of the time, they're due to incompabilities between the source being
> compiled, and the toolchain on the host computer).

We would need the toolchain along with the source.

>
>> Having read lately
>> about trouble getting the buildenv set up convinces me that a flat CVS
>> could lower maintenance effort.
> Possibly - at the price of adding support issues in other places (if I
> understand your suggestion correctly).

Possibly, but I could not really fathom this

> The problems we're having with buildtool (at least the latest ones) have
> little to do with keeping the sources apart, and much more to do with
> changes in the tool-chain (ubuntu ships a different gcc,libs,kernel
> headers than RHEL than debian and so on).
> But maybe I'm misunderstanding your suggestion - please clarify if you
> think that might be the case.

Mhhh.. maybe I am underestimating the issues with the toolchain. I was
under the impression that most of the stuff is perl anyway, so at least
partly portable. I _believe_ also, that a precompiled toolchain would
work on most recent distributions, as we are distributing gcc and the
bintools too.

...> We don't, as far as I can tell - apart from a few sources, like the

> kernel and gcc (I agree that we should probably keep those in cvs as
> well). In short, we already keep the sources of everything (minus kernel
> and gcc) already.
>
>> I believe it would also be easier to
>> handle comprehensive versioning as everything may depend on a certain
>> version of the development environment.
> Not so far (but it is a possibility this may happen) - so far, we try
> our best to make sure that a checkout of the buildenv for a given
> timestamp works with a checkout of everything else for a given timestamp
> - so basically, that versioning is already in place.

Yes, until now this is maintainable, as long as the toolchain version
remains stable. I was a bit puzzled though that, for example, I would
find kernel version information in the buildtool.mk files, but this may
be just an example for source to be fixed.

I am convinced though it is easier to keep a single tree in sync than
multiple trees.

>
> Again, maybe I'm misunderstanding what you're suggesting - but if I'm
> not, it would make life harder for the people who actually use the
> buildenv to develop new packages regularly (since an update to cvs might
> break something the next time they do "cvs update"), while it would
> surely help those who just want an up to date buildenv quickly, to
> compile something.

Basically this is what I am suggesting. Just for my understanding, what
do you think could break the individulal developers workspace in this
case? CVS should protect against exactly these problems.

>
> There has been work on getting a vmware (or something similar) image
> that provides a buildenv - would that help? I guess it's not finished
> yet, as always, due to the lack of extra time available.

I guess this is a good idea, although I am personally not that hooked on
VMWare as it is another closed source environment.

I believe even a simple compressed filesystem which can be mounted and
chrooted into (as was available with Bering glibc) could be one
possible, although primitive, solution. Another one could be a KNOPPIX
image covering the actual release with tools and sources.

>
> There's even been work on setting up a self-contained uclibc-only vmware
> image (would be cool for those troublesome sources that insist on
> linking against the host libs, no matter what you do), but that has died
> half way, due to lack of time. And basically, I don't think that's the
> way to go, since we should work on fixing the sources, to make them be
> able to handle a cross compile.

Agreed, I ran into such issues in the eql_enslave stuff. I believe this
is very difficult though, as we need to maintain patches against the
uplink sources at all times and this is very time consuming.

>
> In short - a lot has been tried to make the process of getting a working
> buildenv easier - but so far, it all died half way, before the point
> where it could be given to the people who are having a hard time setting
> up a build environment. And all that comes down to lack of manpower - if
> there were a handful of people working on just that task, it would be
> doable. But as long there's only a handful of developers on the whole
> project, I don't see it happen (unless somebody who really wants that
> fixed picks up the ball and does it).
>
> Just my thoughts - I'm not speaking for anybody but myself.

It is great to know what is going on behind the curtains :-)

Thanks for your time and information.

Erich

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Martin Hejl]

Hi Erich,

ok, this will have to be quick, since I have to work tomorrow - so
forgive me if I overlook something...

> - but we'd surely burn a lot of disk-space on the SF
>> servers...
>
> We would indeed, but hardly more than we do right now.
Actually, we would - since the sources would not be compressed, and we'd
also check in the binaries created from those sources. Currently (and
I've by far not built everything available) my apps tree from CVS is 120
MB, my buildtool tree is 1.3 GB - yes, apps is missing the kernel and
gcc, and the buildtool tree could be cut down quite a bit, since my
buildtool tree contains stuff not needed for the final result, but it's
still going to be more than just a bit of extra space. Whether that's
going to be an issue, I don't know (we don't have a quota on SF cvs
space right now).

> Mhhh.. maybe I am underestimating the issues with the toolchain. I was
> under the impression that most of the stuff is perl anyway, so at least
> partly portable.
Oh, sure it is - but the perl stuff isn't what I'm worried about (and it
isn't what caused problems in the past, apart from the couple of
instances where a change in Config::General broke things).
The issue I'm seeing is that the binaries in our toolchain have the
location of the uclibc libs hardcoded - so, if I compile the toolchain
on "/stuff/sourceforge/src/bering-uclibc/buildtool", the gcc will look
for its libs in
/stuff/sourceforge/src/bering-uclibc/buildtool/staging/usr/lib
Other people will put it in "/var/leaf" or "/home/leaf" or
"/home/username/devel/leaf" (you get the idea). I'm afraid this is going
to cause plenty of issues - simply because some people will fail to read
the docs about where to put things, and also because some people will
read the docs, but are unable to put things where they should (because
they have to work on a box that they don't have root access to).

> I _believe_ also, that a precompiled toolchain would
> work on most recent distributions, as we are distributing gcc and the
> bintools too.
It will not, simply because there's no common denominator about what a
"recent distribution" might be. I use RHEL - compared to the latest
Fedora, that is hugely out of date. Same for debian-stable (unless
something has changed since the last time I used debian). So, it'll come
down to providing a toolchain for people with Ubuntu or Fedora (which
seem to be the most "up to date" distros out there - or not, I'm not
willing to get into a discussion about Linux distros), and still provide
a "do it yourself" toolset for those running more conservative setups.

Basically, if we went down that route, we'd be making a step backwards.
In the old days, people were told to install debian-whatever, since that
provided all the libs needed for building leaf stuff. Buildtool was an
attempt to allow people to build sources on whatever linux box they
chose to use it on (or at least try to). If we go the route you're
suggesting, we're basically telling people again to install a specific
distro (or one of a few), to be able to install our toolchain, to be
able to compile sources.
And then, if we abandon buildtool - how does this toolchain get built in
the first place? One of the goals of buildtool and buildpacket was to
get reproducible results, even if your box crashed and you had to start
from scratch. Another goal was to make upgrading to a new uClibc release
relatively easy. If we abandon the tools that allow us to build the
toolchain with minimal user-interaction, I think we will make a big step
backwards. If we don't, we have to maintain the toolchain (like today),
plus the compiled version. Call me a pessimist, but I see a huge
potential for things getting out of sync.

> Yes, until now this is maintainable, as long as the toolchain version
> remains stable. I was a bit puzzled though that, for example, I would
> find kernel version information in the buildtool.mk files, but this may
> be just an example for source to be fixed.
No, that's perfectly fine. A specific version of buildtool.mk is built
for a specific toolchain - if you check things out for July 1st, 2007,
you'll (hopefully) get a toolchain that matches all buildtool.mk files
(or vice versa). But you can't use last year's toolchain with a
buildtool.mk file from yesterday - they're all tied together. So the
versioning is there, it's just done in CVS (so, you can't tell buildtool
to use a specific version, but rather use the buildtool that was made
for that version, and then instruct buildtool where to get the
corresponding files - as described in the "Checking out an older version
to build" chapter in our docs).

> I am convinced though it is easier to keep a single tree in sync than
> multiple trees.
We don't have multiple trees - just one tree (starting at /leaf/).
The only place where I can see "multipe trees" is where we're supporting
different uClibc versions or different kernel versions at a given point
in time - but that's simply for support reasons, the average developer
should always use the "latest, greatest".
A given version of buildtool will only be able to build one version of
Bering-uClibc (a specific version of uClibc and a specific kernel version).

> Basically this is what I am suggesting. Just for my understanding, what
> do you think could break the individulal developers workspace in this
> case? CVS should protect against exactly these problems.
Surely not. If we check in binaries (which I guess we would if we use
your suggestion), cvs would only be able to replace one binary with
another. If I link a library against a certain lib, cvs then updates
that lib, chances are that my lib will no longer work.
I've always been told that CVS is a source management system, not one
for deploying binaries (which sounds like what you're suggesting).

> I guess this is a good idea, although I am personally not that hooked on
> VMWare as it is another closed source environment.
Well, to each his own (I don't have an issue with closed source, when
the EULA is reasonable and the tool gets the job done). There are Open
Source Virtual machines too (Xen, Bochs, qemu) that do the job too,
VMWare was simply chosen at the time because that's what was in place
and worked (so rather than learning how to set up a new VM, the person
in question could work on what was supposed to run inside that VM). If a
build environment is provided for an open source VM, I'm sure it would
be used. But at the moment, the point is that there's no build
environment for neither a closed nor an open source VM.

> I believe even a simple compressed filesystem which can be mounted and
> chrooted into (as was available with Bering glibc) could be one
> possible, although primitive, solution. Another one could be a KNOPPIX
> image covering the actual release with tools and sources.
Sure (knoppix has been discussed as well - back in 2003 if I recall
correctly). The problem is, nobody so far had the time to do it. And in
the end it comes down to this: the current buildtool setup is surely far
from perfect, but it works (mostly) for the people creating packages
right now (or at least, the people creating the majority of packages).
I'm sure that if somebody provided a better, more flexible build-system,
people would use it. But so far, nobody has, and the people working on
the majority of packages would (so I assume - I'm only speaking for
myself though) rather continue working on improving the leaf distro,
making new packages, than re-creating what we already have (even if the
end result might be better than what we already have). That's at least
my understanding about why people will rather spend the evening working
on compiling a piece of source that somebody asked for, than work on the
build-system.

Before we get too much into the discussion of what could or should be
done - look at the development resources available to the team right
now. Judging from the CVS commits list for the past few months, there
are 5 people working on leaf sourcecode right now - you, Eric Spakman,
KP Kirchdoerfer, Cedric Schieli and myself (and I hardly count, since I
haven't had near enough time to do serious development for quite a
while). Who is going to provide (easy) and maintain (not so easy) that
chroot environment? That's been the main problem of this project all
along (even before the LEAF project existed and the thing was still
called LRP) - there's always been only a relatively small number of core
developers. And there's only so much people can do in their spare time.

> Agreed, I ran into such issues in the eql_enslave stuff. I believe this
> is very difficult though, as we need to maintain patches against the
> uplink sources at all times and this is very time consuming.
Well, broken sources can be fixed upstream too :-) I won't say it's easy
or that it usually works (especially if he patch is only needed for some
"exotic" distro), but it's worth a try.

Basically, I have nothing at all to say against your suggestion - other
than that I think it addresses the symptom (broken sources/makefile for
the toolchain/buildtool makefiles) rather than the cause (the fact that
the sources/toolchain makefile/buildtool makefiles are broken). If
somebody finds the time to provide a buildenv that will make things work
despite being broken, I surely won't have an issue with that, and I'm
pretty sure it will be put into CVS. But at this point, I don't see who
would create such a thing, and more importantly, support it (nothing is
worse than a toolchain that worked last year...)

Martin

P.S. I guess this mail wasn't all that quick after all :-)

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Erich Titl]

Hi Folks

I have a LEAF box with multiple personalities, controlled through
multiple leaf.cfg files which define different configdb files.

Backing up the configdb works fine with lrcfg but fails miserably with
the webconf interface. The problem appears to be the parameter passing
in the file lrcfg.back.cgi.

The following patch fixes the problem for me

>>>>>>>>>>>>>>>> feed to patch >>>>>>>>>>>>>>>>>>>>>

--- lrcfg.back.cgi.old  2006-11-17 18:49:44.000000000 +0100
+++ lrcfg.back.cgi      2007-08-24 14:22:14.872823587 +0200
@@ -11,6 +11,7 @@
        fi
 title="Commit Changes to Read/Write Media"
/var/webconf/lib/preamble.sh  ?>
 <!-- $Id: lrcfg.back.cgi,v 1.3 2006/09/12 17:57:25 espakman Exp $ -->
+<!-- patched for variable CONFIGDB values by Erich Titl
erich.titl@...  -->

 <? # lrcfg.back settings
   SESSIONID=${FORM_SESSIONID:-${SESSIONID}}
@@ -85,7 +86,7 @@

                build_lrp () {
                        # use apkg $1 to build the package in /tmp
-                       apkg $1 /tmp  2>&1 1>/dev/null
+                       apkg $1 $2 /tmp  2>&1 1>/dev/null
                        if ! [ -r /tmp/$2.lrp ]; then
                                log "Red" "The package was not created
in /tmp!"
                                return 1
@@ -206,7 +207,7 @@
        echo ">"
        # The name comes from /var/lib/lrpkg/backup
        echo "<td>"
-       grep "^${x}" /var/lib/lrpkg/backup 2>/dev/null | cut -f2 -d= ||
echo ${x}
+       grep "^${x}" /var/lib/lrpkg/backup 2>/dev/null | cut -f1 -d= ||
echo ${x}
        echo "</td><td align=left>$( eval echo \$${x}_descr)</td>"
        echo "</tr>"
        done

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

cheers

Erich

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Erich Titl]

Hi Folks

the current version of webconf calls /bin/pidof in svcstat.sh pidof is
now in sbin, so it cannot be found using its full path.

cheers

Erich

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[KP Kirchdoerfer-2]

On Friday 24 August 2007 15:37:02 Erich Titl wrote:
> Hi Folks
>
> the current version of webconf calls /bin/pidof in svcstat.sh pidof is
> now in sbin, so it cannot be found using its full path.
>
> cheers
>
Hi Erich;

this should be fixed in cvs.

kp

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Erich Titl]

KP Kirchdoerfer wrote:

> On Friday 24 August 2007 15:37:02 Erich Titl wrote:
>  
>> Hi Folks
>>
>> the current version of webconf calls /bin/pidof in svcstat.sh pidof is
>> now in sbin, so it cannot be found using its full path.
>>
>> cheers
>>
>>    
> Hi Erich;
>
> this should be fixed in cvs.
>  

Thanks, is it fixed in the current beta? As for me, it is fixed in my
current tree, I have not verified everything in CVS, sorry.

Erich

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Erich Titl]

Hi folks

I am about to build a cups package and I am wondering what entry is
needed in buildtool.cfg to create an empty directory in the package, e.g.

<File>
        Filename    = var/spool/cups
        Source      = var/spool/cups
        Type        = directory ?????
</File>

Thanks for hints

Erich

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Martin Hejl]

Hi Erich,

> I am about to build a cups package and I am wondering what entry is
> needed in buildtool.cfg to create an empty directory in the package, e.g.
>
> <File>
> Filename    = var/spool/cups
> Source      = var/spool/cups
> Type        = directory ?????
> </File>

yup, that's almost right - quoting
http://leaf.sourceforge.net/doc/bucd-buildpacket.html:
> (Type = )directory: Filename specifies the name of a directory that
> should be created. Source is ignored. Only useful if you need to create
> empty directories in the package (if they weren't empty buildpacket
> would create them automatically anyway)

So, you can leave out source (since it will be ignored anyway).

Martin

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[KP Kirchdoerfer-2]

On Sunday 14 October 2007 15:35:01 Erich Titl wrote:
> Hi folks
>
> I am about to build a cups package and I am wondering what entry is
> needed in buildtool.cfg to create an empty directory in the package, e.g.

Hi Erich;

does that mean, that you have managed to build cups with uClibc?

Just curious
kp

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Erich Titl]

KP Kirchdoerfer wrote:
> On Sunday 14 October 2007 15:35:01 Erich Titl wrote:
>> Hi folks
>>
>> I am about to build a cups package and I am wondering what entry is
>> needed in buildtool.cfg to create an empty directory in the package, e.g.
>
> Hi Erich;
>
> does that mean, that you have managed to build cups with uClibc?

Well, it compiled without major problems, I am about to build the
package and see where it gets me.

cheers

Erich



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Erich Titl]

Hi Martin

Martin Hejl wrote:
...

> yup, that's almost right - quoting
> http://leaf.sourceforge.net/doc/bucd-buildpacket.html:

An error has been encountered in accessing this page.

1. Server: leaf.sourceforge.net
2. URL path: /doc/bucd-buildpacket.html:
3. Error notes: File does not exist:
/home/groups/l/le/leaf/htdocs/doc/bucd-buildpacket.html:
4. Error type: 404
5. Request method: GET
6. Request query string:
7. Time: 2007-10-14 23:10:33 PDT (1192428633)

Reporting this problem: The problem you have encountered is with a
project web site hosted by SourceForge.net. This issue should be
reported to the SourceForge.net-hosted project (not to SourceForge.net).

If this is a severe or recurring/persistent problem, please do one of
the following, and provide the error text (numbered 1 through 7, above):

   1. Contact the project via their designated support resources.
   2. Contact the project administrators of this project via email (see
the upper right-hand corner of the Project Summary page for their
usernames) at user-name@...

If you are a member of the project that maintains this web content,
please refer to the Site Documentation regarding the project web service
for further assistance.

:-(

Erich

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

_______________________________________________
leaf-devel mailing list
leaf-devel@...
https://lists.sourceforge.net/lists/listinfo/leaf-devel