On Tue, 17 Aug 2010 10:14:51 +1000 "Brendan Simon (eTRIX)" <brendan.simon@etrix.com.au> wrote: > On 16/08/10 7:15 PM, Neil Williams wrote: > > Now that the Squeeze release freeze is in place, I'm preparing Grip > > Squeeze for a release too. The cron task has already been stopped to > > make it easier to work on the repository. It has taken absolutely ages to get this done. If anyone wants me to work on other stuff during this release freeze, the best thing to do is give me access to an always-on mirror of the Emdebian repositories (*all*) which is *not* on the current server and which has more than 50Gb of free space (after setting up the entire mirror) and all in a single partition with a really, really fast network connection. After synchronising my own local mirror, I had a hard disc failure and the consequent delay of rebuilding the superblocks and running the ext3 journal of a 1Tb drive, only to find that the drive still has an intermittent failure which shows up under large I/O strain. This led to me having to go back to square one and synchronise to my laptop before I even had the accurate data I needed to start programming the script which will manage the point releases for the Emdebian Grip repository. I have had to be mostly offline for the last few days, simply because my (fibre-optic cable) network connection has been constantly saturated. > > The first stage of the release process for Grip Squeeze is actually > > to update and then make a point release of Grip Lenny based on > > Debian 5.0.5. I now have a locally updated Emdebian Grip Lenny which matches up with Debian Lenny 5.0.5. Testing can now begin. The update is LARGE. There are changes to libc6, apt, dpkg, base-files, ... something like 100 packages had to updated beyond what was already in lenny-proposed-updates and several hundred more are to be moved from lenny-proposed-updates into lenny itself. I will look at summarising the changes in more detail during testing - I was mainly concentrating on developing the script to do the work. > Is it possible to also make a full release of Baked Grip Lenny ?? What happened to Baked being DIY? The short answer is No but that's actually because Baked cannot use udebs so those need to be excluded. Therefore, it isn't just a case of throwing a script at pool/ because there has to be some level of exclusion and then I start to think that there really is no point waiting for kernels or -dbg packages or -dev packages to go through the Baked process. > Given that it is much easier to create a new Baked repo, than to add > to an existing Baked repo, I think it will be simpler for people to > try out Baked and experiment, if all packages were available. This > is a once off process, and should only require some processing time > and storage. Neither of which I currently have in abundance. I do not have access to any machines capable of generating a full Baked release. Baked will take up to 20Gb once finished and require at least another 30-40Gb during preparation and this simply has to be on a single partition or things get very awkward. (e.g. 'mv' is much slower across partition boundaries, especially when moving tens of gigabytes a few files at a time). Baking that many packages could take several days, even if the process is automated and runs flawlessly. There seems little point setting this up unless the machine for Baked also includes a full mirror of the rest of the Emdebian repositories (possibly excluding toolchains). That pushes the space requirement well over 100Gb, probably closer to 200Gb or more to allow toolchains and processing space. I'm sorry, Brendan, if you want an Emdebian Baked repository based on this point release, you're going to have to provide or find someone who can provide the processing time and online storage necessary to do this. (That person is also probably going to have to know reprepro very well and keep in step with changes in the emdebian-grip-server processing scripts from SVN themselves - I won't have time to give tutorials.) From now until the Squeeze release, my free time is going to be solely working on the Emdebian releases. The various grip packages will get code improvements because those are the tools I need for the task, but other packages will not get any time whatsoever, *especially* if the work on those packages does not directly support the Emdebian or Debian release, i.e. Ubuntu support is a no-go. I always intended to do things this way (but have a lot less free time now than for Lenny) and I tried to get all the necessary changes into the packages before DebConf because the freeze was obviously imminent. (I don't buy these complaints from people who claim to have been surprised.) This was how it worked for the Lenny release, this is how it needs to work for the Lenny point release and the Squeeze release. If that is a problem then help me get the releases done by providing access to a large, fast, mirror running Debian Squeeze and with a single massive partition which I can simply allocate to reprepro. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgp3yDuPjDskd.pgp
Description: PGP signature