Re: Meeting Minutes, FTPMaster meeting March 2011
On Wed, Mar 30, 2011 at 12:16:00PM +0200, Philipp Kern wrote: > On Wed, Mar 30, 2011 at 11:55:39AM +0200, Bastian Blank wrote: > > Why do you want one keyring per arch? What problem are you trying to > > solve with this? > I think it's called principle of least privilege. Of course we could also let > all buildd admins add arbitrary keys for any architecture and hope that it > isn't abused, given that you're able to upload from anywhere in the world > using the key. They still can use their personal keys to do the uploads, so I don't really see the difference. > (But then everyone who adds keys for his machines at home will just get his > privileges revoked anyway. Question is if harm is done at that point > already.) And it would be acceptable if a person in the wbadm group would do the same? This keyring adds new keys with a subset of permissions of the personal key of the requestor. It still can be traced properly to the "owner". So what harm should be done?[1] Bastian [1] Personally I have signing subkeys. This is a similar concept. -- Behind every great man, there is a woman -- urging him on. -- Harry Mudd, "I, Mudd", stardate 4513.3 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110330110032.gc7...@wavehammer.waldi.eu.org
Re: Meeting Minutes, FTPMaster meeting March 2011
On Wed, Mar 30, 2011 at 11:55:39AM +0200, Bastian Blank wrote: > On Mon, Mar 28, 2011 at 10:19:32PM +, Philipp Kern wrote: > > I talked with Joerg at the meeting and we agreed that arch-based admin > > keyrings aren't needed. If you feel so strongly about it, I think you > > should take it up yourself and make [0] support one keyring per arch. > Why do you want one keyring per arch? What problem are you trying to > solve with this? I think it's called principle of least privilege. Of course we could also let all buildd admins add arbitrary keys for any architecture and hope that it isn't abused, given that you're able to upload from anywhere in the world using the key. (But then everyone who adds keys for his machines at home will just get his privileges revoked anyway. Question is if harm is done at that point already.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Meeting Minutes, FTPMaster meeting March 2011
On Wed, Mar 30, 2011 at 11:54:21AM +0200, Bastian Blank wrote: > On Tue, Mar 29, 2011 at 10:50:31AM -0300, Henrique de Moraes Holschuh wrote: > > At that point, exactly why should you not upload the entire thing? > > In most parts of the world you actually have to pay for data transfer. > So why transfer something that is not going to be used at all? What if the .debs were mangled at dupload/dput time? All that matters is the list of files, their lengths and possibly hashes. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. signature.asc Description: Digital signature
Re: Meeting Minutes, FTPMaster meeting March 2011
On Mon, Mar 28, 2011 at 10:19:32PM +, Philipp Kern wrote: > I talked with Joerg at the meeting and we agreed that arch-based admin > keyrings aren't needed. If you feel so strongly about it, I think you > should take it up yourself and make [0] support one keyring per arch. Why do you want one keyring per arch? What problem are you trying to solve with this? Bastian -- Landru! Guide us! -- A Beta 3-oid, "The Return of the Archons", stardate 3157.4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110330095539.gb7...@wavehammer.waldi.eu.org
Re: Meeting Minutes, FTPMaster meeting March 2011
On Tue, Mar 29, 2011 at 10:50:31AM -0300, Henrique de Moraes Holschuh wrote: > At that point, exactly why should you not upload the entire thing? In most parts of the world you actually have to pay for data transfer. So why transfer something that is not going to be used at all? Bastian -- Superior ability breeds superior ambition. -- Spock, "Space Seed", stardate 3141.9 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110330095421.ga7...@wavehammer.waldi.eu.org
Re: Meeting Minutes, FTPMaster meeting March 2011
Joerg Jaspert writes: > Additionally we will support new architectures like armhf, sparc64, > powerpc64, sh4 and s390x in case someone does the neccessary > groundwork needed prior to an inclusion, and gets all the needed > preconditions settled. If porters want to discuss inclusion, they > should contact us. Hi, did you discuss supporting partial architecture for use with multiarch? What I mean here is that for example powerpc64 doesn't need a full set of packages. There is no need to run bash in 64bit for example. But some people might need a 64bit postgreql. So it would be enough to build only a subset of packages for powerpc64 and run the buildds under multiarch with powerpc + powerpc64 configured. Obviously that still is work in progress but with dpkg and apt finally getting multiarch ready and the emdebian people working on cross compilers and cross building this shouldn't be too far in the future now. The question is: Would you support a partial port that is just an extention of an existing port or does it need to be a full port? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tyelxa7q.fsf@frosties.localnet
Re: Meeting Minutes, FTPMaster meeting March 2011
> Note that it isn't entirely clear to me how splitting up keyrings per
> architecture would help there, so some explanation might help (if I want
> to make sure that whatever patch I come up with actually solves the
> issue at hand...).
You need to check on which site you luck. Lets take it that dak simply
requires one keyring per arch for accepting packages into the archive,
the part we talk about here is how to add/remove keys.
Now, currently this is implemented using ONE keyring to check the sigs
against before processing files. So what you probably want to do is to
give me a patch against buildd-{add,remove}-keys that will allow to have
one admin keyring per architecture. This shouldn't be too hard to
change, at the place we use it you already know the architecture.
When its agreed this is the way to go and you do it, please move the
admin keyrings into a subdir. The one and only currently is in the
keyrings maindir, it would be confusing to have the arch specific admin
rings there.
Also, I am on VAC until end of April, so any merge wont happen before
then.
--
bye, Joerg
I read the DUMP and agree to it.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vcz1shux@gkar.ganneff.de
Re: Meeting Minutes, FTPMaster meeting March 2011
On Mon, Mar 28, 2011 at 10:19:32PM +, Philipp Kern wrote: > On 2011-03-28, Wouter Verhelst wrote: > > But I'd think that "making sure this buildd host can still do uploads in > > a timely manner when the key expires" is pretty well inside the realm of > > the buildd admin's responsibility. > > And manual signing wouldn't be timely? Less so. > I talked with Joerg at the meeting and we agreed that arch-based admin > keyrings aren't needed. If you feel so strongly about it, I think you > should take it up yourself and make [0] support one keyring per arch. > (Or get Joerg to do it. As I told him that he doesn't need to consider > it in the initial design it feels unfair to me to ask him now. Either > way, if it isn't done, you don't feel strongly enough about it. There's > no policy decision in the way this time.) Sure; I'd be happy to put my code where my mouth is, if that helps solve this particular issue. It'll have to wait until my current move is over, however (see my [vac] on -private). Note that it isn't entirely clear to me how splitting up keyrings per architecture would help there, so some explanation might help (if I want to make sure that whatever patch I come up with actually solves the issue at hand...). > I still don't think it's necessary, as it will be mostly identical on > all archs and we'll be doing the work anyway but frankly I don't care, > as long as the keys are following the rules the ftp-masters set for > them. We'll still monitor the expiry and if you don't react quickly > enough do it ourselves. Of course. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Meeting Minutes, FTPMaster meeting March 2011
On Tue, 29 Mar 2011, Dominique Dumont wrote: > On Monday 28 March 2011 19:43:52 Henrique de Moraes Holschuh wrote: > > So, we have to either accept source-only uploads with the knowledge that > > some people will upload even more crap, or don't accept source-only > > uploads at all. There is no "punishment for the bad uploader" option, > > anyone proposing that is just setting the project up for a lot of > > aggravation IMO. > > How about putting "bad uploaders" on a low priority queue, so that source > package from "good uploaders" are built first ? > > This could minimize the impact of source package only upload... Why insist on a solution that is likely to cause social damage? Why insist on something that IS going to cause aggravation the very first time someone decides to complain about it? There are many other ways to avoid the need of a binary package upload from a DD's box/PDA/smartphone/laptop/netbook/whatever. You *WILL* have to build (and _test_) the binary packages anyway, otherwise you're either a perfect DD that never makes mistakes, or exactly the kind of DD we don't want near a source-only upload in the first place. At that point, exactly why should you not upload the entire thing? You have already built them. You already have to be able to sign the upload anyway, be it source-only, or source+binary. Very few DDs have to deal with uploading extremely large binary packages from upload-constrained boxes, and those are likely to be already using one of the numerous methods available to them to minimize the problem. This is off-topic for this thread, and I am repeating all that has been said before in numerous threads. I will post about this no further. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110329135031.gd21...@khazad-dum.debian.net
Re: Meeting Minutes, FTPMaster meeting March 2011
Bernd Zeimetz (29/03/2011): > And as you have to test-build your packages anyway the only reason I > see why you wouldn't be able to upload them is a very slow > connection to the rest of the world. One can test-build in her own, non-chroot environment, and still be cautious about what changed in configure.ac (or similar); so building in a chroot can be usually extra, fruitless work. (mesa or xorg-server come to mind.) And as far as I'm concerned, I just hate having to wait for xorg-server to be built on say mips or sparc before asking for xserver-xorg-dev to be installed on a porter machine to build my drivers there, when I *know* they build (since I tested them on say amd64, by tweaking the Architecture line). Not to mention the fact DSA doesn't want to handle anything like “experimental” chroots, so you can't get build dependencies from experimental, at all. Finally, requiring binary packages to be uploaded along source packages doesn't stop people from uploading broken packages, which basically lack a build dependency on say autoconf, automake, libtool, pkg-config, cmake, python, whatever. It doesn't look like that “let's require binary packages” filter is helping much. The BTS is full of such FTBFS bug reports. KiBi. signature.asc Description: Digital signature
Re: Meeting Minutes, FTPMaster meeting March 2011
On ti, 2011-03-29 at 09:52 +0200, Bernd Zeimetz wrote: > And as you have to test-build your packages anyway the only reason I see > why you wouldn't be able to upload them is a very slow connection to the > rest of the world. Bandwidth quotas would be another reason. (I have no opinion on whether uploads should be required or not, though.) -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301385335.11500.10.ca...@havelock.liw.fi
Re: Meeting Minutes, FTPMaster meeting March 2011
On 03/28/2011 07:05 PM, Philipp Kern wrote: > I think people who screw up repeatedly even after being told to be careful > should have their upload privileges suspended at the discretion of the > ftp-masters. We had that in the past as well. Then source-only uploads > shouldn't be a problem. That won't work, at least not within a proper time frame. And as you have to test-build your packages anyway the only reason I see why you wouldn't be able to upload them is a very slow connection to the rest of the world. > .oO( Don't throw too many technical(ly inferior) solutions onto social > problems... ) Sometimes simple technical solutions are easier to implement than fixing social problems. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d918fd5.7010...@bzed.de
Re: Meeting Minutes, FTPMaster meeting March 2011
On Monday 28 March 2011 19:43:52 Henrique de Moraes Holschuh wrote: > So, we have to either accept source-only uploads with the knowledge that > some people will upload even more crap, or don't accept source-only > uploads at all. There is no "punishment for the bad uploader" option, > anyone proposing that is just setting the project up for a lot of > aggravation IMO. How about putting "bad uploaders" on a low priority queue, so that source package from "good uploaders" are built first ? This could minimize the impact of source package only upload... HTH Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103290925.08655.dominique.dum...@hp.com
Re: Meeting Minutes, FTPMaster meeting March 2011
On 2011-03-28, Wouter Verhelst wrote: > But I'd think that "making sure this buildd host can still do uploads in > a timely manner when the key expires" is pretty well inside the realm of > the buildd admin's responsibility. And manual signing wouldn't be timely? I talked with Joerg at the meeting and we agreed that arch-based admin keyrings aren't needed. If you feel so strongly about it, I think you should take it up yourself and make [0] support one keyring per arch. (Or get Joerg to do it. As I told him that he doesn't need to consider it in the initial design it feels unfair to me to ask him now. Either way, if it isn't done, you don't feel strongly enough about it. There's no policy decision in the way this time.) I still don't think it's necessary, as it will be mostly identical on all archs and we'll be doing the work anyway but frankly I don't care, as long as the keys are following the rules the ftp-masters set for them. We'll still monitor the expiry and if you don't react quickly enough do it ourselves. Kind regards Philipp Kern [0] scripts/debian/buildd-* in http://ftp-master.debian.org/git/dak.git/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnip22bk.3f0.tr...@kelgar.0x539.de
Re: Meeting Minutes, FTPMaster meeting March 2011
On Mon, 28 Mar 2011, Mark Hymers wrote: > The main decision which needs to be made is whether, as a project, > we want source only uploads or to throw away DD built non-all debs. There are two separate decisions here. One is whether we throw away DD built debs (non-all, or everything.[0]) The second is whether we allow source-only uploads. I believe the first is relatively non-controversial;[1] the second is contentious. However, they can certainly be decoupled, and the non-controversial one implemented until consensus or some process happens around the second. Don Armstrong 0: I would personally like to see everything thrown away, including _all... but that's certainly more technically complicated to implement, and I wouldn't want the perfect to hold up the good. 1: Presumably someone will correct me if this actually is controversial. -- There are two types of people in this world, good and bad. The good sleep better, but the bad seem to enjoy the waking hours much more. -- Woody Allen http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110328195728.gz23...@teltox.donarmstrong.com
Re: Meeting Minutes, FTPMaster meeting March 2011
Hi Phil, [ Note: re-reading, I find that my mail could be read as "heated", which it wasn't meant to be. I'm firm in what I believe needs to be done, but not angry :-) ] On Mon, Mar 28, 2011 at 03:08:12PM +0200, Philipp Kern wrote: > > So, AIUI, only members of the wbadm GID can change keys, not any random > > buildd admin. > > > > If I'm supposed to be maintaining a buildd host, I should be able to > > update the key allowed for signing, or I can't do my job properly. We've > > had a situation where only a limited group of people could activate > > buildd machines in the past, and it was broken; I have no desire to get > > back to that situation. > > AFAIR you were against autosigning on your buildds. So nothing will change > for you anyway, unless you allow it. You may remember from your wanna-build BOF during dc10 that I said something along the lines of "yes, I know I said I was against it. I changed my mind." :-) > As Joerg said, we still have that problem because only gid=wbadm can > change the ssh keys on grieg. I wasn't aware of that; I was under the impression that I could update ssh keys when and if I needed to. You're not helping :-) > And only gid=ftp-master can change the list for the hosts allowed to > access incoming. (To be fair: DSA now exports a list of d.o buildds > to ftp-master to automatically allow access to ftp-master's incoming > directory and to security-master.) And you need the machine installed > with the buildd profile by DSA in the first place. Sure. There's always going to be some things I can't do, if we want the machine to be running properly (that is, unless I become a member of the appropriate teams, but given my current time constraints that isn't very likely). But I'd think that "making sure this buildd host can still do uploads in a timely manner when the key expires" is pretty well inside the realm of the buildd admin's responsibility. > > Please fix this by doing one of > > - Adding me (and other buildd admins) to the wbadm group, > > - Creating a new GID to which all buildd admins are added (I'd suggest > > 'builddadm' for that, but apparently that's already taken and is 100% > > the same as wbadm; if that isn't used, however, it could make sense) > > which would limit who can update keys > > - Changing the GID to "Debian", rather than anything else (I don't think > > you lose much by doing that, but I guess there might be reasons not > > to, and it's not my call anyway) > > - Finding someone else to maintain praetorius and voltaire > > The purpose of the wbadm group is the maintainance of the central > wanna-build host. We also control who accesses our infrastructure and > how. That's already the case since years. Do you have any complaint > about the request turnaround time there? Not currently. However, I was not initially complaining about the request turnaround time back when the wanna-build team consisted mostly of James and Ryan, either. But eventually that changed, and I got very very very frustrated with that[1]. When the buildd stuff was changed so that many more people got involved, I was hoping that this kind of thing would never happen again. Now I'm not saying that every buildd admin should have full and unlimited access to wanna-build.d.o, or that we should all be responsible for maintaining the wanna-build software (i.e., I'm not suggesting to make wbadm and the set of buildd admins be one and the same group). But I do think that when you add a new responsibility, you should figure out whether this responsibility is in the realm of the buildd admin or not. I believe that this one is, and therefore I should be able to do it myself without requiring outside intervention. As said, usually the request turnaround time is very reasonable, and I have no complaints there. But there have been times where it was slightly longer than average, and adding more things on the heap of stuff which only you guys can do isn't helping. And, really, when a key rollover needs to be done, most of the work is "gpg --gen-key", and scp'ing the public key to the right system. If I can do all that, but need one of you to run "mv $key $targetloc", that's just adding needless bureaucracy. I want to avoid that, because I don't believe it makes sense. If the fear is that people will add keys without following proper procedure, then please document the procedure in a way which makes it hard to miss, and by all means bitchslap those who fail to follow procedure properly. The set of "buildd admins" is small enough that this should be workable. But I don't think it makes sense to take an already limited group of people (buildd admins) and limit them even further for things that lie squarely in their area of responsibility. I don't really care about SSH keys, because they don't change (unless someone breaks in and steals them, but then I expect DSA to step in, lock down the host, do forensics, reinstall, etc, and eventually generate a new SSH key while
Re: Meeting Minutes, FTPMaster meeting March 2011
On Mon, Mar 28, 2011 at 01:26:02PM +0200, Joerg Jaspert wrote: > Hi > > >> - The long standing project of enabling autosigning for the buildds also > >> got finished. That means that packages successfully built can now be > >> uploaded automatically, without waiting for the buildd admin to wake > >> up/come back from holiday/whatever. The rules for this are simple > >>* the buildd host must be maintained by DSA and have restricted > >> access > >>* the key must have a size of 4096 or higher and the private part > >> must never leave the buildd > >>* the key expires within 120 days > >>* there are not more than 2 keys per buildd (so they can do a key > >> rollover) > >>* no network access during build time/for the build part > >> We maintain a set of keyrings, one per architecture, together with a > >> shell script which allows the wanna-build admins to add and remove > >> keys as necessary. > > So, AIUI, only members of the wbadm GID can change keys, not any random > > buildd admin. > > Correct. > > > If I'm supposed to be maintaining a buildd host, I should be able to > > update the key allowed for signing, or I can't do my job properly. We've > > had a situation where only a limited group of people could activate > > buildd machines in the past, and it was broken; I have no desire to get > > back to that situation. > > You can do your job properly and you can activate buildd machines. > What you can not get is an added feature on top slightly easing the > workload. I don't think this can seriously be called "unable to do the > job properly". Many improvements in Debian start out as an "added feature on top slightly easing the workload". Wanna-build started out as a way to not have to run quinn-diff manually. Buildd started out as a way to not have to run sbuild manually. Sbuild started out as a way to not have to run dpkg-buildpackage... well, you get the idea. It's not required today, that much is true. In two years' time, people will have mostly forgotten about these manually-maintained buildd hosts, and will complain when their pet package isn't uploaded into the archive yet, five minutes after build. (heck, they do so now, occasionally, even without autosigning) > Now, this feature does require a whole set of people to do work before > (for example DSA to have the machine DSA maintained and secured up, > getting the ssh keys and w-b access for the buildd, getting access to > incoming to build stuff from there), and so I really fail to see where > "When asking for ssh/incoming/w-b access, get them to prepare the > autosign key" is much of added trouble? That in itself isn't, no. But the key rollover bit (which is senseble, btw; I'm not suggesting you remove that requirement) does make it a problem. > > Please fix this by doing one of > > - Adding me (and other buildd admins) to the wbadm group, > > None of ftpteams call. Sure. > > - Creating a new GID to which all buildd admins are added (I'd suggest > > 'builddadm' for that, but apparently that's already taken and is 100% > > the same as wbadm; if that isn't used, however, it could make sense) > > which would limit who can update keys > > Also none of ftpteams call, we dont change other peoples groups. I'm not asking to change other people's groups, here, just that "some other group" is used. If builddadm is used for something else and that can't be rolled into wbadm (which seems to be the case), then something else should be used. The point is that a buildd admin should be able to update the necessary bits for his buildd to function properly, if the bits are broken. Otherwise you don't need a buildd admin. > > - Changing the GID to "Debian", rather than anything else (I don't think > > you lose much by doing that, but I guess there might be reasons not > > to, and it's not my call anyway) > > Now this won't happen. fair enough. > > - Finding someone else to maintain praetorius and voltaire > > Not my call either, even though I do think that putting it onto this single > feature is a bit over the top. That's your choice, but I do have my reasons. > Basically this is something the people on the buildd site have to fight out > between. What we on the ftp side want is a *limited* set of people who can do > keychanges, that isn't changing too often. This makes sense. > wbadm does seem to be a perfect fit for this. This I disagree with. > > For clarity, the last option is *not* my preference. However, if none of > > the other three are done, I'm no longer interested in spending my time > > doing something I can't do properly anyway. I've been forced to work > > around not being able to fix issues with connectivity between my buildd > > host and the rest of the Debian infrastructure in the past, and I won't > > stand for it anymore. > > See above. This is an *additional* thing, any buildd will be able to run even > without this (and someone mentioned you don't like this feature
Re: Meeting Minutes, FTPMaster meeting March 2011
On Mon, 28 Mar 2011, Bernd Zeimetz wrote: > On 03/28/2011 04:37 PM, Mark Hymers wrote: > > The main decision which needs to be made is whether, as a project, we > > want source only uploads or to throw away DD built non-all debs. > > There's not entire agreement amongst the ftpmasters about this (I err on > > the side of the source-only uploads to avoid making people waste time > > and bandwidth but that's not the only opinion). One objection to > > source-only is the perception that people will throw untested things at > > the buildds and see what sticks. That strikes me as a social problem, > > but as a project we probably want to think how to handle it. > > Due to the problem of uploading untested stuff, accidentally or not > accidentally I'd suggest to require uploads of all binary packages > together with the source and throw away the arch:any binary packages > (after passing NEW if necessary). > Also I'd be in favour of throwing away DD built arch:all debs as soon as > soon as building them on the buildds is implemented. Possibly archiving interesting metadata from the "discarded" binary debs, and comparing it to the autobuilt ones, etc. This stuff has been very well dissected in debian-devel somewhat recently. What needs to be said is that we CAN FORGET IT about punishing DDs for being lazy and screwing up source-only uploads that don't even built. It is just not going to happen in practice, even to people who do it once a week. What would happen instead is a lot of aggravating business in -private, and a major waste of time and good will across a sizeable portion of the project. So, we have to either accept source-only uploads with the knowledge that some people will upload even more crap, or don't accept source-only uploads at all. There is no "punishment for the bad uploader" option, anyone proposing that is just setting the project up for a lot of aggravation IMO. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110328174352.ga21...@khazad-dum.debian.net
Re: Meeting Minutes, FTPMaster meeting March 2011
On 2011-03-28, Bernd Zeimetz wrote: > On 03/28/2011 04:37 PM, Mark Hymers wrote: >> The main decision which needs to be made is whether, as a project, we >> want source only uploads or to throw away DD built non-all debs. >> There's not entire agreement amongst the ftpmasters about this (I err on >> the side of the source-only uploads to avoid making people waste time >> and bandwidth but that's not the only opinion). One objection to >> source-only is the perception that people will throw untested things at >> the buildds and see what sticks. That strikes me as a social problem, >> but as a project we probably want to think how to handle it. > Due to the problem of uploading untested stuff, accidentally or not > accidentally I'd suggest to require uploads of all binary packages > together with the source and throw away the arch:any binary packages > (after passing NEW if necessary). I think people who screw up repeatedly even after being told to be careful should have their upload privileges suspended at the discretion of the ftp-masters. We had that in the past as well. Then source-only uploads shouldn't be a problem. .oO( Don't throw too many technical(ly inferior) solutions onto social problems... ) Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnip1fts.2td.tr...@kelgar.0x539.de
Re: Meeting Minutes, FTPMaster meeting March 2011
On 03/28/2011 04:37 PM, Mark Hymers wrote: > The main decision which needs to be made is whether, as a project, we > want source only uploads or to throw away DD built non-all debs. > There's not entire agreement amongst the ftpmasters about this (I err on > the side of the source-only uploads to avoid making people waste time > and bandwidth but that's not the only opinion). One objection to > source-only is the perception that people will throw untested things at > the buildds and see what sticks. That strikes me as a social problem, > but as a project we probably want to think how to handle it. Due to the problem of uploading untested stuff, accidentally or not accidentally I'd suggest to require uploads of all binary packages together with the source and throw away the arch:any binary packages (after passing NEW if necessary). Also I'd be in favour of throwing away DD built arch:all debs as soon as soon as building them on the buildds is implemented. Cheers, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d90b715.8020...@bzed.de
Re: Meeting Minutes, FTPMaster meeting March 2011
On Mon, 28, Mar, 2011 at 11:54:29AM +0200, Stefano Zacchiroli spoke thus.. > Related to this, in your agendas you did mention the topic of "throwaway > DD built .debs". I understand from the minutes that no specific hacking > on that has been done (understandably given how much other stuff has > been going on!), but have you advanced on the design of that? I believe > it's a very important technical advancement we need to guarantee all > packages are built equally. Do you have any other news to share about > that? Ok, the situation here is the following: The technical point of view is that source-only uploads are trivially turned on. Indeed, it's actually possible (as quite a few people know) to upload only src+all debs now but not src only if your package doesn't provide an all deb. That's a bit of a discrepancy. As for throwing away non-all debs, the infrastructure is there, it just needs a relatively small amount of code to make it happen (it's a config setting which at the moment just causes a reject with the message "This code still to be written". The main decision which needs to be made is whether, as a project, we want source only uploads or to throw away DD built non-all debs. There's not entire agreement amongst the ftpmasters about this (I err on the side of the source-only uploads to avoid making people waste time and bandwidth but that's not the only opinion). One objection to source-only is the perception that people will throw untested things at the buildds and see what sticks. That strikes me as a social problem, but as a project we probably want to think how to handle it. Once a decision is made, implementation is easy, but I'd like some form of consensus before we go down that route. Oh, and at the moment we'd still need .all debs uploaded and kept, although as was said in the minutes, Phil Kern was looking into that and some backend work in dak and dpkg was done to help with it. Thanks, Mark -- Mark Hymers "I never make predictions. I never have and I never will." Tony Blair signature.asc Description: Digital signature
Re: Meeting Minutes, FTPMaster meeting March 2011
On Mon, Mar 28, 2011 at 11:25:13AM +0200, Wouter Verhelst wrote: > On Sun, Mar 27, 2011 at 10:56:28AM +0200, Joerg Jaspert wrote: > > - The long standing project of enabling autosigning for the buildds also > > got finished. That means that packages successfully built can now be > > uploaded automatically, without waiting for the buildd admin to wake > > up/come back from holiday/whatever. The rules for this are simple > >* the buildd host must be maintained by DSA and have restricted access > >* the key must have a size of 4096 or higher and the private part > > must never leave the buildd > >* the key expires within 120 days > >* there are not more than 2 keys per buildd (so they can do a key > > rollover) > >* no network access during build time/for the build part > > > > We maintain a set of keyrings, one per architecture, together with a > > shell script which allows the wanna-build admins to add and remove > > keys as necessary. > So, AIUI, only members of the wbadm GID can change keys, not any random > buildd admin. > > If I'm supposed to be maintaining a buildd host, I should be able to > update the key allowed for signing, or I can't do my job properly. We've > had a situation where only a limited group of people could activate > buildd machines in the past, and it was broken; I have no desire to get > back to that situation. AFAIR you were against autosigning on your buildds. So nothing will change for you anyway, unless you allow it. As Joerg said, we still have that problem because only gid=wbadm can change the ssh keys on grieg. And only gid=ftp-master can change the list for the hosts allowed to access incoming. (To be fair: DSA now exports a list of d.o buildds to ftp-master to automatically allow access to ftp-master's incoming directory and to security-master.) And you need the machine installed with the buildd profile by DSA in the first place. > Please fix this by doing one of > - Adding me (and other buildd admins) to the wbadm group, > - Creating a new GID to which all buildd admins are added (I'd suggest > 'builddadm' for that, but apparently that's already taken and is 100% > the same as wbadm; if that isn't used, however, it could make sense) > which would limit who can update keys > - Changing the GID to "Debian", rather than anything else (I don't think > you lose much by doing that, but I guess there might be reasons not > to, and it's not my call anyway) > - Finding someone else to maintain praetorius and voltaire The purpose of the wbadm group is the maintainance of the central wanna-build host. We also control who accesses our infrastructure and how. That's already the case since years. Do you have any complaint about the request turnaround time there? The builddadm group is a group that's allowed to log in to all buildds and thus is root-equivalent for quite some machines. Thus the two groups are separated. The whole key management thing isn't really limited to gid=wbadm by design, it's just that you need to be able to access ftp-master and have the key signing key in the admin keyring. The idea is that we could even do the key rotation bit for you, which means less work for the buildd admin. > For clarity, the last option is *not* my preference. However, if none of > the other three are done, I'm no longer interested in spending my time > doing something I can't do properly anyway. I've been forced to work > around not being able to fix issues with connectivity between my buildd > host and the rest of the Debian infrastructure in the past, and I won't > stand for it anymore. I'm not sure why it's more of a problem than it used to be. I'd be sad to lose you as a buildd admin. I'm not actually sure why you threaten us with it, though. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Meeting Minutes, FTPMaster meeting March 2011
Hi >> - The long standing project of enabling autosigning for the buildds also >> got finished. That means that packages successfully built can now be >> uploaded automatically, without waiting for the buildd admin to wake >> up/come back from holiday/whatever. The rules for this are simple >>* the buildd host must be maintained by DSA and have restricted >> access >>* the key must have a size of 4096 or higher and the private part >> must never leave the buildd >>* the key expires within 120 days >>* there are not more than 2 keys per buildd (so they can do a key >> rollover) >>* no network access during build time/for the build part >> We maintain a set of keyrings, one per architecture, together with a >> shell script which allows the wanna-build admins to add and remove >> keys as necessary. > So, AIUI, only members of the wbadm GID can change keys, not any random > buildd admin. Correct. > If I'm supposed to be maintaining a buildd host, I should be able to > update the key allowed for signing, or I can't do my job properly. We've > had a situation where only a limited group of people could activate > buildd machines in the past, and it was broken; I have no desire to get > back to that situation. You can do your job properly and you can activate buildd machines. What you can not get is an added feature on top slightly easing the workload. I don't think this can seriously be called "unable to do the job properly". Now, this feature does require a whole set of people to do work before (for example DSA to have the machine DSA maintained and secured up, getting the ssh keys and w-b access for the buildd, getting access to incoming to build stuff from there), and so I really fail to see where "When asking for ssh/incoming/w-b access, get them to prepare the autosign key" is much of added trouble? > Please fix this by doing one of > - Adding me (and other buildd admins) to the wbadm group, None of ftpteams call. > - Creating a new GID to which all buildd admins are added (I'd suggest > 'builddadm' for that, but apparently that's already taken and is 100% > the same as wbadm; if that isn't used, however, it could make sense) > which would limit who can update keys Also none of ftpteams call, we dont change other peoples groups. > - Changing the GID to "Debian", rather than anything else (I don't think > you lose much by doing that, but I guess there might be reasons not > to, and it's not my call anyway) Now this won't happen. > - Finding someone else to maintain praetorius and voltaire Not my call either, even though I do think that putting it onto this single feature is a bit over the top. Basically this is something the people on the buildd site have to fight out between. What we on the ftp side want is a *limited* set of people who can do keychanges, that isn't changing too often. wbadm does seem to be a perfect fit for this. > For clarity, the last option is *not* my preference. However, if none of > the other three are done, I'm no longer interested in spending my time > doing something I can't do properly anyway. I've been forced to work > around not being able to fix issues with connectivity between my buildd > host and the rest of the Debian infrastructure in the past, and I won't > stand for it anymore. See above. This is an *additional* thing, any buildd will be able to run even without this (and someone mentioned you don't like this feature anyways?), and so you can do your work as properly as you have been able until now, so suddenly going this high up seems a bit heavy to me. (Especially since any serious buildd does need more other bits added and allowed before) Anyways, as written above, this is mainly an issue for a team I have nothing in, deal with them. What ftpmaster wants to have we have stated. How we want the keys submitted is a technical issue already dealt with too, so the rest seems to be a social issue that should be solveable in whatever way. -- bye Joerg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/469b12079792e7c91286bd1953a073e2.squir...@mail.ganneff.de
Re: Meeting Minutes, FTPMaster meeting March 2011
On Sun, Mar 27, 2011 at 10:56:28AM +0200, Joerg Jaspert wrote:
> Hello world,
>
> as previously announced[1] we had a FTPMaster meeting in the
> LinuxHotel[2] in Essen during the week from March 21st till 27th. While
> there have been[3] quite[4] a number[5] of blog[6] posts[7] about this
> meeting[8], a more formal set of minutes seems to be called for, so here
> we go.
Hello FTP {masters,assistants,fanboys}, DSA, buildd admins, etc.,
thanks for your frenetic hacking week and for the way in which you've
kept the rest of the Debian community up to date with what was going on.
For even more transparency, and its durability in time, I've updated the
sprint wiki page http://wiki.debian.org/Sprints/2011/FtpMasterSprint
with pointers to your agenda, reports, blog posts, etc. Please review it
to check I haven't overlooked anything.
(Shameless plug: sprints and their transparency are very important for
Debian to get work done and avoid the risks of cabal-ish
meetings. That's why I routinely ask sprint participants to help me out
in maintaining the information at http://wiki.debian.org/Sprints
current. It's working well, but it still is quite an amount of work. If
anyone out there is willing to help in sprint organization and
documentation, I would *love* that. Please mail me at if
you'd like to *volunteer* as a little sprint organization helper.)
> And before we finally bore you with the details of our work, let us tell
> you that there is again a good reason to send condolences to one of our
> team members. Similar to our last meeting where we took the opportunity
> to welcome a new FTPMaster, we are now torturing Ansgar Burchardt,
> having made him FTP Assistant. And like our last promotion - he also
> didn't run away screaming.
Condolences^W Welcome on board, Ansgar!
> If you want to access the database on ries, use psql service=projectb,
> it will do the right thing for you. Should you use projectb access for
> one of your own projects, to gather whatever data it provides, keep in
> mind that we do not guarantee any kind of schema stability there. But if
> you can specify your needs we can always think about creating a view for
> you - or exporting the data in a defined format like
> RFC822/Yaml/whatever if it makes more sense or a direct projectb access
> is impractical. Just talk to us.
As I routinely end participating in discussions with DDs saying
"ProjectB-what?", I've mentioned this at http://wiki.debian.org/ProjectB
and linked it from the FTPMaster wiki page. If you have suggestions on
where to better document it please let me know or, better, provide
patches!
> This is, of course, just a first step towards being able to build
> .all debs on the buildds.
Related to this, in your agendas you did mention the topic of "throwaway
DD built .debs". I understand from the minutes that no specific hacking
on that has been done (understandably given how much other stuff has
been going on!), but have you advanced on the design of that? I believe
it's a very important technical advancement we need to guarantee all
packages are built equally. Do you have any other news to share about
that?
> - A dak package to upload into unstable. Although that's coming Real
>Soon Now, honest (especially as one of the ftpteam needs it...).
Neat!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Meeting Minutes, FTPMaster meeting March 2011
On Sun, Mar 27, 2011 at 10:56:28AM +0200, Joerg Jaspert wrote: > - The long standing project of enabling autosigning for the buildds also > got finished. That means that packages successfully built can now be > uploaded automatically, without waiting for the buildd admin to wake > up/come back from holiday/whatever. The rules for this are simple >* the buildd host must be maintained by DSA and have restricted access >* the key must have a size of 4096 or higher and the private part > must never leave the buildd >* the key expires within 120 days >* there are not more than 2 keys per buildd (so they can do a key > rollover) >* no network access during build time/for the build part > > We maintain a set of keyrings, one per architecture, together with a > shell script which allows the wanna-build admins to add and remove > keys as necessary. So, AIUI, only members of the wbadm GID can change keys, not any random buildd admin. If I'm supposed to be maintaining a buildd host, I should be able to update the key allowed for signing, or I can't do my job properly. We've had a situation where only a limited group of people could activate buildd machines in the past, and it was broken; I have no desire to get back to that situation. Please fix this by doing one of - Adding me (and other buildd admins) to the wbadm group, - Creating a new GID to which all buildd admins are added (I'd suggest 'builddadm' for that, but apparently that's already taken and is 100% the same as wbadm; if that isn't used, however, it could make sense) which would limit who can update keys - Changing the GID to "Debian", rather than anything else (I don't think you lose much by doing that, but I guess there might be reasons not to, and it's not my call anyway) - Finding someone else to maintain praetorius and voltaire For clarity, the last option is *not* my preference. However, if none of the other three are done, I'm no longer interested in spending my time doing something I can't do properly anyway. I've been forced to work around not being able to fix issues with connectivity between my buildd host and the rest of the Debian infrastructure in the past, and I won't stand for it anymore. Thanks, -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
GIT for pdiff generation (was: Meeting Minutes, FTPMaster meeting March 2011)
On Sun, 27 Mar 2011, Joerg Jaspert wrote: > - As there have been intermittent problems with the current tool which > generates the pdiff files (on occasion causing us to have to restart > the whole diff series), we looked into improving the situation. We > finally came up with the idea to store the affected files (Packages, > Sources, Contents) uncompressed in a local git repository and use gits > ability to output the needed ed scripts (which pdiffs are). The basic > idea would be to save the git commitid relating to the mirrorpushes we > did and then use that, combined with a call to "git difftool --extcmd > 'diff --ed' --no-prompt" to output the ed scripts. This ought to be > more stable, and even better, we can replay whole series of pdiffs in > case there is some bug in them again. > > As we are no git gurus ourself: Does anyone out there see any trouble > doing it this way? It means storing something around 7GB of > uncompressed text files in git, plus the daily changes happening to > them, then diffing them in the way described above, however the > archive will only need to go back for a couple of weeks and therefore > we should be able to apply git gc --prune (coupled with whatever way > to actually tell git that everything before $DATE can be removed) to > keep the size down. AFAIK, there can be trouble. It all depends on how you're structuring the data in git, and the size of the largest data object you will want to commit to the repository. If you want to shed data off a git repository [easily], you must not have a parent-child relationship when you want to drop the parents. There is a way around that, but it is too ugly and cubersome (store time domain series as branches, not parent-child commits). There is an alternative: git can rewrite the entire history (invalidating all commit IDs from the start pointing up to all the branch heads in the process). You can use that facility to drop old commits. Given the indented use, where you don't seem to need the commit ids to be constant across runs and you will rewrite the history of the entire repo at once and drop everything that was not rewritten, this is likely the less ugly way of doing what you want. Refer to git filter-branch. Other than that, git loads entire objects to memory to manipulate them, which AFAIK CAN cause problems in datasets with very large files (the problem is not usually the size of the repository, but rather the size of the largest object). You probably want to test your use case with several worst-case files AND a large safety margin to ensure it won't break on us anytime soon, using something to track git memory usage. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110327132911.ga31...@khazad-dum.debian.net
Re: Meeting Minutes, FTPMaster meeting March 2011
On Sun, Mar 27, 2011 at 12:27:15PM +0100, Roger Leigh wrote: > On Sun, Mar 27, 2011 at 10:56:28AM +0200, Joerg Jaspert wrote: > > - The long standing project of enabling autosigning for the buildds also > > got finished. That means that packages successfully built can now be > > uploaded automatically, without waiting for the buildd admin to wake > > up/come back from holiday/whatever. > > Fantastic news. What's the expected turnaround time between building > and having it available in incoming/the main archive? It gets moved to the upload directory directly after it has been built and signed. Every 15 minutes the buildd-uploader is run from cron. From there on, it's the same time for all uploads. After it's uploaded the queue deamon needs to process the upload to move it from the upload queue to unchecked, as far as I know this happens every 5 minutes. Then every 15 minutes unchecked gets processed and it's accepted (or rejected, moved to NEW). This unchecked processing doesn't happen while dinstall is running. Once it's accepted it's visible on incoming.debian.org, and the buildds will also have access to it. You'll have to wait for the next dinstall and mirror pushes before it's on your mirror. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110327125954.ga29...@roeckx.be
Re: Meeting Minutes, FTPMaster meeting March 2011
On 2011-03-27, Roger Leigh wrote: >> - The long standing project of enabling autosigning for the buildds also >> got finished. That means that packages successfully built can now be >> uploaded automatically, without waiting for the buildd admin to wake >> up/come back from holiday/whatever. > Fantastic news. What's the expected turnaround time between building > and having it available in incoming/the main archive? Builds will be signed automatically post-build and moved to the buildd-local upload queue, which is processed every 15 minutes. process-unchecked runs every 15 minutes, too, as far as I know, so they should be available within 30 minutes for other package builds if the package isn't insanely large. Maybe an hour at worst, if we hit the queue during dinstall. > Is there any prospect for phasing out Architecture: all packages in > binary-foo Packages in favour of binary-all Packages use by apt-get/ > aptitude? That doesn't make sense. The current set of arch:all packages in binary-foo is there for a reason. (In fact certain older arch:all binaries are held availabl/held backe in it if the new package isn't built yet for an architecture. Which is also the reason why we need binary-all after all, it's not guaranteed that we see all arch:all packages in the union of the Packages files of all architectures.) Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrniouc9c.vkj.tr...@kelgar.0x539.de
Re: Meeting Minutes, FTPMaster meeting March 2011
Hi, are there any news about leaf packages and the new field "mainpackage:"? If so, will Wheezy contain packages using this new field? Did you decide about throwing away DD built binaries? * Joerg Jaspert [2011-03-27 10:56 +0200]: > - We had some discussion about accepting ddebs into the archive but it > needs major changes to dak. We might accept them into experimental as > a first step for early testing but there is no code yet to support > this. I assume you strongly prefer implementing ddebs the way it was worked on during a Google summer of code 2009 project (which was the only sane long-term solution for Debian before throwing away uploaded binary packages was discussed) over the way Ubuntu generates ddebs since a few years. Is this correct? The related questions Emil Langrock asked in [1] are still open: | What is the direction we should follow for Wheezy[5]? Should we remove | our special -dbg packages or at least stop to create new -dbg | packages? Regards Carsten [1] http://lists.debian.org/debian-devel/2011/03/msg00376.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110327114938.ga25...@furrball.stateful.de
Re: Meeting Minutes, FTPMaster meeting March 2011
On Sun, Mar 27, 2011 at 10:56:28AM +0200, Joerg Jaspert wrote: Just wanted to say congratulations to you all for for getting so much great stuff done in such a short time, and many thanks for all your hard work; it's much appreciated! > - The long standing project of enabling autosigning for the buildds also > got finished. That means that packages successfully built can now be > uploaded automatically, without waiting for the buildd admin to wake > up/come back from holiday/whatever. Fantastic news. What's the expected turnaround time between building and having it available in incoming/the main archive? > - Added binary-all dists files. This was after discussion with buildd > people (Phil) regarding how "Architecture: all" autobuilding might be > able to work in future. We've let it go onto the main mirror network > in case other people have use for the information. The rationale is > that the arch-dependent packages files sometimes lag in their .all deb > versions in order to maintain installability of packages which are > waiting for architecture specific debs. The binary-all metadata will > always contain the latest versions of the .all packages, thus allowing > wanna-build to work out what needs doing. This is, of course, just a > first step towards being able to build .all debs on the buildds. Is there any prospect for phasing out Architecture: all packages in binary-foo Packages in favour of binary-all Packages use by apt-get/ aptitude? I would also have a use of binary-all dist in sbuild-db (an experimental wanna-build replacement using PostgreSQL 9.0), just for the record. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
