massix-devel Mailing List for massix
Status: Planning
Brought to you by:
lukisi71
You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(33) |
Nov
(9) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Luca D. <luc...@gm...> - 2007-01-18 18:56:51
|
In the file previously attached I mentioned a svn checkout command It was svn co https://massix.svn.sourceforge.net/svnroot/massix/dev/trunk/massix Now I changed it. We should use svn co https://massix.svn.sourceforge.net/svnroot/massix/dev/tags/1.0/massix I created a tagged version, so that I can go on with the changes without breaking anything. --Luca |
From: Luca D. <luc...@gm...> - 2007-01-18 14:42:35
|
Hi all The scripts that I was working on have reached a good status. They can be used to download all needed packages and build a bare system. That system will be built using package-user-management. If you are willing to test them on a machine of yours I would appreciate. Feedback, suggestions, hints are welcome. Since the scripts are in a SVN repository, you could also send me patches if you need to correct something. To get started, I attach a document that is also in the svn repository and explains how to use the scripts. Cheers --Luca PS What do I mean with "bare" system? It is a plain LFS system (no X, not many tools, ...) with NFS-utils. You should know what it looks like! :P |
From: Luca D. <luc...@gm...> - 2006-12-19 18:17:46
|
Dear all first of all, the actual point of this email: I wish that you all will have a Merry Christmas time! Then, just for your knowledge, some little news. I'm working on some scripts that will automate the work of building from scratch our operating system. I hope that when this is done, we'll be able to test different kinds of configuration for various packages in few hours, even if the involved packages are some core ones such as chain tools. At the moment the scripts are not ready at all. I would not call them even at alpha. Anyway, if you want to have a look, they are in Subversion: svn co https://massix.svn.sourceforge.net/svnroot/massix/dev/trunk/massix Again, at the moment I use the repository as a place to store the files, but they are not what I want them to be. So don't even try to send me patches. I hope to be able to let you know soon that the scripts are at a point where we can start from. Then, any collaboration will be much appreciated. Again, merry Christmas and happy new year. --Luca |
From: kriss <chr...@al...> - 2006-11-21 21:15:33
|
i'm ~fine thanks i didn't use package user management sorry i use jhalfs to download packages & to extract commandes and i run commandes manually changed CLFS in MASSIX that's all for now after making users i'll change to remote all packages that you want i didn't script cause i prefer see what's happen but using jhalfs for MASSIX look easy i 'll not build lilo and bin86 i already have grub and no floppy for daemons that are not remote : ok (bind, dhcp ...) for the rest remote so i'll take note of all i do when you tell about flags else than dirs ?!? it's easy to have all commandes in 1 file so assumming the partition is ok and sources are here it will run in one shot i'll post it here when ok if you put your fingers in jhalfs it's more long than changing final commandes so i didn't try -- http://sourceforge.net/projects/massix/ |
From: Luca D. <luc...@gm...> - 2006-11-21 20:20:05
|
I think it is better to have bash and the toolchain locally installed. We will have more troubles than advantages trying to use these 2 pieces remotely. As I said, I worked much less hard than Kriss did. I had very little time to devote to it. At the moment I have written some scripts to try and automate the process of building the system. I didn't even reach the beginning of chapter 5 (building temporary system) By the way, Kriss, have you scripted your build? Or have you written down the steps you did? I think this should be our real work now, so that when we want to test some new flag in configuring a package we can redo the whole build easily and without errors. When the scripts I'm working on will be reasonably robust I will put them in the SVN server of sourceforge. --Luca PS Kriss, I hope you are fine now. |
From: kriss <chr...@al...> - 2006-11-21 17:06:54
|
Le mardi 21 novembre 2006 =C3=A0 17:44 +0100, Luca Dionisi a =C3=A9crit : > Kriss, I already said local for bash and glibc. > Are you suggesting to make them remote? >=20 > --Luca >=20 > -----------------------------------------------------------------------= -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share= your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Massix-devel mailing list > Mas...@li... > https://lists.sourceforge.net/lists/listinfo/massix-devel yes remote sorry ps i didn't work hard : migraines --=20 http://sourceforge.net/projects/massix/ |
From: Luca D. <luc...@gm...> - 2006-11-21 16:44:21
|
Kriss, I already said local for bash and glibc. Are you suggesting to make them remote? --Luca |
From: Luca D. <luc...@gm...> - 2006-11-21 16:21:21
|
You are working hard, Kriss! I am trying to write some scripts to automate the build process. Have you kept track of what you've done to build the system? About users and groups, I have no idea. Let's go with the usual settings recommended by the book (LFS or Cross-LFS) --Luca |
From: kriss <chr...@al...> - 2006-11-21 04:47:58
|
hi does it make more sense to make bash & glibc local ? while i'm building a MASSIX i choosed to add some packages (nfs-utils,bind, gmp ...) so we can use MASSIX on the net don't you have more ? (and local or not ?) also i'm facing a problem now : http://cross-lfs.org/view/svn/x86_64-64/chroot/pwdgroup.html i'm not sure what to do so to have a proper use of MASSIX can you post a list of users & groups -- REGARDS && THANKS CIAO KRISS |
From: Luca D. <luc...@gm...> - 2006-11-04 22:15:14
|
On 11/4/06, kriss <chr...@al...> wrote: > do you want a multilib or pure 64 ? > i prefere a pure 64 > also i can do both if you want go ahead with pure 64 for now. Thanks --Luca |
From: kriss <chr...@al...> - 2006-11-04 19:43:53
|
Luca yes i'll try a clfs 64bit do you want a multilib or pure 64 ? i prefere a pure 64 also i can do both if you want sorry for the late reply -- REGARDS && THANKS CIAO KRISS |
From: Luca D. <luc...@gm...> - 2006-11-04 14:48:52
|
Hi I completed the list. It follows. I will soon try a new LFS build keeping in mind this list. As an info, I use the package-users technique. Kriss, are you going to try a cross-compile 64bit system? --Luca Note: in the examples below the directory "local" is intended as "local to the site", not "local to the machine". See http://www.linuxfromscratch.org/blfs/view/svn/introduction/position.html In how many ways does it make sense to say that a package may or may not be installed/executed remotely? If we have some executables that could be launched from any of our machines and some other ones that should be launched only from the current machine. We can place the shared ones in /usr/local/bin and the private ones in /usr/bin. Then the PATH envvar is used to be able to access any of them. But /usr/local/bin is a network mounted directory, while /usr/bin is not. The same goes for /usr/sbin (for root). If we have some shared libraries that could be used from any of our machines and some others that should be used only from the current machine. We can place the shared ones in /usr/local/lib and the private ones in /usr/lib. Then the system default loader path tells the system to search for shared libs in these directories. That is, edit /etc/ld.so.conf and execute ldconfig. But /usr/local/lib is network mounted and the other is not. If we have some man-pages that we want to share (e.g. the man of an application that we have shared, or a manual page that is the same for all the versions of an application that has been compiled in different ways in our machines) and other ones that we don't. We can place the shared ones in /usr/local/share/man and the private ones in /usr/share/man. Then the MANPATH envvar is used to be able to access any of them. But /usr/local/... is network mounted and the other is not. The same goes for directories /usr/share/doc and /usr/share/info and for the envvar INFOPATH. If a package that we share writes data about its installation in a pkgconfig, we'll have to ensure that we use the correct PKG_CONFIG_PATH when building new packages that depend on this one. If a package that we have choose to share provides include files, or anyway we have include files that we want to be used from any machine, and other ones that we don't. We can put the shared ones in /usr/include and the private ones in /usr/local/include. Then we have to use the correct CPPFLAGS when we build new packages that depend on this one. For other info see: http://www.linuxfromscratch.org/blfs/view/svn/introduction/beyond.html Describes how to use PATH, MANPATH and other envvar in order to tell to the system where to find various things. http://xahlee.org/UnixResource_dir/_/ldpath.html A description by David Barr (the link from the BLFS page is not working anymore) on the use and misuse of LD_LIBRARY_PATH LFS-base packages to install locally or remotely Name local remote 1) linux-libc-headers x 2) man-pages x 3) glibc x 4) binutils x 5) gcc x 6) db x 7) coreutils x 8) iana-etc x 9) m4 x 10) bison x 11) ncurses x 12) procps x 13) sed x 14) libtool x 15) perl x 16) readline x 17) zlib x 18) autoconf x 19) automake x 20) bash x 21) bzip2 x 22) diffutils x 23) e2fsprogs x 24) file x 25) findutils x 26) flex x 27) GRUB x 28) gawk x 29) gettext x 30) grep x 31) groff x 32) gzip x 33) inetutils x 34) IPRoute2 x 35) kbd x 36) less x 37) make x 38) man-DB x 39) mktemp x 40) module-Init-Tools x 41) patch x 42) psmisc x 43) shadow x 44) sysklogd x 45) sysvinit x 46) tar x 47) texinfo x 48) udev x 49) util-linux x 50) vim x Notes: 1,3 & 4) The "toolchain" is strictly related to the kernel running in the machine, I think. 8) is composed by files that have to stay in /etc. 14,18 & 19) I think there will be no problem in putting "bin", "lib" and "include" stuff in /usr/local. But this set of tools (called autotools) installs many things in /usr/share: the directories aclocal, libtool and autoconf. How should those things be managed? 15) This is quite important, 'cause many apps come in form of perl scripts. There is a /usr/lib/perl5 dir with a dir site_perl. We shall understand deeper the meanings of these locations and files. 18) See 14) 19) See 14) 20) Bash and other shells usually resides in /bin. 23) e2fsprogs has many programs in /sbin. 27) GRUB is quite related to a particular system. Its aim is to write the boot record of the disk of a machine. |
From: Luca D. <luc...@gm...> - 2006-10-31 16:34:26
|
On 10/31/06, kriss <chr...@al...> wrote: > Luca > by /shared i mean to install all that is shared > in a root dir called /shared I choosed /usr/local to install all that is shared because it is a widely used directory for installations and... well, see: http://www.linuxfromscratch.org/blfs/view/stable/introduction/position.html about using, e.g., /usr/site. --Luca |
From: kriss <chr...@al...> - 2006-10-31 15:55:53
|
Luca by /shared i mean to install all that is shared in a root dir called /shared many packages want use /share anyway you don't speak in fixed way so for testing few packages ok |
From: Luca D. <luc...@gm...> - 2006-10-31 15:22:19
|
On 10/31/06, kriss <chr...@al...> wrote: > hi Luca > > you'r confusing me : > the shared bin & lib are in /local > the private man are in /local You are right... I correct this sentence: If we have some man-pages that we want to share (e.g. the man of an application that we have shared, or a manual page that is the same for all the versions of an application that has been compiled in different ways in our machines) and other ones that we don't. We can place the shared ones in /usr/local/share/man and the private ones in /usr/share/man. Then the MANPATH envvar is used to be able to access any of them. But /usr/local/... is network mounted and the other is not. The same goes for directories /usr/share/doc and /usr/share/info and for the envvar INFOPATH. > i think you must choose another way than /local > /shared ?!? Here what do you mean? /usr/share means shared among apps, not shared among machines. /usr/local/share contains files shared among machines and among apps. > also for base packages : > if something strange comes we can't repair local > or remote with this style My goal at the moment is to see what we can achieve at most. Sure the system won't be robust in many ways. After, we will tune things up for more performance and stability. Many of the base packages will go in private then. Thanks for the feedback kriss! --Luca |
From: kriss <chr...@al...> - 2006-10-31 14:41:01
|
hi Luca you'r confusing me : the shared bin & lib are in /local the private man are in /local i think you must choose another way than /local /shared ?!? also for base packages : if something strange comes we can't repair local or remote with this style for site_perl : this dir is for modules coming from cpan &/or for the purpose of the distro it depends of the distro it's to haven't to recompile all perl and we can use same names for different modules (it's not usual) i say this from my bad memory about perl so often packages from cpan refuse to compil so i stopped learning perl a long time ago for this time we don't have a usable system with this list but it's coming -- REGARDS && THANKS CIAO KRISS |
From: Luca D. <luc...@gm...> - 2006-10-31 11:27:17
|
Hi all I've done a little bit of work in choosing the apps to build as "remote-able" in the massix o.s. I've tried to explain my point of view first. It is not such a big work, but I had very little time. I append to this mail my notes. They are not complete, as you can see, for the lfs-base system. cheers --Luca Note: in the examples below the directory "local" is intended as "local to the site", not "local to the machine". See http://www.linuxfromscratch.org/blfs/view/svn/introduction/position.html In how many ways does it make sense to say that a package may or may not be installed/executed remotely? If we have some executables that could be launched from any of our machines and some other ones that should be launched only from the current machine. We can place the shared ones in /usr/local/bin and the private ones in /usr/bin. Then the PATH envvar is used to be able to access any of them. But /usr/local/bin is a network mounted directory, while /usr/bin is not. The same goes for /usr/sbin (for root). If we have some shared libraries that could be used from any of our machines and some others that should be used only from the current machine. We can place the shared ones in /usr/local/lib and the private ones in /usr/lib. Then the system default loader path tells the system to search for shared libs in these directories. That is, edit /etc/ld.so.conf and execute ldconfig. But /usr/local/lib is network mounted and the other is not. If we have some man-pages that we want to share (e.g. the man of an application that we have shared, or a manual page that is the same for all the versions of an application that has been compiled in different ways in our machines) and other ones that we don't. We can place the shared ones in /usr/share/man and the private ones in /usr/local/share/man. Then the MANPATH envvar is used to be able to access any of them. But /usr/local/... is network mounted and the other is not. The same goes for directories /usr/share/doc and /usr/share/info and for the envvar INFOPATH. If a package that we share writes data about its installation in a pkgconfig, we'll have to ensure that we use the correct PKG_CONFIG_PATH when building new packages that depend on this one. If a package that we have choose to share provides include files, or anyway we have include files that we want to be used from any machine, and other ones that we don't. We can put the shared ones in /usr/include and the private ones in /usr/local/include. Then we have to use the correct CPPFLAGS when we build new packages that depend on this one. For other info see: http://www.linuxfromscratch.org/blfs/view/svn/introduction/beyond.html Describes how to use PATH, MANPATH and other envvar in order to tell to the system where to find various things. http://xahlee.org/UnixResource_dir/_/ldpath.html A description by David Barr (the link from the BLFS page is not working anymore) on the use and misuse of LD_LIBRARY_PATH LFS-base packages to install locally or remotely Name local remote 1) linux-libc-headers x 2) man-pages x 3) glibc x 4) binutils x 5) gcc x 6) db x 7) coreutils x 8) iana-etc x 9) m4 x 10) bison x 11) ncurses x 12) procps x 13) sed x 14) libtool x 15) perl x 16) readline x 17) zlib x 18) autoconf x 19) automake x Notes: 1,3 & 4) The "toolchain" is strictly related to the kernel running in the machine, I think. 8) is composed by files that have to stay in /etc. 14,18 & 19) I think there will be no problem in putting "bin", "lib" and "include" stuff in /usr/local. But this set of tools (called autotools) installs many things in /usr/share: the directories aclocal, libtool and autoconf. How should those things be managed? 15) This is quite important, 'cause many apps come in form of perl scripts. There is a /usr/lib/perl5 dir with a dir site_perl. We shall understand deeper the meanings of these locations and files. 18) See 14) 19) See 14) |
From: kriss <chr...@al...> - 2006-10-20 21:36:08
|
Luca i'll look at clfs book soon as give the lfs list after i'll make my first pre-Massix so -- THANKS && REGARDS CIAO KRISS |
From: Luca D. <luc...@gm...> - 2006-10-20 15:00:00
|
On 10/17/06, kriss <chr...@al...> wrote: > Luca > > smart look smart but i'm not sure it will be the best > i don't know python I think we have to use packages, I hope we'll do very little modifications in others' code. > > may be it's time cause if you know what sources > to provide in Massix (*lfs, else)... Indeed, I said it is not time 'cause I have yet to choose what are the packages. In particular, I think the first thing is to choose which apllications should be installed in a network-mounted file system. Then, we have to find the right options to ./configure or what else, to install the files in the correct directories. Then we have to try and make sure that such a system, with network-mounted parts, works fine. I've had little time recently. I will try to make a list of packages from lfs-book and choose which to move on-line. Sure I will post the list and welcome any suggestion. --Luca |
From: kriss <chr...@al...> - 2006-10-17 21:33:08
|
Luca smart look smart but i'm not sure it will be the best i don't know python may be it's time cause if you know what sources to provide in Massix (*lfs, else) it's time to work on the install before having a finallized Massix it's a goal of the project : a easy to install os -- THANKS && REGARDS CIAO KRISS |
From: Luca D. <luc...@gm...> - 2006-10-17 15:54:56
|
Since it has been asked... I found (quite by chance) a interesting project. It is a package manager supporting several package format. Perhaps we might consider using it for massix distribution. Anyway, it's not the time. But here it is: http://labix.org/smart --Luca |
From: Luca D. <luc...@gm...> - 2006-10-17 07:20:28
|
On 10/17/06, kriss <chr...@al...> wrote: > Luca > can we know what is the way you want > to have 64 bits Massix ? After a bit of search in the lfs-support, now I know that it is not recommended to use LFS for 64 bit. So I think the answer will be cross-lfs. > also to stress you a little : > what kind of installer for Massix ? No idea. --Luca |
From: kriss <chr...@al...> - 2006-10-17 06:36:09
|
Luca can we know what is the way you want to have 64 bits Massix ? also to stress you a little : what kind of installer for Massix ? -- THANKS && REGARDS CIAO KRISS |
From: kriss <chr...@al...> - 2006-10-12 22:33:20
|
hi my problem was trying compil lfs on dapper x86_64 if i was knowing what i do i had recompiled glib, gcc, listdc++ in this host gcc is not normal i said that in lfs mailling-list they said that it s a i686 project this is wrong they said that is only tested on x86 anyway patchs and all for 64 bits systems are in clfs book sure if you know everything to handle the compil process to make 64 bits lfs you can this is not my case so i tryed clfs x86_64 multilib and big problems comes with X (blfs) not interesting for now for performance, Luca, i'm not expert here too but it depend of kernel, apps and processor (no ?) pentium is designed for 32 bits working (no ?) if i want to run some apps 24/24 true64 bits kernel and apps will make a big diff a cross compiler is a + it may be an option --Kriss |
From: Luca D. <luc...@gm...> - 2006-10-12 17:39:49
|
I think it's time to start a new topic. Kriss wrote about a problem with LFS and x86_64 machines. Of course support for this hardware is a must. I found in the lfs mail archives the message where he asked for help. The problem was the mixing of a 64bit host system and a 32bit target. Kriss, could you explain precisely what the problem was, which your solution has been, and so on? My machine is a Pentium D. It has support for 64 bit architecture (EM64T) I used a Fedora Core 5 as host and I built as usual a LFS. IIRC I downloaded the ISO for i386 (not the x86_64 one) so I should have a 32 bit system now. OT: do you think I'm missing a lot of performance? Anyway, I don't get how a Cross-LFS is needed to build a x86_64 system with a x86_64 host. --Luca |