Re: Question for all candidates: handle debian-admin more openly
[redirecting to -devel where this belongs] On Mon, Mar 13, 2006 at 12:11:59PM +0100, Martin Schulze wrote: > > > -- > > > Question to the release and archive people: Is there such a > > > requirement? Will such architectures indeed be included the archive? > > > Do we really need machines of the particular 64 bit architectures? If > > > so for which architectures exactly? > > > -- > > No decision has been made about including such partial architectures in the > > archive yet. I think it's the logical way to go once multiarch matures, but > > it hasn't really been discussed in-depth. The need for autobuilders capable > > of running binaries of these types exists whether or not we implement > > multiarch, though, because we already have sparc, powerpc, i386, and s390 > > library packages in the archive providing 64-bit variants for these > > architectures; having 32-bit autobuilders stumble over security builds of > > glibc would be a bad thing. > Glibc in woody can by autobuilt. > Glibc in sarge can by autobuilt. > Glibc in etch can most probably by autobuilt. For a while, it was *not* possible to autobuild glibc for etch on i386 and powerpc. As I said, I think that's been fixed now. > Which security updates are you talking about? The ones for etch. > > But this may have been largely mitigated in the meantime by some changes to > > dpkg-dev (dpkg-shlibdeps) that eliminate the dependency on ldd. If the > > existing lib packages can be autobuilt, I don't see any need to rush > > additional 64-bit autobuilders, since I think the current biarch approach to > > libraries is pretty lousy and shouldn't be expanded given that multiarch is > > on the horizon. > So the conclusion is that we currently don't need these machines. > Please correct me if I'm wrong. There is no release-critical need for them. I think it would be nice if the project had a 64-bit ppc porter machine, though, so that maintainers/NMUers of such 64-bit lib packages could test and debug when necessary. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: question for all candidates
On Fri, Mar 10, 2006 at 02:14:01AM +1000, Anthony Towns wrote: > On Thu, Mar 09, 2006 at 03:47:35PM +0200, Kalle Kivimaa wrote: > > Could these mails be required to have a valid GPG signature (either > > for a key in a public keyserver or a DD key)? This would eliminate the > > spam problem (almost) entirely. > keyring-maint is the address for problems with your key -- not being > able to mail it when you have problems with your key seems a bad idea. :) AFAICT, the only reasons a developer should need to contact the keyring-maint role address are: 1) needing to have a key removed from the ring 2) needing to get a replacement key accepted If the developer is contacting keyring-maint due to 1), I guess it means the key is no longer in their control, or else they could just publish their own revocation certificate and upload it to keyring.debian.org. However, you're still left with a question of verifying the authenticity of the request; perhaps having developers proxy such requests through some other developer for signing isn't a bad idea? Well, or maybe it is... 2) seems pretty easy to handle anyway, since getting a replacement key into the keyring does require new signatures from other DDs, so making "signed mail to keyring-maint" part of the process doesn't seem too onerous. Though as an additional practical consideration, doing gpg checks against a keyring is probably heavier than all other spam filtering rules combined... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Improving keyring maintenance (was Re: question for all candidates)
If you don't want to read the rant, skip to the bottom where I volunteer to help Anthony Towns wrote: >In the mail to the DPL I mentioned above, James outlined three fairly >significant technical changes that could be implemented to make the >job easier, and could be done by anyone, without requiring any special >priveleges; Why on EARTH didn't he outline these needed changes to *debian-devel*, or put them on the Debian wiki, or in some other way let *everyone* know what needed to be done? Nobody's going to volunteer to do them if nobody knows *what they are*. On the other hand, if he publicized what he needed, I promise he'd get volunteers writing code almost immediately. *This* is what's wrong with James's communication skills. Apparently it's also a problem with the *DPL*, who could equally well have publicized the same needed changes. --- Anyway, thank you for finally describing the issues (in http://lists.debian.org/debian-vote/2006/03/msg00275.html). If I could be pointed to the existing scripts for managing debian-keyring.gpg, I can start work on making them componentised, simple, obviously correct and secure, and fast. That sort of work is what I'm especially good at. I could start an alioth project for "keyring-manangement-scripts" if anyone else is interested in working on this. Hmm, this is going off topic for -vote Replies to -devel please. -- Nathanael Nerode <[EMAIL PROTECTED]> Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: question for all candidates
[Ways to improve keyring maintenance] On Thu, 2006-03-09 at 23:25 +1000, Anthony Towns wrote: > The second was to get rt setup to, uh, track requests -- it's waiting > on the first thing (since rt sends auto-replies, and auto-replies to > spam is bad, mmmkay), and possibly also lacks a debian.org machine > that can be its host. I might be missing something obvious, but why do we need a separate rt installation, with a debian.org machine to be found, and a spam problem to be tackled? We have the BTS, using that would eliminate point two entirely and alleviate most of point one, since spam fighting can be done in one place. There could be some feature missing from the BTS, but I can't think of one that's required for this task. And if there is one, wouldn't it be a better investment to add that possibility to our current BTS than to implement a parallel infrastructure? Thijs signature.asc Description: This is a digitally signed message part
Re: Question for all candidates: handle debian-admin more openly
Let's move this to elsewhere than -vote for technical discussion, d-ppc and d-ppc64 are good places for this. On Fri, Mar 10, 2006 at 02:21:12AM -0800, Steve Langasek wrote: > On Thu, Mar 09, 2006 at 01:03:47PM +0100, Sven Luther wrote: > > > Are bruckner and voltaire overloaded or do they lack services the > > > developers > > > need? > > > The release team has called for a multi-arch implementation to support > > powerpc64 userland over the biarch situation. This calls for a machine > > capable > > of building *and running* powerpc 64 code, which is not the case of existing > > powerpc 32bit machines. > > Er, the demand for powerpc64 userland support did not come from the release I stand corrected. It is a pre-requisite of having a multi-arch powerpc64 userland. The release team ruled against a biarch powerpc64 userland though, which would not have needed an extra machine. So, if we want a powerpc64 userland for etch, then having a 64bit powerpc buildd is needed. I know though that you ruled this only as a tentative optional release goal, not a strong one. > team; and the problems with building powerpc64 binary packages on a powerpc > system aren't specific to multiarch (obviously -- since multiarch hasn't Well, conceptually, there is no real difference between biarch and multiarch, despite the claims of the multiarch proponent who believe in moving libs around and everything. The real issue here is if you build a the packages for both bitness in a single arch, thus disabling the 64bit specific test runs when built on a 32bit machine, or putting all the 64bit stuff in its own arch. > actually happened yet, and we've been having problems building glibc on > voltaire since last year). Multiarch just happens to be (IMHO) the best /me builds glibc fine on my powerbook, so i wonder about this one, haven't done so in a long time though. Where is glibc built then ? > technical approach to building extra packages for targets such as ppc64. I agree with you that being able to install powerpc-arch packages on 32bit and both powerpc and powerpc64 arch packages on 64bit, and build all 64bit stuff in a 64bit arch is easier on the packaging work. Not sure if we should allow to install powerpc64 packages on 32bit powerpc, in order to be able to build 64bit packages on 32bit machines, or just build 64bit non-packaged apps on 32bit machines though. This kind of defeats the benefits of the multi-arch proposal though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: question for all candidates
On Thu, Mar 09, 2006 at 03:47:35PM +0200, Kalle Kivimaa wrote: > Could these mails be required to have a valid GPG signature (either > for a key in a public keyserver or a DD key)? This would eliminate the > spam problem (almost) entirely. keyring-maint is the address for problems with your key -- not being able to mail it when you have problems with your key seems a bad idea. :) I /think/ it's easier to do the other checks (pseudo-header/subject tag), since they're available for *.debian.org, and it's only lists.d.o which has pre-coded gpg sig checks. Dunno. > I think I could at least try to tackle this, as this doesn't need > anything special. If somebody else is already working on this, I would > appreciate a heads-up :) TTBOMK, none -- James was too busy to work on this at the time, and I don't think has gotten any less so. Cheers, aj signature.asc Description: Digital signature
Re: question for all candidates
[Moving this to -devel, please reply only there, this is not really voting related stuff. We are talking about things to improve keyring maintenance, for those not reading -vote.] Anthony Towns writes: > So first one was the spam problem, keyring-maint is a well-known address, > and mails that are meant to go to it could be in all sorts of weird > formats. There's already magic debian.org handling that'll drop stuff > without a pseudo-header in the mail (for [EMAIL PROTECTED]), or without > a specific tag in the subject which should mostly solve the problem, > which mostly requires working out some tags/headers and making sure all > the appropriate documentation is updated. Could these mails be required to have a valid GPG signature (either for a key in a public keyserver or a DD key)? This would eliminate the spam problem (almost) entirely. > The third thing was to develop some new scripts to manage > debian-keyring.gpg in a more componentised manner -- rather than > one huge blob, have many small files that are independently auditable > (this is the key for "[EMAIL PROTECTED]", it's authorised because it came > via [EMAIL PROTECTED] after blah lost their key in a tragic accident > involving a watermelon, it's signed by foo and bar...). The scripts > to manage all this have to be simple, obviously correct and secure, > and also fast enough to be usable. I think I could at least try to tackle this, as this doesn't need anything special. If somebody else is already working on this, I would appreciate a heads-up :) > Apparently there's been some mention of this on -private; I'm not > sure when. I recall some discussion, yes. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
