On Fri, Jul 18, 2008 at 02:33:40AM -0700, Ryan Murray wrote: > On Tue, 8 Jul 2008 12:59:19 -0500 > Stephen R Marenka <stephen@marenka.net> wrote: > buildd-maintainers@buildd.d.o, which expands to all of the > arch@buildd.debian.org aliases. m68k@buildd.debian.org forwards to > m68k-build@nocrew.org, with special exim rewriting logic so that the > To: is always seen as m68k-build@nocrew.org I've never seen a request > for this to be updated. Other archs replied to the correct address by > May 16th at the latest, and all issues with the changes for them were > sorted out by May 21st. Ouch. We moved from m68k-build@nocrew.org years ago. Would you please update m68k@buildd.debian.org to point to debian-68k@lists.debian.org? > > I've tried contacting buildd-team@b.d.o as well as other roles and > > individual addresses regularly since then. > $work. I'm sorry that this timing, combined with the spam-blackhole > nature of my email addresses (before may 13th for buildd-team, and late june for > other @d.o addresses and @cyberhqz.com), means that the messages I've > referred to are the only ones I've seen. Accepted. > > I have in the past advocated that one of the m68k team be granted > > access to update the ssh keys for buildd_m68k@b.d.o. I still think this > > is the best approach, but I have little faith in this being the result. > > As part of the process requires root access to update and reload apache > config files, there isn't much hope for a non-automated form of updates > this way. I'd happily settle for maintaining the ssh keys. The mail forwards would be nice, but I'm conversant with a workaround. I believe the root access would be for the incoming passwords? If so, Joey has started helping us out there and I'm fine with that. > > We have not had an etch-m68k/stable or stable-security w-b database since > > etch was released. Even though we've made multiple requests. > > etch-m68k was created by one ftp-master who told the others that he > would "do all the work" required to support it, and it was left to that. > I've been swamped with a new startup job since the release of etch, so > haven't had time to hack the buildd scripts to support etch-m68k/stable. Well at least someone was thinking us of at some point. :) > > We've been trying for months (since Feb. 14) to update the ssh keys for > > new buildds. The last update before that only happened after a face-to- > > face meeting at a conference. (And even then, not all of the keys were > > setup correctly.) > > This has been in part to the spamful nature of several debian role > address and over-eager adaptive anti-spam software. It means I've > never seen any of the requests, and they're buried in several gigs of > spam. That explains that. > > So please, either explicitly update our keys, give one of us access, or > > tell us you won't support us any longer. I'm rather tired of being > > I've updated the keys for buildds that already existed. For the new > buildds, I need either an IP address for static IP buildds, or a > 12 character+ password via encrypted email for dynamic IPs for > incoming.debian.org access. Security access needs a separate password I'll send these separately. > for each buildd with access. Buildds not entirely managed by Debian > Developers should likely not build security, as embargoed updates > should have minimum visibility outside (and even within) the project. > It's really the security team's call in the end on that part, tho. I concur. I'll confirm that when I start reenabling buildds. > > ignored. You've spent more time deleting my emails than it takes to fix > > the keys. > > I haven't actively deleted anything. I'm sorry that the situation has > lead you to believe this. That's okay. I'm sorry we ever got here. > > In the event that ya'll don't wish to support us any longer, m68k will > > either host our own w-b database or perhaps the debian-ports folks will > > support us. Either way, it would be nice if we could coordinate a transfer > > so that we don't lose any state information. > > I've heard rumours from a couple of groups that after the release of > lenny, they are looking at changes which will mean a move from > buildd.d.o wanna-build in any case: > * ftp-master is looking at dropping from unstable archs that > haven't made a release in 2+ releases to free up primary mirror space > for archive growth and new archs that seem more ready to be in a > release. I can't argue with that. I just hope there's a path to get back. > * Some active DSA members feel that keeping etch m68k systems > updated is a lot of time better spent doing many other things. That > situation is only getting worse from release to release. I'm under the impression DSA hasn't had to do anything for etch-m68k. We've only just recently figured out that we have to make a sourceful upload with a different original source version to get anything into etch-m68k. I agree that it's not a long term candidate for survival. > So, after the lenny release timeframe, m68k should look at moving all > the infrastructure (archive/dev systems/buildds/w-b) to one place (such > as debian-ports.org, which other archs are using as a pre- ftp-master > staging area). Fair enough. Hopefully we can work up a plan for this at the Kiel meeting. > I've attached the updated buildd_m68k authorized_keys file. It's also > helpful to know who is the local maintainer for each buildd, as that's > how the current file is laid out. Once I have the IPs/passwords for I'll send this separately. > the commented out buildds at the bottom, I'll enable them. Sorry again > for taking so long to get back to you. Apology accepted. I was rather under the impression that buildd-team was a team of people and not an individual. I also figured that the team would notice that only one arch didn't respond to the email and investigate. (Not knowing there was actually an email, I still figured someone would notice we hadn't been given access again.) If I may be of assistance to the buildd-team, please let me know. I'd be happy to devote some of my time there on a regular basis, whether or not m68k remains there. I'll even be responsible for correspondence if necessary. Thanks! Peace, Stephen -- Stephen R. Marenka If life's not fun, you're not doing it right! <stephen@marenka.net>
Attachment:
signature.asc
Description: Digital signature