Re: Lenny general freeze ahead
Hello,
I've actually made a small patch to handle file exclusions when
building root file system with mksquashfs. It's in live-helper package,
not live-initramfs as said before, in script live_binary_rootfs.
It uses a new variable, MKSQUASHFS_EXCLUDES, to handle file names to
be excluded from squashfs image, to prevent '-e files' option to mess
with other mksquashfs options.
Can you include it in a next release of live-helper ?
Thanks,
Fred Boiteux.
diff -Naur live-helper-1.0~a46/helpers/lh_binary_rootfs live-helper-1.0~a46mod/helpers/lh_binary_rootfs
--- live-helper-1.0~a46/helpers/lh_binary_rootfs 2008-04-27 01:21:54.0 +0200
+++ live-helper-1.0~a46mod/helpers/lh_binary_rootfs 2008-06-09 14:56:59.0 +0200
@@ -225,7 +225,7 @@
if [ ${LH_PACKAGES_LISTS} = stripped ] || [ ${LH_PACKAGES_LISTS} = minimal ]
then
- MKSQUASHFS_OPTIONS=${MKSQUASHFS_OPTIONS} -e $(ls chroot/boot/${LINUX}* chroot/boot/initrd.img* chroot/${LINUX}* chroot/initrd.img* | sed 's|chroot/||g')
+ MKSQUASHFS_EXCLUDES=${MKSQUASHFS_EXCLUDES} $(ls chroot/boot/${LINUX}* chroot/boot/initrd.img* chroot/${LINUX}* chroot/initrd.img* | sed 's|chroot/||g')
fi
if [ -f config/binary_rootfs/squashfs.sort ]
@@ -234,6 +234,10 @@
cp config/binary_rootfs/squashfs.sort chroot #FIXME
fi
+ if [ -n ${MKSQUASHFS_EXCLUDES} ]; then
+ MKSQUASHFS_OPTIONS=${MKSQUASHFS_OPTIONS} -e ${MKSQUASHFS_EXCLUDES}
+ fi
+
case ${LH_CHROOT_BUILD} in
enabled)
# Create image
___
debian-live-devel mailing list
debian-live-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Re: Lenny general freeze ahead
On 06/06/2008, Jordi Pujol [EMAIL PROTECTED] wrote:
Hello,
looking at the changes in live-initramfs v1.132.1
there is the following change:
@@ -979,7 +965,7 @@
rofslist=${image} ${rofslist}
elif [ -f ${image} ]
then
- backdev=$(get_backing_device ${image})
+ backdev=$(get_backing_device ${image} -r)
fstype=$(get_fstype ${backdev})
if [ ${fstype} = unknown ]
then
panic Unknown file system type on ${backdev}
(${image})
fi
mkdir -p ${croot}/${imagename}
echo debug: Mounting backdev \${backdev}\ (image =
${image}) on
croot/imagename \${croot}/${imagename}\
mount -t ${fstype} -o ro,noatime ${backdev}
${croot}/${imagename} ||
panic Can not mount ${backdev} (${image}) on ${croot}/${imagename}
rofsstring=${croot}/${imagename}=${roopt}:${rofsstring}
rofslist=${croot}/${imagename} ${rofslist}
fi
considering that the mount command also is done with the readonly option,
What
is the finality of invoking losetup with the option -r ?
It's pretty much irrelevant but it is still cleaner to set up the
device readonly.
Also consider that if the invoked losetup command is the Busybox internal
command, the booting process will fail with an error for unknown option,
The whole reason for this change was to make the script work wit
losetup that ships with the loop-aes. It is recommended so it is
installed and stuff breaks because of it.
It is fine with me if the change is reverted and live-initramfs
conflicts with loop-aes-utils.
Still the inability to set up readonly devices is a deficiency of
BusyBox. Similarily it fails to understand -f and -n mount options
which would break stuff if busybox mount was used.
Thanks
Michal
___
debian-live-devel mailing list
debian-live-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Re: Lenny general freeze ahead
El Friday 06 June 2008 16:58:36 Michael Creel va escriure: These two seem very useful to me: On Fri, Jun 6, 2008 at 4:03 PM, Jordi Pujol [EMAIL PROTECTED] wrote: snip use the /etc/fstab file to mount the persistent /home directory and gain automatic fsck of the partition. good, that trick can be implemented with some lines of code, snip choose user uid, groups, name, that is easy also, requires adding new options for uuid, groups, and modifying some lines of 10adduser and also multiple users, with their corresponding uids, groups, etc... that is more complex, requires some variables with large values, it's better to write that variables in /etc/live.conf Best, Michael ___ debian-live-devel mailing list debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Re: Lenny general freeze ahead
El Wednesday 04 June 2008 22:48:38 vàreu escriure: This sounds nice. However, what happens if there is a non-busybox losetup installed? now the option is present in the two losetup commands, Previously the option -f was only available in the standard command losetup, Assuming that this standard could be not allways installed, to simulate this functionality in the previous Busybox version was used the trick of investigate the /sys filesystem. Since live-initramfs now recommends loop-aes-utils (or whateve the exact name), and they install their own losetup I had to fix up setup_loop to work for cases when the image is readonly. In my opinion, I consider that loop-aes is an obsolete package and is superseded by the cryptoloop module and the crypto functions, included in the standard kernel. Now the kernel works with encrypted devices using the standard command losetup included in the mount package, and there is no need for loop-aes. Observe that the option -r is not present in the Busybox command losetup, Even we can affirm that it does not matter, due that aufs joins that loop devices with the options real-read-only or read-only. Regards, Jordi Pujol ___ debian-live-devel mailing list debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Re: Lenny general freeze ahead
El Thursday 05 June 2008 11:34:39 vàreu escriure: I did not choose to install loop-aes. It only broke my setup. Observe that the option -r is not present in the Busybox command losetup, Even we can affirm that it does not matter, due that aufs joins that loop devices with the options real-read-only or read-only. That's bad because loop-aes can be installed even if it is not necessary, and this gives two losetup versions so incompatible that there cannot be a reasonably complex script that would work with both. Yes, I think so also, I believe that the cryptoloop module in the kernel can do the same or better than loop-aes, then I never install loop-aes, even more, loop-aes should be prohibited loop-aes package includes a replacement for the loop kernel module and another losetup command, that breaks the correct working of some utilities, expecting to found functions included into the loop module, and are not present or do not work in the loop module of loop-aes, in example the uloop module included in the aufs-source package. Regards, Jordi Pujol ___ debian-live-devel mailing list debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Re: Lenny general freeze ahead
Hello,
About live-initramfs, I'm ahead of a small problem with mksquashfs,
I'd like to know if it's a known problem :
To do a live system with a small size, I choose to remove from squashfs
all files from /usr/share/doc, /usr/share/man and /usr/share/locale. I
tried before to remove them directly in the chroot, but then I have
errors with apt/aptitude trying to remove some packages. So, I added in
my live building script :
export MKSQUASHFS_OPTIONS=$MKSQUASHFS_OPTIONS -info -e usr/share/doc
usr/share/man usr/share/locale
It works, but looking at lh_binary_rootfs where the variable
MKSQUASHFS_OPTIONS is used, I've seen statements like :
...
MKSQUASHFS_OPTIONS=${MKSQUASHFS_OPTIONS} -no-progress
As my definition is read before this one, the result will be a command
like :
mksquashfs ... -e path1 path2 ... pathn -no-progress
and the option '-no progress' is considered by mksquashfs as an
excluded path and not an option (it's why I added '-info' in my script).
This problem could be solved by either :
- modify lh_binary_rootfs to add options on the front of
MKSQUASHFS_OPTIONS, but IMHO it's a weak solution
- modify lh_binary_rootfs to add a MKSQUASHFS_EXCLUDES variable which
will be added at the end of mksquashfs command ; this variable should
contain only path to be excluded, lh_binary_rootfs should add '-e'
option in front of it. This is my best choice
If you think it's useful, I could do a small patch for
lh_binary_rootfs, but perhaps there is another solution ?
Fred.
___
debian-live-devel mailing list
debian-live-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Re: Lenny general freeze ahead
Marco Amadori wrote: A part the IRC list were longer and I asked you what you needed and implemented mosts of your taste requirements, I think I actually FIXED[0] coding style: no. live-snapshot is part of userland, not initramfs. therefore live-helper code style applies. that's what i said already. err? you were basically absent in the last 15 month. Yes, I know, and all knows that I was absent because of work and new family, I do not have the spare time I was used to have, but I think I always declared that loudly, so it should be not a surprise. you never needed and still don't need to justify for being busy with other stuff, this is a volunteer committment after all. what i'm saying is that just because it was different in the past doesn't mean it is still the same. You could notice I was also unhappy about you forking casper, mainly because I was collaborating succesfully with some ubuntu upstream guys which were little disappointed by the move, but the real motivation of my absence was just family (and work) related, not technical nor personal by my side. the fork was needed - nobody was working on casper in debian anymore, and ubuntu did not merge from debian. do we need to reiterate that now? Ok to use right a tool, but here it seems just that the effort gives back so little. Topic commits are fine, splitting some small cleanings in 4 commits instead of doing just one cleaned a bit live-snapshot seems overwork and overzealous, moreover because they were 4 commits artificially split, not different works in different times, it seems an abuse of a VCS to me here. this /is/ the right tool used the right way. if you're saying that your big commit is right, then you're absolutely wrong. that commit is not understandable itself (amongst others, also for the reasons pointed out several times already) by me. it is needed that i understand the commit since there is no other active DD maintainer arround for live-initramfs yet, means, in case you disappear again, i'm supposed to fix any upcoming bugs with that part. apart from that, the 4 commits you are refering to are from *me*, not taken out of your big fat one, otherwise i would have used --author. It requires more time to chat than to code. If cleaning like you want requires you 5 min, and chatting to know exaclty how do you want things requires 2 hour (latest irc session had this ratio) please use that 5 min to merge and clean the personal taste uglyness yourself, we will learn by example in less time, I'll assure that! given someone contributes more than once, it requires more time to fix code again and again rather than making the contributor delivering merge ready code in the first hand. apart from the fact that the job of correcting such things is tedious, also the poisoning of git diffs sucks too. It's a methodology objection mine, not a technical. And the fixes I did WERE non technical, if you like I can discuss why the change you required from an if return to if else statement, although you liked more, was better as it was. (since if was an error condition trapping which is better served in term of understanding at it was before because it's shorter, faster and easier to read. [1] vi /usr/share/doc/linux-doc-2.6.25/Documentation/CodingStyle.gz +237 should be mentioned too although is C related, Chapter 4: Naming. that just shows that you don't listen. i already explained that at least twice, that shell functions are different by the very nature of how shell functions are beeing interpreted: To avoid naming scheme conflicts with external commands and thus beeing able to use shorter names, functions are beeing written with a capital letter in live-helper. comparisons to C simply do not apply, be it kernel.org or not. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ ___ debian-live-devel mailing list debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Re: Lenny general freeze ahead
Marco Amadori [EMAIL PROTECTED] writes: ... No critics, but please discuss without prejudice. i don't have prejudices, really. So please, this is not a battle for this particular commit, just that I'm scared about the your concepts of cleanness, separation and uglyness [0] and beauty [0] required for future work. I just would like you to relax a bit your standard and try to be a bit less dispotic. Not always one can rebase and split things asking you how do you want things. I'm sorry but I can't agree with you. If we don't force a style it can be easier for you to work on that _today_ but it will be worse later. We can't accept exceptions and this works fine in many projects much bigger then Debian Live, this will and does work fine for a small project like Debian Live. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ debian-live-devel mailing list debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Re: Lenny general freeze ahead
Marco Amadori [EMAIL PROTECTED] writes: On Wednesday 04 June 2008, 15:11:42, Otavio Salvador wrote: So please, this is not a battle for this particular commit, just that I'm scared about the your concepts of cleanness, separation and uglyness [0] and beauty [0] required for future work. I'm sorry but I can't agree with you. If we don't force a style it can be easier for you to work on that _today_ but it will be worse later. I agree with you, I want rules too. I just wanted to discuss this particular set of rules which I find time-consuming and not well suited for the purpose (which seems to be not trashing git history among others). Like using a nuclear bomb to kill mosquitos. Every time you need to follow a rule you're not used, it consumes time. We can't accept exceptions and this works fine in many projects much bigger then Debian Live, this will and does work fine for a small project like Debian Live. I agree too, and I really think I was misunderstood by both you and Daniel, which is obviously my fault. No problem. Anyway, as I stated, I will adhere to the unwitten rules as they manifests, even if I seem to not agree with them and even if you do not like to discuss them. So expect 2 commits with no codying style change from me. I agree that we need to write down a document that describes the coding style. This will help to avoid this mess in the future. I'm not saying we can't discuss it but I do advice you that, if you want to have your patches in before the freeze you shouldn't wait for we finish it. As engineering teachs, there is a tradeoff between innovation and conservation, I just say that the rationale of your tradeoffs does not convice me, but I also think that this discussion took too much time for me (and maybe also for you) and I do not see ways to let my ideas penetrate without spending more time. So another tradeoff there. hehe At least for my side, you'd need _very_ good arguments to convince me. This kind of rules are used by many projects, like: - Linux Kernel - GNU GRUB - GNU Parted - Debian Installer - DPKG - ... Obviously, them has different coding style rules but the ruleset is basic the same. As I already said previously, this works for them ... no reason to fail for us. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ debian-live-devel mailing list debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Re: Lenny general freeze ahead
On 03/06/2008, Jordi Pujol [EMAIL PROTECTED] wrote: El Tuesday 03 June 2008 18:13:18 Daniel Baumann va escriure: Extra prod to Jordy :) As you pointed out several times, you're using several patches for live-initramfs. Please do send them in. Hello all, Thanks Daniel, Now already there are large differences between the estandard and my own version of live-initramfs. Also it requires a personalized initramfs-tools package. These differences dificult the task of creating patches. I will try to send simplest patches so that can be applied with easy to the current version of live-initramfs, Attached is the first one, The function setup_loop() is simplified for speed and more clear code; observing than losetup from Busybox v1.9 has the option -f to print the name of the next loop device available, This sounds nice. However, what happens if there is a non-busybox losetup installed? Since live-initramfs now recommends loop-aes-utils (or whateve the exact name), and they install their own losetup I had to fix up setup_loop to work for cases when the image is readonly. Thanks Michal ___ debian-live-devel mailing list debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Re: Lenny general freeze ahead
El Tuesday 03 June 2008 18:13:18 Daniel Baumann va escriure: Extra prod to Jordy :) As you pointed out several times, you're using several patches for live-initramfs. Please do send them in. Hello all, Thanks Daniel, Now already there are large differences between the estandard and my own version of live-initramfs. Also it requires a personalized initramfs-tools package. These differences dificult the task of creating patches. I will try to send simplest patches so that can be applied with easy to the current version of live-initramfs, Attached is the first one, The function setup_loop() is simplified for speed and more clear code; observing than losetup from Busybox v1.9 has the option -f to print the name of the next loop device available, Regards, Jordi Pujol losetup.patch.tar.bz2 Description: application/tbz ___ debian-live-devel mailing list debian-live-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
Re: Lenny general freeze ahead
On Tuesday 03 June 2008 23:01:59 Daniel Baumann wrote: - don't change unrelated things - don't change coding style A part the IRC list were longer and I asked you what you needed and implemented mosts of your taste requirements, I think I actually FIXED[0] coding style: $ grep -e '[::alpha::]* ()' scripts/live Arguments () is_live_path () matches_uuid () get_backing_device () match_files_in_dir () mount_images_in_directory () is_nice_device () copy_live_to () do_netmount () do_httpmount () do_nfsmount () do_cifsmount () do_snap_copy () try_snap () setup_unionfs () check_dev () find_livefs () set_usplash_timeout () mountroot () $ grep -e '[::alpha::]* ()' bin/live-snapshot.old Error () panic () Header () Help () Usage () Version () Is_same_mount () Parse_args () Defaults () Validate_input () Mount_device () Do_snapshot () Clean () Main () -- mine: $ grep -e '[::alpha::]* ()' bin/live-snapshot.new handle_error () panic () header () help () usage () version () try_refresh () parse_args () defaults () validate_input () mount_device () do_filelist () do_snapshot () clean () main () So , IMHO things are not consistent as it was, I just, while adding a feature, fixed that (uglyness)[0] non uniformity. [1] Anyway, think again please and ask again if is it the case to not fix the coding style... anyway I do not want to fork the code just to let it adhere to my coding style... it could be just difficult to collaborate then, but such things does not happen in the real world. ;-) since I'm used to XP which leaves you the good (IMHO) and bad (ITIYHO) habit to always refactor and reformat the code one is working whit. as said on irc already, there is no point in merging stuff that makes existing code uglier wrt/ coding style when it can be that easy to correct it. A part from [0], I'll see if is needed.. and if you do not want to change your mind this time too, I hope to find some time to do what you will ask, even if I find it useless and not well motivated. if it's possible to merge them from a git branch. This was done too. [0] I could rebase it if needed. please do so, and please correct the other things i pointed out on irc to be changed. if you don't remember them or don't have a log, i can send one. Done just the rebase for now. A good thing to rush to, should be the debian-installer integration and testing (maybe I'll do in the work hours like latest 2 features If I could convince again my boss we need this feature and push the priority up) . d-i integration isn't the problem from live-helper point of view, the main two problems are (to be done) initrd loop-mounting in order to do klick-on-desktop installs and (existing) problems with live-installer. I'm talking about having a working product for lenny, so both your use cases matters although I see click-on-desktop at a lower priority. I'm afraid I could not help more, but I need to program how to spend time precisely, and my priority are on creativity (scratch the hitch) and bug fixes. I really would enjoy more freedom in merging other code, strict rules need time and effort to adhere, and there are diminishing return in really using a cvs so precisely like you seems to enjoy (look latest 3 commits, spaces, copyright and a version number... ) err? you were basically absent in the last 15 month. Yes, I know, and all knows that I was absent because of work and new family, I do not have the spare time I was used to have, but I think I always declared that loudly, so it should be not a surprise. You could notice I was also unhappy about you forking casper, mainly because I was collaborating succesfully with some ubuntu upstream guys which were little disappointed by the move, but the real motivation of my absence was just family (and work) related, not technical nor personal by my side. things have changed from a svn where you could commit and i cleaned up afterwards to a 'always clean state' git repository done right. please accept that. Hey, hey, It was not me that did a lot of commits without commit messages at the times... :-) Ok to use right a tool, but here it seems just that the effort gives back so little. Topic commits are fine, splitting some small cleanings in 4 commits instead of doing just one cleaned a bit live-snapshot seems overwork and overzealous, moreover because they were 4 commits artificially split, not different works in different times, it seems an abuse of a VCS to me here. No critics, but please discuss without prejudice. i don't have prejudices, really. So please, this is not a battle for this particular commit, just that I'm scared about the your concepts of cleanness, separation and uglyness [0] and beauty [0] required for future work. I just would like you to relax a bit your standard and try to be a bit less dispotic. Not always one can rebase and split things asking you how do you want things.
