[gentoo-dev] new guides

[gentoo-dev] new guides

[Daniel Robbins]

Devs,

Some doc improvements to http://www.gentoo.org:

The development guide has been converted to the new XML guide format. 
Also, we now have Pete's excellent new development HOWTO on the site.

Both are works in progress.  Much thanks to Pete and Thomas for their
hard work!

Best Regards,

-- 
Daniel Robbins					<drobbins@gentoo.org>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] new guides

[pbg1854]

On Mon, Apr 09, 2001 at 08:55:04PM -0600, Daniel Robbins wrote:
> Devs,
> 
> Some doc improvements to http://www.gentoo.org:
> 
> The development guide has been converted to the new XML guide format. 
> Also, we now have Pete's excellent new development HOWTO on the site.
> 
> Both are works in progress.  Much thanks to Pete and Thomas for their
> hard work!
> 

Oh, and speaking of which, I've been quite busy recently (classes,
work, my band, etc...), which is why I have not added much to the
HOWTO recently. I'm going to try to put some more info into it this
week, and so if anyone has any suggestions for improvements/additions
etc. please let me know, I'll add them.

Pete

Re: [gentoo-dev] new guides

[Achim Gottinger]

pbg1854@garnet.acns.fsu.edu wrote:
> 
> On Mon, Apr 09, 2001 at 08:55:04PM -0600, Daniel Robbins wrote:
> > Devs,
> >
> > Some doc improvements to http://www.gentoo.org:
> >
> > The development guide has been converted to the new XML guide format.
> > Also, we now have Pete's excellent new development HOWTO on the site.
> >
> > Both are works in progress.  Much thanks to Pete and Thomas for their
> > hard work!
> >
> 
> Oh, and speaking of which, I've been quite busy recently (classes,
> work, my band, etc...),

It seemms everyone has this problem at the moment. :-)

 which is why I have not added much to the
> HOWTO recently. I'm going to try to put some more info into it this
> week, and so if anyone has any suggestions for improvements/additions
> etc. please let me know, I'll add them.

Pete, I'll do the FHS part of the howto and additionally I want to add a
chapter that
describes the USE concept. I'm not a native english spear, so I can
eighter write the
whole chapers and you correct them, or I can give you a short list of
points and you
write the chapters. Tell me what you think about that please.

bye achim~


> 
> Pete
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://www.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] new guides

[Achim Gottinger]

Hi again,

I have a addition too.

In situations where we modify aclocal or configure.in, i think it is
better to
run autoconf/... and add a patch for all modified files instead of
running autoconf
from the ebuild.
This simplifies package dependencies and makes it possible to build all
packages without autoconf/automake/m4/perl installed.

achim~

> 
> Pete
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://www.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] new guides

[Daniel Robbins]

On Wed, Apr 11, 2001 at 06:56:57AM +0200, Achim Gottinger wrote:

> In situations where we modify aclocal or configure.in, i think it is better
> to run autoconf/... and add a patch for all modified files instead of running
> autoconf from the ebuild.  This simplifies package dependencies and makes it
> possible to build all packages without autoconf/automake/m4/perl installed.

I don't think that this really matters for packages like GNOME (after all, if
you're installing GNOME then you probably also have autoconf/Perl,etc.
installed :), but this technique would be useful for critical system packages,
like those found in sys-*.  However, "emerge" should be able to sort out the
build/runtime deps perfectly in either case -- as long as the DEPEND and
RDEPEND strings are set correctly.

Though I'll agree, it would be nice to have a Perl-free system (drobbins hides)
:P

-- 
Daniel Robbins					<drobbins@gentoo.org>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] new guides

[Gontran]

Hi Achim, devers,

I'm willing to sort through any docs you care to write and correct for 
English grammar and whatnot, I stand to learn something about the project that
way.

On another note ...

Bled the ISO last night, hoping to boot the kernel on VIA board with Cyrix MII 
(via chipset: VT82C598MVP), grub popped up nicely (yea!), selected top option,
got some proper looking boot messages then all kind of scrolling hex numbers
and total lock.  

I understand that there's some issues with some via sets ... have a 486 with
32 Mb I'll try next, I'd give it a shot now, but it won't boot off the cdrom 
and I find myself without a working 3.5 floppy drive for bootdisk making.
Any insights?

Gontran

