Re: Creating unofficial CDs
On Sat, 26 Jan 2002, Nicolas Marchildon wrote: > Karl-Martin Skontorp écrivait/wrote: > > I was not able to build the woody images completely because I was > > missing some old files in my mirror, i.e. a new version had replaced the > > ones used in the image. I was able to get some of them directly from > > an official mirror, but not all of them. Had to do an rsync on the image > > for the last pieces, but that was pretty quick. > > I've been told to revert to rsync in many documents, but haven't found any > precise explanations on how this can be done. Could you write how you did it? Reverting back to rsync when you have an almost finished image (lets call it binary-i386-1.iso) you find a mirror with rsync acccess (lets call that one ftp.se.debian.org). Then you use rsync to make the amlost finished image an exact copy of the one on the server, which due to the rsync protocol doesn't involve huge downloads. Something like: rsync ftp.se.debian.org::debian-iso/2.2_rev4/i386/binary-i386-1.iso binary-i386-1.iso > By the way, does anyone know where I can find information on how to make > netinst images? Sorry, I have no idea bout that. Hopefully someone else does. /Mattias Wadenstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new cd cover
On 2002-01-26T 0:52:04 +, Richard Atterer wrote: > > http://www.liquid2k.com/flawd/debian_cd.html > OK, added to the website. BTW, just wanted to tell you that the first artworks (http://buus.net/mads/cdart/) on the page (they looked so cool) don't work. Actually, http://buus.net/mads/ 404s. -to'Anyone have them? Upload them somewhere, they rock'wo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Creating unofficial CDs
* Mattias Wadenstein ([EMAIL PROTECTED]) wrote: > Reverting back to rsync when you have an almost finished image (lets call > it binary-i386-1.iso) you find a mirror with rsync acccess (lets call that > one ftp.se.debian.org). Then you use rsync to make the amlost finished > image an exact copy of the one on the server, which due to the rsync > protocol doesn't involve huge downloads. > > Something like: > rsync ftp.se.debian.org::debian-iso/2.2_rev4/i386/binary-i386-1.iso binary-i386-1.iso Don't know if it matters too much in this case, but I always use "-avvP" on rsync. a for archive, recursive, preserves timestamps etc. Two v's for extra verbosity and the P will show progress as well as preserve partially downloaded files. -- Karl-Martin Skontorp http://skontorp.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Creating unofficial CDs
On Sat, 26 Jan 2002, Karl-Martin Skontorp wrote: > * Mattias Wadenstein ([EMAIL PROTECTED]) wrote: > > Reverting back to rsync when you have an almost finished image (lets call > > it binary-i386-1.iso) you find a mirror with rsync acccess (lets call that > > one ftp.se.debian.org). Then you use rsync to make the amlost finished > > image an exact copy of the one on the server, which due to the rsync > > protocol doesn't involve huge downloads. > > > > Something like: > > rsync ftp.se.debian.org::debian-iso/2.2_rev4/i386/binary-i386-1.iso >binary-i386-1.iso > > Don't know if it matters too much in this case, but I always use "-avvP" on > rsync. a for archive, recursive, preserves timestamps etc. Two v's for > extra verbosity and the P will show progress as well as preserve > partially downloaded files. Well, in this case it is just one file, så the recursive and permissions preserving is pretty much ignorable. Progress is probably something good to show, but preserving partially downloaded files is probably not what you want to do. If you manage to download the first 100 megs, my experience is that rsync will overwrite the pseduo-image with the 100-meg file. But keeping the original file would probably have been much better, since the download to complete that image would be much less than the 500 megs to complete the 100-meg file. Perhaps I should have added --progress and --stats, but they aren't really essential. Same thing with specifying a specific block size. /Mattias Wadenstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: jigdo-port/lite/lite2win (Re: web pages)
On Sun, 20 Jan 2002, Richard Atterer wrote: [Sorry for the late reply. My mail-R/W intervals are short and sparsely distributed in time. This message was written during several of these intervals the past few days. I just read that jigdo 0.6.2 is available, but I haven't had time to check that out yet (and probably will not before the end of next week), so everything here concerns 0.6.1.] > On Fri, Jan 18, 2002 at 01:59:11PM +0100, J.A. Bezemer wrote: > > As far as I'm concerned, jigdo has just left beta stage. (That's the > > jigdo scheme, not necessarily jigdo 0.6.1 ;-) > > Hm, for *me* jigdo will be finished the moment my mother can download > a CD image without me giving her any instructions! ;-] I'll keep that in mind ;-) > BTW, Anne (or anybody else who is interested), should you have more > spare time in the future, here are some fun projects: > > - Hack debian-cd to allow output of .jigdo/.template files without >saving a temporary image to disc. A must for DVD jigdo generation. Done, will commit shortly. > - Add DVD support to debian-cd (trivial AFAIK?) If you want an iso9660 on the DVD, then trivial (SIZELIMIT to 4GB or so) (eh, if this is used in shell calculations it might not work, use bc instead). BUT at least Macs will only recognize a UDF filesystem on DVD; you have to do something special to make it recognize iso9660. AFAIK we have UDF R/W support in recent kernels but that needs a full partition/disk/loopfile, nothing like mkisofs. > - Hack mkhybrid to output .jigdo/.template instead of raw ISO9660 >data. This would make the template generation a lot faster - >imagine daily "testing" DVD images! I don't think that'll work well. The stuff on CD has (or can have) quite different paths than on the mirrors, so forget the .jigdo. We _can_ do the .template (i.e. only the md5sums) but then there is the problem that mkisofs doesn't know which files were generated (README, Packages) and which weren't. (hardlink count or symlink-outside-tree might do the trick, but that isn't really reliable). The current piping works very well and circumvents all these problems. On the other hand, you might use isoinfo or some specially patched mkisofs to provide hints to jigdo-file so that, for specified offsets, it tries one specific file first before trying everything else. To use this with jigdo on the fly, it'd be optimal if jigdo-file could actually parse the iso's directory structure... > - A CGI script (or mini web server, or Apache module...:) which >assembles the CD image on the fly from .jigdo, .template and a >local mirror. Essentially, this allows mirror admins to offer >direct HTTP downloads without the need to store the complete images >locally. (HTTP/1.1 ranges support would be cool.) Have jigdo-file support --start=byte --end=byte and it can probably be done in a small perl script (but my perl is read-only ;-) > [snip] > > It didn't compile on my potato box, 'cause it requires libdb3 and > > sstream.h. libdb3 was out-configurable, but replacing sstream by > > strstream did compile but produced weird output in the list files. > > /me awards himself the Portable Programming of the Month award. :-/ > > OH NO! It is definitely my intention to make jigdo-file compilable on > potato! After I noticed that sstream worked with GCC 2.95 under > testing, I started to use it. I didn't know that the GCC 2.95 in > potato does not cope with it. > > I'll try to remove the dependency on sstream soon. As for the other > C++ features that many C++ compilers out there probably don't support > yet: The C++ ISO standard has been out for three years, I can't be > bothered to enter "write once, test everywhere" mode. GCC 2.95 or 3 is > available for all the important arches... Just to compare: (unextended) pascal was standardized before 1990, but you won't find many (if any) machines with any pascal support installed. Even though there's an excellent gpc. Availability isn't an issue, the willingness of the sysadmin to install it is. > [snip] > > Now for the future. I don't plan to do anything to > > jigdo-port/lite/lite2win any more (unless I've made some stupid > > mistake somewhere) except fanatically using it. It's my idea that > > -port and -lite get merged into the "official" jigdo distribution. > > Please NOT hidden in some contrib/ dir, _many_ people need it. Maybe > > also -lite could better be placed in it's own top-level dir, along > > with its README and myprintf.c, and not in scripts/ along with all > > those things that "end users" aren't interested in. > > That's fine with me, as soon as the remaining issues (see below) are > resolved! But hopefully you won't just "dump" this on me and then > disappear? :) Your shell scripting expertise and test machines will be > needed for future modifications to the script! > > But I'd rather not include the zlib source in the jigdo source > distribution - doing that increases its size quite a bit, also it's > ea
Re: Creating CD covers [was: http://members.iinet.net.au/~silva/debian_cd_covers/]
On Thu, 10 Jan 2002, Richard Atterer wrote: > BTW, I haven't found *any* program to create CD covers that has the > following features: > > - vector-oriented, so the text need not be converted to a bitmap and > looks sharp with offset printing > - ability to import EPS & graphics, ability to export EPS/PS/PDF. > (Export of PDF with embedded JPEGs would be even cooler, otherwise > any graphics make the file so large.) > > Candidates are xfig, sketch, dia and sodipodi. None of these can > import openlogo.eps. xfig's Picture Object works perfectly with .eps files. It only has a problem when there's no "showpage" in the .eps; add it yourself if necessary. openlogo is fine. Simple example below, put it in the same dir as openlogo. Regards, Anne Bezemer #FIG 3.2 Landscape Center Metric A4 100.00 Single -2 1200 2 2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 6 1935 1260 5445 1890 5535 4680 2250 6795 855 3870 2520 720 2 5 0 1 0 -1 50 0 -1 0.000 0 0 -1 0 0 5 0 openlogo.eps 2340 2565 4086 2565 4086 4867 2340 4867 2340 2565 2 2 0 1 0 8 54 0 20 0.000 0 0 -1 0 0 5 1935 3060 4455 3060 4455 4230 1935 4230 1935 3060 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: jigdo 0.6.2
On Sat, Jan 26, 2002 at 12:15:09AM -0500, Nicolas Marchildon wrote: > In case you ask, jigdo does not install on Progeny Debian (~potato): Yes, the binary packages only really work for woody and sid. :-/ The "jigdo-bin" tar.gz now contains a statically linked jigdo-file, so that should work everywhere. (I know it's ugly.) On Sat, Jan 26, 2002 at 12:46:56AM -0500, Nicolas Marchildon wrote: > Does that libwww stuff is really required to make jigdo work? I > suppose the 0.6.2 version I'm trying to build needs libwww for the > GTK GUI. Correct, jigdo-file compiles without GTK+ or libwww. > Is there a way to disable the compilation of the GUI, so > that we don't need libwww? No, but I'll add a configure switch for the next release. :) Thanks for trying to compile it! Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Creating CD covers [was: http://members.iinet.net.au/~silva/debian_cd_covers/]
On Sat, Jan 26, 2002 at 07:50:57PM +0100, J.A. Bezemer wrote: > xfig's Picture Object works perfectly with .eps files. [...] Ah, nice - thanks! At first sight it looks as if the EPS were converted to a bitmap, but it turns out the original EPS is used when you re-export to EPS. Great! Cheers, Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
