Re: OS X package building environment available for testing

Thanks Fabian,

I've removed the paragraph referring to Internet Junkbuster from all file headers and re-upped the package building module and two OS X install packages.

David it's down to you now!


Many thanks,

Ian


On 2012-02-22, at 2:54 PM, Fabian Keil wrote:

> 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


------------------------------------------------------------------------------
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/