* Achim Gottinger (AGottinger@t-online.de) wrote:
> pbg1854@garnet.acns.fsu.edu wrote:
> > 
> > On Mon, Apr 09, 2001 at 08:55:04PM -0600, Daniel Robbins wrote:
> > > Devs,
> > >
> > > Some doc improvements to http://www.gentoo.org:
> > >
> > > The development guide has been converted to the new XML guide format.
> > > Also, we now have Pete's excellent new development HOWTO on the site.
> > >
> > > Both are works in progress.  Much thanks to Pete and Thomas for their
> > > hard work!
> > >
> > 
> > Oh, and speaking of which, I've been quite busy recently (classes,
> > work, my band, etc...),
> 
> It seemms everyone has this problem at the moment. :-)
> 
>  which is why I have not added much to the
> > HOWTO recently. I'm going to try to put some more info into it this
> > week, and so if anyone has any suggestions for improvements/additions
> > etc. please let me know, I'll add them.
> 
> Pete, I'll do the FHS part of the howto and additionally I want to add a
> chapter that
> describes the USE concept. I'm not a native english spear, so I can
> eighter write the
> whole chapers and you correct them, or I can give you a short list of
> points and you
> write the chapters. Tell me what you think about that please.
> 
> bye achim~
> 
> 
> > 
> > Pete
> > 
> > _______________________________________________
> > gentoo-dev mailing list
> > gentoo-dev@gentoo.org
> > http://www.gentoo.org/mailman/listinfo/gentoo-dev
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://www.gentoo.org/mailman/listinfo/gentoo-dev
-- 
Gontran

Re: [gentoo-dev] new guides

[Achim Gottinger]

Daniel Robbins wrote:
> 
> On Wed, Apr 11, 2001 at 06:56:57AM +0200, Achim Gottinger wrote:
> 
> > In situations where we modify aclocal or configure.in, i think it is better
> > to run autoconf/... and add a patch for all modified files instead of running
> > autoconf from the ebuild.  This simplifies package dependencies and makes it
> > possible to build all packages without autoconf/automake/m4/perl installed.
> 
> I don't think that this really matters for packages like GNOME (after all, if
> you're installing GNOME then you probably also have autoconf/Perl,etc.
> installed :), but this technique would be useful for critical system packages,
> like those found in sys-*.

I had the following problem with glibc-2.2.2. Their configure file was
not designed well and some
tests failed on a system without perl (build). I liked petes suggestion
to modify the root and not the leaf
of the configuration, so I patched configure.in.
So now I had to compile autoconf/m4/perl/libtool before I could build
glibc (very bad). 

I think it is generally a good idea to add configure to the patch,
because it is a bit confusing that
the configure in work exists but does not work. So eigther it must be
removed if configure.in gets modified
or added to the patch.


  However, "emerge" should be able to sort out the
> build/runtime deps perfectly in either case -- as long as the DEPEND and
> RDEPEND strings are set correctly.

Yes that's true. But in the above example it is a problem.

> 
> Though I'll agree, it would be nice to have a Perl-free system (drobbins hides)

Unfortunately xfree requires perl, so it whould be a xfree free system
too.

BTW: It whould be nice to have a python free runtime system too 
(nothing personal this time, so no need to run or hide :-)). 
This is impossible at the moment because of the env-update thing. It
might be required on embedded platforms where disc space is rare
(spython ~5MB).
I suggest recode env-update in bash or c.

achim~

> 
> --
> Daniel Robbins                                  <drobbins@gentoo.org>
> President/CEO                                   http://www.gentoo.org
> Gentoo Technologies, Inc.
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://www.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] new guides

[Daniel Robbins]

On Wed, Apr 11, 2001 at 07:50:15AM +0200, Achim Gottinger wrote:

> I think it is generally a good idea to add configure to the patch, because it
> is a bit confusing that the configure in work exists but does not work. So
> eigther it must be removed if configure.in gets modified or added to the
> patch.

I agree with your suggestion.  Sorry, I should have made that more clear in the
previous email.

> > Though I'll agree, it would be nice to have a Perl-free system (drobbins hides)
> 
> Unfortunately xfree requires perl, so it whould be a xfree free system
> too.

> BTW: It whould be nice to have a python free runtime system too (nothing
> personal this time, so no need to run or hide :-)).  This is impossible at
> the moment because of the env-update thing. It might be required on embedded
> platforms where disc space is rare (spython ~5MB).  I suggest recode
> env-update in bash or c.

Well, pkgmerge, ebuild and emerge are in python right now too.  I don't have a problem
if people want to start converting the more stable code to C++.  A good start would be
env-update and the .tbz2 functions (/usr/lib/python2.0/xpak.py).  Since we're moving to
an object framework, I think that C++ would be a better fit than C.

If anyone is interested in doing this, please contact me first.  Then I'll carefully
coordinate my work in python with yours.

