ITP symlinks -- Scan and change symbolic links
wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/symlinks/setup.hint \ http://cante.net/~jaalto/tmp/cygwin/symlinks/symlinks-1.4-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/symlinks/symlinks-1.4-1.tar.bz2 # To check packaging cd symlinks tar -xf *-src.tar.bz2 ./*.sh --color --verbose all Included in Debian: http://packages.debian.org/symlinks Jari [ setup.hint ] sdesc: Scan and change symbolic links ldesc: Scan directories for symbolic links and list them on stdout. Each link is prefixed with a classification of relative, absolute, dangling, messy, lengthy or other_fs. Symlinks can be converted from absolute links (within the same filesystem) to relative links. Delete messy and dangling links. category: Utils requires: cygwin
Re: perl_vendor
Reini Urban writes: When you start proposing your stuff I can remove these packages from perl_vendor. I've been working on extracting the dependencies automatically given a module or distribution name. The method I started off with turned out to be very slow and somewhat unreliable, so I bit the bullet and re-implemented everything using CPAN and MetaCPAN. I can't seem to manage to use only one of the two… anyway, it's started working today and it generates cygport rpm-style files with full descriptions and everything, but needs to wait for Yaakov to release the next version of cygport. It will also tell you which cygwin packages need to be updated and I hope to implement automatic editing of the cygport files later. But I still don't get the point. Now you have one dependency: perl_vendor. With your scheme you have many dependencies. Yes and that is what I wanted. With opaque bundles like perl_vendor I need an extra step of mapping what is inside each bundle and I actually need to look inside the source archive to find out, record it someplace and then feed this information seperately to the dependency generator. Note that I have nothing against transparent bundling, my local version of perl_vendor is simply an empty package that depends on all the perl distribution packages that comprise it. I have more such bundles like the statistics bundle that started this effort, another bundle for additional distributions required for building and testing (only developers will get these) and another one for some oddball stuff that doesn't fit in either category, but should be installed almost everywhere. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [ITP] doxygen-1.8.0-2 -- A documentation system for C++, C, Java, Objective-C, IDL (Corba and Microsoft flavors) and to some extent PHP, C#, and D.
On 9/29/2012 1:21 PM, David Stacey wrote: wget \ http://www.drstacey.talktalk.net/doxygen-1.8.0-2.tar.bz2 \ http://www.drstacey.talktalk.net/doxygen-1.8.0-2-src.tar.bz2 \ http://www.drstacey.talktalk.net/setup.hint \ http://www.drstacey.talktalk.net/md5.sum You should keep using -1 for subsequent build attempts until one gets RFU'd. Use new package versions only to disambiguate published package versions. The package version number is there to help setup.exe out, not to help us poor humans out. :) Nits: 1. Another build requirement change: the doxygen.README file still refers to TeTeX, which was replaced recently with TeX Live. But, installing a basic TeX setup alone isn't enough. To build the PDF manual, you need the optional texlive-collection-fontutils package for epstopdf, and texlive-collection-latexextra for float.sty. There's no need to mention any other packages. Installing those two into a stock Cygwin install will drag in enough of the remaining TeX stuff to build the manual. 2. /usr/share/doc/doxygen/latex should be removed, in favor of a .../pdf subdirectory. I don't see a reason to ship source and intermediate build files here, expecting the user to build the docs. What's wanted here is a PDF of the LaTeX *output*. 3. I'd rather see your first version be 1.8.2-1 instead. Why start with a version two bug fix releases back? Nits aside, I can't withhold a GTG recommendation, since your packages are no worse off than mine were, and those were apparently still useful to people. :) Something to pursue later, having no effect on GTG status: There's a bogus test in Doxygen's configure script, where it goes looking for dot(1) from GraphViz. It does a weak check for it in a few common locations, and yells if it isn't there. dot(1) being a filter, there isn't a huge penalty for using the native Windows version, which of course doesn't get installed in any of those locations. It would be nice to either 1) send upstream a test using the PATH instead of a hardcoded list; or 2) adopt Yaakov's GraphViz package: http://cygwin.com/ml/cygwin/2010-10/msg00232.html Option 1 is sufficient, but option 2 means you can make graphviz a dependency of your doxygen package, so everyone gets it automatically.
