Re: OS X package building environment available for testing

Ian Silvester <[email protected]> wrote:

> On 2012-02-19, at 1:30 PM, Fabian Keil wrote:
> 
> > Ian Silvester <[email protected]> wrote:
> > 
> > Ian, it occurred to me that this discussion could happen in
> > public on the mailing list. If you agree to this, please reply
> > to the list instead of in private.
> > 
> >> So I've cleaned up my build environment
> <snip>
> >> 
> >> I'm guessing that David you are in the best position to confirm that
> >> it can generate a Privoxy package correctly; Fabian please feel free
> >> to confirm that it does not violate the GPL (I am relatively sure it
> >> does not).
> > 
> > I can't. Confirming GPL compliance requires knowledge of the
> > targeted platform and the build environment and I'm not familiar
> > with Mac OS X and the software required to create the package.
> 
> Understood. The only software required outside of the module I've
> developed is the same as is required for the existing osxsetup module,
> it being PackageMaker (to build the OS X installation package file).
> This software is supplied as part of Xcode, the de facto Apple software
> development environment which, whilst not open source, is a free
> download and included on OS X distribution media.

Whether or not the download is free of charge doesn't matter,
but if everything required to build the package from the
sources provided is also included on OS X distribution media
the "special exception" of §3 should apply, so that's good to
know.

If David comes to the same conclusion, that would be good enough for me.

>                                                   I trust that this
> doesn't present any issues; the fact that it's used by an existing
> Privoxy project module should surely be enough? I recognise the
> possibility that the existing module could be out of GPL compliance, but
> how about the hundreds (thousands?) of other open source projects out
> there that have OS X binary distributions? Surely they can't all be
> wrong!
> 
> Can anyone else make a definitive statement on this? I would hate to see
> this distribution fail due to it's dependence on the fundamental piece
> of software that generates the distribution file!

That would be a shame, indeed.
 
> > I skimmed through the package, though, so I've got a couple
> > of comments:
> > 
> > 1)
> > Several files have no copyright and license information
> > at all and there doesn't seem to be an obvious default
> > license. I'm aware that some of the affected files have
> > been inherited from another package but it would be preferable
> > to fix this.
> > 
> > 2)
> > Some files contain a header like this:
> > 
> > | # Created by Ian Silvester for the Privoxy project.
> > | # See Privoxy's LICENSE file for licensing details.
> > | # With thanks to David Schmidt & Mark Miller on whose work this OS X
> > installer is based | # and to Fabain Keil for technical guidance.
> > 
> > The first line doesn't make it clear who the copyright
> > holder is. An explicit copyright line would be preferable,
> > even if it doesn't mention individuals.
> > 
> > The second line should at least mention the name of
> > the license (if it's GPLv2 or another license whose
> > text is rather long).
> > 
> > Given that your tar file already seems to contains a
> > copy of the GPLv2 it would probably preferable to reference
> > that instead of "Privoxy's LICENSE file" which may change in
> > the future.
> 
> I have inserted a new header in all files of the following format (taken
> from Privoxy's own README file). I believe that it answers all the above
> concerns:
> 
> # File        :  constructPkgContent.sh
> #
> # Purpose     :  Create the hierarchy of folders and files that will 
> #                        comprise the installation package.
> #
> # Copyright   :  Written by and Copyright (C) 2001-2012 the
> #                Privoxy team. http://www.privoxy.org/

This attribution ("the Privoxy team") isn't ideal but will do for now.
Using proper copyright attribution for Privoxy itself is already on the
TODO list as #64, so this can wait until then.

> #                Based on the Internet Junkbuster originally written
> #                by and Copyright (C) 1997 Anonymous Coders and
> #                Junkbusters Corporation.  http://www.junkbusters.com

I think the OS X package sources came long after the fork from
Internet Junkbuster, so this paragraph should be removed.

> #                This program is free software; you can redistribute it
> #                and/or modify it under the terms of the GNU General
> #                Public License as published by the Free Software
> #                Foundation; either version 2 of the License, or (at
> #                your option) any later version.
> #
> #                This program is distributed in the hope that it will
> #                be useful, but WITHOUT ANY WARRANTY; without even the
> #                implied warranty of MERCHANTABILITY or FITNESS FOR A
> #                PARTICULAR PURPOSE.  See the GNU General Public
> #                License for more details.
> #
> #                The GNU General Public License should be included with
> #                this file.  If not, you can view it at
> #                http://www.gnu.org/copyleft/gpl.html
> #                or write to the Free Software Foundation, Inc.,
> #                51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
> #                USA
> #
> # Modification : If you modify this file please consider whether the change
> #                ought to be passed back to the macsetup module.

> > Giving credits is appreciated, but putting them in
> > the README once (where my name is also spelled correctly)
> > is really sufficient if they are given for general help and
> > not actual code.
> 
> Understood - credits now restricted to README file.
> 
> > Where actual copyrighted material has been embedded from
> > another package, the copyright line should cover this (and
> > the licenses have to be compatible of course).
> 
> The macsetup package contains no copyrighting nor licensing information.
> I reached out to Mark Miller for clarification and he has emailed to say
> he's happy for me to include parts of his work and redistribute them
> under the GPLv2; in fact he was keen that his work is licensed in the
> same way as the main Privoxy project.

Great, thanks for the confirmation.

> > 5)
> > Regarding the uninstaller: is uninstalling everything including
> > possibly modified configuration files and log files the expected
> > behaviour for a Mac OS X package?
> > 
> > Given that I don't remember complaints from Mac users in the past
> > the answer may well be yes.
> 
> Hmmm, interesting point that one. The average OS X user has no concept
> of the separation between code and configuration and the location for an
> Objective-C package's configuration files would be
> ~/Library/Preferences. The uninstallation method usually understood by
> said average user is to simply drag the application to the Trash.
> Consequently the effective behaviour is to leave configuration in place
> when uninstalling, though no doubt the user's *intended* behaviour was
> to remove all trace of the application.
> 
> Regardless, I've modified the uninstall script to offer the option of
> leaving the configuration folder in place, for the benefit of what the
> Mac community would refer to as power users.