Best Regards,

-- 
Daniel Robbins					<drobbins@gentoo.org>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] new guides

[Achim Gottinger]

Gontran wrote:
> 
> Hi Achim, devers,
> 
> I'm willing to sort through any docs you care to write and correct for
> English grammar and whatnot, I stand to learn something about the project that
> way.

Fine, thank you. I send you my docs at the end of the week.
> 
> On another note ...
> 
> Bled the ISO last night, hoping to boot the kernel on VIA board with Cyrix MII
> (via chipset: VT82C598MVP), grub popped up nicely (yea!), selected top option,
> got some proper looking boot messages then all kind of scrolling hex numbers
> and total lock.
> 
> I understand that there's some issues with some via sets ... have a 486 with
> 32 Mb I'll try next, I'd give it a shot now, but it won't boot off the cdrom
> and I find myself without a working 3.5 floppy drive for bootdisk making.
> Any insights?

I send the whole last weekend on a rescue disk system and want to update
and rework
the whole boot concept on the next weekend.
In theory the latest iso should work on any >=i486 system, but it
doesn't.
I have tested it on a K62/VIA board here with success.
Yesterday I tried to boot the rescue system on a Compaq armada laptop
had it hangs after
loading the rescue disk. :-/
I'm planning to boot the bootimage directly from the cd, becuase mkisofs
now allows the use of images other that fd for booting. If it works I
can add alot of different kernels to the image and there is no more need
to scan for the cdrom device and mount the iso image loopback.
This solution should work for you too.

Does your 486 cdrom allow boot off the cdrom?

achim~

> 
> Gontran
> 
> * Achim Gottinger (AGottinger@t-online.de) wrote:
> > pbg1854@garnet.acns.fsu.edu wrote:
> > >
> > > On Mon, Apr 09, 2001 at 08:55:04PM -0600, Daniel Robbins wrote:
> > > > Devs,
> > > >
> > > > Some doc improvements to http://www.gentoo.org:
> > > >
> > > > The development guide has been converted to the new XML guide format.
> > > > Also, we now have Pete's excellent new development HOWTO on the site.
> > > >
> > > > Both are works in progress.  Much thanks to Pete and Thomas for their
> > > > hard work!
> > > >
> > >
> > > Oh, and speaking of which, I've been quite busy recently (classes,
> > > work, my band, etc...),
> >
> > It seemms everyone has this problem at the moment. :-)
> >
> >  which is why I have not added much to the
> > > HOWTO recently. I'm going to try to put some more info into it this
> > > week, and so if anyone has any suggestions for improvements/additions
> > > etc. please let me know, I'll add them.
> >
> > Pete, I'll do the FHS part of the howto and additionally I want to add a
> > chapter that
> > describes the USE concept. I'm not a native english spear, so I can
> > eighter write the
> > whole chapers and you correct them, or I can give you a short list of
> > points and you
> > write the chapters. Tell me what you think about that please.
> >
> > bye achim~
> >
> >
> > >
> > > Pete
> > >
> > > _______________________________________________
> > > gentoo-dev mailing list
> > > gentoo-dev@gentoo.org
> > > http://www.gentoo.org/mailman/listinfo/gentoo-dev
> >
> > _______________________________________________
> > gentoo-dev mailing list
> > gentoo-dev@gentoo.org
> > http://www.gentoo.org/mailman/listinfo/gentoo-dev
> --
> Gontran
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://www.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] new guides

[Achim Gottinger]

> 
> Well, pkgmerge, ebuild and emerge are in python right now too.  I don't have a problem
> if people want to start converting the more stable code to C++.  A good start would be
> env-update and the .tbz2 functions (/usr/lib/python2.0/xpak.py).  Since we're moving to
> an object framework, I think that C++ would be a better fit than C.

I ment a situation like, I want to make a cramfs for my (not yet
existsing) Palm on a normal gentoo system.
I don't need pkgmerge, ebuild or emerge on that system, but I need
env-update there. But well, I can create
profile.env on the development system too.

achim~

> 
> If anyone is interested in doing this, please contact me first.  Then I'll carefully
> coordinate my work in python with yours.
> 
> Best Regards,
> 
> --
> Daniel Robbins                                  <drobbins@gentoo.org>
> President/CEO                                   http://www.gentoo.org
> Gentoo Technologies, Inc.
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://www.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] new guides

[Gontran]

* Achim Gottinger (AGottinger@t-online.de) wrote:
> Gontran wrote:
> > 
> > Hi Achim, devers,
> > 
> > I'm willing to sort through any docs you care to write and correct for
> > English grammar and whatnot, I stand to learn something about the project that
> > way.
> 
> Fine, thank you. I send you my docs at the end of the week.
> > 
> > On another note ...
> > 
> > Bled the ISO last night, hoping to boot the kernel on VIA board with Cyrix MII
> > (via chipset: VT82C598MVP), grub popped up nicely (yea!), selected top option,
> > got some proper looking boot messages then all kind of scrolling hex numbers
> > and total lock.
> > 
> > I understand that there's some issues with some via sets ... have a 486 with
> > 32 Mb I'll try next, I'd give it a shot now, but it won't boot off the cdrom
> > and I find myself without a working 3.5 floppy drive for bootdisk making.
> > Any insights?
> 
> I send the whole last weekend on a rescue disk system and want to update
> and rework
> the whole boot concept on the next weekend.
> In theory the latest iso should work on any >=i486 system, but it
> doesn't.
> I have tested it on a K62/VIA board here with success.
> Yesterday I tried to boot the rescue system on a Compaq armada laptop
> had it hangs after
> loading the rescue disk. :-/
> I'm planning to boot the bootimage directly from the cd, becuase mkisofs
> now allows the use of images other that fd for booting. If it works I
> can add alot of different kernels to the image and there is no more need
> to scan for the cdrom device and mount the iso image loopback.
> This solution should work for you too.
> 
> Does your 486 cdrom allow boot off the cdrom?

Unfortunately, no.  But there is another machine around here with a floppy
that works, come to think of it.  I'll make the floppies there and give it
another try on the cyrix.  

Gontran

> 
> achim~
> 
> > 
> > Gontran
> > 
> > * Achim Gottinger (AGottinger@t-online.de) wrote:
> > > pbg1854@garnet.acns.fsu.edu wrote:
> > > >
> > > > On Mon, Apr 09, 2001 at 08:55:04PM -0600, Daniel Robbins wrote:
> > > > > Devs,
> > > > >
> > > > > Some doc improvements to http://www.gentoo.org:
> > > > >
> > > > > The development guide has been converted to the new XML guide format.
> > > > > Also, we now have Pete's excellent new development HOWTO on the site.
> > > > >
> > > > > Both are works in progress.  Much thanks to Pete and Thomas for their
> > > > > hard work!
> > > > >
> > > >
> > > > Oh, and speaking of which, I've been quite busy recently (classes,
> > > > work, my band, etc...),
> > >
> > > It seemms everyone has this problem at the moment. :-)
> > >
> > >  which is why I have not added much to the
> > > > HOWTO recently. I'm going to try to put some more info into it this
> > > > week, and so if anyone has any suggestions for improvements/additions
> > > > etc. please let me know, I'll add them.
> > >
> > > Pete, I'll do the FHS part of the howto and additionally I want to add a
> > > chapter that
> > > describes the USE concept. I'm not a native english spear, so I can
> > > eighter write the
> > > whole chapers and you correct them, or I can give you a short list of
> > > points and you
> > > write the chapters. Tell me what you think about that please.
> > >
> > > bye achim~
> > >
> > >
> > > >
> > > > Pete
> > > >
> > > > _______________________________________________
> > > > gentoo-dev mailing list
> > > > gentoo-dev@gentoo.org
> > > > http://www.gentoo.org/mailman/listinfo/gentoo-dev
> > >
> > > _______________________________________________
> > > gentoo-dev mailing list
> > > gentoo-dev@gentoo.org
> > > http://www.gentoo.org/mailman/listinfo/gentoo-dev
> > --
> > Gontran
> > 
> > _______________________________________________
> > gentoo-dev mailing list
> > gentoo-dev@gentoo.org
> > http://www.gentoo.org/mailman/listinfo/gentoo-dev
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://www.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] new guides

[Achim Gottinger]

> >
> > Does your 486 cdrom allow boot off the cdrom?
> 
> Unfortunately, no.  But there is another machine around here with a floppy
> that works, come to think of it.  I'll make the floppies there and give it
> another try on the cyrix.
> 
I uploaded two disc images to ibiblio
gentoo-x86-distro/gentoo-1.0_rc4/images.

bootgrub_jerry.img conatins a special linuxrc for jerry, but also it
contains
additional grub menues to start the the rescue disc. This image contains
the same kernel that is 
on the rc4_pre2 iso, so if the iso does not work, this disc whouldn't
work too.

I can make you a bootdisk image with a newer kernel if you want.

rdisk.gz is the recue disk image.

achim~

Re: [gentoo-dev] new guides

[Gontran]

* Achim Gottinger (AGottinger@t-online.de) wrote:
> > >
> > > Does your 486 cdrom allow boot off the cdrom?
> > 
> > Unfortunately, no.  But there is another machine around here with a floppy
> > that works, come to think of it.  I'll make the floppies there and give it
> > another try on the cyrix.
> > 
> I uploaded two disc images to ibiblio
> gentoo-x86-distro/gentoo-1.0_rc4/images.
> 
> bootgrub_jerry.img conatins a special linuxrc for jerry, but also it
> contains
> additional grub menues to start the the rescue disc. This image contains
> the same kernel that is 
> on the rc4_pre2 iso, so if the iso does not work, this disc whouldn't
> work too.
> 
> I can make you a bootdisk image with a newer kernel if you want.
> 
> rdisk.gz is the recue disk image.
> 
> achim~
> 

Thanks Achim.  Turns out I had the same (memory?) problem with the boot floppy
on the cyrix *shrug*, and my 486 is old as ... well it doesn't have a math
co-processor.  Frankly, from the specs on the website, gentoo doesn't look
like it's a 486 kind of party... That seems reasonable to me.  

I'm gonna have to go shopping.  Looking forward to helping out.

Rgds,
Gontran

Re: [gentoo-dev] new guides

[Achim Gottinger]

Gontran wrote:
> 
> * Achim Gottinger (AGottinger@t-online.de) wrote:
> > > >
> > > > Does your 486 cdrom allow boot off the cdrom?
> > >
> > > Unfortunately, no.  But there is another machine around here with a floppy
> > > that works, come to think of it.  I'll make the floppies there and give it
> > > another try on the cyrix.
> > >
> > I uploaded two disc images to ibiblio
> > gentoo-x86-distro/gentoo-1.0_rc4/images.
> >
> > bootgrub_jerry.img conatins a special linuxrc for jerry, but also it
> > contains
> > additional grub menues to start the the rescue disc. This image contains
> > the same kernel that is
> > on the rc4_pre2 iso, so if the iso does not work, this disc whouldn't
> > work too.
> >
> > I can make you a bootdisk image with a newer kernel if you want.
> >
> > rdisk.gz is the recue disk image.
> >
> > achim~
> >
> 
> Thanks Achim.  Turns out I had the same (memory?) problem with the boot floppy
> on the cyrix *shrug*, and my 486 is old as ... well it doesn't have a math
> co-processor.  Frankly, from the specs on the website, gentoo doesn't look
> like it's a 486 kind of party... That seems reasonable to me.
> 
You said memeory problem. Hmm, this can be the cause why it did not run
on my compaq laptop (32MB).
If I remeber correct I used 16MB for the default ramdisk size on
rc4_pre2, but that much is not required.
I inform you if I got it installed on my compaq machine.

I run it here on a 486SX/25 system with 16MB ram and two 100MB hds
running as a raid device, since nearly a
year without a problem. But I had to compile all the packages for that
special system , because that time
we used i686 as the default HOST.

> I'm gonna have to go shopping.  Looking forward to helping out.
> 
> Rgds,
> Gontran
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://www.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] new guides

[Pete Gavin]

On Wed, Apr 11, 2001 at 12:28:15AM -0600, Daniel Robbins wrote:
> 
> Well, pkgmerge, ebuild and emerge are in python right now too.  I don't have a problem
> if people want to start converting the more stable code to C++.  A good start would be
> env-update and the .tbz2 functions (/usr/lib/python2.0/xpak.py).  Since we're moving to
> an object framework, I think that C++ would be a better fit than C.
> 

I'm a pretty decent c++ hacker, I could probably help w/ this, but
I'll need to look at the python extension docs. I also thought it
would be really cool to make a portage manager for X using the python
gtk+ bindings. I think it would be best to use python for this, since
pretty much everything that it would need to do is already written, it
only needs the interface to be written. It would also be alot simpler
than writing it in C and imbedding python :)

Pete

Re: [gentoo-dev] new guides

[datazone]

>  I also thought it would be really cool to make a portage manager for X using the python gtk+bindings.

glade springs to mind as a way to build the interface quickly, and then use libglade with python.


Leland Elie

Re: [gentoo-dev] new guides

[Pete Gavin]

On Thu, Apr 12, 2001 at 04:13:17PM -0600, Pete Gavin wrote:
> I'm a pretty decent c++ hacker, I could probably help w/ this, but
> I'll need to look at the python extension docs. I also thought it
> would be really cool to make a portage manager for X using the python
> gtk+ bindings. I think it would be best to use python for this, since
> pretty much everything that it would need to do is already written, it
> only needs the interface to be written. It would also be alot simpler
> than writing it in C and imbedding python :)

I've been looking at SWIG a bit, and I think it would be really
helpful for this stuff. That way, we might eventually be able to make
it so that most portage stuff is also available from perl, and anyone
who wants to access portage from perl may do so easily. (I know some
of you may cringe at this, but I happen to like perl :) but don't
worry, I like python equally... both have their uses)

Pete

Re: [gentoo-dev] new guides

[Achim Gottinger]

"Jerry A!" wrote:
> 
> On Fri, Apr 13, 2001 at 01:40:17AM -0600, Pete Gavin wrote:
> :
> : I've been looking at SWIG a bit, and I think it would be really
> : helpful for this stuff. That way, we might eventually be able to make
> : it so that most portage stuff is also available from perl, and anyone
> : who wants to access portage from perl may do so easily. (I know some
> : of you may cringe at this, but I happen to like perl :) but don't
> : worry, I like python equally... both have their uses)
> 
> Curiousity on my part.  Is there any reason why we're looking to step
> away from python?  It appears as though the Linux/Python connection are
> here to stay.  Especially with ESR's new CML2 project. 

Gimme a link to that project please.

 As we go
> forward, one won't even be able to rebuild the kernel w/out Python.
> 
> Achim, have you looked at the freeze module for compiling the python
> bits for the embedded devices you're working on (instead of rewriting
> them in C++)?

No, can I make binaries for python scripts with that? The problem I see
for embedded 
devices, is that python requires simply too much memory. If it is
possible to make standalone 
binaries that do eighter require all the python modules nor the python
binarie, I would be intersted
how huge such a binary will be.

We had a discussion about allowing other languages like perl or tcl/tk
to be used for ebuild. And decided that
it makes more sense converting stable parts of python code to c++. Once
it's all c++ we can make modules
for other scripting languages. I personal prefer perl as a scripting
language and did not investigate much
time in learning python. But as long as daniel is the developer of
ebuild it is his right do choose his
preferend language for development I think.
Our biggest problem is still that we can not spend all our time in
gentoo development as long as we do not have
sponsors.

There is a install-gui in development that will use qt first, but it
will be designed in a manner that the gui
parts are separated from the configuration backend, so it should be easy
to write ncurses or gtk frontends too.
But do not expect that stuff next week. :-)

BTW: Jerry, are you still headbanging or did you get gentoo working now?

achim~

Re: [gentoo-dev] new guides

[Tom Flavel]

On Fri, Apr 13, 2001 at 11:38:28AM +0200, Achim Gottinger wrote:
> 
> We had a discussion about allowing other languages like perl or tcl/tk
> to be used for ebuild. And decided that
> it makes more sense converting stable parts of python code to c++. Once
> it's all c++ we can make modules
> for other scripting languages. I personal prefer perl as a scripting
> language and did not investigate much
> time in learning python. But as long as daniel is the developer of
> ebuild it is his right do choose his
> preferend language for development I think.
> Our biggest problem is still that we can not spend all our time in
> gentoo development as long as we do not have
> sponsors.
> 
> There is a install-gui in development that will use qt first, but it
> will be designed in a manner that the gui
> parts are separated from the configuration backend, so it should be easy
> to write ncurses or gtk frontends too.
> But do not expect that stuff next week. :-)
> 

Hi,

on a similar note, I remember discussing seperating the backend of portage
from interfaces a while ago, but I think it may have been a bit too early :)

To recap, the idea was to have a C/C++ program listen on a pipe, then have
interfaces (in the language of your choice) do things like
"echo packagename>/thatpipe" - the backend would listen and install the package.

This would mean one could churn out gui's using the wigit tool of personal
prefence, for example, with relative ease. A bouns is that as the protocol
would be simple (basically just a package name/version and what to do with it)
the actual behaviour would be consistent across all interfaces.

- Tom

Re: [gentoo-dev] new guides

[Achim Gottinger]

Tom Flavel wrote:
> 
> On Fri, Apr 13, 2001 at 11:38:28AM +0200, Achim Gottinger wrote:
> >
> > We had a discussion about allowing other languages like perl or tcl/tk
> > to be used for ebuild. And decided that
> > it makes more sense converting stable parts of python code to c++. Once
> > it's all c++ we can make modules
> > for other scripting languages. I personal prefer perl as a scripting
> > language and did not investigate much
> > time in learning python. But as long as daniel is the developer of
> > ebuild it is his right do choose his
> > preferend language for development I think.
> > Our biggest problem is still that we can not spend all our time in
> > gentoo development as long as we do not have
> > sponsors.
> >
> > There is a install-gui in development that will use qt first, but it
> > will be designed in a manner that the gui
> > parts are separated from the configuration backend, so it should be easy
> > to write ncurses or gtk frontends too.
> > But do not expect that stuff next week. :-)
> >
> 
> Hi,
> 
> on a similar note, I remember discussing seperating the backend of portage
> from interfaces a while ago, but I think it may have been a bit too early :)
> 
> To recap, the idea was to have a C/C++ program listen on a pipe, then have
> interfaces (in the language of your choice) do things like
> "echo packagename>/thatpipe" - the backend would listen and install the package.
> 
> This would mean one could churn out gui's using the wigit tool of personal
> prefence, for example, with relative ease. A bouns is that as the protocol
> would be simple (basically just a package name/version and what to do with it)
> the actual behaviour would be consistent across all interfaces.
> 

Hi, 

There will be two separate libs, one for portage and one for the
configuration system.
So that pipe thing whould be a alternative frontend for the portage
libs.

achim~

> - Tom
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://www.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] new guides

[Daniel Robbins]

On Fri, Apr 13, 2001 at 01:05:55PM +0100, Tom Flavel wrote:

> To recap, the idea was to have a C/C++ program listen on a pipe, then have
> interfaces (in the language of your choice) do things like
> "echo packagename>/thatpipe" - the backend would listen and install the package.

One problem with this solution is that we need a robust and feature-rich two-way
communications stream.  For example, your request to install "foo/bar-1.0" may be
answered by a list of dependencies that must be satisfied before installation is
possible, or a particular dependency that couldn't be satisfied (if it's auto-resolving
dependencies), or that the particular package wasn't found in the portage database.

With such a system as you describe, the Portage response would have to be placed
in another file, and tying these two files into a communications stream would become
tricky enough to make this a less-than-elegant, solution.  IMO.

Best Regards,

-- 
Daniel Robbins					<drobbins@gentoo.org>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] new guides

[Pete Gavin]

On Fri, Apr 13, 2001 at 09:20:03AM -0600, Daniel Robbins wrote:
> > To recap, the idea was to have a C/C++ program listen on a pipe, then have
> > interfaces (in the language of your choice) do things like
> > "echo packagename>/thatpipe" - the backend would listen and install the package.
> 
> One problem with this solution is that we need a robust and feature-rich two-way
> communications stream.  For example, your request to install "foo/bar-1.0" may be
> answered by a list of dependencies that must be satisfied before installation is
> possible, or a particular dependency that couldn't be satisfied (if it's auto-resolving
> dependencies), or that the particular package wasn't found in the portage database.
> 
> With such a system as you describe, the Portage response would have to be placed
> in another file, and tying these two files into a communications stream would become
> tricky enough to make this a less-than-elegant, solution.  IMO.
> 

Well, the backend program *does* have both a stdin and stdout stream,
which would provide the two way communication stream you're talking
about. And we could also set up a socket file if necessary. Or even
unix sockets (but I think that would be overkill...)

Pete

Re: [gentoo-dev] new guides

[Jerry A!]

On Fri, Apr 13, 2001 at 11:38:28AM +0200, Achim Gottinger wrote:
: "Jerry A!" wrote:
: > 
: > Curiousity on my part.  Is there any reason why we're looking to step
: > away from python?  It appears as though the Linux/Python connection are
: > here to stay.  Especially with ESR's new CML2 project. 
: 
: Gimme a link to that project please.

Here's a link to the project page <http://www.tuxedo.org/~esr/kbuild>
and here's the announcement
<http://www.tuxedo.org/~esr/kbuild/ANNOUNCEMENT>.

: > Achim, have you looked at the freeze module for compiling the python
: > bits for the embedded devices you're working on (instead of rewriting
: > them in C++)?
: 
: No, can I make binaries for python scripts with that? The problem I
: see for embedded devices, is that python requires simply too much
: memory. If it is possible to make standalone binaries that do eighter
: require all the python modules nor the python binarie, I would be
: intersted how huge such a binary will be.

The freeze module will covert the python code to c and then compile it.
I think we can also look at using stripped down version of Python, like
stackless or pippy.  I guess I'm just very pro-python.  We've developed
a great system that through the use of a very-high level scripting
language provides an easy framework for hacking and extensibility.  I'd
hate to see that lost.

In fact, embdebian (Embedded Debian) is using CML2 already.  My guess is
that they already have found a way to deal with this issue.

: We had a discussion about allowing other languages like perl or tcl/tk
: to be used for ebuild. And decided that it makes more sense converting
: stable parts of python code to c++. Once it's all c++ we can make
: modules for other scripting languages. I personal prefer perl as a
: scripting language and did not investigate much time in learning
: python. But as long as daniel is the developer of ebuild it is his
: right do choose his preferend language for development I think. Our
: biggest problem is still that we can not spend all our time in gentoo
: development as long as we do not have sponsors.

Since time is limited, why don't we just concentrate on what we've
always been doing?  I figure that if can publish an API, then others can
develop ebuild in other languages.

: BTW: Jerry, are you still headbanging or did you get gentoo working now?

No.  Unfortunately, I've become the latest dot-com casualty.  So, the
Vaio z505 had to go back.  I went to a computer show over the weekend
and picked up the parts to put together a 1GHz Athlon system (I even
picked up a pcmcia bay so I can still try and get laptop portages made).
So, it's back to the drawing board for figuring out how to bootstrap
this puppy.

        --Jerry

name:  Jerry Alexandratos         ||  Open-Source software isn't a
phone: 703.599.6023               ||  matter of life or death...
email: jerry@thehutt.org          ||  ...It's much more important
                                  ||  than that!

Re: [gentoo-dev] new guides

[Achim Gottinger]

> The freeze module will covert the python code to c and then compile it.

Sounds good in theory, does it work better that perl->c?

> I think we can also look at using stripped down version of Python, like
> stackless or pippy. 

Yes that must be evaluated.

 I guess I'm just very pro-python.  We've developed
> a great system that through the use of a very-high level scripting
> language provides an easy framework for hacking and extensibility.  I'd
> hate to see that lost.

As long as daniel lives, you whoun't see that lost. The plan is to
convert parts of
the ebuild python code to c++ once it is stable. Do you plan to hack
things like the
dependencie system? So finaly the core of ebuild will be c++ code used
by a python module.
Then it is possible to write modules for ebuild in other languages too.
> 
> Since time is limited, why don't we just concentrate on what we've
> always been doing?  I figure that if can publish an API, then others can
> develop ebuild in other languages.
> 
I do not see a sense in using other languages than bash for ebuild's
functions, but
it whould be great to have a perl module from which I can access ebuilds
functions.
Of cause we currently concentrate on what we've always been doing.
I'm reworking all our packages since two month to make intensive use of
the USE variables.
Once I'm finished we should be able to use USE as a global config file
for all packages.
So for example if you set "mysql" in USE all packages that can be linked
against mysql
get linked against it. I think this is usefull for embedded systems too,
because it can
reduce the package's size immense. There is no need for native languages
support, pam or
readline on an internet radio.
Unfortunately all this is much more time-consumning as I thought and
that is a main cause
why there was no new release in the past. But once it is finished I
swear that it will be real
fun.

> : BTW: Jerry, are you still headbanging or did you get gentoo working now?
> 
> No.  Unfortunately, I've become the latest dot-com casualty.  
Urgh, sorry to hear that, hope you get a new job soon.

So, the
> Vaio z505 had to go back.  I went to a computer show over the weekend
> and picked up the parts to put together a 1GHz Athlon system (I even
> picked up a pcmcia bay so I can still try and get laptop portages made).
> So, it's back to the drawing board for figuring out how to bootstrap
> this puppy.

I made a package for yard, which is a nice system for building rescue
and install discs. Simplified
you pass a list of binraies you want to have on a disc and yard finds te
required libs and builds 
a working image for you. Debian uses a nice script to reduce the size of
the shared libraries for such
a disc by building the shared libs from _pic.a archives with only the
required funtions. This can reduce
for exanple glibc's size to nearly the half.
The problem is that yard currently has the path to the config stuff
hardcoded, so it must be hacked to
read an env var or an parameter (should not be difficult).
Once this is done, I think it's even good for making images for embedded
systems.
Additionaly I try to use syslinux for the boot disc. Hopefully this
works better than our current system.
Once more it's more time-consuming than expected but real fun in the
end.

All the trials we made for a week to get gentoo running on your vaio
where tested here on an Athlon system,
so hopefully it will work on your system too.
Maybe I can upload new snapshot releases for build and sys this week.

bye achim~

> 
>         --Jerry
> 
> name:  Jerry Alexandratos         ||  Open-Source software isn't a
> phone: 703.599.6023               ||  matter of life or death...
> email: jerry@thehutt.org          ||  ...It's much more important
>                                   ||  than that!
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://www.gentoo.org/mailman/listinfo/gentoo-dev