On 12/02/2009 04:41 PM, Florian Weimer wrote: > I don't want to maintain packages in non-free. But apart from that, > I think it's fine.
I don't really either, but i think i'm willing to compromise on this one, because i'd like to collaborate with other debian users with these tools, and they seem to be moving fast enough that the older versions aren't terribly useful. > There's a repository below <http://git.enyo.de/fw/debian/>, but I > think I botched my local copy, and actually uploaded the current > version without comitting everything. I might have fixed that now, > but there are no guarantees that the version in the Git repository is > actually the official one. Sorry about that. 8-( hrm, doesn't want to pull for me: 0 d...@pip:~/src/xml2rfc/x$ git clone http://git.enyo.de/fw/debian/xml2rfc.git/ Initialized empty Git repository in /home/dkg/src/xml2rfc/x/xml2rfc/.git/ warning: remote HEAD refers to nonexistent ref, unable to checkout. 0 d...@pip:~/src/xml2rfc/x$ no worries, though. i think i've got enough information now to start something up from scratch. i just got in touch with Marshall Rose also, to see how i can best work with the > Some of the example RFCs are non-free under Debian's policy. Some > parts of contrib were not DFSG-compliant, either, and if there were > parts that were free software, I simply missed them. ok, sounds reasonable. > I asked on the tlp-interest list first, but that didn't lead to action > from the IETF, as far as I can tell. I'm now following the official > procedure, as outlined in the TLP document. OK, please let me know if you hear anything from those channels. I'd be happy to move the package back to main if we can get licensing assurance. > Yes, non-free seems to be the easiest option. ok. should i just package 1.34, take it over, and move it to non-free for the time being then? That'd save you having to orphan it ;) (if you want me to do this, please say so in a signed e-mail. i don't want to do a package hijack without some level of cryptographic assurance that the original maintainer really wants me to) > Other possible improvements for the packge: xml2rfc phones home, this > should be patched out. I think i agree with you in principle about the version checking/nagging, but i'm not sure we can make it stop all network access. For example, xml2rfc builds human-readable tables of references based only on the number of the referenced RFCs. it's gotta pull that data from somewhere: it hits the web for it. If it's already doing that, i'm not sure that hitting the web for a version update check is so terrible. Maybe it should just be a separate option, though, like "xml2rfc --check-for-updates". (the web searches it does do could probably be better optimized with som kind of pipelining, and it would also be good to be able to do some sort of cryptographic verification of the returned data, though that'd be dependent on xml.resource.org providing some sort of signature, i guess, or to use TLS on that vhost in addition to the tools.ietf.org vhost on the same machine) > The XSLT file could be integrated into > Debian's XML toolchain, I think, but I'm not sure how to do this hm, maybe rfc2629xslt should be shipped as a separate package, since it appears to have a separate author and separate upstream development: http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html > (I had some trouble integrating the DTD, but it should work now). It looks like it to me, but i'm not sure how to test whether that integration is successful (i'm afraid i don't know much about working with DTDs). --dkg
signature.asc
Description: OpenPGP digital signature