Thanks.

> >> Please let me know if you would prefer a straight diff of changes
> >> rather than git's output.
> > 
> > In general I prefer git format-patch output like this,
> > but it seems to me that long lines have been truncated
> > here.
> > 
> > In this case it would also have made sense to squash
> > the two commits into one.
> > 
> > As the manual is generated from the sgml files in
> > doc/source, changes to the HTML will be overwritten
> > the next time the docs are generated, so the source
> > files need to be updated as well.
> > 
> > As this is a change were a file in the binary package
> > differs from the source tarball (until the next release
> > which hopefully will contain your adjustments), the diff
> > for the source file should then also be either included
> > in the package or the URL referenced.
> > 
> > It's unlikely that any user cares about this, but it's
> > important from a GPL point of view.
> 
> To simplify workflow and remove this impediment to release I've reverted
> my distribution to use the documentation from the source tarball.
> 
> I'll re-submit the documentation diffs separately, correcting my
> mistakes and supplying them as source diffs rather than those for the
> resulting HTML, such that they might be included in the next release.

Okay.

> >> - I feel that the manual should reference all three modules since each
> >> has it's good points
> >> 
> >> Please let me know what the official route should be for submitting a
> >> binary back to the project and creating a release for it and also what
> >> you think about including all three modules in the documentation (or
> >> whether mine should become the sole entry!).
> > 
> > It's unlikely that we will be able to maintain three separate
> > modules in the future. Assuming yours is the only one that currently
> > works out of the box the documentation should probably concentrate
> > on that.
> > 
> > It doesn't hurt to mention the others as well (if you are willing
> > to do this), but their current state should be made obvious.
> > A list of the advantages of each package would be great, too.
> 
> On balance I think I'll include mine (OSXPackageBuilder) and macsetup
> and deprecate osxsetup. Mine entirely supersedes osxsetup in that it
> targets the same output (an OS X installer package) and is significantly
> more complete, supporting a far wider range of OS X versions. macsetup
> on the other hand has the advantage that it's target is installing to OS
> X direct from the source code rather than building a distribution. I'll
> make that clear in the documentation.

Sounds good to me.

> Back to the business at hand. I've placed updated OS X packages and a
> tar of the OSXPackageBuilder in the same locations as before, respecting
> all the changes referred to in this email (excepting the documentation
> changes of course). If these items now pass muster, please upload the
> two packages to Sourceforge and make releases for them (or give me the
> rights to do so) and check the OSXPackageBuilder module into CVS. Let's
> get this out there!

I haven't checked the updated tar file but it seems like
you addressed all my comments. Thanks.

David, do you think the package is ready for release?

Fabian

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/

_______________________________________________
Ijbswa-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ijbswa-developers

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iEYEARECAAYFAk9FSAYACgkQSMVSH78upWNa/gCcDSpz/u+xxa2sO+NM9BuLScco
KDcAni3RBzRhFNnplpTJYsyD6hILD8tz
=Htpz
-----END PGP SIGNATURE-----