Hi, subject says all. It would be nice if the documents in /usr/share/doc/topgit/ would be turned into proper man pages. Cheers, Michael
tags 499071 confirmed help thanks also sprach Michael Biebl <biebl@debian.org> [2008.09.16.0026 +0100]: Agreed. It would be nice if someone sent a patch. :) (I don't see myself having the time in the next few weeks).
Do you know whether upstream would be willing to maintain the doc in the future in formats other that .txt files? Don't worry I'm not thinking neither at docbook-xml, nor at *roff :) ... still, I'm willing to do the initial step of converting them into, say, POD, which is quite close to text but permits to generate the manpage structure. Still, that would be pointless (and I wont do that) unless upstream is willing to stay stick with that format, whatever it will be. Let me know, Cheers.
also sprach Stefano Zacchiroli <zack@debian.org> [2008.11.01.0036 +0100]: Petr, could you please answer this?
The documentation was written to loosely adhere the asciidoc syntax, but I never actually tried to process it with asciidoc so there will be surely some syntax errors there. Patches to make it conforming to asciidoc would be welcome. I'm not particularly opposed to other similar formats either, but asciidoc is generally the documentation format of choice for git-related tools and I'm already familiar with it.
Hi Petr, thanks for the feedback. In fact, I was not aware of asciidoc, but from what I've just read apparently it is suitable also to generate manpages. I'll look into that then, thanks! Cheers.
Hi, Looking for man pages to write for my NM process, I found this bug report. I do not think I master both git and topgit, but I would be glad to help a bit. I gave a try to asciidoc, and here is an example of a man page for tg-delete. http://dthconnex.com/topgit/tg-delete.8.txt then: $ a2x -f manpage tg-delete.8.txt give me: http://dthconnex.com/topgit/tg-delete.8 Any thought? Regards,
Yay \o/ Well ... amazing :-), thanks. Still, a proper "fix" for this bug would also require integrating the conversion work in the topgit package build process. I guess the author would like to keep the .txt files where they actually are and convert them to manpages when installing stuff that then gets shipped in the package. If you can provide such a patch I'll be happy to integrate it in the packaging. Cheers.
[...] Ok, so I will put everything in the README file, and submit a patch against the debian directory in order to update the build process to create the manpages. Regards,
Hi, I have done some work on the manpages, you can find a patch against the debian branch: http://www.dthconnex.com/topgit/manpages.diff The final patch should be split in two : a debian part and an upstream part. I have not finished yet, but I post it so you can see what it looks like at the moment. Any comments from upstream? (and others :p!) Regards,
Hello Franck, note I didn't test your patch, only read through. I didn't even read the prose part. I assume you only changed the formating!? hhhm. I didn't start with using Build-Depends:, but as topgit is an arch=all package, I wonder if most if not all dependencies should be Build-Depends-Indep:. Martin? Does the package still build after $ touch tg-astillundocumentedcommand.sh ? What about autogenerating this file? Best regards and thanks for your efforts Uwe
Uwe Kleine-König wrote: Hi, I must admit I have updated some sentences to fit into the manapges and then a full review is necessary before publishing it. In addition, I have put all the manpages at the end of the README file, and added a small description to the list of commands where they were enumerated with their long description in a first place. As a matter of fact, according to policy 7.7 http://www.debian.org/doc/debian-policy/ch-relationships.html#s-sourcebinarydeps [quote] Build-Depends, Build-Conflicts The Build-Depends and Build-Conflicts fields must be satisfied when any of the following targets is invoked: build, clean, binary, binary-arch, build-arch, build-indep and binary-indep. [/quote] and debhelper is used at least in the clean target. So, that should be fine. (Same argument for quilt) You are right, it fails. It sounds a bit strange to me to generate debhelper files automatically, but why not :) I am not worrying about patching the debian directory, since I think the manpages could be added upstream and generated from the main Makefile. I mean, the manpages are not Debian specific. Anyway, I will fix the mistake you found in debian/rules, and continue to create the tg manpage. You're welcome, Regards,
Most of debhelpers support globbing in their configuration files. As long as you generate all manpages in predictable places, a *.1 should do the trick without adding the burden of autogeneration. Disclaimer: I haven't tried if dh_installmanpages actually supports globbing or not, but is worth trying/checking. Cheers.
Hello, Note that dh_installmanpages is the "old-style man page installer". This is a DWIM-style program, with an interface unlike the rest of debhelper. It is deprecated, and you are encouraged to use dh_installman(1) instead. (From dh_installmanpages(1)) Best regards Uwe
^^^^^^^^^^^^^
I meant the new style installer.
/me has always been bothered by those tool rename and would have
preferred a sharp semantics change from one compatibility level to
another.
Stefano Zacchiroli wrote: I have always used dh_installman so far, and not dh_installmanpages. I remembered they were two debhelpers to handle the man pages, but the wrong one caught my attention first :) Patches are enclosed. I have left the txt files in /usr/share/doc/topgit/ since it looks like they are used by tg in a *help mode*. I also wonder if this is still useful to keep the README file in /usr/share/doc/topgit, since it contains only the manpages and nothing more at the moment. Regards,
Just a little wish ;)
Hi, What about this whishlist bug? It there any chance to get it added upstream? Regards,
Hi Franck; Thanks very much for your efforts towards getting topgit manpages. I wanted to sign-off your patch as only changing formatting, but unfortunately it doesn't apply to the the current version at http://repo.or.cz/w/topgit.git or the (extremely similar) one in collab-maint on alioth. In particular hunk 4 doesn't apply. It might be easier to review if it was broken up into a few smaller patches. I did notice a few whitespace only changes; if those are not needed to make asciidoc work then my (purely personal) opinion would be to leave them out, or at least make them seperate patches tidying things up later. If find it more convenient (and assuming your are willing to work on this more :) ) you could also make a branch in the collab-maint repo. All the best, David
Hi, Ok, I will check that next week. Regards,
User: soc-coordination@lists.alioth.debian.org Usertags: gci10 Package: topgit Version: 0.8-1.1 Note, the .ronn files need to be compiled with ronn, which is not in debian
Without having looked at the patch, this sounds awkward from a Debian policy point of view. We need to be able to build all documentation from source using tools in Debian main. I guess we could just consider the nroff as source from here on in and edit that directly. Will you be packaging ronn for debian (or at least filing a request for package bug)? All the best, David
Dear Customer, We could not deliver your item. Please, download Delivery Label attached to this email. Warm regards, Matthew Hines, FedEx Station Manager.
Dear Customer, Your parcel has arrived at October 13. Courier was unable to deliver the parcel to you. You can review complete details of your order in the find attached. Kind regards, Joshua Cannon, FedEx Station Agent.
Dear Customer, We could not deliver your item. Please, open email attachment to print shipment label. Yours sincerely, Alan Hood, Station Manager.
Dear Customer, We could not deliver your item. Shipment Label is attached to this email. Kind regards, Bruce Locke, FedEx Operation Manager.
Dear Customer, Your parcel has arrived at October 24. Courier was unable to deliver the parcel to you. Shipment Label is attached to email. Yours trully, Tom Joseph, Sr. Support Manager.
Dear Customer, This is to confirm that one or more of your parcels has been shipped. Please, open email attachment to print shipment label. Kind regards, Stephen Campbell, Support Agent.
Dear Customer, We could not deliver your item. Shipment Label is attached to this email. Thank you for choosing FedEx, David Gould, FedEx Station Agent.
Dear Customer, This is to confirm that one or more of your parcels has been shipped. Shipment Label is attached to email. Thanks and best regards, Wade Landry, Sr. Support Agent.
Dear Customer, We could not deliver your item. Delivery Label is attached to this email. Yours faithfully, Morris Harrison, FedEx Operation Agent.
Hello, Courier was unable to deliver the parcel to you. Delivery Label is attached to this email. Geri Schatzberg - Area Manager FedEx , CA Regards
Hello, Your parcel has arrived at 25.11.2016. Courier was unable to deliver the parcel to you. Please, open email attachment to print shipment label. Eilis Wake - Area Manager FedEx , CA Yours faithfully.
Hello Have a nice day. Does your company needs customized packaging boxes&bags recently? We are Chinese supplier who can produce customized packaging boxes & bags with custom logo. Any of your reply will be appreciated. Looking forward to your reply. Best regards, Slite Email: slite@slcpackage.com SLC-PACKAGE CO. LTD <http://tracking.slca.info/tracking/click?d=nymz5X4yY3UF-2tZmNHYFE9iBQTRdfVKK59ZdU139tSTQ-_yxA9umvp4-rB2tlvSjIM4fqurhXDwEBUEgdjM_d0Qxur-ZnhUbZjJHAKabIu77NDhJ-ehQnJcBfrziwjzW4bDALPXpsr0f_HlNUAY1ts1> www.slcpackages.com Always Serve you by HeartContact Person: Slite CaoWhat's App: 008615314679598Wechat: 008618159815925 If you no longer wish to receive mail from us, you can <http://tracking.slca.info/tracking/unsubscribe?d=YUgWq4kEVKgfkLCKW3Jk1nKcL-jte_tO3tCuk6-2fXDPyGi2H2yXSNznS6nnXLLf_NNJWkAwHehuhU72qIQYBdEFtdmeLAFeqfCvLEMW9ozn0> Unsubscribe