Re: [144262] trunk/dports/lang/py-htmldocs/Portfile

[Russell Jones]

I was thinking you might use 
git+https://github.com/python/cpython.git/Doc with a set checkout id 
using the GitHub PortGroup, but that would require building the docs.


How about using https://docs.python.org and relying on python.org's SSL 
cert to ensure the integrity rather than the MacPorts checksum?


Russell

On 05/01/16 20:10, Eric A. Borisch wrote:

On Tue, Jan 5, 2016 at 1:03 PM, Clemens Lang  wrote:

Hi,

On Tue, Jan 05, 2016 at 12:44:49PM -0600, Ryan Schmidt wrote:

I'm not comfortable with installing unchecked files on user systems.
The whole point of the checksum system is to verify that the files
that are installed on user systems are the same files that were tested
by the maintainer. By skipping the checksum phase you remove that
safeguard.

I agree, please revert that. This is an invitation for attackers.

I'd prefer to avoid it, obviously. Suggestions, then?

This is a tarball of documentation coming directly from
docs.python.org, which seem to be regenerated nightly (with new
checksums). The other versions are available in a stable form
(http://www.python.org/ftp/python/doc) but not the latest for 34
(3.4.4) or 35 (3.5.1). If there is another, stable, download location,
I'd be happy to point to it.

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


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

Re: [144262] trunk/dports/lang/py-htmldocs/Portfile

[Daniel J. Luke]

The general solution to this problem is to create a stable (snapshot) mirror 
somewhere else.

> On Jan 6, 2016, at 5:44 AM, Russell Jones  
> wrote:
> I was thinking you might use git+https://github.com/python/cpython.git/Doc 
> with a set checkout id using the GitHub PortGroup, but that would require 
> building the docs.
> 
> How about using https://docs.python.org and relying on python.org's SSL cert 
> to ensure the integrity rather than the MacPorts checksum?
> 
> Russell
> 
> On 05/01/16 20:10, Eric A. Borisch wrote:
>> On Tue, Jan 5, 2016 at 1:03 PM, Clemens Lang  wrote:
>>> Hi,
>>> 
>>> On Tue, Jan 05, 2016 at 12:44:49PM -0600, Ryan Schmidt wrote:
 I'm not comfortable with installing unchecked files on user systems.
 The whole point of the checksum system is to verify that the files
 that are installed on user systems are the same files that were tested
 by the maintainer. By skipping the checksum phase you remove that
 safeguard.
>>> I agree, please revert that. This is an invitation for attackers.
>> I'd prefer to avoid it, obviously. Suggestions, then?
>> 
>> This is a tarball of documentation coming directly from
>> docs.python.org, which seem to be regenerated nightly (with new
>> checksums). The other versions are available in a stable form
>> (http://www.python.org/ftp/python/doc) but not the latest for 34
>> (3.4.4) or 35 (3.5.1). If there is another, stable, download location,
>> I'd be happy to point to it.
>> 
>> Thanks,
>>   - Eric

-- 
Daniel J. Luke  
 
++ 
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++ 
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++





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

KDE4/KF5 "cohabitation"

[René J . V . Bertin]

Hello Nicolas,

I'm sure you've noticed that I'm making progress with ports for KF5. Maybe I 
should have asked your opinion on how to approach this (if so, apologies that I 
didn't), but I would like to know your thoughts on the issue of co-existence of 
KDE4 and KF5 ports.

KF5 is designed to allow for step-by-step migration of applications from KDE4 
to KDE5, but with the underlying idea that once an application has been 
migrated it's the better version and users are not supposed to feel the need to 
keep the older version around.

I have some issues with that premise and know of nothing in MacPorts that would 
make it the default behaviour to force a choice between either KDE4 or KF5 
versions of an application (fortunately, with all the inter-dependencies).

KF5 software doesn't leave a lot of leeway to configure it such that it won't 
clash with KDE4 versions of the same, in line with said premise. Fortunately 
most of the time the conflicts are limited to non-crucial things in 
${prefix}/share, usually even things that were not changed w.r.t. their KDE4 
version. So most of the time, the +kde4compat variant of a KF5 ports just omits 
files that are already installed by the KDE4 version of the port.

There are however certain modifications that have to be made to (certain) KDE4 
ports:

- The most frequent conflict occurs at the level of headerfiles. This can be 
avoided very easily by building KDELibs4 with 
-DINCLUDE_INSTALL_DIR=${prefix}/include/KDE4 . That puts the KDELibs headers 
under include/KDE4 but also records the path in a cmake module, so that it is 
inherited by all dependents.
The nice thing is that this change doesn't break binary compatibility, so I 
have set it unconditionally in my KDE4 PortGroup; it gets applied when a port 
is rebuilt.

- CMake modules are still an issue; I haven't yet found out a good way to 
install them to ${prefix}/lib/cmake/KDE4 . I'm looking into simply moving the 
files to a place outside the standard cmake include path (requiring 
CMAKE_PREFIX_PATH to be set) ... but that will only protect against file name 
clashes and against KF5 ports picking up cmake modules from KDE4 software :-/

- the biggest issue is with the libraries of some ports, e.g. kompare and 
libkomparediff2 . While the runtime libraries (lib*.x[.y].dylib) are usually 
distinguishable thanks to the version numbers, the linktime libraries 
(lib*.dylib) aren't always. Or the developers had the brilliant idea to use 
case, which means I won't always catch potential clashes because I use a 
case-sensitive filesystem.
Either way, I am fine-tuning a mechanism to be used with +kf5compat, a set of 
procedures where the 1st sets -DCMAKE_INSTALL_PREFIX=${kde4.legacy_prefix} 
(${prefix}/libexec/kde4-legacy) and the optional 2nd procedure moves a number 
of appropriate things back into ${prefix}. When you don't call that 2nd 
procedure you end up with an installation that requires dependents to be built 
with kf5compat too; fortunately it is enough to set CMAKE_INSTALL_PREFIX in 
identical fashion to make the build work in that case.
I've had to patch port:kdelibs4 to install a symlink 
(${kde4.legacy_prefix}/share -> ${prefix}/share) in order for this to work 
perfectly, but everything indeed seems to work just fine like that, including 
full transparency at runtime.

I haven't had to rebuild a single KDE4 port because one of its dependencies was 
rebuilt using the hacks above, but that may just mean that I have yet to 
encounter a problem port.

This is where I could use help from others who have KDE4 ports installed, the 
more complicated the dependencies the better.
There is only so much time I can devote to checking existing KDE4 ports (which 
do not yet have a KF5 version) against the compatibility changes I've been 
making, in addition to the time I spend developing KF5 ports.

Help could come in 2 or 3 forms:
- install my KDE4 portgroup and port:kdelibs4. Check what effect that has on 
your existing KDE4 ports; should be transparent. Check if that's still the case 
after rebuilding them (supposing that works out OK). One set of ports that I 
haven't rebuilt is akonadi/kdepimlibs,kdepim,kdepim-runtime because those are a 
bit too crucial for me...

- idem, but also build the ports from my repository that have a +kf5compat 
variant, with that variant selected. Again you should not notice any change.

- provide me with a reasonably fast and reasonably close-by (from France) VM on 
which I experiment a bit more freely than on my own, single system. (I'm a bit 
too late to leave hardware suggestions for Santa so I'll keep it at that ;))

Thanks for your attention :)

Cheers,
René

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

Re: [144262] trunk/dports/lang/py-htmldocs/Portfile

[Ryan Schmidt]

On Jan 6, 2016, at 4:44 AM, Russell Jones wrote:

> I was thinking you might use git+https://github.com/python/cpython.git/Doc 
> with a set checkout id using the GitHub PortGroup, but that would require 
> building the docs.
> 
> How about using https://docs.python.org and relying on python.org's SSL cert 
> to ensure the integrity rather than the MacPorts checksum?

An SSL certificate does not guarantee the user is getting the same files the 
maintainer did. It only guarantees the user is talking to the same server. The 
server could be compromised, or (as is the case here) the developers could 
issue stealth updates.


One solution is to let the MacPorts distfiles mirror mirror the file, then 
switch the portfile to only look at the distfiles mirror, not the original 
server. This would need to be done every time you update the port. See the 
history of the graphviz-devel port for an example of this; their automated 
tarball generation system was recently changed and it now sometimes 
inadvertently repackages the current version with a stealth update. If this is 
going to happen often, as seems to be the case with py-htmldocs, it can be 
automated in the Portfile, to a degree. See the curl-ca-bundle subport of the 
curl port for an example of that. 

The ideal would be to work with the developers to convince them not to issue 
stealth updates.


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

Re: pymol-devel obsolete?

[Ryan Schmidt]

On Jan 5, 2016, at 5:19 PM, David Strubbe wrote:

> I propose to make the port pymol-devel obsolete. There is a pymol port, which 
> is a newer version of the same software. It is not clear what, if any, 
> purpose pymol-devel serves, though years ago it was a newer version than the 
> pymol port (no clear reason was stated at the time for why this was useful, 
> either). pymol-devel has had no maintainer since 3 years ago (r105836). Since 
> that time it has not been updated, and only received maintenance commits. The 
> confusing nature of this port was discussed in this ticket a year and a half 
> ago: http://trac.macports.org/ticket/42860
> 
> Does anyone think pymol-devel should be kept?

I have no objection to marking pymol-devel "replaced_by pymol". I'm Cc'ing the 
maintainer of pymol in case he has an opinion on the matter.


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

Re: [144262] trunk/dports/lang/py-htmldocs/Portfile

[Daniel J. Luke]

On Jan 6, 2016, at 6:44 PM, Ryan Schmidt  wrote:
> An SSL certificate does not guarantee the user is getting the same files the 
> maintainer did. It only guarantees the user is talking to the same server.

it's not even that strong of a guarantee (especially since the recommendation 
here was seemingly to just verify that the certificate is 'valid').

> One solution is to let the MacPorts distfiles mirror mirror the file, then 
> switch the portfile to only look at the distfiles mirror, not the original 
> server. This would need to be done every time you update the port.

Can we make it easier for maintainers to add files to the mirrors? When we used 
to put files into subversion, it was easy for any maintainer to avoid this 
problem by just checking in a snapshot. While it's undesirable to go back to 
that (storing lots of binaries in our svn repo isn't a great idea), being able 
to upload a snapshot again would be welcome.

It would fix this and to some extent also make it less 'necessary' for people 
to have ports fetching from source control systems (giving everyone the benefit 
of having the files mirrored and cacheable).

> The ideal would be to work with the developers to convince them not to issue 
> stealth updates.

+1 for this as well.

-- 
Daniel J. Luke  
 
++ 
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++ 
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++





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

Re: uploading distfiles directly to the distfiles mirror

[Ryan Schmidt]

On Jan 6, 2016, at 7:51 PM, Daniel J. Luke wrote:

> On Jan 6, 2016, at 8:35 PM, Ryan Schmidt  wrote:
>> How would you envision this capability being provided? I wouldn't want to, 
>> for example, just open up ftp write access to the distfiles server to anyone 
>> who asked for it.
> 
> maybe for maintainers (or committers only)?
> 
> and probably 'sftp' instead of 'ftp'
> 
>> Would we make a web page where people can upload a distfile for a particular 
>> port?
> 
> sure, that would work too.
> 
> I would think people's mirrors would go in a user directory too (similar to 
> how the svn stuff worked) - so it would be obvious that it was a 
> maintainer/committer sourced distfile.

In that case, this is sounding like a different and separate file hosting 
service we could provide, not to be thought of as part of the distfile mirror.



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

Re: uploading distfiles directly to the distfiles mirror (was: Re: [144262] trunk/dports/lang/py-htmldocs/Portfile)

[Daniel J. Luke]

On Jan 6, 2016, at 8:35 PM, Ryan Schmidt  wrote:
> How would you envision this capability being provided? I wouldn't want to, 
> for example, just open up ftp write access to the distfiles server to anyone 
> who asked for it.

maybe for maintainers (or committers only)?

and probably 'sftp' instead of 'ftp'

> Would we make a web page where people can upload a distfile for a particular 
> port?

sure, that would work too.

I would think people's mirrors would go in a user directory too (similar to how 
the svn stuff worked) - so it would be obvious that it was a 
maintainer/committer sourced distfile.

> Would we make a new port command to submit a distfile?

that could work too (and might be a nice enhancement later to make it easier on 
maintainers) - but I don't think we need to wait for our (long) dev/release 
cycle to get something working.

> I don't really want to be in the business of distributing our own files. The 
> purpose of the mirror is to mirror files the developers provide elsewhere.

Sure, in the general case we shouldn't do it - but when the developer doesn't 
provide a good stable file (and/or only provides source from a source control 
system), then the best bad option is for us to create our own distfile.

-- 
Daniel J. Luke  
 
++ 
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++ 
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++





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

Re: uploading distfiles directly to the distfiles mirror (was: Re: [144262] trunk/dports/lang/py-htmldocs/Portfile)

[Ryan Schmidt]

On Jan 6, 2016, at 7:29 PM, Daniel J. Luke wrote:
> 
> Can we make it easier for maintainers to add files to the mirrors? When we 
> used to put files into subversion, it was easy for any maintainer to avoid 
> this problem by just checking in a snapshot. While it's undesirable to go 
> back to that (storing lots of binaries in our svn repo isn't a great idea), 
> being able to upload a snapshot again would be welcome.
> 
> It would fix this and to some extent also make it less 'necessary' for people 
> to have ports fetching from source control systems (giving everyone the 
> benefit of having the files mirrored and cacheable).

How would you envision this capability being provided? I wouldn't want to, for 
example, just open up ftp write access to the distfiles server to anyone who 
asked for it.

Would we make a web page where people can upload a distfile for a particular 
port?

Would we make a new port command to submit a distfile?


I don't really want to be in the business of distributing our own files. The 
purpose of the mirror is to mirror files the developers provide elsewhere.

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

Re: [144322] trunk/dports/python/py-keyczar/Portfile

[Ryan Schmidt]

> On Jan 6, 2016, at 10:12 AM, adfernan...@macports.org wrote:
> 
> Revision
> 144322
> Author
> adfernan...@macports.org
> Date
> 2016-01-06 08:12:47 -0800 (Wed, 06 Jan 2016)
> Log Message
> 
> python/py-keyczar: fix portfile for silent failures that only buildbot showed 
> (grr)
> Modified Paths
> 
>   • trunk/dports/python/py-keyczar/Portfile
> Diff
> 
> Modified: trunk/dports/python/py-keyczar/Portfile (144321 => 144322)

> +github.setupgoogle keyczar Python_release_0.715
> +
> +regexp {([^_]+)$} ${version} version

This is not the correct usage of the github portgroup. The correct usage is:

github.setupgoogle keyczar 0.715 Python_release_


> +fetch.type  git

Why must it fetch from git?


> +worksrcdir  python-keyczar-Python_release_${version}

Once the usage of github.setup is corrected as above, this line should be 
unnecessary.


> +build.cmd   cd python && ${python.bin} setup.py --no-user-cfg
> +destroot.cmdcd python && ${python.bin} setup.py --no-user-cfg

Using "cd" in a build.cmd/destroot.cmd is unusual. Is there a reason why you 
didn't instead set build.dir?


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

Re: [KDE/Mac] KDE4/KF5 "cohabitation"

[Ian Wadham]

Hi René and Nicolas and everybody,

On 07/01/2016, at 1:44 AM, René J.V. Bertin wrote:
> I'm sure you've noticed that I'm making progress with ports for KF5.

Yep.  Good on yer, René!

And it is nice to see that David Faure and other KDE core developers are taking 
an interest at last...

> KF5 is designed to allow for step-by-step migration of applications from KDE4 
> to KDE5, but with the underlying idea that once an application has been 
> migrated it's the better version

For KDE applications, "better version" = "only officially released version".  
There is only one
'master' branch in each KDE repository and that is the branch from which 
releases are made.
It is the branch where new features are developed and bugs are fixed.  A 
release is "maintained"
for a few months and, during that time, bug-fixes are supposed to be backported 
into the release.

> and users are not supposed to feel the need to keep the older version around.

In principle, a KF5 application, when first released, should have the same 
functionality as
the KDE4 application it replaces.  IIUC, the difference is supposed to be fewer 
extraneous
dependencies on libraries that used to be dragged in by using kdelibs4 and some 
shifting
of dependencies from KDE to Qt library classes, the most troublesome of which 
is the shift
from KStandardDirs to QStandardPaths… ;-)

Porting to Frameworks and Qt 5 is done on a 'frameworks' branch of the app's 
repository and
finally merged into 'master'.  If that work is done quickly, there should be 
few large changes
on the 'master' branch during the porting work.

In practice, of course, porting work does get held up, sometimes for months, 
and it is possible
(but unlikely?) for a lot of work to occur outside the 'frameworks' branch 
while it is open.

I have just been assisting a guy in porting KMahjongg, a KDE game.  It had a 
huge, years-old
branch that that ported some of the code from KDE 3 to KDE 4, but had never 
been merged
into 'master.…  That branch and 'master' contained a dozen or more bug fixes 
and there were
graphics glitches in the KDE 3-to-4 port that had to be fixed.  So yes, in this 
case the KF5
version, to be released in April, will definitely be "better".

Hopefully, that kind of mess will be the exception rather the the rule… but 
there are an awful
lot of unmaintained applications in the KDE code base these days.  The 
workforce is a small
fraction of the 500 or so developers KDE 4 had 5-8 years ago… :-(

> I have some issues with that premise

Having said the above, I agree entirely, René.  I have, and always have had, 
issues with the
idea that a newer version is automatically better...

I have experienced many regressive releases of KDE apps, some due to apps 
changes and
some due to library changes --- even of my own apps, in cases where I had made 
no change.

Also, if there is ever a KF5 port of KMyMoney, I would hesitate to entrust all 
my finances to it
on day one… ;-) … with all due respect to Marko and the KMyMoney developers.

> and know of nothing in MacPorts that would make it the default behaviour to 
> force a choice between either KDE4 or KF5 versions of an application 
> (fortunately, with all the inter-dependencies).

One hope I have is that MacPorts will help us avoid the day when KDE 4 and Qt 4 
libraries are
no longer released and apps that have not yet been ported to KF5 will just 
quietly disappear… :-(

On Linux, we lost a quite a few good KDE programs in the transition from KDE 3 
to KDE 4.

> KF5 software doesn't leave a lot of leeway to configure it such that it won't 
> clash with KDE4 versions of the same, in line with said premise. Fortunately 
> most of the time the conflicts are limited to non-crucial things in 
> ${prefix}/share, usually even things that were not changed w.r.t. their KDE4 
> version. So most of the time, the +kde4compat variant of a KF5 ports just 
> omits files that are already installed by the KDE4 version of the port.

The strategy on Linux is that an app is either KDE4 or KF5, no overlap.  Apps 
and the Frameworks
library are released separately, on different schedules.  See 
https://techbase.kde.org/Schedules …

Apps are released in KDE Applications YY.MM releases every four months and can 
be a mix of
KDE 4 and KF5 apps.  On Linux, KDE 4 libraries, Frameworks, Qt 4 and Qt 5 can 
co-exist, but
that is all.  Each app is either KDE 4 or KF5.

It would be very nice if MacPorts could be more flexible than that.

> There are however certain modifications that have to be made to (certain) 
> KDE4 ports:
> 
> - The most frequent conflict occurs at the level of headerfiles. This can be 
> avoided very easily by building KDELibs4 with 
> -DINCLUDE_INSTALL_DIR=${prefix}/include/KDE4 . That puts the KDELibs headers 
> under include/KDE4 but also records the path in a cmake module, so that it is 
> inherited by all dependents.
> The nice thing is that this change doesn't break binary compatibility, so I 
> have set it 

Re: uploading distfiles directly to the distfiles mirror

[Daniel J. Luke]

On Jan 6, 2016, at 8:53 PM, Ryan Schmidt  wrote:
> On Jan 6, 2016, at 7:51 PM, Daniel J. Luke wrote:
>> On Jan 6, 2016, at 8:35 PM, Ryan Schmidt  wrote:
>>> How would you envision this capability being provided? I wouldn't want to, 
>>> for example, just open up ftp write access to the distfiles server to 
>>> anyone who asked for it.
>> 
>> maybe for maintainers (or committers only)?
>> 
>> and probably 'sftp' instead of 'ftp'
>> 
>>> Would we make a web page where people can upload a distfile for a 
>>> particular port?
>> 
>> sure, that would work too.
>> 
>> I would think people's mirrors would go in a user directory too (similar to 
>> how the svn stuff worked) - so it would be obvious that it was a 
>> maintainer/committer sourced distfile.
> 
> In that case, this is sounding like a different and separate file hosting 
> service we could provide, not to be thought of as part of the distfile mirror.

I don't have a preference for which machine it's hosted on - if we could make 
use of one of the existing authentication mechanisms, though, that would be 
great.

-- 
Daniel J. Luke  
 
++ 
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++ 
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++





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