Re: [140793] trunk/dports/math/svdlibc/Portfile

[David Strubbe]

Ok, thanks.

David

On Sat, Oct 3, 2015 at 7:35 AM, Ryan Schmidt 
wrote:

>
> > On Oct 2, 2015, at 2:43 PM, dstru...@macports.org wrote:
> >
> > Revision
> > 140793
> > Author
> > dstru...@macports.org
> > Date
> > 2015-10-02 12:43:15 -0700 (Fri, 02 Oct 2015)
> > Log Message
> >
> > svdlibc: Add license. Fix checksums. Add livecheck. Comment on destroot
> failure.
>
> Checksums shouldn't just change. Anytime a port's checksums seem wrong,
> you need to investigate and find out why. In this case, it's because the
> project uses an unversioned distfile, and released a new version. The port
> version still says 1.34, but you changed the checksums to those matching
> version 1.4. This port needs to follow the recipe for unversioned distfiles:
>
> https://trac.macports.org/wiki/PortfileRecipes#unversioned-distfiles
>
>
> I'll see if I can fix the port.
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [140793] trunk/dports/math/svdlibc/Portfile

[Ryan Schmidt]

> On Oct 2, 2015, at 2:43 PM, dstru...@macports.org wrote:
> 
> Revision
> 140793
> Author
> dstru...@macports.org
> Date
> 2015-10-02 12:43:15 -0700 (Fri, 02 Oct 2015)
> Log Message
> 
> svdlibc: Add license. Fix checksums. Add livecheck. Comment on destroot 
> failure.

Checksums shouldn't just change. Anytime a port's checksums seem wrong, you 
need to investigate and find out why. In this case, it's because the project 
uses an unversioned distfile, and released a new version. The port version 
still says 1.34, but you changed the checksums to those matching version 1.4. 
This port needs to follow the recipe for unversioned distfiles:

https://trac.macports.org/wiki/PortfileRecipes#unversioned-distfiles


I'll see if I can fix the port.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [140813] trunk/dports/science/OpenCoarrays/Portfile

[Bradley Giesbrecht]

> On Oct 3, 2015, at 1:21 PM, Clemens Lang  wrote:
> 
> 
> 
> - On 3 Oct, 2015, at 22:14, Clemens Lang c...@macports.org wrote:
> 
>> I don't think forcing users to participate in statistics collection like
>> this is OK with their consent, at least not according to German data
> 
> 
> I obviously meant withOUT their explicit consent, sorry for the typo.

I understood that even with mpstatl installed it was still opt-in and the user 
had to make a config change to actually report. Is my understanding incorrect?

—
Bradley Giesbrecht (pixilla)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [140813] trunk/dports/science/OpenCoarrays/Portfile

[Clemens Lang]

Hi,

- On 3 Oct, 2015, at 22:03,  pixi...@macports.org wrote:

> [140813] trunk/dports/science/OpenCoarrays/Portfile
> Revision 140813
> Author   pixi...@macports.org
> Date 2015-10-03 13:03:03 -0700 (Sat, 03 Oct 2015)
> Log Message  Add dependency on mpstats.

I don't think forcing users to participate in statistics collection like
this is OK with their consent, at least not according to German data
privacy and retention laws (and remember I'm currently hosting the
service).

Please revert this change.

-- 
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [140813] trunk/dports/science/OpenCoarrays/Portfile

[Clemens Lang]

- On 3 Oct, 2015, at 22:14, Clemens Lang c...@macports.org wrote:

> I don't think forcing users to participate in statistics collection like
> this is OK with their consent, at least not according to German data
 

I obviously meant withOUT their explicit consent, sorry for the typo.

-- 
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [140813] trunk/dports/science/OpenCoarrays/Portfile

[Clemens Lang]

- On 3 Oct, 2015, at 23:33, Bradley Giesbrecht pixi...@macports.org wrote:

> I understood that even with mpstatl installed it was still opt-in and the user
> had to make a config change to actually report. Is my understanding incorrect?

mpstats uses startupitem.autoload to automatically start statistics reporting
after installation. It sends reports on a random weekday on the hour and two
minutes after you've installed it.

See also: $> port notes mpstats:
  Installing this port automatically enables weekly reporting of data to the 
stats
  server.  Uninstall or deactivate this port if you want to stop providing data 
to
  MacPorts.

-- 
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [140813] trunk/dports/science/OpenCoarrays/Portfile

[Bradley Giesbrecht]

> On Oct 3, 2015, at 2:44 PM, Clemens Lang  wrote:
> 
> 
> 
> - On 3 Oct, 2015, at 23:33, Bradley Giesbrecht pixi...@macports.org wrote:
> 
>> I understood that even with mpstatl installed it was still opt-in and the 
>> user
>> had to make a config change to actually report. Is my understanding 
>> incorrect?
> 
> mpstats uses startupitem.autoload to automatically start statistics reporting
> after installation. It sends reports on a random weekday on the hour and two
> minutes after you've installed it.
> 
> See also: $> port notes mpstats:
>  Installing this port automatically enables weekly reporting of data to the 
> stats
>  server.  Uninstall or deactivate this port if you want to stop providing 
> data to
>  MacPorts.

Thank you Clemens for the explantation. I read the Portfile and saw the 
startupitem.autoload which was a new control to me.

My concern is that since there is consensus that we should not report without 
user intention that a mistake like mine where I did not know mpstat used 
startupitem.autoload that one cannot easily fix the issue for anyone who 
installed before the problem was fixed. They now have mpstat.

I like that mpstat uses startupitem.autoload, I think it make the port simpler 
for those that want it.

Is there a macports mechanism for declaring a port cannot be a dependent?

—
Brad
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev