usr_devx - too much stripping ?
usr_devx - too much stripping ?
hello barry,
as for i wasnt able to find a contact emailaddress i decided to use this forum for asking you some qeustions.
first of all im working on a rtai version for puppy. the latest
release was built upon 1.0.5 and was a big hack.
right now im playing with 1.0.7 and try to do it the puppy way.
i use unionfs, make pupget/unleashed packages, and compile all
on puppy itself.
the progress is available here:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CncUser
now here is my problem. i found some things necessary
for building a puppylinuxsystem missing. namely the most
strange looking misses are:
xargs - theres only the busyboxversion = kernelmodules
would not install. and a lot of other stuff depends
on xargs.
autoreconfigure - seems like the rest of autoconf is here,
why is this binary missing ?
aclocal - the same, the whole automake is installed, except
this vital binary
these are just the things i found till now, but im afraid that
there is a lot more holes in usr_devx.sfs.
could you please tell me:
where you got the binaries from ?
how you selected what to take and what not ?
for it may help me deciding how to continue.
thanks
cncuser
as for i wasnt able to find a contact emailaddress i decided to use this forum for asking you some qeustions.
first of all im working on a rtai version for puppy. the latest
release was built upon 1.0.5 and was a big hack.
right now im playing with 1.0.7 and try to do it the puppy way.
i use unionfs, make pupget/unleashed packages, and compile all
on puppy itself.
the progress is available here:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CncUser
now here is my problem. i found some things necessary
for building a puppylinuxsystem missing. namely the most
strange looking misses are:
xargs - theres only the busyboxversion = kernelmodules
would not install. and a lot of other stuff depends
on xargs.
autoreconfigure - seems like the rest of autoconf is here,
why is this binary missing ?
aclocal - the same, the whole automake is installed, except
this vital binary
these are just the things i found till now, but im afraid that
there is a lot more holes in usr_devx.sfs.
could you please tell me:
where you got the binaries from ?
how you selected what to take and what not ?
for it may help me deciding how to continue.
thanks
cncuser
Re: usr_devx - too much stripping ?
Sadly, compiling everything on Puppy itself is not (yet?) the "Puppy way". usr_devx.sfs was created mainly by copying binaries and headers from other distributions, as Barry indicates at http://www.pupweb.org/puppy/development ... cratch.htm which says:cncuser wrote:right now im playing with 1.0.7 and try to do it the puppy way. i use unionfs, make pupget/unleashed packages, and compile all on puppy itself.
BarryK wrote:The file usr_devx.sfs was created by me in a rather ad-hoc manner. I just grabbed anything that looked necessary for compiling out of Vector Linux 5.0STD, plus XFree86 headers and configuration files out of Mandrake 9.2, plus headers and associated files created in the usr-development directory that you see above in the Rox picture.
Looks useful, thanks for documenting your progress.cncuser wrote:http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CncUser
The answer to why things are missing lies in the quote from BarryK above -- he didn't realize how useful they were. Perl is missing pod2man, and there are a few other examples I have run across. /usr/bin/curl from usr_devx.sfs is linked to a library that isn't present.
Even in the base distro, some included commands like /sbin/ifup and /sbin/ifdown do not work, because the homegrown network config code in Puppy fails to create and use /etc/network/interfaces (though the Busybox binary includes the relevant code, and if you create that file and a run-parts script (also missing for some reason), they then work as one would expect. It's unclear to me why Puppy invented a (less flexible) alternative to the common network config scheme that is already "built in" to Busybox, and used in Debian and Ubuntu and friends.
Based on Barry's web page, the answers are "from Vector Linux and Mandrake", and "in a rather ad-hoc manner"where you got the binaries from ?
how you selected what to take and what not ?
I think the solution lies in those of us who are creating things from source code on Puppy (which seems to be a fairly small fraction of Puppy packagers, as far as I can tell) to suggest/create an enhanced usr_devx.sfs for BarryK to consider making "official". Preferably a fileystem whose entire contents are built from source, on Puppy, so we can provide source for everything in it. I'd be interested in working with you on this, especially if BarryK gives such a project his "blessing"!
Jonathan
hi jmarsden,
jmarsden wrote:
>Sadly, compiling everything on Puppy itself is not (yet?) the "Puppy
>way". usr_devx.sfs was created mainly by copying binaries and headers
>rom other distributions, as Barry indicates at
>http://www.pupweb.org/puppy/development ... cratch.htm which says:
ok, i may have overread that. thanks for the info, it makes it
easy to decide what i got todo next.
>http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CncUser
>
>Looks useful, thanks for documenting your progress.
its not state of the art, right now im trying to get a freedesktop
xserver suite compiled on puppy.
>The answer to why things are missing lies in the quote from BarryK
>above -- he didn't realize how useful they were. Perl is missing
>pod2man, and there are a few other examples I have run across. >/usr/bin/curl from usr_devx.sfs is linked to a library that isn't present.
>Even in the base distro, some included commands like /sbin/ifup and
>/sbin/ifdown do not work, because the homegrown network config code >in Puppy fails to create and use /etc/network/interfaces (though the
>Busybox binary includes the relevant code, and if you create that file and
> a run-parts script (also missing for some reason), they then work as >one would expect. It's unclear to me why Puppy invented a (less flexible)
> alternative to the common network config scheme that is already "built
>in" to Busybox, and used in Debian and Ubuntu and friends.
>Based on Barry's web page, the answers are "from Vector Linux and
>Mandrake", and "in a rather ad-hoc manner" Wink
hehe, well, you found a solution it seems :) the "funniest" thing i
seen on puppy is the missing manpages, but i must say i havent
even looked if there is a pupget or dotpup available :)
> I think the solution lies in those of us who are creating things from
>source code on Puppy (which seems to be a fairly small fraction of Puppy
> packagers, as far as I can tell) to suggest/create an enhanced
>usr_devx.sfs for BarryK to consider making "official". Preferably a
>fileystem whose entire contents are built from source, on Puppy, so we
>can provide source for everything in it. I'd be interested in working with
>you on this, especially if BarryK gives such a project his "blessing"!
fine :) yes, a fully sourcecompileablesystem is the goal.
then lets start :) shouldnt be to hard to get the stuff together.
i have to find/fix the xwindows bug first i think i start from the
beginning and get all things together needed to compile xwindows
(gcc, make..tonsofotherstuff..and then the whole stuff again with itself).
i think it doesnt make sense to use the usr_devx.sfs anymore
"lost like tears in the rain" as some clone once said.
a little more lsb orientetd would be another thing to fix on the way.
besides that id also like to stick with puppy as close as possible.
do you have documentation about your changes to puppy ?
what do you think about a wiki for documenting the progress ?
in the beginning there was
mount -t unionfs -o dirs=/thenewusr=rw:/usr=ro none /usr
well, i like to here from you,
cncuser
jmarsden wrote:
>Sadly, compiling everything on Puppy itself is not (yet?) the "Puppy
>way". usr_devx.sfs was created mainly by copying binaries and headers
>rom other distributions, as Barry indicates at
>http://www.pupweb.org/puppy/development ... cratch.htm which says:
ok, i may have overread that. thanks for the info, it makes it
easy to decide what i got todo next.
>http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CncUser
>
>Looks useful, thanks for documenting your progress.
its not state of the art, right now im trying to get a freedesktop
xserver suite compiled on puppy.
>The answer to why things are missing lies in the quote from BarryK
>above -- he didn't realize how useful they were. Perl is missing
>pod2man, and there are a few other examples I have run across. >/usr/bin/curl from usr_devx.sfs is linked to a library that isn't present.
>Even in the base distro, some included commands like /sbin/ifup and
>/sbin/ifdown do not work, because the homegrown network config code >in Puppy fails to create and use /etc/network/interfaces (though the
>Busybox binary includes the relevant code, and if you create that file and
> a run-parts script (also missing for some reason), they then work as >one would expect. It's unclear to me why Puppy invented a (less flexible)
> alternative to the common network config scheme that is already "built
>in" to Busybox, and used in Debian and Ubuntu and friends.
>Based on Barry's web page, the answers are "from Vector Linux and
>Mandrake", and "in a rather ad-hoc manner" Wink
hehe, well, you found a solution it seems :) the "funniest" thing i
seen on puppy is the missing manpages, but i must say i havent
even looked if there is a pupget or dotpup available :)
> I think the solution lies in those of us who are creating things from
>source code on Puppy (which seems to be a fairly small fraction of Puppy
> packagers, as far as I can tell) to suggest/create an enhanced
>usr_devx.sfs for BarryK to consider making "official". Preferably a
>fileystem whose entire contents are built from source, on Puppy, so we
>can provide source for everything in it. I'd be interested in working with
>you on this, especially if BarryK gives such a project his "blessing"!
fine :) yes, a fully sourcecompileablesystem is the goal.
then lets start :) shouldnt be to hard to get the stuff together.
i have to find/fix the xwindows bug first i think i start from the
beginning and get all things together needed to compile xwindows
(gcc, make..tonsofotherstuff..and then the whole stuff again with itself).
i think it doesnt make sense to use the usr_devx.sfs anymore
"lost like tears in the rain" as some clone once said.
a little more lsb orientetd would be another thing to fix on the way.
besides that id also like to stick with puppy as close as possible.
do you have documentation about your changes to puppy ?
what do you think about a wiki for documenting the progress ?
in the beginning there was
mount -t unionfs -o dirs=/thenewusr=rw:/usr=ro none /usr
well, i like to here from you,
cncuser
- Lobster
- Official Crustacean
- Posts: 15522
- Joined: Wed 04 May 2005, 06:06
- Location: Paradox Realm
- Contact:
wiki for documenting
Your project is mentioned on the wikicncuser wrote: what do you think about a wiki for documenting the progress ?
http://puppylinux.org/wikka/LatestNews
Here is how to use the wiki
http://puppylinux.org/wikka/UsingThisWik
Wiki page for your project started by Jonathan
http://puppylinux.org/wikka/SelfHostingPuppy
Last edited by Lobster on Thu 19 Jan 2006, 09:40, edited 2 times in total.
There are really two projects here: one is a CNC/EMC specific, real-time-kernel-based Puppy. The second, more general, and so probably more ambitious(!), is the creation of a "self-hosting" Puppy for which full sources are provided and which is capable of building itself.
Many parts of the second one will very significantly help the first project, of course.
I just added some (first draft) details to my thinking about this to the new SelfHostingPuppy Wiki page I created earlier. BTW the link Lobster gave to that page is broken (unwanted leading letter "i"), the one above should work.
Jonathan
Many parts of the second one will very significantly help the first project, of course.
I just added some (first draft) details to my thinking about this to the new SelfHostingPuppy Wiki page I created earlier. BTW the link Lobster gave to that page is broken (unwanted leading letter "i"), the one above should work.
Jonathan
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Regarding where everything for usr_devx.sfs came from, just about all of it is from Vector 5.0STD.
The video Xfree headers were from Mandrake 9.2, as the Kdrive Xvesa server is from Xfree 4.3.0, same version as used in Mandrake.
However, Pup 1.0.7 has gone over to Xorg 6.8.1 taken straight out of Vector.
As far as I'm aware, vector 5.1STD is basically the same as 5.0.
Vector's versioning is mighty peculiar. They released 5.0STD betas, then suddently released 5.1STD.
So, install 5.0 or 5.1STD and just grab the extra files from it.
It's easy enough to open up usr_devx.sfs and create a modified version. Then, submit the modified version to us as a candidate to replace the old one!
The video Xfree headers were from Mandrake 9.2, as the Kdrive Xvesa server is from Xfree 4.3.0, same version as used in Mandrake.
However, Pup 1.0.7 has gone over to Xorg 6.8.1 taken straight out of Vector.
As far as I'm aware, vector 5.1STD is basically the same as 5.0.
Vector's versioning is mighty peculiar. They released 5.0STD betas, then suddently released 5.1STD.
So, install 5.0 or 5.1STD and just grab the extra files from it.
It's easy enough to open up usr_devx.sfs and create a modified version. Then, submit the modified version to us as a candidate to replace the old one!
hi lobster, jmarsden, barryk
lobster wrote:
>Your project is mentioned on the wiki
>http://puppylinux.org/wikka/LatestNews
thanks for pointing me to the wikipage.
the puppy rtaiproject was started somewhere around july
last year. in ausgust there was another release.
..so it hasnt started now there also was a forum thread and
news link back then. lets say its cold coffee
you can taste cold coffee here (again):
http://www.murga.org/~puppy/viewtopic.p ... highlight=
in contrary
hot coffee is that there will be a puppybreeding colony up here really soon
jmarsden wrote:
>There are really two projects here: one is a CNC/EMC specific,
>real-time-kernel-based Puppy. The second, more general, and so probably
>more ambitious(!), is the creation of a "self-hosting" Puppy for which full
>sources are provided and which is capable of building itself.
>Many parts of the second one will very significantly help the first project, of
>course.
well, the realtimeproject is basically done. as you can see in the howto
theres is nothing more to do but install a rtai kernel to make puppy
a os running in the linuxtask of a adeoskonfiguration.
its just a matter of letting the available scripts compile on a the new
made developmentenvironment. so no work here
if you are interested in cnc milling i may be able to help you a little
as for realtime itself. im only a user and havent worked with any other
realtime aplication before. from a user point of view rtai is really
unproblematic.
>I just added some (first draft) details to my thinking about this to the new
just read it. well. till m3 i agree with your milestones. with m4, well
that milestone will be done earlier for the devopmentsystem will
have no X in the early days.
i thought about doing the thing that way:
1. get a compileenvironment that is selfcompileable
- besides putting the stuff on a filesystem the use
of your package scripts will be doing the job of
packaging. we should decide if we do sourcepackages to
or just add scripts for getting them from the originator/mirrors
2. get init and the puppy initscripts working
... and you got your commandlineenvironment
also M3 will be also done with the progress of doing the stuff
mentioned above.
lobster wrote:
>Your project is mentioned on the wiki
>http://puppylinux.org/wikka/LatestNews
thanks for pointing me to the wikipage.
the puppy rtaiproject was started somewhere around july
last year. in ausgust there was another release.
..so it hasnt started now there also was a forum thread and
news link back then. lets say its cold coffee
you can taste cold coffee here (again):
http://www.murga.org/~puppy/viewtopic.p ... highlight=
in contrary
hot coffee is that there will be a puppybreeding colony up here really soon
jmarsden wrote:
>There are really two projects here: one is a CNC/EMC specific,
>real-time-kernel-based Puppy. The second, more general, and so probably
>more ambitious(!), is the creation of a "self-hosting" Puppy for which full
>sources are provided and which is capable of building itself.
>Many parts of the second one will very significantly help the first project, of
>course.
well, the realtimeproject is basically done. as you can see in the howto
theres is nothing more to do but install a rtai kernel to make puppy
a os running in the linuxtask of a adeoskonfiguration.
its just a matter of letting the available scripts compile on a the new
made developmentenvironment. so no work here
if you are interested in cnc milling i may be able to help you a little
as for realtime itself. im only a user and havent worked with any other
realtime aplication before. from a user point of view rtai is really
unproblematic.
>I just added some (first draft) details to my thinking about this to the new
just read it. well. till m3 i agree with your milestones. with m4, well
that milestone will be done earlier for the devopmentsystem will
have no X in the early days.
i thought about doing the thing that way:
1. get a compileenvironment that is selfcompileable
- besides putting the stuff on a filesystem the use
of your package scripts will be doing the job of
packaging. we should decide if we do sourcepackages to
or just add scripts for getting them from the originator/mirrors
2. get init and the puppy initscripts working
... and you got your commandlineenvironment
also M3 will be also done with the progress of doing the stuff
mentioned above.
with M5, well thats the finale in my eyes. build a puppy with all
the packages of barrys distribution, but from the packages
compiled from source.
at this stage there is only testing and bugfixing to do. but thanks
to possible debuggingpossibilities like linking agains gdb it should
be way easier then it is now with puppy.
i decided to do a little more planing and start the compileorgies on
monday. is there a other way to communicate ? i could setup a
mailinglist, for i fiend this forum rather unpractical :( (the quotin
g
is just plain dumbwork, its slow (even with lynx))
also instanmessaging or irc would be a possible way to fast exchange
the packages of barrys distribution, but from the packages
compiled from source.
at this stage there is only testing and bugfixing to do. but thanks
to possible debuggingpossibilities like linking agains gdb it should
be way easier then it is now with puppy.
i decided to do a little more planing and start the compileorgies on
monday. is there a other way to communicate ? i could setup a
mailinglist, for i fiend this forum rather unpractical :( (the quotin
g
is just plain dumbwork, its slow (even with lynx))
also instanmessaging or irc would be a possible way to fast exchange
thoughts. like to hear from you. you can also email me to
the email notet on the linux cnc wiki
barry wrote:
>It's easy enough to open up usr_devx.sfs and create a modified versio
n.
>Then, submit the modified version to us as a candidate to replace the
old
>one!
well, that may be possible. but in my opinion its a all new akirastyle
mixup that way as for there would be "nonpuppy" tools involved
when compiling stuff. so you are again where you are now -
you cant really tell whats all involved.
i think this would slowdown the progress of the whole selfcompile
project if there was a usr_devx _thats tested_ for the "binary only"
puppy. i dont think the recreatin of the puppy unleashed appstree
is hard to do. after the compile environment builds itself its plain
dull ./configure ; make ; make install ; "puppackager.sh" for most
of the packages. the progress of the whole _thing_ is documented.
so if anyone wants to make a usr_devx.sfs for the binarymix puppy
theres no problem in doing so.
the email notet on the linux cnc wiki
barry wrote:
>It's easy enough to open up usr_devx.sfs and create a modified versio
n.
>Then, submit the modified version to us as a candidate to replace the
old
>one!
well, that may be possible. but in my opinion its a all new akirastyle
mixup that way as for there would be "nonpuppy" tools involved
when compiling stuff. so you are again where you are now -
you cant really tell whats all involved.
i think this would slowdown the progress of the whole selfcompile
project if there was a usr_devx _thats tested_ for the "binary only"
puppy. i dont think the recreatin of the puppy unleashed appstree
is hard to do. after the compile environment builds itself its plain
dull ./configure ; make ; make install ; "puppackager.sh" for most
of the packages. the progress of the whole _thing_ is documented.
so if anyone wants to make a usr_devx.sfs for the binarymix puppy
theres no problem in doing so.
flame>
... this was not initially part of my post but duie to
the problems involved in my last posts i needed to
leave this here:
well, that was a hard posting..
looks like the serversoftware gets the creeps if i post
my monty python obfuscated emailadress....
simply go to the cncuser mastering howto on the wiki
and cop[y the monty pythonsstuff..... horrible no single " or ats
allowed or something ? i dont intend to find out. this sucks!
took me more the 15 minutes to get this message sent.
for i first believed it has to do to some browsercachestuff...
i even switched pc for that !!!
then a problem with the user,
then with the length of the message...
please lets get another medium for communication on the subject
of sourcecompiling puppy this forumcrap gives me braindamage
i like stuff that is fast and works. thats why i like puppy
sincerly yours
cncuser
... this was not initially part of my post but duie to
the problems involved in my last posts i needed to
leave this here:
well, that was a hard posting..
looks like the serversoftware gets the creeps if i post
my monty python obfuscated emailadress....
simply go to the cncuser mastering howto on the wiki
and cop[y the monty pythonsstuff..... horrible no single " or ats
allowed or something ? i dont intend to find out. this sucks!
took me more the 15 minutes to get this message sent.
for i first believed it has to do to some browsercachestuff...
i even switched pc for that !!!
then a problem with the user,
then with the length of the message...
please lets get another medium for communication on the subject
of sourcecompiling puppy this forumcrap gives me braindamage
i like stuff that is fast and works. thats why i like puppy
sincerly yours
cncuser
- Lobster
- Official Crustacean
- Posts: 15522
- Joined: Wed 04 May 2005, 06:06
- Location: Paradox Realm
- Contact:
Other communication channels:cncuser_ wrote: please lets get another medium for communication on the subject
of sourcecompiling puppy this forumcrap gives me braindamage
You might find this forum faster and use that
http://freeforums.bizhat.com/?mforum=com
email - mine is lobster@puppylinux.org
send a PM (private message) to others to request theirs
IRC
http://puppylinux.org/wikka/PuppyLinuxIRC
Use audacity or the Puppy recorder to send voice mail
Skype is also possible with Puppy
I am sometimes on the irc.icq.net #puppylinux IRC channel (nick jmarsden), if that works better for you. I'd also prefer mailing lists, personally, for async communication, but that doesn't seem to be "the Puppy way" at the moment.cncuser_ wrote:please lets get another medium for communication on the subject of sourcecompiling puppy this forumcrap gives me braindamage
This forum software is definitely quirky (!), but from Firefox or Mozilla it generally mostly works. If we use another medium, there's a risk that much of the Puppy community won't see the discussion and so be left out of whatever we end up doing. I'd like others to see what we are talking about and be able to comment and contribute...
Jonathan
Sounds good to me. Try to remember that the majority of Puppy developers are not from the open source Unix/Linux world and so the idea of creating a Linux distribution by copying binaries around from other places is not as strange-feeling to them as it is to you and to me In this community, the idea of building everything from source is apparently almost a radical new idea!cncuser_cantpost wrote:hot coffee is that there will be a puppybreeding colony up here really soon
That depends... the way I see it, until M4 the development system is the current official Puppy 1.0.7. M1, M2 and M3 are all about just a toolchain, one that builds under, runs under, builds itself under, and is tested under Puppy 1.0.7. Does that make sense?well. till m3 i agree with your milestones. with m4, wellthat milestone will be done earlier for the devopmentsystem will
have no X in the early days.
Maybe. I'd just rather go one step at a time, not even really thinking about creating a new Puppy variant until I have a known working and tested Puppy development toolchain I have the normal amount of control over (i.e., one built from source). So until M3 is reached, all work is (the way I was seeing this) done under Puppy 1.0.7.2. get init and the puppy initscripts working ... and you got your commandlineenvironment
Another advantage of doing it this way is that, even if the project dies early, and only ever reaches (say) M2, the result is still something that could be of use to the wider Puppy community.
Jonathan
lobster: nice. im going to post a ml address next week.
id love you to join. thanx for all the information.
bout the forum, well, i must say i dont believe
that there is any forumsoftware coming near the
benefits of a mailinglist based exchangepoint.
jmarsden wrote:
>Maybe. I'd just rather go one step at a time, not even really thinking
>about creating a new Puppy variant until I have a known working and
>tested Puppy development toolchain I have the normal amount of control
> over (i.e., one built from source). So until M3 is reached, all work is (the
> way I was seeing this) done under Puppy 1.0.7.
ok. i am probably start to setup a developmentenvirenment with lfs
and then work threw the missing parts(if any) to the usr_devx.sfs
at last the puppy unleashed core packages. but thats just my thoughts
now. in my opinion, first there was a development environment.
then there was the rest.
i really dont want to base it on puppy. i dont want to find bugs in puppy
right now. i want to rebuild it and then fix the bugs with a proper start-
position (for we got the source). its just a matter of efficiency.
i want a sourcecompiled puppy thats fully under control fast.
building packages from source on a "puppy develsystem"
doenst even come near my thoughts on how to get this started.
in that context my previous post may sound strange for i agreed with
you on M1 and M2. lets say i overread that the M0 system to compile
the compilesystem. isnt mentioned. this could be put on a puppy,
no problem, but i dont want to use much more then chmod out
of puppy on it
i know this all sounds drastic. thats how i see it. no working around,
no approximation. no "temporary solutions(tm)",
just plain gnudevelsetup.
>Another advantage of doing it this way is that, even if the project dies
>early, and only ever reaches (say) M2, the result is still something that
>could be of use to the wider Puppy community.
i dont see any way the project could die right now i even see
the possibility of 2 parallel projects with the same goal
irc is nice, maybe we can arrange a meeting.
.......
for the practicalpart. i am going to sometimes use this forum,
but really....its that much unpractical id rather miss a few post or
read them later then regularly clicking threw this thing.
i am going to get a mailinglist setup till next week.
we get problems at last when trying to put diffs or
patches into discussion where any character may be.
if anyone is interested in setting up a script that syncs a bunch
of forumthreads with the list or vice verse. just do it.
im going to refresh my LFS knowledge. last time i tried it...
about 5 years ago. i managed to come to init but then had
no time so i didnt continue anyways LFS is still big in business
and activly maintained.
i can tell you more next week. right now i think thats the way
to go, but have to take a closer look at it. you may find tons of
information about it starting here. it has a brief information
about what LFS is all about and what it is now, and can be.
http://www-128.ibm.com/developerworks/l ... index.html
you find links to severall ressources at the bottom.
the real thing:
http://www.linuxfromscratch.org/lfs/dow ... -6.1.1.pdf
and afterwards i suggest:
http://www.linuxfromscratch.org/blfs/do ... ok-6.1.pdf
thats all
good night folks
cncuser
id love you to join. thanx for all the information.
bout the forum, well, i must say i dont believe
that there is any forumsoftware coming near the
benefits of a mailinglist based exchangepoint.
jmarsden wrote:
>Maybe. I'd just rather go one step at a time, not even really thinking
>about creating a new Puppy variant until I have a known working and
>tested Puppy development toolchain I have the normal amount of control
> over (i.e., one built from source). So until M3 is reached, all work is (the
> way I was seeing this) done under Puppy 1.0.7.
ok. i am probably start to setup a developmentenvirenment with lfs
and then work threw the missing parts(if any) to the usr_devx.sfs
at last the puppy unleashed core packages. but thats just my thoughts
now. in my opinion, first there was a development environment.
then there was the rest.
i really dont want to base it on puppy. i dont want to find bugs in puppy
right now. i want to rebuild it and then fix the bugs with a proper start-
position (for we got the source). its just a matter of efficiency.
i want a sourcecompiled puppy thats fully under control fast.
building packages from source on a "puppy develsystem"
doenst even come near my thoughts on how to get this started.
in that context my previous post may sound strange for i agreed with
you on M1 and M2. lets say i overread that the M0 system to compile
the compilesystem. isnt mentioned. this could be put on a puppy,
no problem, but i dont want to use much more then chmod out
of puppy on it
i know this all sounds drastic. thats how i see it. no working around,
no approximation. no "temporary solutions(tm)",
just plain gnudevelsetup.
>Another advantage of doing it this way is that, even if the project dies
>early, and only ever reaches (say) M2, the result is still something that
>could be of use to the wider Puppy community.
i dont see any way the project could die right now i even see
the possibility of 2 parallel projects with the same goal
irc is nice, maybe we can arrange a meeting.
.......
for the practicalpart. i am going to sometimes use this forum,
but really....its that much unpractical id rather miss a few post or
read them later then regularly clicking threw this thing.
i am going to get a mailinglist setup till next week.
we get problems at last when trying to put diffs or
patches into discussion where any character may be.
if anyone is interested in setting up a script that syncs a bunch
of forumthreads with the list or vice verse. just do it.
im going to refresh my LFS knowledge. last time i tried it...
about 5 years ago. i managed to come to init but then had
no time so i didnt continue anyways LFS is still big in business
and activly maintained.
i can tell you more next week. right now i think thats the way
to go, but have to take a closer look at it. you may find tons of
information about it starting here. it has a brief information
about what LFS is all about and what it is now, and can be.
http://www-128.ibm.com/developerworks/l ... index.html
you find links to severall ressources at the bottom.
the real thing:
http://www.linuxfromscratch.org/lfs/dow ... -6.1.1.pdf
and afterwards i suggest:
http://www.linuxfromscratch.org/blfs/do ... ok-6.1.pdf
thats all
good night folks
cncuser
jarsden wrote:
>This forum software is definitely quirky (!), but from Firefox or Mozilla it
>generally mostly works. If we use another medium, there's a risk that much
> of the Puppy community won't see the discussion and so be left out of
>whatever we end up doing. I'd like others to see what we are talking about
>and be able to comment and contribute...
i use nothing but firefox, dillo and lynx for webbrowing. the problems
accured with mozilla, but as there was a internal sevrererror following...
its a forumsoftwarebug.... your browser doesnt have anything to do with
it i assume
just look at this and try to post it:
http://box.hinternet.at/postthis.txt
you really dont wont to spend hours on searching for bugs in
a forumsoftware never ment to be used for "serious stuff"
like posting sourcecode or patches where every tab, space and
char is vital. i think those puppyuseres interested in the progress
or also interested in anticipating will not have that much trouble
in using a mailinglist everyone who knows how to use mails
is able to use mailinglists,.
not everyone that is able to type (broken english for example )
is able to get a post to this forumsoftware .
the mailinglist could be linked to in the forum/wiki.
and of course there is mailinglist archives too. available to everyone!
not just the members. i think its even better to search and browse
trough it for the average puppyuser then it is to click threw numerous
threads. on the search for the result of the forumssearchengine.
ok
off
cncuser
>This forum software is definitely quirky (!), but from Firefox or Mozilla it
>generally mostly works. If we use another medium, there's a risk that much
> of the Puppy community won't see the discussion and so be left out of
>whatever we end up doing. I'd like others to see what we are talking about
>and be able to comment and contribute...
i use nothing but firefox, dillo and lynx for webbrowing. the problems
accured with mozilla, but as there was a internal sevrererror following...
its a forumsoftwarebug.... your browser doesnt have anything to do with
it i assume
just look at this and try to post it:
http://box.hinternet.at/postthis.txt
you really dont wont to spend hours on searching for bugs in
a forumsoftware never ment to be used for "serious stuff"
like posting sourcecode or patches where every tab, space and
char is vital. i think those puppyuseres interested in the progress
or also interested in anticipating will not have that much trouble
in using a mailinglist everyone who knows how to use mails
is able to use mailinglists,.
not everyone that is able to type (broken english for example )
is able to get a post to this forumsoftware .
the mailinglist could be linked to in the forum/wiki.
and of course there is mailinglist archives too. available to everyone!
not just the members. i think its even better to search and browse
trough it for the average puppyuser then it is to click threw numerous
threads. on the search for the result of the forumssearchengine.
ok
off
cncuser
- Lobster
- Official Crustacean
- Posts: 15522
- Joined: Wed 04 May 2005, 06:06
- Location: Paradox Realm
- Contact:
No problem.cncuser___ wrote:lobster: nice. im going to post a ml address next week.
id love you to join. thanx for all the information.
Now that Puppy is bootstrapped (so to speak)
I look forward to a compiler and other components being available.
Being a cructacean fisher I am more interested in cod than code. Part of the job of The Foundation is to support coders as best we can.
I look forward to the email forum.
Your efforts, iniative and interest are very much appreciated
-
- Posts: 198
- Joined: Sat 28 Jan 2006, 15:55
I too am interested in working with this.
I have been frustrated by limitations when trying to compile apps from source.
I do understand there are other ways of doing things (like ripping apart binary RPMs) which do work surprisingly well...but are not the Linux way.
I think we do want to support Linux hackers in order to help ensure that the Windows-refugees get the full potential that this project is cpable of realising
Agree that forums are weak for this kind of thing.
I like IRC, but am only available occasionally, so we need an asynchronous method. Wiki is good for discussing milestones & publishing HowTos, but not discussion...
Mailing list would suit me
F
I have been frustrated by limitations when trying to compile apps from source.
I do understand there are other ways of doing things (like ripping apart binary RPMs) which do work surprisingly well...but are not the Linux way.
I think we do want to support Linux hackers in order to help ensure that the Windows-refugees get the full potential that this project is cpable of realising
Agree that forums are weak for this kind of thing.
I like IRC, but am only available occasionally, so we need an asynchronous method. Wiki is good for discussing milestones & publishing HowTos, but not discussion...
Mailing list would suit me
F
-
- Posts: 198
- Joined: Sat 28 Jan 2006, 15:55
seems there is not really mutch interessts in a correct puppy development environment...
no mor "take this from this distribution", "no this is not possible ecause of this essential tool is missing for compiling" and so on
would be nice. because out there i know are allready many puppydevs extending the usr_devx.sfs and it would be nice if we have a standard one to work with for all developers...
i'm playing at the moment with linuxfromscratch, and check if there is a possibility to create a complete develenvironment, perhaps i have success, perhaps not, perhaps someone helps me, perhaps not
and as usual, when no one is interessted i'm doing it for me, so please no one feel forced to change something to his "puppy" :-p
i keep you informed about my success or notsuccess storys..
regards
costal
no mor "take this from this distribution", "no this is not possible ecause of this essential tool is missing for compiling" and so on
would be nice. because out there i know are allready many puppydevs extending the usr_devx.sfs and it would be nice if we have a standard one to work with for all developers...
i'm playing at the moment with linuxfromscratch, and check if there is a possibility to create a complete develenvironment, perhaps i have success, perhaps not, perhaps someone helps me, perhaps not
and as usual, when no one is interessted i'm doing it for me, so please no one feel forced to change something to his "puppy" :-p
i keep you informed about my success or notsuccess storys..
regards
costal