Michael Stapelberg writes ("Re: manpages.debian.org has been modernized!"): > On Thu, Jan 19, 2017 at 4:43 PM, Ian Jackson > <ijack...@chiark.greenend.org.uk> wrote: > > mariner:~> curl -s > > 'https://manpages.debian.org/cgi-bin/man.cgi?query=make&apropos=0&sektion=0&manpath=Debian+8+jessie&format=html&locale=en' > > | grep debiman > > mariner:~> > > You’re querying the old software of manpages.debian.org which will be > turned down soon.
I got that page as follows: Type into my browser address bar https://manpages.debian.org/ This redirects to https://manpages.debian.org/cgi-bin/man.cgi and then if I type in details I get a url like the above. Hrm. I just looked with HEAD(1) and I don't get the redirect. Is it possible that there was previously a permanent redirect issued from the toplevel URL to this cgi-bin one ? I'm not sure how to bypass such a thing. > > Also, what stops (answer might be workflow, technology, whatever) an > > operator who is in a hurry directly updating the running copy without > > pushing to github ? > > People with the appropriate UNIX permissions (being part of the > “manpages” group) can of course always circumvent any workflow or > safe-guards which are put into place. Of course. But the question is: is circumventing this ever the easiest way to fix things ? My experience of running online services is that in a crisis it can sometimes be most convenient (fastest!) to use some kind of ad-hoc deployment method, up to and including editing the running code directly in a text editor. Obviously there are risks to that kind of thing, but I want the service operator to think about keeping the service running, and *not* to have to worry about publishing source code. > > As I say, I don't want to impose more work on you because of my outre' > > ethical views. I would like to solve this problem by providing a > > patch that causes debiman to copy its source and its git history to > > its own output. That way you would have to do nothing. > > To help me understand the implications of such a patch, can you point > me to an existing implementation of such a patch in another service > please? dgit client https://browse.dgit.debian.org/dgit.git/tree/dgit#n6316 (Currently broken in sid's dgit, 3.6, *sigh*, #851906) server side https://browse.dgit.debian.org/dgit.git/tree/infra/dgit-ssh-dispatch#n167 docs, search for `clone-dgit-repos-server' https://manpages.debian.org/testing/dgit/dgit.1.en.html clone the server side for yourself git+ssh://d...@push.dgit.debian.org/dgit/debian/repos/_dgit-repos-server.git NB this is the source to the special git server that `dgit push' talks to; browse.dgit.d.o is simply git repos published using cgit. yarrg (yes, really, I have been known to play proprietary online games, for which this is a fully Free helper service): intro docs for developers http://yarrg.chiark.net/devel source code http://www.chiark.greenend.org.uk/ucgi/~yarrgweb/git?p=ypp-sc-tools.web-live.git;a=blob;f=yarrg/web/source.tar.gz;h=0e47a83e38d755720427b9c453db6bed6cf33288;hb=HEAD http://www.chiark.greenend.org.uk/ucgi/~yarrgweb/git?p=ypp-sc-tools.web-live.git;a=blob;f=yarrg/Commods.pm;h=5d0ffe29fd46b8dd7b06802655b84d132ec9f100;hb=HEAD#l493 Thanks, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.