Thomas Schmitt wrote:
> Hi,
>
>   
>> Now it's enough to replace grub-mkisofs with xorrisofs.
>>     
>
> What about operating systems other than GNU/Linux
> and FreeBSD ?
>
>   
I've tested under cygwin. Following problems:
1) It tries to build even if no iconv is present
2) I needed to explicitly add LIBS=-liconv to configure depstite
configure properly detecting the need of -liconv. In some commands
actually -liconv was double: one from configure and another from LIBS
but somewhere it's not propagated properly
3) A ton of warnings. Build log attached. At least some warnings seem to
come from cygwin internal problems (e.g. isspace causes "array subscript
is a char") but some may be legitimate
4) GRUB itself had few issues on cygwin. So I've used *.mod and *.img
form GNU/Linux. I'll look into this issue
> I have running a version of grub-mkrescue which
> can deal with grub-mkisofs, genisoimage, and
> xorriso. (genisoimage without
> --protective-msdos-label and --modification-date)
>
> Maybe it would offer a softer migration path
> than flatly urging people to port xorrisofs to
> their favorite exotic OS.
> Of course i would gladly support any porting
> effort, which should be easy as long as one does
> not want to use it for burning optical media.
>
>
>   
>> Do you know when debian will follow? When
>> this version is in Debian sid I plan to remove grub-mkisofs
>>     
>
> I informed George Danchev about our progress
> today. Like so many people he is very occupied
> currently.
> In charge are the Debian Libburnia packagers.
> See
>   http://packages.qa.debian.org/libi/libisofs.html
>
> Since Debian covers our dynamic compilations
> i will first have to release a new
> libisofs-0.6.30 and a new libisoburn-0.5.4.
> That should be possible in the next days.
> I just have to do some more tests.
>
> Maybe one could try to find testers for
> GNU xorriso-0.5.3 on some of the other OSes in
> the meantime ?
>  
> ------------------------------------------------
>
>   
>> Unfortunately floppies are of interest. Moreover our modules put
>> together result in 1146880 bytes tar file.
>>     
>
> Then you should in any case let xorrisofs
> write into a sequential pipe
>   | cat > ${output_image}
> rather than into a random access file
>   -o ${output_image}
>   (or  > ${output_image} without cat)
> in order to save the overhead of 64 to 126 kB.
>
>
> Would read support for zisofs be in your reach ?
> It is implemented in the Linux kernel iso9660
> code since a while. See CONFIG_ZISOFS in
>   fs/isofs/*.[ch]
>
> If zlib is provided, then xorriso can produce
> zisofs on-the-fly on normal input file trees.
> No need to run the mkzftree utility.
> (But it can recognize and use the mkzftree
>  prepared files too.)
>
> The mkisofs emulation cannot do the on-the-fly
> stunt, yet. So this has to look a bit ugly:
>
>   "${mkisofs_prog}" ...
>                     ${source} \
>                     -- -set_filter_r --zisofs / -- \
>                     | cat > ${output_image}
>
> But the result has only 884736 bytes.
>
> We would have to keep some modules uncompressed
> i assume.
>
> It can also produce gzipped files on the fly:
>
>    ${mkisofs_prog}" ...
>                     ${source} \
>                     -- -set_filter_r --gzip / -- \
>                     | cat > ${output_image}
>
> Result again has 884736 bytes. Files have suffix
> .gz now. Small files may stay uncompressed:
>
>   $ ls -l /mnt/boot/grub/i386-pc
>   ...
>   -r--r--r-- 1 root root  2675 2010-04-10 00:17 afs.mod.gz
>   -r--r--r-- 1 root root  1052 2010-04-10 00:17 aout.mod
>   ...
>
>
> One could of course apply mkzftree or gzip to
> the temporary tree during the grub-mkrescue run.
>
>
> Have a nice day :)
>
> Thomas
>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko