On Wed, Jul 02, 2008 at 12:05:19AM +0200, Michael Schmitz wrote: > Hi, > >> Another week passes and we still don't have wanna-build access. >> >> Options: >> >> * move to debian-ports >> * already hosting kfreebsd and hurd >> * already have support for incoming >> * gave me access to buildd_m68k as well as my own account >> on the machine (I was playing with a possible etch-m68k >> w-b there.) >> * seem responsive >> * I haven't contacted them about this yet > > No idea how easy this would be to set up, bit what's the basic difference > between -ports and host our own?
Should be very easy for them, they already support to other archs and answered me about etch-m68k the same day or so. >> * host our own > > Looks like we'll have to do that, in the interim. How we keep the > databases more or less synchronized with the main one is what I'm not > clear about. Just pick up new needs-build state changes from the main > database, and handle everything else (failed, dep-wait, uploaded, > installed) locally? Except for installed that might be not too hard to > do. It's actually a fair amount of work if you want to include incoming support (which debian-ports already has). >> * continue on at b.d.o >> * I grow weary :) > > We'll have to make an effort, though. Shall I set up a weekly cronjob? To do what? >> * contact leader@ > > Definitely. I see this as the cabal dragging their feet, hoping we just > go away. Seems to be the Debian Way these days. Sadly. >> Issues: >> >> * The main issue I see with moving is the perception that we will or >> should lose ArchQualification and get dropped from sid. (Maybe we >> should, but that should be a separate conversation.) > > What else can we be dropped from? Seriously - the project needs to take a > decision on whether it would like to keep boasting about supporting the > widest range of architectures possible, and then deliver on that > commitment, or revert back to just another intel-only distribution (and > please shut up about portability). Preaching to the choir ... brother! >> * Coordinating with debian-release so that give-backs and dep-waits get >> set in the new db. > > Give-back gets set in our own db because our buildds talk to it directly. > Resetting dep-waits to needs-build should be part of the logic of the > database server, no? > Coordinating with -release ...I clearly remember the help and advice I > got when asking about ways to run testing-m68k. Thanks, but no thanks. They set global dep-waits and give-backs. They actually do a fair amount of work for us already, we just need to make sure they're using the new w-b if we move. I don't really think it's a huge issue. (fwiw, I think ftpmaster is who messed us up the most, but that doesn't matter now.) >> * Coordinating with buildd-team to preserve as much status as possible >> during the transition, then deleting the old db afterwards. (Which >> would be more work that fixing the current access, I should think.) > > Coordinating with buildd-team - funny notion indeed. Why would they care, > if they are unwilling or unable to act on the initial request, evidently? > > Why sell it as a 'move', anyway? We're just getting a backup system in > place, for as long as the buildd team takes to retrieve their head from > whatever dark place they stuck it. With their established track record in > handling buildd access for m68k, that cannot be taken as moving away from > Debian? > > Has there _any_ answer been forthcoming from buildd-team at all? Any > indication that someone read your mails? Yes, Ryan responded once with a request for the actual keys, but that was it. No replies after that (his mailed bounced a few times though). > Sorry, but the only practical solution that I see is running our own > backup database, and keep bugging b.d.o in the vain hope that someone, > sometime, will listen. My preferred solution is to try to move to debian-ports, mainly because it's already debugged and working. Any other buildd guys with opinions? ;) Peace, Stephen -- Stephen R. Marenka If life's not fun, you're not doing it right! <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
