Just to report that unison 2.45.4 is happily working for me using a minimally updated info file, and it just built fine on 10.7 as well. I needed to have 2.40.63 coexisting on my server, so I hacked that info file to install as unison24063 instead of plain "unison". Still no Aqua GUI, but I only use the X11 GUI so that isn't a problem for me.
While installing unison's deps, lablgtk2 and docbook-utils threw wobblies but installed fine when I tried again. So they could be sensitive to the number of BuildJobs? I was using 4. cheers, -- Viv On Mon, 24 Oct 2011, Viv Kendon wrote: > Hanspeter and Alexander, > > many thanks for following this up and testing. > > On Sun, 23 Oct 2011, Hanspeter Niederstrasser wrote: > >> On 10/23/2011 5:14 PM, Alexander Hansen wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 10/23/11 4:22 PM, Hanspeter Niederstrasser wrote: >>>> On 10/14/2011 6:58 PM, Viv Kendon wrote: >>>>> There have been some mac-friendly bug fixes to unison, and the >>>>> current version compiles and installs (non-Aqua) just fine for me >>>>> on 10.6.8 (I can't test any other OS versions). >>>> >>>> The version included in that email built fine for me on 10.5/i386 >>>> (both -nox and .) although the .info failed to pass validation (the >>>> added indentation in DescDetail pushes the lines past 79 >>>> characters). As mentioned by Alexander, it will also need >>>> "UseMaxBuildJobs: false" to force a single processor. Can the >>>> dependencies be modernized? For example to libpng15 and >>>> libgettext8(-dev,-shlibs)? > > I changed libgettext to 8 and libpng to 15 as you suggested, fixed the > line-wrapping, and added UseMaxBuildJobs: false. It built fine on 10.6.8, and > worked fine against 2.40.1 as well as itself (having recently built 2.40.63 > on a couple of linux systems, I know it is fairly robust in variation of its > dependencies). Revision 2 info file attached. > >>>> Also, the previous version of unison in Fink included 4 unison >>>> releases (supposedly for backwards compatibility with unison >>>> servers). This package version includes only the latest release. >>>> That's obviously much easier to maintain, but will there be any >>>> real loss in functionality in losing the older versions? I don't >>>> use unison, so have no idea how it functions or how widespread the >>>> older releases are in use. >>>> >>> Unison can only sync between the same major.minor version, e.g. >>> 2.40.63 can only sync with any 2.40.x, and no other 2.y.z . That's >>> what motivated the multi-version install. >>> >>> It's probably worth looking at what is available in contemporary Linux >>> distributions, Macports, Cygwin, ... and what the current install >>> options are for prebuilt binaries for Windows or Mac OS X. >> >> MacPorts only has 2.32.52 near as I can tell. Cygwin has 2.27, 2.32, >> and 2.40 as individual packages (example FS layout for 2.40 [1]). Debian >> seems to have 2.13, 2.27, and 2.32 as separate packages as well. The >> official unofficial binaries seem to be single version [2]. >> >> [1] http://cygwin.com/packages/unison2.40/unison2.40-2.40.16-2 >> [2] http://alan.petitepomme.net/unison/index.html >> >> Would having the different versions as separate packages work >> (unisonX.YY), with a splitoff 'unison' that sets the %p/bin/unison-[%ui] >> --> unison-%v-[%ui] work? This should make all the versions available, >> with the latest version having precedence for the unversioned binary >> (firefox(%v=3-8) works like this)? > > You may want to note this from the user manual: > http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#running > > addversionno > When this flag is set to true, Unison will use > unison-currentversionnumber instead of just unison as the remote server > command. This allows multiple binaries for different versions of unison to > coexist conveniently on the same server: whichever version is run on the > client, the same version will be selected on the server. > > So multiple versions seems like the right way to go, and they can happily > coexist. > > The reason why having the latest version 2.40.63 is good for Macs is that it > supports case sensitive and the specific Mac flavour of case insensitive > properly (using the ignorecase true/false parameter), and it supports unicode > filenames (both these need > 2.40.16 for recent bug fixes). > > I have "used to work" info files for 2.27.57, 2.32.52, 2.40.1 and 2.40.16 as > well as the attached. I don't think the Aqua interface is important. IIRC > the last working incarnation of it (2.27.57??) was pretty unstable (easy to > crash), while the X11 interface seems to be solid. With X11 included as > standard in OSX now, it should at least work reliably, even if people don't > think it is "pretty". If someone is willing to put in the work, of course it > would be nice, but it will need more than tweaking info files and testing. > > Let me know if there is anything else I can help to test. > > many thanks, > -- Viv > ________________________________________________ > Dr Viv Kendon http://quantum.leeds.ac.uk/~viv > tel: +44 113 343 4864 Physics and Astronomy > Quantum Information Group University of Leeds ________________________________________________ Dr Viv Kendon http://quantum.leeds.ac.uk/~viv tel: +44 113 343 4864 Physics and Astronomy Quantum Information Group University of Leeds ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Fink-users mailing list [email protected] List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
