Re: Partition tools (Re: debian-installer status -- 2002-07-29)
* Joey Hess [EMAIL PROTECTED] [2002-09-11 10:02]: Junichi Uekawa wrote: It might be nice to automate the not-yet-uploaded package detection, and compile them all, and other thing... find -type d -name debian | while read A; do ( cd $(dirname $A); debuild-pbuilder; ) done Note that build/Makefile already does something similar when building with DEBUG=y: if [ $(DEBUG) = y ] ; then \ mkdir -p $(DEBUGUDEBDIR); \ cd $(DEBUGUDEBDIR); \ export DEB_BUILD_OPTIONS=debug; \ $(APT_GET) source --build --yes $$needed; \ But what the original poster wanted is building cvs version of udeb, which are not yet in the archive. It will be nice to have a script which : * build cdebconf * install libdebconf and libdebconf-dev * build every udeb against current cvs libdebconf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Partition tools (Re: debian-installer status -- 2002-07-29)
* Junichi Uekawa wrote: | It might be nice to automate the not-yet-uploaded package | detection, and compile them all, and other thing... I'm not sure. I don't like «build all packages and upload» is a good idea. However, if somebody extends uptodatecheck.sh with a --build I wouldn't mindt. * Thomas Poindessous | But what the original poster wanted is building cvs version of udeb, which | are not yet in the archive. It will be nice to have a script which : | * build cdebconf | * install libdebconf and libdebconf-dev | * build every udeb against current cvs libdebconf There is no reason to build against cvs libdebconf unless the soname changes. it's a shared library. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Partition tools (Re: debian-installer status -- 2002-07-29)
* Jim Lynch | Absolutely... I had to cd into each of several dirs containing source | for udebs and run dpkg-buildpackage in each one. I'd like to see a | situation under which I would type make -once-, and it builds all the | udebs. Why? (as in, I think that is a silly idea.) | Yes, I understand they will be downloadable someday... For now, let | me type make once to build everything :) Most of them are in the archive already.. those which aren't are in incoming or similar. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Partition tools (Re: debian-installer status -- 2002-07-29)
Tollef Fog Heen [EMAIL PROTECTED] immo vero scripsit: | Absolutely... I had to cd into each of several dirs containing source | for udebs and run dpkg-buildpackage in each one. I'd like to see a | situation under which I would type make -once-, and it builds all the | udebs. Why? (as in, I think that is a silly idea.) It might be nice to automate the not-yet-uploaded package detection, and compile them all, and other thing... find -type d -name debian | while read A; do ( cd $(dirname $A); debuild-pbuilder; ) done regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Partition tools (Re: debian-installer status -- 2002-07-29)
Junichi Uekawa wrote: It might be nice to automate the not-yet-uploaded package detection, and compile them all, and other thing... find -type d -name debian | while read A; do ( cd $(dirname $A); debuild-pbuilder; ) done Note that build/Makefile already does something similar when building with DEBUG=y: if [ $(DEBUG) = y ] ; then \ mkdir -p $(DEBUGUDEBDIR); \ cd $(DEBUGUDEBDIR); \ export DEB_BUILD_OPTIONS=debug; \ $(APT_GET) source --build --yes $$needed; \ cd ..; \ else \ echo Need to download : $$needed; \ if [ -n $$needed ]; then \ $(APT_GET) -dy install $$needed; \ fi; \ fi; \ -- see shy jo msg22056/pgp0.pgp Description: PGP signature
Re: Partition tools (Re: debian-installer status -- 2002-07-29)
On 30 Aug 2002 17:05:52 +0200 Tollef Fog Heen [EMAIL PROTECTED] wrote: * Jim Lynch | Over the past few days, I tried to build debian-installer, and | subtracting some minor frustrations that could have been cleared up | in the docs, it was pretty easy to build, if tedious: essentially, I | had to run a build process much more than once. You shouldn't. Can you tell me a bit more about what was unclear, if possible how the docs should be improved. Also, you shouldn't need to build anything multiple times. Absolutely... I had to cd into each of several dirs containing source for udebs and run dpkg-buildpackage in each one. I'd like to see a situation under which I would type make -once-, and it builds all the udebs. Yes, I understand they will be downloadable someday... For now, let me type make once to build everything :) -Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Partition tools (Re: debian-installer status -- 2002-07-29)
On Sat, Aug 31, 2002 at 12:00:18AM -0700, Jim Lynch wrote:
On 30 Aug 2002 17:05:52 +0200
Tollef Fog Heen [EMAIL PROTECTED] wrote:
* Jim Lynch
| Over the past few days, I tried to build debian-installer, and
| subtracting some minor frustrations that could have been cleared up
| in the docs, it was pretty easy to build, if tedious: essentially, I
| had to run a build process much more than once.
You shouldn't. Can you tell me a bit more about what was unclear, if
possible how the docs should be improved. Also, you shouldn't need to
build anything multiple times.
Absolutely... I had to cd into each of several dirs containing source
for udebs and run dpkg-buildpackage in each one. I'd like to see a
situation under which I would type make -once-, and it builds all the
udebs. Yes, I understand they will be downloadable someday... For now,
let me type make once to build everything :)
I use th shell script (attached). And then I do a
find /path -name *.udeb -exec cp {} /path/build/localudebs/ \;
--
Thomas Poindessous
[EMAIL PROTECTED]
compile_di.sh
Description: Bourne shell script
Re: Partition tools (Re: debian-installer status -- 2002-07-29)
* Jim Lynch | Over the past few days, I tried to build debian-installer, and | subtracting some minor frustrations that could have been cleared up | in the docs, it was pretty easy to build, if tedious: essentially, I | had to run a build process much more than once. You shouldn't. Can you tell me a bit more about what was unclear, if possible how the docs should be improved. Also, you shouldn't need to build anything multiple times. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Partition tools (Re: debian-installer status -- 2002-07-29)
On Mon, 19 Aug 2002 21:09:22 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: On Mon, Aug 19, 2002 at 05:42:30PM -0700, Jim Lynch wrote: On Mon, 29 Jul 2002 18:46:41 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: I am in complete agreement that we would not want to include EVMS, XFS or similar in our default kernel unless (or until) they are part of the official kernel. Please find the reason for EVMS not being incorporated. Also, is LVM not going to be part of the kernel in the future? I'm not totally sure about this part, but I thought I had read that Linus wants LVM out; note that there have been fairly nasty core-level bugs in LVM in the recent past (the last one I knew of involved main stack overflow causing big filesystem problems: I recall patching to kill that particular bug on my personal machine). Pay special attention to the word 'default' in my sentence above; it is the core of my opinion on this subject. I believe that the default kernel should be sufficiently generic to enable a wide variety of users to install the system, but not so overfeatured as to be difficult to support, or to introduce too many unknowns into the installation process. OK, fair enough. Does your opinion differ wrt what's actually compiled into the kernel vs what modules are included? I think that we should either distribute one kernel per arch that includes as much as possible in the way of module drivers, offer multiple choices (as we do now) or offer a site or live-filesystem cd image which compiles an installation kernel which is customized for each individual user. It would also be good to work toward standardizing naming of volumes (err, allowing such naming of volumes to happen in the installer), and allowing the creation of EVMS, LVM, LVM2 (worth a look!) volumes. Current installer does not allow these things; I think work in these areas should begin as quickly as possible. Should the kernel VFS be extended to allow things along these lines? I had planned to try to build some boot-floppies which could be used with woody to install directly onto EVMS volumes. However, I think the time (if I find that I have it) might be better spent getting something more permanent into debian-installer. Given that I know almost nothing about d-i, this would probably be a significant investment of resources to get up to speed and implement something. Over the past few days, I tried to build debian-installer, and subtracting some minor frustrations that could have been cleared up in the docs, it was pretty easy to build, if tedious: essentially, I had to run a build process much more than once. Overall, it's not too difficult, I got it built and tried it. It's definitely coming along, and if you get time, you should try to build it. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Partition tools (Re: debian-installer status -- 2002-07-29)
On Mon, 29 Jul 2002 18:46:41 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: On Tue, Jul 30, 2002 at 12:09:08AM +0200, Eduard Bloch wrote: #include hallo.h Matt Zimmerman wrote on Mon Jul 29, 2002 um 09:00:42AM: What is the basis for your objection? Are you going to try to stop someone else from doing this development? Pretty simple. The same reason as for not having XFS in the default kernel: - development stage Yes, but xfs is getting cleaner as time goes by. Development thereof seems to be in capable hands, whose owners have fairly deep understanding of the kernel. - not in the kernel Reasons for things not being in the kernel are not always technical. Will you not want grep because it is not in the kernel? (OK, sorry, not the greatest example; point being there are developments that should be looked at; some of those are modules developed in periphery. In this way, changes can be prepared for sooner.) - changes lots of stuff in the kernel Sheesh... OF COURSE it does: it is a kernel module. How will you get an external module in without doing so? What does either do other than add themselves to the kernel as a module? Be specific. OK, maybe you're right WRT the -default- debian kernel. - not stable or has other nasty bugs Specifics. No fud, please. Please include references and examples. - future stable version breaks things Future fud. How would you know? All you can do is guess. The only thing I can grant you here, is we've all seen that happen in the past. I know that you like EVMS, and I do too, but it's still beta-ware. You may argue that it will be stable to the time when Sarge is ready - but we do also release with 2.2.x as default 1.5years after 2.4 release. I am in complete agreement that we would not want to include EVMS, XFS or similar in our default kernel unless (or until) they are part of the official kernel. Please find the reason for EVMS not being incorporated. Also, is LVM not going to be part of the kernel in the future? I'm not totally sure about this part, but I thought I had read that Linus wants LVM out; note that there have been fairly nasty core-level bugs in LVM in the recent past (the last one I knew of involved main stack overflow causing big filesystem problems: I recall patching to kill that particular bug on my personal machine). From what I know about LVM and EVMS, the latter's development is being carried out by people who understand the kernel; the former, not so much: some of the LVM developers had a falling out with others; the group who understood kernel issues were harping on technical issues. They got kicked off the mailing list for doing so. Hence, they are left with people who don't understand the kernel quite as much. I propose that we measure the stability of each, and make a decision based on stability, rather than whether or not a certain module passed political muster to be included in the kernel. I further propose that we take looks at these technologies more often, looking at the development status and trying things out. In addition, let's get more people working on debian-installer. Having built it once, I find that process easier than b-f (having also built -that- once as well). Now I need better floppies, so I can try it :) However, I am willing to do some work to support EVMS in d-i, and to provide EVMS-enabled installation media for those who are interested in trying it. That's definitely more like it... there are many who would want to try such things. It would also be good to work toward standardizing naming of volumes (err, allowing such naming of volumes to happen in the installer), and allowing the creation of EVMS, LVM, LVM2 (worth a look!) volumes. Current installer does not allow these things; I think work in these areas should begin as quickly as possible. Should the kernel VFS be extended to allow things along these lines? If I can use this experience to improve volume management support in d-i, then I would hope that my contributions would be welcome. As far as I'm concerned, such contributions would be very welcome. - mdz -Jim P.S., I just noticed I'm replying to a 3-week-old message; hope my comments are still appropriate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Partition tools (Re: debian-installer status -- 2002-07-29)
On Mon, Aug 19, 2002 at 05:42:30PM -0700, Jim Lynch wrote: On Mon, 29 Jul 2002 18:46:41 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: I am in complete agreement that we would not want to include EVMS, XFS or similar in our default kernel unless (or until) they are part of the official kernel. Please find the reason for EVMS not being incorporated. Also, is LVM not going to be part of the kernel in the future? I'm not totally sure about this part, but I thought I had read that Linus wants LVM out; note that there have been fairly nasty core-level bugs in LVM in the recent past (the last one I knew of involved main stack overflow causing big filesystem problems: I recall patching to kill that particular bug on my personal machine). Pay special attention to the word 'default' in my sentence above; it is the core of my opinion on this subject. I believe that the default kernel should be sufficiently generic to enable a wide variety of users to install the system, but not so overfeatured as to be difficult to support, or to introduce too many unknowns into the installation process. There is no reason why these systems should not be options if someone is willing to do the work, but I would caution against their inclusion in the default kernel. From what I know about LVM and EVMS, the latter's development is being carried out by people who understand the kernel; the former, not so much: some of the LVM developers had a falling out with others; the group who understood kernel issues were harping on technical issues. They got kicked off the mailing list for doing so. Hence, they are left with people who don't understand the kernel quite as much. I don't keep up with LVM, or with kernel politics, and I am not qualified to judge anyone's kernel prowess, but as far as I know, LVM is no longer being actively developed, and current development is focused on LVM2. EVMS is, of course, a separate project. I propose that we measure the stability of each, and make a decision based on stability, rather than whether or not a certain module passed political muster to be included in the kernel. I would add to this that we should be very conservative in our decisions. I further propose that we take looks at these technologies more often, looking at the development status and trying things out. This is what kernel-patch packages are for. There don't seem to be any for LVM2 at the moment, but I would like to see one. There is, of course, one for EVMS. However, I am willing to do some work to support EVMS in d-i, and to provide EVMS-enabled installation media for those who are interested in trying it. That's definitely more like it... there are many who would want to try such things. It would also be good to work toward standardizing naming of volumes (err, allowing such naming of volumes to happen in the installer), and allowing the creation of EVMS, LVM, LVM2 (worth a look!) volumes. Current installer does not allow these things; I think work in these areas should begin as quickly as possible. Should the kernel VFS be extended to allow things along these lines? I had planned to try to build some boot-floppies which could be used with woody to install directly onto EVMS volumes. However, I think the time (if I find that I have it) might be better spent getting something more permanent into debian-installer. Given that I know almost nothing about d-i, this would probably be a significant investment of resources to get up to speed and implement something. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Partition tools (Re: debian-installer status -- 2002-07-29)
#include hallo.h Karl M. Hegbloom wrote on Sun Jul 28, 2002 um 11:01:42PM: Tollef Fog Heen [EMAIL PROTECTED] writes: [...], we need some more partition tools; there has been some discussion on debian-boot regarding it but no final decision has been reached, though several solutions have been presented. I wonder if the partition tools can do EVMS, or if a plugin should be made for that? Anyone else want to use EVMS at some point? I object. EVMS is nice and it is the future. But currently, I miss some features and the guys are preparing a new version with major changes. Lvm10 is known to be stable enough, EVMS is not (yet). Gruss/Regards, Eduard. -- Genieße dein Leben ständig, denn du bist länger tot als lebendig. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Partition tools (Re: debian-installer status -- 2002-07-29)
On Mon, Jul 29, 2002 at 08:26:51AM +0200, Eduard Bloch wrote: #include hallo.h Karl M. Hegbloom wrote on Sun Jul 28, 2002 um 11:01:42PM: Tollef Fog Heen [EMAIL PROTECTED] writes: [...], we need some more partition tools; there has been some discussion on debian-boot regarding it but no final decision has been reached, though several solutions have been presented. I wonder if the partition tools can do EVMS, or if a plugin should be made for that? Anyone else want to use EVMS at some point? I object. EVMS is nice and it is the future. But currently, I miss some features and the guys are preparing a new version with major changes. Lvm10 is known to be stable enough, EVMS is not (yet). What is the basis for your objection? Are you going to try to stop someone else from doing this development? -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Partition tools (Re: debian-installer status -- 2002-07-29)
#include hallo.h Matt Zimmerman wrote on Mon Jul 29, 2002 um 09:00:42AM: I object. EVMS is nice and it is the future. But currently, I miss some features and the guys are preparing a new version with major changes. Lvm10 is known to be stable enough, EVMS is not (yet). What is the basis for your objection? Are you going to try to stop someone else from doing this development? Pretty simple. The same reason as for not having XFS in the default kernel: - development stage - not in the kernel - changes lots of stuff in the kernel - not stable or has other nasty bugs - future stable version breaks things I know that you like EVMS, and I do too, but it's still beta-ware. You may argue that it will be stable to the time when Sarge is ready - but we do also release with 2.2.x as default 1.5years after 2.4 release. Gruss/Regards, Eduard. -- Every nonzero finite dimensional inner product space has an orthonormal basis. ... It makes sense, when you don't think about it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Partition tools (Re: debian-installer status -- 2002-07-29)
On Tue, Jul 30, 2002 at 12:09:08AM +0200, Eduard Bloch wrote: #include hallo.h Matt Zimmerman wrote on Mon Jul 29, 2002 um 09:00:42AM: What is the basis for your objection? Are you going to try to stop someone else from doing this development? Pretty simple. The same reason as for not having XFS in the default kernel: - development stage - not in the kernel - changes lots of stuff in the kernel - not stable or has other nasty bugs - future stable version breaks things I know that you like EVMS, and I do too, but it's still beta-ware. You may argue that it will be stable to the time when Sarge is ready - but we do also release with 2.2.x as default 1.5years after 2.4 release. I am in complete agreement that we would not want to include EVMS, XFS or similar in our default kernel unless (or until) they are part of the official kernel. However, I am willing to do some work to support EVMS in d-i, and to provide EVMS-enabled installation media for those who are interested in trying it. If I can use this experience to improve volume management support in d-i, then I would hope that my contributions would be welcome. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Partition tools (Re: debian-installer status -- 2002-07-29)
[Ob-CC: Cc'd just FYI. d-i refers to the next generation Debian Installer, which you may view at http://cvs.debian.org/ and discuss in [EMAIL PROTECTED]; also archived there - http.] Matt Zimmerman [EMAIL PROTECTED] writes: I am in complete agreement that we would not want to include EVMS, XFS or similar in our default kernel unless (or until) they are part of the official kernel. However, I am willing to do some work to support EVMS in d-i, and to provide EVMS-enabled installation media for those who are interested in trying it. If I can use this experience to improve volume management support in d-i, then I would hope that my contributions would be welcome. I am also interested in an EVMS + XFS (and SMP enabled; give them a choice of kernel images!) enabled install, as well as a totally automatic (perhaps scripted) one. The automatic install should support EVMS too, ideally. Someday it WILL undoubtedly be production quality, and WE'll be the first to have a turnkey installer for a system that utilizes it, if we do this. As I recall, d-i sports a very modular design that should make it possible to give the user a choice of which partitioning tool to pull in off the CD media. They can then choose standard or EVMS, cfdisk, disk druid, or depart (good a name as any?). Yes, at this point in time, EVMS + XFS should certainly be considered experimental. (My present system deadlocks when I compile software; bugs reported to XFS and EVMS lists; I hope they can fix it soon.) It might improve the bugfix and development rate some if more people got exposed to these new features, which may certainly occur if there's an easy way for them to install it and try it on a test box. (You must admit that installing by hand is for experts only.) I wonder if there's any kind of consolidation and reconciliation possible between the EVMS C API and libparted? Both are capable of creating disk partitions... (Sight unseen I cannot say myself; it just occured to me and thus I wonder.) -- As any limb well and duly exercised, grows stronger, the nerves of the body are corroborated thereby. --I. Watts. .''`. We are deB.ORG; You will be freed. : :' : URL:http://www.debian.org/social_contract `. `' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
