thanks. good job 2010/11/28 Neil Williams <[email protected]>
> OK, the server is something like available and the DNS has been > updated, so it should start to resolve over the next few hours. (On my > connection, it already does but then that could be a somewhat > artificial test.) > > Problems: > > 1. Grip packages need further improvements. There are likely to be > missing dependencies, the latest Lenny 5.0.7 point release does not > exist yet. Squeeze and Sid should be mostly OK but the entire repo has > had to be rebuilt, so there may be some inconsistencies. Please don't > do serious build stuff with the current repository (i.e. don't base a > release on anything in Grip currently). Even Lenny needs fixes/checks. > > 2. Crush 1.0 has been recovered, only for ARM and only for Lenny. > > 3. Toolchains for amd64/lenny have been included, Hector has got more > to upload later. > > 4: SVN browser links do not exist yet. (Trac is installed, not > configured) > > 5: SVN itself isn't yet public, anonymous or developer. (So those links > on the website is out of date.) > > 6: The mirroring needs to be reconfigured and isn't running yet. > > I won't have time to do anything more on this for a few days > (away at conference). If there are particular problems with Grip, file a > bug against buildd.emdebian.org, if there are broken links in the > website, those will need to wait until SVN is fixed. Other issues > (like Trac, SVN), ask Wookey or Hector. > > Note: those who have emdebian SVN checkouts are going to have issues. > We lost all SVN history in the recovery process and it isn't likely > that svn switch is going to be able to cope with going backwards from > rev 7800 to 280. We'll see but it may have to be that the old stuff > will have to be moved aside. Any SVN experts out there who know if svn > merge -c could be used? The path will have changed but whether a switch > and a reverse merge can be combined in a single call.... > > The history which does now exist is simply built from the svn tags > which were retained in the working copy, so changesets in the emdebian > scripts packages are simply between tagged versions. It turns out that > most version increments had been tagged. > > -- > > > Neil Williams > ============= > http://www.linux.codehelp.co.uk/ > > --
