Re: Dealing better with CD releases, done partially with 5.0.2a/5.0.3
On Wed, Apr 22, 2009 at 12:31:27AM +0100, Steve McIntyre wrote: On Thu, Apr 16, 2009 at 01:28:56PM +0200, Gerfried Fuchs wrote: * Steve McIntyre st...@einval.com [2009-04-15 15:36:57 CEST]: We currently potentially have a window of a few hours of breakage, as the web pages that point directly to the old images stay around for quite a while. Even if they are updated directly in $VCS as we do a release, the website is only rebuilt periodically from cron. It's not that big of a deal to trigger a manual rebuild of the webpages if one of the webmasters is contacted and around for the time, it doesn't need to wait for the periodically rebuild from cron. [..] OK. How long does it take for the web mirrors to update after a cron run? I'm thinking of *trying* to make all versions of the pages work for a while if we can... Yes, I know I'm being awkward. :-) Just as a reminder: for 5.0.2a and 5.0.3, we didn't wait for broken links reports to reach -www to update the links. Thanks Steve for notiying -www :) Steps before the release: - (not too early) because cdimage need to be ready before the next scheduled website build. (check with /msg dak webwml) a. Update webwml/english/template/debian/release_info.wml with current-cd-release, current-cd-release-dirname, and current-cd-release-filename On www-master as debwww: b. 'cvs -q up -d' in /srv/www.debian.org/webwml/english/template/debian/ c. Build the affected webpages: cd /srv/www.debian.org/webwml/ ; for i in */releases/ */CD/ */distrib/; do (cd $i; make; ); done = Matter of 10 minutes. As soon as the new release is available from cdimage.d.o: - d. Install the build webpages for i in */releases/ */CD/ */distrib/; do (cd $i; make install); done e. Trigger the mirroring: /org/www.debian.org/cron/parts/999TriggerMirrors = Few minutes, since only the html pages modified for the release will be synced.. About ongoing downloads: Concerning the transition of ongoing downloads, cdimage.d.o may enable HTTP redirects from /debian-cd/5.0.2 to /cdimage/archive/5.0.2a/. As a consequence, rsync mirrors would not be affected too much, and people browsing http://cdimage.debian.org/debian-cd/ will only see the new release. -- Simon Paillard -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
On Wed, Apr 15, 2009 at 10:53:35PM +0200, Thilo Six wrote: Thilo Six wrote the following on 15.04.2009 22:20 How about a directory with links to current isos dricetly then? current $ ls -l total 0 lrwxrwxrwx 1 USER USER 37 2009-04-15 22:18 current-stable-ARCH-1.iso - ../ARCH/ISO/debian-501-amd64-CD-1.iso lrwxrwxrwx 1 USER USER 37 2009-04-15 22:18 current-stable-ARCH-2.iso - ../ARCH/ISO/debian-501-amd64-CD-2.iso But that approach obviously puts some more work on you Steve as you would have to rebuild the files: MD5SUMS MD5SUMS.sign SHA1SUMS SHA1SUMS.sign with the appropriate file names i guess. Maybe in that same directory. Yeah, that's a problem. Not something I'd like to do if I can avoid it: I would much rather have the real image names be the ones used in the *SUMS files. -- Steve McIntyre, Cambridge, UK.st...@einval.com Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
On Thu, Apr 16, 2009 at 01:28:56PM +0200, Gerfried Fuchs wrote: Hi! Hey! * Steve McIntyre st...@einval.com [2009-04-15 15:36:57 CEST]: We currently potentially have a window of a few hours of breakage, as the web pages that point directly to the old images stay around for quite a while. Even if they are updated directly in $VCS as we do a release, the website is only rebuilt periodically from cron. It's not that big of a deal to trigger a manual rebuild of the webpages if one of the webmasters is contacted and around for the time, it doesn't need to wait for the periodically rebuild from cron. Involving a webmaster also solves the problems that we had at lenny release with respect to not-tested commits resulting in build problems and not only delaying the issue until the next periodically cron run but the one after the problem got noticed and fixed. OK. How long does it take for the web mirrors to update after a cron run? I'm thinking of *trying* to make all versions of the pages work for a while if we can... Yes, I know I'm being awkward. :-) 2. Possible solutions a. Stop linking directly to the images, and go through a set of symlinks instead. Potentially messy, and people may get mixed sets. Probably difficult to set up on mirrors too? Yeah, symlinking from hell might solve the issue of broken links but raise a lot of other issues indeed - I guess broken links are rather a much lower issue than those. Yup, exactly. b. Stop linking directly to the images, and go via redirects. Could maybe be a central cgi, maybe even with intelligence to redirect to good/close/fast/up-to-date mirrors. Could work, but needs implementing. :-) Sounds like a path that would work very well; but yes, requires work. Yup. c. Do things in stages: * Copy the old release to the archive area a few days before release. Add a warning to users that a new build is due, and they should be careful that their downloaded images are all from one version. * Once that archive copy is live, update the links to point to the archive copy and push the new website. * On the day of release, release as normal and update the web pages in $VCS to point to the new release in release. Remove the new build due warning and add new build just happened. After the website is built, new users will see the new images. * A few days/weeks later, prune the images in the old tree under archive. No current pages should be looking here, so we're just dealing with stragglers. Staging is usually a quite save approach but requires better coordination which seems to have been problematic the last releases from what I perceived. I though would be happy to be proven wrong. ;) This is what I'm going to try for the next few point releases, I think. How much effort would it be for the web team to make changes like this? -- Steve McIntyre, Cambridge, UK.st...@einval.com C++ ate my sanity -- Jon Rabone -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
On Tue, Apr 21, 2009 at 01:06:25AM +0200, Simon Paillard wrote: On Mon, Apr 20, 2009 at 10:49:49PM +0200, Frank Lin PIAT wrote: On Wed, 2009-04-15 at 14:36 +0100, Steve McIntyre wrote: At the moment we have problems when we do releases including new CD/DVD images, as you'll see from mailing list complaints about broken links each time. [..] 1. The Problem [..] The image filenames and the top-level directory are versioned for clarity, [..] We then prune most of the old ISO images so we don't waste too much space [..] We currently potentially have a window of a few hours of breakage, as the web pages that point directly to the old images I discovered mirrorbrain.org, an apache module to handle mirrors (with geoip...). It is capable of tracking the states of mirrors... You are probably aware of that tool, but here it is in case you don't. mirrorbrain was previously named openSuse redirector, already mentionned on debian-mirrors (list in Cc) Though I didn't give it a try : * most of the features needed are here * to be clear; would not be applicable to packages yet, because apt doesn't support HTTP redirect yet, see #212732 #79002 * it's PSQL (overkill ?) + apache module in C, * avoid single HTTP redirector - single point of failure http://mirrorbrain.org/implementation OK, looks like something useful for investigation then. Anybody volunteering the time to do it? I'm a little short on time at the moment, as you can probably tell from my delays in answering emails :-( -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane... -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
Hello, On Wed, 2009-04-15 at 14:36 +0100, Steve McIntyre wrote: At the moment we have problems when we do releases including new CD/DVD images, as you'll see from mailing list complaints about broken links each time. [..] 1. The Problem [..] The image filenames and the top-level directory are versioned for clarity, [..] We then prune most of the old ISO images so we don't waste too much space [..] We currently potentially have a window of a few hours of breakage, as the web pages that point directly to the old images I discovered mirrorbrain.org, an apache module to handle mirrors (with geoip...). It is capable of tracking the states of mirrors... You are probably aware of that tool, but here it is in case you don't. Regards, Franklin -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
On Mon, Apr 20, 2009 at 10:49:49PM +0200, Frank Lin PIAT wrote: On Wed, 2009-04-15 at 14:36 +0100, Steve McIntyre wrote: At the moment we have problems when we do releases including new CD/DVD images, as you'll see from mailing list complaints about broken links each time. [..] 1. The Problem [..] The image filenames and the top-level directory are versioned for clarity, [..] We then prune most of the old ISO images so we don't waste too much space [..] We currently potentially have a window of a few hours of breakage, as the web pages that point directly to the old images I discovered mirrorbrain.org, an apache module to handle mirrors (with geoip...). It is capable of tracking the states of mirrors... You are probably aware of that tool, but here it is in case you don't. mirrorbrain was previously named openSuse redirector, already mentionned on debian-mirrors (list in Cc) Though I didn't give it a try : * most of the features needed are here * to be clear; would not be applicable to packages yet, because apt doesn't support HTTP redirect yet, see #212732 #79002 * it's PSQL (overkill ?) + apache module in C, * avoid single HTTP redirector - single point of failure http://mirrorbrain.org/implementation -- Simon Paillard -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
On Wed, Apr 15, 2009 at 05:41:17PM -0700, Don Armstrong wrote: On Wed, 15 Apr 2009, Steve McIntyre wrote: b. Stop linking directly to the images, and go via redirects. Could maybe be a central cgi, maybe even with intelligence to redirect to good/close/fast/up-to-date mirrors. Could work, but needs implementing. :-) This sounds like a good idea, but there would still need to be logic to detect which mirrors had actually managed to get up to date... and that bit is probably a bit complicated. Yup, that's exactly what I mean. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com We don't need no education. We don't need no thought control. -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
Hi! * Steve McIntyre st...@einval.com [2009-04-15 15:36:57 CEST]: We then prune most of the old ISO images so we don't waste too much space - older images can be recreated in the future using jigdo if necessary. To the best of my knowledge that would depend on snapshot.debian.net being functional because once we release we also prune out the old packages that would be required to build the old images. We currently potentially have a window of a few hours of breakage, as the web pages that point directly to the old images stay around for quite a while. Even if they are updated directly in $VCS as we do a release, the website is only rebuilt periodically from cron. It's not that big of a deal to trigger a manual rebuild of the webpages if one of the webmasters is contacted and around for the time, it doesn't need to wait for the periodically rebuild from cron. Involving a webmaster also solves the problems that we had at lenny release with respect to not-tested commits resulting in build problems and not only delaying the issue until the next periodically cron run but the one after the problem got noticed and fixed. 2. Possible solutions a. Stop linking directly to the images, and go through a set of symlinks instead. Potentially messy, and people may get mixed sets. Probably difficult to set up on mirrors too? Yeah, symlinking from hell might solve the issue of broken links but raise a lot of other issues indeed - I guess broken links are rather a much lower issue than those. b. Stop linking directly to the images, and go via redirects. Could maybe be a central cgi, maybe even with intelligence to redirect to good/close/fast/up-to-date mirrors. Could work, but needs implementing. :-) Sounds like a path that would work very well; but yes, requires work. c. Do things in stages: * Copy the old release to the archive area a few days before release. Add a warning to users that a new build is due, and they should be careful that their downloaded images are all from one version. * Once that archive copy is live, update the links to point to the archive copy and push the new website. * On the day of release, release as normal and update the web pages in $VCS to point to the new release in release. Remove the new build due warning and add new build just happened. After the website is built, new users will see the new images. * A few days/weeks later, prune the images in the old tree under archive. No current pages should be looking here, so we're just dealing with stragglers. Staging is usually a quite save approach but requires better coordination which seems to have been problematic the last releases from what I perceived. I though would be happy to be proven wrong. ;) So long! Rhonda -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
Gerfried Fuchs wrote: We then prune most of the old ISO images so we don't waste too much space - older images can be recreated in the future using jigdo if necessary. To the best of my knowledge that would depend on snapshot.debian.net being functional because once we release we also prune out the old packages that would be required to build the old images. nope; that's what e.g. http://us.cdimage.debian.org/jigdo-area/*/snapshot/ is for. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: daniel.baum...@panthera-systems.net Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
On Wed, Apr 15, 2009 at 08:16:13PM +0200, Luk Claes wrote: Steve McIntyre wrote: On Wed, Apr 15, 2009 at 07:14:52PM +0200, Luk Claes wrote: Steve McIntyre wrote: Hi folks, At the moment we have problems when we do releases including new CD/DVD images, as you'll see from mailing list complaints about broken links each time. Simon Paillard and I had some discussion about this today on #debian-www and I've come up with a workflow that will improve things, I think (see 2c below). Please feel free to point out what I've missed... :-) 1. The Problem We generate new CDs and DVDs for each point release. These are published in the release area of cdimage.debian.org[1]. The image filenames and the top-level directory are versioned for clarity, and we add a current symlink in the debian-cd directory that points to ^^^ the most recent version. We move old trees of images into the archive area[2] as each new build is published, We then prune most of the old ISO images so we don't waste too much space - older images can be recreated in the future using jigdo if necessary. d. Other ideas? Can't we link to the 'current' images on the webpages? We do, but the image names themselves change from one release to the next too. Well then it should probably use an existing tag (like current_release_lenny which contains '5.0.1') that needs to be updated for the point release anyway IMHO. Someone added 3 extra tags which is not very maintainable IMHO. Note that it's easy to convert 5.0.1 to 501 in eperl... In the past there were ocasionally several days between the release and the CD image release, so you can't use the tag for the former for the latter. Haven't checked whether that is still the case. Also using the tag in the URL doesn't give you any advantages, you still have the same rebuild window... Gruesse, -- Frank Lichtenheld dj...@debian.org www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Dealing better with CD releases
Hi folks, At the moment we have problems when we do releases including new CD/DVD images, as you'll see from mailing list complaints about broken links each time. Simon Paillard and I had some discussion about this today on #debian-www and I've come up with a workflow that will improve things, I think (see 2c below). Please feel free to point out what I've missed... :-) 1. The Problem We generate new CDs and DVDs for each point release. These are published in the release area of cdimage.debian.org[1]. The image filenames and the top-level directory are versioned for clarity, and we add a current symlink in the debian-cd directory that points to the most recent version. We move old trees of images into the archive area[2] as each new build is published, We then prune most of the old ISO images so we don't waste too much space - older images can be recreated in the future using jigdo if necessary. Mirrors automatically sync from the debian-cd directory, so it's not a sane option to keep old images around there. Once we do a new build, we need to move the old one aside into the archive. We currently potentially have a window of a few hours of breakage, as the web pages that point directly to the old images stay around for quite a while. Even if they are updated directly in $VCS as we do a release, the website is only rebuilt periodically from cron. Until that happens, the stale pages will give 404 errors. This means pain on the mailing lists. We could *possibly* delay actually moving the new build into place until the new pages go live, but there are problems there too: we would rob the CD mirrors of any advance time to sync the images, plus we could end up waiting for a few hours for the website update (not ideal at the end of an already-long release process). 2. Possible solutions a. Stop linking directly to the images, and go through a set of symlinks instead. Potentially messy, and people may get mixed sets. Probably difficult to set up on mirrors too? b. Stop linking directly to the images, and go via redirects. Could maybe be a central cgi, maybe even with intelligence to redirect to good/close/fast/up-to-date mirrors. Could work, but needs implementing. :-) c. Do things in stages: * Copy the old release to the archive area a few days before release. Add a warning to users that a new build is due, and they should be careful that their downloaded images are all from one version. * Once that archive copy is live, update the links to point to the archive copy and push the new website. * On the day of release, release as normal and update the web pages in $VCS to point to the new release in release. Remove the new build due warning and add new build just happened. After the website is built, new users will see the new images. * A few days/weeks later, prune the images in the old tree under archive. No current pages should be looking here, so we're just dealing with stragglers. d. Other ideas? 3. What do we do? I'm thinking that solution b with a central redirector would be lovely if possible, but may take a lot of effort. If that's not feasible/desired, then should we try option c instead? Or, please shout at me and tell me what obvious easy solution I'm missing here. [1] http://cdimage.debian.org/debian-cd/ [2] http://cdimage.debian.org/cdimage/archive/ [3] http://www.debian.org/CD/http-ftp/ Cheers, -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied twisted, Just an earth-bound misfit, I... -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
Steve McIntyre wrote: Hi folks, At the moment we have problems when we do releases including new CD/DVD images, as you'll see from mailing list complaints about broken links each time. Simon Paillard and I had some discussion about this today on #debian-www and I've come up with a workflow that will improve things, I think (see 2c below). Please feel free to point out what I've missed... :-) 1. The Problem We generate new CDs and DVDs for each point release. These are published in the release area of cdimage.debian.org[1]. The image filenames and the top-level directory are versioned for clarity, and we add a current symlink in the debian-cd directory that points to ^^^ the most recent version. We move old trees of images into the archive area[2] as each new build is published, We then prune most of the old ISO images so we don't waste too much space - older images can be recreated in the future using jigdo if necessary. d. Other ideas? Can't we link to the 'current' images on the webpages? Cheers Luk -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
On Wed, 15 Apr 2009, Luk Claes wrote: Steve McIntyre wrote: Hi folks, At the moment we have problems when we do releases including new CD/DVD images, as you'll see from mailing list complaints about broken links each time. Simon Paillard and I had some discussion about this today on #debian-www and I've come up with a workflow that will improve things, I think (see 2c below). Please feel free to point out what I've missed... :-) 1. The Problem We generate new CDs and DVDs for each point release. These are published in the release area of cdimage.debian.org[1]. The image filenames and the top-level directory are versioned for clarity, and we add a current symlink in the debian-cd directory that points to ^^^ the most recent version. We move old trees of images into the archive area[2] as each new build is published, We then prune most of the old ISO images so we don't waste too much space - older images can be recreated in the future using jigdo if necessary. d. Other ideas? Can't we link to the 'current' images on the webpages? Then you can link to the directory with isos for a particular arch and type: http://cdimage.debian.org/debian-cd/current/amd64/iso-cd/ But not to an actual iso, due to the version number being included there: http://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-501-amd64-CD-1.iso /Mattias Wadenstein -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
On Wed, Apr 15, 2009 at 07:14:52PM +0200, Luk Claes wrote: Steve McIntyre wrote: Hi folks, At the moment we have problems when we do releases including new CD/DVD images, as you'll see from mailing list complaints about broken links each time. Simon Paillard and I had some discussion about this today on #debian-www and I've come up with a workflow that will improve things, I think (see 2c below). Please feel free to point out what I've missed... :-) 1. The Problem We generate new CDs and DVDs for each point release. These are published in the release area of cdimage.debian.org[1]. The image filenames and the top-level directory are versioned for clarity, and we add a current symlink in the debian-cd directory that points to ^^^ the most recent version. We move old trees of images into the archive area[2] as each new build is published, We then prune most of the old ISO images so we don't waste too much space - older images can be recreated in the future using jigdo if necessary. d. Other ideas? Can't we link to the 'current' images on the webpages? We do, but the image names themselves change from one release to the next too. -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
Steve McIntyre wrote: On Wed, Apr 15, 2009 at 07:14:52PM +0200, Luk Claes wrote: Steve McIntyre wrote: Hi folks, At the moment we have problems when we do releases including new CD/DVD images, as you'll see from mailing list complaints about broken links each time. Simon Paillard and I had some discussion about this today on #debian-www and I've come up with a workflow that will improve things, I think (see 2c below). Please feel free to point out what I've missed... :-) 1. The Problem We generate new CDs and DVDs for each point release. These are published in the release area of cdimage.debian.org[1]. The image filenames and the top-level directory are versioned for clarity, and we add a current symlink in the debian-cd directory that points to ^^^ the most recent version. We move old trees of images into the archive area[2] as each new build is published, We then prune most of the old ISO images so we don't waste too much space - older images can be recreated in the future using jigdo if necessary. d. Other ideas? Can't we link to the 'current' images on the webpages? We do, but the image names themselves change from one release to the next too. Well then it should probably use an existing tag (like current_release_lenny which contains '5.0.1') that needs to be updated for the point release anyway IMHO. Someone added 3 extra tags which is not very maintainable IMHO. Note that it's easy to convert 5.0.1 to 501 in eperl... Cheers Luk -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
Thilo Six wrote the following on 15.04.2009 22:20 Mattias Wadenstein wrote the following on 15.04.2009 19:18 On Wed, 15 Apr 2009, Luk Claes wrote: Steve McIntyre wrote: Hi folks, At the moment we have problems when we do releases including new CD/DVD images, as you'll see from mailing list complaints about broken links each time. Simon Paillard and I had some discussion about this today on #debian-www and I've come up with a workflow that will improve things, I think (see 2c below). Please feel free to point out what I've missed... :-) 1. The Problem We generate new CDs and DVDs for each point release. These are published in the release area of cdimage.debian.org[1]. The image filenames and the top-level directory are versioned for clarity, and we add a current symlink in the debian-cd directory that points to ^^^ the most recent version. We move old trees of images into the archive area[2] as each new build is published, We then prune most of the old ISO images so we don't waste too much space - older images can be recreated in the future using jigdo if necessary. d. Other ideas? Can't we link to the 'current' images on the webpages? Then you can link to the directory with isos for a particular arch and type: http://cdimage.debian.org/debian-cd/current/amd64/iso-cd/ But not to an actual iso, due to the version number being included there: http://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-501-amd64-CD-1.iso /Mattias Wadenstein How about a directory with links to current isos dricetly then? current $ ls -l total 0 lrwxrwxrwx 1 USER USER 37 2009-04-15 22:18 current-stable-ARCH-1.iso - ../ARCH/ISO/debian-501-amd64-CD-1.iso lrwxrwxrwx 1 USER USER 37 2009-04-15 22:18 current-stable-ARCH-2.iso - ../ARCH/ISO/debian-501-amd64-CD-2.iso But that approach obviously puts some more work on you Steve as you would have to rebuild the files: MD5SUMS MD5SUMS.sign SHA1SUMS SHA1SUMS.sign with the appropriate file names i guess. Maybe in that same directory. -- bye Thilo key: 0x4A411E09 -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
Mattias Wadenstein wrote the following on 15.04.2009 19:18 On Wed, 15 Apr 2009, Luk Claes wrote: Steve McIntyre wrote: Hi folks, At the moment we have problems when we do releases including new CD/DVD images, as you'll see from mailing list complaints about broken links each time. Simon Paillard and I had some discussion about this today on #debian-www and I've come up with a workflow that will improve things, I think (see 2c below). Please feel free to point out what I've missed... :-) 1. The Problem We generate new CDs and DVDs for each point release. These are published in the release area of cdimage.debian.org[1]. The image filenames and the top-level directory are versioned for clarity, and we add a current symlink in the debian-cd directory that points to ^^^ the most recent version. We move old trees of images into the archive area[2] as each new build is published, We then prune most of the old ISO images so we don't waste too much space - older images can be recreated in the future using jigdo if necessary. d. Other ideas? Can't we link to the 'current' images on the webpages? Then you can link to the directory with isos for a particular arch and type: http://cdimage.debian.org/debian-cd/current/amd64/iso-cd/ But not to an actual iso, due to the version number being included there: http://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-501-amd64-CD-1.iso /Mattias Wadenstein How about a directory with links to current isos dricetly then? current $ ls -l total 0 lrwxrwxrwx 1 USER USER 37 2009-04-15 22:18 current-stable-ARCH-1.iso - ../ARCH/ISO/debian-501-amd64-CD-1.iso lrwxrwxrwx 1 USER USER 37 2009-04-15 22:18 current-stable-ARCH-2.iso - ../ARCH/ISO/debian-501-amd64-CD-2.iso -- bye Thilo key: 0x4A411E09 -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
On Wed, 15 Apr 2009, Steve McIntyre wrote: b. Stop linking directly to the images, and go via redirects. Could maybe be a central cgi, maybe even with intelligence to redirect to good/close/fast/up-to-date mirrors. Could work, but needs implementing. :-) This sounds like a good idea, but there would still need to be logic to detect which mirrors had actually managed to get up to date... and that bit is probably a bit complicated. Don Armstrong -- It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject? -- Robert Fisk http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
