Bug#792624: multiarch = same and different date-entries in generated man page of i32/i64
Roelof Berg rb...@berg-solutions.de writes: I had a look at the idea of writing manpages manually (as upstream) and unfortunately saw some difficulties: Because OpenBSD and Linux use different *roff syntax, man vs. mdoc, if I understodd it correctly, generating the man pages in the syntax of the actual operating system would be the most portable way (everyone: correct me if I'm wrong). I don't want to favor Linux or BSD or Windows (just kidding :) in the source tarball. Many people use some higher-level / more-recent markup language like rst, markdown, or POD. This adds another build-dependency, but means that it's the responsibility of translator (e.g. rst2man, pod2man) to generate appropriate roff. d -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792624: multiarch = same and different date-entries in generated man page of i32/i64
Understood, I put this on my release backlog. Esp. getting rid of doxygen which is clumsy in automake would be great (and isn't justified for a small plain C API). For the current version I will, however, just add some small bugfix inside the .../debian folder. Thanks ! On 11.08.2015 10:21, David Bremner wrote: Many people use some [...] markup language like rst, markdown, or POD [...] rst2man, pod2man [...] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#792624: multiarch = same and different date-entries in generated man page of i32/i64
I had a look at the idea of writing manpages manually (as upstream) and unfortunately saw some difficulties: Because OpenBSD and Linux use different *roff syntax, man vs. mdoc, if I understodd it correctly, generating the man pages in the syntax of the actual operating system would be the most portable way (everyone: correct me if I'm wrong). I don't want to favor Linux or BSD or Windows (just kidding :) in the source tarball. Defining SOURCE_DATE_EPOCH and using the latest help2man version did _not_ fix the date on my system. Even worse: I'm also using doxygen for the man page of the library, which isn't capable of using SOURCE_DATE_EPOCH anyway. So SOURCE_DATE_EPOCH doesn't seem to be the right direction for me. I'm thinking of rude stuff now: Patching the manpages after generation with my own script, taking the date based on dpkg-parsechangelog as input. Maybe it's possible with SED. I can't be the first one facing this issues, right ? Thanks for the excellent feedback so far. Roelof -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
