Re: manpages.debian.org has been modernized!
Michael Stapelberg writes ("Re: manpages.debian.org has been modernized!"):
> On Thu, Jan 19, 2017 at 4:46 PM, Ian Jackson
> > AFAICT this program is not packaged for Debian.
>
> The program is packaged for Debian:
> https://packages.debian.org/stretch/mandoc. I have uploaded a backport
> which is currently pending in NEW.
Oh it's mandoc. OK, sorry for misreading the web page.
Are you using the backport on the manpages.d.o server, then ?
> > (Are you using a version of mdocml running out of a git tree, or
> > what? Are there other unpackaged dependencies?)
>
> I am using a slightly patched version indeed. The patch will be sent
> upstream within the next few days.
The source for this patched version is in only available in NEW ?
(Ie only to DDs ?)
You see, I find this kind of chasing tiresome - whether I'm the user,
or the service operator. I expect you do too. Of course you're
probably hoping not to need to patch mandoc again.
How did you deploy the patched mandoc ? I want to know this so I can
know how the source code can be automatically found and published.
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.
Re: manpages.debian.org has been modernized!
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=0=0=Debian+8+jessie=html=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.
Re: manpages.debian.org has been modernized!
Michael Stapelberg writes ("Re: manpages.debian.org has been modernized!"):
> On Thu, Jan 19, 2017 at 4:41 AM, Paul Wise <p...@debian.org> wrote:
> > The manual page converter seems to use line breaks rather than proper
> > paragraph tags.
>
> Could you report this issue upstream at http://mdocml.bsd.lv/ please?
AFAICT this program is not packaged for Debian.
I would like the actually-running source code for this too to be
distributed by manpages.debian.org. Would you accept a patch to do
that ?
(Are you using a version of mdocml running out of a git tree, or
what? Are there other unpackaged dependencies?)
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.
Re: manpages.debian.org has been modernized!
Michael Stapelberg writes ("Re: manpages.debian.org has been modernized!"):
> On Wed, Jan 18, 2017 at 11:37 PM, Ian Jackson
> > Also, I think the exact running version of Debian services should be
> > publicly available. And, unless this is made so easy that the service
> > operators don't have to think about it, it will always fall behind.
> > So I think this should be done automatically.
>
> All pages on manpages.debian.org already include the git revision at
> the bottom of the page, e.g.:
>
> debiman c17f615, see github.com/Debian/debiman
mariner:~> curl -s
'https://manpages.debian.org/cgi-bin/man.cgi?query=make=0=0=Debian+8+jessie=html=en'
| grep debiman
mariner:~>
> Hence, you can already check out the exact running version. Is that
> not sufficient?
I'm afraid not (even supposing that the lack of the commitid is just a
bug). For a debian.org service, I would like to be able to check out
the running version without interacting with a proprietary online
service.
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 ?
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.
> > If we created a pseudopackage in the Debian bug system, would you use
> > it instead ? It's one thing to use github as a generic git hosting
> > server but I really don't want us to be constructing our issue tracker
> > data in github's databases.
>
> I personally find the Debian bug system very uncomfortable to use. I
> will begrudgingly accept reports made via the BTS, as I do for the
> Debian packages I maintain. I don’t want to give up using GitHub’s
> issue tracker, though, for my convenience and the convenience of our
> users.
Using github as well is up to you. I won't try to talk you out of it.
But I think for a service in the .debian.org namespace, bugs should be
reportable without interacting with a proprietary web service.
So thank you for agreeing to work with a system you don't find
comfortable. You'll see that I have filed a bug against b.d.o
requesting the manpages.debian.org pseudopackage.
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.
Bug#851885: Please add pseudopackage `manpages.debian.org'
Package: bugs.debian.org Please add a pseudopackage for manpages.debian.org. Its operator writes, Michael Stapelberg, writes: > > [Michael:] > [Ian Jackson:] > > > We’d love to hear your feedback and thoughts. Either contact us > > > via an issue on https://github.com/Debian/debiman/issues/, or > > > send an email to the debian-doc mailing list (see > > > https://lists.debian.org/debian-doc/). > > > > If we created a pseudopackage in the Debian bug system, would you use > > it instead ? It's one thing to use github as a generic git hosting > > server but I really don't want us to be constructing our issue tracker > > data in github's databases. > > I personally find the Debian bug system very uncomfortable to use. I > will begrudgingly accept reports made via the BTS, as I do for the > Debian packages I maintain. I don’t want to give up using GitHub’s > issue tracker, though, for my convenience and the convenience of our > users. Based on that I think the email for the pseudopackage should go to debian-doc@l.d.o. Michael, please let us know if that's not right. 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.
Re: manpages.debian.org has been modernized!
Michael Stapelberg writes ("manpages.debian.org has been modernized!"):
> https://manpages.debian.org has been modernized!
Awesome! Thanks to everyone.
> https://github.com/Debian/debiman. In case you would like to use it to
> run a similar manpage repository (or convert your existing manpage
> repository to it), we’d love to help you out; just send an email to
> stapelberg AT debian DOT org.
As you might expect, I'm uncomfortable about the use of the
proprietary github service for this. I realise that we don't
necessarily have entirely comparable alternatives, but Free Software
needs free tools.[1]
Also, I think the exact running version of Debian services should be
publicly available. And, unless this is made so easy that the service
operators don't have to think about it, it will always fall behind.
So I think this should be done automatically.
Would you accept a patch to make debiman copy its own source code,
including git history, to its output ? Then there could be a `source
code for this manpage generator' link on each page, or maybe in the
information page. I have done this for a few programs I have written
and it's surprisingly easy. When it's done, you will always be
publishing your own up to date source code.
Speaking of the information page, if you click on the info links you
get this
https://manpages.debian.org/cgi-bin/man.cgi?query=info.html
which seems out of date.
> We’d love to hear your feedback and thoughts. Either contact us via an
> issue on https://github.com/Debian/debiman/issues/, or send an email
> to the debian-doc mailing list (see
> https://lists.debian.org/debian-doc/).
If we created a pseudopackage in the Debian bug system, would you use
it instead ? It's one thing to use github as a generic git hosting
server but I really don't want us to be constructing our issue tracker
data in github's databases.
Regards,
Ian.
[1] https://mako.cc/writing/hill-free_tools.html
As true now as it was in 2010.
--
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.
Bug#337779: lilo postinst should (offer to) run lilo like it used to
The postinst for the lilo package used to offer to run lilo. Because it didn't, my colo system had a broken bootloader halfway through my own upgrade from woody to sarge. I normally run lilo myself anyway just to be sure but the system crashed due to a kernel bug triggered by another part of the upgrade before I got around to it; as a result I had to make a 5-hour round trip to the colo to fix the machine. I don't think you can make a bug go away by documenting it in the release notes ! Ian. (I don't use distribution kernels and the kernel hadn't changed; the only thing that broke lilo was that the package second stage had been overwritten.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debiandoc-sgml vs. docbook
NB that I have moved this discussion from debian-policy to debian-doc. Havoc Pennington writes (Re: debiandoc-sgml vs. docbook): On 23 Nov 1998, Michael Alan Dorman wrote: ... Furthermore, based on statements Ian made at the time of its introduction, it's big benefit was that it gave better postscript output. Of course, to this end, it uses lout, which, when I was working on the early days of the alpha port 18 months ago, had no active maintainer. In fact, glancing at the changelog, I see that it *still* has no active maintainer, and hasn't been touched in more than a year. Err, perhaps I need to do something about Lout. Yes, I can see from the bugs pages that I do. One of the reasons it's not a very recently-updated package is because the upstream package is reasonably stable and the packaging reasonably straightforward. I see that it's not been quite so stable since I left it for a bit ... Yeah, the lout output was yucky. It has LaTeX now. It also has texinfo, which DocBook still lacks. What did you not like about the debiandoc Lout PostScript output ? At this time, the main disadvantage of DebianDoc is that it lacks some features, like indexing and (I think?) including figures/graphics. I think it is planned to implement them though. I think figures would be good too. Ian.
debiandoc-sgml table support
I have got bogged down in my attempts to add table support to
debiandoc-sgml. Not because the code is hard (it's not), but because
I have fundamental problems with some of the aspects of the
reorganisation that has been made.
For example, the replacement of the
sgml('TAG', sub {
# ... code ...
});
with
sub start_tag {
# ... code ...
}
# ... and much later ...
sgml('TAG', \start_tag);
has created a completely unnecessary level of indirection which will
also have to be kept in step.
I am not willing to try to add code to this. After modifying the DTD,
manual, and Lout backend file, I wanted to run an initial test, but it
quickly became clear that my efforts to make my old source code work
with the new arrangements of the Debian SGML subsystem were a waste of
time, and mixtures of old and new code were even less viable.
I also have a problem with the reduction in code density caused by the
introduction of numerous `horizontal bar' comments and extra
whitespace, which makes it very hard to see some of the overall
structure and limits how much code will fit on my monitor.
Although I think that this latter is a matter of preference about
which people might reasonably disagree, I still maintain that the
degree of changes which have been made do not warrant the amount of
reformatting that has been done. I am upset because feel that I have
been `disenfranchised' - the facility with which I can maintain my own
code has been greatly reduced.
I'm also concerned that complete rearrangement of the code has made it
very difficult to identify what has actually changed between old and
new versions.
I'd like to hear from the current registered maintainer (I believe
this is Ardo van Rangelrooij [EMAIL PROTECTED]) on the
matter of these changes and any other reorganisations. In particular,
I'd like to ask them:
(a) Did you make the changes with which I'm now disagreeing ?
(b) Do you plan to continue to maintain the current situation despite
my comments ?
(c) Do you think that I as the original author have any special
authority with respect to the code ?
Thanks,
Ian.
