Hi Marc, seems this bug is franzing out a little bit ;).
On Mi, 2015-07-01 at 18:08 +0200, Marc Haber wrote: > On Sat, Jun 27, 2015 at 05:21:24PM +0200, Stephan Sürken wrote: > > The Quickstart however now comes with a hint how to set up a ssh > > wrapper. > > That's a rather bad hack ;-) referring to the log/grep/key thingy, who could agree more ;). (...) Btw, I usually use something along the line > > command="/usr/share/doc/mini-buildd/examples/ssh-uploader-command KEYID" > ssh-rsa AA... Sure. this looks way better. Afai remember, it was not in the cards for the 'authorized_keys-Distributors' (that triggered that wrapper in the first place) do so. Just squeeze the example or rewrite to fit for your needs ;). > Wouldn't it be a nicer idea to have mini-buildd take out an inotify on > a new *.changes file in the incoming directory? That way, it could act > on anything appearing in the directory. Well, in short: no. It was a design decision to use (py)ftpd as internal and only way to act on incoming as it gives us 1. a canonical, "always there" actual (networked) upload mechanism. * Note, for example, that this is also used for the repo<->builder communication by exchanging special "buildrequest" and "buildresult" changes. 2. a very easy and effective way to guard against (most) race conditions/user upload errors (double uploads, file overwrites, etc). In a nutshell, "inotify"-based setup gives us more freedom, but none of the two. So, at least for 1.0.x (and most likely 1.2.x) wrapping around the canonical ftp is the only way to provide other "upload channels". Fwiw, i am considering to "officially" support a ssh wrapper via the Debian package -- so it might come with 1.2.x. But then again, I did not even have the time to kick 1.2.x deveopment off yet ;). Hth! S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
