[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 1.17.21 on OS X

Hi Guillem,

It's not as perfect as having access to actual physical or full virtual
machines, and it seems to mandate using Github which is a pain for some,
but Travis is fairly useful for cross-platform testing. Travis can
handle multiple Linux Distros and offer comprehensive OS X support, It
may or may not be useful for you:



Sent from OS X. If you wish to communicate more securely my PGP Public
Key is 0x872524db9d74326c.

On 12/11/2014 00:32, Guillem Jover wrote:
> Hi!
> On Tue, 2014-11-11 at 23:12:48 +0000, Dominyk Tiller wrote:
>> I'm trying to compile the latest dpkg, 1.17.21 on OS X, but keep running
>> into this persistent error. It could be expected given the relative
>> newness of this release, but thought I'd kick the configure process
>> upstream for a better insight.
> Yes, this is a problem in the code that I've fixed now locally, will
> be included in 1.17.22. I try to support other Unices that I don't have
> access to, from documentation, but that has this kind of risk. :)
> I've looked for free access from time to time to porter boxes or
> automated build systems for at least:
>   Mac OS X
>   Solaris, OpenSolaris, etc
>   AIX
>   HP-UX
> to at least make sure the thing still builds, but ideally to not port
> blindly. I'd appreciate information if someone knows about such
> access.
> (And actually also for OpenBSD, NetBSD and DragonFlyBSD systems, as I
> don't have space for so many VMs locally.)
>> Using a patch to fix the Perl location on OS X, and the MD5/SHA1/SHA256
>> tool use, but nothing that should halt or interfere drastically with
>> compile as far as I can see. The error seems to be unrelated.
>> Shall attach the build process and the patch, both of which are
>> hopefully some use.
> Thanks for both. I was aware of some of the things that need to be
> fixed from the BSD port collections, the Fink project, OpenSolaris
> ports, etc, which I regularly scan, but did not have time yet to
> integrate fixes in a generic way; I'd like to do that for 1.18.x, so
> that a pristine dpkg can be used on other systems out of the box. But
> this usually requires others to test stuff and report back which gets
> the iterations cycles a bit long. For example there's a reported test
> suite failure on Fink that I'd like to fix, but having access to such
> a system would make things much easier.
> Thanks,
> Guillem

Reply to: