Bug#356949: Contact. mr .andrew .smith
You are a certified winner of £253,000.00pounds by the powerball award 2009 fill in below your names, Home address,sex, age, telephone, occupation. Regards Mrs Rose Thomas -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Unidentified subject!
-- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Unidentified subject!
-- 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 [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
